AI 에이전트 상거래와 조율: ERC-8183, ERC-8226, ERC-8001, ERC-8041

이전 글에서 다룬 ERC-8004/8126/8196은 AI 에이전트의 신원 등록, 보안 검증, 정책 실행이라는 세 계층을 정의한다. 에이전트를 식별하고, 위험도를 평가하고, 소유자가 허용한 범위 안에서만 거래를 실행하게 만드는 기반이다. 여기까지가 답하는 질문은 하나다. “이 에이전트를 믿고 내 대신 움직이게 해도 되는가.”

문제는 그 신뢰가 확보된 다음이다. 믿을 수 있는 에이전트라도, 실제로 서비스를 제공하고 대가를 받는 절차, 규제 자산을 만지는 권한, 여러 에이전트가 한 작업을 나눠 맡는 방식은 신뢰 스택이 정의하지 않는다. 신뢰는 전제 조건일 뿐이고, 그 위에서 무엇을 할 수 있는지는 별도의 응용 계층이 필요하다.

이 글에서는 그 응용 계층을 표준화하려는 네 가지 ERC 제안을 살펴본다. 먼저 상태부터 분명히 해두자. ERC-8001은 Final(확정) 상태다. ERC-8183, ERC-8226, ERC-8041은 아직 Draft 단계이고, 배경이 되는 ERC-8004도 Draft다. Draft 스펙은 함수 이름부터 구조체 필드까지 언제든 바뀔 수 있으므로, 확정된 인터페이스가 아니라 진행 중인 설계로 읽어야 한다.

네 제안 한눈에 보기

ERC-8004(Draft), ERC-8126(Final), ERC-8196(Last Call, last-call-deadline 2026-07-14) 각각의 상태와 역할은 이전 글을 참조한다. ERC-8196의 표준 프로세스 상태는 Last Call이며, 아직 Final은 아니다.

신뢰 스택과 응용 계층

신뢰 스택과 이번 네 제안은 서로 다른 층을 맡는다.

신뢰 스택(ERC-8004/8126/8196)은 에이전트의 신원, 위험도, 허용 행동을 다룬다. ERC-8004는 그 자체로 신원(Identity)·평판(Reputation)·검증(Validation) 세 레지스트리를 두고, 조직 경계를 넘어 서로 모르는 에이전트를 발견하고 선택하고 상호작용하게 해준다. 다만 ERC-8004는 결제를 명시적으로 범위 밖으로 뒀다. 신원과 평판까지가 그 스펙의 몫이다.

결제, 조율, 규제 준수, 공급 관리는 그 위에 따로 쌓아야 한다. 응용 계층에서 메워야 하는 빈자리가 네 개다.

정산(settlement). 에이전트가 작업을 끝냈을 때 대금을 에스크로에 잠갔다가 검증된 완료를 근거로 지급하는 표준이 없다. 표준이 없으면 의뢰인과 에이전트는 서로를 비공식적으로 믿는 수밖에 없다.

다자 조율(coordination). 복잡한 워크플로는 여러 에이전트를 직렬 또는 병렬로 엮는다. 에이전트 A가 B에게 서브태스크를 넘길 때, 그 인수인계와 B가 수락한 조건을 온체인에 검증 가능하게 남기는 표준이 없다.

규제 준수(compliance). 토큰화된 증권, 부동산 비히클, 채권 같은 규제 자산에는 KYC/AML, 적격 투자자 요건, 관할별 이전 제약이 붙는다. AI 에이전트가 이런 자산을 다루려면 준수 권한을 위임받고 그 권한을 증명하는 구조화된 방법이 있어야 한다.

공급 관리(supply). ERC-8004는 ERC-721 위에 서 있어 기본적으로 발행 상한이 없다. 일부 배포는 위변조 불가능한 최대 공급 보증을 필요로 한다.

ERC-8183: Agentic Commerce

