에이전트 준비 완료 커머스(Agent-Ready Commerce), 파트 4: 정책을 기계가 읽을 수 있게 만들기

에이전트 준비 완료 커머스(Agent-Ready Commerce)에서 어려운 정책 문제는 플랫폼에 반품 정책 페이지가 있는지 여부가 아닙니다.

진짜 어려운 문제는 플랫폼이 다음 질문에 안전하게 답할 수 있는지 여부입니다:

에이전트가 이 지역의 이 구매자에게, 이 채널을 통해, 이 제품에 대해, 이러한 조건 하에 이 품목을 반품할 수 있다고 말할 수 있는가?

그것은 전혀 다른 문제입니다.

공개된 정책 페이지가 존재할 수도 있습니다. 제품 페이지가 그 페이지로 링크를 걸 수도 있습니다. 지원 팀이 예외 사항을 이해하고 있을 수도 있습니다. 인간 구매자는 페이지를 읽고 합리적인 해석을 내릴 수 있을지도 모릅니다. 하지만 그 어떤 것도 AI 에이전트가 해당 페이지를 권위 있는 결정 소스(authoritative decision source)로 취급해야 함을 의미하지는 않습니다.

에이전트 대응 시스템(agent-facing systems)을 위해서는, 정책이 인간이 해석하는 텍스트에서 시스템이 평가할 수 있는 구조화된 상업적 사실(structured commercial facts)로 이동해야 합니다. 어려운 점은 단순히 정책을 데이터베이스에 저장하는 것이 아닙니다. 진짜 어려운 점은 적용 가능성(applicability), 증거(evidence), 최신성(freshness), 충돌(conflicts), 우선순위(precedence), 그리고 인용 가능성(quoteability)을 모델링하는 것입니다.

정책이 단순히 JSON으로 변환되었다고 해서 기계가 읽을 수 있는(machine-readable) 것은 아닙니다. 플랫폼이 다음 질문에 답할 수 있을 때 정책은 기계가 사용 가능한(machine-usable) 상태가 됩니다:

어떤 주장(claim)이 이루어지고 있는가?
어디에 적용되는가?
어떤 소스가 이를 뒷받침하는가?
...

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

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

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

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

파트 3는 실행 자격(action eligibility)에 초점을 맞췄습니다. "사용 가능(available)"이라는 표현은 너무 광범위하다고 주장했습니다. 제품이 검색은 가능하지만 결제 준비(checkout-ready)가 되지 않았을 수 있고, 비교는 가능하지만 정책 인용(policy-quotable)은 불가능할 수 있으며, 인간의 흐름에는 결제 준비가 되어 있지만 위임된 결제(delegated payment)에는 적합하지 않을 수 있습니다.

이 기사는 정책 구조(policy structure)에 초점을 맞춥니다.

핵심 논거는 에이전트 준비 완료 커머스(agent-ready commerce) 플랫폼이 에이전트에게 자유 형식의 텍스트(free-text) 정책 페이지를 마치 실행 가능한 규칙(executable rules)인 것처럼 해석하도록 요구해서는 안 된다는 것입니다. 반품(Returns), 배송(shipping), 보증(warranty), 취소(cancellation), 지역적 제한(regional restrictions), 그리고 기업 구매자 규칙(business-buyer rules)은 명시적인 범위(scope)와 근거(evidence)를 가진 정책 사실(policy facts)로 모델링되어야 합니다. 이러한 사실들은 이후 적격성 결정(eligibility decisions)의 입력값으로 사용됩니다.

정책 페이지는 의사결정 경계가 아닌 커뮤니케이션 수단입니다

정책 페이지는 대개 인간 독자에게 약관을 전달하기 위해 작성됩니다. 이는 종종 일반적인 규칙, 예외 사항, 법률 용어, 고객 지원 안내, 카테고리별 참고 사항, 지역적 차이, 그리고 운영상의 제약 사항을 하나의 문서에 결합합니다.

