AI 에이전트 프레임워크가 퍼즐의 마지막 조각일까? 프레임워크의 '파동-입자 이중성'은 어떻게 해석해야 할까?
글: 케빈, 블록부스터 리서처
AI 에이전트 프레임워크는 산업 발전의 핵심 조각으로, 기술 실현과 생태계 성숙을 동시에 추진할 가능성을 지니고 있다. 시장에서 주목받는 주요 프레임워크로는 Eliza, Rig, Swarms, ZerePy 등이 있으며, 이들은 깃허브 저장소(GitHub Repo)를 통해 개발자들을 유치하고 명성을 쌓아가고 있다. '라이브러리' 형태로 토큰화하는 방식은 마치 빛이 파동과 입자의 이중성을 가지듯, 에이전트 프레임워크 역시 진지한 외부성(externalities)과 메모코인(Memecoin) 특성을 동시에 지닌다. 본 글에서는 이러한 프레임워크의 '파동-입자 이중성'과 왜 에이전트 프레임워크가 마지막 조각이 될 수 있는지를 집중적으로 분석하고자 한다.
에이전트 프레임워크가 가져오는 외부성은 거품이 가라앉은 후에도 새싹을 남긴다
GOAT가 등장한 이후로, 에이전트 서사(narrative)는 점점 더 강력하게 시장을 충격하고 있다. 이는 마치 한 손에는 '메모코인'이라는 주먹을, 다른 손에는 '산업적 희망'이라는 장력을 지닌 무술 대가와 같아서, 누구든 그 중 하나에 압도당하기 쉽다. 사실상 AI 에이전트의 활용 사례는 아직 명확히 구분되지 않았으며, 플랫폼·프레임워크·구체적인 애플리케이션 사이의 경계는 모호하다. 하지만 토큰 또는 프로토콜의 발전 방향에 따라 다음과 같이 대략적으로 분류할 수 있다:
-
런치패드(Launchpad): 자산 발행 플랫폼. Base 체인의 Virtuals Protocol과 clanker, Solana 체인의 Dasha 등.
-
AI 에이전트 애플리케이션: 에이전트와 메모코인 사이를 오가는 형태로, 메모리 구성에서 두각을 나타낸다. 예를 들어 GOAT, aixbt 등이 있다. 일반적으로 단방향 출력이며 입력 조건이 매우 제한적이다.
-
AI 에이전트 엔진: Solana 체인의 griffain 및 Base 체인의 Spectre AI. griffain은 읽기·쓰기 모드에서 읽기·쓰기·실행 모드로 진화할 수 있으며, Spectre AI는 RAG 엔진으로 체인 상 검색 기능을 제공한다.
-
AI 에이전트 프레임워크: 프레임워크 플랫폼 입장에서는 에이전트 자체가 자산이므로, 에이전트 프레임워크는 곧 에이전트의 자산 발행 플랫폼, 즉 에이전트용 Launchpad라 할 수 있다. 현재 대표적인 사례로는 ai16z, Zerebro, ARC 및 최근 화제가 된 Swarms가 있다.
-
기타 소규모 방향: 종합형 에이전트 Simmi; AgentFi 프로토콜 Mode; 반증형 에이전트 Seraph; 실시간 API 에이전트 Creator.Bid 등.
에이전트 프레임워크를 좀 더 깊이 살펴보면, 이들이 상당한 외부성을 지닌다는 것을 알 수 있다. 다양한 공개 블록체인 및 프로토콜의 개발자들이 특정 개발 언어 환경 내에서만 선택할 수 있는 것과 달리, 전체 산업의 개발자 규모는 시가총액 증가율만큼 성장하지 못했다. 깃허브 저장소는 Web2와 Web3 개발자들이 컨센서스를 형성하는 장소이며, 여기서 개발자 커뮤니티를 구축하는 것은 어떤 프로토콜이 혼자 만들어 낸 '그냥 꽂아 쓰는' 패키지보다 Web2 개발자들에게 훨씬 더 큰 매력과 영향력을 행사한다.
본문에서 언급된 4개의 프레임워크 모두 오픈소스로 공개되어 있다: ai16z의 Eliza 프레임워크는 6,200개의 스타를, Zerebro의 ZerePy 프레임워크는 191개의 스타를, ARC의 RIG 프레임워크는 1,700개의 스타를, Swarms의 Swarms 프레임워크는 2,100개의 스타를 받았다. 현재 Eliza 프레임워크는 다양한 에이전트 애플리케이션에 널리 사용되며 가장 폭넓은 적용 범위를 지닌다. ZerePy는 개발 수준이 다소 낮으며 주로 X(트위터) 중심으로 방향을 잡고 있으며, 로컬 LLM 및 통합 메모리를 아직 지원하지 않는다. RIG는 상대적으로 개발 난이도가 가장 높지만, 개발자에게 최대한의 성능 최적화 자유를 부여한다. Swarms는 팀이 mcs를 출시한 외에는 아직 다른 실제 사례가 없으나, 여러 프레임워크를 통합할 수 있어 상상력이 풍부한 여지를 제공한다.
또한 위 분류에서 에이전트 엔진과 프레임워크를 별도로 나누는 것이 혼란스러울 수 있으나, 필자는 두 개념 사이에 차이가 있다고 본다. 우선 왜 '엔진'이라 부르는가? 현실 세계의 검색 엔진을 떠올려 비교하면 적절하다. 동질화된 에이전트 애플리케이션과 달리, 에이전트 엔진은 더 높은 성능을 제공하지만, 동시에 완전히 캡슐화된 블랙박스로서 API 인터페이스를 통해 조정된다. 사용자는 포크(fork) 형태로 엔진의 성능을 경험할 수 있지만, 기본 프레임워크처럼 전반적인 구조를 파악하거나 자유롭게 커스터마이징할 수는 없다. 각 사용자의 엔진은 미리 조정된 에이전트 위에 생성된 이미지와 같으며, 이 이미지와 상호작용하는 것이다. 반면 프레임워크는 근본적으로 체인에 맞추기 위한 것이며, 에이전트를 위해 에이전트 프레임워크를 만드는 궁극적 목적은 해당 체인과의 통합이다. 데이터 상호작용 방식, 데이터 검증 방식, 블록 크기 정의, 합의와 성능 간 균형 등을 어떻게 설정할지는 프레임워크가 고려해야 할 문제다. 반면 엔진은 특정 방향에서 모델을 세밀하게 튜닝하고, 데이터 상호작용과 메모리 관계를 설정하는 데 집중하며, 성능이 유일한 평가 기준이다. 프레임워크는 그렇지 않다.
에이전트 프레임워크를 평가할 때 '파동-입자 이중성'의 관점을 채택하는 것이 올바른 방향성을 보장하는 전제일 수 있다
에이전트가 입력-출력 생명주기를 수행하려면 세 가지 요소가 필요하다. 먼저 하위층 모델이 사고의 깊이와 방식을 결정하며, 다음으로 메모리는 사용자 정의가 가능한 부분으로, 기본 모델이 출력한 후 메모리를 기반으로 수정이 이루어지고, 마지막으로 다양한 클라이언트에서 출력 작업을 완료한다.
출처: @SuhailKakar
에이전트 프레임워크가 '파동-입자 이중성'을 갖는다는 것을 입증하기 위해, '파동(wave)'은 '메모코인' 특성을 지니며, 커뮤니티 문화와 개발자 활성도를 의미하여 에이전트의 매력도와 전파력을 강조한다. 반면 '입자(particle)'는 '산업적 기대'를 나타내며, 하위층 성능, 실제 사례, 기술적 깊이를 의미한다. 아래에서는 세 가지 프레임워크의 개발 튜토리얼을 예로 들어 두 관점에서 설명하겠다:
빠른 조합형 Eliza 프레임워크
1. 환경 설정
출처: @SuhailKakar
2. Eliza 설치
출처: @SuhailKakar
3. 설정 파일
출처: @SuhailKakar
4. 에이전트 성격 설정
출처: @SuhailKakar
Eliza 프레임워크는 상대적으로 사용하기 쉬운 편이다. TypeScript 기반으로 되어 있어 대부분의 Web 및 Web3 개발자가 익숙한 언어를 사용한다. 프레임워크가 간결하고 과도한 추상화가 없어 개발자가 원하는 기능을 쉽게 추가할 수 있다. 3단계에서 확인할 수 있듯이 Eliza는 다수의 클라이언트와 통합 가능하며, 이를 다중 클라이언트 통합 어셈블러로 이해할 수 있다. Eliza는 DC, TG, X 등의 플랫폼을 지원하며, 다양한 대규모 언어 모델(LLM)도 지원한다. 위 소셜미디어를 통해 입력을 받고, LLM 모델을 통해 출력하며, 내장 메모리 관리 기능도 지원하여 개발자가 자신의 습관에 맞춰 빠르게 AI 에이전트를 배포할 수 있다.
프레임워크의 간편성과 풍부한 인터페이스 덕분에 Eliza는 진입 장벽을 크게 낮추었으며, 상대적으로 통일된 인터페이스 표준을 실현했다.
원클릭 사용형 ZerePy 프레임워크
1. ZerePy 저장소 포크(Fork)
출처: https://replit.com/@blormdev/ZerePy?v=1
2. X와 GPT 설정
출처: https://replit.com/@blormdev/ZerePy?v=1
3. 에이전트 성격 설정
출처: https://replit.com/@blormdev/ZerePy?v=1
성능 최적화형 Rig 프레임워크
RAG(검색 증강 생성) 에이전트 구축을 예로 들면:
1. 환경 및 OpenAI 키 설정
출처: https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422
2. OpenAI 클라이언트 설정 및 Chunking을 이용한 PDF 처리
출처: https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422
3. 문서 구조 및 임베딩 설정
출처: https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422
4. 벡터 저장소 및 RAG 에이전트 생성
출처: https://dev.to/0thtachi/build-a-rag-system-with-rig-in-under-100-lines-of-code-4422
Rig(ARC)는 Rust 언어 기반의 LLM 워크플로우 엔진을 지향하는 AI 시스템 구축 프레임워크로, 더 하위층의 성능 최적화 문제를 해결하는 것을 목표로 한다. 즉, ARC는 AI 엔진용 '툴킷'으로, AI 호출, 성능 최적화, 데이터 저장, 예외 처리 등 백엔드 지원 서비스를 제공한다.
Rig는 '호출' 문제를 해결하여 개발자가 LLM을 더 잘 선택하고, 프롬프트를 최적화하며, 토큰을 효율적으로 관리하고, 동시 처리, 자원 관리, 지연 시간 감소 등을 다룰 수 있도록 돕는다. 초점은 AI LLM 모델과 AI 에이전트 시스템이 협력할 때 '잘 사용하는 것'에 있다.
Rig는 오픈소스 Rust 라이브러리로, LLM 기반 애플리케이션(RAG 에이전트 포함) 개발을 단순화하는 것을 목표로 한다. Rig는 개방성이 깊기 때문에 개발자에게 더 높은 요구사항을 두며, Rust와 에이전트에 대한 이해도 또한 높아야 한다. 이 튜토리얼은 가장 기초적인 RAG 에이전트 설정 과정이며, RAG는 LLM과 외부 지식 검색을 결합해 LLM을 강화한다. 공식 홈페이지의 다른 데모를 보면 Rig는 다음과 같은 특징을 가진다:
-
통합 LLM 인터페이스: 다양한 LLM 제공업체에 대해 일관된 API를 지원하여 통합을 단순화한다.
-
추상화된 워크플로우: 사전 구축된 모듈형 컴포넌트를 통해 Rig는 복잡한 AI 시스템 설계를 수용할 수 있다.
-
벡터 저장소 통합: 내장형 벡터 저장소 지원으로 RAG 에이전트와 유사한 검색형 에이전트에서 고성능을 제공한다.
-
유연한 임베딩: 임베딩 처리를 위한 쉬운 API를 제공하여 RAG 에이전트 등 검색형 에이전트 개발 시 의미 이해 난이도를 낮춘다.
Eliza와 비교했을 때 Rig는 개발자에게 추가적인 성능 최적화 공간을 제공하며, LLM과 에이전트의 호출 및 협업 최적화를 더 잘 디버깅할 수 있도록 도와준다. Rig는 Rust 기반의 성능, Rust의 장점을 활용한 제로 비용 추상화, 메모리 안정성, 고성능, 저지연 LLM 작업을 통해 하위층에서 더욱 풍부한 자유도를 제공한다.
분해 조합형 Swarms 프레임워크
Swarms는 기업급 생산 수준의 다중 에이전트 오케스트레이션 프레임워크를 제공하는 것을 목표로 하며, 공식 홈페이지에는 수십 가지의 워크플로우와 에이전트의 병렬·직렬 아키텍처가 소개되어 있다. 여기서 일부만 소개한다.
순차적 워크플로우 (Sequential Workflow)
출처: https://docs.swarms.world
순차 스웜 아키텍처는 선형 순서로 작업을 처리한다. 각 에이전트는 결과를 체인의 다음 에이전트에게 전달하기 전에 자신의 작업을 완료한다. 이 아키텍처는 작업에 의존성이 있을 때 유용하며, 순서 있는 처리를 보장한다.
사례:
-
조립 라인 또는 순차적 데이터 처리와 같이 각 단계가 이전 단계에 의존하는 워크플로우.
-
작업 순서를 엄격히 준수해야 하는 상황.
계층형 아키텍처:
출처: https://docs.swarms.world
상위 에이전트가 하위 에이전트들의 작업을 조율하는 수직적 통제 구조를 구현한다. 각 에이전트가 동시에 작업을 수행한 후 결과를 피드백 루프로 돌려 최종 집계를 한다. 이는 고도로 병렬화 가능한 작업에 매우 유용하다.
전자표 계층형 아키텍처:
출처: https://docs.swarms.world
수천 개의 에이전트를 동시에 관리하는 대규모 그룹 아키텍처로, 각 에이전트가 독립된 스레드에서 실행된다. 대규모 에이전트 출력을 감독하기에 이상적이다.
Swarms는 단순한 에이전트 프레임워크를 넘어 Eliza, ZerePy, Rig 프레임워크까지 호환 가능하며, 모듈화 사고방식을 통해 다양한 워크플로우와 아키텍처에서 에이전트 성능을 극대화하여 문제를 해결한다. Swarms의 개념과 개발자 커뮤니티 진전은 문제가 없다.
-
Eliza: 사용 편의성이 가장 높으며, 초보자 및 빠른 프로토타이핑 개발에 적합하다. 특히 소셜미디어 플랫폼에서의 AI 상호작용에 적합하다. 프레임워크가 간결하고 빠른 통합과 수정이 용이하며, 과도한 성능 최적화가 필요 없는 시나리오에 적합하다.
-
ZerePy: 원클릭 배포가 가능하여 Web3 및 소셜 플랫폼용 AI 에이전트 앱의 신속한 개발에 적합하다. 경량 AI 애플리케이션에 적합하며, 프레임워크가 단순하고 구성이 유연하여 빠른 구축과 반복 개발에 적합하다.
-
Rig: 성능 최적화에 중점을 두며, 고병렬 및 고성능 작업에서 두각을 나타낸다. 세밀한 제어와 최적화가 필요한 개발자에게 적합하다. 프레임워크가 다소 복잡하여 일정 수준의 Rust 지식이 필요하며, 더 경험이 많은 개발자에게 적합하다.
-
Swarms: 기업급 애플리케이션에 적합하며, 다중 에이전트 협업과 복잡한 작업 관리를 지원한다. 프레임워크가 유연하고 대규모 병렬 처리를 지원하며 다양한 아키텍처 구성이 가능하지만, 복잡성으로 인해 효과적으로 활용하려면 더 강한 기술적 역량이 필요할 수 있다.
전반적으로 Eliza와 ZerePy는 사용 편의성과 신속한 개발 측면에서 우위를 점하고 있으며, Rig와 Swarms는 고성능과 대규모 처리가 필요한 전문 개발자나 기업 애플리케이션에 더 적합하다.
이것이 바로 에이전트 프레임워크가 '산업적 희망' 특성을 지닌 이유다. 위 프레임워크들은 아직 초기 단계에 있으며, 당면 과제는 선발 주자로서의 우위를 확보하고 활발한 개발자 커뮤니티를 구축하는 것이다. 프레임워크 자체의 성능이 높은지, 혹은 Web2의 인기 앱에 비해 뒤떨어지는지 여부는 주요 모순이 아니다. 개발자가 끊임없이 유입되는 프레임워크만이 결국 승리할 수 있다. Web3 산업은 항상 시장의 주목을 받아야 하며, 프레임워크 성능이 아무리 뛰어나고 기본이 탄탄해도 접근성이 낮아 관심을 받지 못한다면 본말 전도가 된다. 프레임워크 자체가 개발자를 유치할 수 있다는 전제 하에, 더 성숙하고 완전한 토큰 이코노미 모델을 갖춘 프레임워크가 두각을 나타낼 것이다.
한편 에이전트 프레임워크가 '메모코인' 특성을 지닌다는 점은 매우 쉽게 이해할 수 있다. 위 프레임워크들의 토큰은 합리적인 토큰 이코노미 설계가 없으며, 토큰 용례가 없거나 매우 단일화되어 있고, 검증된 비즈니스 모델도 없으며, 효과적인 토큰 플라이휠도 존재하지 않는다. 프레임워크는 오직 프레임워크일 뿐, 토큰과 유기적으로 결합되지 않았다. 토큰 가격 상승은 FOMO 외에는 기본적인 뒷받침을 받기 어렵고, 안정적이고 지속적인 가치 상승을 보장할 만한 충분한 성을 마련하지 못했다. 또한 위 프레임워크 자체도 다소 거칠며, 실제 가치와 현재 시가총액이 맞지 않기 때문에 강한 '메모코인' 특성을 지닌다.
주목할 점은, 에이전트 프레임워크의 '파동-입자 이중성'이 결코 단점이 아니라는 것이다. 이를 단순히 순수한 메모코인이 아니면서 토큰 용례도 없는 반쯤 찬 물로 이해해서는 안 된다. 필자가 이전 글에서 언급했던 바와 같이, 경량화된 에이전트는 모호한 메모코인의 베일을 두르고 있으며, 커뮤니티 문화와 기본적 실체는 더 이상 모순되지 않는다. 새로운 자산 발전 경로가 서서히 드러나고 있다. 비록 에이전트 프레임워크 초기에는 거품과 불확실성이 존재하지만, 개발자를 유치하고 애플리케이션 실현을 추진하는 잠재력은 무시할 수 없다. 앞으로 완성된 토큰 이코노미 모델과 강력한 개발자 생태계를 갖춘 프레임워크가 이 분야의 핵심 축이 될 가능성이 크다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