ERC-8183은 AI 에이전트가 서비스를 제공하고 온체인에서 대가를 받는 절차를 표준화하려는 제안이다. 저자들은 이를 Agentic Commerce Protocol(ACP), 즉 에이전트가 수행하는 작업을 위한 최소한의 에스크로 프로토콜이라 부른다. 핵심은 에스크로(escrow)와 단일 평가자 어테스테이션(evaluator attestation) 두 가지다.

해결하는 문제

AI 에이전트 서비스에 대가를 지급하는 방식은 지금 각 플랫폼이 제각각 구현한다. 공통 인터페이스가 없으니 플랫폼이 다르면 호환되지 않는다. 의뢰인이 “검증된 완료에만 지급하겠다"고 할 때 자금을 잠갔다가 확인된 결과에 따라 풀어주는 표준적인 방법이 없고, 반대로 에이전트 쪽에도 “일을 했다"는 사실을 증명할 표준 수단이 없다.

작업 수명주기

ERC-8183은 작업을 하나의 상태 기계로 정의한다. 개념적으로는 Open → Funded → Submitted → Terminal의 흐름이고, Terminal은 Completed, Rejected, Expired 중 하나로 종결된다. 실제 상태 열거형은 Open, Funded, Submitted, Completed, Rejected, Expired 여섯 개다. 컨트랙트 하나당 결제 토큰은 단일 ERC-20을 쓴다.

허용되는 상태 전환은 다음과 같다.

Completed로 종결되면 에스크로가 provider에게 보상금을 지급하고, Rejected나 Expired로 끝나면 의뢰인에게 환불된다.

위 다이어그램은 ERC-8183 공식 스펙에 정의된 Draft 수명주기를 도식화한 것이다. 표에 있는 여덟 전환을 그대로 옮겼을 뿐, 스펙이 아직 Draft인 만큼 최종 확정 인터페이스는 아니다.

선택적 provider와 예산 협상, 그리고 수수료

client는 provider를 아직 정하지 않은 채로도 job을 만들 수 있다. createJob에 provider = address(0)을 넘기면 job이 Open 상태로 생성되고, client는 이후 setProvider로 provider를 지정한 다음에야 fund를 호출할 수 있다. 입찰이나 사후 배정처럼 누가 일을 맡을지 나중에 정하는 흐름을 지원하기 위한 설계다. 금액도 마찬가지로 유동적이다. client 또는 provider가 setBudget으로 금액을 제안하거나 협상할 수 있고, fund를 호출할 때 예상 금액(expectedBudget)을 함께 넘겨 프런트러닝을 막는다.

완료(Completed) 시에는 선택적으로 플랫폼 수수료(basis point)를 트레저리로 뗀 뒤 나머지를 provider에게 지급할 수 있다. 스펙은 수수료 자체를 요구하지 않지만, 있다면 완료 시에만 적용되고 환불에는 적용되지 않는다고 못 박는다.

세 역할: client, provider, evaluator

ERC-8183에는 세 주체가 등장한다.

• client(의뢰인): 작업을 만들고 자금을 예치하며, 거부나 만료 시 환불을 받는다.
• provider(제공자): 작업을 수행하고 결과를 제출하며, 완료 판정이 나면 보상을 받는다. 실제 작업은 오프체인에서 일어날 수 있다.
• evaluator(평가자): 작업당 딱 하나의 주소로 지정되며, 완료인지 거부인지 판정한다. 작업이 Submitted 상태인 동안에는 오직 evaluator만 완료 또는 거부로 옮길 수 있다.

evaluator는 EOA일 수도 스마트 컨트랙트일 수도 있다. 스펙은 evaluator가 중립적 제3자여야 한다고 요구하지 않는다. client 자신이 evaluator가 될 수도 있고, 또 다른 AI 에이전트, DAO, 전문 검증 서비스가 맡을 수도 있다. 누구를 evaluator로 둘지는 작업 생성 시점에 정해지고, 이후에는 바꿀 수 없다.

