Commerce.com과 Cloudflare가 거의 10만 개 도메인에 WebMCP를 제공한 사례는 AI 쇼핑 에이전트가 상점과 상호작용하는 방식을 보여준다. 에이전트가 화면을 읽고 버튼의 의미를 추측하는 대신, 상점이 제공하는 상품 검색과 장바구니 도구를 호출하도록 만드는 접근이다. 개발자가 주목할 부분은 연결 규모뿐 아니라 브라우저 세션, 기존 MCP 서버, 상점별 설정을 어떻게 연결했는지다.

다만 제공 범위와 실제 이용 가능 범위는 구분해야 한다. 원문에서 WebMCP는 초기 미리보기 단계의 실험적인 브라우저 표준 제안으로 소개된다. 거의 10만 개 도메인에 기능을 제공했다는 설명을 모든 고객의 브라우저에서 즉시 작동하거나 구매 전 과정이 자동화됐다는 뜻으로 받아들여서는 안 된다.

화면의 버튼 대신 상점이 정의한 도구를 호출한다

일반적인 브라우저 기반 쇼핑 에이전트는 페이지의 HTML이나 화면을 해석해 상품을 찾고, 옵션을 선택하고, 장바구니 버튼을 누른다. 이 과정에서는 쿠키 안내창이나 상품 옵션 메뉴가 장애물이 될 수 있다. 테마 변경으로 버튼 위치나 구조가 달라지면 이전에 성공했던 동작도 실패할 수 있다.

WebMCP는 페이지에서 사용할 수 있는 작업을 구조화된 도구로 노출한다. 원문은 상품 검색 도구인 search_products와 장바구니 추가 도구인 add_to_cart를 예로 든다. 에이전트가 페이지의 의미를 매번 추측하는 대신 필요한 도구와 입력값을 확인해 호출하는 방식이다.

예를 들어 사용자가 예산과 사이즈 조건에 맞는 신발을 요청하면, 에이전트는 검색 도구에 조건을 전달하고 선택한 상품을 장바구니에 넣을 수 있다. 다만 예시에 등장한 검색 조건이 모든 상점에서 동일하게 지원된다는 보장은 없다. 개별 상점의 도구 정의가 어떤 필터와 상품 옵션을 받는지 확인해야 실제 구현 범위를 판단할 수 있다.

Cloudflare는 이 방식이 화면을 탐색하는 작업보다 속도, 토큰 사용량, 신뢰성 측면에서 유리하다고 설명한다. 그러나 제공된 자료에는 비교 실험의 구체적인 수치가 없다. 적용 효과를 평가할 때는 같은 상품과 조건으로 검색 성공률, 옵션 선택 오류, 장바구니 반영 여부를 비교하는 편이 정확하다.

브라우저 안의 WebMCP와 서버 측 MCP가 맡는 역할

Commerce.com은 WebMCP를 기존 서버 측 MCP와 함께 사용한다. 서버 측 MCP는 에이전트가 상점에 직접 연결하는 흐름을 지원하고, WebMCP는 사용자가 상점을 방문한 브라우저 안에서 작업하는 에이전트를 지원한다. 여러 상점을 비교하는 비서와 현재 열린 상점에서 구매를 돕는 비서는 접속 경로가 다르므로, 어느 경로를 지원해야 하는지부터 정해야 한다.

원문에 따르면 Commerce.com은 두 경로에서 같은 쇼핑 도구 집합을 사용한다. Cloudflare는 Commerce.com의 백엔드 MCP 서버와 방문자의 브라우저 사이에서 도구 정의와 요청을 전달하는 엣지 계층을 맡는다. 상품 검색이나 장바구니 처리의 구체적인 로직은 판매자 측에서 계속 통제하는 구조다.

이 사례는 기존 MCP 서버를 가진 개발자에게 특히 참고할 만하다. 브라우저용 기능을 별도로 늘리기 전에 기존 서버의 도구 정의를 재사용할 수 있는지 살펴볼 수 있기 때문이다. 반대로 MCP 서버가 없는 서비스라면 엣지에서 스크립트를 제공하는 것만으로 상품 검색과 주문 로직까지 생기는 것은 아니다. 이번 연동은 Commerce.com의 백엔드 도구를 전제로 한다.

같은 가격과 장바구니를 보되 최종 구매는 사용자가 진행한다

