세 시스템의 재고 숫자가 다를 때 무엇이 오류인가

재고가 몇 개냐고 물었는데 세 시스템이 서로 다른 숫자를 보여줍니다. WMS에는 100개, 주문 화면에는 판매 가능 82개, ERP에는 100개가 잡혀 있습니다. 회의실에서는 곧바로 한마디가 나옵니다.

“그래서 어느 숫자가 맞는 겁니까.”

질문을 조금 바꿔야 합니다. 어디에 있는 수량을 묻는지, 고객에게 약속할 수 있는 수량을 묻는지, 회계상 자산을 묻는지부터 정해야 합니다. 세 숫자가 서로 다르다는 사실만으로 오류라고 판정할 수는 없습니다. 서로 다른 질문에 답하고 있을 가능성이 있기 때문입니다.

이 장에서 사용하는 기록의 기준이 되는 시스템(System of Record, 이하 SoR)은 특정 질문에 답할 때 기준으로 삼는 기록의 주체를 뜻합니다. SoR을 한 번 정해서 시스템 전체에 붙이는 방식은 물류에서 자주 막힙니다. 같은 물건도 위치, 작업, 판매 약속, 회계, 주문, 운송이라는 서로 다른 생명주기를 동시에 갖기 때문입니다.

“재고의 진실”이라는 질문은 너무 큽니다. 위치를 묻는지, 판매 약속을 묻는지, 회계 자산을 묻는지에 따라 기준 기록이 달라집니다.

같은 100개를 세는 방법이 여러 개입니다

창고에 SKU A가 100 Each 있다고 하겠습니다. WMS가 100 Each를 On-hand로 기록하고 있습니다. 이 중 10개는 품질 확인 때문에 Hold 상태입니다. 8개는 이미 주문에 배정됐고 아직 피킹되지 않았습니다.

창고 위치 기준으로 보면 100개가 존재합니다. 판매 약속 관점에서는 Hold 10개와 이미 다른 수요에 묶인 수량을 제외해 더 작은 숫자가 나올 수 있습니다. 계산 방식은 시스템과 업무 규칙에 따라 달라지므로 여기서 100-10-8=82를 보편 공식처럼 쓰지는 않겠습니다. 보여주려는 것은 같은 100개를 바라보는 질문이 다르다는 점입니다.

ERP도 재고를 기록합니다. ERP가 중요하게 보는 것은 기업 차원의 구매·판매·재고 거래와 자산입니다. 창고 안에서 A-01-01에서 A-01-02로 상품이 이동했다고 해서 매번 기업 자산의 총량과 가치가 바뀌는 것은 아닙니다. WMS에는 로케이션 이동이 중요한 사건이고 ERP에는 회계적으로 의미가 없는 내부 이동일 수 있습니다.

반대로 출고가 확정되어 기업 재고가 줄어드는 시점은 ERP에 중요합니다. 창고에서는 피킹이 이미 끝났더라도 기업 기록에서는 아직 출고 거래가 반영되지 않은 구간이 생길 수 있습니다. 공식 창고 시스템 문서에서도 창고 내부 작업과 기업 재고 반영이 서로 다른 해상도와 시점으로 관리되는 구현을 확인할 수 있습니다.

여기서 오류의 기준이 보입니다. 숫자가 다르면 무조건 오류라는 규칙은 너무 거칩니다. 같아야 하는 시점과 항목인데 다를 때 오류입니다. 따라서 인터페이스 요건에는 “재고를 동기화한다”보다 어떤 수량, 어떤 상태, 어떤 이벤트 이후, 어느 시간 안에 일치해야 하는지를 적어야 합니다.

T04 — SoR은 질문별로 정합니다

실무에서 자주 만나는 질문을 일곱 개로 나눠보겠습니다. 표의 시스템명은 절대적인 제품 배치도가 아닙니다. 어느 계층의 기록을 기준으로 삼아야 하는지 판단하는 출발점입니다.

