codex vs claude code — 비교 대신 분담, Codex 리뷰가 머지 뒤에 잡은 결함 8건

codex vs claude code, 어느 쪽을 쓸까. 저희는 고르지 않았습니다.

Claude Code가 설계와 코드를 쓰고, Codex가 설계를 컨펌하고 코드를 리뷰합니다. 관문이 둘입니다.

하나를 고르지 않고 쓰는 쪽과 검토하는 쪽을 나눴습니다.

이 글은 그 분담을 다섯 달 돌린 기록이고, 잘된 것보다 Codex가 잡은 것과 Codex 쪽에서 난 사고를 더 길게 적었습니다.

환경

• Claude Code 2.1.287. 모델은 기간 중 Claude Opus 5에서 Fable 5.1로 바뀌었습니다
• Codex CLI 0.154.0, 모델 gpt-6-astra, reasoning effort xhigh
• Codex Plugin for Claude Code 1.0.4 (openai/codex-plugin-cc). 정지 시점 리뷰 게이트는 5월 26일부터 9월 7일까지 켜 두었습니다
• 리서치 레포 하나(비공개, NestJS와 Python, PostgreSQL)와 이 블로그 레포(공개, Astro). 숫자는 리서치 레포에서 셌고, 공개 레포 쪽은 PR 번호를 적어 두었습니다
• 기간은 2026년 5월 30일부터 10월 5일까지, Mac mini M4 Pro

왜 하나를 고르지 않았나?

검색 상위에 있는 글들은 둘을 같은 일에 붙여 놓고 비교합니다. 저희는 그 실험을 하지 않았습니다. 같은 일을 둘에게 시켜 재지 않았으니 어느 쪽이 낫다는 말은 이 글에 없습니다.

대신 자리를 나눴습니다.

쓰는 일은 Claude Code가 합니다. 레포 안에서 파일을 읽고 고치고 커밋하는 흐름이 훅과 스킬로 묶여 있어서 설계 문서에서 PR까지 한 세션 안에서 끝납니다.

검토하는 일은 Codex가 합니다. 이 블로그의 운영자가 그렇게 정한 이유를 그대로 옮기면 이렇습니다.

“설계/코드 리뷰 부문에서 claude 보다는 codex astra가 좀더 섬세하게 잘못된 부분까지도 다 찾아서 리뷰 해줘서 단점을 보완해주는 그런 느낌으로 진행하고있어”

느낌이라고 적었습니다.

그 느낌이 기록으로는 어떻게 남았는지가 아래 내용입니다.

설계는 어떻게 컨펌을 받나?

순서는 넷입니다.

① Claude Code가 스펙 파일을 쓴다 브레인스토밍에서 나온 설계를 마크다운 한 파일로 적습니다.

② Codex 세션을 열어 그 파일을 읽힌다 검토 결과는 지적 목록으로 돌아옵니다.

③ Claude Code가 반영하고 커밋한다 커밋 제목에 몇 건을 반영했는지 적습니다.

④ 지적이 없어질 때까지 ②와 ③을 반복한다 그 뒤에야 계획과 구현으로 넘어갑니다.

스펙을 고친 커밋 중 제목에 검토가 들어간 것이 23건입니다. 운영자가 직접 검토한 한 편을 빼고 커밋 제목에서 라운드를 복원하면 이렇습니다.

여섯 편에 열여섯 라운드이고, 적힌 것만 더해도 38건입니다.

라운드 사이가 짧습니다. 스펙 D는 두 라운드가 31분 안에 끝났고, 스펙 C는 세 라운드가 같은 날 안에 있습니다. 검토가 사람 일정을 기다리지 않아서 가능한 속도입니다.

스펙 파일 경로가 들어 있는 Codex 세션은 9월 6일부터 10월 3일까지 40개입니다. 세션 기록이 커밋 기록과 같은 날짜에 몰려 있습니다.

코드 리뷰는 어디서 돌아가나?

플러그인의 정지 시점 게이트입니다.

Claude Code가 턴을 끝내려 하면 Stop 훅이 돌고, 플러그인이 그 턴에서 바뀐 코드를 Codex에 넘깁니다. Codex는 둘 중 하나로 답합니다.

ALLOW면 턴이 그대로 끝납니다.

BLOCK이면 Claude는 멈추지 못하고 지적을 먼저 고칩니다.

켜는 명령은 한 줄입니다.

