# API 재시도는 횟수가 아니라 부하 예산으로 설계한다

## 코드보다 먼저 드러난 문제

작은 구현 선택처럼 보였던 문제가 실제 흐름을 따라가자 여러 경계에 걸쳐 있었다. 재시도의 부하 증폭, 멱등성, 지수 백오프, 지터, 재시도 한도, 성공 및 중단 기준 가운데 하나만 고치면 다른 지점에서 부하, 중복, 조립 비용, 복구 비용이 커질 수 있었다. 이 글은 다음 질문을 다룬다. **재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다**
핵심 판단은 명확하다. **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.** 여기서는 서비스 간 동기 HTTP 호출의 클라이언트 재시도 정책, 정책을 검증하는 운영 지표와 실패 실험에 집중하며, 메시지 큐의 전달 보장 전체 설계, 특정 클라우드 SDK의 모든 기본값, 정확히 한 번 처리 보장까지 보편적인 결론으로 확대하지 않는다.

## 문제를 어렵게 만든 제약

재시도의 부하 증폭, 멱등성, 지수 백오프, 지터, 재시도 한도, 성공 및 중단 기준는 입력과 상태, 실패와 복구를 통해 서로 연결된다. 한 부분의 편의를 높이면 다른 경계로 부하나 중복, 복구 비용이 이동할 수 있어서 각 요소를 독립적으로 바꾸기 어려웠다.
근거의 역할도 서로 달랐다. 현재 구현, 결정 기록, 공식 동작, 다른 회사의 사례는 같은 단어를 사용하더라도 같은 사실을 증명하지 않는다. 프로젝트의 선택 이유는 그 이유를 직접 기록한 자료가 있을 때만 설명할 수 있다.

## 검토한 선택지와 막힌 지점

검토할 선택지는 최소 두 가지다. 첫째, 현재 방식을 유지하고 문제가 드러난 지점만 보완한다. 변경 범위는 작지만 상호작용을 놓치기 쉽다. 둘째, 관련 요소를 하나의 정책 경계로 묶는다. 초기 설계와 검증 비용은 늘지만 판단 기준과 실패 범위를 함께 관리할 수 있다.
비교 기준은 구현량이 아니라 실패 시 부하가 어디로 이동하는지, 중복 부작용을 막을 수 있는지, 검증 결과를 관측할 수 있는지, 잘못됐을 때 되돌릴 수 있는지다. 실패한 시도나 제외한 대안도 같은 기준으로 설명해야 독자가 선택을 재현할 수 있다.

## 선택의 이유와 지킨 경계

이 글이 선택한 방향은 **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.** 여러 설정을 함께 다루기로 한 이유는 각각의 값이 서로의 안전 조건을 바꾸기 때문이다. 한 항목만 최적화하면 전체 요청 경로나 모듈 경계에서 예상하지 못한 비용이 발생한다.
대안은 설정을 완전히 분리하거나 편의를 위해 관련 경계를 넓게 허용하는 방식이다. 전자는 상호작용을 운영자에게 떠넘기고, 후자는 정책이 코어 안으로 번질 위험을 키운다. 따라서 초기 설계와 테스트 비용을 수용하되, 허용 범위와 금지 범위를 자동 검사하는 가드레일을 함께 둔다.

## 선택이 코드와 흐름에 반영되는 방식

결정은 입력에서 관측까지 끊기지 않는 흐름으로 반영한다. 요청이나 변경이 들어오면 사전 조건을 확인하고, 같은 기준에서 실행 경로와 상태 변경 범위를 정한다. 실행 뒤에는 결과와 실패 신호를 기록해 성공, 중단, 복구 중 하나를 결정한다.
```text
입력과 현재 상태
  → 안전 조건 확인
  → 한정된 실행 경로 선택
  → 상태 변경 또는 호출
  → 로그·지표·테스트 결과 관측
  → 확정 / 중단 / 복구
```
이 흐름의 불변조건은 실패한 작업이 성공으로 기록되지 않고, 같은 입력을 다시 처리했을 때 허용하지 않은 부작용이 늘어나지 않는 것이다. 실제 글에서는 일반 명칭 대신 프로젝트의 모듈, 인터페이스, 테스트 이름을 사용한다.

## 결정이 지켜지는지 확인하는 방법

검증은 주장마다 관측 가능한 증거를 붙이는 방식으로 설계한다. 구조적 경계는 빌드 규칙이나 정적 분석으로, 런타임 동작은 단위·통합 테스트와 로그·지표로, 실패 복구는 의도된 오류 주입과 롤백 확인으로 검증한다.
성공 기준은 독자가 다음 목표를 반복 가능한 결과로 확인할 수 있는지다. **재시도가 장애를 증폭하지 않도록 타임아웃, 재시도 횟수, 백오프, 지터, 멱등성을 함께 설계한다** 반대로 운영 배포, 장기 부하, 특정 장애 조합을 검증하지 않았다면 그 범위는 명시적으로 남겨야 한다. 로컬 테스트 통과를 운영 검증으로 확대해 쓰지 않는다.

## 얻은 것, 잃은 것, 적용하지 않을 때

얻는 것은 판단 기준의 일관성, 실패 범위의 가시성, 자동 검증 가능성이다. 잃는 것은 초기 설계 시간과 정책을 유지하는 비용이다. 작은 실험이나 폐기 예정 코드에서는 이 구조가 과할 수 있지만, 반복 사용되거나 장애 시 비용이 큰 경로에서는 그 비용이 가드레일로 작동한다.
이 선택은 보편 법칙이 아니다. 성공 기준을 관측할 수 없거나 관련 요소의 소유권이 분리돼 있다면 더 작은 경계가 나을 수 있다. 남은 위험은 자동 검사가 잡지 못하는 런타임 우회와 문서·구현 간 시차이며, 코드 리뷰와 주기적인 근거 재검증으로 보완한다.

## 결국 지키려던 것은 무엇이었나

결국 지키려던 것은 특정 도구가 아니라 판단 가능한 경계다. **재시도는 성공 확률을 높이는 무료 기능이 아니라 실패 중인 의존성에 추가 부하를 보내는 예산이므로, 멱등성·한도·백오프·지터·관측성을 하나의 정책으로 묶어야 한다.** 자신의 환경에서는 ‘왜 이 선택이 필요한가’, ‘대안보다 어떤 비용을 덜어 주는가’, ‘그 대가를 어떤 테스트가 제한하는가’를 연속해서 답할 수 있어야 한다.