이 표를 외우기보다 질문의 형태를 익히는 편이 낫습니다. “재고가 맞습니까”라는 말이 나오면 무엇에 대한 재고인지 되묻습니다. 물리 위치, 판매 약속, 회계 자산, 작업 진행 중 어느 것을 말하는지 좁히면 담당 계층도 함께 좁아집니다.

SoR과 원천 이벤트도 구분할 필요가 있습니다. 컨베이어 센서가 어떤 HU의 통과를 최초로 감지했더라도 고객 주문 상태의 SoR이 센서가 되는 것은 아닙니다. 센서 이벤트는 WCS와 WMS를 거쳐 작업 완료 의미로 바뀌고, 다시 OMS에 전달되어 주문 상태를 갱신할 수 있습니다. 최초 발생 지점과 업무 기준 기록은 다른 질문입니다.

복제본이 있다는 사실도 SoR을 바꾸지 않습니다. OMS가 WMS 재고를 캐시에 복제해 빠르게 조회할 수 있습니다. 조회 응답을 OMS가 반환한다고 해서 창고 위치의 기준 기록까지 OMS로 옮겨간 것은 아닙니다. 반대로 판매 가능 수량을 계산하는 로직이 OMS나 별도 ATP 계층에 있다면 고객 약속에 대한 기준 판단은 그쪽에 있을 수 있습니다.

시나리오 1, 할당됐지만 아직 피킹하지 않았습니다

고객 주문이 들어왔고 SKU A 2개가 배정됐습니다. WMS에는 피킹 작업이 만들어졌습니다. 작업자는 아직 해당 로케이션에 가지 않았습니다. 실물은 그대로 있습니다.

이 순간 “재고가 줄었습니까”라고 물으면 답이 갈립니다.

물리적으로는 줄지 않았습니다. WMS의 On-hand도 그대로일 수 있습니다. 다만 특정 수요에 Allocation 또는 Reservation된 수량이 생겼으므로 다른 주문에 사용할 수 있는 수량은 달라질 수 있습니다. ATP가 판매 약속을 계산할 때 이 배정을 고려한다면 Promiseable 수량이 선행해 줄어들 수 있습니다.

OMS에서는 주문이 이행 진행 상태로 바뀔 수 있습니다. WMS에서는 작업이 생성됐지만 완료되지 않았습니다. ERP의 기업 재고는 아직 출고 거래 전이라 그대로일 수 있습니다.

이 장면에서 Allocation과 Picking을 같은 사건으로 취급하면 여러 오류가 따라옵니다. 주문 취소 시 이미 물건을 움직인 것으로 처리하거나, 피킹 실패가 났는데 재고가 이미 출고된 것처럼 보일 수 있습니다.

개발자는 상태 이름보다 사건 순서를 확인해야 합니다.

수요가 생겼습니다.

재고가 배정됐습니다.

작업이 생성됐습니다.

실물이 피킹됐습니다.

출고가 확정됐습니다.

이 단계 사이에서 어느 시스템이 무엇을 기록하는지 정하면 “재고 감소 시점” 같은 모호한 표현이 구체적인 이벤트로 바뀝니다.

시나리오 2, 물건은 이동했는데 WMS가 아직 모릅니다

자동화 설비가 HU 하나를 A 구역에서 B 구역으로 옮기는 상황을 보겠습니다. WMS는 목적지 B를 포함한 작업을 내렸고, WCS와 제어 계층을 거쳐 물리 이동이 실행됐습니다. 장비는 이동을 끝냈습니다. 완료 이벤트가 네트워크 지연이나 처리 장애 때문에 WMS에 아직 반영되지 않았습니다.

실물은 B에 있습니다.

WMS 화면에는 A로 남아 있거나 작업 중 상태로 보일 수 있습니다.

WCS나 제어 계층의 최근 이벤트에는 B 구간 도착이 기록돼 있을 수 있습니다.

