에이전트가 대신 장바구니 채우는 시대 🛒, Universal Commerce Protocol(UCP)로 준비해보세요

요즘 쇼핑을 할 때 종종 이런 상상을 합니다.
내가 직접 검색하고 비교하는 대신, 내 AI 에이전트가 내 소비 패턴을 알고 알아서 최적의 상품을 고르고, 포인트와 쿠폰까지 계산해서 결제 직전까지 다 끝내놓는 그림이죠.

문제는, 이 멋진 그림이 기술이 없어서가 아니라 각 쇼핑몰, 각 결제사, 각 플랫폼이 다 따로 놀기 때문에 잘 안 돌아간다는 데 있습니다.

이 글에서 이야기할 Universal Commerce Protocol(UCP)은 이 파편화된 커머스 세계를 하나의 공통 언어로 이어보겠다는 시도입니다.
개발자 입장에서도 흥미롭고, 비개발자에게도 꽤 직접적인 영향을 줄 수 있는 변화라서, 개인적으로 꽤 눈여겨보고 있는 프로젝트입니다.

먼저 전체 그림을 간단히 정리하자면 UCP는

• 이커머스의 전 과정을 표준화된 프로토콜로 표현하고

• AI 에이전트가 사람 대신 쇼핑을 진행할 수 있게 설계되어 있고

• 구글, 쇼피파이, 월마트 등 굵직한 플레이어들이 함께 만들고 있는

• 오픈소스, 오픈 프로토콜입니다.

공식 사이트와 스펙 문서는 여기서 직접 보실 수 있어요.

• UCP 공식 사이트: https://ucp.dev

• 스펙 개요: https://ucp.dev/latest/specification/overview

• GitHub 저장소: https://github.com/Universal-Commerce-Protocol/ucp

이제 하나씩, 조금 천천히 풀어보겠습니다.

🧭 UCP가 노리는 문제: 왜 또 새로운 프로토콜인가

처음 UCP를 봤을 때 들었던 생각은 이거였습니다.
결제나 주문 연동 규격은 예전부터 많았는데, 이건 뭐가 다르지?

요즘 이커머스를 떠올려 보면, 사실상 거대한 섬들의 집합입니다.
아마존, 쿠팡, 11번가, 각 브랜드 자사몰, 인스타 쇼핑, 오프라인 매장 앱까지 전부 API도 다르고, 인증 방식도 다르고, 심지어 주문 상태 명칭조차 제각각이죠.

개발자 입장에서는 이런 상황 때문에 매번 이런 일을 반복합니다.

• 플랫폼마다 다른 결제 API 문서 읽기

• 서로 다른 주문 구조를 백엔드에서 다시 매핑

• 각자의 OAuth, 토큰, 웹훅 방식에 맞춰 커스텀

• 새로운 입점처가 생길 때마다 또 한 번의 통합 프로젝트

여기에 AI 에이전트까지 끼어들려고 하니 난이도가 확 튀어 오릅니다.
에이전트가 인간처럼 클릭 한 번으로 화면을 이해하는 것도 아니고, HTML 파싱해서 추론하는 것도 한계가 있으니까요.

UCP가 겨냥하는 지점은 아주 명확합니다.

• 이커머스 전 과정에 대해 공통 언어를 만들고

• 사람이 아니라 에이전트가 쓰기 쉬운 형태로 정의하고

• 어떤 플랫폼이든 이 언어만 이해하면 서로 얽혀서 돌아가게 하자

라는 방향성이죠.

개인적으로는 HTTP라는 공통 언어가 생기면서 웹이 폭발적으로 성장했던 것과 비슷한 느낌을 조심스럽게 떠올리고 있습니다. 물론 아직은 초기 단계지만요.

🧩 기존 이커머스 통합과 UCP의 결정적 차이

기존 이커머스 통합을 해보신 분들이라면 공감하실 텐데, 대부분의 패턴은 어떤 특정 플랫폼의 API에 종속되는 방식이었습니다.

