신뢰할 수 있는 AI 에이전트는 결코 실수를 하지 않는 에이전트가 아닙니다. 작은 실수가 고객에게 노출되는 엉망진창인 상황으로 번지기 전에, 멈추고, 무슨 일이 일어났는지 설명하며, 복구할 수 있는 에이전트입니다.

에이전트가 잘못된 CRM 필드를 업데이트하거나, 중복된 웹훅 (webhook)을 보내거나, 결제 조회 (payment lookup)를 다섯 번이나 재시도하거나, 미완성된 설정을 운영 환경 (production)에 작성하기 전까지는 이 말이 당연하게 들릴 것입니다. 모델은 똑똑해 보일 수 있습니다. 워크플로 (workflow)는 심지어 success를 반환할 수도 있습니다. 하지만 당신의 시스템은 이제 일반적인 재시도 (retry)로는 해결할 수 없는 손상을 입은 상태입니다.

실제 고객 데이터에 접근하는 에이전트를 구축하고 있다면, 롤백 (rollback) 사고가 발생하기 전에 롤백 계획이 필요합니다. 이 가이드는 실질적인 청사진을 제공합니다.

롤백이 AI 에이전트의 기능이 되고 있는 이유

최근 AI 플랫폼의 활동은 한 방향을 가리키고 있습니다. 바로 에이전트가 실제 업무에 더 가까워지고 있다는 점입니다.

개발자 도구들은 팀 채팅 내에 공유 코딩 에이전트를 추가하고 있습니다. 워크플로 플랫폼들은 에이전트를 문서 (docs), 보드 (boards), 양식 (forms), CRM, 브라우저 (browsers), 그리고 내부 API에 연결하는 것을 더 쉽게 만들고 있습니다. 모델 게이트웨이 (model gateways)와 멀티 모델 플랫폼들은 팀들이 여러 제공업체에 걸쳐 작업을 라우팅하도록 밀어붙이고 있습니다. 오픈 소스 에이전트 프레임워크들은 장기 실행 (long-running execution), 메모리 (memory), 도구 호출 (tool calling), 그리고 로컬 배포 (local deployment) 기능을 계속해서 개선하고 있습니다.

이는 유용합니다. 하지만 동시에 위험하기도 합니다.

AI 에이전트가 상태 (state)를 변경할 수 있는 순간, 롤백은 더 이상

전통적인 애플리케이션은 이미 트랜잭션 (transactions), 큐 (queues), 로그 (logs), 그리고 복구 플레이북 (recovery playbooks)이 필요합니다. AI 에이전트는 이 모든 것에 더해 읽을 수 있는 설명 계층 (explanation layer)이 추가로 필요합니다. 왜냐하면 실패 경로 (failure path)에 자연어 결정 (natural language decisions)이 포함되는 경우가 많기 때문입니다.

액션 원장 (action ledger)으로 시작하기

기록하지 않은 것은 롤백할 수 없습니다.

상태를 변경하는 모든 에이전트 도구 호출 (agent tool call)은 실행 전후에 액션 원장 (action ledger) 항목을 생성해야 합니다. 이 원장은 단순한 관찰 가능성 로그 (observability log)가 아닙니다. 이는 복구를 위한 신뢰할 수 있는 단일 원천 (source of truth)입니다.

