에이전트 준비 완료 커머스(Agent-Ready Commerce)를 위한 참조 아키텍처(Reference Architecture)에는 한 가지 핵심 규칙이 있습니다:

모든 외부 접점(External surface)은 동일한 커머스 의사결정 중추(Commerce decision spine)의 투영(Projection)이어야 합니다.

스토어프런트(Storefront), 제품 피드(Product feed), MCP 스타일 도구(MCP-style tool), ACP 스타일 상호작용(ACP-style interaction), AP2 관련 결제 흐름(AP2-related payment flow), 마켓플레이스 API(Marketplace API), 관리자 UI(Admin UI), 지원 뷰(Support view), 그리고 미래의 에이전트 인터페이스(Agent interface)는 모두 서로 다른 형태의 응답을 필요로 할 수 있습니다.

하지만 이들은 서로 다른 상업적 의미를 생성해서는 안 됩니다.

만약 한 접점에서는 제품이 결제 가능(Checkout-ready)하다고 말하는데, 다른 접점에서는 결제를 차단한다면, 아키텍처가 이탈(Drift)한 것입니다.

만약 한 어댑터(Adapter)는 반품 정책을 인용하는데, 다른 어댑터는 반품 정책 범위가 누락되었다고 말한다면, 아키텍처가 이탈한 것입니다.

만약 생성된 요약(Generated summary)에서는 제품이 배송 준비가 되었다고 하는데, 자격 요건(Eligibility)에서는 재고가 오래되었다(Stale)고 한다면, 아키텍처가 이탈한 것입니다.

만약 결제 아티팩트(Payment artifact)가 결제를 진행하게 만드는데 정작 결제 단계(Checkout)가 유효하지 않다면, 아키텍처는 실패한 것입니다.

에이전트 준비 완료 커머스(Agent-ready commerce)는 상점에 부착된 챗봇(Chatbot)이 아닙니다. 단순히 제품 피드(Product feed)도 아닙니다. 프로토콜을 위한 어댑터(Adapter)도 아니며, 결제 토큰(Payment token)이나 생성된 제품 카피(Generated product copy)도 아닙니다.

그것은 상업적 의미에 대한 통제력을 잃지 않으면서, 자신의 사실(Facts), 정책(Policies), 동작(Actions), 상태 전이(State transitions), 권한 경계(Authority boundaries), 생성된 주장(Generated claims), 그리고 증거(Evidence)를 에이전트(Agents)에게 노출할 수 있는 커머스 플랫폼입니다.

이를 위해서는 의사결정 중심의 아키텍처(Decision-centered architecture)가 필요합니다.

이 글은 Agent-Ready Commerce 시리즈의 열 번째이자 마지막 기사입니다.

파트 1에서는 더 넓은 아키텍처 모델을 소개했습니다:

사실(Facts) → 자격 요건(Eligibility) → 권한(Authority) → 상태 전이(State transition) → 증거(Evidence) → 감사(Audit)

파트 2에서는 상업적 진실(Commercial truth)에 초점을 맞췄습니다. 카탈로그 데이터만으로는 충분하지 않다고 주장했습니다. 에이전트나 다른 시스템이 제품 정보에 안전하게 의존하기 위해서는 플랫폼에 출처가 확인되고 최신성을 인지하는(Freshness-aware) 제품 사실(Product facts)이 필요합니다.

파트 3에서는 동작 자격(Action eligibility)에 초점을 맞췄습니다. "사용 가능(Available)"이라는 표현은 너무 광범위하다고 주장했습니다. 제품은 검색은 가능하지만 결제 준비는 안 되어 있을 수 있고, 비교는 가능하지만 정책 인용은 불가능할 수 있으며, 인간의 흐름(Human flow)에는 결제 준비가 되어 있지만 위임된 결제(Delegated payment)에는 적합하지 않을 수 있습니다.

파트 4는 정책 구조(policy structure)에 집중했습니다. 에이전트가 자유 형식의 텍스트(free-text) 정책 페이지를 실행 가능한 규칙으로 해석해서는 안 된다고 주장했습니다. 정책에는 적용 가능성(applicability), 증거(evidence), 생명주기(lifecycle), 충돌(conflicts), 그리고 인용 가능성(quoteability)을 갖춘 구조화된 사실(structured facts)이 필요합니다.

