기계 중심 거래: 현재 상태 및 부재 중인 인프라
Tapbit Wire출처: 워터드롭 캐피탈
요약
대규모 모델은 질문에 답하는 도구에서 계획 수립·도구 호출·결과 제공이 가능한 지능형 에이전트로 진화하고 있다. 동시에 스테이블코인 정산, HTTP 기반 결제 프로토콜(HTTP 402), 스마트 월렛이 결합해 기계용 결제 인프라를 구축하기 시작했다. 프로그램은 실행 시점에 견적을 받아 서명 후 마이크로지불을 완료할 수 있으며, 이는 몇 년 전만 해도 개념에 불과하던 것이 이제 실현 가능한 기술 경로가 되었다.
그러나 '기계가 지불할 수 있다'는 것과 '기계가 거래를 완료할 수 있다'는 것은 동일하지 않다. 지능형 에이전트가 검색·데이터·컴퓨팅 파워·콘텐츠 생성·전문 분석 서비스 등을 구매해야 할 때, 여전히 엔드포인트 발견·견적 비교·교차 프로토콜 결제·예산 관리·서비스 전달 검증·정산 통합 등 여러 과제에 직면한다. 결제 레일은 가치 이동 방식을 해결하지만, 수요가 공급을 어떻게 찾는지 또는 지불 후 올바른 서비스가 제공되었는지는 자동으로 해결하지 못한다.
이는 다음 단계의 에이전트 결제에서 경쟁 초점이 더 이상 프로토콜 처리량·정산 속도·지원 체인 수에만 국한되지 않고, 진정한 기계 구매자 인프라를 구축할 수 있는지 여부로 옮겨갈 수 있음을 의미한다. 본 고에서는 에이전트 결제가 수요 구조·프로토콜 진화·실무상 병목·시장 역할 분담 측면에서 독립된 트랙이 될 이유와, 확장 적용을 위해 여전히 부족한 핵심 요소들을 논의한다.
서론: 지능형 에이전트가 제한된 '임의 예산'을 획득하다
지난 2년간 지능형 에이전트 역량은 급속히 진화했다. 초기 대규모 모델은 정보 생성에 주력했으며, 사용자가 질문하면 모델이 텍스트를 생성했다. 이후 도구 호출 기능을 통해 웹 페이지 검색·데이터베이스 조회·코드 실행·소프트웨어 조작이 가능해졌다. 더 나아가 에이전트는 목표를 분해하고 계획을 수립하며 외부 결과에 따라 여러 실행 라운드에 걸쳐 행동을 조정하기 시작했다.
실행 대상이 무료 도구나 내부 기업 시스템에 국한될 경우, 호출 권한은 개발자가 사전에 설정할 수 있었다. 그러나 개방 시장에서 고품질 기능은 일반적으로 유료다: 실시간 금융 데이터는 호출당 과금되며, 웹 스크래핑은 크레딧 소모, 추론 및 GPU 컴퓨팅 파워는 사용량 기준 과금, 영상 생성 및 전문 데이터베이스는 명확한 가격 책정이 존재한다. 지능형 에이전트가 독립적으로 작업을 완료하려면 실행 시점에 반드시 구매자로서의 역할을 수행해야 한다.
기존 API 비즈니스 모델은 이러한 구매자 유형을 위해 설계되지 않았다. 사람에게는 먼저 웹사이트 방문·계정 등록·은행카드 연결·요금제 선택·API 키 보관·프로그램 환경 내 키 삽입 등 일련의 수작업이 필요하다. 구매 결정과 실제 호출은 시간적으로 분리되어 있으며, 인간은 작업 이전에 구매를 완료하고 소프트웨어는 이미 구매한 할당량만 소비한다.
에이전트는 특정 작업 단계에 도달하기 전까지 무엇이 필요한지 알지 못할 수 있다. 어떤 데이터 소스를 최종 호출할지 미리 예측할 수 없으며, 잠재적 서비스마다 사용자에게 계정 개설을 요구해서도 안 된다. 이들의 조달 특성은 즉시성·저단가·다수 상점·고빈도·결과 중심이다. 따라서 가장 자연스러운 경험은 '먼저 구독 후 호출'이 아니라 '서비스 발견 → 견적 확인 → 결제 승인 → 결과 수령'이다.
따라서 에이전트 결제는 챗봇에 결제 버튼을 추가하는 문제가 아니다. 소프트웨어가 제한된 지출 권한을 갖게 되고, 기계만을 위한 조달 프로세스가 형성되는 것이다. 인간은 목표·예산·위험 한계를 설정하고, 에이전트는 그 범위 내에서 자금을 배분한다. 결제는 단순 정산 행위에서 에이전트의 의사결정 시스템 일부로 전환된다.
1. 왜 에이전트 결제가 독립된 트랙이 될까
1.1 도구 호출에서 경제적 행위로
에이전트와 일반 자동화 스크립트의 차이는 단지 추론 능력에 있지 않다. 스크립트는 사전 정의된 절차를 실행하며, 필요한 자원과 공급업체는 보통 코드에 하드코딩된다. 반면 에이전트는 환경에 따라 경로를 선택한다. 동일한 연구 과제에서 먼저 검색 결과를 구매한 후, 그 결과에 따라 산업 데이터베이스가 필요한지 판단하고, 마지막으로 교차 검증을 위해 다른 모델을 호출할 수 있다. 각 조달 단계는 후속 결정을 바꾼다.
이 '실행 중 조달' 모델은 소프트웨어 실행 시점에 경제적 선택을 도입한다. 에이전트는 도구의 가용성뿐 아니라 구매 가치도 판단해야 한다: 가격이 예산을 초과하는지, 응답 속도가 작업 요구사항을 충족하는지, 과거 이행 신뢰도는 어떤지, 대체 서비스가 더 적합한지 등이다. 기존 도구 라우팅은 기능 매칭에 집중하지만, 기계 조달은 동시에 가격과 거래 상대 위험도를 관리해야 한다. 이러한 거래에서 위험을 부담하는 주체는 바로 에이전트 자체이며, 결제는 성공할 수 있지만 서비스는 제공되지 않을 수 있다.
따라서 에이전트 결제의 핵심 요구는 무조건적인 자동 결제가 아니라, 소프트웨어에 통제 가능한 구매 권한을 위임하는 것이다. 사용자는 자신의 전체 지갑을 에이전트에게 쉽게 맡기지 않겠지만, 명확한 작업을 위해 몇 달러의 예산을 설정하고, 수 센트 단위의 여러 구매를 허용하는 데는 동의할 것이다. 대규모 승인은 여전히 장기적인 신뢰 구축이 필요하지만, 소규모 승인은 이미 실질적 가치를 창출할 수 있다.
1.2 마이크로페이먼트, 고빈도 거래, 다중 상점으로 인한 결제 경제 변화
인간 중심 인터넷의 결제 인프라는 비교적 낮은 빈도·높은 금액 거래를 잘 처리한다. 신용카드 네트워크, 결제 게이트웨이, 정기구독 시스템은 모두 고정 비용을 수반하므로 상점은 보통 여러 요청을 월 단위 패키지로 묶는다. 개별 API 호출당 몇 센트에 불과한 경우, 기존 결제 수수료, 부정청구 위험, 계좌 관리 비용이 상품 가치를 초과할 수 있다.
기계 소비는 정반대다. 에이전트는 단일 결과물을 완성하기 위해 수분 안에 여러 상점에서 여러 구매를 시작할 수 있다. 거래금액은 극히 작지만 호출 빈도는 매우 높으며, 총 거래 건수는 인간 소비자를 훨씬 넘을 수 있다. 스테이블코인과 체인상 프로그래밍 가능한 정산은 이러한 시나리오에 새로운 경제적 기반을 제공한다: 자금은 24시간 내내 이동 가능하며, 결제 승인은 소프트웨어가 서명하고, 서비스는 호출 단위로 직접 가격 책정이 가능하다.
더 중요하게, 다중 상점 조달은 API 시장 내 경쟁 방식을 바꾼다. 정기구독 모델은 사용자가 장기간 한 공급업체에 종속되도록 유도하지만, 사용량 기반 과금은 에이전트가 각 작업마다 동적으로 선택하도록 한다. 서비스 제공업체는 더 이상 연간 계약만을 두고 경쟁하지 않으며, 순간적인 필요성에도 대응해야 한다. 가격, 성능, 이행 실적 등이 실시간으로 라우팅 결과에 영향을 줄 수 있다.
1.3 스테이블코인: 교환 매체에서 정산 인프라로 진화
초기 암호화폐 시장에서 스테이블코인 수요는 주로 거래 및 안전자산 전환에 집중되었다. 발행, 보관, 규제 준수, 크로스체인 인프라가 점차 성숙함에 따라 스테이블코인은 국경 간 정산, 기업 자금관리, 인터넷 원생 결제 분야로 진입하고 있다. 기계 결제에 있어 스테이블코인은 또 다른 특별한 이점이 있다: 화폐이자 프로그램이 직접 조작 가능한 디지털 자산이라는 점이다.
신용카드 결제는 카드 소유자 신원, 은행 계좌, 지리적 네트워크에 의존한다. 에이전트 자체는 자연인 신분을 가지지 않으며 전통적인 계좌 개설 절차를 독립적으로 통과할 수 없다. 그러나 정책 기반 월렛은 에이전트의 자금 인터페이스가 될 수 있다: 운영자가 제한된 잔액을 투입하고, 거래당·세션당 한도를 설정하며, 동결 및 취소 권한을 보유한다. 에이전트는 승인 범위 내에서만 결제를 서명한다.
이는 체인상 결제가 모든 전통적 결제보다 본질적으로 우월하다는 의미가 아니다. 소비자 보호, 환불 메커니즘, 개인정보 보호, 키 관리, 규제 책임 등은 여전히 해결되어야 한다. 그러나 기계 간(M2M), 저가형 사용량 기반 과금, 글로벌 서비스 조달에서는 프로그래밍 가능한 스테이블코인이 명확한 호환성을 갖는다. 이는 ‘인터페이스 호출’과 ‘인터페이스 결제’를 처음으로 동일한 네트워크 상호작용으로 압축할 기회를 제공한다.
2. 결제 레일이 이미 등장: x402, MPP, HTTP-네이티브 거래
2.1 402 상태 코드를 상업적 인터페이스로 전환
HTTP는 오래전부터 402 결제 필요 상태 코드를 예약했으나, 약 30년간 일반적인 워크플로로 자리잡지 못했다. 기계 결제 프로토콜이 이 의미론을 재활성화했다: 클라이언트가 유료 엔드포인트를 요청하면, 서버는 402와 기계 판독 가능한 결제 조건을 반환한다. 클라이언트는 수용 가능한 옵션을 선택해 서명 또는 결제를 완료한 후, 자격 증명을 포함해 요청을 재시도한다.
이 과정의 중요성은 인간용 등록 페이지를 제거한다는 점에 있다. 가격 탐색, 결제 요구사항, 콘텐츠 전달이 모두 프로그램이 이해할 수 있는 프로토콜 계층에서 발생한다. 개발자에게는 유료 API가 더 이상 계정·요금제·키를 위한 완전한 SaaS 포털을 구축할 필요가 없으며, 에이전트에게는 서비스가 일반 웹페이지처럼 탐색되고 실제 필요 시 구매될 수 있다.
x402는 이 경로에서 가장 주목받는 오픈 프로토콜 중 하나다. HTTP 402를 중심으로 결제 도전 과제와 자격 증명을 구성해, 서비스 제공자가 요청 단위로 결제를 수령할 수 있도록 한다. 반면 MPP은 다른 생태계에서 출발해 ‘청구’ 및 ‘세션’과 같은 기계 중심 결제 방식을 탐색한다. 두 프로토콜은 구체적 설계에서 차이가 있으나, 함께 하나의 방향을 입증한다: 기계 결제는 별도의 수동 정산 프로세스가 아닌 애플리케이션 프로토콜 일부가 될 수 있다는 점이다.
2.2 결제 레일 다변화의 장기적 성격
산업계는 종종 궁극적으로 단일 표준 프로토콜, 단일 정산 네트워크, 단일 결제 방식만 남을 것으로 기대한다. 그러나 상점 관점에서 보면 다변화에는 장기적 합리성이 있다. 일회성 데이터 조회는 호출당 과금에 적합하지만, 지속적 추론 또는 스트리밍 서비스는 세션 기반 과금이 더 나을 수 있다. 고가격 서비스는 강력한 보증 및 분쟁 처리를 요구하는 반면, 저가격 호출은 속도와 비용을 중시한다. 지역 및 기업별로도 다양한 규제 및 정산 네트워크를 선택할 것이다.
프로토콜 계층은 계속 혁신할 것이다. 상점은 직접 차감, 사전 승인, 에스크로, 스트리밍 결제, 일괄 정산 등을 채택할 수 있으며, 네트워크는 비용·확정성·유동성·생태계 도구에서 서로 다른 트레이드오프를 선택할 것이다. 판매자에게는 선택의 자유이며, 구매자에게는 새 조합마다 추가 통합 인터페이스가 생긴다.
아래 그림의 구성 행렬은 이 다변화의 한 단면이다: 열은 프로토콜/결제 방식, 행은 블록체인을 나타내며, 각 선택은 별도 통합이 필요한 결제 구성이다. 이 표는 여전히 확장 중이다.
그림 1: 단편화 상황에서의 결제 레일 구성 행렬
따라서 단편화는 시장 성숙과 함께 자연스럽게 사라지지 않을 가능성이 높다. 은행카드 시장은 오랜 발전 끝에 단일 카드 조직만 남지 않았고, 클라우드 컴퓨팅도 단일 공급업체로 수렴하지 않았다. 성숙한 시장은 차이를 제거하기보다, 그 위에 집계·라우팅·정산 계층을 형성한다. 에이전트 결제 역시 동일한 진화 경로를 따를 가능성이 높다. 이 분열은 이미 측정 가능하다. 최근 30일(2026년 9월 3일 기준) 두 공개 탐색기(x402scan 및 mppscan) 데이터에 따르면, MPP 프로토콜은 템포 체인에서 65,591개 활성 구매자 월렛을 보유하고, x402는 베이스 체인에서 19,472개를 보유한다. 양 레일 모두에 나타난 월렛은 365개로, MPP 구매자의 0.6% 미만, x402 베이스 구매자의 2%에 불과하다. 이 중 112개 월렛만이 각 레일에서 10회 이상 거래를 완료했으며, 상당수는 동일 키로 사용자를 대신해 결제하는 이중 레일 집계자일 뿐, 구매자 스스로 두 번째 결제 레일을 채택한 것은 아니다. 구매자는 레일 간 이동하지 않고, 각 레일은 독자적인 구매자 기반을 축적 중이다.
2.3 판매자 등록은 거래의 절반에 불과하다
결제 프로토콜은 상인들이 결제를 수락하는 데 필요한 장벽을 먼저 낮춥니다. 엔드포인트가 견적을 게시하고, 자격 증명을 검증하며, 서비스를 반환할 수 있게 되면, 기계 지향 상거래의 기본 조건을 충족하게 됩니다. 이에 따라 점차 늘어나는 개발자 도구, 데이터 서비스, 콘텐츠 인터페이스가 모두 기계 구매 가능해지고 있습니다.
그러나 결제 가능한 공급이 곧 수요가 자동으로 뒤따른다는 의미는 아닙니다. 상인들은 '기계로부터 어떻게 결제를 받을 것인가'라는 문제를 해결하지만, 에이전트는 여전히 '누구에게서 구매해야 하며, 어떤 결제 수단을 사용해야 하며, 결제 후 어떻게 배송 완료를 확인해야 하는가'를 고민해야 합니다. 모든 구매자가 각 프로토콜을 별도로 연동하고, 서로 다른 네트워크에 자금을 미리 준비하며, 독립적인 장부를 관리해야 한다면, 기계 결제는 초기 API 연동의 복잡성을 그대로 반복하게 될 것입니다—단지 API 키 대신 지갑과 프로토콜 어댑터를 사용하는 차이만 있을 뿐입니다.
실제 채택 여부는 정산 단계의 마찰만이 아니라 거래 전 과정의 총 마찰에 달려 있습니다.
3. 산업의 진정한 병목: 거래에 폐쇄 루프가 부재함
그림 2: 기계 조달의 전체 과정
3.1 첫 번째 관문: 구매 가능한 서비스 탐색
에이전트는 기계 판독 가능한 서비스 디렉터리가 필요합니다. 효과적인 디렉터리는 이름과 URL만 포함해서는 안 되며, 엔드포인트 기능, 입력·출력 형식, 가격 단위, 지원 프로토콜, 지연 시간, 지역 제한, 업데이트 상태 등도 반드시 명시해야 합니다. 또한 자연어 의도와 API 파라미터 간 매핑이 필요합니다. 그렇지 않으면 에이전트는 '거시경제 데이터가 필요하다'는 점은 알지만, 어떤 엔드포인트가 해당 작업을 수행할지 판단할 수 없습니다.
오픈 마켓의 디렉터리는 중복, 만료, 허위 주장 등의 문제도 직면합니다. 어떤 상인이라도 고품질 데이터를 제공한다고 주장할 수 있지만, 에이전트는 인간 조달 담당자의 경우처럼 며칠간 배경 조사를 할 여유가 없습니다. 탐색 계층은 엔드포인트 호출 가능성, 견적의 실시간 유효성, 설명과 실제 반환 콘텐츠 간 일치 여부를 지속적으로 검증해야 합니다.
이는 서비스 탐색을 전통적 검색과 구분짓습니다. 검색 엔진은 정보 관련성 최적화에 초점을 맞추지만, 기계 조달 디렉터리는 거래 가능성(기능 일치 여부, 가격 수용성, 결제 호환성, 상인의 이행 능력)도 함께 최적화해야 합니다.
3.2 두 번째 관문: 견적 이해 및 비교
겉보기에는 유사한 API가 모두 호출당 과금되더라도, 실제로는 견적이 약하게 비교 가능합니다. 한 엔드포인트는 요청당 과금하고, 다른 곳은 결과 항목당 과금하며, 또 다른 곳은 모델 추론 비용을 포함하거나 추가 요금을 부과합니다. 일부 서비스는 입력 길이, 실행 시간, 성공 결과 등에 따라 동적으로 요금을 책정하기도 합니다.
에이전트는 표면상 가장 낮은 명목 가격을 제시한 엔드포인트를 단순히 선택할 수 없습니다. 총 비용, 배송 확률, 지연 시간, 결과 품질을 종합적으로 고려해야 합니다. 저렴한 인터페이스가 반복적으로 실패한다면 재시도 비용과 작업 지연으로 인해 실질 가격이 오히려 더 높아질 수 있습니다. 따라서 견적은 서비스 수준, 과거 성능, 작업 맥락과 함께 평가되어야 합니다.
기계 판독 가능한 견적은 유효 기간과 최종 금액도 명시해야 합니다. 동적 가격 책정 환경에서 에이전트가 서명하는 내용은 애매한 가격 범위가 아닌, 확고한 약속이어야 합니다. 운영자는 신뢰할 수 있는 예산 설정을 위해 서비스 수수료, 네트워크 비용, 경로 수수료 등 요금 구성 내역도 반드시 파악해야 합니다.
3.3 세 번째 관문: 자금 분배 및 크로스레일 유동성
에이전트가 여러 블록체인 및 여러 프로토콜을 동시에 활용해 서비스를 구매해야 한다면, 가장 단순한 접근법은 각 네트워크에 사전 자금을 입금하는 것입니다. 그러나 이 방식은 소량의 자본을 여러 조각으로 분산시켜 버립니다. 현재 사용되지 않는 네트워크에는 자금이 유휴 상태로 머무르고, 인기 네트워크는 잔고 부족을 겪을 수 있으며, 잔고 보충에는 브리징, 스왑, 가스비, 보안 작업 등이 수반됩니다.
개별 사용자 입장에서도 이미 번거로운데, 다수의 에이전트를 관리하는 기업에서는 문제가 더욱 심화됩니다: 각 에이전트가 얼마의 잔고를 보유해야 하며, 누가 잔고 보충 책임을 지는가? 자금 오남용을 어떻게 방지할 것인가? 다양한 네트워크에서 자산과 수수료를 어떻게 집계할 것인가? 통합 자금 계층이 없으면 결제 레일이 많아질수록 재정적 복잡성도 급격히 증가합니다.
이상적으로 에이전트가 보는 것은 여러 네트워크 잔고가 아니라 단일한 사용 가능한 예산이어야 합니다. 기반 시스템이 정산 경로 선택, 유동성 관리, 투명한 견적 제공을 담당합니다. 이 원칙은 여행자가 한 장의 카드로 여러 국가에서 소비하는 것과 유사합니다: 사용자는 총 신용 한도와 환율만 고려하면 되며, 각 목적지마다 현지 계좌를 미리 개설할 필요는 없습니다.
3.4 네 번째 관문: 정책 기반 승인
자율 결제가 유발하는 가장 쉽게 촉발되는 우려는 에이전트가 통제 없이 자금을 사용할 가능성입니다. 해결책은 '완전 금지'와 '완전 승인' 사이에서 단순히 선택하는 것이 아니라, 다층적 정책을 수립하는 데 있습니다.
거래당 상한선은 단일 오류로 인한 손실을 제한하고, 세션 예산은 작업 전체의 총 지출을 제한하며, 상인 화이트리스트/블랙리스트는 거래 상대방을 통제하고, 카테고리 규칙은 구매 가능 품목을 제한하며, 빈도 제한은 짧은 시간 내 비정상 호출을 방지합니다. 고위험 또는 고가치 거래는 수동 확인을 트리거할 수도 있습니다. 정책은 운영자가 설정하며, 에이전트는 정해진 경계 내에서만 작동할 수 있고, 스스로 한도를 상향 조정할 수 없습니다.
지갑은 서명 처리만 하는 것이 아니라, 작업, 신원, 감사 기록과도 연동되어야 한다. 이를 통해 '어떤 에이전트가 어떤 작업을 위해 어떤 정책 하에 이 지불을 승인했는가?'라는 질문에 답할 수 있어야 한다. 그렇지 않으면 기업은 단순히 블록체인 상의 거래 해시 문자열만 남게 되며, 내부 통제 및 비용 귀속 요건을 충족할 수 없다.
3.5 단계 5: 성공적인 결제 완료 ≠ 서비스 제공 완료
블록체인은 자금이 한 주소에서 다른 주소로 이동했음을 증명하는 데 뛰어나지만, API가 올바른 콘텐츠를 반환했음을 본질적으로 증명할 수는 없다. 거래는 결제를 완료했을 수 있으나, 서버가 타임아웃되거나 오류 상태를 반환하거나 광고된 내용과 일치하지 않는 데이터를 전달할 수 있다. 이는 에이전트 입장에서 예외 사례가 아니라 조달 리스크의 핵심이다.
기존 이커머스는 물류, 리뷰, 환불을 통해 결제와 배송을 연결하지만, 머신 서비스에는 물리적 물류가 없으며, ‘배송’은 일시적인 HTTP 응답일 뿐일 수 있다. 결제 시스템이 자금 흐름만 기록하고 판매자가 자신만의 응답만 기록한다면, 판매자와 프로토콜 전체를 아우르는 통합 이행 관점이 부재하게 된다.
주의해야 할 점은 응답 기록 자체가 품질 증명을 의미하지 않는다는 것이다. 그러나 결제와 응답을 연계하면 최소한 ‘지불 완료 및 결과 수신’, ‘지불 완료 but 서비스 실패’, ‘미결제’ 등 기본 상태를 구분할 수 있다. 이것이 머신 거래 신뢰성 구축을 위한 첫 번째 사실 계층이다.
3.6 단계 6: 통합 정산 및 책임 정의
단일 작업은 수십 개의 마이크로 구매를 포함할 수 있다. 각 거래가 서로 다른 지갑, 프로토콜, 판매자 백엔드에 산재해 있으면, 사용자는 최종 산출물 비용이 왜 그렇게 책정되었는지 파악하기 어렵다. 기업은 또한 지출을 프로젝트·팀·고객·비용 센터에 귀속시키고, 감사 가능한 증거를 보관해야 한다.
통합 원장은 조달 의도, 판매자, 견적, 승인 정책, 결제 결과, 응답 상태, 실패 사유를 동시에 기록해야 한다. 이는 재무뿐 아니라 에이전트 최적화에도 활용된다. 시스템은 어떤 데이터 소스가 자주 실패하는지, 어떤 경로가 더 비용이 많이 드는지, 특정 유형의 작업에 대한 일반적인 조달 구성비를 분석할 수 있다.
지불이 추론 체인에 내재화되면, 비용은 모델 결정에 대한 피드백 신호가 된다. 통합 정산이 없으면 에이전트는 답변만 최적화할 수 있고, 답변을 얻는 경제적 과정은 최적화할 수 없다. 에이전트 지불의 장기적 가치 중 상당 부분은 바로 이러한 관측 가능성에서 비롯된다.
4. 결제 프로토콜에서 머신 조달 계층으로
4.1 미래의 핵심 추상화는 ‘지불(pay)’이 아니라 ‘구매(buy)’이다
지불은 대상과 가격이 명확해진 후에 실행되는 행동인 반면, 조달은 수요에서부터 수락까지의 전체 과정을 포괄한다. 에이전트에게 pay() 함수만 노출하면 알려진 주소로 자금을 이체할 수 있을 뿐이지만, buy() 기능을 노출하면 시스템이 수요를 수신하고, 서비스를 탐색하며, 옵션을 비교하고, 결제를 실행하며, 검증 가능한 결과를 반환할 수 있다.
이 구분은 업계 내 역할 분담을 결정한다. 프로토콜은 표준화된 결제 메시지를 제공하고, 지갑은 서명 및 자산을 관리하며, 정산 네트워크는 가치를 이동시키고, 디렉토리는 공급을 집계하며, 조달 계층은 이러한 구성 요소들을 단일 작업으로 조직한다. 어느 하나의 구성 요소도 중요하지만, 단독으로는 완전한 거래를 표현할 수 없다.
머신 조달 계층은 개방성을 유지해야 한다. 모든 판매자가 동일한 프로토콜로 이전하도록 요구해서는 안 되며, 폐쇄형 디렉토리로 누가 구매 가능한지를 결정해서도 안 된다. 더 지속 가능한 모델은 다중 결제 인프라와의 호환성 확보, 견적 내 라우팅 비용 공개, 정책 기반 자율 선택을 지원하는 것이다.
4.2 구매자 집약이 판매자 집약보다 더 중요할 수 있다
인터넷 플랫폼은 일반적으로 공급을 먼저 집약한 후 소비자를 유치한다. 그러나 머신 시장에서는 API 형태로 이미 광범위하게 공급이 존재하며, 부족한 것은 지속적인 구매가 가능한 표준화된 구매자이다. 장착된 에이전트는 조각화되고 우발적인 수요를 안정적인 거래 흐름으로 전환할 수 있다.
구매자 집약은 롱테일 서비스의 가시성도 향상시킨다. 인간 개발자는 새로운 공급업체 평가 시간 비용이 높기 때문에 익숙한 대형 브랜드를 선호하는 경향이 있지만, 에이전트는 표준화된 기능·가격·이행 신호를 직접 읽을 수 있어 각 작업에 가장 적합한 서비스를 선택할 수 있다. 이는 신규 판매자의 고객 확보 비용을 낮추고, 기존 판매자에게 실적 기반 경쟁을 강제할 수 있다.
그러나 구매자 진입 경로는 새로운 플랫폼 권력을 창출할 수도 있다. 기본 디렉토리, 순위, 결제 경로를 통제하는 주체가 트래픽 분배에 영향을 미칠 수 있다. 따라서 업계는 투명한 순위 규칙, 설명 가능한 수수료, 이전 가능한 거래 기록을 필요로 한다. 집약은 마찰을 줄일 수 있지만, 개방형 프로토콜을 폐쇄형 채널로 재포장해서는 안 된다.
4.3 실제 거래 데이터 기반 평판 구축
머신 구매자는 매우 신속하게 의사결정하며, 긴 심층 조사를 의존할 수 없다. 견적이 나타나는 동시에 거래 상대방 신호가 필요하다. 전통적 평가 및 사용자 리뷰는 참고 자료가 될 수 있으나, 세탁 거래량, 사이빌 계정, 관련 당사자에 의해 쉽게 조작될 수 있다. 리뷰가 실제 지불을 요구하지 않으면 공격 비용은 특히 낮다. 에이전트를 위한 최초의 허가 없는 블록체인 신뢰 계층인 ERC-8004에 대한 최근 실증 연구는 이를 확인한다[6]. 프로토콜 명세서는 명시적으로 ‘지불은 본 프로토콜과 무관하다’고 규정하며, 리뷰는 기본적으로 실제 유료 거래와 연결되지 않으며, 지불 증명은 선택적 필드일 뿐이다. 그 결과, 이더리움·BSC·베이스(2026년 5월 13일 기준)에서 각각 73.5%, 59.2%, 90.6%의 리뷰어가 조정된 사이빌 행위를 보였다.
보다 신뢰할 수 있는 기반은 실제 유료 호출과 연계된 결과 기록이다: 서비스 엔드포인트가 완료한 결제 건수, 응답 성공률, 일반적인 지연 시간, 결제 후 응답 없음 비율 등이다. 이러한 지표는 여전히 콘텐츠 품질을 완전히 반영하지 못하지만, 자발적 선언보다는 검증 가능한 사실에 더 가깝다.
데이터가 축적됨에 따라 시장은 계층화된 평판 체계를 형성할 수 있다. 1단계는 객관적 거래 상태, 2단계는 재현 가능한 서비스 지표, 3단계는 특정 작업에 대한 품질 평가다. 에이전트는 금액 및 위험도에 따라 필요한 증거 강도를 선택할 수 있다: 데이터 조회는 몇 센트 수준으로 통계적 신호만으로 충분하지만, 고가 구매는 보증·감사·분쟁 해결 등이 요구된다.
4.4 예산 전략은 에이전트의 핵심 역량이 될 것이다
현재 에이전트는 주로 답변 품질, 작업 완료율, 도구 호출 정확도로 평가된다. 유료 환경에 진입하면 경제적 지표도 추가되어야 한다: 동일한 품질 달성을 위해 얼마를 지출했는가, 예산 내에서 작업을 완료했는가, 언제 고가 데이터 구매가 타당한가, 속도·비용·신뢰성 간 균형은 어떻게 맞추는가 등이다.
이는 훈련 및 평가 방향에도 새로운 변화를 가져올 것이다. 에이전트는 단순히 '어떤 도구가 질문에 답할 수 있는가'가 아니라, '현재 작업 가치 대비 이 도구 구매가 타당한가'도 학습하게 된다. 핵심 결론 검증을 위해 저비용 서비스로 사전 필터링 후 고품질 검증을 구매하거나, 예산 소진 직전 호출 빈도를 줄이거나 사용자에게 추가 승인을 요청할 수도 있다.
이 맥락에서 에이전트 결제는 모델 능력 외부의 금융 플러그인이 아니라 의사결정 지능의 일부다. 진정으로 성숙한 에이전트는 자원을 활용할 뿐만 아니라 자원을 가격 책정해야 한다.
5. 에이전트 결제의 가능성 있는 진화 경로
5.1 1단계: 개발자 도구 및 디지털 서비스가 선도
초기 대규모 적용 사례는 검색, 데이터, 프록시 크롤링, 모델 추론, 코드 실행, 저장소, 콘텐츠 생성 등 순수 디지털 전달 서비스가 될 가능성이 가장 높다. 이 서비스들은 API로 제공되며, 한계 배송 비용이 낮고, 동일 네트워크 세션 내 결제 및 응답이 가능하며, 복잡한 물류가 필요 없다.
이 단계의 거래 금액은 매우 작으며, 사용자는 개발 편의성과 작업 완료율을 중시한다. 시장은 프로토콜을 빠르게 검증하겠지만, 거래량은 고도로 분산될 수 있다. 많은 호출은 여전히 기존 API 키와 구독으로 처리되며, 기계 결제는 임시 수요, 다중 상점 조달, 사전 계정 개설이 불가능한 롱테일 서비스에 더 많이 사용될 것이다.
5.2 2단계: 기업 예산 및 다중 에이전트 협업
기업이 여러 에이전트를 배포하기 시작하면 자금 관리는 개인 지갑에서 조직 차원 계정 체계로 업그레이드된다. 기업은 역할별 예산 배정, 구매 가능 범주 통제, 승인 임계값 설정, 지출 재무 시스템 반영 등을 필요로 한다. 에이전트 간 내부 정산도 발생할 수 있다: 연구 에이전트가 데이터를 구매하고, 분석 에이전트가 컴퓨팅 파워를 구매하며, 실행 에이전트가 외부 서비스를 호출한다.
이 시점에서 결제의 혁신성보다 보안 및 규정 준수가 더 중요해진다. 기업은 키 관리, 권한 격리, 거래 감시, 공급업체 심사, 감사 추적을 중시한다. 기존 재무 프로세스와 통합 가능한 인프라만이 실험 단계를 넘어 실제 운영에 진입할 수 있다.
5.3 3단계: 디지털 서비스에서 실물 경제로 확장
항공권, 호텔, 물류, 광고, 전문 서비스 등도 에이전트의 조달 대상이 될 수 있으나, 현실 세계 거래는 더 복잡한 신원 확인, 환불, 세금, 분쟁 처리를 요구한다. 안정화코인은 정산 문제의 일부만 해결할 뿐, 소비자 권리 및 상업 계약을 대체할 수 없다.
따라서 산업계는 '자율 결제'를 모든 중개자를 제거하는 것으로 오해해서는 안 된다. 오히려 거래 가치가 증가함에 따라 보증·보험·신용·중재 등이 다시 등장할 것이며, 단지 기계 호출 가능 서비스로 전환되어야 할 뿐이다. 향후 에이전트 결제 스택은 개방형 결제 프로토콜과 기존 금융 연동을 동시에 포함할 것이며, 한 경로가 다른 경로를 대체하는 것이 아니다.
5.4 4단계: 교차 프로토콜 라우팅에서 교차 시장 실행으로
장기적으로 에이전트가 구매하는 것은 단순한 API 응답이 아니라 결과다. 사용자가 '신뢰할 수 있는 산업 보고서 생성'을 요청하면, 시스템은 자율적으로 검색·데이터베이스·번역·모델·검증 서비스를 조합한다. 하위 계층에서는 여러 거래가 발생하지만, 사용자는 총 예산, 근거 자료, 최종 전달물만 확인한다.
이는 결제 라우팅을 시장 실행으로 업그레이드한다. 시스템은 복잡한 목표를 조달 포트폴리오로 분해하고, 실패한 공급업체를 동적으로 교체하며, 총 비용과 품질 간 최적화를 수행해야 한다. 프로토콜 호환성은 단지 기반이며, 진정한 경쟁 우위는 수요 이해력, 거래 데이터, 실행 피드백에서 나온다.
6. 리스크 및 미해결 질문
에이전트 결제는 엄청난 창의적 잠재력을 지니지만, 현실 세계의 제약을 무시할 수 없다. 첫 번째는 보안이다. 프롬프트 주입으로 인해 악성 서비스 구매를 유도할 수 있고, 공급망 공격으로 수신 주소가 대체될 수 있으며, 결함 있는 정책으로 인해 대규모 중복 결제가 발생할 수 있다. 결제 동작은 신뢰할 수 없는 콘텐츠로부터 격리되어야 하며, 한도 설정, 시뮬레이션, 취소, 이상 탐지 기능을 갖춰야 한다.
두 번째는 프라이버시다. 조달 기록은 에이전트가 수행하는 작업을 노출하며, 블록체인 상의 공개 데이터는 사용자 신원과 상업적 의도를 연결시킬 수 있다. 시스템은 민감한 메타데이터 유출을 최소화하고 감사 요구사항과 프라이버시 사이에서 균형을 맞춰야 한다.
세 번째는 책임 소재다. 에이전트가 잘못된 구매를 하거나, 판매자가 납품을 실패하거나, 프로토콜 변환이 실패할 경우 손실은 누구에게 귀속되어야 하는가? 저가 거래는 자동화된 리스크 수용이 가능하지만, 고가 거래는 명확한 책임 경계를 요구한다. 분쟁 처리 메커니즘이 없는 결제 네트워크는 고가 상거래에 직접 진입하기 어려울 것이다.
네 번째는 규제다. 스테이블코인 발행, 월렛 관리, 국경 간 송금, 판매자 결제 등은 여러 관할권에서 다양한 규칙의 적용을 받는다. 기계는 실행 주체일 뿐 법적 책임 주체가 아니다. 인프라는 모든 자율적 거래를 명확한 운영자, 승인 정책, 자금 출처로 추적할 수 있어야 한다.
다섯 번째는 상업적 지속 가능성이다. 마이크로페이먼트 수익은 네트워크 비용, 유동성, 리스크 관리 수수료 등으로 쉽게 훼손된다. 플랫폼이 숨겨진 마크업으로 경험을 보조한다면 구매자의 신뢰를 훼손하게 된다. 수수료는 투명해야 하며, 규모 확대, 라우팅 효율성, 부가 가치 서비스를 통해 건강한 비즈니스 모델을 구축해야 한다.
이러한 문제들은 해당 분야를 부정하는 것이 아니라, 에이전트 결제가 단일 프로토콜로 완성되지 않음을 보여준다. 궁극적으로 결제, 신원, 권한, 검색, 평판, 정산을 아우르는 복합 인프라가 될 것이다.
7. SELAT: 머신 원생 상거래를 위한 구매자 측 역량 강화
'SELAT'는 말레이어로 '해협'을 뜻하는 단어로, 예를 들어 말라카 해협(Selat Melaka)을 의미한다. 수세기 동안 어느 항구에서 물건이 도착하든, 어느 시장으로 향하든 동서 무역의 주류는 이 해협을 통했다. SELAT는 머신 원생 상거래에서 그런 해협이 되고자 한다: 상점이 어떤 결제 레일에 접속하든, 에이전트 수요는 여기를 통해 흐를 수 있도록 한다.
SELAT는 AI 원생 기업으로, 머신 결제 분야에 구매자 측에서 진입하기로 선택했다. SELAT는 머신 원생 상거래를 위한 구매자 측 계층이다. 그 핵심 목표는 상점이 이전해야 하는 또 다른 결제 레일을 만드는 것이 아니라, 기존 레일을 활용해 에이전트가 조달을 완료할 수 있도록 지원하는 것이다. 이는 두 가지 핵심 과제에 집중한다: 첫째, 결제 설정의 분산—레일, 프로토콜, 블록체인, 자격 증명이 모두 달라 매 상점마다 새로운 연동이 필요하다는 점; 둘째, 거래 상대방 리스크 측정 부재—결제 성공이 반드시 서비스 납품 완료를 의미하지 않기 때문이다.
그림 3: SELAT 구매자 측 계층 개요도
분산 문제 해결을 위해 SELAT CLI는 프로토콜, 결제 방식, 정산 네트워크의 차이를 인프라 계층에 유지하여, 에이전트가 단일 명령어로 다중 레일 조달을 완료할 수 있게 한다. 검색, 견적, 승인, 결제, 납품 상태 기록, 정산까지 전부 동일한 조달 프로세스에 포함되며, 모든 호출은 동일한 장부에 기록된다.
• 하나의 트레저리, N개의 결제 레일 사용
에이전트는 자체 보관형 USDC 잔액을 보유하며, 블록체인별 사전 입금이나 다양한 프로토콜용 클라이언트 유지가 필요 없다.
• 통합 엔드포인트 카탈로그
SELAT CLI는 Circle, MPP, Apify, pay.sh 등 4개 제3자 서비스 레지스트리와 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)은 거래 양쪽 끝을 연결하는 최적 위치에 있다: SELAT를 통한 모든 구매는 지불된 엔드포인트, 정산 금액, 결제 후 전달 상태 메타데이터(2xx, 4xx, 5xx)를 기록한다. 이 기록은 판매자 및 결제 인프라별로 지속적으로 축적되어 ‘정산–전달 그래프’의 데이터 기반을 형성한다.
명확한 구분이 필요하다: 결제와 전달 상태를 연결한 기록은 전달 품질 또는 견적 정확성에 대한 독립적 증거와 동일하지 않다. 그러나 이는 레지스트리 기반 평판이 부족했던—실제 유료 호출과 연계된 결과 데이터—기반을 제공한다.
7.3 거래 전 당사자 신뢰도 확보
사람들이 X에서 4세대 인터넷을 위한 구글 페이지랭크식 신뢰 메커니즘 설계를 논의하던 중, SELAT은 이미 정산–전달 그래프 기반의 ‘거래 가능성 지수(Transactability Index)’를 출시하여 에이전트가 실시간으로 실제 거래 결과에 기반한 당사자 신뢰도 데이터에 접근할 수 있도록 했다.
이 지수는 견적과 함께 반환되며, 에이전트가 작업을 중단하고 판매자를 별도로 조사할 필요가 없다. 위험을 표시하되 시장 진입 장벽을 설정하지 않으며, 엔드포인트는 여전히 탐색 및 구매 가능하며, 에이전트는 예산·업무 중요도·위험 선호도에 따라 결정한다.
에이전트는 브랜드 스토리를 읽을 시간이 없다. 결제 전 반드시 알아야 할 것은: 이 엔드포인트가 실제 거래에서 어떤 성능을 보이는가? 기계 중심 상거래의 신뢰성은 진술이 아닌 결과에서 나와야 한다.
그림 3: 견적 단계의 거래 가능성 신호
현재 SELAT CLI는 Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes, Grok Bot 등 다양한 에이전트 실행 환경에 적용되었다.
8. 요약: 기계 경제는 단순한 고속 결제 인프라 이상을 필요로 한다
에이전트 결제는 과대평가되기 쉽고, 동시에 과소평가되기 쉬운 단계에 있다. 과대평가되는 이유는 안정화폐 결제를 기술적으로 완료한다고 해서 에이전트가 성숙한 상업적 자율성을 갖는 것은 아니기 때문이다. 과소평가되는 이유는 소프트웨어가 명확한 제약 하에 외부 기능을 구매할 수 있게 되면, 기계 경제의 조직 방식·가격 모델·경쟁 경계가 모두 바뀔 것이기 때문이다.
결제 프로토콜은 이미 기계가 견적을 수신하고 정산을 완료할 수 있음을 입증했다. 다음 핵심 단계는 고립된 결제를 완전한 조달 절차로 확장하는 것이다: 에이전트가 적합한 서비스를 찾고, 진정한 비용을 이해하며, 예산 내에서 다양한 결제 인프라를 통해 결제하고, 전달을 확인하며, 모든 거래를 감사 가능하고 학습 가능한 기록으로 만드는 것.
미래 기계 경제는 단일 체인·단일 프로토콜·단일 월렛만 존재하지 않을 것이다. 다중 공급원은 장기적으로 유지될 것이며, 진정으로 가치 있는 인프라는 구매자가 이 복잡성을 효과적으로 탐색할 수 있도록 지원해야 한다. 에이전트 결제는 결제 인프라·공급망·기본 결제·신뢰 메커니즘을 통합해 기술적 역량을 실제 수요로 전환해야 한다.
소프트웨어가 구매자로서 행동하기 시작할 때, 결제는 단지 첫걸음일 뿐이다. 더 중요한 질문은 항상 다음과 같다: 소프트웨어가 통제 가능하고 투명하며 검증 가능한 방식으로 실제로 유용한 거래를 완료할 수 있는가?
참고문헌
[1] Circle, 「오픈 에이전트 경제 구축」, 2026. https://www.circle.com/blog/building-the-open-agentic-economy
[2] SELAT, 「에이전트 결제의 거래상대방 리스크: 측정되지 않은 반절」, 2026. https://selat.ai/insights/counterparty-risk-agentic-payments
[3] Google Cloud, 「신규 에이전트 결제 프로토콜(AP2)으로 AI 커머스 구동」, 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
[4] x402 재단, 「x402: 인터넷 기반 개방형 결제 표준」. https://github.com/x402-foundation/x402
[5] 머신 페이먼츠 프로토콜, 「HTTP 402 기반 머신 결제 프로토콜(MPP)」. https://mpp.dev/
[6] Xiong 외, 「무신뢰 에이전트를 신뢰할 수 있는가? ERC-8004 기반 탈중앙화 AI 에이전트 생태계 실증 연구」, arXiv, 2026. https://arxiv.org/abs/2606.26028
[7] SELAT 공식 웹사이트: https://www.selat.ai
본 기사는 기고된 글로, 블록비츠(BlockBeats)의 공식 입장이 아닙니다.
