업무 기록을 바꾸는 AI 에이전트를 만드는 개발자는 완료 답변과 함께 실제로 바뀐 기록, 같은 작업을 반복했을 때의 성공률을 검사할 수 있습니다. Microsoft와 Hugging Face, 미국 대학 소속 연구진은 2026년 10월 3일 Hugging Face 블로그에서 ThinkingBox와 ThinkingBox-Bench를 Hugging Face의 에이전트 실행 환경 규격 OpenEnv로 실행하는 방법을 공개했습니다. 공개된 사용자 반응은 아직 미확인이며, 기능·실행 조건의 확인일은 2026년 10월 4일입니다. (공식 발표)

한눈에 보기

궁금한 점 이번 발표의 핵심
ThinkingBox는 무엇인가요? 에이전트·가상 사용자·도구를 연결하고 최종 업무 상태를 검사하는 실행 환경입니다.
ThinkingBox-Bench는 무엇인가요? 업무 정책과 목표를 갖춘 507개 합성 과제 모음입니다.
무엇을 검사하나요? 최종 백엔드 상태와 잘못된 변경·누락·추가 부수 효과를 판정합니다.
반복 평가는 어떻게 하나요? 과제마다 같은 초기 상태에서 20회 독립 실행합니다.
어디서 이용하나요? 공개 코드와 데이터를 받아 OpenEnv 인터페이스로 실행합니다.
준비 조건은 무엇인가요? Linux 또는 WSL, Python 3.11 이상, uv, Docker, 외부 서비스와 모델 엔드포인트입니다.
비용은 어떻게 되나요? 코드·데이터는 공개 라이선스로 제공되며 모델 추론과 실행 인프라 비용은 별도입니다.
한국어 업무도 검증됐나요? 한국어·한국 업무 정책에 대한 성능은 미확인입니다.

환경과 제공 방식은 OpenEnv 공식 문서, 과제 구성은 논문과 공개 데이터셋을 근거로 설명합니다. 아래 실패 수치는 저자 측 실험 결과이며, 실제 서비스의 성공률과는 구분합니다.

ThinkingBox는 어떤 업무를 검사하나요?

쉽게 말하면, 에이전트가 일을 마친 뒤 업무 시스템에 남은 결과를 확인하는 시험장입니다. ThinkingBox는 그 시험을 실행하는 틀이고, ThinkingBox-Bench는 정해진 목표와 정책을 가진 시험 문제입니다. 논문은 소매, 숙박·여행, 자동차보험, 네오뱅크 내부 IT, 컨설팅 IT·인사 지원처럼 여러 도구와 대화가 이어지는 업무를 다룹니다. (논문)

공개 과제에는 시작 시점의 데이터, 사용자 요청과 추가 맥락, 기대하는 도구 상호작용, 판정 기준 등이 들어 있습니다. 예를 들어 배송 지연 문의 과제에서는 주문·배송 상태를 조회한 뒤 고객지원 티켓에 조사 내용과 후속 처리 상태를 남깁니다. 배송사의 조사가 진행 중이면 티켓을 보류 상태로 두는 것이 목표에 포함됩니다. 독자는 데이터셋에서 요청과 기대하는 변경을 나란히 읽어 볼 수 있습니다. (과제 데이터)

MCP는 모델이 외부 도구를 발견하고 호출하는 데 사용하는 연결 규약입니다. ThinkingBox는 시도마다 분리된 MCP 도구 세션을 만들고, 상태를 초기화해 앞선 실행의 변경이 다음 실행에 섞이지 않게 합니다. 가상 사용자는 에이전트가 추가 정보를 물으면 대화에 참여합니다. 최종 상태와 부수 효과, 응답에 요구된 내용까지 평가 대상에 들어갑니다. (OpenEnv 환경 설명)

도구 호출이 정상 종료해도 왜 실패하나요?

호출 성공은 요청이 처리됐다는 신호이고, 업무 성공은 목표한 기록이 남았다는 결과입니다. 문법이 맞는 도구 호출도 틀린 상태값을 저장하거나 불필요한 기록을 추가할 수 있습니다. 배송 조사가 끝나기 전에 티켓을 해결 완료로 바꾸면, 상태 변경 자체가 정상 처리돼도 업무 목표와 어긋납니다. (과제의 기대 상태 · 결과 기반 평가 설명)

