생성된 커머스 텍스트는 플랫폼이 해당 텍스트가 파생된 것이라는 사실을 망각할 때 안전하지 않게 됩니다.

제품 설명, 정책 요약, 비교 문단, 추천 설명, 결제 메시지 또는 결제 설명은 상업적 진실(commercial truth)이 아닙니다. 그것은 상업적 진실을 언어로 투영한 것입니다.

그 투영은 유용할 수 있습니다. 정확할 수 있습니다. 검토될 수 있습니다. 특정 용도로 승인될 수 있습니다.

하지만 그것은 여전히 파생된 것입니다.

그것은 소스 사실(source facts), 정책 사실(policy facts), 자격 결정(eligibility decisions), 결제 상태(checkout state), 결제 권한 결정(payment authority decisions), 구매자 컨텍스트(buyer context), 지역, 채널 및 시간에 의존합니다. 이러한 의존성이 변경되면, 생성된 텍스트는 에이전트 대응 워크플로(agent-facing workflow)에서 더 이상 표시, 인용, 게시 또는 사용하기에 안전하지 않을 수 있습니다.

문제는 환각(hallucination)만이 아닙니다.

생성된 문장은 생성될 당시에는 완전히 근거가 확실하더라도 나중에 안전하지 않게 될 수 있습니다. 가격이 변동됩니다. 재고가 오래된 정보가 됩니다. 정책 사실이 대체됩니다. 결제 차단 요소가 해결됩니다. 명령(mandate)이 만료됩니다. 지원되지 않는 지역이 됩니다. 반품 정책 적용이 취소된 후에도 생성된 반품 요약이 에이전트 피드에 남아 있을 수 있습니다.

이것은 시스템 문제입니다.

생성된 주장(claims)에는 의존성 관리(dependency management)가 필요합니다.

이 글은 Agent-Ready Commerce 시리즈의 여덟 번째 기사입니다.

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

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

파트 2는 상업적 진실(commercial truth)에 초점을 맞췄습니다. 카탈로그 데이터만으로는 충분하지 않다고 주장했습니다. 에이전트나 다른 시스템이 제품 정보에 안전하게 의존하기 전에, 플랫폼에는 소스에 의해 뒷받침되고 신선도(freshness)를 인지하는 제품 사실이 필요합니다.

파트 3는 실행 자격(action eligibility)에 초점을 맞췄습니다. "사용 가능(available)"이라는 표현은 너무 광범위하다고 주장했습니다. 제품은 발견은 가능하지만 결제 준비(checkout-ready)가 되지 않았을 수 있고, 비교는 가능하지만 정책 인용(policy-quotable)은 불가능할 수 있으며, 인간의 흐름(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)이 필요합니다.

이 글은 생성된 상업적 주장(generated commercial claims)에 초점을 맞춥니다.

핵심 논거는 생성된 텍스트를 자유롭게 떠도는 콘텐츠(free-floating content)로 취급해서는 안 된다는 것입니다. 생성된 텍스트는 의존성(dependencies), 범위(scope), 검토 상태(review status), 허용된 사용(allowed use), 무효화(invalidation), 만료(expiry) 및 감사(audit)를 갖춘 파생된 상업적 주장(derived commercial claim)으로 취급되어야 합니다.

안전한 플랫폼은 다음과 같은 체인을 따릅니다:

소스 사실 및 결정 (Source facts and decisions)
      ↓
생성된 주장 (Generated claim)
...

이 체인이 없다면, 생성된 텍스트는 제품의 진실(product truth), 정책 해석, 결제 설명 또는 결제 권한의 숨겨진 소스가 됩니다.

생성된 주장은 캐시된 투영(cached projection)입니다

생성된 커머스 텍스트를 생각하는 유용한 방법은 이를 캐시된 투영(cached projection)으로 보는 것입니다.

플랫폼은 소스에 기반한 사실과 결정을 가지고 있습니다:

제품 속성 (Product attributes)
가격 사실 (Price facts)
재고 사실 (Inventory facts)
...

생성된 주장은 이러한 사실이나 결정 중 일부를 언어로 변환합니다.

예를 들어:

이 배낭은 EU 내에서 배송될 수 있습니다.

이 문장은 다음 사항에 의존할 수 있습니다:

제품: BAG-TRAVEL-42
카테고리: 여행용 가방
배송 정책: EU 배송 가능 확인됨
...

해당 문장은 EU 배송에 대한 진실의 원천(Source of Truth)이 아닙니다. 이는 배송 정책이라는 사실(Fact)을 사람이 읽을 수 있는 언어로 투영(Projection)한 것입니다.

그 차이는 중요합니다.

