웹훅 vs 폴링: 실시간 화물 이벤트 파이프라인 구축하기

운송사 네트워크와의 기성 ERP 통합은 동일한 패턴을 따르는 경향이 있습니다. 운송 번호가 이행 시점에 저장되고, 그 이후부터 상태 업데이트는 운송사 웹사이트를 직접 클릭하거나, 고정된 간격으로 운송사 API를 조회하는 예약된 배치 작업을 통해 확인해야 합니다. 두 방식 모두 동일한 근본적 한계를 공유합니다 — 시스템이 화물 이벤트에 대해 사후에 알게 되고, 이벤트 발생과 인지 사이의 지연이 초 단위가 아닌 시간 단위로 측정된다는 것입니다.

이 지연의 운영 비용은 화주의 전체 포트폴리오에 걸쳐 누적됩니다. 오전 9시에 자동화된 대응을 유발할 수 있었던 예외 사항이 야간 배치 작업이 실행될 때까지 감지되지 않은 채 방치됩니다. 내부 팀이 같은 이벤트를 파악하기 전에 고객 문의가 먼저 들어옵니다. 타임스탬프 증거가 운송사 시스템에 남아 있을 때 운송사 SLA 분쟁은 제기하기 더 어려워집니다.

폴링이 잘못된 기본값인 이유

운송사 API 폴링은 요청을 보내고 응답을 받은 후, 아무 변화가 없으면 폐기하는 방식입니다 — 그리고 통합이 설정된 간격마다 이 사이클을 반복합니다. 소규모에서는 관리 가능합니다. 중간 규모 물류 운영에서는 폴링이 신호 대 잡음 비율이 극히 낮은 상당한 API 호출 볼륨을 생성합니다. 대부분의 응답은 변화 없음을 보고할 것입니다.

문제는 구조적인 것이지, 단순히 간격 조정의 문제가 아닙니다. 더 잦은 폴링은 이벤트와 감지 사이의 지연 시간을 줄이지만, API 호출 소비와 처리 오버헤드의 비용을 증가시킵니다. 덜 잦은 폴링은 저렴하지만 감지 창을 넓힙니다. 어떤 설정도 운영팀이 실제로 원하는 것을 제공하지 못합니다. 바로 무언가가 발생했을 때 즉각적인 알림입니다.

운송사 API 속도 제한은 추가적인 제약을 만듭니다. 여러 운송사에 대해 동시에 높은 빈도로 폴링하면 공격적인 폴링을 고려하지 않고 설계된 운송사별 제한에 부딪힙니다. 개발 환경에서는 단순해 보이는 아키텍처가 운영 규모에서는 운영상 취약해집니다.

이벤트 기반 대안

웹훅은 데이터 흐름을 역전시킵니다. 소비 시스템이 "무언가 변경되었나요?"라고 묻는 대신, 운송사 또는 추적 플랫폼이 이벤트가 기록되는 순간 알림을 전송합니다. 소비 시스템은 처리할 데이터가 있을 때만 데이터를 처리합니다.

화물 추적에 특화하여 말하면, 이는 배달 확인, 예외 플래그, 또는 지연 알림이 다음 예약된 배치 간격이 아니라 운송사가 기록하는 시점으로부터 몇 초 또는 몇 분 내에 ERP 또는 가시성 플랫폼에 도착한다는 것을 의미합니다. 고객 서비스팀은 고객 이후가 아닌 이전에 또는 동시에 정보를 얻게 됩니다.

리소스 관점에서 차이는 의미 있습니다. 이벤트 기반 아키텍처는 폴링 빈도가 아닌 실제 이벤트 볼륨에 비례하여 API 대역폭을 소비합니다. 조용한 날은 성수기 배송일보다 적은 알림을 생성하며, 시스템은 실제 활동에 따라 자연스럽게 확장됩니다.

신뢰할 수 있는 웹훅 파이프라인 설계

웹훅 신뢰성은 자체적인 엔지니어링 요건을 도입합니다. 운송사가 전송한 이벤트는 비동기적으로, 그리고 순서 보장 없이 도착합니다. 수신 측에서 일시적인 네트워크 오류 후 운송사의 재시도 로직이 실행되면 동일한 이벤트가 여러 번 도착할 수 있습니다. 소비 시스템은 두 가지 조건 모두를 처리해야 합니다.

멱등성이 핵심 설계 원칙입니다. 각 수신 이벤트는 고유 식별자를 가져야 하며, 수신 시스템은 해당 식별자가 이미 처리되었는지 확인한 후 조치를 취해야 합니다. 중복 이벤트는 중복 기록을 생성하지 않고 조용히 폐기되어야 합니다.

순서를 가정할 수 없습니다. "배달 완료" 이벤트가 네트워크 조건과 재시도 동작에 따라 메시지 큐에서 그 앞에 있던 "배달 중" 이벤트보다 먼저 도착할 수 있습니다. 데이터 모델은 순서 비보장 도착을 수용해야 합니다 — 이벤트를 도착 타임스탬프가 아닌 운송사 보고 타임스탬프와 함께 기록하고, 표시 레이어가 이벤트를 올바른 시간순으로 정렬할 수 있도록 해야 합니다.

예외 처리를 최우선 사용 사례로

실시간 웹훅 통합의 가장 운영적으로 가치 있는 적용은 예외 처리입니다. 배달 예외, 주소 검증 실패, 세관 보류, 기상 관련 지연은 모두 조기 알림이 의미 있는 운영적 대응 — 재발송 개시, 고객 소통, 운송사 에스컬레이션 — 을 가능하게 하는 조건입니다. 이것이 몇 시간 후에 발견되면 불가능하거나 비용이 크게 됩니다.

사전적 예외 알림은 고객 경험을 비대칭적으로 변화시킵니다. 패키지가 늦기 전에 지연을 설명하는 자동화된 메시지를 받는 고객은, 상담원이 동시에 처음으로 알게 되는 정보를 얻기 위해 고객 서비스 라인에 전화하는 고객과 근본적으로 다른 경험을 합니다.

컨트롤 타워 관점

여러 운송사와 운송 모드에 걸쳐 화물을 관리하는 운영팀에게 아키텍처 질문은 단순히 단일 운송사 통합에서 폴링을 웹훅으로 교체하는 것이 아닙니다. 이질적인 소스 — 운송사 웹훅, 추적 플랫폼 알림, 세관 상태 API — 에서 이벤트를 수신, 정규화, 라우팅하여 일관된 내부 표현으로 만드는 이벤트 수집 레이어를 구축하는 것입니다.

정규화 단계가 멀티 운송사 가시성 플랫폼이 지속적인 가치를 추가하는 곳입니다. 운송사 이벤트 스키마는 충분히 달라서, 한 운송사의 "배달 완료" 이벤트가 다른 운송사의 동일한 논리적 이벤트와 다른 필드명, 타임스탬프 형식, 상태 코드로 도착합니다. 이것들을 ERP나 고객 대면 인터페이스에 도달하기 전에 일관된 마일스톤 모델로 정규화하는 것이 이벤트 기반 아키텍처를 단순히 더 빠른 것이 아니라 실제로 유용하게 만드는 것입니다. 운송사별로 수동 해석이 필요한 실시간 데이터는 그 목적의 상당 부분을 훼손합니다.

출처: Houseblend