단도직입적으로 말하자면, 제가 아는 거의 모든 셀러가 OMS–WMS 연동에서 깨집니다. 주문이 OMS를 떠나는데, 창고는 도착하지 않았다고 합니다. 창고는 출고했다고 하는데, 구매자는 아무것도 안 왔다고 합니다. 양쪽 시스템은 녹색인데, 나쁜 리뷰와 환불, 배송비는 셀러가 다 떠안습니다.
저는 5년째 크로스보더 판매를 하고 있습니다. 처음 3년은 작은 자체 창고를 운영했고, 물량이 감당 안 돼 September 2024에 로스앤젤레스의 3PL로 옮겼습니다. OMS는 그대로, WMS만 새 거 — 그리고 첫 주에 실제 돈으로 값을 치르고 배운 교훈들을 얻었습니다.
첫 번째는 SKU 매핑이었습니다.
SKU가 800+개였습니다. 고라이브 전에 목록을 익스포트해서 3PL이 WMS에 상품 마스터를 만들게 했습니다. 간단해 보이죠. 1주차: 100+건의 주문이 "pending"에 갇힘 — 전송 자체는 정상인데 WMS에서 SKU를 못 찾는 겁니다. 700개 정도는 만들어져 있었고, 나머지 100+건은 최근 2개월에 늘어난 신상품으로 제 익스포트에 빠져 있었습니다. 주문이 이틀간 방치되다가 예외 리포트에서 발견했는데, 하필 가을/겨울 SKU가 올라오는 타이밍이었습니다. 100+건의 주문이 이틀 늦게 출고됐고, CS는 일주일 내내 고성을 들어야 했습니다.
뼈아픈 교훈: SKU 매핑 테이블은 99%가 아니라 100% 정합이 필수입니다. OMS에서 전 SKU를 익스포트해 WMS 품목 코드와 vlookup — 한 행이라도 빠지면 고라이브 없습니다. 그리고 철칙 하나: SKU 매핑이 WMS에 생기기 전에는 그 상품의 리스팅을 절대 라이브로 올리지 않습니다. 매핑이 먼저, 리스팅이 나중.
OMS WMS 연동은 필드 매핑 테이블에서 시작한다
OMS에서 WMS로의 주문 전송은 본질적으로 필드 매핑 테이블이며, 연동 장애의 90%가 그 안에 살고 있습니다. OMS WMS 연동의 필드 매핑에 대한 가이드는 대부분 테이블에서 끝납니다. 테이블은 쉬운 부분이고, 셀러가 돈을 잃는 건 예외 처리입니다. 저희 현재 버전입니다. 마지막 열은 제가 직접 돈을 잃으며 뼈저리게 배운 지점을 표시했습니다:
| OMS 필드 | WMS 필드 | 깨지는 지점 |
|---|---|---|
| 마켓플레이스 주문 번호 | 외부 주문 참조 번호 | 두 시스템의 주문 번호가 다름 — 둘 다 보내고, WMS는 외부 참조 번호로 중복 제거해야 함 |
| OMS 주문 번호 | 출고 주문 번호 | 여기에 마켓플레이스 주문 번호를 쓰지 마세요 — 한 구매자가 하루에 두 번 주문하면 충돌합니다 |
| SKU | 품목 코드 | 매핑 테이블이 먼저 존재해야 함. "매핑 생성"은 모든 신상품 론칭의 필수 단계 |
| 수량 | 피킹 수량 | 단위! 케이스 판매와 개당 판매는 WMS 안에서 하나의 단위로 해결되어야 함 |
| 수령인 / 주소 / 도시 / 주 / 우편번호 / 전화 | 배송지 정보 | 주소 2행(apt, unit, suite)은 반드시 전송 — 많은 연동이 1행만 보냅니다 |
| 배송 방법 | 운송사 + 서비스 코드 | "Standard" 같은 표시 이름은 절대 보내지 말고 — 사전에 양쪽이 합의한 코드를 보내세요 |
| 구매자 메모 | 포장 메모 | 별도 필드 — 주소 행에 넣으면 주소 검증이 실패합니다 |
| 스토어 / 판매자 | 판매자 코드 | 여러 스토어가 하나의 WMS를 공유할 때 필수. 아니면 재고가 엉뚱한 오너에서 차감됩니다 |
제일 교활한 건 수량 단위입니다. 저희 버라이어티 팩은 케이스 판매 — 케이스당 12개. OMS는 "케이스"로 보냈고 WMS 마스터는 "개"로 되어 있어서, 처음 20개 주문이 20케이스가 아니라 20개를 피킹했습니다. 구매자는 1개를 받고 케이스 전체인 줄 알고 곳곳에 분쟁을 열었습니다. "단위 환산" 컬럼을 추가하고 버라이어티 팩 전체에 플래그를 세웠습니다. 그 이후로는 안 일어났습니다.
배송 방법 이름은 절대 보내지 말고 코드만 보내세요. 처음에는 "standard"와 "expedited"로 시작했는데 — 3PL이 운송사를 5곳 쓰고, 각자 자기들의 "standard"가 있어서 WMS가 어느 걸 말하는지 구분할 수 없었습니다. 이제 양쪽이 코드 테이블을 공유하고, OMS는 GROUND_HOME 같은 코드를 보냅니다. 언쟁이 90% 줄었습니다.
OMS WMS 연동에서 매주 마주치는 4가지 예외
이 매트릭스를 핀으로 고정해 둡니다 — 증상, 자동 처리, 사람이 개입하는 타이밍. 4가지 유형으로 거의 전부 커버됩니다:
| 예외 | 증상 | 자동 처리 | 사람이 개입하는 경우 |
|---|---|---|---|
| 미매핑 SKU | WMS에서 주문이 pending에 갇힘 | 홀드 + 예외 리포트에 추가 | 당일: 매핑 추가, 수동 재전송 |
| 재고 부족 | 이행할 재고가 모자름 | 주문 전체 홀드, 또는 규칙에 따라 확보분만 출고 | 4시간이 지나도 미해결 — CS가 구매자에게 연락 |
| 불량 주소 | 검증 실패 / 반송 택배 | 홀드 | 수동으로 주소 확인, 수정, 재전송 |
| 중복 전송 | 같은 외부 참조 번호가 두 번 들어옴 | WMS가 외부 참조 번호로 중복 제거 후 버림 | 조치 불필요 — 다만 버린 건수는 리포트에 표시되어야 함 |
중복 전송은 별도의 이야기가 있습니다 — Black Friday 2024. 저희 전송은 실시간 API였는데, 네트워크가 한순간 걸렸고 OMS가 타임아웃 후 재시도했습니다. 외부 주문 번호로 중복 제거를 안 했더니 WMS가 출고 주문을 두 건 만들었고, 야간조가 둘 다 출고했습니다. 한 구매자는 두 박스를 받고 하나를 반품 — 배송비 + 상품비로 그 주문에 $40 가까이 날렸습니다. 그날 밤에만 열 건이 넘는 중복. 지금도 아픕니다.
여기서 철칙 두 개가 나왔습니다. 하나: WMS는 마켓플레이스 주문 번호로 중복 제거해야 합니다 — 멱등성은 악수가 아니라 계약서에 넣습니다. 둘: 고라이브 전에 제가 직접 테스트합니다, 같은 주문을 10번 재전송해서. 출고 주문이 1건이면 패스, 2건이면 3PL이 돌아가서 고치게 합니다.
불량 주소도 한마디 더. 미국 주소 2행 — apt, unit, suite — 매핑이 1행만 보내기 때문에 계속 떨어집니다. 아파트 주문 일괄이 동·호수 없이 출고됐다가 배송 실패로 반송: 왕복 7일, 별점 1개 리뷰 직행. 이제 4개가 모두 갖춰지지 않으면 OMS가 전송을 막습니다 — 수령인, 주소 행(2행 포함), 우편번호, 전화.
직관에 반하는 결론: 필드가 적을수록, 문제가 적다
대부분은 필드가 많을수록 연동이 좋아진다고 생각하고 쿠폰 코드까지 다 보내려 합니다. 저도 그랬습니다, 뼈를 맞기 전까지는. 필드가 하나 늘어날 때마다 장애 지점이 하나씩 늘어납니다.
WMS는 실행하는 쪽입니다. 필요한 건 수령인, 내용물, 수량, 배송 방법, 포장 메모뿐입니다. 쿠폰 정보, 광고 소스 — WMS는 못 쓰고, 필드 하나가 깨지면 주문 전체가 실패할 수 있습니다. 페이로드를 30+개 필드에서 18개로 줄였더니 예외율이 절반으로 떨어졌습니다.
관련 트레이드오프: 실시간 전송 vs. 정기 배치. 실시간은 기분이 좋습니다 — 몇 초 만에 주문이 창고에 도착하니까요 — 하지만 네트워크가 한순간 걸리면 주문 유실이나 중복이 터지고, 보통 새벽 2시, 아무도 안 보는 시간에요. 배치(15분마다 파일)는 바보 같아 보이지만 리플레이도 가능하고 정합도 맞출 수 있습니다. 깨지면 파일을 다시 돌리면 됩니다. 저희 설정: 실시간 전송 + 양쪽 시스템의 주문 번호를 비교하는 정합 잡을 15분마다. OMS에는 있는데 WMS에 없는 주문은 자동 재전송. 두 마리 토끼를 원하면, 둘 다 하세요.
고라이브 체크리스트: 전날 밤 확인하는 7가지
저희 두 번째 절체는 이 리스트로 돌았습니다 — 체크 7개, 아니면 고라이브 없습니다:
- 멱등성: 같은 주문을 의도적으로 10번 재전송 — WMS는 출고 주문을 정확히 1건 만들어야 합니다.
- SKU 전체 정합: OMS에서 전 SKU를 익스포트해 WMS 품목 코드와 vlookup. 한 행이라도 빠지면 고라이브 없습니다.
- 단위 환산: 버라이어티 팩과 케이스 팩, 모든 환산을 매핑 테이블에 명시.
- 주소 완전성: 수령인, 주소 행(2행 포함), 우편번호, 전화 — 하나라도 빠지면 OMS가 전송을 막습니다.
- 운송사 코드 테이블: 양쪽이 코드 합의. 표시 이름 없이, "standard" 같은 모호한 말 없이.
- 메모는 별도 필드: 구매자 메모를 절대 주소 행에 넣지 않습니다.
- 50건 샌드박스 테스트: 실제 과거 주문을 사용하고, 더티 데이터를 의도적으로 섞습니다 — 동·호수, 사서함, 외딴 지역 우편번호, 전화 누락.
예외 리포트 읽는 법: 숫자 3개
매일 아침 8시, 예외 리포트가 도착합니다. 숫자는 3개, 그게 전부입니다:
첫째, pending 주문 수. 한 자릿수면 정상, 20을 넘으면 3PL에 전화합니다.
둘째, pending 사유 분해. 같은 원인이 3일 연속 1위면 매핑 테이블이나 규칙을 고쳐야 합니다 — 랜덤이 아니라 구조적입니다.
셋째, 24시간 이상 pending 주문 — 레드라인입니다. pending은 괜찮지만 방치는 아닙니다. 그만큼 오래 갇힌 건 지연 출고 예약 중이니까 당일에 해소합니다.
첫 2주: 예외율(pending + 오출고 ÷ 전체 주문)은 8% 안팎. 이 루틴 2개월: 0.5% 미만. Black Friday 같은 피크 주에는 ~1%까지 튀지만 전부 리포트에 보이고 전부 대응 가능합니다.
OMS–WMS 연동은 기술 문제가 아닙니다. 관심의 문제입니다. OMS WMS 연동의 필드 매핑을 정확히 하고, 예외 하나하나에 오너를 붙이고, 일일 리포트를 읽으세요 — 이 3가지를 하면 실패율이 90% 떨어집니다. 제가 직접 검증했습니다 — 8%에서 0.5%로, 저 테이블과 저 이메일로.
Ah K, 이커머스 셀러 (5년차) 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
