이전 기사(AI 에이전트, 무엇을 맡기고 무엇을 남길 것인가)에서 에이전트에게 무엇을 맡길 것인지에 대한 경계선을 다루었다.

맡길 범위를 결정했다면, 다음 논점은 "그 에이전트의 좋고 나쁨을 어떻게 측정할 것인가", 그리고 "실패했을 때 어떻게 되돌릴 것인가"이다.

2026년 5월, 현장 실무자의 판단 기준이 한 단계 이동했다는 감각이 있다. SWE-bench의 점수나 벤치마크 순위가 아니라, **"재작업 비용 (rework cost)"**로 에이전트를 선택하는 움직임이 나타나고 있다. 완벽한 80%보다, 실패 비용이 저렴한 70%가 실무 환경에서는 더 잘 돌아간다.

이 기사는 평가 축의 재구성과 롤백 (rollback) 설계를 두 가지 축으로 실무적으로 정리한다.

기존 평가 축의 한계

에이전트의 평가 축으로서 2024년~2025년에 정착된 것은 대략 세 가지였다.

태스크 완료율 (SWE-bench Verified, TAU-bench 등) -
응답 품질 (MT-bench, Arena-style 투표) -
가성비 (토큰 단가 × 성능)

이것들은 "닫힌 환경에서의 성능 테스트"로서는 유효하다. 벤치마크 간의 순위가 깔끔하게 나오고, 리더보드에 오르기 쉽다.

하지만 2026년 5월 시점에서, 실제 운영 현장이 직면하고 있는 문제는 이러한 축으로는 측정할 수 없다.

실무 축: "재작업 비용"이 중심이 되고 있다

내가 관찰하고 있는 범위 내에서, 에이전트를 장기 운용하고 있는 팀의 판단 기준은 다음과 같이 변화하고 있다.

재작업 비용: 에이전트가 실패했을 때, 되돌리는 데 몇 단계가 필요한가 -
롤백 용이성: 실패를 감지한 후 "실패 전 상태"로 되돌리기까지의 시간과 작업량 -
실패 경고 정확도: 에이전트 스스로가 "이것은 자신 없다"라고 인간에게 통지할 수 있는가 -
부작용의 가역성: 외부 시스템 (DB / API / 메일 전송)에 대한 부작용을 취소할 수 있는가

이것들은 기존의 벤치마크에는 나오지 않는다. 이유는 단순하다. 벤치마크는 "실패하지 않는 것"을 측정하지만, 실제 운영에서는 실패한 뒤에 어떻게 되는가가 결정적이기 때문이다.

구체적인 예: 동일한 성능이라도 채택이 갈리는 이유

예를 들어, 두 에이전트가 SWE-bench Verified에서 동일하게 73%의 점수를 냈다고 가정하자. 기존 축으로는 무승부다.

실무 축을 적용하면 갈린다.

• 에이전트 A: 실패한 커밋을 git revert로 1개 명령어로 취소, 롤백 수 초 -
• 에이전트 B: 실패 시 여러 파일에 이미 쓰기 완료, 인간이 수동으로 정합성 체크, 롤백 수 시간

같은 73%라도, A는 실무에 투입되고 B는 시험 운용 단계에서 멈춘다. 성능이 같더라도, 재작업 비용이 차원이 다르기 때문이다.

평가 프레임의 최소 구성

자사에서 평가 프레임을 만들 때의 최소 구성은 다음과 같다.

태스크 성공률 (기존 방식대로) -
실패 시 감지율 (에이전트 스스로 에러를 선언할 수 있는가) -
롤백 공수 (성공 시의 상태로 되돌리기까지의 수동 작업 단계 수) -
부작용 범위 (취소할 수 없는 외부 영향의 유무)

이 4가지 축으로 보면, SWE-bench 점수가 30위인 에이전트가 1위인 에이전트보다 실무에 더 많이 채택되는 것이 2026년 6월의 실정이다.

롤백 설계의 4가지 패턴

롤백 설계는 "실패한 뒤에 생각하는 것"이 아니다. 에이전트를 도입하기 전에 결정해 두어야 하는 것이다.

2026년 5월 시점에서 관찰할 수 있는, 현장에서 사용되는 롤백 설계는 크게 4가지 패턴으로 나뉜다.

패턴 A: 즉시 취소 (Git revert형)

에이전트의 조작이 추가형 (append-only) 이며, 과거의 상태가 저장되어 있는 케이스.

대표 사례:

• 코드 커밋 (Git revert)
• 문서 편집 (버전 히스토리)
• API 호출 시 멱등성 (idempotent) 이 있는 조작

