MCP로 AI 에이전트를 BigCommerce에 연결하기: Stripe 파트너십이 해결하지 못하는 것

문제: 세 가지 경로, 어느 것도 B2B 견적을 해결하지 못함

BigCommerce는 Shopify와 HubSpot과 다른 길을 선택했습니다. Shopify는 퍼스트파티 Storefront MCP 및 Customer Accounts MCP 서버를 구축하고 Google과 공동으로 Universal Commerce Protocol을 개발했습니다. HubSpot은 퍼스트파티 Remote MCP Server(2026년 4월 13일 GA)를 출시하여 표준 CRM 객체를 다루는 12개의 도구를 제공했습니다. BigCommerce는 둘 다 하지 않았습니다. 대신 2025년 12월 18일, BigCommerce는 Stripe와 파트너십을 맺었고 Stripe의 Agentic Commerce Suite에 참여했습니다. 이는 Agentic Commerce Protocol (ACP) 위에 구축되었습니다 — Stripe, OpenAI, Meta가 공동 제작한 오픈 표준, Apache 2.0 라이선스.

그 결과 AI 에이전트를 BigCommerce 스토어에 연결하는 세 가지 개별 경로가 존재하며, 각각 다른 커버리지 프로파일을 가집니다:

BigCommerce 에이전트 통합의 세 가지 경로는 스택의 다른 계층에 연결됩니다:

경로 1 — BigCommerce 문서 MCP 서버. BigCommerce는 https://docs.bigcommerce.com/_mcp/server에 MCP 엔드포인트를 노출하여 AI 에이전트가 BigCommerce 개발자 문서를 검색할 수 있게 합니다. 문서에서 정보를 끌어와 "BigCommerce checkout API는 어떻게 작동하나요?" 같은 질문에 답합니다. 이는 문서용 MCP 서버이지 스토어 데이터용이 아닙니다. 연결된 에이전트는 BigCommerce API가 어떻게 작동하는지 학습할 수 있지만 어떤 스토어의 제품, 고객, 주문, 재고도 읽을 수 없습니다. 이는 개발자 지원 도구이지 스토어 통합 경로가 아닙니다.

경로 2 — Stripe의 Agentic Commerce Suite, ACP 위에 구축. 파트너십 발표는 이렇게 표현합니다: "BigCommerce 머천트는 기존 카탈로그, 주문 시스템, 운영 프로세스를 계속 사용하면서 AI 기반 발견 및 체크아웃 흐름을 잠금 해제할 수 있습니다." 머천트는 제품 카탈로그를 Stripe에 연결하고, 어떤 AI 에이전트를 통해 판매할지 선택하며, Stripe가 발견, 체크아웃, 결제, 사기 탐지를 처리합니다. Stripe의 Agentic Commerce Suite 글은 대체 비용을 정량화합니다: 없으면 기업은 "지원하는 새 AI 에이전트당 최대 6개월의 통합 작업"에 직면합니다. ACP 경로는 이를 단일 구성 가능한 통합으로 대체합니다.

ACP 아키텍처는 컴포저블합니다: agentic checkout(카트 관리, 이행 옵션, 결제 처리), cart and feed(제품 카탈로그 브라우징), Shared Payment Tokens를 통한 위임 결제(SPTs — 셀러에 스코프되고 시간과 금액으로 제한되며 라이프사이클을 통해 관찰 가능), OAuth 2.0을 통한 위임 인증, 라이프사이클 추적을 위한 orders and webhooks. Stripe Radar는 비인간 트래픽 패턴에 맞춰진 사기 탐지를 제공합니다. 머천트는 merchant-of-record 지위와 고객 관계에 대한 통제를 유지합니다.

이 경로는 소비자 에이전트 커머스 문제를 해결합니다: 쇼핑객이 AI 에이전트에게 제품을 요청하면, 에이전트는 Stripe의 카탈로그 피드를 통해 발견하고, Stripe Checkout Sessions API를 통해 체크아웃하며, SPTs를 통해 지불합니다. B2B 문제는 해결하지 않습니다.

경로 3 — 제3자 제공자의 관리형 MCP 서버. StackOne은 즉시 사용 가능한 120개 액션을 가진 BigCommerce MCP 서버를 제공합니다. Truto는 /tools 엔드포인트를 통해 BigCommerce REST API 기능을 노출합니다. 오픈소스 isaacgounton/bigcommerce-api-mcp는 전체 BigCommerce REST API 서피스를 래핑합니다. 이 서버들은 에이전트에게 제품, 고객, 주문, 재고에 대한 타입화된 도구 접근을 제공합니다 — REST API가 지원하는 CRUD 조작입니다.

