에이전트 준비 완료 커머스, 파트 3: 왜 AI 에이전트에게 '사용 가능(Available)'만으로는 충분하지 않은가

대부분의 이커머스 (ecommerce) 플랫폼은 어떤 형태로든 제품 가용성 (product availability) 정보를 가지고 있습니다.

제품이 활성화되어 있습니다. 재고가 있습니다. 가격이 있습니다. 스토어프런트 (storefront)에 노출될 수 있습니다.

사람을 대상으로 하는 이커머스 사이트의 경우, 이러한 모델은 오랫동안 충분히 유효할 수 있습니다. 스토어프런트는 제품 페이지를 렌더링하고, "장바구니 담기" 버튼을 보여주며, 결제 (checkout) 단계에서 나중에 최종 검증을 수행하도록 할 수 있습니다.

하지만 에이전트 준비 완료 커머스 (agent-ready commerce)를 위해서는 이 모델이 너무 모호해집니다.

문제는 available (사용 가능)이라는 표현이 틀렸다는 것이 아닙니다. 문제는 그 단어 하나 뒤에 너무 많은 서로 다른 결정 사항들이 숨겨져 있다는 점입니다.

무엇을 위해 사용 가능한가요?

탐색 (Discovery)?

비교 (Comparison)?

정책 견적 (Policy quotation)?

장바구니 삽입 (Cart insertion)?

결제 준비 (Checkout preparation)?

위임된 결제 (Delegated payment)?

이러한 동작들은 동일한 위험도를 수반하지 않으며, 동일한 규칙을 사용해서도 안 됩니다.

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

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

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

파트 2에서는 그 체인의 첫 번째 부분인 상업적 진실 (commercial truth)에 집중했습니다. 에이전트 대상 시스템에서는 가공되지 않은 제품 레코드만으로는 충분하지 않습니다. 소프트웨어가 제품 정보에 따라 안전하게 동작하기 위해서는 플랫폼이 출처가 확인되고 최신성을 인지하는 (freshness-aware) 제품 사실 정보를 보유해야 합니다.

이 기사는 체인의 두 번째 부분인 **적격성 (eligibility)**에 초점을 맞춥니다.

핵심 아이디어는 다음과 같습니다:

상업적 진실 (Commercial truth)은 무엇이 알려져 있는지를 말합니다.
적격성 (Eligibility)은 어떤 동작이 유효한지를 말합니다.
권한 (Authority)은 누가 그것을 요청할 수 있는지를 말합니다.
...

이러한 계층들을 분리하여 유지하는 것은 에이전트 준비 완료 커머스에서 가장 중요한 설계 선택 중 하나입니다.

일반적인 가용성 (availability)의 문제점

전형적인 제품 모델은 다음과 같은 필드들을 포함할 수 있습니다:

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

단순한 가용성 체크는 다음과 같이 보일 수 있습니다:

function isAvailable(product: Product) {
  return product.active && product.inventoryStatus !== "out_of_stock";
}

이것은 나쁜 함수가 아닙니다. 실제 질문에 답을 하고 있습니다.

문제는 그 질문이 너무 광범위하다는 것입니다.

isAvailable(product)가 true를 반환한다면, 플랫폼이 정확히 무엇을 허용했다는 뜻일까요?

검색 결과에 제품을 노출할 수 있나요?

에이전트가 이를 추천할 수 있나요?

에이전트가 대안 제품과 비교할 수 있나요?

에이전트가 반품 정책을 인용할 수 있나요?

에이전트가 제품을 장바구니에 담을 수 있나요?

에이전트가 결제 준비를 할 수 있나요?

에이전트가 위임된 결제 흐름 (delegated payment flow)을 트리거할 수 있나요?

사람을 대상으로 하는 스토어프런트 (storefront)는 이러한 모든 동작을 즉시 분리할 필요가 없을 수도 있습니다. 페이지는 제품을 렌더링하고, 나중에 검증 (validation)을 통해 문제를 잡아내는 방식에 의존할 수 있기 때문입니다.

하지만 에이전트를 대상으로 하는 시스템은 더 정밀한 계약 (contract)이 필요합니다. 외부 에이전트가 available: true를 본다면, 해당 제품이 상업적 동작에 사용될 수 있다고 합리적으로 가정할 수 있습니다. 단 하나의 불리언 (boolean) 값에 너무 많은 의미를 담고 있는 것입니다.

플랫폼에는 동작별 적격성 (action-specific eligibility)이 필요합니다.

실행 예시

카탈로그 관점에서는 단순해 보이는 제품을 가정해 보겠습니다:

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

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

하지만 상업적 진실 계층 (commercial truth layer)은 더 많은 것을 알고 있을 수 있습니다:

Price: fresh
Inventory: stale
Return policy: missing for Travel Bags
...

일반적인 가용성 모델 (availability model)은 여전히 다음과 같이 말할 수 있습니다:

available = true

하지만 이 답변은 충분히 정밀하지 않습니다.

더 나은 동작 수준 (action-level)의 관점은 다음과 같을 것입니다:

discover          allowed
compare           allowed
quote_policy      blocked
...

이것이 중요한 변화입니다.

제품은 단순히 사용 가능하거나 불가능한 것이 아닙니다. 제품은 서로 다른 동작에 대해 서로 다른 준비 수준 (readiness levels)을 가집니다.

사람 사용자는 여전히 제품 페이지를 탐색할 수 있습니다. 에이전트 역시 제품을 발견하고 비교할 수 있습니다. 하지만 플랫폼은 누락되거나 오래된 정보 (missing and stale facts)가 해결될 때까지 정책 인용이나 결제 준비를 허용해서는 안 됩니다.

동작은 도메인 모델의 일부여야 합니다

첫 번째 단계는 에이전트 경계 (agent boundary)에서 중요한 동작들을 명명하는 것입니다.

플랫폼이 모든 내부 동작 (internal operation)을 노출할 필요는 없지만, 에이전트가 요청할 수 있는 상업적 동작 (commercial actions)은 정의해야 합니다.

예를 들어:

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

이러한 동작들은 서로 대체 가능하지 않습니다.

discover는 제품이 에이전트용 카탈로그 (catalog), 검색 결과, 또는 제품 피드 (product feed)에 나타날 수 있음을 의미합니다.

compare는 선택된 상업적 사실 (commercial facts)을 사용하여 제품이 대안들과 비교 평가될 수 있음을 의미합니다.

quote_policy는 에이전트가 반품, 배송, 취소 또는 보증과 같은 정책 조건 (policy terms)을 설명할 수 있음을 의미합니다.

add_to_cart는 에이전트가 제품을 임시 장바구니 (draft cart) 또는 구매 의도 문맥 (buyer-intent context)에 담을 수 있음을 의미합니다.

prepare_checkout는 에이전트가 결제 세션 (checkout session)을 시작하거나 준비할 수 있음을 의미합니다.

delegate_payment는 에이전트가 결제 권한 경계 (payment authority boundary) 내에서 동작할 수 있음을 의미합니다.

동작들이 명명되고 나면, 플랫폼은 제품 가용성 (product availability)을 하나의 전역 상태 (global state)로 취급하는 것을 중단할 수 있습니다.

대신, 다음과 같이 질문할 수 있습니다:

현재의 제품 진실 (product truth)과 요청 문맥 (request context)을 고려할 때,
이 특정 동작이 허용되는가?

이것이 더 나은 질문입니다.

서로 다른 동작에는 서로 다른 사실이 필요합니다

동작의 적격성 (eligibility)은 상업적 진실 (commercial truth)에 따라 달라져야 하지만, 모든 동작이 동일한 사실을 필요로 하지는 않습니다.

단순화된 요구사항 매트릭스 (requirement matrix)는 다음과 같을 수 있습니다:

동작 (Action)         필요한 진실 (Required truth)         예시 결과 (Example result)
--------------------------------------------------------------------------------
discover               identity, visibility, media             allowed
...

이 매트릭스는 각 동작이 무엇에 의존하는지를 설명해주기 때문에, 단일한 available 플래그보다 더 유용합니다.

여행용 배낭 예시가 더 명확해집니다:

discover
  필요 사항: identity, visibility, media
  결과: allowed
...

이것은 제품이 고장 났다는 뜻이 아닙니다. 서로 다른 기능들이 서로 다른 준비 수준 (readiness levels)을 가지고 있다는 의미입니다.

그 구분이 에이전트 준비 완료 (agent-ready) 시스템에는 필수적입니다.

적격성 결정은 구조화되어야 합니다

불리언 (boolean) 반환 값만으로는 충분한 경우가 거의 없습니다.

다음은 너무 취약합니다:

const checkoutAllowed = false;

이는 호출자에게 결과만을 알려줄 뿐, 결정의 이유를 설명하지 않습니다.

더 유용한 적격성 결정 (eligibility decision)에는 작업 (action), 대상 (subject), 문맥 (context), 결과 (result), 차단 요소 (blockers), 근거 (evidence), 그리고 규칙 버전 (rule version)이 포함되어야 합니다.