어느 시스템이 거짓말을 하고 있는 것은 아닙니다. 서로 다른 시점의 사실을 갖고 있습니다. 이 상태가 허용된 동기화 지연 범위인지, 복구가 필요한 불일치인지는 인터페이스 계약에 달려 있습니다.

장애 대응에서 WMS 데이터만 보고 “A에 있으니 다시 이동 명령을 보내자”고 결정하면 위험합니다. 실제 HU는 이미 B에 있습니다. 새 명령의 의미와 경로에 따라 중복 이동이나 잘못된 목적지 처리가 생길 수 있습니다.

이 때문에 자동화 구간에서는 위치 SoR을 한 단어로 고정하기보다 질문의 시간 해상도를 더 세밀하게 봐야 합니다. “창고의 논리적 재고 위치”는 WMS가 기준일 수 있습니다. “지금 컨베이어의 어느 센서 구간을 통과했는가”는 WCS나 제어 Telemetry가 더 가까운 기록입니다.

도판 F10

시나리오 3, 반품 한 Case가 시스템마다 다른 상태입니다

3장에서 들어왔던 FD-A100 1 Case가 창고에 도착했고, 이제 검수 전후의 기록을 나눠보겠습니다.

OMS는 고객의 반품 요청과 환불·이행 상태를 추적합니다. WMS는 물건이 실제 창고에 도착했는지, 어느 로케이션에 있고 어떤 재고 상태인지 기록합니다. 검수 전이라면 판매 가능 여부를 확정하지 않은 보류 성격의 상태로 둘 수 있습니다. ATP는 다시 고객에게 약속해도 되는 수량인지 판단할 때 이 Case를 제외할 수 있습니다. ERP는 기업 재고 거래와 환불·회계 반영을 별도의 업무 시점에 처리할 수 있습니다.

Case 하나는 물리적으로 하나입니다. 시스템에는 여러 표현이 동시에 존재합니다.

OMS에서 “반품 접수”라는 말은 창고 입고 완료를 뜻하지 않습니다.

WMS에서 “반품 입고 완료”라는 말은 재판매 가능 판정을 뜻하지 않습니다.

검수에서 정상 판정을 받았다고 해서 ATP의 판매 약속 수량이 같은 밀리초에 바뀌는 것은 아닙니다.

ERP에 재고가 반영됐다고 해서 고객 환불의 전체 생명주기까지 끝났다는 뜻도 아닙니다.

여기서 설계해야 하는 것은 하나의 거대한 상태값이 아닙니다. 각 계층의 상태를 어떤 이벤트로 연결할지입니다. Return Received, Inspection Completed, Inventory Status Changed, Refund Confirmed처럼 업무 의미가 다른 사건을 서로 구분해야 합니다. 실제 이벤트 이름은 시스템마다 다를 수 있습니다.

반품은 SoR을 설명하기 좋은 사례입니다. 순방향 출고에서는 정상 흐름에 가려졌던 차이가 역방향에서 잘 드러납니다. 물건은 창고에 돌아왔는데 판매 가능 재고에는 아직 들어오지 않는 구간이 있기 때문입니다.

시나리오 4, 창고는 끝났고 운송은 시작되지 않았습니다

출고 작업이 모두 끝났습니다. WMS에는 Ship Complete에 해당하는 상태가 기록됐고 기업 재고 거래도 반영됐다고 하겠습니다. 그런데 운송 차량이 아직 도크에 도착하지 않았거나, 도착했지만 Carrier Pickup 확인이 들어오지 않았습니다.

창고 관점에서는 출고 처리가 끝난 상태일 수 있습니다. 고객 주문 관점에서는 Shipped로 표시할 수 있지만 Delivered는 아닙니다. TMS에서는 운송 계획 완료, Pickup 대기, 운송 실행 전 같은 상태가 남습니다.

