에이전틱 체크아웃

요약 — 에이전틱 체크아웃은 AI 쇼핑에서 “나 대신 구매해 줘”에 해당하는 부분입니다. AI 어시스턴트가 상품을 찾고 구매까지 완료할 때, 마지막 거래 단계가 에이전틱 체크아웃입니다. OpenAI의 위임 결제 흐름에서는 에이전트가 원시 카드 번호 대신 범위가 제한된 결제 토큰을 사용하며, 로그인이나 추가 인증처럼 위험이 따르는 단계에서는 멈추고 사람에게 제어권을 돌려줍니다. 독립된 기능이라기보다 더 큰 프로토콜인 ACP와 UCP의 한 구성 요소입니다.

에이전틱 체크아웃이란

“AI 쇼핑”의 대부분은 탐색입니다. 어시스턴트에게 원하는 상품을 찾아 달라고 하면 판매자의 상품 피드를 읽고 선택지를 제안합니다. 에이전틱 체크아웃은 그다음 단계입니다. 에이전트가 배송 옵션을 고르고, 세금과 배송비를 계산하고, 결제를 전달하고, 구매를 확정해 실제 주문을 만드는 부분입니다.

핵심 단어는 단계입니다. 에이전틱 체크아웃은 별도의 제품이나 회사가 아닙니다. OpenAI와 Stripe의 Agentic Commerce Protocol(ACP), Google과 Shopify의 **Universal Commerce Protocol(UCP)**이라는 두 주요 에이전틱 커머스 표준에 포함된 거래 완료 기능입니다. 두 프로토콜의 전체 개요는 각각의 관련 글에서 다루며, 이 글은 체크아웃 작동 방식만 집중해서 살펴봅니다.

사람들이 흔히 오해하는 세 가지

• “AI가 사람의 개입 없이 구매한다.” 정확하지 않습니다. 두 프로토콜 모두 로그인, 추가 카드 인증, 확인 같은 상황에서 “멈추고 사람에게 요청하는” 단계를 내장합니다. 명세 자체가 완전 무인 체크아웃을 전제로 하지 않습니다.
• “AI가 내 신용카드 정보를 본다.” 아닙니다. 결제는 범위 제한 토큰으로 전달됩니다. 이 대체 자격 증명은 판매자 한 곳, 금액 하나, 시간 범위 하나에 묶이고 한 번만 사용할 수 있습니다. 원시 카드 번호는 에이전트에 전달되지 않습니다.
• “이미 일반적이라 대부분의 스토어에서 쓸 수 있다.” 이 역시 사실이 아닙니다. 2026년 중반 현재는 초기 단계입니다. OpenAI가 2026년 3월 완전한 인채팅 방식을 축소하기 전 ChatGPT 체크아웃을 실제 운영한 Shopify 스토어는 약 12곳에 불과했습니다.

문제가 생기면 누가 책임지나요?

구매한 스토어는 여전히 그 거래의 판매자, 즉 merchant of record입니다. 일반 온라인 구매와 마찬가지로 주문, 환불, 분쟁을 처리합니다. 아직 누구도 완전히 해결하지 못한 복잡한 문제는 “구매자”가 AI 에이전트였던 결제에 이의가 제기될 때 어떻게 처리하느냐입니다. 자세한 내용은 고급 탭에서 다룹니다.

실제 상태 머신, 결제 토큰의 제한 범위, 사람이 개입해야 하는 지점, 판매자가 도입 전에 시험해야 할 항목을 알고 싶다면 고급 탭으로 전환하세요.

요약 — 에이전틱 체크아웃은 체크아웃 세션을 생성·수정·완료 또는 취소하고, 결제를 위임하고, 주문을 확인하는 에이전틱 커머스의 거래 완료 기능입니다. 독립 프로토콜이 아니라 ACP와 UCP의 구성 요소입니다. 기술적 중심은 상태 머신입니다. ACP는 세션을 not_ready_for_payment → ready_for_payment → 필요 시 requires_escalation/authentication_required → completed로 이동시키며, UCP의 incomplete → requires_escalation → ready_for_complete 흐름과 대응합니다. 에스컬레이션 상태는 의도적으로 만든 사람 개입 접점입니다. 결제 위임에는 판매자·금액·시간·사용 횟수가 제한된 토큰을 사용하므로 에이전트가 원시 카드 정보를 보유하지 않습니다. 주문 확인은 푸시 방식입니다. 판매자는 HMAC으로 서명한 전체 객체 웹훅을 POST합니다. 판매자는 계속 merchant of record이므로 정산·환불·차지백은 판매자와 PSP가 담당하지만, 차지백의 증거 체계는 2026년 중반 현재 실제로 해결되지 않았습니다. 도입하기 전에 멱등성이 보장되는 재시도, 웹훅 서명 검증, 에스컬레이션 경로를 구축하고 시험하세요.

범위: 프로토콜 전체가 아니라 거래 단계

에이전틱 체크아웃은 하나의 기능입니다. ACP에서는 Product Feed, Delegate Payment, Delegate Authentication, Orders/Webhooks와 함께 다섯 블록 중 하나인 Agentic Checkout 블록입니다. UCP에서는 기능 협상을 사용하는 더 넓은 명세 안의 체크아웃 기능입니다. ACP와 UCP 관련 글은 피드 품질, /.well-known/ucp 프로필, 2026년 3월 방향 전환이 상품 탐색에 미친 영향 등 주변 프로토콜과 비즈니스 맥락을 설명합니다. 이 글은 세션 수명 주기, 결제 위임, 사람의 개입 지점, 주문 확인, 책임처럼 거래를 완료하는 작동 방식에 집중합니다.

ACP 관련 글에서 가져와 여기서 다시 논쟁하지 않을 전제는 하나입니다. 에이전트는 크롤링된 HTML이 아니라 피드와 API를 상대로 거래합니다. 따라서 여기서 최적화할 대상은 페이지 문구가 아니라 체크아웃의 신뢰성입니다.

체크아웃 세션 상태 머신

