Coding agent leaderboard에서 가장 눈에 띄는 것은 보통 점수입니다.
하지만 실제 팀에서 agent를 쓰려면 최소 세 숫자를 같이 봐야 합니다.
성공률
비용
시간
Artificial Analysis Coding Agent Index도 성능뿐 아니라 cost, token usage, execution time을 함께 공개합니다.
Pass@1은 '첫 시도 성공'에 가깝습니다
Coding Agent Index v1.5는 DeepSWE v1.1, Terminal-Bench 4.0, SWE-Atlas-QnA 세 평가의 pass@1을 묶습니다.
이 지표가 중요한 이유는 retry를 무한히 허용했을 때의 최고 성능이 아니라 한 번의 시도에서 실제 해결할 확률을 보기 때문입니다.
하지만 제품에서는 실패 후 다시 실행할 수도 있습니다. 그래서 pass@1만으로 비용을 알 수 없습니다.
2점 높은 성능이 비싼 경우
가상의 두 agent를 생각해봅니다.
Agent A
Score: 58
Cost/task: $4
Time/task: 12m
Agent B
Score: 56
Cost/task: $1.5
Time/task: 5m
A가 순위는 높지만, 대량의 low-risk task에서는 B가 더 좋은 선택일 수 있습니다.
반대로 실패 비용이 매우 큰 migration task라면 2점 차이가 가치 있을 수 있습니다.
CodeBridge Mini Lab: Efficiency Frontier 그리기
내 agent 후보 3개를 같은 task set에 실행합니다.
agent,success_rate,cost_per_task,time_min
A,0.82,3.8,11.2
B,0.78,1.4,5.3
C,0.65,0.3,2.1
그다음 성공률 vs 비용, 성공률 vs 시간을 각각 그립니다.
중요한 것은 1등 하나를 고르는 것이 아니라 지배당하는 선택지를 제거하는 것입니다.
예를 들어 어떤 agent가 더 비싸고, 더 느리고, 성공률도 낮다면 이유 없이 사용할 필요가 없습니다.
개발자의 시간도 비용입니다
API 비용이 싸더라도 agent가 30분 후 실패하면 사람이 다시 context를 확인해야 합니다.
그래서 실제 비용에는 이런 항목도 들어갑니다.
API cost
+ retry cost
+ human review time
+ failure recovery time
작은 회사에서는 API 1달러보다 개발자 20분이 더 비쌀 수 있습니다.
빠른 Agent가 Workflow를 바꿀 수 있습니다
시간은 단순 UX 지표가 아닙니다.
5분 안에 결과가 나오면 개발자는 기다렸다가 즉시 검토할 수 있습니다. 40분이 걸리면 비동기 workflow와 notification이 필요해질 수 있습니다.
즉 latency는 제품 architecture에도 영향을 줍니다.
결론: Coding Agent의 '최고'는 workload마다 다릅니다
leaderboard 점수는 출발점으로 좋습니다. 하지만 운영에서는 다음 세 질문을 함께 해야 합니다.
얼마나 자주 성공하는가? 한 번 시도하는 데 얼마인가? 결과를 받기까지 얼마나 걸리는가?
이 세 축을 함께 보면 더 현실적인 agent 선택이 가능합니다.