이때 고객센터가 “물건이 어디 있습니까”라고 묻습니다. WMS는 창고 출고 완료라고 답합니다. TMS는 Carrier Pickup 전이라고 답할 수 있습니다. 둘을 합치면 물건은 창고의 일반 재고에서는 빠졌지만 운송사의 이동 이벤트는 아직 시작되지 않은 인수인계 구간에 있을 가능성이 보입니다.

그래서 창고 문은 SoR이 바뀌는 중요한 경계입니다. WMS의 작업 완료만으로 배송 상태 전체를 설명할 수 없습니다. 운송 실행이 시작되면 TMS와 Carrier 이벤트가 새로운 질문에 답하기 시작합니다.

시간축을 하나 놓으면 충돌이 정리됩니다

재고 논쟁은 시스템별 스냅샷만 비교하면 더 복잡해집니다. 시간축을 놓으면 각 기록이 어느 순간부터 의미를 갖는지 보입니다.

Order
→ Allocated
→ Picked
→ Packed
→ Shipped
→ Carrier Pickup
→ Delivered

주문 상태는 이 전 구간에서 OMS가 추적합니다. 판매 약속은 주문 전후에 ATP가 중요한 판단을 합니다. 창고 위치는 입고부터 출고 전까지 WMS가 높은 해상도로 봅니다. 자동화 설비를 통과하는 짧은 순간에는 WCS와 제어 계층이 더 세밀한 위치 정보를 가질 수 있습니다. 기업 재고와 가치는 특정 Goods Movement 이벤트에서 ERP에 의미 있게 반영됩니다. Carrier Pickup 뒤에는 TMS와 운송 이벤트가 물건의 이동을 설명하는 데 더 가까워집니다.

도판 F11

이 그림의 목적은 시간이 지나면서 SoR이 한 시스템에서 다음 시스템으로 릴레이처럼 완전히 넘어간다고 말하는 데 있지 않습니다. 질문별 Lane이 겹칩니다. 고객 주문은 배송 중에도 OMS에 남고, ERP의 기업 기록도 계속 존재합니다. 다만 물리 위치를 가장 자세히 아는 계층은 창고 내부와 운송 중에 달라집니다.

같은 값 이름이 같은 의미를 보장하지 않습니다

시스템 통합에서 까다로운 경우는 숫자 차이보다 이름이 같은 경우입니다. ERP, OMS, WMS가 모두 availableQty라는 필드를 갖고 있다고 하겠습니다. 이름만 보면 같은 값을 복제한 것처럼 보입니다. 실제 계산 규칙은 서로 다를 수 있습니다.

WMS의 Available은 재고 상태와 창고 작업 규칙을 기준으로 “현재 창고에서 사용할 수 있는 수량”을 뜻할 수 있습니다. ATP의 Available은 이미 들어온 수요, 향후 공급, Promise 정책까지 고려한 결과일 수 있습니다. OMS의 Available은 고객 채널에 노출하기 위해 안전재고나 채널별 배분 규칙을 한 번 더 적용한 값일 수 있습니다.

이 세 필드를 이름만 맞춰 매핑하면 통합 테스트에서는 숫자가 비슷해 보여 통과할 수 있습니다. 프로모션, 재고 부족, 반품, 지연 입고처럼 경계 상황이 오면 차이가 드러납니다. 문제의 원인은 인터페이스보다 의미 계약의 부재에 가깝습니다.

따라서 데이터 사전에는 필드명과 타입만 적지 않습니다. 계산 대상, 제외 조건, 기준 시각, 갱신 이벤트, SoR을 함께 적는 편이 안전합니다. availableQty integer보다 “판매 약속 계산에 사용할 수량이며 ATP 결과를 기준으로 하고 Order Allocation 변경 후 갱신한다”는 설명이 훨씬 많은 오류를 막습니다.

같은 원칙은 status에도 적용됩니다. WMS의 Inventory Status, OMS의 Order Status, TMS의 Shipment Status를 하나의 공통 상태 코드로 합치려 하면 의미가 사라집니다. 상태를 통합할 때는 이름을 맞추기보다 어떤 사건이 그 상태를 만들었는지 연결해야 합니다.

