Claude Code와 Codex를 활용한 코드 테스트 비교

2026년에 코딩 에이전트 주변에서 시간을 보내게 된다면, '여러 에이전트를 사용하라'는 조언을 접했을 것입니다. 하나는 계획하고, 하나는 구현하며, 하나는 검토합니다. 이 함의는 한 방향으로 흐릅니다. 두 에이전트가 하나보다 낫고, 만약 두 개가 좋다면 세 개는 더 좋을 것이라는 식입니다.

실제로는 그 주장을 다른 쪽에서 오라클(oracle)을 이용해 테스트한 사람이 거의 없습니다. 듣기에는 맞는 말처럼 들립니다. 왜냐하면 코드 리뷰는 인간 팀에게 효과적이기 때문입니다. 하지만 '리뷰어가 많으면 도움이 된다'와 '서로 다르게 실패하는 리뷰어가 도움이 된다'는 두 가지 다른 주장이며, 후자는 사실일 수 있지만 전자는 거짓일 수 있습니다.

RankEvolve: A Reliable Multi-Agent Auto-Research Harness for Evolving Ranking Models (Meta, 2026년 8월)은 명목상 추천 모델을 발전시키는 것에 대한 논문입니다. 제가 계속 읽었던 부분은 그 안에 숨겨진 벤치마크였습니다. ExecML은 해당 배포 과정에서 기록된 결함들을 각 코드베이스당 96개의 오라클 평가 과제로 변환하고, 다중 에이전트 업계가 대부분 건너뛴 질문을 던집니다. 즉, 두 개의 완전한 코딩 에이전트 _제품_을 조합하는 것이 동일한 예산을 하나에만 쓰는 것보다 실행 가능한 정확성(executable correctness)을 구매할 수 있게 해주는가입니다?

답은 '그렇다'입니다. 하지만 그 '예스'보다 더 중요한 조건이 붙습니다. HSTU 코드베이스의 96개 과제에서 Claude Code → Codex → Claude Code 조합은 62.5%의 실행 정확도를 기록한 반면, Claude Code → Claude Code → Claude Code 조합은 동일 예산 대비 45.8%에 그쳤습니다. 한편, Claude Code를 두 배로 사용해도 블라인드 best-of-N 기준선 대비 약 0% 증가에 그쳤습니다. 더 많은 리뷰와 다른 방식의 리뷰는 같은 것이 아닙니다.

이 글은 제가 작성한 하네스 엔지니어링 관련 마지막 게시물의 후속작입니다. 그 논문은 코딩 에이전트 하네스가 어떻게 구축되는지를 설명했습니다. 이번 글은 하나의 하네스를 사용하여 다른 것을 검사할 때 어떤 일이 발생하는지 측정합니다.

연구 과정

ExecML은 리더보드 항목이 아니라 벤치마크입니다. 설계는 다음과 같습니다:

두 개의 코드베이스입니다. 공개된 HSTU 추천기 구현체(Python/PyTorch)와 비추천기 학습 프레임워크인 LitGPT가 있습니다. HSTU가 주요 주장을 담고 있으며; LitGPT는 사전 지정된 전이 테스트입니다.
각 저장소별로 96개의 사설 태스크가 포함되어 있으며, 이는 12회 반복 배포 중에 기록된 실제 사고를 기반으로 시드되었습니다. 이 태스크들은 데이터 출처 및 유출(data provenance and leakage), 텐서 라우팅(tensor routing), 기울기 흐름(gradient flow), 학습/평가 모드(train/eval mode), 메트릭 의미론(metric semantics), 구성 와이어링(configuration wiring)의 여섯 가지 사고군을 균형 있게 다룹니다. 절반은 새로운 구현체이고, 나머지 절반은 의도적으로 주입된 결함을 수리하는 것입니다.
태스크별로 숨겨진 실행 가능한 오라클이 있습니다. 패치는 회귀 스위트(regression suite), 태스크별 행동 검사(task-specific behavioral checks), 과학적 안전 불변성(scientific-safety invariants, 유출, 데드 기울기, 잘못된 평가 의미론), 그리고 평가자 무결성 검사(evaluator-integrity checks)를 동시에 만족할 때만 통과합니다. 주요 종단점은 모든 또는 아무것도 아닌 실행 정확도(all-or-nothing execution accuracy, EA)입니다. 보조 종단점은 조용한 중요 결함 비율(silent critical-defect rate, CDR): 패치를 실행 가능하게 만들지만 과학적 결론을 무효화할 수 있는 오라클 확인 결함입니다.
여섯 가지 조건이 예산에 맞춰 매칭되었습니다. 모든 흐름은 고정된 리소스 엔벨로프에서 동일한 세 가지 역할, 노드별 제한, 도구 권한, 액션 상한선, 그리고 벽시계 시간 및 달러 상한선을 받습니다. 타임아웃과 초과는 실패로 간주되어 분모에 포함됩니다.
제품들은 고정되었습니다. Claude Code는 Claude Opus 4.8을 실행했고; Codex는 GPT-5.6을 실행했습니다. 둘 다 최대 추론 노력으로, 신선한 샌드박스에서, 무작위 순서로, 동일한 프롬프트와 도구 정책 하에 진행되었습니다.

