AI 에이전트 프레임워크 비교 2026: LangGraph · CrewAI · OpenAI Agents SDK · AutoGen — 무엇을 언제 쓰나

프레임워크 4종의 정체성과 트레이드오프를 직접 붙여본 관점으로 정리하고, 프로젝트 규모와 목적별 선택 기준을 제시합니다

중급AI 에이전트·2026년 6월 16일 업데이트

1. 결론부터: 무엇을 언제 쓰나

결론부터 말하면, 에이전트 프레임워크 선택은 "어떤 모델을 쓸지"가 아니라 "제어 흐름을 누가 소유할지"를 기준으로 정해집니다. 워크플로를 직접 그래프로 짜고 상태를 영속화해야 하면 LangGraph, 역할 기반 팀을 빠르게 조립하려면 CrewAI, OpenAI(또는 100여 종 모델)에 가볍게 붙여 핸드오프·가드레일을 쓰려면 OpenAI Agents SDK, .NET/엔터프라이즈 스택이면 AutoGen의 후속인 Microsoft Agent Framework가 합리적인 출발점입니다.

한 줄 요약

LangGraph — 명시적 그래프 + 상태 영속화(durable execution). 복잡한 프로덕션 워크플로·HITL.

CrewAI — 역할 기반 "크루"를 빠르게 조립. 프로토타입·역할 분담 협업. LangChain에서 독립.

OpenAI Agents SDK — 경량 핸드오프·가드레일·트레이싱. provider-agnostic(OpenAI 외 모델도 지원).

AutoGen — 현재 유지보수 모드. 신규 프로젝트는 후속 Microsoft Agent Framework(AutoGen + Semantic Kernel 통합) 또는 커뮤니티 포크 AG2 검토.

이 글은 마케팅 문구가 아니라 각 프레임워크의 메커니즘과 트레이드오프, 그리고 "이럴 땐 쓰지 마라(when NOT)"까지 다룹니다. 버전·날짜·기능은 모두 공식 문서/릴리스에서 확인한 것만 적었고, 확인되지 않은 수치는 넣지 않았습니다. 모든 버전 정보는 본문에 명시한 시점(2026년 6월) 기준이며, 빠르게 바뀌므로 도입 전 공식 릴리스 노트를 한 번 더 확인하길 권합니다.

2. 문제 정의: 왜 "하나의 정답"이 없나

에이전트 프레임워크는 결국 세 가지를 대신 처리해 주는 도구입니다.

루프 관리 — 모델 호출 → 도구 실행 → 결과 반영 → 다시 모델 호출. 이 tool-use loop를 누가 돌리는가.
오케스트레이션 — 에이전트가 여러 개일 때 누가 누구에게 일을 넘기고(handoff), 언제 끝내는가.
상태와 복구 — 중간에 서버가 죽으면 대화·작업 상태가 날아가는가, 아니면 이어서 재개되는가.

프레임워크마다 이 셋을 보는 철학이 다릅니다. LangGraph는 "흐름을 명시적 그래프로 그려라", CrewAI는 "역할을 정의하면 협업은 알아서", OpenAI Agents SDK는 "핸드오프는 그냥 도구 호출일 뿐, 최소한만 추상화한다"는 입장입니다. 즉 같은 멀티 에이전트라도 추상화 레벨이 근본적으로 다릅니다.

그래서 "제일 좋은 프레임워크"는 질문 자체가 틀렸습니다. **"내 프로젝트가 제어 흐름을 얼마나 명시적으로 소유해야 하는가"**가 진짜 질문입니다. 며칠짜리 승인 워크플로를 안정적으로 재개해야 하는 백오피스 자동화와, 사내 슬랙봇에 도구 몇 개 붙이는 작업은 답이 다를 수밖에 없습니다.

3. 각 프레임워크의 정체성 (2026년 6월 기준)

LangGraph — 명시적 그래프 + durable execution

LangChain 팀이 만든 저수준(low-level) 오케스트레이션 프레임워크입니다. 2025년 10월 22일 LangChain과 함께 1.0이 정식 출시(GA)되었고, 1.0은 2.0 전까지 호환성 깨짐(breaking change) 없음을 약속한 안정 버전입니다. 핵심은 그래프(노드=단계, 엣지=흐름)로 워크플로를 명시적으로 정의하고, checkpointer로 상태를 영속화해 서버 재시작·LLM 공급자 장애 후에도 마지막 체크포인트부터 재개(durable execution)한다는 점입니다. Uber·LinkedIn·Klarna 등 프로덕션 사례가 공개돼 있습니다. LangChain 1.0의 create_agent 역시 LangGraph 런타임 위에서 동작합니다. 관측은 LangSmith와 자연스럽게 연결됩니다.

