12. 프레임워크 비교

한 줄 정의. 에이전트 프레임워크 비교는 “무엇이 더 좋은가”가 아니라 “내 문제에는 어떤 추상화 수준이 맞는가”를 고르는 일이다 — 같은 다섯 렌즈(추상화·상태·멀티에이전트·도구·관측)로 보면 서로 다른 출발점이 드러난다.

왜 중요한가

프레임워크는 한번 고르면 코드 구조 전체를 물들입니다. LangGraph로 짠 그래프를 CrewAI의 크루로 옮기는 일은 단순 포팅이 아니라 사고방식의 이주에 가깝습니다. 그래서 “유명한 걸 쓰자”가 아니라 “내 문제가 요구하는 제어 수준이 무엇인가”를 먼저 정해야 합니다.

여섯 프레임워크는 겉보기에 다 “멀티에이전트를 만든다”고 말하지만, 출발점이 다릅니다. 어떤 것은 그래프 실행 엔진에서, 어떤 것은 소수의 원시 요소에서, 어떤 것은 데이터·RAG에서 출발합니다.

이 장은 우열을 가리지 않습니다. 대신 오케스트레이션 패턴과 관측·평가에서 다룬 개념을 공통 렌즈로 삼아, 각 프레임워크가 그 렌즈에서 어디쯤 서 있는지를 1차 문서 기준으로 비춰 봅니다.

다섯 렌즈: 비교의 좌표축을 고정한다

비교가 인상평으로 흐르지 않으려면 축을 먼저 못 박아야 합니다. 이 장은 다섯 축을 씁니다.

추상화 수준은 실행 흐름을 개발자가 직접 조립하는가 아니면 프레임워크가 알아서 돌려 주는가입니다. 상태 관리는 대화 기록과 작업 상태를 어떻게 보존하고 장애에서 복구하는가입니다.

멀티에이전트는 여러 에이전트를 명시적 그래프로 엮는가 아니면 자율적 위임에 맡기는가입니다. 도구는 함수·MCP·외부 모델을 어떻게 붙이는가, 관측은 실행을 어떻게 들여다보고 채점하는가입니다.

이 다섯 축은 우열의 사다리가 아닙니다. “내 문제에 맞는 추상화 수준”을 고르는 자(尺)일 뿐입니다. 같은 그래프 실행이라도 저수준 프레임워크는 노드 하나하나를 손으로 잇게 하고, 고수준 프레임워크는 패턴 이름만 부르면 됩니다. 어느 쪽이 옳다기보다, 통제권을 어디까지 손에 쥐고 싶은지가 다를 뿐입니다.

축마다 결정적으로 갈리는 지점은 “기본 ON인가, 직접 켜야 하는가”입니다. 같은 트레이싱 기능이라도 OpenAI Agents SDK는 코드를 한 줄도 더 쓰지 않아도 실행이 트레이스로 남고¹, LangGraph는 LangSmith를 별도로 연동해야 실행 경로가 잡힙니다². 같은 체크포인팅이라도 LangGraph·MS Agent Framework는 1급 원시요소로 노출하지만, OpenAI Agents SDK는 Sessions가 대화 기록만 자동 보존하고 장애 복구·time travel은 사정권 밖입니다.

이 “기본값의 차이”가 실제 개발 경험을 가장 크게 가릅니다.

참고

이 장은 6개 프레임워크를 같은 렌즈로 위치만 잡습니다. 실제 선택은 기능 체크리스트가 아니라 문제의 무게중심(그래프를 그리는가 / 위임을 선언하는가 / 역할을 나누는가 / 검색을 먼저 두는가)으로 갈립니다.

LangGraph: 저수준 그래프와 지속 실행

