ThinkingBox 평가법: AI 에이전트가 남긴 DB 상태로 신뢰성을 검증하는 절차

Microsoft와 Hugging Face가 공개한 ThinkingBox는 AI 에이전트 평가에서 중요한 기준을 제시한다. 에이전트가 어떤 말을 했는지, 어떤 도구를 호출했는지보다 최종적으로 데이터베이스에 어떤 상태를 남겼는지를 본다. 고객지원, 환불, 보험, 여행, 은행, 컨설팅처럼 상태가 바뀌는 업무에서는 이 차이가 크다. 에이전트가 “처리했습니다”라고 말해도 티켓 상태, 환불 기록, 예약 변경, 고객 알림이 요구된 최종 상태와 다르면 실패다.

ThinkingBox는 507개 stateful business workflow를 대상으로, 각 작업을 독립된 깨끗한 backend에서 20회 반복 실행해 평가한다. 글에서 소개된 사례는 배송 예외 상태가 열린 고객 문의다. 에이전트는 주문 조회, 추적 확인, 고객 프로필 확인, 환불 정책 검색, 티켓 생성 등 여러 도구 호출을 정확히 수행했다. 그러나 carrier exception이 여전히 열려 있어 티켓은 hold 상태여야 했는데 solved로 닫았다. 도구 호출만 보면 성실한 작업처럼 보이지만, 데이터베이스 상태는 틀렸다.

도구 호출은 결과가 아니다

많은 에이전트 평가는 tool call이 올바른 형식으로 나갔는지, 최종 답변이 그럴듯한지 본다. 하지만 실제 업무에서는 이것만으로 부족하다. 도구 호출이 성공해도 잘못된 레코드를 바꿀 수 있고, 필요한 side effect를 빠뜨릴 수 있고, 불필요한 티켓이나 메모를 만들 수 있다. ThinkingBox는 이 문제를 “trajectory는 주장이고 database state가 증거”라고 정리한다.

공개된 분석에 따르면 121,680개 valid trial을 포함한 ablation에서 실패 시도 중 상당수가 겉으로는 깨끗하게 종료됐다. 실패 중 67.24%는 state-changing tool을 호출했고 최종 tool error도 없었다. 그런데 executable check는 wrong field value, unintended extra effect, missing required effect를 찾아냈다. 즉 에이전트가 도구를 불렀다는 사실은 성공 증거가 아니다.

제품팀은 이 기준을 그대로 가져와야 한다. 환불 에이전트라면 “refund API 호출함”이 아니라 “환불 금액, 상태, 고객 알림, 회계 메모가 요구 조건과 일치함”을 봐야 한다. 채용 에이전트라면 “후보자 메모 작성함”이 아니라 “후보자 단계, 면접 일정, 알림 대상, 거절 사유가 맞음”을 봐야 한다.

한 번 성공은 신뢰성이 아니다

ThinkingBox는 각 작업을 20회 반복한다. 여기서 세 가지 지표를 본다. pass@1은 평균적으로 얼마나 잘하는지, pass@20은 20번 중 한 번이라도 성공하는지, observed 20/20은 20번 모두 성공했는지다. 일반 리더보드는 pass@1에 가까운 숫자를 보여주지만, 운영에서는 observed 20/20이 중요하다.

이유는 간단하다. 환불 업무를 한 번 맞히고 다음 네 번 틀리는 에이전트는 운영할 수 없다. 특히 상태 변경 업무는 재시도 비용이 크다. 티켓을 잘못 닫거나, 잘못된 금액을 환불하거나, 고객에게 틀린 안내를 보내면 나중에 사람이 수습해야 한다. 데모에서는 한 번 성공하면 충분해 보이지만, 프로덕션에서는 반복 안정성이 제품 품질이다.

ThinkingBox 결과에서도 breadth와 consistency가 갈라졌다. 어떤 모델은 많은 작업을 적어도 한 번은 풀지만, 20번 모두 맞히는 작업 수는 적다. 반대로 한 번이라도 풀 수 있는 범위는 좁아도, 성공하는 작업에서는 꾸준한 모델이 있다. 에이전트 모델 선택에서 “할 수 있느냐”와 “항상 하느냐”는 다른 질문이다.

내부 평가 세트를 어떻게 만들까

서비스에 적용하려면 먼저 핵심 workflow를 뽑는다. 고객지원이라면 배송 지연, 환불 거절, 구독 취소, 주소 변경, 중복 결제, 계정 잠금 같은 케이스다. 각 케이스마다 초기 데이터베이스 상태, 사용자의 메시지, 허용 도구, 기대 최종 상태를 정의한다.

기대 최종 상태는 자연어가 아니라 executable check로 써야 한다. 예를 들어 “티켓을 적절히 처리한다”가 아니라 다음을 검사한다.

• ticket.status == "hold"
• ticket.reason == "carrier_exception"
• customer.compensation == 0
• internal_note contains tracking timeline
• outbound_message was sent exactly once
• no refund record was created

이런 검사를 코드로 만들면 모델 답변의 말투와 무관하게 결과를 평가할 수 있다. 또한 unintended extra effect를 반드시 검사해야 한다. 필요한 레코드가 생겼는지만 보면, 동시에 잘못된 환불이나 중복 티켓이 생긴 것을 놓칠 수 있다.

