ThinkingBox: 일을 끝냈다는 말 대신 실제 DB 상태로 AI를 평가하기

배경과 문제

LLM 에이전트 평가는 실행 가능한 결과물이 있는 영역부터 발전해 왔다. 코드 수정은 테스트로, 함수 호출은 파싱과 실행으로 확인할 수 있다. 그러나 예약 변경, 환불 처리, 보험 청구 수정, 사내 권한 요청처럼 코드도 아니고 함수 호출 한 번으로 끝나지도 않는 업무는 다르다. 사용자에게 빠진 정보를 여러 차례 물어야 하고, 도메인 정책을 지켜야 하며, 서로 의존하는 도구를 순서대로 호출해서 올바른 레코드만 올바르게 바꿔야 한다.

따라서 이 연구는 두 가지 질문을 나누어 묻는다. 에이전트가 대화를 매끄럽게 끝냈는지와 실제 업무 기록을 올바르게 바꿨는지는 서로 다르다. 한 번의 성공이 우연이 아니었는지 확인하려면, 같은 초기 상태에서 독립적으로 다시 실행했을 때의 결과도 함께 보아야 한다.

기존 접근의 한계

함수 호출 중심 평가는 호출이 형식상 맞았는지는 알 수 있어도, 그 호출로 하려던 일을 에이전트가 끝냈는지는 알 수 없다. 에이전트는 올바른 API를 엉뚱한 고객에게 호출할 수 있고, 필요한 확인을 받기 전에 레코드를 고칠 수 있으며, 그럴듯한 답변을 남기면서 백엔드는 그대로 둘 수도 있다.

상태 기반 벤치마크는 이 문제를 일부 다룬다. τ-bench는 정책을 따르는 대화를 최종 데이터베이스 상태로 채점하고 반복 실행 신뢰성을 측정했으며, AppWorld는 다른 풀이 경로를 인정하면서 의도하지 않은 부수 변경을 잡아낸다. MCP-Atlas와 MCPMark처럼 MCP(Model Context Protocol) 서버 환경을 쓰는 벤치마크도 나왔다. 연구팀이 정리한 비교에 따르면, 사용자 대화, 상태가 있는 백엔드, 부수 효과 검사, MCP 서버를 모두 갖춘 벤치마크는 없었다.

연구방법을 단계별로

ThinkingBox는 에이전트, 시뮬레이션 사용자, 도메인 도구, 부수 효과 추출기, 판정기를 하나의 재현 가능한 실행 루프 안에서 돌린다. 과제 하나는 초기 백엔드 상태 b0, 사용자 목표 g, 쓸 수 있는 도메인 도구 집합 T, 시뮬레이션 사용자 정책 U, 에이전트에게 보이지 않는 실행 가능한 검사 m개로 정의된다. 매 턴 에이전트는 사용자에게 메시지를 보내거나, 도구를 인자와 함께 호출하거나, 대화를 끝낸다.

시도마다 격리된 MCP 도구 세션을 만든다. 같은 과제를 20번 실행하려면 시도끼리 아무것도 공유하지 않아야 한다. 앞선 시도가 만든 티켓이 남아 있으면 다음 시도의 채점이 틀어지고, pass@k와 학습 보상도 믿을 수 없게 된다. 그래서 ThinkingBox는 시도마다 과제를 b0로 초기화하고 새 도구 세션을 만든다. 이 격리는 MCP Session Proxy가 맡는다. 오래 실행되는 HTTP 서버로, 시나리오 초기화 요청을 받으면 필요한 MCP 서버 프로세스를 띄워 대화 하나만을 위한 세션을 만든다.

대화가 끝나면 샌드박스는 과제별 추출기로 부수 효과를 추출한다. 판정은 모든 검사를 곱한 값으로 정의한다. 곱으로 정의했으므로 검사 하나만 실패해도 판정은 0이고, 부분 점수는 없다. 실제 구현에서는 최종 데이터베이스와 과제별 정답 상태의 해시를 비교하고, 다르면 필드 단위 차이를 보고한다. 정답 상태는 미리 저장해 두지 않는다. 평가할 때마다 새 데이터베이스에 초기 상태 패치를 적용하고 정답 도구 호출을 재생해서 만든다. 그래서 정답 상태와 에이전트의 결과가 같은 도구 구현과 같은 데이터베이스 동작을 거친다.

