도착하지 않는 추적 번호: WMS–운송사 라벨 연동의 3가지 단절 지점

결론부터 말하겠다. 추적 번호가 WMS와 운송사 라벨 시스템 사이에서 사라질 때(전형적인 WMS 추적 번호 동기화 장애), 90%의 경우 라벨 시스템의 잘못이 아니다. WMS가 번호를 떨어뜨리고 있다. 나는 이 함정을 30회가 넘는 WMS 구축에서 세 번 목격했다. 2024년 성수기, 로스앤젤레스의 한 3PL 창고는 하루 약 3,000건의 주문을 출고하면서 추적 번호 손실률이 2%에 달했다. 고객 서비스는 마비 직전이었다. 라벨 시스템은 완전히 정상이었다. 세 군데의 누수는 모두 WMS 쪽에 있었고, 매번 같은 세 단절 지점이었다. 라벨은 인쇄됐는데 번호가 돌아오지 않는다. 번호는 돌아왔는데 잘못된 주문에 붙는다. 번호는 WMS 안에서는 정확한데 하류 시스템에 전달되지 않는다. 이 글에서는 각 단절 지점을 찾고 고치는 방법을 설명하고, 마지막에 그대로 복사해 쓸 수 있는 구축 당일 밤 체크리스트를 싣는다.

단절 지점 1: 라벨은 인쇄되는데 추적 번호가 돌아오지 않는다

손실이 간헐적이라면, 먼저 라벨 콜백과 WMS 기록 쓰기가 비동기인지 살펴봐라. 열 번 중 아홉 번, 거기에 답이 있다.

그 3PL 창고에서는 손실이 매일 오후 2시에서 4시 사이에 집중됐다. 한산한 시간대에는 사라졌다가 러시 시간대에 돌아왔다. 로그가 이야기를 말해줬다. 라벨 시스템은 먼저 라벨 PDF를 반환하고, 추적 번호는 별도의 비동기 콜백을 통해 나중에, 타임아웃 5초로 도착했다. 피크 시간대에 라벨 시스템이 느려지면 콜백이 늦게 도착하고, WMS는 이미 "라벨 생성됨"이라고 기록해둔 뒤였다. 라벨은 잘 인쇄되고, 소포는 잘 출고됐으며, 그 주문들은 "출고 대기" 상태로 WMS에 영원히 남았고 고객 서비스는 줄 추적 번호가 없었다.

수정 방법은 세 단계이며, 하나도 생략할 수 없다. 첫째, 라벨 생성과 번호 쓰기를 별도로 확인하라. 라벨 PDF의 도착은 "라벨 생성됨"을 의미하지만, "번호 수신됨"을 의미하는 건 추적 번호가 들어간 출고 테이블 행뿐이다. 이 둘은 별도의 상태 필드에 저장하고, 절대 하나로 합치지 마라. 둘째, 재시도를 붙여 콜백을 멱등하게 만들어라. 라벨 쪽은 네트워크가 끊기면 콜백을 다시 쏘기 때문에, WMS는 중복을 알아봐야 한다. 콜백이 아예 오지 않을 때는, WMS는 기다리지 말고 스스로 번호를 가져오러 가야 한다. 셋째, 안전망 폴링 작업을 추가하라. 15분마다 라벨은 있는데 추적 번호가 없는 주문을 전부 훑고, 각 건을 라벨 시스템에 조회한다. 이 폴링 작업은 생명줄이다. 자세한 건 아래에서 설명한다.

단절 지점 2: 번호는 돌아왔는데 잘못된 주문에 붙는다

이 단절 지점은 복수 소포 주문을 전문으로 한다. 라벨 시스템은 소포 단위로 추적 번호 배열을 반환한다. 한 주문이 두 소포로 나뉘면 추적 번호는 두 개다. 그런데 많은 WMS 출고 테이블은 주문 단위, 주문당 한 행이고, 개발자가 지름길을 택했다. 배열의 첫 번째 번호를 잡아 주문 헤더에 쑤셔 넣고 나머지는 버렸다.

2025년 3월, 한 생활용품 이커머스 창고가 정확히 이 구덩이에 빠졌다. 고객은 첫 번째 소포를 받았다. 두 번째 소포의 추적 번호는 WMS 어디에도 존재하지 않았다. 고객 서비스는 운송사 사이트에서 첫 번째 소포 번호를 조회해 "배송 완료"를 봤고, 고객은 주문의 절반이 사라졌다고 주장했다. 일주일간 실랑이 끝에 두 번째 소포가 아직 운송 중이라는 게 밝혀졌다. 그 추적 번호를 아는 사람이 아무도 없었다. 수정은 단순하다. 출고 테이블은 소포 단위여야 한다. 3개 상품 2개 소포의 한 주문은 출고 레코드 두 개가 되고, 각 추적 번호는 소포와 1대1로 연결된다. 구축 당일 밤 체크리스트에도 이 항목이 있다. 3개 상품 2개 소포의 테스트 주문을 처음부터 끝까지 실행하고, 두 추적 번호가 모두 WMS에서 조회 가능해야 한다.

