지갑 인프라 계층: AI 에이전트가 전통 금융을 사용할 수 없는 이유

AI 에이전트는 컴퓨팅(compute), 데이터, API 호출에 대한 비용을 지불해야 합니다. 하지만 이를 자율적으로 수행할 수 있게 해주는 인프라는 전통 금융(traditional finance)에는 존재하지 않습니다. 은행은 인간을 필요로 합니다. 수탁 계좌(Custodied accounts)는 인간의 승인 루프(approval loops)를 필요로 합니다. 신용카드는 반대편에 사람이 있어야 합니다. AI 에이전트에게 독립적으로 돈을 관리하도록 요청하는 순간, 기존 금융 시스템이 넘을 수 있도록 설계되지 않은 벽에 부딪히게 됩니다.

진짜 문제

AI 에이전트가 경제에 참여하기 위해 실제로 무엇이 필요한지 생각해 보십시오. 에이전트는 자금을 보유해야 합니다. 인간이 "승인"을 클릭할 때까지 기다리지 않고 결제를 보내야 합니다. DeFi 프로토콜과 상호작용하고, API 제공업체에 비용을 지불하며, 운영자가 설정한 한도 내에서 머무는 동시에 여러 체인(chains)을 관리해야 합니다.

전통 금융 인프라는 핵심적인 가정, 즉 "인간이 항상 루프 안에 있다(human is always in the loop)"를 중심으로 구축되었습니다. 모든 거래는 검토됩니다. 모든 계좌는 법적 신원과 연결됩니다. 모든 권한 부여는 책임을 물을 수 있는 사람의 서명을 필요로 합니다. 이는 인간 사용자를 위한 합리적인 설계입니다. 하지만 자율 에이전트(autonomous agents)에게는 완전히 맞지 않는 설계입니다.

이 문제는 실질적입니다. AI 에이전트가 포트폴리오 관리, 거래 실행, API 액세스 비용 지불, 자금 분배와 같이 경제적으로 의미 있는 작업을 수행하도록 요구받는 일이 점점 늘어남에 따라, 그들이 실행되는 인프라 계층은 그들이 실제로 얼마나 많은 자율성을 가질 수 있는지를 결정합니다. 만약 인간 운영자가 관리하는 수탁 지갑(custodied wallet)을 준다면, 당신은 방금 병목 현상을 만든 것입니다. 모든 거래는 지원 티켓(support ticket)이 됩니다. 모든 예외 상황(edge case)은 에이전트를 멈춰 세웁니다.

에이전트에게 필요한 것은 처음부터 자율 운영을 위해 설계된 지갑 인프라입니다. 즉, 프로그래밍 가능한 지출 제어(programmable spending controls), 다중 보안 계층(multiple security tiers), 그리고 일상적인 운영의 핵심 경로(critical path)에서 인간 없이 트랜잭션을 실행할 수 있는 능력입니다.

"자율 지갑 인프라"가 실제로 의미하는 것

WAIaaS (Wallet-as-a-Service for AI agents)는 이 문제를 해결하기 위해 특별히 구축된 오픈 소스(open-source) 기반의 셀프 호스팅(self-hosted) 시스템입니다. 이는 현재 존재하며, Docker를 사용하여 5분 이내에 실행할 수 있습니다. 이 아키텍처는 지갑을 누가(또는 무엇이) 보유하고 있는지에 대한 진정으로 다른 일련의 가설을 반영하고 있기 때문에 이해할 가치가 있습니다.

핵심적인 분리는 다음과 같습니다: 자금의 **소유자 (owner)**는 인간입니다. 지갑의 **운영자 (operator)**는 AI 에이전트입니다. WAIaaS는 세 가지 인증 계층을 통해 이러한 역할을 명확하게 구분합니다.

masterAuth (Argon2id)는 시스템 관리자입니다. 즉, 지갑을 생성하고, 정책을 구성하며, 세션을 관리하는 인간입니다. ownerAuth (SIWS/SIWE)는 자금 소유자입니다. 고액 트랜잭션을 승인하거나 문제가 발생했을 때 킬 스위치(kill switch)를 작동시킬 수 있는 인간입니다. sessionAuth (JWT HS256)는 AI 에이전트가 사용하는 것으로, 에이전트에게 사전 승인된 한도 내에서 트랜잭션을 실행할 수 있는 권한을 부여하는 범위가 지정된 토큰(scoped token)입니다.

