AI 쇼핑 에이전트가 읽을 수 있는 멀티벤더 마켓플레이스 카탈로그 구축: 스키마, 피드, 툴 인터페이스

이 가이드는 멀티벤더 마켓플레이스의 CTO, 아키텍트, 프로덕트 오너를 대상으로 합니다. 플랫폼 아키텍처를 이미 결정하고 셀러 온보딩 순서를 정했으며, 이제 완성된 카탈로그를 AI 쇼핑 에이전트가 읽고 비교하고 거래할 수 있는 형태로 만들어야 하는 분들을 위한 내용입니다. 설계가 명확해지면 이 작업은 이커머스 개발을 통해 이커머스 마켓플레이스 솔루션 위에서 진행됩니다. 단일 셀러 스토어의 에이전트 준비에 대해서는 별도의 에이전틱 커머스 준비 가이드를 참조하십시오. 이 가이드는 카탈로그에 단일 판매자가 아닌 여러 벤더의 오퍼가 포함될 때 무엇이 달라지는지에 초점을 맞춥니다.

이 가이드의 목차

• 단일 셀러 상품 스키마는 왜 멀티벤더 카탈로그에 맞지 않는가?
• 스키마 모델: 하나의 상품, 여러 벤더 오퍼
• 벤더 피드를 하나의 에이전트 가독 카탈로그 피드로 정규화하기
• 마켓플레이스 툴 인터페이스가 단일 스토어와 달리 노출해야 하는 것은 무엇인가?
• 멀티벤더 카탈로그에서 AI의 역할
• 존재하는 납품 실적과 존재하지 않는 것
• 대안: 스키마, 피드, 툴 인터페이스 레이어를 누가 구축하고 운영하는가
• 이 가이드의 한계
• 자주 묻는 질문
• 다음 단계

단일 셀러 상품 스키마는 왜 멀티벤더 카탈로그에 맞지 않는가?

단일 셀러 스토어는 하나의 Product에 하나의 Offer를 게시합니다. 가격, 재고 수량, 판매자, 정책이 모두 암묵적으로 판매자 자신의 것입니다. 반면 마켓플레이스 카탈로그에서는 사실상 동일한 상품을 여러 벤더가 판매하는 경우가 많으며, 에이전트가 이를 비교하려면 가장 낮은 가격만이 아니라 그 가격이 어느 벤더의 것인지, 해당 벤더의 재고·배송·반품 정책이 무엇인지, 그리고 주문을 올바른 셀러에게 라우팅하는 방법을 알아야 합니다. 벤더 수준의 정보를 하나의 요약으로 축소하면 "가격 범위가 어떻게 되나요?"라는 질문에는 답할 수 있지만, "어느 셀러에게서 어떤 조건으로 구매하나요?"라는 에이전트가 행동하기 전에 반드시 답해야 하는 질문에는 답할 수 없습니다.

스키마 모델: 하나의 상품, 여러 벤더 오퍼

실용적인 원칙: 페이지에 사람용 요약(최저 가격과 셀러 수)이 필요하다면 AggregateOffer를 유지하되, 에이전트용 피드나 API에는 모든 항목에 안정적인 셀러 식별자가 붙은 벤더별 Offer 배열을 제공하십시오. Google의 멀티셀러 마켓플레이스 가이드도 피드 수준에서 동일한 입장을 취합니다. 마켓플레이스 계정은 각 셀러가 업데이트 전반에서 식별 가능하도록 모든 항목에 external_seller_id를 설정해야 합니다 (Google Merchant Center, 상품 데이터 사양, 접근일 2026-10-26).

마켓플레이스 툴 인터페이스가 단일 스토어와 달리 노출해야 하는 것은 무엇인가?

단일 스토어의 MCP 또는 프로토콜 방식 툴 인터페이스는 모든 응답이 하나의 판매자에 속한다고 가정할 수 있습니다. 마켓플레이스 툴 인터페이스는 그럴 수 없습니다. 동일한 검색 또는 상품 조회 호출이 하나의 항목에 대해 여러 벤더를 반환할 수 있으며, 각 결과에는 카탈로그로부터 상속받는 것이 아닌 고유한 가격, 재고, 정책, 셀러 신원이 첨부되어야 합니다. 또한 플랫폼 수준 규칙(예: 분쟁에 대한 마켓플레이스 자체 반품 기간)을 벤더 자체 정책과 별도로 표현하는 방법도 필요합니다. 두 가지가 다를 수 있고 에이전트는 특정 오퍼에 어느 쪽이 적용되는지 알아야 하기 때문입니다. Anthropic의 Model Context Protocol은 이를 툴 호출(특정 셀러에게 주문 배치와 같은 액션)과 리소스(카탈로그 목록과 같이 클라이언트가 읽는 데이터)의 차이로 정의하며, 이는 마켓플레이스에 명확하게 대응됩니다. 카탈로그와 오퍼 데이터는 여러 벤더에 걸쳐 읽히는 리소스이고, 체크아웃은 한 벤더의 주문으로 범위가 한정된 툴 호출입니다 (Model Context Protocol, 사양, 접근일 2026-10-26). Shopify와 Google의 Universal Commerce Protocol도 카탈로그 수준에서 비교 가능한 접근 방식을 취하며, 단일 판매자의 데이터를 가정하는 대신 에이전트가 발견할 수 있는 카탈로그와 체크아웃 기능을 게시합니다 (Shopify Engineering, Universal Commerce Protocol, 접근일 2026-10-26).

