자동화된 Kamino 대출: Solana 수익을 최적화하는 AI 에이전트 구축하기

자동화된 Kamino 대출은 현재의 툴체인(toolchain)이 얼마나 파편화되어 있는지를 보여주는 전형적인 DeFi 워크플로우입니다. 비즈니스 로직을 단 한 줄도 작성하기 전에 Kamino의 SDK, Solana 지갑 라이브러리, 모니터링 루프(monitoring loop), 그리고 정책 및 승인을 처리할 무언가가 필요합니다. 만약 수익 최적화 에이전트(yield-optimization agent)를 구축하고 있다면, 전략 코드가 단 한 번 실행되기도 전에 프로토콜 SDK들을 연결하는 데 3주를 소비하고 싶지는 않을 것입니다.

프로토콜 파편화가 진짜 문제인 이유

DeFi 공간은 빠르게 성숙했습니다. Solana의 Kamino, EVM의 Aave, 스테이킹을 위한 Lido와 Jito, 스왑을 위한 Jupiter와 0x, 퍼프(perps)를 위한 Hyperliquid와 Drift 등 프로토콜 자체는 훌륭합니다. 문제는 통합 계층(integration layer)입니다. 각 프로토콜은 자신만의 SDK, 자체 인증 모델(auth model), 자체 에러 표면(error surface)을 가지고 있습니다. Kamino, Jupiter 스왑, Jito 스테이킹 사이에서 자본을 이동시키는 수익 최적화 에이전트는 세 개의 별도 통합 표면을 건드리며, 프로토콜이 업그레이드될 때마다 각각을 유지 관리해야 합니다.

더 깊은 문제는 프로그래밍 방식의 DeFi 접근에는 단순히 프로토콜 호출 이상의 것이 필요하다는 점입니다. 실제 에이전트에는 가드레일(guardrails)이 필요합니다: 지출 한도, 토큰 화이트리스트(token whitelists), 대규모 포지션을 위한 승인 워크플로우, 그리고 청산(liquidated)을 방지하기 위한 건강 지수(health factor) 모니터링 등이 그것입니다. 13개의 서로 다른 SDK 위에서 이 모든 것을 직접 구축하는 것은 진정으로 수개월이 걸리는 프로젝트입니다.

WAIaaS (AI 에이전트를 위한 Wallet-as-a-Service)는 이를 인프라로 취급합니다. Kamino, Jupiter, Jito, Aave v3, Lido, Drift, Hyperliquid 및 크로스체인 브리지(cross-chain bridges)를 포함한 15개의 DeFi 프로토콜 제공업체를 아우르는 단일 REST API를 제공하며, 정책 엔진(policy engine), 세션 기반 인증(session-based auth), 트랜잭션 파이프라인(transaction pipeline)이 이미 구축되어 있습니다. 당신의 에이전트는 하나의 API만 호출하면 됩니다. 나머지는 인프라가 처리합니다.

실제로 포함된 내용

WAIaaS는 로컬 또는 사용자의 인프라에서 실행되는 셀프 호스팅 데몬 (self-hosted daemon)입니다. 이는 15개의 패키지로 구성된 모노레포 (monorepo)로, 39개의 라우트 모듈 (route modules)과 Claude Desktop과의 직접적인 통합을 위한 45개의 MCP 도구 (MCP tools)를 갖춘 REST API를 제공합니다. DeFi 액션 레이어 (action layer)는 다음 15개의 프로토콜 제공업체를 지원합니다:

• Solana: jupiter-swap, kamino, jito-staking, xrpl-dex, drift
• EVM: aave-v3, lido-staking, pendle, zerox-swap, hyperliquid
• Cross-chain: lifi, across, dcent-swap
• Prediction markets: polymarket
• Agent reputation: erc8004

모든 트랜잭션은 검증(validate) → 인증(auth) → 정책(policy) → 대기(wait) → 실행(execute) → 확인(confirm)의 7단계 파이프라인을 거칩니다. 정책 엔진 (policy engine)은 21가지 정책 유형과 4가지 보안 티어 (security tiers: INSTANT, NOTIFY, DELAY, APPROVAL)를 보유하며, 기본 거부 (default-deny) 원칙을 강제합니다. 이는 대출 에이전트 (lending agent)에게 특히 중요합니다. 에이전트가 자본을 자율적으로 재배치하기 시작하기 전에 LTV 비율, 자산 화이트리스트 (asset whitelists), 지출 한도 (spending caps)에 대한 엄격한 제한을 설정해야 하기 때문입니다.

지원 네트워크: 18개 네트워크에 걸친 2가지 체인 유형 (Solana 및 EVM).

데몬 설정하기 (Setting Up the Daemon)

Docker로 시작하세요. 데몬을 실행하는 가장 빠른 방법입니다:

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