이러한 3계층 설계는 에이전트가 일상적인 운영을 위해 독립적으로 실행될 수 있는 동시에, 인간은 정의된 임계값을 넘어서는 모든 것에 대해 강력한 통제권을 유지함을 의미합니다.

정책 엔진 (Policy Engine): 규칙이 인간을 대체하는 곳

WAIaaS에서 자율 운영이 안전한 이유는 정책 엔진(policy engine) 덕분입니다. 이 엔진은 21가지 정책 유형과 4가지 보안 티어(security tiers)를 가지고 있습니다. 트랜잭션이 실행되기 전에 검증(validation), 인증(authentication), 정책 평가(policy evaluation), 확인(confirmation)을 포함하는 7단계 파이프라인을 거칩니다.

4가지 티어는 다음과 같습니다:

• INSTANT — 즉시 실행, 알림 없음
• NOTIFY — 즉시 실행, 소유자에게 알림 전송
• DELAY — 설정된 초 단위 시간 동안 대기열에 머문 후 실행 (취소 가능)
• APPROVAL — WalletConnect, Telegram 또는 푸시 알림을 통한 명시적인 인간의 승인 필요

SPENDING_LIMIT 정책은 트랜잭션 규모를 이러한 티어에 자동으로 연결합니다:

curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
  -H "X-Master-Password: my-secret-password" \
...

이 설정을 통해, 12달러짜리 API 인보이스(invoice)를 결제하는 에이전트는 즉시 실행됩니다. 300달러 송금은 알림을 보내지만 여전히 처리됩니다. 1,500달러 거래는 15분 동안 대기열(queue)에 머물며, 무언가 잘못된 것처럼 보일 경우 소유자가 취소할 수 있는 시간을 제공합니다. 2,000달러를 초과하는 모든 금액은 명시적인 인간의 승인을 필요로 합니다. 에이전트는 멈추는 것이 아니라, 스테이크(stakes, 이해관계/위험도)에 따라 적절하게 단계(escalate)를 높이는 것입니다.

지출 한도를 넘어, 에이전트가 이동할 수 있는 토큰(ALLOWED_TOKENS), 호출할 수 있는 컨트랙트(CONTRACT_WHITELIST), 운영할 수 있는 네트워크(ALLOWED_NETWORKS), 그리고 심지어 사용할 수 있는 거래소(VENUE_WHITELIST)까지 잠글 수 있습니다. 정책 시스템은 이러한 차원들에 대해 기본 거부(default-deny)를 강제합니다. 예를 들어, ALLOWED_TOKENS가 설정되어 있고 특정 토큰이 목록에 없다면, 해당 트랜잭션은 즉시 차단됩니다.

특히 DeFi(탈중앙화 금융) 운영을 위해, 무기한 선물(perpetual futures)에 대한 최대 레버리지(PERP_MAX_LEVERAGE), 대출 프로토콜에 대한 담보 인정 비율 한도(LENDING_LTV_LIMIT), 그리고 포지션 규모 상한(PERP_MAX_POSITION_USD)에 대한 정책이 존재합니다. 트레이딩 전략을 실행하는 에이전트는 버그를 통해서든, 오해를 통해서든 운영자가 설정한 리스크 파라미터(risk parameters)를 진정으로 초과할 수 없습니다.

x402: 사용한 만큼 지불하는 기계들

WAIaaS의 가장 미래 지향적인 요소 중 하나는 x402 HTTP 결제 프로토콜에 대한 지원입니다. 아이디어는 간단합니다. AI 에이전트가 유료 API에 HTTP 요청을 보낼 때, 서버가 402 Payment Required 응답을 반환합니다. 그러면 에이전트는 자동으로 결제를 처리하고 요청을 재시도합니다. 인간의 승인도, 신용카드도, 인보이스 주기도 필요 없습니다.

WAIaaS는 REST API와 TypeScript SDK 모두를 통해 이를 노출합니다:

import { WAIaaSClient } from '@waiaas/sdk';

