이 글은 누구를 위한 것인가
- 셀러 카탈로그가 바이어 ERP에 들어가지 않아 매번 엑셀로 수정하고 있는 B2B 운영자
- B2B 마켓플레이스를 새로 만들거나 리뉴얼하는 PM·기획자
- PIM(Product Information Management)을 도입했지만 실제로 누가 진실인지 모호한 상태인 데이터 팀
들어가며
B2B 커머스의 카탈로그는 상품 정보의 장이 아니라 거래 조건의 장이다. 같은 상품도 바이어 등급·계약·지역에 따라 가격·결제 조건·재고 우선순위가 다르다. 이 정보가 셀러 시스템(ERP·PIM), 플랫폼 카탈로그, 바이어 ERP·구매 시스템 사이를 매일 오간다. 한 곳에서 바꾼 정보가 다른 곳에 반영되지 않으면, 발주서가 잘못 나가고 정산 분쟁이 생긴다.
B2B 카탈로그 동기화는 기술 통합 문제가 아니다. 누구의 어떤 정보를 진실로 인정하느냐의 합의 문제다. 합의가 명확하지 않으면 어떤 미들웨어를 도입해도 사고가 반복된다.
1. 카탈로그 정보의 책임 분리
먼저 카탈로그 정보를 영역별로 나눈다. 같은 "상품 정보"라도 책임 주체가 다르다.
| 영역 | 진실 소스 (Source of Truth) |
|---|---|
| 상품 식별 (SKU, GTIN) | 셀러 |
| 상품 본질 (명칭, 규격, 단위) | 셀러 |
| 마케팅 콘텐츠 (이미지, 설명) | 셀러 또는 플랫폼 |
| 분류·카테고리 | 플랫폼 |
| 가격·할인·계약 단가 | 셀러 (바이어별 차등) |
| 재고 (가용 수량) | 셀러 |
| 결제·정산 조건 | 플랫폼 (계약 기반) |
| 배송 조건 (리드타임, 묶음) | 셀러 |
위 표가 데이터 계약의 출발점이다. 한 영역에 진실 소스가 둘이면 동기화가 깨진다.
2. SKU 식별자 — 셀러 코드와 플랫폼 코드의 매핑
가장 자주 깨지는 영역이다. 셀러는 자기 SKU를 쓴다. 플랫폼은 자기 상품 ID를 쓴다. 바이어 ERP는 또 다른 자체 코드를 쓴다.
세 식별자가 영구 매핑 테이블에 함께 존재해야 한다.
[Product Mapping]
platform_product_id: 1234567
seller_sku: ABC-XYZ-001 (셀러 A 기준)
buyer_internal_code: 99-2025-A123 (바이어 B 기준)
gtin: 8801234567890 (글로벌 표준)
매핑 테이블은 계약 시점에 1회 작성하고 거의 변경하지 않는다. 셀러가 SKU를 바꾸면 매핑은 유지하고 셀러 SKU만 갱신한다. 바이어가 자체 코드를 변경할 때도 마찬가지다.
GTIN(국제 표준 상품 코드)이 있으면 매핑이 훨씬 쉽다. 같은 GTIN은 같은 상품임이 글로벌하게 보장된다. GTIN이 없는 카테고리(B2B 산업재 일부)는 플랫폼이 발급하는 ID가 가장 안전한 기준이 된다.
3. 가격 — 단위·통화·세금 포함 여부의 합의
B2B에서 가장 많은 분쟁이 가격 표기에서 나온다. 다음 5개 항목이 동시에 합의돼야 한다.
| 항목 | 예시 |
|---|---|
| 가격 단위 | 개당, 박스당(12개), 팔레트당(120개) |
| 통화 | KRW, USD, EUR (계약 통화) |
| 세금 포함 여부 | VAT 별도 / VAT 포함 |
| 적용 시점 | 발주일 / 출고일 / 청구일 |
| 유효 기간 | 단가표의 유효 시작·종료일 |
{
"platform_product_id": 1234567,
"buyer_id": 555,
"price_unit": "BOX_12",
"currency": "KRW",
"unit_price": 120000,
"tax_included": false,
"vat_rate": 0.10,
"effective_from": "2026-05-01",
"effective_to": "2026-12-31",
"minimum_order_quantity": 5,
"tier_pricing": [
{"min_qty": 50, "unit_price": 115000},
{"min_qty": 200, "unit_price": 110000}
]
}
*수량 구간별 단가(tier pricing)*와 *최소 발주 수량(MOQ)*은 B2B의 기본이다. 이 정보가 카탈로그 응답에 함께 들어가야 바이어 ERP가 발주서를 자동 생성할 수 있다.
4. 재고 책임 경계
B2B에서 재고는 다음 셋 중 하나의 모델이다.
- 셀러 재고: 셀러가 자기 창고에 가지고 있고 플랫폼에 가용 수량만 보여줌
- 위탁 재고: 셀러가 플랫폼 창고에 위탁, 플랫폼이 관리
- 계약 재고: 바이어 전용으로 일정 수량을 예약
세 모델이 한 카탈로그에 섞여 있는 경우가 많다. 카탈로그 응답에 재고 모델을 명시한다.
{
"platform_product_id": 1234567,
"inventory_model": "SELLER_OWNED",
"available_qty": 1500,
"lead_time_days": 3,
"reserved_for_buyer": 0
}
{
"platform_product_id": 1234568,
"inventory_model": "CONTRACT_RESERVED",
"available_qty": 200,
"lead_time_days": 1,
"reserved_for_buyer": 555,
"contract_id": "CON-2026-A001"
}
reserved_for_buyer가 있으면 해당 바이어만 그 재고를 본다. 다른 바이어에게는 노출되지 않는다. 플랫폼 카탈로그 API가 바이어 컨텍스트를 반드시 받아야 하는 이유다.
5. 카테고리 매핑 — 플랫폼 표준 vs 셀러 분류
셀러는 자기 분류 체계로 상품을 정리한다. 플랫폼은 자기 카테고리 트리를 갖는다. 두 분류가 N:N으로 매핑돼야 한다.
셀러 분류: 플랫폼 카테고리:
"산업용 윤활유 > 기어유" → "산업재 > 윤활유 > 기어"
→ "자동차 부품 > 액체 > 기어 오일"
같은 상품이 두 카테고리에 노출될 수 있다. 카테고리 매핑은 중복 허용이 기본이다. 단, 한 카테고리에서 다른 카테고리로 바뀐 상품은 검색·랭킹에 영향을 주므로 변경 시점을 로그로 남긴다.
매핑 갱신은 분기 1회 정도가 흔하다. 매월 갱신하면 셀러·바이어 모두 적응할 시간이 부족하다.
6. 동기화 프로토콜 — Push, Pull, CDC
셀러 시스템 → 플랫폼 카탈로그의 동기화 방법은 셋이다.
| 방법 | 장점 | 단점 |
|---|---|---|
| Pull (플랫폼이 가져감) | 셀러 부담 적음 | 변경 즉시 반영 어려움 |
| Push (셀러가 보냄) | 변경 즉시 반영 | 셀러 시스템 개발 부담 |
| CDC (DB 변경 캡처) | 즉시성·완전성 | 셀러 DB 접근 권한 필요 |
대형 셀러는 보통 Push 또는 CDC를 쓴다. 중소 셀러는 플랫폼이 제공하는 셀러 어드민에서 직접 입력하거나 엑셀 업로드를 쓴다. 한 플랫폼이 셋을 모두 지원해야 셀러 풀이 넓어진다.
엑셀 업로드는 템플릿 표준화가 핵심이다. 셀러마다 칼럼이 다르면 사고가 끊이지 않는다. 플랫폼 표준 템플릿을 제공하고, 업로드 후 검증 결과를 즉시 보여 준다.
[엑셀 업로드 결과]
- 정상 처리: 1,234건
- 가격 형식 오류: 5건 (행 12, 47, 88, 102, 119)
- MOQ 누락: 2건 (행 33, 89)
- 카테고리 매핑 실패: 1건 (행 200)
→ [오류 행 다운로드] [수정 후 재업로드]
오류를 즉시 보여주지 않으면 셀러는 어디가 잘못됐는지 모르고 같은 실수를 반복한다.
7. 바이어 ERP 연동 — 카탈로그 받는 쪽의 문제
플랫폼이 카탈로그를 잘 만들어도 바이어 ERP가 그것을 받지 못하면 의미가 없다. 바이어는 보통 다음 중 하나로 받는다.
- OCI/Punchout: 바이어 ERP에서 플랫폼으로 세션 점프해 장바구니를 ERP로 가져옴
- CIF (Catalog Interchange Format): 정적 카탈로그 파일을 다운로드해 ERP에 적재
- REST API: 바이어 ERP가 플랫폼 API를 직접 호출
OCI/Punchout이 표준이다. SAP Ariba, Coupa, Oracle Procurement 같은 ERP가 모두 지원한다. 플랫폼 측이 OCI 응답 포맷을 정확히 지원하면 바이어 통합이 빨라진다.
<!-- OCI 응답 예시 (간소화) -->
<NEW_ITEM-DESCRIPTION>산업용 기어 오일 5L</NEW_ITEM-DESCRIPTION>
<NEW_ITEM-MATNR>SUPPLIER-MAT-001</NEW_ITEM-MATNR>
<NEW_ITEM-PRICE>120000</NEW_ITEM-PRICE>
<NEW_ITEM-CURRENCY>KRW</NEW_ITEM-CURRENCY>
<NEW_ITEM-PRICEUNIT>1</NEW_ITEM-PRICEUNIT>
<NEW_ITEM-UNIT>BOX</NEW_ITEM-UNIT>
<NEW_ITEM-QUANTITY>5</NEW_ITEM-QUANTITY>
<NEW_ITEM-LEADTIME>3</NEW_ITEM-LEADTIME>
OCI 필드 매핑이 정확해야 ERP에서 발주서가 자동 생성된다. 필드 하나만 비어 있어도 ERP는 수동 입력을 요구한다. 바이어 입장에서 그게 가장 큰 마찰이다.
8. 데이터 계약 변경 관리
카탈로그 스키마는 시간이 지나면서 변경된다. 새 필드 추가, 단위 변경, 카테고리 트리 개편. 이 변경이 바이어 ERP를 깨면 거래가 멈춘다. 다음 원칙을 둔다.
- API 버전 관리:
/v1/catalog,/v2/catalog병행 지원, 최소 6개월 구버전 유지 - 필드 추가는 OK, 제거는 금지: 새 필드는 무시하면 되지만 사라지면 ERP가 깨짐
- 단위·통화·세금 변경은 계약 갱신과 함께: 데이터만 바꾸지 않음
- 변경 공지 채널: 셀러·바이어 양쪽에 변경 30일 전 공지
API 변경 로그를 공개 페이지로 운영하는 것이 권장된다. 바이어 IT 담당자가 언제 어떤 변경이 있었는지 한눈에 본다.
9. 운영 체크리스트
- SKU·GTIN·플랫폼 ID 매핑 테이블이 한 곳에 있다
- 가격 단위·통화·세금 포함 여부가 명시적 필드다
- 수량 구간별 단가·MOQ가 카탈로그 응답에 함께 들어간다
- 재고 모델이 카탈로그 응답에 명시돼 있다
- 바이어 컨텍스트로 바이어 전용 재고/가격이 분기된다
- 카테고리 매핑이 N:N을 허용한다
- 셀러 동기화가 Pull/Push/CDC/엑셀 모두 지원된다
- 엑셀 업로드 시 오류 행을 즉시 보여 준다
- OCI/Punchout 또는 CIF가 지원된다
- API 버전 관리 정책이 문서화돼 있다
마무리
B2B 카탈로그 동기화는 기술 통합보다 데이터 계약이 먼저다. 누가 어떤 정보의 진실인지, 어떤 형식으로 주고받는지, 변경 시 누구에게 언제 알리는지가 합의돼 있어야 한다. 합의 없이 미들웨어를 도입하면 사고가 플랫폼 책임으로 몰린다.
카탈로그 한 페이지만 골라 진실 소스 표를 한 번 그려 보길 권한다. 진실 소스가 둘 이상인 칸이 있으면 그게 다음 분쟁의 자리다.