LangGraph는 자신을 “상태를 가진 에이전트를 만드는 저수준 오케스트레이션 프레임워크(Low-level orchestration framework for building stateful agents)“이자 “탄력적인 에이전트를 만든다(Build resilient agents)“고 소개합니다². 다른 프레임워크가 “에이전트 패턴”을 추상화로 제공한다면, LangGraph는 그 아래의 실행 엔진을 제공합니다. 영감의 출처가 이를 드러냅니다 — 실행 모델은 분산 그래프 처리 시스템인 Pregel과 Apache Beam에서, 공개 인터페이스는 그래프 라이브러리 NetworkX에서 따왔습니다².

원시요소: 노드·엣지·State·Channels·Reducers

핵심 단위는 StateGraph 클래스입니다. 개발자는 노드(작업 단위 함수)와 엣지(다음 노드로의 전이)를 직접 잇고, 그 사이를 흐르는 State(중앙 공유 데이터)를 정의합니다². State의 스키마와 타입은 Channels로 규정하고, 여러 경로가 같은 상태를 동시에 갱신할 때의 병합 규칙은 Reducers로 지정합니다.

실행은 super-step 단위로 진행됩니다 — 한 스텝에서 동시에 활성화된 노드들이 함께 돌고, 그 결과가 리듀서를 거쳐 다음 스텝의 State로 합쳐집니다².

이 super-step·reducer 구조가 곧 LangGraph의 멀티에이전트 방식입니다. 여러 전문가 노드를 팬아웃으로 동시에 돌리고, 각자가 내놓은 부분 결과를 리듀서가 하나의 State로 모읍니다. 그래서 LangGraph의 멀티에이전트는 “에이전트를 위임한다”가 아니라 “그래프를 그린다”는 멘탈모델입니다.

리듀서 없이 같은 키를 동시에 쓰면 덮어쓴다

두 노드가 같은 super-step에서 State의 같은 키를 갱신하는데 그 키에 리듀서가 지정돼 있지 않으면, 한 노드의 값이 다른 노드의 값을 덮어쓰거나 충돌합니다². 리스트에 누적하고 싶다면 operator.add 같은 리듀서를, 메시지 누적이라면 add_messages를 채널에 명시해야 합니다. 병렬 분기를 설계할 때 가장 흔히 밟는 지뢰입니다.

지속 실행(durable execution)과 Checkpointer

LangGraph가 “저수준인데도 쓸 가치가 있는” 핵심 이유가 지속 실행입니다. 공식 설명으로는 “에이전트가 장애를 견디고 장기간 실행되며, 멈춘 지점에서 정확히 자동으로 재개(persist through failures and run for extended periods, automatically resuming from exactly where they left off)“합니다². 메커니즘은 Checkpointer입니다.

매 super-step마다 State 스냅샷을 저장하므로, 프로세스가 죽거나 중간에 멈춰도 마지막 체크포인트에서 이어서 돌립니다.

체크포인트는 Thread(하나의 실행 컨텍스트) 단위로 묶입니다. 백엔드는 용도에 따라 고릅니다 — 테스트용 인메모리 MemorySaver, 로컬 파일용 SqliteSaver, 프로덕션용 PostgresSaver(Postgres)입니다².

from langgraph.graph import StateGraph
from langgraph.checkpoint.sqlite import SqliteSaver

graph = builder.compile(checkpointer=SqliteSaver.from_conn_string("checkpoints.db"))

# thread_id를 config로 넘겨야 같은 실행 컨텍스트로 이어진다
config = {"configurable": {"thread_id": "user-42"}}
graph.invoke({"messages": [...]}, config=config)

체크포인터·thread_id를 빠뜨리면 핵심 기능이 통째로 죽는다

checkpointer를 붙이지 않으면 interrupt로 멈췄다가 재개하기, time travel 같은 기능 자체가 동작하지 않습니다². 또 thread_id를 config로 넘기지 않으면 매 호출이 새 컨텍스트로 시작돼 상태가 이어지지 않습니다. “왜 대화 기록이 안 남지?”의 8할은 이 두 가지입니다.

Human-in-the-loop와 메모리

