쇼핑몰 상품코드 매핑 개발: 채널별 옵션과 대시보드 집계 기준

쇼핑몰 상품코드 매핑 개발은 채널의 상품·옵션 식별자를 내부 품목과 연결하고, 연결할 수 없는 판매 수량을 별도로 보여주는 일부터 시작합니다. 원본 코드와 매핑 버전을 보존해 채널별 주문 수량과 품목별 집계가 같은 기준에서 맞는지 검수하세요. 대시보드 조회와 재고 차감·주문 전송은 별도 범위입니다.

자사몰에서는 파란색 셔츠 M을 BLUE-M으로, 다른 판매 채널에서는 1024-07이라는 옵션 번호로 관리한다고 가정합니다. 이름이 달라도 같은 실물 품목일 수 있고 이름이 같아도 포장 수량이 다를 수 있습니다. 두 채널의 숫자를 합치기 전에 어떤 값을 같은 품목으로 볼지 담당자가 결정해야 합니다. 이 글의 코드와 수량은 설명을 위한 가상 사례입니다.

운영 담당자가 채널 관리자의 주문 파일을 내려받아 품목별 수량을 맞추는 소규모 팀을 생각해 보세요. 매일 파일을 합치는 시간이 들더라도 기존 보고서나 스프레드시트로 매핑표를 관리할 수 있다면 그 방식이 먼저일 수 있습니다. 채널이 늘면서 담당자별 표가 달라지고 누락 여부를 설명하기 어렵다면 조회 전용 대시보드 구축 범위를 검토합니다.

여기서 판매 수량은 정해진 조회 기간에 들어온 유효 주문행의 상품 수량을 뜻합니다. 실제 재고, 매출액, 출고 완료 건수와 같은 값이 아닙니다. 취소나 교환을 제외할지, 주문일과 결제일 중 어떤 기준일을 쓸지 먼저 합의해야 같은 기간을 비교할 수 있습니다. 대시보드가 값을 읽는다고 채널의 주문 상태나 ERP 원장을 수정하는 것은 아닙니다.

구매 담당자는 개발업체에 원천 파일과 예상 화면 한 장만 주기보다, 채널 계정·상품번호·옵션번호·내부 품목코드가 함께 있는 비식별 표본과 예외 목록을 전달하는 편이 좋습니다. 원천의 실제 API와 파일에서 어떤 필드를 받을 수 있는지, 자료 사용 권한과 갱신 주기는 채널별로 확인합니다. 이 글의 매핑 방법은 특정 채널과의 호환성이나 실시간 연동을 보장하지 않습니다.

공식 자료를 어디까지 참고할 수 있나요?#

Google Merchant Center 안내는 같은 상품의 변형을 묶는 item group ID와 개별 상품 ID를 구분하고, 색상·크기 같은 변형 속성의 관리 방법을 설명합니다. 이는 Google에 제출하는 상품 데이터의 규칙이므로 모든 국내 판매 채널의 옵션 키나 재고 처리 규칙이 같다는 뜻은 아닙니다. GS1 문서는 거래 상품 식별에 관한 기준을 제공합니다. 각 채널의 API·파일 계약과 기업 내부 품목 정의가 우선 확인 대상이며, 아래 표와 예외 처리는 이 글의 설계 제안입니다.

• Google Merchant Center: Local product data specification: 개별 상품 ID와 변형 상품 그룹 ID의 구분을 참고합니다. Google 상품 데이터에 관한 안내입니다.
• Google Merchant Center: Item group ID: 상품 변형을 하나의 그룹으로 설명하는 기준입니다. 타 채널의 필수 속성으로 일반화하지 않습니다.
• GS1: Can a GTIN be reused?: 상품 식별자 재사용에 관한 GS1 기준입니다. 회사 내부 SKU를 GTIN과 동일시하지 않습니다.

매핑표를 누가 관리하고 어떻게 복구할까요?#

원천 값을 수집한 사람, 내부 품목을 관리하는 사람, 매핑을 승인하는 사람이 다를 수 있습니다. 채널 담당자는 원천 상품·옵션을 확인하고 상품 담당자는 내부 코드와 판매 단위를 검토합니다. 운영 책임자는 변경 전후의 영향 기간과 예외 건수를 보고 승인합니다. 개발사는 승인 절차와 이력을 구현하는 역할을 맡을 수 있지만 실제 상품의 정체성을 혼자 확정해서는 안 됩니다.

권한은 조회, 후보 제안, 승인과 과거 재집계로 나눕니다. 협력사나 외부 운영자가 모든 상품과 판매 데이터를 볼 필요가 없다면 채널과 계정별 접근 범위를 별도로 제한합니다. 원천 조회용 자격증명은 필요한 읽기 권한과 보관 위치를 계약에서 확인합니다. 관리자 화면에서 매핑 승인 버튼을 누를 수 있다는 사실이 채널 상품을 수정할 수 있다는 뜻은 아닙니다.

매핑표에는 적용 시작과 종료 시점, 제안자, 승인자, 승인 사유와 변경 전후의 값을 남깁니다. 채널이 옵션을 변경한 날과 데이터가 수집된 날이 다를 수 있으므로 어느 시점을 유효일로 쓸지는 원천의 제공 값과 업무 기준으로 정합니다. 늦게 도착한 주문은 최신 매핑을 무조건 적용하지 않고 해당 주문의 기준 시점과 적용할 표의 버전을 확인합니다.

