유니버설 커머스 프로토콜(UCP) 완벽 가이드

구글이 만든 새로운 개방형 표준 유니버설 커머스 프로토콜(Universal Commerce Protocol, 이하 UCP)이 쇼핑몰의 결제 방식을 바꾸고 있다. 검색 결과나 AI 모드, 제미나이 화면 안에서 상품 페이지로 이동하지 않고 그 자리에서 결제가 끝나는 네이티브 체크아웃이 바로 이 UCP 위에서 동작한다.

결론부터 말하면 이렇다. UCP는 구글 하나만의 기술이 아니라 쇼피파이·월마트·타깃·스트라이프·비자 등이 함께 참여한 업계 공통 표준이다. 지금은 미국·캐나다·호주의 일부 판매자에게 적용되고 있고, 국내 쇼핑몰도 언젠가 이 흐름을 마주하게 될 가능성이 크다. 지금 당장 신청할 대상이 아니더라도, 개념과 구조를 미리 알아 두면 이후 대응이 훨씬 쉬워진다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• UCP가 무엇이고, 왜 구글이 이 표준을 만들었는가
• 기존 쇼핑 광고 체크아웃과 UCP 체크아웃은 어떻게 다른가
• UCP가 실제로 동작하는 방식(디스커버리 → 캐퍼빌리티 호출 → 결제 완료)
• 구글 머천트 센터와의 관계, 지금 신청 가능한 대상은 누구인가
• 국내 쇼핑몰이 지금 점검해 둘 체크리스트와 흔한 오해

유니버설 커머스 프로토콜이란 무엇인가

UCP는 AI 에이전트와 쇼핑몰, 결제사, 플랫폼이 서로 다른 시스템끼리도 같은 언어로 대화할 수 있게 만든 개방형 통신 표준이다. 구글은 2026년 1월 11일 이 표준을 처음 공개했고, 쇼피파이·엣시·월마트·타깃·스트라이프·비자를 포함한 20여 개 기업이 동시에 참여를 선언했다.

UCP가 풀려고 한 문제는 명확하다. 지금까지 쇼핑몰이 구글, 챗GPT, 각종 AI 쇼핑 도우미와 각각 연동하려면 플랫폼마다 다른 방식으로 따로 개발해야 했다. 판매처가 열 곳이면 연동도 열 번, 상품 정보 형식도 열 가지였던 셈이다. 구글은 이를 "N x N 복잡도"라고 표현했다. 판매자 수(N)와 쇼핑 플랫폼 수(N)가 곱해지는 만큼 개발 부담이 기하급수적으로 늘어난다는 뜻이다.

조금 더 구체적으로 그려 보자. 어떤 브랜드가 자사 쇼핑몰, 구글 쇼핑, 챗GPT형 AI 쇼핑 도우미, 다른 마켓플레이스 세 곳까지 총 다섯 개 채널에 상품을 노출하고 싶다고 가정하면, 재고 조회·가격 갱신·결제 요청·주문 상태 확인을 채널마다 각각 다른 방식으로 구현해야 한다. 채널이 하나 늘어날 때마다 개발·유지보수 비용이 그만큼 곱절로 불어난다. UCP는 이 구조를 "판매자 쪽에서 표준 하나만 지키면, 그 표준을 이해하는 모든 채널과 자동으로 연결된다"는 구조로 뒤집었다.

UCP의 핵심은 "판매자 하나가 표준 하나만 지키면, 그 표준을 이해하는 모든 AI 에이전트·플랫폼과 자동으로 연결된다"는 것이다.

UCP는 에이전트투에이전트(A2A), 에이전트 결제 프로토콜(AP2), 모델 컨텍스트 프로토콜(MCP) 같은 기존 AI 업계 표준과도 호환되도록 설계됐다. 여기서 A2A는 서로 다른 AI 에이전트끼리 정보를 주고받는 통신 규칙, AP2는 AI 에이전트가 사람을 대신해 결제를 진행할 때 지켜야 하는 결제 안전 규칙, MCP는 AI 모델이 외부 도구나 데이터에 접근하는 표준 방식을 뜻한다. 쉽게 말해 UCP는 결제·주문 같은 상거래 기능을 담당하고, 나머지 통신·인증 부분은 이미 있는 AI 업계 표준을 그대로 가져다 쓰는 구조다. 새 판을 짜는 대신 기존에 잘 굴러가던 표준끼리 서로 손을 잡게 만든 셈이다.