실행 중 사람이 끼어드는 패턴도 1급입니다. interrupt로 임의 지점에서 실행을 일시정지하고, Command로 State를 수정한 뒤 재개하며, time travel로 과거 체크포인트로 되돌려 다시 실행할 수 있습니다 — “실행 중 임의 지점에서 에이전트 상태를 검사·수정”하는 것이 설계 목표입니다². 이 메커니즘은 checkpointer가 매 스텝 State를 저장해 두기에 성립합니다.

메모리는 두 층입니다. 단기(working memory)는 스레드 안에서만 살아 있는 작업 메모리이고, 장기는 Store 원시요소로 세션을 넘어 영속합니다². 스트리밍은 여러 모드를 지원하고, 관측은 LangSmith 연동으로 실행 경로 추적과 상태 전이 포착을 맡깁니다.

즉시 쓰고 싶다면 프리빌트 create_react_agent도 제공합니다.

설치는 pip install -U langgraph이고, README 기준 버전은 1.x대(1.2.6, 2026-06-18)입니다². 상위 계층인 Deep Agents나 LangSmith 배포 플랫폼과 엮이지만, standalone으로도 충분히 씁니다. 정밀한 흐름·복구 통제가 필요한 장기·고가치 워크플로가 LangGraph의 자리입니다.

OpenAI Agents SDK: 소수 원시요소의 빠른 착수

OpenAI Agents SDK는 정반대 지향입니다. 설계 원칙이 “쓸 만큼의 기능은 있되, 빨리 배울 만큼 원시 요소는 적게(enough features to be worth using, but few enough primitives to make it quick to learn)“이고 Python-first입니다³. 별도 오케스트레이션 추상을 외우는 대신 파이썬 언어 기능으로 흐름을 짭니다.

네 가지 원시요소와 Runner 루프

핵심은 네 개입니다. Agents(지시·도구·가드레일·핸드오프를 가진 LLM), Handoffs(다른 에이전트로의 위임), Guardrails(입출력 검증), Sessions(대화 기록 자동 관리)입니다. 여기에 Tools, HITL, Tracing, Realtime/Voice, Sandbox Agents가 더해집니다¹.

실행은 Runner가 도는 에이전트 루프입니다. 매 턴마다 LLM을 호출하고, 결과가 최종 출력이면 반환, 핸드오프면 대상 에이전트로 전환, 도구 호출이면 도구를 실행한 뒤 루프를 반복합니다³. Runner.run은 async, run_sync는 blocking이며 결과는 result.final_output으로 받습니다.

from agents import Agent, Runner

agent = Agent(name="Assistant", instructions="You are helpful.")
result = Runner.run_sync(agent, "환불 절차를 알려줘", max_turns=10)
print(result.final_output)

max_turns를 초과하면 MaxTurnsExceeded로 끊긴다

루프는 max_turns 기본 한도로 무한 루프를 막습니다³. 도구 호출과 핸드오프가 꼬리를 무는 복잡한 흐름에서 한도를 넘으면 MaxTurnsExceeded 예외가 납니다. 긴 추론·다단계 도구 사용이 예상되면 한도를 명시적으로 올려야 합니다.

Handoffs vs agents-as-tools: 제어권 이전이 갈린다

멀티에이전트는 두 방식이 다릅니다. Handoff는 agent의 handoffs=[other_agent] 파라미터나 handoff() 함수로 정의하며, 트리거되면 대화 컨텍스트와 제어권이 통째로 대상 에이전트로 이전됩니다³. 반면 agents-as-tools는 에이전트를 도구처럼 호출하되 제어권은 넘기지 않습니다 — 부르는 쪽이 결과만 받아 계속 진행합니다³. “분류기가 전문가에게 넘기고 빠진다”면 handoff, “오케스트레이터가 하위 에이전트를 불러 결과만 취합한다”면 agents-as-tools입니다.

이 둘을 혼동하면 흐름 제어가 의도와 어긋납니다.

Guardrails: 첫 에이전트에서만, 병렬로

Guardrails는 입력과 출력 검증을 맡습니다. 핵심은 input 가드레일이 “첫 에이전트”에서만 실행된다는 점입니다 — 사용자 입력을 선검증하는 용도라, 핸드오프 후 하위 에이전트에는 걸리지 않습니다³. output 가드레일은 응답을 검증합니다.

