한 번 통과하고 19번 실패: Microsoft의 ThinkingBox가 발견한 에이전트의 신뢰성 격차

당신의 코딩 에이전트는 정말 멋지게 시연했습니다. 모듈을 리팩토링하고, 테스트를 업데이트했으며, 깔끔하게 요약까지 작성했죠. 하지만 한 가지 문제가 있습니다. 이 데모는 단지 한 번의 실행이었던 겁니다. 이번 주에 Microsoft 연구원들과 Hugging Face가 ThinkingBox의 10월 결과를 발표했습니다. ThinkingBox는 실제 비즈니스 워크플로우 작업 507개를 각각 20번씩 실행하는 벤치마크입니다. 그리고 전 세계 최고의 에이전트들이 이 중 겨우 절반에 대해서만 20회 시도 모두를 통과한다는 것을 발견했습니다.

핵심 수치는 다음과 같습니다: 총 121,680회의 시도. 79,853번의 실패. 최고 성능을 보이는 Claude Opus 5.5조차도 507개 작업 중 단 241개에 대해서만 20/20으로 통과했습니다 (47.53%). 게다가 실패한 시도의 67.24%는 도구 오류(tool error)가 전혀 발생하지 않았습니다. 대시보드 상에서는 성공처럼 보였던 거죠.

Hugging Face의 설명에 따르면, 이 벤치마크의 핵심 논지는 한 문장으로 요약됩니다: "궤적(trajectory)은 주장일 뿐이다. 데이터베이스 상태가 증거다." ThinkingBox는 에이전트가 말로 주장한 것이 아니라 실제로 백엔드 데이터베이스에서 무엇을 변경했는지에 따라 점수를 매깁니다. 이 글은 바로 그 하나의 설계 선택이 왜 이것을 올해 가장 실용적인 에이전트 평가 방식으로 만드는지에 관한 내용입니다.

초등학생도 이해할 수 있도록 설명: 변명 대신 숙제를 채점하라

두 명의 학생을 상상해 보세요. 한 명은 완벽한 숙제를 제출합니다. 다른 한 명은 왜 숙제가 완료되었는지 설명하는 아름다운 메모를 제출하죠. 대부분의 에이전트 벤치마크는 두 번째 옵션과 비슷한 것을 채점합니다. 즉, 에이전트의 채팅 기록을 읽고 "이게 맞는 것 같아?"라고 묻거나, "예상된 도구를 호출했니?"를 확인하는 식입니다.

하지만 그것들은 대리 지표(proxies)이며, 대리 지표는 거짓말을 합니다. 에이전트는 잘못된 날짜를 작성한 후에도 "예약 정보를 업데이트했습니다."라고 말할 수 있습니다. 적절하지 않은 금액으로 올바른 환불 도구를 호출할 수도 있습니다. 심지어 애초에 열 필요가 없었던 두 번째 고객 기록을 건드릴 수도 있습니다.

ThinkingBox는 트랜스크립트(transcript)를 완전히 무시합니다. 에이전트가 시작하기 전에 백엔드 데이터베이스를 스냅샷(snapshot)으로 찍습니다. 이후 에이전트는 자신의 도구들을 사용하며 작업을 진행합니다. 에이전트가 멈춘 후에는 결정론적 심사관(deterministic judges)들이 최종 데이터베이스를 요구되는 종료 상태와 비교하고, 금지된 부작용(forbidden side effects) — 즉 건드리지 않기로 되어 있던 행들(rows) — 을 검사합니다. 트랜스크립트는 절대로 판정 과정에 포함되지 않습니다. 이 논문의 제목(arXiv 2608.19741) 자체가 전체 주장을 담고 있습니다: "한 번의 성공이 신뢰성을 의미하지 않는다."

Capability vs dependability

작동 방식: 507개 작업, 각각 20개의 새로운 백엔드 사용

설정은 추론하기 쉽도록 의도적으로 단순합니다:

1. 리테일, 여행 및 숙박업, 자동차 보험, 네오뱅크 IT, 컨설팅 IT/HR 등 분야에 걸친 507개 비즈니스 워크플로우 — 주문 수정, 보험 청구서 제출, 여행 재예약, IT 티켓 해결 등을 포함합니다.
2. MCP 서버로 노출된 도구들을 사용하여, 모델 컨텍스트 프로토콜(Model Context Protocol)을 사용하는 모든 에이전트가 플러그인할 수 있습니다.
3. 모든 실행은 격리되고 새로 초기화된 백엔드에서 이루어집니다. 7번째 시도는 6번째 시도에 의해 오염될 수 없습니다.
4. 결정론적 심사관이 최종 데이터베이스를 요구되는 종료 상태와 비교하고 부작용을 스캔합니다. LLM 기반의 채점은 없으며, 느낌(vibes)에 의존하지 않습니다.
5. 각 작업은 20번 반복되며, 세 가지 방식으로 보고됩니다:

• pass@1 — 단일 시도 중 성공한 비율입니다. 첫 시도의 품질을 나타냅니다.
• pass@20 — 20번의 시도 중 최소 한 번은 해결된 작업의 비율입니다. 모델이 좋은 날 할 수 있는 최대 역량을 의미합니다.
• observed 20-of-20 — 기록된 모든 시도에서 통과한 작업을 말합니다. 고객에게 약속할 수 있는 신뢰성(Dependability)을 나타냅니다.

세 가지를 모두 보고하는 것이 진정한 기여입니다. 대부분의 리더보드는 pass@1 같은 것만 보고하고 나머지 부분은 독자가 상상하도록 둡니다. ThinkingBox는 "할 수 있음(can do)"과 "신뢰성 있게 할 수 있음(reliably does)" 사이의 격차를 노출시키며 — 이 격차에 실패가 존재합니다.

The three metrics

SOTA: 121,680번의 시도가 오늘날 모델에 대해 말해주는 것들

신뢰성 붕괴는 현실적이며 가파르다. Claude Opus 5는 시도 횟수가 한 번에서 스무 번으로 증가함에 따라 pass@1이 66.50%에서 47.53%로 하락한다. Kimi-K3는 57.37%에서 17.60%로 하락한다. Hugging Face의 게시물은 Kimi 수치 중 가장 심각한 버전을 추가했다: 이 모델은 최소 한 번에 93.89%의 작업을 해결하지만, 신뢰할 수 있는 비율은 **13.41%**에 불과하다. 결국 거의 모든 것을 해결할 수 있는 모델이라도, 신뢰할 수 있는 것은 극히 일부에 불과하다. (정확한 소수점 표기는 논문 초록과 HF 게시물 간에 약간 다르므로 특정 셀을 인용하기 전에 논문의 표를 읽으십시오. 방향성은 어디에서나 동일합니다.)

실패의 해부학은 실행 가능하다. 79,853번의 실패한 시도 중: 대략 77.6%는 잘못된 필드 값을 가졌고, 43%는 의도하지 않은 부작용을 만들었으며, 25%는 필수 변경 사항을 놓쳤다. 이들은 겹치는데, 한 번의 시도가 여러 방식으로 실패할 수 있기 때문이다. 근본 원인별로 보면: **79.9%가 도구 처리(tool handling)**에 기인했고, 10.3%는 잘못된 업데이트, 7.0%는 불완전한 해결, 2.9%는 아무런 조치도 취하지 않은 경우였다. 도구 처리가 지배적이다 — 에이전트가 잘못된 도구를 선택했거나, 스키마를 오독했거나, 매개변수를 처리하는 데 실패했다. 만약 여러분이 에이전트를 구축한다면, 이것이 가장 큰 영역이며, 이는 모델만큼이나 도구의 _표면 설계(surface design)_가 중요하다는 것을 시사한다.

Failure anatomy

침묵하는 실패가 가장 무서운 유형입니다. 실패한 시도 중 67.24%는 최종 도구 오류(final tool error) 없이 끝났습니다. 에이전트가 충돌하거나, 루프에 빠지거나, 속도 제한(rate limit)에 걸리지 않았습니다. 유효한 상태 변경 액션(state-changing actions)을 수행한 후 자신감 있는 요약본을 생성했습니다. 일반적인 운영 모니터링 — 오류나 시간 초과를 감시하는 종류의 모니터링 — 에서는 이를 성공으로 표시했을 것입니다. 하지만 나중에 알게 됩니다. 고객이나 감사자, 또는 조정(reconciliation) 작업으로부터 말입니다.

도메인(Domain)이 엄청나게 중요합니다. 리테일 분야는 평균 59.52%의 pass@1을 기록했고; 자동차 보험은 평균 **33.83%**를 기록했습니다. 보험 워크플로우는 더 많은 정책 규칙과 정확해야 하는 더 많은 필드를 포함하고 있습니다. 이는 비즈니스가 실제로 자동화할 만한 바로 그 종류의 작업입니다.

표면적인 가격이 실제 가격은 아닙니다. 이 게시물은 신뢰할 수 있는(dependable) 태스크당 비용을 추정했습니다: GPT-5.4는 약 $6.80, GPT-6 Astra는 $7.45, Claude Opus 5.5는 $7.80입니다. 더 적은 시도로도 되지만, 더 많은 수동 정리(human cleanup)가 필요한 저렴한 모델은 완성된 태스크당 비용이 더 많이 듭니다. 토큰당 가격과 신뢰할 수 있는 결과물당 가격은 다르므로 검증을 위한 예산을 책정해야 합니다.

Cost and domains

솔직한 주의사항: 507 워크플로우는 잘 설계되었지만, 귀사의 시스템을 위한 합성(synthetic) 대체재일 뿐입니다. 모든 결과가 하나의 에이전트 하네스에서 나오므로, 모델 순위는 보편적인 순서라기보다는 스냅샷으로 간주하십시오. 그리고 심사위원들은 누군가가 작성한 최종 상태만큼만 좋으므로, 어떤 집계(aggregate)를 신뢰하기 전에 수동으로 실패 사례를 샘플링하는 것이 좋습니다. 이 프레임워크는 GitHub에서 MIT 라이선스로 제공되며(microsoft/thinkingbox), 데이터셋은 Hugging Face에 있습니다(microsoft/ThinkingBox-Bench) — 저자들은 여러분이 리더보드를 읽는 것뿐만 아니라 그 방법을 훔치기를 원합니다.

운영 환경에서의 현실 점검 (The production reality check)

1. pass@1이 아닌 전체 실행 성공률(all-runs-pass)을 측정하세요. 워크플로우가 항상 성공해야 하는 경우(환불, 예약, 청구 지급 등), 현재 벤치마크는 pass@1이 제공할 수 있는 것을 체계적으로 과대평가한다고 말합니다. 각 평가 작업을 10~20회 실행하고 전체 분포를 보고하세요.
2. 채팅이 아닌 데이터베이스를 평가하세요. 먼저 필요한 최종 상태(end state)를 작성하세요: 변경되어야 하는 정확한 행과 필드, 그리고 변경되어서는 안 되는 행들입니다. 전후 스냅샷을 찍고 데이터를 비교하여(diff), 관련 없는 기록들이 변하지 않았음을 단언하세요. 최소한의 버전은 ThinkingBox가 필요 없습니다. 단순히 고정된 환경(fixture), 데이터 비교(diff), 그리고 규율만 있으면 됩니다.
3. 도구 처리 방식을 먼저 수정하세요. 근본 원인의 79.9%에서 도구 표면(tool surface)—스키마, 설명, 매개변수 이름 지정—이 스택에서 가장 효과가 큰 수정 지점입니다. 이는 이 시리즈 초반의 harness 교훈을 되풀이합니다: 에이전트가 무엇을 할 수 있는지는 모델이 아니라 harness가 결정합니다.
4. 조용한 잘못된 쓰기(silent wrong writes)를 위해 계측하세요. 오류율 대시보드는 실패 사례의 67%를 놓칩니다. 최종 상태에 대한 결정론적 심사관인 조정 확인(Reconciliation checks)은 쓰기 접근 권한이 있는 모든 에이전트의 프로덕션 모니터링에 포함되어야 합니다.
5. 토큰당 가격이 아닌 검증된 작업당 가격을 책정하세요. $6.80/$7.45/$7.80라는 수치는 다음 점을 강조합니다: 저렴한 모델의 청구서가 재시도와 정리(cleanup)를 계산하면 더 커질 수 있다는 것입니다. 검증 루프를 포함하여 평가 harness 비용을 모델링하세요.

주요 시사점

1. 한 번의 성공이 신뢰성을 의미하지는 않습니다. 역량(Capability, pass@20: Kimi-K3 기준 93.9%)과 의존성(dependability, 20개 중 20개: 13.4%)은 서로 다른 수치이며, 고객이 느끼는 것은 후자입니다.
2. 궤적은 주장일 뿐이고, 데이터베이스가 증거입니다. 성적표나 도구 호출 목록을 평가하는 것은 대리 지표(proxy)에 불과하며, 최종 상태를 필수 종료 상태와 비교하여 차이를 확인하는 것이 그 대리 지표를 제거합니다.
3. 실패의 2/3는 조용합니다. 충돌이나 오류, 시간 초과는 없지만, 자신감 있는 요약만 남기고 잘못된 쓰기(wrong write)가 발생합니다. 오직 상태 검사(state checks)만이 이를 포착할 수 있습니다.
4. 신뢰성 측면에서는 모델 선택보다 도구 설계가 중요합니다. 근본 원인의 79.9%는 도구 처리와 관련됩니다. 모델을 교체하기 전에 도구의 표면을 다듬으십시오.
5. 이것은 단순한 리더보드가 아니라 템플릿입니다. 환경, 과제, 심사위원(judges) 모두 공개되어 있습니다. 어떤 도메인이든 여러분 자신의 워크플로우를 위해 이 방법을 가져가세요.

모든 수치는 arXiv 논문 (2608.19741)과 Hugging Face 작성 자료에 요약된 Microsoft/Hugging Face ThinkingBox 10월 결과를 기반으로 하며, 2026년 10월 커버리지를 통해 확인되었습니다. 소수점의 미세한 차이는 논문 초록과 블로그 게시물(실행 구성/버전 명명 규칙) 간에 존재하지만, 방향성과 크기는 출처 전반에서 일관됩니다.

보조 노트북: 이 포스트를 위한 실행 가능한 튜토리얼 — 여기서 다운로드 (Colab/Jupyter에서 열기).