Databricks의 수백만 라인 코드베이스에서 코딩 에이전트 벤치마킹

Databricks에서 엔지니어링에 AI를 적극적으로 도입함에 따라 소프트웨어를 구축하는 방식이 빠르게 변화하고 있습니다. 지난 한 해 동안 코드 작성을 위한 모델과 하네스(harness)의 환경이 급격히 확장되어 개발자들에게 그 어느 때보다 더 많은 선택권이 주어졌습니다. 선택지가 많아짐에 따라, 실제 코딩 작업에서 어떤 코딩 에이전트가 가장 우수한 성능을 제공하는지 이해하는 것뿐만 아니라, 작업 성능이 가격에 따라 어떻게 달라지는지 파악하는 것이 점점 더 중요해지고 있습니다.

이 글에서는 Databricks 코드베이스에서 당사 엔지니어들이 수행한 실제 코딩 작업을 바탕으로 도구를 평가하는, Databricks 자체 구축 내부 코딩 벤치마크의 결과와 방법론을 공유합니다. 평가 작업에는 여러 인기 언어(Python, Go, Typescript, Scala 등)를 아우르는 수백만 줄 규모의 코드베이스에 대한 수정 작업이 포함되었으며, 정확성을 보장하기 위해 작업과 솔루션 모두 철저히 검토되었습니다. 이것이 모든 것을 포괄하는 종합적인 분석은 아니지만, 이 과정을 통해 당사 엔지니어링 팀이 코딩 에이전트를 활용하여 효율성을 크게 높이는 데 도움이 되는 인사이트를 얻을 수 있었습니다. 아래에서 전체 벤치마크에서 모델과 하네스가 기록한 점수를 확인할 수 있습니다:

Figure 1: 자체 벤치마크에서의 비용 대 성능

분석을 통해 얻은 주요 결론은 다음과 같습니다:

1. 코딩 작업의 파레토 프론티어(즉, 주어진 비용 대비 최고의 품질)에는 OpenAI, Anthropic 및 오픈 소스 모델이 포함됩니다. 이는 오늘날 여러 도구를 조합해야만 최첨단 성능을 제공할 수 있음을 의미합니다.
2. 오픈 모델, 특히 GLM 5.2는 이제 가장 높은 난이도의 작업도 처리할 수 있습니다.
3. 모델의 토큰 가격은 엔드투엔드 작업에서 발생하는 실제 비용을 예측하는 데 적절한 지표가 아닙니다. 더 큰 모델이 토큰 효율성이 훨씬 더 높고 전반적인 비용이 더 낮을 수 있습니다.
4. 모델을 호출하는 하네스는 비용과 품질에 극적인 영향을 미칩니다. 많은 경우, Pi와 같은 단순한 하네스가 당사의 워크로드에서 가장 우수한 성능을 보였습니다.

각 항목에 대해 조금 더 자세히 살펴보겠습니다.

모델들은 대략적인 "역량 계층"으로 분류됩니다

구체적인 결과에서 몇 점 차이가 나는 것은 실제 작업에서는 보통 상쇄될 수 있습니다. 우리는 다양한 작업에 어떤 모델을 사용할지 판단하는 데 도움이 되는 주제별 패턴에 더 집중했습니다. 실제로 결과에 따르면 모델과 하네스가 3개의 역량 계층으로 명확하게 분류되는 것을 확인할 수 있었습니다.

Figure 2: 전체 결과에서 3개의 고유한 역량 계층이 나타났으며, 각 그룹에서 어떤 모델이 효과적인지에 대한 미세한 차이가 있었습니다

성능의 상위권에서는 가장 지능적인 모델이 모든 종류의 문제를 해결하는 데 매우 효과적이지만, 비용이 매우 많이 듭니다. 중간 및 하위 지능 모델도 일반적인 작업에서는 여전히 매우 효과적이며, 많은 경우 비용도 훨씬 저렴합니다.