다만 한 가지 주의할 점은 맨 위에 와야 할 것이지, 아래가 아닙니다: '매칭된 예산'이란 매칭된 관찰 가능한 추론 예산을 의미합니다. 독점 제품들은 제공자 측의 컴퓨팅 자원을 노출하지 않기 때문에 이는 FLOPs의 동등성을 의미하는 것은 아닙니다. 저자들이 이 점을 명확히 했으며, 저는 나중에 다시 언급하겠습니다.

주요 발견 사항

1. 이질적인 조합이 예산 균형에서 승리한다

여기에 논문의 핵심 내용이 있습니다. 조건당 세 가지 역할 모두가 동일한 엔벨로프에서 측정되었습니다:

조건 | HSTU 실행 정확도 ↑ | HSTU 무결점 결함 ↓ | LitGPT 실행 정확도 ↑ | 비용/작업
---|---|---|---|
Claude Code, 한 번 통과 (비교 불가한 저가 기준) | 22.9% | 35.4% | 20.8% | $0.41 |
...
승자 아래의 사다리를 보세요. 하나의 제품에 더 많은 비용을 지출하면 정확도가 22.9%에서 33.3%로 올라갑니다. 독립적인 후보군과 오라클-블라인드 선택 단계를 추가하면 43.8%에 도달합니다. 같은 제품의 검토 체인은 그 위에 거의 아무것도 추가하지 못하며, 아래 단계의 노이즈 안에 머뭅니다. 그런 다음 검토자를 다른 공급업체의 제품으로 교체하면 62.5%로 뛰어오릅니다.

가장 강력한 예산 매칭 기준선과 비교했을 때 쌍별 대비는 +16.7 포인트이며, 95% CI는 [6.6, 26.7]입니다. 무결점 결함률은 16.7%에서 10.4%로 떨어집니다. 그리고 비용은 $0.97 대비 작업당 $1.02입니다. 16.7 포인트의 격차에 대해 오차가 5센트 차이입니다.

2. 의무가 없는 영역에서도 재현되었다

LitGPT 열은 사전에 지정된 전이 테스트이며, 저자들은 결과가 무엇을 보여주든 미리 발표하기로 약속했습니다. 그 결과는 +12.5 포인트 (95% CI [3.0, 22.0]), p = 0.008을 보였습니다. 이는 추천 시스템과 아무 관련이 없는 코드베이스에서도 같은 방향으로 나타났습니다.

이는 명백한 반론을 무디게 만드는 발견입니다. 추천 시스템 코드는 특정한 형태를 가지며; HSTU는 특정한 실패 모드를 가집니다. 저자들은 Meta 출신입니다. 분명 효과가 그들의 주력 분야에 맞추어져 있을 것입니다. 사전에 등록된 독립 도메인 재현은 그 우려를 완전히 없애지는 못하지만, 대부분을 해소합니다.

3. 메커니즘은

Complementarity (D): A가 실패하고 B가 성공하는 확률 질량(probability mass). 이는 B가 '구제할 수 있는' 오류들입니다.
Realized gain (G): 검토 후 A의 패치에 축적된 이득. 구제된 오류에서 B의 검토가 야기한 손상을 뺀 값입니다.

만약 B의 오류가 A의 오류를 따라간다면, D는 아무리 전반적으로 B가 뛰어나더라도 작습니다: A가 눈이 먼 곳에서 B도 눈이 멀다(B is blind where A is blind). 두 측정 쌍이 보여주는 것이 바로 이것입니다:

Codex가 검토한 Claude Code: 오류 상관관계 $
ho = 0.21$, 상보성 $D = 0.18$, 실현 이득 $G = +0.06$.
Claude Code가 검토한 Claude Code: 오류 상관관계 $
ho = 0.58$, 상보성 $D = 0.10$, 실현 이득 $G allingdotseq 0$ (검토자 자신의 실수분을 제외하고).

서로 비슷하게 실패하는 두 제품은 '두 번째 의견'이 아닙니다. 그것은 같은 의견을 두 번 말한 것일 뿐입니다. 논문에서는 이러한 관계를 공식화하고 이를 통해 한 직선을 맞춥니다. 상보성에 대한 기울기는 $etâ₁ = 0.34$, 95% CI $[0.12, 0.56]$입니다. 하지만 직관적인 설명은 업무에 가져갈 만한 것입니다: '두 번째 에이전트가 첫 번째 에이전트가 통과하는 작업에서 실패할 때 조합(composition)이 이득을 가져다준다.'

