스마트스토어와 쿠팡 재고를 따로 고치고 있다면

원재고 하나를 두 판매 채널에 반영한 사례다

스마트스토어의 수량을 바꾸고 쿠팡에서도 같은 상품을 찾아 수정한다. 옵션이 바뀌거나 세트가 추가되면 어느 판매 페이지에 어떤 원상품이 연결됐는지 다시 확인한다. 상품이 늘수록 반복 클릭보다 서로 다른 화면의 수량이 맞는지 파악하는 일이 커진다.

지피터스에 사례를 올린 박정기는 위탁배송 기반으로 스마트스토어와 쿠팡을 함께 운영하면서 상품이 700개 이상이고 옵션·조합을 합치면 관리 대상이 수만 개였다고 밝혔다. 기존 Google Sheets와 DB의 원재고를 n8n으로 모아 판매 단위로 바꾸고 두 채널 API에 수량과 판매 상태를 반영했다. 700개는 작성자가 밝힌 운영 규모다. 지피터스 재고 자동화 사례

공개된 흐름에서 Claude Code의 역할은 재고 계산, 데이터 변환, 예외 처리 코드 구현이다. n8n은 수집·집계·분기·API 호출을 담당했다. 도입 설계에서도 규칙을 만드는 작업과 정해진 계산을 실행하는 작업을 구분해야 한다.

박정기는 데이터 구조를 파악하는 데 시간이 많이 들었고 DB 테이블을 다시 설계하는 편이 장기적으로 효율적이었다고 설명했다. 실제 도입팀이 가져올 논점도 여기 있다. 버튼을 눌러주는 자동화부터 만들기보다, 어느 데이터가 기준이고 어느 상품에 연결되는지 먼저 확정해야 한다.

상품명이 같아도 같은 재고로 처리하면 안 된다

복수 채널을 연결할 때는 사람이 알아보는 상품명과 시스템이 사용하는 식별자를 나눠야 한다. 이름은 상품 설명을 바꾸면서 수정될 수 있고, 같은 상품에도 채널별 등록 번호와 옵션 번호가 붙는다. 상품명만 비교해 수량을 쓰면 다른 색상이나 묶음에 반영할 위험이 있다.

도입 설계에서는 내부 상품 코드와 원재고 코드, 판매 단위, 채널별 상품·옵션 ID를 하나의 매핑표에 둔다. 단품 한 개와 세 개 묶음은 같은 원재고를 쓰더라도 다른 판매 단위다. 옵션명에 수량이 적혀 있다는 이유로 문자열에서 숫자를 읽어 바로 계산하지 않고, 판매 단위를 별도 값으로 저장한다.

아래는 매핑을 준비할 때 쓸 예시 양식이다. 실제 ID와 규칙은 각 판매자의 상품 구조에 맞게 채운다. 매핑을 찾을 수 없는 상품은 유사한 이름의 상품에 임의로 연결하지 않고 검토 대상으로 남긴다.

네이버 상품 목록 조회에는 원상품·채널 상품 번호, 판매자 관리 코드, 재고 수량과 판매 상태가 구분돼 있다. 쿠팡 상품 API에는 아이템별 수량 변경과 수량·가격·상태 조회가 별도 경로로 있다. 두 채널의 필드 이름이 비슷하다고 같은 요청을 그대로 보내기보다, 각 채널의 식별자와 상태를 변환해야 한다. 네이버 상품 조회, 쿠팡 상품 API

매핑표는 처음 한 번 만들고 끝나는 자료가 아니다. 옵션을 추가하거나 세트를 바꿀 때 갱신하지 않으면 이전 구성이 계속 계산에 쓰인다. 상품 등록 담당자가 변경한 판매 단위를 재고 담당자에게 전달하는 절차를 두고, 매핑이 없는 신규 상품은 자동 반영을 시작하기 전에 확인한다.

원재고가 같아도 채널에 표시할 수량은 따로 계산한다

아래 계산은 도입팀이 규칙을 설명할 때 사용할 가정 예시다. 원상품 A의 가용 재고가 12개이고, 판매하는 묶음이 A 3개로 구성된다면 만들 수 있는 묶음은 4개다. AI가 문장을 잘 이해했는지보다 단위와 나눗셈, 정수 처리 규칙이 맞는지를 확인해야 한다.