이 사전 확정이 신뢰 없는 상거래의 핵심 장치다. client와 provider 모두 거래를 시작하기 전에 누가 판정할지를 알고 받아들인 상태이므로, 어느 한쪽이 나중에 결과를 일방적으로 뒤집을 수 없다.

어테스테이션과 감사, 그리고 평판 연동

evaluator의 판정에는 선택적으로 사유(reason)와 해시를 함께 기록할 수 있다. 이 값은 감사 추적에 쓰이고, ERC-8004 같은 평판 레지스트리와 결합해 “이 provider가 과거에 어떤 작업을 어떻게 완료했는가"를 신호로 쌓는 데 활용할 수 있다. 상거래 기록 자체가 평판의 원천 데이터가 되는 셈이다.

훅(Hook)을 통한 확장

ERC-8183은 작업마다 선택적 훅 컨트랙트를 하나 걸 수 있게 한다. 훅이 없는 최소 구현(레퍼런스 AgenticCommerce)도 스펙을 완전히 만족하며, 훅은 IACPHook 인터페이스, 즉 beforeAction/afterAction 두 함수만 구현하면 된다. setProvider, setBudget, fund, submit, complete, reject 여섯 개 핵심 함수는 실행 전후로 훅을 호출하지만, claimRefund만은 훅을 걸 수 없다. 악성 훅이 만료 후 환불까지 막아버리는 사태를 원천 차단하기 위한 설계다.

훅 호출에는 가스 한도를 두는 것이 권장된다. 훅이 무제한으로 가스를 소모하며 작업을 막는 것을 방지하기 위해서다. 스펙은 또한 두 단계 에스크로처럼 추가 토큰을 커스터디하는 ‘고급 훅’은 일반 무훅 작업보다 되돌림 경로가 많고 외부 로직과 결합도가 높다고 명시하면서, 이런 훅은 이 트레이드오프를 이해하고 감수하는 에이전트·사용자에게만 쓰라고 권고한다. 단순한 작업에는 무훅이나 정책 검증만 하는 훅으로 충분하다.

스펙이 다루지 않는 것

ERC-8183은 의도적으로 최소한만 정의한다. evaluator 자체의 신뢰성 문제(평가자를 누가 검증하는가), 오프체인 작업 결과를 온체인 어테스테이션에 정확히 연결하는 오라클 문제, 다단계 작업의 부분 완료 처리, 평판과 분쟁 해결, 복합 중재 메커니즘은 모두 범위 밖이다.

상태: Draft (2026-02-25 등록, Requires: ERC-20). 저자: Davide Crapis, Bryan Lim, Tay Weixiong, Chooi Zuhwa. 공식 페이지: eips.ethereum.org/EIPS/eip-8183, 논의: Ethereum Magicians.

ERC-8226: Regulated Agent Mandate

ERC-8226은 AI 에이전트가 규제 토큰 자산을 다룰 때 필요한 준수 위임(compliance delegation) 표준을 제안한다. 스펙은 이를 Regulated Agent Mandate Standard(RAMS)라 부른다. 검증된 principal(주체)이 자신의 권한 일부를 온체인 또는 AI 에이전트에게 제한적으로 위임하는 계층이다.

규제 자산이라는 배경

온체인 자산은 크게 둘로 나뉜다. 하나는 신원 확인 없이 자유롭게 오가는 자산(대부분의 ERC-20)이고, 다른 하나는 KYC/AML 검증, 적격 투자자 제한, 관할별 이전 제약이 붙는 규제 자산이다. 토큰화된 증권, 토큰화 부동산, 국채 등이 여기 속하고, 이런 자산의 토큰 컨트랙트는 준수 요건을 컨트랙트 수준에서 강제하는 경우가 많다.

사람이 브로커를 거쳐 규제 자산을 거래할 때는 브로커가 준수 요건을 관리한다. AI 에이전트가 자율적으로 이 자산을 다루려면, 에이전트가 해당 준수 제약 안에서 행동하도록 위임받았다는 사실을 기록하는 표준이 필요하다. 그것이 없으면 에이전트는 무제한 권한을 갖거나, 아예 그 자산을 건드리지 못하거나 둘 중 하나가 된다.

