Molayo

© 2026 Molayo

Zenn헤드라인2026. 05. 23. 11:45

AI 에이전트에게 지갑을 들려주기: 왜 지금 Agent Wallet이 필요한가

요약

AI 에이전트 시대에 기존 구독 모델과 신용카드 결제 방식이 가진 한계를 분석합니다. 에이전트의 빈번한 소액 결제와 API 키 관리 문제를 해결하기 위해 스테이블코인 기반의 결제 SDK인 'kawasekit' 프로젝트를 소개합니다.

핵심 포인트

  • 기존 월정액 구독 모델은 AI 에이전트의 사용 패턴에 부적합함
  • 신용카드는 머신 간의 빈번한 초소액 결제에 구조적 한계가 있음
  • API 키 관리의 복잡성을 해결할 새로운 인프라가 필요함
  • 스테이블코인이 에이전트용 결제 수단으로서 대안이 될 수 있음

서론

안녕하세요, k0yote입니다. 일본에서 프리랜서 소프트웨어 엔지니어로 활동하고 있으며, 최근 몇 년간 주로 Web3 백엔드 (Go + Solidity + EVM) 및 스테이블코인 (Stablecoin) 결제 관련 구현을 업무로 하고 있습니다. JPYC의 EIP-3009 구현, MPC 월렛 (Wallet), Paymaster를 통한 가스 레스토랑 트랜잭션 (Gasless Transaction) 등 여러 프로젝트에서 실서비스 운영을 경험했습니다.

앞으로 6개월에 걸쳐, AI 에이전트용 스테이블코인 결제 SDK를 OSS (Open Source Software)로 공개할 예정입니다. 프로젝트 이름은 kawasekit입니다.

('환율' + kit). TypeScript SDK로, AI 에이전트가 일본 엔 스테이블코인 (JPYC)이나 USDC를 사용하여 종량제 API를 호출할 수 있도록 하는 것을 목표로 합니다.

이 기사는 그 시리즈의 제1회로서, **"왜 AI 에이전트에게 Wallet이 필요한가"**라는 문제의식에서 시작되었습니다. 기술적인 상세 내용은 다음 회차부터 다룰 예정이므로, 이번에는 코드가 거의 등장하지 않습니다.

문제: AI 서비스의 요금 모델이 붕괴하고 있다

먼저, 본인이 사용 중인 AI 도구의 월간 구독료를 계산해 보세요.

  • ChatGPT Plus: 약 3,000엔
  • Claude Pro: 약 3,000엔
  • Cursor: 약 3,000엔
  • GitHub Copilot: 약 1,500엔
  • Perplexity Pro: 약 3,000엔
  • Midjourney: 약 1,500엔~
  • Notion AI, Linear, Figma AI…

여기까지만 해도 월 15,000~20,000엔을 넘어서는 것이 현대 소프트웨어 엔지니어의 표준 장비입니다. '구독 피로 (Subscription Fatigue)'라는 말은 이제 구식이며, 이제는 "구독 파탄"의 영역에 들어섰습니다.

하지만 정말 심각한 것은 요금 그 자체가 아닙니다.

API 키 관리 지옥입니다. OpenAI의 키, Anthropic의 키, 각종 MCP 서버, Replicate, ElevenLabs, Voicevox, Cohere, Together AI… 각각에 대해 별도의 키, 별도의 청구서, 별도의 사용량 대시보드가 존재합니다. 엔지니어 혼자서 10~20개의 API 키를 관리하는 것이 당연한 일이 되었습니다.

그리고 AI 에이전트 시대가 시작되면 이 파탄은 더욱 가속화됩니다. 에이전트 스스로가 "지금 사용할 수 있는 API 중 가장 저렴한 것을 선택하여, 필요에 따라 과금하며 태스크를 진행한다"라는 동작을 취하기 시작하기 때문입니다. 월정액 모델은 Agent에게 맞지 않습니다. 초·토큰·횟수 단위로 과금되어야 함에도 불구하고, 현재는 이를 담당할 인프라가 없습니다.

왜 기존 결제 방식으로는 불충분한가

"신용카드로 그때마다 결제하면 되지 않을까?"라고 생각할지도 모릅니다. 실제로 Stripe나 PayPal은 훌륭한 시스템입니다. 하지만 AI 에이전트의 맥락에 대입해 보면 구조적인 불일치가 존재합니다.

