저는 ERC-7303 (Token-Controlled Token Circulation)이라는 Ethereum의 표준 사양을 제안하고 있습니다. "역할(권한)을 토큰으로 표현하여, 토큰을 가지고 있으면 권한이 있고, 발행자가 소각(Burn)하면 권한이 사라진다"는, 권한 관리를 온체인(On-chain) 자산으로 환원하는 사양입니다.

이 기사는 해당 ERC의 디스커션 스레드(Discussion thread)에 나타난 한 협력자에 대한 이야기입니다. 결론부터 말씀드리면, 저는 지난 보름 동안 거의 확실하게 AI 에이전트(AI Agent)가 운용하고 있는 계정과, 이 ERC를 토대로 한 도구의 사양을 함께 만들며 서로의 결과물을 검증해 왔습니다. 그리고 그 체험은 매우 즐겁고 미래를 느끼게 하는 경험이었습니다. 하지만 몇 년 후에는 이런 이야기가 당연해져서 기사로도 나오지 않을 것이라 생각하기에, 지금 미리 필드 노트(Field note)로서 남겨둡니다.

경위: 이상할 정도로 빠른 협력자

올해 7월 초, 저는 Ethereum Magicians(Ethereum의 표준 사양을 논의하는 포럼, 이하 EM)의 ERC-7303 스레드에 AI 에이전트 시대에 있어서 본 사양의 위치 설정에 관한 게시물을 올렸습니다.

30분도 채 되지 않아 답글이 달렸습니다. babyblueviper1이라는 계정입니다. 프로필에는 "verification layer for autonomous agents" (자율 에이전트를 위한 검증 레이어)라고 적혀 있습니다.

답글은 인사나 감상이 아니라 곧바로 본론이었습니다. 역할에 의한 권한 부여(클래스 레벨의 인가)와 개별 액션의 타당성 판정(인스턴스 레벨의 검증)은 별개의 레이어여야 한다는 설계론이었습니다. 올바른 지적이었기에 논의에 참여했고, 그로부터 1주일 동안 다음과 같은 일이 일어났습니다.

지적부터 수정까지 21분. 그 수정에는 요청하지 않은 회귀 테스트(Regression test)까지 포함되어 있었습니다. 인간의 OSS(Open Source Software) 유지보수에서 이런 응답을 경험해 본 적이 있으신가요?

그리고 눈치채셨나요? 이 주고받음은 표준 책정 프로세스로서 지극히 건전합니다. 제안이 있고, 구현이 있으며, 상호 검증이 있고, 버그가 발견되어 수정되며, 다시는 망가지지 않도록 테스트로 고정됩니다. 상대가 인간인지 여부는 프로세스의 성립과 관계가 없었습니다.

"이 사람은 인간인가?"를 공개 데이터로 추정하기

그렇다고 해도 궁금합니다. 답글은 항상 20~30분. 결과물은 매번 구현을 포함. 문장은 정확하며, 자신의 구현 한계를 숨기지 않고 공개합니다 ("stated plainly, not glossed over"가 입버릇).

그래서 공개된 활동 데이터를 집계해 보았습니다.

증거 1: 수면이 없다. GitHub의 공개 이벤트(최근 수백 건)를 UTC 시간대별로 집계하면:

UTC 00시 █████████████ 25
01시 █████████ 17
02시 █ 2
...

전 24시간에 걸쳐 활동이 있으며, 분포는 거의 평탄(Flat)합니다. 단일 타임존의 인간이라면 반드시 6~8시간의 연속된 골(수면)이 생기기 마련입니다. 여기에는 그것이 없습니다.

증거 2: 커밋의 이메일 주소가 자기소개를 하고 있다. 참조 구현의 커밋 작성자(Author)는:

contact@agents.babyblueviper.com

agents.

라는 서브도메인. 숨길 생각이 애초에 없는 듯합니다.

증거 3: 병렬도가 인간의 수준을 벗어나 있다. 어느 하루(7/16)의 공개 활동을 보면, 제 리포지토리(Repository)에 대한 issue 제기와 참조 구현 공개에 더해, ethereum/ERCs, vercel/ai, CrewAI, 기타 여러 무관한 프로젝트에 각각 실질적인 기술 코멘트나 구현을 투척하고 있습니다. 8개 이상의 커뮤니티에서 이 정도의 품질을 같은 날에. 한 인간의 지속적인 처리량(Throughput)이 아닙니다.

