클로드 코드로 만들고 코덱스로 검증하기
AI 교차검증 플레이북

Claude Code로 코드, 문서, 분석을 만들고 있다면 검수는 누가 하고 있나요? 이 글은 Claude Code를 주 작업 도구로 두고 OpenAI의 Codex를 독립 검증자로 붙여 쓴 실제 운영 기록입니다 두 제품의 성능 순위를 매기는 글은 아니에요

19편이 두 도구가 같은 규칙으로 번갈아 일하는 방법이었다면, 이번 편은 한쪽이 만든 결과를 다른 쪽이 검수하는 연결을 다룹니다 범위는 로컬 파일을 읽는 Codex CLI 환경이에요

왜 다른 회사 AI에게 검수를 맡기나

Claude Code 안에도 검수 에이전트를 둘 수 있고, 이 환경도 납품 전 검수 에이전트를 따로 운영해요 그래도 Codex를 하나 더 붙인 이유는 단순합니다 만든 쪽이 짠 시험은 만든 쪽의 가정을 그대로 품기 쉬워서, 다른 도구의 눈으로 한 번 더 보고 싶었어요 다만 효과가 모델 계열의 차이 때문인지, 검수를 한 번 더 했기 때문인지는 따로 재 보지 않았습니다

Codex가 실제로 잡은 결함은 세 종류였어요 기술 용어를 빼고, 업무에서 흔히 겪는 장면에 빗대 보면 이렇습니다

셋 다 Claude 쪽에서 확인을 마쳤다고 보고 다음 단계로 넘긴 뒤에 Codex가 찾은 것이에요 더 직접적인 사례도 있습니다 이 사이트의 용어 설명 14건을 고칠 때 Claude 쪽 검수 에이전트를 두 번 거쳐 조건부 통과를 받았는데, 그 뒤 Codex가 개념 정의의 정밀도를 짚는 메이저 지적 5건을 더 냈어요

실패 사례부터 - 검수자에게 실행 권한이 있던 날

이 구성의 조건 하나는 사고에서 나왔습니다 Codex 검증을 붙이기 일주일 전, 적대적 검수를 Codex가 아니라 Claude 쪽 검수 에이전트에게 맡긴 날이 있었어요 과제는 "파일 쓰기 차단 장치를 통과하는 명령을 찾아라"였고, 예시로 위험한 명령 형태까지 줬습니다

그 뒤로 세 가지를 고정했어요 시험용 명령 문자열은 셸로 실행하지 않는 데이터로만 다루라고 검수 지침에 적었고, heredoc 구분자가 본문과 겹치거나 하위 파일을 한꺼번에 덮어쓰는 셸 명령은 실행 전에 막는 장치를 달았으며, 에이전트에게 일을 넘기기 직전에는 자동으로 복구 지점을 남깁니다 일주일 뒤 Codex 검증 구성을 만들 때 "의뢰서는 파일로만 넘긴다"는 조건이 들어간 이유예요

구성 - Codex를 읽기 전용 검증자로 부르는 4가지 고정 조건

공식 문서도 codex exec의 기본값을 읽기 전용 샌드박스로 안내합니다 이 환경은 기본값에 기대지 않고 옵션으로 명시해 둬요 기본값은 설정 파일 하나로 바뀔 수 있기 때문입니다

기준 문서: OpenAI Codex 비대화 실행(non-interactive mode)

codex exec --ignore-user-config \
  -c features.hooks=false -c features.apps=false -c features.plugins=false \
  -s read-only --skip-git-repo-check --ephemeral \
  -c 'model_reasoning_effort="high"' \
  -C /tmp/codex-review -o /tmp/codex-review/answer.md \
  -m <모델> - < brief.md

웹 검색이 필요한 리서치 의뢰에서만 --search를 exec 앞에 붙입니다 뒤에 두면 옵션 해석에 실패했어요 추론 강도는 기본 high로 두고 가벼운 건만 medium으로 낮추며, 시간과 토큰을 기록할 때 강도도 함께 적습니다 Claude Code 쪽에서는 이 호출을 감싼 스크립트를 스킬로 등록해 "코덱스로 검증해" 한마디로 부르고, 결과를 기다리는 동안 다른 일을 하도록 배경 실행으로 돌립니다

