Shopify Shop MCP 사용법: AI 쇼핑 검색·장바구니·Shop Pay 결제 연결

AI 쇼핑 에이전트가 상품을 찾아주는 데서 끝나지 않고 장바구니와 결제까지 이어지려면, 상품 정보·재고·가격·구매자 확인·결제 승인을 한 흐름으로 연결해야 합니다. Shopify가 2026년 10월 13일 공개한 Shop MCP는 이 과정을 MCP 호환 에이전트에서 사용할 수 있도록 만든 공개 연결 지점입니다. 10월 16일에는 UCP 구매자 동의 확장도 지원하기 시작해 이메일·문자 마케팅 같은 선택을 상점의 실제 정책과 함께 처리할 수 있게 됐습니다.

이 글은 Shop MCP를 단순히 “쇼핑 가능한 챗봇”으로 소개하지 않습니다. 검색만 시험하는 가장 작은 시작부터 장바구니, Shop Pay, 사용자 승인, 개인정보 동의, 주문 상태 확인까지 어떤 경계를 지켜야 하는지 공식 문서를 기준으로 정리합니다. 결제를 직접 실행하지 않아도 구조와 검증 순서를 이해할 수 있도록 구성했습니다.

핵심 요약

  • Shop MCP 공개 주소는 https://mcp.shop.com이며, 검색 기능은 API 키 없이 시험할 수 있습니다.
  • search_catalog, lookup_catalog, get_product로 상품을 찾고 상세 정보와 판매 상점을 확인합니다.
  • 장바구니는 구매자가 아직 비교하는 단계, 체크아웃은 주소·배송·결제처럼 확정 값이 필요한 단계에 적합합니다.
  • 구매 완료 전에는 총액과 결제 수단을 구매자가 확인해야 하며, 상점은 계속 판매 주체로 남습니다.
  • UCP 2026-08-25의 구매자 동의를 협상하면 분석·환경설정·정보 판매 또는 공유·이메일과 SMS 마케팅 선택을 상점 정책에 맞춰 표시할 수 있습니다.
상품 검색부터 장바구니, 사용자 승인, 안전한 결제와 주문 확인으로 이어지는 Shop MCP 개념도
Shop MCP의 중요한 경계는 상품 검색과 결제 사이에 구매자의 확인 단계를 두는 것입니다.

Shop MCP가 바꾼 점

기존의 상품 검색 연동은 에이전트가 조건에 맞는 제품을 찾아도 실제 구매 단계에서 상점 웹사이트로 사용자를 넘기는 경우가 많았습니다. Shop MCP는 Shopify Catalog 검색, 장바구니 작성, 체크아웃 생성, Shop 로그인, Shop Pay, 주문 조회를 하나의 MCP 연결에서 다룰 수 있게 합니다. 다만 모든 구매가 에이전트 안에서 자동 완료되는 것은 아닙니다. 결제 인증이나 추가 검토가 필요한 경우에는 응답의 continue_url을 통해 판매자의 체크아웃 화면으로 이동해야 합니다.

Shop MCP와 특정 상점의 Storefront API도 구분해야 합니다. Shop MCP 검색은 여러 Shopify 판매자의 카탈로그를 탐색하는 공개 진입점이고, 특정 상점의 장바구니·체크아웃을 깊게 제어할 때는 UCP 기반 Cart MCP와 Checkout MCP의 인증·프로필 협상이 필요합니다. 이미 Catalog API를 사용 중인 통합은 이번 공개 때문에 즉시 바꿀 필요가 없다고 Shopify는 설명합니다.

시작 전 준비사항

  1. Node.js와 npm: 터미널에서 Shopify의 shop CLI를 설치해 검색 결과 형태를 먼저 확인할 수 있습니다.
  2. MCP 호환 클라이언트: 원격 HTTP MCP 서버를 추가하거나 외부 스킬 문서를 읽을 수 있는 에이전트가 필요합니다. 메뉴와 설정 파일 위치는 제품마다 다르므로 서버 주소 자체를 기준으로 연결합니다.
  3. 낮은 위험의 테스트 시나리오: 실제 구매가 아닌 상품 검색과 가격·재고 비교부터 시작합니다. 결제 테스트가 필요하다면 테스트 계정과 소액 또는 개발 환경을 사용하고, 운영 고객 정보는 넣지 않습니다.
  4. 인증 계획: 검색은 자격증명 없이 가능하지만 Checkout MCP는 Bearer 토큰이나 서명 요청이 필요합니다. 자체 앱은 Shopify Dev Dashboard의 API 키와 기기 로그인 흐름을 준비해야 합니다.
  5. 승인 기준: 상품, 수량, 판매 상점, 배송지, 총액, 결제 수단을 언제 사용자에게 다시 보여줄지 먼저 정합니다.