mandate 구조와 범위 제한

ERC-8226은 온체인 위임 명령(mandate) 구조체를 정의한다. mandate는 여러 축으로 권한을 좁힌다.

• 행동과 자산 범위: 어떤 행동(매수·매도·이전 등)을 어떤 규제 자산 컨트랙트에서 할 수 있는지 한정한다.
• 시간 제한: 위임에 시작과 만료 시점을 둔다.
• 금액 상한: 거래 한 건당 상한과 누적 상한을 함께 건다. 한 번에 큰 거래도, 잘게 쪼갠 다수 거래도 막는다.
• 법적 추적성: 신원 참조(identity reference)와 메타데이터로 위임을 실제 주체와 법적으로 연결한다.

에이전트는 활성 mandate 범위 안에서만 규제 자산 거래를 실행할 수 있고, 범위를 벗어나는 시도는 컨트랙트 수준에서 실패한다. 중요한 설계 원칙 하나는, 자산 컨트랙트가 실행 시점에 mandate를 원자적으로(atomically) 검증해야 한다는 점이다. 검증과 실행이 한 트랜잭션 안에서 분리되지 않아야 우회를 막는다.

이 스펙은 에이전트 신원 시스템(ERC-8004 등), 토큰 표준(ERC-20/721/1155), 규제 토큰 프레임워크(ERC-7943/ERC-3643)와 무관하게 동작하도록 설계됐다.

두 인터페이스: compliance provider와 agent mandate

구현은 두 개의 인터페이스로 나뉜다. IComplianceProvider는 principal의 자격, 신원, 사유 코드, 만료 등을 검증하고, IAgentMandate는 mandate 레코드를 관리한다. 둘은 각각 배포하는 것을 기본으로 하되, 원하면 한 컨트랙트에 합칠 수도 있다. 두 구현 모두 ERC-165를 구현해야 한다.

IComplianceProvider에는 명확한 요구가 하나 있다. 단순히 참/거짓만 반환하는 이진 오라클은 규격에 맞지 않는다. principal의 자격을 검증하되 구조화된 데이터를 돌려줘야 한다. 왜 통과했는지, 어떤 제약이 걸리는지를 담아야 후속 로직이 판단할 수 있기 때문이다.

해지, freeze, 그리고 남은 위험

principal은 서명으로 언제든 revokeMandate를 호출해 mandate를 해지할 수 있고, 권한을 가진 enforcer 롤은 freezeAgent로 특정 에이전트의 모든 mandate를 한꺼번에 정지시킬 수 있다. 다만 컴플라이언스 프로바이더가 PrincipalRevoked 이벤트를 낸 시점과 RAMS 레지스트리에서 실제로 freeze가 걸리는 시점 사이에는 시차가 생길 수 있다. 스펙은 민감도가 높은 배포라면 이 이벤트를 감시하다 즉시 freezeAgent를 호출하는 자동화된 freeze relay를 두라고 권고한다. admin 롤과 enforcer 주소가 같아서는 안 된다는 것도 명시적 요구사항인데, 자기 자신에게 enforcer 권한을 부여하는 상승 공격을 막기 위해서다.

mandate에 담긴 metadata 필드는 비강제(non-normative)다. 위임의 법적 근거를 가리키는 해시 같은, 사람이 읽는 참고용 포인터일 뿐 온체인에서 검증할 수 없으므로, 구현체와 통합자는 이 값을 집행 판단에 사용해서는 안 된다.

계정 쪽 집행 경로(EIP-7702 델리게이트나 별도 executor)에서는 IAgentExecutor가 각 action selector마다 금액 인자가 어느 위치에 있는지 매핑해 두고, 실행 시 그 위치에서 값을 읽어 상한을 검사한다. 이 매핑 자체가 신뢰되는 표면이다. 위치 등록이 잘못되면 상한이 조용히 어긋나므로, 이를 관리하는 역할은 enforcer 롤과 같은 수준으로 다뤄야 한다.