A와 B를 한 개씩 쓰는 세트라면 두 재고 가운데 세트를 더 적게 만들 수 있는 쪽이 제한이 된다. A가 12개이고 B가 5개라는 가정에서는 이 세트를 5개 만들 수 있다. A가 많다는 이유로 세트 재고를 12개로 표시하면 B가 부족한 주문을 받게 된다.

여기서 계산이 끝나지는 않는다. A를 단품으로도 팔고 여러 세트에서도 사용하면 각 판매 페이지가 같은 원재고를 공유한다. 스마트스토어와 쿠팡에 A의 전체 가용 수량을 동시에 표시할 때는 주문이 겹쳤을 때 차감과 반영이 어떻게 이어지는지 정해야 한다. 채널에 넣은 숫자의 합과 실제 보유 수량을 혼동하면 안 된다.

도입팀은 가용 재고에 어떤 값이 포함되는지부터 정한다. 실재고, 이미 주문된 물량, 출고 준비로 잡아둔 물량, 검수 중인 반품, 공급처에서 확인한 수량을 같은 의미로 쓰면 계산 결과가 달라진다. 아직 팔 수 없는 재고는 판매 가능 수량과 별도로 기록해야 한다.

위탁배송은 공급처 수량의 시점도 중요하다. 공급처가 새 자료를 보내지 않았다는 사실과 재고가 0개라는 사실은 다르다. 빈 값을 0으로 바꾸거나 지난 수량을 무조건 유지하는 대신, 자료가 늦었을 때 판매를 유지할지 보류할지 업무 규칙을 정한다. 그 판단을 매번 AI의 답변에 맡기면 같은 상황에서 처리가 달라질 수 있다.

판매자가 정할 배분 규칙에는 채널별 보유분을 따로 둘지, 공통 재고에서 주문을 차감할지, 안전 수량을 남길지가 포함된다. 어느 방식이든 수량 변경의 근거를 남겨야 한다. 담당자가 0으로 만든 상품을 다음 자동 실행이 다시 판매 중으로 바꾸지 않도록 수동 보류 상태도 계산에 반영한다.

업무 규칙은 사람이 정하고 AI는 구현을 지원한다

재고 자동화에서 사람이 정해야 하는 것은 수량의 의미다. 반품을 언제 가용 재고로 넣는지, 입고 취소가 어떤 수량을 되돌리는지, 공급처 자료가 오래됐을 때 판매를 유지하는지는 현장의 업무에 따라 결정된다. AI에 코드 작성을 맡겨도 이 조건은 판매자가 설명해야 한다.

다른 지피터스 사용자 나츠v는 발주 흐름은 사람이 정의하고, 창고 재고 유무에 따른 분기는 자동화하며, AI는 그 규칙을 DB와 화면으로 구현하는 방식으로 역할을 나눴다. 입고 검수 뒤 항목별 취소와 재고 되돌리기도 현장의 예외를 먼저 설명한 기능이었다. 사람·AI·자동화 역할 사례

실제 도입에서는 이 구분을 명세로 남기는 편이 좋다. 입력 필드, 단위, 계산식, 허용 범위, 빈 값 처리, 실패 시 행동을 적고 정상·예외 입력을 붙인다. AI가 만든 구현을 같은 입력으로 실행해 원하는 결과가 나오는지 확인한다. 숫자를 바꾸는 로직은 말로 그럴듯하게 설명하는 것보다 실행 결과를 비교하는 쪽이 명확하다.

규칙이 바뀌면 코드와 사례 입력을 함께 바꾼다. 세트의 구성 개수가 달라졌는데 설명 문서만 고치면 예전 계산이 계속 실행된다. 반대로 코드만 바꾸면 담당자가 판매 수량이 달라진 이유를 알기 어렵다. 변경 날짜와 담당자, 바뀐 조건을 기록하면 이후 수량 차이를 추적할 수 있다.

AI의 도움을 받는 위치도 구분한다. 채널 문서의 필드를 읽어 변환 코드를 만들고 오류 기록을 해석하는 데는 쓸 수 있다. 판매 가능 수량을 확정하는 운영 경로에는 검증된 계산을 두고, 코드 수정은 별도 검토와 시험을 거쳐 반영한다. 실행 중 오류가 났다는 이유로 AI가 규칙을 즉석에서 바꾸도록 연결하지 않는다.

한 채널만 실패한 상태를 완료로 묶으면 안 된다