특징:

• 롤백 = 1개 명령어 (수 초 ~ 수십 초)
• 실패의 영향 범위가 "변경분만"으로 한정됨
• 에이전트를 다소 공격적으로 운용할 수 있음 (실패해도 바로 되돌릴 수 있다는 전제)

적합한 업무: 코드 생성, 문서 작성, 설정 파일 변경

패턴 B: 단계적 롤백 (DB 트랜잭션형)

에이전트가 여러 조작을 연쇄시키는 케이스. 도중에 실패하면 부분적인 변경이 어중간하게 남는다.

대표 사례:

• 여러 테이블에 대한 DB 쓰기
• 여러 서비스를 가로지르는 API 연동
• 파일 시스템의 일괄 변경

특징:

• 트랜잭션 경계 (Transaction Boundary) 설계가 필수
• 롤백 (Rollback) = 트랜잭션 롤백 (Transaction rollback) 또는 보상 작업 (Compensating action)
• 실패의 영향 범위가 「논리 단위」 내로 한정됨

적합한 업무: 수주/발주 처리, 데이터 이관, 복수 시스템 간의 동기화

패턴 C: 인간 체크포인트 삽입 (HITL pause형)

에이전트가 취소하기 어려운 조작을 실행하기 직전에, 반드시 인간에게 확인을 요청하는 케이스.

대표 사례:

• 메일 전송 전 리뷰
• 공개 게시글의 발행 (Publish) 전 승인
• 고객 대상 자동 답장의 회수

특징:

• 속도는 저하됨 (인간의 응답 대기)
• 실패의 영향 범위를 「인간의 판단 실수」로 좁힐 수 있음
• 에이전트의 자율성을 희생하여, 부작용 (Side effect) 제어를 선택

적합한 업무: 고객 대응, 대외 커뮤니케이션, 결재 프로세스

패턴 D: 사전 합의에 의한 fail-safe 가드레일

에이전트가 완전히 취소할 수 없는 조작을 하는 경우의 최종 수단.

대표 사례:

• 금전 결제 실행
• 물리 디바이스로의 명령 송신
• 제3자에게 전달되는 액션 (SMS, 전화 발신)

특징:

• 「다시 하기」 자체가 불가능하므로,
  사전에 할 수 있는 것으로 제어함 - 상한 금액, 허용된 도메인, 시간대 제한 등의 가드레일 (Guardrail)
• 에이전트의 조작 전 다단계 체크

적합한 업무: 결제, 물리 제어, 대외적으로 되돌릴 수 없는 조작

4가지 패턴의 선택 방법

하나의 시스템에서 4가지를 모두 구분하여 사용하는 것이 일반적이다. "이 업무는 A이고, 이 업무는 C이다"라고 업무 단위로 결정한다.

결정 순서는 다음과 같다.

• 그 조작은 취소할 수 있는가? → No라면 D
• 취소할 수 있다면, 자동인가 수동인가? → 수동 판단이 필요하다면 C
• 연쇄 조작인가 단발성인가? → 연쇄라면 B
• 단발성이며 추가형인가? → A

이 흐름을 먼저 거치면, 에이전트 도입 설계가 뒤로 돌아가는 일을 방지할 수 있다.

판단 축: 업무 크리티컬리티 (Criticality) × 롤백 용이성

업무와 롤백 설계를 매핑하는 2축 매트릭스를 사용하면 정리가 깔끔하게 진행된다.

2축의 정의

세로축: 업무 크리티컬리티 (Criticality)

• 높음: 실패 시 고객 / 매출 / 신뢰에 직접적인 타격
• 낮음: 실패해도 사내에서 완결 가능, 복구(Recovery) 가능

가로축: 롤백 용이성

• 높음: 수 초 ~ 수 분 내에 실패 전으로 되돌릴 수 있음 (패턴 A, B)
• 낮음: 되돌리는 데 수 시간 이상 소요되거나, 되돌릴 수 없음 (패턴 C, D)

4사분면과 권장 대응

제1사분면 (높은 크리티컬리티 × 높은 롤백 용이성)

• 예: 운영 코드의 자동 수정, 운영 DB의 자동 마이그레이션
• 권장: 패턴 A / B + 모니터링 강화
• 에이전트를 적극적으로 사용할 수 있음. 실패해도 즉시 되돌릴 수 있다는 전제.

제2사분면 (낮은 크리티컬리티 × 높은 롤백 용이성)

• 예: 문서 생성, 사내 태스크의 일괄 처리
• 권장: 패턴 A, 인간의 리뷰가 거의 불필요
• 에이전트의 자율성을 최대화해도 문제없음.