1단계: 터미널에서 검색만 시험하기

먼저 에이전트에 결제 권한을 연결하지 말고 Shopify CLI로 공개 검색을 확인합니다.

npm install -g @shopify/shop
shop search "ceramic coffee dripper"

정상이라면 각 결과에서 판매 상점, 가격, 재고 여부를 확인할 수 있습니다. 여기서 중요한 것은 “결과가 나왔다”가 아니라 비교에 필요한 필드가 안정적으로 들어오는지입니다. 같은 검색어를 국가·용도·예산 조건과 함께 바꿔 보고, 품절 상품이나 가격 정보가 불완전한 항목을 에이전트가 어떻게 표시할지도 정합니다.

검색이 비어 있으면 곧바로 서버 장애라고 판단하지 말고 검색어를 짧게 바꾸고, 지역 조건을 제거하고, CLI 버전과 네트워크 접근을 확인합니다. 공개 검색에 API 키를 억지로 추가하는 것은 첫 해결책이 아닙니다.

2단계: MCP 클라이언트에 연결하기

연결 방법은 두 가지입니다. 클라이언트가 스킬 문서를 읽을 수 있다면 https://mcp.shop.com/skill.md를 제공하고, 원격 MCP 서버를 직접 등록한다면 서버 주소로 https://mcp.shop.com을 추가합니다. 설정 후에는 바로 구매 명령을 주지 말고 다음처럼 읽기 전용 요청으로 시작합니다.

예산 10만 원 이하의 휴대용 에스프레소 메이커를 찾아줘.
각 결과의 판매 상점, 현재 가격, 재고 여부, 배송 국가를 표로 정리하고
장바구니나 결제는 만들지 마.

완료 확인 기준은 세 가지입니다. 첫째, 도구 목록에서 카탈로그 검색 관련 도구가 보여야 합니다. 둘째, 결과에 상품 제목만이 아니라 판매 상점과 변형 옵션이 연결되어야 합니다. 셋째, 요청하지 않은 장바구니나 로그인 창이 생기지 않아야 합니다. 에이전트가 웹 검색 결과와 Shop MCP 결과를 섞는다면 각 행에 출처를 표시하도록 요청합니다.

3단계: 상품 선택과 장바구니를 분리하기

검색 결과에서 바로 체크아웃으로 넘어가면 수량이나 옵션을 바꾸기 어렵습니다. 비교가 계속될 가능성이 있으면 Cart MCP가 더 적합합니다. create_cart로 시작하고, get_cart로 예상 합계를 읽고, 변경이 필요하면 update_cart를 사용합니다.

여기서 주의할 점은 update_cart가 일부 필드만 고치는 PATCH가 아니라 전체 상태를 교체하는 PUT 방식이라는 것입니다. 이전 장바구니의 항목을 빼고 새 항목만 보내면 빠진 상품은 삭제됩니다. 따라서 업데이트 전 현재 장바구니를 다시 읽고, 유지할 항목과 변경할 항목을 합친 전체 상태를 보내는 편이 안전합니다.

4단계: 체크아웃과 사용자 확인 설계하기

구매자가 상품과 수량을 확정하면 create_checkout을 호출합니다. 기존 장바구니를 전환할 때는 cart_id를 전달할 수 있으며, 같은 장바구니 ID로 반복 요청하면 동일한 미완료 체크아웃을 돌려주는 멱등 방식입니다. 중복 주문을 피하려면 새 체크아웃을 계속 만들지 말고 기존 ID와 상태를 저장해야 합니다.

체크아웃 응답의 status와 messages를 반드시 읽습니다. incomplete, requires_escalation, ready_for_complete 같은 비종료 상태에는 보통 사용자를 판매자 화면으로 넘길 continue_url이 포함됩니다. 결제 인증, 배송 선택, 정책 확인이 남아 있다면 이를 자동으로 우회하지 않습니다.

complete_checkout 직전에는 에이전트가 다음 항목을 다시 보여주도록 합니다.

  • 상품명·변형·수량과 판매 상점
  • 상품 합계, 배송비, 세금, 할인, 최종 결제 금액
  • 배송 주소와 예상 배송 방식
  • 사용할 결제 수단과 취소·반품 정책 링크