기본 포트 바인딩은 127.0.0.1:3100:3100입니다. 이미지는 ghcr.io/minhoyoo-iotrust/waiaas:latest입니다. 자동 프로비저닝 (auto-provisioning, 첫 실행 시 마스터 비밀번호 자동 생성)을 원하는 경우:

docker run -d \
  --name waiaas \
  -p 127.0.0.1:3100:3100 \
...

운영 환경 (production)에서는 secrets 오버레이 (secrets overlay)를 사용하세요:

mkdir -p secrets
echo "your-secure-password" > secrets/master_password.txt
chmod 600 secrets/master_password.txt
...

또는 CLI 경로를 선호하는 경우:

npm install -g @waiaas/cli
waiaas init
waiaas start
...

quickset은 지갑과 MCP 세션을 한 번에 생성합니다.

인증: 세 가지 역할, 명확한 분리 (Authentication: Three Roles, Clear Separation)

WAIaaS에는 세 가지 인증 레이어 (auth layers)가 있으며, 코드를 작성하기 전에 에이전트가 어떤 레이어를 사용하는지 이해하는 것이 중요합니다.

# masterAuth — 시스템 관리자 (지갑 생성, 세션 관리, 정책 설정)
-H "X-Master-Password: my-secret-password"

...

여러분의 Kamino 대출 에이전트는 모든 런타임 (runtime) 작업에 sessionAuth를 사용하게 됩니다. masterAuth는 지갑 생성, 세션 생성, 정책 설정과 같은 초기 설정 (setup)을 위한 것입니다. ownerAuth는 APPROVAL 단계의 트랜잭션에 승인이 필요할 때 개입하는 인간 (human in the loop)을 위한 것입니다.

에이전트를 배포하기 전에 지갑과 세션을 생성하세요:

# Solana 메인넷 지갑 생성
curl -X POST http://127.0.0.1:3100/v1/wallets \
  -H "Content-Type: application/json" \
...

세션 토큰 (wai_sess_...)은 에이전트가 런타임 (runtime) 중에 사용하는 것입니다.

자본 투입 전 정책 설정

이 부분은 대부분의 수익 봇 (yield-bot) 튜토리얼에서 생략되는 내용입니다. 에이전트가 자본 (capital)에 손을 대기 전에 반드시 정책 (policies)이 마련되어 있어야 합니다. 정책 엔진 (policy engine)의 기본 거부 (default-deny) 동작은 특정 토큰을 화이트리스트 (whitelist)에 등록하지 않으면 트랜잭션이 차단됨을 의미하며, 이는 자율 에이전트 (autonomous agent)에게 정확히 필요한 기능입니다.

Kamino 대출 에이전트를 위해 최소한 다음 사항들이 필요합니다:

지출 한도 (Spending limit) — 트랜잭션 금액에 따른 4단계 보안:

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

단계 할당은 자동으로 이루어집니다: amount <= instant_max → INSTANT (즉시 실행), <= notify_max → NOTIFY (실행 + 알림), <= delay_max → DELAY (900초 동안 대기열에 추가, 취소 가능), > delay_max → APPROVAL (WalletConnect, Telegram 또는 푸시 알림을 통한 인간의 승인 필요).

토큰 화이트리스트 (Token whitelist) — 전략에서 사용하는 자산만 허용:

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

LTV 한도 (LTV limit) — 대출 포지션에 대한 담보 인정 비율 (loan-to-value)의 상한선:

LENDING_LTV_LIMIT 정책 유형은 최대 LTV 비율을 강제하며, 포지션을 임계값 이상으로 밀어붙이는 모든 대출 동작을 차단합니다. LENDING_ASSET_WHITELIST와 결합하면 에이전트가 담보로 사용할 수 있는 자산을 정확하게 제한할 수 있습니다.

컨트랙트 화이트리스트 (Contract whitelist) — 에이전트가 호출할 수 있는 프로토콜 컨트랙트를 제한합니다:

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

총 21가지의 정책 유형이 있으며, 속도 제한 (rate limits)부터 무기한 선물 (perpetuals) 최대 레버리지, ERC-8128 HTTP 서명 도메인 (HTTP signing domains)에 이르기까지 모든 것을 다룹니다. 대출 에이전트의 경우 LENDING_LTV_LIMIT, LENDING_ASSET_WHITELIST, SPENDING_LIMIT, ALLOWED_TOKENS, 그리고 CONTRACT_WHITELIST가 핵심적인 5가지입니다.

에이전트: 스왑 (Swapping), 대출 (Lending), 모니터링 (Monitoring)

정책이 설정되면 에이전트의 런타임 로직은 간단한 API 호출이 됩니다. 다음은 Jupiter에서 SOL을 USDC로 스왑한 다음, Kamino 대출 시장에 공급하는 Kamino 수익 에이전트의 패턴입니다.