UCP 체크아웃은 기존 쇼핑 광고 체크아웃과 무엇이 다른가

가장 헷갈리는 부분이 여기다. 구글은 이미 오래전부터 쇼핑 광고에 "구매하기" 버튼을 지원했다. 그런데 이번 UCP 체크아웃은 그것과 성격이 다르다.

기존 방식은 버튼을 눌러도 결제 자체는 판매자의 쇼핑몰 사이트에서 끝났다. 손님이 상품 페이지로 넘어가서, 그 사이트의 결제창에 카드 정보를 입력하고, 그 사이트의 주문 완료 페이지를 보는 흐름이다. 반면 UCP가 지원하는 네이티브 체크아웃은 결제 화면이 구글 검색·AI 모드·제미나이 안에서 그대로 뜨고, 구글 페이로 즉시 결제가 끝난다. 손님은 판매자 사이트로 이동할 필요조차 없다.

구분	기존 쇼핑 광고 체크아웃	UCP 네이티브 체크아웃
결제가 끝나는 곳	판매자 쇼핑몰 사이트	구글 검색 / AI 모드 / 제미나이 화면
결제 수단	판매자 사이트의 결제창	구글 페이(저장된 카드·배송지 활용)
판매자 지위	판매자(seller of record)	여전히 판매자(seller of record) 유지
필요 조건	쇼핑 피드 등록	쇼핑 피드 + UCP 연동 + 자격 조건
데이터 추적	사이트 내 GA4 등으로 정상 수집	결제가 구글 화면 안에서 끝나 별도 대조 필요
손님 이동	상품 페이지로 이동 필요	이동 없이 화면 안에서 종료

결제가 판매자 사이트 밖에서 끝난다고 해도, 판매자가 판매자 지위(seller of record)를 잃는 것은 아니다. 다만 GA4 같은 자체 분석 도구에 결제 데이터가 그대로 잡히지 않을 수 있어, 머천트 센터 리포트와 함께 대조하는 습관이 필요하다.

이 변화는 이미 국내에도 영향을 주고 있다. 쇼피파이 연동 쇼핑몰을 대상으로 별도 신청 없이 네이티브 체크아웃이 자동으로 켜진 사례는 구글 머천트 센터 네이티브 체크아웃 자동 활성화 글에서 다뤘다. 이번 글은 그 사건의 배경이 되는 UCP라는 표준 자체를 더 깊이 다룬다.

두 방식은 서로 대체 관계가 아니라 공존 관계로 보는 것이 정확하다. 판매자는 여전히 기존 쇼핑 광고 체크아웃을 유지하면서, 자격을 갖추면 UCP 네이티브 체크아웃까지 추가로 지원할 수 있다. 어떤 채널에서 어떤 방식으로 결제가 끝났는지를 구분해서 볼 수 있는 체계를 미리 갖춰 두는 것이 관리의 핵심이다.

UCP는 실제로 어떻게 동작하는가

UCP는 상거래의 각 기능을 "캐퍼빌리티(capability, 기능 단위)"라는 조각으로 나눈다. 대표적인 캐퍼빌리티는 다음과 같다.

• 체크아웃: 결제 세션을 열고 상품·수량·가격을 확정해 결제를 마무리한다.
• 상품 디스커버리: 재고와 실시간 가격 정보를 조회한다.
• 할인 적용: 쿠폰·프로모션 코드를 결제 과정에 반영한다.
• 주문 관리: 주문 상태, 취소·교환 요청을 처리한다.
• 배송/풀필먼트: 배송 방법과 예상 도착일을 안내한다.
• 신원 연결: 회원 계정과 외부 에이전트의 구매자 정보를 안전하게 매칭한다.

판매자는 이 기능들을 /.well-known/ucp라는 정해진 경로에 표준 JSON 파일(매니페스트) 형태로 공개한다. 여기서 매니페스트란 "우리 쇼핑몰은 이런 기능을 지원한다"고 미리 적어 둔 명세서를 뜻한다. AI 에이전트는 이 파일만 읽으면 "이 쇼핑몰이 어떤 기능을 지원하는지"를 자동으로 파악할 수 있다. 판매자마다 다른 문서를 찾아 일일이 코드를 새로 짤 필요가 없다는 뜻이다.

