简体中文

繁體中文

English

Tiếng Việt

한국어

日本語

ภาษาไทย

Türkçe

기계 네이티브 거래: 현황과 부재한 인프라

이 글을 읽으려면 62 분

머신 결제 트랙에서 자율 조달 네트워크로, '누가 구매자를 장비할 것인가'를 둘러싼 인프라 이동이 일어나고 있다.

원문 제목: 《머신 네이티브 거래: 현황과 부재한 인프라》

원문 출처: 수이디캐피탈

요약

대형 모델은 질문에 답하는 도구에서 계획을 세우고 도구를 호출하며 결과를 전달하는 지능형 에이전트로 변모하고 있다. 동시에 스테이블코인 결제, HTTP 네이티브 결제 프로토콜(http 402), 스마트 월렛도 머신을 위한 결제 인프라로 조합되기 시작했다. 프로그램이 런타임에 견적을 받고, 권한을 서명하고, 소액 결제를 완료할 수 있게 되었는데, 이는 몇 년 전만 해도 개념에 불과했지만 지금은 실제로 사용 가능한 기술 경로가 되었다.

그러나 「머신이 결제할 수 있다」는 것이 「머신이 거래를 완료할 수 있다」는 것과 같지 않다. 에이전트가 검색, 데이터, 컴퓨팅 파워, 콘텐츠 생성 또는 전문 분석 서비스를 구매해야 할 때, 여전히 엔드포인트 발견, 견적 비교, 프로토콜 간 결제, 예산 통제, 납품 검증, 통합 대사 등의 문제에 직면한다. 결제 레일은 가치가 어떻게 이동하는지를 해결했지만, 수요가 어떻게 공급을 찾는지, 그리고 결제 후 올바른 서비스를 받았는지는 자동으로 해결하지 못했다.

이는 Agent Payment의 다음 단계에서 경쟁 초점이 더 이상 프로토콜 처리량, 결제 속도 또는 얼마나 많은 체인을 지원하는지가 아니라, 진정한 머신 구매자 인프라를 형성할 수 있는지에 있을 수 있음을 의미한다. 이 글은 수요 구조, 프로토콜 진화, 현실적 병목, 시장 분업에서 출발하여 Agent Payment가 왜 독립적인 트랙이 되는지, 그리고 규모화 채택까지 어떤 핵심 단계가 부족한지 논의하고자 한다.

서론: 지능형 에이전트가 제약된 「가처분 예산」을 받고 있다

지난 2년간 지능형 에이전트의 능력 변화는 매우 빨랐다. 초기 대형 모델은 주로 정보 생성를 담당했고, 사용자가 질문하면 모델이 텍스트를 제공했다. 이후 도구 호출을 통해 모델이 웹 페이지를 검색하고, 데이터베이스를 조회하고, 코드를 실행하고, 소프트웨어를 조작할 수 있게 되었다. 한 걸음 더 나아가, 지능형 에이전트는 목표를 분해하고, 계획을 수립하며, 여러 차례 실행 과정에서 외부 결과에 따라 행동을 조정하기 시작했다.

실행 대상이 무료 도구나 기업 내부 시스템에 국한될 때는 호출 권한을 개발자가 미리 구성할 수 있다. 그러나 개방 시장에서 고품질 능력은 일반적으로 유료다: 실시간 금융 데이터는 건당 과금되고, 웹 스크래핑은 할당량을 소모하며, 추론과 GPU 컴퓨팅 파워는 사용량에 따라 과금되고, 비디오 생성과 전문 데이터베이스도 명확한 가격이 있다. 지능형 에이전트가 독립적으로 작업을 완료하려면 실행 과정에서 필연적으로 구매자가 되어야 한다.

전통적인 API 비즈니스 모델은 이런 구매자를 위해 설계되지 않았다. 사람이 먼저 웹사이트에 접속하고, 계정을 등록하고, 은행 카드를 연동하고, 요금제를 선택하고, API Key를 보관한 다음, 키를 프로그램 환경에 넣어야 한다. 구매 결정과 실제 호출이 두 시점으로 분리된다: 사람이 작업 발생 전에 구매를 완료하고, 소프트웨어는 이미 구매한 할당량을 소비할 뿐이다.

에이전트는 작업을 수행하는 특정 단계에 이르기까지 자신이 무엇을 필요로 하는지 모를 수 있다. 최종적으로 어떤 데이터 소스를 호출할지 미리 판단할 수 없으며, 사용자에게 모든 잠재적 서비스에 대해 일일이 계좌를 개설하도록 요구해서도 안 된다. 그 조달은 즉시성, 소액, 다수 판매자, 고빈도, 결과 지향 등의 특징을 지닌다. 에이전트에게 가장 자연스러운 경험은 '먼저 구독하고, 그다음 호출'하는 것이 아니라 '서비스를 발견하고, 견적을 받고, 결제를 승인하고, 결과를 얻는' 것이다.

따라서 Agent Payment는 챗봇에 결제 버튼을 추가하는 것이 아니다. 이는 소프트웨어가 제약된 지출 권한을 갖기 시작하고, 기계 고유의 조달 프로세스를 형성한다는 것을 의미한다. 인간이 목표, 예산, 리스크 경계를 설정하면, 에이전트는 그 경계 내에서 자금을 배분한다. 이로써 결제는 정산 행위에서 에이전트 의사결정 시스템의 일부로 변모한다.

1. 왜 Agent Payment가 독립적인 트랙이 되는가

1.1 도구 호출에서 경제적 행동으로

에이전트와 일반 자동화 스크립트의 차이는 추론 능력에만 있지 않다. 스크립트는 미리 정해진 프로세스를 실행하며, 필요한 리소스와 공급자는 대개 코드에 이미 작성되어 있다. 반면 에이전트는 환경에 따라 경로를 선택한다. 동일한 연구 작업에서 검색 결과를 먼저 구매하고, 그 결과에 따라 산업 데이터베이스가 필요한지 판단한 뒤, 마지막으로 다른 모델을 호출해 교차 검증할 수 있다. 각 단계의 조달은 이후 의사결정을 바꾼다.

