• AI 코딩 환경은 「어떤 모델이 똑똑한가」보다 「어떤 모델에게 무엇을 감사(Audit)하게 할 것인가」에 따라 품질이 달라진다
• Claude / Codex / Gemini를 user-level로 상설하고, 구현자·리뷰어·조사역을 나누면 확증 편향(Confirmation Bias)을 줄일 수 있다
• 핵심은 어떤 AI가 통솔자가 되더라도 동일한 규약·로그·리뷰 절차를 사용하여 활약할 수 있는 자기 정비된 환경을 만드는 것이다
• 리뷰 발화 조건을 CLAUDE.md, /AGENTS.md, /settings.json에 작성하고 로그를 남기면 개인의 기술에서 운용(Operation)으로 변화한다. 2026-05-27 시점의 체감으로는, Codex가 통솔력·독해력·파일 횡단 이해·성과물·속도의 종합력 면에서 가장 강력하다
• Gemini는 대규모 컨텍스트(Large Context)를 활용한 제3자 리뷰, Claude Code는 복잡한 파일 관계 파악과 Agents 통솔, Codex는 주 구현·diff review·통합 판단에 적합하다
• 복합 QA는 인간 리뷰의 대체가 아니라, 인간이 보기 전에 논점을 압축하기 위한 전단 필터로 사용한다 (컨텍스트를 너무 많이 가지고 있는 상황을, 컨텍스트를 가지지 않고 리뷰하는 차이를 이용한다)

Claude Code, OpenAI Codex, Gemini CLI와 같은 에이전트형 AI가 개발 환경에 들어오면, AI가 구현하고, AI가 테스트하고, AI가 리뷰하는 흐름을 구축할 수 있게 된다. 다만, 동일한 모델에 구현과 리뷰를 가두면 자신의 전제를 스스로 긍정하는 구조가 되기 쉽다.

이 기사에서는 user-level의 AI 개발 환경에 Claude / Codex / Gemini를 병설하여, 복합적인 QA·리뷰 환경으로 사용하는 운용 방식을 정리한다. 대상은 솔로 개발이나 소규모 팀에서 AI 에이전트를 상용하며, "속도는 빨라졌지만, 정말로 품질이 올라가고 있는가"를 검증하고 싶은 개발자다.

결론부터 말하자면, 중요한 것은 "오늘 가장 강한 AI를 찾는 것"이 아니다. Claude, Codex, Gemini 중 어떤 것이 통솔자가 되더라도 동일한 규약, 동일한 외부 메모리, 동일한 리뷰 발화 조건, 동일한 안전 경계를 사용하여 업무를 진행할 수 있는 환경을 만드는 것이다. AI의 강약은 일 단위로 변한다. 그러므로 통솔자를 고정하기보다, 통솔자가 교체되어도 파탄 나지 않는 작업 환경을 user-level에 정비한다.

• 상황 / 과제
• 후보 / 트레이드오프 (Trade-off)
• 채택안과 이유
• 구현 발췌
• 운용상의 배움
• 회고
• 요약
• 참고

AI 에이전트를 도입하면 구현 속도는 즉시 올라간다. Claude Code에 사양을 전달하면 코드를 작성하고, Codex에 차이점(diff)을 보여주면 리뷰하며, Gemini에게 물으면 다른 각도의 우려 사항을 돌려준다.

문제는 그것들을 임기응변식으로 호출하기만 해서는 품질 보증(QA) 메커니즘이 되지 않는다는 점이다.

예를 들어, 구현한 AI와 동일한 AI에게 "리뷰해줘"라고 부탁하면 컨텍스트 공유가 너무 강하다. 왜 그런 설계를 했는지 알고 있기 때문에, 전제의 타당성이 아니라 구현의 정합성(Consistency)만을 보게 된다. 이는 인간의 자기 리뷰와 마찬가지로 속도는 나지만 맹점은 남는다.

Claude Code 공식은 Claude Code를 다음과 같이 설명하고 있다.

"Claude Code is an agentic coding tool that reads your codebase, edits files, runs commands"

Codex도 마찬가지로 로컬 리뷰나 CLI 상의 워크플로우에 편입시킬 수 있다.

"Get your code reviewed by a separate Codex agent before you commit or push"

