Executive Summary

주요 수치

앞의 두 숫자는 같은 모델이 같은 과제를 스무 번 돌렸을 때 벌어진 격차입니다. 뒤의 둘은 실패한 시행이 겉으로 어떻게 보였는지를 나타냅니다.

출처: arXiv 2608.19741 (2026-08-20) · 업무 과제 507개, 모델 14종, 과제마다 20회 반복

지금까지 에이전트를 실행 가능한 환경에서 채점하는 벤치마크는 대체로 코드 쪽에 몰려 있었습니다. 패치는 테스트를 돌려 보면 되고, 함수 호출은 스키마와 대조하면 됩니다. 그런데 예약을 바꾸고 환불을 처리하고 보험 청구를 갱신하는 일은 답 하나로 환원되지 않습니다. 여러 차례 대화를 주고받아 빠진 정보를 받아 내야 하고, 사내 정책을 지켜야 하며, 마지막에 백엔드가 정확히 맞는 상태로 남아야 합니다.

Thinkingbox는 그 조건을 갖춘 실행 환경입니다. 과제마다 리셋 가능한 백엔드 데이터베이스, MCP 호환 도구 세션, 도메인 정책 문서, 지식베이스, 그리고 사람 역할을 대신하는 시뮬레이션 사용자가 붙습니다. 사용자 쪽에는 처음부터 밝히지 않는 사실이 따로 담겨 있어, 에이전트가 물어봐야만 나옵니다. 현실의 요청이 대개 정보가 빠진 채로 들어온다는 점을 그대로 옮긴 설계입니다.

논문은 기존 벤치마크와의 차이를 다섯 개 축으로 정리해 놓았습니다. 도구와 API를 쓰는지, 사용자와 대화를 주고받는지, 상태가 남는 백엔드가 있는지, 시키지 않은 부작용까지 검사하는지, 과제를 MCP 서버로 노출하는지입니다. SWE-bench는 저장소 상태를 다루지만 도구 호출도 사용자 대화도 없습니다. BFCL과 ToolBench 계열은 도구 호출은 있으나 상태가 남지 않습니다. AppWorld는 상태와 부작용 검사를 갖췄지만 사용자와 말을 주고받지 않고, MCP-Atlas는 실제 MCP 서버를 쓰는 대신 상태 저장 백엔드가 없습니다. 가장 가까운 것은 τ-bench 계열로 대화와 상태를 함께 갖췄고 부작용 검사는 부분적입니다. 다섯 축을 모두 채운 항목은 Thinkingbox-bench 하나입니다.

벤치마크 쪽은 507개 과제를 다섯 도메인으로 나눠 담았습니다. 도메인마다 정책 문서 분량과 과제 하나에 필요한 행동 수가 다릅니다.

채점은 최종 대화문이 아니라 백엔드의 마지막 상태를 봅니다. 과제마다 실행 가능한 검사 항목이 붙고, 그 항목이 전부 참일 때만 통과입니다. 검사는 필요한 상태 변경이 일어났는지, 값이 맞는지, 그리고 시키지 않은 변경이 딸려 들어가지 않았는지를 함께 봅니다. 엉뚱한 고객 레코드를 건드리거나 권한 없는 갱신을 얹은 경우가 이 항목에서 걸립니다. 도구를 어떤 순서로 호출했는지는 따지지 않으므로, 경로가 달라도 세계의 최종 상태가 같으면 통과입니다.

507개 가운데 477개는 이 백엔드 검사만으로 판정합니다. 나머지 30개에만 최종 응답의 조건을 추가로 겁니다. 호텔의 비공개 정보를 발설하지 않기, 정책상 거절해야 하는 결과를 사용자에게 분명히 알리기처럼, 데이터베이스 상태로는 확인할 수 없는 조건이 있는 과제들입니다. 글쓰기 품질을 재려는 장치가 아니라, 상태 검사로 잡히지 않는 요건만 골라 붙인 예외입니다.