이러한 '실행하면서 조달하는' 모델은 경제적 선택을 소프트웨어 런타임으로 끌어들인다. 에이전트는 특정 도구가 사용 가능한지 판단할 뿐만 아니라, 그것이 구매할 가치가 있는지도 판단해야 한다. 가격이 예산을 초과하는지, 응답 속도가 작업을 충족하는지, 과거 이행이 신뢰할 만한지, 대체 서비스가 더 적합한지 등이다. 전통적인 도구 라우팅은 능력 매칭에 주목하지만, 기계 조달은 가격과 거래 상대방 리스크까지 동시에 처리해야 한다. 이러한 거래에서 리스크를 부담하는 쪽은 에이전트 자신이다. 결제는 성공했지만 서비스가 제공되지 않을 수 있다.

따라서 Agent Payment의 핵심 요구는 무조건적인 자동 결제가 아니라, 구매권을 통제 가능한 방식으로 소프트웨어에 부여하는 것이다. 사용자는 지갑 전체를 에이전트에게 쉽게 맡기지 않지만, 명확한 작업에 몇 달러의 예산을 설정하고 몇 건의 센트 단위 조달을 허용하는 것은 기꺼이 한다. 큰 권한은 여전히 장기적인 신뢰 구축이 필요할 수 있지만, 작은 권한은 이미 실질적인 가치를 창출할 수 있다.

1.2 소액, 고빈도, 다수 판매자가 결제 경제학을 바꾼다

인간 인터넷의 결제 인프라는 상대적으로 저빈도, 고액 거래를 처리하는 데 능숙하다. 신용카드 네트워크, 결제 게이트웨이, 구독 시스템은 모두 고정 비용이 있기 때문에, 판매자는 흔히 여러 번의 호출을 월간 패키지로 묶는다. 한 번에 몇 센트의 가치밖에 없는 API 요청의 경우, 전통적인 결제의 수수료, 지불 거절 리스크, 계정 유지 비용이 상품 자체보다 클 수 있다.

기계 소비는 정반대다. 에이전트는 하나의 결과물을 완성하기 위해 몇 분 안에 여러 상점에 여러 건의 구매를 요청할 수 있다. 건당 금액은 매우 낮지만 호출 빈도가 높아 거래 건수가 인간 소비자보다 훨씬 많을 수 있다. 스테이블코인과 온체인 프로그래머블 결제는 이런 시나리오에 새로운 경제적 기반을 제공한다. 자금이 24시간 흐를 수 있고, 결제 승인을 소프트웨어가 서명할 수 있으며, 서비스도 호출 단위로 직접 과금할 수 있다.

더 중요한 것은 다중 상점 구매가 API 시장의 경쟁 방식을 바꾼다는 점이다. 구독제는 사용자가 한 공급업체에 장기간 묶이도록 유도하지만, 건별 구매는 에이전트가 매 작업마다 동적으로 선택할 수 있게 한다. 서비스 제공자는 더 이상 연간 계약만 두고 경쟁하지 않고, 특정 순간의 수요를 두고도 경쟁한다. 가격, 성능, 이행 기록이 모두 실시간으로 라우팅 결과에 영향을 미칠 수 있다.

1.3 스테이블코인은 거래 매개에서 결제 인프라로 이동 중이다

암호화폐 시장 초기의 스테이블코인 수요는 주로 거래와 자금 헤지에서 비롯됐다. 발행, 수탁, 컴플라이언스, 크로스체인 인프라가 점차 성숙해지면서 스테이블코인은 국경 간 결제, 기업 자금 관리, 인터넷 네이티브 결제로 진입하기 시작했다. 기계 결제에서 스테이블코인은 특별한 장점이 하나 더 있다. 그것은 화폐이면서 동시에 프로그램이 직접 조작할 수 있는 디지털 자산이라는 점이다.

신용카드 결제는 카드 소지자 신원, 은행 계좌, 지역 네트워크에 의존한다. 에이전트 자체에는 자연인 신원이 없고 전통적인 계좌 개설 절차를 독립적으로 통과할 수도 없다. 반면 정책으로 제약된 지갑은 에이전트의 자금 인터페이스가 될 수 있다. 운영자가 제한된 잔액을 주입하고, 건당 및 세션 한도를 설정하며, 동결 및 취소 권한을 보유한다. 에이전트는 승인 범위 안에서만 결제에 서명한다.

이것이 온체인 결제가 모든 전통 결제보다 본질적으로 우월하다는 뜻은 아니다. 소비자 보호, 환불 메커니즘, 프라이버시, 키 관리, 규제 책임은 여전히 해결해야 한다. 그러나 기계 대 기계, 소액 건별, 글로벌 서비스 구매에서는 프로그래머블 스테이블코인이 뚜렷한 적합성을 갖는다. 그것은 '인터페이스 호출'과 '결제 인터페이스'가 처음으로 동일한 네트워크 상호작용 안에 압축될 기회를 만든다.

2. 결제 레일이 이미 등장했다: x402, MPP와 HTTP 네이티브 거래

2.1 402를 상태 코드에서 상업 인터페이스로 바꾸기

HTTP는 일찍부터 402 Payment Required 상태 코드를 마련해 두었지만, 거의 30년 동안 그것은 범용 워크플로를 형성하지 못했다. 기계 결제 프로토콜은 이 의미를 다시 활성화한다. 클라이언트가 유료 엔드포인트를 요청하면 서버는 402와 기계 판독 가능한 결제 조건을 반환한다. 클라이언트는 수용 가능한 방식을 선택하고 서명 또는 결제를 완료한 뒤 자격 증명을 가지고 요청을 재시도한다.

이 과정의 중요성은 인간용 등록 페이지를 없앤다는 데 있다. 가격 발견, 결제 요구, 콘텐츠 전달이 모두 프로그램이 이해할 수 있는 프로토콜 계층에서 일어난다. 개발자에게 유료 API는 더 이상 계정, 요금제, 키를 중심으로 완전한 SaaS 포털을 구축할 필요가 없다. 에이전트에게 서비스는 일반 웹페이지처럼 발견되고, 실제로 필요할 때 구매될 수 있다.

