“환불 완료”라는 AI의 말을 믿어도 될까? ThinkingBox가 묻는 성공의 조건

1. 핵심: 이 글에서 가져갈 한 가지

AI 에이전트의 성공은 작업이 끝난 뒤 실제로 무엇이 바뀌었는지 확인해야 판단할 수 있다. Microsoft의 ThinkingBox는 에이전트가 도구를 사용하고 데이터를 변경하는 환경을 제공하며, 실행 후 남은 상태와 변경 사항을 검사한다. 주문 취소, 예약 변경, 고객 지원처럼 여러 시스템의 데이터를 정확하게 다뤄야 하는 업무에서 특히 유용하다. 여기서 가져갈 핵심은 ‘완료’를 데이터로 정의하고, 같은 조건에서도 그 결과를 반복해서 만들 수 있는지 확인하자는 것이다.

2. 문제: 기존 방식이 막히는 순간

국내 온라인 쇼핑몰에 AI 상담원을 도입했다고 가정해 보자. 다음은 이해를 돕기 위한 가상 사례다.

고객이 키보드 9만 원과 마우스 3만 원을 함께 주문했다. 아직 출고 전이고, 고객은 이렇게 요청한다.

“마우스만 취소해 주세요. 키보드는 그대로 보내 주시고요.”

AI는 주문을 조회하고, 취소 도구를 호출하고, 환불 내역까지 확인한다. 화면에는 오류가 없다. 마지막 답변도 자연스럽다.

“마우스 주문을 취소하고 3만 원 환불을 완료했습니다.”

그런데 실제로 호출한 것은 주문 전체를 취소하는 기능이었다. 데이터베이스에는 키보드와 마우스가 모두 취소됐고, 환불 금액은 12만 원으로 기록돼 있다.

API 입장에서는 정상 처리다. 전달받은 주문 전체를 요청대로 취소했기 때문이다. 하지만 고객의 요구는 충족하지 못했다.

이 사례에서 ‘완료’의 조건은 적어도 세 가지다.

• 마우스만 취소되고, 3만 원이 한 번 환불됐어야 한다.
• 키보드의 주문과 배송 상태는 유지돼야 한다.
• 다른 주문에는 변경이 없어야 한다.

해야 할 변경과 함께, 건드리면 안 되는 데이터까지 확인해야 한다.

이런 실패는 오류 로그만 찾아서는 놓치기 쉽다. ThinkingBox 저자들의 별도 분석에서도, 검증에 실패한 실행 중 67.24%는 정상적으로 종료됐고, 데이터를 변경하는 도구를 호출했으며, 마지막 도구 오류도 없었다. 이 수치는 전체 실행이 아닌 실패한 실행을 기준으로 한다.

운영자가 보고 싶은 것은 “취소 API 호출 성공”이라는 초록색 표시일 수 있다. 그러나 고객에게 중요한 것은 내일 키보드가 제대로 도착하느냐다. 두 가지를 연결해 주는 검증이 필요하다.

3. 설계: 왜 이런 해결책을 선택했을까

ThinkingBox의 구조는 이 문제를 실험 가능한 형태로 만든다.

각 과제에는 시작 데이터, 사용자의 목표, 업무 정책, 사용할 도구, 성공 여부를 검사할 조건이 준비돼 있다. 에이전트는 모의 사용자와 대화하면서 도구를 사용한다. 실행이 끝나면 평가기가 최종 상태와 변경 사항을 검사한다. 정답 상태와 판정 기준은 에이전트가 볼 수 없는 평가 영역에 둔다.

앞의 부분 취소 사례로 옮기면, 평가자는 미리 다음 상태를 정의하는 셈이다.

마우스: 취소
환불: 30,000원, 1건
키보드: 기존 상태 유지
다른 주문: 기존 상태 유지

여기서 눈여겨볼 점은 에이전트가 거쳐야 할 모든 클릭과 호출 순서를 정답으로 고정하지 않는다는 것이다.

어떤 에이전트는 주문을 먼저 확인하고, 다른 에이전트는 취소 정책부터 확인할 수 있다. 두 경로가 모두 허용된 조건을 지키면서 같은 올바른 결과를 만들었다면 성공으로 인정할 수 있다. 평가의 관심이 특정 절차를 흉내 내는 능력에서 업무를 완수하는 능력으로 이동한다.

물론 결과 중심 평가에도 비용이 있다. 개발자가 ‘올바른 결과’를 먼저 명확하게 작성해야 한다.

부분 취소 하나만 해도 묶음 할인, 배송비, 쿠폰 복구 같은 조건이 붙으면 정답 상태를 정하기 어려워진다. ThinkingBox-Bench는 비교를 명확하게 하기 위해 과제별로 하나의 정답 최종 상태를 사용하며, 여러 최종 상태가 동등하게 정답이 되는 과제는 제외한다.

판정의 명확성을 얻는 대신, 재량이 큰 업무를 다루는 범위는 좁아지는 것이다.