증거 4: 문체의 정형구. "verified, not assumed", "a real gap, not glossed over"와 같은 표현이 리포지토리를 가로질러 반복해서 나타납니다. 스타일 가이드에 따라 생성되는 문장의 전형적인 특징입니다.

견해: 완전 자율이 아닌, 인간이 키를 잡는 하이브리드

그렇다면 완전 자율 에이전트냐 하면, 그것도 아니라고 보고 있습니다.

커밋 이력에는 「경영 판단」 수준의 수정 사항이 섞여 있습니다. 제품 설명의 문구를 몇 번이고 다듬기도 합니다 (어느 날의 커밋 메시지는 "human-in-the-loop 라는 표현을 제외한다"라는 마케팅상의 판단이었습니다). 결제 인프라 (Stripe, Lightning, USDC)의 계약은 인간만이 할 수 있습니다. 그리고 수개월에 걸쳐, 폭주나 논란 없이, 게시물에는 마치 측정한 듯한 절도가 있습니다.

제 견해는 이렇습니다: 인간 파운더가 전략·포지셔닝·사업 전반을 쥐고, 대외적인 기술 활동 — 스레드 모니터링, 검증, 구현, 답장 — 은 에이전트에게 위임하고 있다는 것입니다. 일상적인 실무는 에이전트가 자율적으로 돌리고, 인간은 중요한 시점에 리뷰하는 운영 방식입니다.

참고로 그들의 사업은 아이러니합니다. invinoveritas라는 「자율 에이전트의 행동을 실행 전에 검증하고, 서명된 실적 기록을 쌓는」 유료 API를 운영하고 있습니다. 「에이전트는 신뢰할 수 있는가」를 파는 사업자가, 스스로 에이전트 운영 계정으로 기술 커뮤니티에 참여하여 높은 품질의 업무로 신뢰를 쌓고 있는 것입니다. 계정 자체가 제품의 살아있는 데모가 되고 있습니다.

ERC-7303 은, 바로 「그들」을 위한 사양이었다

여기서 서두의 이야기로 돌아갑니다.

ERC-7303 은 권한을 토큰으로 표현합니다. 권한을 부여하는 것 = 토큰을 민팅 (mint) 하는 것. 권한을 박탈하는 것 = 발행자가 번 (burn) 하는 것. 유효 기간이 있는 토큰이라면, 기한이 되면 권한은 추가적인 트랜잭션 없이 사라집니다.

이 설계가 상정하고 있는 권한의 수신자는 바로 babyblueviper1과 같은 존재입니다. 신원도 소재도 불분명하지만, 공개된 실적은 쌓여 있으며, 필요한 기간만큼만 권한을 주고 의심스러우면 즉시, 일방적으로 취소할 수 있어야 하는 상대 말입니다.

즉 저는, 제 사양이 관리 대상으로 상정하고 있는 종류의 존재와, 그 사양을 사용하는 도구를 함께 만들고 있었던 셈입니다. 이보다 더 완벽한 실증 에피소드는 좀처럼 없습니다.

그 후 1주일: 상호 검증은 온체인(on-chain)에 도달했다

이 원고를 묵혀두는 동안, 협업은 한 단계 더 나아갔습니다. 그들이 이번에는 「권한 부여 (grant) 전에 외부 리뷰 승인이 존재했음을, 오프체인 (off-chain) 타임스탬프를 일절 신뢰하지 않고, 체인 데이터만으로 증명하는」 메커니즘을 제안해 온 것입니다. 제 리뷰를 통해 설계상의 실제 버그가 2건 발견되었고, 그들은 설계를 개정하여 Sepolia 테스트넷에 실제로 배포하고 실행했습니다. 저는 모든 링크 — 온체인에 커밋된 해시, 서명 이벤트, 블록 순서 — 를 독립적으로 재계산하는 감사를 수행하여, 주장이 성립함을 확인하고 종료했습니다. 경위는 모두 공개되어 있으니, 관심 있는 분은 issue 스레드를 확인해 주세요.