파트 5는 프로토콜 어댑터(protocol adapters)에 집중했습니다. ACP, MCP, AP2, 피드(feeds), 도구(tools) 및 미래의 인터페이스들은 별도의 상업적 의미를 생성하는 소스가 되기보다는 도메인 결정(domain decisions)을 번역해야 한다고 주장했습니다.

파트 6는 결제 상태(checkout state)에 집중했습니다. 결제(checkout)는 에이전트 준비 완료 커머스(agent-ready commerce)가 질문에 답하는 단계에서 상업적 상태를 변경(mutating)하는 단계로 넘어가는 지점이라고 주장했습니다. 따라서 결제는 폼 엔드포인트(form endpoint)가 아니라 상태 머신(state machine)으로 모델링되어야 합니다.

파트 7은 위임된 결제(delegated payment)에 집중했습니다. 결제 산출물(payment artifact)만으로는 충분하지 않다고 주장했습니다. 위임된 결제에는 특정 결제 스냅샷(checkout snapshot), 금액(amount), 통화(currency), 가맹점(merchant), 행위자(actor), 구매자(buyer), 시간 범위(time window), 증거(evidence) 및 감사(audit)에 대한 제한된 권한(bounded authority)이 필요합니다.

파트 8은 생성된 클레임(generated claims)에 집중했습니다. 생성된 커머스 텍스트는 의존성(dependencies), 범위(scope), 검토 상태(review status), 허용된 사용(allowed use), 무효화(invalidation), 만료(expiry) 및 감사(audit)를 갖춘 파생된 클레임(derived claim)으로 취급되어야 한다고 주장했습니다.

파트 9는 증거 및 감사(evidence and audit)에 집중했습니다. 에이전트 준비 완료 커머스에는 단순한 로그(logs)가 아닌 증명 계층(proof layer)이 필요하다고 주장했습니다.

이 마지막 기사는 이 조각들을 하나의 참조 아키텍처(reference architecture)로 연결합니다.

핵심 논점은 에이전트 준비 완료 커머스가 공유된 결정 중추(shared decision spine)를 중심으로 구축되어야 한다는 것입니다:

소스 시스템 (Source systems)
      ↓
상업적 진실 (Commercial truth)
...

프로토콜과 채널은 가장자리에 위치합니다. 이들은 의미(meaning)를 소유하지 않습니다.

아키텍처는 토폴로지(topology)가 아닙니다

참조 아키텍처는 배포 다이어그램(deployment diagram)과 동일한 것이 아닙니다.

시스템은 다음과 같이 구현될 수 있습니다:

모듈형 모놀리스 (a modular monolith)
서비스 세트 (a set of services)
워크플로 기반 플랫폼 (a workflow-based platform)
...

배포 형태(deployment shape)는 의미론적 경계(semantic boundaries)보다 덜 중요합니다.

소규모 팀은 상업적 진실(commercial truth), 정책 사실(policy facts), 자격(eligibility), 결제(checkout), 생성된 클레임(generated claims) 및 감사를 하나의 애플리케이션 내 모듈로 구현할 수 있습니다.

대규모 조직은 이를 서비스로 분리할 수 있습니다.

두 방식 모두 작동할 수 있습니다.

다만 중요한 질문의 성격이 다릅니다:

어댑터 (adapters)가 자격 요건 (eligibility)을 우회할 수 있는가?
피드 (feeds)가 결정 기록 (decision records) 없이 준비 상태를 게시할 수 있는가?
정책 적용 (policy coverage) 없이 결제 (checkout)를 진행할 수 있는가?
...

만약 이 질문들에 대한 답이 '예'라면, 아키텍처가 하나의 서비스로 배포되든 20개의 서비스로 배포되든 상관없이 구조적 괴리 (drift)가 발생할 것입니다.

명확한 도메인 경계 (domain boundaries)를 가진 잘 구조화된 모놀리스 (monolith)가 규칙이 중복된 분산 시스템 (distributed system)보다 더 안전합니다.

참조 아키텍처 (reference architecture)는 의미의 소유권 (ownership of meaning)에 관한 것입니다.

결정 스파인 (The decision spine)

결정 스파인 (decision spine)은 커머스적 의미가 생성되는 경로입니다.

단순화된 버전은 다음과 같습니다:

원천 데이터 (Raw source data)
      ↓
소스 기반 사실 (Source-backed facts)
...

각 레이어 (layer)는 서로 다른 질문에 답합니다.

레이어 (Layer)	질문 (Question)
소스 시스템 (Source systems)	운영 시스템 (operational systems)에 어떤 데이터가 존재하는가?
...

이 스파인은 에이전트 (agents), 어댑터 (adapters), 피드 (feeds), 생성된 텍스트 (generated text), 그리고 결제 흐름 (checkout flows)이 커머스 상태 (commerce state)에 대해 자신만의 해석을 임의로 만들어내는 것을 방지합니다.

여행용 배낭 엔드 투 엔드 (The Travel Backpack end-to-end)

진행 중인 예시를 마지막으로 한 번 더 사용해 보겠습니다:

제품 (Product): 여행용 배낭 (Travel Backpack)
SKU: BAG-TRAVEL-42
가격 (Price): €129
...

현재 커머스 진실 레이어 (commercial truth layer)는 다음과 같이 말합니다:

가격 (Price): 최신 (fresh)
재고 (Inventory): 오래됨 (stale)
반품 정책 (Return policy): 여행용 가방에 대해 누락됨 (missing for Travel Bags)
...

액션 매트릭스 (action matrix)는 다음과 같습니다:

액션 (Action)	결과 (Result)
discover	허용됨 (allowed)
...

이제 에이전트가 다음과 같이 질문한다고 가정해 봅시다:

총액이 €150 미만이라면 구매자를 위해 여행용 배낭을 구매할 수 있나요?

채널 우선 (channel-first) 구현 방식은 어댑터 (adapter) 내부에서 답을 찾으려 시도할 수 있습니다:

제품이 활성화되었는가? (Product active?)
재고가 '재고 있음'이라고 하는가? (Inventory says in_stock?)
가격이 €150 미만인가? (Price below €150?)
...

이는 안전하지 않습니다.

결정 중심 플랫폼 (decision-centered platform)은 스파인을 따릅니다:

프로토콜 요청 (Protocol request)
      ↓
표준 의도 (Canonical intent)
...

올바른 결과는 다음과 같습니다:

위임된 결제 (Delegated payment)가 차단되었습니다.

이유 (Reason):
...

이 답변은 어댑터가 즉석에서 만들어낸 것이 아닙니다.

플랫폼의 결정 경로 (decision path)에 의해 생성된 것입니다.

이것이 바로 아키텍처의 목표입니다.

소스 시스템은 입력을 제공할 뿐, 진실을 제공하는 것이 아닙니다

소스 시스템(Source systems)에는 다음이 포함될 수 있습니다:

Catalog systems (카탈로그 시스템)
PIM (제품 정보 관리)
ERP (전사적 자원 관리)
...

이러한 시스템들은 중요한 데이터를 포함하고 있습니다. 하지만 그 데이터가 에이전트(agent)가 사용하기에 자동으로 안전한 것은 아닙니다.

카탈로그 필드에 제품이 '활성(active)' 상태라고 되어 있을 수 있습니다. 그렇다고 해서 체크아웃(checkout)을 준비할 수 있다는 뜻은 아닙니다.

재고 소스(inventory source)에 in_stock이라고 표시될 수 있습니다. 그렇다고 해서 해당 재고 사실(inventory fact)이 결제나 풀필먼트(fulfillment)를 수행할 만큼 충분히 최신 상태라는 뜻은 아닙니다.

정책 페이지(policy page)에 반품에 관한 설명이 있을 수 있습니다. 그렇다고 해서 인용 가능한(quoteable) 반품 정책 사실(return-policy fact)이 이 제품, 카테고리, 지역, 구매자 유형 및 채널에 적용된다는 뜻은 아닙니다.

결제 제공업체(payment provider)가 결제를 승인할 수 있습니다. 그렇다고 해서 주문이 확정(committed)되었다는 뜻은 아닙니다.

따라서 인제스션 레이어(ingestion layer)는 소스 입력값을 참조된 사실(referenced facts)로 변환해야 합니다.

