같은 저장소를 Claude Code와 Codex에 동시에 열어 "각자 고쳐 달라"고 하면 두 답을 비교할 수 있을 것 같지만 실제로는 파일이 섞입니다. 한쪽 테스트가 다른 쪽 변경을 읽고, 먼저 저장한 결과가 뒤의 편집에 덮일 수 있습니다. 두 도구를 함께 쓰는 장점은 작업자를 두 배로 만드는 데 있지 않습니다. 구현 가정과 검토 가정을 분리하는 데 있습니다.
핵심 한 에이전트만 승인된 작업공간에서 구현하고 다른 에이전트는 고정된 `diff`를 읽기 전용으로 검토하게 합니다. 사람은 두 보고서의 근거를 원본 코드와 테스트로 확인한 뒤 수정과 배포를 결정합니다.
먼저 둘째 도구가 필요한 작업인지 판단합니다
오탈자나 단순한 한 줄 변경은 기존 테스트와 사람 검토로 충분합니다. 교차검증은 인증, 데이터 변경, 동시성, 배포 설정처럼 한 번의 잘못된 가정이 큰 회귀로 이어질 때 가치가 있습니다. 두 도구의 비용과 검토 시간보다 실패 비용이 작은 작업에는 쓰지 않습니다.
리뷰어가 구현자와 다른 모델이라는 사실만으로 독립성이 생기지는 않습니다. 같은 프롬프트와 같은 설명만 주면 같은 전제를 따라갈 수 있습니다. 리뷰어는 구현 대화를 받지 않고 요구사항과 실제 `diff`, 재현 명령에서 새로 판단해야 합니다.
작업공간과 역할을 시작 전에 고정합니다
아래 계약은 Claude Code가 구현하고 Codex가 검토하는 예시입니다. 도구 역할을 바꿔도 원칙은 같습니다.
구현 작업공간: work/fix-import-timezone
구현자: Claude Code
허용: src/import/**, tests/import/** 편집과 로컬 테스트
금지: 커밋, 푸시, 운영 DB, 외부 업로드
리뷰 입력: 기준 커밋 SHA, 요구사항, git diff, 테스트 출력
리뷰어: Codex
허용: 읽기, 검색, 승인한 로컬 테스트
금지: 파일 편집, 구현자 대화 열람, 원격 변경
통합 책임: 사람 1명
완료: 지적별 재현 여부와 처리 결과 기록구현자는 작은 diff와 미검증 영역을 함께 냅니다
가상 사례는 CSV의 현지 시각을 UTC로 저장하는 가져오기 오류입니다. 구현자는 실패 테스트를 먼저 만들고 파서와 해당 테스트만 수정합니다. 결과 보고에는 바뀐 파일, 수정 전후 테스트, 시간대가 없는 입력과 일광절약시간 경계처럼 아직 확인하지 못한 경우를 적습니다.
"모든 테스트 통과"만 넘기면 리뷰어가 무엇을 반박해야 할지 알기 어렵습니다. 요구사항별로 어떤 테스트가 증거인지 연결하고, 실행하지 않은 통합·운영 검사를 분리합니다. `diff`는 리뷰 시작 시점의 기준 커밋과 함께 고정합니다.
리뷰어는 설명보다 반례를 찾습니다
리뷰 요청은 "좋아 보이는지" 묻지 않습니다. 요구사항을 깨뜨리는 입력과 코드 경로를 찾고, 재현할 수 없는 지적은 가설로 표시하게 합니다.
이 diff를 읽기 전용으로 리뷰하세요. 파일은 수정하지 마세요.
요구사항: 입력에 명시된 시간대를 존중하고 저장값은 UTC여야 합니다.
각 지적에 포함할 것:
- 심각도와 정확한 파일·줄
- 깨지는 입력 또는 실행 경로
- 재현 테스트나 확인 명령
- 확정 결함인지 추가 확인이 필요한 가설인지
특히 시간대 누락, DST 경계, 재시도 중복, 기존 데이터 호환을 확인하세요.
스타일 취향만 다른 의견은 제외하세요.지적은 표결하지 않고 재현합니다
두 도구가 같은 결론이면 확률은 높아질 수 있지만 사실이 되지는 않습니다. 리뷰 지적마다 현재 코드에서 재현되는지 확인합니다. 테스트를 새로 추가해야 한다면 통합 책임자가 구현 작업공간에서 추가하고, 리뷰 작업공간은 계속 읽기 전용으로 둡니다.
구현자가 리뷰에 반박할 때도 설명만으로 닫지 않습니다. 기존 테스트, 공식 라이브러리 동작이나 최소 재현으로 근거를 남깁니다. 재현할 수 없지만 위험이 큰 항목은 미해결로 표시하고 배포 범위를 줄이거나 추가 검토로 넘깁니다.
다른 도구의 대화 기록을 그대로 넘기지 않습니다
긴 구현 대화에는 실패한 가설과 설득적인 설명이 함께 들어 있습니다. 리뷰어가 이를 먼저 읽으면 실제 `diff`보다 구현자의 서사를 따라가기 쉽습니다. 필요한 것은 최종 요구사항, 기준 상태, `diff`와 검증 출력입니다.
반대로 인계에 필요한 프로젝트 규칙을 빼서는 안 됩니다. 저장소 지침, 지원 버전, 성능·보안 제약은 두 도구가 같은 공식 기준 문서에서 읽게 합니다. 구현 가설은 분리하고 프로젝트 사실은 공유합니다.
마지막 편집과 배포는 한쪽에서만 합니다
리뷰가 끝난 뒤 발견된 수정은 원래 구현 작업공간에 반영합니다. 두 작업공간의 좋은 부분을 파일 복사로 섞지 않습니다. 최종 `diff`, 전체 테스트와 브랜치 상태를 다시 확인한 뒤 사람만 커밋·푸시·배포 여부를 결정합니다.
리뷰 도중 요구사항이 바뀌거나 운영 데이터가 필요해지면 현재 교차검증을 종료합니다. 범위가 달라진 작업은 새 계획과 새 기준 `diff`가 필요합니다. 교차검증은 승인 우회 수단이 아니라 결함을 더 일찍 찾기 위한 절차입니다.
읽고 나서 확인하기
답을 떠올린 뒤 본문의 판단 기준과 비교해 보세요.
- 구현자와 리뷰어는 같은 파일을 동시에 편집하지 않고 고정된 `diff`를 사이에 둡니다.
- 리뷰어에게 구현 대화 대신 요구사항·기준 커밋·`diff`·테스트 결과를 제공합니다.
- 두 도구가 동의해도 지적을 재현한 뒤 한 작업공간에서만 최종 수정합니다.
공식 출처
목록 검증 기준
확인일:
선정 기준: 서로 다른 코딩 에이전트를 동시에 사용할 때 파일 충돌 없이 독립 리뷰 증거를 남길 수 있는지 기준으로 구성했습니다.
추천 중단 기준: 리뷰 중 요구사항이 바뀌거나 운영 접근·배포가 필요해지면 기존 승인으로 이어 가지 않고 새 작업으로 분리합니다.