마이크로소프트와 Hugging Face가 에이전트 평가 프레임워크 'ThinkingBox'와 이에 대응하는 벤치마크 'ThinkingBox-Bench'를 공동으로 발표했다. 채점 기준은 에이전트가 작업을 마친 뒤 백엔드 데이터베이스가 실제로 어떻게 바뀌었는가이며, 에이전트 스스로 "완료했다"고 보고하는 문구는 채점에 반영되지 않는다.
이 벤치마크는 상태를 가진 업무 프로세스 과제 507개로 구성되며, 다섯 개 업종에 걸쳐 있다. 소매 98개, 자동차보험 100개, 여행 104개, 디지털뱅킹 104개, 컨설팅 101개다. 각 과제는 깨끗한 백엔드 위에서 독립적으로 20번 실행되며, 실행 가능한 검증 스크립트가 데이터베이스의 최종 상태와 부작용을 대조한다. 바뀌어야 할 필드가 제대로 바뀌었는지, 건드려서는 안 될 레코드를 실수로 바꾸지는 않았는지 등을 확인한다.
팀은 블로그에서 이 문제를 한 문장으로 정리했다.
"The Agent Said It Was Done. The Database Disagreed."
(에이전트는 끝났다고 말했지만, 데이터베이스는 그렇게 보지 않았다.)
18개 모델의 성적
테스트에 참여한 모델은 총 18개로, 폐쇄형과 오픈 웨이트 모델이 모두 포함됐다. "20번 모두 통과" 기준으로 보면, Claude Opus 5.5와 Claude Opus 5가 공동 1위로 각각 241개 과제를 안정적으로 해결했으며 비율은 47.53%다. GPT-6 Astra는 231개, 45.56%로 3위에 올랐다. 다시 말해 가장 성적이 좋은 모델조차 과제의 절반 이상에서 매번 정확하게 해내지 못한다는 뜻이다.
가장 넓은 범위를 커버한 모델은 Kimi-K3다. 507개 과제 중 476개에서 적어도 한 번은 맞혀 93.89%의 적중률을 보였다. 하지만 20번 모두 맞힌 과제는 68개뿐이다. 같은 모델이라도 pass@20 기준으로는 거의 만능처럼 보이지만, 안정성 기준으로는 뒤쪽에 머문다. 두 수치 사이에 일곱 배 차이가 난다.
실패 원인 통계는 더 구체적이다. "정상적으로 실행을 마쳤지만 결과가 틀린" 79,853건의 시도 중 77.61%는 필드 값을 잘못 기록했고, 43.30%는 의도하지 않은 부작용을 일으켰다(둘 다 동시에 나타날 수 있다). 팀은 실패의 약 80%가 도구 호출 단계, 예컨대 매개변수를 잘못 전달하거나 호출 순서가 틀린 데서 비롯되며, 추론 자체의 오류 비중은 오히려 작다고 평가했다.
팀은 또한 "신뢰할 수 있는 과제당 비용", 즉 20번 실행에서 한 과제를 안정적으로 끝내는 데 평균 얼마가 드는지도 공개했다. GPT-5.4는 6.80달러, GPT-6 Astra는 7.45달러, Claude Opus 5.5는 7.80달러다. 구세대인 GPT-5.4가 이 항목에서는 신형 모델들보다 앞섰다.
기존 에이전트 벤치마크와의 비교
여러 번 실행해 안정성을 측정하는 방식 자체는 ThinkingBox가 처음이 아니다. Sierra가 2024년 공개한 τ-bench는 같은 과제에서 k번 연속 성공해야 하는 pass^k 지표를 제시했으며, 당시에는 소매와 항공 두 시나리오를 다뤘다. ThinkingBox가 다른 점은 규모와 판정 방식이다. 과제 수를 507개로, 업종을 다섯 개로 늘렸고 부작용을 별도의 실패 조건으로 다룬다. τ-bench 기준에서는 에이전트가 무관한 레코드를 하나 더 건드려도 반드시 감점으로 이어지지는 않았다.
이 사이트는 앞서 버클리의 Vero 벤치마크를 다룬 적이 있다. 그 테스트는 에이전트에게 43개 소프트웨어 프로젝트를 완성하게 하며, 지금까지 최고 성적은 27개 완성이다. 그쪽이 측정하는 것은 "한 번에 얼마나 큰 일을 해낼 수 있는가"다. ThinkingBox의 질문 방향은 그 반대다. 과제 자체는 어렵지 않지만, 같은 일을 20번 시켰을 때 단 한 번이라도 틀리는지를 본다. 기업 업무 프로세스에서는 후자의 실패가 훨씬 치명적인 경우가 많다. 보험금 액수나 송금 필드를 한 번 잘못 바꾸면, 아예 끝내지 못한 것보다 복구 비용이 훨씬 크다.
어떻게 활용하나
코드는 MIT 라이선스로 공개됐고, 벤치마크 데이터는 CDLA-Permissive-2.0, OpenEnv 환경은 BSD-3-Clause를 적용한다. Hugging Face의 OpenEnv 인터페이스를 통해 바로 실행할 수 있다. 로컬에 배포하려면 Docker와 Typesense로 상태를 관리해야 하며, 도구는 MCP 서버를 통해 제공된다. 또한 테스트 대상 에이전트, 모의 사용자, 평가 모델이라는 세 개의 모델 엔드포인트를 설정해야 한다.
모의 사용자와 평가자 모두 모델이 맡기 때문에, 이 과정 자체도 오차를 유발할 수 있다. 블로그는 평가 모델의 판정과 사람이 직접 매긴 라벨 사이의 일치율을 따로 공개하지 않았다. 이 수치가 나오기 전까지는 모델 간 1~2%포인트 차이를 지나치게 의미 있게 해석하지 않는 것이 좋다. 이 프로젝트에는 피츠버그대학교, UC 어바인, 노스웨스턴대학교, 컬럼비아대학교 출신 인턴들도 참여했다.
참고 출처: Hugging Face 블로그, Microsoft Research, CocoLoop, Sierra τ-bench 논문. 모델별 통과 수, 실패 유형 비율, 과제당 비용은 모두 ThinkingBox 팀이 공개한 기준을 따른다.