동작 흐름은 "발견 → 캐퍼빌리티 호출 → 거래 완료"의 3단계로 단순하다. 조금 더 풀어 보면 다음과 같은 순서다.

1. 발견(discovery): AI 에이전트가 판매자의 매니페스트를 읽어, 이 판매자가 체크아웃·할인·배송 안내 중 어떤 기능을 지원하는지 확인한다.
2. 캐퍼빌리티 호출(invocation): 손님이 실제로 구매하려는 상품과 수량, 배송 정보를 담아 체크아웃 기능을 호출한다. 이 과정에서 쿠폰이 있다면 할인 캐퍼빌리티도 함께 호출된다.
3. 거래 완료(completion): 결제가 확정되면 주문 관리 캐퍼빌리티로 넘어가, 주문 상태와 배송 예정일이 손님에게 안내된다.

이 세 단계는 사람이 쇼핑몰에서 장바구니에 상품을 담고, 쿠폰을 적용하고, 결제 버튼을 누르는 흐름을 AI 에이전트가 대신 수행하는 것과 본질적으로 같다. 다만 이 모든 과정이 사람의 클릭 없이, 표준화된 요청과 응답으로 오간다는 점이 다르다.

연동 방식도 하나로 고정돼 있지 않다. REST API로 직접 붙일 수도 있고, 이미 익숙한 모델 컨텍스트 프로토콜(MCP)이나 A2A 통신으로도 연결할 수 있다. 구글은 언어별 네이티브 SDK도 제공해, 개발팀이 처음부터 전부 직접 구현하지 않아도 되도록 돕고 있다. 이런 유연성 덕분에 이미 MCP 기반 챗봇을 운영하는 쇼핑몰이라면 기존 인프라를 크게 바꾸지 않고도 UCP를 얹을 수 있다.

보안 설계도 짚어 둘 필요가 있다. UCP는 카드 번호 원본을 그대로 주고받지 않고 토큰화 결제(카드 정보를 임시 토큰으로 바꿔 전달하는 방식)와 검증 가능한 자격 증명(verifiable credentials)을 기본 원칙으로 삼는다. AI 에이전트가 결제를 대신 진행하는 구조인 만큼, "이 요청이 실제로 손님 본인의 승인을 받은 것인가"를 증명하는 절차가 표준 안에 포함돼 있다는 뜻이다.

매니페스트는 실제로 어떤 모습인가

/.well-known/ucp 경로에 올리는 매니페스트는 복잡한 프로그램이 아니라, "우리 쇼핑몰이 지원하는 기능 목록"을 적어 둔 간단한 설명서에 가깝다. 개념을 감으로 익히기 위해 단순화한 예시를 보면 이렇다.

{
  "business_name": "OO몰",
  "capabilities": ["checkout", "discount", "fulfillment", "order_management"],
  "endpoints": {
    "checkout": "https://oomall.com/api/ucp/checkout",
    "discount": "https://oomall.com/api/ucp/discount"
  },
  "auth": "verifiable_credential"
}

실제 명세는 이보다 필드가 많고 세부 규칙도 훨씬 엄격하지만, 큰 그림은 같다. "우리는 어떤 기능을 지원하고, 그 기능은 어떤 주소로 호출하면 되는지"를 표준화된 형식으로 미리 알려 주는 것이다. AI 에이전트는 이 문서 하나만 읽으면 판매자마다 다른 개발 문서를 뒤질 필요 없이 곧바로 필요한 기능을 호출할 수 있다.

auth 항목에 들어가는 검증 가능한 자격 증명 방식은, 결제 요청이 실제로 손님 본인의 승인을 받았는지 암호학적으로 증명하는 절차다. 이 절차가 있기 때문에 "AI가 마음대로 결제를 진행하는 것 아니냐"는 우려와 달리, 실제로는 사람의 승인 없이는 결제가 완결되지 않는 구조로 짜여 있다.

UCP를 도입하면 판매자에게 실질적으로 어떤 이점이 있나

가장 먼저 꼽히는 이점은 결제 단계 이탈률 감소다. 온라인 쇼핑몰에서 장바구니에 담긴 상품 중 상당수는 결제 화면으로 넘어가는 과정에서 이탈한다. 새 사이트로 이동하고, 로그인하고, 배송지와 카드 정보를 다시 입력하는 절차가 길어질수록 이탈은 늘어난다. UCP 네이티브 체크아웃은 이미 구글 페이에 저장된 정보를 그대로 불러오기 때문에, 입력 단계 자체가 크게 줄어든다.