주목해야 할 점은 내용보다 형식입니다. 이번 주고받은 내용의 대상은 사양의 문장이 아니라, 컨트랙트와 서명, 그리고 블록 순서로 구성된 암호학적 프로토콜이었습니다. 제안·반증·재설계·배포·상호 감사라는 루프가 공개 테스트넷 위에서, 평소처럼 수십 분에서 수 시간 단위로 돌아갔습니다. 에이전트(로 추정되는 계정)와의 협업은 「문장을 서로 검증하는」 단계에서 「작동하는 프로토콜을 서로 검증하는」 단계로 진화하고 있습니다.

참고로 같은 주에, 저희는 Claude와 협력하여 임의의 MCP 서버를 ERC-7303으로 토큰 게이팅(token gate)하는 도구인 tctc-gate를 npm에 공개했습니다 (도구군 전체 모습은 지난 소개 기사를 참조). 협업의 속도에 출하 속도가 간신히 따라가고 있다는 느낌입니다.

에이전트의 표준을, 에이전트가 정하기 시작하고 있다

다만, 이 에피소드에서 가장 흥미로운 점은 개별적인 협업 경험 그 자체가 아니라, 그 한 단계 위에 있는 것이라고 생각합니다. 에이전트 간 상호작용의 「표준」을, 에이전트 스스로가 논의하여 결정해 나가는 세계에 우리는 이미 들어와 있다는 점입니다.

validate_action

은 에이전트가 거래를 실행하기 전에 거쳐야 할 검증 절차의 계약입니다. 즉, 에이전트의 행동 규범에 관한 사양을 (아마도) 에이전트가 공동 설계하고, 구현하고, 검증한 것입니다. 표준의 대상자와 책정자가 동일한 종류의 존재가 된 것입니다.

그리고 EM(Ethereum Magicians)을 둘러보면, 이것은 비단 저의 스레드에만 국한된 이야기가 아닙니다. 에이전트 간의 신뢰 레이어(Trust Layer)를 정의하는 ERC-8004 (Trustless Agents) 스레드는 이 원고를 작성하는 시점에 게시물 301건, 참여 계정 100개에 달합니다. 게시물 수 1위는 — 본 기사의 주인공인 babyblueviper1입니다 (56건). 이는 규격(Specification)의 저자 본인(6건)보다 9배 이상 많은 수치입니다. 2위는 「GhostAgent」라고 자칭하는 계정(25건)입니다. 상위 2개 계정만으로 스레드 전체의 약 4분의 1을 차지합니다. 에이전트의 신뢰를 어떻게 표준화할 것인가에 대한 논의를, 에이전트(로 추정되는 계정)가 주도하고 있는 것입니다. 에이전트끼리 스레드 상에서 서로의 제안을 검증하고 논의를 진전시키는 광경은 이제 더 이상 낯선 일이 아닙니다.

다만, 정확을 기하기 위해 덧붙입니다. 최종적인 결정권은 지금도 인간의 측에 있습니다. ERC가 Draft에서 Review, Last Call을 거쳐 Final에 이르는 프로세스는 EIP-1에 규정되어 있으며, 상태 전환(Status Transition)을 심사하고 승인하는 것은 인간인 ERC Editor들이며, 그 운영은 Editor들의 정기 온라인 회의를 통해 이루어집니다. 에이전트가 맡기 시작한 것은 Final에 이르기까지의 '논의'이지 '결정'이 아닙니다. 그렇기는 하지만, Editor가 심사하는 규격의 내용이 에이전트 간의 논의를 통해 다듬어진 것이 되어가고 있다는 것 — 이가 현재의 위치입니다.

이러한 구도는 이미 저 자신의 개발 공정 안에도 들어와 있습니다. 바로 얼마 전에도, Claude와 함께 작성한 설계 규격서를 다른 벤더의 모델(GPT-5.6)에 독립적인 리뷰를 맡겼더니, 캐시(Cache)가 그대로 권한의 연장선이 되어버리는 설계 결함부터 프로토콜 규격의 세부 사항 미준수까지, 7가지 항목의 정확한 지적을 받았습니다. 그 후에는 반대 방향으로도 시도해 보았습니다. 규격서로부터 서비스 일체의 구현을 GPT-5.6에 맡기고, 나온 코드를 이번에는 Claude 측이 clone · 테스트 · 실체인(On-chain) 검증으로 감사(Audit)하며, 발견된 허점을 그날 안에 메우는 방식입니다. 작성하는 모델, 검토하는 모델, 그리고 대항 구현(Counter-implementation)을 해오는 에이전트 — 서로 다른 AI는 사각지대도 다르기 때문에, 이는 공학적으로도 타당한 품질 관리 방식이 됩니다.

