소규모팀을 위한 재고 정확성: 사용 가능, 예약, 판매

소규모팀이 재고 정확성으로 고생하는 이유

작은 상점을 운영하거나 한정된 상품만 발송한다면 재고는 단순할 것 같습니다. 선반에 있는 만큼 세서 그만큼만 팔면 되니까요. 하지만 숫자가 정확해도 오버셀(이중판매)이 발생합니다.

주된 원인은 타이밍입니다. 10:00:00에 재고 수가 맞더라도 10:00:05에는 틀릴 수 있습니다. 두 사람이 동일한 마지막 한 개를 구매하려 했거나, 결제가 지연됐거나, 직원이 체크아웃 중에 재고를 조정했을 수 있습니다. 소규모팀은 전담 운영 담당자가 하루종일 엣지케이스를 감시하지 않으므로 이런 순간을 놓치기 쉽습니다.

재고가 틀리면 고객은 즉시 느낍니다:

• 주문을 하고 나중에 취소 이메일을 받는다.
• 결제는 했지만 발송 불가로 환불을 기다린다.
• 지원팀에 연락해 무슨 일이 있었고 돈은 언제 돌아오는지 묻는다.
• 신뢰를 잃고 다시 오지 않을 수 있다.

내부적으로는 사과, 환불, 재검수, 티켓 응대 같은 일이 생겨 바빠집니다. 그래서 소규모팀의 재고 정확성은 완벽한 계수보다 체크아웃 중에 “재고 있음”이 무엇을 의미하는지에 대한 명확한 규칙에 관한 것입니다.

핵심 아이디어는 재고를 하나의 숫자가 아닌 몇 가지 명확한 상태로 다루는 것입니다. “사용 가능(Available)”은 지금 약속할 수 있는 수량입니다. “예약(Reserved)”은 누군가 결제를 완료하지 않은 상태에서 잠시 보류한 수량입니다. “판매(Sold)”는 결제가 확정되어 이젠 발송해야 하는 수량입니다.

이 가이드는 이런 상태들 간의 이동, 언제 예약을 만들지, 결제 타임아웃을 어떻게 처리해 재고가 묶이거나 이중 판매되지 않게 할지에 대한 단순하고 실용적인 규칙에 집중합니다. 복잡한 수요 예측, 창고 레이아웃, 다중 위치 계획 등은 다루지 않습니다.

사용 가능 vs 예약 vs 판매: 간단한 정의

이 세 단어는 단순한 라벨처럼 보이지만 서로 다른 약속입니다. 섞이면 오버셀(두 사람이 하나의 상품에 대해 결제)하거나 숨겨진 판매 기회를 잃게 됩니다.

**사용 가능(Available)**은 “고객이 지금 이 항목에 대해 체크아웃을 시작할 수 있다”는 의미입니다. 물리적 재고 중 다른 사람에게 이미 할당되지 않은 부분으로, 공개적으로 표시하는 숫자라고 생각하면 됩니다.

**예약(Reserved)**은 “특정 고객을 위해 잠시 이 항목을 보류하고 있다”는 의미입니다. 예약은 일반적으로 쇼퍼가 명확한 의사를 보였을 때 생성됩니다(예: 체크아웃을 시작했을 때). 예약된 재고는 아직 판매되지 않았지만 이중 예약을 막기 위해 다른 사람에게는 일시적으로 판매 불가로 처리합니다.

**판매(Sold)**은 “구매가 확정됐다”는 의미입니다. 이때 더 이상 판매 가능한 것으로 간주하지 않아도 되는 시점입니다. 많은 상점에서는 결제 성공 시점(또는 신뢰할 수 있는 후결제 방식으로 주문이 생성된 시점)을 판매의 시작으로 보고, 배송 시점까지 처리합니다.

한 가지 중요한 점: 사용 가능은 물리적 보유 수량(on hand) 과 같지 않습니다. 보유 수량은 실제로 가진 것이고, 사용 가능은 새 구매자에게 약속할 수 있는 양입니다.

작은 예로 보유 수량 5개가 있을 때:

• 보유(on hand): 5
• 예약(Reserved): 2 (두 명이 체크아웃 중)
• 판매(Sold): 1 (이미 결제된 주문)
• 사용 가능(Available): 2 (5 - 2 - 1)