Gemini CLI는 터미널 상에서 Gemini를 사용할 수 있는 에이전트로 자리매김하고 있다.

"Gemini CLI is an open-source AI agent"

즉, 각 도구는 단독으로도 강력하다. 하지만 실무에서 효과적인 것은 단체 성능이 아니라 역할 분담과 상호 감사(Mutual Audit)의 설계였다.

여기서부터는 공식 기능에 대한 설명이 아니라, 2026-05-27 시점에 나의 user-level 개발 환경에 상설하고 있는 AI를 비교 사용해 본 운용상의 인상이다. 모델이나 서비스는 빈번하게 바뀌므로, 절대 평가가 아니라 "지금 이 환경에서는 어떤 역할을 맡기는 것이 사고가 적은가"라는 실무 메모로서 읽어주길 바란다.

다만, 이 표는 서열표가 아니다. 2026-05-27 시점에서는 Codex를 통솔자로 두는 것이 가장 안정적이지만, Claude Code가 통솔자가 되는 날도, Gemini가 큰 문맥(Context)을 쥐고 리뷰를 주도하는 날도 있을 것이다. 그러한 교체를 허용할 수 있도록 규약·기록·리뷰 절차를 AI의 외부에 둔다.

"Many Gemini models come with large context windows of 1 million or more tokens."

이 '크게 전달할 수 있는' 성질은 리뷰 환경에서 상당히 효과적이다. 코드 단독이 아니라 설계 메모, 테스트 로그, 에러 이력, 과거 리뷰를 함께 전달할 수 있기 때문이다. 반면, 파일 A의 미묘한 변경이 파일 B의 초기화 순서를 깨뜨리는 것과 같은 관계성 추적은 Claude Code나 Codex 쪽이 더 안정적인 경우가 있다.

Claude Code는 공식적으로도 subagent에 의한 컨텍스트 (Context) 분리와 위임을 전제로 하고 있다.

"Each subagent runs in its own context window"

이 때문에 복잡한 리포지토리 (Repository)를 탐색 역할, 구현 역할, 리뷰 역할로 나누어 운용하는 방식과 궁합이 좋다. 특히 '이 변경사항이 어떤 파일군을 건드려야 하는가'를 고민하는 단계에서 강하다. 다만, 같은 Claude Code라도 시간대나 세션 상태에 따라 출력 품질의 변동이 느껴진다. 일본 시간 기준으로 밤에 품질이 떨어진다는 체감은 공식 사양은 아니며 나의 운용 로그상의 관찰이지만, 실무에서는 중요한 제약 사항으로 취급하고 있다. 밤에는 대규모 구현을 맡기지 않고 리뷰·조사·작은 수정 위주로 돌린다.

Codex는 2026-05-27 시점 나의 환경에서 가장 신뢰하고 있다. OpenAI도 Codex를 "agentic software engineering"에 최적화된 것으로 설명하고 있다.

"trained on complex, real-world engineering tasks"

실제 운용에서도 파일 횡단 읽기, 변경 방침 정리, 테스트 추가, diff review까지의 흐름이 빠르다. Claude Code가 '관계성을 파악하는 것'에 강하다면, Codex는 '파악한 관계성을 파손되기 어려운 결과물로 도출하는 것'에 강하다. 현시점에서는 주 구현을 Codex, 무거운 타 관점 리뷰를 Gemini, 복잡한 태스크 분해나 Agents 통솔을 Claude Code로 배치하는 것이 가장 안정적이다.

특징: Claude Code를 중심으로 구현·테스트·리뷰·최종 응답까지를 동일한 AI에게 맡김 -
장점: 컨텍스트 (Context)가 단절되지 않는다. 구현 의도를 파악한 상태로 리뷰할 수 있다. 조작이 적다 -
단점: 구현 시의 전제를 리뷰 시에도 끌어온다. 설계 판단의 타당성보다 구현 정합성 확인에 치우치기 쉽다 -
예상 비용: 저~중. 추가 도구의 인증이나 로그 운용은 불필요

