ERC-4337 계정 추상화 (Account Abstraction)를 활용한 가스비 없는 AI 트레이딩 봇 구축하기

가스비 없는 (Gasless) AI 트레이딩 봇이 마침내 실용화되었습니다. 하지만 개발 시간의 절반을 13개의 서로 다른 프로토콜 SDK를 연결하는 데 소비하지 않을 때만 가능한 이야기입니다. Jupiter, Aave, Lido, Drift, Hyperliquid, Across — 모든 DeFi 프로토콜은 저마다의 통합 방식, 인증 모델, 그리고 고유한 특성을 가지고 있습니다. 만약 당신이 트레이딩 봇이나 자동화된 수익 전략 (yield strategy)을 구축하고 있다면, 이러한 통합 비용 (integration tax)이 조용히 프로젝트의 실질적인 본체가 되어버립니다.

이러한 통합 비용이 DeFi 봇을 망치는 이유

2026년에 멀티 프로토콜 DeFi 봇을 구축하는 현실은 이렇습니다. 당신은 전략을 선택합니다. 예를 들어, Aave에서 빌리고, Across를 통해 Solana로 브릿징하며, Kamino에 유동성을 공급하는 식입니다. 그러다 보면 갑자기 각 단계마다 별도의 SDK를 유지 관리해야 하는 상황에 직면합니다. Aave가 컨트랙트 업그레이드를 진행하면 라이브러리 하나를 패치해야 합니다. Jupiter가 라우팅 API를 변경하면 또 다른 라이브러리를 패치해야 합니다. 어느샌가 코드베이스의 60%는 전략 로직이 아닌 프로토콜을 연결하기 위한 글루 코드 (glue code)가 되어버립니다.

위험 요소는 실재합니다. 의존성 문제로 인해 시장 변동 중에 오프라인 상태가 된 봇은 단순히 짜증 나는 문제가 아니라, 손익 (P&L) 사건으로 직결됩니다. 진지한 자동화 전략을 구축하는 개발자들에게는 프로토콜 수준의 복잡성을 처리해 주는 하나의 안정적인 인터페이스가 필요하며, 이를 통해 실제로 수익을 창출하는 로직에 집중할 수 있어야 합니다.

ERC-4337 계정 추상화 (Account Abstraction)는 이론적으로 가스비 없는 트랜잭션을 가능하게 합니다. 이를 실제 운영 환경에서 실용적으로 만드는 것은, 계정 추상화 (AA)를 정책 집행 (policy enforcement), 멀티 프로토콜 액세스, 그리고 처음부터 다시 구축할 필요가 없는 보안 제어 기능과 결합한 시스템을 갖추는 것입니다.

WAIaaS가 실제로 제공하는 것

WAIaaS는 AI 에이전트를 위한 오픈 소스 기반의 셀프 호스팅 Wallet-as-a-Service (WaaS)입니다. DeFi 개발자에게 유의미한 부분은 다음과 같습니다. ERC-4337 계정 추상화 (Account Abstraction), 7단계 트랜잭션 파이프라인, 그리고 21가지 정책 유형이 내장된 정책 엔진을 통해 15개의 통합된 DeFi 프로토콜 제공자를 단일 REST API로 노출합니다.

15개의 프로토콜은 다음과 같습니다: aave-v3, across, dcent-swap, drift, erc8004, hyperliquid, jito-staking, jupiter-swap, kamino, lido-staking, lifi, pendle, polymarket, xrpl-dex, 그리고 zerox-swap입니다.

이는 여러분이 실제로 관심을 가질 만한 주요 DeFi (탈중앙화 금융) 카테고리를 모두 포함합니다:

• Swaps (스왑): Jupiter (Solana), 0x, LI.FI, D'CENT
• Lending (대출): Aave v3, Kamino
• Liquid staking (유동성 스테이킹): Lido (EVM), Jito (Solana)
• Cross-chain bridging (크로스체인 브릿징): LI.FI, Across
• Perpetuals and spot (무기한 선물 및 현물): Hyperliquid, Drift
• Prediction markets (예측 시장): Polymarket
• Fixed yield (고정 수익): Pendle

18개의 네트워크에 걸친 두 가지 체인 유형 — EVM과 Solana — 를 단일 API 인터페이스로 제공합니다.

계정 추상화 (Account Abstraction) 측면에서, WAIaaS는 스마트 계정 (smart accounts), 가스비 없는 트랜잭션 (gasless transactions), 그리고 UserOp 빌드/서명 API를 통해 ERC-4337 지원을 제공합니다. 이는 여러분의 봇이 운영되는 모든 체인에서 가스비로 사용할 ETH를 보유하지 않고도 트랜잭션을 실행할 수 있음을 의미합니다. 스폰서(sponsor)가 이를 처리하기 때문입니다.

이해해야 할 3단계 인증 모델 (Three-Auth Model)

코드로 들어가기 전에, 인증 모델은 봇을 어떻게 설계할지에 있어 매우 중요합니다.

WAIaaS는 세 가지 인증 계층을 사용합니다:

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

...

