삼태연구소
SAMTAELABS삼태연구소
가이드2026년 4월 29일·6분 읽기

Claude와 Codex를 한 레포에서 같이 쓰는 법: 두 AI 에이전트 역할 분담 워크플로우 (id.news.hada.io)

Claude CodeCodexAI 에이전트코드 리뷰 자동화듀얼 에이전트 워크플로우AGENTS.mdCLAUDE.mdpre-push hookAI 코딩 도구
Claude와 Codex를 한 레포에서 같이 쓰는 법: 두 AI 에이전트 역할 분담 워크플로우
목차(4)

한줄 요약

Claude Code가 코드를 쓰고, Codex가 advisory로 리뷰하는 역할 분담 구조로 단일 에이전트의 blind spot을 메운다.

어떤 상황에서 필요한가?

AI 코딩 도구를 하나만 쓸 때 가장 크게 느끼는 불편함이 있다. 같은 모델이 코드를 작성하고 스스로 리뷰하면, 자신이 세운 가정을 그대로 받아들이는 경향이 강해서 논리적 허점이 그냥 통과된다. race condition이나 null check 누락 같은 버그가 "이미 잘 작성됐다"는 확신과 함께 머지되는 상황이다.

이 문제는 사실 인간 코드 리뷰와 동일한 구조다. 한 사람이 PR을 작성하고 혼자 리뷰하면 regrssion을 잡기 어렵다. 그래서 팀에서는 다른 사람이 리뷰한다. AI 에이전트도 마찬가지다. 핵심은 "어떤 모델이 더 뛰어난가"가 아니라 "서로 다른 모델이 상대방의 가정을 검증할 수 있는가"다.

Claude Code의 slash command와 sub-agent 기능, Codex의 review/exec 분리, 그리고 AGENTS.md 같은 컨텍스트 파일이 갖춰진 지금이 이 구조를 실제로 도입할 수 있는 현실적인 시점으로 보인다.

핵심 구현 방법

역할 분리 원칙

Claude Code는 주 작성자, Codex는 advisory 리뷰어로 고정한다. 중요한 건 advisory는 절대 blocker가 되어서는 안 된다는 점이다. Codex가 CRITICAL 이슈를 발견해도 push는 통과된다. 한 번이라도 blocker로 바꾸면, 모델이 다운됐을 때 전체 작업이 멈추고, false positive 하나가 나오는 순간 사람들은 --no-verify로 hook 전체를 우회하기 시작한다. hook이 형식적 존재로 전락하는 순간이다.

CLAUDE.md와 AGENTS.md는 내용이 달라야 한다

두 파일의 내용이 80% 이상 겹친다면 역할 분담이 실제로 작동하지 않고 있다는 신호다. CLAUDE.md는 "어떻게 만들 것인가"에 집중하고, AGENTS.md는 "무엇을 의심해야 하는가"에 집중해야 한다. 작성자 입장의 지침과 리뷰어 입장의 체크리스트는 본질적으로 다르다.

codex review --base vs codex exec 선택 기준

codex review --base는 git을 직접 읽어서 깔끔하지만, 대형 PR에서는 token이 급격히 늘어난다. codex exec는 diff를 직접 prompt에 넣을 수 있어서 비용 통제가 가능하다. 변경 파일이 100개를 넘는 경우에는 exec 방식으로 전환하는 것이 실용적이다.

pre-push hook 이중 방어 구조

보안 파일 처리는 advisory 원칙과 별개다. .env, *.pem, secrets/ 같은 파일 패턴은 push 자체를 차단하고, sk-, ghp_, AKIA 같은 인라인 regex는 경고만 준다. 모델 output에 대한 "never block" 규칙과, 시크릿 파일이 외부로 나가는 보안 사고는 다른 범주다. 후자는 차단이 맞다.

graceful degradation wrapper

JSON envelope을 기본으로 하고 --raw 옵션으로 Markdown 출력을 지원한다. bash native timeout과 항상 exit 0으로 종료하는 구조를 유지하면, 호출하는 쪽은 status 값만 보고 분기하면 된다. 어느 한 에이전트가 응답하지 않아도 파이프라인이 죽지 않는다.

실전에서 주의할 점

한 달간 직접 운영한 경험을 담은 원문 내용에서 가장 인상적인 변화는 세 가지다.

첫째, merge 직전 버그 발견율이 올라간다. Claude가 자신 있게 "잘 작성됐다"고 판단한 코드에서 Codex가 race condition이나 null check 누락을 잡아내는 케이스가 실제로 반복된다.

둘째, self-review 피로감이 줄어든다. 다음 날 아침 자신이 쓴 코드를 보며 "왜 이렇게 썼지?"라는 감각이 거의 사라진다. 리뷰 시점에 이미 다른 관점이 한 번 들어갔기 때문이다.

셋째, SQL 마이그레이션이나 결제 흐름처럼 롤백이 어려운 변경에서 심리적 안전감이 다르다. 실행 전에 다른 모델이 한 번 더 봤다는 사실 자체가 의사결정의 질을 바꾼다.

구조 전체를 관통하는 핵심 통찰은 하나다. 두 에이전트가 서로의 gate가 되는 순간 이 워크플로우는 망가진다. 가치는 "서로를 막는 것"이 아니라 "서로의 blind spot을 겹쳐서 보완하는 것"에서 나온다.

자주 묻는 질문

Q.Claude Code와 Codex를 함께 쓰면 비용이 두 배가 되지 않나?

리뷰 방식 선택으로 비용을 조절할 수 있다. `codex review --base`는 token 소비가 크지만, `codex exec` 방식으로 전환하면 diff만 prompt에 넣어서 비용을 낮출 수 있다. 원문에서는 변경 파일 100개 이상일 때 exec로 전환하는 기준을 제시한다. 또한 Codex는 모든 커밋이 아니라 특정 단계에서만 호출하도록 파이프라인을 구성하면 추가 비용을 충분히 통제 가능한 수준으로 유지할 수 있다.

Q.AGENTS.md와 CLAUDE.md를 따로 관리하는 게 번거롭지 않나?

두 파일의 내용이 80% 이상 겹친다면 관리가 번거로운 게 아니라 역할 분리 자체가 실패한 것이다. 실제로 작성자용 지침과 리뷰어용 체크리스트는 성격이 달라서 자연스럽게 내용이 분리된다. CLAUDE.md는 구현 컨벤션과 아키텍처 결정 사항 위주, AGENTS.md는 보안 패턴, 예외 처리, 경계 조건 같은 의심해야 할 지점 위주로 작성하면 겹치는 부분이 생각보다 많지 않다.

Q.Codex가 CRITICAL 이슈를 발견했는데도 push를 막지 않으면 의미가 없지 않나?

advisory의 목적은 차단이 아니라 가시성이다. CRITICAL 리뷰 결과가 기록되고 개발자가 인지한 상태에서 의사결정을 내리는 것과, 아무것도 모른 채 push하는 것은 다르다. blocker로 만들면 모델 장애 시 전체 작업이 멈추고, false positive 하나에 팀 전체가 `--no-verify`를 쓰기 시작하면서 hook 자체가 무력화된다. advisory가 실질적으로 작동하려면 blocker가 되지 않는 것이 전제 조건이다.

직접 구축이 어렵다면, 전문가에게 맡겨보세요

대표 개발자가 직접 소통하고, 설계하고, 구축합니다. 중간 과정 없이 의도 그대로.

관련 아티클

관련 사례

이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.