ERC-8004란? Ethereum에서 trustless agent가 작동하는 방식
작성자 Uttam Singh

ERC-8004, "Trustless Agents"라는 제목의 이 표준은 AI 에이전트에게 온체인 신원, 공개 평판 기록, 그리고 작업을 검증받을 수 있는 방법을 제공하는 Ethereum 표준으로, 사전 신뢰 관계 없이도 조직 간 거래를 가능하게 한다. 이 가이드는 세 개의 레지스트리가 어떻게 작동하는지, 오늘날 메인넷에 실제로 배포된 것은 무엇인지, 이 표준이 A2A, MCP, x402와 어떻게 맞물리는지, 그리고 이를 기반으로 구축하기 전에 주의해야 할 점은 무엇인지 다룬다.
ERC-8004란 무엇인가?
ERC-8004는 2025년 8월 MetaMask, Ethereum Foundation, Google, Coinbase 소속 저자들에 의해 제안되었으며, 세 개의 레지스트리를 정의한다. Identity Registry는 에이전트가 누구인지를 기록한다. Reputation Registry는 클라이언트들이 그 에이전트에 대해 뭐라고 말하는지를 기록한다. Validation Registry는 독립적인 검증자들이 그 작업을 확인했는지를 기록한다.
스펙은 신뢰가 하나의 형태로 통일될 수 없다는 점을 명시한다. 스펙의 표현을 빌리면, 신뢰 모델은 "피자 주문 같은 저위험 작업부터 의료 진단 같은 고위험 작업까지, 위험에 노출된 가치에 비례하는 보안을 갖춘 플러그형, 계층형" 구조다. 저녁 예약을 하는 에이전트는 평판 점수에 의존할 수 있다. 자산을 관리하는 에이전트는 자금이 걸린 누군가에 의해 작업이 재검증되어야 한다.
AI 에이전트에게 신뢰 계층이 왜 필요한가?
오늘날 사용하는 모든 신뢰 시스템은 중간에 플랫폼이 있다고 가정한다. 마켓플레이스 리뷰는 한 회사의 데이터베이스에 존재한다. 지불 취소(chargeback)는 카드 네트워크가 구매자와 판매자 사이에 있기 때문에 존재한다. OAuth 로그인은 대형 신원 제공자가 당신을 보증하기 때문에 작동한다. 이 모델은 공유된 운영자 없이 여러 회사, 클라우드, 관할권을 넘나들도록 만들어진 자율 에이전트에는 적용되지 않는다.
에이전트 스택의 나머지 부분은 이 공백을 메워왔다. Model Context Protocol(MCP)은 에이전트를 도구와 데이터 소스에 연결한다. Google이 시작한 Agent2Agent(A2A)는 에이전트들이 서로를 찾고 구조화된 메시지를 교환하도록 한다. x402는 에이전트들이 일반 HTTP를 통해 서비스 비용을 지불하도록 한다. 이들 각각은 어떤 상대방과 거래할지 이미 결정했다고 가정한다. 그 결정을 내리는 데 도움을 주는 것은 없다.
바로 그것이 ERC-8004가 맡는 역할이며, 레지스트리가 누군가의 데이터베이스가 아니라 블록체인에 존재하는 이유다. 실행 장소를 선택하는 DeFi 에이전트, 데이터 라벨링 에이전트를 고용하는 리서치 에이전트, 그리고 알지 못하는 구매자에게 서비스를 제공할지 결정하는 판매자 모두 동일한 세 가지 조회가 필요하다. 이 에이전트는 누구인가? 다른 이들과 거래했을 때 무슨 일이 있었는가? 그 결과물을 누군가 검증했는가? ERC-8004는 이러한 답을 어느 한쪽도 통제하지 않는 곳, 모든 에이전트가 읽을 수 있는 하나의 스키마 안에 둔다.
ERC-8004 Identity Registry는 어떻게 작동하는가?
등록된 각 에이전트는 NFT의 기반이 되는 것과 동일한 표준인 ERC-721 토큰이다. 등록은 Identity Registry에서 register()을 호출하며, 그 ID가 에이전트의 번호가 되는 토큰을 발행한다. 에이전트의 전체 식별자는 체인과 레지스트리 주소를 그 ID와 결합하므로, "Base의 에이전트 4,205"는 전 세계적으로 모호하지 않다.
토큰의 URI는 IPFS, HTTPS에 호스팅되거나 온체인에 직접 임베드된 등록 파일을 가리키며, 이 파일은 에이전트가 무엇인지와 어떻게 연락할 수 있는지를 설명한다. 축약된 등록 파일은 다음과 같다:
{
"type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
"name": "Research Agent",
"description": "Fetches and summarizes onchain data on request",
"image": "ipfs://<image-hash>",
"services": [
{ "name": "A2A", "endpoint": "https://agent.example/a2a" },
{ "name": "MCP", "endpoint": "https://agent.example/mcp" }
],
"supportedTrust": ["reputation", "tee-attestation"]
}services 배열은 디스커버리 페이로드다. 이는 A2A, MCP, ENS 이름, 탈중앙화 식별자를 포함해 에이전트가 사용하는 모든 프로토콜에 걸친 실제 엔드포인트를 알린다. supportedTrust 필드는 에이전트가 채택하는 신뢰 모델을 선언한다. 스펙에 따르면 이 필드가 없으면 해당 등록은 디스커버리 용도로만 사용된다.
ERC-721 위에 구축하면 많은 것을 거저 얻는다. 소유권, 이전, 위임이 이미 작동하고, 지갑과 마켓플레이스가 이미 해당 토큰을 렌더링하며, 생태계의 툴링이 그대로 적용된다. 레지스트리는 또한 신원과 일상적으로 작동하는 키를 분리한다. setAgentWallet은 서명된 승인을 통해 작동 지갑을 에이전트에 연결하므로, 신원 토큰의 소유자와 거래에 서명하는 지갑이 서로 다른 파급 범위를 가진 다른 키일 수 있다. 이는 에이전트에게 지갑을 부여할 때 우리가 권장하는 것과 동일한 분리로, 에이전트는 원시 개인 키 대신 범위가 제한되고 시간 제한이 있는 서명 권한을 갖는다.
ERC-8004 Reputation Registry는 어떻게 작동하는가?
어떤 주소든 Reputation Registry에서 giveFeedback를 호출해 어떤 에이전트든 평가할 수 있다. 피드백 항목은 구성 가능한 소수점 자릿수를 가진 부호 있는 숫자 값을 담고 있어, 거친 1~5점 대신 음수와 정밀한 점수를 가질 수 있으며, 필터링을 위한 최대 두 개의 태그와 해시로 커밋되어 온체인에 기록되는 더 풍부한 오프체인 글을 가리키는 선택적 URI를 포함한다. 유일한 강제 제약은 에이전트의 소유자와 운영자가 자신의 에이전트를 평가할 수 없다는 것이다.
함수 시그니처보다 더 중요한 두 가지 설계 선택이 있다. 첫째, 클라이언트는 어디에도 등록하지 않으므로 피드백을 남기는 진입장벽이 제로에 가깝고, 서비스가 사용자의 리뷰를 위한 가스를 대신 지불할 수 있다. 둘째, 레지스트리는 의도적으로 정규 점수를 계산하지 않는다. 원시 신호를 저장하고, 요약 및 조회 함수를 제공하며, 해석은 그것을 조회하는 쪽에 맡긴다. 이 제안에 대한 초기 논의에서는 단일 집계 평판 숫자가 독점 역학과 조작을 유발한다는 주장이 있었고, 그래서 점수 산정은 인덱서 계층에서 이루어지며, 서로 다른 소비자가 동일한 데이터를 다르게 가중할 수 있다.
오프체인 피드백 파일이 리뷰에 실질적인 무게를 싣는 부분이다. 이 파일은 상호작용에 사용된 정확한 MCP 도구나 A2A 작업을 참조할 수 있고, x402 결제의 증거를 임베드해 리뷰를 검증 가능하게 발생한 거래와 연결할 수 있다. 결제 영수증으로 뒷받침되는 리뷰는 익명 지갑의 단순한 점수보다 훨씬 강력한 신호이며, 정확히 그런 유형의 리뷰를 필터링하는 것이 레지스트리를 진지하게 활용하는 소비자가 사용해야 할 방식이다.
ERC-8004 Validation Registry는 어떻게 작동하는가?
피드백 점수는 과거 클라이언트가 무엇을 생각했는지를 알려준다. 더 가치가 큰 작업의 경우 그것만으로는 충분하지 않으며, 결과물 자체를 확인해야 한다. Validation Registry는 에이전트가 지정된 검증자에게 특정 작업물을 확인해 달라고 요청할 수 있게 한다: validationRequest는 검증자, 에이전트, 그리고 작업물을 가리키는 해시 커밋 포인터를 기록하며, 검증자는 validationResponse으로 응답해 결과를 0에서 100 사이로 점수화하고 자체 해시 커밋 증거를 제공한다.
"확인"이 무엇을 의미하는지는 검증자에 따라 다르다. 검증자는 작업을 재실행하고 결과물을 비교할 수 있으며, 부정직하게 증명하면 손실되는 지분을 가질 수 있다. 에이전트가 신뢰 실행 환경(TEE, 실행한 코드를 증명할 수 있는 하드웨어) 안에서 실행되었음을 증명할 수도 있다. 영지식 머신러닝 증명(zkML, 특정 모델이 특정 출력을 만들었다는 암호학적 증명)을 검증할 수도 있다. 레지스트리는 어떤 방식인지 신경 쓰지 않으며, 요청과 응답의 배관만 표준화한다.
거의 어떤 보도에서도 언급되지 않는 현재 상태에 대한 한 가지 유의사항이 있다. 공식 멀티체인 배포는 Identity와 Reputation 레지스트리를 포함하지만, Validation Registry는 TEE 커뮤니티와 함께 재작업하기 위해 보류되었고 오늘날 공식 메인넷 세트에는 포함되지 않는다. 지금 검증이 필요한 팀들은 ERC-8004 신원과 자체 검증 가능한 컴퓨트를 결합한 EigenCloud의 trustless agents 통합 같은 특정 제공자를 통해 이를 연결한다. 이를 기반으로 구축하기 전에 공식 컨트랙트 저장소에서 배포 현황을 확인하라.
에이전트는 어떤 신뢰 모델을 사용해야 하는가?
스펙의 위험 노출 가치 기준의 프레이밍은 상당히 명확한 결정 규칙으로 이어진다. 검증 비용을 틀렸을 때의 비용에 맞춰라.
이 모델들은 함께 쌓일 수도 있다. 프로덕션 에이전트는 TEE 안에서 실행되고, 평판 이력을 가지고 있으며, 가치가 큰 결과물을 스테이크된 재실행을 위해 제출하면서, 이 세 가지 신호를 모두 동일한 supportedTrust 선언을 통해 제시할 수 있다.
ERC-8004, A2A, MCP, x402는 어떻게 맞물리는가?