모델 14종을 같은 샌드박스에 넣고, 같은 시스템 프롬프트와 같은 도구 정의와 같은 정책 아래에서 과제마다 20회씩 독립 실행했습니다. 성적이 가장 좋은 GPT-5.4의 평균 pass@1은 65.36%였습니다. 이 값만 보면 열 번 중 예닐곱 번은 해내는 모델입니다.

여기서 독립 실행이란 시도마다 백엔드를 초기 상태로 되돌리고 도구 세션을 새로 여는 것을 뜻합니다. 시도 두 개가 데이터베이스 행이나 캐시된 도구 상태, 앞선 시도가 남긴 부작용을 나눠 쓰면 반복 시행으로 잰 값 자체를 믿을 수 없다는 것이 저자들의 설명입니다. 20회는 같은 대화를 그대로 되감은 것도 아닙니다. 사용자 역할을 맡은 모델이 온도 0.3으로 답하기 때문에 시도마다 사용자의 말투와 표현이 달라집니다. 그래서 스무 번을 모두 통과한 비율은 고정된 대화 하나를 스무 번 재생했을 때의 성적이 아니라, 조금씩 다르게 들어오는 요청 앞에서도 매번 같은 결과를 내는지를 잰 값입니다.

같은 모델의 결과를 두 방향으로 다시 세면 그림이 달라집니다. 스무 번 중 한 번이라도 성공한 과제는 91.12%였고, 스무 번을 모두 통과한 과제는 25.25%였습니다. 앞의 값은 성공하는 경로가 어딘가에 존재한다는 뜻이고, 뒤의 값은 그 경로를 매번 다시 찾아낸다는 뜻입니다. 두 값이 이만큼 벌어져 있다면, 한 번 돌려서 얻은 성공은 다음 실행을 보장하지 못합니다.

과제 단위로 세어 보면 구간이 더 또렷합니다. GPT-5.4는 507개 중 128개를 스무 번 모두 성공했고, 45개는 스무 번 모두 실패했습니다. 남는 334개, 그러니까 전체의 3분의 2가 시도할 때마다 결과가 갈린 과제입니다. 도입 심사에서 시연으로 골라 보여 주기 가장 쉬운 것도, 운영에 올린 뒤 재현이 안 돼 문제가 되는 것도 이 구간입니다.

모델을 나란히 놓으면 순위가 지표에 따라 뒤집힙니다. 평균 성공률만 보면 DeepSeek-V4-Pro가 Claude Opus 4.6보다 앞서지만, 스무 번을 모두 통과한 비율은 반대입니다.

Claude Opus 4.6은 아예 손도 못 댄 과제가 152개로 DeepSeek-V4-Pro의 두 배에 가깝습니다. 그런데 되는 과제에서는 스무 번을 채우는 비율이 네 배 가까이 높았습니다. 잘하는 범위는 좁아도 그 안에서는 흔들림이 적은 모델과, 넓게 건드리지만 매번 같은 결과를 못 내는 모델이 갈립니다. 이 둘을 평균 성공률 한 줄로 비교하면 도입 판단이 뒤집힐 수 있습니다.

모델 크기로 설명되지 않는 지점도 있습니다. Mistral-Large-3은 총 파라미터가 수천억 규모인데도 여러 도메인에서 훨씬 작은 Qwen 모델보다 낮은 점수를 받았습니다. 반대로 같은 Qwen 계열에서 9B를 27B로 키웠을 때는 평균 성공률이 5.41%에서 32.94%로 올라갔습니다. 저자들은 도구 호출 형식과 에이전틱 후속 학습, 추론 모드, 환경에 대한 강건성이 명목 파라미터 수만큼이나 크게 작용한다고 봤습니다.