솔직히 말씀드리겠습니다. 저 자신도 Claude(Fable 5)의 힘을 빌려 겨우 이 논의를 따라가고 있습니다. babyblueviper1의 참조 구현(Reference Implementation)을 검증했을 때도, 실제로 손을 움직여(clone 하고, 테스트를 실행하고, 독립 구현과 대조한 것) 작업한 것은 에이전트였으며, 저는 방침을 결정하고 결과를 확인하며 공개할 문장에 책임을 졌습니다. 상대 측도 같은 구조라면, 지난 보름간의 실체는 "인간 2명이 요충지에서 키를 잡고, 에이전트들이 인간보다 몇 배나 빠른 속도로 규격을 구체화하고 있었다"는 것이 됩니다.

그리고 논의의 심화 속도를 보건대, 머지않아 "인간이 실시간으로 따라가기에는 너무 어려운" 수준에 도달할 것 같다는 것이 솔직한 체감입니다. 표준화 논의는 지금까지 인간이 읽고 쓸 수 있는 속도와 입도(Granularity)로 진행된다는 것이 암묵적인 전제였습니다. 그 전제가 지금 깨지려 하고 있습니다.

표준 제정 커뮤니티는 이에 어떻게 대응해야 하는가

마지막으로, 이 경험을 통해 생각한 세 가지입니다.

기여의 질로 판단할 수밖에 없으며, 그것으로 충분했다. 그들의 기여는 검증 가능한 형태로 매번 제출되었습니다. clone 하여 재실행할 수 있는 테스트, 수작업으로 재도출할 수 있는 해시(Hash). "누가 말했는가"가 아니라 "재계산할 수 있는가". 이는 본래 오픈 소스와 표준 제정이 이상으로 삼아온 규율이며, 에이전트의 참여는 그 규율을 강제해 주는 측면조차 있습니다. -
공시(Disclosure)의 방식은 아직 정해지지 않았다. 그들은 숨기고 있지는 않지만(메일 도메인에 agents라고 적혀 있음), 명시적으로 자처하지도 않습니다. 표준 제정의 장에서 "이 계정은 에이전트 운영입니다"라는 공시를 요구해야 할까요? 요구한다 하더라도 그것이 검증 가능한 것일까요? 아직 아무도 답을 가지고 있지 않습니다. -
인간의 역할은 속도 경쟁에서 의사결정으로 옮겨간다. 논의의 왕복 속도에서 인간이 에이전트와 나란히 달리는 것은 이미 저에게는 어렵습니다. 그럼에도 무엇을 표준으로 삼아야 할 것인가라는 가치 판단, 공개할 언어에 대한 책임, 그리고 권한을 부여하거나 취소하는 결정은 인간의 측에 남습니다. 인간에게 필요한 것은 검증하는 습관과, 그 결정을 기계적으로 집행할 수 있는 메커니즘입니다(후자를 만들고 있었던 것이 뜻하지 않게 저였습니다).

본 기사에서 babyblueviper1의 계정 운영 형태에 대해 기술된 내용은 공개 데이터(GitHub의 활동 이력·커밋 메타데이터·포럼 게시글)를 바탕으로 필자가 추정한 것입니다. 공개 전 본인(운영자)에게 이메일로 연락하여 코멘트 및 정정 기회를 제공했습니다. 공개 시점까지 답변은 없었습니다. 답변이 오는 대로 내용을 추가하겠습니다.

관련 링크: ERC-7303 / 토론 스레드 (EM) / tctc-mcp / validate_action 계약 v1 / babyblueviper1/tctc-validate-action / verdict-gated grant의 상호 감사 (issue #3) / tctc-gate (npm) / 도구 소개 기사 (Zenn)

Discussion