x402는 이 경로에서 가장 주목받는 개방형 프로토콜 중 하나입니다. HTTP 402를 중심으로 결제 챌린지와 자격 증명을 구성하여 서비스 제공자가 요청별로 대금을 받을 수 있게 합니다. MPP는 또 다른 생태계에서 출발하여 머신을 위한 charge, session 등의 결제 방식을 탐구합니다.两者的 구체적인 설계는 다르지만, 하나의 방향을 공동으로 검증했습니다: 머신 결제는 애플리케이션 프로토콜의 일부가 될 수 있으며, 애플리케이션 외부에 별도의 수동 정산 프로세스를 구축할 필요가 없다는 것입니다.

2.2 결제 레일 다원화의 장기성

업계는 종종 최종적으로 하나의 표준 프로토콜, 하나의 정산 네트워크, 하나의 결제 방식만 남을 것이라고 기대합니다. 그러나 판매자 관점에서 다원화는 장기적 합리성을 갖습니다. 일회성 데이터 조회는 건당 과금에 적합하고, 지속적 추론이나 스트리밍 서비스는 세션 과금이 더 적합할 수 있습니다. 고가치 서비스는 더 강한 보증과 분쟁 처리가 필요하고, 저가치 호출은 속도와 비용을 더 중시합니다. 지역과 기업에 따라서도 서로 다른 규제 준수 및 정산 네트워크를 선택합니다.

프로토콜 계층은 계속 혁신할 것입니다. 판매자는 직접 출금, 사전 승인, 에스크로, 스트림 결제 또는 일괄 정산을 채택할 수 있습니다. 네트워크는 비용, 최종성, 유동성, 생태계 도구에서 각기 다른 장단점을 가질 수 있습니다. 판매자에게 이것은 자유로운 선택입니다. 구매자에게는 새로운 조합이 하나 추가될 때마다 새로운 통합 지점이 하나 늘어납니다.

아래 그림의 구성 매트릭스는 이러한 다원화의 한 단면입니다: 프로토콜/결제 방식이 열을 구성하고, 체인이 행을 구성하며, 각 선택은 개별적으로 통합해야 하는 결제 구성입니다. 그리고 이 표는 계속 넓어지고 있습니다.

그림 1: 파편화下的 결제 레일 구성 매트릭스

따라서 파편화가 시장 성숙과 함께 자연스럽게 사라지지는 않을 수 있습니다. 카드 시장은 장기 발전에도 불구하고 하나의 카드 조직만 남지 않았고, 클라우드 컴퓨팅도 하나의 공급자로 수렴하지 않았습니다. 성숙한 시장은 일반적으로 차이를 제거하는 것이 아니라 차이 위에 집계, 라우팅, 청산 계층을 형성합니다. Agent Payment도 같은 진화 경로를 따를 가능성이 높습니다. 이러한 분열은 이미 측정 가능합니다. 두 개의 공개 브라우저(x402scan과 mppscan)의 최근 30일 데이터에 따르면(2026년 9월 3일 기준): MPP 프로토콜은 Tempo 체인에서 65,591개의 활성 구매자 지갑을, x402는 Base 체인에서 19,472개를 보유하고 있으며, 두 레일 모두에 나타난 지갑은 365개에 불과하여 MPP 프로토콜 구매자의 0.6% 미만, x402 Base 구매자의 2%에 해당합니다. 그중 두 레일에서 각각 10건 이상의 거래를 완료한 지갑은 112개뿐이며, 상당 부분은 이중 레일 집계기가 동일한 키로 대리 결제한 것이지 구매자가 스스로 두 번째 결제 레일을 채택한 것이 아닙니다. 구매자는 레일 간에 이동하지 않았고, 각 레일은 자신만의 독립적인 구매자 그룹을 축적하고 있습니다.

2.3 판매자 온보딩은 거래의 절반에 불과하다

결제 프로토콜은 우선 판매자의 수금 장벽을 낮춘다. 하나의 엔드포인트가 견적을 게시하고, 자격 증명을 검증하며, 서비스를 반환할 수 있다면 기계를 대상으로 영업할 기본 조건을 갖춘 것이다. 점점 더 많은 개발자 도구, 데이터 서비스, 콘텐츠 인터페이스가 이로 인해 기계가 구매 가능한 상태로 진입하고 있다.

그러나 공급이 지불 가능하다고 해서 수요가 자동으로 따라오는 것은 아니다. 판매자가 해결하는 것은 "기계로부터 어떻게 돈을 받을 것인가"이고, 에이전트는 여전히 "누구에게 사야 하는가, 어떤 방식으로 지불해야 하는가, 결제 후 납품을 어떻게 확인하는가"에 답해야 한다. 만약 모든 구매자가 각각의 프로토콜을 개별 통합하고, 서로 다른 네트워크의 자금을 준비하며, 독립적인 장부를 유지해야 한다면, 기계 결제는 초기 API 통합의 복잡성을 반복하게 될 것이며, 단지 API Key를 지갑과 프로토콜 어댑터로 바꾼 것에 불과하다.

실질적인 채택률은 결제 단계의 마찰이 아니라 거래 전체의 마찰에 달려 있다.

3. 업계의 진정한 병목: 거래에 폐쇄 루프가 없다

그림 2: 기계 조달의 전체 프로세스

3.1 첫 번째 관문: 구매 가능한 서비스 발견

에이전트는 기계가 읽을 수 있는 서비스 디렉토리가 필요하다. 효과적인 디렉토리는 이름과 URL만 있어서는 안 되며, 엔드포인트 능력, 입출력, 가격 단위, 사용 가능한 프로토콜, 지연 시간, 지역 제한, 업데이트 상태를 설명해야 한다. 자연어 의도와 API 파라미터 간의 매핑도 필요하다. 그렇지 않으면 에이전트는 자신이 "거시 데이터가 필요하다"는 것을 알면서도 어떤 엔드포인트가 작업을 충족하는지 판단할 수 없다.