에이전틱 체크아웃을 이해할 때 가장 중요한 차이점이자 많은 설명에서 빠지는 사실은 체크아웃이 상태를 가진 세션이며, 그 상태가 정의된 머신을 따라 이동한다는 점입니다.

ACP의 Checkout 참조 문서에는 전체 상태 열거형이 나옵니다. incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress, expired입니다. 정상 경로는 not_ready_for_payment → ready_for_payment → in_progress → completed로 짧으며, 다른 종료 상태는 canceled입니다. ACP의 수명 주기 개념에 따르면 필수 이행 옵션이 제공되면 세션이 not_ready_for_payment에서 ready_for_payment로 전환됩니다. 결제가 실패하면 재시도를 위해 다시 ready_for_payment로 돌아갈 수 있습니다.

눈여겨볼 상태는 정상 경로에 속하지 않는 상태입니다.

• requires_escalation / authentication_required — 에이전트 혼자 진행할 수 없으며 사람의 조치나 추가 인증이 필요합니다(다음 절 참조).
• pending_approval — 예를 들어 B2B 구매 주문 승인처럼 승인을 기다리는 상태입니다.
• expired — 세션 시간이 만료된 상태입니다(CheckoutSession에는 expires_at이 포함됩니다).

이는 UCP 체크아웃의 기본 설계와 같습니다. UCP는 incomplete → requires_escalation → ready_for_complete로 진행하고, requires_escalation에서는 continue_url을 통해 사람에게 제어권을 돌려줍니다(UCP 관련 글에서 설명). 서로 다른 두 프로토콜이 하나의 패턴으로 수렴합니다. 체크아웃은 사람에게 무언가를 묻기 위해 멈추지 않고는 항상 완료될 수 없습니다. 이는 나중에 덧붙인 제약이 아니라 설계의 핵심 형태입니다.

ACP를 구현하는 사람에게 실용적인 주의점이 있습니다. 형식이 잘못된 요청은 HTTP 수준 오류 객체를 반환하며 type은 invalid_request, request_not_idempotent, processing_error, service_unavailable 중 하나입니다. 반면 형식상 유효한 세션 안의 비즈니스 로직 문제는 HTTP 오류가 아니라 세션의 messages[] 배열에 MessageError 객체로 반환됩니다. 둘 다 처리해야 하며 초기 통합 과정에서 혼동하기 쉽습니다.

결제 위임의 작동 방식

결제 위임 계층의 핵심 목적은 원시 카드 정보가 에이전트에 절대 전달되지 않게 하는 것입니다. 에이전트에 카드 번호를 주는 대신 구매자의 결제 정보를 범위 제한 토큰으로 변환합니다.

OpenAI의 Delegated Payment 명세에 따르면 위임 결제 페이로드는 판매자의 PSP 또는 볼트로 직접 전송되고, PSP나 볼트는 PCI 범위 밖에서 해당 위임 결제에 한정된 결제 토큰을 반환합니다. 토큰은 네 가지 축에서 제한됩니다.

• reason — 현재 값은 일회용을 뜻하는 "one_time"입니다.
• max_amount — 청구액을 체크아웃 합계로 제한해 초과 청구에 사용할 수 없게 합니다.
• expires_at(RFC 3339) — 토큰의 명확한 만료 시각입니다.
• merchant_id + checkout_session_id — 판매자 한 곳과 세션 하나에 묶입니다.

따라서 위임 토큰은 판매자에 고정되고, 금액 상한이 있으며, 시간이 제한되고, 한 번만 사용할 수 있습니다. 재사용 가능한 카드 자격 증명을 맡기지 않고도 에이전트가 “돈을 쓰게” 하는 장치입니다. ACP에서 Stripe의 Shared Payment Token은 Delegated Payment Spec과 호환되는 첫 구현으로 설명되며 다른 PSP도 추가될 예정입니다. UCP는 결제 수단과 핸들러를 분리하는 유사한 비결합 모델을 사용합니다(UCP 관련 글 참조).

여기서 PCI 범위는 실제 설계 결정입니다. OpenAI 명세는 Delegated Payment Spec과 직접 통합하면 카드 소유자 데이터를 직접 처리하게 되어 PCI 범위에 영향을 줄 수 있고, 직접 통합에는 PCI DSS Level 1 자격이 필요하다고 명시합니다. 대부분의 판매자에게는 네트워크 토큰이나 위임을 처리하는 PSP를 사용하는 토큰화 경로가 카드 소유자 데이터를 환경 밖에 두는 방법입니다. “CHD를 직접 처리할지”와 “PSP가 토큰화하게 할지”의 선택이 첫 번째 아키텍처 결정이며, 의사결정 탭에서 설명합니다.

사람이 개입해야 하는 지점

“구매자가 여전히 승인한다”는 말은 맞지만 모호합니다. 프로토콜 수준의 트리거는 구체적입니다. 트리거의 이름을 알아야 조용히 막다른 길에 빠지지 않고 인계 흐름을 설계할 수 있습니다.

• 3-D Secure / 추가 인증. ACP는 InterventionCapabilities로 이를 모델링합니다. 지원 유형에는 3ds와 address_verification이 있고, enforcement 수준은 always/conditional/optional, display_context는 native/webview/modal/redirect입니다. 추가 인증 결과는 authenticated, denied, rejected, abandoned, canceled, not_supported 같은 값을 가진 AuthenticationResult로 반환됩니다.
• requires_escalation / authentication_required 상태. “계속 진행하기 전에 사람이나 추가 검사가 필요하다”는 뜻의 세션 상태입니다.
• B2B approval_required. PaymentData 객체에는 purchase_order_number, payment_terms, due_date, approval_required 같은 B2B 필드가 있습니다. 에이전틱 체크아웃은 DTC에만 해당하지 않습니다.
• UCP의 continue_url 인계. UCP의 requires_escalation은 구매자가 로그인, 확인, 연령 확인 등을 직접 완료할 continue_url을 제공합니다. 같은 접점이지만 프로토콜은 다릅니다.

