신뢰할 수 있는 AI 에이전트가 실제 비즈니스 시스템을 변경할 수 있도록 허용되기 전에는 안전한 재시도(Retries), 중복 제거(Deduplication), 그리고 보상 작업(Compensating actions)이 필요합니다.

요약 (TL;DR)

도구를 호출할 수 있는 AI 에이전트는 결국 동작을 반복하게 됩니다.

모델은 타임아웃(Timeout) 후에 재시도할 수 있습니다. 큐(Queue)는 이벤트를 재전송할 수 있습니다. 워커(Worker)는 API 요청을 완료한 후 결과를 기록하기 전에 재시작될 수 있습니다.

멱등성(Idempotency)이 없다면, 하나의 논리적 동작이 다음과 같은 결과를 초래할 수 있습니다:

• 두 개의 송장 (Invoices)
• 두 개의 CRM 레코드
• 두 개의 구매 주문 (Purchase orders)
• 반복되는 이메일
• 중복된 승인 작업
• 충돌하는 상태 업데이트

따라서 신뢰할 수 있는 AI 에이전트에게는 정확한 추론 이상의 것이 필요합니다. 모든 실세계 동작은 안정적인 식별자(Stable identity), 중복 제거 전략(Deduplication strategy), 그리고 정의된 복구 경로(Recovery path)를 가져야 합니다.

위험한 부분은 모델이 결정을 내린 직후부터 시작됩니다

대부분의 AI 에이전트 데모는 추론(Reasoning)에 집중합니다:

1. 입력을 읽습니다.
2. 요청을 이해합니다.
3. 무엇을 할지 결정합니다.
4. 도구(Tool)를 호출합니다.

네 번째 단계가 바로 운영 환경에서의 실패가 시작되는 지점입니다.

에이전트가 외부 API를 통해 결제 알림을 보낸다고 가정해 봅시다. 외부 서비스는 요청을 수락했지만, 에이전트가 확인을 받기 전에 연결이 타임아웃(Timeout)되었습니다.

에이전트는 무엇을 해야 할까요?

만약 맹목적으로 재시도한다면, 고객은 동일한 알림을 두 번 받을 수 있습니다. 재시도하지 않는다면, 알림이 영영 전송되지 않을 수도 있습니다.

이것은 일차적으로 AI 추론의 문제가 아닙니다. 이는 분산 시스템(Distributed-systems)의 문제입니다.

네트워크는 실패합니다. 워커(Workers)는 재시작됩니다. 메시지는 재전송됩니다. 응답은 늦게 도착합니다. 신뢰할 수 있는 시스템은 재시도가 발생할 것임을 가정하고, 반복된 작업이 안전하도록 만듭니다.

멱등성(Idempotency)이란 무엇인가?

어떤 동작을 여러 번 수행하더라도 한 번 수행했을 때와 동일한 의도된 결과를 생성한다면, 그 동작은 멱등성(Idempotent)을 가졌다고 합니다.

레코드를 읽는 것은 보통 멱등적입니다. 프로젝트 상태를 approved로 업데이트하는 것 또한 업데이트를 반복해도 레코드가 동일한 상태로 남기 때문에 멱등적일 수 있습니다.

송장(Invoice)을 생성하거나, 이메일을 보내거나, 구매 주문(Purchase order)을 발행하는 것은 다릅니다. 요청을 반복하면 또 다른 실제 세계의 효과(Real-world effect)를 발생시킬 수 있습니다.

AWS는 클라이언트가 동일한 논리적 연산을 여러 번 처리하지 않고도 요청을 재시도할 수 있도록, 상태를 변경하는 연산(Mutating operations)을 멱등적(Idempotent)으로 만들 것을 권장합니다.

AI 에이전트의 경우, 이는 플랫폼이 도구 호출(Tool call)이 다음 중 무엇을 나타내는지 반드시 알아야 함을 의미합니다:

• 새로운 비즈니스 액션 (New business action)
• 이전 액션의 재시도 (Retry of an earlier action)
• 이전 액션에 대한 수정 (Correction to an earlier action)
• 의도적인 두 번째 액션 (Deliberate second action)

언어 모델(Language model)이 대화 문맥(Conversational context)만으로 이를 판단해서는 안 됩니다.

모든 액션에 안정적인 식별자 부여하기