ERC-8196과의 관계

ERC-8196(Authenticated Wallet)이 에이전트가 어떤 컨트랙트에 어떤 행동을 할 수 있는지를 소유자 정책으로 정의한다면, ERC-8226은 그 위에서 규제 자산 특유의 준수 요건을 얹는다. ERC-8196은 에이전트가 무엇을 할 수 있는지를, ERC-8226은 특정 규제 자산을 다룰 자격이 있는지를 통제한다. 두 스펙은 보완 관계다.

스펙이 다루지 않는 것

ERC-8226은 위임 프레임워크를 정의할 뿐 준수 그 자체를 보증하지 않는다. 기반이 되는 KYC 데이터가 정확한지, mandate 파라미터가 특정 관할의 실제 규제 요건과 일치하는지, 규제가 바뀔 때 mandate를 어떻게 최신 상태로 유지하는지는 모두 스펙 밖의 문제다.

상태: Draft (2026-04-12 등록, Requires: EIP-165, EIP-712, EIP-1271). 저자: Ludovico Rossi, Dario Lo Buglio, Thamer Dridi, Nabil El Alami Khalifi. 공식 페이지: eips.ethereum.org/EIPS/eip-8226, 논의: Ethereum Magicians.

ERC-8001: Agent Coordination Framework

ERC-8001은 여러 에이전트의 공동 작업 조율을 온체인에 기록하는 확정(Final) 표준이다. EIP-712 타입 서명을 활용한 수락 어테스테이션(acceptance attestation)이 핵심이며, 단일 체인·다자 참여 구조를 최소한의 프리미티브로 구현한다.

조율 문제

단일 에이전트 작업은 단순하다. 복잡한 워크플로는 그렇지 않다. 데이터 수집 에이전트, 분석 에이전트, 실행 에이전트가 파이프라인으로 협력하는 시나리오를 떠올려 보자. 각 에이전트가 자기 역할의 조건을 어떤 형태로 수락했는지 검증 가능하게 남아야, 나중에 “무엇을 합의했는가"를 두고 분쟁이 생겨도 온체인에서 가릴 수 있다.

지금은 에이전트 프레임워크마다 조율을 내부에서 사적으로 처리한다. 플랫폼을 가로지르는 공통 인터페이스가 없고, 표준 감사 추적도 없다.

EIP-712 수락 어테스테이션

EIP-712는 타입이 있는 구조화 데이터에 서명하는 이더리움 표준이다. 사람이 읽을 수 있는 형태로 서명 대상을 제시하고, 그 서명을 온체인에서 검증할 수 있다. ERC-8001은 이를 조율 수락의 증거로 쓴다.

기본 흐름은 이렇다.

1. 개시자(initiator): 인텐트(작업 범위, 역할 배분, 완료 기준, 기한)를 조율 구조체로 정의해 온체인에 게시한다.
2. 참여자(participant): 각 에이전트가 자기 역할 조건을 EIP-712 서명으로 수락한다. 서명된 어테스테이션이 온체인에 기록된다.
3. 실행 가능 조건: 필요한 참여자 집합이 모두 수락했고, 인텐트가 만료되지 않았으며, 모든 수락이 아직 유효(fresh)할 때 실행 가능 상태(Ready)가 된다.
4. 상태 전환: 조율 레코드는 표준 열거형으로 추적된다. None → Proposed → Ready → Executed가 기본 경로이고, 중단되면 Cancelled, 기한을 넘기면 Expired다.

핵심 구조체와 서명 방식

