같은 저장소를 Claude Code와 Codex에 열고 동일한 요청을 준 적이 많다. 두 결과는 비슷한 파일을 수정했고, 나는 어느 구현을 남길지 다시 판단해야 했다. 토큰 사용량과 diff 검토량은 늘었지만 작업 범위는 줄지 않았다.
지금은 두 에이전트에 서로 다른 입력과 권한을 준다. 한 세션은 모호한 요구사항과 코드 경로를 조사한다. 다른 세션은 확정한 결정 안에서 코드를 고친다. 검토 세션은 구현 대화를 읽지 않고 diff와 검사 결과에서 결함을 찾는다. 모델 이름보다 역할의 입력을 분리하는 일이 결과에 더 큰 영향을 줬다.
작업 패킷부터 하나로 만든다
두 에이전트를 켜기 전에 내가 먼저 작업 패킷을 작성한다. 같은 문서를 기준으로 삼지 않으면 각 세션이 다른 문제를 풀기 시작한다.
목표: 사용자가 관찰할 변화
현재 상태: 관련 파일과 데이터 흐름
결정: 이미 확정한 인터페이스와 이름
금지 범위: 건드리지 않을 파일과 외부 시스템
완료 조건: 실행할 검사와 확인할 화면
미해결 질문: 조사 후 사람이 정할 항목
“로그인을 개선해 달라”는 목표는 두 에이전트가 나누기 어렵다. “세션 만료 시 로그인 페이지로 이동하고 작성 중인 입력은 보존한다”처럼 관찰할 동작을 적는다. 현재 상태에는 인증 미들웨어와 테스트 위치를 넣고, 금지 범위에는 데이터베이스 스키마와 배포 설정을 적는다.
저장소의 지속 규칙은 AGENTS.md에 둔다. Codex는 작업 전에 경로를 따라 AGENTS.md 지침을 읽고, 가까운 디렉터리의 지침을 뒤에 적용한다. 테스트 명령과 위험한 명령의 승인 기준을 파일에 두면 새 세션에도 같은 기준이 들어간다. 일회성 제품 결정은 작업 패킷에 남겨 저장소 규칙이 비대해지는 것을 막는다.
설계, 구현, 검토에 다른 입력을 준다
복잡한 변경에서 나는 역할을 다음처럼 나눈다.
| 역할 | 받는 입력 | 내놓는 결과 | 쓰기 권한 |
|---|---|---|---|
| 설계 | 요구사항, 관련 코드, 미해결 질문 | 결정 기록과 변경 계획 | 없음 |
| 구현 | 확정한 계획, 대상 파일, 검사 명령 | 최소 diff와 실행 결과 | 작업 파일 |
| 검토 | 요구사항, 전체 diff, 검사 로그 | 우선순위가 있는 결함 목록 | 없음 |
설계 세션에는 코드 작성을 금지한다. 코드 구조를 읽고 선택지의 비용을 비교하게 한다. 구현 세션에는 결정이 끝난 문서만 전달한다. 검토자는 구현자가 왜 그런 선택을 했는지 듣기 전에 요구사항과 diff를 대조한다.
Claude를 설계에 고정하거나 Codex를 구현에 고정하지 않는다. 저장소와 도구 사용 경험, 작업에 필요한 기능을 보고 역할을 정한다. 같은 세션이 계획부터 검토까지 이어가면 앞선 판단을 방어하기 쉬우므로 검토 컨텍스트는 분리한다.
Anthropic의 Claude Code 가이드는 코드 탐색, 계획, 구현, 검증을 순서대로 진행하는 흐름을 제시한다. Codex도 Git 저장소에서 /review를 실행하면 전용 검토자가 선택한 diff를 읽고 우선순위가 있는 발견 사항을 보고한다. 검토 과정에서 working tree를 바꾸지 않는 흐름이라 구현과 판정을 나누기 좋다.
병렬 조사와 병렬 구현을 구분한다
조사는 쓰기 충돌이 적다. 한 에이전트가 인증 경로를 찾는 동안 다른 에이전트가 관련 테스트와 오류 로그를 조사할 수 있다. 두 결과를 파일 경로와 근거 줄로 받으면 사람이 계획을 만들 때 합칠 수 있다.
병렬 구현에는 더 엄격한 조건을 적용한다.
- 각 작업이 서로 다른 파일군을 수정한다.
- 공통 타입과 인터페이스를 먼저 확정했다.
- 어느 작업부터 합쳐도 검사 결과가 같아야 한다.
- 작업마다 독립된 테스트가 있다.
- 각 세션이 별도 worktree나 브랜치를 사용한다.
Git worktree는 파일 충돌을 줄인다. 두 구현이 같은 데이터 개념을 다른 이름으로 만들면 Git은 그 논리 충돌을 알려 주지 않는다. 공통 스키마와 함수 시그니처를 먼저 합치고, 이후 작업이 그 계약을 사용하게 해야 한다.
작업 경계가 흔들리면 병렬 실행을 멈춘다. 한 에이전트가 공통 인터페이스를 수정해야 한다고 보고하면 다른 구현을 계속 돌리지 않는다. 변경 이유를 검토하고 작업 패킷을 갱신한 뒤 다시 시작한다. 오래 실행한 세션을 아깝게 여기면 충돌한 코드를 더 많이 만든다.
세션마다 파일 소유권을 적는다
동시에 작업할 때는 계획에 파일 소유권을 넣는다.
세션 A
수정 허용: lib/auth/**, tests/auth/**
읽기 전용: app/**
세션 B
수정 허용: app/login/**, tests/ui/**
읽기 전용: lib/auth/**
소유권은 에이전트가 계획을 벗어났는지 diff에서 판정하는 기준이다. 보안 권한은 별도 통제로 강제한다. 공통 파일 수정이 필요하면 세션이 변경을 멈추고 이유를 보고하게 한다.
기존 사용자 변경도 별도로 표시한다. dirty worktree에서 두 에이전트를 실행하면 어느 세션이 파일을 만들었는지 알기 어렵다. 시작 시 git status를 기록하고 작업별 worktree를 만든다. 합칠 때는 커밋 수보다 diff와 검사 결과를 본다.
검토자는 판정 질문을 받는다
검토 모델을 추가해도 잘못된 전제를 공유하면 두 결과가 함께 틀린다. 검토 프롬프트에는 만족도 질문을 넣지 않는다. 요구사항과 손실 가능성을 확인할 질문을 준다.
- 완료 조건마다 대응하는 코드와 검사 확인
- 사용자 데이터나 기존 상태를 잃는 경로 확인
- 승인하지 않은 외부 쓰기와 권한 확대 확인
- 테스트와 요구사항의 대응 관계 확인
- 오류 처리에서 원래 예외를 숨기는 경로 확인
- 변경하지 않기로 한 파일의 diff 포함 여부 확인
검토자는 발견 사항마다 파일과 줄, 재현 조건, 영향 범위를 적는다. “구조가 복잡하다”는 평가는 수정으로 연결하기 어렵다. “세션 만료 분기에서 작성 중인 입력을 초기화한다”처럼 사용자가 겪을 행동을 설명해야 한다.
두 모델의 의견이 다르면 실행 가능한 증거를 찾는다. 테스트를 추가하거나 작은 재현 코드를 만든다. 라이브러리 동작에 대한 의견 차이는 공식 문서를 확인한다. 모델 A의 설명을 모델 B의 자신감으로 승인하지 않는다.
합치는 순서와 중단 조건을 정한다
나는 공통 계약, 서버 로직, UI 순서로 합치는 경우가 많다. 프로젝트에 따라 순서는 바뀌지만 앞 단계의 검사 결과를 다음 단계의 기준점으로 남긴다.
git diff --check
npm run typecheck
npm test
npm run build
한 단계에서 검사가 실패하면 다음 브랜치를 합치지 않는다. 두 작업의 실패가 섞이면 원인을 찾는 시간이 늘어난다. 외부 API나 데이터베이스를 바꾸는 작업은 로컬 코드 합치기와 분리하고 사람의 승인을 받는다.
다음 조건에서는 두 번째 에이전트를 끈다.
- 수정할 파일이 한두 개이고 테스트가 짧다.
- 작업 패킷을 전달하는 시간이 구현 시간보다 길다.
- 민감한 데이터 접근을 여러 세션에 열어야 한다.
- 공통 스키마가 작업 중 계속 바뀐다.
- 결과를 비교할 판정 기준이 없다.
작은 버그는 한 에이전트가 원인 확인부터 검사까지 맡고 사람이 diff를 읽는 편이 낫다. 여러 세션을 운영하는 일도 조정 비용을 가진다.
Claude와 Codex를 함께 쓰면 설계자의 가정을 구현 과정에서 분리하고, 구현자의 설명을 검토 과정에서 분리할 수 있다. 나는 독립된 질문과 파일 경계가 있을 때만 병렬 실행한다. 작업 패킷과 검사 결과가 두 세션을 연결하며, 모델 선택은 그 뒤에 결정한다.