에이전트 벤치마크 점수는 보통 숫자로 확인합니다. SWE-bench 몇 퍼센트, 함수 호출 정확도 몇 퍼센트처럼 말이지요. 하지만 이 숫자들은 채점하기 쉬운 과제에 몰려 있다는 공통점이 있습니다. 패치는 테스트로 돌려보고 함수 호출은 파싱하면 되지만, 환불 처리나 예약 변경과 같은 실제 업무 대부분은 그렇지 않습니다. 여러 턴에 걸쳐 빠진 정보를 캐내고, 정책을 지키고, 백엔드를 정확히 그만큼만 바꿔야 하지요.

최근 마이크로소프트 연구진은 'ThinkingBox'라는 샌드박스와, 그 위에 올린 507개 과제 벤치마크 ThinkingBox-Bench를 공개했습니다. 같은 업무를 에이전트에게 스무 번씩 시켜보고, 어쩌다 한 번 해내는 것과 매번 해내는 것이 얼마나 다른지를 실제 백엔드 상태로 채점해 측정한 연구인데요. 조금 더 자세하게 알아볼까요?🚀

ThinkingBox는 시뮬레이션 고객과 LLM 에이전트, 그리고 MCP 호환 도구 서버를 하나의 루프 안에서 돌립니다. 에이전트는 매 턴 고객에게 말을 걸거나 도구를 호출하고, 도구 호출은 격리된 백엔드 세션에서 실제로 실행됩니다. 대화가 끝나면 샌드박스가 최종 DB 상태와 부수효과를 추출해 과제별 검사 코드로 채점하지요.

이때 채점 방식을 눈여겨볼 만한데요. 검사는 곱으로 결합되기 때문에 하나라도 0이면 전체가 0이 됩니다. 필요한 변경이 빠져도 실패, 값이 틀려도 실패, 관련 없는 레코드를 건드려도 실패입니다. 대신 어떤 순서로 도구를 호출했는지는 보지 않습니다. 정답 궤적을 하나 정해두고 따라 하게 만드는 대신, 결과 상태만 맞으면 다른 경로도 인정하는 구조입니다.

ThinkingBox 개요. 출처: 마이크로소프트

연구진은 이 구조를 유한 지평 POMDP(Partially Observable Markov Decision Process)로 형식화합니다. 우리말로는 '부분 관측 마르코프 결정 과정'으로, 에이전트가 환경의 실제 상태를 직접 볼 수 없고 불완전한 관측값만 얻을 수 있는 상황에서 최적의 결정을 내리는 수학적 모델을 뜻하는데요. 앞에 붙은 '유한 지평'은 에피소드가 정해진 턴 수 안에 반드시 끝난다는 조건입니다. 연구진은 왜 이 틀을 가져왔을까요?

에이전트가 볼 수 없는 잠재 상태는 백엔드 상태, 고객이 아직 말하지 않은 정보, 평가용 이벤트 로그, 에피소드 상태 네 가지로 이루어집니다. 하지만 정작 에이전트에게 주어지는 관측은 고객의 발화와 도구 실행 결과뿐인데요. DB는 조회 도구로 부분적으로 엿볼 수 있을 뿐이고, 고객이 쥐고 있는 정보는 물어봐야만 드러납니다.

샌드박스 설계에서 채점 방식만큼 중요한 조건이 하나 더 있습니다. 바로 시도 간 격리인데요. 두 번의 시도가 DB 행이나 캐시된 도구 상태를 공유하면 pass@k 자체가 무의미해지므로, 매 시도마다 초기 상태로 결정적으로 리셋합니다.🛎

지금까지 살펴 본 샌드박스가 실행 틀이라면, 실제로 모델을 재는 것은 그 위에 올린 과제들입니다. 총 507개 과제가 다섯 도메인에 걸쳐 있는데요. 온라인 쇼핑몰 98개, 여행/호텔 104개, 자동차보험 100개, 은행 사내 IT 104개, 컨설팅 IT/HR 101개입니다. 이 중 477개는 백엔드 상태만 검사하고, 나머지 30개는 최종 응답까지 함께 봅니다. 예를 들어 호텔의 내부 등급처럼 고객에게 알려선 안 되는 정보를 발설했는지는 DB에 흔적이 남지 않는데요. 이렇게 DB만 봐서는 확인할 수 없는 조건이 있는 과제들만 응답까지 검사했습니다.

