에이전트 준비 완료(Agent-ready) 커머스 플랫폼은 단순히 답변하거나, 거절하거나, 행동하는 것만으로는 부족합니다.

왜 답변했는지, 왜 거절했는지, 또는 왜 행동했는지를 증명할 수 있어야 합니다.

문제가 발생한 후 모호한 로그(Logs)를 통해 그 증거를 신뢰성 있게 재구성하는 것은 불가능합니다. 플랫폼이 결정을 내리는 그 순간에 증거가 캡처되어야 합니다.

에이전트가 제품을 비교할 수 있다고 말할 때, 플랫폼은 어떤 제품 사실(Product facts)이 그 비교를 뒷받침했는지 알고 있어야 합니다.

에이전트가 반품 정책 인용을 거절할 때, 플랫폼은 어떤 정책 범위(Policy coverage)가 누락되었는지 알고 있어야 합니다.

결제(Checkout)가 차단되었을 때, 플랫폼은 어떤 사실, 규칙, 정책, 상태 전이(State transitions), 또는 권한 확인(Authority checks)이 이를 차단했는지 알고 있어야 합니다.

위임 결제(Delegated payment)가 거절되었을 때, 플랫폼은 차단 원인이 결제 유효성, 권한 범위(Mandate scope), 장바구니 스냅샷 불일치(Cart snapshot mismatch), 금액 제한, 통화 불일치, 만료, 취소, 확인, 제공업체 상태, 또는 주문 확약(Order commitment) 중 무엇인지 알고 있어야 합니다.

생성된 주장(Generated claim)이 인용될 때, 플랫폼은 어떤 출처 사실, 정책 사실, 결정, 검토 상태, 허용된 용도, 그리고 만료 기간이 해당 주장이 사용될 당시에 안전했음을 보장했는지 알고 있어야 합니다.

이것은 일반적인 로깅(Logging)이 아닙니다.

로그(Logs)는 활동을 설명합니다.

증거(Evidence)는 결정의 근거를 설명합니다.

감사(Audit)는 그 설명을 지속 가능하게 만듭니다.

에이전트 준비 완료 커머스에는 증명 계층(Proof layer)이 필요합니다.

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

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

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

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

파트 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)에 집중했습니다. 체크아웃은 에이전트 준비 완료 커머스(Agent-ready commerce)가 단순히 답변하는 단계에서 상업적 상태를 변이(Mutating)시키는 단계로 넘어가는 지점이라고 주장했습니다. 따라서 체크아웃은 폼 엔드포인트(Form endpoint)가 아닌 상태 머신(State machine)으로 모델링되어야 합니다.

파트 7은 위임 결제(Delegated payment)에 집중했습니다. 결제 아티팩트(Payment artifact)만으로는 충분하지 않다고 주장했습니다. 위임 결제에는 특정 체크아웃 스냅샷(Checkout snapshot), 금액, 통화, 가맹점, 행위자(Actor), 구매자, 시간 범위(Time window), 증거(Evidence), 그리고 감사(Audit)에 대한 제한된 권한(Bounded authority)이 필요합니다.

파트 8은 생성된 주장(Generated claims)에 집중했습니다. 생성된 커머스 텍스트는 의존성(Dependencies), 범위(Scope), 검토 상태(Review status), 허용된 사용(Allowed use), 무효화(Invalidation), 만료(Expiry), 그리고 감사(Audit)를 갖춘 파생된 주장(Derived claim)으로 취급되어야 한다고 주장했습니다.

이 글은 증거(Evidence)와 감사(Audit)에 집중합니다.

핵심 논지는 증거와 감사가 백엔드 관측 가능성(Observability)의 세부 사항이 아니라는 것입니다. 이것들은 제품 기능(Product capabilities)입니다. 에이전트가 플랫폼의 결정을 구매자 대상의 답변과 상업적 행동으로 전환하기 때문에, 에이전트 준비 완료 커머스에는 결정 기록(Decision records), 증거 참조(Evidence references), 재생 가능한 입력(Replayable inputs), 프로토콜 안전 설명(Protocol-safe explanations), 투영 기록(Projection records), 운영자 타임라인(Operator timelines), 그리고 감사 추적(Audit trails)이 필요합니다.

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

요청 (Request)
      ↓
결정 (Decision)
...

이 체인이 없다면, 플랫폼은 무엇이 일어났는지는 알 수 있어도 왜 일어났는지는 증명할 수 없습니다.

로그는 증거가 아닙니다

로그는 유용합니다.

엔지니어가 시스템을 디버깅하는 데 도움을 줍니다. 서비스 호출, 타이밍, 경고, 예외, 큐 이벤트(Queue events), 요청 식별자(Request identifiers), 그리고 운영 세부 사항을 캡처합니다.

