제품 페이지는 계약이 아닙니다.

그것은 프레젠테이션 표면(presentation surface)입니다.

AI 에이전트가 커머스 시스템과 상호작용하기 시작하면 이 차이는 더욱 중요해집니다.

전통적인 이커머스(ecommerce) 플랫폼은 인간의 해석에 의존할 수 있습니다. 인간은 제품 제목을 읽고, 이미지를 검토하고, 배송 정보를 비교하고, 반품 정책을 훑어보고, 불확실성을 인지하며, 계속 진행할지 여부를 결정할 수 있습니다. 제품 페이지는 근본적인 상거래 상태(commercial state)가 불완전하거나, 오래되었거나, 여러 시스템에 분산되어 있는 경우에도 시각적으로 유용할 수 있습니다.

AI 에이전트는 다른 인터페이스가 필요합니다. 에이전트가 제품 페이지를 스크래핑(scrape)하거나, 자유 텍스트(free text)에서 정책의 의미를 추론하거나, 재고가 최신인지 추측하거나, 가격이 인용할 만큼 신뢰할 수 있는지 결정할 필요가 없어야 합니다. 만약 플랫폼이 에이전트가 제품을 추천하고, 대안을 비교하고, 결제를 준비하거나, 위임된 권한 내에서 행동하기를 기대한다면, 플랫폼은 제품 프레젠테이션 이상의 것을 노출해야 합니다.

상거래의 진실(commercial truth)을 노출해야 합니다.

이 글은 Agent-Ready Commerce 시리즈의 두 번째 기사입니다. 파트 1에서는 다음과 같은 더 넓은 모델을 소개했습니다:

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

이 기사는 그 체인의 첫 번째 부분인 **facts (사실)**에 초점을 맞춥니다.

핵심 논거는 간단합니다: 가공되지 않은 제품 기록(raw product record)만으로는 에이전트 준비 완료된 커머스에 충분하지 않습니다. 에이전트가 제품에 대해 안전하게 행동하기 전에, 플랫폼은 소스 기반(source-backed)이며 최신성을 인지(freshness-aware)하고 행동을 지원하는 제품 뷰(view)를 제공해야 합니다.

제품 페이지는 너무 많은 상태(state)를 숨깁니다

일반적인 제품 페이지는 여러 가지 서로 다른 관심사를 하나의 인간이 읽을 수 있는 표면으로 압축합니다:

Product identity (제품 식별 정보)
Price (가격)
Inventory (재고)
...

이러한 압축은 프레젠테이션에는 유용하지만, 시스템 관점에서는 정보 손실(lossy)이 발생합니다.

페이지에는 “재고 있음”이라고 표시될 수 있지만, 재고 값은 몇 시간 전의 데이터일 수 있습니다. 가격이 표시될 수 있지만, 가격 소스(pricing source)는 마지막 피드 발행 이후 변경되었을 수 있습니다. 반품 정책 문구가 표시될 수 있지만, 해당 정책이 모든 카테고리, 지역 또는 고객 유형에 적용되지 않을 수도 있습니다. 사람이 읽도록 승인된 마케팅 주장(marketing claims)이 표시될 수 있지만, 에이전트(agent)가 인용하기에는 충분히 정밀하지 않을 수 있습니다.

사람은 이러한 모호함을 어느 정도 견딜 수 있습니다. 하지만 에이전트에게 이를 강요해서는 안 됩니다.

제품 페이지는 프레젠테이션(presentation) 질문에 답합니다:

이 아이템을 구매자에게 어떻게 보여줘야 하는가?

에이전트 대응 제품 계약(agent-facing product contract)은 운영(operational) 질문에 답해야 합니다:

이 아이템에 대해 현재 알려진 정보는 무엇인가?
그 정보는 어디에서 왔는가?
정보가 얼마나 최신(fresh)인가?
...

