Agentic Kaia: Building the Economic Layer for AI Agents

이번 시리즈의 첫 번째 글은 책임성(Accountability)을 잃지 않으면서 베이스 레이어를 개방하는 것에 대한 논의였다. 이번 글에서 다룰 주제는 그 베이스 위에 새로 등장하기 시작한, 사람이 아닌 사용자에 관한 이야기다.

바로 AI 에이전트에 대한 것이다.

이제 소프트웨어는 단순히 명령을 기다리는 수동적 도구에서, 스스로 계획하고, 외부 서비스를 호출하고, 컨텍스트를 유지하면서 여러 단계에 걸쳐 행동하는 시스템으로 옮겨가고 있다. 이 흐름이 본격화되면 곧 새로운 질문 하나가 따라온다. 에이전트가 스스로 경제 활동에 참여하려면 무엇이 필요한가.

답은 명확하다. 에이전트에게는 자기만의 경제 인프라가 필요하다. 가치를 보유하고, 신원을 증명하고, 평판을 쌓고, 플랫폼 운영자를 사이에 두지 않고도 다른 주체와 계약을 체결할 수 있는 수단. 지금의 인터넷 스택은 이 중 어느 것도 사람이 아닌 주체를 전제로 설계된 적이 없다.

블록체인이 의미를 갖는 지점이 바로 여기다. 모든 AI 워크플로우가 온체인으로 실행되어야 한다는 말이 아니다. 사실 대부분의 경우 굳이 그럴 필요가 없다. 다만 에이전트가 경제 레이어에서 부딪히는 구체적인 문제들이, 블록체인이 이미 풀어둔 영역, 즉 무기명 자산(bearer asset), 프로그래머블 어카운트, 그리고 플랫폼 운영자 없이 자율적으로 실행되는 컨트랙트의 특성과 유난히 잘 맞아떨어진다.

이 글은 그 흐름을 세 단계로 정리한다. 먼저 오늘날 에이전트가 구조적으로 결여하고 있는 지점을 짚어본다. 다음으로 현재 블록체인 업계가 어떤 표준(ERC-8004, x402, ERC-8183)을 중심으로 수렴하고 있는지를 본다. 마지막으로 Kaia가 이 공통 스택을 어떻게 채택(adopt)하고, 어떤 영역을 직접 빌드(build)할지를 다룬다.

1. AI 에이전트와 블록체인

1.1 에이전트는 경제 주체가 되고 있다

AI 시스템에서 일어난 본질적인 변화는, 더 자연스러운 문장을 쓰거나 더 많은 도구를 다루게 된 데 있지 않다. 이제 에이전트가 행동의 순서를 스스로 선택하고, 여러 서비스를 아울러 실행할 수 있다는 점이다.

질문에 답하는 모델은 단순히 도구에 불과하다. 반면 API를 선택하고, 결제하고, 결과를 확인하고, 출력을 내는 에이전트는 전체 워크플로를 관장한다. 여전히 사용자나 회사를 대신해 움직이는 것일지는 몰라도, 동작 방식 자체가 다르다. 에이전트는 이미 마켓 안에서 움직이고 있다.

이렇게 되면 에이전트는 자연스럽게 돈이 필요하다. 데이터를 사야 할 때가 있고, 컴퓨팅 리소스를 빌려야 할 때가 있고, 서비스를 구독하거나 다른 에이전트에게 작업 대금을 지급해야 할 때가 있다. 반대로 자신이 완료한 작업의 보수를 수령해야 할 때도 있다. 지능만으로는 부족하다. 에이전트는 정산(settlement)을 할 수 있어야 한다. 자산을 보유하고, 지출하고, 수령하고, 계약을 이행하는 일을 사람이 직접 마지막 버튼을 눌러주지 않고도 끝낼 수 있어야 한다.

문제는 지금의 인터넷 결제 스택은 처음부터 그런 주체를 가정하지 않았다는 것이다.

1.2 AI 에이전트는 unbanked다

에이전트는 API를 호출할 수 있고, 코드를 실행할 수 있고, 문서를 파싱하고, 서비스를 사용할 수 있다. 그러나 은행 계좌를 개설하지 못하고, 자기 이름의 카드를 발급받지 못하고, KYC를 통과하지 못하며, 차지백(chargeback)이나 계좌 동결에 대응하지도 못한다. 기존의 결제 레일은 자격증명 뒤에 법적 인격을 가진 주체가 있다는 전제 위에 설계됐기 때문이다.

이 전제는 에이전트가 사람을 보조하기만 할 때는 잘 작동한다. 쇼핑 어시스턴트가 상품을 추천하고 사용자가 "구매" 버튼을 누르는 흐름이라면 기존 결제 스택만으로 충분하다. 구매자는 여전히 사람이다.

문제는 에이전트가 사람을 거치지 않고 행동해야 할 때다. 새벽 3시에 데이터 쿼리 비용 몇 센트를 지불해야 하거나, 다른 에이전트의 서브태스크 수행 대금을 정산해야 하는 상황에서, 에이전트는 결국 누군가의 금융 신원을 빌려 써야 한다. 그 순간 자율성은 표면적인 것이 된다.

