택배사별 연동이 쌓이면 생기는 일
처음에는 택배사 한 곳과만 연동합니다. 그러다 신규 화주가 다른 택배사와 계약해 두었거나, 특정 채널이 지정 택배사를 요구하면 두 번째 연동이 붙습니다. 이렇게 연동이 늘어날 때마다 출고 현장에서는 같은 문제가 되풀이됩니다.
화주·채널별로 지정하는 택배사가 늘수록 작업자가 "이 주문은 어느 프린터, 어느 양식인가"를 직접 판단하는 일이 많아집니다. 바로 이 지점에서 출고가 멈춥니다.
공통 배송 계층 설계
어댑터와 내부 표준 모델
핵심은 WMS·OMS가 택배사를 직접 알지 못하게 하는 것입니다. 내부에는 표준 배송 요청(수하인, 중량, 부피, 서비스 유형, 화주)과 표준 응답(송장번호, 라벨 데이터, 분류 코드)을 하나만 둡니다. 택배사별 차이는 어댑터가 흡수합니다. 이렇게 하면 택배사를 새로 붙여도 어댑터 하나만 추가하면 되고, 출고 화면과 업무 로직은 바뀌지 않습니다.
송장번호: 사전 채번 vs 실시간 채번
라벨 출력
열전사 프린터는 ZPL 같은 프린터 언어로 출력하는 것이 빠르고 안정적입니다. 택배사별 양식은 코드에 박아 두지 말고 템플릿으로 분리해 버전을 관리해야 합니다. 그래야 택배사가 양식을 바꿔도 배포 없이 대응할 수 있습니다.
택배사 선택 규칙
배정은 사람이 아니라 규칙 엔진이 맡아야 합니다.
배송 추적과 예외 처리
상태 수집과 코드 통일
추적 방식은 조회 API를 주기적으로 호출하는 폴링과, 택배사가 이벤트를 보내 주는 수신 방식이 있습니다. 하루 3,000건을 6회씩 조회하면 호출이 18,000회에 이르므로, 이벤트 수신을 지원하는 택배사는 그쪽을 우선 사용합니다. 수집한 상태는 접수·집하·간선 이동·배송 출발·배송 완료·반송·예외처럼 내부 표준 코드로 통일해야 화주와 고객 화면이 하나로 정리됩니다.
예외 감지
감지된 예외는 고객 안내 알림이나 CS 티켓으로 바로 이어지게 합니다.
취소·재발행 이력
송장 취소와 재발행은 원 송장번호와 연결해 이력으로 남겨야 합니다. 그래야 한 주문에 송장이 두 개 붙어 이중으로 청구되는 문제를 정산 단계에서 걸러낼 수 있습니다.
구축 단계와 POLYGLOTSOFT 접근
한 번에 모든 택배사를 붙이기보다 주력 택배사 1곳으로 표준 모델과 어댑터 구조를 먼저 검증하고, 그다음 택배사를 하나씩 늘리는 편이 안전합니다. 연동 범위도 미리 정해 두어야 합니다. 주문 수신은 OMS가, 패킹·출력은 WMS가, 채번·추적·예외는 배송 계층이 맡도록 경계를 나누면 각 시스템의 변경이 서로에게 번지지 않습니다.
POLYGLOTSOFT는 WMS 구축 역량을 바탕으로 멀티 택배사 어댑터 설계, 라벨 템플릿 관리, 배송 추적 통합까지 기존 WMS·OMS 환경에 맞춰 단계적으로 구현합니다. 택배사를 추가할 때마다 출고가 멈춘다면 지금의 연동 구조부터 함께 점검해 보시기 바랍니다.