LLM의 코드 merge rate는 정말 개선되고 있을까?

TL;DR Highlight

METR의 SWE-bench 재분석은 LLM의 코드 품질(PR merge 가능 여부)이 2025년 초 이후 1년 넘게 개선되지 않았을 가능성을 통계적으로 더 높은 확률로 시사한다.

Who Should Read

LLM 코딩 도구(Claude Code, Codex 등)를 실무에 도입했거나 도입을 검토 중인 개발자, 또는 AI 성능 벤치마크 해석에 관심 있는 개발자.

Core Mechanics

METR이 발표한 연구에서 LLM이 코드를 작성할 때 '테스트 통과'와 '실제 maintainer가 merge할 수 있는 품질'이라는 두 기준으로 나눠 성능을 비교했다. 그 결과 LLM이 50% 성공하는 작업 소요 시간이 테스트 통과 기준으로는 50분이지만, merge 가능한 품질 기준으로는 고작 8분으로 뚝 떨어진다.
이 글의 저자는 METR 데이터에서 merge rate(실제 PR이 merge될 비율)만 따로 추출해 분석했는데, METR이 제안한 '완만한 상승 추세' 보다 '2024년 말 한 번의 도약 후 정체'를 나타내는 계단 함수나 아예 일정한 상수 함수가 데이터를 더 잘 설명한다는 결론을 냈다.
통계적으로 검증하기 위해 leave-one-out 교차검증(LOO-CV)과 Brier score(예측 오차의 제곱 평균, 낮을수록 좋음)를 사용했다. 결과는 '완만한 상승 직선' 0.0129, '계단 함수' 0.0117, '완전 상수 함수' 0.0100으로, 아무 변화 없다고 가정하는 모델이 가장 예측력이 높았다.
즉 데이터가 시사하는 것은 2025년 초 이후 LLM의 실질적인 프로그래밍 능력(merge 가능한 품질)은 개선되지 않았다는 것이다. 저자는 이를 두고 '1년 이상 발전이 없었는데 왜 아무도 이걸 이야기하지 않냐'고 지적한다.
저자는 포스트스크립텀에서 Anthropic과 Google의 최신 모델(Sonnet 4.5 이후)에서 또 한 번의 도약이 있었다는 주장이 있지만, 그것을 merge rate 기준으로 엄밀하게 측정한 데이터가 없다고 말한다. 2025년 내내 '발전했다'는 주장이 있었지만 데이터는 그렇지 않았으므로, 같은 패턴이 반복될 수 있다고 경고한다.
이 분석의 한계도 있다. 데이터 포인트가 매우 적고, GPT-5 같은 모델은 단 하나의 데이터 포인트만 있어 신뢰성이 낮다. 또한 Sonnet 3.7 → Opus 4.0 → Sonnet 4.5 구간에서는 실제 향상이 보이는데 그래프 설계 방식 때문에 이게 희석됐다는 반론도 있다.

Evidence

