블라인드 심판: 36번의 대결에서 Claude Code vs Codex 채점하기

Thomas Ricouard(@Dimillian)가 어떤 벤치마크보다 더 잘 표현했습니다: “Claude Code은 확실히 실행할 수 있다고 아는, 아주 평범한 리팩토링 같습니다. Codex는 최첨단 아키텍처입니다. 아직 기존 것을 깨뜨리지 않고 실제로 해낼 수 있는지는 확신이 없습니다.”¹

궁금해하는 것을 멈추고 측정을 시작했습니다. Claude Code과 Codex CLI을 같은 작업에서 경쟁시키고, 출력물을 무작위로 Alpha와 Beta로 라벨링한 뒤, 어떤 에이전트가 어떤 것을 작성했는지 밝히기 전에 5개 차원에서 블라인드 채점하는 시스템을 구축했습니다. 36번의 대결 후, 점수판은 Claude이 판정이 난 12번의 대결 중 8번을 이겼다고 말합니다. 하지만 점수판이 핵심이 아닙니다. 핵심은 블라인드 심판이 채점 후 생성하는 종합 분석입니다. 두 계획의 가장 강력한 요소를 결합하여 어느 참가자도 단독으로 만들어내지 못한 것보다 더 나은 결과를 만들어냅니다.

요약

36번의 대결. 5개 차원(정확성, 완전성, 단순성, 분해, 실행 가능성)에 대한 블라인드 평가. 구조화된 판정 매니페스트가 있는 13번의 대결(승자가 선언된 12번 포함) 중 Claude Code이 8번, Codex CLI이 3번, 미결정 1번이었습니다. 진정한 산출물은 승자가 아닙니다. 두 계획에서 최고의 요소를 선별하여 어느 에이전트 단독보다 강력한 구현 브리프를 만들어내는 종합 단계입니다. 동반 게시물 열 개의 두뇌로 생각하기는 협력적 숙의를 다룹니다.¹² 블라인드 심판은 경쟁적 평가를 다룹니다. 방법론이 점수판보다 중요합니다.

비교가 어려운 이유

지금 모두가 AI 코딩 에이전트를 비교하고 있습니다. 결과에 대해 아무도 합의하지 못합니다.

문제는 구조적입니다. 모델 비교는 세 가지 축을 따라 저하됩니다: 느낌(각 모델에서 하나의 작업을 시도하고 직감으로 판단), 최신 편향(마지막 성공이 이전의 모든 실패를 덮어씀), 작업별 강점(리팩토링 작업에서 이기는 모델이 보안 리뷰에서 지는 경우). 이것들은 나쁜 관찰이 아닙니다. 나쁜 실험입니다.

Alex Finn(@AlexFinn)은 두 모델이 서로의 출력을 검증하는 이중 검증 워크플로를 운영합니다.² 이중 검증 방식은 어느 모델 하나만으로는 놓칠 오류를 잡아냅니다. 통찰은 타당합니다: 독립적인 평가는 불일치를 드러내고, 불일치가 있는 곳에 버그가 숨어 있습니다.

@doodlestein은 Claude, Codex, Gemini를 포함한 10개 이상의 에이전트를 동시에 실행하며, “아이디어 위저드”라 부르는 정형화된 프롬프트를 사용하여 같은 문제를 다른 각도에서 공략합니다.³ 분해에 뛰어난 플래너가 세부 지향적인 에이전트가 즉시 잡아내는 정확성 버그를 놓칠 수 있습니다.

두 워크플로 모두 단일 모델 평가보다 개선되었습니다. 그러나 가장 큰 위협인 확증 편향을 제거하지는 못합니다. 어떤 모델이 어떤 계획을 작성했는지 알면, 더 신뢰하는 모델에 더 관대한 점수를 줄 것입니다. 매번. 부주의해서가 아니라, 편향은 의식 아래에서 작동하기 때문입니다. 빠진 조각은 블라인딩입니다. 평가자가 어떤 에이전트가 어떤 출력을 생성했는지 모르면, 확증 편향이 부착될 대상이 없습니다.