존재하는 납품 실적과 존재하지 않는 것

• RB Marketplace. RB Marketplace 레코드는 고객 REST API와 동일한 API 위에 구축된 모바일 앱이 있는 라이브 멀티벤더 마켓플레이스를 설명하며, 외부 클라이언트가 이미 읽고 있는 API 우선 카탈로그를 보여줍니다. AI 지원 정규화 단계, 구조화 데이터 스키마, 에이전트/MCP 통합은 설명되어 있지 않으며 카탈로그 크기나 성능 수치도 게시되지 않았습니다.
• 커머스 플랫폼 범위. Netbase JSC는 WooCommerce, Magento 2, Laravel, 헤드리스 커머스 기반의 커머스를 납품했으며, PrestaShop, OpenCart, Shopware, CS-Cart, Shopify, Salesforce, Akeneo, Odoo, Symfony와도 협업합니다(이 가이드의 카탈로그 및 피드 레이어가 위치하거나 통합되는 플랫폼들).
• 투자 방향. David(CEO)는 에이전틱 커머스와 API 우선 납품을 Netbase JSC 서비스 전반의 투자 영역으로, AI 전환을 납품에 내재된 방향으로 명시한 바 있습니다. 이는 선언된 방향이지 납품된 에이전트-카탈로그 기능이 아닙니다.

존재하지 않는 것. AI 쇼핑 에이전트를 위해 특별히 구축된 멀티벤더 카탈로그 스키마, 정규화된 에이전트용 피드, 또는 MCP/UCP/ACP 툴 인터페이스 통합을 설명하는 Netbase JSC의 게시된 레코드는 없습니다. 위의 프레임워크는 schema.org, Google Merchant Center, Model Context Protocol 문서와 Netbase JSC의 자체 멀티벤더 카탈로그 및 API 작업 구조에서 도출한 납품 방법론이며, 측정된 에이전트 준비 프로젝트가 아닙니다.

대안: 스키마, 피드, 툴 인터페이스 레이어를 누가 구축하고 운영하는가

Netbase JSC 커스텀 개발에서는 클라이언트가 해당 프로젝트를 위해 만들어진 IP를 소유하며, 대부분의 프로젝트는 디스커버리 이후 합의된 고정가 계약으로 진행됩니다. 마일스톤 기반, 월별 팀 리테이너, KPI 연동 조건도 제공됩니다. 에이전트 또는 툴 인터페이스 호출자를 API의 새로운 클라이언트 유형으로 취급하십시오. Netbase JSC의 표준 보안 관행—역할 기반 접근 제어, 관리자 대시보드 MFA, 전송 중 TLS, 저장 데이터 암호화—은 스토어프런트뿐 아니라 외부 호출자에게 서비스하는 카탈로그 API에도 적용됩니다. 이 서비스는 이커머스 개발에서 제공되며, 이커머스 마켓플레이스 솔루션과 리테일 및 이커머스 마켓플레이스에 관련됩니다.

이 가이드의 한계

• Schema.org, Google Merchant Center, Model Context Protocol 문서는 변경됩니다. 구축 전에 각 게시자의 현행 필드와 요건을 확인하십시오.
• 카탈로그 크기, 매칭 정확도, 에이전트 주문 수치는 주장하지 않습니다. Netbase JSC는 이 작업에 대해 현재 어떠한 수치도 게시하지 않았습니다.
• 이 가이드는 카탈로그 스키마, 피드 정규화, 툴/API 인터페이스만 다룹니다. 셀러 등록은 별도 가이드에서, 단일 셀러 스토어 준비는 에이전틱 커머스 준비에서 다룹니다.

다음 단계

현재 벤더들이 상품 데이터를 어떻게 전송하는지 알려주시면, 솔루션 리뷰를 예약하여 멀티벤더 스키마, 피드, 툴 인터페이스 설계의 범위를 정할 수 있습니다. 마켓플레이스 플랫폼 아키텍처 가이드를 읽거나 Netbase JSC 인사이트를 더 살펴보실 수도 있습니다.

관련 서비스 및 솔루션