507개 과제 중 30개는 최종 응답에 대한 예/아니요 루브릭 검사를 추가로 거친다. 호텔의 기밀 등급을 고객에게 말하지 않았는지, 정책상 제한된 결과를 분명히 전달했는지처럼 데이터베이스만으로는 확인할 수 없는 요구사항이다. 이 30개는 여행/숙박과 네오뱅크 사내 IT 지원에 15개씩 있으며, 루브릭 판정에는 GPT-5.4-mini를 고정해서 쓴다.

결과와 숫자의 의미

연구팀은 독점 모델과 오픈 웨이트 모델을 합쳐 18개 모델을 평가했다. 모든 모델은 같은 시스템 프롬프트, 도구 정의, 시뮬레이션 사용자, 검사기를 썼다. API 모델은 Azure에 배포된 OpenAI 호환 Chat Completions 인터페이스로 호출했고(temperature 1.0, reasoning effort medium), Qwen 모델은 vLLM으로 직접 서빙했다. 디코딩 실패나 API 오류 같은 시스템 오류도 실패한 시도로 셌다. 이는 기본 설정이며 모델별 예외가 있습니다. Mistral-Large-3는 지원되지 않는 추론 관련 매개변수를 생략했고, o3-pro는 Responses API를 사용하며 temperature를 지정하지 않았습니다.

전체 1위는 Claude Opus 5(66.50%)와 GPT-5.4(65.36%)이며, 연구팀은 표준오차를 고려하면 두 모델의 전체 성능은 구분되지 않는다고 설명한다. 그러나 도메인별로는 다르다. 여행/숙박에서는 GPT-5.4가 68.12%로 가장 높고 Claude Opus 5는 49.95%에 머물렀다. 소매에서는 오픈 웨이트 모델인 Kimi-K3가 82.24%로 모든 모델 중 가장 높았다. Claude Opus 4.6은 소매에서 68.62%지만 자동차 보험에서는 8.30%였다.

반복 시도 분석이 이 논문의 핵심 결과다. Kimi-K3는 20번 안에 한 번이라도 푼 과제 비율이 93.89%로 가장 많고, 한 번도 못 푼 과제는 31개뿐이다. 하지만 20번 모두 성공한 과제는 68개다. Claude Opus 5는 반대다. 한 번이라도 푼 과제는 79.09%로 Kimi-K3보다 적지만, 20번 모두 성공한 과제가 241개로 가장 많다. Qwen3.8-27B도 pass@20은 89.35%인데 pass^20은 10.93%다.

pass@1 순위와 신뢰성 순위도 다르다. GPT-6 Astra는 pass@1이 5위(58.31%)지만 pass^20은 46.89%로 2위이며, 20번 모두 성공한 과제가 231개로 Claude Opus 5와 비슷하다. 반면 GPT-5.4는 pass@1이 65.36%로 GPT-6 Astra보다 높지만, 20번 모두 성공한 과제는 128개로 더 적다. 연구팀의 표현으로는 '재시도는 성공 경로를 드러낼 수 있지만, 믿을 만한 실행을 보장하지는 않습니다.'

구체적인 예시

고객 상담 에이전트에게 다음과 같은 문의가 들어왔다고 해 보자. '745달러짜리 스탠드 믹서가 배송 예정일을 2주 넘겨 물류센터에서 예외(exception) 상태로 멈춰 있으니 환불하거나 크게 할인해 달라.' 에이전트는 주문, 배송 추적, 고객 정보를 조회하고 정책 문서를 검색한 뒤 상담 티켓을 만들어 경과를 기록한다. 그리고 티켓을 해결됨(solved)으로 닫고 대화를 끝낸다. 도구 호출은 모두 형식이 맞고, 데이터베이스에 쓰기도 했다. 그러나 배송사 조사가 끝나지 않았으므로 정책상 티켓은 보류(hold) 상태여야 했고, 고객은 환불 요청에 대한 답도 받지 못했다. 이 사례는 ThinkingBox-Bench의 실제 실패 사례(논문 부록 D.4의 Case 3)이다.

