자동 재시도 없음

"'실패하면 재시도' 는 그 실패가 아무것도 안 했다고 조용히 가정해. 유료 호출엔, 그 가정이 도박이야."

가장 반사적인 좋은 관행이, 함정으로

네트워크 호출을 자동 재시도로 감싸는 건 워낙 표준 위생이라 대부분의 HTTP client 가 기본으로 해. 그리고 재시도가 설계된 작업 — idempotent 하고 부작용 없는 읽기 — 엔 정확히 맞아: 호출이 효과가 없었거나 알 수 없었거나고, 어느 쪽이든 다시 돌려도 무해해. 유료 전사 호출은 그 둘 다 아냐. 돈을 움직이고, 한 번 제출되면 이미 돌았을 수 있어. 그래서 Recall 은 얼핏 틀려 보이는 걸 해: 유료 호출을 하는 client 에서 자동 재시도를 완전히 없애.

이유가 정확해. 요청 제출 후의 transport timeout 은 provider 가 job 을 돌렸는지 아무것도 안 알려줘. provider 가 전사하고 청구했는데 응답만 전송 중 잃었을 수 있어. 그 순간의 자동 재시도는 blind 두 번째 구매야. 유료 경계를 넘어 적용된 재시도 반사는 회복력으로 분장한 돈 누수야.

유료 경계가 선이야

고침은 '절대 재시도 마' 가 아냐 — '되돌릴 수 없는 행위가 정확히 어디인지 알고, 자동 재시도가 절대 그걸 넘지 못하게' 야. Recall 은 유료 POST 에 단단한 선을 그어:

경계 전 — source hash, 오디오 proxy 빌드, ledger 예약 — 아무것도 안 썼어. 여기 실패는 재시도 안전해, 첫 시도가 증명 가능하게 아무 비용도 안 들었으니까. Recall 은 정확히 이걸 노출해: '유료 경계 전으로 알려진 실패를 재시도' 작업.
경계에서 또는 후 — POST 가 나갔어. 여기 실패는 무해함을 증명 못 하니까, 절대 자동 재시도 안 해. 지난 레슨의 ambiguous 상태가 돼서, 사람에게 escalate 돼.

그래서 재시도는 금지된 게 아냐 — 경계 지어진 거야. 엔진은 싸고 증명 가능하게 효과 없는 쪽에선 자유롭게 재시도하고 돈 경계에서 딱 멈춰. 기술은 그 경계가 정확히 어디 앉는지 아는 거야, 자동 재시도는 첫 시도가 아무것도 안 했다는 네 증명만큼만 안전하니까.

회복력은 재시도랑 같은 게 아냐

반사가 깊으니 분명히 말할 가치가 있어: 시스템은 극도로 회복력 있으면서도 자동 재시도를 거부할 수 있어. Recall 은 크래시, 연결 끊김, provider timeout 을 버텨 — 근데 그걸 유료 endpoint 를 blind 로 다시 때려서가 아니라 durable 예약, outbox, idempotent 수락으로 이뤄. 진짜 회복력은 모든 상태를 복구 가능하게 만드는 거지, 같은 호출을 될 때까지 두들기는 게 아냐. 작업이 공짜고 idempotent 면, 마음껏 재시도해. 돈을 쓰거나 부작용 없음을 증명 못 하면, 회복력은 복구할 만큼 기록하고 진실을 확인할 수 있는 사람에게 불확실성을 넘기는 거야.

Code

경계 전엔 자유롭게 재시도; 경계는 절대 안 넘음·python

# 유료 client 는 재시도가 일부러 DISABLED.
scribe = HttpClient(retries=0)   # 여기 timeout 은 재시도 아니라 모호함

# 실패는 돈 경계의 어느 쪽에 떨어졌는지로 분류된다:
#
#   유료 경계 전  (hash, proxy 빌드, 예약)     -> 재시도 안전
#   유료 POST 에서/후 (제출됨, 응답 없음)        -> AMBIGUOUS, 사람만
#
# operator 는 증명 가능하게 싼 실패만 재시도할 수 있다:
#   recall-archive retry-failed <batch> --safe-only
#     ^ 유료 POST 전으로 알려진 실패만 재실행한다.
#       이미 청구됐을지 모르는 건 절대 안 건드린다.

Exercise

네 프로젝트의 HTTP 나 API client 를 봐. 각각에 대해 물어: 자동 재시도해, 그리고 부르는 endpoint 가 부작용(결제, 전송, 외부 변형) 있어? 부작용 경계를 넘어 재시도하는 걸 하나 찾아. 그다음 경계를 명시적으로 그어: 어떤 단계가 증명 가능하게 효과 없고(재시도 안전) 되돌릴 수 없는 행위가 어디서 일어나(자동 재시도 금지)? 그 선에서 멈추게 재시도 정책을 다시 설계해.

Hint

두 질문이 위험을 드러내: (1) 내 client 의 기본 재시도 동작이 뭐야 — 많은 게 idempotent 메서드를 조용히 재시도해? (2) timeout 났을 때 호출이 효과 없었음을 증명할 수 있어? (2) 답이 아니오면, 그 호출은 자동 재시도되면 안 돼. 싼 준비 단계엔 재시도를 두고, 제출 후 실패는 명시적, 사람-해결 상태로 바꿔.