주 콘텐츠로 건너뛰기
학습용어집에이전트 간 결제
용어집

에이전트 간 결제란.

정의

에이전트 간 결제는 한 AI 에이전트가 다른 AI 에이전트에게 하는 결제로, 일반적으로 프로그래밍 방식으로, 보통 스테이블코인으로 이루어집니다. 지불자와 수취인 모두 자율적입니다(실시간으로 거래를 검토하는 인간이 없습니다). 에이전트-인간 결제(에이전트가 인간이 운영하는 비즈니스에 결제하는 경우) 및 인간-인간 결제(전통적인 체크아웃 흐름이 적용되는 경우)와 구별됩니다.

그것이 중요한 이유

에이전트 능력을 확장하는 형태입니다.

특화된 작업에 대해 다른 에이전트에게 지불할 수 있는 단일 에이전트는 모든 작업을 스스로 수행해야 하는 에이전트보다 훨씬 더 능력 있습니다. 오케스트레이터는 번역을 번역 에이전트에게, 검색을 검색 에이전트에게, 코드 검토를 코드 검토 에이전트에게, 이미지 생성을 일러스트레이션 에이전트에게 위임합니다. 각 위임자는 작고 집중적이며 가격이 적절하고 쉽게 교체할 수 있습니다. 오케스트레이터의 작업은 실행이 아닌 라우팅이 됩니다.

이것은 대부분의 연구소가 현재 구축하고 있는 에이전트-오브-에이전트 생태계를 가능하게 하는 구조적 패턴입니다. 결제 계층은 연결 조직입니다: 프로그래밍 방식의 에이전트 간 결제가 없으면, 오케스트레이터는 모든 기능을 내부적으로 묶어야 하거나(구축 비용이 많이 들고 진화가 느림) 사용자가 위임 선택을 노출해야 합니다(이는 추상화를 파괴합니다). 프로그래밍 방식의 결제로 오케스트레이터는 보이지 않게 라우팅하고, 위임자는 작업에 대해 보수를 받고, 원래 사용자는 단일 일관된 응답을 봅니다.

작동 방식

신원, 요청, 정산, 로그.

  1. 신원 조회. 지불하는 에이전트는 수취인의 결제 신원(공개 페이지, 지갑 주소, 현재 가격)을 조회합니다. 이는 종종 디렉토리 또는 수취인의 공개 API 설명을 통해 발생합니다.
  2. 결제 요청. 수취인의 API는 호스팅된 URL과 함께 402를 반환하거나 프로토콜에 따라 지갑으로의 직접 USDC 전송을 수락합니다. 지불하는 에이전트의 런타임은 결제를 시작하기 전에 요청을 지출 정책과 대조하여 확인합니다.
  3. 정산. USDC는 지불 에이전트의 지갑에서 수취인의 지갑으로 Base(또는 두 체인이 모두 지원하는 체인)에서 이동합니다. 정산은 일반적으로 5-10초 이내에 최종적입니다.
  4. 웹후크 + 로그. 두 에이전트의 플랫폼은 거래를 기록합니다. 수취인의 웹후크는 수령을 확인하고 작업 전달을 트리거합니다. 지불 에이전트의 감사 로그는 유출을 기록합니다.

이 모든 것은 인간의 참여를 요구하지 않습니다. 유일한 인간 설정 입력은 결제 에이전트의 지출 권한(주기별 허용량 및 거래당 한도)과 수취인의 가격 책정입니다 - 두 가지 모두 한 번 구성되면 이후로 자동으로 시행됩니다.

예제들

오늘 우리가 보는 세 가지 패턴.

예시 1

전문가 에이전트에게 지불하는 오케스트레이터 에이전트

연구 조정자 에이전트는 번역이 필요한 요청을 받습니다. 번역 에이전트의 공개 페이지에서 가격을 확인하고($0.50 per 500 words), 결제 요청을 생성하고, USDC를 보내고, 번역을 받고 최종 출력에 통합합니다. 사용자는 조정자에게 한 번만 지불했으며, 조정자는 자신의 위임자에게 지불을 처리합니다.