반복 실험에는 또 하나의 장치가 필요하다. 바로 초기화다.

환불을 한 번 실행한 데이터에 같은 요청을 다시 던지면, 두 번째 실행은 이미 환불된 주문을 만나게 된다. 첫 번째와 같은 문제를 푼다고 보기 어렵다. ThinkingBox는 각 실행에 격리된 환경을 제공하고, 동일한 시작 상태로 되돌려 비교한다.

여기서 내가 얻은 설계상의 교훈은 분명하다.

에이전트에게 일을 설명하는 프롬프트와, 일이 끝났다고 인정하는 검증 조건을 함께 설계해야 한다. 요청문만 정교하게 다듬으면 성공의 정의가 계속 모델의 해석에 맡겨진다.

4. 검증: 실제로 확인하고 내린 판단

검증 결과는 두 범위로 나눠 보는 것이 정확하다. 저자들이 수행한 전체 벤치마크와, 이 글의 작성 과정에서 실행한 작은 판정 함수 확인이다.

먼저 공개 벤치마크에서는 507개 과제를 각각 동일한 초기 상태에서 20번 독립적으로 실행했다. 다음은 원문에 보고된 두 모델의 결과다.

가장 눈에 띄는 것은 ‘한 번 이상 성공’과 ‘20번 모두 성공’ 사이의 차이다.

Kimi-K3는 적어도 한 번 해결한 과제의 범위가 넓다. 반면 Claude Opus 5는 모든 반복에서 성공한 과제가 더 많다. ‘해결할 수 있는 문제의 범위’와 ‘같은 일을 일관되게 처리하는 정도’는 서로 다른 평가 항목이다.

내가 환불 에이전트를 검토한다면, 같은 입력에서 결과가 흔들리는 이유를 먼저 확인하겠다. 실제 고객에게는 여러 실행 중 잘된 결과 하나만 골라 보여줄 수 없기 때문이다.

다만 20회 전부 성공했더라도 앞으로의 모든 실행이 안전하다는 보장은 없다. 이 표 역시 해당 평가 환경에서 얻은 결과다.

작성 과정에서 실행한 확인의 범위는 더 작다. 전체 ThinkingBox 환경이나 LLM을 실행하지는 않았다. 공개 소스의 validate_database 함수와 이를 호출하는 ST003_006 테스트를 분리해, Python 3.12.3에서 네 가지 합성 입력으로 실행했다. 실제 DB를 만들거나 해시를 계산하는 대신, 검사할 해시와 차이 목록을 입력으로 제공했다.

두 번째 결과가 특히 중요했다.

차이 목록이 비어 있어도 해시가 다르면 실패했다. 이 함수에서 차이 목록은 실패를 설명하는 자료이고, 통과 여부는 해시 비교가 결정한다.

네 번째는 성격이 다르다. 필수 평가 데이터가 없어 발생한 입력 오류다. 이를 에이전트가 업무를 잘못 수행한 사례와 섞으면 모델의 실패와 평가 환경의 실패를 구분할 수 없게 된다.

이 작은 확인으로 검증 함수의 동작은 살펴볼 수 있었다. 다만 실제 데이터의 변경 사항을 올바르게 추출하는지, DB 해시를 정확하게 만드는지, 에이전트가 업무를 잘 수행하는지까지 검증한 것은 아니다.

여전히 남는 빈틈도 있다.

공개 벤치마크의 507개 과제 중 477개는 상태만으로 채점하고, 30개는 응답 내용에 대한 추가 기준을 사용한다. 따라서 상태만 검사하는 과제에서는 DB가 맞더라도 고객에게 잘못 설명하는 문제를 충분히 평가하지 못할 수 있다. 또한 합성 과제의 성적이 실제 고객과 운영 환경의 성적을 그대로 의미하지는 않는다.

그래서 나는 ThinkingBox를 주문 변경, 예약 처리, 계정 권한 수정처럼 정답 상태를 명시할 수 있는 업무의 배포 전 평가에 사용하겠다. 우리 서비스의 정책과 데이터를 반영한 과제를 만들고, 반복 실행하면서 필요한 변경과 금지된 변경을 함께 확인하는 방식이다.

반대로 글쓰기나 열린 협상처럼 좋은 결과가 여러 형태로 존재하는 작업에는 사람의 평가나 목적에 맞는 별도 기준을 쓰겠다.

실제 서비스에 적용할 때도 상태 검증과 함께 고객에게 한 설명의 정확성, 외부 시스템에 이미 발생한 변경, 실패 후 복구 가능성을 따로 살피겠다. 이는 이 글에서 제안하는 적용 방향이며, 이번 확인 실험에서 효과까지 검증한 것은 아니다.

ThinkingBox를 읽고 업무 명세에 다음 두 문장을 추가하고 싶어졌다.

“완료됐다면 어떤 데이터가 바뀌어 있어야 하는가?”

“그 과정에서 어떤 데이터는 절대로 바뀌면 안 되는가?”