둘 다 에이전트 실행과 병렬로 돌아 지연을 줄입니다. 결과는 GuardrailFunctionOutput으로 신호하며, tripwire_triggered가 켜지면 InputGuardrailTripwireTriggered 예외로 실행을 중단합니다³.

input 가드레일은 하위 에이전트를 지키지 못한다

input 가드레일이 첫 에이전트 전용이라는 사실은 보안 설계에 직접 영향을 줍니다³. 분류 에이전트가 환불 에이전트로 핸드오프한 뒤 환불 에이전트가 받는 입력은 input 가드레일을 거치지 않습니다. 위임 체인 전반을 검증하려면 각 에이전트에 가드레일을 따로 달거나 output 가드레일로 보완해야 합니다.

Sessions·Tracing·Provider 비종속

Sessions는 다중 턴 대화 기록을 자동 보존합니다 — SQLiteSession(로컬), Redis(선택 의존성)를 백엔드로 쓰며, 매 턴 history를 수동으로 전달할 필요가 없습니다¹. Tracing은 기본 ON입니다. 별도 설정 없이 agent 호출·LLM generation·function(도구) 실행·handoff·guardrail이 스팬으로 남고, 끄려면 OPENAI_AGENTS_DISABLE_TRACING 환경변수를 씁니다¹³.

OpenAI 전용이 아닙니다. Responses와 Chat Completions API에 더해 “100개 이상의 다른 LLM(100+ other LLMs)“을 LiteLLM·Mozilla any-llm 경유로 지원하며, set_default_openai_client 패턴으로 클라이언트를 교체합니다¹. 설치는 pip install openai-agents(Python 3.10+), 음성은 [voice], 레디스는 [redis] extra입니다.

버전은 0.x대(0.17.6, 2026-06)이고 타입세이프를 위해 Pydantic에 의존합니다¹. 마찰 없이 빠르게 착수하고 싶을 때 가장 가벼운 선택입니다.

Google ADK: 코드 우선 + 워크플로 에이전트

Google ADK는 “정교한 AI 에이전트를 만들고·평가하고·배포하기 위한 오픈소스 코드 우선 파이썬 프레임워크(open-source, code-first Python framework for building, evaluating, and deploying sophisticated AI agents)“입니다(Python 3.10+)⁴. LangGraph와 OpenAI Agents SDK 사이의 중간 지대로, “직접 추론하는 에이전트”와 “정해진 흐름을 돌리는 워크플로 에이전트”를 명시적으로 갈라 둔 것이 특징입니다.

LlmAgent vs 워크플로 에이전트

LlmAgent는 model·instruction·tools를 받아 직접 reasoning합니다. 반면 워크플로 에이전트는 흐름을 코드로 박아 둡니다 — SequentialAgent(선형), ParallelAgent(동시 실행, 공유 세션 state), LoopAgent(반복, max_iterations 또는 escalate 신호로 종료)입니다⁵. 즉 LLM이 다음 단계를 정하게 둘지, 개발자가 정할지를 에이전트 종류로 분리합니다.

ParallelAgent의 state 충돌과 LoopAgent의 무한 루프

ParallelAgent는 같은 세션 state를 공유하므로, 동시에 도는 하위 에이전트들이 같은 키에 쓰면 충돌합니다 — 출력 키를 서로 다르게 지정해야 합니다⁵. LoopAgent는 종료 조건(max_iterations 또는 escalate)이 없으면 무한 루프에 빠집니다⁵. 둘 다 “흐름을 코드로 박는” 워크플로 에이전트의 대표적 함정입니다.

ADK 2.0 그래프 엔진과 breaking changes

ADK 2.0은 본격적인 그래프 실행 엔진을 더했습니다 — routing, fan-out/fan-in, loops, retry, state management, dynamic nodes, human-in-the-loop, nested workflows를 지원하고, Workflow(name, edges=[("START", a, b)]) 형태로 노드를 잇습니다⁴. 다만 2.0은 agent API·event model·session schema에 breaking change가 있습니다⁴.