핵심은 깔끔하게 에스컬레이션되는 거래가 조용히 막히는 거래보다 훨씬 낫다는 것입니다. 에스컬레이션 경로를 오류 사례가 아니라 일급 흐름으로 설계하세요.

주문 확인은 풀 방식이 아니라 푸시 방식

경쟁 설명에서 대부분 빠지는 부분이 있습니다. 구매 후 에이전트 플랫폼은 주문 상태를 확인하려고 API를 계속 폴링하지 않습니다. 판매자가 서명된 웹훅을 푸시합니다.

ACP 웹훅 참조에 따르면 판매자는 에이전트 플랫폼이 이행 단계의 사실과 동기화되도록 주문 이벤트를 POST합니다. 신규 주문에는 order_create, 상태 변경에는 order_update 두 이벤트 유형을 사용합니다. 참조된 주문 상태에는 created, manual_review, confirmed, canceled, shipped, fulfilled가 있습니다. 구현자가 알아야 할 세 가지 세부 사항은 다음과 같습니다.

• 요청은 반드시 서명해야 합니다. Merchant-Signature 헤더의 HMAC 서명을 사용하며, 서명이 없거나 잘못되면 401을 반환합니다.
• data 필드에는 증분 차이가 아니라 전체 Order 객체가 들어가야 합니다. 매번 전체 상태를 전송합니다.
• 처리할 응답 코드: 성공 200, 잘못된 서명 401, 속도 제한 429입니다.

따라서 “플랫폼은 주문 완료를 어떻게 아는가?”라는 질문의 답은 구체적입니다. 판매자가 서명된 전체 객체 POST로 알려 주며, 플랫폼의 429 역압도 처리해야 합니다.

사기, 차지백, 책임: 정해진 것과 정해지지 않은 것

가장 솔직하고 차별적인 부분이므로 “정해진 것”과 “열린 문제”의 경계를 분명히 하겠습니다.

정해진 것: merchant of record. OpenAI의 결제 명세는 OpenAI가 merchant of record가 아니라고 명시합니다. ACP에서 판매자는 자체 PSP를 사용하며 정산, 환불, 차지백, 규정 준수는 판매자와 해당 PSP의 책임입니다. Rye의 Arjun Bhargava도 두 프로토콜 모두 판매자를 merchant of record로 유지하며 판매자가 이행, 차지백, 분쟁을 책임진다고 독립적으로 확인합니다. 이는 두 관련 글의 merchant of record 설명과 일치하므로 여기서는 그 전제를 이어받습니다.

정해지지 않은 것: 차지백 증거 체계. merchant of record는 기본적으로 누가 분쟁 비용을 부담하는지는 말해 줍니다. 그러나 “고객”이 AI 에이전트를 통해 거래했을 때 어떻게 분쟁에서 이길지는 알려 주지 않습니다. 전통적인 차지백 방어는 IP, 기기, 탐색 행동, 사람이 “구매”를 클릭한 기록처럼 사람이 만든 증거 흐름에 의존합니다. 에이전트가 만든 승인 로그는 다른 종류의 증거이며 카드 네트워크의 분쟁 규칙은 이를 전제로 작성되지 않았습니다. Chargeflow의 사기 전문가 Ben Herut는 에이전틱 커머스가 기존 시스템이 해석할 수 없는 새로운 사기와 혼란의 층을 더한다고 설명합니다. Chargeflow의 분석은 더 단호합니다. 아직 명확한 답은 없으며 카드 네트워크, 발급사, 플랫폼 제공업체가 모두 이 문제를 검토하고 있습니다.

새 프레임워크는 등장 중일 뿐 완성되지 않았습니다. Visa의 Trusted Agent Protocol은 사용자 경험을 해치지 않으면서 사칭을 막도록 판매자가 에이전트의 신원과 의도를 실시간 검증하게 하는 표준 기반 프레임워크로 설명됩니다. 2025년 4월 발표된 Mastercard의 Agent Pay는 Digital Enablement Service를 확장한 “Agentic Tokens”를 사용합니다. 제3자 보도(Fintech Wrap Up/Finextra)에 따르면 Mastercard의 책임 배분은 표준 토큰화 거래와 같은 규칙을 따르고, 토큰이 적법하게 발급되어 승인 때 수락되면 발급사가 사기 책임을 진다고 합니다. 하지만 Mastercard 자체 문서에 나오기 전까지 이 구체적 배분은 확인된 사실이 아니라 보도된 내용으로 다뤄야 합니다. Visa의 소비자용 무책임 보장은 무단 청구로부터 카드 소유자를 보호할 뿐, 실제 열린 문제인 판매자 측 분쟁을 해결하지 않습니다. 둘을 혼동하지 마세요.

판매자가 구현하고 시험해야 할 항목

기존 콘텐츠는 깨끗한 피드와 로열티 프로그램 같은 전략적 준비를 조언합니다. 다음은 실제 도입 전에 구축하고 검증해야 할 운영 계층입니다.

• PCI 방식을 결정하세요. 토큰화·네트워크 토큰 경로와 직접 CHD 처리(Level 1) 중 선택합니다. 대부분의 판매자는 PSP가 위임을 맡게 하는 편을 원합니다.
• 재시도가 멱등성을 보장하게 하세요. ACP에 request_not_idempotent 오류 유형이 있는 데는 이유가 있습니다. 에이전트나 불안정한 네트워크는 생성·완료 호출을 재시도합니다. 멱등성 키를 보내고 같은 키의 반복 호출을 안전하게 처리해 이중 청구나 주문 중복 생성을 막으세요.
• 웹훅 서명을 검증하세요. 모든 수신 주문 웹훅의 Merchant-Signature HMAC을 확인하고 불일치하면 거부하며, 부하 상황에서 200/429를 올바르게 반환하는지 확인하세요.
• 샌드박스에서 에스컬레이션 경로를 시뮬레이션하세요. requires_escalation/authentication_required를 강제로 발생시키고 3DS 추가 인증을 실행한 뒤, AuthenticationResult 처리가 authenticated뿐 아니라 denied/rejected/abandoned까지 다루는지 확인하세요.
• 피드와 체크아웃 가격의 일치를 대조하세요. 에이전트가 피드에서 본 가격과 체크아웃 가격이 다르면 신뢰가 빠르게 무너집니다. ACP 관련 글에서는 피드 관점에서 설명하지만 체크아웃에서 가장 큰 문제가 됩니다.
• 에이전트 주문 귀속 체계를 마련하세요. 완료된 에이전틱 체크아웃에는 GA4 세션이 없을 수 있습니다. 웹사이트 방문을 기다리지 말고 주문·OMS 수준에서 추적하세요.

