프레임워크 비교와 선택

프레임워크 선택의 핵심은 "기능이 가장 많은가"가 아니라, 팀이 감당할 수 있는 추상화 수준과 운영 방식이 맞는가입니다. 아래 비교는 2026년 3월 27일 기준으로 각 공식 문서의 개념 모델을 바탕으로 정리한 것입니다.

비교 축

축	질문
추상화 수준	low-level graph인가, opinionated runtime인가
주 언어/런타임	Python 중심인가, TypeScript 중심인가
강한 영역	workflow, multi-agent, memory, eval, UI 연계 중 무엇이 강한가
운영 적합성	tracing, guardrail, human-in-the-loop를 어떻게 다루는가

프레임워크 요약

프레임워크	성격	강점	주의점	잘 맞는 팀
LangGraph	graph 중심 orchestration	세밀한 제어, 상태 그래프, 긴 workflow	추상화가 낮아 설계 책임이 큼	복잡한 workflow를 직접 설계할 팀
AutoGen / MS Agent Framework	agent interaction + graph workflow	AutoGen + Semantic Kernel 통합, A2A/AG-UI/MCP 지원	구성 옵션이 많아 운영 설계가 필요	Microsoft 생태계 중심 엔터프라이즈 팀
OpenAI Agents SDK	agent, handoff, session 중심 SDK	WebSocket 전송, 도구 검색 네임스페이스	생태계가 SDK 중심으로 좁을 수 있음	OpenAI 중심 스택을 빠르게 구축할 팀
CrewAI	역할 기반 multi-agent + Flows	Flows 이벤트 드리븐 (12M+/일), Qdrant Edge 메모리	role abstraction이 과해지면 통제 어려움	business workflow를 빠르게 조립할 팀
Vercel AI SDK	TypeScript 기반 app/agent integration	UI, tools, agent loop, 웹앱 연계 강함	장기 workflow는 별도 조합이 필요	TS/Next.js 기반 제품 팀
Mastra	JS/TS 올인원 agent framework	workflow, memory, eval을 한 스택에서 다룸	프레임워크 의존성이 커질 수 있음	JS/TS에서 통합 개발 경험을 원하는 팀

프레임워크 선택 의사결정 트리

선택 가이드

LangGraph

적합: 상태 그래프, fan-out/fan-in, human checkpoint, long-running workflow를 세밀하게 제어해야 할 때
주의: framework가 설계를 대신해주지 않으므로 상태와 eval 설계를 직접 해야 합니다.
구체적 한계: state graph 노드가 10개 이상이 되면 조건부 분기와 상태 전이 조합이 기하급수적으로 늘어나 디버깅과 테스트가 급격히 어려워집니다. 그래프를 sub-graph로 분리하지 않으면 단일 그래프가 관리 불가 수준에 도달합니다.

CrewAI (v1.12.1)

CrewAI v1.12.1에서 Flows 패턴이 안정화되었습니다 (이벤트 드리븐, 12M+ 실행/일).

적합: 역할 기반 협업을 business workflow로 빠르게 모델링할 때
Flows: 이벤트 드리븐 실행 패턴으로, crew 간 조건부 분기와 병렬 실행을 선언적으로 구성
메모리: Qdrant Edge 기반 로컬 벡터 메모리 지원 — 클라우드 의존 없이 agent 메모리 구축
human-in-the-loop: 승인 게이트와 피드백 루프를 workflow 레벨에서 설정 가능
주의: "에이전트 역할명"이 설계 사고를 대신하지 않게 해야 합니다.
구체적 한계: role abstraction(Researcher, Writer 등)이 편리하지만, agent 내부의 세밀한 프롬프트 제어나 단계별 조건 분기가 필요한 경우 추상화가 오히려 방해됩니다. "역할을 더 나누면 해결된다"는 착각으로 agent 수만 늘어나는 패턴에 주의해야 합니다.

AutoGen / Microsoft Agent Framework

Microsoft Agent Framework가 GA로 출시되면서 AutoGen과 Semantic Kernel이 통합되었습니다.

적합: 그래프 기반 워크플로우와 엔터프라이즈 통합(Azure, M365)이 필요할 때
강점: A2A, AG-UI, MCP 프로토콜을 모두 네이티브 지원하여 프로토콜 선택 유연성이 높음
주의: 통합 범위가 넓은 만큼 초기 설정과 운영 설계에 시간이 필요합니다.
구체적 한계: 러닝 커브가 높습니다. AutoGen, Semantic Kernel, Agent Framework 세 레이어의 개념 모델이 각각 다르고, .NET을 우선 지원하므로 Python 팀은 기능 지원 시차를 감수해야 합니다. 문서도 세 프로젝트에 분산되어 있어 진입점 찾기가 어렵습니다.