const client = new WAIaaSClient({
...

에이전트는 일반적인 HTTP fetch 대신 x402Fetch를 호출합니다. 만약 서버가 접근에 대한 비용을 부과한다면, 결제는 백그라운드에서 이루어집니다. X402_ALLOWED_DOMAINS 정책 유형은 에이전트가 자동으로 결제할 수 있도록 허용된 엔드포인트(endpoint)를 제어합니다. 따라서 에이전트가 임의의 주소로 결제하도록 유도되는 것을 방지할 수 있습니다.

이것이 실제 자율적 경제 참여 (autonomous economic participation)의 모습입니다. 데이터가 필요한 에이전트는 데이터 비용을 지불합니다. 컴퓨팅 자원 (compute)이 필요한 에이전트는 컴퓨팅 비용을 지불합니다. 전체 사이클은 인간이 각 트랜잭션 (transaction)을 승인하지 않고도 발생하지만, 안전을 유지하는 정책 범위 (policy envelope) 내에서 이루어집니다.

에이전트 연결하기: MCP 경로

현재 Claude와 같은 역량 있는 AI 에이전트를 WAIaaS에 연결하는 가장 일반적인 방법은 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)을 통하는 것입니다. WAIaaS는 지갑 운영, 트랜잭션 (transactions), DeFi, NFT, 그리고 x402 결제를 아우르는 45개의 MCP 도구 (tools)를 제공합니다.

설정은 단 한 번의 CLI 명령어로 완료됩니다:

waiaas mcp setup --all    # Claude Desktop에 모든 지갑을 자동 등록

또는 claude_desktop_config.json에서 수동으로 구성할 수도 있습니다:

{
  "mcpServers": {
    "waiaas": {
...

그 후, Claude는 자연어를 통해 잔액 확인, 토큰 전송, 15개의 통합 프로토콜에 걸친 DeFi 포지션 조회, Hyperliquid에서의 거래, Jupiter에서의 스왑 (swap), 그리고 x402로 제한된 API 결제 등을 수행할 수 있습니다. 에이전트는 기저의 메커니즘을 알 필요가 없습니다. 그저 도구 (tools)를 호출할 뿐입니다.

만약 트레이딩 에이전트, 데이터 페칭 (data-fetching) 에이전트, 자금 관리 (treasury management) 에이전트와 같이 여러 특화된 에이전트를 운영한다면, 각 에이전트에게 서로 다른 정책 제약 조건이 적용된 별도의 세션 토큰을 가리키는 고유한 MCP 서버 항목을 부여할 수 있습니다. 한 에이전트는 다른 에이전트의 자금이나 정책 범위 (policy envelope)에 접근할 수 없습니다.

DeFi 계층: 15개 프로토콜, 하나의 인터페이스

단순히 자금을 이동하는 것 이상의 작업이 필요한 에이전트를 위해, WAIaaS는 15개의 DeFi 프로토콜 제공업체를 통합합니다: Aave v3, Across, D'CENT Swap, Drift, ERC-8004, Hyperliquid, Jito staking, Jupiter Swap, Kamino, Lido staking, LI.FI, Pendle, Polymarket, XRPL DEX, 그리고 0x Swap입니다.

Solana에서 Jupiter 스왑 (swap)을 실행하는 에이전트는 다음과 같은 모습입니다:

curl -X POST http://127.0.0.1:3100/v1/actions/jupiter-swap/swap \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>"
...

이것은 에이전트가 SOL을 USDC로 스왑하는 과정입니다. 트랜잭션은 검증(validated), 정책 확인(policy-checked), 실행(executed), 확정(confirmed)을 포함하는 전체 7단계 파이프라인을 통해 실행됩니다. 만약 에이전트의 정책이 이 토큰 쌍을 허용하지 않는다면, 의도하지 않은 동작을 묵인하며 수행하는 대신 POLICY_DENIED라는 명확한 에러와 함께 요청이 실패합니다:

{
  "error": {
    "code": "POLICY_DENIED",
...

금융 시장에서 작동하는 에이전트들은 또한 어떤 일이 일어나기 전에 그 일이 무엇인지 미리 알 필요가 있습니다. WAIaaS에는 트랜잭션을 실제로 실행하지 않고 시뮬레이션하는 드라이 런 (dry-run) 모드가 있습니다:

curl -X POST http://127.0.0.1:3100/v1/transactions/send \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer wai_sess_<token>"
...

에이전트는 트랜잭션을 확정하기 전에 해당 트랜잭션이 정책을 통과할지 확인하고, 가스비 (gas)를 추정하며, 결과를 검증할 수 있습니다. 빠른 속도로 작동하는 자율 시스템 (autonomous systems)에게 이는 의미 있는 안전 점검입니다.

5분 만에 실행하기

단순히 읽는 것에 그치지 않고 오늘 바로 작동하는 모습을 보고 싶다면, 과정은 짧습니다:

1단계: 데몬 (daemon) 시작

git clone https://github.com/minhoyoo-iotrust/WAIaaS.git
cd WAIaaS
docker compose up -d

2단계: 자동 프로비저닝 (auto-provision)으로 초기화

npm install -g @waiaas/cli
waiaas init --auto-provision
waiaas start

3단계: 지갑 및 세션 생성

waiaas quickset --mode mainnet

4단계: Claude Desktop에 연결

waiaas mcp setup --all

5단계: 정책 설정

실제 자금을 투입하기 전에 /admin에 있는 관리자 웹 UI (Admin Web UI) 또는 REST API를 사용하여 지출 한도, 토큰 화이트리스트 (token whitelists), 네트워크 제한 사항을 구성하세요.

Docker 이미지는 ghcr.io/minhoyoo-iotrust/waiaas:latest이며, 기본적으로 127.0.0.1:3100에 바인딩됩니다. 프로덕션 (production) 배포를 위해 docker-compose.secrets.yml을 통한 시크릿 오버레이 (secrets overlay)가 제공되며, 이를 통해 자격 증명 (credentials)을 환경 변수 (environment variables)가 아닌 Docker Secrets에 안전하게 보관할 수 있습니다.

인프라 문제는 이미 우리 곁에 와 있습니다

자율 에이전트 금융 (autonomous agent finance)을 미래의 문제, 즉 AI 시스템이 이를 필요로 할 만큼 충분히 유능해졌을 때 해결해야 할 문제로 치부하고 싶은 유혹이 생길 수 있습니다. 하지만 인프라 문제는 이미 우리 곁에 와 있습니다. AI 에이전트들은 오늘날 실제 돈이 개입되는 워크플로 (workflows)에 배치되고 있습니다. 문제는 에이전트에게 지갑 인프라 (wallet infrastructure)가 필요할 것인가가 아닙니다. 그 인프라가 자율 운영 (autonomous operation)을 위해 목적에 맞게 제작될 것인지, 아니면 개발자들이 인간을 위해 설계된 도구들을 사용하며 계속 임기응변식으로 대처할 것인지의 문제입니다.

"금융에 대해 이야기할 수 있는 에이전트"와 "정해진 제약 조건 내에서 자율적으로 자금을 관리할 수 있는 에이전트" 사이의 간극은 바로 목적에 맞게 제작된 지갑 인프라가 채워주는 간극과 정확히 일치합니다. 정책 엔진 (policy engine), 3계층 인증 모델 (three-tier authentication model), x402 지원, 그리고 15개의 DeFi 프로토콜 통합은 이러한 요구사항들이 이론적인 것이 아니라 실제적이기 때문에 존재합니다.

AI 에이전트가 돈을 다뤄야 하는 시스템을 구축하고 있다면 — 설령 그것이 아주 적은 금액이거나 단순한 API 결제를 위한 것이라 할지라도 — 인프라 계층 (infrastructure layer)이 실제로 어떤 모습이어야 하는지 이해할 가치가 있습니다.

다음 단계

가장 좋은 시작점은 GitHub 리포지토리 (repository)입니다. 이곳에서 전체 코드베이스 (codebase), Docker 설정 지침, 그리고 CLI 퀵스타트 (quickstart)를 확인할 수 있습니다: https://github.com/minhoyoo-iotrust/WAIaaS. WAIaaS가 지원하는 기능과 로드맵에 대한 더 넓은 개요를 보려면 공식 사이트인 https://waiaas.ai에서 최신 문서를 확인할 수 있습니다. 데몬 (daemon)을 실행한 후에는 /reference에서 대화형 API 레퍼런스 (API reference)를 사용할 수 있습니다. 이는 코드를 작성하기 전에 실제로 어떤 기능들을 사용할 수 있는지 이해하는 가장 빠른 방법입니다.