에이전트가 한 일을 되돌리는 법 — 4가지 롤백 전략과 그 한계

에이전트가 production 에서 무엇을 하면, 그 무엇 을 되돌릴 수 있어야 한다. 이게 AI 에이전트 도입의 가장 자주 빠지는 요건. "ctrl+z" 정도로 생각하기 쉬운데, production 의 행동을 되돌리는 일 은 작은 자동화 4 종류 + 그 4 종류가 작동 안 하는 시나리오 별도 다.

이 글은 우리가 6개월 동안 정착시킨 4 롤백 전략 과 각각의 한계.

전략 1 — 역행 액션 큐

가장 단순. 에이전트가 모든 액션 직후 그것의 역행 액션 을 큐에 적음. 롤백 시 큐를 역순 으로 실행.

에이전트가 한 액션              → 큐에 추가된 역행 액션
─────────────────────────────┼──────────────────────────
Deploy v2.4.7 to staging      → Deploy v2.4.6 to staging
Update flag enable_x = true   → Update flag enable_x = false
Restart service api-1         → (없음 — restart 는 idempotent)

작동 안 하는 시나리오 — 한 행동이 다른 행동의 입력 일 때. v2.4.7 deploy 후 v2.4.7 의 DB migration 이 자동으로 일어났으면, v2.4.6 으로 롤백 해도 DB 가 맞지 않음.

전략 2 — snapshot 기반

에이전트 행동 직전 에 시스템 상태 snapshot 을 찍음. 롤백 = snapshot 으로 복원.

VM snapshot, DB point-in-time-recovery, k8s deployment revision history 등이 이 패턴.

작동 안 하는 시나리오 — snapshot 이후 발생한 외부 효과. 에이전트가 외부 결제 API 를 호출했으면, snapshot 으로 시스템은 돌아가지만 결제 자체는 발생. 외부 effect 의 보상은 별도 절차 필요.

전략 3 — forward 보정

롤백 대신 새 forward 행동 으로 보정. 예: 잘못된 알람을 보냈으면 수정 알람 을 보냄. 잘못된 deploy 면 새 deploy 로 fix.

이게 production 에서 가장 흔한 롤백 형태. 진짜 "되돌리기" 가 불가능한 행동이 많기 때문.

작동 안 하는 시나리오 — 시간 민감 한 행동. 알람을 보낸 후 15분이 지났으면 수정 알람의 효과가 다름. 15분 동안 받아본 사람은 이미 행동했음.

전략 4 — blast radius 축소 (롤백을 피함)

가장 중요한 전략은 롤백 자체를 피하는 것. 에이전트가 큰 행동 을 하기 전에 작은 행동 으로 영향 범위를 제한.

예:

• production 직접 deploy 없음 — 항상 canary 5% → 검증 → 25% → 100% 순서
• 외부 API 호출 제한 — 한 번에 1건, 결과 검증 후 다음
• DB 변경 2 단계 — schema add (additive only), 후일 add column 사용 시작

이 전략의 한계 — 에이전트의 행동 속도가 느려짐. 사람이 직접 한 번에 하는 일을 에이전트가 5단계로 쪼개 하면 전체 시간이 5배. ROI 가 조건부.

4 전략을 조합 한 우리 패턴

위 4 전략을 조합 해 사용:

에이전트의 행동 종류             | 우선 전략
──────────────────────────────┼────────────────────────────
configuration / flag 변경       | 1. 역행 큐 (가장 단순)
배포                            | 4. blast radius (canary) + 1. 역행 큐
DB schema 변경                  | 4. blast radius (additive only)
외부 API 호출                   | 3. forward 보정 (rollback 불가)
대용량 변경 (수백 행 이상)      | 2. snapshot + 4. blast radius

이 조합이 6개월 후 결정한 답. 처음에는 전략 1 만으로 충분 하다 가정했지만, 첫 DB migration 사고 에서 깨졌다.

한계 — 되돌릴 수 없는 행동

아무 전략으로도 되돌릴 수 없는 행동이 있다:

1. 외부 통보 (이메일, SMS, 결제 confirm)
2. 물리 장비 제어 (스마트팩토리, IoT)
3. 시간 의존 결정 (옛 시각 기반 토큰 무효화)
4. 외부 시스템에 영향 (제3자 trigger)

이런 행동은 에이전트에게 위임 X. 사람이 명시적으로 trigger. 우리 권한 모델에서 별도 카테고리 로 분리. (→ 에이전트가 production 권한을 가질 수 있는가)

누가 이 글을 읽으면 좋은가

지금 production 에이전트 의 권한 경계 를 결정 중인 모든 팀. 권한 부여의 조건 으로 위 4 전략 중 어느 것이 적용되는가 를 명시하면, 사고 시 수습 가능성 이 예측 가능 해진다. 전략 없이 권한 부여 = 사고 = 영구 권한 회수.