실패하면 다시 실행해도 될까?
결론부터 말하면, 재시도는 "같은 행동을 반복"하는 게 아니라 "실패 원인을 먼저 판정"하는 절차다. 2026년 기준 공개 벤치마크들은 재시도 빈도와 성공률이 비례하지 않는다는 결과를 일관되게 보여준다. 이 글은 그 수치를 근거로 재시도 설계의 기준선을 정리한 실험 기록이다.
이 글의 핵심
- 재시도는
실패 분류 → 재시도 가능성 판정 → 경로 선택 → 검증순서로 설계해야 실측 결과와 맞는다 출처 - timeout과 429(rate limit)는 다른 장애이며, 둘을 같은 로직으로 처리하면 성능 저하가 더 커진다
- 같은 도구를 반복 호출하는 행동은 흔하지만(44~76%), 성공률과 강하게 연결되지 않는다 출처
- 결제·발송·삭제처럼 되돌리기 어려운 작업은 재시도 전에 사람 게이트를 둬야 한다
- 평가는 최종 성공률 하나가 아니라 분류율·중복 실행률·사람 전환 적중률을 나눠서 봐야 한다
이 글에서 검증하려는 것은 하나다. "실패했을 때 무엇을 다시 실행하고, 무엇을 멈추고, 무엇을 사람에게 넘길 것인가"를 코드로 고정할 수 있는가. 답은 부분적으로 가능하다는 쪽이고, 그 경계가 이 글의 본론이다.
실패 원인을 먼저 나누지 않으면 무엇이 문제일까?
문제는 재시도 로직이 오류 메시지만 보고 "실패했으니 다시"로 단순화될 때 생긴다. ReliabilityBench(2025)는 Gemini 2.0 Flash와 GPT-4o에 ReAct·Reflexion 구조를 적용해 일정·여행·고객지원·이커머스 작업에서 반복 실행과 장애를 함께 측정했다. 일시적 타임아웃의 통과율은 98.75%로 높았지만, rate limiting 장애는 혼합 장애 기준보다 2.5%p 더 큰 성능 저하를 일으켰다 출처. 즉 timeout과 429는 겉으로는 둘 다 "요청 실패"지만 복구 전략이 다르다. timeout은 네트워크 지연일 가능성이 높아 짧은 간격 재시도가 통하지만, 429는 서버가 "지금은 받지 않겠다"고 명시한 신호라서 즉시 재요청하면 오히려 상태를 악화시킨다.
실무에서 쓸 수 있는 분류는 여섯 갈래다: 인증 오류 / 입력 오류 / 일시 장애 / rate limit / 부분 성공 / 검증 실패. 이 중 자동 재시도 대상은 일시 장애와 rate limit 두 가지뿐이다. 인증 오류와 입력 오류는 다시 실행해도 같은 결과가 나올 뿐이고, 부분 성공과 검증 실패는 재시도가 아니라 상태 확인이 먼저 필요하다. 이 분류 단계를 건너뛰고 "오류면 재시도"로 처리한 초기 설계에서는 인증 만료 오류에 백오프를 걸어 10분을 낭비한 사례가 있었다. 분류가 없으면 재시도 로직은 장애 유형과 무관하게 같은 패턴으로 움직이고, 그 결과 고치지 못하는 오류에 시간과 비용을 쓰게 된다.
재시도 조건과 멱등성은 어떻게 정해야 중복을 막을까?
조건은 장애 유형별로 분리하고, 한도는 횟수가 아니라 시간·비용 예산으로 걸어야 중복을 줄인다. ToolBench-X는 장애가 주입된 1,106개 작업에서 12개 모델을 평가했는데, 모델들은 오류 뒤 같은 도구를 다시 시도하는 행동을 44~76%의 경우에 선택했지만 재시도 빈도가 높다고 성공률이 같이 오르지는 않았다. 최고 성능 모델의 전체 정확도도 0.513에 그쳤고, Invocation Error 정확도는 0.30 미만으로 가장 낮았다. 반면 오류 원인에 대한 힌트를 제공하면 성능 격차가 25~35%p 줄었다 출처. 이는 "다시 시도하라"는 지시보다 "오류 유형을 먼저 판정하고 가능한 복구 경로를 열거한 뒤 실행하라"는 단계가 실제로 작동한다는 뜻이다.
여기에 빠지기 쉬운 함정이 멱등성이다. 첫 호출이 서버에서는 성공했지만 응답이 유실된 경우, 재시도는 같은 작업을 또 만든다. 결제, 티켓 생성, 메시지 발송처럼 되돌리기 어려운 작업에는 멱등성 키를 먼저 붙이고 재시도를 그 위에 얹어야 한다. 다만 공개 검색 결과에서 제품별 멱등성 키 효과를 수치로 확인하지는 못했기 때문에, 이 항목은 수치가 아니라 구현 원칙으로만 제시한다. 재시도 한도는 "3번까지"보다 "총 90초, 토큰 예산 2,000 이내, 동일 오류 2회 반복 시 즉시 중단"처럼 시간·비용·반복 패턴을 함께 거는 편이 실제 운영에서 멈춰야 할 지점을 더 잘 잡아낸다.
사람에게 넘겨야 할 작업은 어떻게 가려낼까?
기준은 비용, 대외 노출, 비가역성 세 가지다. 2026년 에이전트 운영 분석은 고객 메시지 발송, 자금 이동, 시스템 원장 기록, 삭제처럼 비싸거나 외부에 노출되거나 되돌리기 어려운 작업에는 사람 게이트를 두고, 읽기 전용이거나 내부적으로 되돌릴 수 있는 작업은 자동화 대상으로 구분할 것을 제안한다 출처. 실패 재시도 설계에서 이 기준은 "재시도 가능 여부"와 겹치지 않는다는 점이 중요하다. 일시 장애라서 자동 재시도가 가능해 보여도, 그 작업이 결제처럼 비가역적이라면 재시도 자체를 사람 승인 뒤로 미뤄야 한다.
사람 승인 화면에서는 모델에게 다시 판단을 맡기기보다 고정된 정보만 보여주는 편이 안전하다. 실행하려는 작업과 대상, 실패 원인과 근거 로그, 이미 성공했을 가능성, 재시도로 생길 수 있는 중복·비용·외부 영향, 승인·거절·수정 선택지, 취소나 보상 트랜잭션 방법 — 이 여섯 가지가 빠지면 사람도 모델과 같은 실수를 반복한다. 실제로 승인 화면에 "이미 성공했을 가능성"만 추가했을 때 중복 승인 요청이 줄었다는 내부 관찰이 있었지만, 이는 표본이 작아 일반화하기는 이르다.
재시도 설계는 어떤 지표로 검증해야 하나?
단일 pass@1로는 재시도 설계를 검증할 수 없다. ReliabilityBench는 입력 변형 수준을 0에서 0.2로 높이는 것만으로 pass@1이 96.9%에서 88.1%로 8.8%p 떨어졌고, 단일 실행 점수는 실제 신뢰성을 20~40% 과대평가한다고 보고했다 출처. 이 격차는 반복 일관성(같은 입력 k회 실행 시 모두 성공하는 비율), 변형 내성(입력·순서·표현을 바꿔도 성공하는 비율), 장애 복구율(타임아웃·rate limit·도구 오류 뒤 정상 완료하는 비율)을 따로 재지 않으면 보이지 않는다.
실무 평가표는 최초 실행 성공률, 재시도 후 성공률, 올바른 실패 분류율, 불필요한 재시도율, 중복 실행률, 사람 전환 적중률, 평균 재시도 횟수, 작업당 토큰·API 비용, 외부 영향이 발생한 실패율, 검증을 통과한 최종 결과율 — 열 가지로 나눠 기록하는 편이 좋다. 장기 작업에서는 단계별 성공률을 곱해 전체 성공률을 추정해야 하는데, 각 단계 성공률이 0.85인 8단계 작업은 독립 가정 시 0.85의 8승, 약 27.2%로 떨어진다 출처. 이 추정은 단계 간 상관관계를 무시한 수치이므로, 운영 보고서에는 독립 가정을 명시해야 과대 해석을 막을 수 있다.
이 설계는 어디까지 믿을 수 있고 어디서 막힐까?
여기까지의 기준은 분류·한도·멱등성·사람 전환을 정해진 틀로 고정할 수 있다는 점에서 효과가 있었지만, 몇 가지 한계는 분명하다. 첫째, 벤치마크 수치는 특정 모델 버전(Gemini 2.0 Flash, GPT-4o)과 에이전트 구조(ReAct, Reflexion), 특정 장애 주입 조건에서 나온 결과다. 프롬프트와 도구 구현이 달라지면 같은 pass@1이 재현되지 않을 수 있어, 수치를 그대로 자사 시스템의 운영 신뢰성으로 옮겨 쓰면 안 된다. 둘째, ReliabilityBench는 단순 구조가 복잡한 구조보다 장애 상황에서 더 강했다는 결과를 냈는데, 이는 복잡한 재시도 로직을 쌓을수록 실패 지점도 늘어난다는 뜻으로 읽을 수 있다. 재시도 단계를 세분화할수록 검증해야 할 경로도 늘어난다.
셋째, 멱등성 키처럼 공개 수치가 없는 항목은 구현 원칙으로만 제시했고, 실제 효과는 각 시스템의 API 설계에 따라 달라진다. 넷째, 사람 전환 기준(비용·노출·비가역성)은 분류 기준이지 측정 가능한 임계값이 아니라서, 조직마다 "비싸다"와 "되돌리기 어렵다"의 경계를 따로 정해야 한다. 이 틀은 재시도를 설계하는 출발점이지 완성된 운영 매뉴얼은 아니다.
이번 실험에서 무엇을 바꿨나?
처음에는 "오류 코드가 5xx면 재시도, 4xx면 중단"이라는 단순 규칙으로 시작했다. 이 규칙은 429를 5xx로 착각하거나 재시도 대상에서 빠뜨리는 경우가 있었고, rate limit 상황에서 재시도 간격을 짧게 잡아 오히려 장애를 키웠다. 이후 실패 분류를 여섯 갈래로 나누고, 재시도 조건을 일시 장애·rate limit으로 좁히고, 한도를 횟수 대신 시간·비용 예산으로 바꾸고 나서야 불필요한 재시도율이 눈에 띄게 줄었다. 가장 크게 바뀐 지점은 "같은 도구를 다시 부르는 것"을 기본값에서 빼고, 동일 오류가 반복되면 대체 경로나 사람 전환으로 넘어가도록 종료 조건을 먼저 설계한 부분이다. 재시도 횟수를 늘리는 쪽이 아니라 멈추는 조건을 먼저 정하는 쪽이 이번 실험에서 더 안정적이었다.