이런 의미에서 AI 에이전트는 unbanked다. 이 공백을 메우는 첫 번째 결제 인프라가 스테이블코인이다. 스테이블코인은 디지털 네이티브 자산이고, 24시간 결제가 가능하며, 은행 계좌 없이 지갑 안에서 보유될 수 있다. 그렇다고 에이전트 시대의 모든 결제가 스테이블코인으로 대체된다는 뜻은 아니다. 사람이 아니라 에이전트 자신이 거래의 당사자가 되는 영역에서, 스테이블코인이 가장 자연스러운 답이 된다는 의미다.

1.3 에이전트의 신원과 평판은 함께 이동하지 않는다

한 에이전트가 다른 에이전트를 고용하려 할 때, 무엇을 알 수 있을까. 누가 소유하고 있는가. 어떤 API 엔드포인트를 제공하는가. 어떤 작업을 수행해 왔는가. 그 결과물을 검증한 주체가 있는가. 그리고 이 이력은 플랫폼 사이를 자유롭게 이동할 수 있는가.

지금까지의 답은 대부분 플랫폼 안에 갇혀 있었다. 모델 제공자는 자기 환경 안에서 에이전트를 식별할 수 있다. 마켓플레이스에서는 리뷰를 확인할 수 있다. SaaS 제품은 내부 사용 이력을 추적할 수 있다. 그러나 이 신호들은 중립적이지도 공유 가능하지도 않다. 다른 에이전트가 이를 활용하려면 기존 운영자에 대한 신뢰가 전제되어야 한다.

결국 익숙한 크립토 문제가 새로운 옷을 입고 다시 등장한 셈이다. 조직 경계를 넘어 협업하는 에이전트들에게는, 단일 벤더의 데이터베이스에 갇히지 않는 신원과 평판이 필요하다. 지갑은 에이전트에게 영구적인 핸들을 부여한다. 레지스트리는 에이전트를 발견 가능하게 만든다. 서명된 피드백과 검증(attestation)은 평판을 신뢰할 수 있는 방식으로 쌓이게 만든다.

이 중 어느 것도 "이 에이전트는 좋은 에이전트다"라는 사실을 직접 증명해주지는 않는다. 다만 다른 에이전트들이 함께 읽고, 감사하고, 그 위에 무언가를 쌓아 올릴 수 있는 공통의 표면이 만들어진다. 에이전트가 서로에게 신뢰할 수 있는 존재가 되어야 한다는 뜻이다.

1.4 병목은 실행에서 검증으로 이동한다

실행(execution)은 점점 저렴해지고 있다. 검증(verification)은 그렇지 않다.

에이전트가 늘어날수록 주장(claim)도 함께 늘어난다. "작업을 완료했다", "데이터가 유효하다", "거래 제약을 지켰다", "출처를 확인했다", "유료 엔드포인트가 올바른 응답을 돌려줬다" 같은 것들. 일부는 작업을 재실행해 확인할 수 있다. 그러나 많은 경우 검증을 저렴하게 할 방법이 없다. 사람이 의미 있는 행동마다 검증을 직접 수행해야 한다면, 에이전트 경제의 효용은 크게 줄어든다.

블록체인이 검증 자체를 통째로 풀어주지는 않는다. 법률 메모가 훌륭한지, 트레이딩 전략이 현명한지, 모델의 추론이 타당한지를 블록체인이 판단할 수는 없다. 다만 블록체인이 제공할 수 있는 것은 검증을 둘러싼 조율 레이어다. 누가 그 주장을 했는지, 누가 평가했는지, 어떤 조건이 사전에 합의되었는지, 어떤 검증이 이행된건지, 그 결과 자금이 어떻게 이동했는지가 그 위에 기록된다.

1.5 그래서 블록체인이 실제로 해결할 수 있는 것

에이전트 경제에서 블록체인이 풀 수 있는 영역은 명확하다. 스테이블코인 결제, 스마트 월렛 기반 신원 관리, 검증 가능한 행동 기록, 그리고 프로그래머블한 계약들이다.

스테이블코인은 카드 계좌나 은행 자격증명 없이 에이전트가 결제하고 결제받을 수 있는 수단을 제공한다. 스마트 어카운트는 지출 한도, 세션 키, 범위가 제한된 권한, 복구 로직, 정책 컨트롤 같은 안전장치를 함께 묶을 수 있다. 온체인 기록은 행동의 정확성을 증명해주지는 못하지만, 누가 무엇을 했는지를 분명히 남긴다. 스마트 컨트랙트는 자금을 보관하고, 조건을 정의하고, 어테스테이션을 근거로 정산까지 처리할 수 있다.

이 조합 위에서 에이전트는 공유 플랫폼이나 신뢰받는 마켓플레이스, 사람 기반의 에스크로 제공자 없이도 함께 일할 수 있는 방법을 갖게 된다.

이것은 "AI를 일단 온체인에 올리자"는 식의 일반론이 아니다. 정확하게 말하면 적합성에 관한 이야기다. 자율적인 경제 주체는 자기만의 경제적 신체가 필요하다. 에이전트에게 그 신체는 스테이블코인, 스마트 월렛, 스마트 컨트랙트다.

2. Industry Landscape

2.1 산업은 아직 스택을 정의하고 있다

에이전트 경제는 이제 막 시작되었다. 시장의 상당 부분은 여전히 초기 인프라, PoC, SDK, 그리고 표준 정립 작업에 집중되어 있다. 이는 "제품화 이전의 작업"이라며 무시하기 쉬운 풍경이다. 그러나 크립토에서는 실제로 메인 어돕션이 되기 전에 표준이 시장의 형태를 먼저 결정하는 경우가 많다.