OpenAI Agents SDK (0.13.1)

OpenAI Agents SDK 0.13.1에서 WebSocket 전송과 도구 검색 네임스페이스가 추가되었습니다.

적합: agent, handoff, session, guardrail 같은 기본 primitive를 통일된 방식으로 쓰고 싶을 때
WebSocket 전송: 양방향 실시간 통신으로 스트리밍과 푸시 알림을 단일 연결에서 처리
도구 검색 네임스페이스: 대규모 tool set에서 agent가 관련 도구만 동적으로 로드하는 패턴
주의: 특정 벤더 SDK 중심으로 표준화되므로 tool/runtime 경계를 분리해서 보는 편이 좋습니다.
구체적 한계: OpenAI 모델 외의 LLM(Claude, Gemini, 오픈소스 모델)을 사용하려면 어댑터를 직접 구현해야 하고, 일부 기능(tracing, guardrail)이 OpenAI 플랫폼에 종속적입니다. 멀티 모델 전략을 쓰는 팀에는 구조적 제약이 됩니다.

Vercel AI SDK

적합: TypeScript 제품 팀이 agent를 앱과 함께 배포하고, tool loop와 UI 통합까지 빠르게 만들고 싶을 때
주의: durable workflow, queue, approval 같은 장기 실행 문제는 별도 오케스트레이션 계층과 결합해야 합니다.

Mastra

적합: JS/TS에서 workflow, memory, eval, agent를 한 체계로 가져가고 싶을 때
주의: 통합 경험이 강한 만큼 프레임워크 바깥으로 추상화를 분리할 계획이 필요합니다.

Google ADK (Agent Development Kit)

적합: Gemini 모델 중심으로 agent를 빠르게 구축하고 Google Cloud 생태계와 연결해야 할 때
구체적 한계: A2A 프로토콜 지원은 강하지만, MCP 등 다른 agent 간 통신 프로토콜과의 호환은 제한적입니다. Google Cloud 외 환경에서의 배포 경험이 부족하며, 다른 LLM과의 교체 유연성이 낮습니다.

상황별 추천

상황	우선 검토
복잡한 상태 그래프와 checkpoint 중심	LangGraph
역할 기반 business automation + Flows	CrewAI
MS 생태계 통합, 멀티프로토콜 필요	MS Agent Framework (AutoGen + Semantic Kernel)
OpenAI 중심 agent runtime 표준화	OpenAI Agents SDK
TypeScript 웹앱과 agent 통합	Vercel AI SDK
JS/TS 통합 올인원 경험	Mastra

도입 전 확인 질문

질문	의미
상태 전이를 직접 설계할 팀인가	낮은 추상화 프레임워크가 맞을 수 있음
agent 협업보다 제품 UI 통합이 중요한가	app integration 강한 스택이 유리
eval, tracing, guardrail을 프레임워크 안에서 가져가고 싶은가	운영 기능 내장 여부를 우선 확인
Python 생태계가 중심인가, TypeScript 생태계가 중심인가	언어 불일치는 유지보수 비용으로 이어짐
장기 실행과 승인 재개가 핵심인가	workflow/persistence 우선 검토

프레임워크를 바꿔도 남겨야 할 것

프레임워크 선택과 무관하게 다음 자산은 독립적으로 유지하는 편이 좋습니다.

agent 계약 문서
tool schema
eval set
approval policy
observability 필드 체계

이 다섯 가지가 프레임워크 안에만 묶여 있으면 이탈 비용이 커집니다.

프레임워크 마이그레이션 가이드

프레임워크를 바꿔야 할 때, 가장 큰 비용은 코드가 아니라 프레임워크에 묻혀버린 설계 결정을 다시 꺼내는 것입니다.

LangChain에서 LangGraph로

LangChain의 chain 추상화가 복잡한 분기/상태 관리에 한계를 보이면 LangGraph로 전환합니다.

계약 추출: 기존 chain에서 tool schema, prompt template, output parser를 프레임워크 독립 모듈로 분리합니다. langchain.tools에 묶인 함수들을 순수 Python 함수로 꺼냅니다.
그래프 재설계: chain의 순차 실행을 state graph 노드로 매핑합니다. 분기 로직은 conditional_edge로, 반복 로직은 cycle로 명시합니다. 기존 SequentialChain이 숨기고 있던 상태 전이가 드러나므로 이 단계에서 설계를 재점검합니다.

CrewAI에서 커스텀 오케스트레이션으로

