결론부터 말하겠습니다. ERP와 WMS를 통합할 때 마스터 데이터가 먼저입니다. 항상요. 저는 30건이 넘는 고라이브를 진행했는데, "주문 인터페이스부터 띄우고 마스터 데이터 정리는 나중에 하자"고 시도한 프로젝트는 예외 없이 고라이브 당일 밤에 폭발했습니다. 유일하게 잘된 예외도 운이 좋았던 게 아니라, 누군가가 마스터 데이터 작업을 제대로 끝낼 때까지 시작이 충분히 미뤄졌던 것뿐입니다.

도로와 교통으로 생각해 보세요. 통합은 ERP와 WMS 사이에서 구매 발주와 판매 주문을 움직이게 합니다 — 그게 도로입니다. 마스터 데이터는 도로 표지판입니다. 품목 코드, 로케이션 코드, 고객 기록. ERP 표지판에 "SKU-48213"이라고 쓰여 있는데 WMS가 "SKU48213"으로 읽으면 교통은 충돌합니다. 인터페이스가 살아 있다고 고라이브 준비가 된 건 아닙니다. 저 시나리오를 저는 세 번 그대로 목격했습니다.

마스터 데이터를 나중에 하면 반드시 터지는 이유

2024년 여름. 캘리포니아주 리버사이드에 자체 창고를 둔 뷰티 브랜드 — 50,000제곱피트, 하루 약 4,000건의 주문. 고객사의 IT 책임자가 이렇게 결정했습니다. "마스터 데이터 정리는 너무 오래 걸려. PO와 SO 인터페이스부터 띄우고 마스터 데이터는 고라이브 후에 메꾸자."

고라이브 사흘 전, ERP가 WMS로 구매 발주를 보냈습니다. 에러: 품목을 찾을 수 없음. ERP의 품목 번호는 "SKU-48213"이었는데 WMS는 "SKU48213"으로 가져와 있었습니다 — 하이픈 하나가 빠져 있던 겁니다. 어느 쪽도 물러서지 않았습니다. 인터페이스 명세에는 "품목 번호를 그대로 전달한다"고만 쓰여 있었으니까요. 쓰레기가 들어가면 쓰레기가 나옵니다.

상황은 더 악화됐습니다. ERP에는 6,000개가 넘는 유효 SKU가 있었고, 그중 400개가 넘는 좀비 품목 — 단종됐다 부활했다 다시 단종됐는데, 아직 가격 테이블에 앉아 있었습니다. 고라이브 당일 아침, 첫 번째 입고 웨이브가 도크에서 "품목 미유지" 에러의 벽에 부딪혔습니다. 트럭이 쌓여갔습니다. 오후 4시가 돼서야 운영을 시작했고, 문 앞에는 트레일러 12대가 줄지어 있었습니다. 해결책: 그날 밤 ERP의 품목 신규 생성을 동결하고 WMS를 품목 마스터로 선언한 뒤 ERP로 역방향 동기화. 고라이브는 두 주 미뤄졌고, 컨설팅 세 주치 비용이 추가로 탔습니다.

이와 대비되는 건 이듬해 오하이오의 홈굿즈 3PL입니다. 첫날, 세 가지 코드 체계 — 품목, 고객, 로케이션 — 를 고라이브 여덟 주 전에 잠갔습니다. 건물에 들어오는 신규 SKU는 먼저 마스터 데이터 심사를 통과해야 했습니다. 주문 인터페이스는 마지막 두 주에 통합했습니다. 고라이브 당일 밤 이슈는 정확히 두 건이었습니다. 하나는 필드 길이 불일치 — ERP에서는 20자, WMS에서는 30자 — 잘라내기 규칙을 넣어 삼십 분 만에 수정했습니다. 제가 진행한 고라이브 중 가장 매끄러운 것 중 하나였습니다.

나란히 놓고 보면 답은 명확합니다. 마스터 데이터가 먼저인 건 신중한 선택이 아니라, 현실과 맞닿아도 살아남는 유일한 선택입니다. 마스터 데이터는 두 시스템의 공통 언어입니다. 언어가 통일되지 않으면 대화가 빨라질수록 오해는 더 커질 뿐입니다.

