구글 UCP는 결제 요청마다 헤더 네 개를 싣는다. 그중 셋은 나중의 분쟁을 위한 것이다

2026년 1월 11일, 구글이 Universal Commerce Protocol을 공개했습니다. AI 에이전트가 물건을 사게 해주는 오픈소스 표준이고, 쇼피파이와 공동 개발했으며, 엣시·웨이페어·타깃·월마트·아디옌·아메리칸 익스프레스·마스터카드·스트라이프·비자·잘란도를 포함해 20곳이 넘는 파트너가 지지에 이름을 올렸습니다.

뒤따른 보도는 전부 쇼핑 이야기였습니다. 대신 둘러봐 주는 에이전트, 대신 결제해 주는 에이전트, 장바구니의 종말 같은 것들이죠.

그런데 명세를 읽어보면, 쇼핑이 그 안에서 가장 재미없는 부분이라는 사실이 드러납니다. UCP가 유별날 정도로 공들여 표준화한 것은 구매가 아닙니다. 그 구매가 양쪽 말대로 이뤄졌다는 증거입니다.

요약:

• 모든 변경성 UCP 요청에는 헤더 네 개가 실립니다. 그중 셋, 즉 request-signature, idempotency-key, request-id는 거래 자체에는 아무 기여도 하지 않습니다. 나중에 누군가가 무엇을 요청했는지, 그것이 한 번만 요청됐는지, 그리고 그 기록을 다시 찾을 수 있는지를 증명하기 위해 존재합니다.
• 부인 방지가 이름 붙은 기능입니다. 선택적 AP2 맨데이트 확장(dev.ucp.shopping.ap2_mandate)에서는 사업자가 결제 조건에 암호학적으로 서명하고, 플랫폼은 사용자가 그 조건을 승인했음을 증명하는 암호학적 맨데이트를 제공합니다. 명세가 밝힌 목적은 "변조와 분쟁의 위험을 크게 줄이는 것"입니다.
• 지지 파트너 수는 도입 사업자 수가 아닙니다. "20곳이 넘는 글로벌 파트너"는 구글이 발표한 표현이고, 이는 지지를 뜻합니다. 이 글을 쓰는 시점에 UCP를 실제로 연동한 판매자 수를 밝힌 1차 자료는 찾지 못했습니다.

헤더 구성은 구글의 공개 당일 실습 문서에서 가져왔습니다. 출처는 글 끝에 정리했습니다.

거짓 없이 줄이면 UCP는 이렇게 된다

논의를 시작하기 전에, 직접 확인할 수 있는 사실부터 정리합니다. 아래는 ucp.dev에 공개된 명세와 구글 개발자 블로그에서 가져왔으며, 둘 다 2026년 9월 5일에 확인했습니다.

이 표에서 두 가지는 잠시 멈춰 볼 만합니다. 대부분의 소개 글이 둘 다 건너뛰기 때문입니다.

첫째는 전송 방식 줄입니다. UCP는 MCP 전용도 아니고 REST 전용도 아닙니다. 똑같이 선언된 데이터를 REST·MCP·A2A·임베디드 바인딩으로 모두 제공하고, 무엇을 쓸지는 사업자가 고릅니다. 어떤 에이전트 배관이 이길지에 베팅하지 않겠다는 의도적인 거부입니다.

둘째는 날짜 기반 버저닝입니다. 2026-04-08은 시맨틱 버전이 아니라 날짜입니다. 명세가 밝힌 이유는 시간순 정렬과 명확한 비교지만, 실질적인 효과는 따로 있습니다. 협상된 모든 세션이 그 세션을 지배한 규칙의 날짜를 함께 기록하게 된다는 것입니다. 버저닝 결정의 옷을 입은 기록 보존 결정이고, 문서 나머지 전체의 성격을 미리 알려줍니다.

UCP는 N×N 병목을 죽이려고 만들어졌다

구글의 설명은 N×N 문제입니다. 대화형 표면에 등장하고 싶은 사업자는 표면마다 맞춤 연동을 만들어야 하고, 표면은 사업자마다 따로 온보딩해야 하며, 결국 아무것도 출시되지 않습니다.

같은 날 공개된 쇼피파이 엔지니어링 글은 같은 문제를 아래에서 파고듭니다. 저자인 일리야 그리고릭 디스팅귀시드 엔지니어는 20년 넘는 기간, 수십억 건의 거래, 수백만 판매자를 겪은 끝에 커머스는 정규화를 거부한다고 말합니다. "결제 옵션과 규칙은 장바구니, 구매자, 시장의 속성에 따라 달라진다. 할인은 세법에 맞먹는 중첩·조합 규칙을 갖는다. 이행 옵션은 걷잡을 수 없는 조합으로 폭발한다." 그리고 남길 만한 문장이 이어집니다. "이 복잡성은 버그가 아니라, 다양한 리테일러에게서 창발하는 성질이다."