테스트 SOP와 치트 시트 탭에서 이를 구체적인 합격 기준으로 바꿉니다.

2026년 중반 현재의 위치

홍보 자료가 아니라 도입 현실을 기준으로 판단하세요. Shopify 사장 Harley Finkelstein에 따르면 AI 체크아웃 도구를 실제 사용하는 Shopify 판매자는 약 12곳으로 전체 판매자 기반에 비하면 미미했습니다. OpenAI도 온보딩, 정확성, 여러 상품 장바구니 문제를 겪은 뒤 2026년 3월 완전한 인채팅 Instant Checkout을 검색 후 리디렉션 방식으로 축소했습니다. Semrush의 Leigh McKenzie는 마찰을 잘 요약했습니다. 수천만 SKU의 실시간 카탈로그 정규화는 10년 단위 문제이고, 소비자는 여전히 Apple Pay, Google Wallet, Amazon 원클릭처럼 신뢰하는 체크아웃 흐름을 기본으로 선택합니다.

그렇다고 에이전틱 체크아웃이 실체 없는 기술이라는 뜻은 아닙니다. 위임 결제와 서명된 주문 웹훅을 사용해 세션을 프로그래밍 방식으로 생성·수정·완료하는 프로토콜 기능은 실제로 존재하고 명세화되어 있으며 구축할 가치가 있습니다. 다만 “이미 일반적”이지 않을 뿐입니다. 마지막 단계가 채팅 안에서 끝날지 사이트에서 끝날지는 이미 한 번 바뀌었고 다시 바뀔 수 있는 구현 세부 사항입니다.

AI 요약

고급 버전을 압축하면 다음과 같습니다.

• 에이전틱 체크아웃은 에이전틱 커머스의 거래 완료 단계입니다. 에이전트가 구매자를 대신해 체크아웃 세션을 생성·수정·완료·취소합니다. 독립 프로토콜이 아니라 ACP와 UCP의 구성 요소입니다.
• 상태 머신입니다. ACP는 not_ready_for_payment → ready_for_payment → requires_escalation/authentication_required → completed로 진행하며, 정상 경로 밖에는 canceled, expired, pending_approval이 있습니다. UCP의 incomplete → requires_escalation → ready_for_complete 흐름과 대응합니다.
• 에스컬레이션 상태는 사람 개입 접점입니다. 로그인, 3DS 추가 인증, 주소 확인, B2B approval_required, UCP continue_url이 여기에 해당합니다. 명세는 사람의 개입이 전혀 없는 완전 자율 체크아웃을 전제로 하지 않습니다.
• 결제는 범위 제한 토큰을 사용합니다. 판매자 고정(merchant_id + checkout_session_id), 금액 상한(max_amount), 시간 제한(expires_at), 일회용(reason: one_time)입니다. 에이전트는 원시 카드 정보를 보유하지 않습니다. CHD 직접 처리는 PCI 범위(Level 1)에 영향을 주므로 대부분의 판매자는 PSP·토큰화 경로를 사용합니다.
• 주문 확인은 푸시 방식입니다. 판매자는 HMAC 서명(Merchant-Signature)을 적용한 전체 객체 웹훅(order_create/order_update)을 POST하고 200/401/429를 처리합니다.
• 책임: OpenAI 명세에 따라 판매자는 계속 merchant of record이고 정산·환불·차지백은 판매자와 PSP가 담당합니다. 그러나 AI 에이전트가 수행한 구매에 이의를 제기할 때의 차지백 증거 문제는 2026년 중반 현재 해결되지 않았습니다. Visa TAP과 Mastercard Agent Pay는 등장 중인 프레임워크이지 완성된 해법이 아닙니다.
• 시험 항목: 멱등성 재시도(request_not_idempotent), 웹훅 서명 검증, 에스컬레이션·3DS 경로 시뮬레이션, 피드·체크아웃 가격 일치, GA4 세션이 없는 에이전트 주문 귀속입니다.
• 도입은 초기 단계: OpenAI가 2026년 3월 검색 후 리디렉션 방식으로 전환하기 전 실제 운영한 Shopify 판매자는 약 12곳이었습니다.

공식 문서

체크아웃 작동 방식을 설명하는 1차 출처 문서입니다.

ACP — 체크아웃, 수명 주기, 웹훅

• ACP Checkout API 참조 — 체크아웃 세션 엔드포인트, 전체 상태 열거형, CheckoutSession 필드, 오류/MessageError 객체, RiskSignals, AuthenticationResult, InterventionCapabilities를 설명합니다.
• ACP Checkout 수명 주기/개념 — 상태 전환(이행 옵션 → ready_for_payment, 결제 실패 후 재시도)을 설명합니다.
• ACP 주문 웹훅 — order_create/order_update, Merchant-Signature HMAC 요구 사항, 전체 객체 페이로드, 응답 코드를 설명합니다.
• GitHub의 ACP 명세 — OpenAPI/JSON Schema와 날짜 기반 버전입니다.

OpenAI / Stripe — 결제 위임

• OpenAI Delegated Payment 명세 — 범위 제한 토큰 흐름, allowance 객체(max_amount, expires_at, merchant_id, checkout_session_id, reason), PCI 범위 주의 사항, merchant of record 문구를 설명합니다.
• OpenAI Commerce 문서 — 판매자 통합 개요입니다.
• Stripe — Agentic Commerce(ACP) — Delegated Payment와 호환되는 첫 구현인 Shared Payment Token을 설명합니다.
• Stripe — ACP 프로토콜 명세 — 체크아웃 엔드포인트 구축 방법입니다.

