Black Friday 2024. 한 셀러가 하나의 창고에서 세 개 매장을 운영했는데, TikTok Shop 주문이 WMS에 6시간 늦게 도착했다. 히어로 SKU는 40분 만에 품절됐고, 플랫폼에는 여전히 재고가 있는 것으로 표시됐다. 300건이 넘는 오버셀에 고객 서비스 라인은 마비됐다. 창고팀은 억울했다 — 재고는 있었다. 주문 도착이 늦었을 뿐이었다. 근본 원인은 창고에 있지 않았다. 수주 수집 설계에 있었고, 첫날부터 잘못 선택된 것이었다.
10년 전 멀티채널이란 "Shopify 스토어가 있다"는 뜻이었다. 이제는 Shopify, Amazon, TikTok Shop, Walmart를 동시에 다루며, 네 방향에서 주문이 하나의 WMS로 쏟아진다. 수집 방법은 두 가지만 있다. 폴링 — 각 플랫폼에 몇 분마다 "새 주문 있어?"라고 묻는 방식 — 아니면 웹훅 — 플랫폼이 새 주문이 발생한 순간 바로 보내주는 방식이다. 어느 쪽을 선택하느냐에 따라 주문 레이턴시가 분 단위인지 초 단위인지, 피크일에 잠을 자는지 불을 끄는지 결정된다.
차이는 속도만이 아니다
많은 사람들이 이를 빠르고 느린 것의 선택으로 본다. 순진하다. 두 방식은 네 가지 축에서 다르다:
레이턴시. 폴링 레이턴시는 폴링 간격과 같다 — 5분마다 폴링하면 평균 레이턴시는 2분 30초다. 웹훅은 몇 초 만에 전송된다. 평범한 화요일에는 2분 30초를 아무도 신경 쓰지 않는다. 히어로 SKU가 40분 만에 완판될 때는, 네 개 플랫폼에 곱해진 그 지연이 오버셀이 된다.
비용. 폴링은 API 호출 예산을 소모한다. Amazon의 SP-API는 엄격한 속도 제한을 적용한다. 할당량을 초과하면 스로틀링된다. 물량이 클수록 폴링 빈도가 올라가고, 속도 제한의 벽 아슬아슬하게 달리는 꼴이 된다. 웹훅은 할당량을 소모하지 않는다 — 플랫폼이 보내고, 당신이 받는다.
신뢰성. 폴링은 주문을 거의 잃지 않는다 — 물었으면 답을 받았으니까. 웹훅은 두 가지로 죽는다. 플랫폼이 보냈는데 당신이 받지 못했다(네트워크 일시 장애), 또는 받았는데 제대로 처리하지 못했다(서비스 재시작). 그래서 웹훅에는 재시도와 멱등성이 필요하다. 같은 주문이 세 번 전송돼도 WMS 안에는 반드시 한 건만 존재해야 한다. 피크 중에 중복 주문 생성이 이중 출하로 이어져 이를 배운 현장을 하나둘 본 게 아니다.
플랫폼 지원. 모든 플랫폼이 웹훅을 제공하는 것은 아니다. Shopify의 웹훅은 성숙하고, TikTok Shop은 주문 푸시 알림을 제공하며, Amazon은 SP-API Notifications 메커니즘에 의존한다 — 각각 의미론이 다르다. 각 플랫폼의 최신 개발자 문서를 확인하라. 작년의 연동 지식을 올해의 API에 적용하지 마라.
Amazon 건은 특별한 주의가 필요하다. SP-API의 속도 제한은 작업별로 설정되고 진짜로 강제된다 — Prime Day 급증 시 주문 상태를 공격적으로 폴링한 3PL을 아는데, 한 시간 가까이 스로틀링됐고, 그 시간 동안 주문이 쌓이는 걸 눈먼 채로 보냈다. 그들의 해결책은 자체 토큰 버킷 제한기와 지수 백오프였는데, 첫날부터 만들었어야 할 것이었다. Amazon을 폴링한다면, 할당량을 돈처럼 예산을 짜라. 각 작업에 호출 할당량을 부여하고, 소모량을 로그에 남기고, 80%에서 알림을 울려라. 피크 중 스로틀링은 자업자득이다.
내 권장: 주문량으로 선택하라
기술 논쟁은 잊어라. 자사의 물량을 보고 해당하는 단계를 선택하라:
하루 500건 미만: 폴링으로 충분. 네 개 플랫폼을 5분마다 확인하면 된다. 레이턴시는 허용 범위고, 개발은 엔지니어 한 명이 며칠이면 된다. 절약한 시간은 대사(reconciliation)에 써라.
하루 500~5,000건: 웹훅을 주력, 폴링을 백업으로. 웹훅이 실시간을 맡고, 시간당 풀 추출이 웹훅이 놓친 것을 잡는다. 내가 아는 최고의 가성비 조합이며, 내가 일해본 중규모 셀러에게 가장 흔한 구성이다.
하루 5,000건 초과: 웹훅 → 메시지 큐 + 대사. 푸시는 스파이크 흡수를 위해 큐에 쌓이고, 컨슈머가 멱등하게 중복을 제거하며, 야간 풀 대사가 플랫폼 주문과 WMS 주문을 대조한다. 피크 전에 푸시 폭풍을 부하 테스트하라 — 플랫폼은 자체 대형 이벤트 때 전송이 늦어지고 중복도 늘어난다. 테스트 없이 들어가는 건 눈먼 비행이다.
어느 단계에 있든 세 가지 규칙은 타협 불가다. 첫째, 플랫폼 주문 ID를 글로벌 고유 키로 삼고 중복은 조용히 버려라. 둘째, 웹훅 서명을 반드시 검증하라 — 시간을 아끼려 검증을 건너뛴 현장이 위조 주문으로 데이터베이스가 물바다가 된 걸 본 적이 있다. 셋째, 시간당 풀 대사 작업을 계속 돌려라. 이것은 모든 멀티채널 창고의 생명 보험이다 — 웹훅은 떨어지고, 폴링은 놓치고, 대사는 거짓말하지 않는다.
그 대사 작업은 별도의 설계 노트를 받을 만하다. 대부분의 팀이 잘못 만들기 때문이다. "최근 1시간에 생성된 주문"을 비교하지 마라 — 각 플랫폼의 열린 주문 전체 집합을 플랫폼 주문 ID로 WMS의 열린 주문과 비교하라. 작업은 정확히 세 개의 목록을 내야 한다. WMS에 없는 플랫폼 주문(수집 갭 — 가져와라), 플랫폼에 없는 WMS 주문(상위에서 취소되거나 환불 — 검토 대상으로 플래그), 상태 불일치(한쪽은 출하 완료, 한쪽은 대기 중 — 조사)다. 시간당 실행하고, 첫 번째 목록으로 누군가를 호출하고, 나머지 두 개는 로그에 남겨라. 여기서의 한 시간 엔지니어링이 Black Friday를 구한다.
도입부의 그 셀러는 어떻게 됐나? 웹훅 + 시간당 대사로 옮겼다. 다음 Black Friday: 네 개 플랫폼에서 20,000건 주문, 오버셀 제로. 수집 패턴에 본질적 우열은 없다 — 자사 물량에 맞는 것만 있을 뿐이다. 먼저 주문을 세고, 그다음 파이프를 선택하라. 절대 역순으로 하지 마라.
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