특징: Claude가 구현하고, Gemini가 제3자 리뷰를 수행함 -
장점: 서로 다른 모델이 콜드 리드 (Cold Lead)하므로 확증 편향을 줄일 수 있다. 설계·예외 처리·성능 우려에 대한 지적이 나오기 쉽다 -
단점: Gemini에게 전달할 컨텍스트 (Context) 설계가 필요하다. 코드베이스 전체가 아니라 diff나 설계 메모를 어떻게 추출하느냐가 품질을 좌우한다 -
예상 비용: 중. deep review는 발화 조건을 좁힐 필요가 있음

특징: Claude를 구현·통합 판단, Codex를 차분(diff) 리뷰·안전 경계, Gemini를 독립 리뷰·세컨드 오피니언(Second Opinion)으로 분리 -
장점: 모델뿐만 아니라 도구의 특화 영역도 나눌 수 있다. CLI, GitHub, 로컬 리뷰, 조사를 조합하기 쉽다 -
단점: user-level 규약, 발화 조건, 로그 저장소를 정비하지 않으면 운영이 산만해진다. 리뷰 결과의 충돌을 판정할 최종 판단자가 필요 -
예상 비용: 중~고. 상시 deep review가 아니라, 중요한 국면에서만 다중화하는 설계가 필요

채택: 후보 C

이유는 AI를 '한 명의 만능 개발자'로 다루기보다, '여러 전문 역할(컨텍스트 양의 차이)'로 다루는 것이 리뷰 품질을 설계하기 더 쉬웠기 때문이다.

또 하나 중요한 것은 통솔자를 고정하지 않는 것이다. 오늘의 주역이 Codex이든, 내일의 주역이 Claude Code이든, 혹은 거대 컨텍스트를 쥐고 있는 Gemini이든 상관없다. 중요한 것은 어떤 AI가 선두에 서더라도 동일한 작업 원칙으로 돌아올 수 있다는 점이다.

따라서 채택안은 'Codex을 중심으로 한다'가 아니라, Claude / Codex / Gemini 중 어느 것이라도 통솔자가 될 수 있는 user-level 환경을 만드는 것이다. 현시점에서는 Codex을 주 구현체로 두는 경우가 많지만, 이는 환경상의 기본값(default)일 뿐 고정된 조직도가 아니다.

Claude Code는 코드베이스를 읽고 파일 편집이나 명령 실행까지 수행하는 구현자로 다루기 쉽다. CLAUDE.md, skills, hooks와 같은 운영 규약을 읽히기 용이하며, 프로젝트 고유의 규칙을 구현 플로우에 태울 수 있다.

특히 강한 점은 복잡한 파일 관계를 읽고 '어떤 탐색을 어느 Agent에게 맡길 것인가'를 결정하는 장면이다. 구현 그 자체보다 작업을 분해하고, 여러 서브 에이전트(Sub-agent)로부터 돌아온 정보를 통합하는 역할에 적합하다.

단, Claude가 작성한 코드를 Claude만으로 최종 승인하면 자기 리뷰(Self-review)가 된다. 또한, 2026-05-27 시점의 내 환경에서는 시간대에 따른 출력 품질의 편차가 크다. 따라서 Claude Code은 '복잡한 관계성 파악 + Agents 통솔'로 설정하고, 중요한 리뷰나 최종 확인은 다른 모델로 넘긴다.

Codex는 CLI, IDE, 클라우드, GitHub 등 여러 방면에서 사용할 수 있다. 특히 리뷰 대상이 diff로서 명확한 경우, '이 변경이 의도대로인가', '테스트는 충분한가'를 확인하는 리뷰어로서 사용하기 쉽다.

여기에 더해, 2026-05-27 시점의 내 환경에서는 주 구현체로서 가장 안정적이다. 통솔력, 독해력, 파일 횡단 이해, 결과물, 속도의 밸런스가 좋아 여러 파일에 걸친 수정에서도 파손되기 어렵다.

OpenAI는 Codex의 안전한 운용에 대해 샌드박스(Sandbox)와 승인의 관계를 명시하고 있다.

"Approvals and sandboxing work together."

이 사상은 user-level 환경에도 그대로 적용할 수 있다. 저위험 읽기나 테스트는 자동화하고, 외부 통신·파괴적 조작·권한 외 파일 편집은 승인 단계를 거치게 한다.

Gemini CLI는 settings.json이나 환경 변수, 프로젝트 설정을 가질 수 있어 리뷰 전용 사용법을 정의하기 쉽다.