블록체인 쪽에서 보면 AI 에이전트 논의는 비교적 단순한 스택으로 수렴하고 있다.

• 에이전트의 신원과 평판
• 에이전트가 프로그래머블하게 실행할 수 있는 결제
• 결제를 조건부 거래로 확장하는 커머스 기반

이 세 축에 가장 직접 대응하는 표준이 ERC-8004, x402, ERC-8183이다. 세 표준은 서로 경쟁하지 않는다. 각자 다른 레이어를 맡는다.

ERC-8004가 답하는 질문은 이 에이전트는 누구이며, 어떤 평판을 가지고 있는가다.

x402가 답하는 질문은 에이전트가 인터넷 상에서 리소스에 대해 어떻게 결제하는가다.

ERC-8183이 답하는 질문은 에이전트들은 작업, 결과물, 검증, 정산을 어떻게 하나의 프로그래머블 거래로 묶을 것인가다.

이 셋이 합쳐져 에이전트 네이티브 경제를 정의하는 첫 번째 일관된 시도를 만들고 있다.

2.2 ERC-8004: 에이전트를 위한 신원, 평판, 검증

ERC-8004는 Trustless Agents라는 이름으로도 불린다. 이는 기존의 에이전트 프로토콜은 통신은 도와주지만, 신뢰를 풀어주지는 않는다는 관찰에서 시작되었다.

MCP는 외부 시스템이 에이전트에게 툴, 리소스, 프롬프트를 노출할 수 있게 해준다. A2A는 에이전트들이 자기 역량을 광고하고, 메시지를 주고받고, 태스크를 조율할 수 있게 한다. 둘 다 유용한 통신 레이어다. 그러나 어느 쪽도 오픈 인터넷에 중립적인 에이전트 발견, 식별, 이력 평가, 결과 검증 수단을 제공하지는 않는다.

ERC-8004는 이 빠진 신뢰 레이어를 세 개의 레지스트리로 메운다.

첫 번째는 Identity Registry다. ERC-721 위에 설계되어 있어, 각 에이전트는 양도 가능한 온체인 식별자를 갖는다. 토큰은 에이전트 등록 파일을 가리키며, 그 파일에는 에이전트의 기능, 접근 방법, 결제 방식, 디스커버리에 필요한 메타데이터가 담긴다. 등록 파일은 IPFS, HTTPS, 그 외 지원되는 URI 스킴을 통해 게시할 수 있다.

이 설계 선택은 단순해 보이지만 중요한 결과를 만든다. ERC-721을 채택하면서 표준은 에이전트 신원을 크립토가 이미 익숙하게 다루는 소유권 및 인덱싱 스택 위에 직접 꽂아 넣는다. 토큰의 소유자가 곧 에이전트 신원의 소유자가 된다. 기존 지갑, 익스플로러, 인덱서, 마켓플레이스는 이 프리미티브를 그대로 읽는다. 에이전트는 다른 온체인 자산처럼 양도되고, 위임되고, 표시되고, 인덱싱될 수 있으면서, 더 풍부한 오프체인 메타데이터를 함께 가리킨다.

두 번째는 Reputation Registry다. 상호작용이 끝나면 거래 상대는 그 에이전트에 대한 피드백을 제출할 수 있다. 피드백에는 서명된 값, 태그, 엔드포인트 정보, 해시, 그리고 더 풍부한 오프체인 데이터로 향하는 링크가 포함될 수 있다. ERC-8004는 단일한 평판 점수를 강제하지 않는다. 이것은 의도된 설계다. 평판은 하나의 숫자로 압축하기엔 도메인 특이성이 너무 강하다. 코딩 에이전트, 마켓 데이터 에이전트, 법률 리서치 에이전트가 같은 수식으로 평가받아야 할 이유는 없다.

대신 레지스트리는 피드백을 기록할 공통의 공간을 생태계에 제공한다. 인덱서, 평판 엔진, 보험 시스템, 마켓플레이스, 감사 주체가 이 신호들을 각자 다르게 해석한다. 베이스 레이어는 단순한 채로, 스코어링 레이어는 경쟁적인 채로 둔다.

세 번째는 Validation Registry다. ERC-8004가 본격적으로 흥미로워지는 지점이다. 레지스트리는 에이전트가 결과에 대한 독립 검증을 요청하고, 그에 대한 응답을 기록할 수 있는 인터페이스를 제공한다. 검증자는 스마트 컨트랙트일 수도, 스테이크 기반 서비스일 수도, 신뢰받는 심판일 수도, TEE 기반 오라클일 수도, zkML 검증기일 수도, 또 다른 검증 네트워크일 수도 있다. 어떤 검증 모델이 살아남을지는 표준이 결정하지 않는다. 그저 검증이 요청되고 기록될 수 있는 인터페이스만 마련해 둘 뿐이다.

이 분리가 중요한 이유는 단순하다. 검증 없는 평판은 너무 쉽게 조작되기 때문이다. 마켓플레이스는 리뷰로 채워질 수 있고, 에이전트끼리 서로 추천을 남길 수 있으며, 운영자는 신원을 자유롭게 옮겨 다닐 수 있다. 검증이 더해지면 평판은 특정 작업과 특정 어테스테이션에 묶이고, 그제야 비로소 의미를 갖는다.