이는 사람에게는 유용합니다. 하지만 에이전트에게는 안정적인 의사결정 경계(decision boundary)가 아닙니다.

다음과 같이 명시된 반품 정책 페이지를 예로 들어보겠습니다:

대부분의 제품은 미사용 상태이며 원래 포장 상태로 반품될 경우 배송 후 30일 이내에 반품할 수 있습니다. 일부 카테고리, 재고 정리 상품(clearance items), 맞춤형 제품(customized products), 기업 주문(business orders), 그리고 국제 배송 건은 다른 약관이 적용될 수 있습니다.

사람은 이를 읽고 세부 사항이 달라질 수 있음을 이해할 수 있습니다. 하지만 에이전트는 추가적인 구조(structure) 없이는 해당 단락을 제품 수준의 정밀한 주장(claim)으로 안전하게 변환할 수 없습니다.

해당 단락은 다음 질문에 답하지 않습니다:

이것이 여행용 가방(Travel Bags)에 적용됩니까?
이것이 SKU BAG-TRAVEL-42에 적용됩니까?
이것이 EU 구매자에게 적용됩니까?
...

만약 플랫폼이 이러한 질문에 답하지 않는다면, 에이전트는 이를 추론(infer)해야 합니다. 이는 정책 해석(policy interpretation)을 잘못된 계층(layer)으로 이동시키는 결과를 초래합니다.

상업적 권한(commercial authority)은 플랫폼에 있습니다. 에이전트가 정책 엔진(policy engine)이 되어서는 안 됩니다.

유용한 단위는 정책 주장(policy claim)입니다

더 나은 시작점은 정책을 일련의 주장(claims) 세트로 취급하는 것입니다.

정책 주장(policy claim)이란 특정 조건 하에서 플랫폼이 신뢰할 수 있는 진술을 의미합니다.

예를 들어:

스토어프론트(storefront) 또는 에이전트 채널을 통해 EU 소비자 구매자에게 판매된 여행용 가방(Travel Bags)은 미사용 상태이고 원래 포장 상태인 경우 30일 이내에 반품될 수 있습니다.

이는 다음과 같은 방식보다 훨씬 더 유용합니다:

반품 정책: 30일

두 번째 버전은 구조화된 것처럼 보이지만, 범위(scope)가 충분히 설정되지 않았습니다. 카테고리(category), 지역(region), 구매자 유형(buyer type), 채널(channel), 조건(conditions) 및 출처(source)가 누락되어 있습니다.

정책 클레임(policy claim)에는 최소 6가지 차원(dimension)이 필요합니다:

도메인 (Domain):        반품 (returns), 배송 (shipping), 보증 (warranty), 취소 (cancellation), 제한 (restriction)
적용 범위 (Applicability): 제품 (product), 카테고리 (category), 지역 (region), 구매자 유형 (buyer type), 채널 (channel)
값 (Value):         실제 규칙 또는 약관
...

일부 시스템에서는 정책이 중복되는 경우가 흔하기 때문에, 우선순위(precedence)를 일곱 번째 차원으로 추가해야 합니다.

이러한 클레임 기반 모델(claim-based model)이 정책 페이지(policy page)와 기계가 읽을 수 있는 정책(machine-readable policy) 사이의 주요 차이점입니다.

페이지는 무언가를 말합니다.

정책 클레임은 특정 범위(scope) 내에서, 근거(evidence)를 가지고, 생애주기 제어(lifecycle control) 하에, 정의된 허용 용도(allowed use)와 함께 무언가를 말합니다.

여행용 백팩 예시

파트 2와 파트 3에서 진행 중인 예시를 이어가겠습니다:

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

현재 커머셜 트루스 레이어(commercial truth layer)는 다음과 같이 말하고 있습니다:

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