이번 연동에서 도구는 상점 도메인에 열린 사용자의 활성 브라우저 세션 안에서 실행된다. 원문은 이를 통해 에이전트가 사용자와 같은 가격과 장바구니를 본다고 설명한다. 로그인 여부나 현재 장바구니 상태가 중요한 쇼핑에서는 별도 세션을 사용하는 자동화와 구별되는 부분이다.

원문은 이 구조에서 자격 증명을 제삼자에게 전달하지 않으며, 방문도 판매자 사이트에서 이루어진다고 설명한다. 다만 이 설명만으로 모든 에이전트 제품의 데이터 처리 조건까지 확인된 것은 아니다. 도구 호출에 담기는 검색어와 상품 정보, 실행 결과가 사용하는 에이전트와 서버의 로그에 어떻게 남는지는 각각 확인할 항목이다.

또한 장바구니에 상품을 담는 동작과 구매를 확정하는 동작은 구분된다. 소개된 Commerce.com 흐름에서는 사용자가 직접 체크아웃을 진행한다. 따라서 이 발표를 근거로 에이전트가 결제까지 자율적으로 완료한다고 설명하면 범위를 넘어선다. 개인 사용자는 장바구니의 수량과 옵션, 최종 가격을 확인하고 구매를 이어가는 흐름으로 이해하면 된다.

거의 10만 개 도메인을 연결하면서 상점별 선택권을 남긴 방식

대규모 적용에서 해결해야 했던 문제는 설정의 단위였다. 원래 WebMCP 설정은 도메인 존 전체를 켜거나 끄는 방식이었다. 그런데 Commerce.com은 Cloudflare for SaaS를 이용해 공유 존에서 다수 판매자의 개별 도메인을 운영한다. 플랫폼 전체에 기능을 제공하면서 특정 판매자는 제외할 수 있는 장치가 필요했다.

두 회사는 Cloudflare의 Configuration Rules와 사용자 지정 호스트명 메타데이터를 연결했다. Commerce.com이 기본 존에서 WebMCP를 활성화하고, 개별 판매자의 메타데이터에 비활성화 의사가 표시되면 엣지 규칙이 해당 상점의 WebMCP를 끄는 방식이다. 판매자는 Commerce.com 대시보드의 설정으로 참여를 중단할 수 있다.

원문에 따르면 제외된 상점에는 WebMCP용 스크립트가 삽입되지 않는다. 제외 여부도 페이지를 제공하기 전 엣지에서 판단하므로, 이를 확인하기 위한 원격 조회나 추가 지연이 발생하지 않는다고 설명한다. 이는 해당 제외 처리 구조에 관한 설명이며, 기능을 활성화한 모든 상점의 전체 성능 비용이 없다는 의미는 아니다.

여러 고객의 도메인을 관리하는 개발자는 이 구성을 참고해 설정의 소유자를 명확히 할 수 있다. 플랫폼의 기본값과 개별 상점의 선택이 충돌할 때 무엇이 우선하는지, 설정 변경이 어느 호스트명에 적용되는지, 기능을 끈 뒤 스크립트가 실제로 사라지는지가 검증 대상이다.

MCP 주소와 미지원 브라우저에서 생기는 차이

실제 연동에서는 서버 주소도 조정이 필요했다. Cloudflare의 mcp-server-client 도구 묶음은 처음에 MCP 서버가 /mcp 경로에 있다고 가정했지만, Commerce.com의 서버는 /api/mcp에 있었다. 이를 지원하기 위해 존 수준에서 MCP URL을 지정하는 설정이 추가됐다.

따라서 비슷한 구성을 검토한다면 서버가 존재하는지만 확인해서는 부족하다. 브라우저에 전달되는 주소가 실제 도구 서버를 가리키는지, 공유 존에 속한 각 상점의 요청이 올바른 상점으로 연결되는지 확인해야 한다. 주소를 바꿨을 때 상품 검색과 장바구니 작업까지 정상적으로 이어지는지도 따로 점검할 필요가 있다.

브라우저 지원 역시 적용 범위를 가른다. 원문은 실험용 Chrome 플래그, Chrome Origin Trials, 일부 에이전트 브라우저와 Cloudflare Kitesurf 같은 개발 환경을 이용 경로로 제시한다. 이 경로들은 일반 사용자의 기본 브라우저 환경과 같지 않다. 학생이나 연구자가 실험 결과를 공유할 때는 브라우저 종류와 버전, 활성화한 실험 기능을 함께 기록해야 재현 가능성을 판단할 수 있다.