블라인드 평가 프로토콜

/duel 시스템은 5단계로 작동합니다:

1. 병렬 실행. 두 에이전트 모두 같은 작업 프롬프트와 프로젝트 컨텍스트를 받습니다. Claude Code은 한 프로세스에서, Codex CLI은 다른 프로세스에서 실행됩니다. 어느 쪽도 상대의 출력을 보지 못합니다.
2. 무작위 라벨링. 동전 던지기로 한 에이전트를 “Alpha”에, 다른 에이전트를 “Beta”에 배정합니다. 시스템은 매핑을 agent-mapping.json에 기록하고 봉인합니다. 심판도 저도 채점이 끝날 때까지 매핑을 보지 못합니다.
3. 블라인드 채점. 심판 에이전트가 두 계획을 읽고 5개 차원에서 각각 0-4점, 최대 20점 만점으로 채점합니다. 심판은 “Alpha 계획”과 “Beta 계획”만 봅니다.
4. 승자 추천. 심판이 신뢰 수준과 서면 근거를 포함하여 승자(또는 미결정)를 선언합니다.
5. 종합. 심판이 두 계획의 가장 강력한 요소를 결합하여 정제된 구현 브리프를 만듭니다. 종합이 실제 산출물입니다.

5개 채점 차원:

핵심 설계 결정: 종합은 50/50 혼합이 아닙니다. 승자의 핵심 전략에 크게 가중치를 두면서 패자로부터 진정한 통찰을 선별합니다. 초기에 동일 가중치 종합을 시도했을 때 두 계획의 최악의 속성을 물려받은 일관성 없는 계획이 나왔습니다. 가중 종합은 구조적으로 건전하고(승자로부터) 철저하게 강화된(패자의 유효한 엣지 케이스로부터) 계획을 생성합니다.

사례 연구: 보안 교정 대결

2026년 2월, 3개 에이전트 보안 감사에서 Supabase 인증과 Stripe 결제를 사용하는 FastAPI 애플리케이션인 ResumeGeni에서 7개의 CRITICAL 및 7개의 HIGH 발견사항을 찾았습니다.⁴ 이미 2개의 사소한 수정을 배포한 상태였고, 9개가 남아 있었습니다. 교정 계획을 생성하기 위해 대결을 실행했습니다.

두 에이전트 모두 같은 브리핑을 받았습니다: 파일 경로와 줄 번호가 포함된 발견사항 목록, 아키텍처 컨텍스트, 검증된 수정 패턴이 이미 한 파일에 존재한다는 제약, 그리고 단계별 배포 계획 생성 요구사항.

Alpha의 계획: 9개 발견사항에 대한 11개 스토리, 3개 배포 웨이브로 구성. 테스트 베이스라인 스토리(SEC-01)가 모든 후속 작업을 차단. 구체적인 지표가 포함된 배포 게이트: 인증 성공률, 5xx 모니터링, 웹훅 거부 횟수. 철저한 대안 거부 논의. 스토리는 What/Why/Success 구조에 줄 번호 범위를 사용.

Beta의 계획: 발견사항에 대한 직접적 1:1 매핑 스토리. 3개 배포 웨이브: Critical은 단일 단위, High-priority는 독립 배포 가능, Cleanup. 미들웨어 발견사항에 대한 수정 전 조사. 스토리별 구체적인 줄 번호, 함수 이름, import 경로, 검증용 curl 명령어.

정확성 격차가 결과를 말해주었습니다. Beta가 Alpha가 완전히 놓친 두 가지를 잡아냈습니다.

첫 번째: 미들웨어 발견사항(C3)은 get_user(jwt=...)를 세션 오염 벡터로 플래그했습니다. Beta는 get_user()가 상태 비저장 검증 호출이라는 것을 정확히 식별했습니다. gotrue-py는 get_user가 아니라 verify_otp와 exchange_code_for_session에서만 _save_session()을 호출합니다. Alpha는 이를 다른 두 라우터와 동일한 수정이 확실히 필요한 것으로 취급했는데, 이는 모든 인증된 요청에 불필요한 요청당 오버헤드를 추가하게 됩니다. Beta는 말했습니다: 먼저 조사하고, 확인된 경우에만 수정하라.