이것은 유용한 예시인데, 제품이 명백하게 고장 난 상태는 아니기 때문입니다. 일반적인 스토어프런트(storefront)는 여전히 이를 렌더링할 수 있습니다. 제품에는 이름, SKU, 가격, 카테고리 및 재고 상태가 있습니다. 사람은 페이지를 볼 수 있습니다.

문제는 플랫폼이 에이전트(agent)의 동작을 지원해야 할 때 발생합니다.

에이전트는 다음과 같이 물을 수 있습니다:

이 제품을 구매자에게 보여줘도 될까?
이 제품을 유사한 백팩과 비교할 수 있을까?
구매자에게 반품 조건을 알려줄 수 있을까?
...

답변은 모두 다릅니다.

제품은 발견될 수 있습니다. 알려진 제품 사실(product facts)을 바탕으로 아마도 비교가 가능할 것입니다. EU 배송 사실(EU shipping fact)이 활성화되어 있고 출처가 뒷받침된다면 EU 배송비를 견적 낼 수 있을 것입니다. 보증 사실(warranty fact)이 알려져 있고 승인되었다면 보증 내용을 견적 낼 수 있을 것입니다.

하지만 반품 정책 인용(return-policy quotation)은 차단되어야 합니다. 왜냐하면 여행용 가방(Travel Bags) 카테고리에 대한 반품 정책이 누락되었기 때문입니다. 미국 배송(US shipping) 견적 또한 미국 배송 정책을 알 수 없으므로 차단되어야 합니다.

결제 준비 단계 이전에 완전한 반품 및 배송 정책 적용이 요구된다면 결제(Checkout)가 차단될 수 있습니다. 위임 결제(Delegated payment)는 결제가 유효하지 않고 결제 권한(Payment authority)은 별개의 문제이기 때문에 차단됩니다.

이것이 바로 정책 구조(Policy structure)가 중요한 이유입니다. 제품은 단순히 "사용 가능"하거나 "사용 불가능"한 것이 아닙니다. 서로 다른 정책 사실(Policy facts)이 서로 다른 행동을 뒷받침합니다.

정책 텍스트(Policy text)와 정책 사실(Policy facts)은 서로 다른 산출물입니다

커머스 플랫폼에는 여전히 공개적인 정책 페이지가 필요할 수 있습니다. 구매자에게는 읽을 수 있는 설명이 필요합니다. 지원 팀(Support teams)에는 링크가 필요합니다. 법무 및 운영 팀은 검토된 문구를 요구할 수 있습니다. 정책 텍스트는 사라지지 않습니다.

설계상의 문제는 동일한 텍스트가 시스템의 운영 정책 모델(Operational policy model)로도 취급되는지 여부입니다.

에이전트 준비 완료(Agent-ready) 플랫폼에서는 산출물을 분리하는 것이 더 안전합니다:

Policy text:
인간이 읽을 수 있는 약관 설명.

...

이러한 산출물들은 서로 연결될 수 있지만, 혼동해서는 안 됩니다.

반품 정책 페이지에는 다음과 같은 문장이 포함될 수 있습니다:

Eligible Travel Bags may be returned within 30 days if unused and returned in original packaging.
(대상 여행용 가방은 사용하지 않고 원래 포장 상태로 반품할 경우 30일 이내에 반품할 수 있습니다.)

이에 대응하는 정책 사실(Policy fact)은 다음과 같이 표현될 수 있습니다:

type PolicyDomain =
  | "returns"
  | "shipping"
...

중요한 점은 정확한 TypeScript 형태가 아닙니다. 중요한 점은 해당 사실(Fact)이 의사결정에 필요한 차원(Dimensions)을 포함하고 있다는 것입니다.

사실(Fact)은 단순히 "30일"이라고만 말하지 않습니다. 그 주장이 어디에 적용되는지, 어떤 출처가 이를 뒷받침하는지, 해당 사실이 활성화되어 있는지, 그리고 에이전트가 이를 인용할 수 있는지 여부를 말해줍니다.

