Databricks가 자체 코딩 AI 벤치마크를 만든 방법과 결과 — 회사 코드베이스가 SWE-bench보다 정확한 이유

GeekNews에 올라온 Databricks의 자체 코딩 AI 벤치마크 설계 사례는, 공개된 SWE-bench·HumanEval 같은 벤치마크가 실제 회사 코드베이스와 동떨어진다는 문제를 정확히 짚습니다. 수백만 줄짜리 모노레포 위에서 동작해야 하는 코딩 에이전트의 실력을 재려면, 회사별 실제 업무 과제로 자체 벤치마크를 만들어 평가해야 한다는 주장입니다.

흥미로운 건 단순히 벤치마크를 새로 만든 데서 끝나지 않고, 같은 모델이라도 하네스(에이전트 환경)에 따라 가격과 수행 시간이 크게 달라진다는 점입니다. Databricks가 공개한 결과는 한국 개발 조직이 어떤 모델과 하네스 조합을 택할지 결정할 때 직접적인 참고 자료가 됩니다.

• 공개된 코딩 벤치마크는 회사별 상황에 딱 맞지 않고 치팅이 가능한 것이 문제
• Databricks에서 실제 수행한 과제, 언어로 벤치마크를 만들어 평가
• GLM 5.2는 가장 어려운 과제도 Opus 4.8과 같은 수준으로 해결했지만 가격은 Opus의 66% 수준



• Sonnet 5는 Opus 4.8보다 1.7배 저렴하지만 실제 작업 완료를 위해 토큰을 1.9배 더 쓰기 때문에 비효율적
• 동일한 모델을 사용해도 하네스에 따라 가격과 수행 시간이 크게 절약됨

한국 시장에서의 시사점

국내 대기업 SI·금융·통신사도 수백만 줄짜리 레거시 자바·코틀린 코드베이스 위에서 코딩 에이전트를 시험 운영하기 시작했습니다. 이들 조직이 SWE-bench 점수만 보고 모델을 고르면 Databricks 실험과 같은 함정에 빠집니다. 회사 고유 코드베이스에서 실제 PR 머지율·테스트 통과율·롤백률을 측정한 자체 벤치마크가 있어야 의사결정이 가능합니다.

또한 하네스 효과는 한국 SI 환경에서 특히 중요합니다. 한국 SI는 사내 표준 빌드 시스템·인증 프록시·보안 정책이 에이전트 하네스 위에 그대로 얹히기 때문에, 같은 Opus 모델이라도 하네스 설계에 따라 토큰 비용이 2배 차이 날 수 있습니다. 모델 선정과 동시에 하네스 표준을 먼저 만드는 것이 합리적인 도입 순서입니다.

원문: GeekNews #31489 · 출처: Databricks Blog

---

📰 원본 출처 · https://news.hada.io/topic?id=31489 (#N=31489)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.