CrewAI — 역할 기반 크루 + 이벤트 기반 Flow

"처음부터 새로 만든, LangChain·다른 에이전트 프레임워크에 의존하지 않는 경량 파이썬 프레임워크"라고 공식 README가 명시합니다(과거 LangChain 의존 이미지와 달리, 현재는 독립). 두 축이 있습니다. Crews는 역할(role)·목표(goal)·배경(backstory)을 가진 에이전트들이 협업하는 단위이고, Flows는 조건 분기와 상태 관리를 갖춘 이벤트 기반 워크플로입니다. 본문 작성 시점 기준 최신은 1.14.7(2026년 6월 11일)입니다. 역할만 정의하면 빠르게 멀티 에이전트 팀을 띄울 수 있어 학습 곡선이 낮은 편입니다.

OpenAI Agents SDK — 최소 추상화, provider-agnostic

OpenAI가 공개한 경량 SDK로, Agents(지시·도구·가드레일·핸드오프를 가진 LLM), Handoffs(에이전트 간 위임 — LLM에게는 transfer_to_* 도구 호출로 보임), Guardrails(입출력 검증을 병렬 실행, tripwire로 빠르게 차단), Sessions(대화 이력 자동 관리), Tracing(실행 추적), 그리고 음성용 Realtime Agents를 제공합니다. 중요한 오해 정정: 이름은 OpenAI지만 OpenAI Responses/Chat Completions API뿐 아니라 100여 종의 다른 LLM도 지원합니다(provider-agnostic). 파이썬과 JS/TS 두 갈래가 있고, 본문 작성 시점 파이썬 최신은 v0.17.5(2026년 6월 11일)입니다.

AutoGen — 유지보수 모드, 후속은 Microsoft Agent Framework

여기가 2026년에 가장 헷갈리는 지점입니다. AutoGen은 현재 유지보수 모드로, 공식 저장소가 "새 기능·개선 없이 커뮤니티가 관리한다"고 명시합니다(마지막 안정 릴리스 python-v0.7.5, 2025년 9월 30일). Microsoft는 후속으로 Microsoft Agent Framework(MAF) 1.0을 2026년 4월 3일 GA했고, 이는 Semantic Kernel의 엔터프라이즈 기반 + AutoGen의 오케스트레이션을 하나로 통합한 SDK입니다(.NET·Python 지원, sequential·concurrent·handoff·group chat·Magentic-One 오케스트레이션, MCP/A2A, YAML 선언적 에이전트). 한편 원래 AutoGen 코드베이스를 이어가려는 커뮤니티 포크 AG2도 존재합니다. 그래서 "AutoGen을 새로 도입한다"면, 정확히는 MAF 또는 AG2 중 무엇을 말하는지 먼저 정해야 합니다.

참고: 같은 결의 모델 네이티브 SDK로 Anthropic Claude Agent SDK(서브에이전트별 독립 컨텍스트, 세션, MCP, HITL)가 있습니다. Claude 중심 스택이라면 함께 검토할 만합니다.

4. 선택 기준: 어떤 질문에 답하면 프레임워크가 정해지나

도입 결정을 빠르게 내리려면 아래 순서로 자문하세요. 위쪽 질문일수록 결정력이 큽니다.

제어 흐름을 명시적으로 소유해야 하나?
- 예 → LangGraph(그래프로 분기·반복·중단점을 직접 설계).
- 아니오, 역할만 나눠 빠르게 협업시키면 됨 → CrewAI.
중간에 죽어도 재개돼야 하나? (며칠짜리 승인·장기 워크플로)
- 예 → LangGraph(checkpointer 기반 durable execution이 1급 기능).
특정 모델 생태계에 단단히 묶여 있나?
- OpenAI 중심·경량 → OpenAI Agents SDK(단, 다른 모델도 지원).
- Claude 중심 → Claude Agent SDK.
- .NET·MS 엔터프라이즈 → Microsoft Agent Framework.
팀 규모·운영 부담은?
- 빠른 프로토타입·소규모 → CrewAI / OpenAI Agents SDK.
- 장기 운영·관측·복구가 중요 → LangGraph / MAF.

상황·목적별 한 줄 추천

