식별자부터 어긋나면 무엇이 무너지나

연동 사고의 뿌리는 대개 코드 체계입니다. 채널마다 상품을 부르는 이름이 다른데, 사내에서는 그것을 하나의 SKU로 부르고 있기 때문입니다.

구글 머천트 센터 상품 데이터 사양의 조건부 필수 속성을 보면 구조가 드러납니다. brand는 영화·도서·음악을 제외한 모든 신상품에 필수, gtin은 제조사가 부여한 경우 필수(UPC·EAN·ISBN·ITF-14 등), mpn은 제조사 부여 GTIN이 없는 상품에만 필수, condition은 중고·리퍼 상품에만 필수, shipping은 대한민국을 포함한 해당 국가에서 필수, availability_date는 availability를 preorder로 둔 경우 필수입니다. 필드 이름과 필수 여부가 채널마다 다르다는 사실 자체가 매핑 테이블이 필요한 이유입니다.

표준 코드 쪽도 보면, 한국의 GS1 표준 관리기관은 대한상공회의소 유통물류진흥원이고 GTIN은 상품을 판매단위별로 식별하는 고유번호로 자릿수에 따라 GTIN-8·13·14로 구분되는 것으로 정리됩니다. 다만 공식 안내 페이지 본문을 이번 조사에서 확보하지 못해 검색 결과 요약 기준이므로, 실제 코드 발급과 구조는 GS1 Korea 회원 안내로 재확인해야 합니다.

실무 결론은 단순합니다. 사내 SKU, 채널별 상품코드, 제조사 부여 식별자를 각각 별도 열로 두는 매핑 테이블을 먼저 만들고, 그다음에 솔루션을 붙입니다. 옵션이 있는 상품은 옵션 단위까지 이 테이블에 내려와야 합니다.

필드 규격은 어디서 조용히 깨지나

두 번째 지점은 형식입니다. 형식 오류는 전체가 멈추는 방식이 아니라 일부 상품만 소리 없이 빠지는 방식으로 나타납니다.

네이버 쇼핑 상품정보 수신 가이드는 EP 파일에서 배송비 필드를 반드시 정수로 표기하도록 하고, 텍스트로 표기되면 에러 처리된다고 명시합니다. 제어문자·공백문자·프로그래밍 언어 코드가 포함되면 EP 수신 시스템 오류가 발생하므로 사용이 금지됩니다. 상세페이지에서 복사해 온 문자열이 그대로 들어가면서 이런 오류가 생기는 경우가 많습니다.

광고 채널도 같습니다. 메타 카탈로그의 availability 필드는 in stock, out of stock, available for order 같은 정해진 값만 허용하고, 이 값이 실제 재고 상태와 다르면 품절 상품이 광고에 계속 노출되는 오류가 생깁니다. 피드 형식은 CSV, TSV, XML(RSS/ATOM), 엑셀, 구글 시트가 지원되는데, CSV·TSV는 수동 업로드나 시트 연동에, XML은 자동화된 사이트 익스포트에 적합합니다. 수동 업로드 형식으로 운영하면 갱신 주기가 사람 손에 묶인다는 점을 도입 시점에 정해둬야 합니다.

갱신 주기와 상태 시각은 왜 따로 봐야 하나

연동 솔루션이 아무리 빨라도 채널이 읽어가는 주기가 상한입니다. EP는 쇼핑몰의 상품 구성정보로 만들어진 파일이고 네이버 쇼핑이 그 URL을 주기적으로 읽어 상품 데이터베이스를 동기화하는 구조이며, 연동 대행 서비스 가이드는 기본 수집 주기를 하루 4회(01시, 10시, 14시, 18시)로 안내합니다. 이는 네이버 공식 원문이 아닌 2차 자료 기준이라 자기 계정 기준은 파트너센터에서 확인해야 합니다. 메타 피드는 최소 24시간 1회 갱신이 요구되고 매시간 수집이 선택지로 제공됩니다.

그리고 요건은 수량이 아니라 시각입니다. EP 상품정보 송신에서는 개별 상품별로 신규 등록·수정·품절·품절복구가 발생한 시각 정보가 정확히 전달돼야 재고 상태가 실시간에 가깝게 동기화됩니다. 솔루션을 검토할 때 "몇 분마다 동기화하나"만 묻고 "상태 변경 시각을 어떻게 기록해 넘기나"를 묻지 않으면, 도입 후에도 같은 사고가 납니다.

도입 전 대조는 어떤 순서로 하나

점검 절차는 새로 만들 필요가 없습니다. 측정 감사 실무 체크리스트의 공통 항목이 그대로 쓰입니다. 사이트 전체 트래킹 코드 매핑, 집계 데이터와 CRM·주문 데이터 대조를 통한 오차율 산출, 모든 전환 이벤트에 고유 거래 ID 부여, 중복제거 설정 확인, 분기 단위 정기 감사입니다.

이걸 재고·주문 연동으로 옮기면 다섯 줄이 됩니다. 첫째, 채널별 상품·옵션 코드를 사내 SKU에 매핑한 표를 만듭니다. 둘째, 모든 주문에 채널을 포함한 고유 주문 ID를 부여합니다. 셋째, 한 주 동안 채널 판매자센터 집계와 내부 주문 건수를 날짜별로 대조해 오차율을 냅니다. 넷째, 중복 수신과 누락 수신을 각각 세어 유형을 나눕니다. 다섯째, 이 대조를 분기마다 반복합니다.

오차가 어느 정도면 문제인지에 대한 국내 공식 기준은 없습니다. 참고할 만한 인접 사실은 제휴 추적 맥락의 것으로, 제휴사 네트워크 집계 전환 수와 사업자 내부 주문 수가 5~10% 이상 차이 나는 것이 추적 시스템 문제의 뚜렷한 신호로 꼽힌다는 정리가 있습니다. 이는 제휴 추적 기준값이지 재고·주문 대조의 표준이 아니므로, 자사 4주 데이터로 평상시 오차 범위를 먼저 잡아두고 그 범위를 벗어난 날을 조사 대상으로 삼는 편이 맞습니다.

취소·반품은 언제 숫자에 반영되나

마지막 정합성 이슈는 시점입니다. 국내 커머스 플랫폼의 정산액은 결제액에서 판매수수료 등 각종 수수료와 취소·반품분을 뺀 금액으로 확정됩니다. 즉 주문 시점의 숫자와 정산 시점의 숫자가 다릅니다.

리포팅에서도 같은 문제가 생깁니다. 전환 지연 때문에 최근 며칠 데이터는 계속 채워지므로, 일정 일수 이내 데이터로는 최종 결정을 하지 않는 버퍼 정책이 권장됩니다. 커머스는 반품·구매확정 지연 때문에 확정이 더 늦으므로 채널별 정산 확정 시점을 버퍼에 반영해야 합니다. 연동이 어긋나 팔리지 않은 채 쌓인 재고는 결국 재고자산 평가에서 드러납니다.