세 숫자가 동시에 진실일 수 있다는 점을 주목하세요. 만약 “보유”만 추적하면 사이트는 5개로 표시해 다섯 명이 구매하려고 시도하게 만들 수 있고, 실제로는 자신있게 이행할 수 있는 것은 2개뿐일 수 있습니다.

재고가 이동하는 방식: 기본 라이프사이클

재고는 ‘하나의 숫자’처럼 취급될 때 엉망이 됩니다. 소규모팀의 재고 정확성을 위해서는 각각 다른 질문에 답하는 상태(state)를 따라가는 경로로 생각하세요: 누군가 아직 살 수 있는가, 체크아웃을 위해 보류된 상태인가, 판매가 확정된 상태인가.

일반적인 라이프사이클은 다음과 같습니다:

• 사용 가능 -> 예약: 고객이 체크아웃을 시작하거나 “결제”를 클릭했을 때 보류를 생성합니다.
• 예약 -> 판매: 결제가 확인되었을 때만 발생합니다(또는 오프라인 결제를 수락했을 때).
• 예약 -> 사용 가능: 체크아웃 포기, 결제 타임아웃, 고객이 결제 전에 취소했을 때 발생합니다.

“판매”는 실질적인 약속을 하는 순간이어야 합니다. 많은 설정에서 이 시점에 물리적 재고 수를 줄입니다. 배송을 나중에 하는 경우(소규모팀에서 흔함)에도 “판매”를 최종으로 간주하고 배송은 별도로 추적할 수 있습니다. 핵심은: 누군가 결제 페이지에 도달했다고 해서 판매로 표시하지 마세요.

누가 각 상태를 변경할 수 있는지 엄격히 정하세요:

• 체크아웃 시스템은 예약을 생성하고(한도 내에서) 연장할 수 있습니다.
• 결제 확인은 예약을 판매로 전환할 수 있습니다.
• **관리자(Admin)**는 예약을 취소하거나 환불 처리(실제로 재입고할 경우에만 sold -> available로 복원), 새 단위를 받을 때 재고를 수정할 수 있습니다.

마지막으로 상태 변경은 어디에서 보더라도 동일하게 보여야 합니다. 스토어프론트, 관리자 패널, 고객지원 뷰가 동일한 재고 상태 규칙을 읽어야 합니다. 그렇지 않으면 한 곳에서 오버셀을 고쳤다가 다른 곳에서 다시 생깁니다.

체크아웃 중 언제 예약을 생성할까

예약을 언제 만들느냐가 오버셀 빈도와 쇼핑객의 불만에 큰 영향을 줍니다. 너무 일찍 만들면 단순히 둘러보는 사람들을 위해 재고를 묶습니다. 너무 늦으면 같은 마지막 아이템을 두 번 팔게 됩니다.

대부분의 소규모팀에 효과적인 단순 규칙: 쇼퍼가 체크아웃에 확실히 들어갔다고 판단되는 시점에 예약하세요(상품 페이지를 열 때가 아님).

일반적인 옵션(빠른 것부터 늦은 것 순):

• 체크아웃 시작 시(“Checkout” 클릭): 빠르게 팔리는 상품에 적합하지만 만료 시간을 짧게 잡아야 합니다.
• 주소 입력 단계 이후: 가짜 보류를 줄이면서 결제 전 보호를 제공합니다.
• 결제 시작 시(결제 인텐트 생성 또는 결제 제공자 리디렉션 시): 보통 가장 깔끔한 지점입니다. ‘결제 진행 중’은 실제 의사 표현이기 때문입니다.
• 결제 성공 이후: 쇼퍼 경험 측면에선 가장 안전하지만 오버셀 위험이 가장 큽니다.

어떤 시점을 선택하든 각 예약에는 강제할 데 필요한 정보만 저장하세요: 상품(SKU), 수량, 카트 또는 주문 ID, 누가 했는지(세션/사용자), 만료 시간. 지원 대응을 위해 이유나 단계(체크아웃, 결제 등)도 함께 저장하세요.

다중 품목 카트는 한 가지 추가 결정이 필요합니다: 모든 항목을 한꺼번에 예약할 것인지, 항목별로 예약할 것인지. 항목별 예약이 보통 더 안전합니다. 하나의 항목이 품절되면 카트 전체를 블록하지 않고 해당 항목만 해제할 수 있습니다.

