클로드가 만들고 코덱스가 검수했더니 출시는 더 늦어졌다

기능 하나가 명세 5개와 RED 판정 4개를 거쳤다

Flutter 앱을 혼자 만들던 한 개발자는 Claude Code에 명세와 구현을 맡기고 Codex를 검수자로 붙였다. Claude Code가 기능을 만들면 Codex가 명세와 코드를 읽고 GREEN·YELLOW·RED 가운데 하나를 판정했다. RED가 나오면 Claude Code가 수정하고 Codex가 다시 전체를 검수했다.

두 모델을 교차시키면 혼자 개발할 때 놓친 오류를 줄일 수 있을 것 같았다. 실제로 Codex는 문제를 찾았다. 그런데 어려운 기능 하나가 하루 동안 명세 5개와 RED 판정 4개를 거쳤는데도 출시되지 못했다.

발견된 내용이 모두 사소했던 것도 아니다. Claude Code가 실제 파일을 열지 않고 코드 동작을 설명한 부분도 있었다. 다만 앱을 깨뜨리는 오류, 문단과 표의 모순, 드문 예외 상황, 더 엄격하게 쓸 수 있는 문장이 모두 RED가 됐다. 하나를 고치고 전체를 다시 검사할 때마다 다른 문제가 나타났다.

Codex는 검수 요청대로 문제를 계속 찾았다. 문제는 어떤 발견이 출시를 막는지, 무엇을 확인하면 검수가 끝나는지 정하지 않은 데 있었다.

5~15회의 재검수와 18시간 동안 결과 파일 0개

비슷한 경험은 한 번으로 끝나지 않았다. WordPress SEO 작업을 Claude Code와 Codex로 처리한 다른 사용자는 보통 5~10회, 많게는 14~15회의 검수와 수정을 반복했다고 밝혔다. 구현보다 두 AI 사이에서 검수 결과를 옮기고 다시 확인하는 데 시간이 더 들었다.

네 종류의 Claude 에이전트에 제품 전체를 처음부터 검사하게 한 사용자는 11회를 반복했다. 이전 검사에서 사라졌던 critical 문제가 뒤 검사에서 다시 등장하기도 했다. 매번 새 문맥의 검수자가 전체 범위를 다시 열었기 때문에 결함 목록과 판정 기준이 안정되지 않았다.

더 큰 실패도 있었다. 한 개발자는 Codex를 조정자로 두고 Claude 작성 세션과 검수 세션을 반복시켰다. 본인이 공개한 기록에 따르면 18시간 동안 39개 커밋이 생겼지만 목표였던 엔진 파일은 하나도 만들어지지 않았다. 문서는 다섯 차례의 반려를 거치며 22,929바이트에서 176,520바이트로 7.7배 커졌다.

커밋 수와 문서 길이는 계속 늘었다. 그러나 필요한 파일은 0개였다. 검수 횟수와 수정량을 진행률로 사용하자 바쁘게 움직이는 과정이 결과물의 부재를 가렸다.

교차검수의 가치는 의심을 실행 가능한 검사로 바꾸는 데 있다

Claude Code가 만든 코드를 새 문맥의 Codex에 보여주는 방식은 분명한 장점이 있다. 구현 과정의 설명을 공유하지 않은 검수자는 현재 저장소와 명세만 비교한다. 구현자가 이미 옳다고 믿는 설계에 끌려가지 않고 미완성 구현, 빠진 예외, 명세와 코드의 불일치를 새로 찾을 수 있다.

실제 프로젝트 여섯 개를 공개한 Claude Code·Codex 비교에서는 자동 테스트와 빌드만 돌리지 않았다. 브라우저에서 버튼을 눌렀고, 서버를 강제로 종료한 뒤 복구 상태를 봤으며, 같은 사용자에게 요청 2,000개를 동시에 보내고, 정규식 결과를 Python과 비교했다.

• IndexedDB에는 새 제안서가 저장됐지만 편집기가 열리지 않았다.
• 동시 쓰기 뒤 메모리의 점수와 WAL을 재생한 점수가 달랐다.
• 잘못된 상품 값을 넣으면 문서와 수수료 규칙을 우회할 수 있었다.
• 100개 정규식 테스트를 통과한 구현도 a|aa의 기본 처리에서 Python과 다른 결과를 냈다.

교차검수의 가치는 두 AI가 서로 동의하는 데 있지 않다. 의심을 실제 파일, 재현 입력, 명령과 관찰 결과로 바꾸는 데 있다.

RED는 의견이 아니라 깨진 출시 조건이어야 한다

검수를 시작하기 전에 기능이 출시되려면 반드시 참이어야 하는 조건부터 정해야 한다. 이번 변경과 관계없는 조건까지 모두 붙이면 다시 무한 검수가 된다.

RED는 이 조건 가운데 하나가 깨졌거나 입증되지 않았다는 판정이다. “더 깔끔하게 만들 수 있다”, “다른 추상화가 나을 수 있다”, “문장이 더 엄밀할 수 있다”는 의견만으로 RED를 반환해서는 안 된다.

