상담원 워크플로 복구 워크플로 설정: 구현 원칙 및 실무 가이드

에이전트 워크플로 복구 워크플로란 무엇인가요?

에이전트 워크플로 복구 워크플로는 에이전트 실행 중 오류, 시간 초과 또는 외부 중단으로 인해 워크플로가 실패하는 경우 자동 또는 수동으로 일관된 상태로 복원할 수 있는 메커니즘 집합입니다. 단일 도구가 아니라 상태 지속성, 체크포인트, 재시도 로직, 보상 작업을 결합한 시스템 설계입니다.

많은 개발자가 처음 에이전트 작업을 시작할 때 도구 정의, 단계 정렬, 정상적인 결과 처리 등의 진행 경로에만 집중합니다. 그러나 네트워크 지터, LLM 출력 형식 이상 또는 도구 호출 시간 초과가 발생하면 전체 작업 흐름이 중단되거나 더티 데이터가 생성됩니다. 이때 복구 워크플로가 필수가 됩니다.

중요한 이유: 실제 시나리오

사용자 질문 수신 -> 지식 기반 검색 -> CRM에 전화하여 주문 정보 얻기 -> 응답 생성을 담당하는 고객 서비스 에이전트를 구축한다고 가정해 보겠습니다. 기술 자료 검색 단계 시간이 초과되고(예: 타사 API 중단) 복구 워크플로가 없는 경우 에이전트는 오류를 직접 보고할 수 있으며 사용자는 응답을 받지 못합니다. 설상가상으로 이미 CRM 통화가 이루어지고 주문 상태가 변경(예: "처리 중"으로 표시)되었으며 이때 실패하면 상태가 일관되지 않아 후속 수동 개입이 어려워집니다.

복구 워크플로를 사용하면 시간 초과 후 다음을 수행할 수 있습니다. ① 검색을 2회 다시 시도합니다. ② 그래도 실패하면 로컬 캐시로 다운그레이드하세요. ③ 캐시가 없는 경우 단계를 실패로 표시하고 사용자에게 "일부 정보를 사용할 수 없음"을 알리고 후속 수동 검토를 위해 컨텍스트를 기록합니다. 보상 작업은 다운그레이드하기 전에 CRM 호출을 롤백하므로 전체 프로세스에서는 CRM 상태를 삭제하지 않습니다.

에이전트 워크플로 복구 워크플로 설정 실제 단계

1. 체크포인트 정의(Checkpoint)

워크플로의 각 중요한 단계(일반적으로 외부 시스템에 부작용이 있는 작업 전후)에 검사점을 삽입합니다. 현재 에이전트의 전체 컨텍스트(상태, 실행된 단계, 중간 결과)를 데이터베이스 또는 객체 저장소와 같은 영구 저장소에 직렬화합니다.

# 示例：在步骤前后保存 checkpoint
import json, boto3
s3 = boto3.client('s3')

def save_checkpoint(session_id, step_name, context):
    data = {
        'session_id': session_id,
        'step': step_name,
        'context': context,  # 包含所有变量、工具调用历史
        'timestamp': datetime.utcnow().isoformat()
    }
    s3.put_object(Bucket='agent-checkpoints', Key=f'{session_id}/{step_name}.json', Body=json.dumps(data))

가장 흔한 실수: 경량 상태만 저장하고 도구 호출 기록을 무시합니다. 복원할 때 LLM은 이전에 말한 내용을 알지 못하므로 이를 반복적으로 호출하거나 충돌을 일으킵니다. 전체 대화 기록과 도구 호출 결과를 저장해야 합니다.

2. 멱등성 구현(Idempotency)

부작용이 있을 수 있는 모든 도구 호출에는 멱등성 키가 필요합니다. 예를 들어 이메일 전송 API는 재시도가 두 번 발생하지 않도록 중복 제거 키를 지원해야 합니다. 멱등성이 아닌 경우 재시도 자체가 실패의 원인이 됩니다.

3. 복구 전략 설계

세 가지 일반적인 복구 전략이 있습니다.

