역할 경계와 비용 판단 — 어디까지 Claude, 어디부터 Codex | Claude한테 짜게 시키고 Codex한테 까게 시키기

이 챕터를 끝내면 새로운 작업이 들어왔을 때 어떤 도구로 시작할지 1분 안에 결정할 수 있어요.

결정 트리

매 작업마다 다음 순서로 자문해요.

5분 안에 끝날 단발 작업인가? → 한 도구만. 평소 메인 도구로.
변경이 머지될 코드인가? → 작성 후 advisory 교차 리뷰 추가.
컨텍스트가 큰가? (수십 파일, 긴 문서) → 긴 컨텍스트에 강한 모델로 메인. 다른 모델로 리뷰.
독립 검증이 필요한 결정인가? (보안·결제·마이그레이션) → 두 도구 모두 독립적으로 분석시키고 결과 비교.
위 모두 아닌 탐색·실험·삽질 → 한 도구만. 결과가 머지로 안 가면 advisory 생략.

작업 유형별 권장

작업	메인	교차 리뷰
신규 기능 구현	Claude Code	Codex (advisory)
리팩터 (구조 변경)	Claude Code	Codex (advisory, 강하게)
버그 픽스 (작음)	메인 도구 한쪽만	생략 가능
마이그레이션 SQL	Claude Code	Codex (advisory, 필수)
보안 관련 변경	Claude Code	Codex (advisory, 필수)
문서 작성	메인 도구	생략
탐색·실험	메인 도구	생략
1회성 스크립트	메인 도구	생략

기준은 단순해요. 머지 후 되돌리기 어려운 작업일수록 advisory를 강하게.

비용 가이드

정기결제 두 개를 합리화하는 방법:

두 도구 모두 정기결제 — 종량제 청구서 충격 없이 호출 빈도를 마음껏 가져가기 위해
한 도구만 종량제 API + 다른 도구 정기결제 — advisory 호출이 많지 않다면
둘 다 종량제 API — advisory를 거의 안 돌리는 환경 (=이 트랙 적용 대상 아님)

`review` vs `exec` 토큰 곡선

advisory 호출 비용은 두 모드에서 다르게 흘러요. 큰 PR을 돌릴 때 한쪽이 갑자기 비싸질 수 있어요.

codex review --base — Codex가 본인이 git diff를 읽음. diff 크기가 그대로 토큰 비용에 반영되고 호출자가 통제할 수단이 없어요. 큰 머지 직전 PR이 비용 spike의 주범.
codex exec — prompt에 우리가 직접 diff를 넣으니 head -n 800 같은 상한으로 비용 통제 가능. 단, 큰 컨텍스트가 필요한 리뷰는 일부러 잘라야 하는 단점.

기본 흐름은 review로 가되, 100파일 이상 PR이나 마이그레이션 같은 거대 변경에선 exec + 직접 diff 발췌로 갈아타는 패턴을 알아둬요.

점검 주기

팀 운영이면 월말에 다음을 점검:

advisory 리뷰 호출 횟수 (push hook + 수동)
그 중 사용자가 결과를 실제로 본 비율
CRITICAL이 잡힌 횟수 vs 그 중 실제 행동으로 이어진 비율

1인 작업이면 월말 KPI 추적은 과해요. 분기마다 한 번 본인 push 흐름을 돌아보면서 "최근에 advisory 결과를 무시한 push가 몇 번이었나, advisory가 노이즈만 양산한 적이 있나" 정도만 자문해요.

마지막 비율이 10% 미만이면 advisory 프롬프트가 noise로 흐르고 있다는 신호예요. 프롬프트를 더 좁게 잡거나 advisory 페이즈 위치를 조정해요.

모델 선택 가이드

도구 안에서 모델을 고를 수 있다면:

Claude Code 메인 작업 — 가장 똑똑한 모델 (Opus 계열). 작성 품질이 작업 전체 품질을 좌우.
Codex advisory 리뷰 — reasoning effort high. 같은 비용이라면 한 번 깊게 보는 게 여러 번 얕게 보는 것보다 나음.
둘 다 빠른 모델은 비추 — 빠른 모델은 advisory가 noise만 양산해요.

보안과 운영 — `AGENTS.md`에 명문화하기

advisory 리뷰는 변경된 코드와 일부 컨텍스트를 외부 모델 제공자에게 보내는 작업이에요. 운영 룰을 흩어두지 말고 AGENTS.md의 "Security & Privacy" 섹션 한 군데에 모아두면, 신규 팀원도 hook을 켜기 전에 바로 읽고, Codex도 같은 룰을 컨텍스트로 받아요. 한 섹션에 6항목으로 충분해요.

3장의 "AGENTS.md 룰 5~10개" 가이드는 도메인 무결성 룰 카운트예요. 아래 Security & Privacy는 운영 정책에 가까운 고정 섹션이라 룰 카운트와 별개로 두면 돼요. 분량은 30줄 안쪽으로 압축해 80~150줄 가이드와 충돌 안 시키는 게 핵심.