"Gemini CLI uses JSON settings files for persistent configuration."

Gemini는 구현자가 아닌 '다른 관점의 감사역'으로 참여시킨다. 거대한 컨텍스트를 전달할 수 있으므로 diff, 사양, 에러 로그, 과거의 판단을 한꺼번에 읽히는 리뷰에 적합하다.

반면, 복잡한 파일 간의 의존 관계를 정밀하게 추적하는 역할은 서툰 장면이 있다. 따라서 Gemini에게는 '이 설계는 위험한가', '이 차분에 놓친 관점이 있는가'를 묻고, 실제로 어떤 파일을 어떻게 고칠지는 Codex 또는 Claude Code로 되돌린다.

~/.claude/CLAUDE.md나 ~/.codex/AGENTS.md와 같은 user-level 규약에 AI 간의 역할 분담을 명문화한다.

## AI QA Roles
- Claude: 구현, 설계 정리, 태스크 분해, 최종 통합 판단
- Codex: 주 구현, 로컬 diff 리뷰, 테스트 부족 확인, 안전 경계 확인
...

여기서 중요한 것은 AI에게 '필요하면 리뷰해줘'라고 모호하게 적지 않는 것이다. 발화 조건을 구체화하지 않으면 긴 작업 도중에 리뷰가 누락된다.

나아가, 통솔자(Leader)가 바뀌더라도 읽을 수 있는 공통 프로토콜(Common Protocol)로 만들어 둔다.

## Leader-Agnostic Protocol
어떤 AI가 통솔자가 되더라도, 다음을 반드시 실행한다.
1. 작업 전에 user-level 규약을 확인한다
...

이렇게 구성하면 Claude Code가 통솔자이든, Codex가 통솔자이든, Gemini가 리뷰를 주도하든 최소한의 작업 품질이 동일해진다. AI의 능력 차이를 흡수하는 것은 프롬프트(Prompt)가 아니라 환경 측면의 프로토콜(Protocol)이다.

이전에는 Claude 구현을 기점으로 삼았으나, 2026-05-27 시점에는 Codex를 주 구현(Main Implementation)으로 두는 경우가 늘고 있다. 전형적인 흐름은 다음과 같이 설정한다.

# 1. Codex가 구현 및 테스트를 실행
codex "이 버그를 수정하고 관련 테스트를 추가해줘"
# 2. Codex 또는 Claude Code가 commit 전의 차분(diff)을 리뷰
...

git diff

전체가 너무 큰 경우에는 대상 파일과 설계 메모로 나눈다.

git diff -- src/app/auth src/app/api > /tmp/review.diff
gemini <<'PROMPT'
다음 차분을 구현자와 독립된 QA 담당자로서 리뷰해 주세요.
...

실운용에서는 shell을 연결하는 방법보다 "무엇을 넘기고, 무엇을 반환하게 할 것인가"가 더 중요했다. 리뷰 출력 형식을 고정하면 Claude 측에서 수정 태스크(Task)로 되돌리기 쉽다.

AI 리뷰를 운용(Operation)으로 가져가려면 리뷰 결과를 남겨야 한다. 매번 채팅창에 흘려보내기만 해서는 동일한 지적 사항이 반복되고 있는지 확인할 수 없다.

surreal-query.sh --review-create \
--mode "qa" \
--model "gemini" \
...

로그화하는 항목은 최소한이면 충분하다.

target: 무엇을 리뷰했는가 -
mode: qa / deep / issue / error 등 -
model: 어떤 AI가 리뷰했는가 -
tags: 나중에 검색하기 위한 분류 -
content: 지적 내용과 채택 여부

이를 통해 "Gemini가 몇 번이고 같은 종류의 테스트 부족을 지적하고 있다", "Codex는 호환성 리스크를 잡아내지만, 사양(Specification)의 전제 누락은 Gemini가 더 잘 잡아낸다"와 같은 경향을 파악할 수 있다.

AI 도구의 성능 차이는 고정적이지 않다. 2026-05-27 시점에는 Codex를 주 구현으로 두고 있지만, 이는 영구적인 서열이 아니라 현시점의 실무 평가일 뿐이다.

