AI API 요청이 실패했다고 해서 항상 또 다른 AI API 요청이 필요한 것은 아닙니다.

때로는 재시도(retry)가 일시적인 네트워크 문제를 해결해 주기도 합니다.

하지만 때로는 비용을 두 배로 늘리고, 사용자를 지연시키며, 에이전트(agent)의 동작을 반복하게 만들고, 실제로 조사해야 할 사고를 은폐하기도 합니다.

멀티 모델 (multi-model) AI 제품의 경우, 재시도는 단순한 구현 세부 사항이 아닙니다.

그것은 신뢰성 아키텍처 (reliability architecture)의 일부입니다.

재시도(retry), 폴백(fallback), 그리고 수정(fix)은 서로 다른 동작입니다

AI 요청이 실패했을 때, 시스템은 세 가지 가능한 응답을 가질 수 있습니다:

1. 실패가 일시적일 수 있으므로 동일한 경로를 재시도(Retry)합니다.
2. 기본 경로가 불안정하거나 부적절하므로 다른 경로로 폴백(Fall back)합니다.
3. 중단하고 요청, 워크플로우(workflow), 또는 입력을 수정(fix)합니다.

이 세 가지를 모두 "재시도"로 취급하면 비용이 많이 들고 혼란스러운 동작을 초래합니다.

예를 들어, 타임아웃(timeout)은 동일한 제공업체(provider)를 재시도하는 것을 정당화할 수 있습니다.

하지만 컨텍스트 윈도우 (context-window) 오류는 그렇지 않습니다.

유효하지 않은 JSON은 제약된 복구 프롬프트 (constrained repair prompt)를 필요로 할 수 있습니다.

부실한 RAG 답변은 모델을 변경하기보다 검색 (retrieval) 과정을 점검해야 할 수도 있습니다.

실패한 도구 호출 (tool call)은 전체 모델 요청이 아니라 도구를 재시도해야 할 수도 있습니다.

재시도 코드를 작성하기 전에 실패를 분류하세요

유용한 정책은 실패 분류 (failure classification)에서 시작됩니다.

목표는 재시도 횟수를 최대화하는 것이 아닙니다.

목표는 예측 가능한 실패를 반복하지 않으면서 일시적인 실패로부터 복구하는 것입니다.

모든 워크플로우에는 재시도 예산(retry budget)이 필요합니다

고객 지원 챗봇과 배치 추출 작업 (batch extraction job)은 동일한 재시도 정책을 공유해서는 안 됩니다.

챗봇은 첫 번째 응답을 기다리는 사용자가 있습니다.

배치 작업은 더 긴 복구 시간을 견딜 수 있습니다.

에이전트 (agent)는 상태를 확인하지 않고 두 번 실행되어서는 안 되는 외부 도구를 호출할 수도 있습니다.

실질적인 정책은 다음을 정의합니다:

• 최대 재시도 횟수 (maximum retry count)
• 최대 총 대기 시간 (maximum total waiting time)
• 최대 추가 비용 또는 토큰 예산 (maximum extra cost or token budget)
• 백오프 타이밍 (backoff timing)
• 폴백 조건 (fallback conditions)
• 멱등성 요구 사항 (idempotency requirements)
• 알림 또는 큐 조건 (alert or queue conditions)

예를 들어:

yaml
workflow: support_chat
...