트레이딩 봇의 경우, 패턴은 다음과 같습니다: 시스템 관리자가 masterAuth를 통해 지갑과 세션을 생성하고, 봇 자체는 sessionAuth (특정 지갑에 범위가 지정된 JWT)로 실행되며, 자금 소유자인 귀하는 대규모 트랜잭션을 승인하거나 제어권을 회복하기 위해 ownerAuth를 보유합니다. 봇은 귀하의 마스터 비밀번호에 절대 접근할 수 없습니다.

내부적인 인증 방식은 다음과 같습니다: masterAuth는 Argon2id를 사용하고, ownerAuth는 SIWS/SIWE (Sign-In with Solana/Ethereum)를 사용하며, sessionAuth는 JWT HS256을 사용합니다. 세션별 TTL (Time-To-Live), maxRenewals (최대 갱신 횟수), 그리고 absoluteLifetime (절대 수명)은 모두 설정 가능합니다.

트레이딩 봇 지갑 설정하기

Docker로 시작하세요 — 실행 가능한 인스턴스를 만드는 가장 빠른 방법입니다:

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

데몬(daemon)은 기본적으로 127.0.0.1:3100에 바인딩됩니다. 봇을 위한 지갑을 생성하세요:

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

그 다음, 봇을 위한 세션 토큰(session token)을 생성합니다:

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

해당 세션 토큰(wai_sess_...)은 봇이 이후의 모든 호출에 사용하는 것입니다. 권한 범위를 엄격하게 설정하세요. 실제 제한 사항을 강제하는 것은 정책 엔진(policy engine)입니다.

정책 엔진 (Policy Engine): 봇의 리스크 관리자

이 부분은 프로덕션급(production-grade) 봇과 단순 스크립트를 구분 짓는 핵심 요소입니다. WAIaaS는 21가지 정책 유형과 4가지 보안 티어(security tiers)인 INSTANT, NOTIFY, DELAY, APPROVAL를 갖춘 정책 엔진을 보유하고 있습니다.

기본 설정은 거부(deny)입니다. 명시적으로 허용되지 않는 한 트랜잭션은 차단됩니다. 이는 실제 자금을 이동하는 자율 에이전트(autonomous agents)에게 적합한 기본 설정입니다.

다음은 트레이딩 봇을 위한 실질적인 정책 설정 예시입니다:

# 4단계 보안을 적용한 지출 한도 설정
curl -X POST http://127.0.0.1:3100/v1/policies \
  -H "Content-Type: application/json" \
...

티어 할당 로직: amount <= instant_max → 즉시 실행. <= notify_max → 실행 후 알림 전송. <= delay_max → 900초 동안 대기열에 추가 (취소 가능). > delay_max → WalletConnect, Telegram 또는 푸시 알림을 통한 인간의 승인 필요.

여러 프로토콜에 걸쳐 거래하는 봇의 경우, 컨트랙트(contract) 및 토큰 화이트리스트(whitelist)도 필요합니다. 이들은 각각 독립적으로 '기본 거부' 방식으로 작동합니다:

CONTRACT_WHITELIST 정책은 명시적으로 나열되지 않은 모든 컨트랙트로의 호출을 차단합니다. ALLOWED_TOKENS 정책은 목록에 없는 모든 토큰의 전송을 차단합니다. APPROVED_SPENDERS 정책은 어떤 주소가 지갑에서 자금을 사용할 수 있도록 승인될지를 제어합니다. 무기한 선물(perpetuals) 거래의 경우, PERP_MAX_LEVERAGE, PERP_MAX_POSITION_USD, PERP_ALLOWED_MARKETS를 통해 봇 코드 내부가 아닌 인프라 계층에서 리스크 제한을 강제할 수 있습니다.

알아두면 유용한 DeFi 전용 정책(DeFi-specific policies): LENDING_LTV_LIMIT은 Aave/Kamino 포지션의 담보 인정 비율(LTV, Loan-to-Value) 상한을 설정하며, LENDING_ASSET_WHITELIST는 담보로 사용하거나 빌릴 수 있는 자산을 제한하고, VENUE_WHITELIST는 봇이 라우팅할 수 있는 거래소(Trading venues)를 제어합니다.

멀티 프로토콜 실행: 실제 API 호출 (Multi-Protocol Execution: The Actual API Calls)

통합된 프로토콜 접근 방식이 실제로 어떻게 작동하는지 보여드리겠습니다. 이 모든 호출은 동일한 세션 토큰(Session token) 패턴을 사용합니다.

