목차
- Before: AgentExecutor 시절
- After: 상태 그래프 기반 전환
- 에이전트 프레임워크, 왜 지금 비교가 필요한가
- 설계 철학부터 다르다
- LangGraph — 명시적 제어가 주는 안정감
- AutoGen — 대화 프로토콜의 가능성과 함정
- CrewAI — 가장 빠르게 프로토타입을 만든다
- 실무 선택 기준 — 프로젝트 성격이 답을 정한다
- 프로덕션 배포를 고려하면 달라지는 것들
- 당장 할 수 있는 것
Before: AgentExecutor 시절
LangChain의 AgentExecutor로 RAG 파이프라인에 멀티스텝 추론을 붙이던 시절이 있었다. 에이전트가 도구를 호출하고, 결과를 보고, 다음 행동을 결정하는 루프가 전부였다. 단순한 시나리오에서는 잘 돌아갔다. 검색 한 번 하고 응답 생성하는 정도는 문제가 없었다.
문제는 분기가 생기면서 시작됐다. 검색 결과가 불충분하면 재검색, 도구 호출이 실패하면 폴백, 사용자 의도가 모호하면 확인 질문. 이런 조건부 흐름을 AgentExecutor 안에서 제어하려니 디버깅이 사실상 불가능했다. 로그를 뒤져봐도 "어느 스텝에서 어떤 상태였는지"를 재현하기 어려웠고, 에이전트가 왜 그 판단을 내렸는지 추적할 수 없었다.
After: 상태 그래프 기반 전환
지금은 다르다. 상태 그래프 기반 프레임워크로 전환하고 나서, 각 노드의 입출력을 명시적으로 추적할 수 있게 됐다. 에이전트가 5단계를 거치든 10단계를 거치든, 어디서 분기했고 왜 그 경로를 탔는지 시각적으로 확인된다. 실패 시 특정 노드로 되돌려서 재실행하는 것도 가능해졌다. 체감상 디버깅 시간이 절반 이하로 줄었다.
이 전환 과정에서 LangGraph, AutoGen, CrewAI 세 프레임워크를 모두 검토했다. 이 글은 그 AI 에이전트 프레임워크 비교 결과를 정리한 것이다. 2026년 4월 기준 각 프레임워크의 설계 철학, 실무 적용성, 어떤 상황에서 어떤 걸 고르는 게 합리적인지를 다룬다.
에이전트 프레임워크, 왜 지금 비교가 필요한가
단순 프롬프트 체이닝만으로 충분한 시대는 지났다. 2025년부터 LLM 기반 에이전트가 단일 호출을 넘어서 멀티스텝 추론, 도구 사용, 자기 수정까지 수행하는 방향으로 진화했다. OpenAI의 Agents SDK, Anthropic의 Claude Agent SDK 등 LLM 제공사들도 에이전트 인프라를 직접 내놓기 시작한 시점이다.
에이전트가 3개의 도구를 순서대로 호출해야 하는 상황을 생각해보자. 첫 번째 도구가 타임아웃 나면? 두 번째 도구의 결과가 JSON 파싱 에러를 뱉으면? 세 번째 도구 호출 전에 사용자 확인이 필요하면? 이런 분기 처리를 하드코딩하면 if-else가 수십 개 생기고, 새로운 도구 하나 추가할 때마다 코드 전체를 건드려야 한다. 에이전트 프레임워크는 바로 이 복잡성을 구조적으로 관리하기 위해 존재한다.
2026년 4월 현재 실무에서 진지하게 검토할 만한 오픈소스 프레임워크는 세 가지로 좁혀진다. LangGraph, AutoGen, CrewAI. 각각의 접근 방식이 근본적으로 다르기 때문에, "어떤 게 최고냐"보다 "내 상황에 어떤 게 맞느냐"가 올바른 질문이다.
설계 철학부터 다르다
세 프레임워크를 처음 접하면 "다 비슷한 거 아닌가"라는 인상을 받기 쉽다. 공식 문서의 첫 페이지만 봐도 다 "멀티에이전트", "도구 사용", "자율적 실행"을 내세운다. 실제로 써보면 완전히 다른 도구라는 걸 알게 된다.
LangGraph: 상태 머신으로 흐름을 설계한다
LangGraph는 에이전트를 **방향성 그래프(Directed Graph)**로 모델링한다. 노드는 함수이고, 엣지는 조건부 분기다. 상태(State)가 그래프를 따라 흘러가면서 각 노드에서 변환된다. 컴파일러 이론이나 워크플로우 엔진에 익숙한 개발자라면 바로 와닿는 모델이다.
핵심은 명시성이다. 어떤 조건에서 어떤 노드로 가는지가 코드에 그대로 드러난다. 암묵적인 루프나 매직 없이, 개발자가 모든 분기를 직접 정의한다. 이건 디버깅과 유지보수에서 큰 차이를 만든다. LangChain 팀이 만들었기 때문에 LangChain 생태계의 도구, 프롬프트 템플릿, 출력 파서를 그대로 가져다 쓸 수 있다는 것도 장점이다. (출처: LangGraph 공식 문서)
AutoGen: 에이전트끼리 대화하게 한다
AutoGen은 에이전트를 대화 참여자로 모델링한다. 에이전트 A가 메시지를 보내면 에이전트 B가 응답하고, 필요하면 에이전트 C에게 위임한다. 인간이 팀으로 일할 때 대화하는 방식을 모방한 것이다. 멀티에이전트 시나리오에서 직관적이라는 강점이 있다.
Microsoft Research에서 시작한 프로젝트로, 2025년에 AutoGen 0.4(AgentChat)로 대규모 리아키텍처를 거쳤다. 이전 0.2 버전과 API가 완전히 달라졌다는 점은 주의가 필요하다. (출처: AutoGen GitHub)
CrewAI: 역할을 부여하고 태스크를 할당한다
CrewAI는 역할(Role) 기반이다. "연구원 에이전트", "편집자 에이전트"처럼 각 에이전트에 자연어로 역할을 부여하고, 태스크를 할당하면 순차적으로 또는 병렬로 실행된다. 세 프레임워크 중 개념이 가장 직관적이다. 프롬프트 엔지니어링 경험만 있으면 금방 시작할 수 있다.
LangGraph — 명시적 제어가 주는 안정감
LangGraph의 구조는 코드를 보면 이해가 빠르다.
from langgraph.graph import StateGraph, END
from typing import TypedDict
class AgentState(TypedDict):
messages: list
current_step: str
retry_count: int # 재시도 횟수 추적용
# 그래프 정의
graph = StateGraph(AgentState)
graph.add_node("analyze", analyze_input)
graph.add_node("search", search_documents)
graph.add_node("generate", generate_response)
# 조건부 분기 — 분석 결과에 따라 검색할지 바로 생성할지 결정
graph.add_conditional_edges("analyze", route_decision)
graph.add_edge("search", "generate")
graph.add_edge("generate", END)
app = graph.compile()
여기서 add_conditional_edges가 핵심이다. route_decision 함수가 현재 상태를 보고 다음 노드를 결정한다. 이 분기 로직이 코드에 명시적으로 드러나기 때문에, 6개월 뒤에 다른 사람이 이 코드를 봐도 흐름을 파악할 수 있다. AgentExecutor의 암묵적 루프와 비교하면 유지보수성 차이가 크다.
체크포인트와 상태 복원
LangGraph의 또 다른 강점은 내장 체크포인트 기능이다. SqliteSaver나 PostgresSaver 같은 체크포인터를 붙이면 각 노드 실행 후 상태가 자동으로 저장된다. LLM API 호출이 중간에 실패해도 마지막 성공 노드에서 재시작할 수 있다. 프로덕션에서 OpenAI API가 간헐적으로 429 에러를 뱉는 상황을 겪어본 적 있다면, 이게 왜 중요한지 바로 이해될 것이다.
LangSmith와의 연동도 언급할 만하다. 각 노드의 실행 시간, 토큰 사용량, 입출력 데이터를 대시보드에서 모니터링할 수 있다. 에이전트가 왜 그 경로를 탔는지 사후 분석이 가능해진다.
러닝커브라는 현실적 장벽
솔직히 처음에 StateGraph 개념을 잡는 데 시간이 꽤 걸렸다. "상태가 그래프를 따라 흐른다"는 개념 자체는 단순한데, TypedDict로 상태 스키마를 정의하고 reducer 함수로 상태를 병합하는 패턴까지 익숙해지려면 공식 튜토리얼을 두세 번은 따라 해봐야 한다. 기존에 LangChain을 써본 경험이 있어도 LangGraph는 별개의 학습이 필요하다. "LangChain 아니까 금방 하겠지"라는 기대는 버리는 게 좋다.
AutoGen — 대화 프로토콜의 가능성과 함정
AutoGen으로 프로토타입을 만들었을 때 인상적이었던 건 멀티에이전트 대화의 자연스러움이다. "코드 작성 에이전트"와 "코드 리뷰 에이전트"를 만들어서 대화시키면, 실제로 코드를 생성하고 리뷰하고 수정하는 루프가 자동으로 돌아간다. 처음 봤을 때 꽤 인상적이었다.
문제는 이 루프가 언제 끝나는지 제어하기 어렵다는 거다. 에이전트 A가 코드를 작성하고, 에이전트 B가 "이 부분을 수정해라"고 피드백하면, A가 수정본을 내놓고, B가 또 피드백하고… 이게 7턴을 넘어가면서 같은 지적이 반복되는 상황이 실제로 발생했다. max_turns 파라미터로 상한을 걸 수 있지만, 적절한 값을 찾는 것 자체가 또 다른 과제다. 너무 낮게 잡으면 작업이 미완성 상태로 끝나고, 너무 높게 잡으면 토큰 비용이 예측 불가능해진다.
0.4 리아키텍처의 영향
AutoGen 0.4에서 도입된 AgentChat API는 이전 버전과 호환되지 않는다. ConversableAgent, UserProxyAgent 같은 0.2 시절 클래스를 쓴 코드는 전면 마이그레이션이 필요하다. 이 과정에서 생태계가 파편화된 측면이 있다. Stack Overflow나 블로그에서 찾은 AutoGen 코드가 0.2 기준인 경우가 아직 많다. 그대로 복사해서 실행하면 ImportError: cannot import name 'ConversableAgent' 같은 에러를 만나게 된다. 공식 문서부터 확인하는 습관이 필수다.
코드 실행 내장이라는 차별점
AutoGen의 분명한 강점은 코드 실행 환경이 내장되어 있다는 점이다. 에이전트가 Python 코드를 생성하면, Docker 컨테이너 안에서 바로 실행하고, 결과를 받아서 다음 행동을 결정할 수 있다. LocalCommandLineCodeExecutor나 DockerCommandLineCodeExecutor를 설정하면 된다.
from autogen_ext.code_executors.docker import DockerCommandLineCodeExecutor
code_executor = DockerCommandLineCodeExecutor(
image="python:3.12-slim", # 실행 환경 이미지
timeout=60, # 60초 타임아웃
work_dir="./output"
)
코드 생성-실행-검증 사이클이 핵심인 프로젝트라면 AutoGen이 가장 자연스러운 선택이다. 데이터 분석 자동화, 코드 리뷰 봇 같은 유스케이스에서 진가를 발휘한다.
CrewAI — 가장 빠르게 프로토타입을 만든다
CrewAI는 세 프레임워크 중 러닝커브가 가장 낮다. "에이전트에게 역할을 주고, 태스크를 할당한다"는 멘탈 모델이 비개발자에게도 통할 정도로 직관적이다. 역할 정의가 자연어 기반이라는 것도 진입 장벽을 낮춘다. role="Senior Data Analyst", goal="Analyze sales data and find trends" 같은 식으로 에이전트를 정의하면, 내부적으로 LLM에게 시스템 프롬프트로 전달된다. 프롬프트 엔지니어링을 프레임워크가 대신 해주는 셈이다.
프로토타이핑 속도는 체감상 LangGraph 대비 3~4배 빠르다. 그래프 구조를 설계하고 상태 스키마를 정의할 필요 없이, 에이전트 몇 개와 태스크 몇 개를 선언하면 바로 실행할 수 있다. PM에게 데모를 보여줘야 하는 상황에서 이 속도 차이는 결정적이다.
문제는 프로토타입 이후 단계에서 발생한다. 복잡한 조건부 분기가 필요해지면 CrewAI의 추상화가 오히려 걸림돌이 된다. 에이전트가 어떤 순서로 실행됐는지, 중간에 어떤 판단을 내렸는지 추적하기 어렵다. 에러가 나도 스택 트레이스가 프레임워크 내부 코드로 가득 차서 원인 파악에 시간이 걸린다. 높은 추상화 수준이 주는 전형적인 트레이드오프인데, 이건 CrewAI만의 문제가 아니라 "Convention over Configuration" 계열 프레임워크가 공통적으로 안고 있는 한계이기도 하다.
세밀한 상태 관리나 커스텀 에러 핸들링이 필요해지면 결국 프레임워크 내부를 뜯어봐야 하는 상황이 온다. 이때 CrewAI의 내부 구현이 LangGraph만큼 투명하지 않다는 점이 부담으로 작용한다.
실무 선택 기준 — 프로젝트 성격이 답을 정한다
세 프레임워크를 핵심 기준으로 비교하면 다음과 같다. 2026년 4월 기준이며, 각 프레임워크의 업데이트 주기가 빠르므로 시점에 따라 달라질 수 있다.
| 기준 | LangGraph | AutoGen | CrewAI |
|---|---|---|---|
| 설계 패러다임 | 상태 그래프 | 대화 프로토콜 | 역할/태스크 |
| 러닝커브 | 높음 | 중간 (0.4 이후 혼란 가중) | 낮음 |
| 디버깅 용이성 | 높음 (상태 추적 내장) | 낮음 (대화 흐름 추적 어려움) | 중간 |
| 프로덕션 준비도 | 높음 (체크포인트, LangSmith) | 중간 | 초기 단계 |
| 코드 실행 내장 | 없음 (별도 구현 필요) | 있음 (Docker 기반) | 없음 |
| 멀티에이전트 협업 | 수동 구성 필요 | 네이티브 지원 | 네이티브 지원 |
| LangChain 호환 | 완전 호환 | 없음 | 부분 호환 |
이 표에서 패턴이 보인다. 제어와 안정성이 중요하면 LangGraph, 에이전트 간 자율 대화가 핵심이면 AutoGen, 빠른 PoC가 우선이면 CrewAI다.
프로젝트 유형별 권장 사항
RAG 기반 질의응답 에이전트를 만든다면 LangGraph가 적합하다. 검색 → 관련성 평가 → 재검색 → 생성이라는 흐름을 그래프로 명시적으로 표현할 수 있고, LangChain의 Retriever를 그대로 활용할 수 있다. Adaptive RAG, Corrective RAG 같은 고급 패턴도 LangGraph 기반 구현 예제가 가장 풍부하다.
코드 생성 자동화나 데이터 분석 파이프라인이라면 AutoGen을 고려할 만하다. 코드 생성 → 실행 → 에러 확인 → 수정이라는 사이클이 AutoGen의 대화 패턴과 잘 맞는다. 에이전트가 직접 코드를 돌려보고 결과를 확인하는 루프를 별도 인프라 없이 구성할 수 있다.
팀에 LLM 엔지니어링 경험이 적고, 2주 안에 PoC를 만들어서 비즈니스 팀에 보여줘야 하는 상황이면 CrewAI가 합리적이다. 역할 기반 설계가 비기술 이해관계자에게 설명하기도 쉽고, 데모까지의 경로가 가장 짧다.
프로덕션 배포를 고려하면 달라지는 것들
프로토타입에서 잘 돌아가던 에이전트가 프로덕션에서 문제를 일으키는 경우는 흔하다. LLM 호출은 비결정적이고, 외부 API는 실패할 수 있고, 비용은 에이전트가 몇 턴을 도느냐에 따라 수배씩 차이가 난다.
LangGraph는 이 영역에서 현재 가장 성숙한 편이다. 앞서 언급한 체크포인트 기능으로 실패 복구가 가능하고, LangSmith를 통한 모니터링으로 병목 구간을 식별할 수 있다. LangGraph Cloud(구 LangGraph Platform)를 통해 호스팅 배포까지 지원하는 구조라서, "개발 → 테스트 → 배포"까지의 경로가 가장 매끄럽다.
AutoGen은 Azure AI Foundry와의 통합을 강점으로 내세우고 있지만, 에이전트 간 대화의 비결정성이 프로덕션에서는 리스크로 작용한다. 같은 입력에 대해 에이전트가 3턴 만에 끝낼 수도 있고 10턴을 돌 수도 있다. 이건 곧 비용 예측이 어렵다는 뜻이다. 월간 예산을 잡아야 하는 상황에서 이 불확실성은 꽤 부담스럽다.
CrewAI는 모니터링, 체크포인트, 에러 복구 같은 프로덕션 필수 기능을 대부분 직접 구현해야 한다. CrewAI Enterprise라는 유료 서비스가 존재하지만, 2026년 4월 기준으로는 아직 초기 단계라는 평가가 우세하다. 프로덕션 적용을 고려한다면 CrewAI 위에 자체 인프라를 상당 부분 얹어야 한다는 점을 감안해야 한다.
당장 할 수 있는 것
이론적 비교는 여기까지다. 세 프레임워크의 차이를 체감하는 가장 빠른 방법은 같은 문제를 각각으로 구현해보는 것이다. 추천하는 액션은 세 가지다.
첫째, 간단한 ReAct 에이전트(검색 도구 1개 + 응답 생성)를 세 프레임워크로 각각 만들어보자. 구현 시간 차이, 코드 가독성 차이, 에러 발생 시 디버깅 경험 차이를 직접 느낄 수 있다. 둘째, 각 프레임워크의 공식 튜토리얼을 하나씩 따라 해보자. LangGraph는 Quick Start, AutoGen은 AgentChat 가이드, CrewAI는 Getting Started가 출발점으로 적합하다. 셋째, 프로덕션을 고려한다면 LangGraph의 체크포인트 기능과 LangSmith 연동부터 실험해보는 게 좋다. 이 두 가지가 프로덕션에서 가장 큰 차이를 만드는 요소다.
다만 이 영역은 6개월 단위로 판도가 바뀌는 중이라, 지금의 AI 에이전트 프레임워크 비교가 하반기에도 유효할지는 더 지켜봐야 한다.
관련 글
- Python으로 AI 에이전트 자동화 구축하기 — 작업 분해와 오류 복구 실전 기록 – 주간 리포트를 자동화하려고 Python으로 AI 에이전트 파이프라인을 처음 만들었다. 한 덩어리 스크립트에서 시작해 작업 분해 → 툴 연동…
- OpenAI Assistants API로 RAG 구축하기 — 파일 검색부터 함수 호출까지 – LangChain + ChromaDB 조합의 RAG 파이프라인을 OpenAI Assistants API로 교체한 경험이다. 벡터스토어 자동…
- ChatGPT API 비용 72% 줄인 실전 최적화 — 토큰 절약과 캐싱 전략 – GPT-4o와 gpt-4o-mini의 토큰당 단가 차이는 16배다. 이 차이를 활용한 모델 라우팅, 프롬프트 압축, 시멘틱 캐싱 세 가지 …
