에이전트 트랜잭션(Agent Transaction)의 양면성

커피숍에서 신용카드를 긁을 때, 결제 네트워크는 하나의 신원이 아닌 두 개의 신원을 확인합니다. 당신의 카드는 당신을 식별합니다. 가맹점의 단말기는 커피숍을 식별합니다: 가맹점 ID (merchant ID), 가맹점 업종 코드 (merchant category code), 등록된 법인 (registered legal entity), 분쟁이 해결되는 관할 구역 (jurisdiction), 그리고 해당 특정 비즈니스에 맞게 지문이 찍힌 수년 된 네트워크 계약까지 포함됩니다. 거래가 완료되는 이유는 양측 모두 네트워크가 인식하는 신원을 가지고 있기 때문입니다. 문제가 발생했을 때, 네트워크는 양쪽 끝에서 누구와 대화하고 있는지 알고 있습니다.

카드 네트워크는 이를 구축하기 위해 수십 년을 보냈습니다. 그래야만 했습니다. 한쪽은 식별되지만 다른 한쪽은 엔드포인트에 나타나는 무엇이든 될 수 있는 결제 시스템은 대규모 사기를 발생시키며, 거래의 절반이 익명이기 때문에 사기 조사가 어렵습니다.

이제 오늘날 AI 에이전트가 누군가를 대신하여 구매를 수행할 때 어떤 일이 발생하는지 생각해 보십시오. 에이전트는 신원을 가지고 있습니다. Agent-ID, Owner-ID, Authority-Scope, 서명된 Genesis가 모든 요청에 포함되어 전달됩니다. 하지만 가맹점은 URL에 있던 그대로의 상태일 뿐입니다. 프로토콜 수준의 신원 (protocol-level identity)이 없습니다. 가맹점이 주장하는 본인이 맞는지, 가맹점의 등록이 최신 상태인지, 가맹점에 분쟁 정책 (dispute policy)이 있는지, 가맹점이 해당 관할 구역에서 양호한 상태 (good standing)인지에 대한 구조적 검증이 없습니다.

거래의 절반은 신원을 가지고 있지만, 나머지 절반은 연결에 응답한 그 누구일 뿐입니다.

이것이 바로 AGTP의 가맹점 신원 (merchant identity) 레이어가 메우고자 하는 격차입니다. 이는 Agent Genesis가 요청 측 (initiating side)을 위해 수행하는 역할을 에이전트 구매의 수신 측 (receiving side)을 위해 수행합니다. 그리고 이는 Budget-Limit(예산 제한) 및 Intent-Assertion(의도 단언)이라는 두 가지 운영 프리미티브 (operational primitives)와 결합되어, 에이전트 주도 커머스 (agent-driven commerce)를 컴플라이언스 팀, 결제 네트워크, 그리고 가맹점 스스로가 실제로 신뢰할 수 있는 무언가로 만들어 줍니다.

AGTP에서 "가맹점 신원 (merchant identity)"이 의미하는 것

AGTP에서의 가맹점(merchant)은 거버넌스 플랫폼(governance platform)을 통해 등록된 법적 실체(legal entity)이며, 서명된 가맹점 제네시스(Merchant Genesis) 문서로부터 파생된 정형화된 가맹점 ID(Merchant-ID)로 식별됩니다.

가맹점 제네시스(Merchant Genesis)에는 결제 네트워크와 규제 기관이 확인하기를 기대하는 필드들이 포함되어 있습니다: 법인명, 조직 도메인(organization domain), ISO 18245를 따르는 가맹점 업종 코드(merchant category code), 등록 관할 구역(registered jurisdiction), 수락 가능한 결제 네트워크, 분쟁 정책 URI(dispute policy URI), 환불 정책 URI(refund policy URI), 신뢰 등급(trust tier), 거버넌스 구역(governance zone), 그리고 가맹점 등록을 뒷받침하는 검증 경로(verification path)가 그것입니다. 제네시스는 발행 시 서명되며, 해시(hash) 처리되어 가맹점 ID(Merchant-ID)를 생성하고, 해당 가맹점에 영구적으로 귀속됩니다.

에이전트 제네시스(Agent Genesis)와의 구조적 유사성은 의도된 것입니다. 에이전트를 등록하는 거버넌스 플랫폼은 동일한 레지스트리(registry)와 동일한 암호화 메커니즘(cryptographic machinery)을 통해 가맹점을 등록합니다. 제네시스에서 파생된 가맹점 매니페스트 문서(Merchant Manifest Document)는 에이전트 매니페스트 문서(Agent Manifest Document)의 가맹점 측 대응물입니다. 두 문서 모두 서명된 신원 주장(identity claims)을 담고 있습니다. 두 문서 모두 신뢰 등급(trust tier)을 담고 있습니다. 두 문서 모두 거버넌스 구역(governance zone)을 담고 있습니다. 또한 두 문서 모두 탐색(discovery)을 통해 해결(resolve)될 수 있으며 사용 시점에 검증될 수 있습니다.