숫자가 다르면 세 가지를 확인합니다

실무에서 두 시스템의 재고 숫자가 다르면 원인을 찾기 전에 비교 조건부터 맞춰야 합니다.

첫 번째는 대상입니다. SKU만 같은지, LOT와 상태와 로케이션까지 같은 범위를 비교하는지 확인합니다. 한쪽은 전체 On-hand를 합산하고 다른 쪽은 Available만 보여주면 숫자는 원래 다릅니다.

두 번째는 시점입니다. 같은 기준시각인지 확인합니다. WMS의 피킹 완료가 10시 01분에 발생하고 ERP 출고 반영이 10시 03분에 끝난다면 그 사이 스냅샷은 다를 수 있습니다. 허용된 비동기 구간인지 장애인지 SLA와 이벤트 상태를 함께 봅니다.

세 번째는 업무 의미입니다. 위치 수량, 판매 약속 수량, 기업 재고 수량을 같은 이름의 availableQty로 노출하고 있지는 않은지 확인합니다. 이름이 같아도 계산 규칙이 다르면 인터페이스 정의가 부족합니다.

이 세 가지를 맞춘 뒤에도 같아야 할 값이 다르면 비로소 대사와 복구 문제로 들어갑니다. 18장에서는 실물과 전산이 갈라질 수 있는 발생 지점을 공정 전체에서 추적합니다. 19장에서는 메시지 중복과 재처리 때문에 기록이 어떻게 더 어긋날 수 있는지 봅니다.

데이터 소유권은 수정 권한까지 포함합니다

SoR을 정할 때 조회 화면만 생각하면 부족합니다. 누가 값을 변경할 권한을 갖는지도 함께 정해야 합니다.

예를 들어 WMS가 로케이션 단위 재고의 기준 기록이라면 OMS가 직접 WMS의 로케이션 수량을 수정하는 구조는 위험합니다. OMS는 주문 취소나 반품 같은 업무 이벤트를 전달하고, 창고 계층이 해당 이벤트를 창고 상태 변화로 해석하는 편이 경계가 선명합니다.

반대로 OMS가 고객 주문 상태의 기준이라면 WMS가 고객 주문을 임의로 Delivered로 바꾸는 것도 어색합니다. WMS는 출고 완료 사실을 전달하고 OMS가 자신의 상태 모델에 따라 주문 상태를 갱신합니다.

운영 화면에서 긴급 수정 기능을 제공할 수는 있습니다. 그때도 “수정할 수 있다”와 “소유한다”를 구분합니다. 운영자가 임시로 값을 바꿨다면 원래 SoR과 어떻게 대사하고, 어떤 감사 기록을 남기며, 하류 시스템에 어떤 이벤트를 보내는지까지 설계해야 합니다.

데이터 소유권은 테이블 주인이 누구냐는 문제보다 큽니다. 생성, 변경, 확정, 배포, 복구의 권한을 어디에 둘지 정하는 일입니다.

SoR과 복구 권한을 함께 묶습니다

장애가 발생하면 평소의 조회 권한보다 복구 권한이 더 중요해집니다. WMS 위치 기록이 기준인데 WMS 이벤트 반영이 멈췄다고 하겠습니다. OMS가 최신 주문 정보를 갖고 있다는 이유로 WMS 위치를 직접 덮어쓰게 하면 계층 경계가 무너집니다. 주문 정보는 물건이 실제 어느 Bin에 있는지 증명하지 못합니다.

복구 절차는 기준 기록과 가까운 계층에서 시작해야 합니다. WMS 작업 로그와 위치 기록을 확인하고, 자동화 구간이면 WCS 또는 제어 Telemetry로 물리 이동 사실을 보조 확인합니다. 실제 위치가 확정된 뒤 WMS 상태를 복구하고, 그 결과 이벤트를 OMS·ERP 같은 인접 계층에 다시 전파합니다.