하지만 로그만으로는 에이전트 준비 완료 커머스에 충분하지 않습니다.

다음과 같은 로그 라인은:

checkout blocked for BAG-TRAVEL-42

은 해당 결정의 이유를 설명하지 않습니다.

어떤 체크아웃 명령(checkout command)이 요청되었는지, 어떤 액터(actor)가 요청했는지 말해주지 않습니다. 재고가 오래되었는지(stale), 어떤 정책 사실(policy facts)이 누락되었는지, 어떤 자격 규칙(eligibility rule)이 적용되었는지, 결제 권한(payment authority)이 있었는지, 명령 전의 체크아웃 상태(checkout state)가 어떠했는지, 어떤 차단 코드(blocker codes)가 반환되었는지, 또는 에이전트에게 어떤 설명이 표시되었는지 등을 알려주지 않습니다.

더 나은 기록은 다음과 같이 답합니다:

어떤 작업(action)이 요청되었는가?
누가(which actor) 요청했는가?
어떤 제품, 장바구니, 체크아웃, 클레임(claim), 또는 위임 사항(mandate)이 대상이었는가?
...

이것이 바로 증거(evidence)입니다.

유용한 구분법은 다음과 같습니다:

로그(Log):
무언가 발생했다는 기술적 기록.

...

로그는 디버깅(debugging)을 지원합니다.

증거(Evidence)는 결정에 대한 신뢰(decision trust)를 지원합니다.

감사(Audit)는 책임 소재(accountability), 재생(replay), 지원(support), 복구(remediation), 그리고 분쟁 해결(dispute handling)을 지원합니다.

에이전트 준비 완료 커머스(Agent-ready commerce)는 이 세 가지 모두가 필요하지만, 이들은 동일한 계층이 아닙니다.

여행용 백팩(Travel Backpack) 예시

파트 2~8에서 진행 중인 예시를 이어갑니다:

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

현재 상업적 진실 계층(commercial truth layer)은 다음과 같이 말합니다:

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

파트 3에서 작업 매트릭스(action matrix)는 다음과 같았습니다:

작업 (Action)	결과 (Result)
discover	허용됨 (allowed)
...

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

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

플랫폼은 단지 이것만을 생성해서는 안 됩니다:

{
  "allowed": false
}

플랫폼은 증거를 포함한 결정을 생성해야 합니다.

유용한 응답은 다음과 같이 말할 수 있습니다:

체크아웃이 유효하지 않기 때문에 위임된 결제(Delegated payment)가 차단되었습니다.

다음과 같은 이유로 체크아웃을 준비할 수 없습니다:
...

내부적으로 플랫폼은 결정 경로(decision path)를 보존해야 합니다:

delegate_payment
      ↓ 체크아웃이 유효하지 않으므로 차단됨 (blocked because checkout is not valid)

...

이 증거 경로(evidence path)가 중요한 이유는 사용자마다 서로 다른 투영(projections)이 필요하기 때문입니다.

구매자에게는 간결한 설명이 필요할 수 있습니다.

에이전트는 구조화된 차단 코드 (blocker codes)가 필요할 수 있습니다.

운영자 (operator)는 복구 작업 (remediation tasks)이 필요할 수 있습니다.

고객 지원 (Support) 팀은 고객에게 안전한 타임라인 (timeline)이 필요할 수 있습니다.

감사자 (auditor)는 근거 사실 (source facts), 결정 기록 (decision records), 규칙 버전 (rule versions), 프로토콜 투영 (protocol projections), 그리고 타임스탬프 (timestamps)가 필요할 수 있습니다.

동일한 결정에 대해 여러 가지 뷰 (views)가 필요하지만, 이는 하나의 증거 체인 (evidence chain)으로부터 나와야 합니다.

증거는 허용된 결정에도 속합니다

증거는 실패 사례에만 첨부되어서는 안 됩니다.

차단된 결정 (Blocked decisions)은 거절 사유를 설명하기 때문에 중요합니다. 허용된 결정 (Allowed decisions) 또한 신뢰 근거를 설명하기 때문에 똑같이 중요합니다.

만약 에이전트가 두 제품을 비교하도록 허용되었다면, 플랫폼은 어떤 제품 사실 (product facts)이 그 비교를 뒷받침했는지 알고 있어야 합니다.

만약 에이전트가 보증 범위 (warranty coverage)를 인용하도록 허용되었다면, 플랫폼은 어떤 보증 정책 사실 (warranty policy fact)이 적용되었는지 알고 있어야 합니다.

체크아웃 (checkout)이 준비되었다면, 플랫폼은 어떤 가격 (price), 재고 (inventory), 정책 (policy), 배송 (shipping), 세금 (tax), 그리고 장바구니 스냅샷 (cart snapshot) 기록이 사용되었는지 알고 있어야 합니다.