UCP(병렬 체크아웃 머신)

• Google for Developers — UCP 가이드 — Google/Shopify 측의 merchant of record와 자격 요건 설명입니다.

플랫폼/결제 네트워크

• Shopify — Agentic Storefronts 요구 사항 — 추가 약관과 조사 당시 Google AI Mode/Gemini 얼리 액세스 상태입니다.
• Visa — 에이전틱 커머스: 위협 및 위험 — Trusted Agent Protocol에 관한 설명입니다.

출처의 인용문

에이전틱 체크아웃의 작동 방식과 열린 문제를 설명하는 공식 발언입니다. 출처 페이지가 지원하는 경우 딥 링크는 인용된 구절로 이동합니다.

ACP / OpenAI — 명세

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (번역) 「판매자는 재고, 가격, 세금 계산, 결제 처리를 완전히 통제합니다.」 — ACP Checkout API 참조. 인용문으로 이동
• 체크아웃 상태 열거형 원문: “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (번역) 「명세의 상태 토큰은 번역하지 않습니다: incomplete(상태), not_ready_for_payment(상태), requires_escalation(상태), authentication_required(상태), ready_for_payment(상태), pending_approval(상태), complete_in_progress(상태), completed(상태), canceled(상태), in_progress(상태), expired(상태).」 — ACP Checkout API 참조. 인용문으로 이동
• “OpenAI is not the merchant of record.” (번역) 「OpenAI는 merchant of record가 아닙니다.」 ACP에서 판매자는 자체 PSP를 사용하며 정산, 환불, 차지백, 규정 준수는 판매자와 해당 PSP가 담당합니다. — OpenAI Delegated Payment 명세. 인용문으로 이동
• 토큰 흐름에서 PSP 또는 볼트는 PCI 범위 밖에서 “payment token scoped to the delegated payment” (번역) 「위임 결제에 범위가 한정된 결제 토큰」을 반환합니다. — OpenAI Delegated Payment 명세. 인용문으로 이동

업계 관계자 — 책임 문제

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (번역) 「에이전틱 커머스는 효율성을 높이지만 기존 시스템이 해석할 수 없는 새로운 사기와 혼란의 층도 가져옵니다.」 — Chargeflow 사기·차지백 전략가 Ben Herut. 보도 읽기
• 규칙이 확정되었는지에 대해 Chargeflow는 “there are no clean answers yet” (번역) 「아직 명확한 답은 없다」고 분석합니다. 카드 네트워크, 발급사, 플랫폼 제공업체가 모두 이 문제를 검토하고 있습니다. 보도 읽기
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (번역) 「두 프로토콜 모두 판매자를 merchant of record로 유지하며 판매자가 이행, 차지백, 분쟁을 책임집니다.」 — Rye 공동 창업자 겸 CEO Arjun Bhargava. 보도 읽기

결제 네트워크 — 등장 중인 프레임워크

• Visa는 Trusted Agent Protocol을 “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience” (번역) 「사용자 경험을 저해하지 않으면서 사칭을 막도록 판매자가 에이전트의 신원과 의도를 실시간으로 검증할 수 있게 하는 표준 기반 프레임워크」라고 설명합니다. — Visa, 에이전틱 커머스: 위협 및 위험. 인용문으로 이동

도입 현실

• 완전 자율 체크아웃이 홍보만큼 빠르게 확산되지 않는 이유에 대해: “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (번역) 「수천만 SKU의 실시간 카탈로그 정규화는 Google이 Merchant Center로 이미 해결한 10년 단위 문제이며, 소비자는 여전히 Apple Pay, Google Wallet, Amazon 원클릭처럼 신뢰하는 체크아웃 흐름을 기본으로 선택합니다.」 — Search Engine Land를 통해 인용한 Semrush 온라인 가시성 이사 Leigh McKenzie. 보도 읽기

어떤 결제 통합 경로를 선택해야 하나요?

에이전틱 체크아웃의 첫 번째 실질적인 아키텍처 결정은 결제를 어떻게 위임할지입니다. 이 선택이 PCI 범위와 직접 구축해야 할 양을 결정하기 때문입니다. 의사결정 과정을 따라가 보세요.

에이전틱 체크아웃 출시 전 테스트

프로덕션에서 에이전틱 체크아웃을 활성화하기 전에 샌드박스·테스트 모드에서 실행하세요. 전략적 “피드를 정리하라”는 조언에서 빠지는 운영 계층입니다.

1. 체크아웃 세션을 만들고 정상 경로를 진행하세요. POST /checkout_sessions를 호출해 201과 not_ready_for_payment 또는 incomplete 상태의 세션을 받는지 확인합니다. 이행 옵션을 추가하고 상태가 ready_for_payment로 바뀌는지 확인합니다.
2. 합계가 권위 있는 값인지 검증하세요. 세션의 totals[](소계/세금/이행/할인/합계)가 백엔드 계산과 일치하고 가격이 피드와 같은지 확인합니다. 피드와 체크아웃 가격 불일치는 신뢰를 무너뜨립니다.
3. 세션을 완료하세요. POST /checkout_sessions/{id}/complete를 호출해 결제가 처리되고 주문이 생성되며 상태가 completed가 되는지 확인합니다.
4. 세션을 취소하세요. POST /checkout_sessions/{id}/cancel을 호출해 보류 재고가 남지 않도록 재고가 해제되는지 확인합니다.
5. 에스컬레이션 경로를 강제로 발생시키세요. requires_escalation/authentication_required를 시뮬레이션합니다. 3DS 추가 인증을 실행하고 AuthenticationResult 처리가 authenticated뿐 아니라 실패 결과인 denied, rejected, abandoned, canceled, not_supported를 모두 다루는지 확인합니다.
6. 멱등성을 시험하세요. 같은 멱등성 키로 동일한 생성·완료 요청을 두 번 보내 주문이 두 개가 아니라 하나만 생기는지 확인합니다. 실제 비멱등 재시도는 이중 청구가 아니라 request_not_idempotent를 반환해야 합니다.
7. 비즈니스 로직 오류와 HTTP 오류를 구분해 시험하세요. 재고가 없는 품목 같은 세션 내부 문제를 유발해 messages[]의 MessageError로 반환되는지 확인하고, 형식이 잘못된 요청은 HTTP 수준 오류 객체로 반환되는지 확인합니다. 클라이언트는 둘 다 처리해야 합니다.
8. 웹훅 서명을 검증하세요. 유효한 order_create 웹훅을 보내 Merchant-Signature HMAC을 검증하고 200을 반환하는지 확인합니다. 변조된 요청은 401로 거부하는지, 차이가 아니라 전체 Order 객체를 보내는지 확인합니다.
9. 웹훅 역압을 시험하세요. 플랫폼이 429를 반환할 때 이벤트를 버리지 않고 재시도·백오프하는지 확인합니다.
10. 귀속 정보가 기록되는지 확인하세요. GA4 세션이 없을 수 있으므로 완료된 주문이 OMS 수준에서 에이전트 기원으로 태그되는지 확인합니다.

