대화형 AI가 상품을 "추천"하는 단계는 이미 익숙해졌다. 이제 중요한 건 그 다음이다. 사용자가 검색과 대화를 하다가 바로 결제까지 이어질 수 있으려면, AI 플랫폼과 각 쇼핑몰이 서로 다른 방식으로 따로 붙는 구조부터 바뀌어야 한다. Google이 2026년 1월 공개한 UCP(Universal Commerce Protocol)는 바로 이 문제를 풀기 위한 오픈소스 표준이다. Google은 UCP를 Shopify, Etsy, Wayfair, Target, Walmart 등과 함께 설계했다고 설명하고, Shopify 역시 Google과 공동 개발한 개방형 표준이라고 밝히고 있다.
왜 UCP가 필요한가
기존 커머스 연동은 본질적으로 N×N 문제였다. 판매자는 여러 AI 표면과 여러 플랫폼에 각각 다른 API와 결제 흐름을 맞춰야 했고, 그 결과 구현 비용은 커지고 확장은 느려졌다. Google은 이런 병목 때문에 대화형 경험이 실제 구매로 자연스럽게 이어지기 어렵다고 설명하며, UCP가 상품 발견, 고려, 체크아웃, 결제, 주문 관리까지 이어지는 전체 커머스 여정을 하나의 공통 추상화로 표준화한다고 말한다.
쉽게 말해 UCP는 "결제 API 하나"가 아니다. AI와 상점이 상품을 찾고, 장바구니를 만들고, 배송과 결제를 확정하고, 주문 상태를 주고받는 전 과정을 공통 계약으로 맞추려는 시도에 가깝다. 그래서 UCP를 이해할 때는 결제보다도 상거래 전체를 다루는 인터페이스라는 관점이 더 중요하다. 이 해석은 Google이 UCP를 direct buying, account linking, multi-item carts, order lifecycle까지 확장 가능한 구조로 설명하는 방식과도 맞닿아 있다.
UCP가 약속하는 것
Google 문서에서 UCP는 AI Mode in Search와 Gemini 같은 AI 표면에서 직접 구매를 가능하게 하는 표준으로 소개된다. 중요한 점은 판매자가 여전히 Merchant of Record라는 것이다. 즉, 고객 관계와 거래 데이터의 주체는 여전히 판매자이며, UCP를 써도 브랜드 통제권을 잃지 않는다. Google FAQ 역시 UCP의 핵심 장점으로 확장된 도달 범위, 줄어든 체크아웃 마찰, 판매자 데이터 통제권, Native/Embedded라는 유연한 통합 경로를 꼽는다.
이 부분이 실무적으로 꽤 중요하다. 새로운 채널이 생길 때마다 "플랫폼이 고객을 가져가는 구조"를 걱정하는 경우가 많은데, UCP는 적어도 설계 원칙상 판매자가 거래 주체로 남는 방향을 분명히 하고 있다. 그래서 브랜드 입장에서는 AI 채널을 추가하면서도 자체 정책, 고객 관계, 결제 인프라를 최대한 유지하려는 전략과 잘 맞는다.
구조는 어떻게 생겼을까
UCP의 핵심은 프로필 공개 → 기능 협상 → 스키마 조합 → 요청/응답 검증 흐름이다. 비즈니스는 /.well-known/ucp에 자신의 프로필을 게시하고, 플랫폼은 이 프로필을 읽어 어떤 서비스와 capability를 지원하는지 확인한다. 이후 양쪽이 공통으로 지원하는 capability의 교집합을 계산하고, 필요한 스키마를 가져와 합성한 뒤, 그 결과로 실제 요청과 응답을 검증한다. 공식 스펙은 이 과정을 discovery, negotiation, schema fetch, compose, validate 순서로 정의한다.
여기서 capability라는 개념이 특히 중요하다. UCP는 체크아웃, 배송, 주문 관리 같은 기능을 capability 단위로 나누고, 필요하면 extension으로 확장한다. 그래서 "모든 걸 한 번에 도입"하는 방식보다, 필요한 기능부터 단계적으로 붙이는 구조에 가깝다. capability 교집합을 계산하는 규칙이 명시돼 있다는 점도 좋다. 플랫폼과 판매자가 서로 지원하는 기능만 활성화할 수 있으니, 구현 범위와 책임 경계가 상대적으로 분명해진다.
REST만 있는 게 아니다
UCP는 특정 통신 방식 하나에 고정돼 있지 않다. 공식 스펙은 서비스 바인딩으로 REST(OpenAPI 3.x), MCP(OpenRPC), A2A(Agent Card), embedded(OpenRPC)를 정의한다. Google FAQ도 UCP가 APIs, MCP, A2A 같은 매체를 선택적으로 사용할 수 있게 설계됐다고 설명한다. 즉, 백엔드가 전통적인 HTTP API 중심이든, 에이전트 간 상호작용 중심이든, 같은 capability 모델 위에서 연결할 수 있다.
개발자 관점에서 더 흥미로운 부분은 스키마 처리 방식이다. 공식 ucp-schema 저장소를 보면 UCP는 JSON Schema 위에 확장 규칙을 올려두고, self-describing payload, allOf 기반 조합, ucp_request/ucp_response 같은 annotation으로 요청 방향과 연산별 필드 가시성을 제어한다. 그리고 이걸 compose → resolve → validate 파이프라인으로 처리한다. 즉, UCP는 단순 문서 표준이 아니라 기계적으로 합성·검증 가능한 계약을 지향한다.
Google에서 UCP를 붙이려면 무엇을 해야 하나
Google의 구현 가이드를 보면 실제 통합은 꽤 구체적이다. 먼저 Merchant Center를 준비하고, Google Pay 토큰화를 지원하는 PSP를 확인한 다음, UCP 프로필을 게시해야 한다. 그 후 네이티브 체크아웃용 핵심 REST 엔드포인트를 구현하고, 필요하면 OAuth 2.0 기반 identity linking을 추가한 뒤, 주문 상태를 웹훅으로 Google에 전달하는 식이다. Google은 이 통합이 승인 과정을 거쳐야 실제 AI Mode와 Gemini에 노출될 수 있다고도 명시한다.
체크아웃 쪽만 떼어 보면 핵심은 세션 기반이다. Google 가이드는 go-live를 위한 핵심 엔드포인트로 생성, 업데이트, 완료를 강조하고, 네이티브 체크아웃 문서에서는 POST /checkout-sessions, PUT /checkout-sessions/{id}, POST /checkout-sessions/{id}/complete를 중심 흐름으로 제시한다. 같은 문서에는 조회와 취소 세션 엔드포인트도 함께 정의돼 있어, 실제 구현은 "핵심 3개 + 보조 엔드포인트" 구조로 이해하는 편이 자연스럽다.
Native와 Embedded는 어떻게 다를까
UCP의 체크아웃 경로는 크게 Native와 Embedded로 나뉜다. Native는 판매자가 REST API를 제공하고, 실제 체크아웃 로직은 Google 표면 안에서 더 매끄럽게 진행되는 방식이다. Google은 이 경로를 미래의 agentic use case, multi-item cart, personalization을 고려하면 더 권장되는 옵션으로 설명한다. 반면 Embedded는 판매자가 제어하는 웹 체크아웃을 iframe 형태로 삽입하는 방식으로, 복잡한 체크아웃 로직이나 브랜드 맞춤 UX가 꼭 필요한 경우를 위한 대안이다.
내가 보기엔 이 구분이 UCP의 현실성을 보여준다. 프로토콜이 아무리 좋아도 모든 판매자가 바로 완전한 네이티브 흐름으로 갈 수는 없다. 그래서 UCP는 "이상적인 API 중심 경로"와 "현실적인 임베드 경로"를 둘 다 준비해 두었다. 이 점 때문에 UCP는 선언만 화려한 표준이 아니라, 기존 커머스 스택을 가진 업체도 단계적으로 들어올 수 있는 표준에 가깝다.
구현할 때 놓치기 쉬운 포인트
실무에서는 멋진 개념보다 이런 디테일이 더 중요하다. Google의 Native Checkout 문서는 성능 목표를 꽤 명확하게 제시한다. 생성 엔드포인트는 50퍼센타일 1초 이하, 95퍼센타일 4초 이하, 업데이트는 95퍼센타일 5초 이하, 완료는 95퍼센타일 10초 이하가 기대치다. 또 체크아웃 응답의 links 배열에 privacy_policy와 terms_of_service URL을 반드시 넣어야 Google UI에 표시할 수 있다고 명시한다. 즉, UCP 도입은 단순히 스펙을 읽고 끝나는 일이 아니라, 응답 속도와 정책 링크 같은 운영 디테일까지 맞춰야 하는 작업이다.
재고와 주문 처리도 판매자 책임이 남는다. Google FAQ에 따르면 최종 구매 버튼을 활성화하기 전에 실시간 재고 확인이 이뤄지고, 주문이 생성된 뒤에는 판매자가 웹훅으로 주문 상태를 푸시해야 한다. 계정 연동을 넣고 싶다면 OAuth 2.0 Authorization Code 흐름과 /.well-known/oauth-authorization-server 메타데이터도 구현해야 한다. 결국 UCP는 "AI가 다 알아서 사준다"는 마법이 아니라, 판매자 시스템이 신뢰할 수 있는 실시간 상태를 제공할 수 있어야 작동하는 표준이다.
개발자에게 왜 중요한가
UCP가 흥미로운 이유는 커머스를 AI 친화적으로 다시 포장했기 때문이다. 예전에는 상품 검색 API, 장바구니 API, 결제 연동, 주문 조회가 서로 다른 문맥으로 흩어져 있었다면, UCP는 그것들을 capability와 schema 중심으로 재구성한다. 그래서 에이전트는 판매자마다 완전히 다른 결제 플로우를 따로 학습하기보다, 공통 프로토콜 위에서 discovery와 checkout을 처리할 수 있다. Google도 이를 "custom integrations 없이 상호운용 가능한 agentic commerce"라는 방향으로 설명한다.
게다가 생태계도 생각보다 빠르게 갖춰지고 있다. 공식 GitHub 조직에는 스펙 저장소, schema validator, 샘플 서버, Python SDK, JavaScript SDK, conformance 테스트가 따로 공개돼 있다. 즉, UCP는 발표 자료 수준에 머무는 개념이 아니라, 이미 문서·샘플·검증 도구를 갖춘 개발자용 프로젝트로 굴러가고 있다.
마무리
정리하면 UCP는 "AI가 쇼핑을 대신해 주는 시대"를 위해 나온 커머스 표준이다. 핵심은 단순 결제가 아니라, 발견부터 주문 후 상태 업데이트까지 이어지는 전체 흐름을 공통 인터페이스로 만들었다는 점이다. 판매자는 Merchant Center, 결제 처리, 재고, 주문 상태 같은 기존 책임을 유지하면서도, AI Mode in Search와 Gemini 같은 새로운 표면에 더 적은 커스텀 연동으로 들어갈 수 있다. 아직 초기 단계이긴 하지만, 구조와 도구를 보면 적어도 방향성은 꽤 선명하다. 앞으로 커머스 백엔드가 "웹사이트용 API"만이 아니라 "에이전트가 이해할 수 있는 계약"을 함께 제공하는 쪽으로 가게 된다면, UCP는 그 출발점 중 하나가 될 가능성이 높다.