포장 스테이션에도 연계 절차가 있다. 라벨을 소포에 붙인 뒤 작업자가 핸드헬드 스캐너로 라벨 바코드를 스캔하면, WMS가 그 자리에서 스캔 번호와 시스템에 저장된 번호가 일치하는지 검증한다. 소포 하나당 3초. 라벨 오부착이라는 소박하지만 치명적인 실수를 잡아낸다. 시간을 아끼겠다고 건너뛰지 마라. 한 번의 뒤바뀜은 1년 치 스캔보다 많은 고객 서비스 시간을 먹는다.

단절 지점 3: WMS는 번호를 갖고 있는데 하류에 전달되지 않는다

WMS에는 추적 번호가 전부 있는 것처럼 보이는데, OMS와 판매 채널은 여전히 공백이다. 이 함정도 세 번 봤는데, 근본 원인은 매번 똑같다. 푸시 API가 HTTP 200을 반환했고, 개발자가 그걸 성공으로 받아들였다.

200은 "요청을 받았다"는 뜻일 뿐, "성공적으로 처리했다"는 뜻이 아니다. 한 창고에서는 WMS가 OMS에 푸시하고 OMS가 200을 반환하자 WMS는 주문을 "푸시됨"으로 표시했다. 그런데 OMS의 DB 쓰기는 실패해 있었다. 에러는 응답 본문 안에 있었고, WMS는 그걸 파싱하지 않았다. 손실률은 낮았고, 월 수십 건, 전부 이런 종류의 "가짜 성공"이었다. 찾는 법. 매 푸시의 응답 본문 전체를 로그에 저장하고, 주 1회 에러 키워드가 들어간 본문을 훑는다. 고치는 법. 성공은 상대방의 업무 상태로 판단해야 한다. 상대방의 조회 API를 호출해 2차 확인을 하거나, 수신 확인을 요구하라. 2차 확인이 불가능하면, 최소한 본문을 파싱하고 에러 키워드에 알림을 띄워라.

역설적인 이야기: 실시간 동기화 숭배를 멈춰라

많은 팀은 실시간 API 쓰기가 가장 신뢰할 수 있는 선택이라고 믿는다. 체인이 실시간일수록 좋다, 고. 30회가 넘는 구축을 거친 내 판단은 반대다. 실시간 체인은 링크가 많을수록 장애 면적이 커지고, WMS 추적 번호 동기화 장애는 거의 예외 없이 "실시간은 곧 철벽"이라는 믿음에서 자란다.

트레이드오프는 명확하다. 순수 실시간. 지연은 낮다. 하지만 라벨 쪽, 네트워크, WMS 중 어디 하나라도 삐끗하면 번호가 떨어지고, 전적으로 재시도 로직에 의존하게 되는데, 그건 바로 구축 전에 가장 먼저 잘려나갈 가능성이 큰 것이다. 실시간 + 정시 정합. 하루 두 번 전체 정합 작업을 돌려 WMS의 라벨 발행 주문 전건을 라벨 시스템의 추적 번호 기록과 대조하고, 빠진 걸 메운다. 정합은 몇 시간 늦지만 손실률은 거의 0에 수렴한다. 내 권장안은 둘 다다. 실시간 쓰기는 유지하고, 정합 작업은 의무로 해라. 만드는 데 개발자 2인일 정도. 밤에 편히 자게 해주는 유일한 방법이다.

계산해보면 더 명확해진다. 하루 3,000건 주문에 손실률 2%라면, 하루 약 60건이 수작업 개입을 필요로 한다. 건마다 주문 조회, 고객 연락, 추적 번호 재발급으로 약 5분이 걸린다. 월 약 150시간, 풀타임 고객 서비스 담당자의 약 3분의 1이다. 반대쪽은. 정합 작업 하나, 개발자 2인일, 매일 자동 실행, 손실률을 0.1% 미만으로 끌어내린다. 산수는 스스로 말한다.

구축 당일 밤 체크리스트

이 함정도 세 번 봤는데, 매번 팀은 구축 전에 "라벨이 인쇄되니 다 끝났다"고 생각했고, 구축 후 추적 번호 쓰기가 정반대를 가르쳐줬다. 한 줄만 기억해라. 인쇄된 라벨은 연동의 절반에 불과하다. 연동이 끝나는 건 추적 번호가 무사히 WMS로 돌아오고, 이어서 무사히 모든 하류 시스템에 도달했을 때다.

Lin Xiao, WMS 구축 컨설턴트 지음

영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.