흔한 실수와 대안

“에이전틱 체크아웃”을 사람의 개입이 전혀 없는 완전 자율 구매라고 가정합니다. 잘못된 이유: 신뢰할 수 있는 모든 구현은 requires_escalation, authentication_required, 3DS 추가 인증, B2B approval_required 같은 승인·에스컬레이션 접점을 유지합니다. 사람 개입 승인이 없는 완전 자율 방식은 명세의 설계도 아니며 카드 네트워크가 현재 이러한 거래를 처리하는 방식도 아닙니다. 대안: 사람의 조치가 필요한 거래가 막히지 않고 깔끔하게 에스컬레이션되도록 continue_url, 3DS, 승인 경로를 일급 흐름으로 설계하세요.

큰 헤드라인만 보고 이미 일반화된 기술로 취급합니다. 잘못된 이유: OpenAI가 2026년 3월 인채팅 방식을 축소하기 전 ChatGPT 체크아웃을 실제 운영한 Shopify 판매자는 약 12곳뿐이었습니다. 대안: 실재하고 명세화된 프로토콜 기능을 기준으로 구축하되, 뒤처진 사업자가 따라잡는 상황이 아니라 얼리 어답터라는 전제로 인력과 계획을 세우세요.

merchant of record가 정해졌으니 사기 책임도 완전히 해결됐다고 믿습니다. 잘못된 이유: 정산·환불·규정 준수에서 merchant of record는 확인되었지만, 구매자가 AI 에이전트였던 분쟁 거래가 적절히 승인되었음을 입증하는 차지백 증거 체계는 업계 사기 전문가도 해결되지 않았다고 설명합니다. 대안: 지금부터 에이전트 승인 로그와 위험 신호를 수집하고 Visa TAP/Mastercard Agent Pay를 완성된 해법이 아니라 등장 중인 프레임워크로 다루며, 기존 차지백 방어 증거가 그대로 통할 것이라고 가정하지 마세요.

에이전트가 웹사이트를 건너뛰므로 사이트 내 체크아웃은 중요하지 않다고 가정합니다. 잘못된 이유: “항상 판매자 사이트를 건너뛴다”는 것이 초기 ChatGPT Instant Checkout의 홍보였지만, ACP의 대표 구현 자체가 2026년 3월 검색 후 리디렉션 방식으로 이동했습니다. 프로토콜 기능은 특정 구현 방식에 종속되지 않습니다. 대안: 자체 호스팅 체크아웃을 견고하게 유지하면서 프로그래밍 방식 세션 흐름도 지원하세요. 노출 화면에 따라 채팅 안이나 사이트에서 거래를 완료할 수 있습니다.

에이전트가 고객의 카드 번호를 처리한다고 생각합니다. 잘못된 이유: 설계상 원시 카드 정보는 에이전트에 전달되지 않습니다. Shared Payment Token과 UCP의 분리된 수단/핸들러 모델 같은 범위 제한·위임 토큰이 결제 위임 계층의 핵심입니다. 대안: PSP를 통해 위임을 라우팅하여 판매자 고정·금액 제한·일회용 토큰이 결제를 처리하게 하고 PCI 범위를 작게 유지하세요.

비멱등 재시도 처리. 잘못된 이유: 에이전트와 네트워크는 재시도합니다. 단순한 재시도가 이중 청구나 주문 중복 생성을 일으킬 수 있기 때문에 ACP에는 request_not_idempotent 오류 유형이 있습니다. 대안: 생성·완료 호출에 멱등성 키를 요구하고 같은 키의 반복 호출을 안전하게 처리하세요.

에이전틱 체크아웃 치트 시트

ACP 체크아웃 세션 상태 열거형

UCP의 병렬 머신: incomplete → requires_escalation(continue_url을 통한 사람 개입) → ready_for_complete.

체크아웃 엔드포인트(ACP)

• POST /checkout_sessions — 생성(201)
• GET /checkout_sessions/{id} — 조회
• POST /checkout_sessions/{id} — 수정
• POST /checkout_sessions/{id}/complete — 결제 처리 및 주문 생성
• POST /checkout_sessions/{id}/cancel — 취소 및 재고 해제

범위 제한 결제 토큰 — 네 가지 제약

• merchant_id + checkout_session_id → 판매자·세션 고정
• max_amount → 금액 상한
• expires_at(RFC 3339) → 시간 제한
• reason: "one_time" → 일회용

주문 웹훅(ACP)

• 이벤트: order_create, order_update
• 서명: Merchant-Signature HMAC 헤더(필수)
• 페이로드: 차이가 아니라 전체 Order 객체
• 응답: 성공 200 · 잘못된 서명 401 · 속도 제한 429
• 주문 상태: created · manual_review · confirmed · canceled · shipped · fulfilled

사람 개입 트리거

• requires_escalation / authentication_required 상태
• InterventionCapabilities(3ds, address_verification; enforcement always/conditional/optional)
• AuthenticationResult 결과(authenticated/denied/rejected/abandoned/…)
• B2B approval_required, UCP continue_url