두 번째: 매직 링크와 패스키 라우터는 admin.generate_link()(SERVICE_KEY 싱글톤 필요)와 verify_otp()(요청당 새로운 클라이언트 필요) 모두를 사용합니다. Alpha의 계획은 새로운 클라이언트 패턴을 일률적으로 적용했습니다. 그 계획을 따르는 구현자는 관리자 작업을 깨뜨릴 것입니다. Beta는 분리를 명시적으로 지적했습니다: verify_otp에는 새로운 클라이언트, admin.generate_link()에는 공유 싱글톤.

점수:

Alpha는 Codex였습니다. Beta는 Claude이었습니다. 높은 신뢰도.⁴

종합 결과는 Beta의 기술적 정밀성과 Alpha의 운영 엄격성을 결합했습니다. 다음은 종합 산출물의 한 스토리로, 두 계획이 어떻게 병합되었는지 보여줍니다:

Story 1.1 (C1 — Magic Link 공유 싱글톤): magic_link.py에서 _create_auth_client()를 추가합니다. verify_otp(224줄)에만 새로운 anon 클라이언트를 사용합니다. SERVICE_KEY가 필요한 admin.generate_link()(213줄)에는 공유 싱글톤을 유지합니다.

이 스토리는 Beta의 정확한 줄 번호와 중요한 admin/anon 클라이언트 분리를 상속받아, Alpha의 3단계 배포 시퀀스에 맞는 구조로 포장했습니다. 전체 종합은 C3에 대한 Beta의 조사 우선 접근법, Beta의 구체적인 curl 검증 명령어, Alpha의 배포 게이트(인증 성공률 모니터링, 5xx 추적), Alpha의 회귀 테스트 전략(Wave 1 후 E2E Playwright 인증 스위트, Wave 2 후 Stripe 테스트 웹훅)을 유지했습니다. 결과: 어느 계획 단독으로도 제공하지 못한 운영 가드레일을 갖춘, 하루 내 실행 가능한 12개 스토리의 3단계 계획.

점수판 (그리고 왜 오해를 불러일으키는가)

36번의 대결에서 13번이 구조화된 판정 매니페스트를 생성했습니다. 하나의 매니페스트가 미결정을 선언하여, 명확한 승자가 있는 12번이 남았습니다:

Claude: 8승. Codex: 3승. 미결정: 1.¹¹

점수판을 모델 벤치마크로 취급하지 마십시오. 벤치마크가 아닙니다.

Claude의 승리는 리뷰, 검증, 보안 작업에 집중되어 있습니다: 8승 중 7승이 코드 리뷰, 보안 분석, 기술 평가와 관련된 작업에서 높은 신뢰도로 거둔 것입니다. Codex의 유일한 높은 신뢰도 승리는 코드 리뷰 작업에서 나왔는데, 절차적 철저함과 명시적 의존성 체인이 Claude의 덜 구조화된 접근법을 능가했습니다. 나머지 두 승리는 낮은 신뢰도였습니다. 패턴: Claude은 더 실행 가능하고 기술적으로 정밀한 계획을 생성합니다. Codex는 더 강력한 운영 프로세스와 더 넓은 이론적 범위를 생성합니다.

Ricouard의 말이 맞았습니다. 계획 품질 대 실행 신뢰성은 실제 평가 축입니다.¹ 하지만 점수판은 저의 작업 구성(보안 및 아키텍처 리뷰 중심)을 반영할 뿐, 객관적인 모델 순위가 아닙니다. 그린필드 기능 개발이나 인프라 자동화에서 대결을 실행하는 사람은 다른 결과를 볼 가능성이 높습니다. Nathan Lambert의 포스트-벤치마크 시대 분석도 같은 점을 지적합니다: Opus 4.6과 Codex 5.3 사이의 미세한 차이가 작업 형태와 평가 방법론에 의존할 때, 전통적인 벤치마크는 더 이상 의미 있는 신호를 전달하지 못합니다.¹⁰