여기에 한 가지 더 짚어둘 경계가 있다. ERC-8004는 결제를 스코프 바깥에 둔다. 결제는 x402나 다른 레일이 맡고, 커머스는 ERC-8183이 다룬다. ERC-8004는 에이전트를 발견 가능하고, 식별 가능하고, 책임 추적 가능하게 만드는 일에만 집중한다.

2.3 x402: 인터넷 네이티브 결제

x402는 같은 문제를 신원이 아니라 웹 레이어에서 접근한다. HTTP에는 오래 전부터 402번 "Payment Required" 상태 코드가 있었지만, 사실상 거의 쓰이지 않았다. x402는 비어 있던 그 자리에 실제 결제 흐름을 채워 넣는다.

핵심 아이디어는 단순하다. 클라이언트가 유료 리소스를 요청하면, 서버는 결제 요구사항을 담은 응답을 돌려준다. 클라이언트는 결제에 서명한다. 결제 중개자(facilitator)가 이를 검증하고 정산한다. 서버는 유효한 결제가 확인되면 리소스를 내준다.

이 단순함이 핵심이다. 에이전트 결제는 계정 생성, 호스팅 체크아웃 페이지, 수동 승인, 긴 결제 세션 같은 절차를 감당할 수 없다. 툴 호출 한 번, 데이터셋 한 건, 크롤 한 번, API 응답 하나에 대한 결제라면, 결제 자체가 인터넷의 요청–응답 흐름 안에 그대로 들어가 있어야 한다. x402가 정의하는 것이 바로 그 흐름이다.

구체적인 과정은 다음과 같다. 에이전트가 유료 엔드포인트를 호출한다. 서버는 402 응답을 돌려준다. 응답에는 수락 가능한 네트워크, 자산, 금액, 수취인, 결제 스킴이 명시되어 있다. 에이전트는 호환되는 결제 방식을 골라 서명된 결제 페이로드와 함께 요청을 다시 보낸다. 결제 중개자는 결제 유효성을 점검하고, 스킴에 따라 즉시 정산하거나 정산 준비 상태로 둔다. 그 다음 서버가 리소스를 풀어준다.

여기서 결제 중개자의 역할이 중요하다. 판매자가 엔드포인트를 수익화하려고 직접 체인 인프라를 운영해야 한다면 채택은 사실상 불가능하다. 결제 중개자는 검증과 정산을 추상화해, 일반 웹 서비스가 크립토 인프라 회사가 되지 않고도 온체인 결제를 받을 수 있게 만든다. x402가 개발자 인프라 진영에서 빠르게 관심을 끌고 있는 이유도 결국 이것이다. 개발자가 이미 익숙한 지점, 즉 HTTP, 미들웨어, API에서 표준을 구축하고 있다.

프로토콜은 또한 의도적으로 체인 중립적이다. CAIP-2 네트워크 식별자를 사용해, 결제 요구사항이 EVM 체인, Solana, TON, Aptos 등을 새 이름 체계 없이 가리킬 수 있다. EVM 위에서 토큰의 범위 역시 많은 사람이 가정하는 것보다 훨씬 넓다. x402는 프로토콜 레벨에서 USDC 전용이 아니다. EIP-3009 또는 Permit2를 통해 어떤 ERC-20 토큰이든 사용할 수 있다.

물론 현재 USDC가 EIP-3009를 네이티브하게 지원하고, 표준 자체가 coinbase 진영에서 구축되었다 보니 USDC가 디폴트 스테이블코인으로 사용되고 있다. 하지만, Permit2는 EIP-3009를 구현하지 않는 ERC-20 토큰에 대한 더 일반적인 대체 경로를 x402에 제공한다. Kaia 같은 체인 입장에서 이 사실은 더 큰 의미를 갖는다. 에이전트 결제 레이어가 단 하나의 달러 스테이블코인에 종속되어선 안 되기 때문이다. 에이전트 커머스가 아시아 시장에 안착하려면, KRW 스테이블코인, JPYC, 그 외 지역 스테이블코인이 핵심 정산 자산으로 다뤄져야 한다.

x402는 고빈도 마이크로페이먼트를 위한 배치(batch) 정산도 지원한다. "한 번의 요청, 한 번의 온체인 정산"이라는 단순한 모델은 깔끔하지만 항상 경제적이지는 않다. 배치 모델에서 구매자는 한 번 예치를 해두고, 개별 요청에 대해서는 오프체인 바우처에 서명하며, 판매자는 그 바우처들을 묶어 한꺼번에 정산한다. 웹 레벨의 사용자 경험은 세밀하게 유지하면서, 온체인 정산 오버헤드는 줄이는 방식이다.

요컨대 x402가 정의하는 것은 에이전트 결제가 필요로 하는 정확한 형태다. API 콜 한 번에도 잘 맞을 만큼 작고, 체인과 자산 사이를 자유롭게 오갈 만큼 유연하며, 일반 웹 개발자가 통합할 수 있을 만큼 HTTP에 가까운 형태다.

2.4 ERC-8183: 결제에서 커머스로

결제만으로는 커머스가 완성되지 않는다. 에이전트가 날씨 API 엔드포인트를 결제한다면 x402만으로 충분하다. 리소스는 단순하고, 정산은 즉시 이루어지며, 서버는 데이터를 전달하면 된다.