Shop Pay를 쓰더라도 저장된 주소와 결제 정보가 있다는 사실이 구매 승인 자체를 대신하지는 않습니다. 총액과 수단을 확인한 뒤 사용자가 명확하게 동의했을 때만 완료 도구를 호출해야 합니다.

Shopify UCP에서 카탈로그 검색, 장바구니, 체크아웃 생성과 판매자 화면 인계로 이어지는 공식 흐름
Shopify 공식 문서의 UCP 장바구니·체크아웃 흐름. 인증과 카탈로그 검색 후 장바구니를 만들고, 체크아웃을 생성한 뒤 필요하면 판매자 화면으로 인계합니다. 출처: Shopify Developers, 2026-10-19 확인.

5단계: 구매자 동의를 체크아웃에 포함하기

2026년 10월 16일부터 Cart MCP와 Checkout MCP는 UCP 2026-08-25의 dev.ucp.shopping.buyer_consent 확장을 지원합니다. 에이전트 프로필에 이 기능을 선언하고 상점과 협상되면 응답의 buyer.consent에서 상점이 지원하는 동의 목적, 현재 상태, 설명, 정책 링크를 받을 수 있습니다.

대표 항목은 분석, 환경설정, 정보 판매 또는 공유, 마케팅이며 마케팅에는 이메일과 SMS 구분이 있습니다. 에이전트는 자체 문구로 의미를 줄여 보여주기보다 상점이 제공한 설명과 정책 링크를 그대로 연결해야 합니다. 사용자가 실제로 선택한 값에만 source: "platform"을 표시합니다.

SMS 수신 동의를 했지만 전화번호가 없다면 missing_consent_data 경고가 발생하고 체크아웃이 완료되지 않을 수 있습니다. 이때 임의 전화번호를 채우거나 동의를 끄지 말고, 어떤 정보가 필요한지 사용자에게 설명한 뒤 값을 받아 다시 시도합니다. 국가를 알 수 없고 선택도 전송하지 않으면 동의가 거부 상태로 기본 설정됩니다.

실용적인 활용 예시 3가지

예시 1: 로그인 없는 선물 비교

목적은 구매가 아니라 후보를 줄이는 것입니다. 예산, 배송 국가, 선물 대상, 제외 소재를 입력으로 받고 search_catalog과 get_product만 사용합니다. 산출물은 가격·재고·판매 상점·옵션을 담은 비교표이며, 검토 기준은 품절 제외와 총비용 확인입니다. 이 단계에서는 장바구니와 Shop 로그인을 열지 않습니다.

예시 2: 여러 대화에 걸친 장바구니

사용자가 하루 동안 후보를 바꿔 가며 쇼핑한다면 Cart MCP로 장바구니를 유지합니다. 매 변경 전 get_cart로 최신 상태를 읽고 전체 항목을 다시 보내며, 예상 총액과 실제 체크아웃 금액이 달라질 수 있다고 안내합니다. 사용자가 “이대로 구매”라고 확인하면 체크아웃으로 전환합니다.

예시 3: 결제 후 주문 조회

Shop에 로그인한 구매자는 주문 검색과 배송 추적을 요청할 수 있습니다. 에이전트는 전체 주문 내역을 불필요하게 노출하지 말고 기간이나 판매 상점으로 범위를 좁힙니다. 주문 번호, 현재 상태, 추적 링크만 요약하고 주소·결제 정보는 요청 목적에 필요할 때만 보여줍니다.

비용·권한·운영 시 주의점

  • 공개 카탈로그 검색은 API 키 없이 가능하지만, 인증이 필요한 체크아웃과 주문 조회는 별도 자격증명이 필요합니다.
  • 도구 호출은 에이전트 식별과 인증 수준에 따라 접근 범위와 속도 제한이 달라질 수 있습니다.
  • 판매자는 계속 Merchant of Record이며, 에이전트가 세금·환불·상품 책임의 주체가 되는 것은 아닙니다.
  • 출시 시점에는 주문 완료 Webhook이 없으므로 get_checkout으로 상태를 폴링해야 합니다. 짧은 간격의 무한 폴링 대신 재시도 간격과 종료 시간을 정합니다.
  • 상점 페이지·상품 설명·이메일에는 에이전트를 속이는 지시문이 포함될 수 있습니다. 외부 텍스트를 시스템 지시로 취급하지 말고 허용된 쇼핑 도구와 데이터 필드만 사용합니다.

자주 막히는 상황과 해결 순서