보류 사실을 명확한 문구로 보여주세요. "체크아웃을 완료하시는 동안 10분간 이 상품을 보류합니다" 같은 짧은 안내로 충분합니다. 마지막 한 개인 경우에는 "1개 남음. 3:42 PM까지 보류됩니다"처럼 직접적으로 알리세요. 타이머는 도움이 되지만 메시지가 명확하면 필수는 아닙니다.

Koder.ai에서 흐름을 구축하고 있다면 “예약”을 일급 개념(API 호출 + 데이터베이스 행)으로 다루어 UI와 백엔드가 항상 현재 보류 상황에 대해 일치하도록 하세요.

단계별: 재고 예약과 오버셀 방지

소규모팀의 재고 정확성을 원하면 시스템을 단조롭고 예측 가능하게 만드세요. 핵심은 각 숫자가 무엇을 의미하는지 결정하고 한 군데에서만 변경하는 것입니다.

먼저 단일 진실 소스(source of truth)를 선택하세요. 하나의 데이터베이스 테이블이 될 수도 있고 모든 체크아웃이 호출해야 하는 하나의 서비스일 수도 있습니다. 스프레드시트, 관리자 편집, 두 시스템에서의 ‘임시 수정’이 오버셀의 시작점입니다.

대부분의 상점에 유효한 단순 흐름은 다음과 같습니다:

1. 카운트의 진실을 정하세요. 보유(on hand)를 실제 물리적 재고로 추적하세요. 그런 다음 사용 가능(available)을 저장된 숫자로 관리하거나 계산된 값으로 정의하세요: on hand - reserved.
2. 쇼퍼가 커밋할 때 예약을 생성하세요. 결제 버튼을 누르거나 결제 인텐트를 생성할 때 수행하세요. 너무 일찍 예약하면 구매하지 않을 브라우저들을 위해 재고가 잠깁니다.
3. 예약이 생성되면 즉시 가용성을 줄이세요. 사용 가능 숫자를 저장한다면 예약 생성과 같은 트랜잭션에서 감소시키세요. 계산 방식이라면 예약 레코드를 추가하고 수식을 통해 처리하세요.
4. 결제 확인 시 예약을 판매로 전환하세요. 예약을 “판매됨”으로 표시하거나 주문 라인을 생성하고 on hand를 줄이세요. 이 순간이 되면 항목을 되돌릴 수 없다고 처리합니다.
5. 실패나 타임아웃 시 예약을 해제하세요. 결제가 실패하거나 만료되거나 사용자가 페이지를 닫으면 예약을 “해제(released)”로 설정하고 단위를 다시 사용 가능으로 만드세요.

마지막으로 모든 상태 변경을 시간, 이유, ID(카트, 결제, 주문)와 함께 기록하세요. 고객이 “왜 품절이었나요?”라고 물으면 지원팀은 추측이 아닌 명확한 타임라인을 제공해야 합니다. 앱으로 이 흐름을 만든다면(예: Koder.ai 사용) 이 상태와 로그를 일급 데이터로 다루고 UI 라벨이 아닌 데이터로 관리하세요.

결제 타임아웃을 깔끔하게 처리하기

결제 타임아웃은 더 이상 해당 체크아웃이 완료되기를 기다리지 않고 예약된 재고를 사용 가능으로 돌려주는 시점입니다. 일부 쇼퍼는 결제를 완료하지 않으므로 타임아웃이 없으면 예약된 재고가 쌓여 실제 구매자가 차단되거나 수동 정정이 필요해집니다.

타임아웃은 결제 제공자에서 실제로 일어나는 일과 맞춰 결정하세요. 카드 결제는 보통 빠르게 확인되지만 3D Secure, 은행 리디렉트, 지갑 흐름은 더 오래 걸릴 수 있습니다. 너무 짧으면 고객이 결제 중일 때 재고를 해제하게 되고, 너무 길면 이미 떠난 사람을 위해 재고를 묶어 둡니다. 많은 소규모 상점에는 10~20분이 합리적인 시작값이며 로그를 보며 조정하세요.

사용자가 탭을 닫거나 연결이 끊긴 경우에는 아무것도 가정하지 마세요. 결제가 백그라운드에서 성공할 수도 있고 전혀 시작되지 않을 수도 있습니다. 그래서 재고 시스템이 브라우저에 "무슨 일이 일어났나"를 의존해서는 안 됩니다.

