내 AI 에이전트가 스스로 결제하게 하려면 어떻게 해야 할까?

AI 에이전트(AI agents)는 무엇을 살지 결정할 수는 있지만, 대부분은 직접 결제할 수 없습니다. 에이전트에게 결제 권한을 부여하는 실질적인 방법들과 그에 따른 트레이드오프(tradeoffs), 그리고 작동하는 코드를 소개합니다.

당신은 에이전트에게 작업을 맡깁니다: 세 경쟁사의 최신 가격 정보를 가져와서 요약해달라는 작업입니다. 에이전트는 보고서를 찾아냅니다. 하지만 그 보고서는 4달러의 페이월(paywall) 뒤에 있습니다. 에이전트는 멈춰버립니다. 에이전트는 읽고, 추론하고, 계획할 수는 있지만, 결제 수단이 부여되지 않았기 때문에 체크아웃(checkout)을 완료할 방법이 없습니다.

반대의 실패 사례는 더 심각합니다. 에이전트가 필요한 것을 구매할 수 있도록 에이전트의 환경에 카드 번호를 붙여넣고 한 시간 동안 자리를 비웠더니, 당신이 승인하지 않은 결제 목록이 돌아와 있는 경우입니다.

두 가지 실패 모두 동일한 간극에서 발생합니다. 에이전트 결제의 어려운 점은 돈을 옮기는 것이 아닙니다. 에이전트에게 작업에 필요한 만큼만 결제할 수 있는 충분한 권한을 부여하되, 그 이상의 권한은 주지 않는 것입니다.

AI 에이전트가 결제하기 전에 무엇이 필요한가?

에이전트가 인간의 개입(human in the loop) 없이 결제하려면 다음 두 가지가 충족되어야 합니다:

프로그래밍 방식으로 사용할 수 있는 자격 증명(credential). 한 번 입력하고 끝나는 카드가 아니라, 자동화된 프로세스가 구매 시점에 제시할 수 있는 무언가가 필요합니다.
제한된 권한(Bounded authority). 돈이 움직이기 전에 해당 자격 증명이 사용할 수 있는 금액의 상한선(hard ceiling)을 설정하여, 자율성(autonomy)이 무분별한 지출로 이어지지 않도록 해야 합니다.

아래에서 설명할 방법들 사이의 대부분의 차이점은 각 방법이 두 번째 사항을 어떻게 처리하느냐에 달려 있습니다.

AI 에이전트가 결제할 수 있는 방법들

에이전트 기반 커머스(Agentic commerce)는 몇 가지 해답을 내놓았으며, 이들은 주로 에이전트가 사용할 수 있는 지출 범위를 어떻게 제한하느냐에 따라 달라집니다. 알아둘 가치가 있는 다섯 가지 방법은 다음과 같습니다:

1. 카드를 건네주는 방식. 가장 순진한 버전입니다. 실제 카드 번호를 에이전트의 컨텍스트(context)에 넣고 에이전트가 잘 행동하기를 바라는 것입니다. 작업별 한도도 없고, 가맹점 제한도 없으며, 자격 증명이 유출되거나 에이전트가 루프(loop)에 빠질 경우 전체 잔액이 노출됩니다. 또한 이는 대부분의 카드 프로그램 이용 약관을 위반합니다. 이 방법은 피하십시오.

2. 범위 제한 가상 카드 (Scoped virtual cards). 에이전트당 또는 작업당 하나의 가상 카드를 발급하되, 최대 한도(hard cap), 짧은 유효 기간, 그리고 선택적으로 가맹점 잠금(merchant lock)을 설정합니다. 에이전트는 카드를 수락하는 모든 가맹점에 결제할 수 있으며, 사용자의 노출 위험은 설정한 한도 내로 제한됩니다. 에이전트가 구매하는 항목이 일반적인 법정 화폐 (fiat) 세상에 존재할 때 유용합니다. 트레이드오프 (tradeoff)로는 카드 결제망 (card rails)과 발행사에 의존해야 하며, 카드가 통용되는 곳에서만 작동한다는 점이 있습니다.

3. 프로그래밍 가능한 지갑 (Programmable wallets) 및 스테이블코인 (stablecoins). 에이전트에게 수탁형 (custodial) 또는 스마트 컨트랙트 (smart contract) 기반의 지갑을 제공하되, 소량의 스테이블코인 잔액을 충전하고 지출 규칙에 따라 관리되도록 합니다. 결제는 USDC와 같은 자산으로 이루어집니다. API 및 기타 소프트웨어에 직접 비용을 지불할 때 유용합니다. 트레이드오프로는 상대방이 스테이블코인 결제를 수락해야 하므로, 일반적인 온라인 상점에서 구매하기보다는 기계 대 기계 (machine to machine) 통신에 더 적합하다는 점이 있습니다.

4. x402: HTTP를 통한 요청당 결제 (pay per request over HTTP). x402는 HTTP 402 Payment Required 상태 코드를 재사용하여, 어떤 엔드포인트(endpoint)라도 인라인으로 결제를 요청할 수 있게 합니다. 에이전트는 일반적인 요청을 보내고, 지불해야 할 금액이 기술된 402 응답을 받으면, 지갑에서 결제한 후 다시 시도합니다. 계정 가입, OAuth, API 키 교환이 필요 없습니다. 이는 호출당 API 및 MCP 도구 결제에 가장 깔끔하게 들어맞는 방식이며, 아래에 작동 예시가 있습니다.