정책 값(Policy values)은 도메인별로 타입이 지정되어야 합니다

일반적인 value: string 필드만으로는 대개 충분하지 않습니다.

서로 다른 정책 도메인(Policy domains)은 서로 다른 구조를 필요로 합니다. 반품 정책은 배송 정책과 같은 형태가 아닙니다. 보증 정책(Warranty policy)은 지역 제한(Regional restriction)과 같은 형태가 아닙니다. 취소 규칙(Cancellation rule)은 비즈니스-구매자 규칙(Business-buyer rule)과 같은 형태가 아닙니다.

단순화된 정책 값 모델(Policy value model)은 다음과 같을 수 있습니다:

type PolicyValue =
  | ReturnPolicyValue
  | ShippingPolicyValue
...

이러한 구조는 흔히 발생하는 실패 모드, 즉 모든 정책을 짧은 자연어 요약(natural-language summary)으로 축소한 뒤 에이전트에게 이를 다시 해석하도록 요청하는 문제를 방지합니다.

반품 기간(return window)이 중요하다면 반품 기간을 모델링하세요. 취소가 주문 상태(order state)에 따라 달라진다면 허용된 상태들을 모델링하세요. 배송이 지역(region)에 따라 달라진다면 지원되는 지역들을 모델링하세요. 기업 구매자(business buyers)에게 다른 규칙이 적용된다면 그 차이를 직접적으로 표현하세요.

목표는 텍스트를 없애는 것이 아닙니다. 목표는 시스템의 결정이 런타임(runtime) 시의 비정형 텍스트 해석(unstructured text interpretation)에 의존하지 않도록 만드는 것입니다.

적용 가능성(Applicability)은 많은 정책 모델이 실패하는 지점입니다

정책 모델링에서 가장 어려운 부분은 종종 값이 아니라 범위(scope)입니다.

플랫폼은 30일 반품 정책이 존재한다는 사실을 알고 있을 수 있습니다. 하지만 그렇다고 해서 그 정책이 'Travel Backpack'에 적용된다는 것을 의미하지는 않습니다.

정책은 다음과 같이 범위를 지정할 수 있습니다:

Product (제품)
SKU
Category (카테고리)
...

정확한 세트는 비즈니스에 따라 달라집니다. 단순한 플랫폼은 카테고리, 지역, 구매자 유형(buyer type), 채널(channel)만 필요할 수도 있습니다. 마켓플레이스나 글로벌 커머스 시스템은 더 많은 정보가 필요할 수 있습니다.

위험 요소는 플랫폼에 정책 텍스트가 부족한 것이 아닙니다. 위험 요소는 플랫폼이 올바른 정책을 잘못된 컨텍스트(context)에 적용하는 것입니다.

'Travel Backpack'의 경우, 유용한 반품 정책 사실(return-policy fact)은 다음과 같은 질문에 답할 수 있어야 합니다:

이 반품 규칙이 'Travel Bags' 카테고리에 적용되는가?
이 규칙이 SKU 'BAG-TRAVEL-42'에 적용되는가?
이 규칙이 EU 구매자에게 적용되는가?
...

만약 플랫폼이 이러한 질문에 답할 수 없다면, 해당 사실이 존재하더라도 사용할 수 없는 상태가 됩니다.

이것이 바로 "정책이 존재함"과 "이 작업에 대해 정책 커버리지(policy coverage)가 존재함"을 서로 다른 상태로 취급해야 하는 이유입니다.

커버리지(Coverage)는 권한(permission)과 같지 않습니다

정책 사실(policy fact)이 누락되었다고 해서 정책 결과가 자동으로 부정적(negative)임을 의미해서는 안 됩니다.

