구현 컨설턴트로서 저는 이 똑같은 아수라장을 세 번이나 목격했습니다. 가정용 수납용품 셀러가 같은 오거나이저를 Amazon, Walmart, Shopify DTC 스토어에 올리고, 창고에 있는 실재고는 100개. 어느 날 세 채널에서 합쳐 120개가 팔립니다. 초과된 20건의 주문은 취소되고——그중 열댓 건은 Amazon에서——같은 달에 퍼포먼스 경고가 날아듭니다. 사장님이 묻습니다. "재고 시스템이 있는데 어떻게 오버셀을 했죠?" 제 답은 이렇습니다. 오버셀은 절대 규율의 문제가 아닙니다. 여러 채널이 하나의 물리적 재고 풀을 공유할 때, 시스템 설계 자체에 세 개의 퓨즈가 내장되어 있는 것입니다.
모든 오버셀 뒤에 숨어 있는 세 개의 퓨즈
퓨즈 1: 동기화 지연. 대부분의 셀러는 재고를 실시간이 아닌 API 폴링 주기로 동기화합니다. Walmart와 많은 DTC 플러그인의 기본값은 15분 동기화——인기 SKU라면 15분 만에 반나절치 안전재고가 녹아버립니다. 가장 기억에 남는 사례: 플래시 세일에서 DTC 스토어가 12분 만에 90개를 팔아치웠는데, Amazon은 여전히 "재고 있음"으로 표시하며 주문을 계속 받았습니다.
퓨즈 2: 아무도 빼지 않은 운송 중·예약 수량. 창고에 물리적으로 100개 있다고 해서 판매 가능한 게 100개인 것은 아닙니다. 피킹 완료 미출고 주문, 운송 중인 이관, 도매 고객용 예약분——이렇게 "주인이 정해진" 수량을 판매 가능 수에서 빼지 않으면, 모든 채널이 부풀려진 숫자를 보게 됩니다. 어느 3PL 가동 현장에서, 그들의 "판매 가능 수량" 공식이 운송 중 재고를 전혀 빼지 않는 걸 발견했습니다. 첫 주에 40건 이상을 오버셀했습니다.
퓨즈 3: 각 채널의 "판매 가능 수량"이 한 번도 같은 숫자가 아니었다. Amazon 매장에 표시되는 건 FBA 판매 가능 수량입니다. DTC 스토어에 표시되는 건 당신이 보낸 숫자입니다. Walmart는 자체 예약 로직을 적용합니다. 정의는 세 가지가 다른데, 이를 채워야 할 물리적 풀은 하나. 하나의 금고를 세 명의 계산원이 공유하면서 각자 다른 장부로 일하는 것과 같습니다.
세 가지 방지 아키텍처 — 이 표에서 고르세요
| 아키텍처 | 동작 방식 | 강점 | 비용 | 적합 대상 |
|---|---|---|---|---|
| 채널별 안전재고 분할 | 물리적 풀을 과거 판매 비율에 따라 채널별 몫으로 나눈다 | 단순하고, 새 시스템 불필요, 스프레드시트로 운영 가능 | 활용률이 낮음: 잘 팔리는 채널은 품절되고 조용한 채널은 재고를 쌓아둠 | SKU 수십 개, 엔지니어링 여력 없는 셀러 |
| 가상 공유 풀 + 예약 | OMS가 하나의 공유 판매 가능 수량을 보유, 채널 주문은 먼저 예약하고 출고 시 차감 | 활용률이 높고 오버셀률이 거의 0에 수렴 | OMS 필요, 예약 타임아웃·해제 로직을 설계해야 함 | 중규모 셀러: SKU 수백 개, 일 주문 수백 건 |
| 중앙 OMS 재고 + 다창고 배분 | 창고·채널을 아우르는 배분 규칙을 가진 중앙 판매 가능 수량 | 가장 완성도가 높음, 다창고·다채널·다통화 지원 | 구현·유지 비용이 가장 큼 | 다창고 셀러 또는 하루 1,000건 이상을 처리하는 3PL |
제 선정 조언: 아키텍처 3으로 바로 뛰어들지 마세요. 두 숫자를 보세요. SKU 수와 하루 주문량입니다. SKU가 약 100개 이하, 하루 주문이 약 300건 이하라면, 아키텍처 1에 성실한 순환 실사를 더하는 것만으로 정말 충분합니다——시스템 문제는 실사를 하루 한 번 더 하는 게 더 싸게 해결될 때도 있습니다. 하루 약 500건 이상 또는 SKU 약 500개 이상이면, 아키텍처 2의 ROI가 가장 좋습니다. 아키텍처 3은 다창고 플레이어를 위한 것. 단일 창고 셀러가 도입하는 건 못에 대형 망치를 쓰는 격이고, 유지 비용에 잡아먹힙니다.
직관에 반하는 견해: 대부분의 셀러는 실시간 동기화가 최적의 답이라고 믿습니다. 하지만 대다수에게는 15분 동기화 + 충분한 안전재고가 실시간 동기화 + 안전재고 0보다 낫습니다. 실시간화는 지연을 15분에서 몇 초로 줄일 뿐——세 채널이 같은 1초에 주문을 받았을 때의 경쟁 조건은 고쳐지지 않습니다. 정말로 당신을 지켜주는 건 예약 메커니즘과 안전재고이지, 동기화 속도가 아닙니다.
적절한 동기화 주기 정하기
제가 쓰는 기준은 이렇습니다.
동기 간격 내 판매 가능 상한 = 현재 판매 가능 수량 − (분당 피크 판매량 × 간격 분 × 1.5)
읽는 법: 이 SKU가 기록한 분당 최고 판매 속도를 가져와, 동기화 간격을 곱하고, 1.5의 안전 계수를 곱한 만큼을 채널에 판매 가능 수를 보내기 전에 확보합니다. 예: 분당 2개가 피크인 SKU에 15분 간격이라면, 2 × 15 × 1.5 = 45개를 확보합니다. 인기 SKU는 준실시간 동기화(1–2분)로 옮기고, 롱테일 SKU는 15–30분에 둡니다. 모든 걸 완전 실시간으로 하면 이유 없이 API 쿼터를 태웁니다.
그리고 하나 더: 한 방향으로만 동기화하지 마세요. 많은 플러그인은 재고 수를 채널에 보내기만 하고, 채널 측 표시 재고를 다시 가져와 대조하지 않습니다. 주 1회 삼자 대조를 돌리세요——OMS 판매 가능 수량 대 각 채널 매장 표시 수——5%를 넘는 차이가 있으면 조사합니다. 이 습관은 어떤 아키텍처보다 싸고, 대부분의 아키텍처보다 효과적입니다.
Amazon의 오버셀이 가장 비싸다
세 채널이 오버셀을 똑같이 벌하지는 않습니다. DTC라면 사과 메일과 쿠폰으로 대개 만회할 수 있습니다. Walmart라면 매장 평점이 깎입니다. Amazon에서는, 취소된 오버셀이 그대로 주문 결함 지표로 흘러들어갑니다——취소율과 배송 지연율이 ODR에 합산되고, 기준을 넘으면 계정 심사나 정지가 발동됩니다. 기준은 Amazon의 최신 공개 정책을 따르고 시간이 지나면 바뀌니, 작년 숫자에 계정을 걸지 마세요.
즉 실무에서는: Amazon에는 항상 가장 보수적인 판매 가능 수를 보내세요. 저는 Amazon 채널에 2.0의 안전 계수, 나머지에 1.5를 씁니다. 그리고 FBA 판매 가능 수량과 자사 창고 판매 가능 수량은 두 개의 별도 장부로 유지하세요——외부로 보내는 하나의 숫자로 섞지 마십시오. 제가 보는 가장 흔한 초보 실수입니다.
구현 체크리스트
- 재고 마스터 데이터를 통일하세요: 채널에 걸친 SKU 매핑 테이블을 맞춥니다——하나의 물리적 SKU는 정확히 하나의 재고 키에 대응합니다. 변형과 번들은 자체 가상 SKU를 갖습니다.
- "판매 가능 수량" 공식을 문서화하고 전원이 사용하게 하세요: 판매 가능 수량 = 보유 수량 − 예약분 − 운송 중 홀드 − 미출고 채널 주문.
- 채널별로 안전재고 수준을 독립적으로 설정하고, Amazon을 가장 보수적으로 합니다.
- 인기 SKU는 자체 동기화 리듬(1–2분)에 두고, 롱테일은 15–30분에 둡니다.
- 예약 타임아웃과 해제: 미결제 주문의 예약은 30분 후(또는 채널 규칙에 따라) 자동 해제해 "유령 예약"이 재고를 잠그지 않게 합니다.
- 주간 삼자 대조: OMS 판매 가능 수량 대 각 채널 매장 표시 수. 5%를 넘는 차이는 조사합니다.
- 대형 프로모션 48시간 전에 재고 기준선을 동결하세요: 스냅샷을 내보내고, 행사 중에는 안전 계수만 조정하고 기준선은 절대 건드리지 마세요——누구의 편집도 충돌하지 않게.
- 한 페이지짜리 오버셀 SOP를 쓰세요: 누가 구매자에게 연락하는지, 보상 기준은 무엇인지, Amazon 케이스를 어떻게 여는지. 인쇄해서 벽에 붙입니다.
채널을 가로지르는 재고 풀 공유는 근본적으로 "하나의 금고, 세 명의 계산원" 문제이며, 예약 메커니즘과 판매 가능 수량의 단일 정의로 해결됩니다. 적절한 아키텍처를 고르고, 적절한 동기화 리듬을 정하고, Amazon은 보수적으로 유지하세요——그러면 오버셀의 덫은 설계로 없앨 수 있는 것이 됩니다. 이 덫을 저는 세 번 봤습니다. 당신은 한 번도 보지 않으셨으면 합니다.
Lin Xiao, WMS 구현 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