먼저 잔액 확인:

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

const client = new WAIaaSClient({
...

실행 전 시뮬레이션 — 전략 리밸런싱 시에는 항상 먼저 드라이 런 (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>" \
...

드라이 런 API는 정책 검사를 포함한 전체 파이프라인을 통해 트랜잭션을 실행하지 않고 시뮬레이션합니다. 만약 시뮬레이션에서 POLICY_DENIED 에러가 반환되면, 가스(gas)를 소비하기 전에 이를 포착할 수 있습니다.

Jupiter 스왑 실행:

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>" \
...

확인을 위한 폴링 (Poll):

const POLL_TIMEOUT_MS = 60_000;
const startTime = Date.now();

...

DeFi 포지션 모니터링 (Monitor DeFi positions) — get-defi-positions 도구(REST 및 MCP를 통해 모두 사용 가능)는 여러 프로토콜에 걸친 귀하의 대출/스테이킹 (lending/staking) 포지션을 반환합니다. 건강 지수 (health factor) 모니터링을 위해, get-health-factor MCP 도구는 현재의 건강 지수를 직접 노출하므로, 에이전트가 청산 (liquidation)이 발생하기 전에 레버리지 축소 (deleveraging) 작업을 트리거할 수 있습니다.

정책 오류를 명시적으로 처리하기 (Handle policy errors explicitly):

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

try {
...

도메인이 POLICY이고 retryable: false인 POLICY_DENIED는 엄격한 규칙에 저촉되었음을 의미합니다 — 이를 로그에 기록하고 운영자에게 알리되, 재시도하지 마세요. DELAY 티어 트랜잭션은 오류가 아닙니다; 이는 대기열에 추가되며, 소유자가 WalletConnect 또는 Telegram을 통해 취소하지 않는 한 설정된 지연 시간 후에 실행됩니다.

MCP 통합: 수익 전략가로서의 Claude

한 단계 더 나아가 Claude Desktop이 전략 계층 (strategy layer) 역할을 수행하도록 하고 싶다면 — 즉, 포지션을 분석하고, 리밸런싱 (rebalance) 시점을 결정하며, 움직임을 실행하도록 하려면 — MCP 통합을 통해 동일한 인프라에 직접 연결할 수 있습니다.

{
  "mcpServers": {
    "waiaas-kamino": {
...

또는 CLI 단축 명령어를 사용하세요:

waiaas mcp setup --all

45개의 MCP 도구가 등록되어 있어, Claude는 단일 대화 내에서 get_defi_positions, get_health_factor, execute_action (Kamino 공급/대출 작업을 위한), 그리고 get_balance를 호출할 수 있습니다. 동일한 정책 엔진이 적용됩니다 — Claude의 도구 호출은 직접적인 REST 호출과 동일한 파이프라인을 통과합니다.

가스 조건부 실행 (Gas Conditional Execution)

수익 전략을 위해 알아두어야 할 세부 사항: WAIaaS에는 가스 조건부 실행 (gas conditional execution) 기능이 있습니다 — 트랜잭션은 가스 가격이 설정된 임계값(threshold)을 충족할 때만 실행됩니다. 빈번한 리밸런싱을 수행하는 전략의 경우, 이는 에이전트가 가스 가격 급등기에 실행되어 수익을 갉아먹는 것을 방지합니다.

빠른 시작 요약 (Quick Start Summary)

1. docker compose up -d — 데몬(daemon) 시작 (이미지: ghcr.io/minhoyoo-iotrust/waiaas:latest, 포트 127.0.0.1:3100:3100)
2. masterAuth를 사용하여 POST /v1/wallets를 통해 Solana 메인넷(mainnet) 지갑 생성
3. POST /v1/sessions를 통해 세션 생성 — wai_sess_... 토큰 저장
4. 정책(policies) 설정: SPENDING_LIMIT, ALLOWED_TOKENS, LENDING_LTV_LIMIT, CONTRACT_WHITELIST
5. TypeScript SDK 설치 (npm install @waiaas/sdk) 및 Kamino, Jupiter, Jito를 위한 executeAction 호출 시작

OpenAPI 명세(spec)는 /doc에서 자동으로 생성되며, 대화형 Scalar API 레퍼런스(reference) UI는 /reference에서 확인할 수 있습니다. 두 기능 모두 데몬이 시작된 직후 바로 사용할 수 있습니다.

다음 단계 (What's Next)

Kamino 대출(lending)에 작동하는 것과 동일한 세션 토큰 및 정책 설정이 Aave v3, Lido 스테이킹(staking), Hyperliquid 퍼프(perps), 그리고 LI.FI 및 Across를 통한 크로스체인 브릿징(cross-chain bridging)에도 동일하게 적용됩니다 — 총 15개의 프로토콜 제공업체,