인바운드 SMS 웹훅: 재시도·이벤트 순서·수신 멱등

아웃바운드 SMS가 대시보드를 차지합니다. 인바운드야말로 STOP·HELP·고객 답장이 실제로 착지하는 곳이며, 순진한 핸들러가 중복 티켓·이중 지갑 부작용·“STOP를 받지 못했다”는 컴플라이언스 유령을 만드는 곳입니다. 수신 경로가 엄격한 순서의 exactly-once 전달을 가정하면 첫 실제 장애에서 무너집니다.

IOSOR는 인바운드 메시징을 아웃바운드와 같은 화이트라벨 선불 표면에 담습니다. 검증 가능한 이벤트, 브랜드 안전 페이로드, 답장 폭풍을 맞추려고 외래 Ops 포털에 살 필요가 없습니다.

웹훅이 왜 재시도하는가

대부분 플랫폼에서 인바운드 웹훅은 재시도가 있는 at-least-once 전달을 약속하며, 마법 같은 exactly-once 엄격 순서가 아닙니다. 핸들러는 다음을 견뎌야 합니다.

• 동일 논리 이벤트의 중복 POST
• 타임아웃 후 늦은 도착
• 다른 이벤트 유형 대비 간헐적 순서 역전

제품 UX는 자사 스토어가 결정적 병합을 적용할 때 순서 있어 보입니다. 선로가 결코 흔들리지 않기를 바라서는 안 됩니다.

반드시 설계할 세 가지 실패 모드

멱등: 세 가지를 모두 고치는 하나의 속성

인바운드도 돈과 운영 부작용에서 자유롭지 않습니다.

• 자동 답장이 선불 지갑을 인출할 수 있음
• STOP 처리는 향후 마케팅 발송을 억제해야 함
• 티켓을 여는 지원 매크로는 POST 3번에 티켓 3장을 열면 안 됨

멱등 수신 핸들러 체크리스트:

1. 부작용 전에 인바운드 이벤트 id 영속화
2. 중복은 이전 outcome으로 단락
3. 자동 답장 발송에 자체 멱등 키
4. 상관 로그: inbound id → 지갑 줄 → reply id
5. 운영자를 위한 실패 문구를 화이트라벨 안전하게

월 플랫폼 사용 USD 1,000+ 근처에서 중복 인바운드 폭풍은 재무·컴플라이언스 대화가 됩니다. 파일럿은 저량 키워드로 먼저 원장을 증명할 수 있습니다.

이벤트 순서: 왜 “last write wins”가 위험한가

흔한 잘못된 가정:

1. STOP가 다음 마케팅 발송보다 먼저 온다(레이스가 있다)
2. 아웃바운드 DLR가 인바운드 답장보다 먼저(독립 경로)
3. 내구 이벤트 키 없이 “첫 POST 승리”

내구 event / message id로 수신 원장을 만드세요. 비즈니스 규칙은 그 원장의 상태 전이이며 “모든 HTTP 200 경로에서 부작용”이 아닙니다.

. . . .

2xx — typically under a second. . .

1. 인바운드 콜백의 문서화된 재시도 정책
2. 테스트 가능한 서명/인증 검증
3. 페이로드의 내구 이벤트 id
4. 멱등 핸들러 가이던스(“200 반환”만이 아님)
5. 중복 전달에도 살아남는 STOP / HELP 경로
6. 자동 답장 지출이 같은 선불 지갑에 보이는지

. . Near USD 1,000+ — .

위험 신호

. . Near USD 1,000+ — .

IOSOR로 시작하기

지난주 인바운드 webhook 로그를 뽑아 두 번 이상 온 이벤트 ID를 센다. 중복 하나와 순서 어긋난 쌍(failed 다음 delivered)을 재생한다. 수신기는 효과를 하나만 남긴다. 받은편지함 한 줄, STOP 한 번, 지갑 한 번. 마지막 쓰기가 STOP을 되돌리면 실패다. 수신 멱등과 재시도 순서이지, 서명 검증도 큐 전 게이트웨이 잠금도 아니다.

관련 가이드: 인바운드 자동응답 루프 · 캐리어 지연 급증에 대응하는 인바운드 웹훅 처리 버퍼링 · 첫 차감 전 선불 잔액 예약.

IOSOR 핵심 요약

인바운드 webhook은 재시도한다. 수신 멱등이 유일한 안전한 답이다. 순서는 약속이 아니다.

할 일: 이벤트에 키를 달고 쌍둥이를 무시하라. 하지 말 일: STOP에 마지막 쓰기 승리를 쓰거나 같은 이벤트를 두 번 깎지 마라.