재고 데이터를 보충 발주 제품으로 만들기: 품절 알림에서 구매 워크플로까지

재고가 10개 아래로 떨어지면 알림을 보내는 것은 가장 단순한 데이터 제품처럼 보입니다. 하지만 프로덕션에서 운영하기 시작하면 팀은 곧바로 질문을 던집니다. 어느 창고인가, 어느 변형인가, 가용 재고인가 보유 재고인가, 주문 확정 수량은 포함하는가, 운송 중인 재고는 언제 도착하는가, 얼마나 재주문해야 하는가, 어느 공급업체에서 사야 하는가, 추천은 실행되었는가. 숫자는 구매와 재고 이동 워크플로에 들어가야 비로소 품절과 재고 적체를 줄일 수 있습니다.

r/InventoryManagement의 멀티 플랫폼 재고 토론(https://www.reddit.com/r/InventoryManagement/comments/1uq9l7k/how_do_you_all_keep_inventory_straight_across/)에서는 판매자들이 기억과 오래된 스프레드시트로 여러 채널을 관리하다가 같은 재고를 여러 주문에 중복 할당하게 된 사례를 이야기합니다. 게시글과 댓글은 개인적인 상황을 반영할 뿐이며, 특정 소프트웨어가 이 문제를 자동으로 해결한다는 증거는 아닙니다. 다만 유용한 질문을 던집니다. 어느 시스템이 기준이 되는 재고 수치를 보유하는가, 채널 식별자는 어떻게 매핑하는가, 업데이트가 실패하면 누가 알림을 받는가 하는 것입니다.

예측을 논하기 전에 재고 객체부터 정의한다

채널에 따라 같은 실물 상품이 내부 SKU, 플랫폼 상품 정보 ID, 상품 ID, 변형 ID, 바코드를 각각 가질 수 있습니다. 색상, 사이즈, 포장 수량, 세트 구성 관계가 잘못 매핑되면 시스템은 잘못된 숫자를 더 빠르게 동기화할 뿐입니다. 첫 버전에서는 판매 모델을 바로 학습시키기보다 사람이 검증할 수 있는 상품 마스터 데이터를 먼저 구축해야 합니다.

최소한의 재고 키에는 보통 재고 품목, 변형, 로케이션, 수량 상태가 필요합니다. Shopify의 수량 및 상태 관리 가이드(https://shopify.dev/docs/apps/build/orders-fulfillment/inventory-management-apps/manage-quantities-states)도 ProductVariant, InventoryItem, InventoryLevel, Location을 별개의 객체로 나눕니다. 채널 상품 정보는 판매 진입점이므로 내부 상품의 기본 키로 자동 승격되어서는 안 됩니다. 매핑 테이블에는 누가 데이터를 확인했는지, 언제부터 적용되는지, 일대다 관계인지, 묶음 해체·번들·대체품은 어떻게 계산하는지 기록해야 합니다.

Shopify의 InventoryLevel 리소스(https://shopify.dev/docs/api/admin-graphql/latest/objects/InventoryLevel)는 재고를 특정 로케이션에 있는 재고 품목의 수량으로 표현하며, available, on hand, in transit, committed 같은 상태를 서로 다른 수량 상태로 조회합니다. 이 모델이 모든 플랫폼을 대표하지는 않지만, 로케이션과 상태 맥락 없이 'SKU 재고 8개'라고만 말하면 불완전하다는 점을 잘 보여 줍니다.

가용, 보유, 확정, 운송 중 재고를 하나의 현재 재고로 합칠 수 없다

Shopify의 재고 관리 앱 가이드(https://shopify.dev/docs/apps/build/orders-fulfillment/inventory-management-apps)는 incoming, on_hand, available, committed, reserved, damaged, safety_stock, quality_control 등의 상태를 구분합니다. on_hand는 실제 위치에 있는 전체 수량을 나타내지만, 그중 일부는 committed, reserved, damaged 상태이거나 품질 검사 대기 중일 수 있으므로 전부를 새 주문 접수에 사용할 수는 없습니다.

보충 발주 제품은 최소 네 가지 비즈니스 지표를 보여 주어야 합니다. 지금 판매 가능한 수량, 기존 주문에 확정된 수량, 재고로 보유한 실물 수량, 그리고 운송 중인 수량과 예상 가용 시점입니다. 플랫폼이 이 중 일부만 제공한다면, 뺄셈으로 정확해 보이는 '실제 재고' 값을 만들어 내려 하지 말고 커버리지 범위를 명시해야 합니다.

안전 재고는 가용 수량에서 몰래 빼는 고정된 숫자가 아닙니다. 제품은 사용자가 안전 재고 규칙, 적용 로케이션, 유효 기간을 볼 수 있게 해야 합니다. 프로모션 기간, 공급 변동, 신제품 단계에 따라 다른 버퍼가 필요할 수 있으며, 자동 조정이 이뤄질 때는 사유와 운영 감사 로그를 남겨야 합니다.

이벤트 업데이트와 주기적 대사는 함께 운영해야 한다

주문, 취소, 환불, 입고, 재고 이동, 재고 실사는 모두 재고를 변경합니다. 이벤트 기반 동기화는 지연을 줄여 주지만 주기적인 전체 대사를 대신할 수는 없습니다. 웹훅은 지연, 중복, 순서 뒤바뀜, 유실이 발생할 수 있고, 채널에 따라 일부 상태에 대해서만 이벤트를 보내기도 합니다.

Shopify 공식 문서에 따르면 committed, reserved, damaged, safety_stock, quality_control 같은 상태가 바뀌어도 해당 재고 웹훅이 트리거되지 않습니다. inventory_levels/update만 구독해서는 상태 변경을 모두 파악할 수 없습니다. 제품은 각 소스의 기능에 맞춰 보완 조회와 대사 주기를 설계해야 합니다.

각 재고 이벤트에는 소스 이벤트 ID, 품목 매핑, 로케이션, 상태, 변경 수량, 소스 타임스탬프, 수신 타임스탬프, 처리 결과를 보존해야 합니다. 멱등성 키는 중복 차감을 막고, 버전이나 시간 규칙은 순서가 뒤바뀐 실행을 처리하며, 주기적 스냅샷은 누적 이벤트와 현재 소스 값 사이의 차이를 감지합니다.

동기화 실패는 예외 대기열로 보내야 합니다. 한 채널은 업데이트에 성공하고 다른 채널은 실패했다면 시스템은 전체 성공으로 보고해서는 안 됩니다. 사이트 내 API 오류 및 자가 복구 가이드(https://everyinfra.com/build/api-errors-self-healing)는 요청 속도 제한, 타임아웃, 권한 문제, 잘못된 매핑, 소스 오류를 구분하고 각각을 구체적인 재시도 및 수동 처리 절차에 연결하는 데 도움이 됩니다.

품절 알림을 설명 가능한 보충 발주 추천으로 업그레이드한다

고정 임계값은 매우 안정적인 소규모 운영에는 맞지만, 리드 타임, 판매 속도 변화, 이미 발주한 구매 주문, 최소 주문 수량을 반영하지 못합니다. 설명 가능한 보충 발주 추천은 최소한 사용한 판매 기간, 현재 가용 재고와 운송 중 재고, 예상 리드 타임, 목표 재고 일수, 공급업체 제약, 추천 수량을 밝혀야 합니다.

공식을 'AI 추천' 뒤에 숨겨서는 안 됩니다. 예측 모델을 사용하더라도 사용자는 핵심 입력값과 민감도를 볼 수 있어야 합니다. 리드 타임이 7일에서 21일로 바뀌면 추천이 어떻게 달라지는지, 그대로 외삽해서는 안 되는 프로모션 판매 데이터를 누가 제외할 수 있는지, 과거 데이터가 없는 신제품에는 어떤 초기 가정이 적용되는지 등입니다.

보충 발주 후보는 세 가지로 나뉩니다.

• 즉시 처리: 현재 가용 재고, 확정 수량, 운송 중인 발주 물량, 리드 타임을 기준으로 보충 재고가 도착하기 전에 품절이 예상됩니다.
• 확인 필요: 판매 또는 리드 타임 데이터가 부족하며, 시스템이 누락된 필드를 나열하고 검토자를 제안합니다.
• 보충 불필요: 재고가 충분하거나, 운송 중 재고로 수요를 충당할 수 있거나, 품목이 단종 또는 재고 정리 중입니다.

'보충 불필요'는 영구적인 상태가 아닙니다. 추천에는 생성 시각, 사용한 재고 버전, 만료 조건이 포함되어야 하며, 대량 주문, 공급 지연, 수동 실사가 발생하면 다시 계산해야 합니다.

구매 워크플로가 보충 발주 제품의 최종 전달 지점이다

알림을 받은 뒤에도 구매 담당자는 공급업체를 선택하고, 최소 주문 수량과 포장 단위를 확인하고, 예산을 요청하고, 구매 주문서를 작성하고, 배송을 추적하고, 입고와 품질 검사를 관리해야 합니다. 제품이 재고 부족 이메일만 보낸다면 사용자는 여전히 여러 시스템에서 같은 정보를 맞춰 보느라 시간을 씁니다.

구매 후보 카드에는 품목, 로케이션, 예상 품절일, 추천 수량, 현재 운송 중인 미입고 발주 건, 공급업체와 리드 타임, 계산 근거, 예외 항목을 담을 수 있습니다. 지정된 담당자는 내용을 확인한 뒤 자동 발주 대신 구매 작업을 생성합니다. 자동 발주는 재무 및 재고 위험을 낳으므로 권한, 한도, 롤백 설계를 갖춘 별도 기능으로 개발해야 합니다.

입고되었다고 해서 모든 수량을 바로 판매할 수 있는 것은 아닙니다. 수량 차이, 파손, 품질 검사 상태를 다시 기록해야 하며, 구매 주문이 일부만 입고되면 미입고 잔량을 유지해야 합니다. 전체 사이클은 클릭 한 번으로 끝나는 알림이 아니라 추천, 승인, 발주, 운송 추적, 입고, 판매 가능, 사후 분석으로 이어집니다.

데이터 객체와 상태 인터페이스는 사이트 내 통합 데이터 API 설계 가이드(https://everyinfra.com/build/unified-data-api-guide)를 참고하십시오. 외부 상품 가격도 함께 모니터링한다면 보충 발주 의사결정을 가격 모니터링 구독 제품(https://everyinfra.com/blog/price-monitoring-subscription-product)과 분리해야 합니다. 가격 변화는 구매 판단에 영향을 줄 수 있지만 내부 재고 및 공급 기록을 대신할 수는 없습니다.

멀티 창고·멀티 채널 환경에는 명시적인 할당 규칙이 필요하다

회사 전체에 재고가 있다고 해서 특정 로케이션의 출고 능력이 보장되지는 않습니다. 보충 발주 시스템은 먼저 구매보다 재고 이동이 나은지 판단해야 합니다. 다른 창고에 이동 가능한 재고가 있는지, 배송 시간과 비용은 얼마인지, 재고를 옮기면 다른 곳에서 새로운 품절이 생기지 않는지 확인합니다. 재고 이동 추천과 구매 추천에는 서로 다른 액션 항목과 승인 체계가 적용됩니다.

채널 할당에도 규칙이 필요합니다. 전체 가용 수량을 모든 채널에 동기화하면 초과 판매 위험이 있고, 채널별로 고정 할당하면 재고가 묶일 수 있습니다. 공유 풀, 채널별 상한, 안전 버퍼를 설정할 수 있지만, 제품은 현재 전략과 최근 동기화 상태를 보여 주어야 합니다. 실시간으로 운영하더라도 동시 주문, 네트워크 지연, 플랫폼 처리 시간이 존재하므로 초과 판매가 전혀 없다고 약속해서는 안 됩니다.

번들과 멀티팩의 경우 주문 이벤트를 하위 구성품 소모량으로 변환해야 합니다. 예를 들어 2개입 팩 하나를 판매하면 기본 재고를 2개 차감해야 합니다. 같은 구성품이 여러 번들에 포함된다면 보충 발주 추천은 구성품 단위로 수요를 합산해야 합니다. 매핑이 불확실할 때는 잘못된 수량을 퍼뜨리기보다 자동 동기화를 막고 확인을 요청하는 편이 안전합니다.

데이터 품질 대시보드는 복잡한 예측보다 먼저 가치를 만든다

보충 발주 오류는 알고리즘보다 누락된 리드 타임, 잘못된 SKU 매핑, 지연된 재고 실사, 재고가 복원되지 않은 취소 주문, 업데이트되지 않은 운송 상태에서 비롯되는 경우가 많습니다. 제품은 이러한 공백을 작업 대기열로 만들어 공급업체가 지정되지 않은 품목, 실사 기한이 지난 로케이션, 처리에 실패한 이벤트, 예상 납기를 넘긴 구매 주문을 추적해야 합니다.

예측은 실제 결과와도 비교해야 합니다. 예상 품절일과 실제 품절일, 권장 수량과 승인 수량, 그리고 재고 적체 여부를 확인하기 위한 입고 후 판매 소요 일수를 비교합니다. 수동 조정은 모델 실패를 뜻하는 노이즈가 아니라 비즈니스 제약을 이해하는 데 도움이 되는 가치가 높은 피드백입니다.

데이터 수집 범위에 공백이 생기는 경우도 별도로 추적해야 합니다. 채널 인증이 만료되면 판매량이 갑자기 떨어져 모델이 수요 감소로 오판할 수 있습니다. 재고 조회가 실패하면 시스템이 과다 재주문할 수 있습니다. 데이터 신선도와 소스 상태는 비즈니스 지표와 함께 표시해야 합니다.

단일 조달 주기로 MVP 시작하기

초기 버전은 단일 채널, 단일 창고, 수십 개의 고빈도 SKU만 다뤄도 됩니다. 먼저 항목 매핑, 재고 상태, 이벤트 정합성 확인, 구매 후보 카드를 완성한 뒤 한 번의 전체 조달 주기를 통해 검증합니다. 복잡한 예측, 다중 창고 최적화, 자동 발주는 그 이후에 진행해도 됩니다.

검수 지표에는 품절 전 사전 경고 시간, 동기화 예외 발견 시간, 권장안 수용 또는 수정 사유, 긴급 구매 건수, 품절 및 적체 변화, 권장안에서 발주까지의 처리 시간이 포함됩니다. 알림 건수만 측정하거나 대조군 없이 모든 재고 개선을 시스템 덕분으로 돌리는 일은 피해야 합니다.

이 글은 재고 데이터를 제품화하는 방법론을 다루며, EveryInfra가 재고 또는 구매 관리 제품을 출시했다는 의미는 아닙니다. 재고 데이터의 가치는 대시보드가 새로 고쳐질 때가 아니라, 팀이 설명 가능한 권장안을 바탕으로 올바른 액션을 완료하고 시스템이 소스 변경, 동기화 실패, 수동 조정 이후에도 데이터 정합성을 계속 맞출 때 생겨납니다.