정리 작업은 자동으로 만들어 두어 손으로 관리하지 않도록 하세요. 단순한 방법은 만료된 예약을 주기적으로 정리하는 것입니다.

• 예약에 명시적인 expires_at 타임스탬프를 저장하세요.
• 1~5분마다 만료된 예약을 찾는 스케줄 잡을 실행하세요.
• 예약된 수량을 "예약"에서 "사용 가능"으로 이동해 재고를 해제하세요.
• 체크아웃/주문을 "만료됨"으로 표시해 나중에 고객 지원에 참고하게 하세요.
• 만료 횟수를 기록해 타임아웃을 조정하세요.

결제가 만료 이후에 늦게 도착하면 어떻게 할지 미리 결정하세요. 완벽한 답은 없지만 일관된 규칙이 필요합니다. 일반적인 옵션은: 재고가 여전히 있으면 결제를 수락(그렇지 않으면 자동 환불)하거나, 제공자가 진행 중임을 증명할 수 있으면 결제 진행 중인 경우 예약을 연장하는 것입니다.

소규모팀의 재고 정확성 핵심은 타임아웃을 예측 가능하고 자동화하며 가시적으로 만들어 "예약"이 블랙홀처럼 되지 않도록 하는 것입니다.

결제와 재고를 동기화 상태로 유지하기

결제 시스템은 항상 단 하나의 깔끔한 "paid" 메시지를 보내지 않습니다. 같은 확인이 두 번 도착하거나, 웹후크가 지연되거나, 캡처가 고객이 끝났다고 생각한 후 몇 분 뒤에 일어날 수 있습니다. 재고 업데이트가 이런 상황에 대비하지 못하면 같은 단위를 두 번 팔게 됩니다.

가장 단순한 기준은 전체 이야기를 따르는 하나의 주문 ID입니다: 예약, 각 결제 시도, 최종 판매 모두 같은 주문 ID로 연관하세요. 무엇이든 발생하면 먼저 주문 ID를 조회하고 다음 조치를 결정하세요.

소규모팀이 복잡성을 늘리지 않으면서 재고 정확성을 유지하는 몇 가지 규칙은 다음과 같습니다:

• 재고 업데이트를 idempotent하게 만드세요: 같은 "결제 확인" 이벤트가 두 번 처리되면 두 번째는 아무 것도 변경하지 않아야 합니다.
• 주문 ID에 대해 예약을 한 번만 "판매로 전환"으로 표시하세요.
• 고객이 카드를 바꿔 재시도하더라도 모든 결제 시도를 같은 주문 ID 아래에 기록하세요.
• 예약에서 판매로 이동할 때 명확한 최종 결제 결과(승인 및 캡처 등)를 받은 후에만 이동하세요.

idempotent는 반복해도 안전하다는 뜻의 기술 용어일 뿐입니다. 표에 도장을 찍는 것과 같다고 생각하세요: 첫 번째 도장이 중요하고, 두 번째 도장은 영향을 주지 않습니다.

환불과 차지백은 항목을 자동으로 사용 가능으로 되돌려주면 안 됩니다. 이미 발송된 항목이라면 재고는 판매로 유지되고 회계상 환불로 처리하세요. 실제로 반품되어 검수될 때만 재입고하세요.

부분 캡처나 분할 결제의 경우 간단한 정책을 정하세요. 예: 총 캡처 금액이 주문 총액에 도달할 때까지 항목을 예약 상태로 유지하고, 그때 판매로 표시합니다. 고객이 일부만 결제하고 타임아웃되면 다른 실패한 체크아웃과 동일하게 예약을 해제하세요.

오버셀을 유발하는 흔한 실수

대부분 오버셀은 잘못된 수학 때문이 아닙니다. 같은 단어를 다르게 해석하거나 체크아웃의 한 부분이 다른 방식으로 재고를 업데이트할 때 발생합니다. 소규모팀의 재고 정확성 문제는 보통 단순한 수정으로 해결되지만 일관성이 있어야 합니다.

흔한 실수는 너무 일찍 예약하는 것입니다. 상품 페이지를 열거나 카트에 담는 순간 예약하면 단순히 둘러보는 사람들을 위해 재고가 잠깁니다. 예약은 체크아웃 시작이나 결제 세션 생성 등 명확한 의사표시와 연결되어야 합니다.