무엇을 검사할지만큼 중요한 게 과제를 어떻게 짜느냐입니다. 이 벤치마크에서 고객 역할은 사람이 아니라 별도의 LLM이 맡습니다. 연구진은 이 모델이 무엇을 알고 어떻게 말할지를 과제마다 정해두는데요. 그 명세가 둘로 나뉩니다. 하나는 첫 요청입니다. 시뮬레이션 고객이 생성하는 게 아니라 과제에 적힌 문장이 그대로 재생되지요. 다른 하나는 'USER CONTEXT'라는 블록으로, 과제별 행동 규칙과 고객이 공개해도 되는 사실 목록이 담겨 있습니다. 이 사실들은 의도적으로 첫 요청에서 빼놓은 것이기 때문에, 에이전트가 물어봐야만 풀리지요. 명확화 질문을 던지는 행위 자체가 요구사항인 셈입니다. 온라인 쇼핑몰 멤버십 업그레이드 과제를 예시로 살펴볼까요?🛍

• 규칙:
  주어진 컨텍스트에 없는 데이터는 지어내거나 제공하지 말 것.
  목표를 바꾸거나 화제를 옮기지 말 것.
  같은 정보를 다시 물으면 다시 제공할 것.
  집중을 유지하고, 명확하고, 참을성 있게 응대할 것.
  
  
• 추가 정보를 요청받으면 다음을 제공할 수 있음:
  - 신원: 이름 Taylor Brooks, 이메일 taylor.brooks@example.com
  - 의도: 무료 배송과 적립 포인트를 위해 TechHome Plus로 업그레이드하고 싶음

시뮬레이션 고객이 대화 내내 꺼낼 수 있는 정보는 위에 나온 게 전부입니다. 계정을 찾는 데 필요한 이메일조차 에이전트가 먼저 묻지 않으면 나오지 않지요.

또한 지켜야 할 규칙도 촘촘합니다. ID와 이름, 날짜, 숫자 같은 개체는 허용된 정보에서 글자 그대로 복사해야만 하고, 모르는 항목을 물으면 그럴듯하게 지어내는 대신 'I don't know'로 답해야 합니다. 지금 묻는 질문에만 답하고 나머지 명세를 먼저 흘리지 않으며, 에이전트가 자기 대신 일을 해달라고 하면 '그건 어시스턴트인 당신이 처리하라'고 답해야 하지요. 시뮬레이션 고객은 물으면 순순히 답하지만 묻지 않으면 먼저 말하지 않기 때문에, 에이전트가 무엇이 빠졌는지 스스로 알아채고 물어봐야만 일이 진행됩니다.🕵🏻‍♂️

말할 수 있는 것뿐 아니라 볼 수 있는 것도 좁혀졌는데요. 시뮬레이션 고객에게 넘어가는 대화 기록은 고객과 에이전트가 주고받은 말만 남기고 도구 호출과 도구 결과, 추론 흔적을 걷어낸 버전입니다. 그래서 시뮬레이션 고객은 에이전트보다 아는 게 적지요. 도구가 에러를 뱉는 장면을 볼 수 없으니 그걸 잘못 처리하는 에이전트를 구해줄 수 없고, 에이전트가 대화로 꺼내놓지 않은 백엔드 상태를 대신 읊어줄 일도 없습니다.

연구진은 12개 모델을 같은 샌드박스에 올려, 507개 과제를 하나하나 20회씩 독립적으로 시행했습니다. 매 시행마다 백엔드는 초기 상태로 리셋되니 서로 영향을 주지 않고, 모델 하나당 10,140번의 트라이얼이 쌓이는데요. 한 번만 돌리면 성공이냐 실패냐밖에 남지 않지만, 스무 번을 돌리면 그 모델이 어쩌다 맞힌 것인지 매번 맞히는 것인지가 갈라져 나옵니다.🎯

• pass@1: 한 번 시도했을 때의 평균 성공률
• pass@20: 스무 번 중 한 번이라도 성공한 과제의 비율
• pass^20: 스무 번을 모두 성공한 과제의 비율

스무 번 반복 시행 결과. 출처: 마이크로소프트

틀려도 그냥 다시 돌리면 그만인 일이라면 pass@20도 의미가 있습니다. 하지만 환불 집행이나 보험 해지처럼 되돌릴 수 없는 작업에서는 첫 시도가 곧 결과지요. 논문 또한 '발견(discovery)'과 '신뢰성(reliability)'을 구분해서 표현합니다.

리더보드에 찍히는 평균 pass@1은 다섯 도메인을 하나로 뭉친 숫자라, 도메인 사이의 차이를 가려버립니다. 도메인별로 살펴보면 온라인 쇼핑몰이 약 52%인데 자동차보험은 약 23%에 그쳤습니다. 개별 모델은 낙차가 더 크지요. Claude Opus 4.6의 평균 37.91%는 쇼핑몰 74.90%와 보험 14.65%를 모두 포함하는 값이라 어느 쪽도 대표하지 못합니다. 다섯 도메인 모두에서 50%를 넘긴 모델은 GPT-5.4와 Sonnet 4.6 둘뿐이었는데요. 한 도메인에서 강하다고 그 실력이 다른 도메인으로 옮겨간다고 보기는 어렵습니다.