각각의 의도된 비즈니스 액션은 재시도 시에도 변하지 않는 액션 ID(Action ID)가 필요합니다.

이 식별자는 개별 실행 시도가 아닌 워크플로(Workflow)로부터 생성되어야 합니다.

예를 들어, 알림(Reminder) 액션은 다음과 같은 요소로 식별될 수 있습니다:

• 워크플로 인스턴스 (Workflow instance)
• 액션 유형 (Action type)
• 대상 레코드 (Target record)
• 알림 단계 (Reminder stage)
• 관련 날짜 또는 버전 (Relevant date or version)

만약 에이전트가 동일한 알림을 재시도한다면, 동일한 액션 ID를 사용합니다. 만약 프로세스가 나중에 새로운 알림 단계에 도달한다면, 다른 ID를 부여받게 됩니다.

이러한 구분이 중요합니다. 재시도할 때마다 생성되는 무작위 식별자(Random identifier)는 멱등성을 제공하지 못하는데, 수신 서비스가 각 시도를 새로운 요청으로 간주하기 때문입니다.

Stripe는 멱등성 키(Idempotency keys)를 통해 이 원칙을 적용합니다. 클라이언트는 동일한 키를 사용하여 상태 변경 요청을 재시도할 수 있으며, API는 변경 연산을 다시 수행하는 대신 이전에 저장된 결과를 반환할 수 있습니다.

액션 원장(Action Ledger) 저장하기

에이전트 플랫폼은 외부 액션에 대한 내구성이 있는 기록(Durable record)을 유지해야 합니다.

유용한 액션 원장에는 다음이 포함됩니다:

도구를 실행하기 전에 시스템은 원장을 확인합니다.

만약 액션이 완료되었다면, 저장된 결과를 반환합니다. 만약 이미 실행 중이라면, 중복된 요청은 대기하거나 중단됩니다. 만약 재시도 가능한 오류(Retryable error)로 실패했다면, 시스템은 동일한 액션 식별자 하에 재시도를 수행합니다.

원장(Ledger)은 에이전트가 무엇을 의도했는지를 암시하는 기록이 아니라, 에이전트가 실제로 무엇을 수행했는지에 대한 신뢰할 수 있는 단일 출처(Source of truth)가 됩니다.

결정(Decisions)과 부수 효과(Side Effects)의 분리

AI 에이전트는 플랫폼이 부수 효과(Side effect)를 수행하기 전에 제안된 액션(Proposed action)을 생성해야 합니다.

제안된 액션은 다음과 같을 수 있습니다:

• 기회 상태 업데이트 (Update opportunity status)
• 리마인더 이메일 발송 (Send reminder email)
• 조달 작업 생성 (Create procurement task)
• 승인 요청 (Request approval)
• 연체 결제 에스컬레이션 (Escalate overdue payment)

그 후 결정론적 실행 계층(Deterministic execution layer)이 다음 사항을 검증합니다:

• 이 액션이 허용되는가?
• 이미 완료되었는가?
• 파라미터(Parameters)가 유효한가?
• 승인이 필요한가?
• 안전하게 재시도할 수 있는가?
• 이후 단계가 실패할 경우 보상(Compensation)이 가능한가?

이를 통해 명확한 경계가 만들어집니다.

모델은 상황을 해석하고, 실행 계층은 비즈니스 시스템을 보호합니다.

신뢰할 수 있는 핸드오프(Handoffs)를 위한 트랜잭션 아웃박스(Transactional Outbox) 사용

애플리케이션이 자체 데이터베이스를 업데이트하는 동시에 다른 시스템에 알림을 보내야 할 때 또 다른 실패가 발생합니다.

에이전트가 공급업체 요청을 승인으로 표시한 후, 구매 작업을 생성해야 하는 이벤트를 발행한다고 가정해 봅시다.

만약 데이터베이스 업데이트는 성공했지만 이벤트 발행에 실패한다면, 요청은 승인된 것으로 표시되지만 구매 시스템은 작업을 전달받지 못하게 됩니다.

트랜잭션 아웃박스 패턴(Transactional outbox pattern)은 비즈니스 업데이트와 외부로 나가는 이벤트를 동일한 데이터베이스 트랜잭션 내에 저장함으로써 이러한 이중 쓰기(Dual-write) 문제를 해결합니다. 별도의 워커(Worker)가 나중에 이벤트를 발행하므로, 핸드오프(Handoff)를 복구 가능한 상태로 만듭니다.