문제는 이 관리형 서버들이 무엇을 잘못하는지가 아닙니다. 문제는 세 경로 어느 것도 인코딩하지 않는 것입니다: B2B 시맨틱 레이어 — 어느 가격이 어느 고객에게 적용되는지, 어느 재고가 예약 가능한지, 어느 주문이 어느 ERP 레코드에 매핑되는지를 결정하는 비즈니스 의미입니다.

ACP 경로가 B2B에 대해 커버하지 않는 것

Stripe로의 ACP 제품 피드는 제품당 하나의 가격을 운반합니다 — 공개 카탈로그 가격입니다. BigCommerce의 실제 B2B 가격 구조는 Customer Groups와 Price Lists에 있습니다. Price Lists는 Price List Assignment API를 통해 특정 Sales Channels에서 특정 Customer Groups에 변형 수준 가격 오버라이드를 할당할 수 있게 합니다. 엔터프라이즈 계약, 미드마켓 볼륨, 도매, 공개 소매의 4개 가격 티어를 운영하는 유통업체는 하나 이상의 채널에 걸쳐 4개 Customer Groups에 4개 Price Lists를 매핑하는 4개의 Price List Assignments를 가집니다.

엔터프라이즈 바이어의 구매 코디네이터를 대표하는 AI 에이전트가 ACP 경로를 통해 요청을 보낼 때, 에이전트는 공개 카탈로그 가격을 봅니다. 고객은 엔터프라이즈 티어 가격에 대한 계약상 권리가 있습니다 — 잠재적으로 20-40% 더 낮습니다. ACP 피드는 티어 구조를 운반하지 않습니다. 에이전트는 잘못된 가격을 인용합니다. 유통업체는 마진을 흡수하거나 취소하고 판매를 잃습니다.

BigCommerce 파트너십 발표는 이를 인정합니다: 머천트는 "BigCommerce 재고 및 가격 로직으로 에이전트 쇼핑을 정보화합니다." 그 표현은 머천트가 BigCommerce에서 가격 로직을 구성하고 Stripe가 이를 존중해야 함을 의미합니다 — 그러나 ACP 피드 아키텍처는 카탈로그를 단일 가격 서피스로 평탄화합니다. B2B 티어 인텔리전스는 피드에 없습니다.

두 번째 갭은 재고입니다. BigCommerce의 Catalog Products API는 재고 수준을 보고하지만 예약하지 않습니다. 240 라이브 카운트에 대해 200단위를 인용하는 에이전트는 구매 주문이 도착할 때쯤 틀릴 수 있습니다. 왜냐하면 다른 세 견적이 그 사이에 같은 재고를 소비했기 때문입니다. RFQ 엔진 아키텍처 — TTL이 있는 원자적 가용성 홀드, 취소 정책 스냅샷, FX 레이트 잠금 — 는 ERP와 견적 레이어에 존재하며, 이커머스 스토어프론트나 ACP 경로에는 없습니다.

세 번째 갭은 ERP 라이트백입니다. ACP 경로는 수락된 주문을 webhooks를 통해 머천트에게 돌려줍니다. 머천트의 주문 시스템 — BigCommerce Orders API — 가 이를 수신합니다. 그러나 BigCommerce의 주문 객체는 GL 코딩, 자회사, 세금 넥서스, 또는 NetSuite/Brightpearl이 주문을 올바르게 전기하는 데 필요한 커스텀 필드를 인코딩하지 않습니다. NetSuite MCP 모듈 분석이 이를 깊이 다룹니다: 이커머스 주문과 ERP 주문 레코드 간의 시맨틱 갭은 어느 GL 계정, 어느 자회사, 어느 세금 넥서스, 어느 커스텀 필드가 유효한 전기를 구성하는지입니다. ACP 경로는 그 갭을 브리지하지 않습니다.

관리형 MCP 서버가 인코딩하지 않는 것

