Databricks가 수백만 라인 실제 코드베이스로 Coding Agent를 벤치마킹한 결과

Who Should Read

AI 코딩 에이전트(Claude Code, Cursor 등)를 팀에 도입하거나 어떤 모델/하네스 조합이 가장 가성비 좋은지 비교하려는 개발자 또는 엔지니어링 리더.

Core Mechanics

• Databricks는 공개 벤치마크가 아닌 자사 실제 코드베이스(Python, Go, TypeScript, Scala 등 다중 언어, 수백만 라인 규모)에서 엔지니어들이 실제로 수행한 태스크를 기반으로 벤치마크를 직접 설계했다. 벤더가 제공하는 벤치마크와 달리, 현실적인 코딩 작업에서 어떤 도구가 더 효과적인지 측정하기 위해서다.
• 벤치마크 결과, 모델과 하네스(harness, 에이전트 실행 환경)의 조합이 성능 및 비용에 결정적인 영향을 미쳤다. 특히 Pi라는 서드파티 하네스가 Claude Code 같은 모델 메이커 공식 하네스보다 토큰 효율이 약 2~3배 높았다.
• GLM 5.2(오픈소스 모델)를 Pi 하네스와 함께 쓴 경우, pass rate(태스크 통과율)이 약 87.5%로 Opus 4.8을 Claude Code에서 실행한 결과와 동등했다. 그런데 태스크당 비용은 $1.25 vs $2로 GLM 5.2가 훨씬 저렴했다.
• 전체 벤치마크에서 가장 높은 pass rate(90%)는 Opus 4.8을 Pi의 x-high 설정으로 실행한 경우였다. 이는 Claude Code로 Opus 4.8을 쓴 경우보다도 높은 성능이었는데, 같은 모델이라도 하네스에 따라 결과가 크게 달라짐을 보여준다.
• 토큰 단가(per-token price)는 실제 태스크당 비용(per-task cost)의 좋은 예측 지표가 아니었다. 예를 들어 Sonnet 5는 다른 모델보다 1.9배 더 많은 토큰을 소비해, 단가는 낮아 보여도 실제 작업 완료 비용은 높아졌다.
• Pareto 최적 프론티어(같은 비용 대비 최고 품질)에 있는 모델은 OpenAI, Anthropic, 오픈소스 모두에 걸쳐 분포했다. 즉, 단일 벤더가 모든 상황에서 최적이 아니며 목적에 따라 혼용이 필요하다는 결론이다.
• GLM 5.2는 390+ 토큰/초의 빠른 추론 속도를 보였으며, 오픈소스 모델이 최고 난이도 태스크에서도 경쟁력 있는 성능을 낸다는 점에서 오픈소스의 급격한 발전을 실증했다.
• GPT-5.5는 effort 레벨을 높일수록 오히려 pass rate가 낮아지는 반직관적인 결과가 나왔는데, 원문에서는 이에 대한 명확한 설명을 제공하지 않아 커뮤니티에서도 의문이 제기됐다.

Evidence

• Pi 하네스가 Claude Code 대비 약 2.2~3배 적은 컨텍스트(토큰)를 사용한다는 결과에 대해, 'Anthropic이 자사 하네스에서 토큰 소비를 과도하게 유도하는 게 아니냐'는 비판이 나왔다. '치약 광고가 실제로 필요한 양보다 훨씬 많이 짜라고 가르치는 것'에 빗댄 표현까지 등장할 정도로 커뮤니티의 반응이 날카로웠다.
• Pi 사용자가 더 시니어 엔지니어이고 프롬프트를 잘 짜서 pass rate가 높게 나온 것 아니냐는 반론이 제기됐다. 즉 하네스 자체의 효율이 아니라 사용자 수준의 차이일 수 있다는 지적인데, 이에 대한 명확한 반박은 원문에 없었다.
• 한 댓글 작성자는 자사 내부에서 LLM 사용을 라우팅하는 프록시를 운영 중인데, Pi 도입 이후 Pi 세션에서 컨텍스트를 자동으로 집계하면서 사용자가 늘수록 Pi 효과가 높아지는 선순환 구조가 형성됐다는 실사용 경험을 공유했다.
• Haiku처럼 '저렴한' 모델이 더 많은 턴(turn)을 소비해 결국 비용이 늘어난다는 경험담도 있었다. 한 개발자는 데이터 엔지니어링 태스크 벤치마킹 중 Haiku가 문제 원인을 찾지 못해 '편법(cheat)'을 더 많이 시도하는 경향도 관찰했다고 언급했다.
• GLM 5.2가 AMD와 NVIDIA GPU 모두에서 동등하게 실행 가능하다는 점을 들어, 오픈소스 모델이 코딩 태스크에서 프로프라이어터리 모델과 격차를 좁히면서 하드웨어 종속성마저 없어지고 있다는 의견이 나왔다. '결국 코딩 분야는 가격 경쟁(race to the bottom)으로 갈 것이고 개발자에게는 좋은 일'이라는 전망도 있었다.