개방형 시장의 디렉토리는 중복, 무효화, 허위 주장에도 직면한다. 어떤 판매자든 자신이 고품질 데이터를 제공한다고 주장할 수 있지만, 에이전트는 인간 구매 담당자처럼 며칠을 들여 배경 조사를 할 수 없다. 발견 계층은 엔드포인트가 호출 가능한지, 견적이 진실인지, 설명이 반환 내용과 일치하는지 지속적으로 검증해야 한다.

이로 인해 서비스 발견은 전통적인 검색과 다르다. 검색 엔진은 정보 관련성을 최적화하지만, 기계 조달 디렉토리는 거래 가능성도 최적화해야 한다: 능력이 일치하는지, 가격이 수용 가능한지, 결제가 호환되는지, 그리고 판매자가 납품할 수 있는지.

3.2 두 번째 관문: 견적의 이해와 비교

표면적으로 동종 API는 모두 건당 가격을 표시할 수 있지만, 실제로 견적의 비교 가능성은 매우 약하다. 한 곳은 요청당 과금하고, 다른 곳은 결과 건수당 과금한다. 한 곳은 모델 추론을 가격에 포함하지만, 다른 곳은 추가 지불이 필요하다. 또 다른 서비스는 입력 길이, 실행 시간, 성공 결과에 따라 동적으로 과금한다.

에이전트는 단순히 명목 가격이 가장 낮은 엔드포인트를 선택해서는 안 된다. 총비용, 전달 확률, 지연 시간, 결과 품질을 고려해야 한다. 저렴한 인터페이스가 연속으로 실패하면 재시도 비용과 작업 지연으로 인해 실제 가격이 더 높아질 수 있다. 따라서 견적은 서비스 등급, 과거 성과, 작업 맥락과 함께 평가되어야 한다.

기계 판독 가능한 견적은 또한 유효 기간과 최종 금액을 명확히 해야 한다. 동적 가격 환경에서 에이전트가 서명하는 것은 모호한 가격 범위가 아니라 확정된 약속이어야 한다. 운영자도 서비스 수수료, 네트워크 비용, 라우팅 수수료를 포함한 비용 구성을 알아야 신뢰할 수 있는 예산을 설정할 수 있다.

3.3 세 번째 관문: 자금 분포와 크로스 트랙 유동성

하나의 에이전트가 여러 체인과 다양한 프로토콜에서 동시에 서비스를 구매하려면, 가장 직접적인 방법은 각 네트워크에 잔액을 미리 배치하는 것이다. 그러나 이는 소액의 자금을 여러 조각으로 쪼개게 된다. 자금은 당분간 사용하지 않는 네트워크에 묶여 있고, 인기 있는 네트워크는 잔액이 부족할 수 있다. 잔액 보충에는 브리징, 스왑, 가스, 보안 작업이 수반된다.

개별 사용자에게 이것은 이미 번거로운 일이다. 다수의 에이전트를 관리하는 기업에게는 문제가 더욱 확대된다. 각 에이전트가 얼마의 잔액을 보유해야 하는지, 누가 보충을 담당하는지, 자금이 잘못 소비되는 것을 어떻게 방지하는지, 서로 다른 네트워크의 자산과 비용을 어떻게 집계하는지? 통합 자금 레이어가 없으면 결제 트랙이 많아질수록 재무 복잡성은 오히려 높아진다.

이상적으로 에이전트가 보는 것은 여러 네트워크 잔액이 아니라 하나의 가용 예산이다. 하위 시스템이 결제 경로를 선택하고 유동성을 관리하며 투명한 견적을 제공한다. 그 원칙은 여행자가 여러 국가에서 하나의 카드를 사용하는 것과 유사하다. 사용자는 총 한도와 환율에 관심이 있으며, 각 목적지마다 현지 계좌를 미리 개설할 필요가 없다.

3.4 네 번째 관문: 정책 기반 권한 부여

자율 결제에서 가장 쉽게 제기되는 우려는 에이전트가 통제를 벗어나 소비하지 않을까 하는 것이다. 해결책은 단순히 '완전 금지'와 '완전 권한 부여' 사이에서 하나를 선택하는 것이 아니라, 다층 정책을 구축하는 것이다.

단일 거래 한도는 한 번의 실수로 인한 손실을 제한하고, 세션 예산은 하나의 작업에 대한 총지출을 제약하며, 가맹점 화이트리스트 또는 블랙리스트는 거래 상대방을 통제하고, 카테고리 규칙은 구매 가능한 콘텐츠를 제한하며, 속도 제한은 단시간 내 비정상 호출을 차단한다. 고위험 또는 고액 거래는 수동 확인을 트리거할 수도 있다. 정책은 운영자가 설정해야 하며, 에이전트는 경계 내에서만 행동할 수 있고 스스로 한도를 높일 수 없다.

지갑도 단순히 서명 기능만 수행해서는 안 된다. 지갑은 작업, 신원, 감사 기록과 결합되어 '어떤 에이전트가 어떤 작업을 위해 어떤 정책으로 이 지불을 승인했는가'를 답할 수 있어야 한다. 그렇지 않으면 기업이 최종적으로 얻는 것은 온체인 거래 해시의 나열일 뿐이며, 내부 통제와 비용 귀속 요구 사항을 충족할 수 없다.

3.5 다섯 번째 관문: 결제 성공이 서비스 제공을 의미하지는 않는다

블록체인은 자금이 한 주소에서 다른 주소로 이전되었음을 증명하는 데 능숙하지만, API가 올바른 내용을 반환했는지는 본질적으로 증명하지 못한다. 거래는 정산이 완료될 수 있지만, 서버 측 시간 초과, 오류 상태 반환, 또는 전달된 데이터가 광고와 불일치할 수 있다. 에이전트에게 이것은 주변적인 문제가 아니라 조달 위험의 핵심이다.

전통적인 전자상거래는 물류, 평가, 환불을 통해 결제와 배송을 연결한다. 기계 서비스에는 물리적 물류가 없으며, 배송은 단지 순간적인 HTTP 응답일 수 있다. 결제 시스템이 자금 궤적만 기록하고, 판매자가 자신의 응답만 기록한다면, 시장에는 판매자 간, 프로토콜 간 통합된 이행 뷰가 부재하게 된다.

