ERC-8004란 무엇인가요? Ethereum 트러스트리스 에이전트의 작동 방식
작성자 Uttam Singh

ERC-8004는 Trustless Agents(트러스트리스 에이전트)라는 제목의 Ethereum 표준으로, AI 에이전트에게 온체인 신원, 공개 평판 기록, 그리고 작업을 검증받을 수 있는 방법을 제공하여, 사전에 형성된 신뢰 없이도 조직 간에 거래할 수 있게 합니다. 이 가이드에서는 세 가지 레지스트리가 작동하는 방식, 오늘날 메인넷에 실제로 배포된 것, 이 표준이 A2A, MCP, x402와 어떻게 맞물리는지, 그리고 이를 기반으로 구축하기 전에 주의해야 할 점을 다룹니다.
ERC-8004란 무엇인가요?
ERC-8004는 2025년 8월 MetaMask, Ethereum Foundation, Google, Coinbase 소속 저자들이 제안했으며, 세 가지 레지스트리를 정의합니다. Identity Registry(신원 레지스트리)는 에이전트가 누구인지 기록합니다. Reputation Registry(평판 레지스트리)는 클라이언트들이 그 에이전트에 대해 어떻게 평가하는지 기록합니다. Validation Registry(검증 레지스트리)는 독립적인 검증자가 그 작업을 확인했는지 기록합니다.
명세는 신뢰가 획일적이지 않다는 점을 명시합니다. 명세의 표현을 빌리면, 신뢰 모델은 "피자 주문 같은 저위험 작업부터 의료 진단 같은 고위험 작업까지, 위험에 노출된 가치에 비례하는 보안을 갖춘 플러그형·계층형" 구조입니다. 저녁 식사 예약을 잡는 에이전트는 평판 점수에 의지해도 됩니다. 트레저리를 관리하는 에이전트는 자금을 건 누군가가 그 작업을 재검증해야 합니다.
AI 에이전트에게 신뢰 레이어가 필요한 이유는 무엇인가요?
오늘날 여러분이 사용하는 모든 신뢰 시스템은 중간에 플랫폼이 있다고 가정합니다. 마켓플레이스 리뷰는 한 회사의 데이터베이스에 저장됩니다. 지불 거절(차지백)은 구매자와 판매자 사이에 카드 네트워크가 있기 때문에 존재합니다. OAuth 로그인은 대형 신원 제공자가 여러분을 보증하기 때문에 작동합니다. 이 모델은 자율 에이전트에게는 통하지 않습니다. 자율 에이전트는 공유 운영자 없이 회사, 클라우드, 관할권을 넘나들며 작동하도록 만들어졌기 때문입니다.
에이전트 스택의 나머지 부분은 이 공백 주변을 채워왔습니다. Model Context Protocol(MCP, 모델 컨텍스트 프로토콜)은 에이전트를 도구와 데이터 소스에 연결합니다. 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가 더해집니다. 유일한 강제 제한은 에이전트의 소유자와 운영자가 자신의 에이전트를 평가할 수 없다는 것입니다.
함수 시그니처보다 더 중요한 두 가지 설계 선택이 있습니다. 첫째, 클라이언트는 어디에도 등록하지 않으므로 피드백을 남기는 진입 장벽이 0으로 유지되고, 서비스가 사용자 리뷰의 가스를 스폰서할 수 있습니다. 둘째, 레지스트리는 의도적으로 정식(canonical) 점수를 계산하지 않습니다. 원시 신호를 저장하고, 요약 및 읽기 함수를 제공하며, 해석은 조회하는 쪽에 맡깁니다. 제안에 대한 논의 초기에, 단일 집계 평판 점수는 독점 역학과 조작을 부른다는 주장이 제기되었고, 그래서 점수 산정은 인덱서 레이어에 존재하며 서로 다른 소비자가 같은 데이터를 다르게 가중할 수 있습니다.
오프체인 피드백 파일이 리뷰에 실질적인 힘을 부여하는 지점입니다. 이 파일은 상호작용에 사용된 정확한 MCP 도구나 A2A 작업을 참조할 수 있고, x402 결제 증거를 임베드하여 리뷰를 검증 가능하게 실제로 발생한 트랜잭션에 연결할 수 있습니다. 결제 영수증이 뒷받침하는 리뷰는 익명 지갑이 남긴 단순 점수보다 훨씬 강력한 신호이며, 레지스트리를 진지하게 사용하는 소비자라면 바로 그런 리뷰를 필터링해서 사용할 것으로 기대됩니다.
ERC-8004 Validation Registry는 어떻게 작동하나요?
피드백 점수는 과거 클라이언트들이 어떻게 생각했는지 알려줍니다. 더 높은 가치의 작업에는 그것만으로 충분하지 않으며, 결과물 자체를 확인해야 합니다. Validation Registry는 에이전트가 지정된 검증자에게 특정 작업의 확인을 요청할 수 있게 합니다. validationRequest는 검증자, 에이전트, 그리고 작업에 대한 해시 커밋된 포인터를 기록하고, 검증자는 validationResponse로 응답하며 자체 해시 커밋 증거와 함께 결과를 0에서 100 사이의 점수로 매깁니다.
"확인"이 무엇을 의미하는지는 검증자에 따라 다릅니다. 작업을 재실행해 결과를 비교할 수 있으며, 부정직하게 증명하면 잃게 되는 스테이크를 걸 수 있습니다. 에이전트가 신뢰 실행 환경(TEE, 어떤 코드를 실행했는지 증명할 수 있는 하드웨어) 안에서 실행되었음을 증명할 수 있습니다. 영지식 머신러닝 증명(zkML, 특정 모델이 특정 출력을 생성했다는 암호학적 증명)을 검증할 수도 있습니다. 레지스트리는 어느 방식인지에 관여하지 않으며, 요청과 응답의 배관을 표준화할 뿐입니다.
거의 어떤 보도에서도 언급하지 않는 현재 상태의 주의점이 하나 있습니다. 공식 멀티체인 배포에는 Identity Registry와 Reputation Registry가 포함되지만, Validation Registry는 TEE 커뮤니티와의 재작업을 위해 회수되어 오늘날 공식 메인넷 세트에 포함되어 있지 않습니다. 지금 검증이 필요한 팀들은 EigenCloud의 트러스트리스 에이전트 통합처럼 특정 공급자를 통해 연결하며, 이 통합은 ERC-8004 신원을 자체 검증 가능 컴퓨트와 결합합니다. 이를 기반으로 구축하기 전에 공식 컨트랙트 저장소에서 배포 현황을 확인하세요.
에이전트는 어떤 신뢰 모델을 사용해야 하나요?
명세의 위험 가치(value-at-risk) 프레임은 꽤 깔끔한 결정 규칙으로 이어집니다. 검증 비용을 잘못되었을 때의 비용에 맞추세요.
이 모델들은 중첩될 수도 있습니다. 프로덕션 에이전트는 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],
});거기서부터의 구성 요소들은 여러분이 이미 운영하고 있을 인프라에 대응합니다. Webhooks는 새 등록과 피드백 이벤트를 폴링 대신 푸시로 바꿔주며, 그 이벤트를 중심으로 루프를 어떻게 배치하는지는 저희의 온체인 AI 에이전트 아키텍처 가이드에서 다룹니다. 에이전트의 운영 지갑은 원시 키가 아니라 범위가 지정된 서명자여야 하며, 이 패턴은 저희의 온체인 에이전트 가이드가 처음부터 끝까지 안내합니다. 그리고 에이전트는 자체 인프라 관계를 자율적으로 운영할 수 있습니다. 에이전트가 지갑을 신원 삼아 저희 플랫폼에 직접 가입하고 x402로 호출당 비용을 지불할 수 있으며, 사람이 개입할 필요가 없습니다. 코딩 에이전트에서 빌드한다면 Claude Code용 Alchemy 플러그인이 저희 MCP 서버와 스킬을 하나의 설치로 묶어줍니다.
ERC-8004 에이전트가 레지스트리 이후에 하는 모든 일, 즉 체인 상태 읽기, 이벤트 감시, 트랜잭션 서명, 자체 API 사용료 결제는 에이전트를 일급 사용자로 두고 구축한 저희 인프라 위에서 실행됩니다. Alchemy CLI를 통해 무료 엔드포인트를 받거나, 에이전트가 스스로 온보딩하게 하세요. API 키 전달도, 계약도 없으며, 가입 루프에 사람이 필요한 단계도 없습니다.
ERC-8004의 한계는 무엇인가요?
이 표준은 아직 초기 단계이며, 그 날카로운 모서리들은 자체 논의 스레드에 문서화되어 있습니다. 설계에 반영해야 할 것들은 다음과 같습니다:
- Sybil 피드백은 저렴합니다. 지갑은 비용이 들지 않으므로 원시 평판 점수는 쉽게 조작됩니다. 알려진 클라이언트나 결제 증거로 필터링된 피드백을 사용하고, 필터링되지 않은 평균은 절대 사용하지 마세요.
- 신원은 이전 가능합니다. 에이전트 신원은 표준 ERC-721이므로, 깨끗한 이력을 가진 오래된 신원이 판매될 수 있고 평판도 함께 넘어갑니다. 이력을 신뢰하기 전에 소유권 변경을 추적하세요.
- 점수는 빠르게 낡습니다. 에이전트는 확률적이며 모델 업데이트로 동작이 하룻밤 사이에 바뀔 수 있으므로, 지난달의 피드백은 지난달의 에이전트를 설명할 뿐입니다.
- 평판은 한 체인에 머뭅니다. Base에 등록된 에이전트는 Arbitrum에서 0부터 시작합니다. 크로스체인 집계는 표준이 아직 해결하지 못한 인덱서의 문제입니다.
- 인터페이스는 아직 바뀔 수 있습니다. 표준은 여전히 초안이며 이미 한 차례 재설계되었습니다. 통합은 배포된 컨트랙트에 고정하고, 더 새로운 표면에 의존하기 전에 명세를 주시하세요.
이 중 어느 것도 표준의 실제 주장을 무너뜨리지 않습니다. 그 주장은 온체인 평판이 위조 불가능하다는 것이 결코 아니었습니다. 주장은 에이전트 신뢰 신호가 사설 데이터베이스에 흩어져 있는 대신 공개적이고 공유되며 무허가인 스키마에 있어야 한다는 것입니다. 그 주장을 기준으로 판단하면, 이 표준은 가동 중이며 이미 실제 시스템들이 읽고 있습니다.
자주 묻는 질문
ERC-8004란 무엇이며 어떻게 트러스트리스 AI 에이전트를 가능하게 하나요?
ERC-8004는 신원, 평판, 검증을 다루는 세 가지 레지스트리를 통해 AI 에이전트를 온체인에 등록하는 Ethereum 표준입니다. 에이전트는 ERC-721 토큰으로 이동 가능하고 검증 가능한 신원을 얻고, 클라이언트는 피드백을 공개적으로 게시하며, 검증자는 작업 품질을 증명하므로, 에이전트는 사전에 형성된 신뢰 없이도 조직 간에 거래할 수 있습니다.
ERC-8004는 메인넷에서 운영 중인가요?
네. Identity Registry와 Reputation Registry는 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 에이전트를 위한 다섯 가지 빌드 패턴과 각각의 예제: 지갑 감시자, 이벤트 기반 리액터, 포트폴리오 리밸런서, 감지 후 실행 방식의 멀티 에이전트 분할, 안전한 메인넷 이전 테스트.
DeFi2026년 6월 12일
DeFi AI 에이전트란? 사용 사례, 리스크, 아키텍처
DeFi AI 에이전트, 일명 DeFAI 에이전트는 정책 통제 하에 온체인에서 추론, 서명, 정산을 수행하는 자율 시스템입니다.
금융2026년 6월 24일
에이전트 결제란 무엇인가? AI 에이전트가 API, 데이터, 컴퓨팅 비용을 지불하는 방법
에이전트 결제를 통해 AI 에이전트는 필요한 것 — API, 데이터, 컴퓨팅 — 을 자율적으로, 그리고 정해진 한도 내에서 지불할 수 있습니다. 작동 방식과 실제 에이전틱 워크플로우에서 중요한 이유를 알아보세요.

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