고객이 상품 세 개를 주문했습니다.
이 문장이 창고에 바로 “A상품 세 개를 피킹하라”는 작업으로 들어가지는 않습니다. 어느 채널에서 들어온 주문인지 확인해야 하고, 결제나 주문 상태를 관리해야 하며, 어느 지점에서 이행할지 결정해야 할 수 있습니다. 재고가 부족하면 한 번에 보낼지 나눠 보낼지 판단할 수도 있습니다.
주문과 창고 작업 사이에는 여러 결정이 있습니다.
이 구간을 맡는 대표 계층이 OMS, Order Management System입니다.
OMS의 중심 객체는 재고보다 주문입니다
WMS 화면에서 중심이 되는 것은 Inventory, Location, Work입니다. OMS에서는 Order와 Order Line이 중심에 놓입니다.
고객이 두 상품을 샀다고 하겠습니다.
- 상품 A 2개
- 상품 B 1개
OMS는 이 주문이 어느 채널에서 들어왔는지, 주문 상태가 무엇인지, 취소나 변경이 가능한지, 어느 이행 지점으로 보낼지, 각 Order Line이 어느 단계까지 처리됐는지를 관리할 수 있습니다.
공식 주문관리 자료도 OMS를 order capture, tracking, fulfillment orchestration의 관점으로 설명합니다. 주문을 받아 여러 fulfillment system으로 요청을 보내고 결과를 다시 받아 주문 상태를 진행시키는 구조가 존재합니다.
이 장에서 OMS를 “주문 데이터베이스”로 축소하지 않는 이유입니다. 주문을 저장하는 것보다 주문을 어떤 이행 흐름으로 보낼지 조율하는 책임이 중요합니다.
주문을 받은 것과 약속할 수 있는 것은 다릅니다
고객이 상품 A 10개를 주문하려고 합니다.
화면에 재고가 10개 있다고 보인다고 해서 즉시 “오늘 출고 가능”이라고 약속할 수 있는 것은 아닙니다.
10개 중 일부가 이미 다른 주문에 배정돼 있을 수 있습니다.
일부는 Hold 상태일 수 있습니다.
현재 창고에는 없지만 내일 입고 예정일 수 있습니다.
여러 창고 중 한 곳에서 공급할 수 있을 수 있습니다.
그래서 주문관리에는 Available-to-Promise 또는 Order Promising 같은 판단이 붙을 수 있습니다. 현재 수량은 계산의 한 요소입니다. 공급, 기존 수요, 날짜와 소싱 규칙까지 고려해 언제 얼마를 약속할 수 있는지 계산합니다.
여기서 ATP를 OMS와 같은 뜻으로 두지 않습니다.
OMS는 주문의 생명주기와 이행을 조율합니다.
ATP/Promising은 수요에 대해 약속 가능한 수량·날짜·공급원을 판단합니다.
두 기능이 하나의 제품에 포함될 수도 있고 ERP나 별도 서비스가 담당할 수도 있습니다.
도판 F06
Fulfillment Node를 고르는 일
온라인 주문을 처리할 수 있는 곳이 세 군데 있다고 하겠습니다.
서울 물류센터.
부산 물류센터.
재고를 보유한 오프라인 매장.
어디에서 보내든 고객에게 같은 상품이 도착할 수 있습니다. 기업이 지불하는 운송비, 고객이 받는 시간, 각 지점의 재고 균형은 달라집니다.
OMS 또는 인접한 orchestration/ATP 계층에서는 어느 이행 지점이 주문을 맡을지 판단할 수 있습니다. 이것을 Fulfillment Node 결정이라고 부를 수 있습니다.
판단에는 여러 기준이 들어갈 수 있습니다.
재고가 있는가.
고객 주소에 배송 가능한가.
약속한 날짜를 지킬 수 있는가.
분할 배송을 허용하는가.
특정 지점의 재고를 보호해야 하는가.
운송비가 지나치게 높지 않은가.
이 책은 최적화 알고리즘까지 들어가지 않습니다. 개발자와 기획자가 알아야 할 것은 주문이 들어왔다는 사실과 창고가 작업을 시작한다는 사실 사이에 이행 지점 판단이 존재할 수 있다는 점입니다.
WMS가 이 판단을 직접 가져가는 구조도 있을 수 있습니다. 책의 기준 지도에서는 고객 주문과 채널 전체를 보는 책임은 OMS 쪽, 특정 창고 안에서 실제 재고와 작업을 결정하는 책임은 WMS 쪽으로 나눠 읽습니다.
Order와 Shipment는 1대1이 아닐 수 있습니다
주문 하나가 상자 하나로 나간다고 생각하면 데이터 모델이 단순해집니다. 현실에서는 쉽게 깨집니다.
고객이 상품 A와 B를 주문했습니다.
A는 서울 센터에 있고 B는 부산 센터에 있을 수 있습니다.
같은 센터에 있어도 B가 입고 지연으로 하루 늦게 나갈 수 있습니다.
상품 크기 때문에 한 주문을 두 상자로 나눌 수도 있습니다.
반대로 여러 주문의 상품을 운송 실행 관점에서 하나의 차량이나 출하 계획에 묶을 수도 있습니다.
Order는 고객 수요의 단위입니다.
Shipment는 출하·운송 실행의 단위입니다.
둘은 서로 다른 객체입니다.
이 구분을 하지 않으면 order_status = shipped 같은 단순 상태 하나에 지나치게 많은 의미가 들어갑니다. 주문 일부만 출고됐을 때 상태를 설명하기 어렵고, 분할 배송과 부분 취소를 처리하기 어려워집니다.
OMS는 Order Line별 이행 결과를 모아 고객 주문의 상태를 계산할 수 있습니다. WMS는 자신이 받은 Shipment나 Fulfillment Request에 대해 창고 작업을 수행합니다.
주문 상태와 창고 상태를 같은 값으로 만들지 않습니다
주문 상태가 Processing이라고 하겠습니다.
이 말만으로 창고에서 무슨 일이 일어나고 있는지 알 수 없습니다.
WMS가 아직 요청을 받지 않았을 수 있습니다.
요청은 받았지만 Wave 또는 Work가 생성되지 않았을 수 있습니다.
피킹 중일 수 있습니다.
포장은 끝났지만 출고 인계를 기다릴 수 있습니다.
OMS의 상태는 고객 주문의 의미를 압축합니다. 창고 시스템의 상태는 작업 진행을 더 세밀하게 표현합니다.
반대로 WMS의 Pick Complete가 곧 주문 완료를 뜻하지 않습니다. 포장과 출고, 운송이 남아 있을 수 있습니다.
그래서 인터페이스는 상태값을 그대로 복사하기보다 어떤 이벤트를 어떤 업무 상태로 해석할지 정해야 합니다.
예를 들어 WMS에서 Ship Confirmed가 오면 OMS가 Order Line을 Shipped로 바꿀 수 있습니다. 운송사에서 POD가 오면 Delivered로 바꿀 수 있습니다. 실제 이름은 구현마다 달라집니다.
중요한 것은 상태 소유자가 누구인지와 상태 전이의 근거 이벤트가 무엇인지입니다.
취소가 어려워지는 순간
고객이 주문 직후 취소 버튼을 눌렀습니다.
아직 이행 지점이 정해지지 않았다면 OMS에서 주문을 취소하는 것으로 끝날 수 있습니다.
창고에 Fulfillment Request가 전달된 뒤라면 상황이 달라집니다.
작업이 생성됐습니까.
재고가 Allocation됐습니까.
피킹이 시작됐습니까.
이미 포장됐습니까.
창고 밖으로 나갔습니까.
취소 가능 여부는 주문 상태 하나만으로 결정하기 어렵습니다. 실제 물류 진행 단계와 연결됩니다.
OMS는 고객 관점의 취소 요청을 소유할 수 있습니다. WMS는 창고에서 중단 가능한 작업인지 판단하고 결과를 돌려줘야 할 수 있습니다.
이 장면이 두 계층의 경계를 잘 보여줍니다.
OMS는 “고객이 이 주문을 더 이상 원하지 않는다”는 업무 의도를 압니다.
WMS는 “현재 물건이 어느 작업 단계에 있고 안전하게 중단할 수 있는가”를 압니다.
한쪽 정보만으로는 전체 결정을 내리기 어렵습니다.
옴니채널에서 OMS가 중요해지는 이유
주문 채널이 하나라면 흐름이 단순합니다.
온라인몰 주문을 한 창고가 처리합니다.
채널이 늘어나면 같은 재고를 여러 곳에서 보고 싶어집니다.
자사몰.
마켓플레이스.
오프라인 매장.
B2B 주문.
매장 픽업.
당일 배송.
각 채널이 독립적으로 재고를 예약하면 초과 판매가 생길 수 있습니다. 어느 채널에 얼마를 노출할지, 어느 지점이 어느 주문을 맡을지, 취소와 부분 출고를 어떻게 반영할지 조율할 계층이 필요해집니다.
OMS의 역할이 커지는 이유는 단순히 주문 건수가 많아서가 아닙니다.
주문이 여러 채널과 여러 이행 지점을 가로지르기 때문입니다.
여기서 다시 ATP와의 경계를 기억해야 합니다. OMS가 재고 계산 전체를 직접 수행한다고 가정할 필요는 없습니다. Promising 엔진이 계산한 결과를 받아 주문에 적용할 수 있습니다. WMS가 가진 세밀한 창고 재고를 그대로 외부 채널에 노출하지 않고 약속 가능한 수량으로 변환할 수도 있습니다.
이 구조는 13장의 핵심 질문으로 연결됩니다.
WMS에 100개가 있다고 해서 OMS가 고객에게 100개를 보여줘야 합니까.
답은 재고 숫자만으로 정할 수 없습니다.
OMS와 WMS 사이의 계약
OMS가 WMS에 요청을 보낼 때 최소한 무엇이 필요할까요.
어떤 주문 또는 이행 요청인지 식별할 값.
어떤 상품을 얼마나 처리할지.
어느 서비스 수준이나 출고 기한을 적용할지.
취소나 변경을 추적할 참조 값.
배송이나 포장에 필요한 업무 조건.
반대로 WMS가 돌려줄 정보도 필요합니다.
요청을 받았는지.
작업을 시작했는지.
부족이나 예외가 생겼는지.
몇 개를 실제 출고했는지.
언제 출고가 확정됐는지.
이 목록을 API 필드 요구사항으로 곧바로 쓰지는 않습니다. 제품과 업무에 따라 달라집니다. 중요한 것은 요청과 결과가 Order 상태와 Warehouse Work 상태를 연결한다는 점입니다.
공식 주문관리 문서에서도 Order Management가 fulfillment system에 요청을 보내고 결과를 받아 orchestration을 진행하는 구조를 설명합니다. 이 책임 분리는 특정 벤더의 메뉴에 묶이지 않습니다. 주문과 실행을 나누는 일반적인 사고방식으로 사용할 수 있습니다.
주문이 창고 문 앞에 도착하면
고객 주문은 이제 이행 지점과 약속 조건을 거쳐 특정 창고의 처리 대상으로 넘어왔습니다.
여기서부터 질문이 달라집니다.
어느 재고를 사용할 것입니까.
어느 위치에서 꺼낼 것입니까.
어떤 순서로 작업할 것입니까.
누가 수행합니까.
부족하면 어떤 예외를 만들 것입니까.
OMS가 주문을 잘 관리해도 이 질문까지 답할 수 있는 것은 아닙니다.
이제 이 지도의 중심축으로 들어갑니다.
창고를 지휘하는 자리, WMS입니다.