주의할 점은 응답을 기록하는 것이 품질을 증명하는 것과 같지 않다는 것이다. 그러나 결제와 응답을 연관시키면 적어도 '결제 완료 및 결과 수신', '결제 완료 but 서비스 실패', '미정산' 등의 기본 상태를 구분할 수 있다. 이것이 기계 거래 신뢰를 구축하는 첫 번째 사실 계층이다.

3.6 여섯 번째 관문: 통합 대사와 책임 정의

하나의 작업은 십여 건의 소액 구매를 포함할 수 있다. 각 거래가 서로 다른 지갑, 프로토콜, 판매자 백오피스에 흩어져 있다면, 사용자는 최종 산출물에 왜 이러한 비용이 발생했는지 알기 어렵다. 기업은 또한 지출을 프로젝트, 팀, 고객, 비용 센터에 귀속시키고 감사 가능한 증거를 보존해야 한다.

통합 원장은 구매 의도, 판매자, 견적, 승인 정책, 정산 결과, 응답 상태, 실패 원인을 동시에 기록해야 한다. 이는 재무뿐만 아니라 에이전트 최적화에도 기여한다. 시스템은 어떤 데이터 소스가 자주 실패하는지, 어떤 경로가 비용이 더 높은지, 특정 작업 유형의 전형적인 구매 조합을 분석할 수 있다.

결제가 추론 체인에 내장되면, 비용은 모델 의사 결정의 피드백 신호가 된다. 통합 대사가 없으면 에이전트는 답변만 최적화할 수 있을 뿐, 답변을 얻는 경제적 과정을 최적화할 수 없다. Agent Payment의 장기적 가치의 상당 부분은 바로 이러한 관측 가능성에서 비롯된다.

4. 결제 프로토콜에서 기계 조달 계층으로

4.1 미래의 핵심 추상화는 'Pay'가 아니라 'Buy'이다

결제는 대상과 가격이 명확해진 후의 행동이며, 조달은 요구 사항부터 검수까지의 전체 과정을 포괄한다. 에이전트에 pay() 함수를 노출하는 것은 알려진 주소로 송금하게 할 뿐이다. buy() 능력을 노출해야 시스템이 요구 사항을 수신하고, 서비스를 발견하고, 방안을 비교하고, 결제를 실행하고, 검증 가능한 결과를 반환할 수 있다.

이 차이가 업계 분업을 결정한다. 프로토콜은 표준화된 결제 메시지를 제공하고, 지갑은 서명과 자산을 관리하며, 정산 네트워크는 가치를 이동시키고, 디렉터리는 공급을 집계하며, 조달 계층은 이러한 구성 요소를 하나의 작업으로 조직한다. 어떤 단일 구성 요소도 중요하지만, 독립적으로 완전한 거래를 대표할 수는 없다.

기계 조달 계층은 개방성을 유지해야 합니다. 모든 상인에게 동일한 프로토콜로의 이전을 요구해서도 안 되고, 폐쇄된 디렉터리로 누가 구매될 수 있는지 결정해서도 안 됩니다. 더 지속 가능한 모델은 다양한 결제 레일을 호환하고, 견적에 라우팅 비용을 공개하며, 에이전트가 정책에 따라 자율적으로 선택할 수 있게 하는 것입니다.

4.2 구매자 집계가 판매자 집계보다 더 중요할 수 있다

인터넷 플랫폼은 일반적으로 공급을 먼저 집계한 후 소비자를 유인합니다. 기계 시장에서는 공급이 이미 API 형태로 광범위하게 존재하며, 부족한 것은 지속적으로 구매할 수 있는 표준화된 구매자입니다. 무장된 에이전트는 분산되고 일시적인 수요를 안정적인 거래 흐름으로 전환할 수 있습니다.

구매자 집계는 롱테일 서비스의 가시성도 높입니다. 인간 개발자는 새로운 공급자를 평가하는 시간 비용이 높기 때문에 익숙한 대형 브랜드를 선호하는 경향이 있습니다. 에이전트가 표준화된 능력, 가격 및 이행 신호를 읽을 수 있다면 매 작업마다 더 적합한 서비스를 선택할 수 있습니다. 이는 신규 상인의 고객 획득 비용을 낮추고, 성숙한 상인이 실제 성과로 경쟁하도록 강제할 수 있습니다.

그러나 구매자 진입점도 새로운 플랫폼 권력을 형성합니다. 누가 기본 디렉터리, 정렬 및 결제 경로를 통제하는지가 트래픽 분배에 영향을 미칠 수 있습니다. 따라서 업계는 투명한 정렬 규칙, 설명 가능한 수수료 및 이전 가능한 거래 기록이 필요합니다. 집계는 마찰을 줄일 수 있지만, 개방형 프로토콜을 폐쇄형 채널로 재포장해서는 안 됩니다.

4.3 실제 거래 데이터 기반 신뢰 구축

기계 구매자의 의사 결정 속도는 매우 빠르며, 긴 실사에 의존할 수 없습니다. 견적이 나타날 때 거래 상대방 신호를 동시에 얻어야 합니다. 전통적인 평점과 사용자 평가는 참고가 될 수 있지만, 어뷰징, 시빌 계정 및 이해관계자에 의해 조작되기 쉽습니다. 평가가 실제 결제를 요구하지 않으면 공격 비용은 특히 낮습니다. 최근 ERC-8004——최초의 에이전트 대상 무허가 온체인 신뢰 계층——에 대한 실증 연구가 이를 입증합니다 [6]. 해당 프로토콜의 규범 원문에는 「Payments are orthogonal to this protocol」(결제는 이 프로토콜과 직교한다)라고 명시되어 있습니다——평가는 기본적으로 실제 유료 거래에 바인딩될 필요가 없으며, 결제 증명은 선택적 필드일 뿐입니다. 결과적으로: 이더리움, BSC 및 Base 세 체인에서 (2026년 5월 13일 기준) 각각 73.5%, 59.2% 및 90.6%의 평가자가 협력적 시빌 행동을 보였습니다.