예시 2

유료 MCP 서버에 지불하는 에이전트

코딩 에이전트가 문서 검색 MCP 도구를 호출합니다. MCP 서버는 결제 URL과 함께 402를 반환합니다. 에이전트의 지갑(일일 한도 내에서)은 $0.02 USDC를 지불하며, 다음 호출이 성공합니다. MCP 서버 측에서는 이것이 다른 유료 호출과 동일하며, 지불자는 인간 감독이 아닌 다른 에이전트입니다.

예시 3

공유 예산이 있는 조정된 에이전트 집단

같은 프로젝트에서 작업하는 에이전트 팀은 작업 공간 수준의 예산을 공유합니다. 리드 에이전트는 집단 내의 전문 에이전트에게 하위 작업에 대해 지불합니다. 감사 로그는 두 지갑의 신원으로 에이전트 간의 모든 결제를 기록합니다. 이것이 카테고리가 성숙해짐에 따라 생산 에이전트 시스템이 작동하는 방식입니다.

자주 묻는 질문

세 가지 일반적인 질문.

지불하는 에이전트는 수취인 에이전트가 합법적임을 어떻게 알 수 있나요?

인간이 새로운 공급업체를 평가하는 것과 동일합니다: 공개 프로필 페이지, 인증 배지(이메일, GitHub, 도메인), 에이전트 페이지에 표시되는 최근 거래 내역 및 주변 시스템의 사회적 증거입니다. 고가치 에이전트 간 결제의 경우, 지불 에이전트의 정책은 수취인이 최소한 도메인 인증을 받아야 합니다. 저가치 프로그래밍 호출(각 API 호출 패턴)의 경우, 지출 한도가 최악의 경우를 제한하기 때문에 인증 기준을 낮출 수 있습니다.

결제하는 에이전트가 공격자에게 결제를 하도록 프롬프트가 주입되면 어떻게 되나요?

에이전트별 지출 권한은 API 레이어에서 한도를 시행하므로 최악의 경우는 거래당 한도와 기간당 허용량에 의해 제한됩니다 - 주입된 결제는 에이전트의 코드나 프롬프트가 무엇을 말하든 상관없이 어느 쪽도 초과할 수 없습니다. 이를 에이전트가 실제로 필요로 하는 것에 맞게 조정하십시오(엄격한 거래당 한도와 작은 일일 허용량) 그러면 프롬프트 주입의 폭발 반경이 작게 유지됩니다. 수신만 하는 에이전트의 경우, 둘 다 0으로 설정하면 USDC를 전송할 수 없습니다. 에이전트 간 흐름은 지출 봉투가 자연스럽게 좁기 때문에 가장 많은 이점을 얻습니다.

에이전트 간 결제가 원래 사용자에게 보이나요?

네. 작업 공간의 에이전트가 수행한 모든 결제는 감사 로그에 목적지 지갑, 금액, 이유 및 타임스탬프와 함께 기록됩니다. 사용자는 언제든지 에이전트의 외부 결제를 검토할 수 있습니다. 비즈니스 플랜에서는 감사 로그에 해시 체인 변조 증거가 포함되어 있어 사용자가 감사인에게 로그가 사후에 수정되지 않았음을 증명할 수 있습니다. 이러한 가시성 덕분에 에이전트 예산 모델이 작동합니다; 그렇지 않으면 에이전트가 사용자가 결코 재구성할 수 없는 방식으로 지출할 수 있습니다.
마지막 검토: 2026-05-15. CC BY 4.0에 따라 게시됨.

에이전트가 에이전트에게 결제하는 에이전트를 구축하세요.

에이전트별 지갑, 에이전트별 지출 정책, 에이전트별 감사 로그. 무료로 시작할 수 있습니다.