만약 EU 배송 정책이 변경된다면, 생성된 문장은 무효화되거나 검토되어야 합니다. 구매자가 미국에 있다면 해당 문장은 사용되어서는 안 됩니다. 만약 해당 주장(Claim)이 스토어프런트(Storefront) 표시용으로는 승인되었지만 에이전트 견적용으로는 승인되지 않았다면, 에이전트는 이를 인용해서는 안 됩니다.

따라서 생성된 주장(Claims)은 다른 투영(Projections)들과 마찬가지로 동일한 규율이 필요합니다:

무엇이 이를 생성했는가?
무엇에 의존하는가?
어디에 적용되는가?
...

이것은 일반적인 의미의 콘텐츠 관리(Content Management)가 아닙니다. 이는 상업적 언어(Commercial Language)를 위한 의존성 관리(Dependency Management)입니다.

여행용 백팩(Travel Backpack) 예시

파트 2~7에서 진행된 예시를 이어갑니다:

제품: Travel Backpack
SKU: BAG-TRAVEL-42
가격: €129
...

현재 상업적 진실 계층(Commercial Truth Layer)은 다음과 같이 말합니다:

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

파트 3에서 액션 매트릭스(Action Matrix)는 다음과 같았습니다:

액션	결과
discover	허용됨
...

이제 몇 가지 생성된 주장(Claims)을 고려해 보겠습니다:

주장(Claim)	상태
“이 백팩은 재고가 있으며 즉시 배송 가능합니다.”	안전하지 않음: 재고가 오래되었으며(stale) 준비 상태가 확립되지 않음
...

이것들은 모두 유창한 문장들입니다. 어떤 것은 유용하고, 어떤 것은 안전하지 않으며, 어떤 것은 좁은 맥락에서만 안전합니다.

플랫폼은 “생성된 텍스트가 좋은가?”라고 물어서는 안 됩니다.

대신 다음과 같이 물어야 합니다:

어떤 주장이 제기되고 있는가?
어떤 사실이나 결정이 이를 뒷받침하는가?
어디에 적용되는가?
...

이것이 생성된 카피(Generated Copy)와 생성된 상업적 주장(Generated Commercial Claim)의 차이점입니다.

생성된 주장은 모두 동일하지 않습니다

생성된 색상 설명과 생성된 결제 설명은 동일한 규칙을 따르지 않아야 합니다.

도메인에 따라 리스크가 다르기 때문에 주장 유형(Claim type)이 중요합니다.

주장 유형 (Claim type)	예시 (Example)	주요 의존성 (Main dependency)
제품 설명 (Product description)	“노트북 파우치 포함.”	제품 속성 (Product attributes)
...

주장이 구매자의 신뢰, 정책 해석, 결제 행동(checkout behavior) 또는 결제 권한(payment authority)에 영향을 미칠 때 리스크가 증가합니다.

플랫폼은 리스크가 낮은 내부 초안(internal drafts)에 대해서는 가벼운 워크플로우(lightweight workflows)를 허용할 수 있습니다. 하지만 에이전트(agents)가 인용하거나, 피드(feeds)에 게시되거나, 정책 답변에 사용되거나, 결제 및 지불 단계 근처에서 사용되는 주장에는 더 강력한 통제(controls)가 필요합니다.

생성된 주장의 두 가지 출처

생성된 커머스 주장(commerce claims)은 보통 두 가지 서로 다른 출처에서 발생합니다.

첫 번째 유형은 사실 기반(fact-derived)입니다.

제품 사실 (Product facts)
정책 사실 (Policy facts)
카탈로그 속성 (Catalog attributes)
...

예시:

이 백팩의 가격은 €129입니다.
이 백팩은 보증 범위(warranty coverage)를 포함합니다.
이 백팩은 EU 내에서 배송될 수 있습니다.

두 번째 유형은 결정 기반(decision-derived)입니다.

자격 결정 (Eligibility decisions)
결제 결정 (Checkout decisions)
결제 권한 결정 (Payment authority decisions)
...

예시:

재고 재검증이 필요하므로 결제(Checkout)를 준비할 수 없습니다.
결제가 유효하지 않으므로 위임된 결제(Delegated payment)가 차단되었습니다.
여행용 가방(Travel Bags)에 적용되는 반품 정책 사실이 없으므로 반품 정책 인용이 차단되었습니다.

이러한 구분은 중요합니다. 왜냐하면 결정 기반(decision-derived) 주장은 가공되지 않은 사실(raw facts)만으로 생성되어서는 안 되기 때문입니다.

결제 설명(checkout explanation)은 결제 결정(checkout decision)으로부터 나와야 합니다.

