재시도 횟수 대신 실패 원인으로 라우팅하는 자율루프 설계
AI 자율루프가 3회 실패하면 무조건 멈추는 방식은 왜 위험할까요. 실패를 원인별로 분류해 라우팅하는 재시도 설계를 정리했어요.
AI 에이전트에 자율 루프를 붙이면 제일 먼저 넣게 되는 안전장치가 재시도 상한이에요. 3회 실패하면 멈춘다, 10회 돌면 중단한다. 저도 처음엔 그렇게 짰는데, 직접 돌려 보니 이 방식이 엉뚱한 곳에서 걸리더라고요.
횟수 카운터가 놓치는 것
상황을 하나 떠올려 볼게요. 루프가 외부 API를 호출하는데 그 서비스가 점검 중이에요. 재시도 3번이 순식간에 소진되고 루프는 "실패"로 종료됩니다. 원인은 코드가 아니라 남의 서버인데, 내 루프만 죽은 거죠.
반대 경우도 있어요. 프롬프트 설계가 잘못돼서 모델이 매번 같은 형식 오류를 내놓습니다. 이건 10번을 돌려도 결과가 같아요. 그런데 상한이 10이면 토큰 10번어치를 태우고 나서야 멈춥니다.
두 경우 모두 카운터는 제 할 일을 했어요. 문제는 카운터가 왜 실패했는지 모른다는 겁니다.
횟수 기반 중단과 원인 기반 라우팅이 같은 실패에서 어떻게 갈리는지
실패를 먼저 분류한다
그래서 순서를 바꿨어요. 재시도 카운터를 올리기 전에 실패를 분류하는 단계를 넣습니다.
분류는 네 갈래면 충분했어요.
- 인증 실패 — 토큰 만료·권한 부족. 재시도해도 같은 결과라 즉시 중단하고 사람에게 알립니다.
- 도구 오류 — 잘못된 파라미터, 형식 불일치. 입력을 고쳐서 재시도할 여지가 있어요.
- 의존성 다운 — 외부 API 점검, 네트워크 타임아웃. 뒤로 미루되 재시도 횟수는 차감하지 않습니다.
- 불명(unknown) — 어디에도 안 맞는 실패. 조용히 넘기지 말고 unknown 레인에 격리하고 로그를 남겨요.
여기서 제일 중요한 게 마지막 항목이에요. 분류기를 만들다 보면 "나머지는 일반 오류로 처리" 같은 else 가지를 만들고 싶어지는데, 그 순간 오분류가 조용히 통과합니다. 테스트해 보면 이 else 가지에 예상 못 한 실패가 제일 많이 쌓여요.
우선순위가 필요한 이유
실패 하나에 여러 신호가 섞이는 경우가 생각보다 잦아요. 401 응답인데 동시에 타임아웃이 찍히기도 하거든요. 저는 인증 > 도구 > 의존성 순으로 우선순위를 고정했어요. 인증 문제를 의존성으로 오판하면 루프가 계속 대기하면서 영영 끝나지 않으니까요.
- 분류 먼저
- unknown 레인 필수
- 의존성은 횟수 미차감
- 인증 최우선
카운터는 백스톱으로만
그럼 상한은 버리냐 하면, 아니에요. 자리만 바꿉니다.
분류에 성공하면 원인별 경로를 타고, 분류 자체가 실패했을 때만 카운터가 작동해요. 같은 unknown 실패가 3회 연속이면 중단. 그리고 별개 축으로 하나 더 두는데, 완전히 동일한 결과가 3회 연속 나오면 원인 분류와 무관하게 멈춥니다. 이건 수렴 실패 신호라서요. 모델이 같은 답을 반복한다는 건 입력이나 스펙 쪽에 문제가 있다는 뜻이에요.
워크플로우에 붙일 때
n8n 같은 비주얼 자동화에서도 똑같이 적용돼요. 노드 하나가 실패했을 때 바로 에러 워크플로우로 던지지 말고, 그 앞에 응답 코드를 읽는 분류 노드를 두는 식이죠. 40x는 인증·요청 문제, 50x와 타임아웃은 의존성, 나머지는 unknown으로 보냅니다. 노드 3~4개 추가하는 정도의 작업인데, 새벽에 울리는 알림이 확 줄어요.
한 가지 주의할 게 있어요. status=success가 곧 실제 성공은 아니라는 점이에요. 워크플로우가 정상 종료됐는데 실제 결과물이 안 만들어진 경우, 분류기는 그걸 실패로 인식조차 못 합니다. 그래서 완료 조건에 실제 결과를 직접 확인하는 검사 하나는 꼭 넣어야 해요.
정리하면
재시도 설계에서 제가 바꾼 건 결국 순서 하나예요. 세던 것을 먼저 분류하기. 카운터는 분류가 실패했을 때를 위한 백스톱으로 내려보냈고요.
적용해 봤더니 루프가 무의미하게 돌면서 토큰을 태우는 일이 줄었고, 무엇보다 왜 멈췄는지가 로그에서 바로 보입니다. "3회 실패로 중단"보다 "인증 만료로 즉시 중단"이 훨씬 고칠 만한 정보잖아요.
이런 자동화 루프 설계는 제가 플랜티(plan-t)를 만들면서 계속 다듬고 있는 부분이기도 해요. AI가 사용자 데이터를 다루는 흐름이라 실패 하나하나를 조용히 넘기면 안 되거든요. 만들면서 배운 것들은 계속 정리해서 올려 둘게요.
관련 글
댓글
아직 댓글이 없어요. 첫 댓글을 남겨주세요.