작업은 끝냈지만 복구는 못한다는 에이전트 벤치마크 UndoBench 공개

왜 지금 이 주제인가

도구를 호출해 결제, 티켓 처리, 데이터베이스 기록 같은 실제 업무를 수행하는 AI 에이전트가 기업 소프트웨어에 점점 더 많이 배포되고 있습니다. 그런데 이런 에이전트를 평가하는 SWE-bench, ToolBench 같은 기존 벤치마크는 대부분 모든 것이 정상 작동하는 상황에서 작업을 완수하는지만 봅니다. Dolly Sah 등 네 명의 연구자가 2026년 10월 4일 arXiv에 공개한 UndoBench는 이 지점을 정면으로 파고듭니다. 네트워크가 끊기고 응답이 지연되는 실제 운영 환경에서, 에이전트가 작업을 풀 줄 아는 것과 장애에서 안전하게 복구할 줄 아는 것이 같은 능력이 아니라는 것을 숫자로 보여주었습니다.

핵심 내용

UndoBench는 Cloud, CRM, Database, Git, Messaging, Payments, Storage, Ticketing 8개 엔터프라이즈 영역에 걸쳐 36개 기본 워크플로우와 36개 장애 시나리오를 구성했습니다. 핵심 설계는 “대조적 쌍 평가”입니다. 동일한 시드로 같은 작업을 두 번 실행해, 한 번은 아무 장애 없이 완료하는지(작업 능력)를 보고 다른 한 번은 중간에 장애를 주입해 그 상황에서 올바르게 복구하는지(복구 능력)를 따로 측정합니다. 여기에 도구 호출이 실제로 외부 시스템에 어떤 효과를 남겼는지 추적하는 배선 수준 효과 이력과 환경 상태 오라클을 붙여, 에이전트가 “복구했다”고 보고만 하는 것과 실제로 상태를 정합하게 되돌린 것을 구분합니다.

대표적인 장애 시나리오는 “lost acknowledgment”입니다. 결제 게이트웨이가 요금 청구를 서버 쪽에서는 커밋했지만, 그 확인 응답이 클라이언트에 도달하기 전에 연결이 끊기는 상황입니다. 이때 에이전트는 요청이 실패했다고 오판하고 같은 결제를 다시 시도할 위험이 있습니다. 연구팀은 이 시나리오를 포함해 네트워크 지연 손실, 상류 서비스의 속도 제한, 데이터베이스 고유 키 충돌 같은 실제 분산 시스템 장애를 재현했습니다.

실험은 Llama-3.1-8B-Instruct와 Llama-3.2-3B-Instruct 두 오픈웨이트 모델을, JSON 블록으로 도구를 직접 호출하는 Direct Tool Calling과 순환 루프를 관리하는 LangGraph Agent 두 프레임워크에 얹어 돌렸습니다. 복구 방식도 세 가지로 나눠 비교했습니다. 에러가 나면 지수 백오프로 최대 3회 재시도하는 Naive Retry, 작업 컨텍스트와 호출 인수로부터 결정론적 멱등성 키를 만들어 중복 실행을 막는 Idempotency, 클라이언트 측 변이 저널과 영점 권한 조정을 쓰는 자체 진화형 메커니즘 EvoUndo-RB1입니다.

보류된 12개 테스트 워크플로우에서 두 모델, 두 프레임워크, 세 복구 방식을 모두 조합해 5,760회를 실행했고, 이 중 장애가 주입된 대조 쌍은 2,880회였습니다. 결과는 명확했습니다. 장애가 없는 조건에서 작업을 명목상 완수한 비율(task competence)은 83.54%였지만, 장애가 발생했을 때 조건부로 올바르게 복구한 비율(CRSR, Conditional Recovery Success Rate)은 46.72%로 떨어졌습니다. 더 심각한 것은 Naive Retry 방식을 쓴 시도의 53.33%에서 중복된 외부 효과, 즉 결제 중복 청구나 메시지 중복 전송 같은 사고가 발생했다는 점입니다.

의미와 한계

이 결과는 “에이전트가 작업을 풀었다”는 것과 “에이전트를 안심하고 운영에 투입해도 된다”는 것 사이에 넓은 간극이 있음을 보여줍니다. 지금까지 널리 쓰인 벤치마크들은 이 간극을 애초에 측정 대상으로 삼지 않았기 때문에, 명목상 성능 점수만으로는 실제 배포 환경에서의 안전성을 보장할 수 없다는 것이 연구팀의 핵심 메시지입니다. 특히 재시도가 기본값처럼 쓰이는 현재의 많은 에이전트 설계가, 결제나 메시징처럼 중복이 실질적 피해로 이어지는 영역에서는 위험한 전략일 수 있다는 점을 수치로 뒷받침합니다.

다만 한계도 분명합니다. 평가에 쓰인 모델이 8B와 3B 규모의 비교적 작은 오픈웨이트 모델 두 종에 한정되어 있어, 현재 상용 환경에서 널리 쓰이는 대형 프런티어 모델에 이 수치가 그대로 적용되는지는 확인되지 않았습니다. 또한 복구 패러다임도 세 가지 방식을 비교한 초기 연구 단계로, EvoUndo-RB1 같은 자체 진화형 메커니즘이 실제로 CRSR을 얼마나 끌어 올리는지에 대한 구체적 비교 수치는 이번에 확인한 자료에 담겨 있지 않았습니다. 벤치마크 자체도 36개 워크플로우, 8개 도메인으로 기업 소프트웨어 전체를 대표하기에는 아직 좁은 범위입니다.

한 줄 정리

도구를 쓰는 AI 에이전트는 정상 상황에서 작업을 83% 넘게 완수했지만, 장애가 났을 때 올바르게 복구한 비율은 47%에 그쳤습니다.