이 한 줄이 아키텍처 전체를 설명합니다. 판매자가 근본적으로 서로 다르다는 것을 받아들이면, 행동을 표준화할 수는 없습니다. 표준화할 수 있는 것은 판매자가 자기 행동을 선언하는 방식, 그리고 에이전트가 방금 무엇에 동의했는지 알아내는 방식뿐입니다.

사업자가 /.well-known/ucp에 공개하는 구조. 출처: UCP 명세 2026-04-08, Overview.

대화는 디스커버리가 끝난 뒤에 시작된다

명세와 구글 실습 문서가 설명하는 흐름은 다음과 같습니다. 순서 자체가 논점이므로 그대로 따라가 볼 만합니다.

1. 사업자가 /.well-known/ucp에 프로파일을 공개합니다. 프로토콜 버전, 하나 이상의 서비스(dev.ucp.shopping), 그 안의 케이퍼빌리티, 전송 방식과 엔드포인트, 사용 가능한 결제 핸들러, 그리고 뒤에서 중요해질 공개 signing_keys를 선언합니다.
2. 에이전트는 요청마다 자기 프로파일을 알립니다. RFC 8941 딕셔너리 문법을 쓰는 UCP-Agent 헤더로요. UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json" 같은 형태입니다. MCP 전송에서는 같은 정보가 meta 객체에 실립니다.
3. 사업자가 교집합을 계산합니다. 자신이 지원하는 케이퍼빌리티 중 플랫폼도 선언한 것만 남기고, 살아남은 각각에 대해 양쪽 배열에 모두 존재하는 버전 중 가장 높은 것을 고릅니다. 공통 버전이 없으면 그 케이퍼빌리티는 통째로 빠집니다.
4. 고아가 된 확장은 잘라냅니다. extends: "dev.ucp.shopping.checkout"을 선언한 확장은 checkout이 살아남지 못하면 사라집니다. 더 이상 제거할 것이 없을 때까지 이 과정을 반복하므로 연쇄적인 의존도 처리됩니다.
5. 선택은 사업자가 합니다. UCP는 서버가 고르는 구조입니다. 에이전트가 아니라 판매자가 이번 세션에서 무엇이 활성인지 정하고, 활성 케이퍼빌리티 레지스트리를 응답에 되돌려 줍니다.

이름 규칙은 관행이 아니라 통제 대상입니다. 모든 케이퍼빌리티는 {역방향-도메인}.{서비스}.{케이퍼빌리티} 형식입니다. 표준은 dev.ucp.shopping.checkout, 판매자 고유 기능은 com.example.payments.installments 같은 식이죠. 리테일러는 아무에게도 허락받지 않고 누구와도 충돌하지 않으면서 자기만의 케이퍼빌리티를 만들 수 있습니다. 역방향 도메인 자체가 권위이기 때문입니다.

실패에도 별도의 분류 체계가 있고, 그 구분이 시사적입니다. 명세는 디스커버리 실패(전송 오류. invalid_profile_url은 400, profile_unreachable은 424, profile_malformed는 422)와 협상 실패를 나눕니다. 협상 실패는 비즈니스 결과이므로 평범한 200에 capabilities_incompatible을 담아 돌아옵니다. "당신에게 닿지 못했다"와 "우리 사이에 공통점이 없다"는 다른 사건이고, UCP는 이 둘을 하나의 400으로 뭉개기를 거부합니다.

모든 변경 요청에 헤더 네 개가 실린다

이제 실제 호출을 보겠습니다. 구글이 공개 당일 예제에서 샘플 꽃집을 상대로 결제 세션을 만드는 요청입니다.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

헤더 네 개입니다. 각각이 무엇을 위한 것인지 물어보면 패턴이 드러납니다.

넷 중 셋은 거래를 위한 것이 아닙니다. 그 거래를 둘러싼 분쟁을 위한 것입니다.

API 위생 관리의 우연한 결과가 아닙니다. 멱등성 키와 요청 ID가 결제 분야의 평범한 모범 사례인 것은 맞습니다. 하지만 명세는 거기서 상당히 더 나아가고, 더 나아갈수록 의도는 더 분명해집니다.

부인 방지는 설계 목표지, 컴플라이언스 뒤처리가 아니다

