Google ADK와 LangGraph, LlamaIndex로 보는 AI 에이전트 프레임워크 선택
Google ADK, LangGraph, LlamaIndex, CrewAI와 Llama Stack의 아키텍처·메모리·표준화 관점의 AI 에이전트 프레임워크 비교
2026-08-14 · 최초 발행 2026-05-05
2025년 4월 9일 Google이 Agent Development Kit(ADK)를 오픈소스로 공개한 뒤 2주 만에 GitHub 스타 8,200개를 얻었고, 현재는 15,600개 이상을 기록하고 있다. 같은 시기 OpenAI Codex CLI는 4월 오픈소스 공개 후 67,000개 스타에 도달했다. 반면 LangGraph는 Uber, Klarna, LinkedIn, JPMorgan 등 대형 기업의 프로덕션 환경에서 채택되며 다른 방식의 존재감을 만들었다.
이 흐름은 단순한 프레임워크 인기 경쟁이라기보다, 에이전트의 상태·도구·데이터·협업 방식을 어떤 구조로 운영할지에 대한 선택지의 확대에 가깝다.
프레임워크의 영향력은 스타 수만으로 판단하기 어렵다
2025년 기준 주요 오픈소스 에이전트 프레임워크의 흐름은 다음과 같다.
- OpenAI Codex CLI: 67,000+ 스타. 2025년 4월 오픈소스 공개 후 빠르게 증가했다.
- Google ADK: 15,600+ 스타. 2025년 4월 9일 출시 후 성장 중이다.
- Meta Llama Stack: 6,400+ 스타. 자체 호스팅과 오픈 가중치 모델에 초점을 둔다.
- LangGraph: 대형 기업 프로덕션 환경의 채택 사례가 많은 프레임워크다.
- LlamaIndex: 데이터 중심 RAG와 에이전트 워크플로우를 다룬다.
- CrewAI: 역할 기반 팀 구성으로 빠른 프로토타이핑을 지원한다.
실제 선택에서는 엔터프라이즈 도입 사례, 프로덕션 안정성, 아키텍처 혁신이 더 직접적인 기준이 된다. ADK가 짧은 기간에 주목받은 배경에는 Google Cloud와의 통합, 계층형 에이전트 트리, A2A와 MCP의 네이티브 지원이 있다.
Google ADK는 위임 구조와 이벤트 흐름을 함께 다룬다
ADK의 중심 구조는 계층적 에이전트 트리다. 복잡한 요청을 하위 작업으로 나누고, 개별 에이전트는 독립적으로 처리하되 루트 오케스트레이터가 전체 흐름을 조율한다.
Root Orchestrator (루트 오케스트레이터)
├── Sub-Agent 1 (전문 작업 담당)
├── Sub-Agent 2 (데이터 처리 담당)
└── Sub-Agent 3 (외부 API 연동 담당)
├── Child Agent 3-1 (특수 작업)
└── Child Agent 3-2 (특수 작업)
이 모델은 분산 실행과 중앙 조율을 함께 요구하는 작업에 맞는다. 하위 에이전트가 전문 작업, 데이터 처리, 외부 API 연동을 나누어 맡을 수 있고, 필요하면 하위 에이전트도 다시 자식 에이전트에 작업을 위임한다.
ADK는 워크플로우 에이전트도 제공한다. SequentialAgent는 Task A에서 Task B, Task C로 이어지는 순차 작업을 수행한다. ParallelAgent는 독립 작업을 동시에 실행한 뒤 결과를 병합하며, LoopAgent는 수렴 조건까지 반복 실행한다.
에이전트 간 통신은 이벤트 기반 아키텍처로 구성된다. 한 에이전트가 낸 결과가 이벤트 스트림으로 발행되면 다음 에이전트가 이를 구독해 처리한다. 이 구조는 에이전트 간 대기 시간을 줄이고, 병렬 처리 확대와 에이전트 추가 시 기존 코드 수정 최소화에 유리하다.
A2A는 에이전트 간 직접 메시지 교환과 협업을, MCP는 모델·도구·리소스 간 표준화된 통신을 담당한다. ADK는 Gemini의 텍스트·이미지·비디오 처리 능력을 활용하는 멀티모달 지원과 LiteLLM을 통한 Gemini·Claude·GPT 등 다양한 모델 사용도 제공한다. Google Agentspace와 Gemini Enterprise를 구동하는 핵심 엔진이기도 하다.
상태, 데이터, 역할 중심으로 갈리는 프레임워크 설계
| 항목 | Google ADK | LangGraph | LlamaIndex | CrewAI | Llama Stack |
|---|---|---|---|---|---|
| 핵심 패러다임 | 계층적 에이전트 트리 | 방향성 그래프 상태머신 | 데이터 중심 RAG | 역할 기반 팀 | 통합 API 레이어 |
| 주요 강점 | 다중모달, A2A/MCP 네이티브, Google Cloud 통합 | 상태 지속성, 프로덕션 안정성, 대규모 기업 채택 | 문서 지능, 의미론적 검색, RAG 최적화 | 빠른 프로토타이핑, 쉬운 학습곡선 | 자체 호스팅, 오픈 가중치 모델 우선 |
| 배포 모델 | Google Cloud 우선 | 멀티 클라우드, 온프레미스 | 멀티 클라우드 | 독립적 배포 | 완전 자체 호스팅 가능 |
| 상태 관리 | 이벤트 스트림 | 명시적 상태 머신 | 메모리 기반 | 암시적 | 세션 기반 |
| 성숙도 | 새로움(High Growth) | 프로덕션 리더 | 성숙(Stable) | 중간 | 성장 중 |
프레임워크 선택은 애플리케이션의 중심 제약에서 출발한다. 다중모달 처리와 Google Cloud의 깊은 통합, 실시간 A2A 협업이 필요하면 Google ADK가 후보가 된다. 복잡한 상태 관리와 프로덕션 안정성, 대규모 동시 처리가 핵심이면 LangGraph의 명시적 상태 머신이 맞는다.
문서 기반 지식 활용과 RAG 최적화, 검색 정확도가 본체라면 LlamaIndex가 적합하다. 빠른 프로토타입이나 MVP, 역할 분담을 통한 팀 협업 시뮬레이션에는 CrewAI가 맞으며, 오픈 가중치 모델·완전 자체 호스팅·폐쇄 환경이 우선이면 Llama Stack을 검토할 수 있다.
멀티에이전트 협업은 작업 경계에 따라 설계한다
| 패턴 | 사용 예시 | 장점 | 단점 |
|---|---|---|---|
| 계층적 위임 | 고객 요청 → 분석 → 실행 → 보고 | 명확한 책임, 확장성 | 하위 에이전트 실패 시 복잡성 증가 |
| 그래프 기반 상태머신 | 워크플로우 자동화, 주문 처리 | 예측 가능성, 디버깅 용이 | 동적 조건 처리 제한 |
| 역할 기반 팀 | 컨텐츠 제작(작가, 편집자, 리뷰어) | 역할별 특화, 팀웍 시뮬레이션 | 오버헤드, 느린 실행 |
| 명시적 핸드오프 | 파이프라인 처리, ETL | 명확한 인터페이스, 모니터링 용이 | 신축성 떨어짐 |
| 도구 사용 체인 | 코드 생성 후 검증 → 배포 | 유연성, 도구 재사용성 | 복잡한 의존성 관리 |
계층적 위임은 책임 분리와 확장이 필요한 경우에, 그래프 기반 상태머신은 상태 전이를 예측하고 디버깅해야 하는 워크플로우에 어울린다. 역할 기반 팀은 전문 역할을 나누는 프로토타이핑에, 명시적 핸드오프는 단계별 인터페이스와 모니터링이 필요한 파이프라인에 적합하다. 외부 API와 서브 에이전트를 반복적으로 호출하는 작업은 도구 사용 체인으로 모델링할 수 있다.
컨텍스트를 넘어서 지속성을 만드는 메모리 계층
에이전트의 성능은 메모리 아키텍처의 영향을 크게 받는다. 현재 세션만 다루는 작업 메모리부터 과거 상호작용, 구조화된 지식, 도구 사용 방법까지 서로 다른 형태의 정보를 다층으로 운영한다.
작업 메모리는 현재 세션의 컨텍스트로, LLM 컨텍스트 윈도우 안에서 즉시 접근할 수 있다. 지속 시간은 짧지만 응답 속도가 빠르다.
에피소딕 메모리는 과거 상호작용 이력을 저장한다. Pinecone, pgvector 등의 벡터 스토어에 보관하고 유사도 검색으로 관련 컨텍스트를 찾는다. 의미론적 메모리는 개념·규칙·관계처럼 구조화된 지식을 다루며, Mem0·Zep·Letta 같은 메모리 전문 플랫폼으로 관리할 수 있다. 절차적 메모리는 도구 사용 방법, 스킬, API 스펙을 담고 도구 레지스트리와 RAG 인덱스로 관리한다.
메모리 아키텍처를 적절히 설계한 에이전트는 약 40% 성능 향상을 보인다. 관련 컨텍스트 검색은 할루시네이션을 줄이고, 과거 상호작용 추적은 모순을 방지하며, 반복 상호작용은 패턴 인식에 도움을 준다. LangGraph와 Google ADK는 모두 이런 메모리 계층을 명시적으로 관리할 수 있는 구조를 제공한다.
MCP와 A2A가 도구와 에이전트의 경계를 바꾼다
2025년 에이전트 표준화에서 MCP(Model Context Protocol)와 A2A(Agent-to-Agent) 프로토콜은 핵심 축이다.
MCP는 Claude를 개발한 Anthropic이 주도하는 오픈 표준으로, 모델·도구·데이터소스 간 통신을 표준화한다. JSON 스키마로 도구 인터페이스를 정의하고, 파일·데이터베이스·API에 표준화된 방식으로 접근하며, 모델에서 도구로, 도구에서 모델로 이어지는 양방향 메시징을 다룬다.
클라이언트(LLM)
↔ MCP 프로토콜
↔ 리소스 서버(데이터, 도구, 시스템)
이 방식은 프레임워크 사이에서 도구를 재사용할 수 있게 하고, 도구 권한을 명시적으로 관리하며, 새 도구를 추가할 때 기존 코드 변경을 줄인다. Google ADK, LangGraph, CrewAI는 모두 MCP를 지원하거나 지원 중이다.
A2A는 에이전트 사이의 직접 통신을 위한 프로토콜이다. JSON 기반 메시지 형식을 사용하고, 다른 에이전트의 역할과 능력을 자동으로 발견하며, 실시간 협업 계약을 맺는 구조를 포함한다. Google ADK는 A2A를 네이티브로 지원하고, OpenAI도 Agents SDK에 A2A를 포함시켰다.
두 표준의 확산은 특정 프레임워크 종속을 줄이고, 도구·모델·프레임워크를 더 자유롭게 조합하게 하며, 보안과 거버넌스 요구사항을 가진 엔터프라이즈 도입에도 영향을 준다.
엔터프라이즈에서는 거버넌스와 운영 제약이 선택을 좌우한다
Gartner의 2026년 전망에 따르면 엔터프라이즈 애플리케이션의 40%가 AI 에이전트 기능을 포함할 것으로 예상된다. 현재 엔터프라이즈 도입에서 가장 큰 장애물은 거버넌스 격차이며, 68% 기업이 이를 언급했다.
| 항목 | 중요도 | 검증 기준 |
|---|---|---|
| 보안 및 규정준수 | 매우 높음 | SOC 2, ISO 27001, HIPAA, GDPR 지원 |
| 통합 깊이 | 높음 | 레거시 시스템 연결, API 표준화(MCP, A2A) |
| 상태 지속성 | 높음 | 세션 복구, 장기 대화 이력 관리 |
| 거버넌스 및 감시 | 높음 | 감사 로그, 의사결정 투명성, 비용 추적 |
| 성능 및 확장성 | 중간~높음 | 동시 요청 처리, 응답 지연시간 |
| 모델 다양성 | 중간 | 멀티 모델 지원, 벤더 독립성 |
| 개발자 경험 | 중간 | 문서화, SDK, 커뮤니티 |
LangGraph는 프로덕션 안정성이 우선이고 복잡한 상태 관리와 대규모 트래픽 처리가 필요한 환경에 권장된다. 금융·보험·의료 분야가 예시이며, Uber·Klarna·LinkedIn·JPMorgan이 예시 기업으로 제시된다. 그래프 구조 설계가 복잡해질 수 있으므로 충분한 설계 검토가 필요하다.
Google ADK는 Google Cloud 기존 사용자, 다중모달 처리, 실시간 A2A 협업, 빠른 혁신 수용이 필요한 환경에 적합하다. Google Cloud 고객과 SaaS 플랫폼이 예시다. 다만 새로운 프레임워크이므로 커뮤니티와 문서화가 성장 중이라는 점을 고려해야 한다.
LlamaIndex는 문서 기반 지식 활용, RAG 기반 검색, 데이터 보안, 지식 관리 시스템에 적합하다. 출판·법률·정보 서비스가 예시다. RAG 특화로 인한 제한이 있으므로 다른 패턴이 필요하면 혼합 접근이 필요하다.
Llama Stack은 완전 자체 호스팅, 오픈 가중치 모델 선호, 데이터 프라이버시 극대화, 클라우드 락인 회피가 필요한 환경에 맞는다. EU 규제 대상과 자체 인프라 운영 기업이 예시이며, 자체 호스팅 비용과 운영 복잡도 증가는 주의할 부분이다.
에이전트 프레임워크 경쟁에서는 기술 혁신과 표준화가 동시에 진행되고 있다. Google ADK의 성장, OpenAI Codex CLI의 확산, LangGraph의 프로덕션 리더십은 각기 다른 운영 모델이 공존한다는 신호다. 선택할 때는 아키텍처 패러다임, 엔터프라이즈 요구사항, 기술 팀의 역량, 장기 유지보수 전략을 함께 놓고 봐야 한다.
MCP와 A2A의 채택 확대, 지속적 학습을 위한 메모리 아키텍처의 중요성, 협업·위임·상태 관리를 명시적으로 다루는 멀티에이전트 패턴, 자체 호스팅과 매니지드 서비스 사이의 긴장은 이 분야를 계속 규정할 흐름이다. 조직의 전략과 제약 조건을 분석한 뒤 파일럿 프로젝트로 2-3개 프레임워크를 실제 검증해보는 것이 필요하다. 이론적 선택은 현실 앞에서 종종 무너지기 때문이다.
Sources
- https://google.github.io/adk-docs/
- https://github.com/google/adk-python
- https://developers.googleblog.com/en/agent-development-kit-easy-to-build-multi-agent-applications/
- https://github.com/meta-llama/llama-stack
- https://github.com/openai/codex
- https://www.zenml.io/blog/google-adk-vs-langgraph
- https://langfuse.com/blog/2025-03-19-ai-agent-comparison
- https://blog.langchain.com/how-to-think-about-agent-frameworks/
- https://visagetechnologies.com/agent-framework-comparison-llamaindex-vs-langgraph-vs-adk/