따라서 user-level 규약에는 "어떤 AI가 우월한가"가 아니라 "지금은 어떤 AI에게 무엇을 맡길 것인가"를 적는다. 예를 들어, Codex의 결과물이 안정적인 시기에는 주 구현을 Codex에 집중시키고, Claude Code의 품질이 흔들리는 시간대에는 Agents 통솔과 조사에 집중한다. Gemini는 방대한 자료를 읽히는 리뷰 역할로 남겨둔다.

이러한 전환을 명문화해 두면 AI 환경의 유행이나 모델 업데이트에 휘둘리지 않는다.

복합 QA의 본질은 강력한 AI를 하나 선택하는 것이 아니다. 어떤 AI가 통솔자가 되더라도 활약할 수 있는 환경을 미리 갖추어 놓는 것이다.

통솔자에 의존하지 않기 위해, 다음 요소들을 AI의 외부에 배치한다.

이러한 환경이 있으면 AI의 역할을 유연하게 변경할 수 있다. Codex가 주도하는 날은 Codex가 규약과 로그를 읽고 진행한다. Claude Code가 주도하는 날은 Agents를 전환하고 필요한 리뷰를 Gemini나 Codex에게 넘긴다. Gemini가 주도하는 날은 방대한 설계 자료를 읽게 하고, 구현은 Codex나 Claude Code에게 되돌린다.

지휘자는 가변적이고, 환경은 고정되어 있다. 이러한 분리가 있으면 AI 모델의 유행이나 시간대에 따른 품질 변동에 강해진다.

모든 변경 사항에 Claude, Codex, Gemini의 3단계 리뷰를 적용하면 금방 무거워진다. 작은 문구 수정이나 국소적인 타입 수정까지 deep review(심층 리뷰)를 하면, 품질보다 마찰이 더 커진다.

운용상으로는 다음의 분기가 다루기 쉬웠다.

Claude는 "문제 없음", Gemini는 "위험", Codex는 "테스트 부족"이라고 말할 때가 있다. 이때 다수결로 결정하는 것은 위험하다.

채택하고 있는 판정 규칙은 단순하다.

Blocking(차단) 지적은 인간 또는 최종 통합자가 근거를 확인할 때까지 무시하지 않는다AI의 결론이 아니라, 재현 절차·해당 코드·실패 조건을 확인한다리뷰 결과가 충돌하면, 더 구체적인 증거를 제시한 AI의 지적을 우선한다

AI 리뷰는 판결이 아니라, 조사표로서 취급한다.

user-level(사용자 레벨)에는 "전체 프로젝트 공통 AI 운용"을 둔다. project-level(프로젝트 레벨)에는 "해당 리포지토리 고유의 빌드, 테스트, 설계 제약"을 둔다.

user-level:
- 어떤 AI를 어떻게 사용할 것인가
- 언제 리뷰를 실행할 것인가
...

이 분리를 하지 않으면, 다른 프로젝트로 옮겼을 때 "이전 프로젝트의 전제"를 AI가 끌어오게 된다.

개발 환경으로서 Claude / Codex / Gemini의 복합 QA를 갖추면, 단순히 내부 품질이 올라가는 것뿐만이 아니다. 외부에도 설명할 수 있는 개발 문화가 된다.

"AI를 사용하고 있습니다"로는 부족하다. 지금은 많은 개발자가 AI를 사용하고 있다. 차이가 나는 지점은 AI의 출력을 어떻게 검증하고, 어떻게 기록하며, 어떻게 인간의 판단으로 되돌리는가이다.

이 운용을 기사화하는 가치는 바로 거기에 있다. 채용 후보자에게도 "AI로 빠르게 작성한다"가 아니라 "AI끼리 감사하게 하고, 인간이 의사결정한다"라는 개발 문화를 보여줄 수 있다.

판단 시 중시한 축: 구현 속도가 아니라, AI의 출력을 어떻게 검증 가능하게 만들 것인가, 지휘자가 바뀌더라도 작업 품질을 유지할 수 있는가를 중시했다 -
양보한 부분: 2026-05-27 시점에서는 Codex가 가장 강력하다고 느끼고 있지만, 모든 것을 Codex에 가두지 않는다. 지휘자는 가변적으로 두어, 중요 판단에서는 Gemini나 Claude Code의 별도 관점을 남겨두었다 -
양보하지 않은 부분: 구현자와 리뷰어를 동일 모델에 가두지 않는 것. 적어도 중요 변경에서는 별도 모델의 관점을 넣는다 -
다시 판단한다면: 처음부터 review_log의 스키마를 정비하여, 리뷰 지적의 채택 여부까지 기록해 둔다. 나중에 경향 분석을 하기 쉬워진다

