핵심부터 말씀드리겠습니다. WES-ERP 통합에서 기술은 결코 어려운 부분이 아닙니다. 어려운 부분은 누군가 인터페이스 코드를 쓰기 전에 세 가지 흐름을 확실히 정하는 것입니다 — 주문이 어디서 들어오는지, 재고가 어디에 기록되는지, 예외를 누가 책임지는지. 제가 이끈 30+회의 운영에서, WES 통합 실패 10건 중 8건은 정의되지 않은 통합 경계로 거슬러 올라갑니다. 그리고 운영일에는 양쪽이 서로 책임을 떠넘깁니다. 이 영화를 벌써 세 번 봤습니다.
세 가지 데이터 흐름: 주문 유입, 재고 기록
WES-ERP 통합 작업이 시작되기 전에 세 개의 선을 그으십시오:
- 주문 하향 흐름: 판매 주문과 생산 지시는 ERP에서 옵니다 — 어떤 세부 수준으로, 어떤 빈도로 WES에 들어옵니까? 주문 단위입니까, 라인 단위입니까? 그리고 릴리스를 실행하는 주체는 누구입니까 — ERP의 릴리스 작업입니까, WES 내부의 수동 릴리스입니까?
- 재고 상향 흐름: WES가 피킹과 검수를 마치면, 재고 차감과 출하 확인은 어디에 기록됩니까? ERP에 직접입니까, 아니면 중간 WMS를 먼저 거칩니까? 로트, 유통기한, 시리얼 번호 항목이 애초에 ERP에 존재합니까?
- 예외 복귀 흐름: 주문이 WES에서 멈춥니다(품절, 웨이브 구성 불가, 설비 중단) — 누가 보고, 누가 처리하며, 해결된 상태는 어디에 기록됩니까?
이 세 개의 선이 그어지면, 통합 설계는 사실상 정해진 것입니다. 건너뛰면, 아무리 멋진 인터페이스도 그림의 떡입니다.
WES-ERP 통합의 세 가지 패턴: 직접, WMS 경유, 하이브리드
패턴 1: 직접(WES↔ERP). 주문은 ERP에서 WES로 직접 전달되고, WES는 출하 확인을 직접 기록합니다. 인터페이스가 가장 적고, 가장 깔끔해 보입니다. 창고 내부 프로세스가 단순하고 ERP가 이미 재고를 잘 관리하는 단일 창고 운영에 맞습니다. 2023년 중국 동부의 3C 액세서리 유통사에서 직접 패턴으로 했습니다 — 하루 20,000건, 성수기에는 40,000건까지 치솟았습니다 — 6주 만에 운영했습니다. 하지만 대가가 있었습니다. 모든 예외가 경계에 쌓였습니다. WES에서는 웨이브가 구성되지 않는데 ERP에서는 주문이 이미 "released"로 표시되어, 고객센터는 ERP 상태만 보고 출하일을 약속하는데 창고에서는 하나도 피킹하지 않았습니다. 3개월 후 예외 작업 큐를 급히 붙였습니다 — 결국 건너뛴 중간 계층을 사후에 다시 추가한 셈입니다.
패턴 2: WMS 경유(ERP→WMS→WES). WMS가 재고 진실성과 주문 오케스트레이션을 가지고, WES는 실행만 담당합니다(설비 디스패치, 웨이브 최적화, 경로 계획). 주문은 WMS에서 릴리스되고 할당되며, WES는 깨끗하고 실행 가능한 작업을 받습니다. 실적은 WES→WMS→ERP로 돌아옵니다. 창고 내부 흐름이 복잡하고, 자동화 설비가 있으며, 로트·유통기한의 엄격한 관리가 필요한 다중 창고·다중 고객 운영에 맞습니다. 2024년 미국 중서부의 식품 유통사가 콜드체인 DC에서 이 방식을 택했습니다. 세 계층 때문에 구현에 6주가 추가로 들었지만, Black Friday는 사고 제로로 지나갔습니다 — 품절과 유통기한 블록이 모두 WMS 계층에서 걸러져, WES는 실행 가능한 작업만 받았기 때문입니다.
패턴 3: 하이브리드. 주문은 WMS로 오케스트레이션하지만, 재고 스냅샷은 재무용으로 ERP에 직접 전달합니다. 또는 일반 주문은 WMS를 경유하고 긴급 끼워넣기 주문은 직접 WES로 들어갑니다. 실시간 재고 가시성을 요구하는 강력한 본사 ERP와 자동화된 창고를 가진 기업에 맞습니다. 가장 유연한 패턴 — 그리고 경계 정의가 가장 까다로운 패턴입니다. 모든 흐름에 "정상 경로"와 "예외 경로"가 명문화되어야 하며, 문서 한 줄의 누락이 운영 후 책임 공방 한 건이 됩니다.
직관에 반하는 판단 하나: 많은 팀이 "시스템은 적게, 직접 연결"이 현대적인 아키텍처라고 생각합니다. 제 경험은 정반대입니다 — 직접 연결은 복잡성을 없애는 것이 아니라, 중간 계층 하나에서 두 경계 사이의 책임 떠넘김으로 옮길 뿐입니다. WMS 중간 계층 추가는 추가 비용처럼 보이지만, 실은 보험입니다. 예외의 약 80%를 흡수해 WES와 ERP를 각각 깨끗하게 유지합니다. 계산은 다음 섹션에서.
의사결정 계산법: 네 가지 질문으로 고르는 WES-ERP 통합 패턴
| 직접 | WMS 경유 | 하이브리드 | |
|---|---|---|---|
| 인터페이스 수 | 최소(주요 흐름 2개) | 중간(주요 흐름 4개) | 최대(5+) |
| 구현 기간 | 최단 | 최장(+4–8주) | 그 중간 |
| 예외 처리 | 책임 떠넘김, 가장 취약 | WMS 작업 큐, 가장 강함 | 정의에 따라 — 경계가 모호하면 가장 취약 |
| 정합 복잡도 | 높음(양쪽, 정의 충돌) | 낮음(WMS가 단일 진실 원천) | 최고 |
| 적합 대상 | 단일 DC, 단순 흐름, 자동화 없음 | 다중 DC·다중 고객, 자동화, 로트·유통기한 엄격 관리 | 강력한 본사 ERP + 자동화 창고 |
계산해 보십시오. 직접 연결로 아낀 4–8주의 구현 비용은 성수기 사고 한 번에 다 타버립니다 — "ERP는 출하됐다고 하는데, WES는 아직 피킹 중" — 고객센터와 운영의 불 끄기로요. 제가 본 가장 비싼 사례: 유아용품 브랜드가 프로모션에서 2,000+건의 주문을 초과 판매했고, 환불과 특급 재배송으로 거의 $60,000이 타버렸습니다. 중간 계층에 쓰는 돈은 보이는 보험, 직접 연결로 잃는 돈은 어둠에 바치는 수업료입니다.
네 가지 질문이면 답이 나옵니다. 1) 디스패치할 자동화 설비가 있습니까? 예 → 직접은 탈락. 2) 로트·유통기한·시리얼의 엄격한 관리가 필요합니까? 예 → WMS 경유. 3) 본사 재무가 실시간 재고를 필요로 합니까? 예 → 하이브리드 또는 WMS 경유. 직접 연결의 정의 충돌은 재무를 미치게 합니다. 4) 운영 개시까지 얼마나 촉박합니까? 6주뿐이라면 → 직접. 단 예외 작업 큐는 지금 예산에 넣으십시오, 나중에 말고.
운영 전날 체크리스트: 이 함정을 세 번 봤습니다
패턴을 정했습니까? 운영 전에 아래 항목을 전부 확인하십시오. 하나라도 빠지면 운영하지 않습니다.
- 마스터 데이터 단일 오너: SKU 마스터, 위치 마스터, 로트·유통기한 규칙 — ERP 또는 WMS 중 정확히 하나의 오너를 정하십시오. 양쪽이 각자 SKU 코딩 규칙을 만든 현장을 봤습니다. 운영 3일째에는 같은 바코드가 두 개의 다른 상품명이 되어 있었습니다.
- 주문 상태 머신 정합: ERP의 "released"는 WES의 어느 상태에 매핑됩니까? WES의 "verified"는 ERP에 "shipped"으로 기록됩니까 "ready to ship"입니까? 상태 매핑 표를 인쇄해 벽에 붙이십시오.
- 항목 목록을 하나씩 훑기: 로트, 유통기한, 시리얼, 중량, 치수 — ERP에 있는 항목을 WES가 모두 받을 수 있습니까? 못 받는 항목은 운영 전에 대체 방안을 정하십시오(예: 인터페이스에서 유통기한을 버리고 WMS 계층에서 차단). 운영 당일이 아닙니다.
- 멱등성과 재시도: 네트워크 문제로 같은 주문이 두 번 들어오면 — WES가 웨이브를 두 개 만듭니까? 인터페이스는 멱등해야 하고(ERP 주문 번호로 중복 제거), 운영 전날 밤에는 실제로 테스트하십시오. 테스트 환경에서 전송 중간에 네트워크를 끊었다가 다시 연결하는 것입니다.
- 마이너스 재고 가드: WES가 가용 수량보다 많이 피킹하면 — 누가 막습니까? 직접 패턴에서는 양쪽 모두 상대가 막는다고 생각하는 것이 보통입니다. 아무도 막지 않습니다.
- 정합 작업: T+1 3자 대조(ERP 재고 vs WMS/WES 실적), 임계값 초과 시 자동 알림. 정합은 "운영 후에나" 할 일이 아닙니다 — 첫날부터 돕니다.
- 예외 오너와 SLA: 구성되지 않은 웨이브, 설비 중단, 품절 — 각각 누구 책임인지, 언제까지인지, 시간 초과 시 누구에게 에스컬레이션하는지. 오너 없는 예외는 항상 고객센터로 떨어집니다.
세 가지 더, 전형적인 대실패: 첫째, 팀은 해피 패스만 테스트하고 예외 경로는 테스트하지 않습니다 — WES 프로젝트 버그의 80%가 거기에 숨어 있습니다. 둘째, ERP 팀이 항목 길이를 바꾸는 패치를 적용해 새벽 2시에 인터페이스가 죽습니다 — 인터페이스 계약은 변경 관리의 대상이며, ERP 항목 변경은 2주 전에 통지합니다. 셋째, 부하 테스트는 WES 내부만, 엔드투엔드는 아닙니다 — ERP에서 10,000건의 주문을 전체 체인에 밀어넣고 어느 계층이 진짜 병목인지 알아내십시오.
내일 당장 쓸 수 있는 한 가지: 오늘 밤 프로젝트 팀에 세 가지 질문을 하십시오 — 주문이 어디서 들어오는지, 재고가 어디에 기록되는지, 예외를 누가 책임지는지. 아무도 답하지 못하면 통합 설계에 승인하지 마십시오.
Lin Xiao, WMS 구현 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
