AI 에이전트의 소모율(Burn Rate)을 측정하다: 정확한 답변 하나의 비용을 벤치마크하다
요약
본 글은 AI 에이전트 시스템의 실제 운영 비용(Burn Rate)을 측정하는 새로운 벤치마크를 소개합니다. 기존 모델 호출 비용 대신 '정답 하나당 총 비용'을 산출하여, 복잡한 루핑 및 도구 사용 과정에서 발생하는 숨겨진 유료 왕복 비용을 계량화했습니다. 이를 통해 정확도가 비슷한 여러 LLM 간의 실질적인 운영 효율성을 비교할 수 있습니다.
핵심 포인트
- 에이전트 시스템은 단순 모델 호출 비용 외에 복잡한 루핑 및 도구 사용 비용이 발생한다.
- 새로운 벤치마크는 '정답 하나당 총 비용'을 측정하여 실제 프로덕션 환경의 효율성을 평가한다.
- Gemini 2.5 Flash가 모든 태스크를 완료하며 최고점을 기록하는 등 모델별 운영 성능 비교가 가능하다.
카글 벤치마킹 챌린지 제출작.
벤치마크: https://www.kaggle.com/benchmarks/karmendra8386/cost-per-correct
도구(Tooling): tokenecon — 에이전트 워크플로우를 위한 오픈 소스 비용 회계 · 프리프린트: https://doi.org/10.5281/zenodo.23195511
단일 모델 호출은 예측 가능한 가격을 가집니다. 하지만 루핑(looping) 에이전트는 그렇지 않습니다. 모든 도구 호출, 재시도(retry), 검색된 문서는 추가적인 유료 왕복(round-trip)을 발생시키며, 대부분의 팀은 월말에 클라우드 청구서에서 총 비용을 알게 됩니다.
그래서 저는 다른 질문을 던지는 벤치마크를 만들었습니다. "모델 비용이 얼마인가?"가 아니라 **"정답 하나당 비용이 얼마인가?"**입니다.
제가 구축한 것
세 가지 난이도 대역(쉬움: 산술, 추출, 분류 / 중간: 분석, 초안 작성, 우선순위 지정 / 어려움: 다단계 합성, 상충 관계 고려, 도출)으로 구성된 24개의 소규모 에이전트 스타일 태스크 모음입니다. 단순한 지식 문제가 아니라, 실제 프로덕션 에이전트가 수행하는 종류의 작업들입니다. 모든 태스크에는 결정론적 검사기(deterministic checker)가 있어 답이 맞거나 틀리게 됩니다. LLM 심사관이나 느낌에 의존하지 않습니다.
첫 5개의 쉬운 태스크는 현재 Kaggle에서 라이브로 운영되고 있으며, Gemini 2.5 Flash, Gemini 3.7 Flash, DeepSeek R1, GPT-OSS 120B, Qwen3 235B의 다섯 가지 호스팅 모델을 대상으로 실행됩니다.
카글 결과 (실제, 라이브 태스크 페이지에서 가져옴)
| Task | Gemini 2.5 Flash | Gemini 3.7 Flash | DeepSeek R1 | GPT-OSS 120B | Qwen3 235B |
|---|---|---|---|---|---|
| e1 — 산술: 47 × 38 + 112 | Pass | – | – | – | – |
| ... |
세 가지 주목할 만한 점이 있습니다.
1. 모든 것을 완료한 모델. Gemini 2.5 Flash는 다섯 개의 태스크 모두에서 결과를 낸 유일한 모델이며(5개 중 5개), 벤치마크 리더보드에서 100.00점으로 최고점을 기록했습니다. 다섯 개 모델이 모두 실행된 세 가지 태스크(e3–e5)에서는 15개 행 중 14개가 통과했습니다.
2. 진정한 실패는 흥미로운 실패다. 플래그십 오픈 가중치 모델인 GPT-OSS 120B가 e5에서 실패했다. 이는 다른 모든 모델이 통과한 한 줄 추출("에펠탑의 높이는 몇 미터인가?") 문제였다. 쉬운 단계(easy tiers)는 지루해야 한다고 여겨진다. 실제로도 그렇다 — 하지만 모델이 처리할 필요가 없는 작업을 떨어뜨리는 순간, 그리고 프로덕션 환경에서 그 떨어진 작업은 실제 사용자의 요청이 된다.
3. 정확도가 동점일 때, 비용이 전체 게임이다. 쉬운 작업에서는 거의 모든 최신 모델이 대부분의 경우에 정답을 맞힌다. 만약 정확도로 모델들을 구분할 수 없다면, 차별화 요소는 각 정답이 얼마의 비용이 드는지이다 — 이는 사실 대부분의 팀들이 계산하지 않는 숫자이다.
e2에 대한 솔직한 언급: 여기에 있는 세 개의 "Error" 행은 제가 처음 구축했던 패턴에서 나온 Kaggle 플랫폼 오류이며, 모델 답변이 아닙니다. 실행 자체는 완료되었지만 플랫폼이 교체된 모델을 인식하지 못했기 때문입니다. 저는 e3부터의 패턴을 수정하고 e2는 그대로 두었습니다. 왜냐하면 조용히 편집할 수 있는 벤치마크는 가치가 크지 않기 때문입니다.
나머지 절반: 라우팅 (로컬 시뮬레이션)
위의 Kaggle 작업들은 모델들을 하나씩 테스트합니다. 프로덕션 에이전트는 그렇게 작동하지 않습니다 — 라우터가 어떤 계층(tier)이 각 작업을 처리할지 결정합니다. 그래서 로컬 환경에서, 저는 tokenecon을 사용하여 24개 작업 전체를 네 가지 라우팅 전략으로 실행했으며, 이는 결정론적 점수 계산을 사용했습니다.
| 전략 | 정확도 | 총 비용 | 정답당 비용 |
|---|---|---|---|
| 계층별 라우팅 (Tiered routing) | 100% | $0.1661 | $0.0069 |
| ... |
계층별 라우팅은 더 큰 모델의 정확도를 29% 낮은 비용으로 달성했습니다 — 쉬운 작업은 저렴한 계층으로 갔고, 어려운 작업은 상위 단계로 에스컬레이션되었습니다. 하지만 마지막 행을 보세요: 가장 저렴한 계층이 정답당 가장 낮은 비용을 가지지만, 전체 작업의 3분의 2를 틀립니다. 정확도 하한선(accuracy floor) 없이 계산된 정답당 비용은 함정입니다. ≥95%의 정확도 요구 사항이 있을 때, 계층별 라우팅이 가장 저렴하고 실행 가능한 전략이며 — 이 하한선이야말로 대부분의 비용 대시보드가 놓치고 있는 부분입니다.
이 표가 무엇인지 명확히 하자면: tokenecon의 가격표에서 가져온 예시 가격을 사용한 결정론적 로컬 시뮬레이션입니다. Kaggle의 과제 페이지는 통과/실패 여부만 보고하므로, 위에 제시된 달러 금액은 Kaggle에서 나온 것이 아닙니다. 이 시뮬레이션은 팀이 실제로 제어할 수 있는 부분인 _라우팅 정책(routing policy)_을 측정합니다.
고지 사항 (Disclosures), 벤치마크에는 이것들이 필요하기 때문에
- 현재 Kaggle에서 라이브인 것은 쉬운 과제 5개뿐입니다. 중간 및 어려운 등급은 스위트와 로컬 실행에 존재하며, 이들의 Kaggle 버전이 다음에 올라올 예정입니다.
- Kaggle의 모델 카탈로그에는 Qwen3 235B가 2506 빌드로 제공되므로, 이것으로 실행되었습니다. 제가 원래 명시한 사양은 2507이었습니다.
- Gemini 3.7 Flash는 Kaggle이 템플릿에서 구축하는 벤치마크 과제에 대한 기본 플레이스홀더 모델이기 때문에 나타납니다. 이 행들은 실제 실행 결과이므로 그대로 두었습니다.
- 일부 분들이 발견할 수도 있는 임의의 비공개 과제 페이지(
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기