더 신뢰할 수 있는 기반은 실제 유료 호출과 연결된 결과 기록입니다: 특정 서비스 엔드포인트가 얼마나 많은 결제를 완료했는지, 응답 성공률은 어떤지, 일반적인 지연은 얼마인지, 결제 후 무응답 비율은 얼마나 높은지. 이러한 지표는 여전히 내용 품질을 완전히 대표할 수 없지만, 자기 선언보다 검증 가능한 사실에 더 가깝습니다.

데이터가 축적됨에 따라 시장에는 계층화된 평판이 나타날 수 있다. 첫 번째 계층은 객관적 거래 상태이고, 두 번째 계층은 재현 가능한 서비스 지표이며, 세 번째 계층이야말로 구체적인 작업에 대한 품질 평가이다. 에이전트는 금액과 위험에 따라 필요한 증거 강도를 선택할 수 있다. 몇 센트짜리 데이터 조회는 통계적 신호에만 의존해도 충분하지만, 고가치 조달에는 보증, 감사 또는 분쟁 해결이 필요하다.

4.4 예산 전략은 에이전트의 중요한 능력이 될 것이다

오늘날 에이전트를 평가할 때는 주로 답변 품질, 작업 완료율, 도구 호출 정확성을 본다. 유료 환경에 진입하면 경제적 지표도 추가해야 한다. 동일한 품질을 달성하는 데 얼마를 쓰는지, 예산 내에서 완료하는지, 언제 더 비싼 데이터를 살 가치가 있는지, 그리고 속도, 비용, 신뢰성 사이에서 어떻게 균형을 잡을 것인지가 그것이다.

이는 새로운 훈련 및 평가 방향을 낳는다. 에이전트는 '어떤 도구가 질문에 답할 수 있는가'뿐만 아니라 '현재 작업 가치 아래에서 이 도구를 구매하는 것이 경제적으로 합리적인가'도 학습해야 한다. 먼저 저비용 서비스로 선별한 뒤 핵심 결론에 대해서는 고품질 검증을 구매할 수도 있고, 예산이 거의 소진되었을 때 호출 빈도를 낮추거나 사용자에게 추가 권한을 요청할 수도 있다.

이런 의미에서 Agent Payment는 모델 능력 밖의 재무 플러그인이 아니라 의사결정 지능의 일부이다. 진정으로 성숙한 에이전트는 자원을 사용할 줄 알 뿐만 아니라 자원에 가격을 매길 줄도 알아야 한다.

5. Agent Payment의 가능한 진화 경로

5.1 1단계: 개발자 도구와 디지털 서비스가 먼저 온다

가장 먼저 규모화될 시나리오는 여전히 순수 디지털 전달일 가능성이 크다. 예를 들어 검색, 데이터, 프록시 크롤링, 모델 추론, 코드 실행, 스토리지, 콘텐츠 생성 등이다. 이러한 서비스는 자체적으로 API를 통해 제공되고, 한계 전달 비용이 낮으며, 결제와 응답이 동일한 네트워크 세션에서 완료될 수 있고, 복잡한 물류도 수반하지 않는다.

이 단계의 전형적인 금액은 매우 작고, 사용자는 개발 편의성과 작업 완료율에 관심을 둔다. 시장은 프로토콜을 빠르게 검증하겠지만 거래량은 고도로 분산될 수 있다. 많은 호출은 여전히 전통적인 API Key와 구독으로 처리되고, 머신 결제는 임시 수요, 판매자 간 조달, 사전 계좌 개설이 불가능한 롱테일 서비스에 더 많이 사용될 것이다.

5.2 2단계: 기업 예산과 다중 에이전트 협업

기업이 여러 에이전트를 배포하기 시작하면 자금 관리는 개인 지갑에서 조직 수준의 계정 체계로 업그레이드된다. 기업은 서로 다른 역할에 예산을 할당하고, 구매 가능 품목을 통제하고, 승인 임계값을 설정하고, 지출을 재무 시스템에 기록해야 한다. 에이전트 간 내부 결제도 형성될 수 있다. 연구 에이전트는 데이터를 조달하고, 분석 에이전트는 컴퓨팅 파워를 구매하며, 실행 에이전트는 외부 서비스를 호출한다.

이 시점에서 보안과 규정 준수의 중요성은 결제의 참신함을 넘어서게 됩니다. 기업은 키 위탁, 권한 격리, 거래 모니터링, 공급업체 심사 및 감사 추적에 관심을 갖습니다. 기존 재무 프로세스와 호환되는 인프라만이 실험에서 생산으로 진입할 수 있습니다.

5.3 3단계: 디지털 서비스에서 실물 경제로 확장

항공권, 호텔, 물류, 광고 및 전문 서비스는 모두 에이전트 구매 대상이 될 수 있지만, 현실 세계의 거래에는 더 복잡한 신원, 환불, 세무 및 분쟁 처리가 필요합니다. 스테이블코인은 결제 문제의 일부만 해결할 수 있으며, 소비자 권리와 상업 계약을 대체할 수 없습니다.

따라서 업계는 '자율 결제'를 모든 중개자의 제거로 오해해서는 안 됩니다. 오히려 거래 가치가 높아짐에 따라 보증, 보험, 신용 및 중재가 다시 등장하지만, 이들은 기계가 호출할 수 있는 서비스로 전환되어야 합니다. 미래의 Agent Payment 스택은 단일 경로가 다른 경로를 대체하는 것이 아니라 개방형 결제 프로토콜과 전통 금융 연결을 동시에 포함할 수 있습니다.

5.4 4단계: 프로토콜 간 라우팅에서 시장 간 실행으로

장기적으로 에이전트가 구매하는 것은 단순한 API 응답이 아니라 결과입니다. 사용자는 '신뢰할 수 있는 산업 보고서 생성'을 요청할 수 있으며, 시스템은 검색, 데이터베이스, 번역, 모델 및 검증 서비스를 자체적으로 조합합니다. 기저에서 여러 거래가 발생하지만, 사용자는 총 예산, 증거 출처 및 최종 결과물만 봅니다.