두 번째 이점은 채널 확장 비용의 절감이다. 앞서 짚은 N x N 문제를 떠올려 보면, 새로운 AI 쇼핑 채널이 하나 등장할 때마다 판매자가 새로 개발해야 했던 부담이 UCP 표준 하나로 줄어든다. 오늘 체크아웃 캐퍼빌리티를 준비해 두면, 내일 다른 플랫폼이 같은 표준을 채택했을 때 추가 개발 없이 그대로 연결될 가능성이 크다.

세 번째 이점은 초기 진입자로서의 노출 우위다. 아직 국내에 정식 도입되지 않은 지금, 미국·캐나다·호주에서 UCP를 먼저 준비해 둔 판매자는 AI 모드·제미나이 쇼핑 결과에서 "구매 가능" 배지를 먼저 얻는다. 검색 초기에 상위에 자리 잡은 페이지가 이후에도 유리한 위치를 유지하는 것처럼, 결제 표준 적용에서도 먼저 준비한 판매자가 먼저 노출되는 구조가 반복될 가능성이 크다.

물론 이점만 있는 것은 아니다. 결제가 판매자 사이트 밖에서 끝나는 만큼 브랜드 경험을 직접 설계할 기회가 줄어드는 것은 감수해야 할 부분이다. 결제창 디자인, 추가 상품 추천, 회원 가입 유도 같은 장치를 결제 과정에 넣기 어려워진다는 뜻이다. 이런 트레이드오프를 인지한 채로 도입 여부와 범위를 판단하는 것이 바람직하다.

구글 머천트 센터와 UCP는 어떤 관계인가

UCP를 이해할 때 가장 먼저 짚어야 할 사실은, UCP가 머천트 센터를 대체하는 것이 아니라 그 위에서 작동한다는 점이다. 판매자는 이미 등록해 둔 머천트 센터의 쇼핑 피드를 그대로 활용해, 발견(discovery) 단계에서 고객을 붙잡는다.

UCP 체크아웃까지 열려면 별도 절차가 추가된다. 정리하면 다음과 같다.

1. 머천트 센터 계정을 정상적으로 유지하고, 상품 데이터를 최신 상태로 관리한다.
2. 구글 페이 & 월렛 콘솔 계정을 만들어 결제 처리 권한을 연결한다.
3. native_commerce(checkout_eligibility) 속성을 상품 데이터에 넣어야 검색·AI 모드에 "구매" 버튼이 뜬다.
4. 필요 시 관심 신청 폼을 제출하고, 기술·운영 요건 심사를 통과한다.

이 흐름은 머천트 API 전환 완벽 가이드에서 다룬 데이터 연동 기반과도 이어진다. 상품 데이터가 정확하고 최신이어야 AI 에이전트가 믿고 결제를 진행할 수 있기 때문에, UCP를 준비하는 작업은 결국 머천트 센터 데이터 품질을 다시 점검하는 작업과 크게 다르지 않다. 머천트 API가 상품 데이터를 구글에 올리고 관리하는 통로라면, UCP는 그 데이터를 바탕으로 결제까지 이어 붙이는 다음 단계라고 이해하면 된다.

참여 방식도 계속 바뀌고 있다. 2026년 3월 처음 도입될 때는 신청서를 내야 하는 옵트인 구조였지만, 9월 쇼피파이 연동 확대부터는 조건만 맞으면 신청 없이 자동으로 켜지는 옵트아웃 구조로 바뀌었다. 앞으로 다른 플랫폼에도 이런 자동 적용이 넓어질 가능성이 있다.

구글은 통합 방식도 두 가지로 나누어 두었다. 하나는 네이티브 체크아웃으로, AI 모드와 제미나이 검색 로직에 결제를 곧바로 연결하는 기본형이다. 다른 하나는 임베디드 체크아웃으로, 특정 요건을 충족한 승인된 판매자에게만 열리는 맞춤형 연동이다. 대부분의 중소 쇼핑몰은 네이티브 체크아웃 경로를 따르게 될 가능성이 크다.

UCP는 어떤 속도로 확산되고 있나

