에이전틱 결제(Agentic Payments): 지출 권한을 런타임(Runtime)으로 이동시키다

에이전틱 결제(Agentic payments)가 결제 권한의 주인이 정해지기도 전에 등장하고 있습니다.

LangChain Interrupt에서는 에이전틱 AI(agentic AI)를 위한 결제 문제, 즉 돈을 써야 하는 AI 에이전트를 어떻게 처리할 것인가에 대한 질문이 끊임없이 제기되었습니다. Privy는 결제 문제가 계속해서 발생하고 있다고 언급했습니다. Harrison Chase는 정적인 허용 목록(allowlists)보다 아마도 더 나은 방법으로 중앙 집중식 최소 권한(centralized least privilege), 감사 추적(audit trails), 그리고 동적 정책(dynamic policies)을 지목했습니다.

지갑이 서명하고, 런타임(runtime)이 결정합니다.

다시 한번 반복하겠습니다. 에이전틱 커머스(agentic commerce), 즉 결제를 수행하는 AI 에이전트와 관련하여 제기된 결제 문제는 바로 위임된 지출(delegated spend)입니다. 그리고 돈을 쓰는 것은, 설령 그것이 새로운 도구 호출(tool call)이라 할지라도, 단순히 또 다른 도구 호출이 아닙니다. 그것은 부채, 분쟁 경로, 예산 압박, 사용자 신뢰 문제, 조달의 기이함, 그리고 사후에 기업이 방어해야 할 감사 추적(audit trail)을 생성합니다.

지출 버그는 완벽한 UX를 가지고 있다

이러한 통합된 형태에서, 에이전트는 공급업체를 조사하고, 제안을 비교하며, 리소스를 예약하고, API나 기타 디지털 상품 및 서비스에 대해 결제하며, 고객에게 환불을 처리하거나, 인간이 이미 작업하고 있는 시스템 내부에서 여행을 예약할 수 있습니다. 따라서 이전에 언급했듯이, 통합된 에이전트(integrated agent)는 AI 기반 채팅보다 훨씬 더 강력합니다.

돈은 모호한 자율성(autonomy) 뒤에 숨겨져 있던 아키텍처의 부분을 드러냅니다.

에이전트가 통합된 워크플로(workflow) 내에서 명령을 실행하지 못하고, 대신 사람이 제어하는 결제 페이지(예: 구매를 위한 페이지)를 작성하게 되는 즉시, 해당 워크플로는 통합된 상태를 벗어나 순수하게 수동적인 작업으로 변한다는 점에 유의하십시오. 또한 에이전트에게 직접적인 지갑 접근 권한을 부여하여 사용자를 대신해 돈을 쓰게 하는 경우, 가장 최악인 점은 UI가 마치 사용자가 의도적으로 돈을 쓴 것처럼 보이게 만든다는 것입니다(예를 들어 멋진 진행 표시줄을 보여주는 식). 그러다 몇 주 뒤 재무 부서에 의해 프롬프트(prompt)가 잘못 입력되어 AI 에이전트가 돈을 사용했다는 사실이 밝혀질 때까지 말입니다.

프로토콜들이 빠르게 움직이고 있습니다. x402는 인터넷 네이티브 결제를 위한 개방형 결제 표준을 표방합니다. Coinbase는 x402를 인간 개발자와 AI 에이전트를 위한 계정 설정이나 수동 결제 흐름이 없는 HTTP 기반의 직접적인 프로그래밍 방식 결제(direct programmatic payments over HTTP)라고 설명합니다. Cloudflare의 Agents 문서는 다음과 같은 머신 투 머신(machine-to-machine) 흐름을 보여줍니다: 클라이언트가 유료 리소스를 요청하면, 402 Payment Required 응답을 받고, 서명된 결제 페이로드(payment payload)와 함께 재시도하여, 결제 완료 확인을 받습니다.

좋습니다. 에이전트를 위한 인터페이스는 결제 인터페이스를 포함하여 에이전트가 조작 가능한 인터페이스(agent-operable interfaces)여야 합니다. 이것이 바로 인간을 위한 결제 페이지가 자율적인 작업에 매우 부적합한 이유입니다.