위임 결제 (delegated payment)가 허용되었다면, 플랫폼은 어떤 권한 결정 (authority decision)을 뒷받침하기 위해 위임장 (mandate), 장바구니 스냅샷 (cart snapshot), 체크아웃 상태 (checkout state), 금액 (amount), 통화 (currency), 가맹점 결합 (merchant binding), 만료 확인 (expiry check), 취소 확인 (revocation check), 그리고 확인 기록 (confirmation record)이 사용되었는지 알고 있어야 합니다.

감사 질문은 단지 다음과 같은 것만이 아닙니다:

플랫폼이 왜 이것을 차단했는가?

다음과 같은 질문도 포함됩니다:

플랫폼이 왜 이것을 허용했는가?

유용한 규칙은 다음과 같습니다:

플랫폼이 답변을 제시하거나 동작을 수행할 수 있다면, 어떤 증거가 그것을 허용했는지 알고 있어야 한다.

그렇지 않으면, 시스템이 런타임 (runtime)에는 올바를지 몰라도 나중에 설명이 불가능해질 수 있습니다.

결정 기록은 핵심 아티팩트(artifact)입니다

결정 기록 (decision record)은 요청 (request), 컨텍스트 (context), 결과 (result), 증거 (evidence), 설명 (explanation), 그리고 감사 (audit)를 연결하는 객체입니다.

이것은 플랫폼의 증명 아티팩트 (proof artifact)입니다.

단순화된 모델:

type DecisionResult =
  | "allowed"
  | "blocked"
...

Travel Backpack의 경우, prepare_checkout 결정은 다음과 같을 수 있습니다:

{
  "decisionId": "decision_prepare_checkout_001",
  "action": "prepare_checkout",
...

이는 다음과 같은 항목들을 지원할 수 있기 때문에 단순한 로그 메시지보다 더 유용합니다:

에이전트 응답 (agent responses)
운영자 작업 (operator tasks)
프로토콜 투영 (protocol projections)
...

결정 기록 (decision record)은 플랫폼의 안정적인 설명 경계 (explanation boundary)가 됩니다.

증거(Evidence)는 곳곳에 복사하는 것이 아니라 참조되어야 합니다

증거(Evidence)란 모든 제품 기록, 정책 페이지, 결제 스냅샷 (checkout snapshot), 권한 부여 (mandate), 제공자 응답 (provider response), 그리고 생성된 주장 (generated claim)을 모든 결정에 복사해 넣는 것을 의미하지 않습니다.

그렇게 하면 중복, 개인정보 보호 위험, 그리고 일관성 문제가 발생합니다.

더 나은 모델은 증거 참조 (evidence references)를 저장하는 것입니다.

결정은 자신이 사용한 증거의 식별자 (identity), 버전 (version), 해시 (hash), 가시성 (visibility), 그리고 캡처 시간 (capture time)을 기록합니다.

그 후 권한이 있는 시스템에 의해 참조된 증거를 검색할 수 있습니다.

이는 개인정보 보호와 보안 측면에서 중요합니다. 결제 권한 기록, 구매자 식별 정보, 제공자 응답, 리스크 결정, 그리고 지원 노트 (support notes)에는 민감한 정보가 포함될 수 있습니다. 구매자에게 안전한 설명 (buyer-safe explanation)은 내부 감사 뷰 (internal audit view)와 동일한 세부 정보를 노출해서는 안 됩니다.

증거는 다음과 같아야 합니다:

주소 지정 가능 (addressable)
버전 관리 (versioned)
유용할 경우 해시 가능 (hashable where useful)
...

이를 통해 플랫폼은 모든 것을 모든 곳에 노출하지 않고도 증거를 보존할 수 있습니다.

증거는 평면 리스트가 아니라 그래프입니다

단순한 결정은 증거 참조의 평면 리스트 (flat list)를 사용할 수 있습니다.

복잡한 커머스 워크플로우 (commerce workflows)에는 그래프 (graph)가 필요합니다.

예를 들어:

delegate_payment 결정
      checkout_state에 의존
      payment_mandate에 의존
...

단순화된 증거 그래프 모델:

type EvidenceEdgeType =
  | "derived_from" (로부터 유도됨)
  | "blocked_by" (에 의해 차단됨)
...

Travel Backpack의 경우:

delegate_payment 결정
      blocked_by → checkout_not_valid 결정

...

이 그래프를 통해 플랫폼은 구매자에게 보여지는 거절 (refusal)로부터 실제 거절의 근원까지 추적할 수 있습니다.

이는 고립된 이벤트 (isolated events)를 저장하는 것보다 더 강력합니다.

또한 시간이 지남에 따른 변화를 설명하는 데에도 도움이 됩니다. 만약 반품 정책 (return-policy) 적용이 나중에 승인된다면, 플랫폼은 어떤 이전의 차단 요소들이 대체되었는지, 어떤 생성된 주장들이 무효화되었는지, 그리고 어떤 피드 투영 (feed projections)이 새로고침되었는지를 보여줄 수 있습니다.

설명은 증거의 투영 (projections)입니다

설명 (explanation)은 증거 기록 (evidence record)과 동일한 것이 아닙니다.

증거 기록에는 내부 규칙 ID (internal rule IDs), 정책 사실 참조 (policy fact references), 소스 해시 (source hashes), 결제 제공업체 참조 (payment provider references), 리스크 플래그 (risk flags), 운영자 노트 (operator notes), 그리고 민감한 구매자 정보가 포함될 수 있습니다.

설명은 대상(audience)에게 안전하고 유용한 정보만을 노출해야 합니다.

대상에 따라 서로 다른 투영 (projections)이 필요합니다:

대상	필요한 설명
구매자 (Buyer)	명확하고 간결하며 안전한 이유
...

여행용 배낭 (Travel Backpack)의 경우, 구매자에게 안전한 설명은 다음과 같을 수 있습니다:

현재 이 품목에 대한 결제 준비를 완료할 수 없습니다. 가용성을 재검증해야 하며, 이 제품 카테고리에 대한 반품 조건이 제공되지 않습니다.

에이전트 대상 설명은 다음과 같을 수 있습니다:

{
  "result": "blocked",
  "blockers": [
...

운영자 대상 설명은 다음과 같을 수 있습니다:

BAG-TRAVEL-42가 결제 준비 단계에서 차단되었습니다.

필요한 조치:
...

감사 뷰 (audit view)에는 증거 참조 (evidence references), 규칙 버전 (rule versions), 장바구니 스냅샷 (cart snapshots), 타임스탬프 (timestamps), 그리고 투영 기록 (projection records)이 포함될 수 있습니다.

이것들은 동일한 증거 체인 (evidence chain)으로부터 파생된 서로 다른 설명들입니다.

플랫폼은 각 설명을 독립적으로 생성해서는 안 됩니다. 결정 기록 (decision record)으로부터 이를 투영 (project)해야 합니다.

프로토콜 안전 (Protocol-safe)이 모호함을 의미하지는 않습니다

일부 팀은 내부 세부 정보를 유출하고 싶지 않기 때문에 증거를 노출하는 것을 피합니다.

이는 합리적입니다.

하지만 그 해결책이 모호한 에러여서는 안 됩니다.

취약한 프로토콜 응답:

{
  "error": "not_allowed"
}

더 나은 프로토콜 안전 응답:

{
  "result": "blocked",
  "reason": "RETURN_POLICY_MISSING",
...

이 응답은 내부 정책 기록 ID (internal policy record IDs), 소스 문서 (source documents), 규칙 구현 (rule implementation), 또는 운영자 노트를 노출하지 않습니다. 대신 도메인 의미 (domain meaning)를 보존합니다.

이것은 에이전트가 다음에 무엇을 해야 할지 알아야 하기 때문에 중요합니다.

일반적인 거절 응답은 에이전트가 재시도하게 만들거나, 구매자에게 잘못된 질문을 던지게 하거나, 혹은 다른 안전하지 않은 가정을 가지고 진행하게 만들 수 있습니다.

구조화된 거절(structured refusal)은 에이전트가 올바르게 복구하는 데 도움을 줍니다.

INVENTORY_STALE:
재검증 요청

...

프로토콜 안전 응답(Protocol-safe responses)은 가능한 한 차단 의미론(blocker semantics)을 보존해야 합니다.

투영 기록(Projection records)은 어댑터 드리프트(adapter drift)를 방지합니다

파트 5에서는 어댑터 드리프트(adapter drift)에 초점을 맞췄습니다. 서로 다른 어댑터들이 동일한 커머스 질문에 대해 서로 다르게 답변하기 시작할 수 있습니다.

증거(Evidence)는 그러한 드리프트(drift)를 탐지하고 방지하는 데 도움을 줍니다.

MCP 스타일의 도구 응답, ACP 스타일의 커머스 응답, AP2 관련 결제 응답, 내부 피드(internal feed), 그리고 관리자 UI(admin UI)가 모두 동일한 결정 기록(decision record)을 참조한다면, 이들은 동일한 의미를 유지하면서도 서로 다른 형태(shape)로 투영될 수 있습니다.

응답의 형태는 다를 수 있습니다.

하지만 결정은 달라져서는 안 됩니다.

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