클로드 코드가 짜고 코덱스가 리뷰하면 — AI 2중 코드 리뷰로 잡은 결함 25건 실험기

클로드 코드(Claude Code)가 코드를 짜고, 코덱스(Codex)가 그 코드를 리뷰하게 했다. 이 블로그의 기능 작업 7개(10월 1~3일)를 이 방식으로 돌렸더니, 리뷰가 중복을 뺀 지적 25건을 냈다. 이 중 19건은 실제로 고쳐야 하는 코드 결함이었고, 3건은 '배포하면 안 되는' 등급(BLOCKER)이었다. 리다이렉트를 따라가다 서버 내부 주소로 요청이 나갈 수 있는 보안 문제도 그중 하나다.

여기서 '2중 리뷰'는 만든 AI와 검사하는 AI를 서로 다른 모델로 두는 구조를 말한다. 사람 개발팀에서 작성자와 리뷰어를 나누는 것과 같은 이유다. 자기 코드는 자기 눈에 잘 안 보인다.

파이프라인은 이렇게 생겼다

작업 하나는 명세 파일 한 장에서 시작한다. 목표, 수정해도 되는 경로, 요구사항, 완료 기준, 그리고 실행할 빌드·테스트 명령이 들어 있다. 그다음은 스크립트가 순서대로 돌린다.

1. 작업마다 별도 git 작업 공간(worktree)을 만든다.
2. 클로드 코드가 명세대로 구현한다.
3. 명세에 적힌 빌드·테스트를 Docker 안에서 실행한다.
4. 코덱스가 변경분 전체를 읽고 지적을 낸다. 지적에는 BLOCKER·MAJOR·MINOR·SUGGESTION 등급이 붙는다.
5. BLOCKER·MAJOR와 보안·명세 불일치 지적은 자동으로 수정 라운드에 넘긴다(기본 2회). 나머지는 기록만 한다.
6. 수정 라운드를 다 써도 남거나, 운영·비용·DB 변경처럼 사람이 정할 일이 나오면 멈추고 질문한다.
7. 통과하면 커밋, PR, 머지까지 진행한다. 운영 배포는 따로 승인받는다.

사람이 하는 일은 명세를 쓰고, 멈췄을 때 결정하는 것뿐이다.

숫자로 본 결과

작업	리뷰 횟수	지적(중복 제외)	대표 사례
정부지원 카테고리	2	MAJOR 2, MINOR 1	시각이 적힌 자정 마감을 하루 늦게 처리
정부24 수집기	3	BLOCKER 1, MAJOR 2	페이지를 넘겨도 첫 페이지만 반복 요청
행사 전 출처 재점검	7	BLOCKER 2, MAJOR 10	리다이렉트로 내부 주소 요청 가능(SSRF)
소개·편집 원칙 페이지	2	MAJOR 1, MINOR 1	소개 글 분량이 명세 기준 미달
데스크톱 레이아웃	3	MAJOR 2, MINOR 1	코드 블록 닫는 표식을 잘못 인식해 목차 앵커가 밀림
관리자 검색량 패널	1	MAJOR 2	진단 명령이 API 키 값을 출력할 수 있음
테크 수집기 수정	1	없음	—

가장 오래 걸린 건 '행사 전 출처 재점검' 작업이었다. 리뷰 7번, 수정 8번을 돌았다. 지적을 고치면 그 고친 코드에서 다음 문제가 나오는 식이었다. 순서는 이랬다.

• 처음 받은 페이지의 기준값이 저장되지 않는 문제
• 같은 날 다시 확인하면 해결 처리가 안 되는 문제
• 재점검이 n8n 호출 제한 시간(15초)을 넘는 문제
• 리다이렉트를 따라 내부 주소로 요청이 나가는 문제(SSRF)
• DNS 조회에 시간 제한이 없는 문제

마지막 두 개는 사람이 따로 리뷰했다면 놓치기 쉬운 종류라고 본다. 기능이 '정상 동작'하는 데는 아무 문제가 없기 때문이다.

그대로 믿으면 안 되는 지점

좋은 점만 있지는 않았다. 25건 중 6건은 코드 결함이 아니었다. 명세와 표현이 다르다는 지적, 문서에 한 줄이 빠졌다는 지적, 작업 공간 도구가 자동으로 만든 설정 파일을 "범위 밖 파일"로 잡은 지적 등이다. 그대로 자동 수정에 넘기면 쓸데없는 수정 라운드만 늘어난다. 이런 건 사람이 "수용, 사유는 이렇다"로 끊어 줘야 했다.

리뷰가 수렴하지 않는 경우도 있다. 위의 재점검 작업처럼 라운드마다 새 지적이 나오면, 어느 시점에 사람이 설계 방향을 정해 줘야 끝난다. 이번에는 "응답부터 보내고 재점검은 뒤에서 돌린다", "확인일은 날짜가 아니라 시각으로 저장한다" 같은 지시를 메모로 넘기고 나서야 정리됐다.

리뷰어 쪽이 아예 못 도는 날도 있었다. 작업 공간 도구가 만든 프로젝트 설정이 리뷰 도구의 전역 설정과 충돌해, 코덱스가 시작조차 못 했다. 원인은 금방 찾았지만, 파이프라인이 두 도구에 기대는 만큼 고장 날 지점도 두 배다.

직접 해 본다면

개인적으로 가장 효과가 컸던 건 리뷰 모델보다 명세의 '하면 안 되는 것' 쪽이었다. 수정 금지 경로, 운영 배포 금지, 새 패키지 금지, 비밀값 출력 금지 같은 것들이다. 이게 있어야 리뷰어가 무엇을 기준으로 봐야 할지 알고, 구현 AI도 범위를 넘지 않는다. 시작한다면 이 순서를 권한다.

1. 작은 작업 하나로 명세 양식부터 만든다. 목표, 수정 범위, 금지 사항, 테스트 명령 네 칸이면 충분하다.
2. 리뷰 등급별 처리 규칙을 정한다. 무엇을 자동으로 고치고, 무엇을 사람에게 물을지.
3. 수정 라운드 상한을 둔다. 수렴하지 않으면 사람이 설계를 정하게 해야 끝이 난다.

AI 두 개를 붙인다고 사람이 빠지지는 않는다. 다만 사람이 하는 일이 "코드를 한 줄씩 읽는 것"에서 "기준을 정하고 갈림길에서 고르는 것"으로 바뀐다.

수치는 이 블로그의 개발 기록(2026년 10월 1~3일, 작업 7개)에서 셌다. 같은 지적이 여러 번 나온 경우는 한 번으로 셌다.