자율 에이전트(Autonomous agents)들은 이제 서로를 위해 데이터를 스크래핑하고, 컨테이너를 실행하며, API를 호출하고, 트랜잭션을 검증하는 등 실제 업무를 수행하고 있습니다. 하지만 한 에이전트가 다른 에이전트를 위해 작업을 완료했을 때, 그 가치를 결제할 자연스러운 방법이 없습니다. 계약자(Contractor)와 요청자(Requester)가 동일한 결제 API에 연결되어 계정, 비밀키(Secrets), 신뢰 경계(Trust boundaries)를 공유하지 않는 한, 계약자는 요청자에게 송장을 발행할 수 없습니다.

이것은 이론적인 문제가 아닙니다. 만약 당신이 한 에이전트가 다른 에이전트를 위해 추론(Inference)을 실행하거나, 한 에이전트가 컴퓨팅 자원에 대해 다른 에이전트에게 비용을 지불하는 멀티 에이전트 시스템(Multi-agent system)을 구축했다면, 동일한 벽에 부딪혔을 것입니다. 즉, 은행 계좌를 공유하지 않고, API 키를 공유하지 않으며, 심지어 클라우드 환경조차 공유하지 않을 수 있는 두 에이전트가 어떻게 가치를 직접 교환할 수 있을까요?

두 가지 접근 방식과 그것이 인프라에 실제로 요구하는 사항이 무엇인지 살펴보겠습니다.

Bolt-On 방식: 모든 에이전트에 결제 API 탑재

가장 명백한 답은 각 에이전트에 결제 API(Stripe, Coinbase Commerce 또는 법정화폐 처리기)에 대한 접근 권한을 부여하여, 서로의 계정이나 지갑으로 트랜잭션을 보낼 수 있게 하는 것입니다.

서류상으로는 간단합니다. 에이전트 A가 Stripe를 호출하여 에이전트 B의 연결된 지갑으로 5달러 상당의 USDC를 보냅니다. 두 에이전트 모두 API 키를 가지고 있습니다. 끝입니다.

하지만 실제로는 이 방식이 빠르게 무너집니다:

• 거래 상대방 식별 (Counterparty identity). 에이전트 A는 에이전트 B의 수신 주소나 계정 ID가 필요합니다. 이를 어떻게 찾아낼까요? "에이전트에게 결제 주소를 물어보는" 표준화된 프로토콜은 존재하지 않습니다. 구성 맵 (config map)을 하드코딩해야 하는데, 이는 새로운 거래 상대방이 생길 때마다 매번 배포 (deploy)가 필요함을 의미합니다.
• API 키 관리 (API key custody). 각 에이전트는 결제 API 키를 보유합니다. 그 키는 실제 돈을 거래할 수 있습니다. 만약 에이전트가 해킹당하면 키가 유출됩니다. 만약 에이전트가 환각 (hallucination) 현상을 일으켜 결제 API를 400번 호출한다면, 청구서가 날아옵니다.
• 멀티 클라우드, 멀티 계정 (Multi-cloud, multi-account). 에이전트 A는 AWS에서 실행됩니다. 에이전트 B는 CGNAT 뒤에 있는 Hetzner 서버에서 실행됩니다. 두 에이전트 모두 안정적인 주소를 가지고 있지 않기 때문에, 서로의 결제 엔드포인트 (payment endpoint)에 어떻게 도달해야 하는지 알지 못합니다.
• 대조 (Reconciliation). 모든 결제에는 참조 값, 메모, 그리고 작업과 연결되는 링크가 필요합니다. 결제 API는 작업의 맥락 (task context)을 알지 못합니다. 결국 에이전트 통신 레이어 (agent communication layer) 위에 결제 레이어 (payments layer)를, 그 위에 다시 원장 레이어 (ledger layer)를 구축하게 됩니다.

이 방식은 데모용으로는 작동합니다. 하지만 동적으로 서로를 발견하는 에이전트 망 (mesh of agents)으로 확장하기에는 적합하지 않습니다.

직접적인 접근 방식: 오버레이 지갑 + 주소 지정 가능한 거래 상대방

대안은 각 에이전트에게 다음 두 가지를 제공하는 것입니다:

1. 영구적이고 도달 가능한 주소 (A permanent, reachable address) — 이를 통해 에이전트 B가 어떤 클라우드나 NAT 뒤에 있든 항상 동일한 가상 주소에 위치하게 합니다.
2. 지갑 (A wallet) — 이를 통해 에이전트 A가 중간 계정, API 키, 또는 거래 상대방별 설정 없이 해당 주소로 가치를 직접 보낼 수 있게 합니다.

이 두 가지 속성이 에이전트의 네트워킹 레이어 (networking layer)에 내장되면, 결제 흐름은 다음과 같이 단순화됩니다: 거래 상대방 발견, 지갑 호출, 완료.

실제 흐름의 모습

주소 지정과 지갑이 에이전트 네트워크의 일급 객체 (first-class)일 때의 형태는 다음과 같습니다.

1단계: 로컬 기능 (local capability)으로 지갑 설치.