CrewAI의 role 추상화가 세밀한 제어를 방해하면 직접 오케스트레이션을 구축합니다.

역할 해체: 각 Agent의 role, goal, backstory를 분석하여 실제로 필요한 것이 "역할"인지 "특정 tool + prompt 조합"인지 구분합니다. 대부분은 후자입니다.
흐름 재구성: Crew의 process (sequential/hierarchical)를 명시적 DAG나 state machine으로 변환합니다. Task 간 의존성을 코드로 선언하고, CrewAI의 암묵적 context 전달을 명시적 state 객체로 바꿉니다.

OpenAI Agents SDK에서 멀티모델 구조로

벤더 종속을 해소하고 여러 LLM을 활용해야 할 때의 전환입니다.

인터페이스 분리: Agent, Handoff, GuardrailFunction 등 SDK 타입에 직접 의존하는 코드를 추상 인터페이스 뒤로 숨깁니다. tool 정의는 SDK 포맷이 아닌 JSON Schema 기반으로 통일합니다.
런타임 교체: 추상 인터페이스 구현체를 LLM별로 만들어 설정으로 전환할 수 있게 합니다. tracing은 OpenTelemetry 같은 벤더 중립 계층으로 옮깁니다.

안티패턴

안티패턴	문제	개선
데모가 화려한 프레임워크를 바로 채택	운영 모델과 맞지 않을 수 있음	팀 역량과 use case 기준으로 평가
프레임워크가 곧 아키텍처라고 생각	핵심 설계 책임이 가려짐	패턴과 계약을 먼저 정의
한 프레임워크 기능에 지나치게 잠김	이식성과 교체 비용 증가	contracts/evals 분리
language fit을 무시	조직 속도 저하	기존 스택과 운영 환경 우선
추상화 레이어 과잉	프레임워크 위에 자체 추상화를 쌓아 디버깅 불가	프레임워크 API를 직접 사용하되, 계약만 분리
프레임워크 과의존 — "프레임워크가 알아서 해줄 것"	error handling, retry, timeout을 프레임워크 기본값에 위임	운영 정책을 명시적으로 선언하고 테스트
벤더 종속 무시	특정 벤더 SDK에 tool/prompt/eval이 모두 묶임	tool schema는 JSON Schema 기반으로 독립, eval set은 프레임워크 외부에 유지

ADR 스타일 결론

Decision

프레임워크는 오케스트레이션 설계를 대체하지 않습니다. 팀의 주 언어, 필요한 추상화 수준, 장기 실행과 observability 요구사항을 기준으로 고르고, agent 계약과 eval 세트는 프레임워크 바깥 자산으로 유지합니다.

비교 축

축	질문
추상화 수준	low-level graph인가, opinionated runtime인가
주 언어/런타임	Python 중심인가, TypeScript 중심인가
강한 영역	workflow, multi-agent, memory, eval, UI 연계 중 무엇이 강한가
운영 적합성	tracing, guardrail, human-in-the-loop를 어떻게 다루는가

프레임워크 요약

프레임워크	성격	강점	주의점	잘 맞는 팀
LangGraph	graph 중심 orchestration	세밀한 제어, 상태 그래프, 긴 workflow	추상화가 낮아 설계 책임이 큼	복잡한 workflow를 직접 설계할 팀
AutoGen / MS Agent Framework	agent interaction + graph workflow	AutoGen + Semantic Kernel 통합, A2A/AG-UI/MCP 지원	구성 옵션이 많아 운영 설계가 필요	Microsoft 생태계 중심 엔터프라이즈 팀
OpenAI Agents SDK	agent, handoff, session 중심 SDK	WebSocket 전송, 도구 검색 네임스페이스	생태계가 SDK 중심으로 좁을 수 있음	OpenAI 중심 스택을 빠르게 구축할 팀
CrewAI	역할 기반 multi-agent + Flows	Flows 이벤트 드리븐 (12M+/일), Qdrant Edge 메모리	role abstraction이 과해지면 통제 어려움	business workflow를 빠르게 조립할 팀
Vercel AI SDK	TypeScript 기반 app/agent integration	UI, tools, agent loop, 웹앱 연계 강함	장기 workflow는 별도 조합이 필요	TS/Next.js 기반 제품 팀
Mastra	JS/TS 올인원 agent framework	workflow, memory, eval을 한 스택에서 다룸	프레임워크 의존성이 커질 수 있음	JS/TS에서 통합 개발 경험을 원하는 팀