type AgentActionLedgerEntry = {
  actionId: string;
  runId: string;
...

주요 필드들은 의도적으로 단순하게 구성되었습니다. actionId는 각 액션에 안정적인 식별자를 부여하고, runId는 액션들을 하나의 워크플로 (workflow)로 연결하며, tenantId는 고객 간 복구 실수를 방지하고, idempotencyKey (멱등성 키)는 중복 쓰기를 방지합니다. 이를 단순히 가공되지 않은 모델 트레이스 (raw model traces)에만 묻어두지 마세요. 트레이스는 디버깅 (debugging)에는 유용하지만, 원장은 운영 (operations)을 위한 것입니다.

롤백 난이도에 따른 액션 분류

모든 도구 호출이 동일한 방식으로 되돌려질 수는 없습니다. 에이전트에게 쓰기 권한 (write access)을 부여하기 전에 각 액션을 분류하십시오.

위험한 카테고리는 "되돌릴 수 있을 것 같지만 실제로는 그렇지 않은" 경우입니다. Slack 메시지는 일부 워크스페이스에서 삭제할 수 있지만, 항상 가능한 것은 아닙니다. 이메일을 보내는 것은 의미 있는 수준으로 되돌릴 수 없습니다. 결제는 종종 환불될 수 있지만, 그것이 카드로 결제되지 않은 것과 동일하지는 않습니다.

되돌릴 수 없는 액션의 경우, 롤백 계획은 예방과 보상 (compensation)의 결합이어야 합니다:

• 실행 전 인간의 승인 (human approval)을 요청합니다.
• 정확한 액션 미리보기를 보여줍니다.
• 범위가 제한된 자격 증명 (scoped credentials)을 사용합니다.
• 명확한 감사 추적 (audit trail)을 저장합니다.
• 후속 보상 경로 (compensation path)를 제공합니다.

모든 쓰기 작업에 멱등성 키 (idempotency keys) 사용

AI 에이전트는 사용자가 생각하는 것보다 더 자주 재시도 (retry)를 합니다. 에이전트는 도구 타임아웃 (tool timeouts), 제공자 오류 (provider errors), 큐 재시작 (queue restarts), 브라우저 탐색 실패 (browser navigation failures), 그리고 모델 폴백 (model fallback) 이벤트 발생 시 재시도를 수행합니다.

쓰기 작업이 멱등성 (idempotent)을 가진다면 괜찮습니다. 하지만 그렇지 않다면 매우 고통스러운 일이 될 것입니다.

멱등성 키 (idempotency key)를 사용하면 도구 계층 (tool layer)에서 "나는 이미 이 논리적 동작을 수행했다"라고 말할 수 있습니다. 에이전트는 부수 효과 (side effect)를 중복시키지 않고 다시 요청할 수 있습니다.

import crypto from 'crypto';

function createIdempotencyKey(input: { 
...

쓰기가 발생하는 경계 지점에서 키를 사용하세요:

async function updateTicketPriority(args: {
  tenantId: string;
  ticketId: string;
...

중요한 세부 사항: 모델은 멱등성을 강제하지 않습니다. 당신의 도구 런타임 (tool runtime)이 강제해야 합니다.

데이터베이스 롤백뿐만 아니라 보상 작업 (compensating actions)을 추가하세요

데이터베이스 트랜잭션 (database transactions)은 작업이 로컬이고 짧을 때 도움이 됩니다. 에이전트 워크플로 (agent workflows)는 종종 길고 분산되어 있습니다. 에이전트는 데이터베이스, 벡터 스토어 (vector store), 티켓팅 API, 캘린더 API, 메시징 시스템, 그리고 브라우저 세션을 호출할 수 있습니다.

이를 위해 사가 패턴 (saga pattern)을 사용하세요. 가능한 경우 모든 순방향 동작 (forward action)에는 보상 작업 (compensating action)이 있어야 합니다.

예시:

보상 작업은 다른 도구와 동일한 안전 규칙을 가진 실제 도구여야 합니다. 장애 발생 중에 모델이 무에서 유를 창조하듯 되돌리기 동작을 만들어내게 두지 마세요.

type CompensationPlan = {
  originalActionId: string;
  compensationTool: string;
...

위험도가 높은 보상의 경우, 사용자에게 어떤 일이 일어날지 보여주세요:

"티켓 T-182를 일반에서 높음으로 변경했습니다. 이를 다시 일반으로 복구하고 수정 사항을 설명하는 노트를 추가할 수 있습니다. 그렇게 할까요?"

그 순간이 신뢰를 쌓습니다. 조용한 복구 (silent recovery)도 유용할 수 있지만, 사용자 데이터가 변경된 경우에는 가시적인 복구 (visible recovery)가 더 좋습니다.

워크플로를 체크포인트 (checkpoints)로 설계하세요

롤백 계획은 에이전트 워크플로에 체크포인트가 있을 때 가장 잘 작동합니다.

체크포인트는 시스템이 추측 없이 재개, 재시도 또는 롤백할 수 있을 만큼 충분한 정보를 가진 안전한 일시 정지 지점입니다.

예를 들어:

1. 요청 이해 (Understand the request).
2. 관련 레코드 가져오기 (Fetch relevant records).
3. 도구 작업 계획 (Plan tool actions).
4. 필요 시 승인 요청 (Ask for approval when needed).
5. 작업 그룹 A 실행 (Execute action group A).
6. 결과 검증 (Verify result).
7. 작업 그룹 B 실행 (Execute action group B).
8. 결과 요약 (Summarize outcome).

각 체크포인트는 다음 사항을 저장해야 합니다:

• 현재 워크플로 상태 (Current workflow state)
• 계획된 작업 (Planned actions)
• 완료된 작업 (Completed actions)
• 대기 중인 작업 (Pending actions)
• 승인 상태 (Approval state)
• 복구 지침 (Recovery instructions)
• 추적 링크 (Trace links)
• 사용자 가시적 요약 (User-visible summary)

이 지점에서 LangGraph 스타일의 상태 그래프 (state graphs), 내구성 있는 워크플로 엔진 (durable workflow engines), 큐 (queues), 그리고 커스텀 오케스트레이션 레이어 (custom orchestration layers)와 같은 프레임워크가 유용해집니다. 특정 프레임워크를 사용하는 것보다 상태 관리 규율 (state discipline)을 지키는 것이 더 중요합니다.

간단한 체크포인트 객체는 다음과 같은 형태일 수 있습니다:

{
  "runId": "run_91x",
  "checkpoint": "after_ticket_update",
...

만약 여기서 워커 (worker)가 중단된다면, 다음 워커는 모델에게 "우리가 어디까지 했는지 파악해 봐"라고 요청해서는 안 됩니다. 대신 체크포인트를 로드해야 합니다.

모델 재시도와 도구 재시도 분리하기

실제 운영 환경에서의 흔한 실수 중 하나는 모든 실패를 모델에게 다시 물어봐야 하는 이유로 취급하는 것입니다.

그렇게 하지 마십시오.

재시도를 다음과 같이 계층별로 분리하십시오:

• 모델 재시도 (Model retry): 응답 형식이 잘못되었거나 (malformed), 불완전하거나, 스키마 (schema)를 위반한 경우.
• 도구 재시도 (Tool retry): API 타임아웃 (timeout)이 발생했거나, 일시적인 오류 (transient error)를 반환했거나, 속도 제한 (rate limit)에 걸린 경우.
• 워크플로 재시도 (Workflow retry): 워커가 충돌(crash)했거나 큐 작업 (queue job)이 재개된 경우.
• 사용자 재시도 (Human retry): 사용자가 계획을 수정하거나 다른 경로를 승인한 경우.

도구 재시도는 일반적으로 검증된 동일한 도구 인자 (tool arguments)와 멱등성 키 (idempotency key)를 재사용해야 합니다. 실패 원인이 잘못된 인자 때문이 아니라면, 모델에게 작업을 다시 생성하도록 요청해서는 안 됩니다.

나쁜 패턴:

도구 타임아웃 → 모델에게 새로운 작업을 생성하도록 요청 → 중복 쓰기 위험 (duplicate write risk)

더 나은 패턴:

도구 타임아웃 → 동일한 idempotencyKey로 동일한 actionId 재시도 → 최종 상태 검증

이렇게 하면 의도치 않은 드리프트 (drift)를 줄일 수 있습니다. 에이전트는 네트워크에 작은 문제가 생길 때마다 작업을 재해석할 새로운 기회를 갖지 않게 됩니다.

모든 중요한 작업 후 검증하기

롤백 (Rollback)은 단순히 되돌리는 것만을 의미하지 않습니다. 이는 언제 되돌리기가 필요한지를 감지하는 것에 관한 것이기도 합니다.

상태를 변경하는 작업 (state-changing action) 이후에는 모델의 확신도 (confidence)에 의존하지 않는 검증 단계 (verification step)를 실행하십시오.

예시:

• 기록을 다시 읽어 들여 예상된 필드와 비교합니다.
• 외부 API 상태를 확인합니다.
• 작업 원장 (action ledger)이 running에서 succeeded로 변경되었는지 확인합니다.
• 테넌트 ID (tenant ID)와 대상 ID (target ID)가 경계값과 일치하는지 검증합니다.
• 결과에 대해 작은 정책 체크 (policy check)를 실행합니다.
• 결과가 외부 영향력을 가질 경우 인간의 확인을 요청합니다.

async function verifyTicketPriority(args: {
  tenantId: string;
  ticketId: string;
...

검증에 실패하면 워크플로 (workflow)가 맹목적으로 계속 진행되도록 두지 마십시오. 해당 실행 건을 복구 큐 (recovery queue)로 이동시키십시오.

인간과 에이전트를 위한 복구 큐 구축하기

복구 큐 (recovery queue)는 실패했거나 의심스러운 실행 건들이 검토를 위해 모이는 곳입니다. 이곳은 지루할 정도로 단순해야 하며, 검색이 가능하고, 운영 측면에서 유용해야 합니다.

포함 항목:

• 실행 ID (Run ID)
• 고객 또는 워크스페이스 (workspace)
• 사용자 요청 (User request)
• 실패한 작업 (Failed action)
• 위험 수준 (Risk level)
• 현재 상태 (Current state)
• 제안된 보상 조치 (Suggested compensation)
• 필요한 승인 (Required approval)
• 추적 링크 (Trace link)
• 실패 후 경과 시간

큐는 다음 세 가지 작업을 지원해야 합니다:

1. 재개 (Resume): 마지막 안전한 체크포인트 (checkpoint)부터 계속 진행합니다.
2. 보상 (Compensate): 미리 정의된 되돌리기 또는 수정 경로를 실행합니다.
3. 종료 (Close): 예상된 결과이거나 이미 처리된 것으로 표시합니다.

위험도가 낮은 내부 변경의 경우 시스템이 자동으로 보상 (auto-compensate)할 수 있습니다. 위험도가 높은 작업의 경우 인간에게 요청하십시오.

이는 특히 1인 개발자나 소규모 팀에게 매우 중요합니다. 완전한 운영 부서를 갖추고 있지는 않더라도, 복구 작업이 로그, Slack 스레드, 또는 기억 속에만 머물지 않도록 방지하는 작은 관리자 페이지를 만들 수 있습니다.

사용자에게 명확한 수정 경로를 보여주기

에이전트가 눈에 보이는 실수를 했을 때, 최악의 대응은 모호한 언어를 사용하는 것입니다.

피해야 할 표현:

“문제가 발생했습니다. 다시 시도해 주세요.”

더 나은 표현:

“재시도 과정에서 잘못된 티켓 우선순위를 업데이트했습니다. 티켓 T-182를 정상 상태로 복구했고, 티켓 T-204는 변경 없이 유지했으며, 해당 사건을 활동 로그 (activity log)에 저장했습니다.”

수정 이력 (correction trail)은 다음 내용을 설명해야 합니다:

• 무엇이 변경되었는가
• 왜 수정되었는가
• 무엇이 복구되었는가
• 무엇을 되돌릴 수 없었는가
• 사람이 검토했는가
• 감사 기록 (audit record)이 어디에 있는가

이는 내부의 사고 과정 (chain-of-thought)이나 가공되지 않은 프롬프트 (raw prompts)를 노출할 필요는 없습니다. 운영상의 사실 (operational facts)을 노출해야 합니다.

실질적인 구현 순서

한 번의 스프린트 (sprint) 만에 완벽한 롤백 플랫폼을 구축할 필요는 없습니다. 위험도가 높은 경로부터 시작하세요.

1단계: 쓰기 도구 (write tools) 인벤토리 작성

상태를 변경하는 모든 에이전트 도구를 나열하세요. 내부 API, 외부 API, 브라우저 동작, 파일 쓰기, 메시지, 그리고 워크플로 트리거 (workflow triggers)를 포함합니다.

2단계: 위험 수준 추가

각 쓰기 작업을 낮음, 중간, 또는 높음 위험으로 표시하세요. 고위험 동작은 승인 또는 더 강력한 검증 경로를 필요로 합니다.

3단계: 멱등성 (idempotency) 추가

중복된 쓰기 작업이 아무런 영향이 없도록 만드세요. 이 한 가지 변화가 많은 끔찍한 사고를 방지합니다.

4단계: 실행 전 스냅샷 저장

되돌릴 수 있는 내부 변경 사항의 경우, 실행 전에 이전 상태를 저장하세요.

5단계: 보상 도구 (compensation tools) 생성

명시적인 실행 취소 (undo) 또는 수정 도구를 정의하세요. 프롬프트 지침 (prompt instructions)에만 의존하지 마세요.

6단계: 체크포인트 (checkpoints) 추가

중요한 단계 이후에 워크플로 상태를 저장하세요. 모델의 메모리가 아닌 상태 (state)로부터 재개해야 합니다.

7단계: 소규모 복구 큐 (recovery queue) 구축

사고 발생 시 로그를 검색하는 것보다 기본적인 관리자 테이블이라도 있는 것이 훨씬 낫습니다.

이것이 더 넓은 AI 아키텍처에 어떻게 부합하는가

롤백은 관측 가능성 (observability), 승인 게이트 (approval gates), 테넌트 격리 (tenant isolation), 평가 (evals), 장애 조치 (failover), 그리고 출력 출처 (output provenance)와 함께 구성되는 복구 계층 (recovery layer)입니다. 강력한 에이전트 아키텍처는 모델이 항상 올바른 선택을 할 것이라고 가정하지 않습니다. 대신 시스템이 모델의 동작을 제약하고, 검증하며, 모델의 행동으로부터 복구해야 한다고 가정합니다.

최종 요약

에이전트(Agents)는 점점 더 유능해지고, 더 많이 연결되며, 실제 업무에 있어 더 큰 신뢰를 얻고 있습니다. 이는 롤백(rollback)이 단순한 엔지니어링 정리 작업이 아니라, 하나의 제품 기능(product feature)이 되어야 함을 의미합니다.

만약 당신의 AI 에이전트가 고객 데이터를 변경할 수 있다면, 에이전트는 다음 세 가지 질문에 답할 수 있어야 합니다:

1. 내가 정확히 무엇을 변경했는가?
2. 이를 안전하게 되돌리거나(undo) 보상(compensate)할 수 있는가?
3. 복구 경로(recovery path)가 제대로 작동했음을 증명할 수 있는가?

사고가 발생하기 전에 이를 구축하십시오. 미래의 당신이 고마워할 것입니다.

FAQ

AI 에이전트 롤백 계획(rollback plan)이란 무엇인가요?

AI 에이전트 롤백 계획은 잘못되었거나 부분적인 에이전트 작업으로부터 복구하기 위한 기술적 패턴의 집합입니다. 여기에는 일반적으로 작업 원장(action ledgers), 멱등성 키(idempotency keys), 사전 스냅샷(before snapshots), 보상 작업(compensating actions), 체크포인트(checkpoints), 검증 단계(verification steps), 그리고 복구 큐(recovery queue)가 포함됩니다.

모든 AI 에이전트 작업이 롤백 가능한가요?

아니요. 내부 업데이트는 종종 되돌릴 수 있지만, 이메일, 결제, 제출된 양식, 제3자 메시지와 같은 외부 작업은 보상(compensatable)만 가능할 수 있습니다. 이러한 작업의 경우 승인 게이트(approval gates), 미리보기(previews), 감사 로그(audit logs), 그리고 수정 워크플로우(correction workflows)를 사용하십시오.