도메인별로도 성적이 크게 흔들립니다. 모델 평균으로 소매는 52% 안팎인데 자동차보험은 23% 수준입니다. 다섯 도메인 전부에서 50%를 넘긴 모델은 GPT-5.4와 Claude Sonnet 4.6 둘뿐이었습니다. 그 둘 사이에도 결이 다릅니다. Sonnet 4.6은 도메인별 성적이 51.14%에서 68.93% 사이에 머물러 낙폭이 작았고, GPT-5.4는 소매 76.33%에서 컨설팅 54.60%까지 내려갑니다. Claude Opus 4.6은 소매에서 74.90%를 받고 자동차보험에서 14.65%로 떨어졌고, GPT-5.2도 소매 70.20%에서 자동차보험 22.40%로 내려앉았습니다. 종합 점수만 보고 우리 업무에 써도 되는지를 판단할 수는 없습니다.

저자들은 판정 방식 자체를 시험대에 올렸습니다. 12개 모델의 유효 시행 121,680건 가운데 실패로 판정된 79,853건을 골라, 백엔드 상태를 보지 않는 약한 기준으로 다시 채점했습니다. 세 기준은 점점 엄격해집니다. 먼저 대화가 정상적으로 닫혔는지, 다음으로 상태를 바꾸는 도구 호출이 한 번이라도 있었는지, 마지막으로 최종 도구 응답에 에러가 없었는지입니다.

실패 시행의 84.86%가 정상 종료로 끝났고, 80.88%는 거기에 더해 데이터베이스를 실제로 바꾸는 도구 호출까지 마쳤습니다. 67.24%는 마지막 도구 응답에 에러 표시조차 없었습니다. 응답만 보거나 도구 호출만 보는 시야에서는 잘못된 실행 상당수가 완수된 것처럼 보인다고 논문은 적었습니다.

같은 79,853건을 실행 가능한 상태 검사로 다시 보면 다른 장면이 나옵니다. 98.95%가 데이터베이스 해시 불일치로 걸렸고, 77.61%는 필드 값이 틀렸으며, 43.30%는 시키지 않은 변경을 추가로 남겼습니다. 25.36%는 반대로 필요한 변경이나 부작용을 빠뜨렸습니다. 로그가 조용한 것과 상태가 맞는 것은 서로 다른 사실이었습니다.

실패의 유형을 나눠 보면 어디서 어긋나는지가 드러납니다. 저자들은 실패한 궤적마다 지배적인 실패 유형 하나를 배정했습니다.

논문 부록에 실린 자동차보험 사례 하나가 두 번째 유형을 그대로 보여 줍니다. 결제가 7일 밀린 고객이 납부 유예를 요청하고, 에이전트는 고객을 조회하고 증권을 확인하고 본인 확인까지 마칩니다. 그리고 납부 유예 이력을 조회해 최근 12개월간 2회라는 값을 받습니다. 이 고객 등급의 상한이 2회입니다. 에이전트는 방금 읽은 그 값을 티켓 설명에 적어 넣은 뒤, 세 번째 유예를 승인합니다.

마지막 응답은 이렇게 끝납니다. 본인 확인이 완료됐고, 납부 기한을 연장했으며, 계정에 12개월간 3회 이력이 기록됐다고 알린 다음, 티켓을 해결 상태로 닫습니다. 모든 도구 호출이 에러 없이 실행됐고 대화도 매끄럽게 마무리됐습니다. 정답 상태는 유예를 승인하지 않고 요청을 거절하는 것이었습니다. 정책 위반의 근거가 될 숫자를 에이전트 스스로 말해 놓고, 그 옆에서 정책을 어긴 셈입니다.

이 결과를 도입 심사로 옮기면 바뀌는 것은 세 가지입니다. 첫째는 횟수입니다. 한 번의 성공을 근거로 삼는 대신 같은 시나리오를 반복해 돌리고, 몇 번 중 몇 번이 통과했는지를 함께 적습니다. 논문이 쓴 20회는 연구용 설정이지만, 사내 검증에서 반복 횟수를 줄이더라도 한 번으로 끝내지 않는 것만으로 앞서 본 334개 구간의 상당 부분이 드러납니다.