UCP는 공개 이후 매 계절마다 적용 범위를 넓혀 왔다. 흐름을 시간순으로 보면 다음과 같다.

• 2026년 1월 11일: UCP 표준 공식 공개. 쇼피파이·엣시·월마트·타깃·스트라이프·비자 등 20여 개 기업이 참여 선언.
• 2026년 3월: 구글이 첫 UCP 체크아웃을 옵트인(관심 신청) 방식으로 도입. 미국 중심의 초기 테스트.
• 2026년 5월 20일: 구글 마케팅 라이브 행사에서 UCP 확대 발표. 다이렉트 오퍼, 디맨드젠 캠페인, AI 모드 쇼핑, 유튜브 쇼핑 광고까지 연동 지점이 늘었고, 어펌·클라나 같은 후불결제(BNPL) 서비스도 구글 페이 안에 통합됐다. 나이키, 세포라, 타깃, 월마트, 웨이페어, 쇼피파이 입점 브랜드(펜티, 스티브 매든 등)가 초기 파트너로 참여했다.
• 2026년 9월: 쇼피파이 연동 쇼핑몰을 대상으로 옵트아웃(자동 적용) 방식 확대. 신청하지 않아도 조건이 맞으면 자동으로 네이티브 체크아웃이 켜지는 판매자가 늘었다.

이런 확산 속도를 보면, 국내 쇼핑몰도 언제 대상 국가에 포함될지 모른다는 전제로 미리 준비해 두는 편이 안전하다. 특히 해외 배송을 취급하거나 쇼피파이 기반으로 운영하는 국내 판매자라면, 미국·캐나다·호주 고객을 상대로 이미 UCP의 영향을 받고 있을 가능성도 있다.

지금 국내 쇼핑몰도 UCP를 신청할 수 있나

아직은 아니다. 2026년 9월 현재 UCP 기반 네이티브 체크아웃은 미국, 캐나다, 호주를 중심으로 열려 있고, 이후 영국까지 확대할 계획이 발표됐다. 국내 쇼핑몰을 대상으로 한 정식 서비스 시점은 아직 공개되지 않았다.

그렇다고 지금 국내 쇼핑몰 운영자에게 상관없는 이야기는 아니다. 구글은 이미 UCP 연동 지점을 검색뿐 아니라 광고 상품 전반으로 계속 넓히고 있다고 밝혔다. 대상 국가가 확대되는 시점에 뒤늦게 준비를 시작하면, 상품 데이터 정비부터 계정 권한 정리까지 한꺼번에 처리해야 해서 오히려 더 급해진다. 미리 기초를 다져 두면, 서비스가 열리는 순간 곧바로 신청할 수 있는 위치를 선점하게 된다.

UCP를 둘러싼 흔한 오해 세 가지

첫째, "UCP는 큰 브랜드만 신경 쓸 일이다"는 오해다. 초기 파트너 목록에 나이키, 세포라, 월마트 같은 대형 브랜드가 눈에 띄지만, 실제 적용 대상은 쇼피파이 연동 여부와 머천트 센터 등록 여부로 정해진다. 중소 쇼핑몰도 쇼피파이를 쓰고 있다면 이미 대상에 포함될 수 있다.

둘째, "UCP를 켜면 내 쇼핑몰 사이트로 오는 손님이 줄어든다"는 오해다. 결제가 구글 화면 안에서 끝나더라도 판매자 지위와 매출은 그대로 판매자의 것이다. 다만 방문자 수 같은 트래픽 지표가 줄어드는 것처럼 보일 수 있어, 분석 지표를 매출 중심으로 다시 설계할 필요가 있다.

셋째, "UCP는 결제 기능 하나만 바꾸는 것이다"는 오해다. 실제로는 체크아웃뿐 아니라 상품 디스커버리, 할인, 주문 관리, 배송, 신원 연결까지 여러 캐퍼빌리티를 아우르는 표준이다. 결제만 따로 떼어 이해하면 나머지 캐퍼빌리티가 열릴 때 대응이 늦어질 수 있다.

실무자는 어떤 순서로 준비하면 되나

한꺼번에 모든 것을 갖추려 하면 오히려 아무것도 시작하지 못한다. 단기·중기·장기로 나눠 순서대로 접근하는 편이 실무적으로 안전하다.