5. 위임 기반 프로토콜 (Mandate based protocols). Google의 에이전트 결제 프로토콜 (Agent Payments Protocol, AP2) 및 Stripe의 공유 결제 토큰 (Shared Payment Tokens)과 같은 신흥 표준은 에이전트에게 구매가 허용된 범위 내로 제한된, 사전 승인된 자격 증명 (credential)을 부여합니다. 두 방식은 접근 방식이 다릅니다. AP2는 검증 가능한 위임 (verifiable mandate)으로 자격 증명을 뒷받침하는 반면, Stripe는 특정 구매에 범위가 제한된 토큰을 발행합니다. 두 방식 모두 사람이 한 번 범위를 승인하면 에이전트가 그 범위 내에서 거래하는 동일한 패턴을 목표로 합니다. 트레이드오프는 성숙도입니다. 생태계가 아직 형성 중이므로 지원이 고르지 않습니다.

에이전트가 단일 API 호출 비용을 어떻게 지불할까요?

x402가 시작점으로 훌륭한 이유는 결제 로직이 래핑된 (wrapped) fetch 안으로 사라지기 때문입니다. 에이전트 코드를 변경할 필요가 없습니다.

// npm install @x402/fetch @x402/evm viem
import { x402Client, wrapFetchWithPayment } from "@x402/fetch";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
...

엔드포인트(endpoint)가 결제를 요구할 때 발생하는 과정은 다음과 같습니다:

첫 번째 요청이 금액, 자산, 수취인 정보와 함께 402 Payment Required로 돌아옵니다.
래퍼(wrapper)가 해당 요구 사항을 읽고 결제 전에 금액을 확인합니다. 따라서 설정한 상한선(ceiling)을 초과하는 모든 요청은 거부할 수 있습니다.
지갑에서 결제에 서명(sign)하고, 결제 정보가 첨부된 요청을 다시 보냅니다.
엔드포인트가 이를 검증하고 리소스(resource)를 반환합니다.

해당 상한선이 바로 제한된 권한(bounded authority) 요소입니다. 지갑에 소액의 잔액을 충전하고, 요청당 한도를 초과하는 모든 결제는 거부하도록 설정하면 단 한 번의 호출로 지갑을 모두 소진할 수 없습니다. 전체 루프를 테스트해보고 싶다면, x402는 에이전트를 실제 대상에 연결하기 전에 로컬에서 바로 실행해 볼 수 있는 실행 가능한 구매자(buyer) 및 서버 예제를 제공합니다.

내 에이전트는 어떤 결제 방식을 사용해야 할까?

대략적인 결정 경로:

카드를 사용하는 일반 상인으로부터 구매해야 한다면? 범위가 지정된 가상 카드(Scoped virtual cards).
API, 도구 또는 다른 에이전트에게 호출당 비용을 지불해야 한다면? x402 또는 프로그래밍 가능한 지갑(programmable wallet).
사람이 예산을 한 번 승인하고 에이전트가 그 범위 내에서 거래하게 해야 한다면? 위임 기반 프로토콜(mandate based protocols)을 살펴보고, 현재 지원되는 프로토콜로 프로토타입을 제작하세요.

실제로는 이들을 혼합하여 사용하게 됩니다. 단일 에이전트가 법정 화폐(fiat) 구매를 위한 한도가 정해진 가상 카드와 API 호출을 위한 x402 지갑을 모두 보유할 수 있습니다. 번거로운 부분은 회계 처리(bookkeeping)입니다. 충전해야 할 대상이 두 개이고, 한도 설정도 두 세트이며, 실제로 무엇을 소비했는지 감사(audit)할 때 확인해야 할 곳도 두 군데입니다. FluxA가 바로 이 문제를 해결하기 위해 구축된 서비스입니다. 에이전트 지갑과 일회용 가상 카드를 제공하며, x402 및 AP2 지원이 하나의 지출 정책(spend policies) 뒤에 배치되어 있어 상한선(cap)을 세 곳이 아닌 한 곳에서 관리할 수 있습니다. 이러한 복잡한 인프라(plumbing)를 직접 구축하고 싶지 않다면, 바로 이것이 이러한 서비스를 이용해야 하는 이유입니다.

AI 에이전트의 과도한 지출을 어떻게 방지할 수 있을까?

에이전트는 눈앞에 놓인 작업의 규모보다 더 큰 결제 자격 증명 (payment credential)을 절대로 보유해서는 안 됩니다. 자율성 (Autonomy)은 돈이 이동한 후에 정산하는 것이 아니라, 돈이 이동하기 전에 지출 한도 (spending limit)가 강제될 때에만 안전합니다. 위에서 언급한 모든 접근 방식은 사실 하나의 질문에 대한 서로 다른 답변입니다: 정확히 어디에서 한도 (cap)가 강제되는가?

참고: 이 포스트의 일부는 AI 어시스턴트의 도움을 받아 초안을 작성한 후, 게시 전 검토 및 편집 과정을 거쳤습니다. 코드 예제를 신뢰하기 전에 직접 실행해 보시기 바랍니다.