Google의 코드 리뷰 지침도 완벽함을 승인 조건으로 두지 않는다. 변경이 코드베이스 전체를 분명히 개선하면 작은 다듬을 거리가 남아 있어도 승인을 선호하고, 선택 사항인 의견에는 Nit처럼 의무가 아니라는 표시를 붙인다. GitHub의 코드 품질 게이트도 관리자가 정한 심각도 이상인 발견만 병합을 막는다.

위험 등급은 문제 이름이 아니라 발생 가능성과 영향으로 정한다

보안, 데이터, 성능이라는 단어가 붙었다고 모두 RED가 되는 것은 아니다. 실제 제품에서 해당 경로가 실행되는지, 일반적인 입력인지 드문 예외인지, 실패가 복구 가능한지, 다른 사용자의 데이터까지 영향을 받는지를 확인해야 한다.

문서의 모순도 실제 요구사항을 바꾸거나 테스트 기준을 흔들 때는 RED가 될 수 있다. 반대로 표현만 다듬으면 되는 모순은 NOTE다. 등급은 문제의 종류가 아니라 제품에 미치는 결과로 정한다.

실제 파일과 테스트가 없는 RED는 다시 확인해야 한다

OpenAI의 Codex 코드 리뷰 안내는 변경 파일과 diff를 직접 보고, 테스트 결과와 검사 상태를 확인하며, 생성된 발견을 관련 코드와 대조한 뒤 사용하라고 설명한다. Anthropic의 프롬프트 지침도 열지 않은 파일에 관해 추측하지 말고 먼저 관련 파일을 읽도록 요구한다.

Finding ID:
Severity: RED | YELLOW | NOTE
Release-blocking claim:
File and line:
Current code or diff:
Reproduction input:
Command or test:
Expected result:
Observed result:
Affected scope:
Confidence:
Fix now or defer:

“동시 요청에서 데이터가 깨질 수 있다”는 말만으로는 RED가 아니다. 관련 파일과 줄, 동시에 보낼 요청, 실행 명령, 예상 상태와 실제 상태가 있어야 한다. 공개 비교 저장소의 WAL 오류는 같은 사용자에게 2,000개 요청을 보낸 뒤 재시작 전 점수 1996과 WAL 재생 후 점수 2000이 달라지는 방식으로 입증됐다.

수정 뒤 제품 전체를 처음부터 다시 검사하지 않는다

RED 하나를 고친 뒤 제품 전체를 새 문맥에서 다시 감사하면 검수 범위가 매번 원점으로 돌아간다. 수정한 파일과 영향을 받은 출시 조건, 인접한 회귀 가능성부터 다시 확인해야 한다.

인증 미들웨어를 바꿨다면 로그인 성공, 권한 거부, 토큰 만료와 관련 회귀를 다시 검사한다. 버튼 문구를 바꿨다면 데이터베이스 복구와 결제 동시성까지 다시 열 이유가 없다. 수정 범위가 넓어졌거나 공통 기반 코드가 바뀐 경우에만 전체 검사를 다시 실행한다.

두 번의 검수는 출시 명령이 아니라 사람에게 넘기는 기준이다

검수 횟수를 두 번이나 세 번으로 제한하면 비용 폭주는 막을 수 있다. 그러나 두 번 돌았다는 이유만으로 인증 우회나 데이터 손실을 남긴 채 출시할 수는 없다.

고정 횟수는 출시 조건이 아니라 확대 판단의 조건이다. 두 차례 수정 뒤에도 같은 RED가 남거나 두 AI의 판정이 갈리면 반복을 멈추고 사람이 세 가지 가운데 하나를 결정한다.

1. 출시를 막고 직접 원인을 해결한다.
2. 기능 범위를 줄여 RED가 걸린 경로를 제외한다.
3. 위험을 재현할 별도 실험과 테스트를 만든다.

YELLOW와 NOTE는 사라질 때까지 돌리지 않는다. 이슈 원장에 발견, 담당자, 처리 시점을 남기고 출시 판단에서 분리한다.

GREEN의 뜻을 먼저 쓰면 검수는 끝난다

1. 이번 기능의 출시 차단 조건을 유한하게 적었다.
2. 각 조건에 파일·테스트·실행 결과 가운데 하나 이상의 증거가 있다.
3. 최신 변경본에서 필수 빌드·타입 검사·테스트·린트가 통과했다.
4. 증거가 있는 RED가 0건이다.
5. YELLOW와 NOTE는 담당자와 처리 시점을 정해 이슈 원장에 남겼다.
6. 마지막 수정으로 영향을 받은 조건만 다시 확인했다.

GREEN은 Codex가 더 이상 문제를 찾지 못했다는 뜻이 아니다. 출시를 막기로 정한 조건이 모두 충분한 증거를 가졌고, 그 증거를 뒤집는 미해결 문제가 없다는 뜻이다.

Claude Code와 Codex를 함께 쓰면 한 모델이 놓친 문제를 다른 모델이 찾을 수 있다. 그러나 검수자가 출시 여부까지 결정하면 제품은 계속 고쳐지기만 하고 나가지 않는다. 구현은 AI가 해도 RED의 기준과 GREEN의 뜻은 사람이 먼저 정해야 한다.

자주 묻는 질문