안녕하세요! 블록체인 엔지니어 야마구치 나츠오(@0x_natto)입니다.

블록체인 × AI Agent로 자율 경제권을 만드는 개발 조직 Komlock lab에서 CTO를 맡고 있습니다.

2026년 1월 Google이 발표한 UCP(Universal Commerce Protocol)는 "AI 에이전트가 쇼핑을 대행하는 시대의 커머스 공통 언어"라고 소개되고 있지만, 실제 통신에서 무엇이 어떻게 흐르는지까지 깊이 있게 다룬 일본어 설명은 거의 찾아볼 수 없습니다. 이 기사에서는 사양(Specification) 원문만을 토대로, .well-known/ucp의 JSON 내용, 서버가 집합(Intersection)으로부터 결정하는 capability negotiation, 체크아웃의 상태 머신(State Machine), AP2 mandate가 삽입되는 위치까지 차례대로 파헤쳐 보겠습니다.

UCP란 무엇인가

UCP는 Google이 2026년 1월 11일, 소매 업계의 연례 컨퍼런스인 NRF 2026 기조연설에서 발표한 에이전틱 커머스(Agentic Commerce)의 오픈 표준입니다. Sundar Pichai는 "오픈되어 있으며 특정 기술에 의존하지 않고, Shopify, Etsy, Wayfair, Target, Walmart와 함께 만들었으며, 20개 이상의 기업이 지지하고 있다"라고 말했습니다. 발표 당시 보도에 따르면, Visa나 Mastercard, Stripe와 같은 결제 측 플레이어들도 지지자 명단에 이름을 올리고 있습니다.

해결하고자 하는 과제는 간단합니다. 에이전트마다 EC 사업자가 개별적으로 연결을 만들면 연결 수가 폭발적으로 증가합니다. Google 발표문의 표현을 빌리자면 "개별 에이전트마다 고유한 연결을 요구하는 대신, UCP는 모든 에이전트가 용이하게 상호작용할 수 있도록 한다"입니다. 이른바 N×N 문제의 해소입니다. 여기까지는 기존 기사에서 충분히 다루어졌으므로, 이 기사에서는 더 이상 깊이 들어가지 않겠습니다.

먼저, 페르소나가 가지기 쉬운 오해 3가지를 바로잡아 두겠습니다.

Google의 발표문도 UCP는 A2A, AP2, MCP와 같은 기존 프로토콜과 호환된다고 명시하고 있습니다.

또 하나, 사양이 정의하는 등장인물을 파악해 둡시다. UCP는 4가지 역할로 작성되어 있습니다.

"에이전트가 산다"는 문맥에서 주로 이야기되지만, Platform과 Business는 capability가 흐르는 방향에 따라 결정되는 역할로, 업종을 가리지 않습니다. 사양은 B2B 조달이나 에이전트 간의 거래에도 동일한 프레임워크를 사용할 수 있다고 명시하고 있습니다.

여기서부터가 본론입니다. 입구인 발견부터 차례대로 이 공통 언어의 내용을 살펴보겠습니다.

.well-known/ucp를 열다

입구는 단순한 JSON입니다. UCP의 입구는 허탈할 정도로 소박합니다. 사업자가 자신의 사이트 https://<host>/.well-known/ucp에 두는 정적인 JSON 한 장. 이것뿐입니다. 이 JSON은 프로필(Profile)이라고 불리며, 에이전트는 GET 요청을 하는 것만으로 다음 5가지를 모두 해결할 수 있습니다.

• 사업자가 대응하는 프로토콜 버전 (Protocol Version)
• API 엔드포인트 (API Endpoint)의 위치
• 대응하는 capability (기능) 목록
• 수용 가능한 결제 핸들러 (Payment Handler)
• 메시지 서명을 검증하기 위한 공개키 (Public Key)

실제 구조를 살펴보겠습니다. Google 공식 가이드의 샘플에서 핵심이 되는 부분을 추출한 것입니다.

