웹훅으로 데이터 동기화하려다 세 번이나 재조정 크론을 만든 개발자의 고백

아무리 맞는 말이어도 다들 웹훅을 "해결된 문제"라 여기는 인터넷을 설득해서 바꾸긴 힘들 듯.

웹훅을 해결된 문제라 생각하는 엔지니어가 있다니 상상이 안 감. 제공자들이 고품질 웹훅 만드느라 그렇게 고생해도 패킷 누락 불만이 끊이지 않음, 운영 악몽임.

글 마지막 부분 보니 2013년 "The Log" 글 생각남. 근데 특정 기간에만 구독된 접근 윈도우(access window) 문제는 어떻게 처리하지 싶음.

그런 요구사항은 흔치 않을 듯. 진짜 필요하면 실시간 스트림 API로 구독 시점부터의 이벤트 주고, 과거 데이터는 별도 배치 리포트 API로 주는 게 나을 듯.

웹훅 진짜 골치 아픈 문제 맞음. Stripe 이벤트 API는 커서 제공해서 폴링하는 게 대형 고객들 사이에서 오래전부터 선호되는 방식임.

Stripe 이벤트 API가 제대로 하는 예시임. SCROLL은 그런 stripe식 이벤트 폴링 API를 표준 스펙으로 만들려는 시도임.

웹훅은 데이터 변경 없으면 알림도 안 오는데, SCROLL 방식은 소비자가 언제 물어볼지 직접 정해야 해서 불필요한 트래픽 늘고 지연도 커질 듯, 두 가지 문제가 있음.

스트리밍 옵션 안 쓴다면 "뭔가 바뀐 듯하니 폴링해봐" 정도의 빈 웹훅 하나 보내면 되지 않나.

API가 그냥 Kafka 감싸는 거면 롱폴링하면 됨.

이 글에서 제안하는 "피드" 솔루션이 결국 점진적 재조정(incremental reconciliation)이랑 기능적으로 똑같음. 글은 잘 썼지만 새로운 건 없음.

그게 오히려 좋은 소식임. 로그 복제가 필요한 거라면 표준이 있으면 제공자들이 그에 맞는 엔드포인트를 낼 가능성이 커지고 tombstone, 커서 비연속 같은 흔한 함정도 커버됨.

"잘 썼다"는 부분에는 동의 못 함. 이거 거의 슬롭인데 그냥 em dash만 지운 수준임.

이 주제 볼 때마다 놀라운 게, 왜 사람들이 웹훅만으로 동기화 메커니즘을 만드는지 이해가 안 감. 웹훅은 at-least-once도 at-most-once도 순서 보장도 안 됨, UDP처럼 best-effort로 취급해야 함.

LLM이 이 글 최대 50단어 정도만 써주고 문법이랑 일관성만 다듬은 거 아닐까 싶음.

재해복구 동기화에 공들이면 평소에도 그 경로를 자주 돌리게 되니까, 정작 필요할 때 고장나있는 일이 줄어듦.

요즘 이런 LLM 블로그 기술 제안 글들 보면 클로드한테 "너 진짜 대단한 거 발견한 거야"라고 가스라이팅 당한 느낌 남. 되게 이상함.

우리(Svix)도 이런 약점 때문에 FIFO 엔드포인트, 폴링 엔드포인트, Svix Stream 같은 걸 만들어서 순서 보장 상태 동기화를 지원함. Standard Webhooks라는 서명 검증 스펙도 만들었는데 OpenAI, Anthropic, Google 등이 채택함.

나도 Stripe 이슈로 몇 번 당해봄. 웹훅은 "특정 시점 이후 변경된 레코드" 조회 엔드포인트랑 같이 제공돼야 하고, 완전히 검증 가능하면서 데이터 폭탄은 아닌 재조정 프로세스가 필요함.