Exponential Backoff란? 실패할수록 재시도 간격을 늘리는 이유 쉽게 이해하기
Exponential Backoff는 요청이 계속 실패할수록 재시도 전 대기 시간을 점점 늘리는 방식입니다. Retry Storm·Jitter·Cap·멱등성·Deadline·Circuit Breaker까지 초보 기준으로 정리합니다.
통화 중인데 0.1초마다 다시 걸기
요청이 실패하면 프로그램이 자동으로 다시 시도하는 것이 Retry입니다. 서버가 이미 과부하인데 모두가 즉시 재시도하면 회복할 틈이 없고 부하만 커집니다 — 이를 Retry Storm이라고 부릅니다. Exponential Backoff(지수 백오프)는 실패가 반복될수록 재시도 전 대기 시간을 1초→2초→4초처럼 늘려 서버에 숨 쉴 틈을 줍니다. 숫자는 시스템마다 달라도 「실패할수록 더 오래 기다린다」가 핵심입니다.
대기 ≈ 기본시간 × 2^재시도횟수 예: 1초 → 2초 → 4초 → 8초 (최대 Cap)
Jitter · Cap · 무엇을 Retry할까
Backoff만 같으면 모두가 정확히 1초·2초·4초 뒤 동시에 다시 때릴 수 있습니다. Jitter로 대기 시간에 무작위 차이를 넣어 시각을 흩뿌립니다 — Livelock의 대칭 즉시 Retry도 같은 정신으로 줄입니다. 대기 시간·횟수에는 Cap과 최대 Retry를 둡니다. 잘못된 입력·권한 부족 같은 영구 오류는 Retry해도 소용없습니다. HTTP 상태 중 429·503은 `Retry-After`가 있으면 우선 존중합니다. 결제·주문 같은 쓰기는 응답이 끊겨도 서버에서는 성공했을 수 있어, 그대로 재시도하면 이중 처리 위험이 있습니다 — 멱등성(Idempotency)·HTTP 메서드 실제 동작을 함께 봅니다.
일시 오류만 Retry Backoff + Jitter + Cap + 횟수 제한 쓰기 요청 → Idempotency 먼저
Deadline · 계층 · Circuit Breaker
사용자 화면은 빠르게 실패하는 편이 낫고, 백그라운드·Queue Job은 더 긴 정책이 가능합니다 — 만료(TTL) 지난 인증 메일처럼 「늦은 성공」은 버릴 수 있습니다. Timeout(한 번)과 Deadline(전체)을 나눠 보고, 앱·Gateway·서비스가 각자 3회씩 Retry하면 요청이 폭증합니다 — Retry 책임을 한곳에. 앱이 페이지를 떠나면 Abort로 남은 Retry를 끊습니다. Circuit Breaker는 Backoff와 다릅니다 — Backoff는 「다음 시도까지 기다림」, Breaker는 「일정 시간 요청 자체를 차단」. Deadlock 충돌 후 짧은 Backoff는 도움이 될 수 있지만 구조 버그를 가리지는 않습니다. 모니터링·분산 추적에서는 Retry 횟수와 「최종 성공까지 걸린 시간」을 함께 봅니다.
오류 분류 → 횟수/Deadline → Backoff+Jitter 대기 → 재요청 실패 지속 → DLQ / Circuit Open
자주 묻는 질문
Exponential Backoff란?
실패가 반복될수록 재시도 전 대기 시간을 점점 늘리는 Retry 전략입니다.
왜 즉시 Retry가 문제인가?
장애 중인 서버에 재시도가 몰리면 Retry Storm으로 장애가 더 커질 수 있습니다.
Jitter란?
대기 시간에 무작위 차이를 넣어 모두가 같은 순간에 다시 요청하지 않게 하는 방법입니다.
모든 오류를 Retry할까?
아닙니다. 일시 오류만 대상으로 하고, 잘못된 입력·권한 부족 등은 제외합니다.
결제도 Retry해도 되나?
Idempotency 등 중복 방지 없이 그대로 반복하면 이중 결제 위험이 있습니다.
Backoff는 무한히 늘어나나?
보통 최대 대기(Cap)와 최대 Retry 횟수로 막습니다.
정리
Exponential Backoff = 실패할수록 재시도 간격을 늘려 서버에 회복 시간을 주는 방식입니다. 1→2→4→8초로 기억하면 됩니다. Backoff만으로는 시각이 동기화될 수 있어 Jitter를 함께 씁니다. Retry 가능한 오류인지·멱등한지·Deadline은 얼마인지·어느 계층이 Retry하는지까지가 한 세트입니다. 그런데 서버가 잠깐 느린 게 아니라 계속 실패한다면, 간격을 늘려도 요청을 끝없이 보내는 것이 맞을까요? 실패가 반복되면 잠시 요청 자체를 차단했다가, 시간이 지난 뒤 복구 여부를 시험하는 패턴이 Circuit Breaker(서킷 브레이커)입니다.