발표는 모두 18개 모델을 평가했고, 그중 같은 과제 묶음으로 비교한 공통 집계는 12개 모델의 유효 실행 121,680회입니다. 그중 79,853회가 실행 가능한 검사에 실패했고, 실패한 실행 중 67.24%에 해당하는 사례는 상태 변경 도구를 호출하고 최종 도구 오류 없이 정상 종료했습니다. 분모는 전체 실행이 아니라 검사 실패 실행입니다. (공식 발표의 공통 집계)

개발자가 자기 업무에 적용할 때는 먼저 완료 조건을 기록의 필드와 변경 목록으로 적어 볼 수 있습니다. 배송 문의라면 티켓 상태, 조사 요청의 생성 여부, 중복 기록 유무가 각각 검사 대상이 됩니다. 이는 공개 과제의 설계를 바탕으로 한 적용 예시입니다. 결과를 검증하는 조건이 있으면 모델의 마지막 문장과 실제 처리 상태가 어긋난 실행을 찾아낼 수 있습니다. (실행 가능한 판정의 설계)

한 번 성공과 20회 모두 성공은 어떻게 다른가요?

이번 공개에서 읽을 핵심은 반복 지표의 분모입니다. 과제 수는 소매 98개, 자동차보험 100개, 여행 104개, 네오뱅크 104개, 컨설팅 101개로 합계 507개이며, 모델별로 각 과제를 20회 독립 실행합니다. (공식 발표의 과제 구성)

지표 계산 대상 알 수 있는 것
pass@1 전체 시도 중 성공한 시도의 비율 한 번 맡겼을 때의 성공률 추정값입니다.
pass@20 20회 중 적어도 한 번 성공한 과제의 비율 성공 경로를 한 번이라도 찾은 범위입니다.
observed 20/20 실제 20회 전부 통과한 과제 수 관측된 반복 일관성입니다.

발표의 observed 20/20은 추정식을 적용한 값이 아니라 기록에서 직접 센 과제 수입니다. (지표 정의)

가령 한 과제를 20회 실행해 1회 통과했다면, 그 과제는 pass@20의 성공 과제에 포함됩니다. observed 20/20에는 포함되지 않습니다. 이 예시는 지표를 설명하기 위한 계산이며 특정 모델의 결과가 아닙니다. 재시도하면서 성공 경로를 찾는 개발 실험과, 같은 일을 맡길 때마다 올바르게 처리하는지 확인하는 평가는 서로 다른 질문을 합니다.

20회 모두 성공했다는 기록도 앞으로의 모든 요청을 보장하지는 않습니다. 공개 과제의 정책과 초기 상태에서 얻은 관측값이므로, 실제 업무에 맞춘 과제와 반복 횟수로 다시 평가하면 판단에 더 가까워집니다. 논문 초록은 같은 성질을 pass^20이라는 비율로 적고, 발표의 observed 20/20은 과제 수로 적으므로 두 자료를 비교할 때는 단위를 먼저 맞춥니다. 초록은 한 번 성공과 매번 성공의 차이를 이렇게 예로 듭니다. Claude Opus 5는 pass@1 66.50%에서 pass^20 47.53%로, Kimi-K3는 57.37%에서 17.60%로 떨어졌습니다. 한 번 맡겼을 때 잘하던 모델도 같은 일을 매번 맞히는 비율은 크게 낮아진다는 것이 저자들의 주장입니다. (논문 초록)

제공 범위와 이용 조건은 무엇인가요?

OpenEnv 어댑터는 ThinkingBox를 공통 reset·step 인터페이스로 다루게 합니다. 초기화로 과제를 선택한 뒤 도구 조회·호출과 메시지 제출을 이어가고, 끝에는 통과 또는 실패의 이진 보상을 받습니다. 공개 벤치마크 어댑터의 현재 용도는 평가이며, 별도 시나리오는 학습 워크플로에도 활용할 수 있습니다. (OpenEnv 문서)

준비 환경은 Linux 또는 Windows의 WSL, Python 3.11 이상, Python 패키지·프로젝트 관리 도구 uv와 Docker입니다. ThinkingBox 코드 저장소도 Python 3.11 이상과 uv 기반 설치를 안내합니다. Windows 독자는 WSL 안에서 준비하는 경로를 검토할 수 있으며, 실제 설치 순서는 공식 실행 안내와 코드 저장소를 따라갑니다.