1.x → 2.0 세션 스키마는 비호환이다

ADK 2.0의 세션은 1.28+와는 forward-compatible이지만, 그 이전 1.x와는 비호환이라 마이그레이션이 필요합니다⁴. 1.x로 운영 중인 세션 데이터를 2.0으로 올릴 때는 스키마 이관을 반드시 거쳐야 합니다.

상태·도구·평가

상태는 SessionService가 맡습니다 — 로컬은 InMemorySessionService, GCP는 VertexAiSessionService입니다⁵. State는 프리픽스 app:/user:/temp:로 범위를 구분하고, MemoryService가 대화 기록·컨텍스트를 관리하며, 실행·관측은 Runner + InvocationContext + Events로 이뤄집니다⁵.

도구는 폭이 넓습니다. FunctionTool(파이썬 함수), AgentTool(에이전트를 도구로), MCP 도구, 빌트인(google_search·code execution)에 더해 LangChain·CrewAI 도구를 어댑터로 래핑할 수 있습니다⁵. 모델은 Gemini가 기본이지만 “거의 모든 생성형 AI 모델과 작동(can work with almost any generative AI model)“하며 LiteLlm 래퍼로 Claude·Ollama·vLLM을 붙입니다⁵.

평가가 내장이라는 점이 ADK의 차별점입니다. adk eval CLI로 evalset 데이터셋을 돌려 tool_trajectory_avg_score·response_match_score 같은 메트릭을 뽑고, before/after agent·model·tool 콜백으로 실행에 개입합니다⁵. CLI는 adk run <agent>와 웹 UI용 adk web <dir>이고, 설치는 pip install google-adk(옵션 [extensions]), 버전은 2.x(2.3.0, 2026-06-18)입니다⁴. Google Cloud·Gemini 친화에 모델·도구 비종속까지 필요한 중간 지대가 ADK의 자리입니다.

Microsoft Agent Framework: 멀티언어 그래프 워크플로

Microsoft Agent Framework는 ”.NET과 Python으로 프로덕션급 AI 에이전트와 멀티에이전트 워크플로를 만드는 개방형 멀티언어 프레임워크(open, multi-language framework for building production-grade AI agents and multi-agent workflows in .NET and Python)“입니다⁶. 프로토타입에서 프로덕션까지 일관된 API를 지향하며, Semantic Kernel과 AutoGen 양쪽의 마이그레이션 가이드를 두고 두 프레임워크 경험을 수렴했습니다⁶.

원시요소와 그래프 워크플로

원시요소는 Python에선 Agent, C#/.NET에선 AIAgent이고, client·name·instructions로 초기화합니다. 실행은 .run()(Py)/.RunAsync()(.NET)이며, .NET은 AIProjectClient.AsAIAgent() 확장을 씁니다⁶. 워크플로는 그래프 기반으로 sequential, concurrent, handoff, group collaboration(Magentic 스타일) 패턴에 더해 타입 기반 라우팅(executors/edges 노드 아키텍처)을 지원합니다⁶.

상태는 체크포인팅으로 영속하고, time-travel 리플레이로 저장 지점부터 재실행해 내구성과 디버깅을 함께 챙깁니다⁶. 모델·도구는 Azure OpenAI·OpenAI·GitHub Copilot·Microsoft Foundry 등 pluggable client backend로 붙여 벤더 종속을 피하고, 도구 호출 패턴과 MCP를 지원합니다⁶.

OpenTelemetry 관측과 Python/.NET 패리티