가맹점의 정형화된 URI는 agtp://acme.tld/merchant/acme-commerce와 같은 형태를 띱니다. 도메인은 가맹점을 등록된 조직에 고정(anchor)시킵니다. 라벨이 붙은 접미사(suffix)를 통해 단일 조직이 여러 가맹점 신원을 운영할 수 있게 하며, 이는 멀티 브랜드 소매업체와 대기업에 중요합니다. 모든 URI 형태는 동일한 정형화된 가맹점 ID(Merchant-ID)로 다시 해결됩니다.

이것이 바로 에이전트 커머스(agent commerce)에서 누락되었던 기질(substrate)입니다. 가맹점은 단순히 구매(PURCHASE) 호출에 응답하는 엔드포인트(endpoint) 그 이상입니다. 가맹점은 검증 가능한 신원, 선언된 정책, 그리고 감사가 가능한 등록 기록을 갖추고 트랜잭션(transaction)의 배후에 서 있는 법적 실체(legal entity)입니다.

[

]

구매(PURCHASE) 시 검증

구매(PURCHASE) 메서드는 가맹점 신원 확인 메커니즘(merchant identity machinery)을 호출합니다. payments:purchase 권한 범위(Authority-Scope)를 보유한 에이전트는 요청을 보내기 전에 반드시 상대방 검증(counterparty verification)을 수행해야 합니다.

검증은 5단계로 이루어집니다. 가맹점 URI를 확인(Resolve)합니다. 거버넌스 플랫폼(governance platform)에 게시된 키를 사용하여 매니페스트(manifest)의 서명을 검증합니다. 가맹점의 생명주기 상태(lifecycle state)가 활성(Active) 상태인지 확인합니다. 가맹점의 신뢰 등급(trust tier)이 해당 트랜잭션 금액에 대해 에이전트의 정책이 요구하는 임계값(threshold)을 충족하는지 확인합니다. 정형화된 매니페스트 바이트(canonical manifest bytes)의 SHA-256 해시를 계산하고, 해당 지문(fingerprint)을 Merchant-Manifest-Fingerprint 요청 헤더에 담아 전달합니다.

어느 한 단계라도 실패하면 구매(PURCHASE)는 절대 전송되지 않습니다. 에이전트의 런타임(runtime)은 해당 실패를 본인(principal) 또는 거버넌스 플랫폼에 알립니다. 검증되지 않은 트랜잭션으로 조용히 대체(silent fallback)되는 경우는 없습니다.

수신 측 가맹점 서버 또한 자체적인 검증 책임이 있습니다. 서버는 인바운드(inbound) 요청의 Merchant-ID 헤더가 자신의 정형화된 ID(canonical ID)와 일치하는지 확인합니다. 또한 매니페스트 지문(manifest fingerprint)이 현재의 가맹점 매니페스트(Merchant Manifest)와 일치하는지 확인합니다. 불일치가 발생하면 458 Counterparty Unverified를 반환합니다. 여기서 주목해야 할 부분은 지문 확인 단계입니다. 요청 에이전트를 자신이 검증했던 엔드포인트가 아닌 다른 엔드포인트로 리다이렉트하는 공격자는 지문 비교 단계에서 적발됩니다. 에이전트가 검증한 매니페스트는 서버가 실제로 제시하는 매니페스트와 반드시 일치해야 합니다. 이 둘은 해시(hash)에 의해 결합되어 있습니다.

이것이 바로 위장 가맹점(spoofed-merchant) 공격을 차단하는 프로토콜 수준의 메커니즘입니다. 에이전트는 DNS를 신뢰할 필요도, 호스팅 인프라를 신뢰할 필요도 없으며, 자신이 확인한 URL이 5초 전과 동일한 곳을 가리키고 있는지 의심할 필요도 없습니다. 지문 확인은 응답하는 엔티티가 바로 검증되었던 그 엔티티임을 보장하는 암호학적 보증(cryptographic guarantee)입니다.

통신 단계에서 강제되는 예산 제한(Budget-Limit)

신뢰할 수 있는 에이전트 상거래(agent commerce)의 나머지 절반은 운영적 격리(operational containment)입니다. 상한선(ceiling)까지 구매하도록 권한을 부여받은 에이전트는, 상위 애플리케이션 로직에 버그가 있는 경우를 포함하여 실제로 그 상한선에서 멈춰야 합니다.