그러나 많은 에이전트 거래는 그런 형태가 아니다. 이는 보다 더 워크플로에 가깝다. 클라이언트가 무언가를 만들어달라고 에이전트에게 요청한다. 공급자 에이전트가 결과물을 제출한다. 그리고 그 결과물이 작업 조건을 충족하는지 평가한다. 그 이후에 자금이 결제된다.

ERC-8183은 Agentic Commerce라는 이름으로도 불리며, 바로 이 라이프사이클을 표준화한다.

표준의 핵심은 잡 기반 에스크로(job-based escrow)다. 클라이언트가 잡을 생성하고, 공급자, 예산, 만료 기한, 평가자를 설정한 뒤 ERC-20 토큰으로 잡에 자금을 묶어둔다. 공급자는 결과물을 제출한다. 평가자가 작업이 완료되었는지 거부되었는지를 결정한다. 완료되면 공급자가 보수를 받는다. 거부되거나 기한이 지나면 클라이언트에게 자금이 반환된다.

핵심 설계는 역할 분리다. 자금을 묶는 클라이언트, 작업을 수행하는 공급자, 작업의 조건 충족 여부를 판정하는 평가자가 명시적으로 나뉜다. 단순한 경우에는 클라이언트가 평가자를 겸할 수도 있다. 더 흥미로운 사례에서는 평가자가 제3자 어테스터(attester)나 스마트 컨트랙트가 된다.

이 평가자 역할이 ERC-8183을 검증 문제와 직접 연결한다. 평가자 컨트랙트는 영지식 증명을 검사할 수 있고, 오라클의 신호를 읽을 수 있고, 다수의 오프체인 심판이 결과에 서명하도록 요구할 수도 있고, 별도의 검증 네트워크와 결합할 수도 있다. 심지어 그 결과를 ERC-8004의 Reputation Registry에 다시 기록해, 완료되거나 거부된 잡이 공급자 에이전트의 장기 이력으로 누적되도록 만들 수도 있다.

그래서 ERC-8183을 또 하나의 결제 프로토콜로 읽으면 곤란하다. x402를 대체하려는 시도가 아니다. x402는 웹 요청 레이어 위에서 돈을 움직인다. ERC-8183은 작업 자체를 조건부 정산 객체로 만든다.

잡의 상태 머신은 의도적으로 작게 설계 되었다. create, fund, submit, complete, reject, expire. 이는 도메인 특화 로직을 코어 표준 바깥에 남겨두기 때문이다. 법률 리뷰 에이전트, DeFi 실행 에이전트, 데이터 클리닝 에이전트는 각자 다른 평가 로직을 필요로 할 수 있다. ERC-8183은 그 도메인을 표준 안에 인코딩하지 않는다. 그 위에 공통의 에스크로와 어테스테이션 골격을 깔아둘 뿐이다.

물론 아직 풀리지 않은 질문도 많다. 멀티 스텝 잡, 잡들 사이의 연쇄, 상태를 가진 DeFi 워크플로우는 일회성 태스크보다 훨씬 어렵다. 어떤 에이전트 서비스에서는 단일 submit-and-evaluate 사이클이 아니라, 종속성을 갖는 잡의 시퀀스가 필요할 수 있다. 이 부분은 베이스 표준의 일부가 아니라 별도 익스텐션 프로파일로 다뤄질 가능성이 크다. 다만 방향성은 분명하다. 에이전트 커머스는 결제만으로 끝나지 않는다. 에스크로, 결과물, 평가, 평판이 함께 조합되어야 한다.

2.5 세 표준은 어떻게 맞물리는가

새로 만들어지고 있는 스택을 가장 잘 이해하는 방법은 각각을 별도의 레이어로 보는 것이다.

ERC-8004는 신원과 신뢰 레이어다. 어떤 에이전트가 행동하고 있는지, 어떤 메타데이터를 노출하는지, 어떤 평판과 검증 이력을 들고 있는지를 보여준다.

x402는 결제 레이어다. 에이전트가 인터넷 리소스를 소비하는 그 흐름 안에서 결제를 처리할 수 있게 한다.

ERC-8183은 커머스 레이어다. 작업을 공급자, 평가자, 결과물, 정산 결과를 포함하는 에스크로된 잡으로 바꾼다.

현실적인 에이전트간 거래는 이 세 가지를 모두 사용할 수 있다. 클라이언트는 ERC-8004로 공급자를 발견한다. 공급자의 평판과 검증 이력을 확인한다. ERC-8183 잡을 만들고 자금을 에스크로한다. 공급자가 작업을 제출한다. 평가자가 결과에 어테스테이션을 남긴다. 그 결과로 평판이 갱신된다. 워크플로우 안에 단순한 유료 API 콜이 끼어 있다면, 그 결제는 x402가 처리한다.

3. Kaia의 방향: Adopt and Build

3.1 Kaia가 출발하는 위치

Kaia가 별도의 에이전트 표준을 반드시 새로 만들 필요는 없다. 초기 단계의 에이전트 경제가 필요로 하는 것은 체인별로 별도의 룰을 정의하는게 아니라, 공통 기반 인프라이기 때문이다.

대신 Kaia의 방향성은 이렇게 정리할 수 있다. 업계가 수렴하고 있는 공통 표준은 적극 채택(adopt)하고, Kaia의 환경이 우위를 만들 수 있는 지점에서는 직접 빌드(build)한다.

이 우위는 두 갈래로 나뉜다.

