각 프레임워크를 "단순↔복잡" × "오프라인/데이터↔온라인/추론" 2차원에 배치.
💡 핵심 개념: 프레임워크 선택은 기능 비교가 아니라 내 상황에 맞는 위치 매핑. x축은 "도구 사용 난이도", y축은 "데이터/추론 어느 쪽에 시간 들이는가".
quadrantChart
title LLM 프레임워크 전략 맵
x-axis "단순한 사용성 --> 복잡한 워크플로우"
y-axis "오프라인/데이터 --> 온라인/추론"
quadrant-1 "복잡 에이전트 (오케스트레이션)"
quadrant-2 "프롬프트·타입 (경량 추론)"
quadrant-3 "데이터 중심 (RAG/ETL)"
quadrant-4 "고급 데이터 파이프라인"
LlamaIndex: [0.55, 0.50]
Haystack: [0.65, 0.40]
LangGraph: [0.85, 0.90]
AutoGen: [0.75, 0.85]
CrewAI: [0.65, 0.85]
DSPy: [0.70, 0.75]
Pydantic AI: [0.45, 0.80]
Semantic Kernel: [0.80, 0.75]
Instructor: [0.35, 0.70]
🔧 사분면별 해석
- 좌하(Q3): 데이터 중심 — 인덱싱·ETL에 시간. 예: LlamaIndex. 사내 문서 QA 파이프라인.
- 좌상(Q2): 프롬프트·타입 (경량 추론) — 단순 API 호출 + 구조화 출력. 예: Pydantic AI, Instructor. 빠른 프로토타입, 백엔드 통합.
- 우상(Q1): 복잡 에이전트 — 다단계 추론, 멀티에이전트. 예: LangGraph, AutoGen, CrewAI. 복잡한 워크플로우 자동화.
- 우하(Q4): 고급 데이터 파이프라인 — Haystack 같은 production-grade 검색 시스템.
📋 구체적 예시: "내 팀은 FastAPI 백엔드에 RAG 붙이려 한다" → 좌상(Q2) + 좌하(Q3) 조합 추천: Pydantic AI로 타입 안전한 호출 + LlamaIndex로 인덱싱.
⚠️ 흔한 함정:
- "무조건 LangChain" 신봉 → 실제론 80% 경우 LlamaIndex/Pydantic AI가 더 깔끔
- 프로토타입에 LangGraph 도입 → 그래프 디버깅이 처음엔 너무 복잡
- 오프라인 데이터 작업 적은 팀이 Haystack 도입 → 도구 과잉
🛠️ 1줄 추천: 데이터 많음 → LlamaIndex. 백엔드 통합 → Pydantic AI. 에이전트 → LangGraph(명시적 그래프) or AutoGen(대화형).