관리형 MCP 서버(StackOne, Truto, Apideck)는 다른 문제를 해결합니다: 에이전트에게 타입화된 BigCommerce REST API 접근을 제공합니다. StackOne의 120 액션은 제품, 고객, 주문, 재고, 스토어 관리를 다룹니다. Truto는 REST API를 통일된 /tools 엔드포인트 뒤에 래핑합니다. 이들은 실제 제품이지 데모가 아닙니다 — 커스텀 통합 코드 없이 BigCommerce API를 AI 에이전트에게 읽기 쉽게 만듭니다.

하지만 타입화된 API 접근은 타입화된 비즈니스 의미와 같지 않습니다. get_products(filters)를 노출하는 관리형 MCP 서버는 에이전트에게 제품을 쿼리하는 능력을 줍니다. 이 스토어에서 고객 그룹 4("Enterprise Contract")가 "B2B Portal" 채널에서 Price List 7에 대한 권리를 가지며, 그 그룹의 바이어로부터의 요청이 기본 카탈로그 가격이 아닌 GET /v3/pricelists/7/records?variant_id={id}를 통해 해결되어야 함을 에이전트에게 알리지 않습니다. 관리형 서버는 API 서피스를 래핑합니다. 어느 API 호출이 무엇을 의미하는지 결정하는 비즈니스 규칙을 인코딩하지 않습니다.

이것은 커넥터 시리즈 전반에 나타나는 같은 구조적 패턴입니다. HubSpot 분석은 HubSpot의 퍼스트파티 서버에서 6개 역량 갭을 문서화합니다 — 커스텀 객체 없음, 검토 가능한 쓰기 계획 없음, 연결당 1포털, 시스템 수준 설계 없음, 라이브 API 전용 쿼리, 민감 데이터 제약. Shopify 분석은 퍼스트파티 Storefront MCP가 커버하지 않는 B2B 경로 — 고객 티어 가격, 대량 RFQ 견적, NetSuite에 대한 재고 홀드, 채널 간 주문 귀속 — 를 문서화합니다. 각 경우, 벤더의 커넥터는 연결 문제를 해결합니다. 커스텀 MCP 모듈은 시맨틱 레이어 문제를 해결합니다.

BigCommerce의 경우, 벤더는 연결 레이어 MCP 서버를 전혀 구축하지 않았습니다 — 소비자 에이전트 커머스를 Stripe에 위임하고 스토어 데이터 MCP 서피스를 제3자 제공자에게 남겼습니다. 시맨틱 레이어 갭은 동일합니다. 차이점은 연결 레이어 자체가 더 파편화되어 있다는 것입니다.

인증: 헤드리스 친화적 제약

BigCommerce의 API 인증은 X-Auth-Token을 사용합니다 — 스토어 관리 화면(Store Setup → API Settings)에서 생성되거나 머천트가 앱을 설치할 때 OAuth 앱 설치 흐름을 통해 발행되는 스토어 스코프 베어러 토큰입니다. HubSpot의 OAuth 2.1 with PKCE(브라우저 기반 동의 및 1회용 리프레시 토큰 필요)와 달리, BigCommerce API 토큰은 취소되지 않는 한 만료되지 않으며 브라우저 기반 리프레시가 필요하지 않습니다. 이는 HubSpot의 퍼스트파티 MCP 서버보다 헤드리스 친화적입니다: 오버나이트 주문 변경을 동기화하기 위해 새벽 2시에 실행되는 백그라운드 에이전트가 인간 개입 없이 정적 X-Auth-Token으로 인증할 수 있습니다.

제약은 레이트 제한이지 인증이 아닙니다:

API는 헤더를 통해 레이트 제한 상태를 반환합니다: X-Rate-Limit-Requests-Quota, X-Rate-Limit-Requests-Left, X-Rate-Limit-Time-Reset-Ms. 리스트 엔드포인트는 페이지당 250개 항목을 반환합니다. Standard 스토어에 30개의 병렬 도구 호출을 발사하는 에이전트는 한 번에 150 요청 윈도우를 소진하고 나머지에서 429를 받습니다. 도구별 스로틀링을 강제하지 않는 관리형 MCP 서버는 그 실패를 비구조화된 에러로 에이전트에게 전달합니다.

커스텀 MCP 모듈은 도구별 레이트 제한을 내부적으로 강제합니다 — 각 도구가 제한을 선언하고, 백본이 30초 윈도우 내에 머물도록 요청을 스로틀하며, 에이전트는 크래시가 아닌 X-Rate-Limit-Time-Reset-Ms에서 도출된 Retry-After를 가진 구조화된 429를 받습니다. 모듈은 또한 리스트 쿼리를 배치 처리합니다 — 250개 항목의 200개 요청을 페이지네이션하는 대신, 모듈은 필터링된 쿼리를 사용해 에이전트가 실제로 필요한 레코드만 가져와 레이트 윈도우 내에 머물 수 있습니다.

커스텀 MCP 모듈이 제공하는 것

모듈 패턴은 MCP Module Code Standard를 따릅니다: 모든 도구는 타입화된 입력 스키마, 타입화된 출력 스키마, 레이트 제한, 감사 로그, 에러 컨트랙트를 가집니다. 에이전트는 원시 엔드포인트에 대한 자유 형식 API 호출이 아닌 이름과 구조화된 인수로 도구를 호출합니다.

BigCommerce의 경우, 커스텀 모듈은 ACP 경로와 관리형 MCP 서버가 열어둔 갭을 채웁니다:

고객 그룹 가격 해결. 모듈은 get_tier_price(customer_id, product_id, channel_id, quantity)를 노출합니다 — 바이어의 Customer Group을 해결하고 현재 채널에서 그 그룹의 Price List Assignment를 찾아 요청된 수량에 대한 변형 수준 가격을 반환하는 타입화된 도구입니다. 에이전트는 고객 그룹 4가 Price List 7에 매핑되는 것을 알 필요가 없습니다. 모듈이 매핑을 인코딩합니다. 에이전트는 get_tier_price를 호출하고 공개 카탈로그 가격이 아닌 올바른 계약 가격을 받습니다.

재고 가용성 홀드. 모듈은 BigCommerce 재고 수준 체크를 래핑하고 예약 레이어를 추가합니다 — 스토어가 지원하면 BigCommerce 재고에 대해, 그렇지 않으면 권위 있는 재고 카운트가 있는 상위 ERP(NetSuite, Brightpearl)에 대해. 에이전트는 acquire_availability_hold(product_id, quantity, duration_minutes)를 호출하고 RFQ 엔진 아키텍처와 일치하는 TTL이 있는 홀드 토큰을 받습니다. 견적은 사라질 수 있는 라이브 카운트가 아닌 예약된 재고로 뒷받침됩니다.

시맨틱 매핑이 있는 ERP 라이트백. 모듈은 BigCommerce 주문을 수락하고 ERP가 기대하는 형식으로 변환합니다 — GL 코딩, 자회사, 세금 넥서스, 커스텀 필드. 에이전트는 create_erp_order(bigcommerce_order_id)를 호출하고 모듈이 변환, API 서피스 선택(NetSuite용 SuiteTalk REST, RESTlets, SuiteQL, Brightpearl용 Brightpearl API), 인증, 감사 로그를 처리합니다. 에이전트는 OAuth 서명을 구성하거나 API 서피스를 선택하지 않습니다.

검토 가능한 쓰기 계획. 모듈은 멀티스텝 변경을 위한 구조화된 계획을 기안합니다 — "어제 수락된 견적에서 15개 주문을 생성하고 각각을 올바른 GL 코딩으로 NetSuite에 전기하고 BigCommerce에서 이행 태스크를 생성" — 하고 실행 전 인간 검토자에게 라우팅합니다. ACP 경로와 관리형 MCP 서버는 즉시 실행합니다. 모듈은 잘못된 배치가 ERP를 왜곡하는 것을 방지하는 검토 게이트를 추가합니다.

레이트 제한 배치 쿼리. 모듈은 BigCommerce 레이트 제한을 내부적으로 강제합니다 — 도구별 스로틀링, 배치 리스트 쿼리, 그리고 질문당 API 왕복 없이 크로스 객체 분석을 위해 카탈로그와 주문 데이터를 로컬 스토어에 동기화하는 관리 데이터 레이어. 에이전트가 "지난 30일간 NetSuite 전기에 대응하는 것이 없는 Enterprise 고객 그룹의 모든 주문을 보여줘"라고 물으면 모듈은 30분의 페이지네이션 API 호출이 아닌 로컬 레이어에서 답을 반환합니다.

왜 이것이 일반화되는가

BigCommerce 패턴 — 컨슈머 에이전트 경로를 위해 파트너십하는 벤더, REST API를 래핑하지만 비즈니스 의미를 인코딩하지 않는 관리형 MCP 레이어, 사용 가능한 서피스 어느 것도 커버하지 않는 B2B 시맨틱 레이어 — 는 이커머스와 ERP 환경 전반에 나타나는 같은 구조입니다. 갭의 분포가 다를 뿐입니다:

• Shopify는 가장 완전한 퍼스트파티 에이전트 서피스(Storefront MCP, Customer Accounts MCP, UCP)를 구축했지만, B2B 경로 — 고객 티어 가격, 대량 RFQ 견적, NetSuite에 대한 재고 홀드 — 는 퍼스트파티 서피스에 없습니다. Shopify 커넥터 분석이 이를 다룹니다.
• HubSpot은 표준 CRM 객체를 다루는 12개 도구를 가진 퍼스트파티 MCP 서버를 구축했지만, 커스텀 객체, 검토 가능한 쓰기 계획, 헤드리스 인증, 멀티포털 운영은 갭입니다. HubSpot 커넥터 분석이 이를 다룹니다.
• NetSuite는 퍼스트파티 AI Connector Service를 가지지만 자체 FAQ에서 "AI는 환각을 일으킬 수 있습니다. 항상 소스 데이터와 대조하여 결과를 검증하세요"라고 경고합니다. 시맨틱 갭은 어느 GL 계정이 수익을 구성하는지입니다. NetSuite MCP 모듈 분석이 이를 다룹니다.

Anthropic 2026 State of AI Agents Report(500+ 기술 리더, Novo Nordisk, Doctolib, L'Oréal, Shopify의 실제 구현)는 기존 시스템과의 통합을 에이전트 채택의 최대 장벽으로 식별합니다 — 46%의 조직이 그것을 인용하며 데이터 액세스(42%), 보안(40%), 모델 인텔리전스를 상회합니다. 47%가 하이브리드 build-and-buy 접근을 사용합니다: 완전히 사전 빌드된 것이 아니고 모두 인하우스도 아닌, 커스텀 코드로 확장하는 플랫폼입니다. ACP 경로는 BigCommerce의 "사는" 절반입니다. 관리형 MCP 서버는 스토어 데이터 액세스의 "사는" 절반입니다. 커스텀 모듈은 "짓는" 절반입니다 — 에이전트를 컨슈머 체크아웃이 아닌 B2B 운영에 유용하게 만드는 시맨틱 레이어.

BigCommerce와 Stripe의 파트너십은 건전한 제품 결정이었습니다 — Stripe는 대부분의 이커머스 플랫폼이 자체 구축할 수 있는 것보다 결제 인프라와 사기 탐지를 더 잘 처리합니다. 그러나 파트너십은 컨슈머 경로를 커버합니다. B2B 경로 — 바이어가 협상된 가격을 가진 구매 코디네이터이고, 재고는 보고가 아닌 예약되어야 하며, 주문은 올바른 GL 코딩과 자회사 매핑으로 ERP에 도달해야 하는 — 는 이 시리즈의 다른 모든 커넥터가 요구하는 것과 동일한 커스텀 모듈 레이어를 요구합니다. MCP Module Code Standard가 구조를 정의합니다. BigCommerce 커넥터는 파트너십 경로 케이스의 참조 구현입니다 — 벤더가 컨슈머 에이전트 레이어를 외주하고 B2B 시맨틱 레이어를 통합 팀에 남긴 케이스.

스토어프론트에서 BigCommerce, ERP에 NetSuite 또는 Brightpearl, 4개 고객 그룹 가격 티어를 운영하는 B2B 유통업체는 Price List Assignment API를 통해 바이어의 계약 가격을 해결하고, ERP 재고 카운트에 대해 원자적 가용성 홀드를 획득하고, 견적 시점에 상업 조건을 스냅샷하고, 올바른 GL 코딩과 자회사 매핑으로 수락된 주문을 ERP에 라이트백하는 에이전트를 얻습니다 — 모든 도구 호출은 레이트 제한되고 로깅되며, 예외는 인간 검토자에게 라우팅됩니다. 그 빌드는 4단계 메서드의 Phase 2-3이며 일반적으로 5-8주 내에 라이브됩니다.

스코프드 빌드를 요청하세요. 1주 Discovery. 시스템 인벤토리, 워크플로 맵, 고정 스코프를 받습니다 — 우리와 빌드하든 아니든.