매일 엔지니어들은 복잡성이 크게 다른 다양한 작업을 수행합니다. 플래그를 전환하거나 구성을 업데이트하는 것과 같은 일반적인 운영 작업에는 극도로 지능적인 모델이 필요하지 않지만, 더 심도 있는 설계 탐색에는 필요합니다. 하지만 과거에는 기본 모델이 항상 가장 비싼 모델이었습니다. 이 분석을 바탕으로 우리는 Haiku 및 GPT 5.4 Mini 등급의 모델에 더 많은 작업을 할당해야 한다고 결정했습니다.

코딩을 위한 오픈 모델의 등장

GLM 5.2에 대한 기대감이 컸는데, 당사의 결과는 GLM이 많은 개발자들에게 일상적인 주력 모델이 될 수 있다는 증거를 보여주었습니다. 이 모델은 최상위 역량 계층에 올랐으며, 품질 면에서 통계적으로 Opus 4.8과 동등한 수준이었지만, 작업당 비용은 Opus의 $1.94에 비해 $1.28에 불과했습니다.

GLM 품질 점수는 일상적인 개발에 GLM을 시범적으로 사용해 온 내부 개발자들로부터 받은 정성적 피드백과 일치합니다. 일상적인 코딩 작업에서의 뛰어난 성능 덕분에 당사는 최고의 성능으로 GLM을 서비스하는 것에 집중해 왔으며, 이제 이를 코딩을 위한 일상적인 주력 모델로 배포하기 시작할 때가 되었음을 보여주는 증거가 있습니다.

작업당 비용 대 토큰당 비용

개발자들은 코딩 작업을 완료할 때 모델 비용이 얼마나 들지 알아보기 위해 대략적으로 토큰 비용을 살펴보는 경우가 많습니다. 그러나 모델 간의 추론 효율성 차이로 인해 토큰 비용이 전반적인 작업 비용을 나타내는 지표로는 부적합한 경우가 많다는 것을 발견했습니다. 이는 컨텍스트마다 작업의 형태와 복잡성이 다를 수 있기 때문에 작업 수준의 벤치마킹이 필요함을 강조합니다.

예를 들어, Sonnet 5는 토큰당 비용이 Opus 4.8보다 약 1.7배 저렴하지만, 당사의 작업에서는 Sonnet의 비용이 작업당 $2.09로 Opus의 $1.94에 비해 더 높았으며, 작업 완료율은 6포인트 더 낮았습니다(81% 대 87%). 이는 주로 Sonnet 5가 결과를 도출하기 위해 더 오래 작업하고 더 많이 읽어 1.9배 더 많은 토큰을 소비했기 때문입니다.

효율성에 큰 영향을 미치는 하네스

동일한 모델을 동일한 사고 노력으로 두 개의 서로 다른 하네스(Claude Code/Codex 대 Pi)를 통해 실행했을 때, 품질은 동일하게 유지되면서도 작업당 비용은 크게 차이(일부 경우 2배 이상)가 나는 것을 관찰했습니다. 주요 차이점은 각 하네스가 매 턴마다 모델에 얼마나 많은 컨텍스트를 제공하는지에 있었습니다.

Pi는 턴당 약 3배 적은 컨텍스트를 전송했습니다. 컨텍스트를 더 잘 관리하여 작업 세트를 더 타이트하게 유지하고 더 적은 실행 횟수로 작업을 완료했습니다.

여기서 얻을 수 있는 교훈은 특정 하네스가 항상 더 저렴하다거나 네이티브 하네스가 더 나쁘다는 것이 아닙니다. 그보다는 모델 선택이 전체 퍼즐의 한 조각에 불과하다는 점입니다. 이러한 유연성을 확보하는 것이 바로 당사가 모드 및 하네스 전환을 원활하게 만들기 위해 Omnigent에 투자한 이유입니다.

자체 벤치마크를 구축해야 하는 이유는 무엇인가요?

SWE-Bench 및 TerminalBench와 같은 공개 벤치마크는 유용하지만, 우리가 가졌던 의문에 답을 줄 수는 없습니다. 여기에는 몇 가지 이유가 있습니다:

• 작업이 공개되어 있어 시간이 지나면서 솔루션이 학습 데이터에 유출됩니다.
• 우리는 해당 결과가 10개 이상의 언어와 Scala, Go, Rust, Java, Python, Bazel, Protobuf 등으로 작성된 많은 서비스를 아우르는 당사의 코드베이스를 대표하지 못한다는 것을 발견했습니다.

자체 PR을 기반으로 벤치마크를 구축함으로써, 최적화를 도입하더라도 개발자들에게 방해가 되지 않을 것이라는 더 높은 확신을 가지고 이러한 결정을 내릴 수 있습니다.

벤치마크 구축 방법

우리는 Unity AI Gateway를 사용하여 모든 코딩 상호작용의 로그를 캡처했으며, 이를 통해 엔지니어들이 코딩 에이전트를 사용하여 해결하는 작업의 복잡성을 분석할 수 있었습니다. 작업 복잡성에는 상당한 다양성이 있었으며, 약 4분의 1은 낮은 복잡성의 작업으로, 약 60%는 중간 복잡성의 작업으로 분류되었습니다.

하지만 엔지니어들이 사용하는 기본 모델은 비싼 모델이었기 때문에, 효율성을 개선할 수 있는 엄청난 기회가 분명히 존재했습니다.

작업 구성

당사 엔지니어들은 하루에 수천 개의 코드 변경 사항을 병합하므로, 벤치마크를 구축할 수 있는 훌륭한 데이터 세트가 이미 준비되어 있습니다. 좋은 풀 리퀘스트는 개발자의 반복 작업을 보여주는 커밋, 사람의 검토, 코드 변경이 의도에 부합하는지 검증하는 데 도움이 되는 테스트가 포함된 풍부한 결과물입니다. 하지만 이를 통해 고품질의 벤치마크를 구성하려면 몇 가지 품질 검사와 필터링이 필요했습니다:

• 최신성: 현재 사용 중인 프레임워크, 패턴, 컨벤션을 포함하여 오늘날 우리가 소프트웨어를 구축하는 방식을 작업에 반영할 수 있도록 최근 이력에서 데이터를 가져옵니다.
• 사람이 작성함: 봇 커밋, service accounts, 완전히 AI가 생성한 변경 사항 및 자동 생성된 변경 사항은 필터링되었습니다.

후보 PR이 확보된 후에는 다음과 같은 방법으로 명확하게 정의된 작업을 구성하는 데 집중했습니다.

1. 의도를 파악하고 이를 프롬프트로 요약합니다. PR을 읽고 실제로 무엇을 위한 것인지 파악한 다음, 원하는 결과를 설명합니다. 보통 이는 문제나 목표를 명시하고, 제약 조건을 지정하며, 해결책에 대한 설명을 제거하여 PR 설명을 다시 작성하는 것을 의미했습니다. 예를 들어 버그 수정이 왜 올바른지에 대한 설명을 제거하는 것이 중요한데, 그렇지 않으면 작업이 너무 쉬워지기 때문입니다.
2. 관련 테스트 분리하기. 테스트가 아닌 파일들은 모델이 스스로 재현해야 하는 변경 사항이므로, 테스트 파일은 따로 보관하고 컴파일이 가능한지 확인했습니다. 저희 빌드 시스템은 원래 PR에서 수정된 파일에 의존하는 테스트가 무엇인지 이미 판단할 수 있으므로, 해당 테스트 타겟을 모두 실행했습니다.

이 과정을 통해 벤치마크에 단일 작업이 생성되었습니다. 다음은 단순화된 예시입니다.

스크립트와 AI를 사용하여 후보 작업을 생성했지만, 각 샘플은 수작업으로 평가했습니다. 어떤 경우에는 대안적인 구현을 허용하거나 더 엄격하게 검증하기 위해 원래 PR의 테스트를 다시 작성해야 했으며, 이는 AI 없이 수동으로 진행했습니다. 마찬가지로, 작업을 명확하게 정의하기 위해 작업 설명을 개선해야 하는 경우도 발견했습니다.