이는 결제 라우팅을 시장 실행으로 업그레이드합니다. 시스템은 복잡한 목표를 구매 조합으로 분해하고, 실패한 공급업체를 동적으로 교체하며, 총 비용과 품질 사이에서 최적화해야 합니다. 프로토콜 호환성은 기초일 뿐이며, 진정한 장벽은 요구 이해, 거래 데이터 및 실행 피드백에서 비롯됩니다.

6. 리스크와 해결 과제

Agent Payment의 상상력은 크지만 현실적 제약을 무시할 수 없습니다. 첫째는 보안입니다. 프롬프트 인젝션은 에이전트가 악성 서비스를 구매하도록 유도할 수 있고, 공급망 공격은 수취 주소를 바꿀 수 있으며, 잘못된 정책은 대량의 중복 결제를 초래할 수 있습니다. 결제 동작은 신뢰할 수 없는 콘텐츠와 격리되어야 하며, 한도, 시뮬레이션, 취소 및 이상 탐지 기능을 갖추어야 합니다.

둘째는 프라이버시입니다. 구매 기록은 에이전트가 어떤 작업을 수행 중인지 노출하며, 온체인 공개 데이터는 사용자 신원과 상업적 의도를 연결할 수 있습니다. 시스템은 민감한 메타데이터 유출을 최소화하고, 감사 요구와 프라이버시 사이에서 균형을 이루어야 합니다.

셋째는 책임입니다. 에이전트가 잘못 구매하거나, 판매자가 미배송하거나, 프로토콜 전환이 실패할 때 손실은 누가 부담해야 합니까? 소액 거래는 자동화 리스크를 수용할 수 있지만, 고액 거래는 명확한 책임 경계가 필요합니다. 분쟁 메커니즘이 없는 결제 네트워크는 고가치 상업에 직접 진입하기 어렵습니다.

네 번째는 규제입니다. 스테이블코인 발행, 지갑 통제, 국경 간 이전, 가맹점 수금은 각기 다른 관할권의 규칙에 영향을 받습니다. 기계는 집행자일 뿐 법적 책임 주체가 아닙니다. 인프라는 모든 자율 거래를 명확한 운영자, 승인 정책, 자금 출처로 추적할 수 있어야 합니다.

다섯 번째는 상업적 지속 가능성입니다. 소액 결제 수익은 네트워크 비용, 유동성, 리스크 관리 비용에 쉽게 잠식됩니다. 플랫폼이 숨겨진 마진으로 경험을 보조하면 구매자 신뢰를 훼손하게 됩니다. 수수료는 투명해야 하며, 규모, 라우팅 효율성, 부가 서비스를 통해 합리적인 비즈니스 모델을 구축해야 합니다.

이러한 문제들은 이 분야를 부정하는 것이 아니라, Agent Payment가 단일 프로토콜만으로 완성되지 않는다는 것을 보여줍니다. 결국 결제, 신원, 권한, 발견, 평판, 대사의 복합 인프라가 될 것입니다.

7. SELAT: 기계 네이티브 상업을 위한 구매자 역량 강화

「SELAT」은 말레이어로 「해협」을 뜻하며, 예를 들어 말라카 해협(Selat Melaka)을 가리킵니다. 수백 년 동안 화물이 어느 항구에서 와서 어느 시장으로 향하든, 동서양 무역의 주류는 이 수로를 통과했습니다. SELAT는 기계 네이티브 상업에서 그 해협이 되고자 합니다. 가맹점이 어느 트랙에 정박하든, 에이전트의 수요가 이곳을 통해 흐를 수 있도록 말입니다.

SELAT는 AI 네이티브 기업으로, 구매자 측에서 기계 결제에 접근합니다. SELAT는 기계 네이티브 상업의 구매자 레이어이며, 핵심 목표는 가맹점에 이전을 요구하는 새로운 결제 트랙을 또 만드는 것이 아니라, 에이전트가 기존 트랙을 넘나들며 조달을 완료할 수 있게 하는 것입니다. 두 가지 핵심 문제에 집중합니다. 첫째는 결제 구성의 파편화로, 트랙, 프로토콜, 체인, 자격 증명이 각기 달라 가맹점마다 새로운 통합이 필요합니다. 둘째는 거래 상대방 리스크 측정의 부재로, 결제 성공이 서비스 제공을 의미하지는 않습니다.

그림 3: SELAT 구매자 레이어 개략도

파편화 문제에 대응하여, SELAT CLI는 프로토콜, 결제 방식, 결제 네트워크의 차이를 인프라 레이어에 남겨두고 에이전트가 하나의 명령으로 트랙 간 조달을 완료할 수 있게 합니다. 발견, 견적, 승인, 결제, 납품 상태 기록, 대사가 모두 하나의 조달 흐름에 포함되며, 모든 호출도 동일한 원장에 기록됩니다.

• 하나의 자금 풀, N개의 결제 트랙 사용

에이전트는 자체 보관 USDC 잔액을 보유하며, 체인별로 자금을 미리 배치할 필요도, 프로토콜마다 다른 클라이언트를 유지할 필요도 없습니다.

• 집계형 엔드포인트 카탈로그

SELAT CLI는 Circle, MPP, Apify, pay.sh 네 개의 서드파티 서비스 레지스트리와 SELAT 자체 카탈로그를 통합하여, 에이전트가 실시간 의도에 따라 4,000개 이상의 서비스 엔드포인트를 발견하고 비교할 수 있게 합니다.

• 하드 지출 상한

운영자는 건당 상한과 세션 예산을 설정하고 언제든지 지출 권한을 동결할 수 있으며, 에이전트는 스스로 한도를 높일 수 없습니다.

• 판매자 제로 마이그레이션

판매자는 자신이 선택한 결제 레일을 유지할 수 있으며, SELAT에 재등록하지 않고도 에이전트에게 발견되고 구매될 수 있습니다.

자금 측면에서 SELAT은 Circle 및 MetaMask의 에이전트 지갑을 포함한 모든 에이전트 지갑과 조합하여 사용할 수 있습니다. SELAT은 x402와 MPP 등 결제 레일 간에 각 구매를 라우팅하며, 실시간 견적을 기준으로 합니다.

