"우리가 연락할 테니, 먼저 물어보지 마세요."
일반적인 API 요청은 내가 먼저 질문하는 방식이에요. "Shopify야, 새 주문 들어온 거 있어?" 창구에 다가가서 묻고, 답을 받아요. 문제는 타이밍이에요. 무언가 일어나는 바로 그 순간을 알고 싶다면, 한 번 묻는 것으로는 부족해요. 다시 창구로 가서 또 물어봐야 해요. 또 물어보고. 하루 종일. "새 주문 있어요? 지금은요? 이제는요?"
이걸 폴링(polling)이라고 해요. 들리는 것만큼 피곤한 방식이에요. 뒷좌석에서 30초마다 "아직 멀었어요?"를 외치는 아이와 같죠. 대부분은 아무 일도 없어서, 그 모든 수고가 헛수고로 끝나요.
웹훅은 이 구조를 완전히 뒤집어요.
내가 계속 물어보는 대신, 번호 하나를 남겨두고 이렇게 말하는 거예요. "새 주문 들어오면 바로 연락줘." 그러고는 자리를 떠나 다른 일을 해요. 일이 생기면 앱이 나에게 알아서 연락해요. 이미 세부 내용도 들고 와요. 내가 물어볼 필요도, 창구 앞에서 기다릴 필요도 없어요.
피자를 주문하는 상황을 생각해 보세요. 완성됐다는 걸 알 수 있는 방법은 두 가지예요.
5분마다 가게에 전화해요. "됐어요?" "됐어요?" (API 방식이에요. 내가 계속 수고를 들이는 거죠.)
오븐에서 꺼내는 순간 가게가 문자를 보내요. (웹훅 방식이에요. 가게 쪽에서 먼저 연락하는 거예요.)
하나는 저녁을 망쳐요. 다른 하나는 핸드폰이 울릴 때까지 편하게 TV를 볼 수 있게 해줘요.
이것이 사실상 모든 자동화의 엔진이에요. 한번 보이기 시작하면, 매일 쓰는 도구들 뒤에서 이게 조용히 돌아가고 있다는 게 보여요. 어딘가에서 일이 생기면 웹훅이 발동하고, 누가 지켜보지 않아도 다른 곳에서 다른 일이 벌어져요.
- 새 판매가 발생하면 웹훅이 발동해서 고객을 이메일 리스트에 추가해요
- 새 폼 제출이 생기면 Slack 채널에 알림을 보내요
- 결제 실패가 발생하면 문자를 보내서, 거래가 사라지기 전에 붙잡을 기회를 줘요
마지막 예시는 직접 겪은 일이에요. 운영하던 스토어에서 구독 결제 실패는 며칠이 지나서야 알게 됐어요. 이미 고객은 떠나고 없는 상태였죠. 그래서 웹훅을 연결했어요. 결제가 실패하는 순간 바로 발동해서, 고객 이름과 어떤 결제가 튕겼는지 정보를 Slack에 바로 떨어뜨려요. 아무도 대시보드를 새로고침하지 않아도 돼요. 월요일에 보고서를 확인하지 않아도 되고요. 실패 자체가 두드림 역할을 하고, 아직 살릴 수 있을 때 대응할 기회가 생겨요.
둘의 차이를 머릿속에 깔끔하게 정리하면 이래요.
- API는 내가 먼저 연락하는 거예요. 알고 싶을 때, 내 일정에 맞춰 내가 물어요.
- 웹훅은 세상이 나에게 연락하는 거예요. 알만한 일이 생기는 순간, 그쪽 일정에 맞춰 알려줘요.
물어보는 걸 멈추고, 통보받기 시작하면 돼요.