책임 요약

• 판매자 = merchant of record → 정산·환불·차지백은 판매자와 PSP가 담당 ✅ 확정
• 에이전트 구매자의 차지백 증거 규칙 ⚠️ 2026년 중반 현재 미해결
• Visa TAP / Mastercard Agent Pay → 등장 중인 프레임워크, 미완성

에이전틱 체크아웃 작업용 스니펫

다음 스니펫은 자체 통합을 점검하고 시험하기 위한 것이며 실제 구매를 실행하기 위한 것이 아닙니다. 샌드박스·테스트 자격 증명을 사용하세요.

웹훅 서명 검증(Node.js, HMAC)

Merchant-Signature가 일치하지 않는 요청은 모두 거부하세요. 상수 시간으로 비교합니다.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

체크아웃 세션 상태 폴링(shell)

테스트하는 동안 샌드박스 세션이 상태 머신을 따라 이동하는 과정을 관찰합니다.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

멱등성 키를 사용해 생성 요청 보내기(Python)

같은 키로 재시도했을 때 주문이 두 개가 아니라 하나만 생성되는지 증명합니다.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

콘솔 스니펫 — 렌더링된 페이지에서 .well-known UCP 프로필 검색

판매자가 UCP 검색 발견 정보를 노출하는지 빠르게 확인하는 DevTools Console 검사입니다. 판매자 오리진의 브라우저 콘솔에 붙여 넣으세요.

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

북마클릿 — ACP 문서의 체크아웃 상태 열거형으로 이동

ACP Checkout 참조의 상태 목록을 열도록 북마크에 저장하세요.

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

에이전틱 체크아웃의 흔한 실패

재시도로 주문이나 청구가 두 개 생성됨

증상: 시간 초과나 네트워크 재시도 후 같은 체크아웃 세션에서 주문이 중복 생성됩니다. 가능성 높은 원인: 생성 또는 완료 호출에 키가 없거나 재실행 안전성이 없습니다. 수정: 멱등성 키를 필수로 하고 같은 키의 재시도에는 최초 결과를 반환하며, 동일한 샌드박스 호출 두 번이 세션 하나와 주문 하나만 만드는지 확인합니다.

체크아웃이 결제 준비 상태가 되지 않음

증상: 세션이 not_ready_for_payment 또는 incomplete에 머뭅니다. 가능성 높은 원인: 필수 이행 옵션, 주소 필드, 비즈니스 규칙이 해결되지 않았습니다. 수정: 세션의 필수 필드와 messages[]를 검사하고 누락된 선택을 제공한 뒤 상태가 ready_for_payment 또는 ready_for_complete로 진행하는지 확인합니다.

유효한 요청이 성공한 것처럼 보이지만 장바구니를 완료할 수 없음

증상: HTTP 요청은 성공하지만 세션에 재고 부족 또는 다른 비즈니스 오류가 들어 있습니다. 가능성 높은 원인: 클라이언트가 HTTP 오류만 처리하고 MessageError 항목을 무시합니다. 수정: 전송 오류와 세션 메시지를 모두 처리한 뒤 사용자나 에이전트에게 실행 가능한 실패 내용이 표시되는지 확인합니다.

사람 인증 단계에서 조용히 중단됨

증상: 체크아웃이 requires_escalation 또는 authentication_required에 들어간 뒤 돌아오지 않습니다. 가능성 높은 원인: 3DS, 로그인, 승인, continue_url 인계를 지원되는 상태가 아니라 예외 오류로 처리했습니다. 수정: 인계 과정에서 세션을 유지하고 모든 인증 결과를 처리하며 성공한 흐름과 중단된 흐름이 모두 깔끔하게 종료되는지 확인합니다.

결제 후 주문 상태 업데이트가 멈춤

증상: 판매자에게는 주문이 있지만 에이전트 화면은 대기 중이거나 오래된 상태입니다. 가능성 높은 원인: 웹훅 서명 검증에 실패했거나, 차이만 보냈거나, 429 응답을 버렸습니다. 수정: 정확한 페이로드에 서명하고 전체 Order 객체를 보내며 속도 제한 이벤트를 백오프로 재시도하고 수신자가 이벤트를 받아들이는지 확인합니다.

에이전틱 체크아웃을 이해하는 사고 모델

체크아웃은 단일 API 호출이 아니라 상태 머신

각 응답은 세션을 알려진 상태로 이동시키거나 이동할 수 없는 알려진 이유를 노출해야 합니다. 클라이언트를 하나의 “구매” 요청이 아니라 전환, 종료 상태, 재시도, 에스컬레이션을 중심으로 설계하세요.

권한은 판매자에게 남음

에이전트는 의도를 표현하지만 가격, 재고, 세금, 이행, 주문 상태, merchant of record 의무의 권위 있는 주체는 판매자입니다. 에이전트가 요청한 장바구니는 입력으로, 판매자가 반환한 장바구니는 사실로 취급하세요.

위임은 권한을 좁힘

범위 제한 결제 토큰은 판매자와 세션에 묶이고 금액과 시간이 제한되며 한 번만 사용할 수 있기 때문에 안전합니다. 위임된 기능마다 무엇을, 누구를 위해, 얼마까지, 얼마나 오래 수행할 수 있는지 물어보세요.

에스컬레이션은 성공한 분기

사람의 개입은 자율 체크아웃의 실패가 아닙니다. 3DS, 로그인, 주소, B2B 승인을 깔끔하게 인계하면 프로토콜이 설계대로 작동한 것입니다.

완료 후 전달은 비동기식

결제 완료가 통합의 끝은 아닙니다. 서명된 전체 객체 웹훅이 체크아웃 이후의 주문 사실을 전달하므로 서명 검증, 재실행 안전성, 재시도 처리는 체크아웃 신뢰성의 일부입니다.

에이전틱 체크아웃 지표

종료 상태별 체크아웃 완료율