• user-level AI 환경에서는 Claude / Codex / Gemini를 "여러 전문 역할(Role)"로 취급하면 품질 보증에 사용하기 쉽다

• 핵심은 어떤 AI가 지휘자가 되더라도 움직일 수 있도록, 규약·로그·외부 메모리·안전 경계를 AI 외부에 마련해 두는 것이다

• 2026-05-27 시점의 체감으로는 Codex가 주 구현·diff review·통합 판단의 중심이 된다

• Claude Code는 복잡한 파일 관계 파악과 Agents(에이전트) 지휘, Gemini는 대규모 컨텍스트의 제3자 QA와 deep review로 나눈다

• 실행 조건을 규약 파일에 명문화하지 않으면, 복합 QA는 임기응변식 상담으로 끝나버린다

• 리뷰 결과는 로그화하여, 동일한 지적이 반복되고 있지 않은지 나중에 확인할 수 있는 상태로 만든다

• AI 리뷰의 최종 목적은 AI에게 승인받는 것이 아니라, 인간이 봐야 할 논점을 압축하는 것이다

• Claude Code 개요 — Anthropic — Claude Code의 개요, CLI / IDE / browser / hooks / skills / MCP 등의 공식 설명

• 커스텀 서브에이전트(subagents) 생성 — Claude Code Docs — Claude Code의 subagent, 독립 컨텍스트, 에이전트 팀(Agent Teams)에 대한 설명

• 유료 Claude 플랜의 컨텍스트 윈도우(context window) 크기는 어느 정도인가? — Claude Help Center — Claude / Claude Code의 컨텍스트 윈도우에 관한 공식 도움말

• CLI — OpenAI Codex — Codex CLI의 설정, 로컬 코드 리뷰, 서브에이전트, 승인 모드(approval mode) 등의 공식 문서

• Codex — OpenAI — Codex의 제품 개요. CLI, IDE, 앱, 백그라운드 작업, 코드 리뷰에서의 위치

• Codex 업그레이드 소개 — OpenAI — GPT-5-Codex, 코드 리뷰, AGENTS.md 준수, 복잡한 태스크 처리 등에 관한 공식 설명

• Codex 앱 소개 — OpenAI — 다중 에이전트 병렬 실행, 워크트리(worktree), diff 리뷰에 관한 공식 설명

• (거의) 모든 것을 위한 Codex — OpenAI — Codex의 장기 태스크(long-term tasks), 메모리(memory), 소프트웨어 개발 생명 주기(SDLC) 전체로의 확장

• OpenAI에서 Codex를 안전하게 실행하기 — OpenAI — Codex를 안전하게 운영하기 위한 샌드박스(sandbox), 승인, 감사 로그(audit logs)에 대한 개념

• Gemini CLI 문서 — Gemini CLI의 공식 문서

• Gemini CLI 설정 — Gemini CLI의 user / project / system 설정 및 환경 변수 설정 방식

• 롱 컨텍스트(Long context) — Gemini API — Gemini의 1M 토큰 이상의 대규모 컨텍스트에 관한 공식 설명

• Gemini 모델 — Gemini API — Gemini 2.5 Pro의 입력 토큰 제한 및 롱 컨텍스트(long context)에 관한 공식 모델 사양

• Claude + Gemini 2단계 리뷰 문화 — LLM 리뷰를 개발 워크플로우에 통합하는 실례 — 본 기사의 앞부분에 해당하는 2단계 리뷰 운영

• 「자기 완결형 프롬프트(self-contained prompt)」를 통한 서브에이전트 운영 — Opus = PM / Sonnet = Worker — Claude 내부의 PM/Worker 분담 패턴

• SurrealDB를 「조직 기억(organizational memory)」으로 사용하는 운영 — review_log / output_log를 남기는 조직 기억 설계