이것들은 서로 다른 질문입니다. 제품 페이지를 신뢰할 수 있는 단일 원천(source of truth)으로 취급하는 것은 이 질문들을 뒤섞어 버립니다.

실행 예시

카탈로그에 있는 제품을 가정해 보겠습니다:

Product: Travel Backpack
SKU: BAG-TRAVEL-42
Price: €129
...

단순한 스토어프런트(storefront)는 이 제품을 렌더링할 수 있습니다. 제목, 가격, 이미지, 카테고리, 그리고 재고 플래그(inventory flag)를 가지고 있습니다.

기본적인 제품 모델은 다음과 같을 수 있습니다:

type Product = {
  id: string;
  sku: string;
...

이것은 제품 카드(product card)를 표시하기에는 충분합니다.

하지만 AI 에이전트가 해당 제품에 대해 안전하게 행동할 수 있는지 결정하기에는 충분하지 않습니다.

실제 플랫폼 상태가 다음과 같다고 가정해 봅시다:

Price: 최신(fresh), 5분 전 확인됨
Inventory: 오래된(stale), 18시간 전 마지막 동기화됨
Return policy: Travel Bags 카테고리에 대한 정보 누락
...

사람 대상의 스토어프런트는 여전히 제품을 보여줄 수 있습니다. 그러나 커머셜 시스템(commercial system)에는 해결되지 않은 몇 가지 질문이 남아 있습니다.

에이전트가 이 제품을 발견할 수 있는가? 아마도 그렇습니다.

에이전트가 이 제품을 다른 백팩과 비교할 수 있는가? 비교에 정체성(identity), 가격, 카테고리 및 기본 속성만 필요하다면 아마도 가능할 것입니다.

에이전트가 반품 정책을 인용할 수 있는가? 아니요, 해당 카테고리에 대한 반품 정책 범위(coverage)가 누락되었기 때문입니다.

에이전트가 결제(checkout)를 준비할 수 있는가? 아니요, 재고 정보가 오래되었기(stale) 때문입니다.

에이전트가 위임된 결제(delegated payment)를 실행할 수 있는가? 절대 아닙니다. 결제(checkout) 자체가 아직 유효하지 않기 때문입니다.

active: true와 같은 단일 필드로는 이러한 차이점들을 표현할 수 없습니다.

이것이 바로 커머셜 트루스(commercial truth, 상거래 진실)가 메워야 할 간극입니다.

제품 데이터는 커머셜 트루스가 아닙니다

제품 데이터(Product data)는 아이템이 무엇인지 설명합니다.

커머셜 트루스(Commercial truth)는 플랫폼이 해당 아이템에 대해 현재 무엇을 신뢰할 용의가 있는지를 설명합니다.

이 둘은 서로 관련되어 있지만, 동일하지는 않습니다.

카탈로그 레코드(catalog record)는 다음과 같이 말할 수 있습니다:

const product = {
  id: "bag_travel_42",
  title: "Travel Backpack",
...

커머셜 트루스 요약(commercial truth summary)은 다음과 같이 말할 수 있습니다:

type ProductTruthSummary = {
  productId: string;
  truthVersion: string;
...

백팩 예시의 경우, 트루스 요약은 다음과 같은 형태일 수 있습니다:

const truth: ProductTruthSummary = {
  productId: "bag_travel_42",
  truthVersion: "truth_2025_10_18_001",
...

커머셜 트루스 객체는 제품을 대체하는 것이 아니라, 제품에 대한 자격을 부여(qualify)합니다.

제품은 해당 아이템이 무엇인지를 말합니다.

트루스 요약은 해당 아이템을 상거래 워크플로(commerce workflows)에서 사용하는 데 필요한 사실들에 대해 플랫폼이 어느 정도의 확신(confidence)을 가지고 있는지를 말합니다.

소스 참조(Source references)는 모델의 일부입니다

소스 참조(Source references)는 메타데이터 장식이 아닙니다. 그것은 신뢰성 모델(reliability model)의 일부입니다.

가격 책정 서비스(pricing service)의 가격, 창고 동기화(warehouse sync)에서 가져온 재고 값, 정책 문서(policy document)의 보증 문구, 그리고 AI 워크플로(AI workflow)에 의해 생성된 설명은 모두 동일하게 권위 있는 것으로 취급되어서는 안 됩니다.

소스 참조는 다음과 같이 간단하게 모델링될 수 있습니다:

type SourceReference = {
  sourceId: string;
  sourceType: 
...

중요한 점은 커머셜 사실(commercial facts)이 추적 가능(traceable)해야 한다는 것입니다.

소스 참조가 없다면, 플랫폼은 다음과 같은 기본적인 운영 질문에 쉽게 답할 수 없습니다:

이 가격은 어디에서 왔는가?
이 재고 값은 동기화된 것인가, 아니면 수동으로 편집된 것인가?
이 정책 주장(policy claim)은 승인된 것인가, 아니면 생성된 것인가?
...

사람을 대상으로 하는 커머스(human-facing commerce)에서 추적 가능성이 결여되면 디버깅의 고통을 초래할 수 있습니다. 에이전트를 대상으로 하는 커머스(agent-facing commerce)에서는 신뢰 문제 또한 발생시킵니다.

만약 에이전트가 오래된 재고(stale inventory)를 바탕으로 반품 정책을 인용하거나 결제(checkout)를 준비한다면, 플랫폼은 어떤 사실(fact)이 해당 결정으로 이어졌는지, 그리고 그 사실을 생성한 출처(source)가 무엇인지 알아야 합니다.

이것이 바로 상업적 진실(commercial truth)이 처음부터 증거 인식(evidence-aware) 기반이어야 하는 이유입니다.

신선도(Freshness)는 사실 그룹(fact group)별로 모델링되어야 합니다

신선도는 종종 너무 광범위하게 모델링됩니다.

제품이 신선함(fresh) 또는 오래됨(stale)으로 표시되는 식입니다.

이는 충분히 정밀하지 않습니다.

서로 다른 사실들은 서로 다른 리스크 프로필(risk profiles)을 가집니다. 오래된 재고는 오래된 제품 이미지보다 더 위험합니다. 오래된 가격은 결제(checkout)를 막을 수는 있지만, 탐색(discovery)을 막지는 않습니다. 누락된 보증 정보는 정책 인용(policy quotation)은 막을 수 있지만, 제품 비교(product comparison)를 막지는 않습니다. 검토 대기 중인 생성된 설명은 에이전트의 인용(agent quotation)은 막을 수 있지만, 내부 머천다이징(internal merchandising)을 막지는 않습니다.

더 나은 모델은 사실 그룹(fact group)별로 신선도를 추적합니다:

type ProductTruthFreshness = {
  identity: "fresh" | "stale" | "unknown";
  price: "fresh" | "stale" | "unknown";
...

백팩 예시의 경우:

const freshness: ProductTruthFreshness = {
  identity: "fresh",
  price: "fresh",
...

이를 통해 플랫폼은 더 유용한 결정을 내릴 수 있습니다:

Discovery: allowed
Comparison: allowed
Policy quotation: blocked
...

단일한 productIsFresh 값은 그 이유를 숨기게 됩니다. 사실 수준(fact-level)의 신선도는 플랫폼이 제품을 완전히 사용 가능하거나 완전히 사용 불가능한 것으로 취급하는 대신, 우아하게 성능을 저하시키는(degrade gracefully) 방법을 제공합니다.

진실(Truth)이 모든 것을 결정해서는 안 됩니다

상업적 진실 계층(commercial truth layer)은 알려진 내용이 무엇인지를 기술해야 합니다. 모든 비즈니스 결정에 책임을 져서는 안 됩니다.

이 경계는 중요합니다.

상업적 진실은 다음을 답변합니다:

어떤 사실들이 존재하는가?
그 사실들은 어디에서 왔는가?
그것들은 얼마나 신선한가?
...

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

해당 사실들을 고려할 때, 어떤 행동이 허용되는가?

이 두 계층은 분리된 상태로 유지되어야 합니다.

예를 들어:

type TruthReadiness = {
  productId: string;
  facts: {
...

진실 계층은 에이전트가 무엇을 할 수 있는지 결정하지 않고도 해당 결과를 생성할 수 있습니다.

자격 계층(eligibility layer)은 다음과 같이 작업별 규칙(action-specific rules)을 적용할 수 있습니다.

type AgentCommerceAction =
  | "discover"
  | "compare"
...

단순화된 자격 평가 함수(eligibility function)는 다음과 같은 형태일 수 있습니다.

function evaluateCheckoutReadiness(truth: TruthReadiness): EligibilityDecision {
  const blockers: string[] = [];

...

이러한 분리는 진실 계층(truth layer)이 숨겨진 모놀리스(monolith)가 되는 것을 방지합니다.

만약 기업이 나중에 "오래된 재고(stale inventory)의 경우 장바구니 담기는 허용하되 결제(checkout)는 차단해야 한다"라고 결정한다면, 해당 변경 사항은 재고 진실(inventory truth)의 정의가 아니라 자격 규칙(eligibility rules)에 포함되어야 합니다.

유용한 경계는 다음과 같습니다.

Truth(진실)는 상거래 사실(commercial facts)을 설명합니다.
Eligibility(자격)는 해당 사실들이 무엇을 허용할지 결정합니다.

작업 임계값(Action thresholds)은 달라야 합니다

모든 작업이 동일한 품질의 진실을 요구하는 것은 아닙니다.

탐색(Discovery)은 신원(identity), 가시성(visibility), 미디어(media), 그리고 기본적인 카테고리 정보만을 필요로 할 수 있습니다. 비교(Comparison)는 가격과 비교 가능한 속성(comparable attributes)을 필요로 할 수 있습니다. 정책 인용(Policy quotation)은 정책 보장 범위(policy coverage)와 출처 참조(source references)를 필요로 합니다. 결제 준비(Checkout preparation)는 최신 가격, 최신 재고, 그리고 적용 가능한 정책을 필요로 합니다. 위임된 결제(Delegated payment)는 훨씬 더 많은 것, 즉 결제 유효성(checkout validity), 장바구니 무결성(cart integrity), 결제 권한(payment authority), 그리고 어쩌면 인간의 확인(human confirmation)까지 필요로 합니다.

따라서 동일한 제품이라도 작업에 따라 서로 다른 준비 수준(readiness levels)을 가질 수 있습니다.

type ActionTruthRequirement = {
  action: AgentCommerceAction;
  requiredFacts: Array<
...

요구 사항 예시:

const requirements: ActionTruthRequirement[] = [
  {
    action: "discover",
...

백팩 예시의 경우, 결과 행렬(matrix)은 다음과 같을 수 있습니다.

discover          allowed
compare           allowed
quote_policy      blocked: return policy missing
...

이는 제품을 단순히 사용 가능 또는 사용 불가능으로 표시하는 것보다 더 유용합니다.

에이전트 대응 시스템(Agent-facing systems)은 어떤 종류의 작업이 안전한지 알아야 합니다. 운영자는 어떤 누락된 사실이 어떤 상거래 기능(commercial capabilities)을 차단하는지 알아야 합니다.

파생된 사실(Derived facts)에는 출처(provenance)가 필요합니다

일부 제품 사실(product facts)은 직접적인 값입니다. 다른 것들은 파생된(derived) 것입니다.

직접적인 사실(Direct fact):

가격은 €129입니다.

파생된 사실(Derived fact):

제품이 에이전트에게 노출됩니다.

두 번째 문장은 규칙(rules)에 의존합니다. 이는 카탈로그 상태, 제품 카테고리, 판매자 설정, 정책 완결성, 피드 게시 상태, 생성된 클레임 검토(generated claim review), 그리고 지역적 제한 사항에 따라 달라질 수 있습니다.

파생된 사실에는 출처(provenance)가 포함되어야 합니다.

type DerivedFact<T> = {
  value: T;
  derivedFrom: string[];
...

예를 들어:

type AgentVisibilityFact = DerivedFact<{
  visible: boolean;
  reason?: string;
...

파생된 가시성 사실(visibility fact)은 다음과 같을 수 있습니다:

const visibility: AgentVisibilityFact = {
  value: {
    visible: true
...

이렇게 하면 의사결정 과정을 디버깅하기가 더 쉬워집니다.

만약 제품이 에이전트 피드에서 사라진다면, 플랫폼은 라우트 핸들러(route handlers), 프론트엔드 로직(frontend logic), 피드 작업(feed jobs), 프로토콜 어댑터(protocol adapters)를 일일이 뒤지는 대신, 규칙 버전과 입력 사실(input facts)을 조사할 수 있습니다.

출처가 없는 파생된 사실은 또 다른 형태의 숨겨진 상태(hidden state)가 됩니다.

진실 버전(Truth versions)과 해시(hashes)는 변경 감지를 지원합니다

에이전트 대상 시스템은 상거래의 진실(commercial truth)이 언제 변하는지 알아야 합니다.

제품이 어제 피드에 게시되었을 수 있습니다. 그 이후로 가격이 변했을 수도 있고, 재고가 오래되었을 수도 있으며, 정책 소스(policy source)가 업데이트되었을 수도 있습니다.

진실 버전(Truth version)은 플랫폼에 안정적인 참조 지점을 제공합니다:

type TruthVersion = {
  productId: string;
  version: string;
...

해시(Hashes)는 특정 범위(scopes) 내의 변경을 감지하는 데 도움이 될 수 있습니다:

type TruthHash = {
  productId: string;
  scope: "identity" | "price" | "inventory" | "policy" | "media" | "full";
...

해시는 도메인 로직(domain logic)을 대체하는 것이 아닙니다. 해시는 단지 무언가가 변했다는 사실만을 알려줍니다.

그 변화가 중요한지 여부는 여전히 도메인에서 결정해야 합니다.

type TruthChangeSummary = {
  productId: string;
  changedScopes: Array<"identity" | "price" | "inventory" | "policy" | "media">;
...

예를 들어:

Price hash changed:

• requires feed republish
• requires checkout revalidation for open sessions
  ...

해시(Hash)는 변경 사항을 감지합니다. 도메인(Domain)은 그 영향을 결정합니다.

이러한 분리가 중요한 이유는 모든 변경 사항이 동일하지 않기 때문입니다.

에이전트 대응 피드(Agent-facing feeds)는 선택된 진실(Selected truth)을 게시해야 합니다

에이전트를 위한 제품 피드(Product feed)는 카탈로그(Catalog)의 가공되지 않은(Raw) 내보내기 형태여서는 안 됩니다.

선택된 상업적 진실(Commercial truth)을 게시해야 합니다.

피드 항목(Feed item)은 다음과 같은 형태일 수 있습니다:

type AgentProductFeedItem = {
  id: string;
  title: string;
...

이 구조는 모든 내부 필드(Internal field)를 노출하지 않습니다. 대신 외부 소비(External consumption)에 안전하고 유용한 상업적 진실의 부분들만을 노출합니다.

이러한 구분이 아키텍처를 더 깔끔하게 유지해 줍니다:

Catalog는 제품 데이터(Product data)를 저장합니다.
Commercial truth는 제품 데이터를 검증(Qualifies)합니다.
Feed publication은 선택된 진실(Selected truth)을 노출합니다.
...