제약 사항신용카드/Stripe의 실태AI Agent가 원하는 것
최소 결제액수십 엔~ (고정 수수료 때문)1엔 미만의 극소액도 가능
...

신용카드는 "인간이, 가끔, 어느 정도의 금액을, 인간을 상대하는 상점에 지불하기" 위해 최적화되어 있습니다. 머신 간의, 빈번한, 소액의, 자동 결제에는 근본적으로 적합하지 않습니다.

국제 결제가 되면 더욱 지옥입니다. 일본에서 해외 API를 호출하면 거의 확실하게 DCC (Dynamic Currency Conversion: 해외 결제 시 불리한 자체 환율 변환)의 희생양이 되어, 표시된 가격보다 5~8% 높은 청구서가 날아옵니다. 에이전트가 전 세계의 API를 나누어 사용하는 시대에 이것은 치명적입니다.

Stablecoin이 구조적으로 해결하는 문제

여기서 Stablecoin (법정 화폐에 가치를 연동시킨 암호 자산)이 등장합니다.

Stablecoin이 특별한 이유는 가격 안정성 때문만이 아닙니다. **프로그램 가능한 돈 (Programmable Money)**이라는 점이 본질입니다.

  • 24/7 settlement: 은행 영업시간에 얽매이지 않음
  • 프로토콜 층에서 국경 없음: 체인 상의 송금에는 국경 개념이 없음 (실제 이용은 on/off-ramp나 규제의 제약을 받음)
  • 마이크로 페이먼트 (Micropayment) 실용 영역: 가스비 (Gas fee)에 따라 1엔 미만의 결제도 성립
  • 머신 가독성 (Machine Readable): 스마트 컨트랙트 (Smart Contract)와 자동 연동 가능

특히 일본의 상황은 2025년 이후 극적으로 변했습니다. 개정 자금결제법에 의해 일본 엔화 연동 스테이블코인(Stablecoin)인 JPYC가 전자결제수단으로서 정식 인가되어, 2025년 10월 27일에 발행이 시작되었습니다. 이는 선불식 지급수단의 연장이 아니라, 은행 송금과 동등한 법적 지위를 갖는 엔화 기반 스테이블코인입니다.

즉, AI 에이전트가 "100엔의 API 콜을 10번 호출하는" 결제를 법적으로 깨끗한 엔화 스테이블코인으로 실행할 수 있는 세상이 이미 기술적으로 도래했습니다.

하지만, Wallet은 "사용자에게 보여주어서는 안 된다"

여기서 많은 Web3 프로젝트가 발을 헛디딥니다.

"스테이블코인(Stablecoin)이 편리하니까, 사용자에게 월렛(Wallet)을 갖게 하자" ─ 이것이 최대의 함정입니다.

"개인키(Private Key)를 보관해 주세요", "시드 구절(Seed Phrase)을 메모해 주세요", "Polygon 네트워크에 연결해 주세요", "가스비(Gas Fee)를 위해 MATIC을 구매해 주세요"… 이 순간 사용자는 이탈합니다. Web3의 10년 동안 반복되어 온 실패 패턴입니다.

참고해야 할 것은, 사실 20년도 더 전에 Valve가 Steam을 통해 이미 실현했던 것입니다:

  • 한 번 신용카드를 등록한다
  • Steam Wallet에 충전한다
    이후에는 클릭만으로 게임을 살 수 있다

Steam Wallet은 "월렛을 의식하게 만들지 않는 것"에 성공한, 아마도 역사상 가장 성공적인 결제 UX일 것입니다. AI 에이전트의 세계에서 지향해야 할 바가 바로 이것입니다.

사용자는 월렛을 가지고 있다는 사실조차 모른다.

그저 "사용한 만큼 요금이 차감되고 있다"고 느낀다.

이를 실현하기 위한 기술이 최근 몇 년 사이 급속도로 갖춰졌습니다.

Account Abstraction (ERC-4337)이라는 해법

Ethereum 커뮤니티가 지난 5년간 추진해 온 가장 큰 UX 개선이 바로 계정 추상화 (Account Abstraction, AA) 입니다. 표준화된 ERC-4337과 Kernel/Safe 등의 구현을 통해 다음과 같은 것들이 현실적으로 사용 가능해졌습니다:

여기서 중요한 점은, 엔트리포인트 (EntryPoint)가 UserOp를 **두 가지 단계 (Phase)**로 나누어 처리한다는 점입니다. 먼저 **검증 단계 (Validation Phase)**에서 서명이나 정책을 검증하고, 이를 통과해야 비로소 **실행 단계 (Execution Phase)**에서 실제 처리가 진행됩니다. 후술할 지출 정책 (Spending Policy)이 적용되는 곳은 바로 이 검증 단계이며, 정책에 반하는 조작은 실행에 도달하기 전에 차단됩니다.

이 아키텍처를 통해 해결할 수 있는 것:

  • 페이마스터 (Paymaster): 가스비를 다른 주체 (서비스 제공자 등)가 대신 부담한다 → 사용자는 가스의 존재조차 모른다
  • 세션 키 (Session Key): "이 시간 동안, 이 상대에게, 이 금액까지"와 같이 범위를 한정한 서브 키를 발행 → 에이전트가 마음대로 서명할 수 있는 안전한 범위를 만들 수 있다
  • 스마트 계정 (Smart Account): EOA가 아닌 스마트 컨트랙트 (Smart Contract)가 계정 역할 → 복구, 정책, 다중 소유자 설정이 가능하다

실제로 최신 ERC-4337 v0.7과 Kernel v3.1의 조합을 사용하면, 사용자의 EOA는 단 한 번도 트랜잭션의 송신자가 되지 않고, 가스도 잔액도 없는 상태에서 스마트 계정의 배포와 트랜잭션 실행을 완료하는 것이 가능합니다. 제가 이번 주에 배포한 kawasekit M1의 테스트 트랜잭션이 그 실례입니다:

Bundler가 게시하고, Paymaster가 0.013 POL의 가스비를 대신 부담하며, Smart Account가 배포 및 실행되었습니다. 소유자의 EOA는 이 트랜잭션의 송신자 (from)로 등장하지 않습니다. from은 Bundler이며, EOA 자체는 단 한 번도 자신의 트랜잭션을 발행하지 않았습니다. 가스도 잔액도 가지고 있지 않습니다.

Spending Policy: 에이전트에게 자유를 주기 위한 제약

AI 에이전트에게 월렛을 들려준다고 하면 "탈취당하면 어떻게 하느냐"라는 반응이 반드시 나옵니다. 이는 타당한 우려입니다.

하지만 답은 "갖게 하지 않는다"가 아니라, "갖게 하는 방식을 설계한다" 입니다.

지출 정책 (Spending Policy)의 개념은 단순합니다:

  • 금액 제한: 1일 최대 1,000엔, 1회 거래당 최대 100엔 -
    수신처 제한: 허가된 API 엔드포인트의 스마트 컨트랙트(Smart Contract)만 가능 -
    시간 범위: 평일 09:00~18:00만 허용, 심야 시간대 차단 -
    토큰 제한: JPYC만 허용, 기타 ERC-20 송금은 거부

이러한 조건들을 선언적으로 작성하여, Validator (검증자) 또는 **Permission Module (권한 모듈)**로서 스마트 계정(Smart Account)에 통합합니다. 에이전트가 폭주하더라도, 정책을 초과하는 조작은 EntryPoint 레벨에서 차단됩니다.

이는 "신뢰하느냐/하지 않느냐"의 문제가 아니라, 설계의 문제입니다. 신용카드에 이용 한도를 설정하는 것과 동일한 발상을 더 세밀한 입도(Granularity)로 구현할 수 있다는 것뿐입니다.

ERC-7579 (modular smart accounts)의 등장으로 Validator나 Executor를 플러그인 방식으로 추가하거나 교체할 수 있게 되었으며, Spending Policy (지출 정책) 엔진도 독립된 부품으로서 개발할 수 있는 시대가 왔습니다. kawasekit은 M2에서 이 레이어를 구축합니다.

지금까지 "어떻게 구현할 것인가"를 이야기해 왔지만, 마지막으로 "어떤 스테이블코인 (Stablecoin)으로 구현할 것인가", 특히 일본 시장에 가장 적합한 선택에 대해 적어두겠습니다.

왜 일본의 JPYC가 이 문맥에서 강력한가