결제 설명(payment explanation)은 결제 권한 결정(payment authority decision)으로부터 나와야 합니다.

정책 인용(policy quotation)은 인용 가능한 정책 사실(quoteable policy facts)로부터 나와야 합니다.

프로토콜 어댑터(protocol adapter)는 모델에게 로그(logs), 제품 필드(product fields) 또는 정책 페이지(policy pages)로부터 이러한 설명들을 추론하도록 요청해서는 안 됩니다. 대신 결과에 대해 이미 설명하고 있는 도메인 결정(domain decision)을 사용해야 합니다.

안전한 모델은 다음과 같습니다:

사실 기반 주장 (Fact-derived claim):
출처가 뒷받침된 사실(source-backed facts)로부터 생성됨.

...

주장의 출처는 해당 주장이 어떻게 검토(reviewed), 무효화(invalidated) 및 감사(audited)되어야 하는지를 결정합니다.

생성된 주장에는 구조가 필요합니다

생성된 주장은 단순히 문자열(string)로만 존재해서는 안 됩니다.

기록(record)이 필요합니다.

단순화된 TypeScript 모델은 다음과 같을 수 있습니다:

type GeneratedClaimKind =
  | "product_description"
  | "attribute_summary"
...

목표는 모든 문장을 과도하게 모델링하는 것이 아닙니다. 목표는 영향력이 큰 생성된 텍스트가 추적되지 않는 상업적 언어(commercial language)로서 시스템 외부로 유출되는 것을 방지하는 것입니다.

기록(record)은 중요한 질문들에 답합니다:

주장이 무엇을 말하는가?
어디에 적용되는가?
어떤 사실이나 결정이 이를 뒷받침하는가?
...

위험도가 높을 때는 절(clause) 단위로 증거를 결합해야 합니다

생성된 단락에는 여러 개의 상업적 주장(commercial claims)이 포함될 수 있습니다.

다음 문장을 고려해 보십시오:

이 백팩은 재고가 있으며, 유럽 전역으로 배송 가능하며, 30일 이내에 반품할 수 있습니다.

이 문장에는 최소 세 가지의 단언(assertions)이 포함되어 있습니다:

재고(Inventory):
in stock

...

Travel Backpack의 경우:

재고(Inventory):
stale

...

이 문장은 하나의 블록으로서 승인되어서는 안 됩니다.

한 절(clause)은 뒷받침될 수 있지만, 다른 절은 오래된 정보(stale)일 수 있고, 또 다른 절은 근거가 없을 수 있습니다.

위험도가 높은 생성된 주장은 다음과 같이 세분화될 수 있습니다:

type ClaimSupportStatus =
  | "supported"
  | "unsupported"
...

예시 문장에 대해 플랫폼은 다음과 같은 결과를 생성할 수 있습니다:

{
  "segments": [
    {
...

이를 통해 플랫폼은 안전한 단언과 안전하지 않은 단언이 섞인 문장을 그대로 승인하는 대신, 텍스트를 수정할 수 있습니다.

절(clause) 단위의 지원(support)은 정책 요약(policy summaries), 결제 단계 설명(checkout explanations), 결제 설명(payment explanations) 및 추천(recommendations)에 특히 유용합니다.

검토(Review)는 하나의 불리언(boolean) 값이 아닙니다

approved: true와 같은 검토 필드는 너무 취약합니다.

무엇에 대해 승인된 것입니까?

생성된 제품 설명(product description)은 내부 검토용으로는 승인되었지만, 스토어프런트(storefront) 전시용으로는 승인되지 않았을 수 있습니다.

생성된 정책 요약(policy summary)은 스토어프런트 전시용으로는 승인되었지만, 에이전트 견적(agent quotation)용으로는 승인되지 않았을 수 있습니다.

생성된 결제 단계 설명(checkout explanation)은 현재의 결정 기록(decision record)으로부터 도출되었을 때만 승인될 수 있습니다.

생성된 추천(recommendation)은 특정 구매자 기준(buyer criterion)에 대해서만 승인될 수 있습니다.

따라서 검토는 허용된 용도(allowed uses)를 생성해야 합니다.

type ClaimReviewDecision = {
  claimId: string;
  approvedUses: GeneratedClaimUse[];
...

여행용 배낭(Travel Backpack)의 경우:

생성된 주장(Generated claim):
이 배낭은 보증 범위(warranty coverage)를 포함하며 EU 내에서 배송될 수 있습니다.

...

이는 일반적인 승인 플래그(approval flag)보다 훨씬 안전합니다.

질문은 단순히 텍스트가 정확한지 여부만이 아닙니다. 핵심은 플랫폼이 해당 텍스트를 어디에 사용할 수 있도록 허용되는가입니다.

범위(Scope)는 의도치 않은 권한 남용을 방지합니다

생성된 언어는 종종 이를 뒷받침하는 사실(facts)보다 더 일반적인 것처럼 들립니다.

예를 들어:

이 배낭은 빠르게 배송됩니다.

이 문장은 너무 많은 것을 숨기고 있습니다.

EU 구매자에게 적용되나요?

미국 구매자에게 적용되나요?

기업 구매자에게 적용되나요?

마켓플레이스 주문에 적용되나요?

고객 지원(Support) 지원 주문에 적용되나요?

재고가 오래된(stale inventory) 제품에 적용되나요?

결제 준비(checkout preparation) 단계 이후에만 적용되나요?

더 안전한 주장은 범위(scope)가 지정되어 있습니다:

EU 소비자 주문의 경우, 이 배낭은 근거가 확인된(source-backed) 배송 범위를 가집니다.

범위는 주장 기록(claim record)에도 저장되어야 합니다:

const euShippingClaim: GeneratedClaim = {
  claimId: "claim_shipping_eu_001",
  kind: "policy_summary",
...

플랫폼이 별도의 적용 가능한 미국 배송 사실(US shipping fact)을 가지고 있지 않는 한, 미국 구매자에게 이 주장이 전달되어서는 안 됩니다.

파트 4에서 정책 사실(policy facts)에 대해 이 점을 언급했습니다. 생성된 주장(Generated claims) 또한 동일한 적용 가능성 규율(applicability discipline)을 상속받아야 합니다.

주장 상태(Claim status)가 실행 적격성(action eligibility)을 무시해서는 안 됩니다

승인된 생성된 주장이 특정 실행(action)을 적격하게 만드는 것은 아닙니다.

이는 중요한 실패 모드(failure mode)입니다.

생성된 제품 설명이 승인되었다고 가정해 봅시다:

이 배낭은 짧은 여행과 일상적인 여행을 위해 설계되었습니다.

그것이 해당 제품이 결제 준비(checkout-ready)가 되었다는 것을 의미하지는 않습니다.

EU 배송 요약이 승인되었다고 가정해 봅시다:

이 배낭은 EU 내에서 배송될 수 있습니다.

그것이 위임된 결제(delegated payment)를 진행할 수 있다는 것을 의미하지는 않습니다.

보증 성명(warranty statement)이 승인되었다고 가정해 봅시다:

이 배낭은 보증 범위(warranty coverage)를 포함합니다.

그것이 반품 정책(return-policy) 적용을 생성하는 것은 아닙니다.

생성된 주장 상태(Generated claim status)와 실행 적격성(action eligibility)은 별개입니다.

주장 승인 (Claim approval):
이 문장이 이 문맥에서 사용될 수 있습니까?

...

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

일부 생성된 주장(claims)은 승인될 수 있습니다.
결제 준비(Checkout preparation)는 여전히 차단된 상태입니다.
위임된 결제(Delegated payment)는 여전히 차단된 상태입니다.

플랫폼은 승인된 생성 텍스트로부터 실행 적격성(action readiness)을 결코 추론해서는 안 됩니다. 대신 적격성 계층(eligibility layer)을 사용해야 합니다.

생성된 정책 요약(Generated policy summaries)은 정책 권위(policy authority)가 아닙니다

생성된 정책 요약은 유용할 수 있습니다.

운영자가 보장 범위를 이해하는 데 도움을 줄 수 있습니다. 에이전트(agents)가 간결한 질문에 답변하는 데 도움을 줄 수 있습니다. 긴 정책 텍스트를 제시하기 더 쉽게 만들 수 있습니다.

하지만 이것은 정책 권위(policy authority)가 아닙니다.

권위는 적용 가능성(applicability), 증거(evidence), 생명 주기(lifecycle), 충돌(conflicts), 그리고 인용 가능성(quoteability)을 갖춘 구조화된 정책 사실(structured policy facts)에서 나옵니다.

예를 들어:

생성된 요약:
여행용 가방(Travel Bags)은 30일 이내에 반품할 수 있습니다.

만약 여행용 가방에 대해 활성화된 반품 정책 사실(return-policy fact)이 없다면, 해당 요약은 인용 가능(quoteable)해서는 안 됩니다.

안전한 흐름은 다음과 같습니다:

정책 소스 (Policy source)
      ↓
정책 사실 (Policy facts)
...

생성된 요약은 인용 가능성(quoteability)의 하류(downstream)에 위치합니다. 그것이 인용 가능성을 생성하는 것이 아닙니다.