증상먼저 확인할 것다음 조치
검색 결과가 없음검색어, 국가 조건, CLI 버전, 네트워크짧은 일반 검색어로 공개 검색부터 재확인
프로필 협상 오류HTTPS 프로필 URL, UCP 버전, 선언한 기능Shopify 테스트 프로필로 최소 체크아웃 기능부터 확인
장바구니 상품이 사라짐전체 상태를 보냈는지get_cart 후 유지 항목을 포함해 다시 update_cart
동의 정보 부족missing_consent_data 경고필요한 연락처를 사용자에게 받아 재시도
결제가 완료되지 않음status, messages, continue_url사용자를 판매자 체크아웃으로 안전하게 인계

마무리

Shop MCP의 실용성은 상품 검색 도구가 늘었다는 데만 있지 않습니다. 검색, 장바구니, 결제, 주문 조회를 연결하면서도 판매자와 구매자의 책임 경계를 유지한다는 점이 핵심입니다. 처음에는 CLI 검색으로 데이터 형태를 확인하고, 다음에는 읽기 전용 MCP 연결, 그다음 장바구니, 마지막에 인증된 체크아웃 순서로 권한을 넓히는 편이 안전합니다.

다른 업무용 MCP의 권한 설계가 궁금하다면 WhatsApp Business Tools MCP 설정 가이드도 함께 참고할 수 있습니다.

English version: Read this guide in English

공식 자료

자료 확인일: 2026년 10월 19일

댓글

댓글 쓰기

이 블로그의 인기 게시물

Diagram Design 사용법: Claude Code·Codex로 다이어그램 만드는 순서

이미지
Diagram Design은 Claude Code나 Codex 같은 코딩 에이전트에 다이어그램 제작 규칙을 더하는 외부 스킬·플러그인입니다. 별도의 웹 편집기에서 도형을 끌어다 놓는 방식이 아니라, 설명할 구조와 목적을 전달하면 에이전트가 HTML·SVG 기반 결과물을 만들도록 돕습니다. 자동화 흐름을 문서에 넣고 싶은데 상자 배치와 색상 정리에 시간을 쓰고 있다면 살펴볼 만합니다. 다만 보기 좋은 그림과 정확한 설계는 다릅니다. 여기서는 설치부터 첫 요청, 결과 검토와 내보내기까지 구분해 정리합니다. 자료 확인: 2026년 9월 16일 · 공식 README·사용 가이드 기반 안내입니다. 먼저 알아둘 세 가지 Diagram Design 자체가 AI 모델은 아닙니다. 사용할 코딩 에이전트가 먼저 준비돼 있어야 합니다. 처음에는 작은 흐름 하나를 정적 HTML로 만든 뒤 검토하는 편이 좋습니다. 공개 저장소라는 사실과 모델 사용료가 무료라는 말은 다릅니다. 1. 어떤 작업에 쓰면 좋을까? 공식 문서는 아키텍처, 흐름도, 시퀀스, 데이터 모델 등 여러 유형을 제공합니다. 기본 결과는 정적 HTML이며, Mermaid·draw.io·Excalidraw 자료를 선택한 크기와 상세도에 맞춰 다시 그리는 기능도 안내합니다. 모든 요소를 그대로 옮기는 단순 변환과는 다릅니다. 설명할 내용 선택 기준 문의 처리나 업무 자동화 순서 처리 단계와 분기가 보이는 흐름도 앱·서버·데이터베이스의 관계 구성 요소와 연결을 보여주는 아키텍처 시간 순서에 따른 요청과 응답 메시지 순서를 구분하는 시퀀스 옵션 두 개의 장단점 그림보다 비교표가 명확할 수 있음 공식 갤러리의 콘텐츠 사이트 아키텍처 예제. © 2025 Cathryn Lavery, MIT License. 원본 예제 보기 이 예제는 단순한 상자 나열이 아닙니다. Reader에서 들어온 요청, Astro Origin이 읽는 MDX 문서와 CMS, 다시 돌아가는 응답을 선 종류와 라벨로 구분합니다. 자신의 결과물에서도 ...
자세한 내용 보기

Aside Browser 사용법: 설치·가격·권한과 업무 자동화 가이드

