Claude Code와 Codex 역할분리 2026 – 구현 AI와 검수 AI를 나누는 리뷰 체크리스트

Posted on by

AI가 만든 코드를 같은 흐름에서 바로 검수하면 빠르지만, 리뷰 책임이 흐려질 수 있다. Claude Code와 Codex를 같이 쓸 때 핵심은 모델 이름 싸움이 아니라 역할 분리다.

한쪽은 구현 루프를 잡고, 다른 쪽은 diff와 테스트 증거를 따로 보는 식으로 나누면 자기검증 편향을 조금 줄일 수 있다. 물론 AI 두 개를 붙였다고 코드가 자동으로 안전해지는 건 아니다.

그건 운동화 두 켤레 신었다고 100m 기록이 두 배 빨라지는 것과 비슷하다. 중요한 건 누가 만들고, 누가 의심하고, 사람이 어디서 최종 판단을 멈춰 세우는지다.

이 글은 2026년 5월 14일 이 볼트에서 글감 수집, 후보 선별, 블로그 파이프라인 검수 흐름을 나눠 돌리며 정리한 운영형 체크리스트다. OpenAI Codex 문서는 Codex가 로컬 프로젝트에서 파일을 읽고 명령을 실행하고 변경을 만들 수 있으며, 클라우드에서는 작업을 실행하고 결과 diff를 검토해 PR로 이어갈 수 있다고 설명한다.

Claude Code 문서는 Claude가 터미널에서 context 수집, action, verification을 반복하는 agentic loop로 일한다고 설명한다. 둘 다 강하다.

그래서 더더욱 같은 역할을 두 번 시키기보다 다른 책임을 맡기는 편이 낫다.

지금 판단

가장 단순한 기본값은 이렇다. Claude Code는 구현 담당, Codex는 검수 담당으로 둔다.

Claude Code가 로컬 repo에서 파일을 고치고 테스트를 돌리며 구현 루프를 이어간다면, Codex는 변경 범위, 실패 가능성, 테스트 증거, 보안 권한, 누락된 문서를 따로 본다. 이 방식이 좋은 이유는 똑똑한 AI를 하나 더 붙여서가 아니다.

생성한 주체와 의심하는 주체를 분리하기 때문이다. 사람 리뷰어가 PR에서 하는 일도 비슷하다.

작성자는 “내 의도는 이거였어”에 가까워지고, 리뷰어는 “그 의도가 코드와 테스트에 남았나”를 본다. AI끼리도 이 역할 차이를 만들어야 한다.

단계 구현 AI가 할 일 검수 AI가 볼 일 사람이 멈춰야 할 지점
문제 파악 실패 로그와 파일을 읽고 수정 후보를 좁힘 문제 정의가 과하게 넓지 않은지 확인 요구사항이 애매하면 재정의
구현 최소 변경으로 코드와 테스트 수정 unrelated 파일, 새 의존성, 과한 리팩터링 확인 범위 밖 개선은 보류
검증 테스트, lint, build 실행 실행 결과가 실제로 남았는지 확인 실패를 숨긴 요약이면 중단
리뷰 수정 이유와 남은 위험 요약 diff 단위로 버그와 누락 테스트 찾기 보안·데이터·배포 권한은 사람 승인
후속 문서와 체크리스트 업데이트 다음 작업으로 넘길 blocker 분리 “대충 됨”이면 머리 식히기

이 표에서 제일 중요한 칸은 마지막이다. 검수 AI가 PASS라고 말해도 최종 책임자는 사람이다.

AI 검수는 리뷰어를 없애는 기능이 아니라, 사람이 볼 위험 목록을 더 빨리 정리하는 기능에 가깝다.

왜 같은 AI에게 구현과 검수를 다 맡기면 약해지나

한 세션에서 구현과 검수를 모두 시키면 문맥이 편하다. 이미 어떤 파일을 고쳤는지 알고 있고, 왜 그렇게 고쳤는지도 알고 있다.

문제는 그 편함이 의심을 약하게 만들 수 있다는 점이다. 에이전트가 방금 만든 해결책을 다시 읽으면 “내가 왜 이렇게 했는지” 설명이 머릿속에 남아 있다.

그러면 실제 코드가 증명한 것보다 의도 설명을 더 믿게 되는 흐름이 생긴다. 사람도 그렇다.

내가 쓴 글을 내가 바로 교정하면 오타가 투명 망토를 입는다. 코드도 비슷하다.