호출이 끝날 때마다 실행 기록에서 훅이 몇 줄 돌았는지를 함께 찍고, 0줄이 아니면 답을 쓰기 전에 원인부터 봐요 처음 붙일 때는 Codex가 쓸 수 있는 도구 목록을 끄기 전후로 비교해 커넥터가 빠졌는지도 확인했습니다

의뢰서 - 결론을 빼고 사실만 준다

가장 중요한 원칙은 내 결론과 "여기가 의심된다"를 넣지 않는 것이에요 검증자가 내 가설을 확인해 주는 쪽으로 끌려옵니다 원 요청, 완료 기준, 제약, 원천 자료 위치처럼 사실만 줘요

# 검증 의뢰 - 대상 한 줄
너는 독립 검증자다 파일은 읽기만 하고 아무것도 수정하지 마라
아래 대상과 참고에 적힌 경로만 읽어라

## 원 요청
요청 원문과 완료 기준
## 대상
검증할 파일의 절대경로
## 참고
원천 데이터, 기준 문서의 절대경로
## 지켜야 하는 것
요구사항과 제약을 번호로
## 묻는 것
결함, 누락, 근거 없는 주장, 요구 위반
확인 못 한 것은 미확인으로 적고 추정으로 채우지 마라
## 답 형식
결함마다 제목, 심각도, 위치, 재현 조건, 수정안
최대 8건, 심각도 순, 없으면 없다고

• 읽을 범위를 적는다 - 이 환경에서는 읽기 전용 샌드박스가 임시 작업 폴더 밖에 있는 검증 대상 파일도 읽을 수 있었어요 의뢰서에 경로를 적고 볼 필요 없는 폴더는 열지 말라고 쓰지만, 이 문장은 부탁일 뿐 막는 장치가 아닙니다 민감한 파일이 많은 컴퓨터라면 읽기 범위를 제한하는 공식 설정이 있는지 먼저 확인하세요
• 보낼 범위를 살핀다 - 의뢰서와 대상 파일 내용은 OpenAI로 전송돼요 밖으로 내보내기 곤란한 내용이 섞이지 않았는지 보내기 전에 한 번 살펴봅니다
• 답 형식을 고정한다 - 심각도와 재현 조건을 요구하면 판정이 빨라지고, 개수 상한을 두면 사소한 지적이 줄어요
• "미확인"을 허용한다 - 확인 못 한 것을 추정으로 채우지 말라고 적습니다 이 구성에서 Codex는 샌드박스 안에서 주소 조회에 실패해 라이브 사이트를 열지 못했고, 스스로 확인하지 못했다고 적었어요 라이브 확인은 Claude가 했습니다

지적은 건마다 직접 확인한 뒤에만 고친다

Codex의 답을 그대로 반영하지 않습니다 지적마다 파일을 열거나 재현해서 수용, 부분 수용, 기각을 정하고 근거를 남겨요 검증자도 틀리기 때문입니다 의뢰서와 회신 원문은 요약하지 않고 임시 폴더 밖에 그대로 보관해요 호출 스크립트가 끝나면서 임시 답을 지우기 때문이고, 나중에 "왜 그렇게 판정했나"를 되짚을 때 요약본으로는 원래 지적을 복원할 수 없었던 경험이 있어서입니다

기각한 사례는 이랬어요 기사 요약 본문의 성과 주장과, 그 주장의 표본이 공개되지 않았다고 짚은 편집자 해설을 Codex가 "내부 모순"으로 봤습니다 해설은 본문을 비판적으로 읽어 준 부가 정보라 모순이 아니라고 판정했어요

부분 수용은 지적은 맞지만 제안한 고침이 과하거나 범위가 넓을 때 씁니다 "실패한 주의 기록이 다음 주에 사라질 수 있다"는 지적이 그랬어요 앞선 수정으로 실패 경로가 거의 닫혀 있어 구조는 그대로 두고, 화면 문구의 "모두 남깁니다" 같은 표현을 "날짜별로"로 낮췄습니다