또 다른 큰 문제는 만료되지 않는 예약입니다. 하루에 몇 건의 포기된 체크아웃만으로도 판매 가능한 재고가 조용히 잠식됩니다. 만료 시간과 그 시점에 자동으로 해제하는 절차가 필요합니다.

자주 나타나는 실수 목록:

• 체크아웃 이전에 재고를 예약해 브라우저가 실제 구매자 대신 재고를 잠금.
• 만료를 설정하지 않아 오래된 예약이 쌓여 사용 가능 수량이 계속 줄어듦.
• 관리자 편집, 일괄 임포트, 반품 등 여러 시스템이 카운트를 변경하면서 상태 전환 규칙이 없음.
• 한 곳에서는 “판매”를 “결제됨”으로, 다른 곳에서는 “발송됨”으로 다르게 처리.
• 예약 해제를 이유 없이 수행해 지원 추적이 불가능.

마지막 항목은 생각보다 중요합니다. 고객이 “결제했는데 품절이에요”라고 말하면 팀은 언제 예약됐고 언제 해제됐으며 그 이유가 결제 타임아웃인지 수동 취소인지 환불인지 답할 수 있어야 합니다.

간단한 습관: 재고가 변경될 때마다 이유와 출처(체크아웃, 관리자, 임포트, 지원)를 기록하세요. Koder.ai로 흐름을 만든다면 데이터 모델에 이러한 이유를 포함시키고 한 곳에서 강제해 모든 기능이 동일한 규칙을 따르게 하세요.

배포 전에 확인할 빠른 체크리스트

새로운 체크아웃 또는 재고 로직을 배포하기 전에 팀 전원이 각 상태가 무엇을 의미하는지 추가 규칙 없이 설명할 수 있어야 합니다. “사용 가능”은 아직 예약될 수 있는 것, “예약”은 만료될 때까지 특정 체크아웃에 약속된 것, “판매”는 결제되어 최종 상태라는 뜻으로 명확히 정의하세요.

단순한 재고 예약 시스템은 시간과 정리에 달려 있습니다. 예약에는 명확한 만료 시간(예: 10-15분)이 있어야 하고, 만료된 보류를 해제해 재고가 사용 가능으로 돌아오도록 잡(job)이나 트리거가 필요합니다.

사전 배포 체크리스트:

• 체크아웃은 카트에 담긴 것만으로 약속하지 않고, 실제로 예약된 항목만 약속하는지 확인하세요.
• 예약 생성이 원자적(atomic)인지 확인해 두 사람이 동시에 마지막 상품을 예약하지 못하게 하세요.
• 결제 확인이 예약을 정확히 한 번만 판매로 변환하는지(재시도와 웹훅에 대한 idempotent 처리)를 검증하세요.
• 예약 만료 후 결제가 늦게 도착하면 어떻게 할지 정의하세요: 수락, 취소, 백오더 처리 등 하나의 규칙을 정하고 일관되게 적용하세요.
• 타임아웃 경로를 종단간(end-to-end) 테스트하세요: 예약 만료, 재고 복원, 고객 메시지 표시.

지원팀에는 추측이 아닌 가시성이 필요합니다. 어떤 주문이든 상태 변경 타임라인과 타임스탬프를 볼 수 있어야 분쟁 처리가 쉬워집니다.

지원 타임라인은 세 가지 질문에 답해야 합니다

• 예약은 언제 생성되었고 언제 만료되었나?
• 결제는 언제 성공하거나 실패했고, 만료 이전이었나 이후였나?
• 재고는 언제 해제되거나 판매로 전환되었고, 어떤 시스템 이벤트에 의해 발생했나?

Koder.ai 같은 코드 제너레이터나 바이브 코딩 플랫폼에서 이 로직을 구현한다면 먼저 규칙을 문서화하고 명시적인 상태와 이벤트로 구현하세요. 엣지케이스가 나중에 숨어들지 않게 합니다.

예시: 두 명의 고객, 마지막 한 개

인기 상품이 1개 남아 있습니다. 두 쇼퍼가 거의 동시에 체크아웃을 시도합니다.

12:00:00 - 상점은 사용 가능: 1, 예약: 0, 판매: 0을 표시합니다.