그래서 역할분리의 첫 번째 목적은 모델 성능 향상이 아니라 시선 분리다. 검수 AI에게는 구현 의도를 길게 먹이기보다 결과물과 기준을 먹이는 편이 좋다.

예를 들면 “이 diff가 사용자 요청을 만족하는지 봐줘”보다 “요청, 변경 파일, 테스트 결과, 금지 범위를 기준으로 P0/P1 버그만 찾아줘”가 더 낫다. 검수 조건이 좁을수록 잡음이 줄어든다.

Claude Code에 맡기기 좋은 일

Claude Code는 터미널 안에서 이어지는 구현 루프와 잘 맞는다. 공식 문서가 설명하는 agentic loop도 context 수집, action, verification이 섞여 돌아가는 흐름이다.

실무적으로는 파일을 읽고, 고치고, 명령을 돌리고, 실패를 보고 다시 고치는 일에 자연스럽다. 내가 맡긴다면 아래 작업을 Claude Code 쪽에 둔다.

작업 이유 필요한 제한
테스트 실패 수정 실패 재현과 반복 수정이 필요함 테스트 범위와 최대 수정 파일 지정
작은 기능 구현 repo 규칙을 읽고 바로 반영 가능 public API와 디자인 범위 고정
리팩터링 파일 이동과 call site 수정이 이어짐 새 기능 추가 금지
문서 동기화 코드와 문서 차이를 바로 확인 가능 추측 문서화 금지
로컬 검증 명령 실행 결과를 바로 반영 가능 실행한 명령과 exit 결과 기록

이때 구현 프롬프트에는 “잘 만들어줘”보다 “무엇을 바꾸고 무엇을 바꾸지 말라”가 더 중요하다. 예를 들어 새 의존성 금지, 특정 디렉터리 밖 수정 금지, 테스트 실패 3회 반복 시 중단 같은 제약이 있어야 한다.

구현 AI는 생각보다 성실하다. 성실함은 좋지만, 범위가 흐리면 성실하게 멀리 간다.

멀리 간 diff는 리뷰어의 오후를 통째로 데려간다.

Codex에 맡기기 좋은 검수

Codex는 별도 작업자로 두었을 때 가치가 살아난다. OpenAI Codex quickstart는 Codex가 Agent mode에서 프로젝트 파일을 읽고 명령을 실행하고 변경을 만들 수 있다고 설명한다.

클라우드 흐름에서는 작업이 끝난 뒤 diff view에서 변경을 검토하고 PR로 이어갈 수 있다고 안내한다. 이 포지션을 검수에 쓰면 구현 세션과 다른 창에서 다시 보는 효과가 생긴다.

검수 프롬프트는 넓게 주면 안 된다. 넓게 주면 Codex도 친절하게 리팩터링 아이디어, 스타일 제안, 문서 개선까지 잔뜩 가져온다.

지금 필요한 건 멋진 회의가 아니라 깨지는 지점이다. 검수 요청은 이렇게 쓰는 편이 좋다.

다음 변경을 코드 리뷰 관점으로 봐줘. 목표는 새 아이디어 제안이 아니라 P0/P1 버그, 보안 위험, 누락 테스트, 요청 범위 밖 변경 찾기야. 결과는 severity, 파일/라인, 재현 가능성, 필요한 수정으로만 정리해줘. 스타일 취향과 큰 리팩터링 제안은 제외해줘.

이 프롬프트의 포인트는 “제외”다. 검수 AI가 너무 많은 것을 잘하면 결과가 길어진다.

결과가 길어지면 사람은 중요한 버그와 취향 코멘트를 같은 무게로 읽게 된다. 리뷰에서 제일 위험한 건 틀린 지적이 아니라 중요한 지적이 묻히는 것이다.

/review와 /rescue로 나누는 실전 패턴

역할분리는 명령 이름을 붙이면 더 오래 간다. 나는 두 가지 별칭을 추천한다.

/review는 정상 흐름의 검수다. 테스트가 통과했고 구현자가 “끝났다”고 말한 뒤, Codex가 diff를 차갑게 다시 본다.

이때는 버그, 누락 테스트, 권한 변경, 사용자 요구사항 누락만 본다. /rescue는 구현 세션이 꼬였을 때 쓰는 구조 요청이다.

테스트가 계속 실패하거나, diff가 커졌거나, 원인이 흐려졌을 때 Codex에게 “지금 상태를 구조화하고 다음 3단계만 제안해줘”라고 맡긴다. 구현을 이어가는 게 아니라 정지선을 만드는 역할이다.