20회 반복 평가가 필요한 이유

LLM 에이전트는 같은 입력에서도 매번 같은 경로를 가지지 않을 수 있다. temperature를 낮춰도 도구 응답 순서, 검색 결과, 내부 추론 경로, 타임아웃에 따라 달라진다. 그래서 단일 실행 결과는 신뢰성 평가에 약하다. 최소 10회, 가능하면 20회 반복해서 성공률과 실패 유형을 봐야 한다.

반복 평가를 할 때는 매번 깨끗한 sandbox를 써야 한다. 이전 실행이 만든 티켓이나 상태가 다음 실행에 영향을 주면 평가가 왜곡된다. ThinkingBox도 isolated MCP tool session과 terminal backend state를 사용한다. 사내 평가에서도 테스트 DB snapshot을 매번 되돌리고, 외부 발송·결제·삭제는 mock으로 대체한다.

지표는 pass@1만 보지 않는다. 작업별 20/20 성공 여부, 실패 시 남은 잘못된 상태, 중복 side effect, 사람 개입 필요 여부를 함께 기록한다. 모델을 바꿨을 때 pass@1이 올라도 observed 20/20이 떨어지면 운영 안정성은 나빠진 것이다.

실패 유형을 분류해야 고칠 수 있다

에이전트가 실패했을 때 “모델이 멍청하다”로 끝내면 개선이 안 된다. 실패를 최소한 네 가지로 나눈다.

첫째, 정책 해석 실패다. 환불 규정이나 계정 제한 기준을 잘못 읽은 경우다. 이때는 정책 문서 검색, 근거 인용, rule engine 보조가 필요하다.

둘째, 상태 전이 실패다. 해야 할 상태 변경은 알았지만 잘못된 필드를 바꾸거나 티켓 상태를 잘못 닫은 경우다. 이때는 도구 스키마, precondition, postcondition check가 필요하다.

셋째, 누락된 side effect다. 고객에게 안내를 보내야 했는데 내부 메모만 남긴 경우다. 이때는 workflow checklist와 마지막 검증 단계가 필요하다.

넷째, 불필요한 extra effect다. 환불하면 안 되는데 환불 레코드를 만들거나, 티켓을 중복 생성한 경우다. 이때는 권한 제한과 dry-run 검사가 필요하다.

각 실패 유형에 따라 해결책이 다르다. 모델만 더 큰 것으로 바꾸는 것은 마지막 수단이어야 한다. 많은 문제는 도구 설계, 상태 검증, 정책 표현, 승인 흐름으로 줄일 수 있다.

프로덕션에 넣기 전 안전장치

상태 변경 에이전트는 실행 전후 검증이 필요하다. 실행 전에는 precondition을 확인한다. 예를 들어 환불하려면 주문 상태, 결제 수단, 환불 가능 기간, 이전 환불 기록을 확인한다. 실행 후에는 postcondition을 확인한다. 환불 레코드가 정확한 금액으로 하나만 생겼는지, 티켓 상태가 맞는지, 고객 알림이 발송됐는지 본다.

중요한 업무는 에이전트가 직접 완료 상태로 닫지 못하게 할 수 있다. 예를 들어 배송 예외가 남아 있으면 solved가 아니라 hold만 허용한다. 환불 금액이 일정 기준을 넘으면 사람 승인으로 넘긴다. 고객에게 나가는 메시지는 자동 발송 전 정책 위반과 사실 오류를 검사한다.

로그에는 최종 답변보다 상태 변화가 중요하다. 어떤 도구를 언제 호출했고, 어떤 레코드가 전후로 어떻게 바뀌었으며, 어떤 check가 통과했는지 남겨야 한다. 나중에 고객 불만이 들어왔을 때 “모델이 그렇게 말했다”가 아니라 실제 상태 전이를 추적할 수 있어야 한다.

실행 체크리스트

• 핵심 업무 20~50개를 stateful workflow 평가 세트로 만든다.
• 각 workflow마다 초기 DB 상태와 기대 최종 상태를 코드로 정의한다.
• 필요한 effect와 금지해야 할 extra effect를 모두 검사한다.
• 각 작업을 최소 10회, 가능하면 20회 반복 실행한다.
• pass@1, pass@20, observed 20/20을 분리해서 본다.
• 실패를 정책 해석, 상태 전이, 누락 side effect, extra effect로 분류한다.
• precondition과 postcondition check를 프로덕션 도구 호출 앞뒤에 넣는다.
• 되돌리기 어려운 상태 변경은 사람 승인 또는 hold 상태로 제한한다.

AI 에이전트 평가는 말솜씨 평가가 아니다. 실제 업무에서는 데이터베이스가 최종 판정자다. 에이전트가 남긴 상태를 코드로 검사하고, 같은 작업을 여러 번 반복해도 항상 맞는지 확인해야 프로덕션에 넣을 수 있다.

출처

• Hugging Face, The Agent Said It Was Done. The Database Disagreed.: https://huggingface.co/blog/microsoft/thinkingbox