예를 들어,

• 쇼피파이 앱을 만들려면 쇼피파이 API에 딱 맞춰 설계

• 아마존 셀러 통합을 하려면 또 완전히 별도의 연동

• 국내 오픈마켓은 각자 자체 스펙

이렇게 각각의 플랫폼이 작은 세계를 통째로 제공하고, 우리는 거기에 맞춰 들어가는 방식이죠.

UCP는 관점을 완전히 뒤집습니다. 중심이 플랫폼이 아니라 Capability, 즉 기능 단위입니다.

간단히 말해서

• 체크아웃

• 주문

• ID 연동

같은 기능을, 특정 회사가 아닌 프로토콜 차원에서 표준화해 두고, 누가 구현하든 이 규격만 맞추면 에이전트나 다른 시스템이 똑같은 방식으로 사용할 수 있게 만드는 구조예요.

여기서 크게 눈에 들어온 부분이 세 가지였습니다.

1️⃣ 기능 단위로 쪼개고, 표준 이름을 붙인다

UCP는 API 엔드포인트를 서비스별로 다르게 두는 대신

• Checkout

• Identity Linking

• Order

처럼 의미 있는 기능 단위(Capability)를 표준으로 선언합니다.

에이전트 입장에서 보면, 이 판매자가 쇼피파이를 쓰는지, 자체 빌드를 했는지, 다른 SaaS를 쓰는지는 전혀 신경 쓸 필요가 없습니다.

UCP의 Checkout Capability만 지원하면,

• 장바구니 구성

• 옵션/배송비/세금 계산

• 결제 세션 완료

까지를 한 공통 인터페이스로 다룰 수 있죠.

이게 왜 중요하냐면, 앞으로 에이전트 기반 커머스가 커질수록, 에이전트는 수십, 수백 개의 상점을 한 번에 뒤져야 할 텐데, 이때마다 각기 다른 API 형태를 이해해야 한다면 사실상 스케일링이 불가능하기 때문입니다.

2️⃣ 비즈니스가 스스로 기능을 광고하고, 에이전트는 자동으로 발견한다

지금까지의 API 연동은 늘 이런 패턴이었습니다.

• 개발자 포털 가입

• API 문서 읽고

• 키 발급받고

• 샘플 코드 보면서 연동

UCP에서는 비즈니스 측이 프로필에 자기 기능을 선언해둡니다. 어떤 Capability를 지원하는지 표준 포맷으로 기술해 놓고, 에이전트는 이를 보고 자동으로 연동할 수 있습니다.

즉,

• 기능을 제공하는 쪽은 '나는 Checkout, Order, Identity Linking을 이렇게 지원해요'
  라고 스스로 명함을 내밀고

• 기능을 사용하는 쪽은 '이 판매자는 Checkout과 Order만 되네? 그럼 이렇게 쓰자'
  하는 식으로 역으로 판별합니다.

이렇게 되면 API 연동이라는 행위 자체가 문서 기반 수동 작업에서, 프로토콜 기반 자동화에 가까워집니다.

이 부분은 스펙 개요 페이지에서도 핵심 가치로 강조하고 있어서, 관심 있으시면 천천히 읽어보셔도 좋습니다.

3️⃣ 사람 클릭이 아닌, 에이전트 사용을 전제로 설계

기존 쇼핑몰은 기본적으로 사람이 브라우저에서 클릭한다는 가정을 전제로 만들어졌습니다.

• 버튼 위치

• 결제 페이지 이동 흐름

• 팝업으로 뜨는 약관 동의

이런 것들이 전부 사람 눈을 위한 디자인이죠.

UCP는 아예 처음부터 에이전트가 주체라는 관점으로 설계되어 있습니다.

• Agent Payments Protocol(AP2) 기반 결제 권한 위임

• Verifiable Credentials를 활용한 신뢰 가능한 자격 증명

• 사용자를 대신해서 장바구니 구성, 세금 계산, 결제 승인까지 처리