적합: 상태 그래프, fan-out/fan-in, human checkpoint, long-running workflow를 세밀하게 제어해야 할 때
주의: framework가 설계를 대신해주지 않으므로 상태와 eval 설계를 직접 해야 합니다.
구체적 한계: state graph 노드가 10개 이상이 되면 조건부 분기와 상태 전이 조합이 기하급수적으로 늘어나 디버깅과 테스트가 급격히 어려워집니다. 그래프를 sub-graph로 분리하지 않으면 단일 그래프가 관리 불가 수준에 도달합니다.

CrewAI (v1.12.1)

CrewAI v1.12.1에서 Flows 패턴이 안정화되었습니다 (이벤트 드리븐, 12M+ 실행/일).

적합: 역할 기반 협업을 business workflow로 빠르게 모델링할 때
Flows: 이벤트 드리븐 실행 패턴으로, crew 간 조건부 분기와 병렬 실행을 선언적으로 구성
메모리: Qdrant Edge 기반 로컬 벡터 메모리 지원 — 클라우드 의존 없이 agent 메모리 구축
human-in-the-loop: 승인 게이트와 피드백 루프를 workflow 레벨에서 설정 가능
주의: "에이전트 역할명"이 설계 사고를 대신하지 않게 해야 합니다.
구체적 한계: role abstraction(Researcher, Writer 등)이 편리하지만, agent 내부의 세밀한 프롬프트 제어나 단계별 조건 분기가 필요한 경우 추상화가 오히려 방해됩니다. "역할을 더 나누면 해결된다"는 착각으로 agent 수만 늘어나는 패턴에 주의해야 합니다.

AutoGen / Microsoft Agent Framework

Microsoft Agent Framework가 GA로 출시되면서 AutoGen과 Semantic Kernel이 통합되었습니다.

적합: 그래프 기반 워크플로우와 엔터프라이즈 통합(Azure, M365)이 필요할 때
강점: A2A, AG-UI, MCP 프로토콜을 모두 네이티브 지원하여 프로토콜 선택 유연성이 높음
주의: 통합 범위가 넓은 만큼 초기 설정과 운영 설계에 시간이 필요합니다.
구체적 한계: 러닝 커브가 높습니다. AutoGen, Semantic Kernel, Agent Framework 세 레이어의 개념 모델이 각각 다르고, .NET을 우선 지원하므로 Python 팀은 기능 지원 시차를 감수해야 합니다. 문서도 세 프로젝트에 분산되어 있어 진입점 찾기가 어렵습니다.

OpenAI Agents SDK (0.13.1)

OpenAI Agents SDK 0.13.1에서 WebSocket 전송과 도구 검색 네임스페이스가 추가되었습니다.

적합: agent, handoff, session, guardrail 같은 기본 primitive를 통일된 방식으로 쓰고 싶을 때
WebSocket 전송: 양방향 실시간 통신으로 스트리밍과 푸시 알림을 단일 연결에서 처리
도구 검색 네임스페이스: 대규모 tool set에서 agent가 관련 도구만 동적으로 로드하는 패턴
주의: 특정 벤더 SDK 중심으로 표준화되므로 tool/runtime 경계를 분리해서 보는 편이 좋습니다.
구체적 한계: OpenAI 모델 외의 LLM(Claude, Gemini, 오픈소스 모델)을 사용하려면 어댑터를 직접 구현해야 하고, 일부 기능(tracing, guardrail)이 OpenAI 플랫폼에 종속적입니다. 멀티 모델 전략을 쓰는 팀에는 구조적 제약이 됩니다.

Vercel AI SDK

적합: TypeScript 제품 팀이 agent를 앱과 함께 배포하고, tool loop와 UI 통합까지 빠르게 만들고 싶을 때
주의: durable workflow, queue, approval 같은 장기 실행 문제는 별도 오케스트레이션 계층과 결합해야 합니다.

Mastra

적합: JS/TS에서 workflow, memory, eval, agent를 한 체계로 가져가고 싶을 때
주의: 통합 경험이 강한 만큼 프레임워크 바깥으로 추상화를 분리할 계획이 필요합니다.

Google ADK (Agent Development Kit)

적합: Gemini 모델 중심으로 agent를 빠르게 구축하고 Google Cloud 생태계와 연결해야 할 때
구체적 한계: A2A 프로토콜 지원은 강하지만, MCP 등 다른 agent 간 통신 프로토콜과의 호환은 제한적입니다. Google Cloud 외 환경에서의 배포 경험이 부족하며, 다른 LLM과의 교체 유연성이 낮습니다.

상황별 추천

