저자: 스테이블헌터
지난주 홍콩에서 열린 웹3 페스티벌에 참석했는데, 거의 모든 포럼과 패널 토론이 인공지능(AI)을 중심으로 돌아간다는 매우 분명한 느낌을 받았습니다.
원래 논의가 결제, 스테이블코인, RWA, 지갑, 거래소, 규정 준수 및 인프라 등 어떤 주제에 초점을 맞췄든 간에, 결국에는 거의 항상 같은 질문으로 귀결됩니다. 인공지능이 단순히 콘텐츠를 생성하는 것을 넘어 작업을 수행하고, 서비스를 호출하고, 의사 결정을 내리고, 심지어 인간의 현금 흐름까지 관리하기 시작할 때, 기존의 금융 및 결제 시스템이 충분할까요?
제가 참석했던 패널 토론에서 누군가 직접적으로 " 웹3는 단순히 AI의 인기에 편승하는 것인가?"라고 질문했습니다. 저는 그렇게 생각하지 않습니다. 물론 유행에 편승하는 프로젝트들이 있을 것입니다. 하지만 AI와 웹3의 결합을 단순히 하나의 이야기로만 이해한다면, 더 근본적인 변화를 놓칠 수 있습니다. AI는 이해, 의사 결정, 그리고 행동을 담당하는 반면, 웹3는 자산, 회계, 결제, 그리고 검증 가능한 실행 환경을 제공합니다. 이는 단순히 개념들을 쌓아 올리는 것이 아니라, 역할의 재정의를 의미합니다.
폴 찬 모포 홍콩 재무장관은 웹3 페스티벌 2026 연설에서 AI 에이전트가 기계 속도로 정보를 분석하고 조치를 취하는 동시에 블록체인 인프라를 최대한 활용하여 거래 효율성을 높이고 금융, 무역, 자산 관리, 공급망 및 물류와 같은 시나리오를 재편할 것이라고 언급했습니다. AI가 활동을 시작할 때 중요한 것은 단순히 '지능' 그 자체뿐만 아니라 이러한 행동이 어떻게 승인되고, 정산되고, 기록되고, 책임지게 되는가입니다.
이러한 주제들 중에서 에이전트 기반 결제는 점점 더 무시하기 어려워지고 있습니다. 하지만 저는 처음에 아주 간단한 질문을 던졌습니다. 왜 사람들은 에이전트 기반 결제나 에이전트 기반 상거래에 대해 이야기할 때 그것을 암호화폐, 스테이블코인, 블록체인과 필연적으로 연결짓는 걸까요?
AI 에이전트는 은행 카드를 받을 수 없나요? 신용 카드는 받을 수 없나요? Apple Pay, Visa, Mastercard, Stripe 또는 PayPal은 받을 수 없나요?
만약 에이전트가 단순히 항공권 구매, 호텔 예약, 또는 SaaS 구독 갱신과 같은 간단한 업무를 처리해 준다면, 이론적으로 기존 결제 시스템을 충분히 활용할 수 있습니다. 사용자가 한 번만 승인하면, 에이전트는 은행 카드, 가상 카드, 법인 계좌 또는 제3자 결제 지갑을 사용하여 허용 한도 및 규칙 내에서 결제를 처리합니다. 이는 그다지 비합리적으로 들리지 않습니다.
그러므로 질문은 "은행 카드를 사용할 수 있습니까?"가 아닙니다. 물론 사용할 수 있습니다. 진짜 질문은 에이전트 결제의 어떤 부분에 은행 카드와 신용 카드가 적합하고 어떤 부분에 적합하지 않은가입니다. AI 에이전트가 실제로 은행 카드를 사용할까요? 그리고 에이전트 결제가 발전함에 따라 스테이블코인과 블록체인이 거의 필연적으로 포함되는 이유는 무엇일까요?
첫째, 결제는 은행 카드로 처리되며, 대리점 시스템은 관여하지 않습니다.
에이전트 기반 결제가 단순히 AI 에이전트가 항공권 구매, 호텔 예약, SaaS 구독 갱신과 같은 최종 결제 단계를 완료하는 것이라면, 백그라운드에서 은행 카드, 신용 카드, 가상 카드, Apple Pay, Stripe, PayPal 등을 사용하는 데 근본적인 장애물은 없습니다. 은행 카드도 물론 사용할 수 있고, 신용 카드도 문제없이 사용할 수 있습니다.
사용자가 사전 승인을 하면 담당자가 지정된 한도 및 규칙 내에서 결제를 실행합니다. 이는 이해하기 어렵지 않습니다. 본질적으로 더욱 스마트해진 자동 이체, 기업용 가상 카드, 여행 카드 또는 자동 구매 시스템과 유사합니다.
따라서 비자, 마스터카드, 스트라이프와 같은 기존 결제 업체들은 사라지지 않을 것입니다. 오히려 초기 에이전트 기반 상거래의 중요한 진입점이 될 수도 있습니다.
Stripe와 Tempo가 출시한 머신 결제 프로토콜(Machine Payments Protocol)이 바로 이 점을 잘 보여줍니다. 이 프로토콜은 스테이블코인에만 의존하지 않고, 판매자가 에이전트로부터 직접 결제를 받을 수 있도록 하며, 스테이블코인뿐 아니라 카드, 선구매(BNPL)와 같은 다른 법정화폐 결제 방식도 지원합니다. 다시 말해, 에이전트 결제 초기 단계에서는 기존 결제 방식과 스테이블코인이 공존할 가능성이 높으며, 어느 한쪽이 다른 쪽을 즉시 대체하지는 않을 것입니다. 하지만 이는 에이전트 기반 상거래의 한 측면, 즉 결제 과정만을 해결할 뿐입니다.
체크아웃은 제품, 판매자, 주문, 결제 버튼, 환불 및 분쟁 해결 프로세스가 이미 갖춰져 있다고 가정합니다. 상담원은 사용자가 구매를 보다 자동화된 방식으로 완료할 수 있도록 지원하기만 하면 됩니다.
진정한 문제는 다른 시나리오에서 발생합니다. 에이전트가 더 이상 미리 구성된 쇼핑 카트에 담는 방식이 아니라, 개방형 네트워크 내에서 지속적으로 리소스를 호출하고, 서비스를 결합하고, 작업을 완료하는 방식입니다. 예를 들어, AI 연구 에이전트가 산업 보고서를 작성하려면 여러 데이터베이스에 접근하고, 유료 문서를 구매하고, 다양한 모델 API에 액세스하고, 웹 크롤링 서비스를 호출하고, 차트 생성 도구 비용을 지불하고, 심지어 다른 에이전트로부터 분석 결과를 구매해야 할 수도 있습니다. 전통적인 "상점"이나 단일 결제 페이지가 존재하지 않을 수 있습니다. 대신 API, 데이터 인터페이스, 모델 서비스, 컴퓨팅 노드, 콘텐츠 리소스, 자동화 도구, 심지어 다른 에이전트와도 상호 작용해야 할 수 있습니다.
최근에 저도 비슷한 경험을 했습니다. 웹사이트 트래픽, 키워드, 경쟁사, 시장 동향 등을 분석하기 위해 필요에 따라 Semrush 같은 데이터 소스를 자동으로 호출하는 트래픽 분석 도우미를 만들고 싶었습니다. 하지만 실제로 개발을 시작하면서 깨달은 것은 "AI가 분석할 수 있을까?"가 아니라 "어떻게 데이터를 얻을까?"였습니다. 많은 상용 데이터 소스는 "일회성 호출, 일회성 결제, 즉시 결과 반환" 모델에 맞춰 설계되지 않았습니다. 예를 들어 Semrush의 API 시스템은 계정, 패키지, API 유닛 모델에 가깝습니다. 각 API 요청은 일정량의 API 유닛을 소모하며, 사용자는 이에 상응하는 API 접근 권한을 갖거나 API 유닛 패키지를 구매해야 합니다. Trends API도 개별 접근 권한 구매가 가능하지만, 데이터 요청에는 여전히 API 유닛이 필요합니다.
하지만 이러한 모델은 상담원에게는 적합하지 않습니다. 상담원이 트래픽 데이터에 가끔씩만 접근하면 된다면, SaaS 계정을 등록하거나 API 패키지 전체를 구매하는 것이 아니라 웹페이지에 접속하는 것처럼 "이 데이터는 얼마인가요? 제가 구매할 권한이 있나요?"라고 문의하는 것으로 충분합니다. 예산 범위 내라면 결제하고 즉시 결과를 얻을 수 있으면 됩니다.
이것이 바로 Agentic Payments와 기존 API 비즈니스 모델 간의 차이점입니다. 오늘날 많은 API는 여전히 "기계가 필요에 따라 리소스를 구매하는" 모델이 아닌 "인간 기업이 소프트웨어를 구매하는" 모델에 따라 가격이 책정되고 있습니다.
따라서 에이전트 결제의 문제는 최종 단계에서 결제 금액을 차감할 수 있는지 여부가 아니라, 기계가 전체 작업 과정에서 어떻게 지속적으로 승인을 얻고, 결제를 시작하고, 배송을 확인하고, 정산을 완료하는지에 있습니다.
이것이 은행 카드 시스템의 경계입니다.
은행 카드가 시대에 뒤떨어져서가 아니라, 원래는 소비 시나리오에 맞춰 설계되었기 때문입니다. 즉, 소비자가 상점에 들어가 상품을 선택하고 주문을 확정하고 결제를 완료하면, 은행, 카드사, 매입 대행사, 결제 서비스 제공업체가 승인, 정산, 위험 관리 및 분쟁 해결을 완료하는 방식입니다.
하지만 에이전트 경제는 또 다른 질문들에 직면합니다. 이 에이전트는 어떻게 이 돈을 쓸 권한을 갖게 된 것일까요? 서비스 제공자는 이것이 악의적인 봇이 아니라 사용자의 진정한 의도를 대변하는 존재임을 어떻게 확인할 수 있을까요? 에이전트는 매 단계마다 사람의 검증 없이 소액의 빈번한 플랫폼 간 결제를 처리할 수 있을까요? 서비스 제공자는 결제를 받은 후 즉시 해당 자원을 제공할 수 있을까요? 에이전트가 실수를 하거나, 권한을 남용하거나, 공격을 받을 경우 누가 책임을 져야 할까요?
이러한 이유로 구글은 AP2를 개발할 때 "어떤 결제 방식을 사용할 것인가"에 초점을 맞추기보다는 보다 보편적인 에이전트 결제 신뢰 프레임워크에 집중했습니다. 구글의 공식 설명에 따르면 AP2는 사용자, 판매자, 결제 서비스 제공업체가 다양한 결제 방식을 통해 에이전트 기반 결제를 안전하게 완료할 수 있도록 하는 결제 방식에 구애받지 않는 프레임워크입니다. AP2 사양은 또한 에이전트가 사용자를 대신하여 작업을 수행하기 위한 범위 지정 권한을 안전하고 간편하게 획득해야 한다고 명시하고 있으며, 프로토콜의 보안은 사용자와 판매자가 관련 정보를 암호화 서명하는 데 기반합니다.
그러므로 대리인 지불에 관한 첫 번째 질문은 "돈은 어디에서 오는가?"가 아니라 "대리인이 이 돈을 쓸 권리는 어디에서 오는가?"입니다.
은행 카드 시스템은 이 문제의 일부를 해결할 수 있습니다. 예를 들어, 가상 카드, 토큰화된 자격 증명, 신용 한도 관리, 기업 경비 관리 및 위험 관리 규칙을 통해 담당자는 기존 가맹점 시스템 내에서 거래를 완료할 수 있습니다.
Visa 역시 이러한 방향으로 나아가고 있습니다. Visa의 지능형 상거래 및 신뢰 에이전트 프로토콜은 기본적으로 AI 에이전트를 식별하고 신뢰하여 기존 가맹점 네트워크 내에서 소비자 또는 기업을 대신하여 거래를 완료할 수 있도록 합니다. Visa 개발자가 설명하는 신뢰 에이전트 프로토콜은 다음과 같습니다. AI 에이전트는 사용자가 가맹점 웹사이트를 탐색하고, 제품을 찾고, 가격을 비교하고, 선택을 내리는 데 도움을 주며, 이러한 비즈니스 여정은 결제 훨씬 이전부터 시작됩니다. 과거에는 이러한 자동화된 접근이 가맹점, CDN 또는 봇 차단 서비스에 의해 봇으로 차단되는 경우가 많았습니다.
이는 기존 결제 네트워크 역시 동일한 문제를 인식하고 있음을 보여줍니다. 에이전트 기반 상거래는 결제 버튼을 클릭하는 순간뿐만 아니라 검색, 비교, 선택, 승인, 최종 결제에 이르는 전체 과정에서 발생합니다. 카드 네트워크는 에이전트가 기존 상거래 흐름에 통합되어 승인된 거래를 완료하는 방법을 해결하는 데는 탁월하지만, 개방형 네트워크 내에서 에이전트가 API, 데이터, 모델, 컴퓨팅 파워, 콘텐츠, 도구 및 다른 에이전트에 대한 소액 결제를 지속적으로 시작하는 방법에 대해서는 자연스럽게 다루지 않습니다.
따라서 은행 카드는 나쁜 해결책이 아닙니다. 더 정확히 말하면, 은행 카드는 에이전트 커머스의 결제 문제를 해결해 주지만, 에이전트 커머스에는 보다 근본적인 결제 프로토콜이 필요합니다.
이로써 다음과 같은 질문이 제기됩니다. 거래 상대방이 기존의 판매자가 아니라 API, 모델, 데이터 인터페이스 또는 다른 에이전트인 경우, 기기 간 결제는 어떻게 시작하고 완료해야 할까요? 바로 이러한 이유로 x402, L402, T402와 같은 프로토콜이 논의되기 시작했습니다.
둘째, 에이전트에게 진정으로 필요한 것은 기계가 읽을 수 있는 결제 프로토콜입니다.
거래 상대가 기존 가맹점이라면, 담당자는 기존 결제 흐름에 접근하여 신용카드, 직불카드, 가상카드 또는 전자지갑을 사용하여 결제를 완료할 수 있습니다. 그러나 거래 상대가 가맹점이 아닌 API, 모델, 데이터 인터페이스, 콘텐츠 리소스 또는 다른 담당자라면 상황이 달라집니다.
이 시점에서 기계에 필요한 것은 "결제 버튼"이 아니라 기계가 이해할 수 있는 결제 프로세스입니다. 에이전트가 리소스를 요청하면 서비스 제공자는 해당 리소스에 대한 결제, 가격, 수령 주소 및 지원되는 결제 방법을 에이전트에게 알려줍니다. 에이전트는 결제가 사용자의 권한 범위 내에 있는지 판단하고, 허용된다면 결제를 완료합니다. 결제를 확인한 후 서비스 제공자는 즉시 리소스를 제공합니다.
이 과정은 간단해 보이지만, 사실 인터넷이 오랫동안 결여해왔던 기능, 즉 자체 결제 계층이라는 공백을 메워줍니다. 과거 인터넷은 정보의 흐름을 자연스럽게 지원했습니다. 웹 페이지를 요청하고, 이메일을 보내고, API를 호출하고, 파일을 다운로드할 수 있었습니다. 하지만 "결제"는 일반적으로 인터넷 프로토콜 자체의 일부가 아니었고, 계정 등록, 은행 카드 연결, 결제 게이트웨이 연결, 서비스 요금제 구매, API 키 관리, 월말 계정 정산 등과 같이 다른 시스템으로 분리되어 처리되는 경우가 많았습니다.
이는 사람에게는 감당할 수 있는 수준입니다. 사람은 회원가입, 로그인, 카드 연동, 신청서 승인, 구매, 환급 청구 등을 할 수 있습니다. 하지만 상담원에게는 이 과정이 너무 번거롭습니다.
상담원은 API 호출마다 계정을 등록하거나, 데이터 접근 시마다 전체 데이터 요금제를 구매하거나, 몇 센트 또는 몇 십 센트 정도의 소액 호출에 대해 사람이 직접 결제하고 구매하는 복잡한 과정을 거칠 필요가 없습니다. 바로 이러한 이유로 x402와 같은 프로토콜이 존재하는 것입니다.
x402 프로토콜은 오랫동안 존재했지만 거의 사용되지 않았던 HTTP 402 결제 필요 상태 코드를 다시 활성화합니다. 이를 통해 서비스는 HTTP 계층에서 클라이언트에게 "이 리소스에 접근하려면 결제해야 합니다"라고 직접 알릴 수 있습니다. 클라이언트는 사람일 수도 있고 기계일 수도 있습니다. 결제가 완료되면 서비스는 결제를 확인한 후 해당 API, 콘텐츠 또는 디지털 서비스를 반환합니다. 코인베이스는 x402를 간단히 정의합니다. x402는 HTTP를 통해 즉시 자동 스테이블코인 결제를 위한 개방형 프로토콜로, 사람과 기계 클라이언트가 계정, 세션 또는 복잡한 인증 없이 프로그래밍 방식으로 결제하고 접근 권한을 얻을 수 있도록 합니다.
여기서 진짜 중요한 것은 코인베이스를 사용할지 말지, 또는 USDC를 반드시 사용해야 하는지가 아닙니다. 진정으로 중요한 것은 x402가 결제 기능을 인터넷의 요청-응답 흐름에 다시 통합한다는 점입니다. 이전 글:
먼저 계정을 등록하세요.
다른 패키지를 구매하세요.
API 키를 다시 받으세요.
그런 다음 해당 서비스에 다시 전화하세요.
우리는 월말에 회계 장부를 대조할 것입니다.
x402는 다음과 같이 되고 싶어합니다:
리소스를 요청합니다.
402 결제 필요 오류가 발생했습니다.
결제가 완료되었습니다.
자원을 확보하세요.
이는 에이전트 결제에 매우 중요합니다. 왜냐하면 에이전트 거래는 몇 건의 대규모 구매가 아니라, 수많은 소규모 실시간 온디맨드 서비스 호출로 이루어지기 때문입니다.
작가 에이전트는 기사 작성을 위해 데이터 조회 서비스를 한 번 구매할 수 있습니다.
투자 조사 담당자는 특정 질문에 대해 온체인 분석 서비스를 한 번 호출할 수 있습니다.
여행사는 여러 가격 API에 동시에 견적을 요청할 수 있습니다.
개발 담당자는 사용량에 따라 모델 추론, 코드 검토 또는 테스트 환경을 구매할 수 있습니다.
트래픽 분석 담당자는 전체 SaaS 패키지를 먼저 구매하는 대신 특정 웹사이트에 필요한 Semrush 유형의 데이터를 한 번만 구매하기를 원할 수도 있습니다.
모든 서비스에 계정, 구독, API 키, 요금제, 수동 승인이 필요하다면, 에이전트의 실행 능력은 결제 및 조달 프로세스로 인해 제약을 받게 됩니다. 따라서 x402의 의미는 결제를 "더욱 암호화폐화"하는 것이 아니라, 인터넷 프로토콜처럼 요청 가능하고, 반환 가능하며, 검증 가능하고, 자동화된 방식으로 만드는 데 있습니다.
L402도 비슷한 노선입니다.
이 기술 역시 HTTP 402를 중심으로 하지만, 접근 자격 증명과 비트코인 라이트닝 네트워크, 마카롱과 같은 소액 결제 방식을 통합합니다. 라이트닝 랩스는 L402를 다음과 같이 정의합니다. API 엔드포인트 및 컴퓨팅 리소스와 같은 서비스의 인증 및 거래를 용이하게 하고, 서비스가 API 엔드포인트에 요금을 부과할 수 있도록 하여 AI 에이전트의 참여를 더욱 간편하게 만듭니다.
L402 오류는 이 문제가 x402에서 갑자기 나타난 것이 아님을 시사합니다. 사람들은 오래전부터 HTTP 접근 제어, 소액 결제, 디지털 서비스 권한이라는 세 가지 요소를 결합하려고 시도해 왔습니다. 다만 과거에는 이러한 기능에 대한 수요가 충분하지 않았을 뿐입니다.
일반 사용자는 API 엔드포인트에 접근하는 데 비용을 전혀 지불하지 않습니다. 하지만 에이전트는 지불합니다. 사람은 하루에 수백 개의 데이터 소스를 자동으로 호출하지 않습니다. 하지만 에이전트는 합니다. 사람은 여러 서비스에 걸쳐 통화, 견적, 결제 및 배송 확인을 실시간으로 통합하여 작업을 완료하지 않습니다. 하지만 에이전트는 합니다.
따라서 AI 에이전트의 등장으로 HTTP 기반 결제 방식이 갑자기 의미를 갖게 되었습니다.
USDT/테더 생태계에서도 유사한 추세가 나타나고 있습니다. 테더 WDK x402 문서에서는 AI 에이전트가 리소스 비용을 프로그래밍 방식으로 지불해야 하므로 x402가 필수적이라고 명시적으로 언급하고 있습니다. x402는 웹 스택에서 결제를 핵심 기능으로 만들어 에이전트가 단일 요청-응답 주기 내에서 가격을 확인하고, 결제에 서명하고, 리소스를 획득할 수 있도록 합니다. t402 프로젝트는 또한 암호화폐, 법정화폐, 스테이블코인, 토큰 등 다양한 가치 형태를 지원하고 테더 WDK와 호환되는 것을 목표로 하는 인터넷 기반 결제를 위한 개방형 표준이라고 스스로를 설명합니다. 하지만 여기서 주의할 점은 x402가 "공식 테더 표준이 되었다"라고 직접적으로 말하는 것은 적절하지 않다는 것입니다. 더 정확하게는 USDT/테더 생태계 내에서 x402와 유사한 프로토콜 탐색이 진행되고 있다고 표현하는 것이 좋습니다.
이러한 현상의 배경에는 주목할 만한 추세가 있습니다. 에이전트 기반 결제는 개별 기업 제품 간의 경쟁이 아니라 새로운 프로토콜 스택의 형성에 관한 것입니다.
AP2는 "대리인이 지불을 할 수 있도록 승인해야 하는 근거는 무엇인가?"라는 질문에 대한 답을 제시하는 것 같습니다.
x402, L402, T402와 같은 프로토콜은 에이전트가 디지털 리소스를 요청할 때 서비스 제공자가 어떻게 결제 요청을 시작하고, 에이전트가 어떻게 결제를 완료하고 리소스를 획득하는지에 대한 질문에 답하는 것과 같습니다.
스테이블코인과 블록체인은 다음과 같은 질문에 대한 해답과 같습니다. 이 자금은 궁극적으로 어떤 자산으로 결제될 것인가? 어디에서 검증될 것인가? 그리고 어떻게 하면 저비용, 실시간, 프로그래밍 가능, 크로스 플랫폼으로 구현될 수 있는가?
따라서 에이전트 기반 결제와 암호화폐가 함께 논의되는 이유는 웹3가 AI에 편승하려는 시도 때문이 아닙니다. 더 정확히 말하면, 에이전트 기반 결제가 인터넷이 과거에 해결하지 못했던 "결제의 본질적인 특성" 문제를 다시금 전면에 내세웠기 때문입니다.
정보는 인터넷상에서 자연스럽게 흐를 수 있지만, 장기적으로 가치는 그렇게 흐르지 않습니다. 에이전트의 등장으로 인터넷은 이러한 공백을 메워야 하는 상황에 놓였습니다.
이것이 바로 x402, L402, T402와 같은 프로토콜에 주목할 가치가 있는 이유입니다. 이러한 프로토콜은 단순히 "AI가 암호화폐로 결제하도록 허용하는 것"을 의미하는 것이 아니라, 새로운 상호작용 방식을 정의하려는 시도입니다.
기계는 자원을 요청하고, 가격을 이해하고, 권한을 확인하고, 결제를 완료하고, 서비스를 받습니다. 은행 카드가 결제 과정을 해결한다면, 이러한 프로토콜들은 다음과 같은 문제를 해결합니다.
기계는 어떻게 결제를 시작할까요? 이 질문에 대한 답을 찾으면 스테이블코인과 블록체인은 단순한 결제 도구를 넘어, 에이전트 기반 결제의 핵심 결제 언어 및 실행 환경이 됩니다.
III. 왜 스테이블코인인가? 투자자들은 변동성이 큰 자산이 아닌 안정적인 회계 단위를 필요로 한다.
만약 에이전트들이 정말로 기계가 판독하고 자동으로 실행되는 결제 프로토콜이 필요하다면, 왜 스테이블코인이 가장 많이 논의되는 주제일까요? 왜 비트코인(BTC)이나 이더리움(ETH)이 아닐까요? 일반 은행 카드는 왜 아닐까요?
여기서 핵심은 '암호화 자산' 그 자체가 아니라, 에이전트가 실제로 필요로 하는 결제 수단이 무엇인지입니다. 에이전트가 단순히 자산을 장기 보유하는 경우라면 가격 변동, 수익률, 위험 노출에 관심을 가질 수 있습니다. 하지만 에이전트가 특정 업무 수행에 대한 대가를 받는 경우라면 투기성 자산보다는 안정적인 회계 단위가 주된 필요가 됩니다.
리서치 담당자는 데이터 API 호출 한 번에 0.10달러를 지출할 수 있습니다. 코딩 담당자는 모델 추론 호출 한 번에 0.03달러를 지출할 수 있습니다. 마케팅 담당자는 트래픽 데이터 구매 한 건에 1달러를 지출할 수 있습니다. 가격을 자동으로 비교하고, 주문하고, 결제하는 구매 담당자는 예산 범위 내에서 모든 지출을 관리해야 할 수도 있습니다.
이러한 시나리오에서 에이전트는 거래를 하거나 암호화폐를 거래하는 것이 아니라, 특정 작업을 완료하는 것입니다. 따라서 에이전트는 다음과 같은 사항을 알아야 합니다. 이 리소스 사용에 드는 비용은 얼마인가? 이 호출로 예산을 초과할 가능성은 없는가? 이 결제는 사용자의 승인 범위 내에 있는가? 서비스 제공 후 비용을 정확하게 기록할 수 있는가?
결제 자산 자체의 가격이 매일 크게 변동한다면, 에이전트의 예산 관리가 매우 복잡해집니다. 오늘 API 호출 비용이 0.10달러이지만, 내일은 가격 변동으로 인해 0.12달러 또는 0.08달러가 될 수도 있습니다. 이는 거래 시장에서는 큰 문제가 되지 않을 수 있지만, 시스템의 온디맨드 리소스 구매 과정에 불필요한 복잡성을 더합니다.
이러한 이유로 Agentic Payments에서는 변동성이 높은 암호화폐 자산보다는 스테이블코인이 더 자연스럽게 찾아볼 수 있습니다.
스테이블코인의 가장 큰 가치는 실제 상거래 환경을 더욱 잘 반영하는 회계 단위를 제공한다는 데 있습니다. 오늘날 수많은 API, SaaS, 데이터 서비스, 모델링 서비스 및 클라우드 서비스가 미국 달러로 가격이 책정됩니다. 에이전트가 이러한 서비스를 필요에 따라 구매하고자 할 때, 미국 달러 스테이블코인을 결제 자산으로 사용하면 예산, 가격, 승인 및 청구서를 동일한 단위로 직접 관리할 수 있습니다.
언뜻 평범하게 들릴지 모르지만, 상담원에게는 매우 중요한 부분입니다. 상담원은 단순히 "비용을 지불"하는 것뿐만 아니라 여러 가지 판단을 내려야 하기 때문입니다. 통화가 가치 있는 것인지, 예산이 충분한지, 사용자 확인이 필요한지 등을 판단해야 합니다. 또한 작업 비용을 기록하고, 오류가 발생했을 경우에는 비용 지출 이유를 설명해야 합니다.
따라서 에이전트 기반 결제에는 프로그램에서 직접 호출할 수 있는 변동성이 낮고 기계 판독이 가능한 결제 자산이 필요합니다. 스테이블코인은 비트코인이나 이더리움과 같은 변동성이 큰 자산보다 이러한 요구 사항에 더 가깝습니다.
두 번째 가치는 스테이블코인이 소액 거래, 빈번한 거래, 그리고 즉각적인 결제에 더 적합하다는 점입니다. 이러한 경향은 앞서 x402에 대해 논의할 때 이미 드러났습니다. 코인베이스는 x402를 HTTP를 통한 즉각적이고 자동화된 스테이블코인 결제를 가능하게 하는 기술로 정의하며, 이를 통해 API, 디지털 콘텐츠 및 서비스는 계정, 세션 또는 복잡한 인증 없이도 사람과 기계 클라이언트 모두로부터 결제를 받을 수 있다고 설명합니다. 이 설명에는 중요한 변화가 숨어 있습니다. 더 이상 결제가 전체 결제 페이지 내에서 이루어질 필요 없이, 단 하나의 API 요청으로 처리될 수 있다는 것입니다.
에이전트가 리소스를 요청합니다. 서비스 제공자는 402 Payment Required 응답을 반환합니다. 에이전트는 가격과 권한을 확인합니다. 에이전트는 스테이블코인으로 결제합니다. 서비스 제공자는 검증 후 리소스를 제공합니다.
이 프로세스는 소량, 고빈도, 온디맨드 호출과 관련된 시나리오에 적합합니다. 예를 들어 데이터 쿼리, 모델 호출, 콘텐츠 잠금 해제, 온체인 분석 및 차트 생성 등이 있습니다. Tether WDK의 x402 문서에서도 이를 명확히 언급하고 있습니다. AI 에이전트는 리소스 비용을 프로그래밍 방식으로 지불해야 하며, x402를 통해 에이전트는 단일 요청-응답 주기 내에서 가격을 확인하고, 결제에 서명하고, 리소스를 획득할 수 있습니다.
이는 은행 카드와 같은 사용 맥락에서 사용되는 것이 아닙니다. 은행 카드는 사람이 직접 결제하는 매장 결제에 더 적합합니다. 스테이블코인은 기계가 자원에 접근할 때 즉시 결제되는 자산으로 더 적합합니다. 물론 이것이 은행 카드가 사라진다는 것을 의미하는 것은 아닙니다. Stripe와 Tempo의 기계 결제 프로토콜(MPP)은 두 가지 결제 방식을 명시적으로 지원합니다. 하나는 온체인 직접 암호화폐 결제이고, 다른 하나는 카드나 지갑과 같은 법정화폐 결제입니다. Stripe는 또한 판매자가 MPP를 통해 에이전트로부터 스테이블코인과 카드, BNPL(선구매 후결제)과 같은 법정화폐 결제 방식을 모두 사용하여 결제를 받을 수 있다고 언급합니다.
따라서 "스테이블코인이 은행 카드를 대체하고 있다"는 평가보다는 "은행 카드는 기존 가맹점 네트워크 및 결제 시나리오에 적합하고, 스테이블코인은 개방형 네트워크의 기계 결제 시나리오에 더 적합하다"는 평가가 더 정확합니다.
세 번째 가치는 스테이블코인이 플랫폼 간 및 국경 간 거래에 본질적으로 적합하다는 점에 있습니다. 에이전트는 반드시 단일 플랫폼에서만 운영될 필요는 없습니다. 한 에이전트는 다른 에이전트와 거래하기 위해 미국 데이터 API, 유럽 모델 서비스, 아시아 콘텐츠 인터페이스, 온체인 분석 도구 등을 활용할 수 있습니다. 각 계층이 서로 다른 국가의 은행 계좌, 인수 기관, 현지 결제 방식, 정산 주기에 의존한다면 전체 작업 체인은 결제 시스템에 의해 파편화될 것입니다. 그러나 스테이블코인은 인터넷 자산으로서 24시간 내내 유통될 수 있고, 다양한 플랫폼, 지갑, 애플리케이션에서 접근 가능하며, 스마트 계약이나 결제 프로토콜을 통해 직접 처리될 수 있습니다. 일반 사용자에게는 단순히 "더 빠른 정산"을 의미할 수 있지만, 에이전트에게는 그 의미가 훨씬 더 큽니다. 에이전트의 거래 실행은 은행 영업시간에 구애받지 않기 때문입니다.
주말, 국경 간 거래, 은행 결제 시간 또는 가맹점 계정 시스템에 의해 중단되어서는 안 됩니다. 필요한 것은 즉시 사용 가능하고, 자동으로 실행되며, 검증 가능한 결제 자산입니다.
이러한 이유로 x402, Tether WDK의 x402 지원, 그리고 USDT/Tether 생태계를 둘러싼 t402 탐구는 모두 같은 방향으로 나아가고 있습니다. 즉, 스테이블코인 결제를 에이전트가 먼저 사람이 설계한 결제 페이지를 거치지 않고 기계가 직접 호출할 수 있는 웹 스택 구성 요소로 전환하는 것입니다.
하지만 이에 찬물을 끼얹을 필요가 있습니다. 스테이블코인에도 문제점이 없는 것은 아닙니다.
다양한 스테이블코인은 준비금 투명성, 발행 주체, 규제 상태, 상환 기능 및 온체인 유동성 측면에서 차이가 있습니다. 영국 증권거래위원회(BIS)는 2025년 연례 경제 보고서에서 스테이블코인이 단일성, 탄력성, 무결성과 같은 핵심 통화 시스템 기준에 미치지 못하며 현대 통화 시스템의 완전한 대안으로 간주되어서는 안 된다고 명시적으로 비판했습니다.
더 정확하게 말하자면, 스테이블코인은 완벽한 화폐는 아니지만, 현재 에이전트 기반 결제의 요구 사항을 가장 잘 충족하는 인터넷 기반 결제 자산 중 하나입니다.
그 가치는 "탈중앙화 담론" 자체에 있는 것이 아니라, 상대적으로 안정적인 가격, 프로그래밍 가능한 기능, 플랫폼 간 전송 기능, 연중무휴 24시간 정산 기능, 그리고 HTTP 기반 결제, 지갑, 스마트 계약 및 온체인 감사와의 통합 등 여러 조건을 동시에 충족한다는 사실에 있습니다.
에이전트 기반 결제에서 개방형 네트워크의 리소스 사용량을 논할 때 스테이블코인이 자연스럽게 떠오르는 이유가 바로 여기에 있습니다. 에이전트에게 필요한 것은 "카드를 긁을 수 있는 손"이 아니라 소프트웨어가 직접 이해하고 사용할 수 있는 화폐 형태이기 때문입니다.
신용카드가 인간이 사용할 수 있도록 설계된 결제 수단이라면, 스테이블코인은 기계 경제를 위해 준비된 결제 언어와 더 유사합니다.
물론 이 언어는 아직 미성숙합니다. 더 나은 규정 준수 체계, 더욱 안정적인 발행 메커니즘, 명확한 위험 관리, 그리고 더욱 포괄적인 지갑 권한 관리가 필요합니다. 또한 에이전트 기반 결제 시나리오를 대규모로 활용하기 위해서는 AP2, x402, MPP와 같은 프로토콜과의 통합도 필수적입니다.
하지만 방향은 분명합니다. 에이전트는 안정적인 가격 단위, 즉시 정산 자산, 프로그램에서 호출할 수 있는 자금, 그리고 플랫폼, 국경 및 서비스 전반에 걸친 결제 기능을 필요로 합니다.
이것이 바로 스테이블코인이 에이전트 기반 결제에 필수적인 이유입니다. 모든 결제가 암호화폐 결제로 바뀌어야 한다는 의미가 아니라, 스테이블코인은 거래 대상이 '인간 소비자'에서 '소프트웨어 주체'로 바뀔 때 '돈'이 인터넷 프로토콜의 일부처럼 느껴지도록 만들어주기 때문입니다.
스테이블코인은 단 하나의 질문, 즉 에이전트가 결제에 어떤 화폐를 사용하는지에 대한 답만 제시합니다. 하지만 또 다른 질문에는 답하지 못합니다. 에이전트가 개방형 네트워크에서 돈을 지출한 후, 누가 그 지출을 승인했는지, 어디에 사용되었는지, 권한 남용은 없었는지, 그리고 서비스가 제대로 제공되었는지에 대한 질문입니다. 이러한 질문에 대한 답을 찾기 위해 블록체인이 필요합니다.
IV. 블록체인이 필요한 이유는 무엇일까요? 단순히 데이터를 기록하는 것뿐만 아니라, 행위자의 행동을 검증 가능하게 만들기 위해서입니다.
에이전트가 스테이블코인 결제를 필요로 한다고 해도, 왜 꼭 블록체인이어야 할까요? 중앙 집중식 원장은 안 될까요? 스트라이프, 비자, 은행, 또는 자체적으로 기록을 관리하는 플랫폼은 안 될까요?
물론입니다. 에이전트가 아마존에서만 쇼핑하거나, 특정 SaaS 플랫폼 내의 서비스만 이용하거나, 기업 내부 시스템 내에서만 구매하는 등 폐쇄적인 플랫폼 내에서만 활동하는 경우라면 중앙 집중식 원장이 충분합니다. 플랫폼 자체가 사용자, 에이전트, 권한, 지출 금액, 서비스 제공 여부 등을 모두 파악하고 있기 때문입니다.
하지만 에이전트 결제의 진정한 매력은 단순히 에이전트가 폐쇄된 플랫폼 내에서 결제 버튼을 클릭하는 데 그치지 않습니다. 플랫폼, 서비스, 지갑, 국가, 심지어 서로 다른 에이전트를 넘어서까지 작업을 완료할 수 있다는 점이 핵심입니다. 이 단계에서는 단순히 "돈이 지급될 수 있을까?"라는 질문이 아니라, 왜 돈이 지급되는지, 누가 승인했는지, 에이전트가 권한을 남용했는지, 서비스 제공업체가 실제로 결제를 처리했는지, 그리고 오류 발생 시 책임 소재는 어디인지 등이 중요한 문제로 대두됩니다.
이러한 질문들은 에이전트 결제에서 블록체인의 진정한 가치를 부각시켜 줍니다. 모든 거래가 블록체인에 기록되어야 하거나 온체인 거래가 은행 거래보다 본질적으로 더 발전된 방식이어서가 아니라, 에이전트가 작업을 수행하고, 서비스를 호출하고, 자금을 처리할 때 취하는 모든 경제적 행위에는 검증 가능한 기록이 필요하기 때문입니다.
인간은 결제 과정에서 상당한 불투명성을 감수할 수 있습니다. 서비스를 구매했는데 받지 못하면 고객 서비스에 문의할 수 있고, 회사 조달에 문제가 생기면 계약서를 확인하고 재무팀과 이야기하고 이메일을 확인하고 회의를 열어 논쟁할 수 있습니다. 신용카드 결제가 잘못되면 은행에 가서 이의를 제기할 수 있습니다. 이러한 메커니즘은 다소 번거로울 수 있지만, 인간 사회는 오랫동안 이러한 방식으로 운영되어 왔습니다.
에이전트마다 상황이 다릅니다. 에이전트는 거래 빈도가 높을 수도 있고, 거래 금액이 적을 수도 있으며, 서비스 제공업체가 더 많을 수도 있고, 실행 과정이 더 길 수도 있습니다. 모든 거래에 대해 수동 사후 검증, 스크린샷 촬영, 이메일 대조, 고객 서비스 문의 등이 필요하다면 Agentic Payment의 의미는 사라집니다. 따라서 에이전트에게 필요한 것은 더 멋진 지갑이 아니라 더 명확한 책임 연쇄 구조입니다.
예를 들어, 사용자가 상담원에게 다음과 같은 작업을 지시합니다. "이번 주에 최대 100달러를 사용하여 데이터, 모델 호출 및 차트 생성 서비스만 구매하는 시장 분석을 수행해 주세요." 상담원은 데이터 API를 요청하고, 서비스 제공업체는 해당 쿼리에 대한 대가로 0.20달러를 반환합니다. 상담원은 이 금액이 예산 범위 내에 있다고 판단하고 결제를 완료합니다. 서비스 제공업체는 금액을 받은 후 데이터를 제공합니다. 이 과정에서 진정으로 중요한 것은 "어떤 블록체인을 사용했는지"가 아니라, 다음과 같은 몇 가지 질문에 대한 답을 나중에 찾을 수 있는지 여부입니다. 사용자가 어떤 권한을 부여했는지? 상담원은 무엇을 구매했는지? 금액이 예산을 초과했는지? 서비스 제공업체가 실제로 데이터를 반환했는지? 만약 상담원이 프롬프트 주입에 속아 부적절한 항목을 구매한 것으로 나중에 밝혀진다면, 해당 정보의 출처를 추적할 수 있을까요?
이것이 바로 에이전트 결제를 논의할 때 비트코인 백서를 다시 살펴보는 것이 단순히 향수 때문이 아니라고 생각하는 이유입니다. 사토시 나카모토가 해결하려 했던 핵심 문제는 "거래 가능한 자산을 발명하는 것"이 아니라, 신뢰할 수 있는 제3자 없이도 네트워크에서 전자 화폐의 이체를 검증, 순서 지정 및 기록할 수 있는 방법을 보장하는 것이었습니다. 백서에는 네트워크가 거래를 해시하여 지속적으로 증가하는 작업증명(Proof-of-Work) 체인을 생성하고, 작업을 다시 수행하지 않고는 변경할 수 없는 기록을 만든다고 명시되어 있습니다.
에이전트 기반 결제는 다소 다른 문제에 직면합니다. 이중 지출 문제뿐만 아니라 에이전트 승인, 권한 남용, 전달 및 책임 문제도 포함됩니다. 그러나 이러한 결제 방식에는 공통점이 있습니다. 개방형 네트워크 내에서 경제 활동이 발생하면 검증 가능한 거래 기록은 더 이상 부차적인 것이 아니라 인프라 자체의 필수적인 요소가 된다는 것입니다.
이것이 바로 블록체인의 중요성입니다. 블록체인은 결제를 불투명하게 만드는 것이 아니라, 플랫폼 데이터베이스에 숨겨져 있던 일부 정보를 외부에서 검증 가능한 상태로 전환시켜 줍니다. 이상적으로는 결제 기록, 인증 정보, 서비스 접근 권한, 환불 조건, 예산 지출 내역 등을 보다 표준화된 방식으로 기록하고 검증할 수 있습니다. 일반 사용자에게는 단순히 "더 투명한 계정"을 의미할 수 있지만, 금융 기관에게는 신뢰성의 기반이 될 수 있습니다.
에이전트는 사람이 아니기 때문입니다. 에이전트는 "당시에는 이렇게 생각했던 게 기억나요"라고 말하며 자신의 행동을 설명할 수 없습니다. 에이전트에게는 외부에서 검증 가능한 일련의 증거가 필요합니다.
이러한 이유로 AP2, x402, 스테이블코인, 블록체인이 같은 도표에서 함께 언급되는 경우가 많지만, 이들은 엄연히 다른 개념입니다. AP2 자체는 탈중앙화 프로토콜도 아니고 블록체인 프로토콜도 아닙니다. 구글은 AP2를 사용자, 판매자, 결제 서비스 제공업체가 다양한 결제 방식을 통해 에이전트 기반 결제를 안전하게 완료할 수 있도록 하는 결제 방식에 구애받지 않는 개방형 프레임워크로 정의합니다. AP2 사양 또한 AI 에이전트가 사용자를 대신하여 안전하고 자율적으로 결제를 완료할 수 있도록 하는 개방형 프로토콜로 정의하고 있습니다.
따라서 더 정확히 말하면, AP2는 에이전트 결제의 권한 부여 및 신뢰 계층에 가깝고, 사용자의 의도, 권한 범위 및 책임 경계를 표현하는 역할을 합니다. x402, L402, T402는 결제 요청 계층에 더 가깝고, 에이전트가 리소스를 요청할 때 서비스 제공자가 결제 요청을 시작하는 방식을 결정합니다. 스테이블코인은 결제 자산으로, 에이전트가 결제에 사용하는 안정적인 단위를 지정합니다. 반면 블록체인은 검증 가능한 상태 계층으로, 거래 기록, 결제 상태 및 후속 실행을 외부에서 검증할 수 있는지 여부를 결정합니다.
이러한 계층 구조는 서로 동일하지는 않지만, 함께 고려하면 진정한 에이전트 기반 결제 인프라와 유사한 형태를 띨 수 있습니다. 그렇지 않으면 어색한 상황이 발생합니다. 에이전트는 지능적으로 서비스를 찾고, 가격을 비교하고, 결정을 내리는 데 도움을 주지만, 결제 단계에서는 계정 등록, 카드 연결, 요금제 구매, 요금 확인, 고객 서비스 문의, 환불 처리 등 인간 세상의 절차로 되돌아가게 됩니다. 그러면 그것은 에이전트 기반 결제가 아니라 단순히 버튼 클릭만 더 잘하는 브라우저 도우미에 불과하게 됩니다.
물론 지나치게 낙관해서는 안 됩니다. 온체인 결제에 에이전트를 통합하는 것은 위험이 없는 것은 아니며, 오히려 더 직접적인 위험이 존재할 수 있습니다. 기존 결제 시스템에서는 많은 거래가 분쟁 제기, 동결 또는 취소될 수 있습니다. 하지만 온체인 거래는 일단 전송되면 복구가 훨씬 어려워집니다. 에이전트가 공격을 받거나, 사용자의 권한 범위가 너무 넓거나, 서비스 제공자가 대금을 받고 서비스를 제공하지 않거나, 악성 웹사이트가 에이전트를 속여 결제를 유도하거나, 에이전트가 하룻밤 사이에 예산을 모두 소진하는 경우 등은 모두 심각한 문제로 이어질 수 있습니다.
따라서 에이전트 결제는 단순히 에이전트에게 지갑을 주고 "마음껏 돈을 쓰세요"라고 말하는 방식이 아닙니다. 이는 너무 위험합니다. 진정으로 필요한 것은 포괄적인 제어 메커니즘입니다. 즉, 거래 한도, 화이트리스트, 블랙리스트, 승인 범위, 위험 수준, 사람 검증, 일시 중지/재개 스위치, 감사 로그 등이 포함되어야 합니다. 소액의 저위험 거래는 기계가 자동으로 생성할 수 있지만, 실제 현장 이행이 필요한 고위험 거래는 여전히 사람 검증이 필요합니다.
따라서 저는 에이전트 결제에서 블록체인의 역할을 다음과 같이 이해하고 싶습니다. 블록체인은 웹3가 전통 금융보다 우월하다는 것을 증명하기 위한 것이 아니라, 에이전트의 경제적 행위에 대한 검증 가능한 기반을 제공하기 위한 것입니다. 에이전트 결제에 블록체인이 필요한 이유는 모든 결제가 온체인되어야 한다는 것이 아니라, AI 에이전트가 개방형 네트워크에서 돈을 쓰기 시작할 때, 그들이 쓰는 돈이 승인된 것인지, 무엇을 사는지 기록할 수 있는지, 그들의 행동을 추적할 수 있는지, 그리고 그들이 일으키는 문제에 대해 책임을 물을 수 있는 방법이 필요하기 때문입니다.
이것이 바로 이 문제에서 블록체인이 진정으로 해야 할 일입니다. 블록체인은 맹목적인 믿음이나 허황된 주장, 혹은 무차별 대입 방식의 "AI + Web3" 접근법에 관한 것이 아닙니다. 기계가 경제 활동에 참여하기 시작하면서 기존의 회계 시스템과 플랫폼 데이터베이스가 더 이상 충분하지 않을 수 있다는 점에 초점을 맞추고 있습니다. 기계가 더 쉽게 읽고 검증할 수 있는, 보다 개방적이고 표준화된 경제 상태 체계가 필요하며, 블록체인은 적어도 그 방향을 제시해 줍니다.
다섯째, 이는 은행 카드를 대체하는 것이 아니라, 단계별 결제 시스템의 시작입니다.
따라서 궁극적으로 저는 에이전트 기반 결제가 단순히 스테이블코인이 은행 카드를 대체하고 블록체인이 기존 결제 네트워크를 대체한다는 한 가지 결론으로 이어질 것이라고 생각하지 않습니다.
이러한 판단은 지나치게 단순하며 현실과 너무 쉽게 모순됩니다. 적어도 오랫동안 은행 카드, 신용 카드, 애플 페이, 비자, 마스터카드, 스트라이프, 페이팔과 같은 시스템은 여전히 존재하며 수많은 실제 소비 시나리오에서 결제 수단으로 계속 사용될 것입니다. 사람들이 전자상거래 웹사이트에서 물건을 구매하고, 호텔과 항공권을 예약하고, 오프라인에서 구매하고, 기업에서 조달하는 시나리오들은 단순히 결제 대행업체가 등장했다고 해서 갑자기 사라지지 않을 것입니다.
에이전트 기반 상거래 초기에도 에이전트들은 기존 결제 시스템에 먼저 연결했을 가능성이 있습니다.
기존 가맹점 네트워크가 이미 성숙되어 있고, 소비자는 이미 카드와 전자지갑을 보유하고 있으며, 가맹점은 이미 결제 처리 시스템을 구축했고, 은행 및 카드사는 성숙한 위험 관리, 분쟁 해결, 환불, 규정 준수 및 신원 확인 시스템을 갖추고 있기 때문에 "AI가 구매를 완료하도록 도와주는" 시나리오에서는 기존 Rails 플랫폼을 직접 사용하는 것이 가장 현실적인 접근 방식입니다.
그러므로 문제는 "카드가 사라질 것인가?"가 아닙니다.
문제는 에이전트 기반 결제가 현재 수준에 머물 것인가 하는 점입니다. 에이전트가 단순히 누군가를 위해 "결제" 버튼을 클릭하는 경우라면 기존처럼 은행 카드를 사용할 수 있습니다. 하지만 에이전트가 API 호출, 데이터 구매, 결제 모델 서비스 이용, 컴퓨팅 파워 정산, 콘텐츠 잠금 해제, 다른 에이전트와의 거래 등 더욱 복잡한 작업 네트워크에 참여하게 된다면, 단순히 더 스마트한 결제 버튼이 아니라 완전히 새로운 결제 프로토콜 스택이 필요하게 될 것입니다.
그래서 저는 미래에 우리가 보게 될 모습은 "은행 카드 대 스테이블코인"의 대립이 아니라, 오히려 계층화된 결제 시스템일 가능성이 더 높다고 생각합니다.
인간의 소비와 기존 가맹점 네트워크에서는 은행 카드, 신용 카드, 전자지갑, 은행 계좌가 여전히 주류로 남을 것입니다. Rails와 같은 전통적인 결제 방식은 에이전트가 쇼핑, 티켓 예매, 호텔 예약, SaaS 갱신 등을 완료하도록 지원하는 시나리오에서 계속해서 중요한 역할을 할 것입니다. 에이전트는 기존 상거래 흐름에 간단히 통합되어 사용자가 거래를 더욱 자동화된 방식으로 완료할 수 있도록 도와줍니다.
하지만 스테이블코인과 블록체인은 API, 데이터, 모델, 컴퓨팅 파워, 콘텐츠, 온체인 서비스, 에이전트 간 거래와 같은 기계 친화적인 시나리오에서 더욱 두드러지게 등장할 가능성이 높습니다. 이는 이러한 시나리오에서 결제 수령자가 전통적인 판매자가 아니라 디지털 자원이기 때문입니다. 거래 금액은 적을 수 있지만 거래 빈도는 높을 수 있으며, 서비스 제공자는 다양한 플랫폼, 국가 및 시스템에서 올 수 있고, 전체 프로세스는 이상적으로 기계가 자동으로 이해하고, 결제하고, 검증해야 합니다.
간단히 말해, 은행 카드는 인간 소비 시대의 결제 문제를 해결했다면, 스테이블코인과 블록체인은 기계 경제 시대의 결제 방식과 검증 가능한 실행 환경 문제를 해결하는 데 더 가깝다고 할 수 있습니다.
물론, 그렇다고 해서 스테이블코인과 블록체인이 준비되었다는 의미는 아닙니다. 온체인 경험은 여전히 복잡하고, 지갑 관리는 아직 사용자 친화적이지 않으며, 스테이블코인 관련 규정은 계속 발전하고 있고, 여러 블록체인에 걸친 유동성은 분산되어 있습니다. 더욱 중요한 것은, 에이전트가 직접 자금을 통제하도록 허용하는 것은 본질적으로 위험하다는 점입니다. 접근 제어, 한도 관리, 위험 관리 메커니즘, 수동 검토 및 감사 시스템이 없다면, 에이전트 기반 결제는 "자동화된" 것을 넘어 "자동으로 문제를 일으키는" 행위로 쉽게 변질될 수 있습니다.
따라서 에이전트 결제의 진정한 구현은 에이전트들이 자신의 지갑으로 돈을 함부로 쓸 수 있게 된다는 것을 의미하지는 않습니다.
이는 점진적인 진화 과정을 거칠 가능성이 더 높습니다. 첫째, 기존 결제 시스템에 통합되어 사용자들이 더욱 자동화된 결제를 완료할 수 있도록 지원할 것입니다. 둘째, 예산, 화이트리스트, 사용 범위, 시간 제한, 위험 수준과 같은 더욱 세분화된 승인 기능을 갖추게 될 것입니다. 셋째, API, 데이터, 모델 및 콘텐츠 서비스가 기계 판독 가능한 결제 요청을 지원하기 시작하여 에이전트가 필요에 따라 리소스를 구매할 수 있게 될 것입니다. 마지막으로, 스테이블코인은 특히 소액, 고빈도, 플랫폼 간 및 국경을 넘나드는 디지털 서비스 호출과 같은 특정 기계 기반 시나리오에서 결제 자산으로 사용될 것입니다.
이러한 관점에서 볼 때, 에이전트 기반 결제는 단일 기업, 블록체인, 스테이블코인 또는 프로토콜이 단독으로 달성할 수 있는 것이 아닙니다. 오히려 AI 에이전트라는 새로운 존재에 직면하여 전체 결제 시스템이 해체되고 재편성되는 것에 가깝습니다.
과거에는 결제 시스템이 주로 개인과 기업을 대상으로 했습니다. 하지만 미래에는 새로운 유형의 주체인 공인 소프트웨어 에이전트에게도 서비스를 제공할 수 있을 것입니다.
법인도 아니고 전통적인 기업 계정도 아니지만, 요청을 시작하고, 가격을 비교하고, 서비스를 이용하고, 자원을 소비하고, 결제를 처리하고, 기록을 남깁니다. 이러한 주체들이 대거 등장함에 따라 결제 시스템은 다음과 같은 새로운 질문에 답해야 합니다. 이 주체는 누구인가? 누구를 대표하는가? 무엇을 할 수 있는가? 얼마만큼의 돈을 쓸 수 있는가? 무엇을 구매했는가? 권한을 남용한 것은 아닌가? 문제가 발생할 경우 누가 책임져야 하는가?
이러한 문제들은 단순한 결제 버튼으로 해결될 수 없습니다.
자, 그럼 기사 초반의 질문으로 돌아가 보겠습니다. AI 에이전트는 은행 카드를 사용할까요?
회의.
하지만 은행 카드만 사용하는 것은 아닙니다.
은행 카드는 계속해서 결제를 처리할 것이며, 스테이블코인은 기기에서 바로 사용할 수 있는 소액 즉시 결제를 처리하기 시작할 것이고, 블록체인은 검증 가능한 상태와 실행 환경을 제공할 것이며, AP2, x402, L402, T402와 같은 프로토콜은 승인, 결제 요청 및 리소스 접근을 연결하려고 시도할 것입니다.
이것이 바로 에이전트 결제가 주목할 만한 이유입니다. 단순히 AI에 결제 기능을 추가하는 것에 그치는 것이 아닙니다. 기계가 경제 활동에 참여하기 시작하는 시대에 인터넷에 진정으로 필요한 결제 시스템은 어떤 모습일지 다시 생각해 보게 한다는 점에서 의미가 있습니다.