즉, 사람이 하는 클릭 시퀀스를 그대로 복제하는 게 아니라, 에이전트가 바로 이해하고 실행할 수 있는 수준으로 추상화한 프로토콜이라는 점이 핵심입니다.

이게 실제로 구현되기 시작하면, 사용자는 에이전트에게

• 이번 달 생필품, 지난달이랑 비슷한 구성으로 최저가로 주문해줘

• 출장 가기 전날 도착하도록 공항 근처 호텔에서 쓸 물건만 골라줘

같은 자연어 명령만 내리고, 나머지는 전부 백엔드에서 에이전트들끼리 통신하면서 알아서 돌아가게 될 가능성이 큽니다.

🛠 UCP가 제공하는 핵심 기능 세 가지

UCP는 커머스 전체를 다 하겠다고 욕심 부리기보다, 초기 버전에서 세 개의 핵심 Capability에 집중하고 있습니다. 개인적으로도 이 선택이 꽤 현실적이라고 느꼈습니다.

🧾 Checkout: 결제 버튼이 아니라, 결제 프로세스 전체

Checkout Capability는 단순히 결제 요청 한 번 보내는 수준이 아닙니다.

여기에는

• 장바구니의 각 상품 정보

• 수량, 옵션, 가격

• 세금, 배송비, 할인

• 배송 옵션 선택

같은 것들이 하나의 Checkout 세션 안에 포함됩니다.

UCP의 예시 JSON을 보면 감이 금방 옵니다.

• ucp 버전

• 체크아웃 id와 상태

• currency

• buyer 정보

• line_items 배열

• fulfillment 옵션

이런 필드를 표준 스키마로 고정해 두니, 에이전트는 더 이상 필드 이름을 추론하거나 HTML을 파싱할 필요 없이, 바로 구조화된 데이터를 읽고 판단할 수 있습니다.

스펙에서 말하는 것처럼, 여기서 중요한 포인트는

• 에이전트가 이 구조를 기반으로 자체 UI를 그릴 수도 있고

• 판매자가 제공하는 결제 UI를 임베딩 형식으로 호출할 수도 있다는 점입니다.

즉, 완전 자동화와 판매자 고유 UX 사이에 적당한 유연성을 남겨둔 셈입니다.

🧑‍💻 Identity Linking: OAuth 2.0 기반, 에이전트를 위한 계정 연동

에이전트가 우리 대신 뭔가를 하려면, 결국 나의 계정 권한을 일부 위임해야 합니다.

• 이전 주문 내역 조회

• 적립 포인트 사용

• 특정 멤버십 할인 적용

이런 것들은 모두 그 상점 내 내 계정과 연결되어야 가능한 일입니다.

UCP는 이 부분을 완전히 새로 발명하지 않고, OAuth 2.0을 기반으로 Identity Linking Capability를 정의합니다.

핵심 아이디어는

• 사용자는 자신의 계정을 직접 에이전트에게 넘기는 것이 아니라

• 상점이 발급하는 토큰을 통해 에이전트에게 필요한 권한만 위임하고

• 이 위임 상태는 언제든 회수 가능해야 한다

는 겁니다.

OAuth에 익숙한 개발자라면, 비교적 쉽게 이해할 수 있는 구조일 거라 생각합니다.
관련 표준은 여기를 참고해보셔도 좋습니다: https://oauth.net/2/

📦 Order: 주문의 전 생명주기를 표준 구조로

Order Capability는 말 그대로 주문의 라이프사이클 전체를 다룹니다.

• 주문 생성

• 결제 완료

• 배송 준비, 배송 중, 배송 완료

• 반품 및 교환 처리

이 모든 상태를 UCP 표준 구조 안에서 표현할 수 있게 설계되어 있습니다.

여기에 웹훅(Webhook)이 결합되면서, 에이전트는 주문 상태 변경을 바로바로 받아볼 수 있습니다.

사용자 입장에서는

• 배송이 예상보다 지연될 가능성이 보이면

