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

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

관련 논문

• LLM이 TLA+로 실제 시스템을 제대로 모델링할 수 있을까? — SysMoBench 벤치마크

  LLM이 TLA+ 명세를 작성할 때 문법은 잘 통과하지만 실제 시스템과의 동작 일치도(conformance)는 46% 수준에 그친다는 걸 체계적으로 검증한 벤치마크 연구로, AI 기반 형식 검증의 현실적 한계를 보여준다.

• Natural Language Autoencoders: Claude의 내부 활성화를 자연어 텍스트로 변환하는 기법

  Anthropic이 LLM 내부의 숫자 벡터(활성화값)를 직접 읽을 수 있는 자연어로 변환하는 NLA 기법을 공개했다. AI가 실제로 무슨 생각을 하는지 해석하는 interpretability 연구의 새로운 진전이다.

• ProgramBench: LLM이 프로그램을 처음부터 다시 만들 수 있을까?

  LLM이 FFmpeg, SQLite, PHP 인터프리터 같은 실제 소프트웨어를 문서만 보고 처음부터 재구현할 수 있는지 측정하는 새 벤치마크로, 최고 모델도 전체 태스크의 3%만 95% 이상 통과하는 수준에 그쳤다.

• MOSAIC-Bench:코딩 에이전트의 Compositional Vulnerability 유도 측정

  티켓 3장으로 쪼개면 Claude/GPT도 보안 취약점 코드를 53~86% 확률로 그냥 짜준다.

• LLM의 거절(Refusal) 동작은 단 하나의 방향(Direction)으로 제어된다

  13개의 오픈소스 채팅 모델을 분석했더니, 모델이 유해한 요청을 거절하는 동작이 내부 활성화 공간에서 단 하나의 1차원 벡터 방향으로 인코딩되어 있었다. 이 방향을 제거하면 안전 파인튜닝이 사실상 무력화되므로, 현재 안전 학습 방식이 얼마나 취약한지 보여준다.

• LLM의 구조화된 출력(Structured Output)을 테스트하는 새 벤치마크 SOB 공개

  스키마 준수 여부만 보던 기존 벤치마크의 한계를 넘어, 실제 값의 정확도까지 7가지 지표로 평가하는 Structured Output Benchmark(SOB)가 공개됐다. 인보이스 파싱, 의료 기록 추출처럼 JSON 출력의 정확성이 중요한 프로덕션 시스템에서 어떤 모델을 써야 할지 판단하는 데 직접적으로 참고할 수 있다.

Related Resources

• https://entropicthoughts.com/no-swe-bench-improvement
• https://metr.org/assets/images/many-swe-bench-passing-prs-wo...
• https://fabien.benetou.fr/Content/SelfHostingArtificialIntel...