재시도
Retry · 리트라이
재시도는 네트워크 오류나 일시적 서버 장애로 실패한 요청을 정해진 조건과 간격에 따라 다시 실행하는 정책입니다. 무제한 반복이 아니며 백오프·지터·최대 횟수와 멱등성을 함께 설계합니다.
AI 보조 조사·작성 후 원문과 대조한 설명입니다. 사례·계산은 별도 출처 표기가 없는 한 이해를 위한 가상 예시이며 실제 고객 성과가 아닙니다.
재시도는 어떤 역할을 하나요?
AWS Builders Library는 재시도가 짧은 일시 장애를 견디게 하지만 실패 중인 서버의 부하를 키울 수 있어 백오프와 지터가 필요하다고 설명합니다. AWS 재시도 안내 타임아웃은 작업 미실행을 뜻하지 않으므로 결제·메일·주문 같은 부작용 작업은 중복 방지 키를 사용합니다. 여러 서비스가 차례로 재시도하면 각 단계의 최대 횟수가 곱해져 원래 한 건이 수십 번 실행될 수 있으므로 전체 호출 사슬에서 재시도 주체를 정하고 나머지 단계는 실패를 빠르게 전달하게 설계합니다.
무엇과 구분해야 하나요?
| 구분 | 판단 기준 |
|---|---|
| 재시도 | 같은 의도의 요청을 조건부로 다시 보냅니다. |
| 백오프 | 반복 간격을 점차 늘립니다. |
| 지터 | 동시에 몰리는 재시도 시점을 무작위로 분산합니다. |
| 멱등성 | 같은 요청을 반복해도 결과가 한 번 실행한 것과 같게 만듭니다. |
실무에서는 어떻게 계산하거나 확인하나요?
가상의 웹훅을 최대 4회 재시도하고 간격을 1초, 2초, 4초, 8초로 둔다면 최초 요청을 포함해 최대 5번 전달될 수 있습니다. 수신 서버가 세 번째 요청에서 처리했지만 응답을 잃었다면 네 번째 요청이 중복 생성할 수 있습니다. event_id를 고유 키로 저장해 이미 처리한 건은 성공 응답만 돌려줍니다.
계약·도입·데이터 연동에서는 무엇을 확인하나요?
Google Cloud Storage는 재시도 가능한 오류와 잘린 이진 지수 백오프, SDK별 기본 최대 횟수를 문서화합니다. Google Cloud 재시도 전략 이 값은 Cloud Storage 제품 기본값이므로 다른 API에 복사하지 않습니다. 연동표에는 재시도 상태코드, 최대 횟수, 전체 시간, 멱등키, 실패 보관함과 수동 재처리 책임자를 적습니다.
한계와 검수 기준은 무엇인가요?
인증 실패, 권한 부족, 잘못된 요청은 반복해도 해결되지 않는 경우가 많습니다. 429와 5xx도 공급사 Retry-After와 약관을 확인합니다. 재시도 성공률만 보고 원래 장애를 숨기지 않고 중복률·최종 실패·추가 비용·처리 지연을 함께 보고합니다.
자주 묻는 질문
- 모든 5xx 오류를 재시도해도 되나요?
- API 문서와 작업의 멱등성을 확인해야 합니다. 서버가 이미 부작용을 실행했을 가능성도 있습니다.
- 지수 백오프면 중복이 없어지나요?
- 아닙니다. 부하를 분산할 뿐이며 멱등키와 중복 처리 기록이 필요합니다.
- SDK 기본 재시도를 그대로 쓰면 되나요?
- 업무의 허용 지연·비용·부작용에 맞는지 확인해야 합니다. 공급사와 버전별 기본값도 다를 수 있습니다.
출처와 확인 범위
- Timeouts, retries and backoff with jitter · AWS Builders Library · 확인 2026-10-27
재시도·백오프·중복 실행 위험을 뒷받침합니다.
확인 범위: AWS 운영 경험이며 모든 API의 재시도 가능 상태코드와 최대 횟수를 정하지 않습니다.
- Retry strategy · Google Cloud Storage · 확인 2026-10-27
공급사 SDK의 재시도 기본값이 제품별로 다르다는 예입니다.
확인 범위: Cloud Storage 기능이며 다른 API·결제·메일 발송에 그대로 적용하면 안 됩니다.