제가 ERP-WMS 통합을 진행하는 방식: 일곱 단계 순서

모든 프로젝트에서 같은 플레이북입니다. 이것만 따르면 문제없습니다.

  1. 다른 무엇보다 먼저 코드 체계를 잠그세요. 고라이브 여덟~열 주 전에 품목 코드 체계, 로케이션 코드 체계, 고객/벤더 코드 체계를 확정 — 세 자가 서명. 서명한 사람이 이후의 모든 변경에 책임집니다. 서명 후에는 동결: 특별 케이스는 변경 요청으로 처리하고, 복도에서 구두로 처리하지 마세요.

  2. 마스터 데이터 도메인마다 오너를 한 명씩 두세요. ERP와 WMS 둘 다 품목 데이터가 필요하지만, 진실의 원천은 하나만 있습니다. 제가 보통 쓰는 분담: 품목은 ERP(재무와 구매가 거기 있으니까), 로케이션은 WMS(창고가 자기 랙을 아니까요), 고객은 ERP, 벤더는 ERP. 오너가 만들고 유지합니다. 하류 시스템은 읽기만 합니다.

  3. 마스터 데이터 전건 정합을 한 번 하세요. 지름길 없습니다. ERP의 유효 품목을 WMS의 실재고와 한 줄씩 대조하세요. 사냥감은 세 가지 — 코드 불일치, 명칭/사양 불일치, 그리고 업무 실체는 없는데 문서에는 계속 등장하는 좀비 품목. 한 프로젝트에서는 정리 과정에서 좀비가 7%나 나왔습니다. 살려 두면 고라이브가 시한폭탄이 됩니다.

  4. 필드 매핑 문서에 하나씩 서명하세요. "대충 돌아간다"는 없습니다 — 헤더, 주문 라인, 품목 코드, 수량 단위, 로트 번호, 유통기한 모두에 원천, 목적지, 변환 규칙을 씁니다. 특히 수량 단위: ERP는 케이스, WMS는 피스였던 프로젝트를 저는 네 번 경험했습니다. 변환 계수를 한 번만 틀려도 문서 배치 전체가 쓰레기가 됩니다.

  5. 마스터 데이터 인터페이스를 트랜잭션 인터페이스보다 먼저 띄우세요. 순서는 협상의 여지가 없습니다. 품목 마스터 동기화 가동·정합 완료 → 로케이션/고객/벤더 가동 → 업무 문서(PO, ASN, SO, 반품)는 마지막. 이 순서를 뒤집으면 오탐에 대해 테스트하는 셈입니다.

  6. 진짜 더러운 데이터로 테스트하세요. 테스트 시나리오에는 단골 용의자들을 넣으세요. 자릿수가 하나 많은 품목 코드, 뒤에 공백이 붙은 고객명, 너무 긴 로트 번호. 깨끗한 데이터로만 테스트한 통합은 테스트하지 않은 것과 같습니다.

  7. 고라이브 전날 밤 체크리스트(이건 매 프로젝트마다 씁니다):

    • 세 가지 코드 체계가 동결됐고, 미처리 변경 요청이 제로인가?
    • ERP→WMS 품목 전건 정합이 완료됐고 불일치가 제로인가?
    • 로케이션 마스터가 WMS와 동기화됐고 빈 로케이션이 검증됐는가?
    • 좀비 품목이 비활성화됐고 새 문서가 더 이상 참조할 수 없는가?
    • 수량 변환 계수가 품목별로 검토됐는가?
    • 업무 하루 전체 리플레이(PO → 입고 → 적치 → 웨이브 → 출하 → 콜백)가 처음부터 끝까지 그린인가?
    • 고라이브 당일 인터페이스 대규모 장애 시 롤백 계획은?