사내 도구 호출 챗봇(소규모, 빠른 출시) → OpenAI Agents SDK 또는 CrewAI.
역할 분담형 리서치·콘텐츠 파이프라인 → CrewAI.
HITL 승인이 끼는 백오피스 자동화(상태 영속 필수) → LangGraph.
.NET 기반 엔터프라이즈 → Microsoft Agent Framework.
연구·복잡한 멀티 에이전트 대화 실험 → AG2(또는 MAF로 이전 고려).

5. 비교 표: 핵심 차이 한눈에

아래 표의 버전은 본문 작성 시점(2026년 6월) 기준이며 빠르게 바뀝니다. 도입 전 공식 릴리스 노트를 다시 확인하세요.

항목	LangGraph	CrewAI	OpenAI Agents SDK	AutoGen → MAF
정체성	저수준 그래프 오케스트레이션	역할 기반 크루 + Flow	경량 핸드오프·가드레일	(유지보수) → 통합 엔터프라이즈 SDK
핵심 버전(시점 기준)	1.0 (2025-10-22 GA)	1.14.7 (2026-06-11)	v0.17.5 (2026-06-11, Python)	AutoGen python-v0.7.5 (2025-09-30) / MAF 1.0 (2026-04-03 GA)
추상화 레벨	낮음(명시적 제어)	높음(역할 선언)	낮음~중간(최소 추상화)	중간(오케스트레이션 패턴 다수)
상태 영속화/재개	1급 기능(checkpointer)	Flow 상태 관리	Sessions(이력 관리)	MAF: checkpoint·hydration
HITL	1급 API 지원	지원	내장 메커니즘	MAF 지원
모델 종속성	모델 무관(LangChain 통합)	모델 무관	provider-agnostic(100+ LLM)	MAF: Foundry·OpenAI·Claude·Bedrock·Gemini·Ollama
언어	Python, JS/TS	Python	Python, JS/TS	.NET, Python
관측/디버깅	LangSmith	자체 + 외부 연동	내장 Tracing	미들웨어 훅
학습 곡선	다소 가파름(그래프·상태 스키마)	완만(역할 DSL)	완만	중간
잘 맞는 곳	프로덕션·HITL·장기 워크플로	빠른 협업 프로토타입	경량·모델 네이티브	엔터프라이즈·.NET
주의(when NOT)	단순 챗봇엔 과함	세밀한 분기 제어엔 부족할 수 있음	복잡한 상태 그래프엔 부족	신규 AutoGen 도입은 MAF/AG2 먼저 확인

표의 "버전"과 "GA 날짜"는 공식 릴리스/블로그에서 확인한 값이며, 추정치는 넣지 않았습니다. 표에 없는 벤치마크 수치("N배 빠름" 등)는 벤더 자체 측정이라 그대로 인용하지 않았습니다.

6. 코드로 보는 차이: 핸드오프 vs 그래프 vs 크루

추상화 레벨의 차이를 같은 "분류 → 전문 에이전트로 위임" 시나리오로 비교하면 체감이 빠릅니다. (아래는 개념 설명용 최소 예시이며, 실제 API는 각 공식 문서를 따르세요.)

OpenAI Agents SDK — 핸드오프는 도구 호출

from agents import Agent, Runner

billing = Agent(name="Billing", instructions="결제/환불 문의 처리")
support = Agent(name="Support", instructions="일반 문의 처리")
triage = Agent(
    name="Triage",
    instructions="문의를 분류해 적절한 에이전트로 핸드오프",
    handoffs=[billing, support],  # LLM에는 transfer_to_billing 같은 도구로 노출
)

result = Runner.run_sync(triage, "카드 두 번 결제됐어요")
print(result.final_output)

LangGraph — 흐름을 그래프로 명시

from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import InMemorySaver

def triage(state): ...      # 분류 노드
def billing(state): ...      # 결제 처리 노드
def support(state): ...      # 일반 처리 노드

g = StateGraph(dict)
g.add_node("triage", triage); g.add_node("billing", billing); g.add_node("support", support)
g.add_edge(START, "triage")
g.add_conditional_edges("triage", lambda s: s["route"], {"billing": "billing", "support": "support"})
g.add_edge("billing", END); g.add_edge("support", END)

app = g.compile(checkpointer=InMemorySaver())  # 상태 영속화 → 재개 가능

CrewAI — 역할만 선언하면 협업

from crewai import Agent, Task, Crew

triager = Agent(role="분류 담당", goal="문의를 올바른 담당에게 배정", backstory="10년차 CS 리드")
resolver = Agent(role="해결 담당", goal="분류된 문의를 해결", backstory="결제 도메인 전문가")