상품명이 같아 자동 후보가 나와도 승인된 연결이 아닙니다. 색상 표기, 크기, 판매 구성과 단위가 다른 후보는 보류합니다. 충돌이 해소되기 전까지 원천 주문행과 판매 수량을 대기 화면에서 확인할 수 있어야 합니다. 담당자가 바뀌어도 왜 보류했는지 찾을 수 있도록 확인 사유와 다음 확인 담당자를 남깁니다.

승인 후 잘못 연결한 사실을 발견하면 적용 범위를 정지하고 변경 전 매핑표와 원천 표본을 보존합니다. 승인된 새 버전을 만든 뒤 영향을 받는 기간의 조회 결과를 별도로 다시 계산해 기존 보고서와 비교합니다. 재계산을 현재 숫자에 덮어쓰는 대신 기준 버전, 생성 시각과 차이를 표시해야 어떤 숫자를 회의에 사용했는지 다시 찾을 수 있습니다.

연동 인증 만료나 수집 지연이 발생하면 매핑 오류와 구분해 보여줍니다. 원천이 오지 않은 날의 0개와 수집은 됐지만 연결되지 않은 2개는 다른 상황입니다. 마지막 성공 수집 시각, 원천 기준일, 수집 실패 범위와 확인 대기 수량을 함께 확인하도록 설계합니다. 수집 재개 뒤에도 빠진 기간의 재처리와 표본 대사는 별도로 확인합니다.

인수 문서에는 채널별 키 정의, 매핑 변경 승인표, 보류 원인, 단위 환산표와 재계산 절차를 남깁니다. 소스코드 제공 여부뿐 아니라 원천 접근 계정의 소유자, 배포 환경, 장애 연락처, 운영 중 변경의 담당과 비용 범위도 계약에서 나눕니다. 실제 수집 가능 여부와 운영 지원 기간은 확인 후 합의하며 기본 제공으로 단정하지 않습니다.

채널별 지표와 기준일은 쇼핑몰 통합 대시보드 구축 기준에서 확인하세요. 품목이 아니라 주문 처리 상태를 구분하려면 SCM 주문 상태 코드 매핑을 참고하세요.

대시보드 업체에 줄 수 있는 가상 검수 표본#

검수표에는 원천별 판매행 식별자, 상품 ID와 옵션 ID, 승인된 내부 품목코드, 주문 기준일, 판매 단위와 수량을 적습니다. 원천 합계와 매핑 완료·확인 대기의 합을 먼저 비교합니다. 위 가상 사례에서 원천 9개는 승인 7개와 대기 2개이므로 9 = 7 + 2입니다. 표본에 고객 이름과 연락처가 필요하지 않다면 비식별 자료를 사용하고 접근 권한이 있는 인원만 확인합니다.

첫 번째 시험은 정상 매핑입니다. 채널 A의 BLUE-M 4개와 채널 B의 1024-07 3개가 모두 P-01로 연결되는지 봅니다. 채널 필터를 각각 적용하면 4개와 3개가 표시되고 두 채널을 같이 선택하면 P-01 7개입니다. 상세에 원천 두 행이 남아 있어야 합계가 7인 이유를 추적할 수 있습니다. 채널 C는 이 품목의 승인 합계에 포함하지 않습니다.

두 번째 시험은 미확인과 중복입니다. 채널 C의 NEW-7 2개에 매핑 후보가 없어도 원천 총계는 9개로 유지하고 확인 대기에 2개가 나오는지 확인합니다. 같은 계정의 같은 원천 식별자가 다른 품목 두 개에 동시에 승인된 충돌을 가상으로 넣으면 자동 합산을 멈추고 담당자에게 확인하도록 요구합니다. 중복 수집과 중복 매핑은 다른 오류이므로 각각의 사유와 처리 기록이 보여야 합니다.

세 번째 시험은 묶음과 단위입니다. P-01 두 개로 구성된 상품을 1세트 판매한 별도 표본에서 판매 단위 1세트와 내부 기준 2개를 구분합니다. 구성표가 없으면 기본 품목 수량을 임의 계산하지 않고 보류합니다. 세트 주문을 앞선 단일 상품 9개 사례와 합산하려면 보고서에 판매 단위와 기본 단위의 분모를 따로 정하고, 재고 차감이나 반품 처리는 이번 조회 검수와 별도 승인합니다.

네 번째 시험은 버전 변경과 복구입니다. 이전 버전에서 확인 대기로 둔 NEW-7을 담당자가 P-01로 승인한 뒤, 당시 보고서는 7개와 대기 2개로 재현되는지 봅니다. 재산출을 별도 승인한 현재 보고서에서는 같은 원천 9개가 P-01 9개와 대기 0개가 됩니다. 두 보고서에 각각의 매핑 버전과 생성 시각을 표시하고 승인 전 결과를 조용히 교체하지 않습니다.

다섯 번째 시험은 운영 인수입니다. 채널 담당자가 변경 제안, 책임자가 승인, 다른 사용자가 이력 조회를 수행하고 승인 권한이 없는 계정의 변경은 거절되는지 확인합니다. 원천 한 곳의 인증 만료와 늦은 수신을 가정해 마지막 성공 시각과 미수집 범위를 점검합니다. 원천 자료가 제공되지 않은 연동은 미검증으로 표시하고, 검수 통과로 간주하지 않습니다.