별칭 쓰는 순간 Codex 출력
/review 구현 완료 직전 P0/P1 리스크, 누락 테스트, 요청 불일치
/rescue 구현 루프가 꼬일 때 현재 상태, 실패 원인 후보, 되돌리지 않는 다음 단계
/scope-check diff가 커질 때 요청 범위 밖 변경과 보류할 개선
/security-check 권한·키·DB·배포가 닿을 때 민감 작업, 승인 필요 지점, 로그 증거

이 네 가지를 분리하면 AI가 서로 싸우지 않는다. 구현 AI는 계속 고치고 싶어 하고, 검수 AI는 계속 의심하고 싶어 한다.

그 둘 사이에서 사람은 “이번 라운드의 목적”을 정한다. 목적을 안 정하면 도구들이 각자 똑똑한 방향으로 흩어진다.

권한 분리와 로그가 없으면 반쪽이다

역할분리를 말할 때 도구 이름만 나누면 부족하다. 권한도 나눠야 한다.

구현 담당은 파일 수정과 테스트 실행 권한이 필요할 수 있다. 검수 담당은 처음에는 읽기 전용으로도 충분하다.

보안, 결제, 배포, 고객 데이터가 닿는 작업에서는 검수 AI에게도 쓰기 권한을 바로 주지 않는 편이 낫다. Claude Code 공식 문서의 subagents 설명도 작업별로 별도 컨텍스트와 도구 제한을 둘 수 있다는 방향을 보여준다.

OpenAI Codex의 skill 구조도 반복 워크플로우를 instructions, scripts, references로 묶어 관리할 수 있다고 설명한다. 이 두 흐름을 합치면 답은 단순하다.

역할을 나누려면 프롬프트만 나누지 말고, 권한과 증거도 나눠야 한다.

항목 구현 담당 검수 담당
파일 쓰기 허용 가능 기본은 읽기 중심
명령 실행 테스트·빌드 중심 필요한 경우 재현 명령만
외부 서비스 최소 권한 보통 차단
산출물 diff, 테스트 로그, 남은 blocker 리뷰 findings, 누락 테스트, 승인 필요 지점
실패 시 작은 수정 반복 구조화 후 중단선 제안

로그도 중요하다. 테스트를 돌렸다고 말하는 것과 테스트 결과가 대화나 CI 로그에 남는 것은 다르다.

검수 AI는 “통과했다”는 문장보다 어떤 명령이 어떤 결과로 끝났는지를 봐야 한다. 이걸 남기지 않으면 리뷰가 감상문이 된다.

감상문은 국어 시간에는 좋지만 배포 전에는 심장이 조금 얇아진다.

팀에서 바로 쓰는 리뷰 체크리스트

팀에 붙일 때는 거창한 에이전트 조직도보다 체크리스트가 먼저다. 아래 표를 PR 템플릿이나 작업 완료 메모에 붙이면 역할분리가 훨씬 덜 추상적이다.

체크 질문 PASS 기준
요청 일치 사용자가 원한 문제를 풀었나 원래 요청과 diff가 같은 방향
범위 제한 unrelated 변경이 섞였나 새 기능, 스타일 정리, 파일 이동이 이유 없이 없음
테스트 증거 어떤 명령을 실행했나 명령명과 결과가 남아 있음
실패 처리 실패한 테스트를 숨기지 않았나 남은 실패와 blocker가 별도 기록
보안 권한 키, 토큰, DB, 배포 권한을 건드렸나 민감 변경은 사람 승인 대기
롤백 가능성 되돌릴 수 있나 변경 단위가 작고 파일 범위가 설명 가능
문서 동기화 사용법이나 설정이 바뀌었나 필요한 문서만 같이 갱신

이 표의 목표는 모든 코멘트를 늘리는 게 아니다. 오히려 리뷰 코멘트를 줄이는 것이다.

P0/P1 리스크와 누락 테스트만 먼저 잡으면, 스타일 취향은 다음 라운드로 미룰 수 있다. AI 리뷰가 시끄러워지면 팀은 금방 꺼버린다.

조용하지만 중요한 리뷰가 오래 간다.

언제 역할분리가 과한가

모든 작업에 구현 AI와 검수 AI를 따로 둘 필요는 없다. 오타 수정, 작은 문서 링크 수정, 명확한 타입 에러 하나 고치기처럼 위험이 낮은 작업은 한 세션에서 끝내도 된다.

