ERC-8183: AI 에이전트가 서로를 고용할 수 있게 해주는 표준 — 인간의 개입이 필요 없습니다
AI 에이전트가 로고 디자인, 데이터 세트 정제, 또는 스마트 컨트랙트 감사를 필요로 하는데 그 과정에 인간이 개입하지 않는다면 어떤 일이 벌어질까요? 2026년 2월 전까지 그 답변은 "표준화된 것이 아무것도 없다"는 것이었습니다. 모든 에이전트 간 거래는 맞춤형 통합, 중앙 집중식 중개자 또는 단순한 신뢰에 의존했습니다. ERC-8183은 자율 에이전트가 온체인에서 완전히 작업을 게시하고, 자금을 에스크로하며, 결과물을 검증할 수 있는 이더리움 네이티브 상거래 레이어를 제공함으로써 이를 변화시킵니다.
Virtuals Protocol과 이더리움 재단(Ethereum Foundation)의 dAI 팀이 공동 개발한 ERC-8183은 상업적 거래의 전체 수명 주기를 4가지 상태로 인코딩하는 단일 프리미티브인 **작업 (Job)**을 도입합니다. 에이전트 정체성을 위한 ERC-8004 및 HTTP 네이티브 결제를 위한 x402와 결합하여, 110억 달러 규모의 에이전트 기반 AI 경제가 실제로 거래되는 방식을 정의할 수 있는 3부작 스택을 완성합니다.
문제점: AI 에이전트는 생각할 수 있지만, 거래할 수는 없습니다
2025년과 2026년 자율 AI 에이전트의 폭발적인 성장은 놀라웠습니다. 2025년에만 282개 이상의 Web3 AI 프로젝트가 투자를 받았으며, 에이전트 기반 AI 시장은 2026년 초에 100억 달러를 넘어섰습니다. 이제 에이전트는 DeFi 포지션을 관리하고, 콘텐츠를 생성하며, 온체인 데이터를 분석하고, Coinbase Agentic Wallets와 같은 서비스를 통해 자체 지갑을 운영할 수도 있습니다.
하지만 에이전트 간의 상거래는 여전히 원시적인 수준에 머물러 있습니다. 한 에이전트가 다른 에이전트의 서비스(예: 시장 심리를 요약하기 위해 자연어 연구 에이전트가 필요한 트레이딩 봇)를 필요로 할 때, 상호작용을 위해서는 일반적으로 인간이 거래를 중개하고, 결제를 설정하며, 결과물을 확인해야 합니다. 이러한 병목 현상은 다음과 같은 공유 표준이 없었기 때문에 발생했습니다.
- 작업 정의 (Job definition): 어떤 작업이 수행되어야 하며, 무엇을 완료로 간주하는가?
- 결제 에스크로 (Payment escrow): 자금이 어떻게 신뢰 없이 (trustlessly) 잠기고 해제되는가?
- 결과 검증 (Outcome verification): 인도물이 사양을 충족하는지 누가 결정하는가?
ERC-8183은 최소한의 구성 가능한 프로토콜로 이 세 가지 문제를 모두 해결합니다.
ERC-8183 내부: 작업 (Job) 프리미티브
핵심적으로 ERC-8183은 3명의 참여자와 4가지 상태를 가진 단일 데이터 구조인 **작업 (Job)**을 정의합니다.
세 가지 역할
모든 작업에는 세 가지 블록체인 주소가 포함됩니다.
- 클라이언트 (Client): 작업을 요청하고 에스크로 자금을 제공하는 에이전트(또는 인간)
- 공급자 (Provider): 작업을 수행하는 에이전트
- 평가자 (Evaluator): 인도물을 수락하거나 거부할 책임이 있는 주소
평가자 역할은 의도적으로 유연하게 설계되었습니다. 인간 검토자, 또 다른 AI 에이전트, 멀티시그 지갑, 결정론적 검증을 수행하는 스마트 컨트랙트, 또는 모델의 내부를 공개하지 않고도 결과물의 품질을 암호학적으로 증명하는 zkML 검증자가 될 수 있습니다.
네 가지 상태
작업은 엄격한 수명 주기를 거칩니다.
- Open (개시) → 클라이언트가 사양과 마감 기한을 포함하여 작업을 생성합니다.
- Funded (자금 예치) → 클라이언트가 온체인 에스크로 컨트랙트에 결제 대금을 예치합니다.
- Submitted (제출) → 공급자가 작업을 완료하고 작업을 제출된 상태로 표시합니다.
- Terminal (종료) → 평가자가 수락(공급자에게 자금 지급), 거부(클라이언트에게 환불), 또는 마감 기한 만료(자동 환불) 상태가 됩니다.
이 상태 머신은 의도적으로 단순합니다. 기본 레이어에는 협상 단계도, 부분 결제도, 분쟁 해결 기능도 내장되어 있지 않습니다. 이러한 단순함이 핵심입니다. ERC-8183은 훅 (hooks)을 통해 확장할 수 있는 최소한의 커널로 설계되었습니다.
훅 (Hooks): 모듈식 확장성
이 표준은 상태 전환 시 실행되는 프로그래밍 가능한 훅을 도입합니다. 개발자는 다음과 같은 맞춤형 로직을 추가할 수 있습니다.
- 입찰 시스템: 하나가 선택되기 전에 여러 공급자가 Open 작업에 입찰할 수 있습니다.
- 평판 게이팅: 최소 ERC-8004 평판 점수를 가진 에이전트만 특정 작업을 청구할 수 있습니다.
- 마일스톤 결제: 큰 작업을 자금이 지원되는 하위 작업으로 나눕니다.
- 에스크로 변형: 타임락 (time-lock) 해제, 스트리밍 결제 또는 성과 기반 보너스.
이러한 훅 아키텍처는 ERC-8183이 완전한 마켓플레이스 프로토콜이 되려고 하지 않음을 의미합니다. 대신, 마켓플레이스 프로토콜이 그 위에 구축될 수 있는 신뢰 없는 정산 레이어를 제공합니다.
삼인조: ERC-8004 + x402 + ERC-8183
ERC-8183은 독립적으로 존재하지 않습니다. 이는 자율 에이전트 상거래의 전체 수명 주기를 아우르는 세 가지 표준 스택을 완성합니다.
ERC-8004: 정체성 및 평판
2026년 1월 이더리움 메인넷에 출시된 ERC-8004는 세 가지 레지스트리를 통해 모든 AI 에이전트에게 지속적인 온체인 정체성을 부여합니다.
- 정체성 레지스트리 (Identity Registry): 에이전트의 등록 파일로 확인되는 ERC-721 기반 핸들로, 이식 가능하고 검열 저항적인 식별자입니다.
- 평판 레지스트리 (Reputation Registry): 완료된 거래에서 피드백 신호를 게시하고 가져오기 위한 표준 인터페이스입니다.
- 검증 레지스트리 (Validation Registry): 독립적인 검증 체크(작업을 재실행하는 스테이커, zkML 검증자, TEE 오라 클)를 위한 훅입니다.
ERC-8183과의 연결은 직접적입니다. 완료된 모든 작업 (Job)은 에이전트의 ERC-8004 프로필로 유입되는 평판 데이터를 생성합니다. 시간이 지남에 따라 에이전트는 다른 에이전트가 상업적 관계를 맺기 전에 쿼리할 수 있는 검증 가능한 실적을 쌓게 됩니다. 이는 중앙 집중식 평판 플랫폼 없이도 신뢰 레이어를 생성합니다.
x402: HTTP 네이티브 결제 레일
ERC-8183이 작업 수준의 에스크로를 처리하는 동안, Coinbase가 개발하고 Stripe, Cloudflare, Google, Vercel이 채택한 x402 프로토콜은 HTTP 계층에서 결제 처리 구조를 담당합니다.
x402는 오랫동안 사용되지 않았던 HTTP 402 "Payment Required" 상태 코드를 부활시킵니다. AI 에이전트가 API 엔드포인트를 요청하면, 서버는 가격, 통화 (일반적으로 USDC) 및 대상 지갑 주소가 포함된 402 상태로 응답합니다. 에이전트의 지갑은 자동으로 결제에 서명하고 제출하며, 서버는 리소스를 전달합니다.
2025년 중반 Solana에서 출시된 이후, x402는 3,500만 건 이상의 트랜잭션과 1,000만 달러의 거래량을 처리했습니다. 이 프로토콜은 기존 결제 시스템에서는 비경제적이었을 마이크로페이먼트 — 1센트 미만의 API 호출, 쿼리당 데이터 수수료, 컴퓨팅 시간 기반 과금 — 분야에서 탁월한 성능을 발휘합니다.
이 세 가지 표준은 함께 완전한 스택을 구성합니다:
| 계층 | 표준 | 기능 |
|---|---|---|