둘째는 검증 데이터를 어디서 뜨느냐입니다. 에이전트의 응답 텍스트와 도구 호출 로그는 만들기 쉽고 모으기도 쉬워서 QA 지표의 기본값이 되기 마련입니다. 이 논문이 보여 준 것은 그 데이터가 판정 근거로는 약하다는 사실입니다. 통과 여부를 가르려면 작업 전후의 백엔드 상태를 뜨고, 정답 상태와 대조하고, 시키지 않은 변경이 딸려 들어갔는지까지 세어야 합니다. 리셋 가능한 테스트 백엔드와 과제별 정답 상태를 갖추는 일이 평가 준비 작업의 대부분을 차지한다는 뜻이기도 합니다.

이 준비물이 평가에서만 쓰이는 것은 아닙니다. 논문의 설계에서는 통과 여부를 가른 검사 항목이 그대로 학습 보상이 됩니다. 같은 과제 세계에 다른 에이전트를 얹어 다시 재 볼 수도 있고, 검사 하나하나를 신호로 삼아 모델을 손볼 수도 있습니다. 정답 상태를 정의하는 비용은 평가 한 번으로 소진되지 않습니다.

셋째는 어느 업무에서 재느냐입니다. 같은 모델이 소매에서 74.90%를 받고 자동차보험에서 14.65%로 떨어지는 폭을 보면, 공개 리더보드 순위는 우리 업무의 성적을 대신해 주지 못합니다. 정책 문서가 길고 조건 판정이 얽힌 업무일수록 격차가 벌어집니다.

읽을 때 함께 봐야 할 조건도 있습니다. 이 벤치마크의 과제는 비공개 기업 사례를 합성으로 재구성한 것이고, 저자들도 실제 업무 분포를 대표한다고 주장하지 않습니다. 정답 상태가 하나로 정해지는 과제만 남겼기 때문에, 해결 방법이 여럿인 업무는 애초에 빠져 있습니다. 사용자 역할은 GPT-5.4-mini 하나로 고정돼 있어 말을 바꾸거나 협조하지 않는 상대는 등장하지 않습니다. 응답 조건이 붙은 30개 과제의 판정도 같은 GPT-5.4-mini가 맡습니다. 실제 창구에서 벌어지는 일은 이보다 어렵지 쉽지 않습니다.

논문은 8월 20일 올라온 프리프린트로 아직 동료 심사를 거치지 않았습니다. 저자는 피츠버그대·노스웨스턴대·UC 어바인 연구자들과 마이크로소프트 소속 연구자들이며, 공동 1저자들의 작업은 마이크로소프트 인턴십 기간에 이뤄졌다고 각주에 적혀 있습니다. 프레임워크는 microsoft/thinkingbox에, 시나리오와 도구 서버는 microsoft/thinkingbox-data에 나뉘어 공개돼 있습니다.

페블러스 블로그에서는 과업은 성공하고 규칙은 어긴 에이전트를 잡아내는 벤치마크도, 현장 실패 3,607건을 유형으로 분류한 기록도 다룬 적이 있습니다. 이번 논문은 그 논의에 반복 시행이라는 축을 더합니다. 원문은 arXiv 2608.19741에서 확인할 수 있습니다.

(주)페블러스 데이터 커뮤니케이션팀
2026년 8월 22일

학술 논문

• 1.Li, Z. et al. (2026). "One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows." arXiv:2608.19741.
• 2.Yao, S., Shinn, N., Razavi, P., Narasimhan, K. (2024). "τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains." arXiv:2406.12045.
• 3.Barres, V., Dong, H., Ray, S., Si, X., Narasimhan, K. (2025). "τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment." arXiv:2506.07982.

코드·데이터 저장소

• 4.Microsoft. microsoft/thinkingbox. GitHub. — 샌드박스 프레임워크(tb CLI, MCP 세션 프록시, 평가 하네스)
• 5.Microsoft. microsoft/thinkingbox-data. GitHub. — 507개 과제 시나리오·도구 서버 패키지