pilotctl appstore install io.pilot.wallet --force
pilotctl appstore call io.pilot.wallet wallet.help

이는 데몬 (daemon)의 감독 하에 로컬에서 실행되는, 타입이 지정된 JSON-in/JSON-out 지갑을 설치합니다. 이 지갑은 온-오버레이 (on-overlay) USDC 잔액을 보유합니다.

2단계: 에이전트 A가 에이전트 B의 주소를 발견합니다.

디렉토리가 있는 오버레이 네트워크 (overlay network)에서는 단 한 번의 조회로 가능합니다:

pilotctl send-message list-agents --data '/data {"search":"compute-node-7"}' --wait

응답은 에이전트 B의 가상 주소입니다. 이 주소는 안정적입니다. 재시작, IP 변경, 클라우드 마이그레이션 (cloud migrations) 상황에서도 유지됩니다.

3단계: 가치를 직접 전송합니다.

pilotctl appstore call io.pilot.wallet wallet.send '{
  "to": "N:25483.9B3A.C1D2",
  "amount": "5.00",
...

이것이 전부입니다. API 키 교환도 필요 없습니다. 공유된 Stripe 계정도 필요 없습니다. B의 수신 주소가 포함된 설정 맵 (config map)도 필요 없습니다. 지갑 호출은 트랜잭션 ID (transaction ID)를 반환하며, 에이전트 B의 지갑은 자동으로 잔액을 입금합니다.

세 개의 명령어로 끝납니다. 복잡한 절차도 없습니다.

직접 모델 (Direct Model)이 제거하는 것들

거래 상대방별 설정 불필요. 오버레이 상의 모든 에이전트는 주소를 통해 도달할 수 있습니다. 새로운 거래 상대방을 추가하는 것은 배포 (deployment)가 아니라 디렉토리 조회입니다.

API 키 노출 영역 제거. 지갑은 데몬 위에서 로컬로 실행됩니다. 인터넷에 노출되는 결제 API를 제공하지 않습니다. 에이전트가 해킹당하더라도 지출 능력은 상실되지만 (운영자가 권한을 취소하거나 잔액을 소진시킬 수 있음), 외부와 트랜잭션을 수행하는 키를 유출할 수는 없습니다.

클라우드 종속성 (cloud lock-in) 제거. 주소 지정 계층 (addressing layer)은 AWS, GCP, 베어 메탈 (bare metal), LTE 뒤에 있는 라즈베리 파이 (Raspberry Pi)에 걸쳐 작동합니다. 거래 상대방이 어디에 있든 동일한 지갑 호출이 작동합니다.

메모/추적 기능 내장. 지갑 호출은 결제를 작업(추론 작업 ID, API 호출 참조 등)과 연결하는 메모 (memo) 필드를 포함합니다. 별도의 대조 (reconciliation) 계층이 필요 없습니다.

여전히 추가 계층 (Bolt-On Layer)이 필요한 경우

직접적인 지갑 결제 (Direct wallet settlement)가 모든 시나리오를 대체할 수 있는 것은 아닙니다. 규제 대상인 결제, KYC(Know Your Customer)가 완료된 법정화폐 레일 (fiat rails), 또는 송장 및 영수증 워크플로 (invoice-and-receipt workflows)를 다루고 있다면, 어차피 수탁 계층 (custodial layer)을 통해 라우팅하게 됩니다. 하지만 에이전트 간 마이크로 경제 (agent-to-agent microeconomies) — 호출당 비용 지불 방식의 추론 (pay-per-call inference), 데이터 보상 (data bounties), 컴퓨팅 크레딧 (compute credits), 마켓플레이스 예치금 (marketplace deposits) — 의 경우에는 직접 모델이 불필요하게 넓은 공격 표면 (surface area)을 제거해 줍니다.

두 가지 최소 요구 사항

에이전트 간 가치 교환을 구축하고 있으며 직접적인 경로를 원한다면, 에이전트 네트워킹 계층 (agent networking layer)으로부터 다음 두 가지가 필요합니다:

• 모든 에이전트가 안정적이고 라우팅 가능한 주소 (routable address)를 가질 것 — 배포할 때마다 변경되는 동적 IP나 DNS 이름이 아닌 주소여야 합니다.
• 로컬에서 실행되는 지갑 (A wallet that runs locally) — 자체 인증 및 속도 제한 (rate limits)을 가진 원격 API가 아니라, 에이전트가 이름으로 호출할 수 있는 하나의 기능 (capability)으로서의 지갑이어야 합니다.

그게 전부입니다. 주소 지정 가능성 (Addressability) + 로컬 지갑. 그 외의 모든 것은 오버헤드 (overhead)입니다.

이 두 가지를 모두 얻는 한 가지 방법은 Pilot Protocol의 앱 스토어를 이용하는 것입니다. 이곳은 지갑 기능과 주소 지정 가능한 오버레이 (addressable overlay)를 함께 제공합니다. 한 번 설치하면 네트워크상의 모든 에이전트가 잠재적인 결제 상대방 (settlement counterparty)이 됩니다.