4. 멋진 배포 토폴로지의 장점은 토폴로지가 아니라 예산이다

RankEvolve의 프로덕션 플로우는 '계획-병합(plan-merge)' 토폴로지입니다: 두 개의 계획 레인, 하나에는 Claude Code가, 다른 하나에는 Codex가 할당되어 있으며, 각 레인은 상대방의 최신 초안을 읽으면서 자신의 계획을 수정하고, 그 다음 병합하고, 검토-후속 조치-계획 이중 과정을 거칩니다. 이 시스템은 논문에서 최고의 원시 수치를 제시합니다: HSTU 정확도 70.8%, 무음 결함(silent defects) 6.2%, LitGPT에서 64.6%입니다.

하지만 이는 작업당 $2.40, 250개의 액션으로 운영됩니다. 동일한 예산에 맞추어 제한하면 Claude Code $ o$ Codex $ o$ Claude Code 순서가 정확히 일치합니다: 62.5%, 쌍별 차이(paired difference) 0.0, 95% CI $[-5.5, 5.5]$. 동시에 재실행된 비교군과 비교했을 때, 그 쌍별 향상분은 +8.3 포인트이지만, McNemar p = 0.077 및 CI $[-0.7, 17.3]$입니다. 통계적으로 구별할 수 없습니다.

저자들은 자신들의 결과에 따라 다음과 같이 결론 내립니다. 확증적인 가중치는 정교한 다이어그램이 아니라 단순한 조합 자체에 있습니다. 배포된 흐름(deployed flow)이 제공하는 것은 추가 비용을 지불하더라도 작업별 정확도이며, 논문은 방지된 결함이 훨씬 더 비싼 학습 실행을 보호하기 때문에 이러한 지출은 합리적이라고 주장합니다. 하지만 이것을 토폴로지(topology) 탓으로 돌리지 마십시오. 토폴로지는 포장재일 뿐입니다.

5. 순서가 중요하다 (Order matters)

반전된 쌍(reversed pair)이 여전히 모든 동종 조건(homogeneous condition)보다 높은 56.2%를 기록하지만, 정방향 방향(forward direction)보다 6.2 포인트 낮습니다. 어떤 제품이 구현하고 어떤 제품이 검토하는지가 결과의 일부입니다.

이것이 여러분에게 의미하는 바 (What This Means for You)

동일한 에이전트를 두 배로 만들지 마십시오. 이것이 실행 가능한 핵심(actionable core)입니다. 만약 여러분의 설정이 저자/검토자 패턴으로 동일한 제품 사본을 두 개 실행한다면, 논문의 수치는 여러분이 대부분 두 번째 청구서만 구매하고 있음을 시사합니다. 동일 제품 검토는 $
ho = 0.58$를 기록했으며, 도입된 오류로 인해 약 0에 가깝게 되었습니다. 다른 계보(lineage)에서 검토자를 선택하십시오. 다른 공급업체, 다른 하네스(harness), 다른 학습 코퍼스를 사용하십시오.

투입하기 전에 상호 보완성을 추정하십시오. 이것을 위해 작은 버전을 실행할 오라클이 필요하지 않습니다. 이미 올바른 결과를 알고 있는 20~30개의 작업을 가져와서, 여러분의 에이전트를 실행하고, 두 번째 에이전트의 검토를 실행한 다음, 두 가지를 계산하십시오. 검토자가 저자가 놓친 결함을 몇 개 잡아냈는지, 그리고 검토가 몇 개의 문제를 도입했는지입니다. 만약 첫 번째 숫자가 작다면, 이 조합은 여러분이 생각하는 것을 구매하고 있지 못한 것입니다.

예산 사다리(budget ladder)를 의도적으로 사용하십시오. 한 번의 실행 $
ightarrow$ 확장된 예산 $
ightarrow$ 블라인드 베스트-오브-N $
ightarrow$ 교차 제품 검토 체인입니다. 각 발판은 다른 실패 모드를 수정하고 다른 양의 비용이 듭니다. 논문의 데이터는 가장 큰 단일 점프(biggest single jump)가 동일한 것에 추가 실행을 하는 것에서 오는 것이 아니라, 검토자의 정체성을 전환하는 것에서 온다고 말합니다.

경제적 측면은 귀하에게 유리합니다. 이 조건들은 몇 시간의 GPU를 소모하는 트레이닝 실행을 제한하기 위해 작업당 약 1달러로 운영됩니다. 논문은 비율을 노골적으로 제시합니다: 방지된 사일런트 결함(silent defect)은 그것을 막는 추론 비용(inference spend)의 약 $10^3$배 가치가 있습니다. 만약 귀하가 두 번째 검토자 예산 라인에 대해 주장한다면, 그것이 바로 그 논거입니다.

