인공지능(AI) 기술을 활용한 전자상거래 생태계를 둘러싼 OpenAI와 구글의 경쟁이 본격화되고 있습니다. 두 기업은 각자의 프로토콜을 통해 차세대 커머스 시장 선점에 나서며, 과거 안드로이드와 iOS가 모바일 운영체제 시장을 양분했던 것과 유사한 양상을 보이고 있습니다.
OpenAI는 'ACP(Agentic Commerce Protocol)'를, 구글은 'UCP(Universal Commerce Protocol)'를 각각 내세우며 서로 다른 접근 방식으로 시장 공략에 나섰습니다. 현재로서는 커머스 사업자들이 당분간 두 프로토콜 모두에 대응해야 하는 상황이 불가피할 것으로 전망됩니다.
ACP-UCP, 이들의 철학적 접근 방법 차이

두 프로토콜은 근본적인 철학부터 차이를 보입니다. OpenAI의 ACP는 '즉각성과 편의성(Instant & Frictionless)'을 강조하며, ChatGPT를 통한 상품 발견과 ACP 기반 구매를 지향합니다. 반면 구글의 UCP는 '개방성과 포괄성(Open & Comprehensive)'에 중점을 두고, 구글 검색과 AI 모드, Gemini를 통한 상품 발견을 추구하고 있습니다.
기술 구현 방식에서도 뚜렷한 차이가 나타납니다. ACP는 REST API와 공유 토큰 기반으로 에이전트에서 판매자로 향하는 단방향 최적화에 집중합니다. 이에 비해 UCP는 REST뿐 아니라 JSON-RPC, AP2, MCP 기술을 활용해 에이전트와 판매자 간 양방향 협상을 지원합니다.
결제 시스템 측면에서 OpenAI는 Stripe를 주요 파트너로 시작해 PayPal 등으로 확장하는 개방형 전략을 취하고 있습니다. Stripe는 'Agentic Commerce Suite'를 공동 개발하며 긴밀한 협력 관계를 구축했습니다. 구글은 자체 결제 시스템인 Google Pay를 기반으로 Google Merchant Center를 지원 플랫폼으로 활용하고 있습니다.
주요 전자상거래 플랫폼들도 양측 진영에 나뉘어 참여하고 있습니다. Shopify는 오픈AI, Stripe와의 협력을 통해 ACP 생태계에 합류한 반면, 동시에 구글의 UCP에도 참여하는 양면 전략을 구사하고 있습니다. Walmart와 Target 역시 두 프로토콜 모두를 지원하는 것으로 나타났습니다. Etsy, Wayfair 등은 구글과의 협력을 선택했습니다.
API 경제 시대의 도래
저희는 이번 프로토콜 경쟁이 본격적인 'API 경제(API Economy)' 시대의 서막이 될 것으로 전망하고 있습니다. 상품 발견부터 구매, 거래에 이르는 최종 접점이 브랜드 쇼핑몰의 API가 되면서, API가 준비되지 않은 쇼핑몰은 AI 에이전트의 접근 자체가 불가능해질 것으로 예상됩니다.
특히 주목할 점은 AI 에이전트가 모든 API를 동등하게 취급한다는 것입니다. 이는 기존 커머스 생태계에서 기존 커머스 플랫폼(마켓플레이스)이 누렸던 우위가 약화될 수 있음을 시사합니다. 초기에는 기존 커머스 플랫폼들이 우위를 유지하겠지만, 브랜드들의 대응 수준에 따라 관계가 역전될 여지도 있다는 것입니다.
승자와 패자를 가르는 요인
| 구분 | 승자의 조건 | 패자의 조건 |
|---|---|---|
| 데이터 | 구조화된 데이터 보유 | 열악한 데이터 인프라 |
| 업데이트 방식 | 실시간 및 최적화 지향 | 배치 업데이트 방식의 제품 피드 |
| 제품 특성 | 독창적이고 장인 정신이 담긴 제품 | 진열 위치에 대한 의존성 |
| 기술 수용성 | 새로운 기술을 빠르게 받아들이는 얼리 어답터 | 전통적인 광고 의존형 발견 방식 |
| 결제 시스템 | 현대적인 결제 프로세스(Stripe/PayPal 등) 활용 | 유연하지 못한 구식 결제 시스템 |
이번 프로토콜 경쟁에서 승패를 가를 핵심 요인으로는 구조화된 데이터 보유 여부, 실시간 최적화 능력, 제품의 독창성, 신기술에 대한 수용성, 그리고 현대적 결제 시스템 활용 등이 꼽히고 있습니다. 반대로 열악한 데이터 인프라, 구식 배치 업데이트 방식, 진열 위치 의존성, 전통적 광고 중심 전략, 경직된 결제 시스템을 유지하는 사업자들은 경쟁에서 뒤처질 가능성이 높습니다. 과거 모바일 운영체제 경쟁이 그랬듯, 이번 AI 커머스 프로토콜 전쟁도 장기화될 가능성이 큽니다. 따라서 당분간은 양쪽 프로토콜 모두에 대응하는 것이 불가피하다고 저희는 전망합니다.
AI 에이전트 커머스 시대, UCP 대응 5대 핵심 전략
AI 에이전트가 직접 상품을 검색하고 결제하는 AI 커머스 시대를 맞아, 전자상거래 기업들이 기술적·운영적 준비 태세를 전면 재점검해야 할 시점이 왔습니다. 아마 2026년은 이러한 AI 커머스를 실체적으로 경험하는 첫해가 되지 않을까 합니다. 이를 위해 개별 비즈니스 쇼핑몰들은 단순히 API를 개방하는 수준을 넘어, AI 에이전트와의 원활한 상호작용을 위해 5가지 핵심 영역에서 체계적인 준비가 필요하다는 것이 블루닷 인텔리전스를 개발하고 있는 저희의 판단입니다.
저희는 커머스 기업이 '디지털 간판' 정비부터 자율 결제 보안 인증까지 다층적 준비를 갖춰야 한다고 강조하고자 합니다. 이는 AI 에이전트가 쇼핑몰의 기능을 효율적으로 탐색하고, 안전하게 거래를 완료할 수 있는 환경을 조성하기 위한 필수 요건이기 때문입니다. 이에 대한 자세한 내용은 더코어 강정수 박사의 글(AI가 ‘최고의 고객’이 되는 순간)을 참고해 보시면 큰 도움을 얻으실 수 있을 겁니다.

동적 발견과 프로필 최적화가 첫 관문
.png)
첫 번째 핵심 영역은 동적 발견 및 프로필 최적화입니다. 우선 UCP에 최적화고자 하는 기업들은 자사 도메인 루트에 '/.well-known/ucp' 프로필을 호스팅해야 합니다. 이 프로필에는 지원 서비스(쇼핑, 결제 등), API 엔드포인트(REST, MCP 등), 공개 키 정보가 JSON 형식으로 정확히 명시돼야 합니다.
특히 UCP(Universal Commerce Protocol)는 '서버 선택(Server-selects)' 아키텍처를 따르기 때문에, 요청이 올 때마다 비즈니스 서버가 에이전트의 프로필을 확인해야 합니다. 전문가들은 성능 저하를 방지하기 위해 에이전트 프로필을 적절히 캐싱하여 협상 속도를 높이는 로직 구현이 필수적이라고 조언했습니다.
여기서 잠시 서버 선택 아키텍처를 이해할 필요가 있는데요. 조금 쉽게 설명을 해드리도록 하겠습니다. '서버 선택(Server-selects)' 아키텍처는 UCP(Universal Commerce Protocol)의 핵심 설계 원칙 중 하나입니다. 어떤 기능과 프로토콜 버전을 사용하여 통신할지를 에이전트가 아닌 서버(예, 쇼핑몰)가 최종 결정하는 방식을 말합니다. 예를 들어, 에이전트가 '나는 이런 기능들을 할 수 있어'라고 알려주면, 쇼핑몰(서버)이 그중에서 "그럼 우리 둘 다 가능한 이 기능들로 대화하자"라고 교집합을 계산해 통보하는 구조입니다. 즉 어떻게 기계적으로 대화할지 그 방법을 쇼핑몰 쪽이 선택 및 결정하게 되는 아키텍처라고 할 수 있습니다.
따라서 쇼핑몰 서버 쪽이 에이전트의 여러 역량들을 파악 및 진단하고 대화와 교신을 주도할 수 있는 최적화 준비가 필요할 수밖에 없습니다.
'신뢰의 삼각형' 모델로 결제 흐름 재구성

두 번째 영역인 결제 핸들러 구성에서는 '신뢰의 삼각형(Trust Triangle)' 모델이 핵심입니다. 여기서 신뢰의 삼각형을 구성하는 주체는 비즈니스(쇼핑몰), 플랫폼(에이전트를 의미합니다), 페이먼트 제공기업입니다. 이들 간의 신뢰 구축이 결제 측면에서 반드시 필요하며 이를 안전하게 보증하기 위해 프로토콜이 설계됐다는 얘기합니다. 예를 들어, 기업들은 단순히 '카드 결제 가능'이라고 알리는 대신, 사용하는 결제 제공자(PSP)와 공개 키를 포함한 구체적인 핸들러 정보를 프로필에 담아야 합니다.
결제 정보는 에이전트(플랫폼)에서 비즈니스로만 흐르는 단방향 흐름으로 설계됩니다. 비즈니스는 에이전트에게 결제 폼을 제공하는 대신, 에이전트가 PSP와 직접 통신하여 받아온 '불투명한 토큰(Opaque Credential)'을 처리할 수 있는 백엔드를 준비해야 합니다. 이러한 구조는 결제 성공률을 높이고 보안 사고를 방지하는 데 기여할 것으로 기대됩니다.
에이전트별 맞춤 경험 제공하는 협상 알고리즘
세 번째 핵심은 기능 협상 알고리즘 구현입니다. 모든 에이전트가 동일한 기능을 지원하지 않기 때문에, 에이전트의 능력에 따라 최적의 쇼핑 경험을 제공하는 교집합 연산 로직이 필요합니다.
비즈니스 서버는 요청이 들어오면 '자사가 지원하는 기능'과 '에이전트가 지원하는 기능'의 교집합을 계산하여, 해당 세션에서 사용할 기능을 확정해야 합니다. 예를 들어, 에이전트가 '할인 기능'은 지원하지만 부모 기능인 '체크아웃'을 지원하지 않는 경우, 할인 기능도 자동으로 비활성화하는 동적 가지치기(Pruning) 로직을 구현해야 오류를 방지할 수 있다고 설명했습니다.
완전 자율 커머스 대비한 보안 인증 체계
네 번째 영역은 자율 결제 보안 준비입니다. 사람의 개입 없이 AI가 스스로 결제하는 완전 자율 커머스를 대비하려면 더 높은 수준의 보안 인증이 요구됩니다.
쇼핑용 에이전트는 사용자의 실시간 클릭 대신 '암호화된 위임장(Mandate)'을 제출합니다. 기업들은 이 위임장의 서명을 검증하고, 이를 근거로 결제를 승인하는 'dev.ucp.shopping.ap2_mandate' 확장 기능을 구현해야 합니다. 또한 AI가 결제한 내역에 대해 사용자가 나중에 부인하는 것을 막기 위해, 거래 시 생성된 암호화 증명을 저장하고 검증하는 부인 방지(Non-Repudiation) 체계를 갖춰야 합니다.
리스크 관리와 규제 준수 비용 최소화와 최적화
다섯 번째 핵심은 리스크 관리 및 PCI-DSS 범위 축소입니다. AI 거래의 특성상 발생할 수 있는 이상 거래를 탐지하고 규제 준수 비용을 낮추는 전략이 필요합니다.
먼저 PCI-DSS가 무엇인지 알아야하겠죠. PCI-DSS(Payment Card Industry Data Security Standard)는 비자(Visa), 마스터카드(Mastercard) 등 글로벌 카드사들이 만든 데이터 보안 표준입니다. 신용카드 정보를 처리, 저장, 전송하는 모든 기업이 지켜야 하는 엄격한 보안 규칙을 의미합니다. UCP(Universal Commerce Protocol) 문서에서는 이 PCI-DSS 준수 부담을 최소화하는 것이 핵심 설계 목표 중 하나로 언급됩니다.
이를테면, 카드 번호(PAN)나 CVC 같은 원본 금융 정보가 서버를 스쳐 지나가기만 해도, 해당 서버와 네트워크는 PCI-DSS의 '규제 범위(Scope)'에 포함되게 됩니다. 이 범위에 들어가면 매년 복잡한 보안 심사를 받아야 하고, 이를 유지하는 데 막대한 비용과 기술적 노력이 듭니다. 이 부담을 축소하지 않으면, 이 프로토콜의 적용과 작동은 끊임없이 지연될 수가 있습니다.
기업의 쇼핑몰들은 결제 완료 요청 시 에이전트가 보내는 세션 ID, 디바이스 점수 등의 리스크 신호 데이터를 받아들이고, 이를 기존 사기 탐지 시스템(FDS)과 연동하는 파이프라인을 구축해야 합니다. 또한 UCP 구조를 활용하여 원본 카드 데이터(PAN)가 쇼핑몰 서버를 거치지 않도록 설계함으로써, PCI-DSS 인증 범위를 획기적으로 줄이고 보안 비용을 최적화할 수 있습니다.
전문가들은 "커머스 기업이 단순 API 개발을 넘어 '쇼핑몰 기능을 에이전트에게 설명하는 프로필 관리', '토큰 기반의 비대면 결제 처리', 'AI 위임장 검증'이라는 세 가지 핵심 역량을 내재화해야 프로토콜 도입 효과를 극대화할 수 있다"고 강조했습니다.
요약하면, 다음과 같습니다.
구분 | UCP 준비 (개방형 표준) | ACP 준비 (실용적 구현) |
|---|---|---|
핵심 과제 | 발견 및 협상 (Discovery & Negotiation) | 사양 준수 (Specification Compliance) |
필요 문서 | 비즈니스 프로필 ( /.well-known/ucp) | OpenAPI YAML ( openapi.*.yaml) |
결제 방식 | 신뢰의 삼각형 & 핸들러 협상 | 위임 결제 (Delegate Payment) 사양 구현 |
참조 대상 | 표준 문서 및 SDK | OpenAI / Stripe 참조 구현체 |
접근 태도 | "우리는 이런 기능들을 가지고 있어요" (광고) | "정해진 이 규격대로 통신합시다" (계약) |
마무리하며
GEO(Generative Engine Optimization)는 AEO(Agent Engine Optimization)를 포괄하는 영역으로 나아가고 있습니다. 이를 모두 아우르는 용어로 저희 블루닷에이아이는 MCO(Machine Customer Optimization)라는 표현을 조어했습니다. 이 모든 건 결국 기계 고객 최적화라는 의미에서입니다. GEO와 AEO를 포괄하는 영역으로서 MCO를 기업들은 준비해야 할 시점입니다.
MCO는 단순한 콘텐츠 최적화와 스키마 마크업 최적화를 넘어섭니다. 이제 기계 고객 최적화는 콘텐츠 엔지니어링과 API 엔지니어링을 포괄하는 통합적 엔지니어링 비즈니스로 진화하고 있습니다. 어쩌면 진단과 분석은 손쉬워질 수 있을지 모르겠지만 이를 최적화하기 위한 실행 과정은 더욱 복잡한 엔지니어링 이슈로 자리를 잡게 될 것입니다.
앞서 소개한 프로토콜의 대비 과정에서 확인했다시피, 최적화는 엔지니어링에 더욱 의존적입니다. 물론 이러한 엔지니어링이 적용되려면 개별 쇼핑몰 비즈니스의 정책적 준비와 보안이 잘 갖춰져 있어야 합니다. 에이전트 대리 구매가 편안하고 신뢰할 수 있는 경험으로 자리를 잡기 위해서는 단일 부서의 특정 역할로만으로는 부족합니다. 관련 부서의 종합적/협업적 대응이 필수적이라고 할 수 있습니다.