컨테이너 하나로 전체 환경이 완성되지는 않습니다. OpenEnv 이미지가 시작하는 것은 API 서버이며, 도구 세션을 연결하는 Session Proxy, 벤치마크 MCP 서버, 검색 서비스 Typesense를 별도로 실행합니다. 발표는 Typesense 30.1을 안내합니다. 에이전트·가상 사용자·판정자에 사용할 모델 엔드포인트도 설정하며, 하나의 엔드포인트를 세 역할이 공유할 수 있습니다. (실행 안내 · 배포 경계와 설정)

재현용 실행 데이터는 GitHub 저장소 microsoft/thinkingbox-data의 고정 릴리스 thinkingbox-bench-v1.0에서 가져오며, 발표의 준비 조건도 이 릴리스를 받아 두는 것을 포함합니다. Hugging Face 데이터셋은 내용을 살펴보기 쉽게 옮긴 사본이고, 실행 가능한 원본은 GitHub에 있습니다. 자체 시나리오도 평가할 수 있지만 공식 고정 벤치마크 결과와 구분됩니다. 한국어·한국 업무 정책의 적용 성능은 미확인이므로, 국내 업무를 검증하려면 해당 정책과 목표 상태를 가진 시나리오부터 구성합니다. (데이터와 평가 범위)

비용과 요금은 어떻게 계산하나요?

ThinkingBox 코드는 MIT, 벤치마크 데이터는 CDLA-Permissive-2.0, OpenEnv 환경은 BSD-3-Clause로 공개됩니다. 실행 시 사용하는 모델 추론 비용은 사용자가 부담합니다. 가상 사용자와 판정자도 모델을 사용하는 구성이라 에이전트 호출만 세는 견적보다 호출 역할을 나눠 계산하는 편이 실제 지출을 파악하기 쉽습니다. (라이선스와 실행 조건)

507개 과제를 20회씩 실행하면 모델 하나당 에이전트 실행은 10,140회입니다. 이는 과제 수와 반복 횟수를 곱한 값이며, 개별 모델 호출 수는 대화 길이와 도구 사용에 따라 달라집니다. 처음부터 전체를 돌리는 대신 한 과제를 실행해 서비스 연결과 판정 결과를 확인한 뒤 반복 평가로 넓히면 초기 지출을 가늠할 수 있습니다.

발표의 비용 비교는 기록된 토큰 사용량에 OpenRouter 정가 등을 적용한 추정 지표입니다. 실제 청구액이나 서비스 요청 한 건의 요금과는 구분합니다. 자기 환경의 예산은 모델별 입력·출력·캐시 요금, 가상 사용자·판정자 호출, Docker 등 실행 인프라를 합쳐 계산합니다. (비용 산정 설명)

실제 서비스에 적용할 때 무엇을 확인하나요?

공개 과제는 실제 고객 데이터가 아니라 합성 재구성입니다. 과제의 사용자 요청, 초기 데이터와 판정 코드를 먼저 읽으면 자사 업무와 맞는 정책인지 판단할 수 있습니다. 공개 데이터의 영어 요청과 해외 업무 사례를 한국어 상담 품질이나 국내 업무 정확도의 근거로 곧바로 옮기기에는 평가 대상이 다릅니다. (공개 데이터셋 · 논문의 평가 범위)

OpenEnv는 운영 인프라 실패를 별도로 보고합니다. 모델이 과제를 잘못 처리한 경우와 외부 서비스가 준비되지 않아 실행이 끊긴 경우를 나누어 보면 수정할 곳이 선명해집니다. 모델에게는 도구와 대화가 보이고, 정답 상태·판정 내부·인증 정보는 평가 환경 쪽에 남습니다. (환경의 판정과 경계)

자체 시험의 첫 질문은 “완료라고 답했나”에 더해 “필요한 기록이 올바르게 바뀌었나”가 됩니다. 다음 질문은 같은 초기 조건으로 반복해도 그 결과가 유지되는지입니다. ThinkingBox의 공개 환경은 이 두 질문을 실제 과제로 확인할 출발점을 제공합니다.

반응 (2026년 10월 4일 기준)

공개된 사용자 반응은 아직 확인되지 않았습니다.

참고한 자료

아래 자료의 확인일은 2026년 10월 4일입니다. 발표일은 OpenEnv 공개 안내의 10월 3일을 사용하며, 논문 최초 제출일인 8월 20일과 구분합니다.