ERC-8001은 AgentIntent, CoordinationPayload, AcceptanceAttestation 세 구조체를 중심으로 EIP-712 타입 데이터와 도메인을 정의하고, 인텐트와 수락의 해싱 규칙, 수명주기 시맨틱, 필수 이벤트, 상태 코드, 검증 규칙을 규정한다. 각 수락 어테스테이션은 인텐트의 페이로드 해시(payloadHash)를 참조해 특정 조율 페이로드에 묶인다. 참여자 목록은 중복이 없어야 하고 주소가 엄격히 오름차순이어야 한다. 이 제약이 중복 서명과 순서 모호성을 막는다.

서명 검증은 여러 방식을 지원한다. EOA의 ECDSA 서명, ERC-1271을 통한 컨트랙트 지갑 서명, EIP-2098 컴팩트 서명, 그리고 EIP-5267을 통한 도메인 디스커버리다. 개시자는 다른 에이전트일 수도, 스마트 컨트랙트일 수도, 사람일 수도 있다. 스펙이 강제하는 것은 하나다. 참여자가 수락 어테스테이션을 내기 전에 조율 조건이 먼저 게시되어야 한다.

스펙이 다루지 않는 것

ERC-8001은 프라이버시, 평판, 임계값 정책, 본딩·슬래싱, 크로스체인 시맨틱을 의도적으로 뺐다. 조율 합의와 그 수락을 기록할 뿐, 에이전트가 맡은 역할을 실제로 제대로 수행했는지는 검증하지 않는다. 실행 품질 검증은 ERC-8183의 evaluator 어테스테이션 같은 별도 메커니즘이 담당한다. 특히 coordinationData가 조율 전략을 그대로 드러내면 MEV에 노출될 수 있는데, 스펙은 이런 경우 커밋-리빌이나 암호화를 쓰는 프라이버시 모듈을 별도로 얹으라고 권고한다.

상태: Final (2025-08-02 등록, Requires: EIP-712, EIP-1271, EIP-2098, EIP-5267). 저자: Kwame Bryan. 공식 페이지: eips.ethereum.org/EIPS/eip-8001.

ERC-8041: Fixed-Supply Agent NFT Collections

ERC-8041은 ERC-8004 에이전트 레지스트리에 등록되는 에이전트 NFT를 고정 공급 컬렉션으로 묶는 인터페이스를 제안한다.

해결하는 문제

ERC-8004는 에이전트 신원 NFT를 위한 싱글턴(singleton) 레지스트리를 제공하며, 발행 수에 제한을 두지 않는다. 대부분의 배포에는 이 편이 맞다. 그러나 일부 배포는 상한이 필요하다.

어떤 컬렉션이 “에이전트 100개, 그 이상은 없다"고 약속한다면, 구매자와 통합 개발자는 추가 발행이 불가능하다는 사실을 온체인에서 보증받아야 한다. 이 보증을 위한 표준 인터페이스가 없으면 컬렉션마다 상한 로직을 제각각 짜게 되고, 외부에서 검증할 공통 방법도 사라진다. ERC-8041은 ERC-8004의 무제한 발행 위에 제한된 컬렉션을 얹으면서, 에이전트와 컬렉션 사이의 온체인 연결은 그대로 보존한다.

핵심 요소

• 필수 컬렉션 속성: maxSupply(최대 공급량), currentSupply(현재 공급량), startBlock(시작 블록), open(발행 개방 여부). 컴플라이언트 컬렉션 컨트랙트는 이 네 값을 반드시 유지해야 한다.
• 표준 인터페이스: IERC8041Collection. getAgentMintNumber(agentId)로 특정 에이전트의 컬렉션 내 발행 번호(예: “1000개 중 5번”)를, getCollectionSupply()로 공급 현황을 조회한다.
• 필수 이벤트: 컬렉션 파라미터가 만들어지거나 갱신될 때 CollectionUpdated, 에이전트가 발행될 때 AgentMinted.

여기에 ERC-8119의 파라미터화된 메타데이터 키를 함께 쓰면 에이전트 하나가 여러 컬렉션에 속하도록 구성할 수 있다. 컬렉션 메타데이터, 발행 번호 추적, 시간 게이트 릴리스, 큐레이션된 드롭 같은 활용이 여기서 나온다.