AGTP는 이를 헤더(header)로 포함합니다. Budget-Limit: USD=850.00. 형식은 통화 코드, 등호, 소수점 금액입니다. 이 헤더는 구매(PURCHASE) 요청과 함께 전달됩니다. 판매자(merchant) 서버는 이를 강제할 의무가 있습니다. 선언된 예산을 초과하는 장바구니 총액은 트랜잭션이 완료되기 전에 거부됩니다. 경로 상의 범위 강제 지점(Scope Enforcement Points)은 요청이 판매자의 애플리케이션에 도달하기 전, 라인 레이트(line rate)로 이를 강제할 수 있습니다.

권한 범위(Authority-Scope)와의 관계를 명확히 짚고 넘어갈 가치가 있습니다. 권한 범위(Authority-Scope)는 에이전트의 전반적인 상거래 권한을 설명합니다: payments:purchase, payments:up-to-2500usd. 이는 에이전트가 세션 내의 모든 트랜잭션에 걸쳐 광범위하게 허용된 작업입니다. 예산 제한(Budget-Limit)은 특정 트랜잭션에 대한 상한을 설명합니다: 이 구매(PURCHASE)에는 사용할 수 있는 850달러가 있습니다. 권한 범위(Authority-Scope)가 카드에 설정된 신용 한도라면, 예산 제한(Budget-Limit)은 당신이 오늘 밤 승인한 저녁 식사의 규모입니다.

두 가지 모두 프로토콜 계층(protocol layer)에서 강제됩니다. 권한 범위(Authority-Scope)가 최대 2,500달러까지 허용되는 에이전트가 그 허용치를 사용하여 단일 5,000달러 구매를 수행할 수는 없습니다. 예산 제한(Budget-Limit)이 850달러로 설정된 특정 구매(PURCHASE)는 850.01달러로 완료될 수 없습니다. 프로토콜 계층 상위의 애플리케이션 버그는 예산을 초과하는 트랜잭션을 발생시킬 수 없는데, 프로토콜이 이를 먼저 잡아내기 때문입니다.

이것이 바로 컴플라이언스(compliance) 팀이 요구해 왔으나 애플리케이션 계층의 강제(application-layer enforcement)로는 계속해서 제공하지 못했던 운영적 가드레일(operational guardrail)입니다. 와이어 레벨(Wire-level)의 예산 강제는 애플리케이션 루프의 버그, 사용자 지침의 프롬프트 인젝션(prompt-injection), 그리고 판매자의 예상치 못한 가격 급등이 모두 동일한 벽에 부딪힘을 의미합니다. 즉, 프로토콜이 트랜잭션 완료를 거부하는 것입니다.

의도 주장(Intent-Assertion): 휴대 가능한 증거

AGTP가 해결해야 할 문제는 순수한 프로토콜 ID (Protocol Identity)만으로는 단독으로 해결할 수 없는 문제입니다. 결제 네트워크는 이미 존재합니다. Visa, Mastercard, ACH, PIX, FedNow, 그리고 모든 지역적 결제망(rail)이 그러합니다. 이러한 네트워크들은 수십 년의 역사를 가지고 있으며, 연간 수조 달러를 처리하고 있고, AGTP 트래픽을 직접 수용하는 일은 결코 없을 것입니다. 카드 네트워크를 통해 구매를 수행하는 에이전트는 카드 네트워크가 소비할 수 있는 증거를 제시해야 합니다.

Intent-Assertion (의도 주장) 헤더가 바로 그 가교 역할을 합니다. 이 헤더는 이 특정 구매에 대한 주체(Principal)의 권한 부여를 포함하는 분리된 서명된 JWT (JSON Web Token)를 운반합니다. 여기에는 주체의 신원, 장바구니 다이제스트 (Cart Digest), 예산 상한선 (Budget Cap), 의도 타임스탬프 (Intent Timestamp), 그리고 구매 대상인 가맹점 정보가 포함됩니다. JWT는 주체의 키(또는 배포 패턴에 따라 주체를 대신하여 거버넌스 플랫폼)에 의해 서명되며, 휴대 가능합니다. 카드 네트워크는 이를 소비할 수 있습니다. PSP (결제 서비스 제공업체)도 소비할 수 있습니다. 매입사 (Acquirers)도 소비할 수 있습니다. 이들 중 누구도 AGTP를 직접 구동할 필요는 없습니다. 그저 주체가 공개한 키를 통해 JWT 서명을 인식하기만 하면 됩니다.

이는 물리적 세계에서 공증된 문서가 따르는 패턴과 동일합니다. 공증된 서명은 공증을 수용하는 기관이라면 어디서든 소비할 수 있는 권한 부여의 휴대 가능한 증거입니다. 공증인은 모든 기관의 워크플로우 내부에 존재할 필요가 없습니다. 서명 그 자체로 독립적인 효력을 갖습니다.