• 지표: 시작된 세션 중 완료, 취소, 만료된 세션의 비율입니다.
• 알 수 있는 것: 체크아웃 상태 머신이 어디서 끝나며 주문 생성 전에 얼마나 많은 의도가 사라지는지 보여 줍니다.
• 수집 방법: 커머스 API나 주문 플랫폼의 체크아웃 세션 상태 변화를 집계하고 프로토콜과 판매자 화면별로 분류합니다.
• 벤치마크/현실적 범위: 자체 상품 구성의 기준선을 만들고 유사한 흐름끼리 비교하세요. 현재 도입 단계에서 보편적 비율을 제시할 근거는 없습니다.
• 주기: 매일 모니터링하고 매주 추세를 검토합니다.

에스컬레이션 복구율

• 지표: 3DS, 로그인, 주소, 승인 개입 후 돌아와 완료된 에스컬레이션 세션의 비율입니다.
• 알 수 있는 것: 사람에게 넘기는 경로가 실제로 쓸 수 있는지, 막다른 길인지 보여 줍니다.
• 수집 방법: 체크아웃 세션 ID로 에스컬레이션 이벤트와 이후 상태 전환을 결합합니다.
• 벤치마크/현실적 범위: 인증과 B2B 승인은 마찰이 다르므로 개입 유형별로 기준선을 따로 만드세요.
• 주기: 매주, 그리고 인계 흐름을 변경할 때마다 검토합니다.

주문 중복 및 웹훅 실패율

• 지표: 같은 키의 재시도에서 생긴 중복 주문과 거부되거나 재시도 한도를 소진한 웹훅 전달의 합계입니다.
• 알 수 있는 것: 실패 상황에서도 멱등성과 비동기 주문 동기화가 안전한지 보여 줍니다.
• 수집 방법: 애플리케이션 로그에서 멱등성 키, 주문 ID, 서명 실패, 401, 429, 재시도, 데드 레터 이벤트를 비교합니다.
• 벤치마크/현실적 범위: 중복 주문은 0이어야 합니다. 일시적 재시도의 정상 기준선을 만들고 지속되는 이탈을 조사하세요.
• 주기: 즉시 알림을 보내고 매주 요약합니다.

시간을 들일 가치가 있는 자료

관련해서 제가 쓴 글

• 에이전틱 체크아웃이 포함되는 두 프로토콜은 이 사이트의 Agentic Commerce Protocol(ACP) 및 Universal Commerce Protocol(UCP) 글에서 자세히 다룹니다. 이 페이지는 두 글 아래에 놓이는 체크아웃 작동 방식 심층 안내입니다.
• 이커머스 SEO 초보자 가이드 — 에이전트 대상 체크아웃이 더 큰 이커머스 구조에서 어디에 놓이는지 설명합니다.

제 발표

• 검색의 작동 방식(SlideShare) — 검색 발견, 색인, 순위를 설명한 발표로, 에이전트가 중개하는 거래 계층이 그 위에 어떻게 놓이는지 이해하는 데 도움이 됩니다. 제 상시 고지 문구가 적용됩니다. “This is my understanding of systems… not going to be 100% complete or accurate.” (번역) 「이는 시스템에 대한 제 이해이며 100% 완전하거나 정확하지 않을 수 있습니다.」

업계 자료

• Agentic Commerce Protocol — Checkout 참조(OpenAI/Stripe) — 권위 있는 상태 열거형, 세션 필드, 개입·인증 객체입니다.
• OpenAI Delegated Payment 명세 — 범위 제한 토큰 흐름과 merchant of record/PCI 범위 문구입니다.
• ACP 주문 웹훅 참조(OpenAI/Stripe) — 푸시 기반, HMAC 서명, 전체 객체 주문 동기화 방식입니다.
• 에이전틱 커머스 차지백: AI가 구매할 때 누가 책임지는가?(Chargeflow) — 증거 문제에 “아직 명확한 답이 없다”고 말하는 솔직한 분석입니다.
• 에이전틱 커머스: 위협 및 위험(Visa) — Trusted Agent Protocol과 에이전트 신원 설명입니다.
• OpenAI’s big ChatGPT Instant Checkout plan just changed(Search Engine Land) — 2026년 3월 방향 전환과 도입 현실에 관한 인용입니다.
• What Is Agentic Checkout?(Rye) — 명확하고 독립적인 정의와 merchant of record 확인입니다.
• Deep Dive: Mastercard Verifiable Intent vs Visa Trusted Agent Protocol(Fintech Wrap Up/Finextra) — 결제 네트워크 프레임워크 비교입니다. 구체적인 책임 배분은 확인된 사실이 아니라 보도된 내용으로 취급하세요.

인용할 만한 통계

에이전틱 체크아웃의 실제 위치를 보여 주는 수치입니다. 판매자가 보고했거나 보도를 통해 전달된 수치는 방향성으로만 사용하고 의존하기 전에 검증하세요.

• Shopify 사장 발언을 2026년 3월 방향 전환에 관한 Search Engine Land 보도가 전달한 내용에 따르면 AI 체크아웃 도구를 실제 사용한 Shopify 판매자는 약 12곳으로, Shopify 전체 판매자 기반과 비교하면 미미했습니다. 보도
• 2026년 3월: 방향 전환. OpenAI는 온보딩, 정확성, 여러 상품 장바구니의 마찰을 겪은 뒤 ChatGPT Instant Checkout을 완전한 인채팅 구매 완료에서 검색 후 리디렉션 방식으로 바꿨습니다. 보도
• 토큰 범위 = 네 가지 제약. 위임 결제 토큰은 max_amount, expires_at, merchant_id/checkout_session_id, reason: one_time으로 제한됩니다. 에이전트가 원시 카드 정보에 접근하지 못하게 하는 구체적 장치입니다. 출처
• 웹훅 규칙: 항상 전체 객체. ACP는 웹훅 data 필드에 증분 차이가 아니라 전체 Order 객체를 넣고 모든 요청에 HMAC 서명을 적용하도록 요구합니다. 출처

에이전틱 체크아웃 퀴즈

체크아웃 작동 방식에 관한 짧은 질문 다섯 개입니다. 각 답을 고른 뒤 확인하세요.

변경 내역