에이전트 워크플로 재시도 정책이란 무엇인가요? 왜 필요한가요?
에이전트 워크플로는 LLM 호출, 도구 실행, 메모리 읽기 및 쓰기, 외부 API와의 상호 작용 등 여러 단계로 구성됩니다. 네트워크 지터, API 제한, 시간 초과 또는 중간 상태 불일치로 인해 각 단계가 실패할 수 있습니다. 재시도 정책은 특정 단계가 실패할 때 시스템이 재시도해야 하는 방법(재시도 횟수, 간격 길이, 재시도할 가치가 있는 오류, 재시도 중 멱등성을 보장하는 방법)을 결정합니다.
재시도 전략이 없으면 일시적인 오류로 인해 전체 워크플로가 완전히 실패하게 됩니다. 부적절하게 설정된 재시도 전략은 컴퓨팅 성능을 낭비하고 시스템 부하를 증폭시키거나 심지어 실제 버그를 덮을 수도 있습니다.
핵심 메커니즘: 재시도 조건, 백오프 전략 및 시간 초과
1. 다시 시도해 볼 가치가 있는 오류는 무엇입니까?
모든 오류를 다시 시도해야 하는 것은 아닙니다. 두 가지 유형의 오류를 구별합니다.
- 재시도 가능: 네트워크 시간 초과, HTTP 503, API 현재 제한(429), 임시 서비스 사용 불가. 이러한 오류는 재시도 후 복구될 가능성이 더 높습니다.
- 재시도 불가: HTTP 400 매개변수 오류, 401 인증 실패, 403 권한 부족, 404 리소스가 존재하지 않습니다. 이러한 오류를 다시 시도하면 트래픽이 낭비될 뿐이며 단순히 실패하고 경보가 트리거됩니다.
// 伪代码示例
if (error.IsRetriable()) {
executeWithRetry(step, retryPolicy);
} else {
failImmediately(step, error);
}
2. 백오프 전략: 지수 백오프 + 지터
지속적인 재시도는 시스템 정체를 증가시킬 뿐입니다. 표준 접근 방식은 지수 백오프입니다. 즉, 재시도 간격을 두 배로 늘리고 임의 지터를 추가하여 모든 클라이언트가 동시에 재시도하는 것을 방지합니다.
| 재시도 횟수 | 기본 간격(고정) | 지수 백오프(2^n) | 지수 백오프 + 지터 |
|---|---|---|---|
| 1 | 1초 | 1초 | 0.5~1.5초 |
| 2 | 1초 | 2초 | 1.0~3.0초 |
| 3 | 1초 | 4초 | 2.0-6.0초 |
| 4 | 1초 | 8초 | 4.0-12.0초 |
권장 구성: 초기 간격 1초, 최대 간격 30초, 총 시간 초과 제한 60초, 재시도 3~5회.
3. 타임아웃 및 회로 차단기
무한정 기다릴 수는 없습니다. 각 단계에는 독립적인 시간 제한(timeout)이 있어야 하며 전체 워크플로에는 전역 시간 제한이 있어야 합니다. 단계의 연속 실패가 임계값에 도달하면(예: 3회 이내 실패율이 50%를 초과하는 경우) 회로 차단기가 트리거되어 리소스 소진을 방지하기 위해 일정 시간 동안 서비스 또는 단계 재시도를 일시 중지해야 합니다.
실제 시나리오: 외부 날씨 API 호출 시 재시도 실패
에이전트 워크플로에 외부 API를 통해 날씨 데이터를 가져오는 단계가 있다고 가정해 보겠습니다. 특정 요청에서 DNS 확인 시간 초과가 발생하고 재시도가 트리거됩니다. 재시도 전략은 고정 간격 2초, 최대 3회로 설정됩니다. 결과: 다음 2번의 재시도가 모두 시간 초과되었으며 세 번째로 500번의 재시도가 반환되었습니다. 결국 오류로 인해 워크플로가 실패했습니다.
문제 분석:
- 오류 유형이 정확합니다: 네트워크 시간 초과를 다시 시도할 수 있습니다.
- 불합리한 백오프 전략: 2초라는 고정 간격은 너무 빠르며, DNS 문제는 일반적으로 복구하는 데 10초 이상이 필요합니다. 지수 백오프를 사용한 후 첫 번째는 2초, 두 번째는 4초, 세 번째는 8초, 세 번째는 성공할 수 있습니다.
- 회로 차단기 부족: 3회 연속 오류가 발생해도 일시 중지가 없습니다. 에이전트를 트리거하기 위한 후속 요청은 계속해서 재시도되므로 리소스가 낭비됩니다.
개선 후: 지수 백오프 + 퓨즈 스위치, 1분 이내 오류율이 30%를 초과할 경우 퓨즈가 30초 동안 열려서 직접 오류가 발생하고 캐시된 데이터가 다운그레이드됩니다.
쉬운 함정: 멱등성 부족 및 상태 잔여물
재시도의 가장 위험한 위험은 멱등성이 아닌 작업이 여러 번 실행된다는 것입니다. 예를 들어, 에이전트가 결제 인터페이스를 호출하고, 알림을 보내고, 데이터베이스에 쓰는 경우 이러한 작업이 재시도 시 멱등성이 보장되지 않으면 반복적인 공제, 반복적인 알림 및 더티 데이터 쓰기가 발생합니다.
해결책:
- 각 요청에는 고유한 요청 ID(멱등성 키)가 추가되며, 서버는 키를 기반으로 중복을 제거합니다.
- 또는 작업 자체가 멱등성을 갖도록 설계되었습니다. 예를 들어 "인벤토리를 100으로 설정"은 멱등성이고 "인벤토리를 1만큼 감소"는 멱등성이 아닙니다.
또 다른 일반적인 함정은 상태 잔여입니다. 즉, 재시도 전에 중간 상태(예: "처리 중")가 데이터베이스에 기록되었으며 재시도 중에 정리되거나 건너뛰지 않아 논리적 비용이 반복되거나 잠금 시간 초과가 발생합니다. 모범 사례는 재시도 단계 내에서 트랜잭션을 유지하고 실패 시 롤백하거나 중복 허용으로 표시하는 것입니다.
실패 시 대체 계획
재시도가 설정되어 있어도 여전히 실패할 가능성이 있습니다. 대체 경로를 준비해야 합니다.
- 저하: 실패한 단계를 건너뛰고 기본값이나 캐시된 데이터를 사용하여 워크플로를 계속합니다. 예를 들어 날씨 API가 전날의 예측 데이터를 사용하지 못했습니다.
- 수동 개입: 배달 못한 편지 대기열 또는 알람 채널에 오류 정보를 기록한 다음 수동 문제 해결 후 다시 실행합니다.
- 보상 트랜잭션(Saga): 교차 단계 워크플로의 경우 재시도 후에도 단계가 계속 실패하면 이전에 성공한 단계를 롤백하기 위해 보상 작업이 트리거됩니다. 예를 들어, 먼저 주문을 생성한 다음 결제 금액을 공제합니다. 공제에 실패하면 보상으로 주문이 종료됩니다.
- 재시도 대기열: 실패한 단계를 재시도 대기열에 비동기식으로 푸시하고 재시도를 지연하며 기본 프로세스를 차단하지 않습니다.
요약: 실행 가능한 체크리스트
에이전트 워크플로 재시도 정책을 구성할 때 다음 체크포인트를 확인하세요.
- 재시도 가능 오류와 재시도 불가능 오류를 구별하고 재시도 불가능 오류의 경우 직접 실패합니다.
- 지수 백오프 전략을 채택합니다. 초기 간격은 1초, 최대 30초, 25% 랜덤 지터를 추가합니다.
- 총 시간 초과 제한(예: 60초)과 각 단계 시간 초과(예: 10초)를 설정합니다.
- 연속 실패율이 임계값에 도달하면 일시 중지하고 다시 시도하는 회로 차단기를 구현합니다.
- 각 단계가 멱등성 작업인지 확인합니다. 그렇지 않은 경우 멱등성 키를 사용하세요.
- 완전한 작업 흐름 붕괴를 피하기 위해 실패할 경우 다운그레이드 또는 보상 계획을 제공합니다.
- 후속 분석을 용이하게 하기 위해 재시도 횟수, 간격 및 최종 결과를 로그에 기록합니다.
다음 단계: 실제 에이전트 엔지니어가 되기
재시도 전략은 에이전트 워크플로 설계의 한 부분일 뿐입니다. 일반 개발자에서 에이전트 엔지니어로 변신하고 시스템의 컨텍스트 관리, 워크플로 조정, 권한 제어, 메모리 메커니즘 등을 마스터하고 싶다면 고품질 원본 유료 기사와 AI 고급 프로그래밍 과정을 통해 완전한 지식 시스템을 구축하는 데 도움을 받을 수 있습니다.
아직 댓글이 없습니다