12:00:05 - 쇼퍼 A가 “결제”를 클릭합니다. 시스템은 10분간 지속되는 1개 예약을 만듭니다. 이제 상품 페이지는 사실상 사용 가능: 0을 표시하고 백오피스는 예약: 1을 표시합니다.

12:00:20 - 쇼퍼 B가 같은 상품을 카트에 넣고 체크아웃으로 갑니다.

• 쇼퍼 B가 보는 것: “품절” 또는 “지금은 구매 불가”.
• 지원/관리자가 보는 것: 사용 가능 0, 예약 1(쇼퍼 A를 위해 보류), 판매 0.

12:03:10 - 쇼퍼 A 결제 성공.

예약을 판매로 전환합니다:

• 판매가 1로 증가합니다.
• 예약은 0으로 감소합니다.
• 물리적 재고가 없으므로 사용 가능은 0입니다.

이제 수치는 사용 가능: 0, 예약: 0, 판매: 1입니다. 쇼퍼 A는 주문 확인을 받습니다. 쇼퍼 B는 여전히 구매할 수 없습니다.

다른 결말: 결제 타임아웃

같은 시작인데 쇼퍼 A가 결제를 완료하지 않습니다.

12:10:05 - 예약 만료(타임아웃). 재고를 해제합니다.

• 수치는 사용 가능: 1, 예약: 0, 판매: 0가 됩니다.
• 쇼퍼 B가 이제 체크아웃할 수 있고 B에 대해 새 예약을 생성할 수 있습니다.

변형: 만료 이후 결제 성공

결제 제공자가 지연되어 늦게 성공을 보고하는 경우가 있습니다.

규칙은 단순해야 합니다: 예약이 만료되면 부활시킬 수 없습니다. 그래서 만료 후 늦게 "성공" 알림이 오면 다음 중 하나를 하세요:

• 만료된 예약이면 판매로 표시하지 마세요. 주문을 "검토 필요"로 두고 환불하거나 재주문을 요청하세요.
• 새 예약이 이미 쇼퍼 B에 대해 존재하면 B가 우선권을 가집니다.

이 단일 규칙이 오버셀을 방지하고 지원 결과를 예측 가능하게 만듭니다.

다음 단계: 규칙을 단순한 시스템으로 전환하기

소규모팀의 재고 정확성은 모두가 같은 용어를 같은 의미로 쓸 때 훨씬 쉬워집니다. 사용 가능, 예약, 판매의 정의를 한 곳에 적어 두고 고객에게 보이는 것, 지원팀이 말하는 것, 관리자 화면이 모두 일치하도록 하세요.

정책은 짧고 명확하게 유지하세요: 예약이 언제 생성되는지(예: 체크아웃 시작 시 또는 결제 시작 시)와 얼마 동안 재고를 보류할지 정확히 정하세요. 만료 규칙과 만료 후 고객이 돌아왔을 때 어떻게 처리할지도 평이한 문장으로 적어두세요.

체크아웃을 변경하기 전에 상태와 전환을 스케치하세요. 각 이벤트가 재고에 무엇을 하는지 가리킬 수 있어야 합니다.

단순하고 실용적인 기본

대부분 팀은 다음 다섯 가지 동작을 기본 골격으로 잘 운영합니다:

• Reserve: 특정 카트나 주문에 대해 보류 생성
• Release: 고객 취소나 타임아웃 시 보류 해제
• Convert to sold: 결제 확인 시 예약을 최종화
• Fail safely: 확실하지 않으면 판매로 표시하지 않기
• Reconcile: 드문 불일치를 수동 또는 예약 검사로 수정

드물게 생기는 엣지케이스를 추적할 수 있도록 관찰성을 추가하세요. 모든 reserve, release, convert-to-sold 이벤트를 주문 ID, 이유(타임아웃, 취소, 결제 성공), 타임스탬프, 전후 수량과 함께 기록하세요.

빠르게 만들고, 그다음 단단히 다지기

이 흐름을 빠르게 프로토타입하거나 조정해야 한다면 Koder.ai가 상태를 채팅에서 매핑하고 예약 및 타임아웃 로직을 생성하며 배포용 소스 코드를 내보내는 데 도움을 줄 수 있습니다. 중요한 건 멋진 도구가 아니라 규칙을 명확하고 일관되게 정하고 체크아웃이 재고에 닿는 모든 곳에서 이를 강제하는 것입니다.