UCP는 사업자가 받아들일 수 있는 인증 방식 네 가지를 제시합니다. API 키, OAuth 2.0, mTLS, 그리고 RFC 9421 기반 HTTP 메시지 서명입니다. 앞의 셋은 평범합니다. 네 번째는 특별한 일을 합니다.

메시지 서명 방식에서는 양쪽 모두가 케이퍼빌리티를 선언하는 바로 그 프로파일 문서의 signing_keys 배열에 공개 키를 함께 게시합니다. 검증자는 Signature-Input 헤더에서 keyid를 꺼내 서명자가 공개한 키 집합의 kid와 맞추고 서명을 확인합니다. 공유 비밀도, 사전 등록도, 계정도 필요 없습니다. 명세는 이 결과를 무허가 온보딩이라 부릅니다. "발견 가능한 프로파일을 가진 어떤 플랫폼이든 사전 등록 없이 어떤 사업자와도 상호작용할 수 있다"는 것입니다.

명백한 구멍은 아이덴티티 바인딩이 막습니다. 어떤 방식을 쓰든 검증자는 인증된 주체가 UCP-Agent에 적힌 프로파일을 대신해 행동할 권한이 실제로 있는지 확인해야 하고, 둘이 충돌하면 요청을 거부해야 합니다. 자기 자신으로 인증한 뒤 남의 에이전트인 척할 수는 없습니다.

그리고 사업자에서 플랫폼으로 가는 웹훅은 반드시 서명해야 합니다. 권고가 아니라 의무입니다. 배송·인도·반품 같은 주문 생애주기 갱신은 프로토콜 안에서 이 요구가 절대적인 유일한 지점입니다. 돈이 움직인 뒤에 도착하는 메시지이고, 실시간으로 지켜보는 사람이 아무도 없기 때문입니다.

출처: UCP 명세 2026-04-08, Identity & Authentication 및 Transaction Integrity 절.

그리고 사다리의 꼭대기가 있습니다. 자율 에이전트와 고액 거래를 위해 UCP는 선택적 확장 dev.ucp.shopping.ap2_mandate를 정의합니다. 양쪽이 이 확장을 협상하면 다음이 성립합니다.

• 사업자가 결제 조건에 암호학적 서명을 제공합니다.
• 플랫폼이 사용자가 그 조건을 승인했음을 증명하는 암호학적 맨데이트를 제공합니다.

에이전트는 비(非)에이전트 표면에서 사용자의 개인 키로 맨데이트 객체에 서명합니다. 즉 사람은 곧 자기 돈을 쓰려는 에이전트 루프 안이 아니라, 자기가 통제하는 화면에서 승인합니다. 명세가 직접 밝힌 목적은 그대로 인용할 가치가 있습니다. 보안 상용구가 아니기 때문입니다. 이 방식은 "거래 세부 사항과 참여자 동의에 대해 강력한 종단 간 암호학적 보증을 제공하며, 변조와 분쟁의 위험을 크게 줄인다"고 적혀 있습니다.

핵심은 이것입니다. 에이전트가 쇼핑만 하게 하려는 프로토콜이라면 이 중 어느 것도 필요 없습니다. 판매자 쪽 서명된 조건과 사용자 쪽 서명된 맨데이트는 구매의 기능이 아닙니다. 6주 뒤에, 누가 옳았는지 판단해야 하는 사람 앞에서, 그 구매를 두고 다투는 일의 기능입니다.

어디서부터 서사가 근거를 앞지르는가

UCP를 두고 반복되는 이야기 중 1차 자료가 그대로 뒷받침하지 않는 것이 셋 있습니다.

"20곳 이상"은 지지 파트너 수입니다. 구글의 표현은 UCP가 "20곳이 넘는 파트너에 의해 공동 개발되고 지지받았다"는 것입니다. 지지는 공개적인 지원 표명입니다. 출시된 연동이 아니고, 살아 있는 판매자는 더더욱 아닙니다. UCP로 실제 거래하는 판매자 수를 밝힌 1차 자료를 찾아봤지만 없었습니다.

"개방형 표준"과 "구글의 표준"은 둘 다 참이고, 그 긴장은 실재합니다. 명세는 오픈소스이고, 깃허브 저장소는 풀 리퀘스트를 받으며, 이름 규칙은 누구나 자기 네임스페이스를 주장할 수 있도록 일부러 설계됐습니다. 동시에 첫 레퍼런스 구현을 만든 것은 구글이고, 그 구현에 참여하려면 결제 가능한 상품을 갖춘 활성 구글 머천트 센터 계정이 필요합니다. 중립적인 프로토콜, 그러나 문이 달린 첫 무대인 셈입니다.