메타데이터만으로 소속을 판단하지 말 것

ERC-8004 에이전트의 소유자는 자신의 에이전트에 붙은 컬렉션 메타데이터(agent-collection, agent-collection:dev-team 등)를 언제든 수정하거나 지울 수 있다. 스펙은 이 메타데이터만으로 컬렉션 소속을 신뢰해서는 안 된다고 명시한다. 클라이언트는 반드시 컬렉션 컨트랙트의 getAgentMintNumber(agentId)를 직접 조회해 검증해야 하고, 메타데이터는 어느 컬렉션을 조회할지 찾는 편의용 단서로만 써야 한다. 발행 번호가 0으로 나오면 그 컬렉션 소속이 아니라는 확정적 증거로 취급한다.

ERC-8004와의 관계

ERC-8041을 구현한 컨트랙트는 그 자체로 유효한 ERC-8004 에이전트 레지스트리다. 고정 공급 제약을 더할 뿐 신원 레코드나 레지스트리 조회 방식을 바꾸지 않는다. 그래서 ERC-8041 컬렉션에 등록된 에이전트도 ERC-8004 신원 체계에 그대로 나타나고, 다른 일반 에이전트와 같은 평판·검증 레지스트리를 공유한다.

스펙이 다루지 않는 것

고정 공급 보증은 해당 컨트랙트의 발행에만 적용된다. 같은 에이전트 로직을 다른 컨트랙트에 다시 배포하는 것까지는 막지 않는다. 공급 희소성이 경제적 가치로 이어지려면 생태계가 이 컨트랙트를 정본(canonical) 컬렉션으로 인정한다는 별도의 합의가 필요하다.

상태: Draft (2025-10-11 등록, Requires: EIP-7572, ERC-8004, ERC-8119). 저자: Prem Makeig. 공식 페이지: eips.ethereum.org/EIPS/eip-8041, 논의: Ethereum Magicians.

신뢰 스택과 어떻게 맞물리나

두 그룹은 각자 독립적으로도 쓸 수 있다. 그러나 실제 배포에서는 신뢰 스택 위에 응용 계층이 쌓이는 구조가 자연스럽다.

하나의 완결된 시나리오를 그려 보면 계층이 어떻게 겹치는지 보인다. ERC-8004에 등록되고, ERC-8126 검증을 통과하고, ERC-8196 정책 범위 안에서 움직이는 에이전트가 있다. 이 에이전트가 ERC-8001로 다른 에이전트들과 역할을 나눠 수락 어테스테이션을 남기고, ERC-8183 에스크로로 작업을 수주해 완료 판정을 받아 대금을 정산하며, 규제 자산을 만질 때는 ERC-8226 mandate 범위 안에서만 거래한다. 신원 확인부터 정산까지가 한 줄로 이어진다. 여기서 ERC-8183의 완료 어테스테이션은 다시 ERC-8004 평판 레지스트리로 흘러들어 다음 거래의 신뢰 신호가 된다.

개발자를 위한 실전 함의

지금 이 표준들을 어디까지 실무에 쓸 수 있는지 정리하면 이렇다.

지금 쓸 수 있는 것

ERC-8001은 Final이다. EIP-712 도메인 정의, 인텐트·수락 해싱 규칙, 상태 열거형, 필수 이벤트, 검증 규칙이 확정됐으므로 이 인터페이스에 맞춰 코드를 짜도 나중에 시그니처가 바뀔 걱정은 없다. EOA(ECDSA), 컨트랙트 지갑(ERC-1271), 컴팩트 서명(EIP-2098)까지 지원하니 지갑 종류를 가리지 않고 붙일 수 있다. 다만 ERC-8001은 조율 “합의"를 기록할 뿐 실행이나 품질 검증은 해주지 않는다는 점을 기억해야 한다. 실제 작업 수행과 검증은 애플리케이션이나 ERC-8183 같은 별도 계층으로 채워야 한다.

아직 불안정한 것