점수판은 저의 워크플로에 대해 알려줍니다. 어떤 모델이 “더 나은지”는 알려주지 않습니다.

종합이 진정한 산출물이다

이긴 계획이 핵심이 아닙니다. 종합이 핵심입니다.

모든 대결은 세 가지 산출물을 생성합니다: Plan Alpha, Plan Beta, 그리고 종합. 종합은 일관된 구조를 따릅니다: 승자의 핵심 전략을 채택하고, 패자의 유효한 엣지 케이스를 통합하고, 양쪽의 불필요한 범위를 제거합니다. 외교적이지 않습니다. 차이를 나누지 않습니다. 어떤 요소를 유지하고 어떤 것을 폐기할지 명시적으로 선택하며, 각각에 대한 서면 근거를 제공합니다.

채용 코퍼스 확장 대결에서, Claude의 계획은 기존 인프라를 먼저 활성화하고(시스템이 아직 폴링하지 않던 8,780개의 알려진 보드에 대한 시드 스크립트), 새로운 ATS 플랫폼으로 확장한 뒤, 발견 시스템을 구축했습니다.⁶ Codex의 계획은 단 하나의 채용 공고를 수집하기 전에 코드베이스 감사와 계측 사양부터 시작했습니다. Claude이 단순성과 실행 가능성에서 이겼습니다. 하지만 Codex는 Claude이 놓친 것을 식별했습니다: 보드 생명주기 상태 머신(active/failing/quarantined)의 필요성. Codex는 또한 볼륨 확장이 중복 폭발을 은폐하는 것을 방지하기 위한 중복 제거 회귀 감사를 플래그했습니다. 종합은 Claude의 활성화 우선 시퀀싱을 유지하고, 초기 시딩이 측정 가능한 결과를 제공한 후 Phase 1.5로 Codex의 관찰 가능성 및 생명주기 추적을 통합했습니다. 같은 패턴이 채용 공고 수집 시스템 대결에서도 나타났는데, Claude의 계획은 기존 APScheduler와 레지스트리 테이블을 재사용한 반면 Codex는 더 철저한 2-테이블 출처 스키마를 제안했습니다. 종합은 Claude의 실용적 아키텍처를 채택하고 Codex의 중복 제거 해시 개선을 선별했습니다.⁷

ATS 리뷰 대결에서, Claude은 Codex가 완전히 놓친 P0 런타임 크래시(채용 공고 추적을 조용히 깨뜨리는 스케줄러의 메서드 시그니처 불일치)를 발견했습니다.⁵ Codex는 Claude이 플래그하지 않은 스케줄러 중복 실행 방지와 관리자 엔드포인트 남용 벡터를 발견했습니다. 종합은 Claude의 P0 수정으로 시작하고 Codex의 운영 강화로 보완했습니다.

36번의 대결에 걸친 패턴: 심판 모델은 일관되게 어느 참가자의 계획보다 강력한 종합을 생성합니다. 심판이 더 똑똑한 것이 아닙니다. 적대적 구조가 완전한 범위를 강제합니다.⁹ 각 에이전트가 독립적으로 위험과 엣지 케이스를 식별합니다. 심판은 그 모두를 봅니다. 종합은 두 에이전트 통찰의 합집합에서 개별 사각지대를 뺀 것을 상속합니다.

이 패턴은 다중 에이전트 숙의의 더 넓은 발견과 연결됩니다: 독립성이 메커니즘입니다. 서로 다른 관점에서 의사결정을 평가하는 10개의 숙의 에이전트는 단일 에이전트가 놓치는 편향을 잡아냅니다. 서로 다른 아키텍처에서 같은 작업을 공격하는 2개의 대결 에이전트는 어느 에이전트 하나만으로는 출시할 수 있는 구현 격차를 잡아냅니다. 종합 단계는 두 시스템에서 동일합니다: 독립적 평가를 모든 관점의 혜택을 받는 단일 산출물로 결합합니다.