상황	우선 검토
복잡한 상태 그래프와 checkpoint 중심	LangGraph
역할 기반 business automation + Flows	CrewAI
MS 생태계 통합, 멀티프로토콜 필요	MS Agent Framework (AutoGen + Semantic Kernel)
OpenAI 중심 agent runtime 표준화	OpenAI Agents SDK
TypeScript 웹앱과 agent 통합	Vercel AI SDK
JS/TS 통합 올인원 경험	Mastra

도입 전 확인 질문

질문	의미
상태 전이를 직접 설계할 팀인가	낮은 추상화 프레임워크가 맞을 수 있음
agent 협업보다 제품 UI 통합이 중요한가	app integration 강한 스택이 유리
eval, tracing, guardrail을 프레임워크 안에서 가져가고 싶은가	운영 기능 내장 여부를 우선 확인
Python 생태계가 중심인가, TypeScript 생태계가 중심인가	언어 불일치는 유지보수 비용으로 이어짐
장기 실행과 승인 재개가 핵심인가	workflow/persistence 우선 검토

프레임워크를 바꿔도 남겨야 할 것

프레임워크 선택과 무관하게 다음 자산은 독립적으로 유지하는 편이 좋습니다.

agent 계약 문서
tool schema
eval set
approval policy
observability 필드 체계

이 다섯 가지가 프레임워크 안에만 묶여 있으면 이탈 비용이 커집니다.

프레임워크 마이그레이션 가이드

프레임워크를 바꿔야 할 때, 가장 큰 비용은 코드가 아니라 프레임워크에 묻혀버린 설계 결정을 다시 꺼내는 것입니다.

LangChain에서 LangGraph로

LangChain의 chain 추상화가 복잡한 분기/상태 관리에 한계를 보이면 LangGraph로 전환합니다.

계약 추출: 기존 chain에서 tool schema, prompt template, output parser를 프레임워크 독립 모듈로 분리합니다. langchain.tools에 묶인 함수들을 순수 Python 함수로 꺼냅니다.
그래프 재설계: chain의 순차 실행을 state graph 노드로 매핑합니다. 분기 로직은 conditional_edge로, 반복 로직은 cycle로 명시합니다. 기존 SequentialChain이 숨기고 있던 상태 전이가 드러나므로 이 단계에서 설계를 재점검합니다.

CrewAI에서 커스텀 오케스트레이션으로

CrewAI의 role 추상화가 세밀한 제어를 방해하면 직접 오케스트레이션을 구축합니다.

역할 해체: 각 Agent의 role, goal, backstory를 분석하여 실제로 필요한 것이 "역할"인지 "특정 tool + prompt 조합"인지 구분합니다. 대부분은 후자입니다.
흐름 재구성: Crew의 process (sequential/hierarchical)를 명시적 DAG나 state machine으로 변환합니다. Task 간 의존성을 코드로 선언하고, CrewAI의 암묵적 context 전달을 명시적 state 객체로 바꿉니다.

OpenAI Agents SDK에서 멀티모델 구조로

벤더 종속을 해소하고 여러 LLM을 활용해야 할 때의 전환입니다.

인터페이스 분리: Agent, Handoff, GuardrailFunction 등 SDK 타입에 직접 의존하는 코드를 추상 인터페이스 뒤로 숨깁니다. tool 정의는 SDK 포맷이 아닌 JSON Schema 기반으로 통일합니다.
런타임 교체: 추상 인터페이스 구현체를 LLM별로 만들어 설정으로 전환할 수 있게 합니다. tracing은 OpenTelemetry 같은 벤더 중립 계층으로 옮깁니다.

안티패턴

안티패턴	문제	개선
데모가 화려한 프레임워크를 바로 채택	운영 모델과 맞지 않을 수 있음	팀 역량과 use case 기준으로 평가
프레임워크가 곧 아키텍처라고 생각	핵심 설계 책임이 가려짐	패턴과 계약을 먼저 정의
한 프레임워크 기능에 지나치게 잠김	이식성과 교체 비용 증가	contracts/evals 분리
language fit을 무시	조직 속도 저하	기존 스택과 운영 환경 우선
추상화 레이어 과잉	프레임워크 위에 자체 추상화를 쌓아 디버깅 불가	프레임워크 API를 직접 사용하되, 계약만 분리
프레임워크 과의존 — "프레임워크가 알아서 해줄 것"	error handling, retry, timeout을 프레임워크 기본값에 위임	운영 정책을 명시적으로 선언하고 테스트
벤더 종속 무시	특정 벤더 SDK에 tool/prompt/eval이 모두 묶임	tool schema는 JSON Schema 기반으로 독립, eval set은 프레임워크 외부에 유지

ADR 스타일 결론

Decision

프레임워크 비교와 선택

목차

프레임워크 비교와 선택

목차