'Travel Bags'에 대한 반품 정책이 누락되었다고 해서 반드시 'Travel Bags'를 반품할 수 없다는 뜻은 아닙니다. 이는 플랫폼이 현재 해당 컨텍스트에 대한 반품 정책 주장을 뒷받침할 수 있는, 소스 기반의 정책 사실(source-backed policy fact)을 보유하고 있지 않음을 의미할 뿐입니다.

이러한 구분은 에이전트 대응 시스템(agent-facing systems)이 '알 수 없음(unknown)'을 '거짓(false)'으로 변환하는 것을 피해야 하기 때문에 중요합니다.

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

Travel Bags에 대한 반품 정책 누락 (Return policy missing for Travel Bags)

은 다음을 의미하지 않습니다:

이 제품은 반품이 불가능합니다. (This product is not returnable.)

그것은 다음을 의미합니다:

플랫폼이 현재 이 제품/카테고리 컨텍스트에 대한 반품 조건을 인용할 수 없습니다. (The platform cannot currently quote return terms for this product/category context.)

마찬가지로:

미국 배송 정책 알 수 없음 (US shipping policy unknown)

은 반드시 다음을 의미하는 것은 아닙니다:

이 제품은 미국으로 배송할 수 없습니다. (This product cannot ship to the US.)

그것은 다음을 의미합니다:

플랫폼이 추가적인 검증 없이 현재 미국 배송 조건을 인용하거나 미국 결제(checkout)를 준비할 수 없습니다. (The platform cannot currently quote US shipping terms or prepare US checkout without additional validation.)

유용한 정책 커버리지(policy coverage) 모델은 다음과 같이 상태를 구분할 수 있습니다:

type PolicyCoverageStatus =
  | "known" (알려짐)
  | "missing" (누락됨)
...

이를 통해 적격성(eligibility) 결정이 정밀해질 수 있습니다.

'알려진(Known)' 정책 커버리지는 인용(quotation)이나 결제(checkout)를 허용할 수 있습니다. '누락된(Missing)' 커버리지는 인용을 차단할 수 있습니다. '충돌하는(Conflicting)' 커버리지는 운영자 작업(operator task)을 생성할 수 있습니다. '해당 없음(Not applicable)'은 플랫폼이 특정 도메인이 적용되지 않는다는 명시적인 증거를 가지고 있다면 유효할 수 있습니다.

'알 수 없음(Unknown)'만으로는 부족합니다. '알 수 없는' 이유가 중요합니다.

증거는 나중에 재구성하는 것이 아니라 주장(claim)에 부착되어야 합니다

에이전트 대응 주장(agent-facing claims)은 추적 가능해야 하므로, 정책 사실(policy facts)에는 증거가 필요합니다.

만약 에이전트가 다음과 같이 말한다면:

이 제품은 24개월 보증 기간을 가집니다. (This product has a 24-month warranty.)

플랫폼은 어떤 소스(source)가 해당 진술을 뒷받침했는지 설명할 수 있어야 합니다.

증거는 다양한 소스에서 올 수 있습니다:

공개 정책 페이지 (Public policy page)
법적 문서 (Legal document)
관리자 입력 항목 (Admin entry)
...

증거 참조(evidence reference)는 사후에 고려되는 사항이 되어서는 안 됩니다. 그것은 정책 사실의 일부여야 합니다.

예를 들어:

const warrantyFact: PolicyFact = {
  id: "policyfact_warranty_bag_travel_42_eu_consumer",
  domain: "warranty",
...

이는 플랫폼에 다음과 같은 안정적인 체인을 제공합니다:

주장 (Claim) → 소스 (Source) → 검토 (Review) → 인용 가능성 (Quoteability) → 적격성 (Eligibility) → 감사 (Audit)

이 체인은 정책 텍스트를 저장하고 에이전트가 이를 올바르게 해석하기를 바라는 것보다 훨씬 더 유용합니다.

Insights

에이전트 준비 완료 커머스(Agent-Ready Commerce), 파트 4: 정책을 기계가 읽을 수 있게 만들기

요약

핵심 포인트