두 시스템을 지원하는 오케스트레이션 레이어는 별도로 문서화합니다. 여기서 중요한 것은 대결과 숙의가 상호 보완적 기능을 수행한다는 점입니다. 숙의는 “이것을 만들어야 하는가?”에 답합니다. 대결은 “이것을 만드는 가장 강력한 방법은 무엇인가?”에 답합니다.

대결할 때 vs. 숙의할 때

두 시스템 모두 독립적 평가와 종합을 사용합니다. 서로 다른 의사결정 유형에 적합합니다.

저의 패턴: 설계를 숙의하고, 구현 계획을 대결시키고, 종합을 실행합니다.

보안 교정 결정은 먼저 숙의를 거치고(“이것이 올바른 우선순위인가? 시스템적 문제를 놓치고 있는가?”), 그다음 대결을 하고(“이 수정들을 실행하는 가장 강력한 단계별 계획은 무엇인가?”), 그다음 심판의 종합으로부터 실행합니다. 숙의 시스템과 대결 시스템은 인프라를 공유하지만 의사결정 파이프라인에서 별개의 목적을 수행합니다.

잘못한 것들

초기 대결에는 블라인드 라벨링이 없었습니다. 어떤 모델이 어떤 것을 작성했는지 알면서 두 계획을 읽었습니다. 확증 편향은 실제로 존재했고 측정 가능했습니다: 블라인딩 전에 일관되게 Claude에 실행 가능성 점수를 더 높게 주었고, 무작위 Alpha/Beta 배정을 도입한 후 격차가 줄어들었지만(사라지지는 않았지만) 확인했습니다. 블라인딩 프로토콜은 선택 사항이 아닙니다.

3개의 채점 차원(정확성, 완전성, 실행 가능성)으로 시작했습니다. 두 번째 대결에서, 계획의 구조와 계획의 내용을 혼동하고 있다는 것을 깨달았습니다. 단순성(과도한 엔지니어링인가?)과 분해(단계가 잘 정렬되어 있는가?)를 추가하여 이 두 관심사를 분리했고, 더 유용한 채점이 가능해졌습니다.

첫 번째 종합 시도는 두 계획을 동등하게 혼합했습니다. 결과는 일관성이 없었습니다: Alpha의 테스트 전략이 Beta의 배포 시퀀스에 접목되었고, 어느 계획의 가정도 유지되지 않았습니다. 심판이 승자의 프레임워크를 명시적으로 채택하고 패자의 통찰을 선별적으로 통합하는 가중 종합이 돌파구였습니다.

저의 작업 구성에서 N=36은 모델 벤치마크가 아닙니다. 워크플로 도구 평가입니다. 대결 시스템은 저의 특정 코드베이스에서 저의 특정 작업에 대해 어떤 에이전트가 더 강력한 계획을 생성했는지 알려줍니다. “Claude이 Codex보다 낫다”로 외삽하는 것은 이 시스템이 제거하기 위해 존재하는 것과 같은 느낌 기반 추론이 될 것입니다.

Claude을 사용하여 Claude과 Codex 간의 대결을 심판합니다. 이 충돌을 인정합니다.⁸ 완화책은 구조적입니다: 블라인드 라벨링, 구조화된 차원, 그리고 Codex가 3번의 대결에서 이기고 여러 다른 대결에서 근접했다는 사실. 더 강력한 테스트는 동일한 대결을 Claude이 아닌 심판(Gemini 또는 GPT)을 통해 실행하고 점수 분포를 비교하는 것입니다. 아직 하지 않았습니다. 그때까지 8-3 점수 차이에는 별표가 붙어야 합니다: 심판과 한 참가자가 같은 모델 패밀리를 공유합니다.

참고문헌