서론

AI에게 코드를 작성하게 하는 개발은 빨라졌습니다. 하지만 "빠르게 만드는 것"과 "품질을 담보하는 것"은 별개의 문제입니다. 작성한 본인(AI)은 자신의 실수를 알아차리기 어렵고, 하나의 AI에게 작성하게 하고 동일한 AI에게 리뷰를 맡겨도 사각지대는 그대로 남습니다.

지금까지 우리는 AI가 작성한 코드의 리뷰를 사람이 ChatGPT에 붙여넣어 의뢰해 왔습니다. 사람이 복사 및 붙여넣기를 하는 중계 역할을 매번 수행해야 했으며, 그 부분이 병목(bottleneck)이었습니다. 이 기사는 그 리뷰를 Codex CLI를 사용하여 다른 AI에게 자율적으로 맡기고, 계획→리뷰→구현을 사람의 손을 거치지 않고 회전시키는 구현 워크플로우에 대한 기록입니다. 2026년 7월 시점의 운용으로, 여러 프로젝트에서 실제로 구성한 형태를 재현 가능한 입도로 작성합니다.

이중 게이트(Dual Gate)라는 개념

AI 리뷰에는 수비 범위가 다른 두 종류가 있으며, 양쪽을 서로 다른 게이트로 통과시키는 것이 기본입니다.

게이트 A: 설계 정합성 리뷰 (텍스트형)— 설계서·사양을 읽고, enum·계약·상태 전이·권한 경계·스코프가 설계 내에서 정합성을 유지하는지 확인한다. 담당은 Claude / ChatGPT. 한계는 "입력에 없는 구현 사실(실제 SQL/RLS·route 규약·cron·DB 제약)은 보이지 않는다"는 점.

게이트 B: 구현 접지 리뷰 (repo 직접 읽기형)— 실제 리포지토리의 working tree를 직접 읽고, cross-file 통합·병행(race)·데이터 파괴·schema/RLS·router 규약·config 의존의 구현 접지 버그를 찾아낸다. 담당은 Codex CLI (read-only).

이 두 가지는 독립적으로 실패합니다. 텍스트형이 GO(통과)한 설계에서, repo 직접 읽기가 실질적인 버그를 검출하는 차이는 재현성이 있습니다.

셋업(Setup)

Codex CLI는 OpenAI의 커맨드라인형 코딩 AI입니다. Claude Code에서 사용하는 설정은 두 가지 방법이 있습니다.

• 간편한 방법은 Claude Code에게 맡기는 방법. Codex용 플러그인을 설치하고 /codex setup을 실행하면 도입까지 안내됩니다 (Windows 데스크톱 버전도 동일하며, 직접 터미널을 열 필요는 없습니다).

• 직접 설치하려면, npm install -g @openai/codex → codex 실행 → codex login으로 로그인합니다.