이미지
Read in English Aside Browser(어사이드)는 웹사이트를 읽고 답하는 것에서 한 걸음 더 나아가, 사용자가 허용한 브라우저·계정·파일 문맥을 이용해 여러 단계의 작업을 진행하는 AI 브라우저입니다. 자료를 찾은 뒤 비교표를 만들거나, 로그인한 서비스에서 필요한 정보를 확인하고 검토할 초안을 준비하는 식으로 사용할 수 있습니다. 중요한 것은 “무엇이든 알아서 처리한다”는 기대보다 어느 자료를 사용하고, 어떤 결과를 만들며, 어디에서 멈춰야 하는지 를 정하는 일입니다. 이 글은 공식 도움말을 기준으로 시작 방법, 권한, 활용 예시와 비용을 정리한 안내입니다. 특정 작업의 성공률이나 시간을 측정한 사용 후기는 아닙니다. 자료 확인: 2026년 9월 16일. 기능·메뉴·플랜 조건은 업데이트에 따라 달라질 수 있습니다. 1. 챗봇에 질문하는 것과 무엇이 다를까? 핵심은 답변의 길이가 아니라 작업에 사용할 수 있는 문맥과 행동입니다. 설명을 복사해 넣는 대신 현재 보고 있는 페이지를 연결하고, 사용할 사이트와 결과물까지 지정할 수 있습니다. 공식 문서는 웹 탐색, 파일 작업, 기록 검색, 허용된 자격증명 자동 입력과 승인 요청을 여러 단계의 작업 안에서 다룹니다. 그렇다고 모든 사이트가 같은 수준으로 동작하거나 사람의 검토가 필요 없어지는 것은 아닙니다. 원하는 일 Aside에 맡길 범위 사람이 확인할 것 내용 이해 현재 문서의 요약과 근거 위치 정리 중요한 조건과 예외의 누락 여러 페이지 비교 같은 기준으로 정보를 수집해 표 작성 출처·확인일·서로 다른 과금 조건 계정에 연결된 업무 허용된 자료 조회와 결과물 준비 대상 계정·접근 범위·외부 반영 여부 다른 챗봇에도 검색이나 외부 도구 기능이 있을 수 있으므로 “챗봇은 못 하고 브라우저만 할 수 있다”고 단정할 필요는 없습니다. 브라우저에 흩어진 문맥을 반복해서 옮기는 일이 많은지, 결과를 검토할 수 있는 작은 단위로 맡길 수 있는지를 기준으로 판단하면 좋습니다. 2. 설치와 첫 실행...
자세한 내용 보기

OpenAI Agents API란? 관리형 에이전트 실행 환경 이해하기

이미지
모델에 질문을 한 번 보내는 것과, 파일을 읽고 도구를 호출하며 여러 단계의 작업을 끝내는 에이전트를 운영하는 것은 다른 문제입니다. 후자에서는 작업 기록, 실행 권한, 중간 실패, 결과물 보관까지 설계해야 합니다. OpenAI Agents API는 Codex의 에이전트 하네스를 OpenAI가 관리하는 API로 사용할 수 있게 하는 선택지 입니다. OpenAI는 2026년 9월 10일 Agents API 공개 베타를 발표했습니다. 이 글에서는 설치 명령을 나열하기보다 무엇을 맡길 수 있는지, Agents SDK·Responses API와 어떻게 다른지, 어떤 작은 업무로 도입 여부를 판단하면 좋을지 살펴봅니다. 자료 확인: 2026년 9월 16일 · 공식 발표와 개발자 문서 기준 먼저 기억할 핵심 관리형 하네스는 모델 자체가 아니라 작업을 이어 가고 도구를 쓰도록 조율하는 실행 기반입니다. 실행 환경을 선택할 수 있어도 도구 권한, 외부 시스템 접근, 승인 기준은 개발자가 정해야 합니다. 긴 작업에 유용한 선택지이지만, 단발성 호출까지 모두 옮길 필요는 없습니다. 1. 관리형 하네스는 무엇을 관리할까? 하네스는 에이전트가 입력을 받고, 필요한 도구를 사용하고, 중간 결과를 다음 단계에 반영하도록 돕는 실행 틀입니다. 공식 개요는 세션, 작업 조율, 컨텍스트 압축, 복구를 OpenAI가 관리하고 애플리케이션은 도구와 실행 환경을 제공하거나 선택한다고 설명합니다. 따라서 “더 강한 모델을 호출하는 API”보다는 에이전트 운영 책임을 나누는 방식 으로 이해하는 편이 정확합니다. Agent: 사용할 모델, 지시문, 도구와 MCP 서버를 정하는 구성입니다. Environment: 파일을 다루고 명령을 실행하는 선택적 샌드박스나 컴퓨터 환경입니다. Session: 여러 차례 입력을 받으며 작업을 이어 갈 수 있는 지속적인 에이전트 인스턴스입니다. Events와 items: 세션에 전달된 입력과 생성된 출력을 추적하는 자료입니다. 예를 들어 첫 요청에...
자세한 내용 보기