교차 모델 LLM 코드 리뷰: Claude로 Codex를 리뷰할 것인가, 그 반대인가?
Digest: 개발자들이 이미 코딩 에이전트 두 대를 “하나는 쓰고 하나는 검토한다”는 방식으로 함께 쓰고 있지만, 그 두 번째 패스가 비용과 지연을 감당할 만큼 값어치를 하는지, 그리고 짝의 순서가 결과를 바꾸는지는 리더보드가 답하지 않는다는 것이 이 논문의 문제의식이다. 핵심 통찰은 리뷰의 가치가 “패스를 하나 더 붙였다”는 사실이 아니라 리뷰어가 초안 작성자보다 상대적으로 강한가에 묶여 있다는 점이다. 방법은 2025년 이후 공개된 LiveCodeBench hard·medium 과제 116개(complete case)를 Claude Opus 4.7(Claude Code 2.1.50)과 Codex GPT-5.5(Codex CLI)로 6개 조건 — solo 2종(A, O), 교차 2종(AO, OA), 동일모델 2종(AA, OO) — 에 걸쳐 돌리되, 리뷰어에게는 문제와 초안만 주고 테스트 실행·히든 테스트 열람을 금지해 pre-CI static review를 근사한 것이다(§3). 핵심 수치로 OA(Codex 초안 → Claude 리뷰)는 71.6%→89.7%(+18.1pp, p_BH = .0010)로 오르는 반면 AO(Claude 초안 → Codex 리뷰)는 91.4%→82.8%(−8.6pp, p_BH = .0456)로 떨어지고, AA는 91.4%에서 변화가 없다(Table 2·4). 과제 단위로 보면 OA는 26건을 고치고 5건을 망가뜨려 순 +21인 반면 AO는 3건을 고치고 13건을 망가뜨려 순 −10이다(Figure 1). 함의는 실무 규칙으로 압축된다 — Codex가 초안을 쓰면 리뷰를 붙이고(정확도 우선이면 Claude 리뷰어, 지연 예산 70초 미만이면 Codex 자기리뷰), Claude가 초안을 쓰면 그대로 제출하라. 한계는 AO vs OA 직접 대조가 BH 보정 후 유의하지 않고(p_BH = .1444), 표본이 116과제·모델 쌍 1개·단일 런이며, 두 모델의 baseline 자체가 달라 “리뷰 방향의 효과”와 “baseline 격차의 효과”를 분리하지 못한다는 점이다.
먼저 이해하기
이 논문은 새 모델이나 새 벤치마크를 만드는 연구가 아니라, 이미 손에 있는 코딩 에이전트 두 대를 어떤 순서로 배치해야 하는가를 통제 실험으로 재는 연구다. 한 모델이 코드를 쓰고 다른 모델이 그 코드를 검토해 최종본을 내는 2단계 파이프라인에서, “누가 쓰고 누가 검토하느냐”만 바꿔 정답률·비용·지연을 비교한다.
writer(작성자): 문제 설명과 starter code만 보고 Python 해답을 처음부터 작성하는 모델.reviewer(리뷰어): 같은 문제 설명에 더해 writer의 초안을 받아, 버그·엣지케이스 누락·비효율을 코드만 읽고 찾아낸 뒤 최종 프로그램을 직접 출력하는 모델. 코멘트를 다는 게 아니라 제출본을 다시 쓴다.static review(정적 리뷰): 리뷰어가 코드를 실행하거나 테스트 러너를 호출할 수 없는 설정. CI가 돌기 전에 사람이 눈으로 보는 검토 단계에 해당한다.SID: 해당 조건의 pass rate에서 그 writer의 solo baseline pass rate를 뺀 값. 즉 “리뷰가 순수하게 더한 것”.
설정 규칙은 단순하고 빡세다. 과제는 LiveCodeBench의 hard·medium 티어만 쓴다(easy는 두 모델 모두 사실상 만점이라 제외). 모든 문제는 2025년 이후 공개분이라 두 모델의 학습 컷오프 이후이며, 따라서 정답 암기 가능성이 통제된다. writer와 reviewer 프롬프트는 모델·조건에 관계없이 고정된 템플릿이고, 두 프롬프트 모두 <solution> 태그 안에 Python 코드만 내놓게 강제해 동일한 파서·채점 파이프라인을 타게 만든다. 모든 턴은 벤더의 high reasoning effort 설정을 쓰고, 턴당 CLI 타임아웃은 3,000초, 실패 시 타임아웃을 두 배로 늘려 1회 재시도, 그래도 실패하면 최대 4회까지 재시도한다.
분석은 complete case 기준이다. 6개 조건 전부가 유효한 산출물(CLI 에러·타임아웃·파싱 실패·예산 초과 없음, 최종 프로그램 비어 있지 않음)을 낸 과제만 남겨 116개가 되었고, 같은 116개 과제 위에서 조건끼리 짝지어 비교한다. 짝 비교이므로 McNemar 검정을 쓰고, 여러 대조를 동시에 하므로 Benjamini-Hochberg(BH) 보정을 건다.
왜 중요한가: 리더보드는 모델을 단독으로 줄 세울 뿐, “두 대를 어떤 역할로 붙일까”에는 답하지 않는다. 그런데 이 논문의 결과는 같은 두 모델을 쓰더라도 순서에 따라 89.7%와 82.8%로 갈린다는 것을 보여준다 — 6.9pp 차이는 모델 하나를 통째로 갈아치우는 수준의 격차다. 게다가 잘못된 방향(AO)은 정확도를 8.6pp 잃으면서 비용은 과제당 0.382로, 지연은 86.2초 → 118.0초로 늘린다. 즉 “리뷰어를 하나 더 붙이면 안전하다”는 직관이 특정 방향에서는 정확히 반대로 작동한다.
먼저 알아둘 용어 표
| 원 용어 | 쉬운 설명 |
|---|---|
| A / O | Anthropic Claude Opus 4.7 / OpenAI Codex GPT-5.5의 축약 라벨 |
| AO, OA, AA, OO | writer→reviewer 순서 두 글자 라벨. OA = Codex가 쓰고 Claude가 리뷰 |
| pass rate | 히든 테스트를 통과한 과제 비율 |
| SID | 리뷰 조건 pass rate − 해당 writer의 solo baseline pass rate |
| fix / regression | 리뷰가 실패 초안을 살린 건수 / 통과 초안을 망가뜨린 건수 |
| McNemar test | 같은 과제 집합에서 두 조건의 0/1 결과가 엇갈린 항목만 세는 짝 비교 검정 |
| BH correction | 여러 대조를 동시에 검정할 때 위양성(false discovery)을 통제하는 p값 보정 |
| complete case | 6개 조건 모두 유효 산출물을 낸 과제만 남기는 분석 방식 |
섹션별 요약
Abstract
Claude Opus 4.7과 Codex GPT-5.5를 116개의 최신 LiveCodeBench hard·medium 과제에 대해 6개 조건(solo 2, 교차 2, 동일모델 2)으로 통제 실험한다. 리뷰어는 문제와 초안을 보지만 테스트를 실행할 수 없어 코드 리뷰 단계를 근사한다. Claude 리뷰는 Codex 초안을 71.6%→89.7%로 올리고(p_BH = .001), Codex 자기리뷰는 84.5%로 올린다(p_BH = .022). 반대 방향은 손해다 — Codex가 Claude 초안을 리뷰하면 91.4%→82.8%로 떨어지고(p_BH = .046), Claude 자기리뷰는 91.4%에서 변화가 없다. 결론: 유용한 짝짓기는 비대칭이며, Claude로 Codex를 리뷰하되 그 반대는 하지 말라.
왜 이 연구를 하는가?
오늘날 코드 생성 리더보드는 모델을 고립된 단독 조건으로 순위 매긴다. 그래서 (1) 가진 두 에이전트 중 누가 쓰고 누가 검토해야 하는지, (2) 두 번째 패스가 비용값을 하는지, (3) 어느 방향으로 짝을 돌려야 정확도가 최대인지에 답하지 못한다. 저자들은 이를 writer와 reviewer 사이의 역할 배정(role assignment) 문제로 정식화하고, 실행 피드백·반복·과거 시도 기억을 모두 제거해 측정된 효과가 “리뷰 개입 그 자체”에 귀속되도록 설계한다. 연구 질문은 네 개다 — RQ1 리뷰 패스가 전체 정확도를 올리는가, RQ2 그 가치가 누가 쓰고 누가 읽느냐에 의존하는가, RQ3 리뷰어는 언제 고치고 언제 망가뜨리는가, RQ4 정확도 이득이 추가 비용·지연을 정당화하는가.
Introduction
기존 연구 대비 위치는 세 갈래로 정리된다. 첫째, self-refinement 계열(Self-Refine, Reflexion, Self-Debug)은 한 모델이 자기 출력을 피드백으로 개선하는 설정이며, Olausson et al.은 self-repair의 이득이 “복구 모델이 초안 모델보다 의미 있게 강한가”에 달려 있음을 보였다. 이 논문의 동일모델 조건(AA, OO)은 그 발견을 실행 피드백을 제거한 채 재현한다. 둘째, 멀티에이전트 계열(ChatDev, MetaGPT, AgentCoder, CodeCoR, multi-agent debate)은 역할 분담이나 상호 비판을 다루지만 생성 테스트나 실행 피드백을 함께 쓴다 — 이 논문은 writer 1명, static reviewer 1명, 생성 테스트 없음, 실행 피드백 없음으로 축소한다. 셋째, LLM 리뷰어 연구(CodeReviewQA, requirement conformance overcorrection)는 “그럴듯한 코멘트를 내는가”를 넘어 최종 제출 프로그램이 실제로 더 맞는가를 평가 타깃으로 삼아야 한다고 지적했고, 이 논문이 그 기준을 그대로 채택한다.
Methods
- 과제: LiveCodeBench hard·medium, 2025년 이후 공개분. 단일 파일 Python, 문제 설명 + 선택적 starter code + 히든 테스트 스위트. easy 티어는 제외.
- 프롬프트(Listing 1·2): writer는 “정확성 우선, 그다음 성능”,
<solution>태그 안 완전한 실행 가능 코드만 출력. reviewer는 같은 문제 + writer 산출물을 받고 “버그·잘못된 로직·누락된 엣지케이스·비효율을 찾아 최종 수정본(원본이 맞으면 원본 그대로)을 내되, 실행·테스트 금지, 코드 검사만으로 추론”하도록 지시받는다. 설명 텍스트 금지. - 조건 6종(Table 1): A(Claude solo), O(Codex solo), AO(Claude 작성 → Codex 리뷰), OA(Codex 작성 → Claude 리뷰), AA, OO. 라벨은 writer-then-reviewer 순서.
- 실행 환경:
claude-opus-4-7via Claude Code 2.1.50,gpt-5.5via Codex CLI, 둘 다reasoning.effort = high. 오케스트레이션·파싱·wall-clock 측정은 로컬 MacBook Air(Apple M4, 16GB). - 기록: raw output, 최종 산출물, 프롬프트 해시(SHA-256), CLI 버전, 타임스탬프, 파싱/재시도 메타데이터, 토큰 수, 비용, 평가 결과. 비용은 토큰 수 × 공식 가격표.
- 지표: pass rate
PR_c = (1/|T_c|) Σ y_tc,SID_c = PR_c − PR_b(w), 과제당 평균 비용·지연, reviewer fix(baseline 실패 → 리뷰 후 통과)와 regression(baseline 통과 → 리뷰 후 실패). - 통계: pass rate에 부트스트랩 95% CI. 짝 비교는 정확 양측 McNemar(불일치 항목 수가
Binom(n10+n01, 1/2)), 다중 비교는 BH 보정.
발견 (Findings)
- RQ1의 답은 조건부다 — “리뷰가 도움이 되는가”는 누가 초안을 썼는가에 따라 뒤집힌다.
- Codex 초안에 대해서는 두 리뷰어 모두 BH 보정 후 유의하게 도움이 된다(OA +18.1pp, OO +12.9pp).
- Claude 초안에 대해서는 자기리뷰가 무효(±0pp)이고 Codex 교차 리뷰는 유의하게 해롭다(−8.6pp).
- 리뷰어의 기여는 “패스를 하나 더했다”가 아니라 상대적 역량에 의해 상한이 정해진다. OA는 Codex solo 대비 순 +21 통과(104 vs 83)로 Claude solo(106)와 단 2건 차이까지 따라붙는다.
- AA vs AO 대조도 유의하다(p_BH = .0323) — writer가 이미 둘 중 강한 쪽이어도 리뷰어 선택은 여전히 중요하다.
Results
- Table 2(전체 조건): A .914 / O .716 / AO .828 / OA .897 / AA .914 / OO .845. regression rate는 AO .112로 최고, AA .026으로 최저.
- Table 3(writer × reviewer 행렬): Claude를 리뷰어로 두면 항상 도움이 되거나 중립(+18.1pp, ±0pp). Codex를 리뷰어로 두면 자기 초안일 때만 도움이 된다(+12.9pp vs −8.6pp).
- Table 4(McNemar): OA vs O 26/5, p = .0002, p_BH = .0010 / OO vs O 21/6, .0059 → .0222 / AO vs A 3/13, .0213 → .0456 / AA vs A 3/3, 1.0000 → 1.0000 / AA vs AO 12/2, .0129 → .0323. 직접 대조 AO vs OA는 5/13, p = .0963, p_BH = .1444로 보정 후 유의하지 않다.
- Figure 1(fix/regression 분해): OA +26/−5(순 +21), OO +21/−6(순 +15), AO +3/−13(순 −10), AA +3/−3(노이즈 수준).
- Table 5(수작업 사례): 고침 사례 — 3562(OA: DP 해답을 감싼 코드 펜스를 제거해 평가기가 파싱하게 함), abc394_f(AO의 드문 성공: 잘못된 연결요소 세기를 트리 DP로 교체), 3688(OO: 세그먼트 트리 상태에서 지워진 값을 복원하되 초안 인터페이스는 유지). 망가뜨린 사례 — 3717(AO: 통과하던 sorted-list 중앙값 윈도를 힙 기반으로 재작성해 실패), arc191_a(AA: 통과하던 해답의 경계 처리 변경), abc389_f(OO: 엣지케이스를 지키던 세그먼트 트리 범위 가드를 삭제).
- RQ4 비용·지연(Figure 2): Codex writer 기준 두 화살표 모두 우상향 — OO는 +12.9pp를 과제당 추가 0.25·74초에 산다. Claude writer 기준은 둘 다 값어치가 없다 — A→AA는 0.16·32초를 쓰고 8.6pp 손실. Claude solo가 이 벤치마크의 Pareto frontier에 있고, 어떤 리뷰 조건도 그것을 넘지 못한다.
Discussion
이론적 의의
저자들의 해석은 “리뷰의 여지(margin)는 writer가 첫 패스에서 이미 얼마나 스스로 검증했는가의 잔여분”이라는 것이다. high reasoning effort의 Claude Opus 4.7은 첫 패스에서 이미 static reviewer가 찾을 수 있는 오류 대부분을 잡아버려 두 번째 패스에 남는 신호가 거의 없고, Codex GPT-5.5는 잡을 수 있는 잔여 오류를 더 많이 남긴다. 지연 수치가 이 읽기를 뒷받침한다 — Claude solo 86.2초 vs Codex solo 38.5초로, Claude가 첫 패스 자기검증에 더 많은 연산을 쓴다는 것과 일관된다. 그래서 AA는 더할 게 없고 OO는 실질적 여지가 있다.
두 번째 해석 축은 개입의 양이 아니라 방식이다. 저자들이 사례를 눈으로 훑은 결과, OA와 AO 리뷰어는 개입 빈도보다 개입 스타일에서 갈렸다. Codex 리뷰어는 확신이 없을 때 writer의 자료구조를 버리고 처음부터 다시 쓰는 경향이 있고(3717 힙 재작성, abc389_f 가드 삭제), Claude 리뷰어는 writer의 인터페이스를 유지한 채 국소 불변식 하나를 고치는 경향이 있다(3688 세그먼트 트리 수정). 다만 저자들은 rewrite 빈도를 직접 측정하지 않았으므로 이는 정량 주장이 아니라 해석적 패턴이라고 명시한다.
Discussion Points
- 프롬프트 구조 자체가 결과를 편향시킨다 — 이 설계에서 리뷰어는 항상 최종 프로그램을 출력해야 하므로 “개입할 것인가?”라는 별도 결정 지점이 없다. AO의 11.2% regression rate는 Codex가 이 rewrite 여지를 과다 사용한 결과와 일관된다. “먼저 개입 여부를 판단하고 그다음에만 최종본을 쓰라”는 2단 프롬프트가 자연스러운 후속이다.
- 두 모델의 baseline pass rate가 애초에 다르기 때문에(91.4% vs 71.6%), 이 설계는 “리뷰 방향의 효과”와 “baseline 격차의 효과”를 완전히 분리하지 못한다. 저자들 스스로 교차 비교를 인과 주장이 아니라 역할 배정에 대한 기술적(descriptive) 관찰로 읽으라고 못 박는다.
- static 설정은 pre-CI 리뷰에 가깝지만, 샌드박스를 가진 도구 사용 에이전트가 할 수 있는 일을 과소평가한다. 반대로 이 제약이 있어야 측정 효과를 리뷰 패스에 귀속시킬 수 있다는 트레이드오프.
- 자기완결형 Python 문제·히든 테스트라는 과제 형태는 정확도 측정을 정밀하게 만드는 대신 API 호환성·빌드 통합·스타일 일관성·보안·다중 파일 유지보수성을 전혀 다루지 못한다.
- 리뷰를 “최종 프로그램의 정확성”만으로 채점한다 — 실무 코드 리뷰가 산출하는 설계 피드백·가독성 코멘트·보안 관찰은 측정 밖이다.
실험 결과 상세
Table 2 — 6개 조건의 pooled complete-case 지표 (116 과제)
| 조건 | Pass | Pass Rate [95% CI] | SID | Cost/task | Latency | Reg. rate |
|---|---|---|---|---|---|---|
| A: Claude Opus 4.7 solo | 106 | .914 [.862, .957] | – | $.226 | 86.2s | – |
| O: Codex GPT-5.5 solo | 83 | .716 [.629, .793] | – | $.190 | 38.5s | – |
| AO: Claude 작성 → Codex 리뷰 | 96 | .828 [.759, .897] | −.086 | $.382 | 118.0s | .112 |
| OA: Codex 작성 → Claude 리뷰 | 104 | .897 [.836, .948] | +.181 | $.443 | 112.4s | .043 |
| AA: Claude 작성 → Claude 리뷰 | 106 | .914 [.862, .957] | +.000 | $.389 | 135.8s | .026 |
| OO: Codex 작성 → Codex 리뷰 | 98 | .845 [.776, .905] | +.129 | $.312 | 67.9s | .052 |
Table 3 — writer × reviewer 행렬 (괄호는 해당 writer의 solo 대비 델타)
| Writer \ Reviewer | Claude | Codex |
|---|---|---|
| Claude (solo 91.4%) | 91.4% (±0 pp) | 82.8% (−8.6 pp) |
| Codex (solo 71.6%) | 89.7% (+18.1 pp) | 84.5% (+12.9 pp) |
Table 4 + Figure 1 — 짝 비교 검정과 fix/regression 분해
| 대조 | First only | Second only | p | p_BH | 판정 |
|---|---|---|---|---|---|
| OA vs O | 26 | 5 | .0002 | .0010 | 유의(순 +21) |
| OO vs O | 21 | 6 | .0059 | .0222 | 유의(순 +15) |
| AO vs A | 3 | 13 | .0213 | .0456 | 유의하게 악화(순 −10) |
| AA vs A | 3 | 3 | 1.0000 | 1.0000 | 무효(노이즈 수준) |
| AA vs AO | 12 | 2 | .0129 | .0323 | 유의(리뷰어 선택이 중요) |
| AO vs OA (직접 대조) | 5 | 13 | .0963 | .1444 | 보정 후 유의하지 않음 |
Figure 2 — 리뷰 한 패스가 사는 것과 지불하는 것
| 화살표 | 정확도 변화 | 추가 비용/과제 | 추가 지연/과제 | 순 fix당 비용 |
|---|---|---|---|---|
| O → OA | +18.1 pp | +$0.25 | +74s | ≈ $1.40 |
| O → OO | +12.9 pp | +$0.12 | +29s | ≈ $0.95 |
| A → AA | ±0 pp | +$0.16 (비용 +72%) | +49.6s (지연 +58%) | 해당 없음 |
| A → AO | −8.6 pp | +$0.16 | +32s | 해당 없음(순 −10) |
프레임워크 다이어그램
flowchart TD A["LiveCodeBench hard+medium<br/>2025년 이후 공개, complete case 116과제"] --> B["Writer 프롬프트<br/>문제 + starter code<br/>solution 태그 안 Python만"] B --> C["Writer 초안<br/>Claude Opus 4.7 또는 Codex GPT-5.5<br/>reasoning effort = high"] C --> D{"조건 분기"} D -->|"solo"| E["초안을 그대로 제출<br/>조건 A, O"] D -->|"reviewed"| F["Reviewer 프롬프트<br/>문제 + starter code + 초안<br/>실행·테스트 금지, 코드 검사만"] F --> G["Reviewer 최종 프로그램<br/>조건 AO, OA, AA, OO"] E --> H["동일 태그 파서로 추출"] G --> H H --> I["LiveCodeBench 히든 테스트 평가"] I --> J["Pass rate + 부트스트랩 95% CI"] I --> K["fix / regression 카운트"] I --> L["토큰 기반 비용 + wall-clock 지연"] J --> M["McNemar 짝 비교 + BH 보정"] K --> M M --> N["역할 배정 권고<br/>Codex 초안이면 리뷰 붙이기<br/>Claude 초안이면 그대로 제출"] L --> N
재현성 및 신뢰도 평가
종합등급: Evidence B / Reproducibility B
- 근거(Evidence B): 같은 116개 과제 위의 완전 교차 6조건 설계, solo baseline 2종, 부트스트랩 95% CI, 짝 비교 McNemar + BH 다중비교 보정, fix/regression 분해, 비용·지연 동시 보고까지 갖춘 통제 실험이라 주장 대부분이 데이터로 뒷받침된다. 다만 (1) 조건당 과제당 단일 런이라 LLM 출력의 실행 간 분산이 CI에 반영되지 않고, (2) 표본이 116과제·모델 쌍 1개로 좁으며, (3) 핵심 서사인 “방향 비대칭”의 직접 대조(AO vs OA)가 BH 보정 후 p_BH = .1444로 유의하지 않아 결론이 per-writer 대조의 조합에 의존한다. 저자들도 “안정적 순위를 정하는 연구가 아니라 1차 진단(first diagnostic)“이라고 명시한다. 따라서 A는 아니다.
- 근거(Reproducibility B): 공개 artifact(https://github.com/shawnzxiang/cross-model-review-code)에 전체 실험 설정, 프롬프트 파일, raw output, 프롬프트 SHA-256 해시, CLI 버전, 타이밍·토큰 필드, 분석 스크립트가 들어 있고, 6조건 116과제 전체 재현 비용까지 약 1.94) 수준으로 명시돼 있어 재현 경로가 예외적으로 투명하다. 반면 대상이 폐쇄형 벤더 모델(
claude-opus-4-7/gpt-5.5)이고 Claude Code 2.1.50·Codex CLI 버전에 묶여 있어, 벤더가 모델을 갱신하면 수치 재현이 불가능하다. 저자들 스스로 프롬프트 문구·포맷 지시에 결과가 민감하며 비용은 시점 기준 추정치라고 인정한다.
주장별 신뢰도
- “Claude 리뷰가 Codex 초안을 71.6%→89.7%로 올린다” — 신뢰도 높음(Table 2·4, 26 fix / 5 regression, p_BH = .0010으로 이 논문에서 가장 강한 효과).
- “Codex 리뷰가 Claude 초안을 91.4%→82.8%로 떨어뜨린다” — 신뢰도 중상(p_BH = .0456으로 유의하나 임계값에 근접하고, 3 fix / 13 regression이라는 소수 사건 기반).
- “리뷰 방향은 비대칭이다(OA는 이득, AO는 손해)” — 신뢰도 중간. 두 per-writer 대조는 각각 유의하지만 직접 대조 AO vs OA는 p_BH = .1444로 살아남지 못했고, 두 모델의 baseline 격차와 방향 효과가 교란된다.
- “Claude 첫 패스의 자기검증이 더 무거워서 리뷰 여지가 없다” — 신뢰도 낮음. 지연 86.2s vs 38.5s라는 간접 증거에 기댄 해석이며, 내부 검증량을 직접 측정하지 않았다.
- “Codex 리뷰어는 재작성 성향, Claude 리뷰어는 국소 수리 성향” — 신뢰도 낮음. 저자들이 rewrite 빈도를 측정하지 않았다고 명시했고 Table 5는 코딩된 분류체계가 아닌 예시 6건이다.
관련 연구 비교 매트릭스
| 논문/설정 | 두 번째 패스의 주체 | 실행 피드백 | 반복 횟수 | 평가 타깃 | 본 논문과의 차이 |
|---|---|---|---|---|---|
| 본 논문 (Cross-Model Review) | 다른 모델 또는 같은 모델 | 없음(static) | 1회 | 최종 프로그램의 pass rate | 역할 배정 방향을 조작 변인으로 삼음 |
| Self-Refine | 같은 모델(자기 피드백) | 없음 | 다회 | 다양한 과제 품질 | 모델 다양성 축이 없음 |
| Reflexion | 같은 모델(언어적 자기반성 + 메모리) | 있음 | 다회 | 과제 성공률 | 메모리·반복이 효과에 섞임 |
| Self-Debug / Olausson self-repair | 같은 또는 더 강한 모델 | 있음(실행 트레이스) | 다회 | HumanEval/APPS 정확도 | 실행 피드백이 개선의 주요 동력 |
| LiveCodeBench self-repair 시나리오 | 같은 모델 | 있음 | 1회 | 시나리오별 점수 | 벤치마크 제공자 관점, 짝짓기 미탐색 |
원자적 인사이트 (Zettelkasten)
- 리뷰 패스의 가치는 “패스를 하나 더 붙였다”가 아니라 리뷰어와 작성자의 상대적 역량 격차에서 나온다. 같은 두 모델, 같은 프롬프트, 같은 116개 과제인데 순서만 뒤집으면 +18.1pp와 −8.6pp로 갈린다. 파이프라인 설계에서 “검증 단계 추가”는 무조건 안전한 개입이 아니다.
- 첫 패스에서 이미 자기검증을 많이 한 모델에게는 두 번째 패스가 줄 신호가 남아 있지 않다. Claude solo가 과제당 86.2초를 쓰고 91.4%에 도달한 뒤 자기리뷰(AA)를 붙이면 비용 +72%·지연 +58%를 쓰고 정확도는 정확히 0pp 오른다 — reasoning effort로 이미 산 것을 두 번 사는 셈이다.
- “최종본을 반드시 출력하라”는 리뷰어 프롬프트는 개입 편향을 구조적으로 심는다. 개입 여부를 결정할 지점이 없으면 리뷰어는 확신이 없을 때 재작성으로 도피하고, AO의 11.2% regression rate가 그 비용이다. 리뷰 에이전트 설계에서 “고칠까 말까”는 “어떻게 고칠까”보다 먼저 나와야 하는 결정이다.
- 평균 pass rate는 서로 상쇄되는 두 행동을 감춘다. OA(+26/−5)와 AO(+3/−13)는 fix와 regression을 따로 세야만 구별된다. 리뷰·수정 계열 시스템은 순 델타뿐 아니라 fix/regression을 분해해 보고해야 한다.
- 비용을 정확도 델타가 아니라 “순 fix 1건당 비용”으로 환산하면 의사결정이 단순해진다. OA는 순 fix당 약 0.95, AO는 순 fix가 음수라 계산 자체가 성립하지 않는다.
핵심 용어 정리
| 용어 | 정의 |
|---|---|
| Cross-model review | 초안을 쓴 모델과 다른 모델이 그 초안을 검토해 최종본을 내는 2단계 파이프라인 |
| Static review | 리뷰어가 코드를 실행하거나 테스트 결과를 볼 수 없이 코드 검사만으로 판단하는 리뷰(pre-CI 검토에 대응) |
| Role assignment | 가진 모델들 중 누구를 writer로, 누구를 reviewer로 배치할지 결정하는 문제 |
| SID | Solo Improvement Delta. 리뷰 조건 pass rate에서 해당 writer의 solo baseline을 뺀 값 |
| Reviewer fix / regression | 초안이 실패했는데 리뷰 후 통과한 과제 / 초안이 통과했는데 리뷰 후 실패한 과제 |
| McNemar test | 같은 과제 집합에서 두 조건의 결과가 엇갈린 항목만 세어 짝 비교하는 이항 검정 |
| BH correction | Benjamini-Hochberg 절차. 다중 검정에서 false discovery rate를 통제하는 p값 보정 |
| Complete case analysis | 모든 조건이 유효한 산출물을 낸 항목만 남겨 조건 간 짝 비교 가능성을 보장하는 분석 |
| Pareto frontier | 정확도와 비용·지연 두 축 모두에서 다른 어떤 조건에도 지배되지 않는 지점 |
관련 연구
- LiveCodeBench - Holistic and Contamination Free Evaluation of Large Language Models for Code — 이 실험의 과제 소스이자 오염 통제 근거(2025년 이후 공개 문제만 사용). LiveCodeBench 자체의 self-repair 시나리오는 짝짓기 방향을 다루지 않는다.
- Self-Refine - Iterative Refinement with Self-Feedback — 같은 모델의 자기 피드백 반복 개선. 본 논문의 AA/OO 조건이 실행 피드백과 반복을 제거한 극단 버전에 해당한다.
- Reflexion - Language Agents with Verbal Reinforcement Learning — 언어적 자기반성 + 메모리로 재시도하는 계열. 본 논문은 메모리·반복·도구 사용을 모두 제거해 리뷰 개입 자체를 분리한다.
- Rethinking Failure Attribution in Multi-Agent Systems - A Multi-Perspective Benchmark and Evaluation — 같은 AgenticSE @ KDD 2026 워크숍. 다중 에이전트 파이프라인에서 “어느 단계가 망쳤는가”를 귀속하는 문제로, 본 논문의 fix/regression 분해와 문제의식이 맞닿는다.
- Terminal-Bench - Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces — 도구 사용·실행 피드백이 허용된 현실적 에이전트 평가. 본 논문이 명시한 한계(“샌드박스를 가진 도구 사용 에이전트의 상한을 과소평가한다”)의 대조군 역할.
태그
논문 LLM에이전트 코드리뷰 에이전틱코딩 LiveCodeBench 교차모델 AgenticSE KDD2026
BibTeX
@inproceedings{xiang2026crossmodel,
title = {Cross-Model {LLM} Code Review: Should you use {Claude} to review {Codex} or vice versa?},
author = {Xiang, Zuodong and Zhang, Yike and Zhang, YueMing and Xu, Hailu},
booktitle = {KDD 2026 Workshop on Agentic Software Engineering (AgenticSE)},
year = {2026},
url = {https://openreview.net/forum?id=Fh32FqhIfG}
}