## Security & Privacy

1. **외부 모델 전송**
   - advisory 리뷰는 diff와 일부 컨텍스트를 OpenAI(Codex)에 전송함
   - 고객사 NDA가 외부 모델 입력을 금지하면 해당 레포에서 비활성화

2. **절대 전송 금지 파일/디렉토리** (pre-push hook이 자동 차단)
   - `.env*`, `*.pem`, `*.key`, `*.p12`, `*.pfx`, `*.cer`, `*.crt`
   - `secrets/`, `credentials/`, `private-key*`
   - 위 경로는 `.gitignore`에도 무조건 등록

3. **인라인 시크릿 패턴** (pre-push hook이 경고만 출력, 진행)
   - `api_key/secret/password/token = "..."` (16자 이상)
   - `Bearer <20+자>`, `sk-...`, `ghp_...`, `AKIA[0-9A-Z]{16}`

4. **리뷰 결과 저장**
   - 로컬: `.git/codex-review.log` (git untracked), 7일 후 자동 삭제
   - CI: artifact 7~14일 보존, PR 작성자/리뷰어만 접근

5. **인증 관리**
   - 우선: `codex login` (OAuth, `~/.codex/` 토큰)
   - 대안: `OPENAI_API_KEY` env var (회사 계정 + SSO 권장)
   - `OPENAI_API_KEY`는 절대 git-tracked 파일에 두지 않음

6. **Escape hatch**
   - 임시로 advisory를 끄려면 `SKIP_CODEX=1 git push`
   - 장기 비활성화는 hook 자체 제거, 결정 사유는 PR로 남김

`SKIP_CODEX=1` escape hatch가 필요한 이유

advisory가 항상 켜져 있어야 한다고 우기면 곧 다음 일이 생겨요.

Codex 일시 다운에 본인(또는 팀 전원)의 push가 60~90초 늘어짐
false positive에 사용자가 --no-verify로 hook 자체를 우회하기 시작
한 번 우회 습관이 들면 hook이 무력화

SKIP_CODEX=1은 advisory codex 호출 부분만 건너뛰는 의도적 escape hatch예요. 보일러플레이트의 pre-push엔 advisory만 들어 있어 단독으로는 --no-verify와 효과가 같지만, 의미가 달라요.

SKIP_CODEX=1 — "이번 push만 codex 리뷰 빼겠다"는 명시적 의도. 시크릿 abort, 향후 추가될 다른 결정론적 게이트는 그대로 작동
--no-verify — pre-push hook 전체 무력화. 추후 pnpm preflight 같은 결정론적 게이트를 hook에 추가하면 그것까지 같이 우회됨

지금은 두 효과가 동치지만, hook이 advisory만 들어 있는 단계에서 컨벤션을 잡아두면 hook이 더 두꺼워졌을 때 사용자가 자동으로 "맞는 escape hatch"를 쓰게 돼요.

사내 보안 정책과 자주 충돌하는 지점

"코드는 사내 환경에서만 처리" — 현재 advisory 모델은 외부 SaaS라 충돌. 자체 호스팅 모델로 대체 가능한지 먼저 확인
"모든 외부 API 호출 감사 로깅 필요" — codex/claude CLI 호출도 감사 대상에 포함시켜야 함
"고객사 코드는 분리 머신에서만" — 정기결제 계정이 직원 개인 계정이면 위반 소지. 회사 계정 + SSO로 통일
"OpenAI/Anthropic 학습 미사용 보장" — enterprise 플랜은 보장, 개인 정기결제는 약관이 다를 수 있음. 계약 단위로 확인

체크 결과 한 가지라도 막혀 있으면 advisory를 끄는 게 정답이에요. "리뷰 한 번 더 받는 편익 < 한 번의 누출 사고 비용" 비대칭성이 큰 영역이에요.

안티패턴 정리

모든 작업에 advisory — 비용·시간 낭비. 머지 안 가는 코드는 생략.
두 도구가 서로의 게이트 — advisory가 차단으로 변하면 어느 한쪽 다운에 워크플로우가 멈춤.
두 도구 동시 작성 — 같은 파일을 동시에 수정하면 충돌. 메인 작성자는 한쪽만.
advisory 결과 무시 습관화 — 결과가 잡혀도 매번 무시하면 advisory 페이즈를 빼는 게 정직.
컨텍스트 분리 없이 두 도구 굴리기 — CLAUDE.md와 AGENTS.md가 같은 내용이면 이중 구조 의미 없음.

트랙 마무리

여기까지 따라왔다면 다음 능력이 손에 잡혔어요.

두 에이전트 병용의 의도와 한계 설명
환경 셋업과 컨텍스트 분리
advisory 래퍼·파이프라인·hook 셋
작업 유형별 도구 선택 기준

다음 단계는 본인 워크플로우에 적용하면서 마찰을 한 줄씩 CLAUDE.md/AGENTS.md에 추가하는 거예요. 이 트랙은 출발점이고, 실제 운영에서 만나는 엣지 케이스가 진짜 콘텐츠예요.