/codex:setup --enable-review-gate

5월 26일부터 9월 7일까지 이 리뷰가 1,025회 돌았습니다.

하루 열 번쯤입니다.

여기서 셀 수 없는 것이 하나 있습니다.

게이트가 멈춤을 막아 그 자리에서 고쳐진 지적은 PR에 흔적이 없습니다.

셀 수 있는 것은 반대쪽입니다.

PR이 머지된 뒤에 리뷰가 도착해 교정 PR이 따로 난 경우입니다. 그게 8건입니다.

머지 뒤에 잡힌 여덟 건은 무엇이었나?

전부 빌드와 테스트가 통과한 상태였습니다.

종류를 묶으면 셋입니다.

조용히 통과시키는 구멍 #221, #306, #308. 감사와 발행 게이트가 위반을 걸러야 하는 자리에서 걸러지지 않았습니다. 셋 다 테스트가 있었고 셋 다 초록이었습니다.

완료라는 보고가 틀린 것 #107, #118, #189. 작업은 됐는데 「됐다」의 범위가 실제보다 넓었습니다.

빠진 상태 #126, #314. 정상 경로는 맞고, 회전과 미확정 주문처럼 가끔 오는 상태가 빠졌습니다.

여덟 건 중 다섯 건이 첫째와 둘째 종류입니다. 테스트가 통과했다는 사실 자체가 틀린 보고의 일부였던 경우입니다.

분석 판정 하나가 같은 날 두 번 교정된 일도 있었습니다. 첫 교정을 리뷰가 잡았고, 그 교정이 또 틀렸다는 것도 리뷰가 잡았습니다.

쓴 쪽은 왜 못 보고 검토하는 쪽은 보나?

여덟 건은 전부 쓴 쪽이 됐다고 보고한 뒤에 나왔습니다. 쓴 쪽은 자기가 기억하는 경로를 검사합니다. 기억에 없는 경로는 검사 목록에도 없습니다.

검토하는 쪽은 보고를 믿지 않습니다. 플러그인의 리뷰 프롬프트에 그 말이 그대로 있습니다. 앞 턴의 응답을 변경이 있었다는 증거로 삼지 말고 레포 상태에서 확인하라는 지시입니다.

그러면 이것이 Codex라서인지, 다른 눈이라서인지가 남습니다.

저희는 가르지 못했습니다.