만약 에이전트 제품을 구축한다면, 이것은 경쟁적인 영역(competitive surface)입니다. 다른 공급업체의 검토자가 이제 귀하 제품의 품질 스토리 일부가 되며, 인터페이스 뒤에 다른 에이전트를 호스팅할 수 있는 능력은 더 이상 호기심거리가 아니라 측정 가능한 것이 됩니다. 복합 제품들은 누가 어떤 것을 포착하는지에 대해 경쟁하고 있습니다.

제가 검증받고 싶은 것들

제 지난 게시물에서는 Pi의 문서를 열어 논문의 주장을 1차 출처와 비교했습니다. 그 움직임은 여기서 막힙니다: Claude Code, Codex, 그리고 오라클(oracle) 모두 독점적이거나 비공개입니다. 따라서 감사는 구현에서 주장으로 바뀝니다. HTML 버전을 처음부터 끝까지 읽고 난 후 제가 말할 수 있는 것은 다음과 같습니다:

헤드라인은 자체 간격(intervals)을 유지하지만, 그 간격은 넓습니다. 각 조건은 96개 작업에 대한 이진 결과이므로, 조건당은 대략 ±12포인트의 군집 간격(clustered intervals)을 의미합니다. 짝지어진(paired) +16.7이 인용하기에 맞는 숫자이며, 저자들이 그렇게 인용합니다. 구간 없이 결과를 의역하면 과장하는 것입니다.
'일치된 예산(Matched budget)'은 관찰 가능한 예산입니다. 동일한 범위, 동일한 프롬프트, 실패 시의 시간 초과를 의미합니다. 이것은 FLOP 동등성(FLOP equality)이 아니며, 저자들도 그렇게 말합니다.
오라클은 불완전합니다. 논문은 거짓 통과(false passes)를 줄이기 위해 변이 테스트(mutation testing)와 감사를 보고하는데, 이것이 올바른 완화책입니다. 오라클은 그것들을 제거할 수 없습니다. 패스가 된 패치는 '포착되지 않은 것'이지 '정확함이 증명된 것'이 아닙니다.
메커니즘은 인과적(causal)이기보다 예측적(predictive)입니다. 상보성 기울기(complementarity slope)의 간격은 0을 제외하며, 보유 데이터(held-out data)에서 단지 주변값(marginals-only model) 모델보다 우수하지만, 논문은 명시적으로 상보성을 높이는 것이 이득을 _야기한다_고 주장하지 않습니다. 그들의 말입니다.
깨끗한 결과와 지저분한 결과는 서로 다른 연구입니다.

HSTU 사례 연구는 프로토콜 게이트에서 인간 운영자가 참여했습니다. 62.5%의 생존율을 보이는 ExecML에는 인간이 개입하지 않았습니다. 이 둘을 혼합해서는 안 됩니다.

모델 핀은 시간이 지남에 따라 노후화될 것입니다. Claude Opus 4.8과 GPT-5.6이 이번 실험에서 사용된 제품입니다. 자신의 계열사 오류를 검토하는 데 더 나은 미래 모델이 등장한다면 격차는 줄어들 것입니다. 이 방법론은 견고하지만, 수치는 특정 시점의 스냅샷일 뿐입니다.
제가 원하는 재현은 다음과 같습니다: 저자(author), 리뷰어(reviewer) 또는 둘 다로 열린 하네스(open harnesses)를 사용하여 쌍을 다시 실행하는 것입니다. 제품들이 두 공급업체 스택보다 더 많은 DNA를 공유할 때도 효과가 유지되는지 알고 싶습니다.

한계점 (Limitations)

논문의 자체 섹션에서 발췌한 것으로, 평소보다 솔직합니다. 증거 기반은 두 개의 Python/PyTorch 코드베이스이므로 도메인 간 전이가 확립되지 않았습니다. 제품들은 블랙박스(black boxes)라서 컴퓨팅 동등성(compute equivalence)을 보여줄 수 없습니다. 오라클(Oracles)은 거짓 통과(false passes)를 줄이지만 제거하지는 못합니다. 상보성(Complementarity)은 예측적이지 인과적이지 않습니다. 지식 계층(knowledge layer)은 배포 중에 활성화되었지만 절제(ablated)된 적이 없어 기여도를 측정할 수 없습니다. 크로스 데이터셋 전이 결과는 단일 실행입니다. 그리고 체크포인트 포킹(checkpoint forking)은 반복들이 서로 얼마나 멀리 벗어나는지를 과소평가합니다.