또한, 모델이 크다고 잘하지도 않았습니다. 총 파라미터 675B인 Mistral-Large-3의 평균 pass@1은 4.66%로, 27B 밀집 모델 Qwen3.6-27B의 32.94%에 크게 못 미쳤지요. 연구진은 도구 사용 포맷이나 사후학습이 파라미터 수만큼 중요할 수 있다고 말합니다.

검사 코드는 통과와 실패만 알려줄 뿐, 왜 실패했는지는 말해주지 않습니다. 그래서 연구진은 실패한 트라이얼마다 메시지와 도구 호출, 도구 응답, 종료 표시를 훑어 지배적 실패 유형을 하나씩 붙였는데요. 그 결과 실패 사례의 평균 77.5%가 에이전트가 도구의 실패 응답에서 회복하지 못한 경우였습니다. GPT-5.4는 실패의 89.6%가, GLM-5.1은 88.1%가 여기 몰려 있었지요. 그렇다면 에이전트가 회복하지 못한다는 건 어떤 의미일까요?

에이전트는 도구가 실패했는데도 성공한 줄 알고 다음 단계로 넘어가기도 합니다. 논문 부록에 나온 한 예시를 보면, 인터넷 전문은행의 사내 IT 헬프데스크 과제에서 에이전트가 권한 부여 도구를 호출하자 '이미 접근 권한이 있음'이라는 에러가 돌아옵니다. 하지만 에이전트는 업데이트 계열 도구로 재시도하지도, 필요한 티켓을 만들지도 않고 고객에게 '권한을 업데이트해 드렸습니다'라고 답한 뒤 대화를 끝내지요. 검사 코드는 정답 상태에 있어야 할 접근 권한 기록이 없고 티켓도 하나 모자란 것을 잡아냈습니다.

나머지 유형은 '잘못된 상태 변경' 12.1%, '불완전한 사용자 응답' 7.9%, '필요한 상태 변경 자체를 하지 않음' 2.5% 순으로 비중이 작습니다. 그중 잘못된 상태 변경은 도구가 에러 없이 실행됐는데도 결과가 틀린 경우인데요. 에이전트가 방금 정책을 조회해놓고 그 제약을 위반하는 값을 골라 넣습니다. 보험 과제에서 이미 연 2회 분할 납부를 모두 쓴 고객에게 세 번째 유예를 승인해준 사례가 여기 해당합니다.💸

하지만 이런 실패들은 겉으로 잘 드러나지 않습니다. 연구진은 실패로 판정된 79,853개 트라이얼을 DB 대신 겉모습으로만 다시 채점해봤는데요. 대화가 질문 없이 깔끔하게 끝나고 상태를 바꾸는 도구까지 호출한 경우가 80.88%였고, 마지막 도구 응답에 에러조차 없는 경우도 67.24%였습니다. 응답이 자연스러운지, 도구를 호출했는지만 봤다면 이 실패들이 대부분 성공으로 집계됐으리라는 뜻이지요. 환불이 두 번 나가거나 엉뚱한 고객의 예약이 생기는 것처럼, 실무에서 위험한 상황은 '있어야 할 게 없는 것'보다 '없어야 할 게 생긴 것'인데요. DB를 직접 비교한 검사에서는 '잘못된 필드 값'이 77.61%, '없어야 할 부수효과'가 43.30%, '누락된 상태 변경'이 25.36%에서 확인됐습니다. 한 트라이얼이 여러 항목에 동시에 걸릴 수 있어 합이 100%를 넘습니다.

이번 실험에서 고객 역할을 맡은 시뮬레이션 고객은 일반 고객과 다릅니다. 사실을 잘못 기억하지 않고, 목표를 바꾸지 않으며, 반복된 실패에도 협조를 거두지 않지요. 따라서 까다로운 상대를 다루지 못해 생기는 실패는 이번 실험에서 잡히지 않았습니다. 게다가 이 고객을 연기한 모델이 GPT-5.4-mini여서, 최고 성적을 낸 GPT-5.4가 같은 계열이라는 이점을 누렸을 가능성도 연구진이 직접 인정하고 있습니다.

도구를 유창하게 쓰는 것과 업무를 확실하게 끝내는 것 사이에는 간극이 있습니다. 스무 번 중 한 번 잘하는 에이전트라면 일을 믿고 맡기기 조심스럽지요. 한 번의 성과가 아니라 일관적으로 임무를 성공적으로 수행하는 에이전트의 소식을 기다립니다.💫