이 블로그 레포에서는 Claude Code가 새 컨텍스트의 리뷰어를 띄워 같은 브랜치를 보게 했는데, 그 리뷰어도 CI 네 종이 전부 통과한 상태에서 Important 2건을 잡았습니다(블로그 PR #126). 쓴 세션과 다른 컨텍스트라는 조건만으로도 잡히는 것이 있다는 뜻입니다.

Codex가 더 많이 잡는지는 같은 변경을 둘에게 보여야 알 수 있고, 그 실험은 아직 안 했습니다. 지금 아는 것은 하나입니다. 쓴 세션이 자기 결과를 검토하게 두지 않는다.

Codex 쪽에서는 무엇이 잘못됐나?

9월 6일, Codex 세션이 레포 루트에 자기 설정 파일을 만들었습니다. 그 안에 내부 시크릿이 평문으로 들어 있었습니다.

git add -A를 했으면 그대로 커밋될 자리였습니다.

커밋 전에 발견했습니다. 무시 목록에 넣었고, 그 교정이 PR #303입니다.

검토하는 도구도 레포 안에 파일을 씁니다. 사람이 안 만든 파일이 루트에 생기면 커밋 전에 열어 봅니다.

정지 시점 게이트는 9월 7일을 마지막으로 꺼 두었습니다. 끈 이유는 운영자 말로 “리뷰 루프가 길어져서”입니다. BLOCK 뒤에 고친 턴이 다시 리뷰되고 그 리뷰가 다시 BLOCK을 내면 한 턴이 끝나지 않습니다.

그 뒤로는 Codex 세션을 따로 열어 검토를 받습니다. 9월 8일부터 10월 3일까지 그런 세션이 36개이고 그중 25개가 스펙 파일을 읽었습니다.

남는 것

둘 중 하나를 고르는 질문이 아니었습니다. 쓰는 자리와 검토하는 자리를 나누면 비교할 필요가 없습니다. 어느 쪽이 낫다는 말은 같은 일을 둘에게 시켜 본 뒤에만 할 수 있고, 저희는 안 했습니다.

검토는 다른 눈이 합니다. 쓴 쪽이 됐다고 한 여덟 건을 검토하는 쪽이 뒤집었고, 다섯 건은 테스트 통과 자체가 틀린 보고의 일부였습니다. 모델이 달라서인지 컨텍스트가 달라서인지는 아직 가르지 못했습니다.

게이트는 흔적을 남기지 않습니다. 머지 전에 막은 것은 셀 수 없습니다. 셀 수 있는 여덟 건은 게이트를 지나 새어 나간 쪽입니다. 그래서 리뷰 횟수와 교정 건수를 따로 셉니다.

검토하는 도구도 파일을 씁니다. 시크릿이 평문으로 든 설정 파일이 레포 루트에 생겼습니다. 사람이 만들지 않은 파일은 커밋 전에 열어 봅니다.

리서치 레포는 비공개라 아래 명령은 저희 머신에서만 재현됩니다. 블로그 PR #126은 공개 레포라 누구나 확인할 수 있습니다.

# 설계 관문 — 스펙을 고친 커밋 중 제목에 검토가 든 것
git log --format='%ad %s' --date=short -- docs/superpowers/specs | grep -c 검토
# 코드 관문 — Codex 가 본문에 나오는 머지 PR, 그중 8건이 리뷰 교정
gh pr list --state merged --search Codex --limit 50
# 정지 시점 리뷰 횟수 — 세션 기록에 리뷰 프롬프트의 첫 줄이 들어 있다
grep -rl 'Run a stop-gate review of the previous Claude turn' ~/.codex/sessions | wc -l
# 게이트 상태
cat ~/.claude/plugins/data/codex-openai-codex/state/*/state.json
# 공개 레포 — Claude 새 컨텍스트 리뷰어가 잡은 2건
gh pr view 126 --repo wndudtjd/anchorforest-blog

자주 묻는 질문

Q. codex와 claude code 차이는 뭔가요?

성능 차이는 말할 수 없습니다.

같은 일을 둘에게 시켜 재지 않았습니다.

운영에서 겪은 차이는 자리입니다. Claude Code는 레포 안에서 설계와 코드를 쓰고 훅과 스킬로 흐름을 묶는 쪽이 편했고, Codex는 추론 강도를 올려 두고 검토만 맡기는 쪽이 편했습니다. 두 도구의 공식 문서는 아래 참고 자료에 있습니다.

Q. codex 코드 리뷰 스킬은 어떻게 켜나요?

플러그인을 깔고 게이트를 켭니다.

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/codex:setup --enable-review-gate

끄는 것은 --disable-review-gate입니다. 게이트 없이 한 번만 보려면 /codex:review, 설계 선택까지 따져 보게 하려면 /codex:adversarial-review가 있습니다.

Q. claude code 코드 리뷰만 쓰면 안 되나요?

됩니다. 이 블로그 레포는 Claude Code가 새 컨텍스트의 리뷰어를 띄워 보게 했고 그 리뷰어가 Important 2건을 잡았습니다.

쓴 세션과 다른 컨텍스트에서 보게 하는 것이 먼저입니다. 다른 벤더까지 두는 것은 그 다음이고, 저희는 운영자의 판단으로 그렇게 했습니다.

Q. 정지 시점 리뷰는 비용이 얼마나 드나요?

토큰 비용은 재지 않았습니다. 셀 수 있는 것은 횟수입니다. 켜 둔 105일 동안 1,025회, 하루 열 번쯤입니다.

참고 자료

• openai/codex-plugin-cc 는 정지 시점 리뷰 게이트가 Stop 훅으로 돌고 /codex:setup --enable-review-gate 로 켠다는 것, 그리고 /codex:review 와 /codex:adversarial-review 명령의 근거입니다.
• Claude Code 훅 레퍼런스 는 Stop 훅이 Claude가 응답을 끝낼 때 돌고 종료 코드 2로 멈춤을 막을 수 있다는 것의 근거입니다.
• 블로그 레포 PR #126 은 Claude 새 컨텍스트 리뷰어가 CI 통과 상태에서 Important 2건을 잡은 기록입니다.

이 사이트의 수치는 주 1회 DB와 다시 대조하고, 판단이 바뀌면 지우지 않고 글 안에 덧붙입니다. 갱신은 RSS로 받을 수 있습니다.