첫째는 아시아를 위한 스테이블코인 인프라다. 에이전트 커머스가 USDC 단독의 이야기로 끝나지는 않을 것이다. 아시아에서는 로컬 통화 스테이블코인이 중요해진다. KRW 스테이블코인, JPYC, 그 외 지역 자산은 단순한 대체 자산이 아니라, 에이전트 결제가 로컬 비즈니스, 로컬 사용자, 로컬 컴플라이언스 환경에서 실제로 작동하도록 만들어주는 도구다. 이 지역에서 에이전트가 서비스를 결제하고, 커머스를 정산하고, 기관과 상호작용하려면 정산 레이어가 그 지역의 통화를 말할 수 있어야 한다.

둘째는 메신저 슈퍼앱을 통한 디스트리뷰션이다. Kaia는 LINE, Kakao와 가까운 자리에 있다. 이는 에이전트가 실제로 쓰일 컨슈머/머천트 표면(surface)에 닿을 수 있는 현실적인 경로를 의미한다. 이 차이는 작지 않다. 우아한 에이전트 인프라를 가진 체인이라도 사용자에게 닿지 못하면 실패한다. 에이전트 커머스에는 라스트 마일이 필요하다. 사용자가 무언가를 요청하는 자리, 머천트가 응답하는 자리, 결제가 승인되거나 자동화되는 자리, 그리고 서비스가 전달되는 자리. 아시아에서 이 라스트 마일은 메시징과 슈퍼앱 표면을 통해 흐를 가능성이 가장 높다.

그래서 Kaia의 전략은 단순하다. 공통 에이전트 표준을 채택하고, 그것을 지역 스테이블코인과 메신저 네이티브 디스트리뷰션에 연결한다.

3.2 Adopt: ERC-8004, x402, ERC-8183

Kaia는 새로 떠오르는 표준들을 공통 인프라로 다뤄야 한다.

ERC-8004는 더 넓은 trustless agent 생태계와의 호환성을 목표로 한다. 에이전트는 다른 생태계가 인식할 수 있는 방식으로 Kaia 위에서 등록되고, 메타데이터를 노출하고, 평판을 쌓고, 검증을 요청할 수 있어야 한다. Kaia 위의 에이전트가 Kaia 전용 신원 모델 안에 갇혀선 안 된다. 신원과 평판은 함께 이동 가능해야 한다.

이는 개발자 입장에서도 중요하다. 이미 ERC-8004 레지스트리를 이해하는 에이전트 프레임워크가 있다면, Kaia 위에서의 배포 역시 익숙하게 느껴져야 한다. 체인이 바뀌었다는 이유만으로 에이전트 신원을 처음부터 다시 배워야 할 이유는 없다.

x402의 채택은 지역 스테이블코인을 중심에 두는 방향이어야 한다. 프로토콜 자체는 이미 여러 네트워크와 토큰 유형을 지원한다. Kaia가 추가로 풀어야 하는 일은 KRW 스테이블코인, JPYC, 그 외 의미 있는 아시아 스테이블코인이 x402 흐름 안에서 자연스러운 정산 자산이 되도록 만드는 것이다. 개발자가 유료 도구, 엔드포인트, 리소스의 가격을 지역 스테이블코인으로 매기기 위해 별도의 커스텀 결제 스택을 짤 필요가 없어야 한다.

여기에 미묘하지만 중요한 설계 질문이 따라온다. 프라이머리 자산(primary asset)을 무엇으로 둘 것인가. x402는 결제 금액을 명시적인 토큰 단위로 표현할 수 있지만, 개발자들은 단순한 가격 문자열과 합리적인 기본값을 선호한다. Kaia 입장에서 이 프라이머리 자산의 선택은 가볍지 않다. 기본값이 글로벌 달러 스테이블코인 하나뿐이라면, 기술적으로는 정확한 통합이지만 전략적으로는 미완성이다. 결제 레이어는 Kaia가 에이전트 커머스가 일어나리라 기대하는 지역의 통화를 반영해야 한다.

ERC-8183은 Kaia가 표준을 가까이서 추적하면서 그것이 안정화되는 흐름에 맞춰 지원해 나가야 할 영역이다. 이것이야말로 에이전트 결제를 에이전트 커머스로 확장시키는 조각이다. 유료 엔드포인트만으로는 부족하다. 많은 에이전트 워크플로우는 결과물, 에스크로, 타임아웃, 평가까지 함께 다뤄야 한다. ERC-8183은 그 흐름에 표준 형태를 부여한다.

이런 채택 자세 전반에서 Kaia가 견지해야 할 태도는 실용주의다. 공통 인프라가 되어가는 표준은 그대로 구현하고, 어휘를 포크하지 않으며, 강한 이유 없이 자체 표준을 만들지 않는다. 에이전트 경제는 이미 충분히 파편화된 채로 시작하고 있다. Kaia가 거기에 또 하나의 갈라파고스 섬을 만들 이유는 없다.

3.3 Build: Kaia Skills

첫 번째 빌드 레이어는 이미 완성 되었다. Kaia Skills다.

