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

관련 논문

• 2,000명이 내 AI 어시스턴트를 해킹하려 한 뒤 벌어진 일

  실제로 6,000개 이상의 이메일로 AI 에이전트에 prompt injection 공격을 시도한 공개 실험 결과로, Claude Opus 4.6이 비밀 파일 유출을 한 번도 허용하지 않았지만 실험 설계의 현실성에 대한 논란이 뜨거웠다.

• 언제 LLM을 조합하면 효과가 있나? 67개 Frontier 모델에서 Routing, Voting, Mixture-of-Agents의 Co-Failure Ceiling 분석

  여러 LLM을 조합해도 '모든 모델이 동시에 틀리는 비율(β)'이 성능 상한선이며, 업계가 쓰는 pairwise 상관계수(ρ)는 이 상한선을 예측하지 못한다.

• Function Calling을 넘어서: Tool-Environment 신뢰성 문제 하에서의 Tool-Using Agent 벤치마크

  실제 환경처럼 API가 망가지거나 결과가 이상할 때 LLM 에이전트가 얼마나 잘 버티는지 측정하는 벤치마크 ToolBench-X 공개.

• LG 스마트 TV 앱의 절반 가까이에 Residential Proxy SDK가 심어져 있다

  6,038개의 LG·Samsung 스마트 TV 앱을 스캔했더니 2,058개에서 사용자의 IP를 몰래 팔아 트래픽을 중계하는 Residential Proxy SDK가 발견됐다. TV는 컴퓨터처럼 감시받지 않아서 프록시 호스트로 거의 이상적인 환경이다.

• Prompt Injection의 본질은 Role Confusion이다

  LLM이 시스템 프롬프트, 사용자 입력, 툴 출력을 구분하지 못하는 구조적 결함이 prompt injection의 근본 원인이라는 ICML 2026 논문으로, 현재 LLM 보안 아키텍처의 한계를 명확히 분석한다.

• GPT-5.5의 환각(Hallucination) 비율이 MIT 라이선스 GLM-5.2보다 3배 높다

  모델 크기가 커질수록 성능이 좋아진다는 통념에 반해, 오픈소스 753B 모델 GLM-5.2가 추정 1~2T 규모의 GPT-5.5보다 환각 비율이 3배 낮다는 벤치마크 결과가 나왔다. 단순히 파라미터 수와 벤치마크 점수만으로 모델을 선택하면 실제 업무에서 낭패를 볼 수 있다는 경고다.

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...