• 자동 재시도: 일시적인 오류(네트워크 시간 초과, 429 너무 많은 요청)의 경우 최대 재시도는 지수 백오프를 사용하여 3회입니다.
• 다운그레이드 경로: 중요한 도구를 사용할 수 없는 경우 대체 도구나 캐시된 데이터가 있습니까? 예를 들어 검색이 실패하면 로컬 인덱스가 대신 사용됩니다.
• 수동 개입: 자동으로 복구할 수 없는 오류(예: 데이터 확인 실패)의 경우 세션 상태가 저장되어 수동 대기열에 푸시되고 적절한 오류 메시지가 사용자에게 반환됩니다.

4. 보상작업 등록(Compensation)

단계가 실패하면 이미 실행된 이전 단계를 롤백해야 할 수도 있습니다. 예를 들어, 주문이 생성되었지만 후속 결제가 실패하는 경우 주문이 자동으로 취소되어야 합니다. 보상 작업은 전진 단계와 일대일로 대응해야 하며 워크플로가 시작될 때 등록되어야 합니다.

compensation_map = {
    'create_order': 'cancel_order',
    'deduct_inventory': 'restore_inventory',
}

def execute_compensation(session_id, failed_step):
    # 反向遍历已执行步骤，执行对应补偿
    for step in reversed(executed_steps):
        if step in compensation_map:
            invoke_tool(compensation_map[step], session_id)

실패 시나리오: 보상 작업 자체도 실패할 수 있습니다. 설계할 때 보상 재시도 및 최종 일관성을 고려하거나 수동으로 처리할 운영 및 유지 관리에 대한 실패를 기록해야 합니다.

가장 들어가기 쉬운 함정

1. 자동 재시도에 대한 과도한 의존: 일부 오류(예: 도구 존재하지 않음, 잘못된 매개변수)의 경우 재시도가 성공하지 못하며 이는 시간과 자원 낭비입니다. 오류는 유형에 따라 분류되어야 하며 일시적인 오류에 대해서만 다시 시도해야 합니다.
2. 컨텍스트 창 무시: 저장된 체크포인트에는 대량의 LLM 대화 기록이 포함되어 있으며 복원 시 컨텍스트 창 제한을 초과할 수 있습니다. 요약하거나 잘라야 합니다.
3. 디버깅 어려움: 복구가 실행되면 로그가 여기저기 흩어져 있어 추적이 어렵습니다. 모든 단계에 추적 ID를 도입하고 로그를 중앙 집중화하는 것이 좋습니다.

Fallback: Recovery Workflow 자체가 실패하는 경우

복구 워크플로의 스캐폴딩(예: 체크포인트 저장소를 사용할 수 없고 보상 작업이 실패하는 경우)의 경우 가장 바깥쪽 전역 커버가 필요합니다.

• 수동으로 대체: 운영 및 유지 관리 알림(예: Slack, PagerDuty)에 오류 세부 정보와 컨텍스트를 보내고 수동 복구를 위해 세션 데이터를 유지합니다.
• 최종 상태 기록: 복구 성공 여부에 관계없이 최종 상태(성공, 실패, 부분 성공)는 이벤트 후 분석을 용이하게 하기 위해 항상 데드 레터 큐(DLQ) 또는 감사 테이블에 기록되어야 합니다.
• 점진적 성능 저하: 체크포인트 쓰기가 실패하는 경우 실행을 계속할 수 있는지 고려합니다(예: 저장하지 않고 로깅만 하는 상태로 다운그레이드).

전체 복구 워크플로의 설계 원칙은 최종 일관성을 보장하고 고스트 상태를 생성하지 않습니다입니다. 완벽한 복구를 추구하지 말고 관찰 가능하고 보상 가능하며 롤링 가능해야 합니다.

다음 단계

일반 개발자에서 에이전트 엔지니어로 전환하는 경우 복구 워크플로를 이해하는 것은 첫 번째 단계일 뿐입니다. 보다 체계적인 학습을 위해서는 에이전트 컨텍스트 관리, 권한 모델, LLM 평가 및 프로덕션 배포에 대한 깊은 이해가 필요합니다.