Kaia Skills는 Kaia 위에서 작업하는 AI 코딩 에이전트를 위한 스킬 파일 레포지토리다. 전제는 단순하다. LLM은 Kaia에 대해 자주 틀린다. Klaytn 시절의 단위를 그대로 기억하고 있다. 컨트랙트 주소를 잘못 만들어낸다. 프로토콜 레벨 수수료 위임(fee delegation)을 빼놓는다. 최근 KIP, 생태계 변경, Kaia 고유 트랜잭션 타입을 잘 모른다. 일반 문서 페이지는 사람을 위한 것이고, 에이전트에게는 작업 시점에 로드할 수 있는, 압축되고 타겟된 지식이 필요하다.

Kaia Skills는 그 목적에 맞게 설계되어 있다. 작업 방식은 리서치 우선이다. LLM이 무엇을 틀리는지를 감사하고, 정말 의미 있는 정정만 작성하고, 그 스킬이 실제로 모델 행동을 개선하는지를 평가한다. 문서를 복제한 결과물이 아니라, 에이전트 행동을 위한 정정 레이어(correction layer)다.

이 일이 첫인상보다 훨씬 큰 의미를 갖는 이유는 단순하다. 개발자가 AI 코딩 에이전트로 온체인 애플리케이션을 점점 더 많이 만들고 있다면, Kaia로의 첫 인터페이스는 더 이상 문서 페이지가 아니다. 그것은 에이전트가 가지고 있는 Kaia에 대한 내부 이해다. 그 이해가 낡으면 개발자는 깨진 코드, 잘못된 단위, 잘못된 주소, 잘못된 수수료 가정, 그리고 체인에 대한 부정적인 첫인상을 얻는다.

Kaia Skills는 이 문제를 인프라 문제로 다시 정의한다. AI 에이전트에게 Kaia 전용 개발을 위한, 유지 관리되는 지식 레이어를 제공한다. Kaia를 더 에이전트 네이티브하게 만드는 가장 즉각적인 방법은, Kaia 위에서 빌드하는 에이전트가 덜 틀리도록 만드는 것이다.

3.4 Build: Kaia AgentKit

다음 레이어는 Kaia AgentKit이다.

가장 가까운 비유는 Solana Agent Kit이다. 에이전트가 체인 함수와 생태계 프로토콜을 호출하기 위해 매번 통합 코드를 직접 짤 필요가 없게 만들어주는 툴킷이다. Kaia에도 같은 카테고리의 도구가 필요하다. 다만 단순한 복제판이 되어선 안 된다. Kaia 버전은 Kaia를 다르게 만드는 기능들 위에서 설계되어야 한다.

수수료 위임(fee delegation)이 그중 하나다. Kaia는 프로토콜 네이티브 수수료 위임을 지원한다. 즉, 애플리케이션은 외부 paymaster 패턴에만 의존하지 않고도 가스를 후원할 수 있다. 에이전트 관점에서 이게 중요한 이유는 분명하다. 새로 만들어진 에이전트는 네이티브 가스 토큰을 보유하고 있지 않을 가능성이 높고, 자기 첫 행동의 가스를 어느 계정이 부담해야 하는지조차 모를 수 있다. 수수료 위임은 서비스, 운영자, 혹은 애플리케이션이 에이전트를 대신해 트랜잭션 비용을 지불할 수 있게 한다.

가스 추상화(gas abstraction)도 같은 축이다. 에이전트의 운용 예산이 스테이블코인으로 보관되고 있다면, 거기에 네이티브 가스 재고 관리까지 강제로 얹는 것은 불필요한 마찰이다. 가스 추상화는 에이전트가 실제로 커머스에 사용하는 자산에 가까운 곳에서 동작할 수 있게 해준다. 에이전트 결제 맥락에서 이상적인 상태는 단순하다. 에이전트는 정산 자산만 보유하고, 그것으로 행동한다. 나머지 가스 처리는 인프라가 알아서 한다.

Kaia의 계정 모델 역시 중요한 요소다. Kaia는 단순한 Ethereum 클론보다 더 풍부한 계정과 트랜잭션 디자인을 가지고 있다. 강력하지만, 도구 레이어가 얇으면 에이전트가 실수할 수 있는 경로 또한 그만큼 늘어난다. Kaia AgentKit은 이런 흔한 실수 지점을 감추고, 의견이 분명한 흐름들을 드러내야 한다. 에이전트 지갑을 만들거나 연결하는 흐름, 범위가 제한된 권한을 설정하는 흐름, 수수료를 후원하는 흐름, x402로 결제하는 흐름, ERC-8004로 등록하는 흐름, ERC-8183 잡을 만들거나 수락하는 흐름, 그리고 Kaia의 주요 프로토콜과 상호작용하는 흐름이다.

목표는 표준 경로를 분명하게 만드는 것이다. 개발자가 에이전트를 Kaia 위에서 움직이고 싶을 때, AgentKit은 다음 실용적인 질문에 답할 수 있어야 한다. 에이전트가 자금을 어떻게 보유하는가, 어떻게 결제하는가, 어떻게 서명하는가, 가스 마찰을 어떻게 피하는가, 신원을 어떻게 노출하는가, 잡을 어떻게 정산하는가.

3.5 Build: 메신저 네이티브 에이전트 커머스

가장 긴 호흡의 빌드 레이어는 Kaia에게 가장 고유한 영역이다. 메신저 네이티브 에이전트 커머스.

대부분의 체인은 x402를 지원할 수 있다. 대부분의 EVM 체인은 ERC-8004를 채택할 수 있다. 그중 많은 곳에서 ERC-8183 컨트랙트를 배포할 수 있다. 결국 이것만으로는 차별화가 되지 않는다.