요약하자면, 인터넷을 통해 리소스에 대한 비용을 지불할 수 있도록 만드는 어려운 작업들은 런타임(runtime, 즉 지출 정책)의 몫으로 남겨집니다. 즉, 어떤 에이전트가 이 지출을 요청했는지, 에이전트의 목적은 무엇인지, 관련 예산은 얼마인지, 어떤 가맹점/서비스가 범위 내에 있는지, 누가 지출 위임(delegation of spend)을 철회할 수 있는지, 지출을 승인할 인간은 누구인지, 돈을 지출한 결제 영수증이 어디에 기록될 것인지 등이 런타임에서 다뤄져야 합니다.

결제 의도(Payment Intent)는 런타임에 속해야 한다

핵심 객체는 결제 의도(payment intent)입니다.

에이전트(Agent)는 결제 권한(payment authority)을 전달하며 돌아다녀서는 안 되며, 결제 의도(payment intent)를 생성해야 합니다. 이 의도에는 행위자(actor), 작업(task), 가맹점/서비스(merchant/service), 금액(amount), 통화(currency), 목적(purpose), 예산(budget), 요청된 결제 수단(requested payment method), 수집된 증거(evidence gathered), 그리고 주 결제 수단이 실패했을 때를 대비한 폴백(fallbacks)이 포함되어야 합니다. 그러면 런타임 정책 엔진(runtime policy engine)이 자신의 규칙에 따라 결제 의도의 다음 단계(미터링된 API 호출에 대한 결제 자동 승인, 지원 담당자에게 고객 환불 지급, 신규 벤더에 대한 구매 부서 승인 요구, 의도된 작업이 아닌 트랜잭션 거부 등)를 결정합니다. 이러한 다음 단계는 '예', '아니오', '사람의 승인 요청', 또는 '티켓 생성'이 될 수 있습니다.

지갑(Wallet)은 에이전트 루프(agent loop) 내부가 아니라 런타임 정책(runtime policy) 뒤에 있어야 합니다.

돈은 지루한 것을 좋아하기 때문에, 이 이야기는 지루하게 들릴 수 있습니다.

런타임 지출 정책(runtime spending policy)에는 다음과 같은 몇 가지 명확한 필드가 필요합니다:

• 금액 및 통화 제한(Amount and currency limits).
• 가맹점 또는 서비스 범위(Merchant or service scope).
• 위임된 목적(Delegated purpose).
• 예산 기간(Budget window).
• 승인 임계값(Approval threshold).
• 지갑 또는 서명자 범위(Wallet or signer scope).
• 권한 취소 소유자(Revocation owner).
• 영수증 수신처(Receipt destination).