마스터 데이터 동기화 빈도도 정해 둘 만한 가치가 있습니다. 품목, 고객, 벤더는 거의 실시간으로 움직여야 합니다. ERP에서 만든 품목은 하룻밤이 아니라 몇 분 안에 WMS에 도착해야 합니다. 로케이션 마스터는 WMS 안에 있고 즉시 반영됩니다. 한 프로젝트는 품목 동기화를 자정에 돌렸습니다. 오전 10 AM에 창고가 신제품을 출하해야 했는데 그 품목이 아직 도착하지 않아 피킹 작업을 만들 수 없었습니다. 거의 실시간이 최소 기준입니다. 지연이 15분을 넘으면 인터페이스가 경고를 올려야 합니다.

창고에서의 통합 테스트 현장

트랜잭션 먼저가 허용되는 경우: 하이브리드 전략

예외는 있습니다. 조건이 이렇다면요. 그린필드 창고, 레거시 재고 제로, 품목 500개 미만, 문서 유형은 두 가지만 — 그렇다면 하이브리드로 갑니다. 마스터 데이터 규칙과 트랜잭션 인터페이스를 병행하되, 마스터 데이터 인터페이스는 여전히 먼저 가동합니다. 이건 사실 마스터 데이터 우선의 압축판입니다.

제가 본 유일하게 진짜 예외: ERP는 아무도 건드릴 수 없는 레거시 시스템이고 WMS는 새로 구축하는데, 구 ERP에는 마스터 데이터 거버넌스가 전혀 없는 경우. 이 경우 제 수는 마스터 데이터 권한 전체를 WMS에 넘기는 겁니다 — WMS가 품목, 로케이션, 고객을 만듭니다. ERP는 문서만 보내고 콜백만 받습니다. "마스터 데이터는 새 시스템을 따른다"도 대화를 시작하기 전에 언어를 통일하는 것일 뿐입니다.

폭발 주의: 고라이브 당일 밤에 터지는 함정

함정 하나: 필드 길이가 안 맞는다. ERP는 고객 약칭에 50자를 허용하고 WMS는 30자만 받는다. 고라이브 전에 아무도 확인하지 않았다. 고객명은 전송 중에 잘렸고, 같은 고객이 두 시스템에서 다른 이름이 되었다 — 정합 불가능. 해결책: 모든 필드의 길이를 매핑 테이블에 쓰고, 오버플로우 정책(잘라내기 또는 에러)을 정한다 — 둘 중 하나로.

함정 둘: 코드에 묻힌 변환 계수. 일부 통합업체는 "1 케이스 = 24 피스"를 하드코딩한다. 고객이 포장 사양을 바꾼다. 인터페이스는 에러를 내지 않는다. 데이터는 조용히 세 달간 엉망이 된다. 해결책: 계수는 품목 마스터의 필드로, 품목과 함께 움직인다 — 하드코딩은 절대 금지.

함정 셋: 죽은 품목을 참조하는 반품 문서. 품목은 ERP에서 비활성화됐는데 WMS의 반품이 여전히 그것을 참조한다. 문서가 도착하고 인터페이스는 "품목을 찾을 수 없음"을 던지고 반품 프로세스가 멈춘다. 해결책: 품목을 비활성화하기 전에 WMS에서 그것을 참조하는 미처리 문서가 있는지 확인한다 — 사전 검증 게이트.

함정 넷: 조직 차원 불일치. ERP의 조직 구조가 WMS 창고 코드와 일대일이 아니다. 인터페이스가 조직 코드를 넘기고 WMS가 잘못된 건물로 해결한다. 해결책: 조직 매핑은 별도의 테이블을 가진다. 품목 매핑에 섞지 않는다.

다음 ERP-WMS 통합 프로젝트에서는 킥오프 화이트보드의 첫 줄에 "마스터 데이터가 먼저"라고 쓰세요 — 그리고 세 자가 서명하게 하세요. 고마워할 겁니다. 이 순서로 진행한 프로젝트는 모두 고라이브 당일 밤이 조용했습니다. 역순으로 진행한 프로젝트는 모두 한밤중에 패닉 전화를 걸어왔습니다.

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

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