더 어려운 질문은 이것이다. 에이전트는 사용자를 어디에서 만나는가.

Kaia의 답은 LINE과 Kakao 표면이다. 에이전트가 일상의 커머스에서 유용해지는 단계에 들어서면, 이들이 늘 독립된 크립토 앱으로 등장하지는 않을 것이다. 채팅, 미니앱, 머천트 플로우, 고객 응대 채널, 커뮤니티 도구, 개인 비서 안에서 자연스럽게 나타날 가능성이 높다. 사용자는 자기 행동을 "블록체인 에이전트를 쓴다"고 인식하지 않을 수도 있다. 그저 이미 쓰고 있는 앱 안에서 무언가를 요청하고, 승인하고, 받아본다.

여기서 Kaia의 메신저 연결이 의미를 갖는다. 표준은 에이전트에게 공통의 경제 스택을 제공한다. Kaia는 그 위에 지역 디스트리뷰션 표면을 얹을 수 있다.

흐름은 단순하게 그릴 수 있다. 사용자가 메신저 앱 안에서 에이전트에게 어떤 서비스를 찾아 구매해 달라고 요청한다. 에이전트는 x402로 유료 도구를 호출한다. 공급자의 평판은 ERC-8004로 확인한다. 서비스가 결과물 기반 작업을 요구하면 ERC-8183 에스크로를 생성한다. 정산은 지역 스테이블코인으로 처리된다. 사용자가 보는 것은 메신저 안의 깔끔한 경험이고, 그 아래에서 에이전트 스택이 신원, 결제, 정산을 처리한다.

이건 한 개의 컨트랙트로 환원될 수 없는 종류의 문제다. 지갑, 스테이블코인, 메시징, 결제 권한, 개발자 도구, 표준이 함께 맞물려야 한다. 그래서 일반적인 L1이 쉽게 따라 하기 어려운 영역이기도 하다.

Kaia가 해야 할 역할은 이 경로를 빌더에게 실제로 가능하게 만드는 것이다. 공통 표준은 아래에, Kaia 네이티브 도구 레이어는 가운데에, 메신저 디스트리뷰션은 가장자리에.

3.6 왜 Adopt and Build가 올바른 방향인가

Kaia가 채택만 한다면, 에이전트 스택 안에서 또 하나의 호환 체인으로 머무는 데 그친다. 호환성은 필요조건이지 충분조건은 아니다. 호환성은 에이전트에게 "Kaia를 굳이 피할 이유가 없다"는 정도만 제공한다. "Kaia를 굳이 선택할 이유"를 만들어주지는 않는다.

반대로 Kaia가 독점적인 에이전트 도구만 빌드한다면, 고립의 리스크가 생긴다. 생태계 전체가 공유된 프리미티브를 향해 움직이는 동안, 개발자들에게 Kaia 전용 신원 모델, Kaia 전용 결제 프로토콜, Kaia 전용 커머스 표준을 새로 배우라고 강요할 이유는 없다.

답은 둘 다다. 신원, 결제, 커머스의 공통 표준은 채택하고, Kaia가 실제로 우위를 가진 지점, 즉 지역 스테이블코인 정산, 프로토콜 레벨 수수료 위임과 가스 추상화, Kaia 고유 에이전트 도구, 메신저 네이티브 디스트리뷰션에서는 직접 빌드한다.

마치며

에이전트 경제는 아직 초기다. 지금 진지하게 진행되어야 할 작업은 또 하나의 에이전트 토큰을 발행하거나, 또 하나의 챗봇 데모를 만드는 일이 아니다. 에이전트가 실제 경제 주체가 되기 전에, 그들이 필요로 할 레일을 정의하는 일이다.

ERC-8004는 에이전트에게 신원, 평판, 검증을 부여한다. x402는 인터넷을 따라 흐르는 결제 경로를 제공한다. ERC-8183은 커머스를 위한 잡과 에스크로 모델을 제공한다. 이 표준들은 아직 어리지만, 가리키는 방향은 같다. 에이전트에게는 오픈된 경제 인프라가 필요하고, 블록체인은 그 인프라가 정의되고 있는 장소 중 하나가 되어가고 있다.

Kaia의 역할은 별도의 우주를 새로 만드는 것이 아니다. 의미 있는 표준을 도입하고, 그것을 Kaia가 가장 잘 서비스할 수 있는 시장에서 유용하게 만드는 일이다.

그것은 에이전트 결제를 달러 단일 시각으로만 다루지 않는다는 의미다. AI 에이전트가 Kaia 위에서 올바르게 빌드하고 동작할 수 있도록 Kaia Skills와 Kaia AgentKit이 자리잡아야 한다는 의미다. 그리고 시간이 흐르면서 아시아의 사용자와 머천트가 이미 살고 있는 LINE과 Kakao 표면 위로 에이전트를 연결한다는 의미다.

인터넷의 첫 번째 단계는 사람들이 읽고 클릭하기 위해 설계되었다. 다음 단계는 그 사람들을 대신해 협상하고, 결제하고, 작업을 완료하는 에이전트들을 포함하게 될 가능성이 높다. 만약 그렇게 된다면, 유용한 체인은 에이전트에게 단순한 실행을 넘어 경제적 주체를 함께 제공하는 체인일 것이다.

Kaia는 새로운 버전의 사용자 레이어를 향해 나아가고 있다.