{
"ucp": {
"version": "2026-04-08",
...

구조는 깔끔하게 2층 구조입니다. ucp 객체가 "무엇을 할 수 있고, 어디에 연결해야 하는지"를 선언하며, 루트 직하에 나열된 keys가 JWK 형식의 공개키를 배포합니다 (RFC 7517의 JWK Set으로 그대로 사용할 수 있는 형식입니다). capability의 선언과 검증키의 배포가 동일한 1개 파일 내에서 이루어집니다. 이것이 사전 API 키 교환 없이 연결을 시작할 수 있는 permissionless onboarding (무허가 온보딩)의 기술적 토대입니다. 사양(Specification)의 원문은 다음과 같이 설명합니다.

any platform with a discoverable profile can interact with any business without prior registration.

사전 API 키 발급도, 공유 시크릿(Shared Secret)의 교환도 없습니다. 서로 상대방의 프로필 공개키를 확인하고, RFC 9421 (HTTP Message Signatures)로 메시지 서명을 상호 검증하는 설계입니다. 에이전트 측도 자신의 프로필을 공개하고, 후술할 UCP-Agent 헤더를 통해 자신의 위치를 알립니다.

인증이 이 서명 방식만 가능하다는 의미는 아닙니다. 이미 알고 있는 상대와는 OAuth 2.0, API 키, mTLS와 같은 사전 등록형 인증도 병용할 수 있습니다. 사전 등록 없이 시작할 수 있는 것은 RFC 9421의 서명뿐이라고 정리할 수 있습니다.

그리고 이 1개 파일에는 은근히 엄격한 배포 규칙이 부과되어 있습니다. 사양의 MUST/MUST NOT을 정리하면 다음과 같습니다.

리다이렉트 금지는 목적이 명확합니다. 프로필은 키를 배포하는 신뢰의 기점이므로, 리다이렉트를 통해 다른 오리진(Origin)으로 보내버리면 사칭의 입구가 될 수 있습니다. 캐시가 필수인 이유는 수많은 에이전트로부터 반복적으로 참조되는 파일이기 때문입니다. 매번 오리진으로 요청을 보내지 않도록 하는 전제입니다. 신뢰의 앵커(Trust Anchor)와 확장성(Scalability) 모두를 이 정적 파일 한 장에 담아내고 있습니다.

capability negotiation: 서버가 교집합을 통해 결정

프로필을 읽는 것만으로는 거래가 시작되지 않습니다. 에이전트 측에도 "자신이 무엇을 할 수 있는지"에 대한 선언이 있으며, 양측의 조율이 필요합니다. UCP는 이를 capability negotiation (기능 협상)이라 부르며, 설계상 가장 특징적인 부분이 바로 여기입니다.

메커니즘은 다음과 같습니다. 에이전트는 요청을 보낼 때마다 자신의 프로필 URL을 UCP-Agent 헤더로 제시합니다.

UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json"

형식은 RFC 8941의 Dictionary Structured Field입니다. 참고로 UCP를 호출하는 방식에는 후술할 4가지 트랜스포트(Transport)가 있으며, MCP 트랜스포트의 경우 HTTP 헤더 대신 tools/call의 인자 내 meta 객체에 동일한 정보를 넣습니다.

사업자 측은 이 프로필을 가져와 자신의 선언과 교집합을 계산하여, 유효한 capability를 확정합니다. 사양에서는 이를 server-selects 아키텍처라고 부릅니다. 원문을 인용하겠습니다.

Capability negotiation (기능 협상)은 server-selects 아키텍처를 따릅니다. 사업자는 자신이 선언한 capability (기능)와 플랫폼 프로필에 있는 capability의 교집합을 계산하여 활성 capability를 결정합니다.

결정하는 것은 항상 사업자 측입니다. 알고리즘은 4단계로 이루어집니다.

• 이름으로 교집합을 구함. 후보가 되는 것은 양측이 모두 선언한 capability뿐임
• 버전을 선택. 양측 배열에 공통된 버전 중 가장 최신 날짜를 채택하며, 공통된 것이 없으면 제외
• 고립된 확장(extension)을 제거. 부모 capability가 교집합에 남지 않은 확장을 제거
• 제거할 것이 없을 때까지 3단계를 반복하여 확장 체인(chain)에 대응

말로만 설명하면 파악하기 어려우므로, 사양에 충실한 예시를 통해 살펴보겠습니다. 수치가 포함된 완전한 예시는 원문에 없으므로, 이는 직접 구성한 예시입니다.

ap2_mandate는 사업자가 선언하지 않았으므로 1단계에서 탈락하고, fulfillment는 공통 버전이 없으므로 2단계에서 탈락합니다. 결과적으로 이 쌍에서 유효하게 되는 것은 checkout뿐입니다. 주목해야 할 점은, AP2를 통한 결제 승인을 사용할 수 있는지 여부조차 이 negotiation (협상) 결과에 따라 결정된다는 점입니다.

네임스페이스: 도메인을 가지면 확장을 정의할 수 있다

capability의 이름은 dev.ucp.shopping.checkout과 같은 reverse-domain 형식을 따릅니다. 사양에서 예시로 든 실제 명칭들을 나열합니다.

이 reverse-domain 명명 방식이 거버넌스(governance) 메커니즘 그 자체입니다. 사양은 capability의 spec/schema URL의 오리진(origin)이 네임스페이스의 권위 도메인과 일치해야 한다고 MUST(필수)로 규정하며, 일치하지 않는 capability의 거부를 요구합니다. dev.ucp.*는 UCP의 Tech Council이 관리하는 예약된 네임스페이스이며, com.example.*를 사용할 수 있는 것은 example.com의 소유자뿐입니다. 벤더는 누구의 승인도 기다리지 않고 독자적인 capability를 정의할 수 있으며, negotiation이 항상 opt-in 방식이므로 양측이 모두 선언했을 때만 유효하게 됩니다.

capability 위에는 service라는 묶음이 있으며, dev.ucp.shopping과 같이 vertical (수직 시장) 단위로 capability 그룹을 묶습니다. 향후 호텔 예약과 같은 새로운 vertical이 추가될 때는 dev.ucp.hotels와 같은 service 네임스페이스를 추가함으로써 확장되는 설계입니다. 지금까지의 계층 관계는 공식 전체 구성도가 이해하기 쉬우므로 첨부합니다.

UCP 전체 구성 (출처: Google / UCP 공식 문서)

버전은 2026-04-08과 같은 날짜 형식이며, capability마다 독립적으로 진행됩니다. 구버전을 병행 판매하는 사업자는 supported_versions

필드에서 버전별 프로파일을 광고할 수 있습니다. 트랜스포트(Transport)는 REST, MCP, A2A, EP(Embedded Protocol) 4종이 있으며, 동일한 capability를 여러 트랜스포트로 공개할 수 있습니다. 프로토콜의 의미론(Semantics)을 하나로 유지하면서, 호출 방식만 환경에 맞춰 선택하게 하려는 구상입니다.

체크아웃 상태 머신 (Checkout State Machine)

negotiation이 완료되면 드디어 거래입니다. UCP의 체크아웃은 세션(Session)으로 표현되며, 6개의 상태를 가진 상태 머신(State Machine)으로 정의되어 있습니다.

전이(Transition) 화살표는 사양의 상태도에 기반하지만, 사양 원문에는 전이 조건 레이블이 붙어 있지 않으므로 그림 중의 레이블은 보충 설명입니다.

이 상태 머신에서 짚고 넘어가야 할 설계 판단은, 상태를 결정하는 것이 항상 사업자 측이라는 점입니다. 원문은 한 문장으로 단언하고 있습니다.

"The business sets the status; the platform receives messages indicating what's needed to progress."

에이전트가 할 수 있는 것은 세션 생성(POST), 정보를 추가하는 PUT, 확정을 요청하는 Complete의 3가지뿐입니다. 상태 전이 그 자체는 지시할 수 없으며, 돌아온 status와 messages를 읽고 다음 수를 선택하는 관찰자입니다. AP2의 mandate 구동 방식이나 x402의 "402가 반환되면 결제 후 재전송"하는 모델과 비교하면, 이러한 비대칭성은 두드러집니다. 거래의 주도권은 마지막까지 사업자에게 있습니다. merchant-authority의 철저한 구현입니다.

messages 배열이 에이전트에 대한 지시서가 됩니다. error에는 severity가 필수이며, 이것이 다음 액션을 결정합니다.

path 필드에는 RFC 9535의 JSONPath가 들어가며, 예를 들어 $.items[1]과 같이 어떤 필드의 문제인지 기계 판독 가능하게(Machine-readable) 지시할 수 있습니다. 세션의 TTL은 지정이 없으면 생성으로부터 6시간입니다.

인간으로의 핸드오프 2가지 경로

requires_buyer_input이나 requires_buyer_review로 인해 인간의 차례가 왔을 때, UCP에는 두 가지 지속 경로가 있습니다.

첫 번째는 리다이렉트(Redirect)입니다. 사업자는 requires_escalation을 반환할 때 continue_url 제공이 MUST입니다. 에이전트는 구매자를 해당 URL로 유도하고, 인간이 브라우저에서 나머지를 완료합니다.

두 번째는 Embedded Checkout Protocol (ECP)입니다. 이름이 혼동될 수 있으나, 이는 앞서 4가지 트랜스포트 중 하나로 언급한 EP 위에 정의된 체크아웃 전용 사양입니다. 호스트인 에이전트 앱이 사업자의 체크아웃 UI를 iframe에 임베딩하고, postMessage 상의 JSON-RPC 2.0으로 양방향 통신을 합니다. 단순한 화면 임베딩이 아니라, 위임(Delegation) 계약이 3단계로 좁혀지는 설계입니다. 사업자가 허가하는 범위인 config.delegate, 호스트가 요구하는 URL 파라미터인 ec_delegate, 핸드셰이크(Handshake)인 ec.ready

확정되는 범위는 각각 이전 단계의 부분 집합이 됩니다. 결제 자격 증명 (credential) 취득과 같은 민감한 작업은 이 계약을 통해 명시적으로 위임된 경우에만 가능하며, 사양에는 "트리거가 Embedded Checkout 기점인 경우, 사이런트 토큰화 (silent tokenization)는 엄격히 금지된다"라고 명시되어 있습니다.

에스컬레이션 (Escalation)을 실패로 처리하지 않고, 상태 머신 (State Machine)과 UI 위임 프로토콜까지 준비하여 수용합니다. 에이전트 결제 실무에서 가장 큰 걸림돌은 "전 과정이 자동으로 끝나지 않는 케이스"이므로, 이 부분이 처음부터 사양화되어 있다는 점은 구현자 입장에서 큰 도움이 될 것입니다.

여기까지가 UCP의 핵심입니다. 사업자는 프로파일 (Profile)을 통해 기능을 공개하고, 에이전트와의 교집합으로부터 유효한 권한 (capability)을 결정하며, 체크아웃을 사업자 주도의 상태 머신으로서 진행합니다. 결제와 인가 (Authorization)는 이 위에 외부 사양으로서 합성됩니다. 이를 다음 섹션에서 살펴보겠습니다.

결제는 어디에 있는가: payment handler와 AP2 mandate의 접점

지금까지 결제에 대한 이야기가 거의 나오지 않았습니다. 당연한 결과인데, UCP의 핵심 사양은 결제 수단을 정의하지 않습니다. Google Developers Blog의 원문이 이 설계를 한마디로 표현하고 있습니다.

UCP models a unique payments architecture, separating what consumers use to pay (instruments) from payment handlers (payment processors)

소비자가 무엇으로 결제하는지를 나타내는 instrument와, 누가 결제를 처리하는지를 나타내는 handler를 분리하며, 코어는 그 연결 규약만을 정합니다. 구체적인 결제 방식은 각 프로바이더가 자신의 도메인에서 handler 사양을 공개합니다. Google Pay라면 com.google.pay, Shop Pay라면 dev.shopify.shop_pay와 같습니다. 사업자는 프로파일과 체크아웃 응답을 통해 "수용할 handler"를 광고하고, 에이전트는 그중에서 선택하여 해당 handler의 spec에 따라 credential을 생성합니다.

이 이면에서 작동하는 것이 서두에 언급한 4가지 역할 중 Credential Provider와 Payment Service Provider입니다. 사양은 이 결제 모델을 세 가지 양자 간 신뢰 관계로 설명합니다. 사업자와 CP/PSP 사이에는 계약과 API 키라는 기존 관계가 존재합니다. 플랫폼은 CP와 대화하여 토큰을 얻습니다. 플랫폼은 그 결과만을 사업자에게 전달합니다. 결제 실행의 전체 시퀀스 (Sequence)를 구성하면 다음과 같습니다.

도입 관점을 하나 먼저 짚어두자면, CP와 직접 대화하여 토큰을 취득하는 것은 주로 플랫폼 측입니다. 사업자 측에서 새롭게 필요해지는 것은 수용할 payment handler의 선언과, 해당 handler가 발행하는 credential을 처리할 수 있는 PSP 또는 결제 게이트웨이 (Payment Gateway)의 통합입니다. 이슈어 (Issuer)나 국제 브랜드까지 논의가 확장될지는 AP2의 mandate 분업을 살펴본 후 정리하겠습니다.

체크아웃 확정 시의 credential 제출은 다음과 같습니다.

{
"payment": {
"instruments": [
...

handler_id가 사업자가 광고한 handler를 가리키며, credential의 내용은 프로토콜 관점에서는 불투명 (opaque)합니다. 해석 방법은 handler 사양만이 알고 있습니다. credential은 플랫폼에서 사업자로 한 방향으로만 흐르며, 사업자가 응답에 credential을 다시 쓰는 것은 금지되어 있습니다 (MUST NOT). 또한 binding이라는 개념을 통해, credential은 대상 사업자와 거래 컨텍스트 (Transaction Context)에 결속되는 것을 상정합니다. UCP 코어는 credential의 내용을 해석하지 않으므로, 결속을 위한 구체적인 암호 방식은 handler 측에서 정의합니다. 목적은 사업자 A를 대상으로 한 credential을 가로채서 사업자 B에서 사용하는 리플레이 공격 (Replay Attack)을 방지하는 것입니다.

AP2 mandate가 삽입되는 정확한 위치

AP2를 알고 있는 독자에게 가장 중요한 부분은 여기입니다. 확장 dev.ucp.shopping.ap2_mandate가 checkout에 합성되면, 플로우의 두 곳에 서명이 삽입됩니다.

첫 번째는 사업자 측의 서명입니다. checkout 응답의 ap2.merchant_authorization에 JWS Detached Content 형식(<헤더>..<서명>)으로...

）에 「이 조건으로 판매한다」라는 사업자의 서명이 포함됩니다. 서명 대상은 checkout 페이로드에서 ap2 필드 자체를 제외한 것을 JCS (RFC 8785)로 정준화 (Canonicalization)한 것입니다. 알고리즘은 ES256 계열이며, 검증 키는 프로파일의 keys에서 kid로 참조합니다.

두 번째는 사용자 측의 승인입니다. 플랫폼은 Complete 요청의 ap2.checkout_mandate에 SD-JWT+kb 형식의 검증 가능한 자격 증명 (Verifiable Credential)을 넣습니다. kb는 key binding의 약자로, 제시자가 비밀키를 소유하고 있다는 증명이 첨부됩니다. 이 mandate는 사업자 서명이 포함된 완전한 checkout 응답을 내포해야 합니다 (MUST). 즉, 「사업자가 이 조건으로 판매한다고 서명한 것」에 대해 「사용자가 구매하겠다고 승인했다」는 이중의 증적이 하나의 credential에 통합됩니다.

그리고 강제성도 있습니다. negotiation에서 AP2 확장이 활성화된 세션에서는 mandate가 없는 Complete 요청은 mandate_required 에러로 거부됩니다. 고액 거래만을 위한 추가 옵션이 아니라, AP2가 활성화된 체크아웃 세션에서는 항상 필수입니다.

AP2에는 또 하나, Payment Mandate, 즉 결제 자체에 대한 승인이 있습니다. 공식 문서의 정리 내용에 따르면, 플랫폼은 Complete 요청에 두 가지 mandate를 제출하며, 검증자가 나뉩니다. Checkout Mandate를 검증하는 것은 사업자이고, Payment Mandate를 검증하는 것은 결제 프로세서 (Payment Processor)입니다. Payment Mandate는 ap2 필드가 아니라 payment instrument의 credential로서 전달되며, UCP로부터는 불투명한(opaque) 상태로 결제 측으로 흐릅니다. UCP가 프로토콜 계층에서 의미를 정의하는 것은 무엇을 살 것인지에 대한 승인인 Checkout Mandate까지입니다. 이러한 분업 구조를 이해하면, 서두의 「UCP는 결제 프로토콜이 아니다」라는 말이 구체적인 경계선으로서 납득될 것입니다. 효과도 명확하여, mandate는 체크아웃 상태에 암호학적으로 결합되어 있기 때문에, 다른 거래로의 전용이나 서명 후의 조건 변경을 감지할 수 있습니다. 재전송이나 중복 실행까지 방지하려면 구현 측에서의 일회성 소비 제어 (Idempotency control)가 별도로 필요합니다.

mandate는 이슈어 (Issuer)까지 도달할 필요가 있는가

카드 레일 (Card Rail)에 이 메커니즘을 탑재할 때, 관계자는 어디까지 확장될까요? 핵심은 앞서 언급한 분업입니다. Checkout Mandate의 검증은 사업자, Payment Mandate의 검증은 결제 프로세서입니다. 그리고 PSP가 Payment Mandate를 검증한 후에도, 카드 결제는 기존 방식대로 3DS와 이슈어의 승인 (Authorization)을 거칠 수 있습니다. 즉, 초기 도입 단계에서는 이슈어나 국제 브랜드가 mandate를 인식할 필요가 없습니다.

두 가지 판정은 역할이 다릅니다. mandate 검증이 확인하는 것은 「이 에이전트에게 이 결제를 시도할 권한이 있는가」입니다. 이슈어의 승인이 확인하는 것은 「이 카드 계좌에서 실제로 결제해도 되는가」입니다. 두 가지 모두를 통과 조건으로 하므로, mandate 도입으로 인해 본인 인증이나 신용 판단이 완화되는 일은 없습니다. 기존 카드 레일의 전단에 에이전트에 대한 위임 확인 단계가 한 단계 추가될 뿐입니다.

단, 이 구성에서 mandate의 효력은 사업자와 PSP의 범위 내로 한정됩니다. 이슈어에게는 mandate가 전달되지 않으므로, 위임의 상한이나 스코프를 승인 판단에 사용하거나, mandate를 근거로 3DS를 생략하거나, 책임 분계 (Responsibility demarcation)를 변경할 수는 없습니다. 판정이 이중이 되는 만큼 성공률도 낮아질 수 있습니다. 3DS 챌린지가 발생하면, 자율 흐름 (Autonomous flow)은 인간으로의 핸드오프 (Handoff)로 전환됩니다. 도입은 2단계로 생각하는 것이 정확합니다.

UCP와 AP2를 사용하기 시작하는 단계라면 PSP 게이트형만으로도 성립합니다. 브랜드나 이슈어가 등장하는 시점은, mandate를 전단 체크 용도가 아니라 카드 네트워크상의 공식적인 인증이나 책임 이전의 근거로 취급하고 싶어지는 단계입니다. 도입의 병목 (Bottleneck)은 자사의 API 구현보다는, 대응하는 월렛과 대응하는 PSP의 확산, 그리고 그 너머의 네트워크 측 규칙 정비에 있다고 저는 보고 있습니다.

비교를 위해 OpenAI 측도 살펴보면, ACP의 결제는 Stripe의 SharedPaymentToken 방식입니다. 구매자의 결제 수단에 대한 권한을 1개 사업자·1개 통화·상한액·유효기간으로 스코프(scope)한 토큰으로서 발행하며, 사업자는 Stripe의 PaymentIntent로 상환(redeem)합니다. credential을 거래에 결속(binding)한다는 방어적 사고방식은 UCP의 binding과 공통적이지만, UCP가 프로세서 중립적인 handler 교체 방식인 것에 반해, SharedPaymentToken의 문서는 Stripe API를 전제로 작성되어 있습니다. 결제의 주도권을 어디에 둘 것인가에 대한 설계 차이가 명확히 드러나는 부분입니다.