ACP인가 UCP인가? 이 질문은 당신이 하나를 선택해야 한다는 것을 전제로 합니다. 하지만 그렇지 않습니다. 2026년 중반이 되면 이 둘은 수행하는 역할조차 달라져 있을 것입니다.

ACP와 UCP는 동일한 표준의 경쟁 관계에 있는 두 가지 구현체가 아닙니다. 이들은 서로 다른 계층(layer)에 위치하며, 하나를 위해 필요한 대부분의 작업은 다른 하나를 위해 필요한 작업과 동일합니다.

2026년 6월 기준 프로토콜 상태. 두 사양(spec) 모두 변화 중입니다. 구현하기 전에 현재 사양 버전을 확인하십시오. 그러한 이유로 아래의 모든 주장에는 날짜를 기입했습니다.

2026년 3월에 무엇이 변했나

ACP — OpenAI와 Stripe가 지원하는 Agentic Commerce Protocol — 는 ChatGPT Instant Checkout의 기반이 되는 표준으로 출시되었습니다. 에이전트가 제품을 찾고, 에이전트가 제품을 구매하며, 판매자(merchant)는 기록상의 판매자(merchant of record)로 남습니다.

2026년 3월에 그 흐름이 바뀌었습니다. ACP는 네이티브 체크아웃(native checkout)에서 벗어났으며, 실제로 남은 것은 **탐색 및 피드 프로토콜 (discovery and feed protocol)**입니다. 즉, 당신이 게시하고 OpenAI가 수집하며, ChatGPT가 당신의 제품이 답변에 포함될지 결정하는 데 사용하는 구조화되고 사양을 준수하는 제품 피드입니다.

UCP — Google이 지원하며 2026년 1월 NRF에서 발표되고 2026년 5월 20일 Google Marketing Live에서 대폭 확장된 Universal Commerce Protocol — 는 반대 방향으로 나아갔습니다. 이는 **라이브 에이전트 기반 체크아웃 표준 (live agentic-checkout standard)**입니다. 탐색, 장바구니 구성, 그리고 트랜잭션(transaction)을 포함하며, AI Mode, Gemini, YouTube Shopping 및 Gmail 전반에 걸친 통합이 발표되었습니다. 초기 액세스는 미국 우선으로 진행되었으며, 출시 범위는 서비스(surface)와 시장에 따라 다릅니다.

정리하자면: 하나의 프로토콜은 AI 시스템에 당신이 무엇을 파는지 알려줍니다. 다른 하나는 AI가 그것을 구매할 수 있게 합니다.

나란히 비교하기

실제로 공유되는 부분

1. 깨끗하고 완전한 제품 데이터 (Clean, complete product data) — SKU, 제목, 설명, 가격, 통화, 재고 상태, 이미지, 식별자 (GTIN/MPN). 두 프로토콜 모두 불완전한 레코드는 거부하거나 조용히 우선순위를 낮춥니다.
2. 정확한 실시간 재고 및 가격. 매일 밤 갱신되는 피드는 23시간 동안 거짓을 말하는 피드와 같습니다. 두 생태계 모두 이를 처벌합니다. 하나는 규정 준수 실패(conformance failures)로, 다른 하나는 좋지 않은 에이전트 경험(bad agent experiences)으로 처벌합니다.
3. 명시적인 기계 판독 가능 정책 (Explicit machine-readable policies) — 배송, 반품, 보증. 인간을 위해 작성된 CMS 페이지가 아닙니다.
4. JavaScript 실행에 의존하지 않는 크롤러 및 엔드포인트 접근 권한 (Crawler and endpoint access).
5. 페이지 자체의 구조화된 데이터 (Structured data on the page itself) — 피드가 오래되었거나 없는 경우를 대비한 폴백(fallback) 경로입니다.

이것은 프로토콜의 작업이 아닙니다. 그것은 카탈로그 위생(catalog hygiene)입니다. 이는 ACP가 다시 피벗하거나, UCP가 이름을 바꾸거나, 제3의 프로토콜이 무엇으로 나타나든 상관없이 살아남을 요소입니다.

내가 주장하는 구축 순서

Phase 0 — 기반 다지기 (무조건 수행할 것).
크롤러 접근성을 수정하세요. Product + Offer 구조화된 데이터가 availability를 완전한 schema.org URI로 포함하여 서버 측(server-side)에서 렌더링되도록 하세요. LLM이 읽을 수 있는 콘텐츠 맵을 게시하세요. 이 중 어느 것도 특정 프로토콜에 국한되지 않으며, 이 모든 것은 오늘날 ChatGPT, Gemini, Perplexity에서 보상을 받습니다.

Phase 1 — ACP 피드 배포.
이는 노력이 적게 드는 결과물이며, 이미 대상(audience)이 존재합니다 (ChatGPT는 엄청난 양의 쇼핑 의도 쿼리를 처리합니다). 또한 이를 구축하면 어차피 UCP에서 맞닥뜨리게 될 데이터 품질 문제를 해결하게 됩니다. 실제 간격으로 크론(Cron)을 설정하세요. 재고가 변동되는 카탈로그라면 매일 밤이 아니라 15분 간격이 합리적인 시작점입니다.

Phase 2 — UCP 매니페스트(manifest) 준비.
/.well-known/ucp를 게시하고, ECDSA 서명 키를 생성하며, 프로필 검증을 받으세요. 에이전트 기반 결제(agentic checkout)가 아직 귀하의 시장에 도달하지 않았더라도, 매니페스트를 유지하는 비용은 저렴하며 대기 수요는 실재합니다.

3단계 — 결제(checkout)에 대해 의도적으로 결정하십시오.
에이전트가 구매를 완료하도록 허용하는 것은 기술적인 결정인 동시에 정책적인 결정입니다. 주문 금액 상한선, 확인 요구 사항, 사기 대응 태세(fraud posture), 에이전트가 실수를 했을 때 어떻게 처리할지 등이 여기에 해당합니다. 스위치를 켜기 전(flip the switch)에 이 논의를 완료하십시오. 나중에 하면 늦습니다.

결제 문제가 여전히 머물러 있는 지점

이것이 모든 것을 결정짓기 때문에 명확하게 언급할 가치가 있습니다. 서버 측 프로토콜(server-side protocol)에서 작동하는 에이전트는 카드를 토큰화(tokenize)할 수 없습니다. Stripe의 카드 흐름은 PCI 준수 브라우저 컨텍스트(PCI-compliant browser context) — Stripe.js, Payment Element 등 — 를 필요로 하며, 이는 백엔드 도구 호출(backend tool call)과는 근본적으로 호환되지 않습니다.

현재의 모든 에이전트 결제(agentic-checkout) 설계는 이 문제를 정면으로 돌파하기보다는 우회하는 방식으로 작동합니다. 오프라인/인보이스(invoice) 방식, 인증된 고객과 연결된 저장된 토큰, 또는 마지막 단계에서 호스팅된 결제 페이지(hosted payment page)로의 핸드오프(handoff) 등이 그 예입니다. 순수한 API 프로토콜을 통해 에이전트가 "귀하의 카드로 결제한다"고 주장하는 사람은 내부에 브라우저가 숨겨져 있는 무언가를 설명하고 있는 것입니다.

이것이 2026년 에이전트 커머스(agentic commerce)가 직면한 정직한 한계이며, 이를 고려하여 설계를 진행해야 합니다.

Magento 2를 사용 중이라면

두 프로토콜 모두 내장된 지원은 없습니다. Magento는 스택에 대한 완전한 제어권과 그에 따른 완전한 책임을 사용자에게 부여합니다. 양측 모두를 위한 오픈 소스 옵션이 존재합니다. 저는 그중 일부를 유지 관리하고 있습니다 (angeo/module-openai-product-feed는 ACP용, angeo/module-ucp는 UCP 프로필 및 서명 키용 — MIT, Composer). 공개하자면, 제가 직접 작성한 것들이며, 다른 라이선스와 범위를 가진 비교해 볼 만한 대안들도 존재합니다.

하지만 모듈 선택은 마지막 10%에 불과합니다. 나머지 90%는 귀하의 카탈로그 데이터가 실제로 정확한지 여부이며, 어떤 모듈도 이를 대신 해결해 주지는 않습니다.

여러분의 생각은 어떠신가요? 이곳에 벌써 프로덕션 환경에서 UCP 결제를 구축하고 있는 분이 계신가요, 아니면 모두가 여전히 피드 제공 및 대기(feed-and-wait) 모드에 머물러 있나요? 미국 측의 초기 액세스(early-access) 경험이 어떤 모습인지 진심으로 궁금합니다.