관측은 “내장 OpenTelemetry 연동(Built-in OpenTelemetry integration)“으로 분산 추적·모니터링·디버깅을 제공합니다 — agent 레벨과 workflow 레벨 텔레메트리를 export하며 요청/응답 트레이스에 미들웨어 이벤트까지 함께 잡습니다⁶. 가장 큰 차별점은 .NET과 Python 양쪽을 일급으로 다루는 일관된 API surface입니다. 두 언어에서 동일한 방식으로 에이전트·미들웨어·프로바이더·워크플로를 구성하도록 설계됐고, 개발·테스트·디버깅용 DevUI와 선언적 YAML 에이전트 정의를 함께 제공합니다⁶.

비-Azure 모델·외부 시스템 연동의 거버넌스는 사용자 책임

프레임워크는 3자 리스크를 숨기지 않습니다. 비-Azure 모델이나 외부 시스템을 붙일 때의 데이터 거버넌스·컴플라이언스·책임 AI 완화는 사용자 책임이라고 명시합니다⁶. 규제 환경에서 외부 모델을 끌어 쓸 때는 이 경계를 설계 단계에서 따져야 합니다.

설치는 Python 전체가 pip install agent-framework, .NET 코어가 dotnet add package Microsoft.Agents.AI, 호스팅이 Microsoft.Agents.AI.Foundry입니다. 90개 넘는 릴리스가 있고 버전은 python-1.9.0(2026-06)입니다⁶. .NET 생태계나 엔터프라이즈 표준 관측이 필요한 조직에 들어맞습니다.

CrewAI: 역할 기반 자율 협업 + 결정론 흐름

CrewAI는 “처음부터 완전히 새로 만든 가볍고 빠른 파이썬 프레임워크로, LangChain이나 다른 에이전트 프레임워크와 완전히 독립(lean, lightning-fast Python framework built entirely from scratch—completely independent of LangChain or other agent frameworks)“입니다⁷. 정체성은 Crews와 Flows의 짝입니다.

Crews(자율) vs Flows(결정론)

Crews는 “역할 기반 협업(role-based collaboration)“으로, 에이전트들 사이의 “자연스럽고 자율적인 의사결정(natural, autonomous decision-making between agents)“과 동적 작업 위임을 다룹니다⁷. Flows는 “프로덕션급 이벤트 기반 워크플로(production-ready, event-driven workflows)“로 “실행 경로에 대한 세밀한 제어(fine-grained control over execution paths)“와 조건 분기를 제공합니다⁷. 둘은 목적이 다릅니다 — Crews가 자율이라면 Flows는 결정론입니다.

에이전트는 agents.yaml에 role·goal·backstory로 정의하고, Task는 tasks.yaml에 description·expected_output·agent로 정의합니다⁷. Process는 두 가지입니다 — sequential(순차)과 hierarchical로, hierarchical은 “자동으로 manager를 배정해 위임을 통해 계획·실행을 조율”하며 manager_llm/manager_agent로 매니저를 지정합니다⁷.

Flow는 데코레이터로 흐름을 엮습니다. @start(트리거), @listen(특정 출력 수신), @router(조건 분기)이고, or_/and_ 연산자로 조건을 결합하며, 상태는 Pydantic BaseModel로 구조화합니다⁷.

from crewai.flow.flow import Flow, start, listen, router

class SupportFlow(Flow[State]):
    @start()
    def classify(self): ...

    @router(classify)
    def route(self): ...

    @listen("refund")
    def handle_refund(self): ...

자율과 결정론을 섞을 때: 재현성 구간은 Flow로 감싼다

Crews는 위임이 자율적이라 같은 입력에도 경로가 흔들릴 수 있습니다. 결정론·재현성이 필요한 구간은 Flow로 감싸 실행 경로를 고정해야 합니다⁷. 또 역할·목표·배경 정의가 모호하면 에이전트 위임 자체가 불안정해지므로, role/goal/backstory를 구체적으로 적는 것이 협업 품질을 좌우합니다⁷.

성능에 대해 CrewAI는 “특정 경우(이 QA 작업 예시 등)에서 5.76배 빠르게 실행(executing 5.76x faster in certain cases like this QA task example)“한다고 LangGraph 대비 수치를 명시합니다⁷. 설치는 uv pip install crewai(옵션 crewai[tools])이고, crewai create crew <name>으로 스캐폴딩하면 agents.yaml·tasks.yaml·crew.py·main.py가 생성됩니다⁷. 역할을 나눠 빠르게 팀을 짜고 싶을 때 직관적입니다.