crew = Crew(
    agents=[triager, resolver],
    tasks=[Task(description="카드 이중 결제 문의 처리", agent=triager, expected_output="처리 결과 요약")],
)
result = crew.kickoff()

핵심: OpenAI SDK는 "위임을 도구로" 최소 추상화, LangGraph는 "흐름·재개를 개발자가 명시적으로 소유", CrewAI는 "역할 선언만으로 협업" 합니다. 같은 일을 하더라도 코드가 보여주는 책임의 위치가 다릅니다.

7. 직접 붙여보며 느낀 트레이드오프와 한계

실제로 붙여보면 데모와 운영의 간극이 갈리는 지점들이 있습니다. 정직하게 적습니다.

LangGraph는 "옳지만 무겁다". 그래프·상태 스키마·체크포인터를 설계하는 초기 비용이 분명히 있습니다. 단순 단발성 도구 호출에는 과합니다. 대신 며칠짜리 HITL 승인 워크플로처럼 "죽어도 이어져야 하는" 요구가 생기면, 이 무게가 그대로 안정성으로 돌아옵니다.
CrewAI는 빠른 대신 세밀한 제어가 아쉬울 수 있다. 역할만 정의하면 금방 굴러가지만, "이 조건이면 반드시 이 분기"처럼 결정적(deterministic) 흐름이 중요해지면 Flow로 내려가 다시 흐름을 짜야 합니다. 프로토타입에서 빛나고, 정밀 제어가 핵심인 곳에서는 손이 더 갑니다.
OpenAI Agents SDK는 가볍지만 상태 그래프가 약하다. 핸드오프·가드레일·트레이싱이 깔끔하지만, 복잡한 분기·장기 상태 영속화가 필요하면 결국 더 무거운 도구가 필요합니다. "provider-agnostic"이라고 해도 OpenAI 모델에서 가장 매끄럽다는 점은 감안하세요.
AutoGen은 신규 도입 시 이름부터 확인. "AutoGen 쓰자"는 말이 MAF인지 AG2인지 원조 AutoGen인지 합의 없이 진행되면, 유지보수 모드 코드베이스에 신규 기능을 기대하는 미스매치가 생깁니다.

공통 함정 하나. 벤더가 제시하는 "N% 빠름 / N배 빠름" 같은 수치는 자체 벤치마크인 경우가 많습니다. 워크로드가 다르면 결과가 뒤집힙니다. 본인 워크로드로 작은 PoC를 돌려 측정하는 편이 어떤 비교 표보다 정확합니다.

8. 도입 팁: 한국 개발자 실무 관점

프레임워크 선택만큼 운영 디테일이 비용을 가릅니다. 한국 환경에서 특히 챙길 것들.

한국어 토큰 비용을 처음부터 설계에 반영하라. 같은 의미라도 한국어는 영어보다 토큰이 더 들기 쉽습니다(특히 구형 토크나이저일수록). 멀티 에이전트는 에이전트 수 × 컨텍스트 전달량만큼 토큰이 곱셈으로 늘어납니다. 그래서 (1) 핸드오프 시 "필요한 컨텍스트만" 넘기고, (2) Claude Agent SDK의 서브에이전트별 독립 컨텍스트처럼 컨텍스트 격리를 제공하는 구조를 활용하고, (3) 분류·라우팅 같은 단순 단계는 저렴한 소형 모델로 내리는 티어드 전략이 비용을 크게 줄입니다.
모델 라우팅을 프레임워크에 가두지 마라. OpenAI Agents SDK가 100여 종 모델을 지원하고 MAF가 멀티 프로바이더를 지원하는 것처럼, 모델 교체 여지를 남겨두면 국내 모델/리전 사정이나 가격 변동에 대응하기 쉽습니다.
관측·트레이싱을 1일차에 켜라. 멀티 에이전트는 "왜 이 답이 나왔는지" 추적이 어렵습니다. LangSmith(LangGraph)·내장 Tracing(OpenAI SDK)·미들웨어 훅(MAF)을 처음부터 켜두면 디버깅 시간이 줄어듭니다.
상태 저장소는 국내 인프라와 함께 결정하라. LangGraph의 PostgreSQL checkpointer처럼 상태를 외부 DB에 영속화한다면, 국내 리전 DB·개인정보 처리 정책과의 정합성을 초기에 맞춰야 나중에 재작업이 없습니다.
작게 시작하고, 요구가 커지면 갈아탄다. CrewAI/OpenAI SDK로 빠르게 검증하고, 상태·HITL·복구 요구가 분명해질 때 LangGraph/MAF로 옮기는 경로가 현실적입니다. 처음부터 무거운 프레임워크로 시작해 과설계하는 것이 더 흔한 실수입니다.