한 댓글에서 'Sonnet 3.7 → Opus 4.0 → Sonnet 4.5로 가면서 명확한 향상이 보이는데, 저자가 참조한 그래프에서 이게 숨겨진 것이다. GPT-5 데이터 포인트 하나가 이상치로 작용해 전체 추세를 왜곡하고 있으며, 이를 제외하면 로지스틱 성장 모델(개선이 느려지지만 멈추지 않은 모델)에 부합한다'는 반론이 나왔다. 저자의 분석이 데이터 포인트 수가 너무 적어 신뢰하기 어렵다는 비판도 함께 제기됐다.
'모델 자체의 원샷 지능은 1년간 크게 변하지 않았지만, 그 주변 워크플로우(tool use, planning loop, 서브 에이전트, persistent context)가 비약적으로 발전해서 실용적 성능은 크게 높아졌다'는 의견이 공감을 많이 받았다. 즉 모델과 하네스(harness)를 분리해서 봐야 한다는 시각이다.
실제 사용자 경험으로는 '모델이 나아진 건 맞는 것 같은데 체감이 매우 주관적'이라는 의견이 많았다. 한 댓글에서는 'Claude Code나 Codex 덕분에 터미널만 쓰게 됐는데, 코드 품질은 여전히 끔찍하다(4중 중첩 제어 흐름, 잘못된 아키텍처 등)'며 두 가지가 동시에 사실처럼 느껴지는 모순을 토로했다.
리뷰어 피로(reviewer fatigue) 관점의 흥미로운 의견도 있었다. '모델이 나아지지 않아도 merge rate는 올라갈 수 있다. 리뷰해야 할 코드가 폭발적으로 늘어나면서 reviewer들이 피로해져 품질이 낮은 PR도 통과시키게 된다'는 것이다. 반대로 'LLM이 더 능숙해질수록 더 야심찬 작업을 맡기게 되므로 merge 성공률은 자연스럽게 낮아질 수 있다'는 반론도 있었다.
프론티어 랩들이 모델 크기 확장보다 에이전틱 AI와 복잡한 post-training(강화학습 기반 후처리)에 집중하는 방향 전환이 이 정체의 원인일 수 있다는 의견도 있었다. 이는 AGI에 대해 비관적인 시각으로 이어졌지만, 동시에 '이 수준으로도 화이트칼라 업무의 50%는 자동화할 수 있다'는 현실적 낙관론도 함께 나왔다.

How to Apply

코딩 작업에 LLM을 도입할 때 '테스트 통과'만을 성공 기준으로 삼으면 실제 코드 품질을 과대평가하게 된다. PR merge 가능 여부, 코드 리뷰 승인률 같은 기준으로 팀 내 LLM 성능을 직접 측정해두면 벤더의 벤치마크 홍보에 흔들리지 않고 실제 효용을 판단할 수 있다.
모델 자체의 성능 향상을 기다리기보다, 현재 모델의 한계 안에서 tool use, 서브 에이전트, 작업 분해(task decomposition) 같은 워크플로우 개선에 투자하는 것이 단기적으로 더 큰 실용적 효과를 낼 수 있다. 댓글에서도 '원샷 지능보다 워크플로우가 훨씬 많이 좋아졌다'는 실사용 경험이 공유됐다.
새 모델이 출시될 때마다 'merge rate' 또는 팀 내 코드 리뷰 승인률 기준으로 A/B 테스트를 직접 수행해두면, 마케팅 성능 과장(hype)과 실제 업무 성능 차이를 구분하는 데 도움이 된다. 특히 SWE-bench 같은 공개 벤치마크 점수만 보고 도입을 결정하는 것은 위험할 수 있다.

Terminology

merge rate오픈소스 프로젝트에서 LLM이 작성한 코드가 실제 maintainer에게 승인되어 메인 브랜치에 합쳐지는 비율. 단순히 테스트를 통과하는 것보다 훨씬 높은 기준이다.

SWE-benchLLM이 실제 GitHub 이슈를 해결하는 능력을 측정하는 벤치마크. 실제 오픈소스 프로젝트의 버그 수정 과제로 구성된다.

Brier score예측 모델이 얼마나 정확한지 측정하는 지표로, 예측값과 실제값 차이의 제곱 평균이다. 낮을수록 예측이 정확하다는 뜻.

leave-one-out cross-validation데이터 포인트 하나를 빼고 나머지로 모델을 학습한 뒤 뺀 포인트를 예측하는 방식으로, 과적합 없이 모델 예측력을 검증하는 통계 기법이다.

harnessLLM을 감싸는 실행 환경이나 도구 프레임워크. Claude Code, Codex 같은 터미널 에이전트가 이에 해당하며, 모델 자체와 별개로 성능에 큰 영향을 준다.

post-training사전 학습(pre-training)이 끝난 모델을 특정 목적에 맞게 추가로 조정하는 과정. RLHF(인간 피드백 강화학습)나 instruction tuning 등이 여기 포함된다.