에이전틱 AI 사고 대응: 자율 에이전트를 위한 '실행 취소(Undo)' 버튼 설계하기

자율 에이전트(Autonomous agent)를 일반적인 마이크로서비스(Microservice)처럼 취급해서는 안 됩니다. 전통적인 시스템에서는 서비스가 오작동할 경우 프로세스를 종료하거나 컨테이너 이미지(Container image)를 이전의 안정적인 버전으로 롤백(Roll back)하면 됩니다. 로직이 결정론적(Deterministic)이기 때문에 상태(State)는 대개 일관되게 유지됩니다. 하지만 AI 에이전트는 결정론적이지 않습니다. 이들은 도구 호출(Tool calls)을 통해 세상과 상호작용하는 추론 엔진(Reasoning engines)입니다. 에이전트가 통제를 벗어나 오작동(Rogue)할 때, 프로세스를 종료한다고 해서 방금 조달 시스템에 보낸 API 호출이나 방금 삭제한 데이터베이스 레코드가 취소되지는 않습니다.

기업용 에이전틱 AI(Enterprise agentic AI)에는 전용 사고 대응(Incident response) 계층이 필요합니다. 시스템 안정성을 해치지 않으면서 오작동하는 에이전트를 무력화하기 위해서는 세밀한 감사 추적(Audit trails), 상태 스냅샷(State snapshots), 그리고 인간 참여형(Human-in-the-loop) 킬 스위치(Kill switches)를 결합한 시스템이 필요합니다. 부작용(Side effects)을 되돌릴 방법이 없다면, 당신은 에이전트를 운영하는 것이 아니라 부채(Liability)를 운영하고 있는 것입니다.

자율성의 역설: 왜 '중단(Stop)'이 '롤백(Rollback)'이 아닌가

왜 대부분의 팀이 에이전틱 사고 대응에 실패할까요? 그들은 프로세스 종료(Process termination)와 상태 복구(State restoration)를 혼동하기 때문입니다.

LLM 실행을 중단하는 것은 "킬(Kill)" 명령입니다. 이는 현재의 추론 루프(Reasoning loop)를 멈춥니다. 하지만 에이전트는 이미 도구 호출을 내보낸 상태입니다. 그 호출은 네트워크를 타고 제3자 API나 내부 데이터베이스로 전달되었습니다. 일단 해당 요청이 수락되면, 그것은 "좀비(Zombie)" 액션이 됩니다. 에이전트는 죽었지만, 그 동작은 여전히 당신의 운영 환경(Production environment)에서 살아 움직이고 있습니다.

전통적인 소프트웨어 사고 대응은 코드의 되돌리기에 집중합니다. 하지만 에이전틱 시스템에서의 "버그(Bug)"는 대개 코드에 있는 것이 아니라, 비결정론적인 추론 체인(Non-deterministic reasoning chain)에 있습니다. 10분 전에 발생한 환각(Hallucination)을 "패치(Patch)"할 수는 없습니다. 대신 그로 인해 발생한 상태 변화를 되돌려야 합니다.

전통적 사고 대응 vs 에이전틱 사고 대응. 코드 롤백의 결정론적 특성과, 에이전틱 추론 체인 및 부작용을 되돌리는 과정의 비결정론적 과제를 대조합니다.

옵션	요약	점수
전통적 소프트웨어 (Traditional Software)	코드 버그 또는 인프라 설정 오류로 인한 결정론적 (Deterministic) 실패.	90.0
에이전틱 AI (Agentic AI)	추론 루프 (Reasoning loops), 환각 (Hallucinations), 또는 프롬프트 주입 (Prompt injections)으로 인한 비결정론적 (Non-deterministic) 실패.	40.0

에이전트 환각 탐지 및 완화에 시간을 투자해 보셨다면, 탐지는 싸움의 절반에 불과하다는 것을 알고 계실 것입니다. 나머지 절반은 복구 (Remediation)입니다. 만약 에이전트가 수천 개의 계정에 90% 할인을 적용하기로 잘못 결정했다면, 에이전트를 "중단"하는 것만으로는 계정 문제를 해결할 수 없습니다. 해당 특정 추론 세션 동안 발생한 모든 변경 사항을 식별하고 이를 되돌릴 수 있는 결정론적인 방법이 필요합니다.

에이전틱 폭발 반경 (Agentic Blast Radius) 정의하기