type SourceRef = {
  system: string;
  objectType: string;
...

이 레이어는 다음 질문에 답합니다:

그 사실은 어디에서 왔는가?
언제 캡처되었는가?
어떤 버전이 사용되었는가?
...

이 레이어가 없다면, 모든 다운스트림(downstream) 결정은 약화됩니다.

커머셜 트루스(Commercial truth)는 첫 번째 플랫폼 경계입니다

커머셜 트루스(Commercial truth)는 플랫폼이 현재 신뢰할 수 있는, 소스에 의해 뒷받침되는 사실(source-backed facts)의 집합입니다.

이것은 카탈로그의 복사본이 아닙니다.

이것은 제품 페이지가 아닙니다.

이것은 생성된 카피(generated copy)가 아닙니다.

이것은 의사결정 입력값(decision input)입니다.

Travel Backpack의 경우:

Catalog:
active
in_stock
...

차이점은 아키텍처에 있습니다.

제품이 활성 상태일 수는 있지만, 체크아웃 준비가 되어 있지 않을 수 있습니다.

제품에 가격이 있을 수는 있지만, 결제에 사용할 만큼 충분히 최신 가격이 아닐 수 있습니다.

제품에 정책 페이지가 있을 수는 있지만, 인용 가능한 정책 사실(quoteable policy fact)은 없을 수 있습니다.

제품에 생성된 카피가 있을 수는 있지만, 승인된 생성된 주장(approved generated claim)은 없을 수 있습니다.

커머셜 트루스 스냅샷(Commercial truth snapshot)은 다음과 같을 수 있습니다:

type CommercialTruthSnapshot = {
  snapshotId: string;

...

스냅샷은 저장, 캐싱되거나 요청 시(on demand) 계산될 수 있습니다. 중요한 속성은 일관성(consistency)입니다.

피드(Feeds), 어댑터(adapters), 체크아웃(checkout), 생성된 주장(generated claims), 그리고 관리자 UI(admin UI)가 각각 서로 다른 진실을 선택해서는 안 됩니다.

정책 사실(Policy facts)은 정책 페이지가 아닙니다

정책 페이지는 인간에게 약관을 전달합니다.

정책 사실(Policy facts)은 머신의 결정을 지원합니다.

정책 계층(Policy layer)은 반품, 배송, 보증, 취소, 지역 제한 및 기업 구매자 규칙을 적용 가능성(applicability)과 인용 가능성(quoteability)을 갖춘 구조화된 사실(structured facts)로 변환해야 합니다.

type PolicyFact = {
  policyFactId: string;

...

여행용 백팩(Travel Backpack)의 경우:

Warranty policy:
known

...

생성된 요약(generated summary)은 그 간극을 채울 수 없습니다.

어댑터(adapter)는 일반적인 반품 페이지를 인용하고 이를 적용 가능한 것으로 취급할 수 없습니다.

체크아웃 흐름(checkout flow)은 특정 카테고리에 어딘가 공개된 정책 페이지가 있다는 이유만으로 반품 조건이 사용 가능하다는 가정을 해서는 안 됩니다.

정책 계층이 적용 가능성과 인용 가능성을 소유합니다.

이러한 소유권은 에이전트(agent)가 정책 언어를 과도하게 인용(over-quoting)하는 것을 방지합니다.

자격(Eligibility)은 액션별로 특정됩니다

자격(Eligibility)은 available이 안전하지 않은 불리언(boolean) 값이 되는 것을 방지합니다.

플랫폼은 액션(actions)을 별도로 평가해야 합니다:

discover
compare
quote_policy
...

각 액션은 서로 다른 요구 사항을 가집니다.

type CommerceAction =
  | "discover"
  | "compare"
...

여행용 백팩(Travel Backpack)의 경우:

discover:
allowed

...

이 계층은 모든 서피스(surface)에서 공유되어야 합니다.

피드(feed)가 액션 준비 상태(action readiness)를 별도로 계산해서는 안 됩니다.

어댑터(adapter)가 제품 상태로부터 체크아웃 준비 상태를 추론해서는 안 됩니다.

관리자 UI(admin UI)가 에이전트 피드와 다른 준비 상태 결과를 보여주어서는 안 됩니다.

자격(Eligibility)은 액션 계약(action contract)입니다.

권한(Authority)은 자격(eligibility)과 분리됩니다

자격(Eligibility)은 다음을 답변합니다:

이 상업적 맥락에서 이 액션이 유효한가?

권한(Authority)은 다음을 답변합니다:

이 행위자(actor)가 이 액션을 요청할 수 있는가?

이것들은 서로 다른 질문입니다.

제품이 체크아웃할 자격(eligible)이 있을 수 있지만, 에이전트가 구매자를 위해 체크아웃을 준비할 권한(authorized)이 없을 수도 있습니다.

구매자가 에이전트에게 아이템 구매를 승인할 수 있지만, 체크아웃은 여전히 유효하지 않을 수 있습니다.

결제 아티팩트(payment artifact)가 존재할 수 있지만, 명령 범위(mandate scope)가 장바구니 스냅샷(cart snapshot)과 일치하지 않을 수 있습니다.

지원 운영자(support operator)는 차단 요소(blockers)를 볼 수는 있지만 결제를 요청할 수는 없습니다.

권한(Authority)은 별도의 계층에 속해야 합니다.

type ActorContext = {
  actorId: string;
  actorType: "human" | "agent" | "system";
...

파트 7에서는 위임된 결제 권한(delegated payment authority) 문제를 소개했습니다:

이 액터(actor)가 이 구매자(buyer), 판매자(merchant), 체크아웃 스냅샷(checkout snapshot), 금액(amount), 통화(currency), 그리고 시간 범위(time window)에 대해 이 결제 동작(payment action)을 요청할 수 있는가?

그 질문에 대한 답은 결제 어댑터(payment adapter) 내부에서 이루어져서는 안 됩니다.

플랫폼 권한 계층(platform authority layer)에서 답변되어야 합니다.

체크아웃은 변이 경계(mutation boundary)입니다

체크아웃은 플랫폼이 질문에 답하는 단계에서 상업적 상태(commercial state)를 변이(mutating)하는 단계로 넘어가는 지점입니다.

참조 아키텍처(reference architecture)는 체크아웃을 폼 엔드포인트(form endpoint)가 아닌 상태 머신(state machine)으로 취급해야 합니다.

type CheckoutState =
  | "draft_cart"
  | "cart_requires_revalidation"
...

어댑터(Adapters)는 숨겨진 체크아웃 변이(checkout mutations)를 수행해서는 안 됩니다.

어댑터는 외부 요청을 명령(commands)으로 매핑해야 합니다.

async function protocolAdapterHandler(req: ProtocolRequest) {
  const command = mapToCheckoutCommand(req);
  const result = await checkout.handleCommand(command);
...

체크아웃 상태 머신은 상업적 진실(commercial truth), 정책 사실(policy facts), 자격(eligibility), 권한(authority), 장바구니 스냅샷(cart snapshots), 멱등성(idempotency), 만료(expiry), 결제 상태(payment state), 증거(evidence), 그리고 감사(audit)를 조정합니다.

이 모든 도메인을 내부적으로 중복해서 가질 필요는 없습니다.

Travel Backpack의 경우:

add_item:
requires revalidation

...

이는 결제 또는 주문 로직이 장바구니가 자격이 없었다는 사실을 너무 늦게 발견하는 것을 방지합니다.

결제 권한은 체크아웃 스냅샷에 결합됩니다

결제 권한은 토큰 확인(token check)으로 모델링되어서는 안 됩니다.

특정 체크아웃 스냅샷(checkout snapshot)에 대한 제한된 권한(bounded authority)으로 모델링되어야 합니다.

type PaymentMandate = {
  mandateId: string;

...

결제 실행 전에 플랫폼은 다음을 확인합니다:

체크아웃 상태(checkout state)
장바구니 스냅샷 일치 여부(cart snapshot match)
금액(amount)
...

Travel Backpack의 경우, 체크아웃이 유효하지 않기 때문에 제공자(provider) 실행 전에 결제가 차단됩니다.

이 인과 관계(causal chain)는 중요합니다:

delegate_payment blocked
      ↓
checkout is not valid
...

결제 권한(Payment authority)은 체크아웃(checkout)을 유효하게 만들 수 없습니다.

결제 권한은 체크아웃이 유효하고 요청이 위임 범위(mandate scope) 내에 있는 경우에만 결제를 승인할 수 있습니다.

생성된 주장(claims)은 파생된 투영(projections)입니다

생성된 텍스트가 병렬적인 진실 계층(parallel truth layer)이 되어서는 안 됩니다.

생성된 주장(claims)은