7.1 ERC-8004: 프리미티브는 올바르나 신호는 의문

ERC-8004는 신원, 평판, 검증 세 가지 레지스트리를 정의하고 구매자가 판매자에게 평가를 제출할 수 있도록 합니다. 방향은 맞지만, 결제와 평판을 명확히 분리합니다: 피드백이 실제 거래에서 비롯될 필요가 없으며, 결제 증명 첨부도 선택 사항입니다.

배포된 생태계에 대한 실증 연구에 따르면, Base에서 93.8%의 평가자가 x402 결제를 한 번도 한 적이 없음에도 94.9%의 피드백을 기여했으며, 다수의 피드백이 조직적 시빌 행위를 보였습니다 [6]. 레지스트리가 기록하는 것은 선언이며, 구매자가 진정으로 필요로 하는 것은 결과입니다.

7.2 실제 거래 데이터에 연관된 평판이야말로 구매자에게 필요한 것

결제 레일은 자금이 결제되었는지 확인할 수 있지만 서비스가 무엇을 반환했는지는 볼 수 없고, 판매자는 자신의 응답을 볼 수 있지만 전체 시장은 볼 수 없으며, 레지스트리는 엔드포인트를 나열할 수 있지만 평가가 실제 구매에서 비롯되었음을 증명할 수 없습니다.

구매를 실행하는 구매자 계층이 거래의 양쪽 끝을 연결할 가장 좋은 기회를 가집니다: SELAT을 통해 완료된 모든 구매는 어느 엔드포인트에 결제했는지, 얼마가 결제되었는지, 그리고 결제 후 전달 상태 메타데이터(2xx, 4xx, 5xx)를 기록합니다. 이러한 기록이 판매자와 결제 레일별로 지속적으로 축적되면서 '결제–전달 그래프'(Settlement–Delivery Graph)의 데이터 기반을 구성합니다.

정확히 구분해야 합니다: 결제와 전달 상태가 연관된 기록이 전달 품질이나 견적 정확성에 대한 독립적 증명과 동일하지는 않습니다. 그러나 등록식 평판에 부족한 기반, 즉 실제 유료 호출과 연관된 결과 데이터를 제공합니다.

7.3 거래 전 거래 상대방의 신용 조회

사람들이 X에서 제4세대 인터넷을 위한 Google PageRank와 유사한 Trust 메커니즘을 어떻게 설계할지 논의하고 있을 때, SELAT은 이미 결제-배송 그래프 위에 '거래가능성 지수'(Transactability Index)를 출시하여, 에이전트가 런타임에서 실제 거래 결과로 뒷받침되는 거래 상대방 신용 데이터를 얻을 수 있도록 하는 것을 목표로 하고 있다.

지수는 견적과 함께 반환되며, 에이전트에게 작업을 중단하고 별도로 상인을 조사하도록 요구하지 않는다. 이는 위험을 표시하되 시장을 대신해 제한을 두지 않는다: 엔드포인트는 여전히 발견되고 구매될 수 있으며, 에이전트는 예산, 작업 중요성 및 위험 선호도에 따라 결정을 내린다.

에이전트는 브랜드 스토리를 읽을 시간이 없다. 그것은 결제 전에 알아야 한다: 이 엔드포인트가 실제 거래에서 어떻게 수행되는지를. 머신 네이티브 상거래의 신용은 선언에서 오는 것이 아니라 결과에서 와야 한다.

그림 3: 견적 단계의 거래가능성 신호

현재 SELAT CLI는 Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes 및 Grok Bot 등 에이전트 실행 환경에 적응되었다.

8. 요약: 머신 경제에 필요한 것은 더 빠른 결제 레일만이 아니다

Agent Payment는 과대평가되기 쉽고 과소평가되기도 쉬운 단계에 있다. 과대평가되기 쉬운 이유는 기술적으로 스테이블코인 결제를 완료하는 것이 에이전트가 성숙한 상업적 자율 능력을 갖추었다는 것을 의미하지 않기 때문이며; 과소평가되기 쉬운 이유는 소프트웨어가 명확한 제약 아래에서 외부 능력을 구매할 수 있게 되면 머신 경제의 조직 방식, 가격 책정 방식 및 경쟁 경계가 변화할 것이기 때문이다.

결제 프로토콜은 이미 머신이 견적을 받고 결제를 완료할 수 있음을 증명했다. 다음的关键은 고립된 결제를 완전한 조달로 확장하는 것이다: 에이전트가 적합한 서비스를 찾고, 실제 비용을 이해하고, 예산 내에서 크로스 레일 결제를 하고, 배송을 확인하고, 모든 거래를 감사 가능하고 학습 가능한 기록으로 전환하도록 하는 것.

미래의 머신 경제는 하나의 체인, 하나의 프로토콜 또는 하나의 지갑만으로 이루어지지 않을 것이다. 다양한 공급이 장기적으로 존재할 것이며, 진정으로 가치 있는 인프라는 구매자가 이러한 복잡성을 헤쳐 나가도록 도울 것이다. Agent Payment는 레일, 공급, 기본 결제 및 신뢰 메커니즘을 결합해야만 기술적 용량을 실제 수요로 전환할 수 있다.

소프트웨어가 구매자가 되기 시작할 때, 결제는 단지 첫 걸음일 뿐이다. 더 중요한 문제는 항상 이것이다: 그것이 통제 가능하고, 투명하며, 검증 가능한 방식으로 진정으로 유용한 거래를 완수할 수 있는가.

참고 자료

[1] Circle, 《Building the Open Agentic Economy》, 2026. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, 《Counterparty Risk in Agentic Payments: The Unmeasured Half》, 2026. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, 《Powering AI commerce with the new Agent Payments Protocol (AP2)》, 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] x402 Foundation, 《x402: 개방형 인터넷 네이티브 결제 표준》. https://github.com/x402-foundation/x402

[5] Machine Payments Protocol, 《MPP: HTTP 402 기반 머신 결제 프로토콜》. https://mpp.dev/

[6] Xiong 외, 《Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem》, arXiv, 2026. https://arxiv.org/abs/2606.26028