UCP는 판매자를 없애지 않습니다. 자주 왜곡되므로 분명히 적습니다. UCP 아래에서 사업자는 자기 비즈니스 로직을 그대로 보유하고 기록상 판매자(Merchant of Record) 지위를 유지합니다. 쇼피파이의 임베디드 체크아웃 프로토콜은 반대 방향에서 같은 약속을 합니다. 흐름에 사람이 필요해지면 에이전트가 continue_url을 불러오고, 판매자의 실제 결제 화면이 JSON-RPC 2.0 채널을 통해 에이전트 표면 안에 렌더링되며, 거래를 마무리하는 것은 판매자입니다. 에이전트는 표면이지 대체재가 아닙니다.

확인하지 못한 네 가지, 그대로 표시한다

확인 시점에 ucp.dev에 공개된 명세는 2026-04-08 버전이고, 표준 케이퍼빌리티 목록은 Cart, Checkout, Identity Linking, Order입니다. 이는 1월 11일 실습 문서와 다릅니다. 그 문서의 예제는 2026-01-11 버전으로 돌아가며 checkout, discount, fulfillment를 보여줍니다. 두 날짜 사이에 무언가가 추가됐습니다. 언제인지 특정할 수 있는 1차 변경 이력이나 중간 버전의 날짜 있는 릴리스 노트는 찾지 못했으므로, 릴리스 사건이 아니라 차이 자체만 보고합니다.

구글, 쇼피파이, 지지 파트너 어느 쪽에서도 UCP를 실제 운영 중인 판매자 수를 공개한 자료를 찾지 못했습니다. 숫자가 없다는 것이 숫자가 작다는 증거는 아니지만, 저희가 아무 숫자도 적지 않는 이유는 됩니다.

구글은 검색의 AI 모드와 제미나이 앱 안에서 구매를 구동하는 첫 레퍼런스 구현을 만들었다고 밝혔습니다. 그 출시의 이용 가능 범위, 지역, 규모는 독립적으로 확인하지 않았습니다.

UCP가 에이전트 커머스의 그 표준이 될지는 이 글을 쓰는 시점에 알 수 없고, 그렇지 않다고 말하는 글은 추측하는 것입니다. 정직한 독법은 더 좁습니다. 명세가 존재하고, 공개돼 있으며, 증명에 유별나게 공을 들였고, 아주 큰 회사 여럿이 발표에 이름을 올렸습니다.

서명되지 않은 절반

커머스에서 한 걸음 물러나 보겠습니다. 흥미로운 부분은 일반화되기 때문입니다.

UCP가 그리는 세계에서는 기계가 나를 대신해 행동하고, 그 행동의 모든 단계가 무언가를 남깁니다. 누가 요청했는지는 서명으로, 어떤 조건이었는지도 서명으로, 몇 번이었는지는 키로, 어떤 순서였는지는 상관 ID로요. 6주 뒤에 청구가 다퉈질 때, 남아 있는 산출물이 있습니다. 아무도 기억할 필요가 없습니다.

이제 그 행동의 권한이 어디서 왔는지 생각해 봅시다. 에이전트가 400개를 사는 것은 구매 결정이 내려졌기 때문입니다. 계약이 갱신되는 것은 누군가 조건에 동의했기 때문입니다. 범위가 바뀌는 것은 두 사람이 목요일에 이야기를 나눴고 그중 한 명이 그러자고 했기 때문입니다.

그 대화들이 같은 워크플로의 서명되지 않은 절반입니다. 기계 쪽 절반은 암호학적 영수증과, 분쟁을 일급 시나리오로 다루는 명세 위에 지어지고 있습니다. 사람 쪽 절반은 대부분의 조직에서 누군가의 기억, 그와 다른 누군가의 기억, 그리고 그 둘로부터 쓰인 요약입니다.

이 비대칭은 나아지기 전에 더 나빠질 것입니다. 기계 쪽은 명세의 속도로 개선되고 사람 쪽은 개선되지 않기 때문입니다. 그리고 실패 양상은 구체적입니다. 사람들이 거짓말을 한다는 것이 아닙니다. 파생된 산출물, 즉 요약이나 회의록이나 액션 아이템 목록이, 그것이 파생돼 나온 원본이 사라진 순간부터 기록 그 자체로 취급된다는 것입니다. 요약은 구조상 손실이 있습니다. 그래서 쓸모가 있습니다. 그리고 바로 그 점 때문에 1차 자료로는 부적합하고, 원본이 폐기된 뒤에는 손실 있는 요약과 정확한 요약을 구분할 방법이 없습니다.

