한 번의 성공은 신뢰성이 아니다: Thinkingbox로 업무 에이전트 평가하기
들어가며
에이전트가 그럴듯한 답변을 내놓고 문법적으로 올바른 도구를 호출했다고 해서 실제 업무를 완료한 것은 아닙니다. 업무 환경에서는 여러 차례의 대화를 통해 누락된 정보를 모으고, 도메인 정책을 지키며, 의존 관계가 있는 도구를 조정하고, 마지막으로 백엔드 시스템을 정확한 영속 상태로 바꿔야 합니다. 필요한 단계가 빠지거나 불필요한 변경이 발생하면 겉보기에는 성공한 실행도 전체적으로는 실패입니다.
Thinkingbox는 이러한 차이를 평가의 중심에 둔 샌드박스입니다. 최종 답변의 자연스러움이나 개별 도구 호출의 유효성만 보는 대신, 사용자·에이전트·도구 사이의 상호작용이 올바른 업무 결과로 이어졌는지를 확인합니다.
핵심 내용
- 격리된 실행 환경. MCP 호환 도구 세션을 분리해 제공하므로 여러 시도 사이의 상태 간섭을 줄일 수 있습니다.
- 전체 실행 추적. 최종 답변뿐 아니라 정보 수집, 중간 판단, 도구 사용을 포함한 상호작용 전체를 기록합니다.
- 상태 중심의 결과 평가. 작업별 실행 가능한 검사가 백엔드의 최종 상태를 확인합니다. 올바른 경로는 수용하지만 잘못된 변경, 누락된 변경, 추가적인 부작용은 거부합니다. 일부 작업은 최종 답변에 필요한 속성도 검사합니다.
- 다양한 업무 영역. Thinkingbox-bench에는 소매, 호텔, 자동차 보험, 네오뱅크 내부 IT, 컨설팅 기업의 IT/HR 지원 등 정책 제약이 있는 507개 워크플로가 포함됩니다.
- 반복 성공의 어려움. 독점 모델과 오픈 웨이트 모델을 비교한 결과, 가장 높은 pass@1은 65.36%였지만 pass^20은 25.25%였습니다. 한 번 성공 경로를 찾는 것과 안정적으로 재현하는 것은 다릅니다.
의미와 영향
기존 에이전트 평가에서는 올바른 형식의 도구 호출, 유효한 중간 작업, 정상적인 종료를 성공의 신호로 보는 경우가 많습니다. 그러나 Thinkingbox의 결과는 이런 신호가 최종 작업 완료를 충분히 대변하지 못한다는 점을 보여줍니다. 실패한 실행 중에도 정상적으로 종료되고 실제로 유효한 상태 변경을 수행한 사례가 있습니다. 그럼에도 필요한 변경을 모두 처리하지 않았거나, 허용되지 않은 추가 효과를 남겼다면 작업 전체는 실패입니다.
기업 자동화에서 필요한 것은 가끔 작동하는 시연이 아니라 예측 가능한 실행입니다. 에이전트는 정책과 제약을 준수하고, 도구 간 의존성을 처리하며, 부작용을 피하고, 의도한 영속 상태를 반복해서 만들어야 합니다. Thinkingbox는 이 요구사항을 하나의 평가 고리에 넣어 실제 운영에 더 가까운 비교 기준을 제시합니다.
물론 이 벤치마크는 미리 설계된 샌드박스이므로 현실의 모든 업무 환경을 재현할 수는 없습니다. 그럼에도 평가의 기준을 분명히 했다는 점은 중요합니다. 핵심 질문은 “말을 그럴듯하게 했는가”나 “도구를 호출했는가”가 아니라, 제약을 지키면서 시스템을 필요한 상태로 정확히 바꾸었는가입니다. 이는 성공적인 데모와 신뢰할 수 있는 업무 에이전트를 구분하는 기준이 될 수 있습니다.
댓글
로그인 상태 확인 중…
댓글 불러오는 중…