• 에이전트가 선제적으로 알림을 보내고, 필요하다면 고객센터 연결이나 옵션 변경까지 제안하는 그림도 충분히 가능해집니다.

개발자로서 느끼는 장점은, 각 쇼핑몰마다 다른 주문 상태 코드와 이벤트 명칭을 하나씩 매핑하는 대신, UCP Order 스키마만 기반으로 내부 도메인 모델을 설계할 수 있다는 점입니다.

🧬 기술적인 포인트: Transport 자유, 확장 가능, 그리고 보안

개발자 모드로 넘어가서, 기술적인 포인트도 한 번 짚어볼게요.
UCP가 흥미로운 지점 중 하나는, 특정 기술 스택에 묶여 있지 않다는 점입니다.

🔌 Transport Agnostic: REST만이 답은 아니다

UCP의 정의는 네트워크 전송 계층에 종속적이지 않습니다.
말 그대로 Transport Agnostic입니다.

즉, 같은 프로토콜 스펙을 두고도

• HTTP/REST API 형태로 구현할 수도 있고

• JSON-RPC 스타일로 갈 수도 있고

• Model Context Protocol(MCP)을 통해 LLM과 연동할 수도 있고

• 에이전트 간 직접 통신(A2A, Agent-to-Agent)으로도 이용할 수 있습니다.

MCP에 대해 궁금하신 분은 이쪽도 한 번 보셔도 좋고요.
https://modelcontextprotocol.io

에이전트 간 직접 통신 개념은 이런 방향과 잘 맞습니다.
https://discuss.pytorch.kr/t/google-ai-a2a-agent-to-agent/6761

개인적으로 이 부분이 특히 마음에 들었습니다. 초기에 REST로 시작했다가, 나중에 MCP나 A2A 쪽으로 확장하고 싶어질 가능성이 충분히 있다고 보기 때문입니다.

🔒 보안과 권한 위임: AP2 Mandates와 암호학적 증명

결제는 말 그대로 돈이 왔다 갔다 하는 영역이다 보니, 보안 모델이 허술하면 이 전체 구상이 의미가 없어집니다.

UCP는 기본 인증/인가에 OAuth 2.0을 쓰되, 결제 권한 위임에 대해서는 AP2 Mandates라는 개념을 도입합니다.

핵심은,

• 사용자의 명시적인 동의를 전제로

• 누가 누구에게 어떤 범위의 결제 권한을 위임했는지

• 이것이 암호학적으로 검증 가능해야 한다

는 점입니다.

이렇게 되면 에이전트가 내 계좌나 카드 정보를 직접 가지지 않고도, 정해진 한도와 범위 내에서 결제를 대신 수행할 수 있는 구조가 만들어집니다.

개인적으로는, 이 영역이 제대로 구현되면 에이전트 기반 핀테크 서비스들이 엄청나게 많이 나올 수 있겠다는 생각이 듭니다.

🧱 Extension 구조: 필요한 만큼만, 점진적으로 확장

UCP는 Core Capability 외에 Extension이라는 확장 구조를 별도로 둡니다.

예를 들어,

• Discounts

• Fulfillment

• 쿠폰, 프로모션 로직 등

은 필수는 아니지만 대부분의 서비스에 중요한 기능이죠.

이런 것들을 Extension으로 분리해두면,

• 초기에는 Checkout, Order만 단순하게 붙이고

• 서비스가 성장하면 Fulfillment, Discounts 등을 붙이는 식으로
  점진적인 도입이 가능해집니다.

개발자로서 실제 프로젝트를 진행할 때, 이런 단계적 도입이 가능하냐 아니냐가 채택 여부에 꽤 큰 영향을 주기 때문에, 이 설계는 현장감 있는 선택이라고 느꼈습니다.

🧾 예시 JSON으로 보는 UCP Checkout 구조

문서에 나온 Checkout 세션 예시 JSON을 한 번 곱씹어 보면서,
실제로 어떤 그림인지 감을 잡아볼게요.