9. AIPida 관련 가이드 & 다음 단계

이 글은 프레임워크 "선택"에 초점을 맞췄습니다. 실제 설계·구현으로 넘어갈 때 AIPida의 아래 가이드를 함께 보면 좋습니다.

멀티 에이전트 오케스트레이션 — 여러 에이전트의 협업·조정 패턴: /guides/g-guide-15bbf
에이전트 설계 패턴(ReAct 등) — 추론·행동 루프 설계: /guides/g-ai-react-18e93
Agent Harness 설계 — 가드레일·권한·실행 경계 설계: /guides/agent-harness-design
LangChain vs LlamaIndex — 상위 생태계 비교: /guides/g-langchain-vs-llamaindex-3e08c
에이전트 메모리 — 컨텍스트·장기 메모리 전략(토큰 비용과 직결): /guides/g-guide-213aa

프레임워크는 도구일 뿐, 결국 좋은 에이전트는 명확한 권한 경계(harness)·검증된 도구·관측 가능성 위에서 나옵니다. 선택을 끝냈다면 위 가이드로 설계 단계를 이어가세요.

10. 자주 묻는 질문 (FAQ)

LangGraph와 CrewAI 중 뭘 먼저 써봐야 하나요?

빠른 검증·역할 분담형 협업이면 CrewAI가 학습 곡선이 낮아 시작이 쉽습니다. 다만 "중간에 죽어도 재개", "세밀한 분기 제어"가 핵심 요구라면 처음부터 LangGraph가 맞습니다.

OpenAI Agents SDK는 OpenAI 모델만 되나요?

아니요. 공식 문서 기준 OpenAI의 Responses/Chat Completions API 외에 100여 종의 다른 LLM도 지원하는 provider-agnostic 설계입니다. 다만 OpenAI 모델에서 가장 매끄럽게 동작하는 경향이 있습니다.

AutoGen, 지금 새로 도입해도 되나요?

원조 AutoGen은 현재 유지보수 모드(신규 기능 없음, 마지막 안정 python-v0.7.5)입니다. 신규 프로젝트라면 후속인 Microsoft Agent Framework 1.0(2026-04-03 GA, AutoGen+Semantic Kernel 통합) 또는 커뮤니티 포크 AG2를 먼저 검토하세요.

Microsoft Agent Framework는 AutoGen과 무슨 관계인가요?

Microsoft가 Semantic Kernel의 엔터프라이즈 기반과 AutoGen의 오케스트레이션을 하나로 합친 후속 SDK입니다. .NET과 Python을 지원하고 OpenAI·Claude·Bedrock·Gemini·Ollama 등 멀티 프로바이더를 지원합니다.

한국어 서비스에서 토큰 비용을 줄이려면?

핸드오프 시 필요한 컨텍스트만 전달하고, 컨텍스트 격리(서브에이전트별 독립 컨텍스트)를 활용하며, 분류·라우팅 같은 단순 단계는 저렴한 소형 모델로 내리는 티어드 전략이 효과적입니다. 한국어는 영어보다 토큰이 더 드는 경향이 있어 멀티 에이전트에서 비용이 곱셈으로 커집니다.

프레임워크 없이 직접 구현하면 안 되나요?

됩니다. 도구 호출 루프 하나면 단순 에이전트는 충분합니다. 프레임워크의 가치는 상태 영속화·HITL·핸드오프·관측을 직접 다시 만들지 않게 해주는 데 있습니다. 요구가 단순하면 프레임워크가 오히려 오버헤드일 수 있습니다.

벤더가 말하는 "N배 빠름" 같은 벤치마크를 믿어도 되나요?

참고만 하세요. 대부분 자체 측정이라 워크로드가 다르면 결과가 뒤집힙니다. 본인 워크로드로 작은 PoC를 돌려 측정하는 편이 정확합니다.

버전 정보는 얼마나 신뢰할 수 있나요?

이 글의 버전·날짜는 모두 본문 작성 시점(2026년 6월)에 공식 릴리스/문서에서 확인한 값입니다. 에이전트 생태계는 빠르게 바뀌므로 도입 직전 각 공식 릴리스 노트를 한 번 더 확인하세요.

← 모든 가이드