재시도(Retries)는 유용합니다.

하지만 일부 AI 작업은 여전히 실패합니다.

문서 추출 작업이 재시도 횟수를 모두 소진합니다. 에이전트(Agent)가 도구 타임아웃(tool timeout) 후 중단됩니다. RAG 인덱싱 작업이 소스 파일에 접근할 수 없습니다. 배치 워크플로(batch workflow)가 컨텍스트 제한(context limit)에 걸립니다.

그다음에는 어떤 일이 일어날까요?

만약 그 답이 "에러 로그를 작성하고 넘어가라"라면, 해당 애플리케이션은 단순한 요청 그 이상을 잃고 있는 것입니다.

작업을 이해하고, 수리하며, 안전하게 재실행(replay)하는 데 필요한 증거를 잃고 있는 것입니다.

이것이 바로 데드 레터 큐(dead letter queues, DLQ)가 중요한 이유입니다.

데드 레터 큐는 복구 경계입니다

데드 레터 큐, 즉 DLQ는 일반적인 재시도 정책(retry policy)이 소진된 후 안전하게 완료될 수 없었던 작업들을 보관합니다.

그곳은 에러를 숨기는 장소가 아닙니다.

실패 컨텍스트(failure context)를 보존하는 장소입니다.

AI 워크플로(workflows)의 경우, 그 컨텍스트에는 다음 내용이 포함될 수 있습니다:

• 워크플로 이름
• 입력 데이터에 대한 참조
• 선택된 모델 및 경로(route)
• 프롬프트(prompt) 또는 설정 버전
• 재시도 횟수
• 폴백 이력(fallback history)
• 에러 분류
• 작업의 안전한 재실행 가능 여부

이는 request failed라고 적힌 한 줄보다 훨씬 더 유용합니다.

AI 실패는 단순히 제공자(provider)의 실패인 경우가 드뭅니다

모델 요청 실패는 여러 가지 원인으로 발생할 수 있습니다:

• 일시적인 제공자 서비스 중단
• 속도 제한(rate limit)
• 과도하게 큰 컨텍스트
• 유효하지 않은 구조화된 출력(structured output)
• 누락된 소스 문서
• 손상된 검색(retrieval)
• 도구 호출(tool-call) 타임아웃
• 지원되지 않는 파라미터
• 승인되지 않은 모델 경로

이러한 문제 중 일부는 재시도로 복구될 수 있습니다.

다른 문제들은 프롬프트 변경, 스키마(schema) 수정, 경로 변경 또는 수동 검토가 필요합니다.

DLQ는 모든 실패에 동일한 해결책이 있는 것처럼 시스템이 가장하는 것을 방지합니다.

AI DLQ는 무엇을 기록해야 할까요?

유용한 기록은 다음과 같은 모습일 수 있습니다:

{
...