자세한 절차는 공식 리포지토리 ( https://github.com/openai/codex )에 정리되어 있습니다.

실제 운용 방식

Claude Code가 설계·지휘를 담당하며, 신기능 설계 단계에서 Codex에게 read-only로 리뷰를 의뢰합니다. 포인트는 전문을 던지는 것이 아니라, 리스크 영역(인가·병행·데이터 파괴)을 명시하여 읽게 하는 것입니다. 컨텍스트(context) 과다는 오히려 검출력을 떨어뜨립니다.

의사적으로는 다음과 같은 루프입니다.

1. Claude Code가 설계서 / diff를 준비
2. Codex에게 read-only 리뷰를 의뢰 (리스크 영역을 명시)
3. 지적 사항을 Claude Code가 실제 코드로 검증한 후 반영
...

reasoning effort는 billing / auth / RLS / 데이터 파괴 / 병행과 같은 리스크 영역에서 high를 사용하고, 경미한 UI는 보통(normal)으로 충분합니다. 여기서 주의할 점은, high는 "내부 추론량의 제어"이지 정확도 보증이 아니라는 점입니다. 모든 항목을 high로 설정하는 것은 비용과 지연 시간 대비 효율적이지 않습니다.

무엇을 얻었는가

고객 정보는 숨기고 일반화하겠습니다. 어떤 신기능에서 "출전자에 따라 자신의 데이터만 볼 수 있다"는 권한(액세스 제어) 설계를 3 라운드에 걸쳐 리뷰했습니다. 대상은 완성된 코드가 아니라, 앞으로 만들 설계입니다.

라운드가 진행될수록 지적 사항은 깊어졌고, 수렴했습니다 (Critical 1 → 0 → 0). 예를 들어:

• 권한 판정 조건이 너무 넓어서, 그대로 만들면 타사의 데이터까지 보일 수 있는 설계였다 (인가의 항진/Tautology)
• 동의 상태를 확인하지 않은 채 이미지를 다루는 설계였다
• 여러 업데이트가 동시에 실행될 때 데이터가 경합할 수 있는 구조였다

모두 문자열 검색(grep)이나 타입 체크로는 드러나지 않는 내용입니다. SQL의 의미, 병행 시의 동작, 외래 키(foreign key)로 연결된 데이터의 연결 고리를 "읽어야" 비로소 알 수 있는 층위입니다. 그리고 중요한 것은, 이것들이 구현되기 전의 설계 단계에서 발견되었다는 점입니다. 세상에 나오기 전에 설계의 구멍을 메울 수 있습니다.

왜 지금 가능한가

이전의 AI는 "코드만 작성하는" 에이전트였습니다. 지금은 Codex가 사용하는 GPT-5.6 Sol을 ultra 모드로 구동함으로써, 구현 내용을 읽고 반증할 뿐만 아니라 설계나 전략의 시비(是非)까지 깊이 있게 고민하게 되었다고 느낍니다.

용어는 정확하게. "Sol"은 모델의 이름이며, "ultra"는 여러 에이전트를 병렬로 실행하여 통합하는 실행 모드의 이름으로 서로 별개입니다 (단일 호출의 reasoning effort 상한은 max입니다). Sol은 OpenAI가 미국 시간 2026년 7월 9일(일본 시간 7월 10일)에 일반 제공을 시작했습니다.

한계를 직시하기

에이전트끼리 왕복할수록 지적 사항이 깊어졌다는 관찰을 통해, "대화와 사고의 축적이 정밀도에 영향을 미치고 있는 것이 아닌가"라는 가설을 가지고 있습니다. 다만 이는 직접적인 경험에 기반한 가설이며, 인과관계가 증명된 것은 아닙니다.

공개 벤치마크에서도 AI 리뷰의 검출률은 제한적입니다 (사람이 지적한 issue의 일부만을 포착하며, 모델 간의 우열도 근소한 차이로 바뀝니다). 테스트에 따라서는 다른 모델의 성적이 더 높게 나오는 결과도 있습니다. 따라서 "AI가 아무 말도 하지 않는다 = 안전하다"라고 취급하지 않습니다. 결제, 인가(Authorization), 데이터 파괴와 같은 영역에서는 AI 리뷰에 더해 property / idempotency / transaction 테스트와 사람의 최종 확인을 반드시 병행합니다. AI 리뷰는 사람이나 테스트의 대체재가 아니라, 간과하는 부분을 줄이기 위한 하나의 계층(layer)입니다. 중단점(어디서 멈출 것인가) 또한 지휘 역할을 하는 사람이 결정합니다.

요약

• 리뷰는 "작성하는 AI"와 "읽는 AI"를 분리한다. 하나의 AI가 수행하는 자기 리뷰(Self-review)는 사각지대가 남는다.
• 게이트 A(설계 정합성)와 게이트 B(구현 접지성)는 독립적으로 실패한다. 둘 다 통과해야 한다.
• Codex에는 전체를 다 읽게 하는 것이 아니라, 리스크 영역을 명시하여 read-only로 읽게 한다.
• high는 정밀도 보증이 아니다. 리스크 영역에만 사용한다.
• "지적 사항 제로"까지 돌리지 않는다. 실질적인 버그 → 에지(edge) 케이스 → 문구 순으로 decay(감쇠)시킨다. 중단점은 사람이 결정한다.
• AI 리뷰는 사람 / 테스트의 대체재가 아니다. 결제, 인가, 데이터 계통은 반드시 사람 + 테스트를 병행한다.

이 이중 게이트를 "업무에 어떻게 편입시키고, 소수 인원으로도 품질을 시스템으로 담보할 것인가"라는 경영 관점에서의 정리는 운영사의 lab note에 정리되어 있습니다.

→ https://nihonbashi.ai/blog/dual-gate-ai-review

Discussion