type ActionEligibilityDecision = {
  subject: {
    productId: string;
...

여행용 배낭의 경우, 결제 (checkout) 결정은 다음과 같을 수 있습니다:

const decision: ActionEligibilityDecision = {
  subject: {
    productId: "bag_travel_42",
...

이 결정은 여러 소비자 (consumers)에게 쓰일 수 있습니다.

에이전트 (agent)는 작업을 중단하거나, 명확한 설명을 요구하거나, 대안을 제안할 수 있습니다.

결제 서비스 (checkout service)는 세션 준비를 거부할 수 있습니다.

관리자 UI (admin UI)는 복구 작업 (remediation tasks)을 생성할 수 있습니다.

감사 추적 (audit trail)은 왜 해당 제품이 차단되었는지 기록할 수 있습니다.

피드 게시자 (feed publisher)는 제품의 작업 요약 (action summary) 등급을 낮출 수 있습니다.

구조화된 결정은 불리언 (boolean) 값보다 재사용성이 높습니다.

적격성은 권한이 아닙니다

적격성 (eligibility)과 권한 (authority)은 종종 혼동됩니다.

혼동해서는 안 됩니다.

적격성은 다음을 답변합니다:

현재의 상업적 조건 하에서 이 제품에 대해 이 작업이 유효한가?

권한은 다음을 답변합니다:

이 행위자 (actor)가 이 작업을 요청할 수 있는 허가를 받았는가?

실행 (execution)은 다음을 답변합니다:

시스템이 지금 상태 변경 (state change)을 수행할 수 있는가?

이것들은 서로 별개의 확인 절차입니다.

예를 들어, 제품이 결제 적격 (checkout-eligible) 상태일지라도, 특정 에이전트가 결제를 준비할 권한이 없을 수 있습니다.

에이전트가 유효한 결제 위임 (payment mandate)을 가지고 있더라도, 재고 정보가 오래되어(stale) 제품이 결제 적격 상태가 아닐 수 있습니다.

결제 세션이 적격하고 권한이 있더라도, 검증 (validation)과 전환 (transition) 사이에 상태가 변경되어 실행 (execution)이 실패할 수 있습니다.

분리 구조는 다음과 같습니다:

상업적 진실 (Commercial truth)
        ↓
적격성 (Eligibility)
...

명령 (command)은 각 계층을 통과해야 합니다.

type CommerceCommandReadiness = {
  eligibility: ActionEligibilityDecision;
  authority: AuthorityDecision;
...

이를 통해 하나의 결정이 너무 많은 역할을 수행하는 것을 방지할 수 있습니다.

제품이 적격(eligible)하다고 해서 행위자(actor)에게 권한(authorized)이 있다는 의미는 아닙니다.

행위자에게 권한이 있다고 해서 제품이 적격하다는 의미도 아닙니다.

두 가지가 모두 참이라 하더라도, 상태 전이(state transition)가 유효하지 않다면 실행(execution)이 보장되지 않습니다.

이러한 구분은 결제(checkout) 및 위임 결제(delegated payment)에서 특히 중요해집니다.

적격성(Eligibility)은 상업적 진실(commercial truth)을 재구축하는 것이 아니라 소비해야 합니다

적격성 계층(eligibility layer)은 가공되지 않은 카탈로그 데이터로부터 제품 정보를 다시 찾아내서는 안 됩니다. 그렇게 하면 로직이 중복되고 일관성 없는 동작이 발생할 수 있습니다.

대신, 적격성은 진실 스냅샷(truth snapshot)을 소비해야 합니다.

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

그 후 적격성 계층은 특정 액션에 특화된 요구사항(action-specific requirements)을 적용합니다.

type ActionRequirement = {
  action: AgentCommerceAction;
  requiredFacts: Array<keyof ProductTruthSnapshot["facts"]
...

예시:

const actionRequirements: ActionRequirement[] = [
  {
    action: "discover",
...

경계가 명확합니다:

상업적 진실(Commercial truth)이 말합니다:
재고가 오래되었습니다(Inventory is stale).

...

각 계층은 더 좁은 범위의 책임을 가집니다.

컨텍스트(Context)가 중요합니다

제품의 적격성은 전역적(global)인 경우가 드뭅니다.

제품이 한 지역에서는 적격하지만 다른 지역에서는 차단될 수 있습니다. 배송 정책이 EU에는 존재하지만 미국에는 없을 수 있습니다. 반품 정책이 일반 소비자에게는 적용되지만 기업 구매자에게는 적용되지 않을 수 있습니다. 결제 수단은 통화(currency)에 따라 달라질 수 있습니다. 마켓플레이스 채널은 판매자 자신의 스토어프런트보다 더 엄격한 요구사항을 가질 수 있습니다.

따라서 적격성에는 컨텍스트(context)가 포함되어야 합니다.

type EligibilityContext = {
  region?: string;
  currency?: string;
...

동일한 제품이라도 다른 결정이 내려질 수 있습니다:

컨텍스트: EU 소비자, 에이전트 채널
discover          allowed
compare           allowed
...

전역적인 available 플래그로는 이를 표현할 수 없습니다.

컨텍스트 인식형 적격성(Context-aware eligibility)은 더 복잡하지만, 플랫폼이 특정 구매자나 시장에 필요한 정보를 갖추지 못한 경우에 제품이 과도하게 노출되는 것을 방지합니다.

적격성은 성능 저하(degradation)를 지원해야 합니다

적격성 (Eligibility)은 단순한 관문(gate)이 아닙니다. 이는 안전하게 성능 저하 (degradation)를 유도하는 방법이기도 합니다.

단 하나의 고위험 동작이 차단되었다고 해서, 모든 에이전트 인터페이스 (agent surface)에서 제품이 사라질 필요는 없습니다.

여행용 배낭의 경우, 플랫폼은 다음과 같은 기능 프로필 (capability profile)을 노출할 수 있습니다:

discover          allowed
compare           allowed
quote_policy      blocked
...

이는 에이전트와 운영자에게 제품의 상태가 정확히 어떠한지를 알려줍니다.

반품 정책 (return-policy) 커버리지가 불완전한 제품이라도 여전히 검색 (discoverable)될 수 있습니다. 재고 정보가 오래된 (stale) 제품이라도 여전히 비교 (comparable)될 수 있습니다. 검토되지 않은 생성된 설명 (generated description)이 있는 제품이라도, 에이전트가 승인된 카탈로그 문구를 대신 사용한다면 여전히 표시될 수 있습니다.

이는 두 가지 극단적인 대안보다 더 나은 방식입니다:

너무 허용적인 경우 (Too permissive):
결제 (checkout)가 안전하지 않음에도 불구하고 제품을 완전히 사용 가능한 상태로 표시함.

...

동작별 적격성 (Action-specific eligibility)을 통해 플랫폼은 안전하지 않은 동작은 차단하면서도 안전한 기능들은 보존할 수 있습니다.

이것이 더 유용한 운영 모델입니다.

결정 결과는 '허용(allowed)' 또는 '차단(blocked)' 그 이상이어야 합니다

모든 부정적인 결정이 반드시 blocked로 표현될 필요는 없습니다.

어떤 결정은 재검증 (revalidation)이 필요하고, 어떤 결정은 사람의 검토 (human review)가 필요하며, 어떤 결정은 추가적인 권한 (additional authority)을 요구합니다. 또한 어떤 결정은 차단 요소라기보다 경고 (warnings)에 가깝습니다.

유용한 결과 유형은 다음과 같을 수 있습니다:

type EligibilityResult =
  | "allowed"
  | "allowed_with_warnings"
...

예를 들어:

discover
  result: allowed_with_warnings
  warning: generated description pending review, using approved catalog summary
...

이는 시스템을 더욱 표현력 있게 (expressive) 만들어 줍니다.

제품이 '허용'에서 '차단'으로 직접 이동할 필요는 없습니다. 동작에 따라 재검증, 검토, 또는 경고를 인지한 처리 (warning-aware handling)가 필요할 수 있습니다.

규칙 버전 관리 (Rule versioning)는 필수적입니다

적격성 규칙 (Eligibility rules)은 변경됩니다.

플랫폼은 오래된 재고(stale inventory)가 장바구니 담기(cart insertion)에는 허용되지만, 결제(checkout)에는 허용되지 않는다고 결정할 수 있습니다. 나중에 수요가 높은 카테고리의 경우, 장바구니 담기 전 단계부터 신선한 재고(fresh inventory)를 요구할 수도 있습니다. 정책 팀은 특정 지역에서 비교(comparison)를 수행하기 전에 반품 정책(return-policy) 적용 여부를 요구할 수 있습니다. 마켓플레이스 채널은 스토어프런트(storefront)보다 더 엄격한 정책 완결성(policy completeness)을 요구할 수도 있습니다.

적격성 결정(eligibility decisions)이 저장, 캐싱, 게시 또는 감사(audited)되는 경우, 플랫폼은 어떤 규칙 버전(rule version)이 해당 결정을 생성했는지 알아야 합니다.

type EligibilityRuleSet = {
  id: string;
  version: string;
...
}

결정(decision)은 규칙 세트(rule set)를 참조해야 합니다:

type EligibilityDecisionMetadata = {
  truthVersion: string;
  ruleSetId: string;
...
}

이는 다음 두 가지 사례를 구분하는 데 도움이 됩니다:

Case 1:
재고가 신선한 상태(fresh)에서 오래된 상태(stale)로 변경되어 제품이 차단(blocked)되었습니다.

...

두 경우 모두 유효하지만, 운영 측면에서는 서로 다른 의미를 갖습니다.