이 글에 대해
AI coding assistant 한 명에게 맡기는 일을 줄였다. Claude Code 를 main orchestrator 역할로 두고, 그 옆에 OpenAI Codex 플러그인을 adversarial reviewer 역할로 묶었다. Gemini 는 아직 결합하지 않았고, 세 번째 voter slot 으로 남겨뒀다.
이 글은 그 셋업 절차와, 각 도구에 어떤 역할을 줄지 정한 의사결정을 한꺼번에 적는다. 코드 디테일 critic 은 다른 모델에 맡기고, 본인 무게중심이 design 과 trade-off 판단 쪽으로 옮겨갔다는 운영 관찰과 수치까지 포함한다.
Gemini 결합은 적용된 셋업이 아니라 검토 중인 계획이다. 그 slot 을 비워둔 채로도 환경이 이미 굴러가고 있어 결합을 서두르지 않고 있다는 점을 미리 밝혀둔다.
§1단일 모델 답을 default 로 믿지 않기로 했다
1M context Opus 한 모델로 굴러가는 워크플로우에서, 가장 자주 부딪힌 한계는 모델의 능력 부족이 아니라 모델이 "단순한 길로 가버리는" 경향이었다. 합리적이고 잘 정돈된 답이 한 번에 나오면, 그 답이 놓친 제약을 본인이 critic 역할로 다시 짚는 일이 반복됐다.
이 critic 역할에 들어가는 시간을 본인이 직접 쓰는 일을 줄여야 한다는 판단이 환경 구성을 바꾼 계기였다. 두번째 의견을 기본값으로 두지 않으면, 그 비용을 결국 본인 시간으로 낸다.
본인 글로벌 컨피그(~/.claude/CLAUDE.md)에 정리해둔 운영 원칙도 같은 사고와 맞닿아 있다.
요청이 불명확하거나 여러 해석이 가능하면 즉시 확인한다. 구현 방식에 선택지가 있으면 2~3개 옵션을 제시하고 컴펌을 받은 뒤 진행한다. 실행 전 가정을 명시적으로 표명하고 틀릴 여지가 있으면 물어본다.
옵션 2~3개를 항상 노출하는 원칙은, 의사결정 기본값에 cross-check 를 심어둔 사고의 표현이다. 모델 한 명의 답을 그대로 받아 쓰는 흐름은 이 원칙과 정면으로 충돌했다. 환경이 그 원칙을 따라잡지 못하고 있었다.
단일 AI 모델로 끝낼지 vs 여러 모델을 voter로 묶을지
§2Claude Code 쪽 환경부터 강한 reasoning 에 정렬
멀티 voter 를 묶기 전에 main orchestrator 역할의 Claude Code 부터 reasoning 쪽에 무게가 실리도록 정리했다. ~/.claude/settings.json 에 넣어둔 값 몇 개가 그 의도를 그대로 보여준다.
{
"language": "korean",
"effortLevel": "xhigh",
"autoCompactWindow": 1000000,
"advisorModel": "opus",
"skipAutoPermissionPrompt": true
}effortLevel 을 가장 높게 잡고, autoCompactWindow 를 1M context 에 맞춰 키우고, advisorModel 을 Opus 로 고정했다. 메인 모델은 깊게 생각하고 길게 본다. 그 위에서 두 번째 의견을 받을 별도 채널을 따로 뽑는다.
활성 플러그인은 일곱 개를 켜뒀다.
"enabledPlugins": {
"jdtls-lsp@claude-plugins-official": true,
"superpowers@claude-plugins-official": true,
"skill-creator@claude-plugins-official": true,
"codex@openai-codex": true,
"swift-lsp@claude-plugins-official": true,
"ralph-loop@claude-plugins-official": true,
"ralph-skills@ralph-marketplace": true
}이 중 codex@openai-codex 한 줄이 이 글의 역할 배치 의사결정의 출발점이다.
§3Codex 를 어떤 역할로 둘 것인가
Codex 플러그인을 켜는 일은 어렵지 않았다. 역할 결정이 본격적인 의사결정이었다. 한 모델에 다른 모델을 더할 때 가장 자연스럽게 검토되는 후보가 셋이다.
대안 A. 주된 코드 작성자
Claude Code 의 main orchestrator 역할을 Codex 로 교체하거나, 적어도 코드 작성의 절반을 Codex 에 넘긴다. 모델의 코드 생성 디테일이 강한 점을 살리는 쪽.
대안 B. 막힐 때만 rescue 전용
Claude 가 반복 실패하거나 논리적 막힘에 걸렸을 때만 /codex:rescue 로 위임. Codex 플러그인의 codex:codex-rescue subagent 가 정확히 이 역할을 가정하고 정의돼 있다.
Proactively use when Claude Code is stuck, wants a second implementation or diagnosis pass, needs a deeper root-cause investigation, or should hand a substantial coding task to Codex through the shared runtime.
대안 C. Adversarial reviewer
Claude 가 작성한 결과를 Codex 가 다른 모델의 시선으로 비판한다. /codex:adversarial-review 는 이 역할을 직접 가정하는 slash command 다. "Challenge review that questions the chosen implementation, design choices, tradeoffs, and assumptions" 라는 정의가 그대로 들어 있다.
A 는 main orchestrator 역할을 흔드는 결정이라 보류했다. B 는 사용 빈도가 낮다. Claude 가 명백히 막히는 일은 자주 나오지 않고, 그때 가서야 두번째 의견을 들이면 cross-check 인사이트가 너무 늦게 들어온다. 결국 C 로 갔다. Claude 가 작성과 1차 판단, Codex 가 그 결과에 대한 critic. 이 배치가 default 가 됐다.
Codex 를 어떤 역할로 둘지
세 도구의 역할 배치를 한 컷으로 모으면 다음과 같다.
Claude Code 를 main orchestrator 역할로 두고, 왼쪽 아래에 OpenAI Codex 를 adversarial reviewer 역할로, 오른쪽 아래에 Gemini 를 결합 보류 상태의 voter slot 으로 배치한 역할 도식
Codex 결합 셋업 절차
플러그인 자체 등록은 settings.json 의 두 블록으로 끝난다. 마켓플레이스 등록과 활성화.
"extraKnownMarketplaces": {
"openai-codex": {
"source": {
"source": "github",
"repo": "openai/codex-plugin-cc"
}
}
},
"enabledPlugins": {
"codex@openai-codex": true
}마켓플레이스가 잡히면 /plugin install codex@openai-codex 로 설치하고, 첫 사용 전에 /codex:setup 으로 CLI 인증 상태를 점검한다. Adversarial review 는 /codex:adversarial-review 로 호출하고, review 결과는 verbatim 으로 반환되어 Claude 가 paraphrase 하지 않는다. 결과를 그대로 받아보는 점이 cross-check 의 가치를 흐리지 않는다.
운영상 자주 쓰는 호출은 셋이다.
/codex:adversarial-review: 작업 단위 끝에 default 로 한 번 돌린다./codex:rescue: 명백한 막힘에 한정해 위임./codex:status,/codex:result: 백그라운드 review 의 결과 확인.
§4code-task-agent 를 직접 만든 이유
Codex 의 codex-rescue subagent 가 위임 패턴을 처리해주는데도, 별도로 ~/.claude/agents/code-task-agent.md 를 직접 작성해 두고 있다. 둘은 비슷한 역할로 보이지만 실제는 다르다.
codex-rescue 는 "thin forwarding wrapper around the Codex companion task runtime" 이다. Claude Code 외부의 다른 모델 (OpenAI Codex CLI runtime) 로 작업 자체를 넘기는 외부 위임이다. 본인이 직접 작성한 code-task-agent 는 그 반대편에 있다. Claude Code 의 sub-agent 로서 도메인 규칙을 강제하는 isolated sub-context worker 다.
규칙을 그대로 옮기면 이렇다.
- 커밋 금지: git commit 실행 불가. 코드 수정과 테스트까지만.
- 설정 파일 읽기 금지: application*.yml/yaml/properties, .env*, secrets.* 접근 불가.
- 사용자와 대화 금지: 질문하거나 확인을 구하지 않는다. 판단이 필요하면 보수적으로 결정.
- Pre-flight 검증, CLAUDE.md 읽기, 패턴 문서 읽기, Grep 우선 탐색, 컴파일 검증, LSP self-check, 자가검증.
- 구조화 JSON 반환.같은 sonnet 모델을 쓰지만 역할 자체가 다르다. 외부 모델로의 위임은 codex-rescue 가 맡고, Spring/Java 도메인 규칙을 강제하는 isolated worker 는 code-task-agent 가 맡는다. 한 에이전트에 한 가지 일을 시키는 원칙이 깨지지 않도록 둘을 분리해 둔다.
§5Gemini 를 결국 어디에 끼울지
여기서부터는 적용된 셋업이 아니라 검토 중인 Gemini 결합 계획이다. Gemini 는 아직 환경에 들어와 있지 않고, Claude 와 Codex 의 cross-check 가 default 로 굴러가고 있어 결합 시점을 서두르지 않고 있다.
비워둔 slot 에 어떤 역할을 맡길지 후보가 셋이다.
후보 A. 대용량 컨텍스트와 긴 문서 분석 보조
Gemini Pro 계열이 가진 큰 컨텍스트 윈도우를 운영 로그, 대규모 코드베이스, 설계 문서 요약 역할에 둔다. 이 역할은 Claude Code 의 1M context 와 직접 겹친다. Claude 가 이미 1M context 로 동일한 일을 처리하고 있어, 추가 가치가 명확하지 않다는 점이 망설이는 이유다.
후보 B. 멀티모달 입력 보조
UI 스크린샷, 아키텍처 다이어그램, 차트, 로그 그래프를 Gemini 로 먼저 읽고 Claude 에 전달한다. 멀티모달 입력 빈도가 본인 워크플로우에서 아직 높지 않다. 이 역할은 결합 후 활용도가 워크로드에 크게 의존한다.
후보 C. Claude·Codex 와 다른 관점의 cross-check voter
설계·review·아키텍처 판단에서 세 번째 voter 로 둔다. Claude 가 작성, Codex 가 adversarial critic, Gemini 가 또 다른 시선으로 본다. 이 역할은 cross-check default 를 한 단계 더 확장하는 결정이다.
Gemini 를 결국 어떤 역할로 끼울지 (구상)
C 후보 쪽에 무게가 실린다. 이 글의 출발점이 단일 모델 답을 default 로 신뢰하지 않기였으므로, 같은 사고를 확장하는 역할에 Gemini 가 가장 자연스럽게 들어맞는다. 다만 결합 비용, 호출 분배 규칙, 결과 통합 규약을 더 다듬어야 결정이 굳어진다. 그 trade-off 를 정리하기 전까지는 slot 을 비워둔다.
§6관찰된 패턴과 수치, 그리고 한 가지 교훈
Codex adversarial review 를 default 로 두고 굴려보면, 작업 단위 4개 중 약 3개에서 한 건 이상의 critic 포인트가 짚힌다. 가장 자주 잡히는 패턴은 한 가지로 정리된다.
over-simplification. Claude 가 합리적인 단순화로 답을 낼 때, "여기 이 제약을 놓쳤다" 고 Codex 가 짚어주는 경향. 코드 디테일의 누락 (임포트 누락, 시그니처 불일치, off-by-one) 보다 상위에 있는 종류의 실수다. 단일 모델 한 답으로는 본인이 직접 critic 역할로 들어가지 않으면 놓치는 layer. 두 번째 모델의 다른 시선이 정확히 이 layer 를 잡는다.
흐름으로 그리면 4단계가 된다. 사용자가 task 를 던지고, Claude 가 작성과 1차 판단을 마치고, Codex 가 adversarial critic 을 verbatim 으로 회신하고, 사용자가 두 결과를 비교해 design·trade-off 결정을 내린다.
사용자 task 요청에서 시작해 Claude Code 작성, OpenAI Codex adversarial critic, 사용자의 design·trade-off 결정으로 이어지는 4단계 cross-check 흐름도. Codex 단계 결과는 verbatim 반환되어 paraphrase 없이 사용자에게 전달된다
수치로 보면 두 가지가 달라졌다.
- 본인 critic 검토 시간 약 30~40% 단축. 작업 단위 1개당 본인이 코드 디테일 검토에 쓰던 시간이 대략 그만큼 줄었고, 그 역할에서 빠진 시간은 design 판단과 trade-off 비교로 넘어갔다.
- over-simplification 적발 빈도 약 75%. 작업 단위 4개 중 약 3개에서 Codex 가 한 건 이상의 의미 있는 critic 포인트를 짚는다. 이 중 다수가 Claude 의 합리적인 단순화에 가려졌던 제약·엣지·결정 누락이다.
본인 무게중심이 옮겨갔다는 점이 이번 셋업의 가장 큰 변화다. 모델이 코드를 쓰고 다른 모델이 그 코드를 비판하면, 본인은 두 모델의 결과를 보고 어떤 분기로 갈지 정하는 곳으로 자연스럽게 이동한다. critic 에서 결정으로.
Gemini slot 을 비워둔 점은 단점이 아니다. 멀티 voter slot 에 도구를 채우는 일은 결합 비용과 결과 통합 규칙을 같이 정리해야 의미가 산다. 결합 후 운영 패턴을 한 번 더 관찰해야 결정이 굳어진다.
교훈은 한 가지다. Codex 를 처음부터 adversarial reviewer 역할로 뒀어야 했다. 처음에는 rescue 후보로 두고 시작했는데, 막힘이 자주 나오지 않아 default 사용 빈도가 낮았다. 역할부터 critic 으로 잡고 들어갔으면 cross-check 인사이트를 더 일찍 만났을 것이다. 새 도구를 어떤 역할로 둘지를 셋업 첫날에 정하는 결정이, 도구 자체를 도입하는 결정보다 운영 효과를 더 크게 좌우한다.