블록체인 상에서 AI 에이전트를 실현하는 데 왜 어려움이 많은가?
글쓴이: Zack Pokorny
번역: Chopper, Foresight News
AI 에이전트의 블록체인 상 실현은 원활하지 않다. 블록체인은 프로그래밍 가능하고 허가 없이 사용할 수 있는 특성을 갖추고 있으나, AI 에이전트에 적합한 의미론적 추상화 및 협업 계층을 부족하게 한다. 암호화폐 연구 기관 갤럭시(Galaxy)는 보고서에서, AI 에이전트가 체인 상에서 ‘기회 탐지’, ‘신뢰성 검증’, ‘데이터 읽기’, ‘실행 프로세스’라는 네 가지 구조적 마찰에 직면해 있으며, 기존 인프라가 여전히 인간 상호작용 중심으로 설계되어 있어 AI가 자산을 자율적으로 관리하거나 전략을 실행하는 것을 지원하기 어렵다고 지적했다. 이러한 한계들이 바로 AI 에이전트의 블록체인 상 대규모 도입을 가로막는 핵심 병목 현상이다. 다음은 보고서 전문 번역본이다.
AI 에이전트의 적용 분야와 능력은 진화를 시작했다. 이제 에이전트는 스스로 작업을 수행할 뿐 아니라 자본 보유 및 배분, 거래 및 수익 전략 탐색까지 개발되고 있다. 비록 이 실험적 전환은 극초기 단계에 불과하지만, 이는 과거에 주로 소셜 및 분석 도구로서 기능하던 에이전트의 발전 패턴과 완전히 다르다.
블록체인은 이러한 진화 과정의 자연스러운 실험장이 되고 있다. 블록체인은 허가 없이 접근 가능하며, 조합 가능하고, 오픈소스 애플리케이션 생태계를 갖추고 있으며, 모든 참여자에게 데이터를 동등하게 공개한다. 또한 체인 상의 모든 자산은 기본적으로 프로그래밍 가능하다.
이로부터 구조적 질문 하나가 제기된다: 만약 블록체인이 프로그래밍 가능하고 허가 없이 사용 가능한데, 자율 에이전트는 왜 여전히 마찰을 겪는가? 그 해답은 실행 가능성 여부가 아니라, 실행 위에 얼마나 많은 의미론적·협업적 부담이 얹혀 있는가에 있다. 블록체인은 상태 전환의 정확성을 보장하지만, 일반적으로 경제적 해석, 규범적 신원 정의 또는 목표 차원의 협업 등 프로토콜 내재적 추상화를 제공하지 않는다.
일부 마찰은 허가 없이 운영되는 시스템의 아키텍처 결함에서 비롯되며, 또 다른 일부는 현재의 도구, 콘텐츠 관리 및 시장 인프라의 현실을 반영한다. 실제로 많은 상위 기능은 여전히 소프트웨어 및 워크플로우에 의존하는데, 이들은 인간의 직접적인 개입을 전제로 구축된다.
블록체인 아키텍처와 AI 에이전트
블록체인은 합의 및 결정론적 실행을 중심으로 설계되었지, 의미론적 해석을 위해 설계되지 않았다. 블록체인은 저장 슬롯, 이벤트 로그, 호출 트레이스 등 저수준 원시 요소를 외부에 노출시킬 뿐, 표준화된 경제 객체를 노출하지 않는다. 따라서 포지션, 수익률, 건강 계수(health coefficient), 유동성 심도 등 추상적 개념들은 일반적으로 인덱서, 데이터 분석 계층, 프론트엔드 인터페이스 및 API 등 체인 외부에서 재구성되어야 하며, 각 프로토콜 고유의 상태를 더 쉽게 활용 가능한 형태로 변환해야 한다.
많은 주류 탈중앙화 금융(DeFi) 운영 프로세스, 특히 소매 투자자 및 주관적 의사결정 중심의 프로세스는 여전히 사용자가 프론트엔드 인터페이스를 통해 상호작용하고 단일 거래에 서명하는 방식을 기반으로 한다. 이러한 프론트엔드 중심 모델은 소매 투자자의 확산과 함께 성장했으며, 체인 상 활동의 상당 부분이 이미 기계에 의해 구동되고 있음에도 불구하고 여전히 주류다. 현재 소매 투자자의 주요 상호작용 모델은 다음과 같다: 의도 → 프론트엔드 인터페이스 → 거래 → 확인. 프로그래밍 방식의 운영은 또 다른 경로를 따르지만, 이 역시 자체적인 제약을 안고 있다: 개발자는 구축 단계에서 계약 및 자산 집합을 사전에 선택한 후, 이 고정 범위 내에서 알고리즘을 실행한다. 두 모델 모두 실행 중에 끊임없이 변화하는 목표에 따라 동적으로 기회를 탐지·평가·조합해야 하는 시스템에는 적응할 수 없다.
거래 검증에 최적화된 인프라가, 경제 상태를 해석하고 신용을 평가하며 명확한 목표에 따라 행동을 최적화해야 하는 시스템에 의해 사용될 때, 마찰이 발생하기 시작한다. 이러한 격차의 일부는 블록체인의 허가 없이 운영되며 이질적인 설계 특성에서 비롯되며, 또 다른 일부는 여전히 인간의 검토 및 프론트엔드 중개를 전제로 구축된 상호작용 도구에서 기인한다.
에이전트 행동 프로세스와 전통적 알고리즘 전략의 비교
블록체인 인프라와 에이전트 시스템 간 격차를 논의하기에 앞서, 보다 지능적이고 자율적인 행동 프로세스가 전통적인 체인 상 알고리즘 시스템과 어떻게 다른지를 명확히 해야 한다.
두 시스템의 차이는 자동화 수준, 복잡성, 매개변수 설정, 심지어 동적 적응 능력에도 있지 않다. 전통적 알고리즘 시스템은 고도로 매개변수화될 수 있으며, 새 계약 및 새 토큰을 자동으로 탐지하고, 다양한 전략 유형 간 자금을 분배하며, 성과에 따라 재균형 조정할 수 있다. 진정한 차이는 시스템이 구축 단계에서 예측하지 못한 상황을 처리할 수 있는가에 있다.
전통적 알고리즘 시스템은 아무리 복잡하더라도 사전에 정의된 패턴에 따라 사전에 정의된 논리를 실행할 뿐이다. 각 프로토콜 유형에 대해 사전 정의된 인터페이스 파서, 계약 상태를 경제적 의미로 매핑하는 사전 정의된 평가 논리, 명확한 신용 및 표준성 판단 규칙, 그리고 각 의사결정 분기를 위한 하드코딩된 규칙을 반드시 필요로 한다. 사전 정의된 패턴에 부합하지 않는 상황이 발생하면, 시스템은 해당 항목을 건너뛰거나 바로 오류를 발생시킨다. 시스템은 낯선 상황에 대해 추론할 수 없으며, 현재 상황이 알려진 템플릿과 일치하는지 여부만 판단할 수 있다.
이 '소화 오리' 기계 자동 장치는 생물학적 행동을 모방하지만, 모든 동작은 미리 프로그래밍된 것이다
DeFi 대출 시장 전체를 스캔하는 전통적 알고리즘은 친숙한 이벤트를 발생시키거나 알려진 팩토리 패턴과 일치하는 새로 배포된 계약을 식별할 수 있다. 그러나 인터페이스가 낯선 새로운 대출 기반 구성요소가 등장하면, 시스템은 이를 평가할 수 없다. 인간이 계약을 검사하여 작동 원리를 이해하고, 이것이 채굴 가능한 기회인지 판단하며, 통합 논리를 작성해야 한다. 그 후에야 알고리즘이 해당 계약과 상호작용할 수 있다. 즉, 인간이 해석하고, 알고리즘이 실행한다. 기초 모델 기반의 에이전트 시스템은 이 경계를 바꾼다. 에이전트는 습득된 추론 능력을 통해 다음과 같은 기능을 수행할 수 있다:
- 모호하거나 불완전하게 표현된 목표를 해석한다. 예를 들어 「최대 수익 달성 단, 과도한 리스크는 피함」이라는 지시는 의미론적 해석을 요구한다. 과도한 리스크란 무엇인가? 수익과 리스크는 어떻게 균형을 맞춰야 하는가? 전통적 알고리즘은 이러한 조건을 사전에 정밀하게 정의해야 하지만, 에이전트는 의도를 해석하고 판단하며, 피드백을 통해 자신의 이해를 최적화할 수 있다.
- 낯선 인터페이스에 일반화하여 적응할 수 있다. 에이전트는 낯선 계약 코드를 읽고, 문서를 해석하거나 접해보지 않은 애플리케이션 바이너리 인터페이스(API)를 살펴보고, 해당 시스템의 경제적 기능을 추론할 수 있다. 각 프로토콜 유형마다 사전에 파서를 구축할 필요가 없다. 물론 현재 이 능력은 아직 완벽하지 않아, 에이전트가 보는 내용을 잘못 해석할 수도 있지만, 구축 단계에서 예측하지 못한 시스템과도 상호작용을 시도할 수 있다.
- 신뢰 및 규범성에 대한 불확실성이 존재할 때 추론할 수 있다. 신용 신호가 모호하거나 불완전할 경우, 기초 모델은 이진 규칙을 단순히 적용하는 대신, 신호를 확률적으로 가중 평가할 수 있다. 이 스마트 계약은 표준화되어 있는가? 현재 증거를 기반으로 이 토큰은 합법적인가? 전통적 알고리즘은 규칙이 있으면 적용하고, 그렇지 않으면 아무것도 할 수 없지만, 에이전트는 신뢰도에 대한 추론을 수행할 수 있다.
- 오류를 설명하고 조정할 수 있다. 예기치 않은 상황이 발생하면, 에이전트는 문제의 근본 원인을 추론하고 대응 방식을 결정할 수 있다. 반면 전통적 알고리즘은 예외 캡처 모듈만 실행하여 오류 정보를 전달할 뿐, 해석은 하지 않는다.
이러한 능력은 현재 실제 존재하지만 완벽하지는 않다. 기초 모델은 환각(hallucination)을 일으키고, 내용을 잘못 해석하며, 확신에 찬 듯한 오류 결정을 내릴 수 있다. 대립적이고 자본이 관련된 환경(즉, 코드가 자산을 제어하거나 수신할 수 있는 환경)에서 ‘예측하지 못한 시스템과 상호작용 시도’는 자금 손실을 의미할 수 있다. 본문의 핵심 주장은 지금 당장 에이전트가 이러한 기능을 신뢰성 있게 수행할 수 있다는 것이 아니라, 전통적 시스템이 절대 시도하지 않는 방식으로 시도할 수 있다는 점이며, 미래의 인프라는 이러한 시도를 더욱 안전하고 신뢰성 있게 만들 수 있다는 것이다.
이 차이는 절대적인 분류 경계라기보다는 연속적인 상태로 봐야 한다. 일부 전통적 시스템은 습득된 추론 형태를 포함할 수 있고, 일부 에이전트는 핵심 경로에서 하드코딩된 규칙에 의존할 수도 있다. 이 차이는 방향성에 관한 것이지, 절대적인 이분법이 아니다. 에이전트 시스템은 해석·평가·적응 작업의 상당 부분을 구축 단계의 사전 정의 규칙에서, 실행 시점의 추론으로 이동시킨다. 이 점은 마찰 논의에 매우 중요하다. 왜냐하면 에이전트 시스템이 시도하는 것은 전통적 알고리즘이 완전히 회피하는 일이기 때문이다. 전통적 알고리즘은 구축 단계에서 인간이 계약 집합을 선별함으로써 ‘탐지 마찰’을 회피하고, 운영자가 관리하는 화이트리스트를 통해 ‘제어 계층 마찰’을 회피하며, 사전에 구축된 프로토콜 파서를 통해 ‘데이터 마찰’을 회피하고, 사전에 정의된 안전 경계 내에서 실행함으로써 ‘실행 마찰’을 회피한다. 인간이 사전에 의미론적·신용·전략 차원의 작업을 완료하고, 알고리즘은 그 범위 내에서 실행한다. 초기 체인 상 에이전트 행동 프로세스는 이 패턴을 따를 수도 있지만, 에이전트의 핵심 가치는 ‘탐지’, ‘신용’, ‘전략 평가’를 구축 단계의 사전 정의에서 실행 시점의 추론으로 이동시키는 데 있다.
에이전트는 낯선 기회를 탐지하고 평가하며, 하드코딩된 규칙 없이 표준성을 추론하고, 사전에 구축된 파서 없이 이질적인 상태를 해석하며, 모호할 수 있는 목표에 따라 전략 제약을 실행한다. 마찰이 존재하는 이유는 에이전트가 알고리즘과 동일한 일을 하되 더 어려운 방식으로 수행하기 때문이 아니라, 근본적으로 다른 일을 시도하기 때문이다: 폐쇄적이고 사전 통합된 체계 내부가 아니라, 개방적이며 동적 해석이 필요한 행동 공간 내에서 작동하는 것이다.
마찰
구조적 관점에서 이 모순은 블록체인 합의의 결함에서 비롯된 것이 아니라, 블록체인 주변에서 발전해 온 전체 상호작용 스택의 작동 방식에서 비롯된 것이다.
블록체인은 결정론적 상태 전환, 최종 상태에 대한 합의, 그리고 최종 확정성을 보장한다. 그러나 프로토콜 수준에서 경제적 의미 해석, 의도 검증, 또는 목표 추적을 코딩하려 하지 않는다. 이러한 책임은 전통적으로 프론트엔드 인터페이스, 월렛, 인덱서 및 기타 체인 외부 협업 계층이 맡아왔으며, 여기에는 항상 인간의 개입이 필요했다.
심지어 숙련된 참가자들 사이에서도 현재 주류 상호작용 방식은 이러한 설계를 반영한다. 소매 투자자는 대시보드를 통해 상태를 해석하고, 프론트엔드 인터페이스를 통해 작업을 선택하며, 월렛을 통해 거래에 서명한다. 결과는 공식적으로 검증하지 않고 비공식적으로 확인한다. 알고리즘 거래 기관은 실행 자동화를 실현했지만, 여전히 인간 운영자가 프로토콜 집합을 선별하고, 이상 징후를 확인하며, 인터페이스 변경 시 통합 논리를 업데이트하는 데 의존한다. 두 경우 모두 프로토콜은 실행의 정확성만 보장하고, 의도 해석, 이상 처리, 새로운 기회 적응은 인간이 담당한다.
에이전트 시스템은 이러한 분업을 압축하거나 심지어 제거한다. 에이전트는 경제적 의미를 갖는 상태를 프로그래밍 방식으로 재구성하고, 목표 달성 진행 상황을 평가하며, 실행 결과를 검증해야 하며, 단순히 거래가 체인에 포함됐다는 사실만 확인해서는 안 된다. 블록체인에서는 이러한 부담이 특히 두드러지는데, 왜냐하면 에이전트는 개방적이고 대립적이며 급변하는 환경에서 작동하며, 새로운 계약, 자산, 실행 경로가 중앙집중적 검토 없이 등장할 수 있기 때문이다. 프로토콜은 거래의 정확한 실행만 보장할 뿐, 경제적 상태가 해석하기 쉬운지, 계약이 표준화돼 있는지, 실행 경로가 사용자 의도와 부합하는지, 또는 관련 기회가 프로그래밍 방식으로 탐지 가능한지에 대해서는 보장하지 않는다.
다음에서는 에이전트 실행 루프의 각 단계를 따라 이러한 마찰을 순차적으로 정리한다: 기존 계약 및 기회 탐지, 그 합법성 검증, 경제적 의미를 갖는 상태 획득, 그리고 목표에 따라 작업 실행.
탐지 마찰
마찰이 발생하는 이유는 허가 없이 운영되는 환경에서 탈중앙화 금융의 행동 공간이 개방적으로 확장되지만, 관련성과 합법성은 인간이 체인 상의 소셜, 시장, 도구 계층을 통해 선별한다는 데 있다. 새로운 프로토콜은 공고를 통해 등장하며, 동시에 프론트엔드 통합, 토큰 목록, 데이터 분석 플랫폼, 유동성 형성 등 여러 필터링 계층을 거친다. 시간이 지남에 따라 이러한 신호들은 경제적 가치가 있고 충분히 신뢰할 수 있는 행동 공간의 어느 부분을 구분하는 실용적인 기준이 된다. 다만 이러한 합의는 비공식적이며 불균형적일 수 있고, 일부는 제3자 및 인간 선별에 의존한다.
에이전트에게는 선별된 데이터 및 신용 신호를 제공할 수 있지만, 인간이 이러한 신호를 해석할 때 사용하는 직관적 단축 경로는 자체적으로 갖추지 못한다. 체인 관점에서 보면, 모든 배포된 계약은 동일한 발견 가능성을 갖는다. 합법적 프로토콜, 악의적 포크, 테스트 배포, 폐기된 프로젝트는 모두 호출 가능한 바이트코드 형태로 존재한다. 블록체인 자체는 어떤 계약이 중요한지, 어떤 계약이 안전한지에 대해 코딩하지 않는다.
따라서 에이전트는 자체 탐지 메커니즘을 구축해야 한다: 배포 이벤트를 스캔하고, 인터페이스 패턴을 식별하며, 팩토리 계약(즉, 다른 계약을 프로그래밍 방식으로 배포할 수 있는 계약)을 추적하고, 유동성 형성 상황을 모니터링하여 어떤 계약을 의사결정 범위에 포함시켜야 할지를 판단해야 한다. 이 과정은 단순히 계약을 찾는 것을 넘어서, 해당 계약이 에이전트의 행동 공간에 포함되어야 할지를 판단하는 것이다.
후보 객체를 식별하는 것은 단지 첫걸음일 뿐이다. 계약이 초기 탐지 필터를 통과한 후에는 다음 섹션에서 설명할 표준성 및 진실성 검증 절차를 거쳐야 한다. 에이전트는 자신이 발견한 계약이 진정으로 이름값을 한다는 것을 먼저 확인한 후에야 이를 의사결정 공간에 포함시킬 수 있다.
탐지 마찰은 단순히 새롭게 배포된 행위를 탐지하는 것과는 관련이 없다. 성숙한 알고리즘 시스템은 이미 자체 전략 범위 내에서 이를 수행할 수 있다. Uniswap 팩토리 이벤트를 모니터링하고 새 유동성 풀을 자동으로 검색 범위에 포함시키는 검색자(searcher)는 바로 동적 탐지를 수행하는 것이다. 마찰은 두 가지 더 높은 수준에서 발생한다: 발견된 계약이 합법적인지 판단하는 것, 그리고 단순히 사전 정의된 전략 유형과 일치하는지 여부를 넘어, 개방적 목표와 관련이 있는지 판단하는 것이다.
검색자의 탐지 논리는 전략과 밀접하게 결합되어 있다. 검색자는 전략이 정의한 대로 어떤 인터페이스 패턴을 찾아야 하는지 알고 있다. 그러나 「리스크 조정 후 최적 기회 배치」와 같은 보다 광범위한 지시를 실행하는 에이전트는 전략에서 유래한 필터만으로는 충분하지 않다. 에이전트는 새롭게 만난 기회를 목표 자체와 비교하여 평가해야 하며, 이는 낯선 인터페이스를 해석하고, 경제적 기능을 추론하며, 해당 기회가 의사결정 공간에 포함되어야 할지를 판단하는 것을 의미한다. 이는 어느 정도 일반적 자율성 문제이지만, 블록체인은 이 문제를 가중시킨다.
제어 계층 마찰
제어 계층 마찰은 신원 및 합법성 판단이 일반적으로 프로토콜 외부에서 이루어지며, 선별, 거버넌스, 문서, 인터페이스, 운영자 판단 등을 종합적으로 활용한다는 데서 비롯된다. 현재 많은 워크플로우에서 인간은 여전히 판단 단계의 핵심 구성원이다. 블록체인은 결정론적 실행 및 최종 확정성을 보장하지만, 호출자가 목표 계약과 상호작용하고 있는지 보장하지 않는다. 이러한 의도 판단은 소셜 맥락, 웹사이트, 인간 선별 등 외부로 이관된다.
현재 프로세스에서 인간은 웹사이트의 신용 계층을 비공식적 검증 수단으로 활용한다. 인간은 일반적으로 DeFiLlama 같은 집계 플랫폼이나 프로젝트 인증 소셜 계정을 통해 공식 도메인에 접속하고, 이 웹사이트를 인간 개념과 계약 주소 간 표준 매핑 매체로 간주한다. 이후 프론트엔드 인터페이스는 공신력 있는 신뢰 기준을 형성하여, 어떤 주소가 공식 주소인지, 어떤 토큰 식별자를 사용해야 하는지, 어떤 진입점이 안전한지 명확히 한다.
1789년의 기계식 터키인은 체스를 두는 기계로, 겉보기에는 자율적으로 작동하지만, 실제로는 숨겨진 인간 조작자에 의해 구동된다
에이전트는 기본적으로 소셜 맥락을 통해 브랜드 식별자, 인증 소셜 신호, 또는 ‘공식성’을 해석할 수 없다. 이러한 신호에서 파생된 선별된 데이터를 에이전트에 입력할 수는 있지만, 이를 영구적으로 사용 가능한 기계 신용 가설로 전환하려면 명확한 레지스트리, 정책, 또는 검증 논리가 필요하다. 에이전트는 운영자가 제공하는 선별된 화이트리스트, 인증 주소, 신용 정책으로 구성될 수 있다. 문제는 소셜 맥락을 완전히 얻을 수 없는 것이 아니라, 동적으로 확장되는 행동 공간에서 이러한 보호 조치를 유지하는 운영 비용이 매우 높고, 조치가 누락되거나 불완전할 경우 에이전트가 인간이 기본적으로 사용하는 대체 검증 메커니즘을 갖추지 못한다는 데 있다.
체인 상 에이전트 기반 시스템에서 신용 판단의 취약성으로 인한 실제 결과가 이미 나타나고 있다. 유명 암호화폐 블로거 Orangie의 사례에서, 에이전트가 꿀벌통(honey pot) 계약에 자금을 입금했다고 보고되었다. 또 다른 사례에서는 Lobstar Wilde라는 에이전트가 상태 또는 맥락 오류로 인해 주소 상태를 잘못 판단하여 대량의 토큰 잔액을 온라인 ‘구걸자’에게 전송했다. 이러한 사례는 본 논지의 핵심 근거는 아니지만, 신용 판단, 상태 해석, 실행 전략 오류가 자금 손실로 직접 이어질 수 있음을 충분히 보여준다.
문제는 계약을 탐지하기 어려운 데 있는 것이 아니라, 블록체인에 일반적으로 ‘이 애플리케이션의 공식 계약’이라는 개념이 원시적으로 존재하지 않는 데 있다. 이 부재는 어느 정도 허가 없이 운영되는 시스템의 특성일 뿐, 설계상의 소홀이 아니지만, 자율 시스템에 협업 난제를 초래한다. 이 문제는 부분적으로 표준 신원 식별이 약한 개방형 시스템 아키텍처에서 비롯되며, 또 다른 부분은 레지스트리, 표준, 신용 분배 메커니즘이 아직 성숙하지 못한 데서 기인한다. Aave v3와 상호작용하려는 에이전트는 어떤 주소가 표준 주소인지, 그리고 이 주소가 변경 불가능한지, 프록시를 통해 업그레이드 가능한지, 또는 현재 거버넌스 변경이 보류 중인지 판단해야 한다.
인간은 문서, 프론트엔드 인터페이스, 소셜 미디어를 통해 이 문제를 해결한다. 에이전트는 다음 내용을 확인함으로써 판단해야 한다:
- 프록시 패턴 및 구현 세부사항
- 관리 권한 및 타임록(time lock)
- 거버넌스 제어의 매개변수 업데이트 모듈
- 기존 배포 간 바이트코드 / 애플리케이션 바이너리 인터페이스 일치 여부
표준 레지스트리가 부재한 상황에서 ‘공식성’은 추론 문제이다. 이는 에이전트가 계약 주소를 정적 설정으로 간주할 수 없다는 것을 의미한다. 에이전트는 지속적인 검증을 수행하는 선별된 화이트리스트를 유지하거나, 실행 시점에서 프록시 검사 및 거버넌스 모니터링을 통해 표준성을 재추론하거나, 폐기되거나 손상되거나 모조된 계약과 상호작용할 위험을 감수해야 한다. 전통적 소프트웨어 및 시장 인프라에서 서비스 신원은 일반적으로 기관이 관리하는 네임스페이스, 자격 증명, 액세스 제어에 의해 고정된다. 반면 체인 상에서는 계약이 호출 가능하고 정상 작동할 수 있지만, 호출자 관점에서 경제적 또는 사업적 측면에서 표준성을 갖추지 못할 수 있다.
토큰 진실성 및 메타데이터는 동일한 문제이다. 토큰은 스스로를 설명하는 것처럼 보인다. 그러나 토큰 메타데이터는 권위가 없으며, 단지 코드가 반환하는 바이트 데이터일 뿐이다. 대표적인 사례는 래퍼드 이더리움(WETH)이다. 널리 사용되는 WETH 계약 코드에는 명시적으로 이름, 심볼, 정밀도가 정의되어 있다.
이것은 신원 식별처럼 보이지만, 실은 그렇지 않다. 어떤 계약이라도 다음을 설정할 수 있다:
- symbol() = WETH
- decimals() = 18
- name() = Wrapped Ether
그리고 동일한 ERC-20 토큰 표준 인터페이스를 구현할 수 있다. name(), symbol(), decimals()는 단지 공개된 읽기 전용 함수일 뿐이며, 배포자가 설정한 임의의 내용을 반환한다. 실제로 이더리움에는 이름이 ‘Wrapped Ether’, 심볼이 ‘WETH’, 정밀도가 18인 토큰이 약 200개 있다. CoinGecko나 Etherscan을 조회하지 않고, 당신은 어떤 ‘WETH’가 표준 버전인지 구분할 수 있는가?
에이전트가 직면한 상황이 바로 이와 같다. 블록체인은 고유성 검사를 하지 않으며, 어떤 레지스트리와도 대조하여 검증하지 않으며, 어떠한 제한도 두지 않는다. 당신은 오늘 500개의 계약을 배포할 수 있으며, 모두 동일한 메타데이터를 반환할 수 있다. 체인 상에는 몇 가지 시도적 판단 방법(예: 이더리움 잔고와 총 공급량 일치 여부 확인, 주요 탈중앙화 거래소의 유동성 심도 조회, 대출 프로토콜 담보 토큰 여부 검증)이 존재하지만, 이는 절대적 증거를 제공하지 않는다. 각 방법은 임계값 가정에 의존하거나, 다른 계약의 표준성 검증에 재귀적으로 의존한다.
미로에서 ‘진짜’ 길을 찾기 위해서는 외부 안내가 필요하듯, 체인 상에는 원시적인 표준 신호가 존재하지 않는다
이것이 토큰 목록 및 레지스트리가 체인 외부 선별 계층으로 존재하는 이유이다. 이들은 ‘WETH’라는 개념을 특정 주소에 매핑하는 방식을 제공하며, 이는 월렛 및 프론트엔드 인터페이스가 화이트리스트를 유지하거나 신뢰할 수 있는 집계 플랫폼에 의존하는 이유이기도 하다. 에이전트에게 핵심 문제는 단순히 메타데이터의 신뢰도가 낮은 데 있는 것이 아니라, 표준 신원이 일반적으로 소셜 또는 기관 수준에서 확립되며, 프로토콜 원시 수준이 아니라는 데 있다. 신뢰할 수 있는 체인 상 식별자는 계약 주소이지만, ‘USDC로 교환’과 같은 인간 의도를 올바른 주소에 매핑하는 것은 여전히 프로토콜 원시 수준이 아닌 선별, 레지스트리, 화이트리스트, 기타 신용 계층에 크게 의존한다.
데이터 마찰
탈중앙화 금융의 다양한 프로토콜 간에 자산을 최적화하여 배치하는 에이전트는 각 기회를 수익률, 유동성 심도, 리스크 매개변수, 수수료 구조, 오라클 소스 등과 같은 표준화된 경제 객체로 변환해야 한다. 어느 정도로 보면, 이는 일반적인 시스템 통합 문제이다. 그러나 블록체인에서는 프로토콜의 이질성, 직접적인 자본 노출, 다중 호출 상태 조합, 그리고 기본적인 통일된 경제 모델 부재가 이러한 부담을 더욱 가중시킨다. 그런데 이러한 요소들이 바로 기회 비교, 배분 시뮬레이션, 리스크 모니터링에 필수적인 기본 요소들이다.
블록체인은 일반적으로 프로토콜 수준에서 표준화된 경제 객체를 노출하지 않는다. 블록체인은 저장 슬롯, 이벤트 로그, 함수 출력을 노출하며, 경제 객체는 이들로부터 추론하거나 재구성해야 한다. 프로토콜은 계약 호출이 올바른 상태 값을 반환하도록 보장할 뿐, 해당 값이 읽기 쉬운 경제 개념으로 명확하게 매핑될 수 있도록 보장하지 않으며, 동일한 경제 개념을 프로토콜 간 일관된 인터페이스를 통해 검색할 수 있도록 보장하지도 않는다.
따라서 시장, 포지션, 건강 계수 등 추상적 개념은 프로토콜 원시 요소가 아니다. 이들은 인덱서, 데이터 분석 플랫폼, 프론트엔드 인터페이스, 애플리케이션 인터페이스 등 체인 외부에서 재구성되어 이질적인 프로토콜 상태를 사용 가능한 추상화로 전환한다. 인간 사용자는 일반적으로 이 표준화된 계층만을 본다. 에이전트도 이 계층을 사용할 수 있지만, 이 경우 제3자 모델, 지연, 신용 가정을 함께 물려받게 된다. 그렇지 않다면, 에이전트는 이러한 추상화를 스스로 재구성해야 한다.
이 문제는 다양한 프로토콜에서 점점 더 두드러지고 있다. 금고의 주식 가격, 대출 시장의 담보율, 탈중앙화 거래소 자금풀의 유동성 심도, 스테이킹 계약의 보상률 등은 모두 경제적 의미를 갖는 기본 구성요소이지만, 표준화된 인터페이스로 노출되지 않는다. 각 프로토콜은 각자의 획득 방식, 구조 배치, 단위 관례를 갖춘다. 동일한 유형 내에서도 구현 방식이 다를 수 있다.
대출 시장: 조각화된 검색의 전형적 사례
대출 시장은 이 문제를 명확히 보여준다. 이 시장의 경제적 개념은 보편적이고 대체로 통일되어 있으며, 예를 들어 공급 및 대출 유동성, 이자율, 담보율, 한도 상한, 청산 임계값 등이 있다. 그러나 이들을 획득하는 경로는 각기 다르다.
Aave v3에서는 시장 열거 및 예비 자산 상태 획득이 두 개의 독립된 단계이다. 전형적인 절차는 다음과 같다:
다음과 같은 방식으로 예비 자산을 열거하여 토큰 주소 배열을 반환한다.
각 자산에 대해 또 다른 코드 조각을 사용하여 유동성 및 이자율 기본 데이터를 획득한다.
이 방법은 유동성 총량, 이자율 지수, 구성 플래그를 포함한 구조체를 단일 호출로 반환한다. 예시:
반면 Compound v3에서는 각 배포가 단일 시장(USDC, USDT, ETH 등)에 해당하며, 통일된 예비 자산 구조체가 없다. 대신, 여러 함수 호출을 통해 시장 스냅샷을 조합해야 한다:
- 기본 이용률
- 총량
- 이자율
- 담보 자산 구성
- 전역 구성 매개변수
각 호출은 경제 상태의 서로 다른 부분집합만을 반환한다. ‘시장’은 1차 객체가 아니라 호출자가 조합하여 추론한 구조이다.
에이전트 관점에서 보면 두 프로토콜 모두 대출 시장이지만, 통합 관점에서는 구조가 완전히 다른 획득 시스템이다. 통일된 공유 패턴은 존재하지 않는다. 대신 에이전트는 서로 다른 프로토콜에 대해 서로 다른 자산 열거 방식을 채택하고, 여러 호출을 통해 상태를 조합해야 한다.
조각화로 인한 지연 및 일관성 위험
구조적 불일치 외에도, 이러한 조각화는 지연 및 일관성 위험을 유발한다. 경제 상태가 단일 원자화된 시장 객체로 노출되지 않기 때문에, 에이전트는 여러 계약을 걸쳐 스냅샷을 재구성하기 위해 여러 차례의 원격 프로시저 호출(RPC)을 수행해야 한다. 호출이 한 번 더 추가될수록 지연, 요청 제한 위험, 블록 불일치 확률이 증가한다. 변동성이 큰 환경에서는 공급 이자율 계산이 완료되었을 때 이미 이자율이 변했을 수 있다. 블록을 명시적으로 고정하지 않으면, 구성 매개변수가 유동성 총량과 다른 블록 높이에 대응할 수 있다. 사용자는 UI 캐시 계층과 집계 백엔드를 통해 이러한 문제를 간접적으로 완화한다. 원시 RPC 인터페이스를 직접 조작하는 에이전트는 동기화, 배치 처리, 시간 일관성을 명시적으로 관리해야 한다. 따라서 표준화되지 않은 검색은 단순히 통합의 불편함을 초래하는 것이 아니라, 성능, 동기화, 정확성까지 제한한다.
규범적인 경제 데이터 검색 방안이 부재함에 따라, 프로토콜이 거의 동일한 금융 원시 요소를 구현하더라도, 그 상태 노출은 계약의 구체적인 상황과 구성 방식에 따라 달라진다. 이러한 구조적 차이가 바로 데이터 마찰의 핵심 구성 요소이다.
잠재적 데이터 흐름 불일치
블록체인 상의 경제 상태 접근은 본질적으로 풀(pull) 모드이며, 실행 신호가 스트리밍될 수 있음에도 불구하고 그렇다. 외부 시스템은 필요한 상태를 노드에 질의하는 반면, 지속적이고 구조화된 업데이트를 수신하지는 않는다. 이 모드는 블록체인의 핵심 기능—필요에 따라 검증하는 것—을 반영하며, 애플리케이션 수준의 지속적인 상태 뷰를 유지하지는 않는다.
푸시(push) 방식의 원시 요소는 존재한다. WebSocket 구독을 통해 새 블록 및 이벤트 로그를 실시간으로 스트리밍할 수 있지만, 대부분의 경제적 의미를 담고 있는 저장 상태는 포함하지 않으며, 프로토콜이 명시적으로 중복 게시하기로 선택하지 않는 한 그렇다. 에이전트는 체인 상에서 대출 시장 이용률, 자금풀 예비 자산, 포지션 건강 계수를 직접 구독할 수 없다. 이러한 값은 계약 저장소에 저장되어 있으며, 대부분의 프로토콜은 하류 사용자에게 이러한 정보를 푸시하기 위한 원시 메커니즘을 제공하지 않는다. 현재 최선의 방법은 새 블록 헤더를 구독하고, 각 블록마다 다시 질의하는 것이다. 로그는 상태가 변경되었을 수 있음을 알릴 뿐이며, 최종 경제 상태를 인코딩하지는 않는다. 해당 상태를 재구성하려면 여전히 명시적인 읽기 및 과거 상태 접근이 필요하다.
에이전트 시스템은 역방향 프로세스에서 이득을 볼 수 있다. 에이전트는 수백 개의 계약 상태 변경을 폴링하는 대신, 구조화되고 사전 계산된 상태 업데이트를 직접 실행 환경으로 푸시받을 수 있다. 푸시 기반 아키텍처는 중복 질의를 줄이고, 상태 변경과 에이전트 인식 간 지연을 낮추며, 중간 계층이 상태를 의미론적으로 명확한 업데이트로 패키징할 수 있게 해준다. 이는 에이전트가 원시 저장소에서 의미를 해석하는 대신 가능하게 한다.
이러한 역방향 전환은 쉽지 않다. 구독 인프라, 관련성 필터링 논리, 저장소 변경을 에이전트가 실행 가능한 경제 이벤트로 변환하는 패턴이 필요하다. 그러나 에이전트가 간헐적 질의자가 아니라 지속적인 참여자가 되어감에 따라, 풀 모드의 비효율성 비용은 점점 더 커진다. 에이전트를 지속적인 소비자로, 간헐적 클라이언트가 아니라 인프라를 설계하는 것이 자율 시스템의 작동 방식에 더 부합할 수 있다.
푸시 기반 인프라가 정말 더 우수한지는 여전히 미해결 문제이다. 방대한 상태 변경은 필터링 난제를 야기하며, 에이전트는 여전히 어떤 변경이 관련 있는지를 판단해야 하므로, 이는 또 다른 차원에서 풀 방식의 의미론을 다시 도입한다. 핵심은 풀 아키텍처 자체에 문제가 있는 것이 아니라, 현재 아키텍처가 지속적인 기계 소비자를 고려하지 않고 설계되었다는 데 있다. 에이전트 사용 규모가 커짐에 따라 다른 대체 모델을 탐색해볼 가치가 있다.
실행 마찰
실행 마찰은 현재 많은 상호작용 계층이 의도 변환, 거래 검토, 결과 검증을 프론트엔드 인터페이스, 월렛, 운영자 감독을 중심으로 설계된 워크플로우에 통합시키기 때문에 발생한다. 소매 투자자 및 주관적 의사결정 시나리오에서는 이러한 감독이 일반적으로 인간에 의해 수행된다. 자율 시스템의 경우, 이러한 기능은 형식화되어 직접 코딩되어야 한다. 블록체인은 계약 로직에 따라 결정론적 실행을 보장하지만, 거래가 사용자 의도에 부합하거나 리스크 제약을 준수하거나 예상 경제적 결과를 달성한다고 보장하지 않는다. 현재 프로세스에서는 프론트엔드 인터페이스와 인간이 이 격차를 메운다.
프론트엔드 인터페이스는 작업 시퀀스(교환, 승인, 입금, 대출 등)를 조합하고, 월렛은 최종 ‘검토 및 전송’ 단계를 제공한다. 사용자 또는 운영자는 마지막 단계에서 비공식적으로 전략적 판단을 내린다. 그들은 정보가 불완전한 상황에서 거래가 안전한지, 제시된 결과가 수용 가능한지 판단한다. 거래가 실패하거나 예기치 않은 결과가 발생하면, 사용자는 재시도하거나 슬리피지(slippage)를 조정하거나 경로를 변경하거나 작업을 포기한다. 에이전트 시스템은 인간을 이 실행 루프에서 제거한다. 이는 시스템이 다음 세 가지 인간 기능을 기계 원시 방식으로 대체해야 함을 의미한다:
- 의도 통합. ‘내 안정화 토큰을 리스크 조정 후 최적 수익 장소로 이전한다’는 인간의 목표는 구체적인 실행 계획으로 통합되어야 한다: 어떤 프로토콜, 어떤 시장, 어떤 토큰 경로, 어느 규모, 어떤 승인, 어떤 실행 순서를 선택할 것인가. 인간의 경우 이 과정은 프론트엔드 인터페이스를 통해 암묵적으로 완료되지만, 에이전트의 경우 형식적으로 구현되어야 한다.
- 전략 실행. ‘거래 전송’ 버튼을 클릭하는 것은 단순한 서명이 아니라, 슬리피지 허용 범위, 레버리지 상한, 최소 건강 계수, 화이트리스트 계약, ‘업그레이드 가능한 계약 금지’ 등 제약 조건을 암묵적으로 검사하는 것이다. 에이전트는 명시적인 전략 제약을 기계가 검증 가능한 규칙으로 코딩해야 한다:
- 실행 시스템은 제안된 호출 그래프가 이러한 규칙을 충족하는지 검증한 후에야 브로드캐스트할 수 있다.
- 결과 검증. 거래가 체인에 포함되었다고 해서 작업이 완료된 것은 아니다. 거래 실행이 성공하더라도 목표를 달성하지 못할 수 있다: 슬리피지가 허용 범위를 초과했을 수 있고, 한도 제한으로 인해 목표 포지션 규모에 도달하지 못했을 수 있으며, 시뮬레이션과 체인 상 실행 사이에 이자율이 변했을 수 있다. 인간은 이후 프론트엔드 인터페이스를 통해 비공식적으로 검증한다. 에이전트는 후조건(post-condition)을 프로그래밍 방식으로 평가해야 한다.
이것은 단순한 트랜잭션 포함 이상의 ‘완료 검사’ 요구를 도입한다. 의도 중심 아키텍처는 ‘어떻게’ 실행하는 데 대한 부담의 상당 부분을 에이전트에서 전문 솔버(solver)로 이전함으로써 이 문제를 부분적으로 해결할 수 있다. 원시 호출 데이터가 아니라 서명된 의도를 브로드캐스트함으로써, 에이전트는 결과 기반 제약 조건을 지정할 수 있으며, 솔버 또는 프로토콜 수준 메커니즘은 실행을 수용하기 위해 이러한 제약 조건을 충족해야 한다.
다단계 워크플로우 및 오류 모드
탈중앙화 금융의 대부분의 실행 작업은 본질적으로 다단계이다. 수익 배치 하나가 승인 → 교환 → 입금 → 대출 → 스테이킹을 포함할 수 있다. 일부 단계는 독립적인 거래일 수 있고, 다른 단계는 멀티콜(multicall) 또는 라우팅 계약을 통해 패키징될 수 있다. 인간은 부분 완료를 용인하고, 프론트엔드 인터페이스로 돌아가 계속 진행할 수 있다. 에이전트는 결정론적 프로세스 오케스트레이션이 필요하다: 어떤 단계라도 실패하면, 에이전트는 재시도, 재라우팅, 롤백, 또는 일시 중단을 결정해야 한다.
이는 인간 프로세스에서 대부분 은폐되어 있던 새로운 오류 모드를 촉발한다:
- 의사결정과 체인 상 실행 사이의 상태 이탈. 시뮬레이션과 실행 사이에 이자율, 이용률, 유동성이 변경될 수 있다. 인간은 이러한 가변성을 받아들이지만, 에이전트는 수용 가능한 범위를 설정하고 강제로 시행해야 한다.
- 비원자 실행 및 부분 체결. 일부 작업은 여러 거래에 걸쳐 실행되거나 부분적인 결과를 생성할 수 있다. 에이전트는 중간 상태를 추적하고, 최종 상태가 목표와 일치하는지 확인해야 한다.
- 승인 한도 및 승인 리스크. 인간은 프론트엔드 인터페이스를 통해 무의식적으로 승인을 서명한다. 에이전트는 승인 범위(한도, 사용자, 기간)를 보안 정책의 일부로 추론해야 하며, 단순히 프론트엔드 인터페이스 단계로 보아서는 안 된다.
- 경로 선택 및 암묵적 실행 비용. 인간은 라우팅 계약 및 프론트엔드 인터페이스의 기본 설정에 의존한다. 에이전트는 슬리피지, 최대 탈취 가능 가치(MEV) 리스크, 가스 비용, 가격 영향을 목표 함수에 포함시켜야 한다.
실행: 기계 원시 제어 문제
실행 마찰의 핵심 주장은, 탈중앙화 금융의 상호작용 계층이 인간 월렛 서명을 최종 제어 평면으로 삼고 있다는 점이다. 이 단계는 현재의 의도 검증, 리스크 허용, 비공식적인 ‘합리한가’ 판단을 담당한다. 인간을 제거하면 실행은 제어 문제로 전환된다: 에이전트는 목표를 행동 패턴으로 전환하고, 전략 제약을 자동으로 실행하며, 불확실성 하에서 결과를 검증해야 한다. 이 도전은 많은 자율 시스템에서 존재하지만, 블록체인 환경은 특히 엄격하다: 실행은 자본을 직접적으로 포함하며, 낯선 계약과 조합 가능하고, 대립적 상태 변화에 노출된다. 인간은 경험칙(heuristic)을 통해 의사결정을 하고, 시행착오를 통해 오류를 수정한다. 에이전트는 기계 속도로 동일한 작업을 프로그래밍 방식으로 수행해야 하며, 일반적으로 동적으로 변화하는 행동 공간에서 그렇게 해야 한다. 따라서 ‘에이전트는 단지 거래를 제출하면 된다’는 말은 난이도를 과소평가한 것이다. 거래 제출은 가장 쉬운 부분이다.
결론
블록체인은 처음부터 에이전트가 필요로 하는 의미론적 및 협업 계층을 원시적으로 제공하도록 설계되지 않았다. 블록체인의 설계 목표는 대립적 환경에서 결정론적 실행 및 상태 전환 합의를 보장하는 것이다. 이 기반 위에 구축된 상호작용 계층은 인간 사용자가 인터페이스를 통해 상태를 해석하고, 프론트엔드 인터페이스를 통해 작업을 선택하며, 인간 검토를 통해 결과를 검증하는 방식으로 진화해왔다.
에이전트 시스템은 이 아키텍처를 전복시킨다. 에이전트는 인간 해석자, 승인자, 검증자를 루프에서 제거하고, 이러한 기능을 기계 원시 방식으로 구현하도록 요구한다. 이 전환은 네 가지 차원에서 구조적 마찰을 드러낸다: 탐지, 신용 판단, 데이터 획득, 실행 프로세스. 이러한 마찰은 실행 자체가 불가능하기 때문이 아니라, 블록체인 주변의 인프라가 대부분의 경우 여전히 상태 해석과 거래 제출 사이에 인간의 개입이 있다고 가정하기 때문이다.
이 격차를 해소하기 위해서는 다층 기술 스택 전반에 걸쳐 새로운 인프라를 구축해야 할 가능성이 높다: 프로토콜 간 경제 상태를 기계가 읽을 수 있는 중간웨어로 표준화하는 것; 포지션, 건강 계수, 기회 집합 등 의미론적 원시 요소를 위한 인덱싱 서비스 또는 원격 호출 확장; 표준 계약 매핑 및 토큰 진실성 검증을 제공하는 레지스트리; 전략 제약을 코딩하고, 다단계 워크플로우를 처리하며, 목표 달성 여부를 프로그래밍 방식으로 검증하는 실행 프레임워크. 일부 격차는 허가 없이 운영되는 시스템의 구조적 특성—즉, 개방적 배포, 표준 신원의 약함, 인터페이스의 이질성—에서 비롯된다. 또 다른 일부는 현재의 도구, 표준, 인센티브 설계에 달려 있으며, 에이전트 사용 규모가 확대되고 프로토콜이 자율 시스템에 대한 통합 친화성을 최적화하기 위해 경쟁함에 따라 이러한 격차는 좁아질 수 있다.
자율 시스템이 자본 관리, 전략 실행, 체인 상 애플리케이션과의 직접 상호작용을 시작함에 따라, 현재 상호작용 계층의 아키텍처 가정이 점점 더 두드러질 것이다. 본문에서 언급된 대부분의 마찰은 블록체인 도구 및 상호작용 모드가 인간 중개 워크플로우를 중심으로 진화해온 특성을 반영한다. 일부 마찰은 허가 없이 운영되는 시스템의 개방성, 이질성, 대립적 환경에서 비롯되며, 또 다른 일부는 복잡한 환경에서 자율 시스템이 일반적으로 직면하는 문제이다.
핵심 도전은 에이전트가 거래에 서명하도록 만드는 것이 아니라, 현재 블록체인 상태와 조작 행동 사이에서 소프트웨어와 인간 판단이 공동으로 담당하는 의미론적 해석, 신용 판단, 전략 실행 작업을 에이전트가 신뢰할 수 있는 방식으로 수행할 수 있도록 하는 것이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@galaxyhq