Intent-Assertion을 통해 에이전트가 시작한 트랜잭션은 양측 모두에서 검증 가능한 권한 부여 증거를 지닌 채 기존 결제망을 이용할 수 있습니다. 카드 네트워크는 AGTP 인프라와 통합할 필요 없이, 자신들에게 필요한 증거(에이전트가 이 주체로부터, 이 금액만큼, 이 가맹점에 대해, 이 시간에 권한을 부여받았음)를 얻게 됩니다.

MNS: 가맹점 이름 서비스 (Merchant Name Service)

가맹점 측의 탐색(Discovery)은 에이전트 측의 탐색과 대칭을 이룹니다. Merchant Name Service (MNS)는 ANS (Agent Name Service)의 가맹점 대응 모델입니다. 이는 가맹점 매니페스트 문서 (Merchant Manifest Documents)를 인덱싱하고, 순위가 매겨진 서명된 결과 세트로 DISCOVER 쿼리에 응답하는 AGTP 인식 서버입니다.

특정 관할 구역 내에서 특정 유형의 가맹점을 찾고, 특정 결제 네트워크를 수용하며, 특정 임계값 이상의 신뢰 계층(Trust Tier)을 가진 가맹점을 찾는 에이전트는 ANS에 쿼리하는 것과 동일한 방식으로 MNS에 쿼리합니다. 결과는 동일한 연합(Federation) 및 범위 강제(Scope-enforcement) 속성을 유지하며, 서명된 상태로 신뢰 계층, 행동 점수(Behavioral Score) 및 역량 일치도(Capability Match)에 따라 순위가 매겨져 반환됩니다.

MNS는 ANS와 같은 위치에 배치되거나 별도로 운영될 수 있습니다. 일부 운영자는 통합된 디스커버리 계층(Discovery Layer)을 실행할 것이며, 일부는 가맹점 디렉터리(Merchant Directories)를 전문으로 할 것입니다. 프로토콜은 이에 대해 불가지론적(Agnostic)인 상태를 유지합니다. 중요한 점은 가맹점 측에 에이전트가 모든 잠재적 거래 상대방과 양자 간 통합(Bilateral Integration)을 수행하지 않고도 사용할 수 있는 디스커버리 인프라가 갖춰져 있다는 사실입니다.

이 부분이 AGTP 커머스를 양자 간 패턴에서 개방형 시장(Open Marketplace)으로 전환하는 핵심입니다. 에이전트는 역량(Capability)에 따라 가맹점을 찾을 수 있습니다. 가맹점은 사전 소개 없이도 발견될 수 있습니다. 프로토콜 수준의 디스커버리 계층을 기다려온 트랜잭션 접점(Transaction Surface)이 마침내 이를 갖게 된 것입니다.

양자 간 귀속 (Dual-party attribution)

모든 성공적인 구매(PURCHASE)는 양측 거래 상대방을 암호학적으로 명시하는 귀속 기록(Attribution-Record)을 생성합니다.

이 기록에는 에이전트의 Agent-ID, 본인의 Principal-ID, 가맹점의 Merchant-ID, 가맹점 매니페스트 지문(Merchant Manifest Fingerprint), 의도 주장(Intent Assertion)의 JTI, 방식(Method), 타임스탬프(Timestamp), 그리고 가맹점의 서명이 포함됩니다. 3년 후 이 기록을 추출하는 분쟁 조사관은 누가 행동했는지, 누가 승인했는지, 거래 상대방이 누구였는지, 어떤 특정 매니페스트 버전이 검증되었는지, 그리고 어떤 특정 의도가 주장되었는지에 대한 암호학적 증거를 갖게 됩니다.

이것이 바로 결제 네트워크들이 기다려온 감사 산출물(Audit Artifact)입니다. 에이전트가 시작한 트랜잭션의 양측 당사자를 명시하며 서명된 기록으로서, 분쟁 해결 프로세스가 AGTP를 직접 지원할 필요 없이 해당 프로세스에서 소비될 수 있습니다. 이 기록은 그 자체로 독립적인 효력을 가집니다.

가맹점(Merchant)에게 이 기록은 검증되고 승인된 의도(Intent)에 따라 물품이나 서비스를 인도했다는 증거가 됩니다. 에이전트의 본인(Principal)에게 이 기록은 구매 시점에 가맹점이 주장한 신원과 일치했다는 증거가 됩니다. 규제 기관(Regulator)에게 이 기록은 조사를 용이하게 만드는 기질(Substrate)이 됩니다.

이것이 변화시키는 것

에이전트에게 상거래는 검증 가능한(Verifiable) 영역이 됩니다. 구매를 수행하는 에이전트는 상대방에 대한 암호학적 확실성(Cryptographic certainty)을 가지며, 전송 단계에서 강제된 예산 제한(Enforced budget limits)을 적용받고, 하위 시스템(Downstream systems)이 수용할 수 있는 휴대 가능한 의도 증거(Portable evidence of intent)를 보유하게 됩니다.