AI 코딩 에이전트 벤치마크: 팀 PR로 모델 비용과 통과율 비교하기

AI 코딩 에이전트가 좋아 보여도 팀 코드에서 어느 모델이 돈값을 하는지는 별개입니다. 공개 점수만 보고 고르면 실제 저장소 작업과 어긋날 수 있습니다. 여기서 갈립니다.

직접 돌려보지는 않았습니다. Databricks 공식 블로그 기준으로 정리했습니다. 저라면 공개 벤치마크 점수만 보고 모델을 고르지 않고, 팀 PR 이력으로 작은 내부 벤치마크를 먼저 만들겠습니다.

1. 적용 범위

• AI 코딩 에이전트를 팀 저장소에 넣기 전 모델과 실행 하네스를 고르려는 경우입니다.
• Python, Go, TypeScript, Scala처럼 언어가 섞인 큰 저장소에서 실제 작업 난도를 재고 싶은 경우입니다.
• 모델 가격표가 아니라 작업 1건당 비용과 통과율을 같이 보려는 경우입니다.

자동화 자체보다 운영 기록이 중요하다는 점은 Tasker, n8n, Firefly III 연동 기록과도 비슷합니다. 코딩 에이전트도 결과만 보면 안 되고, 어떤 입력과 검증으로 나온 결과인지 같이 남겨야 합니다.

2. PR로 문제 만들기

공식 글의 핵심은 이미 병합된 PR을 시험 문제로 바꾸는 방식입니다. 사람 개발자가 끝낸 변경에서 의도를 뽑아 프롬프트를 만들고, 정답 diff는 숨깁니다. 모델은 롤백된 저장소에서 작업하고, 테스트는 나중에 붙습니다.

문제 후보는 아무 PR이나 쓰지 않습니다.

• 사람이 작성한 최근 PR.
• 자동 변경이나 대규모 포맷팅 제외.
• 몇 개 모듈 안에서 끝나는 작업.
• 검증할 테스트가 남아 있는 작업.
• 팀의 일반 업무를 대표하는 작업.

이 조건을 잡으시면 됩니다. 너무 큰 리팩터링은 모델 비교보다 프롬프트 해석 싸움으로 흐릅니다.

3. 채점 방식

Databricks는 LLM judge로 맞다 틀리다를 보지 않았습니다. 에이전트가 완료를 선언한 시점의 코드를 체크포인트로 잡고, 숨겨 둔 테스트를 다시 붙여 통과 여부를 봤습니다. 말이 그럴듯한 답보다 테스트 통과를 우선한 셈입니다.

정답 diff가 Git 이력에 남아 있으면 벤치마크가 깨집니다. 공식 글에서도 초기 실험 때 에이전트가 shell로 Git history를 따라가 정답 구현을 찾을 수 있는 상태였다고 설명합니다. 이후 실행 중에는 작업 복사본을 저장소 이력에서 잘라냈습니다.

4. 볼 지표

모델 토큰 단가만 보면 판단이 틀어집니다. 공식 결과에서도 비싼 모델이 작업 전체에서는 토큰을 덜 쓰고, 싼 모델보다 작업당 비용이 낮아지는 경우가 있었습니다. 실행 하네스도 결과를 바꿉니다. 같은 모델이라도 Pi, Claude Code, Codex 같은 호출 환경에 따라 비용과 통과율이 달라졌습니다.

제가 본 기준은 이렇습니다.

• 통과율: 숨겨 둔 테스트 기준 pass rate.
• 작업당 비용: 토큰 단가가 아니라 한 문제를 끝내는 평균 비용.
• 난도 계층: 쉬운 운영 변경과 설계 변경을 나눠 보기.
• 하네스 차이: 모델 이름만 보지 말고 실행 도구까지 함께 기록.

확인

내부 벤치마크를 만들 때는 PR 10개 정도로 시작하시면 됩니다. 각 문제에 프롬프트, 숨긴 테스트, 격리된 작업 복사본, 모델명, 하네스명, 통과 여부, 작업당 비용을 남겨 두시면 결과 비교가 가능한 상태가 됩니다.