단기(지금 바로 할 수 있는 것)는 데이터 정비다. 머천트 센터에 등록된 상품명, 가격, 재고, 이미지가 실제 상황과 일치하는지 다시 확인한다. 이 작업은 UCP 여부와 무관하게 검색 노출에도 직접 도움이 되므로, 당장 투자 대비 효과가 가장 크다.

중기(서비스 확대 시점을 염두에 둔 준비)는 계정과 권한 정비다. 머천트 센터, 구글 페이 & 월렛 콘솔 같은 계정을 팀 단위로 관리하고, 담당자가 바뀌어도 업무가 끊기지 않도록 접근 권한 인수인계 절차를 문서로 남겨 둔다. 개발팀이 있다면 REST API나 MCP 연동 방식 중 어느 쪽이 기존 시스템과 더 잘 맞을지 미리 검토해 두는 것도 이 단계에 해당한다.

장기(국내 서비스 시작 이후)는 실제 신청과 연동이다. 서비스 대상 국가가 확대되는 시점에 관심 신청 폼을 제출하고, 기술·운영 요건 심사를 준비한다. 이 단계까지 오면 단기·중기에서 다져 둔 데이터·계정 기반이 그대로 자산이 된다.

준비 순서를 거꾸로 잡아, 신청부터 서두르고 데이터 정비를 나중으로 미루면 심사 단계에서 발이 묶이기 쉽다. 데이터가 먼저, 신청은 나중이라는 순서를 지키는 편이 안전하다.

쇼핑몰이 지금 점검해 둘 것은 무엇인가

UCP가 아직 국내에 정식으로 열리지 않았더라도, 지금 미리 손봐 둘수록 나중에 유리한 항목들이 있다. 좋은 예와 나쁜 예를 나눠 본다.

상품 데이터 관리

나쁜 예: 재고가 소진됐는데도 머천트 센터에는 여전히 "구매 가능"으로 남아 있다.

좋은 예: 재고·가격 변경이 발생하면 자동으로 머천트 센터 피드에 실시간 반영되도록 연동해 둔다.

AI 에이전트가 대신 결제를 진행하는 구조에서는 사람이 직접 눈으로 확인하고 넘어가는 단계가 없다. 상품 데이터가 틀리면 곧바로 잘못된 결제, 환불, 신뢰 하락으로 이어진다. UCP 시대의 상품 데이터 정확성은 선택이 아니라 결제 시스템의 일부다.

계정·권한 정비

나쁜 예: 머천트 센터 계정 담당자가 퇴사한 뒤 비밀번호와 권한이 방치돼 있다.

좋은 예: 머천트 센터, 구글 페이 & 월렛 콘솔 계정을 팀 단위로 관리하고, 접근 권한을 주기적으로 점검한다.

권한이 한 사람에게만 몰려 있으면, 그 담당자가 자리를 비운 사이 문제가 생겨도 아무도 손을 쓸 수 없다. 계정 접근 권한을 최소 두 명 이상이 나눠 관리하는 것이 UCP뿐 아니라 모든 온라인 판매 채널의 기본 원칙이다.

데이터 추적 이원화

나쁜 예: 매출이 늘었는데 GA4에는 그 매출이 잡히지 않아 원인을 못 찾는다.

좋은 예: GA4와 머천트 센터 리포트를 함께 놓고, UCP를 통해 발생한 거래를 따로 표시해 매출을 대조한다.

해외 규제 흐름 확인

유럽에서는 2026년 9월 27일부터 시행된 소비자 보호 관련 고지 요건이 눈에 보이는 결제 화면을 전제로 하고 있어, UCP 같은 방식과 충돌할 여지가 있다는 지적도 나온다. 아직 국내에 직접 적용되는 규정은 아니지만, 해외 판매를 겸하는 쇼핑몰이라면 진출 국가별 규제 동향을 함께 확인해 두는 것이 안전하다.

고객센터·환불 정책 재정비

AI 에이전트가 결제까지 대신 진행했다면, 환불이나 교환을 요청하는 손님도 "내가 언제 어떻게 결제했는지 기억이 흐릿한" 상태로 문의할 가능성이 크다. 주문 확인 메일과 문자 안내를 평소보다 더 명확하게 보내는 것만으로도 문의 응대 부담을 크게 줄일 수 있다.

UCP는 결국 쇼핑몰 운영 방식을 어떻게 바꾸는가

