Universal Commerce Protocol (UCP)는 Google과 Shopify의 에이전트 기반 쇼핑 표준이며, 대부분의 표준이 결코 모으지 못할 수준의 파트너 목록과 함께 출시되었습니다. 저는 이것이 단순히 지지(endorsed)되는 것을 넘어 실제로 얼마나 '배포(deployed)'되었는지 궁금했습니다. 그래서 레이어별로 측정하여 모든 수치를 출처와 연결하고, 매달 업데이트하며 공개적으로 게시하고 있습니다: spck.dev/state-of-ucp.

저를 놀라게 한 몇 가지 사항들이 있습니다.

제공되는 프로필이 채택을 의미하지는 않는다

약 3,000개의 라이브 UCP 엔드포인트(endpoints) 중 약 **99%는 단일 플랫폼이 엔드포인트를 자동 프로비저닝(auto-provisioning)**하는 것이며, 독립적인 채택 결정에 의한 것이 아닙니다. "검증된 UCP 가맹점(verified UCP merchants)"을 채택자로 계산하는 것은 실제 상황을 거의 모든 면에서 과다 계상하는 것입니다.

프런티어는 아주 작은 꼬리 부분에 존재한다

메시지 서명(message signatures), 신원 연결(identity linking), 에이전트 결제(agent payments)와 같은 사양(spec)의 고급 기능들은 거의 독점적으로 소수의 셀프 호스팅(self-hosted) 그룹에서만 나타납니다. 플랫폼 기본값인 99%는 이러한 기능들을 전혀 포함하고 있지 않습니다. 따라서 이 사양의 야망은 실제적이고 차별화된 배포보다 몇 년은 앞서 나가고 있습니다.

결제 레이어는 발표되었을 뿐, 라이브 상태가 아니다

AP2 결제 코호트(cohort)는 가장 깊은 지지 목록을 보유하고 있지만, 가장 적게 배포되었습니다: 에이전트 기반 카드 결제를 위한 카드 네트워크는 아직 라이브 상태가 아닙. 해당 분야에서 유일한 프로덕션(production) 주장은 카드가 아닌 크립토 레일(crypto rails)입니다.

"준수(Conformant)"는 세 가지 서로 다른 질문이다

규범적 요구사항(normative requirements) 중 일부는 가맹점 서버를 테스트하고, 일부는 구매 에이전트를 구속하며, 일부는 프로세스/수동 방식입니다. 사용자를 실제로 해칠 수 있는 실패 사례, 즉 에이전트가 일치하지 않는 총액을 결제하거나 검증되지 않은 응답을 신뢰하는 문제는 오늘날 거의 아무도 측정하지 않는 **에이전트 측(agent side)**에서 발생합니다.

방법론

이것은 최선의 노력을 다한 독립적인 분석이며, 저는 확신하기보다는 교정받는 쪽을 택하겠습니다. 해당 페이지는 모든 수치를 출처와 연결하고, 원시 데이터(raw data)를 함께 게시하며, 매달 갱신합니다. 무언가 잘못된 것처럼 보인다면 진심으로 수정을 환영합니다.

전체 보고서 및 데이터: spck.dev/state-of-ucp.