표면적 응답을 넘어선 백엔드 상태 검증 체계 공개
마이크로소프트 Copilot Studio 연구진과 허깅페이스는 AI 에이전트가 완수했다고 보고하는 비즈니스 태스크의 백엔드 데이터베이스 변경 상태를 직접 검증하는 샌드박스 도구 '씽킹박스(ThinkingBox)'와 평가 벤치마크 '씽킹박스-벤치(ThinkingBox-Bench)'를 공동 공개했다. 이 연구는 에이전트가 문법적으로 올바른 도구 호출을 수행하고 '처리가 완료되었습니다'라는 확신에 찬 텍스트를 출력하더라도, 실제 데이터베이스 레코드에는 누락이나 오류가 남을 수 있다는 실무적 문제의식에서 출발했다.
이번 프레임워크는 허깅페이스의 OpenEnv 규격을 통해 배포되었으며, 런타임 및 도구는 MIT 라이선스, 507개 워크플로우를 담은 벤치마크 데이터셋은 CDLA 라이선스로 오픈소스 공개되었다. 개발팀은 모델의 자연어 추론이나 도구 호출 문법 체크에만 의존하던 기존 평가 방식을 벗어나, 데이터베이스 트랜잭션의 부수 효과를 물리적으로 대조하는 실행 검증 방식을 도입했다.
12만 회 실행으로 입증된 '침묵하는 실패'의 실태
연구진은 소매·전자상거래, 여행·호스피탈리티, 자동차 보험, 네오뱅킹 지원, 컨설팅 IT/HR 등 5대 비즈니스 도메인에서 추출한 507개 상태 기반 워크플로우를 구성했다. 이후 12개 주요 대형언어모델을 대상으로 각 작업을 초기 클린 상태에서 20회씩 독립 반복 실행해 총 121,680회의 유효 시도를 기록했다. 이 중 79,853회가 최종 DB 검증을 통과하지 못해 실패로 분류되었다.
주목할 점은 실패한 시도 가운데 67.24%가 도구 호출 오류 없이 정상적인 응답과 함께 깔끔하게 세션을 종료했다는 사실이다. 실패 원인의 약 79.9%는 논리적 추론 결함이 아니라 도구 처리 과정, 사전조건 불충족, 오류 복구 실패에서 기인했으며, 구체적으로 실행 검증 실패 사례의 77.6%는 잘못된 필드 값 기입 때문으로 확인되었다.
단일 실행과 반복 실행 간의 극심한 일관성 격차
이번 측정 결과는 에이전트 평가에서 단일 시도 성공률(Pass@1) 지표만을 신뢰하는 것이 얼마나 취약한지를 명확히 드러낸다. 단일 시도 기준으로는 Claude Opus 5.5가 67.16%로 1위를 기록했고 GPT-5.6 Sol(61.9%), GPT-6 Astra(58.3%), Kimi-K3(57.4%) 순으로 우수한 성능을 보였다. 그러나 20회 반복 테스트에서 단 한 번이라도 실패하면 결격으로 처리하는 완전 일관성(20/20) 기준을 적용하면 성능은 급격히 하락했다.
실제로 Kimi-K3의 경우 507개 작업 중 93.89%(476개)를 최소 한 번 이상 성공시켰으나 20회 모두 연속 성공한 과업은 13.41%(68개)에 불과했다. 최고 수준의 일관성을 기록한 Claude Opus 5.5 및 Opus 5 계열 역시 20회 연속 성공 과업 비율은 47.53%(241개)에 그쳤다. 단 한 번의 오작동도 허용하기 어려운 엔터프라이즈 환경에서는 단일 성공률보다 반복 일관성 유지 비율을 우선적으로 검토해야 한다.
격리 환경과 골든 스테이트 해시 비교 기반 아키텍처
씽킹박스의 기술적 핵심은 모델 콘텍스트 프로토콜(MCP) 세션을 격리하고 '골든 스테이트(Golden State)' 해시 대조 방식을 구축했다는 점에 있다. 시나리오 서버는 초기 패치 적용 후 사전에 정의된 정상 트랜잭션을 재생하여 기준 DB 상태를 생성하며, 에이전트 작업 종료 후의 DB 상태 해시값과 대조한다. 이를 통해 필수 변경 사항의 누락뿐 아니라 에이전트가 임의로 다른 레코드를 조작하는 부수 효과까지 엄격하게 식별한다.
이러한 아키텍처는 기업용 에이전트 개발진이 프롬프트 엔지니어링이나 단순 대화 로그 검증에만 의존해서는 안 된다는 실무적 시사점을 제공한다. 에이전트가 백엔드 API를 호출한 직후 실제 데이터베이스 상태를 즉각 다시 조회해 기댓값과 비교하는 '읽기 재검증(Read-Back verification)' 레이어를 백엔드 미들웨어에 표준적으로 탑재해야만 시스템의 무결성을 보장할 수 있다.
합성 데이터의 한계와 실무 도입 시 확인 필요 과제
다만 이번 벤치마크 결과를 현업 시스템에 직접 대입하기에는 전제 조건상의 명확한 한계가 존재한다. 씽킹박스-벤치에 포함된 507개 과업은 기업 업무 시나리오를 바탕으로 재구성한 '합성 워크플로우'이며, 실시간 데이터 변동이나 비정형 데이터베이스 구조를 가진 실제 프로덕션 환경 전체를 완벽히 대변하지는 못한다. 아울러 보고된 신뢰도당 비용 수치는 OpenRouter 정가 기준의 캐싱 미적용 산출물이므로 실무 적용 시에는 프롬프트 캐싱이나 재시도 로직에 따른 단가 변화를 별도로 계산해야 한다.
또한 마이크로소프트의 발표에서는 해당 검증 체계가 Copilot Studio 등 실제 상용 제품군에 기본 검증 엔진으로 내장될지 여부나 구체적인 적용 일정이 공개되지 않았다. 따라서 실무 개발팀은 상용 플랫폼의 기본 기능에만 의존하기보다는, 씽킹박스 오픈소스 도구를 내부 스테이징 환경에 독립적으로 구축해 배포 전 자동화 회귀 테스트 도구로 선제 활용하는 것이 바람직하다.
출처
Hugging Face의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
The Agent Said It Was Done. The Database Disagreed. (새 창)