LlamaIndex: 데이터에서 출발하는 RAG 우선

LlamaIndex는 애초에 에이전트 프레임워크가 아니라 “LLM 앱을 만들도록 돕는 데이터 프레임워크(data framework to help you build LLM apps)“입니다⁸. 본질은 사적 데이터로 LLM을 증강하는 것이고, 에이전트는 그 위에 얹힌 층입니다.

RAG 코어: 커넥터 → 인덱스 → 검색 → 합성

데이터 파이프라인이 코어입니다. Data Connectors(LlamaHub, 300+ 통합으로 API·PDF·문서·SQL 수집)로 원천을 끌어와 Documents/Nodes로 쪼개고, 인덱스(주력 VectorStoreIndex에 더해 graph·keyword 인덱스)를 만든 뒤, retriever와 query engine이 “데이터에 대한 고급 검색·질의 인터페이스(advanced retrieval/query interface over your data)“를 제공하며, response synthesizer가 최종 답을 합성합니다⁸. 영속은 index.storage_context.persist()로 합니다⁸.

에이전트는 RAG 위의 층: event-driven Workflows

에이전트 층은 RAG 위에 더해집니다. Workflows는 event-driven 실행이고 그래프가 아닙니다 — @step 데코레이터로 스텝을 정의하고 Context 객체로 상태를 관리하며, FunctionAgent·ReActAgent·AgentWorkflow를 제공합니다⁸. 차별점은 전통적 그래프 프레임워크와 달리 이벤트 기반이라는 점입니다 — 비동기 step 조율과 동적 제어 흐름을 이벤트로 엮습니다⁸.

Workflows는 그래프가 아니다 — 멘탈모델이 다르다

LangGraph·ADK의 노드·엣지 그래프를 기대하고 LlamaIndex Workflows를 보면 어긋납니다. Workflows는 이벤트를 발행·수신하는 모델이라, “다음 노드로 간다”가 아니라 “이벤트가 도착하면 해당 step이 깨어난다”로 사고해야 합니다⁸.

모델은 비종속입니다. Settings로 LLM(OpenAI·Ollama 등)·embedding model·tokenizer를 설정합니다⁸. 엔터프라이즈 파싱은 OSS와 분리된 LlamaParse·LlamaCloud가 맡아 agentic OCR·파싱(130+ 포맷)과 구조화 추출을 제공합니다⁸.

참고

설치는 두 갈래입니다 — pip install llama-index는 스타터·통합을 함께 깔아 의존성이 무겁고, 코어만 쓰려면 pip install llama-index-core를 씁니다⁸. 버전은 0.14.x(0.14.22, 2026-05)입니다. 출발점이 “에이전트”가 아니라 “데이터 연결”일 때 가장 자연스럽습니다.

같은 렌즈로 본 요약

프레임워크	추상화	상태·복구	멀티에이전트	관측 기본값
LangGraph	저수준(그래프 직접)	체크포인트·지속 실행	명시적 노드·엣지	LangSmith 연동
OpenAI Agents SDK	고수준(소수 원시요소)	Sessions 자동	핸드오프·에이전트=도구	트레이싱 기본 ON
Google ADK	중간(LlmAgent+워크플로)	세션·상태·메모리	계층·워크플로 에이전트	평가 내장
MS Agent Framework	중간(그래프 워크플로)	체크포인트·시간여행	순차·동시·핸드오프·그룹	OpenTelemetry
CrewAI	고수준(역할 기반)	Flows의 상태 관리	Crew 자율 / Flow 통제	메모리·추적
LlamaIndex	데이터 우선	인덱스 중심	Workflows로 추가	통합 위주

표는 위치만 잡아 줄 뿐입니다. 실제 선택은 본문에서 본 “출발점”으로 갈립니다.

