요즘 X·디스코드에서 "Claude Code랑 Codex 같이 쓴다"는 글이 부쩍 늘어, 다들 좋다는데 진짜 그런지 한 달 정도 두 도구를 한 레포에 같이 깔고 굴려봤습니다. 막상 도입하려고 보니 어디서부터 셋업해야 하는지, 두 도구를 어떻게 분담시켜야 충돌이 안 나는지, AGENTS.md와 CLAUDE.md를 똑같이 채워도 되는지 결정 포인트가 한 트럭이라, 같은 고민으로 시작 못 하고 계신 분들이 시행착오를 줄일 수 있게 8챕터짜리 커리큘럼 형태로 정리해 두었습니다.
이중 에이전트 워크플로우는 단순합니다. 같은 모델에게 자기 코드 자기 리뷰를 시키면 자기가 쓴 가정을 그대로 받아들여 빈틈이 안 잡히니, 다른 모델을 advisory(차단 X) 리뷰어로 옆에 두는 구조입니다. Claude Code는 메인 작성자, Codex는 advisory 리뷰어. 어느 쪽이 더 똑똑하냐가 아니라 모델이 다르다는 점이 핵심이고, 둘이 서로의 게이트가 되는 순간 워크플로우가 깨지므로 advisory를 절대 차단으로 만들지 않는 것이 가장 큰 룰이 됩니다.
배경 — 정리하면서 다시 짚어본 변화
• 예전 질문: "어떤 AI 코딩 도구가 가장 좋은가"
• 지금 질문: "두 개 이상의 도구를 어떻게 분담시킬 것인가", "한 도구의 사각지대를 다른 도구로 어떻게 메울 것인가"
• Claude Code의 슬래시 커맨드·서브에이전트, Codex의 review/exec 분리, AGENTS.md 같은 컨텍스트 파일이 갖춰지면서 이중 구조를 워크플로우에 박는 것이 처음으로 현실적인 옵션이 된 시점
이중 구조 패턴의 핵심 (한 달 굴리면서 인상 깊었던 부분)
• advisory는 절대 차단이 아니다 — Codex가 CRITICAL을 잡아도 push는 통과. 차단으로 한 번 변하면 모델 다운에 작업 전체가 멈추고, false positive 한 번에 사용자가 --no-verify로 hook을 통째 우회하기 시작
• CLAUDE.md / AGENTS.md를 같은 내용으로 채우지 않는다 — 작성자에게는 "어떻게 만드는지", 리뷰어에게는 "무엇을 의심해야 하는지". 80% 이상 겹치면 분담이 사실상 안 되고 있다는 신호
• codex review --base vs codex exec는 유즈케이스로 나눈다 — review는 git을 직접 읽어 깔끔하지만 큰 PR에서 토큰 폭주, exec는 prompt에 diff를 직접 넣어 비용 통제 가능. 100파일 넘는 변경은 exec로 갈아타는 패턴
• pre-push hook의 시크릿 두 단계 방어선 — 파일 패턴(.env, *.pem, secrets/)은 push abort, 인라인 정규식(sk-, ghp_, AKIA…)은 경고만. advisory의 "never block"은 모델 출력 룰이고 시크릿 파일 push는 별개의 보안 사고라 차단이 정답
• graceful degradation 래퍼 한 개로 흡수 — JSON envelope 기본 + --raw Markdown, bash-native 타임아웃, 항상 exit 0. 호출자는 status만 보고 분기
한 달 써보고 달라진 점
• 머지 직전에 잡히는 버그가 늘어남. Claude가 "잘 짰다"고 자신만만한 부분에서 Codex가 race condition·누락된 null 체크를 짚어내는 케이스가 꽤 자주 발생
• PR 올린 다음 날 다시 열어보며 "어 이거 왜 이렇게 짰지" 하는 일이 거의 사라짐. 다른 시점이 한 번 들어간 뒤라 회귀 검토 비용이 줄어듦
• 자기 코드 자기가 들여다보는 셀프 리뷰 피로가 확연히 줄어듦. 사람 리뷰어 한 명을 더 붙인 효과
• 마이그레이션 SQL·결제 흐름처럼 되돌리기 어려운 변경 직전에 다른 모델이 한 번 더 본다는 점이 심리적으로 가장 큰 차이
커리큘럼 구성 (8챕터, 5파트)
• Part 1 두 에이전트 병용 사고법 · 1챕터 — 단일 에이전트의 사각지대, 비용 정당화 기준
• Part 2 환경과 컨텍스트 · 2챕터 — VSCode + Claude Code + Codex CLI 베이스 셋업, AGENTS.md vs CLAUDE.md 분담
• Part 3 리뷰 자동화 패턴 · 3챕터 — advisory 래퍼 스크립트, 슬래시 커맨드 멀티페이즈 파이프라인, pre-push hook 자동화
• Part 4 운영 가이드 · 1챕터 — 작업 유형별 도구 선택 트리, 비용·모델 가이드, Security & Privacy 섹션
• Part 5 보일러플레이트 · 1챕터 — 본인 레포에 그대로 깔 수 있는 래퍼·hook·CLAUDE.md/AGENTS.md 템플릿 한 묶음
정리하면서 들었던 생각
• 이중 구조의 진짜 가치는 "두 도구가 서로의 게이트가 되지 않는 것"이라는 점. 차단 한 번 허용하면 한쪽 다운에 작업이 멈추고, false positive 한 번에 사용자가 hook을 통째 우회하기 시작해 hook 자체가 무력화됨
• AI 도구가 빨라질수록 "어떤 도구를 쓰느냐"보다 "여러 도구의 사각지대를 어떻게 겹쳐 덮느냐"가 결정적인 변수가 되는 듯한 느낌. 사람 코드 리뷰를 둘 이상에게 받는 이유와 같은 구조
• AI 코딩 도구로 작업하면서 자기 코드를 자기가 다시 검토하는 것이 미덥지 않으셨던 분들, Claude Code와 Codex를 같이 깔까 말까 미루고 계신 분들이 같이 보면 좋을 것 같아 공유합니다. 잘못 이해하고 정리한 부분이 있으면 댓글로 알려주시면 반영하겠습니다.
저는 trilateral-validation이라고 claude subagent(fresh context)+codex+gemini 까지 붙여서 검증 스킬 하나 만들어두고 씁니다.
자잘한 오류 말고 방향성 자체를 틀어야 하는 실험이나 설계는 메인 개발은 클로드로 하고, gpt 5.5pro에 깃허브 앱달아서 검증시키구요.(codex가 프로 모델을 지원 안해서...)
프로덕션 개발은 안하고 연구만해서 생각못했는데 git hook도 한번 걸어봐야겠네요.
이렇게 하시는 분들 있다고 하는데, 어떤 방식일지가 궁금하네요.
두 도구를 별도의 에이전트로 묶지 않고, 개발자가 직접 필요할 때마다 각각 호출하는 건지,
Git Hook 할 때 자동으로 Codex가 리뷰를 하게 만드는 설정으로 조치하는 지 궁금하네요.
저희는 둘 다 사용하는 쪽으로 정착했습니다.
슬래시 커맨드 흐름 안에 Codex 교차 리뷰 페이즈를 넣어두고(/ship 안에 기획 → 구현 → 검증 → Codex 리뷰 → 보고 식으로), 동시에 pre-push hook에도 같은 리뷰를 걸어둡니다. 슬래시 커맨드만 두면 급할 때 그냥 push해서 리뷰가 빠지고, hook만 두면 push 직전에야 결과가 나와 늦습니다.
두 경로 모두 Codex CLI를 직접 부르지 않고, 한 번 감싼 bash 스크립트(codex-review.sh) 한 개를 양쪽에서 똑같이 호출합니다. 그 스크립트가 타임아웃, 인증 체크, 시크릿 체크, 출력 포맷을 한 곳에서 처리해줘서 슬래시 커맨드든 hook이든 호출 측이 깔끔해집니다.
핵심은 Codex 리뷰 결과로는 절대 차단하지 않는다는 점입니다. CLI가 죽었거나 CRITICAL이 나와도 push는 그대로 통과시키고 결과만 출력해요. 한 번이라도 차단으로 만들면, Codex가 실제로는 문제없는 코드를 잘못 잡았을 때 사용자가 push를 하려고 hook을 우회하는 옵션(git push --no-verify)을 쓰게 되고, 이게 습관이 되면 hook이 걸려 있어도 안 도는 것과 똑같은 상태가 됩니다. 그래서 차단이 필요한 검사(린트·타입·테스트, 시크릿 파일 push)는 별도 게이트로 분리하고, 모델 의견은 참고용으로만 둡니다.
스크립트·슬래시 커맨드·hook 본문은 트랙 4~6챕터에 그대로 들어 있으니 참고하셔도 좋을 것 같습니다.