아웃박스(Outbox)가 중복을 제거해주지는 않습니다. 일반적으로 최소 한 번 전달(At-least-once delivery)을 보장하므로, 컨슈머(Consumer)는 여전히 중복 제거(Deduplication)와 멱등성 처리(Idempotent processing)를 수행해야 합니다.

책임을 다음과 같이 생각하십시오:

• 아웃박스 (Outbox): 이벤트 유실 방지
• 멱등성 키 (Idempotency key): 반복된 요청 식별
• 컨슈머 중복 제거 (Consumer deduplication): 중복된 결과 방지
• 액션 원장 (Action ledger): 전체 실행 이력 기록

모든 액션을 자연스럽게 멱등하게 만들 수는 없음

어떤 작업들은 단순히 반복할 수 없습니다.

이미 발송된 이메일은 발송 취소를 할 수 없습니다. 공급업체가 수락한 구매 주문(Purchase order)은 계약상의 의무를 생성할 수 있습니다. 고객은 시스템이 해당 알림이 잘못되었음을 발견하기 전에 알림에 따라 행동할 수도 있습니다.

이러한 액션의 경우, 시스템은 다음 세 가지 전략 중 하나를 사용해야 합니다.

1. 반복 방지 (Prevent repetition)

고유한 액션 키(Unique action key)를 사용하여 중복 실행을 거부합니다.

2. 목적지를 멱등하게 만들기 (Make the destination idempotent)

외부 API에 동일한 키를 전달하여 해당 API가 원래의 결과를 반환하도록 합니다.

3. 보상 액션 정의 (Define a compensating action)

완료된 단계를 직접 롤백(Rollback)할 수 없는 경우, 예약 취소, 역분개(Reversal) 발행 또는 수정 기록 생성과 같은 도메인 특화된 교정 작업을 실행합니다.

Microsoft의 보상 트랜잭션 패턴(Compensating transaction pattern)은 후속 단계의 실패로 인해 이미 완료된 액션을 비즈니스 특화 로직을 통해 되돌리거나 수정해야 하는 다단계 워크플로(Multi-step workflows)를 위해 설계되었습니다.

보상(Compensation)은 이력을 삭제하는 것과 다릅니다. 원래의 액션과 그에 대한 수정 사항은 모두 가시적으로 남아 있어야 합니다.

실행 전 도구 호출 분류 (Classify Tool Calls Before Production)

에이전트에게 도구에 대한 접근 권한을 부여하기 전에, 사용 가능한 모든 액션을 분류하십시오.

읽기 전용 (Read-only)

기록 검색, 프로젝트 상태 조회, 재고 확인 등이 예시입니다.

이러한 작업은 일반적으로 재시도(Retry)하기에 안전합니다.

멱등적 변이 (Idempotent mutation)

상태를 특정 값으로 설정하거나 알려진 소유자를 할당하는 것 등이 예시입니다.

원하는 최종 상태가 명시적인 경우, 이러한 작업은 대개 안전하게 반복할 수 있습니다.

중복 제거된 생성 (Deduplicated creation)

태스크, 인보이스(Invoices), 알림 또는 CRM 기록을 생성하는 것 등이 예시입니다.

이러한 작업에는 안정적인 액션 식별자(Action identities)와 중복 방지 기능이 필요합니다.

가역적 액션 (Reversible action)

용량 예약 또는 초안 생성 등이 예시입니다.

이러한 작업에는 정의된 취소 또는 보상 경로가 필요합니다.

불가역적 또는 고영향 액션 (Irreversible or high-impact action)

결제 승인, 기록 삭제 또는 구속력 있는 약정 발행 등이 예시입니다.

이러한 작업은 더 엄격한 정책 제어가 필요하며, 일반적인 에이전트 도구로 노출되어서는 안 됩니다.

이러한 분류는 AI 에이전트가 "자율적(autonomous)"인지 묻는 것보다 더 유용합니다. 중요한 질문은 각 도구가 무엇을 변경할 수 있는지, 그리고 실행이 불확실해졌을 때 시스템이 어떻게 복구되는가입니다.

신뢰할 수 있는 AI 에이전트 실행 흐름 (A Reliable AI Agent Execution Flow)

