쇼핑 에이전트가 5,850센트의 모의 주문을 완료하는 데 필요한 7단계

요약 (The short verdict)

• **Universal Commerce Protocol (UCP)**는 쇼핑 에이전트를 상인의 제품, 풀필먼트 (fulfillment), 그리고 결제 시스템에 연결하기 위한 공유 계약입니다.
• 공식 Python 샘플은 두 번째 제품을 추가하고, 10OFF를 적용하며, 목적지와 배송 옵션을 선택한 뒤 모의 결제를 완료합니다.
• 결과는 총액을 6,500센트에서 5,850센트로 변경하고 주문 ID (order ID)를 반환하는 7단계의 체크아웃 (checkout) 경로입니다.
• 판매 가치는 여전히 $0입니다. 클라이언트는 샘플의 success_token을 전송하며, 주문 URL은 localhost를 가리킵니다. 실제 카드나 돈은 관여되지 않습니다.
• 이것을 사용하십시오. 만약 당신이 커머스의 상인 측을 운영하며 에이전트 대응 주문 경계 (agent-facing order boundary)가 필요하다면 사용하세요. 이 데모를 AI가 스스로 판매할 수 있다는 증거로 사용하지는 마십시오.

이 실험의 유용한 부분은 Google의 홍보 내용이 아닙니다. 기존 상점에 에이전트 대응 경계를 추가할 때, 상인 측 개발자가 제품 탐색부터 주문에 이르기까지 유지해야 하는 상태 (state)의 형태입니다.

“이것을 구매해줘”는 단일 요청 작업이 아닙니다

쇼핑 에이전트는 누군가

UCP는 Google Search의 AI 모드(AI Mode)나 Gemini와 같은 다양한 서비스(surfaces)를 통해 직접 구매를 수행할 수 있도록 Google이 제시한 개방형 표준(open standard)입니다. 판매자(Merchant)는 거래에 대해 법적 책임을 지는 판매자인 기록상 판매자(Merchant of Record)로 남으며, 고객 관계 및 구매 후 책임을 유지합니다.

이 설계에서 에이전트(agent)는 언어 모델(language model) 단독이 아닙니다. 쇼핑 인터페이스(shopping surface) 또는 서비스가 판매자의 공개 프로필을 읽고, 지원되는 기능(capabilities)을 탐색하며, 그에 맞는 주문을 생성합니다. 판매자는 /.well-known/ucp 경로에 해당 기능들을 광고합니다.

공식 Python 클라이언트는 스크립트 프로그램이며, AI 모델이 아닙니다. 이 차이는 중요합니다. 이번 실행은 결제 계약(checkout contract)이 구현되고 실행될 수 있음을 증명합니다. 다만, 이것이 모델이 올바른 제품을 선택하거나, 재고를 비교하거나, 의심스러운 주문을 탐지하거나, 결제 시간 초과(payment timeout)로부터 안전하게 복구할 수 있음을 증명하는 것은 아닙니다.

구매를 자동화하는 세 가지 방법

유용한 구분 기준은 "수동 대 AI"가 아닙니다. 주문 상태(order state)를 누가 소유하는지, 그리고 결제에 대한 책임이 누구에게 있는지가 기준입니다.

UCP는 판매자의 기능을 탐색 가능하게(discoverable) 만듭니다. 샘플 프로필은 REST, MCP, A2A 및 임베디드 결제(embedded checkout) 전송 방식을 노출했습니다. REST는 일반적인 HTTP API 접근 방식이며, MCP는 도구 호출(tool-calling) 인터페이스이고, A2A는 에이전트 간 통신(agent-to-agent communication)을 위한 프로토콜입니다. 또한 결제(checkout), 주문(order), 할인(discount), 이행(fulfillment), 구매자 동의(buyer-consent) 기능도 선언되었습니다. Google의 가이드는 이와 동일한 바인딩(bindings) 및 A2A와의 호환성을 설명합니다.

이것이 모든 판매자가 모든 기능을 지원한다는 의미는 아닙니다. 즉, 에이전트는 할인, 배송 또는 계정 연동(account linking) 기능이 존재한다고 가정하기 전에 프로필을 먼저 검사해야 한다는 뜻입니다.

결제는 7개의 가시적인 작업입니다

결제는 하나의 커다란 명령이 아닙니다. 하나의 구매 상태(purchase state)에 대한 일련의 업데이트 과정입니다.

Discovery는 UCP 버전, 서비스 전송(service transports), 기능 선언(capability declarations), 그리고 세 가지 결제 핸들러(payment handlers)를 반환했습니다. Discovery는 사전 점검(preflight) 단계이며, 7단계의 체크아웃 작업은 세션 생성으로 시작하여 완료로 끝납니다:

"결제 지원"이라는 정보만으로는 자격 증명(credential)을 보내기에 충분하지 않습니다. 각 핸들러는 결제 수단(instrument)의 형태와 토큰 규칙을 정의합니다. UCP 체크아웃 사양은 완료(completion)를 결제 수단과 그 자격 증명을 전달하는 요청으로 모델링합니다.

상태 변화에 따른 총액의 변화

클라이언트는 장미 꽃다발 한 개로 시작합니다. 세라믹 화분 두 개를 추가하면 총액이 3,500센트에서 6,500센트로 이동합니다. 10OFF를 전송하면 5,850센트로 변경됩니다.

할인은 응답에 붙여진 라벨이 아닙니다. totals 내에 discount 라인이 나타나며, 최종 합계가 변경됩니다. 배송 선택 후에도 클라이언트는 체크아웃 응답을 여전히 현재의 신뢰할 수 있는 단일 원천(source of truth)으로 취급해야 합니다.

풀필먼트(Fulfillment)는 결제 준비의 일부입니다

샘플에서는 판매자에게 풀필먼트 옵션(fulfillment options)을 생성하도록 요청하고, 목적지 ID를 선택한 다음, std-ship을 선택합니다. 결제 단계는 이러한 업데이트 이후에 이루어집니다.

화면에서 사람은 “배송 선택”을 봅니다. 프로토콜에서 에이전트는 ID, 품목별 연관 관계(line-item associations), 목적지 데이터, 그리고 판매자의 최신 합계 금액을 계속 유지해야 합니다. 만약 이러한 참조 중 하나라도 오래된 정보(stale)라면, 결제 요청은 추측하는 대신 중단되어야 합니다.

공식 샘플을 실행해 보았습니다

공식 저장소(repository)는 격리된 임시 디렉터리로 클론(clone)되었습니다. 서버와 클라이언트는 Python 환경 및 의존성 관리 도구인 uv를 통해 동기화되었고, 꽃집의 제품, 재고, 할인 및 배송 요금은 파일 기반 데이터베이스인 SQLite에 로드되었습니다. 그리고 Python 웹 API 서비스인 FastAPI 머천트(merchant) 서버가 시작되었습니다. 단계는 저장소의 Python README를 따릅니다.

클라이언트는 모든 요청(request)과 응답(response)을 Markdown으로 내보냅니다. 제가 확인한 값은 다음과 같습니다:

공식 Python 통합 테스트 스위트(integration suite) 또한 통과했습니다: 16개의 테스트가 통과되었으며, 두 개의 경고(warning)가 있었습니다. 경고는 테스트 수집(test collection) 및 향후 httpx2 권장 사항에 관한 것이었습니다. 해피 패스(happy path) 자체는 완료되었습니다.

Discovery 요청은 7개의 체크아웃(checkout) 작업을 포함하여 총 8개의 HTTP 요청을 수행합니다. 제목에 언급된 7단계는 기능 사전 점검(capability preflight)이 아닌 체크아웃 자체를 카운트한 것입니다.

실제 응답의 결정적인 부분은 다음과 같습니다:

{
  "status": "completed",
  "totals": [
...

결제 자격 증명(payment credential)은 명시적으로 샘플 토큰이었습니다:

{
  "handler_id": "mock_payment_handler",
  "credential": {"type": "token", "token": "success_token"}
...

정확한 표현은 "샘플이 5,850센트의 모의 주문(mock order)을 완료했다"입니다. "에이전트가 58.50달러를 판매했다"가 아닙니다. 요청에는 success_token이 사용되었고, 주문 퍼머링크(permalink)는 localhost URL이었습니다. 이것은 프로토콜 및 상태 테스트였지, 현금 수령이 아니었습니다.

또한 작은 재현 함정(reproduction trap)이 있습니다. 저장소의 extract_json_dialog.sh는 ../../../../conformance/test_data/flower_shop을 참조하고 있는 반면, 클론된 저장소는 피스처(fixture)를 rest/python/test_data/flower_shop 아래에 저장합니다. 해당 헬퍼(helper)는 통과로 간주되지 않았습니다. 실제 피스처 경로를 사용한 README 명령은 정상적으로 작동했습니다.

AI 엔티티가 실제로 시작할 지점

제가 실행한 Python 클라이언트는 AI 엔티티가 아닙니다. 제품 선택, 수량, 할인 코드, 결제 토큰이 모두 코드 내에 고정되어 있습니다. 이로 인해 실현된 매출은 $0입니다.

이 샘플은 AI 엔티티가 반드시 넘어야 할 경계를 여전히 보여줍니다:

1. 의사결정 (Decision): 모델이 장미와 화분을 구매하기로 결정합니다.
2. 주문 상태 (Order state): 커넥터(connector)가 해당 결정을 UCP 요청으로 변환하고 판매자의 응답을 따릅니다.
3. 결제 (Payment): 커넥터가 판매자의 결제 처리기(payment handler)에서 수락되는 인증 정보(credential)를 제공합니다.
4. 책임 (Responsibility): 판매자와 결제 제공업체가 재고, 청구, 환불 및 구매 후 처리를 담당합니다.

UCP 자체가 이러한 계층들을 안전하게 만들어주는 것은 아닙니다. 구현 단계에서는 여전히 멱등성 키 (idempotency keys), 결제 전 동의, 재고 재검증, 그리고 불확실한 응답 이후의 최신 데이터 읽기 (fresh read)가 필요합니다. 프로토콜은 시스템 간의 언어를 표준화할 뿐입니다. 프로토콜이 모델에게 은행 계좌나 리스크 정책을 부여하지는 않습니다.

책임 분할은 구체적입니다: 판매자는 카탈로그, 재고, 풀필먼트 (fulfillment), 청구, 환불, 사기 처리, 분쟁 및 고객 관계에 대한 책임을 유지합니다; 결제 제공업체는 결제 수단과 결제 네트워크 의무를 처리합니다; 에이전트는 다음 체크아웃 전환을 요청하는 호출자 (caller)일 뿐입니다. UCP는 이러한 법적 책임 (liabilities)을 모델로 옮기지 않습니다.

UCP를 사용해야 할까요?

사용하세요: 이미 제품, 재고, 풀필먼트 및 결제를 운영하고 있으며, AI 인터페이스가 발견하고 호출할 수 있는 계약 (contract)을 원한다면 사용하십시오. 기존 로직을 매핑하여 체크아웃을 생성, 업데이트 및 완료할 수 있는 판매자는 스크린 스크래퍼 (screen scraper)보다 더 테스트 가능한 경계를 가집니다.

기다리세요: 비즈니스 측에서 누가 재고, 환불, 결제 분쟁 또는 의심스러운 주문을 소유할지 아직 결정하지 않았다면 기다리십시오. UCP를 추가한다고 해서 제품 선택 모델이나 안전 정책이 생성되는 것은 아닙니다.

이를 도입하기 전에 네 가지 전제 조건을 확인하십시오: API로 접근 가능한 카탈로그 (catalog), 완료 직전의 재고 재검증 (inventory revalidation), 가격 정보가 포함된 풀필먼트 옵션 (fulfillment options), 그리고 결제 및 환불을 담당할 지정된 소유자 (named owner)와 처리자 (handler)입니다. 만약 이 중 어느 하나라도 해결되지 않았다면, 먼저 해당 판매자 측의 경계 (merchant-side boundary)를 수정하십시오.

공식 샘플이 가치 있는 이유는 번거로운 부분을 숨기려 하지 않기 때문입니다. 탐색 (Discovery), 체크아웃 생성 (checkout creation), 항목 업데이트 (item updates), 할인 계산 (discount calculation), 배송 선택 (shipping selection), 그리고 결제 (payment) 과정이 모두 명시되어 있습니다. 이 7단계를 거치면 주문 ID (order ID)가 생성됩니다.

이는 에이전트 기반 커머스 (agentic commerce)를 위한 좋은 토대입니다. 이것이 자율 판매 (autonomous selling)의 증거는 아닙니다. 다음 단계의 증명에는 실제 결제 샌드박스 (payment sandbox), 안전한 재시도를 위한 불변의 주문 의도 (immutable order intent), 그리고 모델이 단독으로 수행해서는 안 되는 행동에 대한 명확한 중단 경계 (stop boundary)가 필요할 것입니다. 이 경계를 재현하려면 공식 README 명령어를 실행하여 success_token이 모의(mock) 전용임을 확인한 다음, 실제 결제 통합을 이 데모의 연장선이 아닌 별도의 테스트로 취급하십시오.

마지막 참고 사항

다음 점검 단계에서는 실제 결제 샌드박스에서 동일한 상태 머신 (state machine)을 실행해야 하며, success_token을 실제 결제 자격 증명 (payment credential)과 분리하여 유지해야 합니다. 경계를 재현하려면 공식 README 명령어를 실행하여 completed 응답과 해당 localhost 주문 URL을 확인한 다음, 라이브 결제 통합을 별도의 테스트로 취급하십시오. 코드와 검증 노트는 Daisuke134/anicca 및 Substack에서 공개되어 있습니다.

출처

출처

• Google Universal Commerce Protocol guide
• Universal-Commerce-Protocol/samples
• Python flower shop client README
• Python merchant server README
• simple_happy_path_client.py
• UCP checkout specification
• UCP documentation