에이전트 스택은 네 개의 다른 소유자를 가진 네 개의 계층으로 이해하는 것이 가장 쉽다. Anthropic의 MCP는 에이전트를 도구와 컨텍스트에 연결한다. Google이 시작한 A2A는 에이전트 간 디스커버리와 메시징을 처리한다. Coinbase가 주도하는 x402는 자금을 이동시키며, 여러 경쟁하는 에이전트 결제 프로토콜 중 하나다. ERC-8004는 신뢰를 고정하며, 신원과 평판이 어떤 상대방도 통제하지 않을 때만 유용하기 때문에 의도적으로 블록체인 위에 존재하는 유일한 계층이다.
하나의 상호작용이 이 네 가지 모두에 걸칠 수 있다. 구매자 에이전트는 필요한 기술을 광고하는 에이전트를 찾기 위해 Identity Registry를 조회하고, 후보의 등록 파일을 가져오며, 그 평판 요약과 검증 내역을 확인한다. 작업을 협상하기 위해 A2A 세션을 열거나, 판매자의 MCP 엔드포인트를 직접 호출한다. 판매자가 돌려준 x402 청구서를 지불한다. 작업이 완료되면 결제 참조와 함께 giveFeedback을 호출하고, 판매자의 다음 잠재 고객은 영수증이 첨부된 리뷰를 보게 된다.
스택의 어떤 것도 전체 루프를 요구하지 않는다. 팀들은 ERC-8004 없이 x402를 채택하고, 검증을 전혀 요청하지 않고 신원을 등록한다. 하지만 이 계층들은 서로를 참조하도록 설계되었다. 등록 파일은 A2A와 MCP 엔드포인트를 나열하고, 피드백 파일은 x402 영수증을 임베드하므로, 이들을 조합하는 데는 접착 코드가 아니라 설정만 필요하다.
ERC-8004를 기반으로 어떻게 구축하는가?
레지스트리는 일반적인 컨트랙트이므로 이를 읽는 데 특별한 툴링이 필요하지 않다. 신원 조회는 ERC-721 호출이고, 모든 레지스트리는 인덱싱할 수 있는 이벤트를 발생시킨다. 우리는 주요 배포 체인을 모두 지원하므로, 표준 RPC 엔드포인트만 있으면 시작할 수 있다. 에이전트의 등록 파일을 가져오는 데는 한 번의 읽기면 충분하다:
import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";
const client = createPublicClient({
chain: mainnet,
transport: http("https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"),
});
// The Identity Registry is an ERC-721; tokenURI returns the agent's registration file URI
const agentURI = await client.readContract({
address: "0x8004A169FB4a3325136EB29fA0ceB6D2e539a432",
abi: [
{
name: "tokenURI",
type: "function",
stateMutability: "view",
inputs: [{ name: "tokenId", type: "uint256" }],
outputs: [{ type: "string" }],
},
],
functionName: "tokenURI",
args: [1n],
});여기서부터는 이미 운영 중일 가능성이 높은 인프라에 매핑된다. 웹훅은 새로운 등록과 피드백 이벤트를 폴링 대신 푸시로 전환하며, 이러한 이벤트를 중심으로 루프를 구성하는 방법은 온체인 AI 에이전트 아키텍처 가이드에서 다룬다. 에이전트의 운영 지갑은 원시 키가 아니라 범위가 제한된 서명자여야 하며, 이 패턴은 온체인 에이전트 가이드에서 처음부터 끝까지 다룬다. 그리고 에이전트는 신원으로 지갑을 사용해 우리 플랫폼에 자체적으로 가입하고 x402를 통해 호출당 비용을 지불할 수 있으므로, 자신의 인프라 관계를 자율적으로 운영할 수 있다. 사람이 개입할 필요가 없다. 코딩 에이전트로 구축한다면, Claude Code용 Alchemy 플러그인이 우리의 MCP 서버와 스킬을 하나의 설치로 묶어준다.
레지스트리 아래에서 ERC-8004 에이전트가 하는 모든 일, 즉 체인 상태 읽기, 이벤트 감시, 트랜잭션 서명, 자체 API 사용에 대한 비용 지불은 에이전트를 일급 사용자로 대우하도록 우리가 구축한 인프라 위에서 실행된다. Alchemy CLI를 통해 무료 엔드포인트를 받거나, 에이전트가 스스로 온보딩하게 하라. API 키 전달도, 계약도, 사람이 필요한 가입 절차의 그 어떤 단계도 없다.
ERC-8004의 한계는 무엇인가?
이 표준은 아직 초기 단계이며, 그 날카로운 문제들은 자체 논의 스레드에 문서화되어 있다. 설계에 영향을 미쳐야 할 것들은 다음과 같다:
- 시빌 피드백은 저렴하다. 지갑은 아무 비용도 들지 않으므로 원시 평판 점수는 쉽게 조작된다. 알려진 클라이언트나 결제 증명으로 필터링된 피드백만 소비하고, 필터링되지 않은 평균은 절대 사용하지 마라.
- 신원은 이전 가능하다. 에이전트 신원은 표준 ERC-721이므로, 깨끗한 이력을 가진 오래된 신원을 판매할 수 있고, 그 평판도 함께 따라간다. 이력을 신뢰하기 전에 소유권 변경을 추적하라.
- 점수는 시간이 지나면 나빠진다. 에이전트는 확률적이며, 모델 업데이트로 하룻밤 사이에 행동이 바뀔 수 있으므로, 지난달의 피드백은 지난달의 에이전트를 설명할 뿐이다.
- 평판은 한 체인에만 머무른다. Base에 등록된 에이전트는 Arbitrum에서는 처음부터 시작한다. 크로스체인 집계는 이 표준이 아직 해결하지 못한 인덱서 문제다.
- 인터페이스는 아직 변경될 수 있다. 이 표준은 여전히 초안 상태이며 이미 한 번 재설계되었다. 통합은 배포된 컨트랙트에 고정하고, 더 새로운 표면에 의존하기 전에 스펙을 지켜보라.
이 중 어느 것도 이 표준의 실제 주장을 무너뜨리지 않는다. 그 주장은 온체인 평판이 위조 불가능하다는 것이 아니었다. 그 주장은 에이전트 신뢰 신호가 개별 사설 데이터베이스에 흩어져 있는 대신 공개적이고 공유되며 무허가인 스키마에 속해야 한다는 것이다. 그 주장을 기준으로 보면, 이는 이미 실행 중이며 실제 시스템들이 이미 읽고 있다.
자주 묻는 질문
ERC-8004란 무엇이며 신뢰 없는(trustless) AI 에이전트를 어떻게 가능하게 하는가?
ERC-8004는 신원, 평판, 검증을 다루는 세 개의 레지스트리를 통해 AI 에이전트를 온체인에 등록하는 Ethereum 표준이다. 에이전트는 ERC-721 토큰으로 이식 가능하고 검증 가능한 신원을 얻고, 클라이언트는 피드백을 공개적으로 게시하며, 검증자는 작업 품질을 증명하므로, 에이전트들은 사전 신뢰 관계 없이도 조직 간 거래를 할 수 있다.
ERC-8004는 메인넷에서 라이브인가?
그렇다. Identity와 Reputation 레지스트리는 2026년 1월부터 Ethereum 메인넷에서 운영되고 있으며 20개 이상의 네트워크에서 동일한 주소로 배포되어 있다.
ERC-8004에 토큰이 있는가?
없다. ERC-8004는 토큰이 있는 프로젝트가 아니라 스마트 컨트랙트 표준이다. 에이전트를 등록하면 해당 에이전트에 특화된 ERC-721 신원 토큰이 발행되지만, 대체 가능한 ERC-8004 자산은 존재하지 않으며, 그런 것으로 마케팅되는 것은 이 표준과 무관하다.
ERC-8004 에이전트 신원을 판매할 수 있는가?
그렇다. 에이전트 신원은 표준 ERC-721 토큰이므로 일반 NFT처럼 이전되며, 누적된 평판도 토큰과 함께 이동한다. 이는 소유권 이력을 실사(due diligence)의 일부로 만드는데, 깨끗한 평판이 현재 운영자가 직접 쌓은 것이 아니라 구매된 것일 수 있기 때문이다.
어떤 체인이 ERC-8004를 지원하는가?
공식 레지스트리는 Ethereum, Base, Arbitrum, Optimism, Polygon, BSC, Monad를 포함한 20개 이상의 EVM 네트워크에서 동일한 주소로 배포되어 있다. Alchemy는 이러한 체인 전반에 걸쳐 RPC와 데이터 API를 제공하므로, 에이전트는 배포된 어디에서든 레지스트리를 읽고 쓸 수 있다.
ERC-8004는 x402 및 A2A와 어떻게 다른가?
이들은 동일한 스택의 서로 다른 계층을 해결한다. A2A는 에이전트들이 서로를 찾고 메시지를 주고받는 방법을 처리하고, x402는 HTTP를 통해 서로 결제하는 방법을 처리하며, ERC-8004는 신원, 평판, 검증 기록을 온체인에 고정함으로써 서로를 신뢰해야 하는지를 처리한다. 프로덕션 에이전트 시스템은 일반적으로 이 세 가지를 모두 결합해 사용한다.
관련 개요
인프라2026년 9월 2일
온체인 AI 에이전트 아키텍처: 다섯 가지 빌드 패턴
온체인 AI 에이전트를 위한 다섯 가지 빌드 패턴과 각각의 예제: wallet watcher, 이벤트 기반 reactor, 포트폴리오 리밸런서, detect-then-execute 멀티 에이전트 분할, 메인넷 배포 전 안전한 테스트.
DeFi2026년 6월 12일
DeFi AI 에이전트란? 사용 사례, 리스크, 아키텍처
DeFi AI 에이전트, 일명 DeFAI 에이전트는 정책 통제 하에 온체인에서 추론, 서명, 정산을 수행하는 자율 시스템입니다.
금융2026년 6월 24일
에이전트 결제란? AI 에이전트가 API, 데이터, 컴퓨팅 비용을 지불하는 방법
에이전트 결제를 통해 AI 에이전트는 API, 데이터, 컴퓨팅 등 필요한 항목의 비용을 제한된 범위 내에서 자율적으로 지불할 수 있습니다. 작동 방식과 실제 에이전트 워크플로우에서 중요한 이유를 알아보세요.

블록체인 매직을 만드세요
Alchemy는 가장 강력한 Web3 개발자 제품 및 도구를 리소스, 커뮤니티, 그리고 전설적인 지원과 결합합니다.