재고 연동이 꼬이지 않는 상품 식별 체계 설계법
판매처가 늘어나면 동일한 제품도 관리자 화면마다 이름과 선택 항목과 수량이 다르게 나타납니다. 이 차이를 그대로 둔 채 자동화를 붙이면 하나의 품목이 여러 재고로 인식될 수 있습니다. 연결 기능보다 식별 체계를 먼저 확인해야 합니다. ## 1단계. 판매처별 품목을 한곳에 정리하기 각 채널의 제품과 선택 항목을 한 표로 합치고 중지와 예약과 세트 상품도 포

판매처가 늘어나면 동일한 제품도 관리자 화면마다 이름과 선택 항목과 수량이 다르게 나타납니다. 이 차이를 그대로 둔 채 자동화를 붙이면 하나의 품목이 여러 재고로 인식될 수 있습니다. 연결 기능보다 식별 체계를 먼저 확인해야 합니다.
1단계. 판매처별 품목을 한곳에 정리하기
각 채널의 제품과 선택 항목을 한 표로 합치고 중지와 예약과 세트 상품도 포함합니다. 기존 판매처 번호는 유지하고 별도의 열에 사내 표준 코드를 입력합니다. 수량을 실제로 변경하는 시스템도 함께 표시합니다.
2단계. 공통 식별 코드 정하기
제품 이름은 프로모션이나 노출 전략에 따라 자주 달라집니다. 따라서 이름 대신 계속 유지할 수 있는 사내 코드를 만들고 각 판매처의 번호를 매핑해야 합니다.
제품을 구분하는 대표 식별값
선택 항목별 수량 관리 코드
판매처에서 발급한 품목 번호
공급처 정보와 현재 판매 여부
수정 담당자와 변경 기록
식별값은 알아보기 쉽고 서로 겹치지 않아야 합니다.
3단계. 선택 항목의 기준 통일하기
어떤 판매처는 색상과 크기를 나눠 등록하고 다른 곳은 두 값을 합친 조합으로 관리할 수 있습니다. 표기 방식이나 공백이 조금만 달라도 시스템에서는 별개의 수량으로 판단할 수 있습니다. 먼저 색상과 규격과 추가 구성 같은 분류 축을 정의합니다. 이후 출고 가능한 모든 조합에 각각 독립된 재고 코드를 배정합니다.
> 수량을 묶는 기준은 화면의 상품명이 아니라 창고에서 나가는 최소 선택 단위여야 합니다.
4단계. 수량의 원본 시스템 선택하기
두 곳 이상에서 수량을 직접 고치면 늦게 저장된 값이 이전 변경을 덮어쓸 수 있습니다. 사내 운영 시스템이나 중심 판매처 중 한 곳을 재고 원본으로 지정해야 합니다. 나머지 채널은 기준값을 전달받고 수동 수정은 권한과 이력을 남깁니다.
5단계. 주문 상태별 증감 규칙 연결하기
수량은 결제가 발생한 순간에만 변하지 않습니다. 입금 전과 결제 후와 주문 취소와 배송 처리와 반품 입고에 따라 가용 수량이 달라집니다. 어느 단계에서 물량을 확보할지와 어느 조건에서 복구할지를 운영 기준으로 합의합니다. 처리 실패나 일부 취소가 발생해도 동일한 변화가 반복 적용되지 않도록 각 작업의 고유 번호를 저장합니다.
6단계. 연결 오류를 관리자에게 보여주기
외부 판매처와의 통신은 인증 정보 만료나 요청 횟수 제한 때문에 중단될 수 있습니다. 운영 화면에서 최근 정상 반영 시점과 오류가 난 채널과 재처리 결과를 확인할 수 있어야 합니다. 기준 수량과의 차이가 허용 범위를 벗어나면 알림을 보내거나 해당 품목의 판매를 잠시 막는 선택지도 필요합니다.
7단계. 대표 품목으로 사전 검증하기
처음부터 전체 목록을 전환하지 말고 주문이 꾸준한 품목과 선택 조합이 많은 품목을 골라 제한된 범위에서 시험합니다. 테스트 주문과 취소와 반품을 만들어 각 채널의 결과 수량을 대조합니다. 표준 코드가 비어 있거나 하나의 코드가 중복된 항목은 정식 연결을 시작하기 전에 분리해 수정합니다.
> 제한된 품목으로 전체 흐름을 확인하면 전면 적용 과정에서 발생할 수 있는 수량 오류를 미리 발견할 수 있습니다.
핵심 요약
판매처 고유 번호와 사내 표준 식별값을 따로 관리하기
출고 가능한 각 선택 조합에 독립된 재고 코드 부여하기
수량의 원본이 되는 관리 시스템을 하나만 지정하기
결제와 취소와 반품에 따른 반영 조건을 명확히 정하기
오류 채널과 최근 정상 처리 시점을 관리 화면에서 확인하기
다채널 재고 관리의 안정성은 연결 기능보다 기준 데이터의 품질에서 시작됩니다. 식별 코드와 선택 항목과 주문 상태의 규칙이 먼저 정리되어야 이후 자동화도 예측 가능한 방식으로 움직입니다. 판매처가 늘어나도 같은 기준표를 확장할 수 있습니다.
[CodeLune 프로젝트 사례 확인하기](https://codelune.dev/ko/portfolio)
관련 글
- [쇼핑몰개발] 결제 이후가 흔들리지 않는 주문 상태 설계 7가지 기준쇼핑몰을 기획할 때 결제 뒤 주문 처리 단계가 빠지기 쉽습니다. 이 간격이 남으면 고객은 주문이 끝났다고 여기지만 운영팀은 아직 검토할 일로 판단합니다. 같은 주문을 서로 다르게 해석하는 순간 문의와 취소가 쌓이기 시작합니다. 주문 단계는 단순한 화면 표시가 아닙니다. 결제 확인과 재고 관리와 출고 절차를 한 흐름으로 잇는 운영 규칙입니다. 구현 전에 맞
- 주문 이후가 더 어렵다 취소 교환 환불 시스템 설계쇼핑몰 구축에서 놓치기 쉬운 부분은 주문 버튼 다음입니다. 판매 화면은 잘 동작해도 취소나 교환이 시작되는 순간 재고와 결제와 배송 상태가 따로 움직이면 운영자는 수기로 맞춰야 합니다. 판매량이 늘수록 작은 불일치가 고객 문의와 정산 오류로 번집니다. 취소와 교환과 환불은 하나의 기능 이름으로 묶여 있지만 실제로는 다른 업무입니다. 개발 착수 전에 다음
- 결제 뒤 혼선을 줄이는 쇼핑몰 배송 정책 설계 7단계온라인 상점을 준비할 때 배송 조건은 결제 화면보다 먼저 설계해야 합니다. CodeLune에서는 쇼핑몰 프로젝트를 검토할 때 작은 기준 하나가 주문 취소와 상담 증가로 이어지는 경우를 자주 봅니다. 구현 전에 계산 원칙을 문서로 고정해야 고객과 운영자가 같은 결과를 확인할 수 있습니다. ## 1단계. 배송비 면제선을 금액으로 확정하기 면제 운임이 시작되는