Jupiter(Solana)에서 스왑(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 스왑입니다. 라우팅(Routing), 슬리피지 처리(Slippage handling), 트랜잭션 구성(Transaction construction)은 프로바이더(Provider) 내부에서 이루어지며, 여러분의 봇은 단지 의도(Intent)를 보낼 뿐입니다.

실행 전 잔액 확인:

curl http://127.0.0.1:3100/v1/wallet/balance \
  -H "Authorization: Bearer wai_sess_eyJhbGciOiJIUzI1NiJ9..."

실행 전 시뮬레이션 (봇에게 매우 중요):

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

dryRun 플래그는 트랜잭션을 검증(Validate), 인증(Auth), 정책 확인(Policy check), 대기(Wait), 실행(Execute), 확정(Confirm)의 전체 7단계 파이프라인(Pipeline)을 통해 실행하지만, 브로드캐스트(Broadcast) 직전에 멈춥니다. 이를 통해 자금이 이동하기 전에 정책 결정 결과, 시뮬레이션된 결과, 그리고 모든 오류를 확인할 수 있습니다. 자동화된 전략(Automated strategies)의 경우, 새로운 코드 경로를 실제 실행하기 전에 항상 드라이 런(Dry-run)을 수행하십시오.

**가스 조건부 실행 (Gas conditional execution)**은 알아두면 좋은 또 다른 파이프라인 기능입니다. 트랜잭션이 가스 가격(Gas price)이 특정 임계값에 도달했을 때만 실행되도록 설정할 수 있습니다. 이는 파이프라인의 stage4-wait 단계에 해당하며, 봇이 트랜잭션을 큐(Queue)에 넣으면 파이프라인이 조건이 충족될 때까지 이를 유지합니다.

TypeScript로 봇 구축하기 (Building the Bot in TypeScript)

TypeScript SDK를 사용하면 동일한 API 인터페이스에 타입이 지정된(Typed) 방식으로 접근할 수 있습니다:

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

const client = new WAIaaSClient({
...

에러 핸들링 (Error handling)은 명시적으로 처리할 가치가 있습니다. 정책 거부 (Policy denials)는 구조화된 에러로 반환됩니다:

try {
  const tx = await client.sendToken({ to: '...', amount: '1.0' });
} catch (error) {
...

코드 세부 정보가 포함된 POLICY_DENIED 에러는 어떤 정책이 실행되었는지 정확히 알려줍니다 — SPENDING_LIMIT, CONTRACT_WHITELIST, PERP_MAX_LEVERAGE 등입니다. 이는 즉각적인 조치가 가능합니다. 여러분의 봇은 조용히 실패하거나 불투명한 RPC 에러를 던지는 대신, 이를 로그에 기록하고, 알림을 보내고, 실행을 중단(back off)할 수 있습니다.

AI 기반 전략을 위한 MCP 통합 (MCP Integration)

만약 여러분의 봇이 의사결정을 위해 LLM (Claude, GPT-4 또는 기타 MCP 호환 에이전트)을 사용한다면, WAIaaS는 지갑, 트랜잭션 (transaction), DeFi, NFT 및 x402 작업에 직접 매핑되는 45개의 MCP 도구 (tools)를 노출합니다.

빠른 설정:

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

Claude Desktop 설정:

{
  "mcpServers": {
    "waiaas-trading": {
...

여러 개의 지갑을 별도의 MCP 서버로 실행할 수 있습니다. 예를 들어, 하나는 Solana 트레이딩 지갑용으로, 다른 하나는 EVM 수익률 전략 (yield strategies)용으로 사용하며, 각 지갑에 대해 별도의 정책 세트를 적용할 수 있습니다. 에이전트는 get_defi_positions를 호출하여 Aave, Kamino, Lido, Jito에 걸친 현재 노출 (exposure)을 확인한 후, 그 결과에 따라 행동합니다.

퀵 스타트: 봇 실행을 위한 5단계

1. WAIaaS 배포: docker compose up -d — 데몬 (daemon)은 127.0.0.1:3100에서 실행됩니다.
2. 지갑 생성: masterAuth를 사용하여 POST /v1/wallets 실행
3. 세션 생성: masterAuth를 사용하여 POST /v1/sessions 실행, wai_sess_... 토큰 획득
4. 정책 설정: 최소한 SPENDING_LIMIT + ALLOWED_TOKENS + CONTRACT_WHITELIST 설정
5. 실행: 모든 봇 호출에 sessionAuth를 사용 — 통합 API를 통해 스왑 (swap), 대출 (lend), 스테이킹 (stake), 브릿지 (bridge) 수행

수동 비밀번호 설정 없이 자동 프로비저닝 (auto-provisioning)을 하려면:

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

전체 OpenAPI 3.0 명세는 http://127.0.0.1:3100/doc에서 확인할 수 있으며, /reference에서 대화형 참조 UI (interactive reference UI)를 제공합니다. 39개의 모든 REST API 라우트 (route) 모듈이 그곳에 문서화되어 있으며, 이는 프로토콜별 액션 파라미터 (action parameters)를 매핑할 때 유용합니다.

다음 단계

15개의 통합된 DeFi 프로토콜, 21개의 정책 유형 (policy types), 그리고 ERC-4337 지원에 대한 상세한 내용은 WAIaaS GitHub 저장소에 상세히 문서화되어 있습니다. 코드베이스는 오픈 소스이며 프로토콜 제공자 구현체 (protocol provider implementations)를 직접 읽어볼 수 있습니다. 실제 자금을 사용하여 운영 환경에 배포하기 전에는 Docker Secrets 오버레이 패턴 (docker-compose.secrets.yml)과 3계층 보안 아키텍처 (3-layer security architecture)를 반드시 검토하십시오. 전체 문서와 커뮤니티 리소스를 확인하려면 waiaas.ai를 방문하세요.