LLM 파이프라인 오류 분류 3가지와 재시도 설계

LLM 파이프라인 오류를 코드로 나누려면 retryable, permanent, auth 3가지부터 잡으면 충분한 경우가 많아요. 직접 만들어보니 실패를 한 덩어리로 묶을 때보다, 재시도 가능 여부를 먼저 고르는 쪽이 로그도 읽기 쉽고 DLQ도 덜 지저분했어요.

왜 에러 메시지보다 코드가 먼저일까

혼자 운영하면서 가장 답답했던 건 "실패"만 남는 로그였어요. 돌려 보니 같은 timeout처럼 보여도 성격은 달랐어요. 300초 안에 응답이 안 온 경우는 다시 시도할 수 있지만, 401이나 403은 키나 권한을 고치기 전에는 몇 번을 보내도 같아요. 429와 5xx도 마찬가지예요. 사람 눈에는 비슷한 실패여도 워크플로우 입장에서는 다른 길로 보내야 해요.

요청→오류 분류(retryable · permanent · auth)→backoff 또는 DLQ 또는 즉시 알림

제가 쓰는 기본 분류는 3가지예요

retryable은 429, 5xx, 일시 네트워크 장애처럼 시간이 지나면 풀릴 수 있는 실패예요. 적용해 봤더니 이 부류만 backoff 대상으로 묶는 게 제일 단순했어요.

permanent는 입력이 잘못됐거나 출력 파서 계약이 깨진 경우예요. 테스트해 보면 이런 건 1개 큐에서 여러 번 재시도해도 고쳐지지 않아요. 바로 DLQ나 수동 검토로 보내는 편이 빨라요.

auth는 따로 빼는 게 좋아요. 인증 오류는 기술적으로는 실패지만 운영적으로는 경보에 더 가까워요. 재시도 횟수보다 알림 속도가 중요해요.

코드에 무엇을 남기면 좋을까

직접 만들어보니 error_code, attempt, next_retry_at, last_error 정도 4개 필드만 있어도 시작하기 괜찮았어요. 여기에 상태를 분리해 두면 원인 추적이 빨라져요. 비슷한 맥락은 중복 게시 0을 노리는 outbox 패턴에서도 이어져요.

• ✓retryable은 backoff
• ✓permanent는 DLQ
• ✓auth는 즉시 알림
• ✓상태는 필드 4개부터

라이프케어로그처럼 작은 도구를 여러 개 운영하다 보면, 모델 성능보다 실패 분류가 먼저 체감될 때가 있어요. 처음부터 큰 taxonomy를 만들기보다 3가지 코드와 2개 재시도 필드부터 붙여 보세요. 직접 만들어보니 어디를 자동화하고 어디서 멈춰야 하는지가 훨씬 빨리 보였어요.