역할분리는 비용이 있다. 컨텍스트를 다시 설명해야 하고, 리뷰 결과를 사람이 다시 판단해야 하며, 때로는 두 AI가 서로 다른 말을 한다.

그래서 기준을 세우는 편이 좋다. 아래 중 하나라도 해당하면 분리 검수를 켠다.

분리 검수 신호 이유
결제, 인증, 권한, 개인정보가 닿음 실패 비용이 큼
diff가 300줄을 넘음 사람이 놓칠 가능성이 커짐
테스트가 없거나 약함 AI가 성공을 과신하기 쉬움
마이그레이션 또는 파일 이동 포함 call site 누락 위험
배포 직전 hotfix 빠른 판단일수록 별도 시선 필요
구현 중 실패가 2회 이상 반복 원인 구조화가 필요

반대로 작은 변경에 매번 별도 검수를 붙이면 속도가 죽는다. 좋은 운영은 모든 문에 자물쇠를 다는 게 아니라, 중요한 문에 제대로 단단한 자물쇠를 다는 것이다.

AI 워크플로우도 똑같다.

오늘 바로 적용하는 20분 루틴

첫 5분은 작업을 둘로 나눈다. 구현 담당에게 줄 목표와 검수 담당에게 줄 기준을 따로 쓴다.

같은 문장을 복붙하지 않는 게 포인트다. 구현 프롬프트에는 목표, 변경 가능 범위, 테스트 명령을 넣는다.

검수 프롬프트에는 요청, diff 요약, 금지 범위, 찾을 위험만 넣는다. 다음 10분은 구현을 시킨다.

구현 AI가 테스트를 돌렸다면 명령과 결과를 남기게 한다. 실패하면 억지로 “완료”를 만들지 말고 실패 테스트와 blocker를 남기게 한다.

마지막 5분은 Codex 리뷰를 붙인다. 리뷰 결과가 없으면 PASS가 아니라 “발견된 P0/P1 없음”으로 기록한다.

말이 비슷해 보이지만 다르다. PASS는 최종 판단이고, “발견된 것 없음”은 검수 범위 안에서의 관찰이다.

최종 판단은 사람이 한다. 여기서 사람의 역할이 사라지지 않는다.

오히려 더 선명해진다. AI가 손을 빠르게 움직이면, 사람은 기준과 중단선을 더 잘 잡아야 한다.

FAQ

Claude Code와 Codex를 꼭 같이 써야 하나요?

꼭 그럴 필요는 없습니다. 작은 수정이나 명확한 버그는 한 도구로 끝내도 됩니다. 다만 인증, 배포, 큰 리팩터링, 테스트가 약한 변경처럼 실패 비용이 큰 작업은 구현과 검수 시선을 나누는 편이 안전합니다.

구현은 Claude Code, 검수는 Codex가 항상 정답인가요?

항상은 아닙니다. 이 글의 기본값은 도구별 우열이 아니라 역할 분리입니다. 팀의 습관에 따라 Codex가 구현하고 Claude Code가 검수할 수도 있지만, 생성 주체와 검수 주체를 분리한다는 원칙은 유지하는 게 좋습니다.

AI 리뷰 결과를 그대로 고치면 되나요?

아닙니다. AI 리뷰는 후보 목록입니다. severity, 재현 가능성, 사용자 영향, 테스트 증거를 사람이 다시 보고 반영 여부를 결정해야 합니다. 특히 보안과 데이터 변경은 AI가 PASS라고 해도 사람 승인 게이트를 남겨야 합니다.

검수 AI에게 어떤 자료를 줘야 하나요?

원래 요청, 변경 파일, 핵심 diff, 실행한 테스트 명령과 결과, 변경 금지 범위를 주는 게 좋습니다. 구현 과정의 긴 대화보다 결과와 기준을 주는 편이 리뷰 잡음이 줄어듭니다.

두 AI가 서로 다른 말을 하면 어떻게 하나요?

먼저 재현 가능한 증거가 있는 쪽을 봅니다. 테스트 실패, 타입 에러, 보안 권한 변경처럼 확인 가능한 지적은 우선합니다. 취향이나 구조 선호가 갈리는 부분은 이번 작업 범위 밖이면 보류하는 편이 낫습니다.

언제 /rescue 패턴을 쓰면 좋나요?

테스트 실패가 반복되거나, diff가 너무 커졌거나, 원래 목표가 흐려졌을 때 씁니다. /rescue의 목적은 계속 구현하는 게 아니라 현재 상태를 멈춰 세우고 다음 1-3단계를 좁히는 것입니다.

공식 출처

관련 글