그림 3: 테스트 스위트의 전후 비교: 이전 테스트는 정확한 문자열 일치 여부를 확인하는 데 중점을 두어 모델이 작업을 해결하려고 할 때 일부 실패가 발생했습니다. 이는 비결정적(non-deterministic) 출력을 테스트하기에 좋은 방법이 아니었기 때문에 동작을 평가하도록 다시 작성되었습니다.

저희는 Databricks 엔지니어들이 사용할 수 있는 모든 공통 도구와 함께 기본 제공되는 표준 설정을 사용하여 코딩 에이전트 하네스(harness)와 모델을 인스턴스화했습니다.

에이전트가 작업을 완료했다고 명시적으로 밝히면, 해당 코드를 체크포인트로 저장하고 보류해 둔 테스트를 패치한 후 테스트를 평가하여 해당 모델과 하네스 조합에 대해 해당 작업이 "통과"인지 여부를 결정했습니다. 저희는 정확성을 평가하기 위해 LLM 심사위원을 사용하지 않았습니다. 왜냐하면 LLM 심사위원은 실제로 옳은 것보다 그럴듯하게 들리는 것에 점수를 더 주는 경향이 있기 때문입니다.

추가 가드레일

초기 실험에서 일부 모델 점수가 믿기지 않을 정도로 높게 나와서, 에이전트 궤적에서 어떤 일이 일어났는지 파악하기 위해 추적(trace)을 수동으로 검사했습니다. 확인 결과, 원래 설정 때문에 작업 트리의 Git 기록에서 "올바른" 구현을 여전히 복구할 수 있었습니다! 모든 작업이 병합된 커밋에서 시작되었기 때문에, 셸을 가진 에이전트가 git 기록을 거슬러 올라가 이를 찾아내는 것을 막을 수 없었습니다. 이 문제를 해결하기 위해 git 기록을 봉인했습니다. 각 실행 기간 동안 작업 복사본을 리포지토리로부터 완전히 차단했습니다.

다음 단계는 무엇인가요?

저희는 "코딩 에이전트를 더 효율적으로 사용할 수 있을까?"라는 간단한 질문에서 시작했습니다. 대답은 확실한 '예'이며, 데이터 기반으로 접근할 수 있기 때문에 적절한 모델을 자동으로 선택하고 효율성을 추적하는 기능을 구축하기 시작할 수 있습니다.

어떤 기업이든 똑같이 할 수 있습니다. 병합된 PR 백로그가 있는 팀이라면 이미 어떤 모델도 학습하지 않은 벤치마크를 보유하고 있는 셈이며, 이는 팀에서 작성한 테스트를 통해 평가됩니다. 저희는 적극적으로 더 많은 작업(특히 더 어려운 작업)을 추가하고 있으며, 모든 새로운 에이전트/하네스를 여기에 실행하여 선택에 대한 확신을 높일 계획입니다.

Databricks에서는 특정 벤더에 종속되는 것뿐만 아니라, 시간이 지남에 따라 팀의 유연성을 떨어뜨리는 가정에 갇히는 것을 항상 경계해 왔습니다. 이러한 본능은 개방형 포맷과 표준에 대한 초기 투자로 이어졌으며, 현재 AI에 접근하는 방식에도 영향을 미치고 있습니다. 즉, 우리가 배포하는 코드에서 실제로 작동하는 것을 측정하고, 엔지니어가 일관된 가드레일을 유지하면서 여러 모델과 하네스를 자유롭게 전환할 수 있는 여지를 제공하며, AI를 효과적으로 사용하기 위한 최적화를 수행하는 것입니다.

후속 블로그에서는 개발자가 효율성을 유지하면서 가장 지능적인 에이전트를 사용할 수 있도록 지원하기 위해 Unity AI Gateway 및 Omnigent에서 지능형 라우팅 기능을 어떻게 활용하고 있는지 자세히 설명하겠습니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)