3PL의 숨은 비용은 화주 연동입니다
3PL 센터의 원가를 따질 때는 보통 인건비, 임대료, 설비 상각을 먼저 봅니다. 그런데 화주가 늘어날수록 눈에 덜 띄는 비용이 함께 늘어납니다. 바로 화주 연동입니다.
A 화주는 매일 오전 엑셀로 주문을 올리고, B 화주는 FTP로 CSV를 떨어뜨리고, C 화주는 자사 API를 호출해 달라고 하고, D 화주는 쇼핑몰 통합관리 솔루션에서 주문을 가져가라고 합니다. 화주마다 연동이 따로 만들어지면 WMS 안에는 화주 수만큼 개별 수신 로직이 생깁니다. 화주 하나의 필드 하나가 바뀌어도 개발자가 그 화주 전용 코드를 찾아 고쳐야 합니다.
신규 화주 온보딩이 늦어지는 진짜 원인도 여기에 있습니다. 창고 공간이나 인력은 2주 안에 준비되는데 연동 개발이 4~6주씩 걸려 첫 출고가 밀리는 일이 흔합니다. 그동안은 수작업으로 주문을 옮겨 입력하게 되고, 이것이 초기 오출고의 원인이 됩니다.
주고받아야 할 데이터 정의
화주가 아무리 많아도 실제로 오가는 데이터의 종류는 정해져 있습니다.
여기서 가장 많이 문제가 되는 것은 코드 매핑입니다. 화주의 상품코드 `SKU-1001`과 3PL 내부 품목코드는 다른 체계이며, 같은 상품이 화주 쪽에서는 낱개, 센터에서는 박스 단위로 관리되기도 합니다. 매핑 테이블은 화주 코드, 내부 코드, 단위 환산 계수, 적용 시작일을 함께 가져야 합니다. 이력 없이 덮어쓰면 과거 주문을 재처리할 때 엉뚱한 품목으로 풀립니다.
표준 인터페이스 계층 만들기
해법은 WMS 앞단에 표준 인터페이스 계층을 두는 것입니다. 구조는 세 단계입니다.
이렇게 나누면 신규 화주를 받을 때 새로 만드는 것은 어댑터 하나뿐입니다. 필드 대응표로 설정할 수 있는 수준이라면 개발 없이 설정만으로 끝납니다. 원문 보관도 중요합니다. 분쟁이 생겼을 때 "화주가 무엇을 보냈는가"를 증명할 근거가 되기 때문입니다.
연동 오류를 운영으로 관리하기
연동 오류는 없앨 수 없고, 처리 규칙을 정해 두는 것이 현실적입니다.
그리고 이 상태를 화주가 직접 보는 연동 상태 화면으로 공개해야 합니다. 화주가 "어제 주문 다 들어갔나요?"를 전화로 묻는 대신 수신 건수, 보류 건수와 사유를 직접 확인하고 수정해 다시 보낼 수 있으면 CS 문의가 눈에 띄게 줄어듭니다.
재고 정합성을 지키는 동기화 주기
재고 전송은 무조건 실시간이 정답은 아닙니다.
어느 방식이든 정기 대사는 별도로 필요합니다. 예를 들어 매일 마감 후 화주 측 재고와 센터 재고를 품목 단위로 비교하고, 차이가 난 품목은 입출고 이력을 따라가 원인을 분류합니다. 미반영 출고, 단위 환산 오류, 반품 입고 누락이 대표적인 원인입니다. 차이 원인을 쌓아 두면 어떤 연동 지점이 자주 어긋나는지가 보입니다.
POLYGLOTSOFT의 3PL 연동 구축
POLYGLOTSOFT는 기존 WMS를 교체하지 않고 그 앞단에 화주 연동 계층을 표준화하는 방식으로 3PL 연동을 구축합니다. 현재 화주별 연동 방식과 데이터 항목을 정리해 내부 표준 메시지를 설계하고, 어댑터 구조, 오류 처리 규칙, 화주용 연동 상태 화면, 재고 대사 리포트까지 단계적으로 적용합니다. 화주가 늘 때마다 연동 개발이 쌓이고 있다면 polyglotsoft.dev에서 문의해 주십시오. 현재 연동 구조를 함께 진단해 드리겠습니다.