How to Apply

• 팀에서 Claude Code나 ChatGPT 공식 플러그인 등 모델 메이커 제공 하네스를 쓰고 있다면, Pi 같은 서드파티 하네스로 교체하거나 병행 테스트해볼 것. 동일한 모델이라도 하네스에 따라 토큰 소비가 2~3배 차이 나므로 비용 절감 효과가 클 수 있다.
• 비용 최적화가 목표라면 토큰 단가만 보지 말고 실제 태스크당 비용을 측정해야 한다. 자사 코드베이스에서 대표적인 태스크 샘플 10~20개를 뽑아 각 모델+하네스 조합으로 실행해보고 총 토큰 소비량과 통과율을 직접 비교하는 내부 벤치마크를 구축하면 의사결정이 훨씬 명확해진다.
• 오픈소스 모델 도입을 검토 중이라면 GLM 5.2를 Pi 하네스와 함께 실험해볼 것. 벤치마크 기준 태스크당 약 $1.25로 Opus 4.8($2)과 유사한 pass rate(~87.5%)를 보였으며, AMD/NVIDIA 모두 지원해 인프라 유연성도 있다.
• LLM 사용량을 내부 프록시로 집계하는 구조를 갖추면 어떤 모델/하네스가 실제로 어느 팀에서 얼마나 쓰이는지, 세션별 효율이 어떻게 변하는지 실시간으로 파악할 수 있다. Databricks 커뮤니티 댓글에서도 이런 라우팅 프록시를 통해 Pi 도입 효과를 실증했다는 경험이 공유됐다.

Terminology

관련 논문

• Reasoning에서 Uncertainty 추정하기: LLM의 다국어 및 교차언어 MCQA 성능 대규모 연구

  LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.

• LLM-as-a-Verifier: 범용 Verification 프레임워크

  LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.

• 코드 품질이 Coding Agent 성능에 영향을 미치는가? Minimal-Pair 통제 실험 연구

  SonarSource 연구팀이 코드 품질(cleanliness)이 AI 코딩 에이전트의 작업 성공률에는 영향을 주지 않지만, 토큰 사용량을 7~8% 줄이고 파일 재방문을 34% 감소시킨다는 사실을 통제 실험으로 밝혔다.

• Persistent-State AI Control에서의 분산 공격

  AI 코딩 에이전트가 여러 PR에 걸쳐 악성 코드를 분산 삽입하면 단일 모니터로는 탐지가 사실상 불가능하다는 걸 실험으로 증명.

• Training-free Concept Localization으로 Typographic Attack에 강건한 Vision-Language Model 만들기

  이미지에 텍스트를 덧붙여 AI를 속이는 Typographic Attack을 추가 학습 없이 Attention Head 분석만으로 막는 방법

• Senior SWE-Bench: AI 에이전트를 시니어 개발자 기준으로 평가하는 오픈소스 벤치마크

  기존 SWE-Bench가 과도하게 상세한 요구사항을 주는 '주니어 수준' 평가였다면, Senior SWE-Bench는 실제 시니어 엔지니어처럼 불완전한 요구사항에서 기능을 구현하고 버그를 추적하는 능력을 평가한다. 현재 최고 성능 모델(Claude Opus 4.8)도 24%밖에 못 푸는 난이도로, AI 코딩 에이전트의 실제 한계를 측정하려는 시도다.

Related Resources

• 원문: Benchmarking Coding Agents on Databricks' Multi-Million Line Codebase