모델과 비용 - 주력과 최상위 두 개만

이 환경은 검증 모델을 두 개로 고정했어요 평소에는 주력 모델(GPT-6.1 Sol), 실제 서비스에 바로 반영되는 중요한 배포와 외부로 나가는 문서에는 최상위 모델(GPT-6 Astra)을 씁니다 사람이 최상위를 지정한 건은 대상과 무관하게 최상위로 돌리고, 어느 쪽인지 애매하면 고른 모델과 이유를 보고에 한 줄 남겨요

한 번에 1분 반부터 15분 가까이 걸려요 그동안에는 대상 파일을 고치지 않습니다 Codex가 가리킨 줄 번호가 어긋나기 때문이에요

몇 라운드 돌리나

기본은 1회입니다 검증 한도는 구독에서 나가므로 습관적으로 반복하지 않아요 블로커나 메이저를 고쳤고 위험이 큰 건일 때만 수정한 부분만 대상으로 다시 돌립니다

4라운드까지 간 사례가 두 번 있었어요 하나는 무인으로 도는 데이터 갱신 장치였고, 4차에서 "종료 기록을 못 쓰면 본 갱신까지 멈추는 회귀를 고친 뒤 사용"이라는 조건부 통과를 받았습니다 다른 하나는 이 사이트의 근거 기사 내부 링크 개편이었는데, 3라운드가 앞 라운드 수정 중에 생긴 회귀를 잡았고 4라운드에서 새 결함과 회귀가 0건이라 종료했어요 수정분만 본 3, 4라운드는 139초와 97초로 짧았어요

• 종료 조건 1 - 새 결함과 회귀가 0건이다
• 종료 조건 2 - 남은 지적은 받아들일 잔여 위험으로 기록에 명시했다
• 종료 조건 3 - 마지막 수정은 실제 함수 시험이나 실제 데이터로 확인했다

코드 리뷰라면 공식 플러그인부터

기준 문서: openai/codex-plugin-cc

이 환경이 의뢰서 방식을 고른 이유는 두 가지였어요 검증 대상이 코드만이 아니라 문서, 발표 자료, 분석 결과까지라 변경분 중심 리뷰와 맞지 않았고, 플러그인은 현재 저장소의 맥락으로 Codex를 띄우므로 작업 폴더의 지침과 훅이 검증자에게 실릴 수 있었습니다 플러그인은 공개 설명을 기준으로 판단했고 직접 설치해 시험하지는 않았어요

교차검증 점검표

• 검증자가 쓰기를 할 수 없는 환경인가(설정 파일이 아니라 실행 옵션으로 확인)
• 검증자가 작업 폴더의 지침과 훅을 읽지 않는 위치에서 도는가
• 의뢰서에서 내 결론과 의심 지점을 뺐는가
• 밖으로 내보내기 곤란한 내용이 섞이지 않았는지 살폈는가
• 시험용 명령 문자열을 셸로 실행하지 않는 데이터로 다뤘는가
• 지적마다 직접 확인한 근거와 판정을 남겼는가
• 위험이 큰 건은 수정분만 다시 검증했는가
• 어느 모델로, 몇 초, 몇 토큰을 썼는지 기록했는가

자주 묻는 질문

두 도구가 같은 규칙으로 번갈아 일하게 하려면 19편 클로드 코드와 코덱스 같이 쓰기부터 읽어보세요 자동 점검 장치는 6편 Hooks, 작업장 전체 설계는 12편 하네스 엔지니어링, 권한과 사고 방지 기준은 18편 에이전트 거버넌스로 이어집니다

검증 기준일: 2026-10-07 KST 공식 문서로 확인한 기능과 한 환경의 운영 기록(2026-09-25부터 10-07까지)을 구분해 작성했으며, 제품 업데이트에 따라 옵션과 모델명은 달라질 수 있습니다