배달은 적어도 한 번; 의도는 정확히 한 번

"네트워크가 정확히 한 번 배달하게 만들 순 없어. 두 번 도착한 같은 배달이 한 번의 뜻만 갖게 만들 순 있어."

네트워크에 관한 불편한 진실

모든 견고한 클라이언트가 결국 마주하는 사실이 있어: 불안한 네트워크 위에선 정확히 한 번 배달을 얻을 수 없어. 더 열심히 하면 되는 문제가 아냐. 고전적 함정을 봐 — 요청이 백엔드에 닿고, 백엔드가 처리하고, 그다음 응답이 돌아오는 길에 떨궈져. 폰 입장에선 요청이 '실패'했어. 근데 아냐. 확인만 잃은 거야. 클라이언트가 이제 재시도하면, 백엔드는 같은 요청을 두 번째로 봐. 배달은 적어도 한 번: 메시지가 0번, 1번, 또는 여러 번 도착할 수 있고, 클라이언트는 밖에서 그 차이를 진짜로 구분 못 해.

보장을 한 층 위로 옮겨라

배달을 못 고치니까, 의미를 고쳐. 목표는 정확히 한 번 배달(불가능)이 아냐. 정확히 한 번 의도야 — 요청이 물리적으로 몇 번 도착하든, 한 번의 효과를 갖기. 그게 멱등성이 사주는 거야: 한 번 적용한 것과 같은 결과로 반복 적용할 수 있는 연산. 재시도가 안전해지는 건, 반복 안 한다고 보장해서가 아니라, 반복이 무해해서야.

배달 층: 불안하고, 적어도 한 번, 네 통제 밖. 받아들여.
의도 층: 믿을 만하고, 정확히 한 번, dedupe 키로 온전히 네 통제 안. 지어.

이게 트랙 전체가 걸린 심상 전환이야. 선 위에서 중복을 막으려 하지 마; 중복이 상관없게 만들기 시작해.

왜 이게 대담하게 재시도할 자유를 주나

중복이 무해해지면, 재시도가 안 무서워져. 재연결에 다시 보내고, 앱 실행에 다시 보내고, 사용자 탭에 다시 보내 — 신뢰성이 요구하는 만큼 자주 — 의도 층이 그 모든 도착을 한 효과로 접으니까. 재시도를 두려워하는 클라이언트는 언더딜리버하는 경향이야(안전하려고 버림). 멱등 의도를 가진 클라이언트는 넉넉히 재시도하고도 절대 이중 행동 안 해. 다음 레슨들이 이걸 진짜로 만드는 dedupe 키를 지어: device turn ID.

Code

정확히 한 번 배달을 불가능하게 만드는 ack 떨굼 함정·text

폰                            백엔드
  |  --- ask (turn X) ------->  |
  |                            |  X 처리, 답함
  |  X    응답 -------------- |   <-- 전송 중 떨궈짐
  |  (실패로 봄)               |
  |  --- ask (turn X) 다시 --> |   <-- 같은 의도가 두 번 도착
  |                            |  X 를 알아봐야 함, 다시 하면 안 됨

// 폰은 '요청 잃음'이랑 '응답 잃음'을 구분 못 해.
// 그래서 재시도해. turn X 의 dedupe 키만이 효과를 정확히 한 번으로 지켜.

Exercise

ack 떨굼 시나리오를 단계별로 묘사해: 요청 성공, 응답 잃음, 클라이언트 재시도. 각 단계에서 폰이 뭘 믿고 백엔드가 뭘 믿는지 적어. 그다음, 왜 폰에서만의 재시도나 타임아웃 튜닝으로는 배달을 정확히 한 번으로 못 만드는지 — 그리고 대신 어떤 단일 메커니즘(힌트: 안정된 키)이 의도 층에서 고치는지 설명해.

Hint

폰이랑 백엔드가 어긋나는 건 정확히, 폰이 첫 시도가 성공한 걸 못 배웠기 때문이야. 타임아웃은 그 불일치를 못 풀어. 백엔드가 두 번째 도착에 알아볼 수 있는 공유 dedupe 키만이 풀어. 그 키가 device turn ID 야.