예제: 같은 요구를 여섯 가지로 푼다

“고객 문의를 분류해 환불·배송·일반 상담 중 맞는 전문 에이전트로 넘기고, 실패하면 사람이 개입한다”는 요구를 생각해 봅시다. 같은 요구가 무게중심에 따라 전혀 다른 코드 형태로 풀립니다.

LangGraph        : 분류 노드 → 조건 엣지로 분기, 각 전문가 노드, 실패 시 interrupt로
                   상태를 사람에게 노출. 흐름·복구를 직접 그린다.
OpenAI Agents SDK: 분류 에이전트가 Handoff로 전문 에이전트에 위임, Guardrail로
                   입력 검증, Sessions가 대화 유지. 트레이스는 자동으로 남는다.
Google ADK       : 라우팅용 LlmAgent + 전문가 LlmAgent를 계층으로 두고,
                   2.0 그래프 워크플로의 human-in-the-loop로 사람 개입.
MS Agent Fwk     : handoff 패턴 워크플로 + 체크포인트, .NET 서비스에 그대로 얹고
                   OpenTelemetry로 운영 관측.
CrewAI           : 매니저가 이끄는 계층형 Crew로 역할 분담, 결정론이 필요한
                   구간은 Flow로 감싼다.
LlamaIndex       : 문의 답변 근거가 사내 문서라면 RAG 검색을 코어에 두고
                   FunctionAgent로 분기 로직을 얹는다.

여기서 갈리는 것은 기능 유무가 아니라 멘탈모델입니다²¹⁴⁷⁸⁶. LangGraph는 분류를 노드로, OpenAI Agents SDK는 분류를 에이전트의 핸드오프 결정으로, CrewAI는 분류를 매니저의 위임으로, LlamaIndex는 분류 이전에 검색을 먼저 둡니다. “사람 개입”도 LangGraph는 interrupt로 상태를 노출하고, ADK·MS는 워크플로의 HITL 노드로 받습니다.

정답은 문제의 무게중심이 “그래프를 그린다 / 위임을 선언한다 / 역할을 나눈다 / 검색을 먼저 둔다” 중 어디에 있느냐입니다. 고른 프레임워크로 실제 코드를 짜 보는 단계는 실전 구축에서 이어집니다.

요약 · 체크리스트

• 흐름·상태·복구를 직접 정밀 통제해야 한다면 LangGraph 같은 저수준 그래프(노드·엣지·State·checkpointer)를, 빨리 착수하고 싶다면 OpenAI Agents SDK 같은 소수 원시요소형을 먼저 본다.
• LangGraph는 리듀서·thread_id·checkpointer를, OpenAI Agents SDK는 max_turns 한도와 input 가드레일이 첫 에이전트 전용이라는 점을, ADK는 1.x→2.0 세션 비호환과 LoopAgent 종료 조건을 체크한다.
• .NET/엔터프라이즈 OpenTelemetry 관측이 필요하면 MS Agent Framework, Google Cloud·Gemini 친화 + 평가 내장 + 모델 비종속이면 ADK, 역할 기반 협업이 직관적이면 CrewAI(결정론 구간은 Flow)를 후보로 둔다.
• 문제의 무게중심이 “사적 데이터 연결”이면 LlamaIndex처럼 RAG에서 출발하는 프레임워크가 자연스럽다는 것을 안다(Workflows는 그래프가 아니라 event-driven임에 주의).

관련 장

• 8. 오케스트레이션 패턴
• 11. 관측 · 평가
• 13. 실전 구축

Footnotes

1. OpenAI Agents SDK README — openai/openai-agents-python ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. LangGraph 공식 README — langchain-ai/langgraph ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³

3. OpenAI Agents SDK 공식 문서 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

4. Google ADK README — google/adk-python ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

5. Google ADK 공식 문서 — adk.dev ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

6. Microsoft Agent Framework README — microsoft/agent-framework ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

7. CrewAI README — crewAIInc/crewAI ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹

8. LlamaIndex README — run-llama/llama_index ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