UCP 설계자들은 이를 프로토콜 계층에서 이해했고 문서로 남겼습니다. 서명된 원본을 보관하고, 원하는 것은 무엇이든 그로부터 파생하되, 그 파생이 언제든 움직이지 않은 무언가와 대조될 수 있게 하라는 것입니다. 기술이 아니라 규율이고, POST /checkout-sessions에 적용되는 만큼이나 사람들이 한 시간 동안 나눈 대화에도 똑같이 적용됩니다.

결론: 에이전트 커머스는 쇼핑 옷을 입은 영수증 표준이다

Universal Commerce Protocol은 보통 AI 에이전트가 물건을 사는 방법으로 설명됩니다. 끝까지 읽고 나면, 에이전트가 하는 모든 일이 곧 마주할 질문에 답하려는 시도라고 부르는 편이 더 정확합니다. 기계가 나를 대신해 행동했을 때, 내가 무엇에 동의했는지에 대해 정확히 무엇을 증명할 수 있는가?

UCP의 답은 좋은 답입니다. 케이퍼빌리티를 공개적으로 선언하고, 조건에 서명하고, 동의에 서명하고, 재시도에 키를 붙이고, 호출을 상관시키고, 그 뒤에 벌어진 일을 알리는 웹훅에도 서명하라는 것입니다. 이 프로토콜이 이길지는 정말로 열려 있습니다. 하지만 이 프로토콜이 중심에 놓은 질문은 누가 이기든 사라지지 않습니다.

그래서 곱씹어 볼 질문 하나가 남습니다. 곧 당신의 에이전트는 자기가 무엇에 동의했는지에 대해, 당신이 무엇에 동의했는지보다 더 나은 기록을 갖게 됩니다. 그 끝은 어디일까요?

---

Telli.sh는 여기에 있습니다: 저희가 만드는 것이 바로 그 서명되지 않은 절반입니다. Telli.sh는 대화를 녹음하고, 화자를 분리하고, 15개 언어로 실시간 번역하며, 생성한 모든 요약 옆에 원본 녹음과 전체 전사를 함께 보관합니다. 파생된 산출물이 유일한 산출물이 되지 않도록요. Telli.sh는 UCP를 구현하지 않으며 그렇게 주장하지도 않습니다. 저희가 다루는 것은 같은 문제의 반대편, 즉 에이전트의 행동을 승인하는 결정이 대개 말로 내려지고 어디에도 남지 않는다는 쪽입니다.

다음 의사결정 회의를 기록해 보기

출처

• Universal Commerce Protocol 명세, Overview, 버전 2026-04-08 — 서비스·케이퍼빌리티·확장 모델, 이름 규칙, 날짜 기반 버저닝, 케이퍼빌리티 교집합 알고리즘, 협상 및 서명 오류 코드, 표준 케이퍼빌리티(Cart, Checkout, Identity Linking, Order), 전송 방식, UCP-Agent 헤더와 RFC 8941 문법, 인증 방식과 무허가 온보딩, signing_keys를 통한 키 디스커버리, 아이덴티티 바인딩, 웹훅 서명 의무, Transaction Integrity and Non-Repudiation 절. 2026년 9월 5일 확인
• Google Developers Blog, "Under the Hood: Universal Commerce Protocol (UCP)", 2026년 1월 11일 — 파트너 목록과 20곳 이상 지지 수치, AP2·A2A·MCP 호환성, N×N 설명, /.well-known/ucp 매니페스트, 5단계 실습과 POST /checkout-sessions 헤더 구성, 기록상 판매자 지위와 임베디드 옵션, AI 모드·제미나이의 구글 레퍼런스 구현, 머천트 센터 요건. 2026년 9월 5일 확인
• Shopify Engineering, Ilya Grigorik, "Building the Universal Commerce Protocol", 2026년 1월 11일 — 20년 이상·수십억 건 거래·수백만 판매자라는 배경, "버그가 아니라 창발하는 성질"이라는 논지, 네 가지 설계 원칙, continue_url을 통한 JSON-RPC 2.0 임베디드 체크아웃 프로토콜 핸드오프. 2026년 9월 5일 확인
• Agent Payments Protocol (AP2) — UCP가 호환성을 선언한 결제 프로토콜
• GitHub의 Universal Commerce Protocol — 두 발표에서 모두 지목한 오픈소스 저장소
• GPT-6 Astra 분석과 캡처 계층이 여전히 결정하는 것 — 모델 쪽에서 본 같은 논지. 추론 품질은 그것이 추론하는 기록을 만든 쪽에서 이미 상한이 정해진다