두 채널의 재고를 바꾸는 작업은 동시에 성공하지 않을 수 있다. 스마트스토어에는 새 값이 들어갔지만 쿠팡 요청은 실패할 수 있고, 응답이 늦어 성공 여부를 아직 모르는 요청도 생긴다. 도입 설계에서는 전체 작업의 완료 표시와 채널별 반영 결과를 구분해야 한다.

API 호출에는 서비스별 빈도 제한이 있다. n8n 공식 문서는 429 응답을 호출 제한 오류로 설명하며, 재시도 사이의 대기와 배치 처리를 제공한다. 요청을 더 자주 보내는 것으로 해결하지 않고 각 채널의 제한에 맞춰 속도를 조절해야 한다. n8n 호출 제한 처리

재시도는 실패했던 숫자를 그대로 여러 번 쓰는 기능으로만 만들면 부족하다. 대기하는 동안 새 주문이나 수동 보류가 생길 수 있으므로 재처리 시점의 원재고와 채널 상태를 다시 확인한다. 예전 실행이 나중에 끝나서 최신 수량을 덮어쓰지 않게 실행 순서와 기준 시점도 관리해야 한다.

수량을 새 값으로 설정하는 작업과 일정 수량을 차감하는 작업은 재실행 결과가 다르다. 차감 요청을 중복 처리하면 재고가 두 번 줄어들 수 있다. 주문이나 재고 변경 사건의 식별자를 남기고 이미 처리한 변경인지 확인해야 한다. 자동 재시도 설정만 켰다고 중복 처리가 해결되는 것은 아니다.

사람이 개입할 때는 실패 목록에서 대상 상품과 채널, 마지막 기준 수량, 오류 내용을 볼 수 있어야 한다. 수동 수정 후에는 그 값을 기준 자료에도 반영하거나 보류 사유를 남긴다. 판매자 화면만 고쳐두면 다음 실행이 같은 값을 다시 덮어쓰면서 두 사람이 서로 수정하는 상태가 된다.

재고 정합성과 상품 등록 품질은 따로 검사한다

상품을 올리는 자동화와 재고를 맞추는 자동화는 검사 대상이 다르다. 상품 등록에서는 제목·태그·이미지·옵션 구성이 중요하고, 재고에서는 원재고·판매 단위·채널 수량·판매 상태가 맞아야 한다. 한 검사 결과로 다른 작업의 정확성을 대신할 수 없다.

쿠팡 상품 생성 문서도 최초 등록 때의 수량 입력과 승인 이후 옵션별 수량 변경을 구분한다. 이미 팔고 있는 상품의 재고를 바꿀 때는 등록 요청을 다시 보내는 일과 구분해서 설계해야 한다. 쿠팡 상품 생성과 재고 변경

Threads의 chammo.log는 상품명 절단과 태그·추가 이미지 누락에도 자동 검증은 통과한 상품 등록 실패를 기록했다. 이는 재고 수량이 어긋난 사례와는 다른 문제다. 등록 자동화에서는 실제 페이지 내용을 보고, 재고 자동화에서는 실제 채널 수량을 되읽어 기준 값과 비교해야 한다. 상품 등록 실패 기록

API 계정 연동 없이 주문 엑셀만 쓰는 시트를 소개한 사례도 있다. 이 방식은 주문 정리 범위를 좁힐 수 있지만, 내려받은 자료의 시점 이후 변동을 자동으로 안다는 뜻은 아니다. 엑셀 기반으로 시작하는 판매자라면 어떤 자료를 언제 갱신하고 어느 화면의 수정은 사람이 맡는지 명시해야 한다. 주문 엑셀 기반 시트 사례

도입 전에는 단품·세트·품절·매핑 누락·한 채널 실패를 포함한 상품으로 시험한다. 계산 결과와 API 요청, 실제 판매자 화면을 차례로 비교한다. 작은 범위에서 원재고가 어디서 바뀌고 채널 반영은 어디서 실패하는지 확인한 뒤 상품군을 넓히면 원인을 찾기 쉽다.

스마트스토어와 쿠팡을 따로 고치는 일을 줄이려면 원재고의 기준과 상품 매핑부터 하나로 연결해야 한다. 그 위에 검증한 계산과 채널별 반영, 부분 실패 복구를 붙인다. AI가 구현을 도울수록 판매자는 어떤 숫자를 기준으로 팔고 있는지 설명할 수 있어야 한다.

자주 묻는 질문