요즘 모델 성능 비교 글을 읽다 보면 "어떤 모델이 몇 점을 받았다"는 숫자만 눈에 들어옵니다. 그런데 2026년 들어서는 점수 자체보다 그 점수를 얻기 위해 얼마를 태웠는지가 더 중요한 문제가 됐습니다. 특히 에이전트 평가에서는 이제 학습보다 평가가 더 비싸거나, 최소한 무시할 수 없을 정도로 커졌습니다. 실무팀 입장에서는 이걸 모르고 벤치마크를 설계하면 예산이 먼저 터지고, 결과는 생각보다 신뢰하기 어려운 상황을 맞게 됩니다.
정적 벤치마크 시절에는 비용이 크더라도 구조가 단순했습니다. 정해진 문제를 한 번씩 돌리고 정확도나 점수를 집계하면 됐습니다. 하지만 에이전트 평가는 다릅니다. 한 문제를 푸는 과정이 길고, 툴 호출이 섞이고, 스캐폴드 구성에 따라 토큰 사용량이 급변합니다. Hugging Face 블로그에서 정리한 수치를 보면 Holistic Agent Leaderboard(HAL)는 9개 모델과 9개 벤치마크에 대해 21,730개의 롤아웃을 실행하는 데 약 4만 달러를 썼습니다. 이건 그냥 "조금 비싸다" 수준이 아니라, 실험 설계 자체를 다시 생각해야 하는 수준입니다.
더 눈에 띄는 건 단일 벤치마크의 비용입니다. 같은 글에서 GAIA 벤치마크 한 번이 프런티어 모델 기준 캐시 전 비용으로 2,829달러까지 올라간다고 정리합니다. 이 수치가 무서운 이유는, 대부분의 팀이 평가를 한 번만 하지 않기 때문입니다. 프롬프트를 바꾸고, 툴 체인을 바꾸고, 재시도를 넣고, 실패 케이스를 따로 측정하면 비용은 금방 몇 배로 커집니다. 결국 "점수 비교"가 아니라 "실험 경제성"이 평가 체계의 일부가 된 셈입니다.
핵심은 평가 대상이 더 이상 모델 하나가 아니라는 점입니다. 실제로 측정되는 것은 모델 × 스캐폴드 × 토큰 예산 × 실행 환경의 곱입니다. 예를 들어 같은 모델을 써도 브라우저 자동화 에이전트를 붙이느냐, 툴 사용 루프를 몇 단계로 허용하느냐, 실패 시 재시도 정책을 넣느냐에 따라 비용이 10배 이상 벌어질 수 있습니다. Exgentic의 2만2천 달러 규모 스윕에서 동일한 작업에 대해 비용 차이가 33배까지 벌어졌다는 사례는 이 점을 잘 보여줍니다.
문제는 비용이 늘어도 성능이 비례해서 좋아지지 않는다는 데 있습니다. HAL 사례에서는 어떤 구성은 40% 정확도에 1,577달러가 들었고, 다른 구성은 42% 정확도를 171달러 수준에서 냈습니다. 성능 차이는 미미한데 비용은 거의 한 자릿수 이상 차이 나는 식입니다. 실무 관점에서 보면 "최고 점수"보다 "Pareto 효율"을 봐야 한다는 뜻입니다. 점수 2%를 더 얻으려고 비용을 8배 쓰는 구조는 리더보드에는 남아도 제품에는 잘 안 남습니다.
많은 팀이 여기서 한 번 더 실수합니다. 단발성 점수로 결론을 내려버리는 겁니다. 에이전트는 실행 편차가 크기 때문에 한 번 잘 된 결과를 평균 성능처럼 착각하기 쉽습니다. 그런데 반복 실행으로 일관성을 보려면 비용이 다시 배수로 늘어납니다. 같은 글은 HAL 스타일 평가에서 셀당 8회 재실행을 걸면 4만 달러가 대략 32만 달러 수준까지 커질 수 있다고 지적합니다. 이건 단순 추정이 아니라, 신뢰도를 확보하려면 원래 한 번에 끝날 일이 아니라는 뜻입니다.
실무팀에게 더 중요한 건 "재현 가능한 의사결정"입니다. 예를 들어 새 에이전트 프레임워크를 도입할지 말지 판단할 때, 한 번 잘 나온 데모 점수보다 5회 반복에서 분산이 어느 정도인지가 더 중요합니다. 고객 지원 자동화, 내부 리서치 에이전트, 코드 생성 워크플로우처럼 실패 비용이 있는 업무는 더 그렇습니다. 평가 비용을 줄이겠다고 반복 측정을 아예 빼버리면, 나중에는 운영 중 장애 비용으로 더 크게 갚게 됩니다.
첫째, 전체 벤치마크를 매번 다 돌리지 말고 단계형 평가를 설계해야 합니다. 초기 실험에서는 작은 샘플과 저비용 시나리오로 후보를 걸러내고, 마지막 단계에서만 고비용 평가를 쓰는 방식이 현실적입니다. 정적 벤치마크에서 Flash-HELM류 접근이 먹혔던 이유도 여기에 있습니다. 에이전트 평가에서는 압축 효과가 덜하더라도, 최소한 "아무 후보나 풀 스윕하지 않는 체계"는 필요합니다.
둘째, 성능 지표를 정확도 하나로 두지 말아야 합니다. 비용당 성공률, 실행 시간, 실패 유형, 툴 호출 수, 토큰 소비량을 함께 봐야 합니다. 그래야 실제 운영비와 연결됩니다. 예를 들어 브라우저 에이전트라면 "완료율"과 함께 "실패 1건당 평균 토큰 소비"를 같이 보면 최적화 포인트가 훨씬 빨리 드러납니다.
셋째, 스캐폴드 자체를 1급 변수로 관리해야 합니다. 프롬프트와 툴 구성은 부수 요소가 아니라 비용 구조를 바꾸는 핵심 파라미터입니다. 스캐폴드 버전을 분리 기록하지 않으면 같은 모델인데 왜 비용이 튀었는지 원인 추적이 안 됩니다. 평가 대시보드에 모델명만 남기고 스캐폴드를 남기지 않는 팀은 나중에 꼭 헤맵니다.
제품팀은 평가를 예산 항목으로 먼저 잡아야 합니다. 모델 사용료는 계산하면서 평가용 반복 실행 비용은 뒤늦게 보는 경우가 많은데, 이제는 반대여야 합니다. 특히 출시 직전 성능 검증, A/B 비교, 회귀 테스트를 생각하면 평가 비용은 고정비에 가깝습니다.
리서치팀은 벤치마크 선택부터 재검토할 필요가 있습니다. 실제 제품과 상관없는 리더보드 점수를 높이는 데 실험비를 쓰기보다, 자신의 도메인에서 재현 가능한 미니 벤치마크를 따로 갖는 편이 낫습니다. 예를 들어 세일즈 지원 에이전트 팀이라면 공개 코딩 벤치마크보다 "내부 CRM 질의 50개"가 더 강한 평가 세트일 수 있습니다. 이때 중요한 건 문제 수보다 분류 체계입니다. 검색형, 요약형, 다단계 액션형, 외부 툴 의존형으로 나누면 적은 샘플로도 좋은 판단이 가능합니다.
또 하나, 비용 절감은 모델 교체보다 실행 구조 단순화에서 더 크게 나오는 경우가 많습니다. 툴 호출 횟수 제한, 실패 시 즉시 중단 규칙, 장문 중간 사고흐름 강제 축소, 결과 검증 단계 축약 같은 운영 설계가 의외로 큰 차이를 만듭니다. "더 싼 모델"만 찾지 말고 "덜 비싼 실행 구조"를 먼저 찾는 편이 보통 더 빠릅니다.
예전에는 학습이 비싸고 평가는 그 뒤에 붙는 절차였습니다. 지금은 특히 에이전트 영역에서 그 순서가 깨졌습니다. 평가가 비용, 신뢰도, 출시 속도, 제품 위험을 동시에 결정합니다. 그래서 앞으로 좋은 팀은 모델만 잘 고르는 팀이 아니라 평가 체계를 잘 설계하는 팀이 될 가능성이 큽니다. 점수표를 많이 모으는 것보다, 어떤 점수가 어떤 비용 구조에서 나왔는지 설명할 수 있는 팀이 더 강합니다.
마지막으로 기억할 체크리스트를 남깁니다.
참고 소스: Hugging Face Blog, AI evals are becoming the new compute bottleneck (2026-04-29)