구조는 대략 이런 식입니다.

• ucp 버전

• 체크아웃 id

• 상태 (예: ready_for_complete)

• currency

• buyer 정보 (이메일, 이름 등)

• line_items: 각 상품과 수량 정보

• fulfillment: 배송 옵션과 선택된 옵션

이걸 보고 든 생각은, LLM 기반 에이전트를 염두에 두고 굉장히 명시적으로 설계했구나 하는 느낌이었습니다.

에이전트는 이 구조를 받아서

• 장바구니 요약 UI를 그리거나

• 어떤 배송 옵션을 추천할지 판단하고

• 결제 진행 여부를 사용자에게 묻거나

같은 액션을 취하기가 쉬워집니다.

또 하나 흥미로운 지점은, 이 구조가 특정 PG사, 특정 결제 수단에 묶여 있지 않다는 점입니다.

프로토콜의 관점에서는

• 이 주문에 어떤 항목이 포함되어 있고

• 지금 상태가 어디까지 진행되었고

• 다음에 가능한 액션은 무엇인지

이 정도까지만 표준화하고, 실제 결제 수단과 결제창은 구현체에서 선택하도록 여지를 남겨둡니다.

장기적으로 보면 이 유연성이 UCP의 생존력과 직결될 거라고 생각합니다.

📜 라이선스와 생태계: 왜 오픈소스가 중요한가

UCP는 Apache License 2.0으로 공개되어 있습니다.
라이선스 전문은 GitHub에서 확인할 수 있습니다.

https://github.com/Universal-Commerce-Protocol/ucp/blob/main/LICENSE

Apache 2.0의 장점은

• 상업적 이용 가능

• 포크와 수정 후 재배포 가능

• 특허 관련 조항도 깔끔한 편

이라서, 커머스처럼 사업성이 짙은 분야에서 채용되기에 꽤 적합한 라이선스입니다.

개인적으로 중요하게 보는 부분은, 이 프로토콜을 누가 독점할 수 없다는 점입니다.

만약 특정 빅테크가 폐쇄적으로 밀어붙이는 표준이라면, 결국 또 다른 종속 구조가 생길 수밖에 없겠죠.

오픈소스, 오픈 프로토콜이라는 점 덕분에

• 작은 스타트업도 UCP를 도입해 글로벌 에이전트 생태계에 합류할 수 있고

• 커뮤니티 차원에서 구현체나 SDK, 테스트 도구를 만들어도 라이선스 걱정이 적고

• 특정 회사의 비즈니스 전략 변화에 프로토콜이 흔들리지 않을 가능성이 큽니다.

이런 구조가 장기적으로는 커머스 인프라를 더 개방적인 방향으로 끌고 갈 수 있지 않을까 기대하게 됩니다.

🧠 개인적인 인사이트: 개발자와 서비스 기획자가 미리 생각해볼 포인트

AI 개발자 입장에서 UCP를 보면서 들었던 생각들을 조금 정리해 보겠습니다.
아직은 초기지만, 미리 고민해두면 좋은 지점들이 꽤 보입니다.

1. 에이전트 친화적인 커머스 도메인 설계가 빨리 필요해진다

지금까지의 커머스 설계는 대부분 사람 눈을 기준으로 했습니다. 페이지 구조, 버튼 배치, 이벤트 배너, 팝업 등등.

앞으로는

• 에이전트가 이해하기 좋은 데이터 구조

• 상태 전환이 명확한 주문/결제 모델

• 권한 위임, 취소, 재시도에 대한 명시적인 규칙

이런 것들을 먼저 고민해야 할 가능성이 큽니다.

UCP는 이 방향성을 꽤 선명하게 던져주고 있어서, 커머스 관련 서비스를 기획하거나 개발하신다면 한 번쯤 스펙을 천천히 읽어보는 걸 추천합니다.

https://ucp.dev/latest/specification/overview

2. 기존 커머스에게는 위협이자 기회