프로덕션 환경의 도구 호출(tool call)은 다음 시퀀스를 따라야 합니다:

1. 에이전트가 구조화된 동작(structured action)을 제안합니다.
2. 플랫폼이 권한과 정책을 검증합니다.
3. 워크플로(workflow)가 안정적인 동작 ID(action ID)를 할당합니다.
4. 동작 원장(action ledger)을 확인하여 기존 결과가 있는지 점검합니다.
5. 플랫폼이 동작을 예약하거나 기록합니다.
6. 지원되는 경우, 멱등성 키(idempotency key)와 함께 외부 도구를 호출합니다.
7. 결과와 외부 참조(external reference)를 저장합니다.
8. 재시도 가능한 실패(retryable failures)는 동일한 동작 식별자(action identity)를 사용합니다.
9. 영구적 실패(permanent failures)는 예외 경로(exception path)로 진입합니다.
10. 부분적 완료(partial completion)는 필요한 경우 보상(compensation)을 트리거합니다.

이 패턴은 에이전트가 CRM을 업데이트하거나, 조달을 조정하거나, 프로젝트 리마인더를 보내거나, ERP를 동기화하는 경우 모두에 적용됩니다.

자주 묻는 질문 (Frequently Asked Questions)

AI 에이전트는 왜 도구 호출을 반복하나요?

도구 호출은 네트워크 타임아웃(network timeouts), 애플리케이션 재시도(application retries), 큐 재전송(queue redelivery), 워커 재시작(worker restarts) 또는 이전 요청이 완료되었는지에 대한 불확실성 때문에 반복될 수 있습니다.

멱등성 키(idempotency key)란 무엇인가요?

멱등성 키는 동일한 논리적 작업의 반복된 시도에 부착되는 안정적인 식별자입니다. 이를 통해 수신 시스템은 재시도를 인식하고 부수 효과(side effect)를 다시 수행하는 것을 방지할 수 있습니다.

재시도 로직(retry logic)만으로 신뢰할 수 있는 AI 에이전트를 만들 수 있나요?

아니요. 재시도는 가용성(availability)을 향상시키지만 중복된 효과를 발생시킬 수 있습니다. 재시도 로직은 멱등성(idempotency), 중복 제거(deduplication), 시도 횟수 제한(limited attempts), 백오프(backoff) 및 관찰 가능한 실패 처리(observable failure handling)와 결합되어야 합니다.

롤백(rollback)과 보상(compensation)의 차이점은 무엇인가요?

롤백은 트랜잭션(transaction) 내에서 작업을 되돌립니다. 보상은 이전에 완료된 단계를 수정하거나 상쇄하는 별도의 비즈니스 작업을 수행합니다.

신뢰할 수 있는 에이전트는 불확실성을 중심으로 구축됩니다

AI 워크플로가 중복 작업을 생성하기 위해 모델이 동일한 실수를 두 번 반복할 필요는 없습니다.

인프라는 단 한 번만 불확실해지면 됩니다.

따라서 프로덕션 에이전트(production agent)는 요청이 재시도될 수 있고 이벤트가 여러 번 전달될 수 있음을 가정해야 합니다. 안정적인 액션 ID(action IDs), 멱등성 키(idempotency keys), 액션 원장(action ledgers), 트랜잭션 아웃박스(transactional outboxes) 및 보상 작업(compensating actions)은 이러한 불확실성을 통제 가능한 엔지니어링 문제로 전환해 줍니다.

실제 프로세스를 자동화하기 전에, 무엇을 먼저 자동화해야 하는지 식별하십시오. 그런 다음 모든 가능한 액션을 위험도, 재시도 동작 및 복구 경로에 따라 분류하십시오.

만약 이러한 에이전트의 배후 시스템을 설계하고 있다면, 제품이 성장함에 따라 신뢰할 수 있고 프로덕션 준비가 된 아키텍처를 심도 있게 고민하기 위해 MVP에서 확장 가능한 SaaS 아키텍처 가이드를 참고하는 것이 더 나은 다음 단계가 될 것입니다.

에이전트가 신뢰할 수 있는 이유는 보통 올바른 액션을 선택하기 때문이 아닙니다.

액션이 두 번 시도된 후에도 시스템이 올바른 상태를 유지할 때, 비로소 신뢰할 수 있는 것입니다.