여기까지 읽고 "USDC로 충분하지 않을까?"라고 생각하신 분도 계실지 모릅니다. 글로벌 전개에 있어서는 USDC도 당연히 고려 대상입니다. 하지만, 일본 시장의 출발점으로서 JPYC는 독자적인 우위를 점하고 있습니다.

법적 명확성: 개정 자금결제법에 따른 전자결제수단. 일본 사업자가 안심하고 채택 가능 -
멀티체인 (Multi-chain): Ethereum / Polygon / Avalanche에서 동일한 주소로 배포 완료. 향후 Kaia, Circle의 Arc로도 확장 예정 -
엔화 네이티브 (Yen-denominated native): 환리스크 없이 일본의 AI 스타트업이 도입 가능 -
LINE NEXT와의 연결: Kaia 상의 JPYC 대응을 통해 동아시아 4억 사용자 권역 (LINE 경제권)과의 가교 역할

특히 네 번째 항목은 은근히 영향력이 큽니다. Kaia 상의 Unifi 월렛이 LINE에 내장되어 출시된다면, 일본뿐만 아니라 한국, 대만, 태국, 인도네시아의 사용자들이 JPYC 결제에 직접 접근할 수 있게 됩니다.

즉, JPYC는 "일본 국내 스테이블코인"이라기보다, **"아시아 권역에서의 달러 이외의 유력한 결제 단위"**가 될 가능성이 있습니다. AI 서비스의 아시아 시장 공략에 있어 이는 무시할 수 없는 인프라입니다.

앞으로 만들 것: kawasekit

kawasekit은 위 사항들을 모두 추상화한 TypeScript SDK입니다.

// 개발자가 작성하고 싶은 코드 (이 정도로 심플하게)
import { createKawaseClient, polygon } from "kawasekit";
const client = createKawaseClient({
...

기술 스택:

TypeScript 6 (strict, ESM-only) -
viem v2 + ZeroDev Kernel v3.1 (ERC-4337 v0.7) -
Foundry (Solidity contracts, ERC-7579 modules) -
Polygon → Kaia → Avalanche 순으로 체인 지원 확대

로드맵:

M1: 스마트 계정 기반 (Polygon Amoy testnet) ← 현재 단계 -
M2: Spending Policy + JPYC 송금 (UserOp을 통해 가스리스 (Gasless) 구현) -
M3: CLI + 문서 + 통합 샘플 -
M4: 메인넷 (Mainnet) 대응 + v0.1 npm 공개 -
M5: 커뮤니티 + 첫 번째 프로덕션 통합 -
M6: Managed 버전 alpha + Rust policy engine

리포지토리는 이미 공개되었습니다: https://github.com/k0yote/kawasekit

kawase

(為替)라는 이름은 일본어로 '통화 간의 교환·송금'을 의미하는 오래된 단어에서 따왔습니다. AI 에이전트와 API 프로바이더, 에이전트 간, 그리고 국경을 넘나드는 결제 ─ 이 모든 것을 '환(為替)'으로 파악하고, 개발자가 이를 의식하지 않고 다룰 수 있는 Kit를 만든다는 의도입니다.

차기 예고

다음 회차 (M2 착수 시)는 기술 심층 분석 편으로 들어갑니다:

「일본 엔화 스테이블코인 (JPYC)을 에이전트가 가스비 없이(gasless) 보내게 하기 — EIP-3009와 Account Abstraction의 활용법」

  • EIP-3009 (transferWithAuthorization)가 해결한 문제와 Smart Account에서는 사용할 수 없는 이유 - ZeroDev Paymaster와 조합할 때의 주의점
  • JPYC를 실제로 송금하는 TypeScript 코드
  • Spending Policy를 어떻게 Validator로서 통합할 것인가

Build in public 방식으로 진행하므로, 커밋 단위의 진척 상황은 GitHub과 X (구 Twitter)를 통해 공유하겠습니다:

기술적인 피드백, 설계 판단에 대한 이견, JPYC나 ZeroDev에 관한 보충 설명 등 댓글을 남겨주시면 정말 큰 도움이 됩니다. 솔로 개발의 가장 큰 약점은 시야 협착이기에, 외부의 시선 그 자체가 가치입니다.

그럼 다음 시간에 뵙겠습니다.

Discussion

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0