그리고 Supervisor Agent (감독 에이전트)가 필요합니다. 이것은 단순한 또 다른 LLM (Large Language Model)이 아니라, 정책 집행 계층 (policy enforcement layer)입니다. Supervisor Agent는 워커 에이전트 (worker agent)의 도구 호출 (tool calls)을 실시간으로 모니터링합니다. 이는 제안된 동작을 하드코딩된 일련의 안전 제약 조건 (safety constraints)과 대조하여 확인합니다. 만약 워커 에이전트가 정책을 위반하는 동작을 제안하면, Supervisor는 해당 호출이 네트워크에 도달하기 전에 차단합니다. 이 단계에서 에이전트 ID 및 액세스 관리 (agent identity and access management)를 구현하여 Supervisor가 워커를 무시하고 제어할 수 있는 권한을 갖도록 보장해야 합니다.

에이전틱 폭발 반경 아키텍처 (Agentic Blast Radius Architecture)

에이전틱 복구의 기술적 기둥 (The Technical Pillars of Agentic Recovery)

비결정론적 시스템 (non-deterministic system)을 위해 실제로 어떻게 "실행 취소 (undo)" 버튼을 만들 수 있을까요? 모든 에이전트 동작을 트랜잭션 (transaction)으로 취급하는 것부터 시작해야 합니다.

상태 스냅샷 (State-Snapshotting)

캡처하지 않은 것은 롤백(roll back)할 수 없습니다. 에이전트가 위험도가 높은 도구 호출(tool call)을 실행하기 전에, 시스템은 영향을 받는 환경 상태(environment state)의 스냅샷(snapshot)을 찍어야 합니다. 만약 에이전트가 고객 기록을 수정하고 있다면, session_id와 연결된 임시 저장소에 pre_action_state를 저장합니다. 만약 해당 동작이 비정상적(rogue)이라고 판단되면, 기록을 이전 상태로 복구하는 데 필요한 정확한 데이터를 보유하게 됩니다.

멱등성 요구사항 (Idempotency Requirements)

도구가 멱등성(idempotency)을 갖추지 못하면 롤백은 실패합니다. 만약

// Example of an idempotent tool wrapper with state snapshotting
async function executeAgentTool(agentId, toolName, params) {
    const sessionId = getSessionId(agentId);
...}

## 운영화하기: Human-in-the-Loop (HITL) 에스컬레이션

자동으로 롤백할까요? 항상 그런 것은 아닙니다.

자동 복구에 과도하게 의존하면

- **저위험 (Low Risk)**: 사후 로깅 (post-hoc logging)을 동반한 자율 실행.
- **중위험 (Medium Risk)**: 즉각적인 알림과 60초의 "실행 취소 (undo)" 창을 동반한 자율 실행.
- **고위험 (High Risk)**: 실행 전 수동 승인 (manual approval) 필요.

이러한 접근 방식은 안전 시스템 자체가 불안정성의 주요 원인이 되는 "자동화의 역설 (automation irony)"을 방지합니다. 이와 관련된 거버넌스 측면에 대해 더 자세히 알고 싶다면, [멀티 에이전트 시스템 거버넌스를 위한 CTO 블루프린트 (CTO blueprint for governing multi-agent systems)](https://omnithium.ai/blog/cto-blueprint-governing-multi-agent-ai.html)를 확인해 보세요.

## 실무 시나리오: 로직 루프에서 환각 할인까지

이를 실제 실패 사례에 적용해 보겠습니다.

### 시나리오 1: 조달 루프 (The Procurement Loop)

자율 조달 에이전트(autonomous procurement agent)는 하드웨어 재고 수준을 유지하는 업무를 맡고 있습니다. 프롬프트 인젝션 (prompt injection) 또는 로직 루프 (logic loop)로 인해 에이전트가 "수준 유지"를 "매시간 100개 주문"으로 해석하게 됩니다.

**실패 상황**: 에이전트가 2시간 동안 벤더 API에 50건의 대량 주문을 보냅니다.
**대응 방식**:

1. 감독 에이전트 (Supervisor Agent)가 주문량의 비정상적인 급증(시간당 $5,000 상한 초과)을 감지합니다.
2. 조달 도메인에 대해 글로벌 킬 스위치 (Global Kill Switch)가 작동합니다.
3. 사고 대응자 (incident responder)는 감사 추적 (audit trail)을 사용하여 지난 120분 동안 생성된 모든 `order_id`를 식별합니다.
4. 부수 효과 (side effects)를 되돌리기 위해 각 ID에 대해 멱등성 (idempotent)이 보장된 `cancel_order` 도구를 호출합니다.

### 시나리오 2: 할인 환각 (The Discount Hallucination)

고객 대응 에이전트가 존재하지 않는 "봄 세일 (Spring Sale)"을 환각 (hallucinating)하기 시작합니다. 에이전트는 내부 API를 통해 운영 계정에 50% 할인을 적용하기 시작합니다.

**실패 상황**: 200개의 계정에서 `discount_rate`가 수정되었습니다.
**대응 방식**: