스토어를 운영하고 있다면, 에이전트 기반 커머스(agentic-commerce) 물결은 아마도 이번 봄 Shopify의 변경 로그 형태로 당신의 받은 편지함에 도착했을 것입니다. Shopify의 Spring '26 릴리스는 **에이전트 스토어프론트(Agentic Storefronts)**와 구글과 함께 **범용 커머스 프로토콜(Universal Commerce Protocol, UCP)**을 출시했습니다. UCP는 오픈 표준이며 (Amazon, Meta, Microsoft, Salesforce, Stripe, Etsy, Target, Wayfair가 지원함) AI 에이전트가 쇼핑객을 대신하여 제품을 검색하고, 장바구니를 만들고, 결제를 완료할 수 있도록 합니다. Hydrogen를 사용한다면, 모든 스토어프론트는 기본적으로 proxyStandardRoutes가 활성화된 /api/mcp에서 MCP 엔드포인트를 노출합니다. 이전의 Storefront Catalog MCP는 UCP에 통합되었으며, 레거시 엔드포인트는 6월 15일까지만 유지됩니다.

이는 정말로 큰 변화이며, Shopify에서 판매한다면 카탈로그가 이를 통해 흐르도록 확실히 해야 합니다. 하지만 UCP가 실제로 에이전트 구동을 가능하게 하는 것이 무엇인지 정확히 아는 것이 중요합니다. 왜냐하면 헤드라인(

그 중 어느 것도 "카탈로그를 검색하고 결제하기"를 수행하지 않습니다. 그것들은 카탈로그 위(또는 옆)에 구축된 맞춤형 인터랙티브 플로우 (bespoke interactive flows)이며, 고객이 일반적인 리스팅 (generic listing) 대신 _당신_을 선택하게 만드는 빈번한 이유이기도 합니다. UCP를 통해 스토어를 구동하는 에이전트는 이미 원하는 것을 알고 있는 SKU를 구매할 수 있습니다. 하지만 어떤 SKU를 선택할지 결정하도록 돕는 퀴즈를 안정적으로 실행하거나, 보증 청구 (warranty claim)를 시작하거나, B2B 견적 (B2B quote)을 요청할 수는 없습니다. 왜냐하면 UCP는 이러한 것들을 설명하지 않으며, 다른 어떤 것도 에이전트에게 그것들이 존재한다는 사실을 알려주지 않기 때문입니다.

그리고 그것이 바로 /api/mcp를 무료로 상속받는 Shopify-on-Hydrogen 사례입니다. 다음의 두 가지 큰 그룹은 그렇지 못합니다:

1. 커스텀 / 비-Hydrogen 헤드리스 스토어프론트 (Custom / non-Hydrogen headless storefronts). "자체 프론트엔드 상의 진정한 헤드리스 (Truly headless on your own front end)"라는 의미는 표준 경로 (standard routes)를 무료로 제공받지 못한다는 뜻이며, 에이전트 인터페이스 (agent surface)를 직접 재구축해야 함을 의미합니다.
2. Shopify를 사용하지 않는 모든 곳. 웹의 대부분은 하단에 Shopify의 데이터 그래프 (data graph)가 전혀 없는 상태로 판매, 예약 또는 온보딩 (onboarding)을 수행합니다.

Shopify 스토어의 커스텀 플로우, 헤드리스 프론트엔드, 그리고 비-Shopify 사이트라는 이 세 가지 경우 모두에서 질문은 "내 카탈로그가 UCP에 있는가"가 아닙니다. 질문은 "에이전트가 사람이 할 수 있는 것과 동일한 방식으로 내 사이트의 인터랙티브한 부분들을 조작할 수 있는가?"입니다.

그것이 바로 WebMCP가 채워야 할 간극입니다

WebMCP (2026년 6월 기준 Chrome 149 오리진 트라이얼 (origin trial)에 포함된 navigator.modelContext API)는 UCP의 경쟁자가 아니라 상호 보완적인 존재입니다. UCP가 스토어 전반에 걸쳐 커머스 (commerce) 작업을 표준화한다면, WebMCP는 _단일 사이트_가 그것이 무엇이든 자신만의 도구 (tools)를 선언할 수 있게 하여, 브라우저 내의 에이전트가 당신의 DOM을 추측하는 대신 직접 호출할 수 있도록 합니다.

제가 유지하고 있는 멘탈 모델 (mental model)은 다음과 같습니다:

UCP는 공유된 커머스 레일 (commerce rails)입니다. WebMCP는 당신의 스토어프론트가 수행하는 기능 중 일반적인 커머스 프리미티브 (commerce primitive)가 아닌 모든 것을 위한 도구 인터페이스 (tool surface)입니다.

이들은 깔끔하게 결합됩니다. 에이전트(agent)는 UCP를 사용하여 물건을 구매하고, 귀하의 WebMCP 도구(tools)를 사용하여 무엇을 살지, 그리고 구매 _전후에 어떤 일이 일어날지_를 결정하는 맞춤형 작업(bespoke work)을 수행합니다. 구성기(configurator)는 configure_bundle 도구가 됩니다. 사이즈 추천 퀴즈(fit quiz)는 recommend_size가 됩니다. B2B 흐름은 request_quote가 됩니다. 각각은 귀하의 UI가 이미 호출하고 있는 함수에 대한 얇고 타입이 지정된(typed) 프런트 도어(front door) 역할을 합니다:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "recommend_size",
...

두 가지 요소가 이를 저렴하고 안전하게 만들며, 이는 UCP 도입을 합리적으로 만드는 두 가지 요소와 동일합니다:

• 기능 감지 (Feature-detected). 전체 인터페이스(surface)는 if ("modelContext" in navigator) 뒤에 위치합니다. 해당 API가 없는 모든 브라우저(현재 거의 모든 브라우저가 해당됨)에서는 아무런 동작도 수행하지 않는 no-op 상태가 됩니다. 아무것도 망가지지 않습니다.
• 재사용하되, 재구축하지 마십시오 (Reuse, don't rebuild). WebMCP 도구는 기존 UI가 호출하는 것과 정확히 동일한 함수(sizeEngine, productSearch, startReturn)를 호출해야 합니다. 만약 에이전트를 위해 새로운 비즈니스 로직을 작성하고 있다면, 귀하는 동기화가 어긋나게 되는 비용이 많이 드는 방식을 선택한 것입니다. 그렇게 하지 마십시오.

솔직한 주의 사항 (UCP와 동일)

2026년 6월 기준으로, 아직 어떤 주류 에이전트(mainstream agent)도 귀하의 페이지에서 navigator.modelContext를 호출하지 않습니다. ChatGPT Agent, Claude, Gemini 모두 마찬가지입니다. (UCP는 커머스 측면에서 더 앞서 나가고 있는데, 이는 에이전트와 프로토콜이 동일한 기업들에 의해 구축되고 있기 때문이지만, 일반적인 브라우저 도구 호출(tool-call) 경로 역시 출시된 에이전트들에는 아직 연결되어 있지 않습니다.) 따라서 이것은 "오늘 당장 하지 않으면 내일 매출을 잃게 된다"는 뜻이 아닙니다. 다음과 같습니다: 에이전트 기반 커머스(agentic-commerce) 구축은 플랫폼들로부터 명확하게 하향식(top-down)으로 진행되고 있으며, 귀하의 맞춤형 흐름을 기능 감지형 도구로 노출하는 데 드는 비용은 단 몇 시간(an afternoon) 정도이며, 그 보상은 귀하가 날짜를 예측할 수 없는 바로 그 시점에 찾아올 것입니다.

제가 하나 더 덧붙이고 싶은 것은 바로 **계측(instrument it)**입니다. 첫날부터 모든 도구 호출(tool invocation) — 어떤 도구인지, 정제된 인자(sanitized args), 성공 여부, 지연 시간(latency) — 을 기록하세요. 에이전트가 UCP 결제를 통해 유입되든 직접적인 WebMCP 호출을 통해 유입되든, 여러분은 대시보드를 통해 이를 확인하고 싶을 것입니다. 6개월 뒤에 청구서의 이상 징후를 보고서야 알게 되는 상황은 피해야 합니다. "에이전트가 내 스토어를 운영하고 있는가, 그리고 어떤 흐름(flow)을 사용하는가?"라는 질문만이 이 상황을 막연한 추측에서 관리 가능한 베팅(managed bet)으로 바꿔줄 유일한 질문입니다.

결론 (Bottom line)

Shopify에서 판매하고 있다면, 카탈로그를 UCP에 등록하세요. 그것이 바로 커머스 레일(commerce rails)이며, 이제는 실재하는 인프라입니다. 하지만 "내 카탈로그를 에이전트가 구매할 수 있다"는 것이 "내 스토어를 에이전트가 운영할 수 있다"는 의미와 같다고 착각하지 마세요. 여러분의 스토어프론트를 차별화하는 요소들 — 설정기(configurators), 퀴즈, 예약, B2B, 구매 후 단계(post-purchase) — 은 UCP의 표준화된 프리미티브(primitives) 외부에 존재하며, 커스텀 사이트나 비(non)-Shopify 사이트의 모든 것 또한 마찬가지입니다. 이것이 바로 WebMCP가 해결해야 할 문제의 나머지 절반입니다. 이러한 흐름들을 타입이 지정된 도구(typed tools)로 노출하고, 핸들러(handlers)가 어긋나지 않도록 기존 핸들러를 재사용하며, 첫 번째 에이전트가 들어오는 것을 확인할 수 있도록 사용량을 측정(meter)하세요.

공지: 저는 위 내용 중 WebMCP 측면을 수행하는 오픈 소스(MIT) 한 줄 스크립트인 Latch에서 일하고 있습니다. Latch는 사이트의 기존 검색, 장바구니, 양식 및 커스텀 흐름을 기능 감지(feature-detected) 방식의 navigator.modelContext 도구(유효한 스키마, 기존 핸들러 재사용)로 노출합니다. 선택 사항인 호스팅 티어는 측정(meter) 역할을 하여, 어떤 에이전트가 여러분의 도구를 호출하고 무엇을 하는지 보여줍니다. 표준적인 방식만을 원하신다면, WebMCP 가이드는 특정 벤더에 종속되지 않으며 코드는 GitHub에 공개되어 있습니다. 이는 UCP를 대체하는 것이 아니라 보완하는 것입니다. 특히 헤드리스(headless) 또는 비(non)-Shopify 스토어프론트를 운영하시는 분들과 댓글을 통해 의견을 나누고 싶습니다.