이는 Privy의 x402 기술 문서(Privy's x402 writeup gets close to this shape)에서 에이전트에 의해 정의되도록 요구되는 런타임 지출 정책과 대조될 수 있습니다. 해당 문서는 도메인별 지출 제한, 에이전트별 권한, 워크플로 수준의 승인, 그리고 오프라인 사용자 워크플로를 위한 세션 서명자(session signers)에 대해 다룹니다.

지갑 소유권이 실패 모드(Failure Mode)를 변화시킨다

지갑 아키텍처(Wallet architecture)는 여전히 중요합니다. 다만 훨씬 더 좁은 범위의 질문에 답할 뿐입니다.

Privy의 에이전틱 지갑 문서(agentic wallet docs)는 두 가지 제어 모델을 설명합니다: 백엔드 권한 키(backend authorization keys)로 제어되는 개발자 소유 지갑(developer-owned wallets), 그리고 사용자가 궁극적인 제어권과 취소 권한을 유지하면서 에이전트 서명자(agent signer)에게 범위가 제한된 정책(scoped policies)을 부여하는 사용자 소유 지갑(user-owned wallets)입니다.

데이터 보강(data enrichment), 유료 API, 크롤링 크레딧(crawl credits), 모델 호출(model calls) 또는 트랜잭션 수수료(transaction fees)와 같은 인프라 비용을 지불하는 백엔드 에이전트를 위한 개발자 소유 지갑입니다. 회사가 예산을 소유하고, 런타임(runtime)이 정책을 소유하며, 취소에 대한 운영 제어(operational control)만으로도 충분합니다(즉, 팀의 누군가가 관리 인터페이스에 로그인하여 에이전트를 취소할 수 있으면 됩니다).

에이전트 서명자를 포함하는 사용자 소유 지갑 또한 위임된 작업 모델(delegated action model)에 부합합니다. 이 경우, 사용자는 자신을 대신하여 작업을 수행하도록 타인에게 권한을 위임합니다. 이러한 사례에서 사용자는 자신의 워크플로우(workflow)에 자금을 공급하며, 에이전트 또는 서명자는 사용자를 대신하여 작업을 완료할 수 있도록 제한된 권한(bounded authority)을 부여받습니다. (이 경우, 사용자는 항상 에이전트나 서명자를 취소할 수 있는 능력을 갖추고 있어야 합니다).

제어 모델은 누가 자금을 소유하는지, 누가 액세스를 취소할 수 있는지, 그리고 정책이 어디에서 집행되는지를 결정합니다.

두 모델 모두 런타임 정책(runtime policy)이 필요합니다. 지출 제어가 없는 개발자 소유 지갑은 에이전트의 등에 테이프로 붙여놓은 회사의 법인 카드와 다를 바 없습니다. 범위가 제한된 위임(scoped delegation)이 없는 사용자 소유 지갑은 고객 분쟁으로 이어지기만을 기다리는 동의(consent) 문제로 변질됩니다.

승인 UI는 런타임 인프라입니다

승인은 런타임 상태 전이(runtime state transition)입니다. 모달(modal)은 단지 인간이 이를 확인하는 장소일 뿐입니다.

그렇기 때문에 에이전트 UI는 런타임 인프라(runtime infrastructure)에 속해야 합니다. 따라서 사용자가 지출 동작을 승인할 때, 사용자는 정책(policy)과 매칭된 제안된 트랜잭션(transaction)을 승인하는 것입니다. 에이전트가 사용한 증거, 예산에 미치는 영향, 그리고 부여되는 권한의 범위는 모두 지출을 승인하는 사용자에게 보여야 합니다. 사용자는 모호한 에이전트 계획(agent plan)이 아니라, 범위가 제한된 결제 의도(bounded payment intent)를 승인해야 합니다.

이것이 바로 모든 이들이 SDK 통합처럼 취급하여 결제가 단순히 "작동"하게만 만들려고 하는 부분입니다.

영수증이 신뢰보다 낫다

결제 기능이 있는 에이전트는 해당 결제 내역이 에이전트의 런타임(runtime) 내에서 일급 데이터(first-class data)로서 영수증으로 기록될 수 있는 방법을 갖춰야 합니다.

결제를 수행할 때, 결제 응답(payment response)은 에이전트가 수행한 나머지 작업과 동일한 스트림(stream)에 증거로서 다시 기록되어야 합니다. Cloudflare의 x402 플로우는 결제 확정 정보가 포함된 PAYMENT-RESPONSE 헤더로 종료됩니다.

이는 도구 호출(tool calls)에서도 마찬가지였습니다: 에이전트 트레이스(agent traces)는 작업의 경계를 넘나들어야 하며, 그 부수적인 효과로 트레이스의 가치가 훨씬 높아집니다. 결제의 경우, 그 부수적인 효과는 가치 이전(value transfer, 즉 계좌로 돈이 들어오거나 나가는 것)입니다. 따라서 가장 저렴한 동작을 제외한 모든 에이전트 작업의 트레이스에는 결제 영수증이 포함되어야 합니다.

원장(ledger)이 예쁘거나 화려할 필요는 없습니다. 원장은 수행된 작업에 대한 지루한 질문 세트에 답할 수 있어야 합니다.

• 에이전트가 무엇을 구매하려고 의도했는가?
• 어떤 정책(policy)이 이를 허용했는가?
• 어떤 서명자(signer)가 이를 실행했는가?
• 어떤 결제 망(rail)을 통해 정산되었는가?
• 승인이 필요했다면, 어떤 인간이 승인했는가?
• 어떤 작업(task), 티켓(ticket), 고객(customer) 또는 계정(account)이 영수증의 소유자인가?

카드 네트워크도 동일한 경계를 본다

기존 결제 네트워크(payment networks)가 이 문제를 어떻게 정의하고 있는지 주의 깊게 살펴봐야 합니다. 예를 들어, 암호화 기술로 구현된 Visa Intelligent Commerce는 에이전틱 체크아웃(agentic checkout)을 소비자가 온라인에서 자신의 카드를 관리할 수 있도록 승인된 AI "에이전트(agents)"를 중심으로 구성합니다. 반면 가맹점(merchants)의 경우, 사기/분쟁 보호(fraud/dispute protections), 가맹점 수락 여부, 그리고 특히 각 결제 컨텍스트(Visa 온라인, 앱 내 결제 등)에 대한 "거래 신뢰도(trust in transaction)"와 같은 유사하면서도 추가적인 요소들을 중심으로 정의하며, 이 모든 것은 이미 기존 결제 네트워크에 의해 처리되고 있습니다. PayPal 또한 최근 지갑에 결제 수단을 추가한 사용자를 대신하여 행동하는 AI 에이전트로부터 가맹점이 결제를 수락할 수 있도록, Mastercard의 Agent Pay를 PayPal 지갑에 통합한다고 발표했습니다 Mastercard Agent Pay will integrate with PayPal's wallet.

이것이 일반적인 패턴이 되기 전에 런타임 계층(runtime layer)이 권한 모델(authority model)을 소유해야 합니다.

지출 정책(Spending Policy)을 먼저 구축하라

결제 의도 스키마(payment intent schema)를 정의하십시오. 목적(purpose), 가맹점 범위(merchant scope), 금액(amount), 예산(budget), 요구되는 증빙(evidence required), 요구되는 승인(approval required), 서명자 범위(signer scope) 및 영수증 수신처(receipt destination)를 포함해야 합니다. 첫날부터 이를 하나의 객체(object)로 취급하십시오. 이는 백엔드 로직(backend logic)뿐만 아니라, 사람이 빈칸을 채워 승인하는 동작을 위한 양식 필드(form fields)를 생성하는 데에도 사용됩니다.

기업용 지갑(enterprise wallet) 서비스 그 이상의 결제 런타임 제어 경로를 확보하려면, 먼저 정책 엔진(policy engine)을 구현하고, 재무(Finance) 및 보안(Security) 부서가 이해할 수 있는 단순한 규칙으로 정책을 작성한 다음, 다양한 시나리오에 대해 테스트를 수행해야 합니다. 서비스 허용 목록(allowlists)은 첫 번째 입력값일 뿐이며, 목적, 예산 기간(budget window), 작업 소유자(task owner), 고객 계정(customer account) 및 승인 상태(approval state)가 모두 결제에 영향을 미칩니다.

승인을 런타임(Runtime) 이벤트로 만드세요: 승인은 결제 의도(payment intent)를 일시 중지하고, 정책 일치(policy match) 여부를 보여주며, 제한된 결정(bounded decision)을 캡처한 다음, 워크플로(workflow)를 재개하거나 거부해야 합니다. 즉, "에이전트 작업 승인"을 단순한 버튼으로 만들지 마세요.

거부 경로(denial paths)를 테스트하세요. 결제 시스템이 테스트할 수 있는 것이 성공적인 결제(settlement)뿐이라면, 그 팀은 이상한 금요일 오후를 요청하고 있는 것입니다. 결제 거부, 승인 만료, 서명자 권한 취소, 중복 재시도, 결제 실패, 분쟁 거래(disputed transaction), 예산 소진 모두가 일급 시민(first-class) 경로로 다뤄져야 합니다.

에이전틱 결제(Agentic payments)는 에이전트가 지정된 정책 내에서 데이터를 구매하고, API 호출 비용을 지불하며, 크레딧을 발행하고, 서비스를 예약할 수 있게 함으로써 에이전트가 유용하다고 느끼게 만들 것입니다. 그것이 진정한 업무입니다.

에이전트 런타임(Agent runtime)은 지출 제어 평면(spending control plane)이 됩니다.

기업들은 기존의 결제 "솔루션(solutions)"과는 다른 관점에서 시작하여, 모든 트랜잭션(transaction)에 대해 다음과 같은 단순한 질문들을 던짐으로써 에이전틱 결제를 올바르게 구현할 것입니다: 누가 지출을 위임하는가; 해당 지출에 어떤 정책이 적용되는가; 지출에 대한 승인은 어디로 위임되었는가; 그리고 어떤 영수증이 해당 트랜잭션이 비즈니스 목적이었음을 증명할 것인가.

그러고 나서 지갑(wallet)이 서명할 수 있습니다.