AI 자동화 재시도, 횟수 말고 원인으로 나누기

자동화 루프를 돌리다 실패가 나면 보통 "세 번 더 해보고 안 되면 멈춰"처럼 횟수부터 세게 돼요. 그런데 직접 돌려 보니, 이 방식이 오히려 헛도는 재시도를 늘릴 때가 있었어요.

왜 횟수만 세면 문제일까요

원인이 뭐든 똑같이 "몇 번 남았나"만 세면, 금방 풀릴 일과 절대 안 풀릴 일을 구분하지 못해요. 예를 들어 외부 API가 잠깐 죽어 있는 상황은 아무리 즉시 재시도해도 그 순간엔 안 돼요. 여기서 재시도 3회를 다 태워 버리면, 정작 30초 뒤 서비스가 살아났을 때 이미 루프는 포기한 뒤죠.

원인부터 분류하기 — classify_failure

그래서 재시도 로직 앞에 원인을 나누는 단계를 하나 뒀어요. 실패를 잡으면 바로 세지 말고, 먼저 "이게 무슨 종류의 실패인가"를 판별하는 거예요.

실패 감지→원인 분류→라우팅(재시도 · 대기 · 중단)

• 인증 오류(auth): 토큰이나 권한 문제라 재시도해도 그대로예요. 바로 사람에게 넘겨야 해요.
• 도구 오류(tool): 입력이나 호출 방식 문제일 수 있으니 고쳐서 다시 해볼 여지가 있어요.
• 의존성 다운·긴 타임아웃: 지금은 안 되지만 나중엔 될 일이에요. 재시도 횟수를 태우지 말고 잠시 미뤄(defer) 두는 게 맞아요.

이렇게 원인별로 나눠 적용해 봤더니, 안 될 일에 재시도 예산을 낭비하는 경우가 눈에 띄게 줄었어요.

우선순위와 안전장치

원인이 여러 개 겹칠 때는 순서를 정해 뒀어요. auth → tool → dependency 순으로 보면, 사람이 꼭 봐야 하는 문제를 먼저 걸러낼 수 있어요.

• ✓auth 먼저
• ✓tool 다음
• ✓dependency 마지막

그래도 분류 자체가 애매할 때가 있죠. 그럴 때만 백스톱으로 "같은 실패가 3번 연속이면 중단", 그리고 전체 재시도는 최대 10회로 상한을 뒀어요. 원인 라우팅이 1차 방어, 횟수는 마지막 안전망인 셈이에요.

프롬프트·워크플로우에도 그대로

이 패턴은 n8n이나 LLM 파이프라인에도 그대로 붙여 봤어요. LLM이 형식이 깨진 답을 냈을 때와, 벡터 DB가 잠깐 안 붙을 때를 같은 "재시도"로 묶으면 안 되더라고요. 분류 함수 하나(classify_failure)와 라우팅 함수 하나(route_failure)로 나눠 두면, 나중에 실패 종류가 늘어도 갈라 넣기가 쉬웠어요.

라이프케어로그에서 플랜엘(plan-l) 같은 서비스의 자동화 작업을 돌릴 때도, 이 "원인 먼저, 횟수는 나중" 원칙 덕에 새벽에 조용히 멈춰 있는 루프가 줄었어요.

작은 차이 같지만, 재시도를 세기 전에 "왜 실패했지?"를 한 번 물어보는 것만으로 루프가 훨씬 덜 헛돌아요.