재시도는 에이전트를 살리는 장치이지만, 무작정 늘리면 비용과 중복 실행이 커집니다. 그래서 retry는 횟수보다 정책이 중요합니다.
이 글은 어떤 실패를 다시 시도할지, 어느 시점에서 멈출지, 어떤 경우에 사람에게 넘길지 정리합니다.
개요 #
재시도 전략은 에이전트 전체 안정성을 결정합니다. tool call이 실패했을 때 바로 다시 실행하면 좋아 보이지만, 실제로는 같은 실패를 반복하거나 중복 작업을 만들어낼 수 있습니다.
관련 글로는 Agent Debugging 실무 가이드, Human in the Loop란 무엇인가, OpenAI Agent Evals 실무 가이드, Tool Selection Strategy 실무 가이드가 있습니다.
왜 중요한가 #
재시도는 가장 싸고 빠른 복구처럼 보이지만, 조건이 없으면 가장 비싼 습관이 됩니다.
- 같은 timeout을 계속 반복할 수 있습니다.
- 이미 성공한 작업을 다시 실행할 수 있습니다.
- 느린 도구에 과도한 트래픽을 넣을 수 있습니다.
- 사용자에게는 응답이 느리지만 내부에서는 비용이 누적됩니다.
그래서 retry는 무조건 다시 시도가 아니라 상황에 맞게 다시 시도여야 합니다.
재시도 정책 #
기본 정책은 다음 순서가 좋습니다.
- 실패 유형을 먼저 분류합니다.
- 일시적 실패만 retry 대상으로 둡니다.
- 지수 백오프와 jitter를 넣습니다.
- 같은 요청은 idempotent하게 만들거나 dedupe합니다.
- 한도를 넘으면 fallback 또는 사람 검토로 넘깁니다.
재시도는 특히 Tool Calling과 붙을 때 중요합니다. 도구가 내려가 있거나 느려졌을 때는 재시도보다 대체 경로가 더 낫고, 출력 검증 실패일 때는 retry보다 재질의가 더 낫습니다. 따라서 retry는 도구별, 실패별로 분리해야 합니다.
백오프와 중복 방지 #
재시도 설계에서 놓치기 쉬운 것은 중복 방지입니다. 같은 작업을 두 번 실행하면 데이터가 꼬이기 쉽습니다.
- 요청 ID를 고정합니다.
- 성공 여부를 저장합니다.
- 외부 호출은 idempotency key를 사용합니다.
- 대기 시간은 지수 백오프와 랜덤 지터를 같이 사용합니다.
- 장기 실패는 회로 차단기로 격리합니다.
이 구조는 Agent Session Management와도 잘 맞습니다. 세션마다 retry budget을 따로 두면, 한 세션의 실패가 다른 세션을 오염시키지 않습니다.
체크리스트 #
- retry 대상 실패와 즉시 중단 실패를 구분했는가
- 재시도 횟수와 총 대기 시간이 제한되는가
- idempotency key나 dedupe가 있는가
- fallback 도구 또는 사람 검토가 준비되어 있는가
- 같은 실패를 eval로 재현할 수 있는가
- 실패 후 회로 차단기가 동작하는가
결론 #
좋은 retry 전략은 응답률을 높이면서도 중복 실행과 비용 폭증을 막습니다. retry, fallback, human review를 한 묶음으로 설계해야 운영이 안정적입니다.