기존 대형 플랫폼 입장에서는 UCP 같은 표준이 처음엔 부담스러울 수 있습니다.

• 지금까지 쌓아온 폐쇄적인 생태계가 느슨해질 수 있고

• 에이전트가 가격 비교와 조건 비교를 훨씬 잘하게 되면

• 브랜드/판매자가 플랫폼 종속에서 조금 더 벗어날 수 있기 때문이죠.

반대로, 중소 상점이나 브랜드 입장에서는 꽤 큰 기회가 될 수 있습니다.

• UCP를 지원하는 순간

• 글로벌 에이전트 생태계의 후보군 중 하나가 되고

• 검색, 추천, 자동 구매 플로우의 일부가 될 수 있기 때문입니다.

이런 의미에서, UCP는 기술 프로젝트를 넘어 커머스 권력 구조에도 영향을 줄 수 있는 변화라고 느껴집니다.

3. 실제 구현은 결국 개발자의 몫, 조기에 손대볼 만하다

프로토콜이 아무리 좋아도, 결국 구현체, SDK, 샘플 코드, 테스트 환경이 따라와야 실전에서 쓸 수 있습니다.

UCP GitHub를 보면 스펙과 문서가 중심이지만, 앞으로는 아마 이런 것들이 자연스럽게 따라붙을 겁니다.

• 언어별 SDK

• 샌드박스 상점 구현

• 레퍼런스 에이전트

• 테스트 툴과 시뮬레이터

지금 시점에서 개발자들이 할 수 있는 일은

• 스펙을 읽어보고

• 작은 PoC 수준의 구현을 해보면서

• 도메인 모델과 내부 시스템을 UCP에 맞춰보는 연습을 해보는 것

이라고 생각합니다.

GitHub 저장소는 여기서 바로 볼 수 있습니다.
https://github.com/Universal-Commerce-Protocol/ucp

🔎 마무리: UCP, 지금 당장 써야 할까?

정리해보면, Universal Commerce Protocol(UCP)은

• 에이전트 기반 차세대 커머스를 전제로 설계된

• 오픈소스, 오픈 프로토콜이며

• Checkout, Identity Linking, Order라는 핵심 Capability부터 탄탄히 다지는 중이고

• Transport에 독립적이고, 확장 가능하며, 보안 모델까지 고려한 설계입니다.

개인적으로 느끼는 포인트는 이렇습니다.

• 지금 당장 모든 서비스를 UCP로 갈아탈 시점은 아니다.

• 하지만, 앞으로 커머스 관련 도메인을 설계할 때 UCP의 구조를 의식하면서 모델링을 해두면 몇 년 뒤 에이전트 생태계가 본격화될 때 큰 이점을 얻을 수 있다.

• 특히 AI 에이전트를 만들거나, 커머스 API를 설계하는 분이라면 한 번쯤은 스펙을 보면서 자신의 시스템과 어떻게 맞물릴 수 있을지 상상해볼 만하다.

결국 질문은 이런 것 같습니다.

앞으로 쇼핑의 기본 단위가 페이지가 아니라 프로토콜이 되고, 사용자가 아니라 에이전트가 고객의 첫 접점이 되는 시대가 온다면, 우리는 지금 무엇을 준비하고 있어야 할까.

UCP는 그 질문에 대한 하나의 구체적인 제안이라고 느껴집니다.

시간 나실 때 공식 문서 한 번 쭉 훑어보시고, 내 서비스에 이걸 어디까지, 어떻게 가져올 수 있을지 한 번 생각해보시면 좋겠습니다.

• UCP 공식 사이트: https://ucp.dev

• 스펙 개요: https://ucp.dev/latest/specification/overview

• GitHub 저장소: https://github.com/Universal-Commerce-Protocol/ucp

저도 시간이 허락하는 대로, 간단한 데모 쇼핑몰과 에이전트를 UCP 기반으로 붙여보면서
실제 구현기를 한 번 더 정리해 볼까 생각 중입니다.