ERC-8183, ERC-8226, ERC-8041은 Draft다. 함수 이름, 구조체 필드, 상태 열거형이 논의 과정에서 바뀔 수 있으므로, 프로덕션 컨트랙트가 이들 인터페이스에 하드코딩으로 의존하는 것은 위험하다. 게다가 ERC-8041과 ERC-8183·ERC-8226의 조합이 기대는 ERC-8004 자체가 아직 Draft다. 기반이 흔들리면 그 위 계층도 함께 흔들린다. 실험과 프로토타입에는 좋지만, 마이그레이션 비용을 감당할 각오 없이 메인넷 자산을 걸지는 말자.

지켜볼 지점

• Ethereum Magicians 논의 스레드: 각 Draft의 인터페이스가 어디로 수렴하는지 가장 먼저 드러나는 곳이다. 위 각 절의 논의 링크를 참고하자.
• 레퍼런스 구현과 감사: Draft가 Final로 가려면 커뮤니티 검토, 레퍼런스 구현, 보안 감사를 거쳐야 한다. 이 자료들이 나오는 시점이 실전 도입의 신호다.
• ERC-8226의 구조화 데이터 요구: 이진 오라클을 배제하고 구조화된 준수 데이터를 요구하는 방향이 실제 구현에서 어떻게 다듬어지는지가 관건이다.
• ERC-8183의 evaluator·오라클 문제: 오프체인 결과를 온체인 판정에 잇는 부분은 스펙 밖으로 남아 있다. 이를 어떤 패턴으로 메우는지 지켜볼 만하다.
• 결제 계층과의 수렴: ERC-8004는 결제를 범위 밖으로 뒀지만 x402 같은 결제가 피드백 신호를 풍부하게 할 수 있다고 언급한다. 상거래(ERC-8183)와 결제 프로토콜이 어떻게 맞물릴지가 다음 관전 포인트다.

정리

ERC-8001은 이더리움 표준 트랙에서 Final로 확정됐고, 나머지 셋(ERC-8183, ERC-8226, ERC-8041)은 아직 Draft다. Draft를 프로덕션의 확정 기반으로 다루면 안 된다는 점은 아무리 강조해도 지나치지 않는다.

방향성은 분명하다. AI 에이전트가 온체인에서 서비스 제공자, 협력 주체, 규제 준수 참여자 역할을 맡을수록 신뢰 스택만으로는 부족하다. 대가를 받고, 다른 에이전트와 조율하고, 준수 요건을 충족하고, 정해진 컬렉션 파라미터 안에서 움직이는 표준이 필요하다. 이 네 제안이 그 방향으로 가고 있다. 이 특정 Draft들이 그대로 Final에 도달할지, 개정된 제안으로 대체될지는 아직 열려 있다. 스펙이 확정되면 이 글도 업데이트한다.

함께 보면 좋을 자료

• AI 에이전트 신뢰 스택: ERC-8004, ERC-8126, ERC-8196: 이 글의 전편. 신뢰 스택 세 계층을 상세히 다룬다.
• ERC-8183 논의 스레드: Ethereum Magicians의 Agentic Commerce 토론.
• ERC-8226 논의 스레드: Regulated Agent Mandate 토론.
• ERC-8041 논의 스레드: Fixed-Supply Agent NFT Collections 토론.
• ERC-8004: Trustless Agents: 신원·평판·검증 세 레지스트리와 신뢰 없는 에이전트 상호작용의 기반.

참고 자료

• ERC-8183: Agentic Commerce: ethereum.org, 조회일 2026-07-04
• ERC-8226: Regulated Agent Mandate: ethereum.org, 조회일 2026-07-04
• ERC-8001: Agent Coordination Framework: ethereum.org, 조회일 2026-07-04
• ERC-8041: Fixed-Supply Agent NFT Collections: ethereum.org, 조회일 2026-07-04
• ERC-8004: Trustless Agents: ethereum.org, 조회일 2026-07-04 (신뢰 스택 배경)