제3사분면 (낮은 크리티컬리티 × 낮은 롤백 용이성)

• 예: 사내 통지 메일, 정형 보고서 전송
• 권장: 패턴 C (전송 전 프리뷰)
• "크리티컬리티가 낮으니까"라고 방심하면, 신뢰 저하가 누적됨.

제4사분면 (높은 크리티컬리티 × 낮은 롤백 용이성)

• 예: 고객 대상 메일 전송, 결제, 계약서 송부
• 권장: 패턴 D + 인간의 최종 승인
• 에이전트의 자율 실행은 금지. 인간이 트리거를 당기는 역할을 담보함.

「완벽한 8할보다, 실패 비용이 저렴한 7할」의 의미

이 2축 매트릭스를 사용하면, SWE-bench 점수나 벤치마크 순위보다, 자사의 업무 분포에서 제4사분면이 얼마나 많은가가 에이전트 선택의 결정 요소가 된다.

제4사분면이 많은 업무 (금융, 의료, 법무)에서는 성능이 높더라도 롤백 설계가 취약한 에이전트는 채택되지 않는다. 반대로 제1~2사분면이 많은 업무 (사내 도구, 개발 지원, 사내 문서)에서는 성능이 낮더라도 롤백 설계가 견고한 에이전트가 채택된다.

「완벽한 8할보다, 실패 비용이 저렴한 7할이 돌아간다」는 표현은 이 제4사분면의 존재를 의식한 것이다.

1차 소스

이 기사에서 참조한 1차 소스.

• InfoQ - Anthropic's Code with Claude Announces Managed Agents, Proactive Workflows, Capability Curve (2026/05): https://www.infoq.com/news/2026/05/code-with-claude/ Anthropic이 2026년 5월 Code with Claude에서 발표한 Managed Agents, Dreaming (멀티 에이전트 간의 메모리 공유), Advisor, Remote Agents, CI auto-fix 등에 대한 리뷰. 프로덕션 운영 에이전트의 미결 과제들을 깊이 있게 다루고 있다. -
  OpenAI - Evaluate agent workflows (2026): https://developers.openai.com/api/docs/guides/agent-evals 에이전트 워크플로우 (Agent workflows) 평가 가이드. Trace + Grader를 통해 end-to-end 동작을 채점하는 방식, HITL (Human-in-the-loop)과 LLM-as-judge의 병용 베스트 프랙티스. -
  buildmvpfast.com - AI Agent Versioning and Rollback (2026): https://www.buildmvpfast.com/blog/agent-versioning-rollback-production-ai-update-zero-downtime-2026 프로덕션 에이전트의 버전 관리 및 롤백 (Rollback) 설계. Blue-Green, 카나리 (Canary), prompt pinning 등의 패턴 정리. 본 기사의 롤백 4가지 패턴 분류는 이곳의 정리를 바탕으로 하고 있다. -
  Kili Technology - AI Benchmarks 2026: Top Evaluations and Their Limits (2026): https://kili-technology.com/blog/ai-benchmarks-guide-the-top-evaluations-in-2026-and-why-theyre-not-enough 벤치마크 평가와 프로덕션 운영 사이의 격차를 논의. 엔터프라이즈 환경에서 랩 스코어 (Lab score)와 실제 운영 사이에 37%의 성능 차이가 있으며, 동일 정밀도에서 50배의 비용 변동이 있다는 데이터가 정리되어 있다. -
  Latent Space podcast (2026): https://www.latent.space/podcast AI 엔지니어를 위한 인터뷰 모음. 장기 운영 에이전트의 설계 판단 (Andon Labs의 long-horizon 운영 사례 등)이 본 기사의 「재작업 비용」 축을 고찰하는 데 배경이 되었다.

요약

2026년 6월 시점에서, AI 에이전트를 선택하는 기준은 「성능」에서 **「재작업 비용」**으로 무게 중심이 이동하고 있다.

평가 축을 「태스크 성공률 + 실패 탐지율 + 롤백 공수 + 부작용 범위」의 4가지로 재구성하고, 롤백 설계를 A~D의 4가지 패턴으로 나누어 업무별로 적용한다.

업무 중요도(Criticality)와 롤백 용이성이라는 2개 축의 매트릭스를 통해 자사의 업무 분포를 확인하면, 필요한 에이전트의 모습이 보인다.

「완벽한 8할보다, 실패 비용이 저렴한 7할이 돌아간다」는 표현은 이 제4사분면의 존재를 의식한 것이다. 성능 벤치마크만 보고 선택하면 여기서 막히게 된다.

Discussion