원문은 상점의 MCP 서버가 오프라인이거나 고객 브라우저가 WebMCP를 지원하지 않으면 스크립트가 종료되고 상점은 정상적으로 로드되는 대체 동작을 설명한다. 실제 서비스에서도 이를 확인하려면 지원 환경의 성공 사례뿐 아니라 미지원 브라우저와 서버 장애 상황에서 상품 탐색이 계속 가능한지 살펴봐야 한다.

개인 프로젝트와 연구에서 비교할 구체적인 작업

개인 개발자에게 적절한 출발점은 상품 수가 적은 테스트 상점에서 하나의 구매 보조 흐름을 확인하는 것이다. 검색어만으로 찾는 상품, 사이즈나 색상 선택이 필요한 상품, 재고가 없는 상품을 구분하면 도구가 처리하는 범위와 사람이 개입해야 하는 지점을 파악하기 쉽다.

  1. 같은 검색 조건으로 화면 조작 방식과 WebMCP 방식이 어떤 상품을 반환하는지 비교한다.
  2. 검색 결과의 상품과 실제 장바구니에 담긴 상품의 옵션 및 수량이 일치하는지 확인한다.
  3. 도구가 오류를 반환했을 때 에이전트가 성공한 것으로 오해하거나 같은 상품을 중복 추가하지 않는지 확인한다.
  4. 기능을 비활성화한 상점과 미지원 브라우저에서도 기존 구매 경로가 유지되는지 확인한다.

이 항목들은 발표에서 모두 검증됐다고 제시된 결과가 아니라, 적용 전 확인할 기준이다. 특히 장바구니 변경은 검색과 달리 사용자 상태를 바꾸는 작업이다. 연구자는 검색 정확도와 상태 변경의 정확도를 별도로 평가하고, 개인 사용자는 에이전트의 완료 안내와 실제 장바구니를 대조하는 편이 좋다.

비용과 전환 가치는 작업량을 기준으로 따져야 한다

제공된 자료에는 일반 사용자가 적용할 수 있는 구체적인 가격표, 플랜별 권한, 사용량 한도가 충분히 제시돼 있지 않다. 따라서 코드 작성 없이 기능을 제공한다는 설명을 무료 제공이나 모든 계정의 즉시 사용 가능 조건으로 확대해서는 안 된다. Commerce.com 판매자에게 제공되는 설정과 독립 사이트가 Cloudflare에서 직접 구성할 때의 조건도 구분해 확인해야 한다.

비용 비교에는 에이전트의 토큰 사용량뿐 아니라 MCP 서버 요청, 도구 유지보수, 오류 처리에 드는 작업도 포함하는 것이 좋다. 화면 탐색 횟수가 줄어도 상품 옵션 검증과 장바구니 오류 복구에 많은 개입이 필요하다면 기대한 절감 효과가 작을 수 있다. 원문이 제시하는 방향성과 자신이 운영하는 상점의 측정 결과를 연결해야 한다.

이미 안정적인 API나 서버 측 MCP로 필요한 작업을 처리하고 있다면, 브라우저 세션의 가격과 장바구니를 함께 사용하는 것이 추가로 필요한지 판단하면 된다. 반대로 테마 변경 때마다 화면 자동화가 깨지는 상점이라면 구조화된 도구의 효과를 비교할 이유가 크다. 선택 기준은 새로운 표준을 지원한다는 사실보다 실제로 줄어드는 실패와 수정 작업이다.

출처와 검증

이 글은 2026년 10월 21일 공개된 Cloudflare Blog의 How Commerce.com and Cloudflare are getting storefronts ready for AI agents에 제공된 내용을 바탕으로 작성했다. 거의 10만 개 도메인이라는 적용 규모, 브라우저 세션을 이용하는 구조, 상점별 제외 설정과 사용자 체크아웃 흐름은 해당 발표의 설명이다.

구체적인 가격과 계정별 제공 조건, 현재 지원 브라우저의 범위, 개별 상점 도구의 입력값은 실제 적용 시점에 다시 확인해야 한다. 속도와 비용 절감에 관한 정량적 비교, 개별 서비스의 보안 검증을 직접 수행한 결과는 포함하지 않았다.