반대 방향도 같습니다. WMS가 출고 완료를 알고 있어도 고객 주문 상태의 복구 규칙은 OMS가 소유해야 합니다. WMS가 OMS 테이블을 직접 고치는 편법은 당장 숫자를 맞출 수 있지만 다음 이벤트에서 다시 충돌할 가능성이 큽니다. SoR을 정한다는 말에는 누가 정상 상태를 복원할 권한을 가지는지도 포함됩니다.

인터페이스 명세에 SoR을 쓰는 방법

“재고는 WMS 기준”이라는 한 줄은 편하지만 너무 많은 정보를 숨깁니다. 인터페이스 명세에는 더 좁은 단위가 필요합니다.

예를 들어 다음처럼 질문을 나눌 수 있습니다.

• Location Inventory의 기준 기록은 WMS가 가진다.
• Promiseable Quantity는 ATP 규칙으로 계산하고 OMS가 고객 채널에 노출한다.
• Enterprise Inventory/Value는 ERP의 기업 거래를 기준으로 한다.
• Equipment Position은 WCS 또는 제어 Telemetry를 장애 조사 시 참조한다.
• Order Fulfillment State는 OMS가 기준으로 관리한다.
• Transport Execution State는 TMS와 Carrier 이벤트를 기준으로 갱신한다.

이 정도까지 내려가면 동기화 방향도 자연스럽게 따라옵니다. 어느 시스템이 Publish하고 어느 시스템이 Subscribe하는지, 어떤 이벤트가 상태 전환을 일으키는지, 재처리 때 원 기록을 다시 조회할지 결정할 수 있습니다.

명세에서 특히 조심할 표현이 sync입니다. “ERP와 WMS 재고 Sync”만 적으면 누가 무엇을 어떤 방향으로 맞추는지 알 수 없습니다. Goods Issue confirmed in WMS → ERP inventory transaction requested → ERP result returned → reconciliation target updated처럼 사건과 책임을 나누면 장애 처리 방식까지 보입니다. 실제 메시지명은 프로젝트마다 달라집니다.

진실 하나를 찾는 대신 질문을 정확하게 만듭니다

재고 시스템이 여러 개라서 복잡한 것이 아닙니다. 하나의 물건이 동시에 여러 업무 문맥에 놓이기 때문에 여러 기록이 필요합니다. 창고 위치, 판매 약속, 회계 자산, 작업 진행, 장비 위치, 주문 이행, 운송 상태는 같은 데이터의 복사본이 아닙니다. 서로 연결돼 있지만 각각 다른 질문에 답합니다.

따라서 회의에서 “어느 시스템이 맞습니까”라는 질문이 나오면 서둘러 시스템 하나를 선택하지 않아도 됩니다. 질문을 더 작게 나눕니다.

어느 위치를 말합니까.

어떤 상태의 수량을 말합니까.

고객에게 약속할 수 있는 수량입니까.

회계상 자산입니까.

창고 작업의 진행 상태입니까.

자동화 설비 위의 현재 위치입니까.

주문입니까, 운송입니까.

여기까지 나누면 기록의 기준이 보이고, 서로 다른 숫자가 왜 존재하는지도 설명할 수 있습니다. 같아야 할 값이 무엇인지 정했으니 대사 조건도 정할 수 있습니다.
같은 숫자를 만드는 일보다 같은 의미를 보장하는 일이 선행돼야 합니다. 의미가 맞으면 동기화 주기와 허용 오차를 설계할 수 있고, 의미가 다르면 숫자를 억지로 맞추는 작업 자체가 새로운 오류를 만듭니다.

이제 물건이 창고 문을 나갑니다. WMS의 로케이션과 작업이 중심이던 세계에서 Carrier, Pickup, Transit, POD가 중심인 세계로 이동합니다. 물건은 계속 하나지만 다음 질문의 주인은 달라집니다.