지금까지 온라인 쇼핑몰의 성공 기준은 "내 사이트로 손님을 얼마나 데려오는가"였다. UCP가 자리를 잡으면 이 기준에 한 가지가 더 추가된다. "AI 에이전트가 내 상품을 믿고 대신 결제해 줄 만큼 데이터가 정확한가"라는 기준이다.

두 기준은 서로 배타적이지 않다. 오히려 검색에 잘 노출되도록 SEO를 다듬는 작업과, AI 에이전트가 신뢰할 만한 상품 데이터를 유지하는 작업은 같은 뿌리에서 나온다. 상품 정보가 정확하고, 재고와 가격이 실시간으로 맞고, 사이트 구조가 명확한 쇼핑몰일수록 검색에서도, AI 쇼핑에서도 유리해진다.

쇼핑몰 전반의 검색 노출을 점검하고 싶다면 쇼핑몰 SEO 완벽 가이드도 함께 참고할 만하다. UCP 대응과 기본 SEO 점검은 결국 "내 상품 정보를 누구에게든 정확하게 보여준다"는 같은 목표로 이어진다.

자주 묻는 질문

UCP는 구글만의 폐쇄형 기술인가요?

아니다. UCP는 개방형 표준이며, 쇼피파이·엣시·월마트·타깃·스트라이프·비자 등 20여 개 기업이 함께 참여를 선언했다. 구글은 이 표준을 검색·AI 모드·제미나이에 적용한 첫 번째 사례를 만들었을 뿐, 다른 플랫폼도 같은 표준을 활용할 수 있다.

UCP 체크아웃을 켜면 우리 쇼핑몰이 판매자 지위를 잃나요?

그렇지 않다. 결제 화면이 구글 안에서 뜨더라도 판매자는 여전히 판매자(seller of record)로 남는다. 다만 결제 데이터가 자체 분석 도구에 자동으로 잡히지 않을 수 있어, 머천트 센터 리포트와 대조하는 절차가 필요하다.

머천트 API와 UCP는 같은 것인가요?

다르다. 머천트 API는 상품 데이터를 구글에 등록·관리하는 인터페이스이고, UCP는 그 데이터를 바탕으로 AI 에이전트가 결제까지 진행하도록 만든 통신 표준이다. UCP는 머천트 센터·머천트 API 위에서 동작하는 추가 계층에 가깝다.

네이티브 체크아웃과 임베디드 체크아웃은 어떻게 다른가요?

네이티브 체크아웃은 대부분의 판매자에게 열린 기본형으로, AI 모드·제미나이의 검색 로직에 결제가 곧바로 연결된다. 임베디드 체크아웃은 특정 요건을 충족한 승인된 판매자만 쓸 수 있는 맞춤형 연동으로, 결제 화면을 판매자 요구에 맞게 더 세밀하게 조정할 수 있다.

지금 당장 우리 쇼핑몰이 준비해야 할 일이 있나요?

대상 국가가 아니라면 급하게 신청할 필요는 없다. 다만 상품 데이터 정확성, 재고·가격 실시간 동기화, GA4와 머천트 센터 데이터 대조 같은 항목은 UCP와 무관하게도 쇼핑몰 운영의 기본이므로 미리 다듬어 둘 가치가 있다.

UCP를 도입하려면 개발팀이 처음부터 다 새로 만들어야 하나요?

그렇지는 않다. UCP는 REST API, MCP, A2A 등 여러 연동 방식과 언어별 SDK를 지원하도록 설계돼, 이미 있는 시스템 위에 필요한 캐퍼빌리티만 얹는 방식으로 접근할 수 있다. 처음부터 전체를 새로 구축하기보다, 상품 데이터 정비부터 단계적으로 준비하는 편이 현실적이다.

---

유니버설 커머스 프로토콜은 아직 국내에 완전히 자리잡지 않았지만, 검색과 AI 쇼핑의 경계가 사라지는 흐름은 이미 시작됐습니다. 이루웹은 홈페이지·쇼핑몰 제작 과정에서 이런 최신 흐름까지 함께 점검해 드리고 있습니다. 우리 쇼핑몰이 AI 검색·AI 쇼핑 시대에 잘 대응하고 있는지 궁금하시다면 문의하기 페이지로 편하게 남겨 주시기 바랍니다.