자동차 보험 사례는 잘못된 상태 변경의 예이다. 에이전트는 지난 12개월 동안 이미 납부 유예를 2번 받았다는 기록을 조회해 티켓에 직접 적어 놓고도, 등급 상한이 2번인 고객에게 3번째 유예를 승인했다. 모든 쓰기 도구는 오류 없이 실행되었다.

한계와 오해하기 쉬운 점

pass^20은 논문의 plug-in estimator이고 실제 20회 모두 성공한 과제 비율과 다르다. 예를 들어 Kimi-K3 pass^20 17.60%, 실제 20/20 과제 68/507 약 13.4%다. 따라서 표의 추정치와 그림의 실제 완전 성공 과제 비율을 같은 숫자로 읽으면 안 된다.

67.24%는 12개 모델의 유효 실행 121,680건 가운데 실패한 79,853건을 대상으로 한 사후 분석에서 나온다. 이 중 53,697건은 정상 종료·상태 변경 도구 호출·마지막 도구 응답에 명시적 오류가 없다는 세 조건을 만족했다. 모든 모델의 전체 실행 실패율이나, 정상 종료한 실행 중 실패 비율을 뜻하지 않는다. 18개 모델 전체 평가와 이 12개 모델 하위집합 분석도 구분해야 한다.

최종 응답은 대부분 채점하지 않는다. 507개 중 477개는 백엔드 상태와 부수 효과만으로 판정한다. 상태를 올바르게 바꾸고 사용자에게 결과를 잘못 전달한 시도도 성공으로 셀 수 있다. 연구팀은 모든 과제에 LLM 판정 루브릭을 넣으면 판정에 판정기의 편차가 들어오므로 주 지표를 결정론적으로 유지하기 위해 이 비대칭을 받아들였다고 설명한다. 따라서 보고된 통과율은 정책에 맞는 백엔드 결과를 측정하며, 사용자와의 소통 품질은 측정하지 않는다.

협조적이고 고정된 사용자만 시험한다. 시뮬레이터는 목표를 바꾸지 않고, 주어진 정보만 말하며, 협조적이고, 후속 턴은 최대 10번이다. 세부 정보를 잘못 기억하거나, 목표를 바꾸거나, 비협조적으로 변하는 사용자는 다루지 않는다. 또한 모든 실험이 GPT-5.4-mini 시뮬레이터 하나를 썼고, 이 모델이 평가 대상인 GPT 계열과 같은 계열이라 상호작용 방식의 영향을 배제할 수 없다.

과제는 합성 재구성이며 정답 상태가 하나다. 비공개 원본에서 구조를 가져와 다시 만든 과제라 기업 업무의 분포를 대표하지 않는다. 정답 최종 상태가 하나인 과제만 남겼으므로, 여러 해결책이 모두 타당한 워크플로는 처음부터 빠져 있다. 결과는 종료 표시, 턴과 토큰 상한 같은 하네스 설정에도 영향을 받는다.

실제로 어떻게 활용할까

ThinkingBox는 '에이전트가 일을 끝냈는가'를 응답 문장이 아니라 데이터 상태로 묻고, '매번 끝내는가'를 20번의 반복으로 묻는 평가 틀이다. 보고된 숫자는 특정 시점의 모델과 설정에 묶여 있지만, 실제 레코드를 다루는 에이전트를 만드는 팀이라면 이 두 질문을 자기 평가에 그대로 옮겨 볼 수 있다. 연구팀이 블로그에서 요청한 것도 반복 지표를 보고할 때 best-of-k인지 every-of-k인지, 어떻게 계산했는지 밝히라는 것이었다.

블로그는 실패 분석에서 얻은 운영 권고도 덧붙였다. 커밋 전에 모델의 요약이 아니라 최종 상태를 확인하고, 복구 가능한 오류만 재시도하도록 오류를 분류하고, 워크플로에 필요한 도구만 남기고, 되돌리기 어려운 변경에는 사람의 승인을 요구하라는 내용이다. 블로그는 이런 조치의 효과를 이 벤치마크에서 측정하지는 않았다고 함께 밝혔다.