AI 에이전트의 지속적인 하락은 최근 폭발적으로 인기를 끌고 있는 MCP 프로토콜 때문인가요?
Manus + MCP가 Web3 AI Agent가 이번에 타격을 입은 핵심이다.저자: Haotian
친구가 말하길, #ai16z, $arc와 같은 web3 AI 에이전트의 지속적인 하락은 최근 폭발적으로 인기를 끌고 있는 MCP 프로토콜 때문이라고? 처음 듣고는 조금 어리둥절했지만, WTF 이게 무슨 관계가 있지? 하지만 곰곰이 생각해보니, 확실히 일정한 논리가 있더라: 이미 존재하는 web3 AI 에이전트의 가치 평가 논리가 바뀌었고, 서사 방향과 제품 실현 경로를 조정할 필요가 있다! 아래는 개인적인 의견이다:
1) MCP(모델 컨텍스트 프로토콜)는 다양한 AI LLM/에이전트가 다양한 데이터 소스와 도구에 원활하게 연결될 수 있도록 하는 오픈 소스 표준화 프로토콜로, 일종의 플러그 앤 플레이 USB "범용" 인터페이스에 해당하며, 과거의 엔드 투 엔드 "특정" 포장 방식을 대체한다.
간단히 말해, 원래 AI 애플리케이션 간에는 명확한 데이터 고립이 있었고, 에이전트/LLM 간의 상호 통신을 위해서는 각자 해당 호출 API 인터페이스를 개발해야 했으며, 작업 프로세스가 복잡할 뿐만 아니라 쌍방향 상호작용 기능이 부족하여 일반적으로 상대적으로 제한된 모델 접근과 권한 제한이 있었다.
MCP의 출현은 AI 애플리케이션이 과거의 데이터 고립 상태에서 벗어나 외부 데이터와 도구에 "동적"으로 접근할 수 있는 가능성을 제공하는 통합 프레임워크를 제공하며, 개발 복잡성과 통합 효율성을 크게 낮출 수 있다. 특히 자동화된 작업 실행, 실시간 데이터 쿼리 및 크로스 플랫폼 협업 등에서 뚜렷한 촉진 효과가 있다.
이 말을 하니, 많은 사람들이 즉시 떠올릴 것이다. 여러 에이전트 협업 혁신의 Manus가 이 MCP 오픈 소스 프레임워크를 통합하면 여러 에이전트 협업을 촉진할 수 있을 텐데, 이게 무적이 아닐까?
맞다, Manus + MCP가 바로 web3 AI 에이전트가 이번에 충격을 받은 핵심이다.
2) 하지만, 기이한 것은 Manus와 MCP 모두 web2 LLM/에이전트를 위한 프레임워크와 프로토콜 표준이라는 점이다. 이들이 해결하는 것은 중앙화된 서버 간의 데이터 상호작용과 협업 문제이며, 그 권한과 접근 제어는 각 서버 노드의 "적극적인" 개방에 의존한다. 다시 말해, 이는 단순한 오픈 소스 도구 속성에 불과하다.
이론적으로 보면, 이는 web3 AI 에이전트가 추구하는 "분산 서버, 분산 협업, 분산 인센티브" 등의 중심 사상과 완전히 배치된다. 중앙화된 이탈리아 포탄이 어떻게 분산화된 요새를 폭파할 수 있을까?
그 이유는 첫 번째 단계의 web3 AI 에이전트가 너무 "web2화"되었기 때문이다. 한편으로는 많은 팀이 web2 배경에서 왔고, web3 네이티브의 원초적 요구에 대한 충분한 이해가 부족하다. 예를 들어, ElizaOS 프레임워크는 원래 개발자가 AI 에이전트 애플리케이션을 신속하게 배포할 수 있도록 돕는 포장 프레임워크로, Twitter, Discord 등 플랫폼과 OpenAI, Claude, DeepSeek 등의 "API 인터페이스"를 통합하여 일부 Memory, Character 범용 프레임워크를 적절히 포장하여 개발자가 AI 에이전트 애플리케이션을 신속하게 개발할 수 있도록 돕는다. 하지만 진지하게 생각해보면, 이 서비스 프레임워크와 web2의 오픈 소스 도구는 어떤 차이가 있을까? 또 어떤 차별화된 장점이 있을까?
어, 장점이란 Tokenomics 인센티브 방식이 있다는 것인가? 그리고 web2에서 완전히 대체할 수 있는 프레임워크로, 새 코인을 발행하기 위해 존재하는 AI 에이전트를 더 많이 유도하는 것인가? 무섭다.. 이 논리를 따라가면, 왜 Manus + MCP가 web3 AI 에이전트에 충격을 줄 수 있는지 대략 이해할 수 있다.
많은 web3 AI 에이전트 프레임워크와 서비스는 web2 AI 에이전트의 신속한 개발과 애플리케이션 요구만 해결했지만, 기술 서비스와 표준 및 차별화된 장점에서 web2의 혁신 속도를 따라가지 못했기 때문에 시장/자본은 이전의 web3 AI 에이전트를 재평가하고 가격을 매겼다.
3) 이 말을 하니, 대략적인 문제의 본질을 찾았을 것이다. 하지만 어떻게 해결할 수 있을까? 한 가지 길이 있다: web3 네이티브 솔루션에 집중하는 것이다. 분산 시스템의 운영과 인센티브 구조가 바로 web3의 절대적인 차별화된 장점이기 때문이다.
분산 클라우드 컴퓨팅, 데이터, 알고리즘 등의 서비스 플랫폼을 예로 들면, 겉보기에는 이러한 유휴 자원을 이유로 모인 컴퓨팅 파워와 데이터가 단기적으로는 공학적 혁신의 필요를 충족할 수 없지만, 많은 AI LLM이 중앙화된 컴퓨팅 파워로 성능 돌파 군비 경쟁을 벌이고 있을 때, "유휴 자원, 저비용"을 내세운 서비스 모델은 자연스럽게 web2 개발자와 VC 팀에게 무시당할 것이다.
하지만 web2 AI 에이전트가 성능 혁신의 단계를 지나면, 반드시 수직 애플리케이션 장면 확장과 세분화된 미세 조정 모델 최적화 등의 방향을 추구하게 될 것이며, 그때야 비로소 web3 AI 자원 서비스의 장점이 진정으로 드러날 것이다.
사실, 자원 독점 방식으로 거대 기업 위치에 오른 web2 AI가 일정 단계에 이르면, 다시는 농촌이 도시를 포위하는 사고방식으로 돌아가 세분화된 장면을 하나하나 무너뜨릴 수 없다. 그때가 바로 과잉된 web2 AI 개발자와 web3 AI 자원이 힘을 합치는 때이다.
사실, web3 AI 에이전트는 web2의 신속한 배포 + 다수 에이전트 협업 통신 프레임워크 + Tokenomic 발행 서사 외에도 탐색할 가치가 있는 많은 web3 네이티브 혁신 방향이 있다:
예를 들어, 분산 합의 협업 프레임워크를 갖추고, LLM 대모델의 오프체인 계산 + 온체인 상태 저장의 특성을 고려하여 많은 적응성 구성 요소가 필요하다.
탈중앙화된 DID 신원 인증 시스템으로, 에이전트가 검증 가능한 온체인 신원을 가질 수 있도록 하며, 이는 스마트 계약을 위한 유일한 주소를 생성하는 실행 가상 머신과 유사하다. 이는 후속 상태의 지속적인 추적과 기록을 주로 위해서이다;
탈중앙화된 오라클 예언기 시스템으로, 주로 오프체인 데이터의 신뢰할 수 있는 수집과 검증을 담당하며, 기존의 오라클과는 달리, 이 AI 에이전트에 적합한 오라클은 데이터 수집 계층, 의사결정 합의 계층, 실행 피드백 계층 등 여러 에이전트의 조합 구조를 필요로 하여, 에이전트의 온체인 데이터와 오프체인 계산 및 의사결정이 실시간으로 도달할 수 있도록 한다;
탈중앙화된 저장 DA 시스템으로, AI 에이전트 실행 시의 지식베이스 상태에 불확실성이 존재하고, 추론 과정도 임시적이기 때문에, LLM 뒤의 핵심 상태베이스와 추론 경로를 기록하여 분산 저장 시스템에 저장하고, 비용을 통제할 수 있는 데이터 증명 메커니즘을 제공하여 공공 블록체인 검증 시 데이터의 가용성을 보장해야 한다;
제로 지식 증명 ZKP 프라이버시 계산 계층으로, TEE 시점, FHE 등을 포함한 프라이버시 계산 솔루션과 연동하여 실시간 프라이버시 계산 + 데이터 증명 검증을 구현하여 에이전트가 더 넓은 수직 데이터 출처(의료, 금융)를 가질 수 있도록 하여, 그 위에 더 많은 전문 맞춤형 서비스 에이전트가 등장할 수 있다;
크로스 체인 상호 운용성 프로토콜로, MCP 오픈 소스 프로토콜이 정의한 프레임워크와 유사하지만, 이 상호 운용성 솔루션은 에이전트의 실행, 전달, 검증을 위한 릴레이 및 통신 스케줄링 메커니즘이 필요하여, 에이전트가 서로 다른 체인 간의 자산 이동과 상태 동기화 문제를 해결할 수 있도록 한다. 특히 에이전트의 컨텍스트와 프롬프트, 지식베이스, Memory 등 복잡한 상태를 포함한다;
……
내가 보기에는 진정한 web3 AI 에이전트의 핵심은 AI 에이전트의 "복잡한 작업 흐름"과 블록체인의 "신뢰 검증 흐름"이 최대한 일치하도록 하는 것이다. 이러한 증분 솔루션이 기존의 구형 서사 프로젝트에서 업그레이드된 것인지, 아니면 새롭게 구성된 AI 에이전트 서사 트랙의 프로젝트에서 다시 만들어진 것인지 모두 가능성이 있다.
이것이 바로 web3 AI 에이전트가 노력해야 할 방향이며, AI + Crypto라는 대宏관 서사 아래의 혁신 생태계의 기본 면모에 부합하는 것이다. 만약 관련된 혁신 개척과 차별화된 경쟁 장벽을 구축하지 못한다면, 매번 web2 AI 트랙의 바람이 불 때마다 web3 AI가 뒤집힐 수 있다.
