Agent-Ready Commerce, Part 5: Keeping ACP, MCP, and AP2 Adapters Thin
개요
Agent-Ready Commerce 시리즈의 다섯 번째 글은 ACP(Agent-Commerce Protocol), MCP(Merchant-Commerce Protocol), AP2(Agent-Payment Protocol) 등의 프로토콜 어댑터를 얇게 유지하여 상업적 의미의 분산을 방지하는 방법에 대해 설명합니다.
주요 내용
- 어댑터의 본질적인 역할: 외부 프로토콜 요청을 상업 플랫폼이 이해할 수 있는 형태로 단순히 번역하는 것에 집중해야 합니다.
- 의미 분산(Semantic Drift)의 위험: 어댑터가 제품 가용성 확인, 정책 해석, 결제 권한 결정 등 상업적 의미를 결정하기 시작하면, 여러 어댑터가 각기 다른 해석을 내놓아 플랫폼의 일관성이 저해됩니다.
- "얇은 어댑터"의 정의: 어댑터의 크기(코드 라인 수)가 아니라 상업적 의미를 결정하지 않는 '권한'에 의해 얇음이 측정됩니다. 어댑터는 프로토콜 번역만 담당하고, 상업적 결정은 플랫폼의 도메인 계층에서 이루어져야 합니다.
- 단계별 어댑터 경계: 외부 프로토콜 요청 → 프로토콜 어댑터 → 표준화된 의도(Canonical Intent) → 도메인 결정 → 프로토콜 투영(Projection)의 5단계로 명확히 구분되어야 합니다.
- 표준화된 의도(Canonical Intent)의 중요성: 프로토콜의 외부 언어를 플랫폼의 내부 의도로 매핑하여, 다양한 프로토콜 요청이 동일한 상업적 결정을 내릴 수 있도록 합니다.
- 컨텍스트의 역할: 표준화된 의도는 제품, 구매자, 지역, 채널, 행위자 등 다양한 컨텍스트 정보를 포함해야 하며, 이는 결정의 입력으로 사용됩니다.
- 프로토콜 투영(Projection): 도메인 결정 결과를 각 프로토콜에 맞는 응답 형식으로 변환하는 과정으로, 이는 결정 자체가 아니라 표현 방식의 차이입니다.
- 기능(Capability)과 준비 상태(Readiness)의 구분: 프로토콜이 특정 작업을 표현할 수 있는지(Protocol Capability), 플랫폼이 해당 작업을 지원하는지(Platform Capability), 특정 제품 및 컨텍스트에서 해당 작업이 유효한지(Contextual Readiness)를 명확히 구분해야 합니다.
- 도메인 오류의 보존: 어댑터는 프로토콜 수준의 오류뿐만 아니라, 도메인 계층에서 발생하는 구체적인 차단 이유(Blocker Code)를 보존하여 전달해야 합니다.
- 내부 피드 및 관리자 인터페이스: 이러한 인터페이스 역시 외부 프로토콜과 마찬가지로 도메인 결정의 투영으로 간주되어야 하며, 의미 분산을 방지해야 합니다.
- 결제 관련 아티팩트: 결제 관련 프로토콜에서 제공되는 정보(mandates, signed messages 등)는 권한 평가를 위한 입력으로만 사용되어야 하며, 어댑터가 자체적으로 권한을 결정해서는 안 됩니다.
- 멱등성(Idempotency): 상태 변경 작업을 수행할 때 멱등성은 어댑터가 아닌 애플리케이션 서비스 또는 상태 전환 경계에서 관리되어야 합니다.
시사점
프로토콜 어댑터를 얇게 유지하고 상업적 결정을 중앙 집중식 도메인 계층으로 분리함으로써, agent-ready commerce 시스템은 일관성 있고 신뢰할 수 있는 상업적 의사 결정을 내릴 수 있으며, 다양한 외부 시스템과의 통합 시 발생하는 의미 분산 문제를 효과적으로 방지할 수 있습니다.
원문을 불러오는 중...
댓글
GitHub Discussions