AI 에이전트 프레임워크 비교: LangGraph vs CrewAI vs AutoGen

2026년에 새 프로젝트를 시작해서는 안 될 이 비교에서 가장 많은 별을 받은 프레임워크는 무엇일까요?

AutoGen은 약 60,400개의 GitHub 스타를 보유하고 있으며, 이는 CrewAI의 57,100개와 LangGraph의 39,800개보다 많습니다. 하지만 지난 320일 동안 Python 버전을 출시하지 못했습니다. 마지막 태그 버전(python-v0.7.5)은 2025년 9월 30일에 배포되었습니다. 게다가 이 저장소는 2026년 4월 15일 이후로 커밋이 올라온 적이 없습니다. 그런데도 지금 작성되는 모든 'LangGraph vs CrewAI vs AutoGen' 게시물들은 여전히 이를 활성 옵션으로 취급하고 있습니다.

별의 개수와 실제 프로덕션 현실 사이의 간극, 이것이 바로 이 포스트가 다루는 핵심입니다. 기능 매트릭스가 아닙니다. 감사할 수 없는 벤치마크도 아닙니다. 각 프레임워크를 대규모로 실행했을 때 어디서 문제가 발생하는지, 누가 이를 유지 관리하는지, 그리고 문제가 생겼을 때 실제로 비용이 얼마나 드는지에 대한 증거들입니다.

여기에 제시된 모든 사실은 GitHub REST API, PyPI 릴리스 기록, 공식 README, 공급업체 마이그레이션 가이드, 공개 이슈 트래커 등에서 가져왔으며, 모두 2026년 8월 16일에 검증되었습니다. 증거가 측정치가 아닌 한 엔지니어의 계정에 기반한 경우, 그렇게 표시되어 있습니다.

핵심 요약 사항

• AutoGen은 자체 README에 따르면 유지보수 모드(maintenance mode)이며, Python 패키지는 약 320일 동안 안정적인 릴리스를 배포하지 못했습니다. 후속작은 Microsoft Agent Framework로, 2026년 4월 3일에 GA(General Availability)가 되었습니다. 새로운 프로젝트는 그곳에서 시작해야 합니다. AG2는 레거시 코드베이스에 대한 실제 선택지이며, 리브랜딩이 아닌 포크(fork)입니다.
• 별점(Stars)은 거짓말을 하고; 설치 횟수(Installs)가 진실에 가깝습니다. AutoGen은 별점에서는 앞서지만(약 60K), 월간 PyPI 설치 횟수에서는 뒤처집니다(약 1M). LangGraph는 별점이 더 적고(약 40K), 약 71M의 설치 횟수를 기록하여 AutoGen보다 대략 65배 높습니다. 이 격차는 어떤 정직한 주의사항으로도 사라지지 않습니다.
• 별점 대비 설치 비율을 역방향의 신선도 지표로 취급하세요. 별점은 최고조의 과대광고(hype) 시기에 축적되고; 설치 횟수는 현재 진행형 생산 의존도를 추적합니다. 높은 비율은 프로젝트가 한때 흥미로웠지만, 지금 어디에서도 핵심적인 역할을 하지 못한다는 것을 의미합니다.
• 2026년 8월 16일 기준으로 LangGraph 1.2.11, CrewAI 1.15.16, AutoGen 0.7.5 및 Microsoft Agent Framework 1.0을 검증했습니다. 이 카테고리는 몇 주 단위로 변하므로, 어떤 결정을 내리기 전에 PyPI에서 해당 버전을 확인하세요.
• 별점 수에 집착하지 마세요. 무엇이 배포되었는지, 무엇이 고장 났는지, 그리고 무엇이 여전히 유지보수되고 있는지에 집중하세요.

실제 시스템을 구상하는 것이지 단순한 스파이크(spike)를 위한 것이 아니라면, 프레임워크 선택은 프로덕션 에이전트 시스템 구축의 하나의 입력값일 뿐이며, 그 자체가 프로젝트가 출시될지 여부를 결정하는 입력값이 되는 경우는 드뭅니다.

2026년에 어떤 에이전트 프레임워크를 사용해야 할까요?

증거를 보기 전에 짧게 말씀드리자면.

명시적이고 감사 가능한(auditable) 제어 흐름과 지속적인 상태(durable state)가 필요하며, 그로 인해 발생하는 영속성(persistence) 작업을 처리할 인력이 확보된 경우 LangGraph를 선택하세요. 멀티 에이전트 워크플로우를 빠르게 프로토타이핑하고, 위임(delegation)이 모델 매개라는 점을 수용할 수 있다면 CrewAI를 선택하세요. AutoGen으로 시작하지 마세요: 2026년 8월 기준으로 README에 유지보수 모드(maintenance-mode) 배너가 있어 신규 사용자에게 다른 곳을 안내하고 있습니다. 이미 AutoGen을 사용 중이라면 목표는 2026년 4월부터 GA(General Availability)인 Microsoft Agent Framework이며, 이는 업그레이드가 아닌 재작성(rewrite)이 필요합니다. 그리고 만약 워크플로우가 루프 내에서 LLM 호출 세 번으로 구성되어 있다면, 아예 어떤 프레임워크도 사용하지 마세요.

왜 이 답변이 일반적이지 않은가

여기에 있는 모든 프레임워크는 도구를 호출하고 메시지를 전달할 수 있기 때문에 기능 매트릭스로는 이들을 구분할 수 없습니다. 이들을 구분하는 것은 규모(scale)에서 무엇이 실패하느냐입니다: LangGraph는 체크포인트 증가 시에 깨지고, CrewAI는 프롬프트 기반 위임에서 깨지며, AutoGen은 유지보수 문제에서 깨집니다. 이 게시물의 나머지는 각각의 증거이며, 트래커 이슈와 사후 분석(post-mortems)으로 문서화되어 있습니다.

중요하지만 비교 글에 나오지 않는 지표

스타는 후행 지표(lagging indicator)입니다. 이는 최고조의 기대감 속에서 북마크된 것을 기록하며, AutoGen의 경우 2024년 v0.2 출시 시기였습니다. 스타는 프로젝트가 조용해져도 무기한 축적되며 제거되지 않습니다. 설치 횟수는 정반대입니다: CI가 실행되거나 이미지가 재구축될 때마다 지불되는 반복적인 생산 비용입니다.

이 수치들은 완전히 분리되었습니다.

지난 30일간 월별 PyPI 설치 횟수

스타에서의 선두와 비교했을 때 65배의 설치 격차는 실제로 생산 부하가 어디에 있는지에 대한 강력한 신호입니다. 이것은 인기 경쟁이 아닙니다. 이는 부하 지도(load map)입니다.

GitHub 활동량: 스타(stars) 대 포크(forks)

릴리스 주기 또한 다른 각도에서 같은 이야기를 합니다. 2026년 8월 16일 기준 마지막 릴리스까지의 일수:

• AG2: 1일
• CrewAI 및 MS Agent Framework: 2일
• LangGraph: 5일
• AutoGen: 320일

프레임워크로 넘어가기 전에 한 가지 더 주기 관련 참고 사항이 있습니다. CrewAI는 8월 14일에 1.15.16을, 8월 12일에 1.15.15를, 8월 8일에 1.15.14를 출시했으며, 8월 5일에는 두 개의 버전을 출시했습니다. 이는 약 19일 동안 열 번의 릴리스에 해당합니다. 이것이 빠른 수정(fast fixes)을 의미하는지 아니면 빠른 변화(fast churn)를 의미하는지는 그들의 릴리스 프로세스를 얼마나 신뢰하느냐에 달려 있지만, 어느 쪽이든 시작하기 전에 버전을 고정해야 합니다.

정신적 모델 (그리고 왜 모델이 중요한가)

LangGraph는 중앙 상태 객체(central state object)를 가진 방향성 그래프(directed graph)입니다. 에이전트는 노드(node)이며, 엣지(edge)가 흐름을 정의합니다. 조건부 엣지(conditional edges)는 분기 처리를 담당합니다. 리듀서(reducers)는 동시 상태 업데이트를 병합합니다. 사용자가 제어 흐름을 그리고, LLM이 그 안에서 실행됩니다. 정신적 모델은 상태 기계(state machine)이며, 프레임워크가 코드 내에서 이를 강제합니다.

내장 원시 요소(Built-in primitives): 영속적 실행(durable execution) (체크포인팅, 중단 후 재개), 인간 참여형 루프(human-in-the-loop) (그래프 중단, 입력 수집, 재개), 단기 및 장기 메모리. 이 세 가지 중에서 제어권이 어디에 있는지 가장 명시적으로 보여줍니다.

CrewAI는 역할 기반 팀입니다. 모든 에이전트는 역할(role), 목표(goal), 배경 이야기(backstory), 그리고 도구(tools)를 가집니다. Crew는 작업을 순차적 또는 계층적으로 실행합니다. 계층적 모드에서는 자동 생성된 매니저 에이전트가 위임하고 검토합니다. 런타임은 계층 구조를 제공하며, 그 안에서의 위임 결정은 개발자가 정의한 조건부 엣지(conditional edges)로 인코딩되기보다는 모델에 의해 중재됩니다. 더 새로운 원시 요소인 Flow는 이벤트 기반 파이프라인으로, 예측 가능한 프로덕션 제어를 제공합니다: 단계당 하나의 LLM 호출만 발생하며 자율적인 위임은 없습니다.

AutoGen은 현재 유지보수 모드에서 대화 주도형 멀티 에이전트 런타임입니다. 두 에이전트 채팅, LLM 기반 스피커 선택기를 사용한 그룹 채팅, 순차적 및 중첩된 대화를 지원합니다. 후속작인 Microsoft Agent Framework는 동일한 패턴을 가지고 있지만 아키텍처가 다릅니다. AutoGen 자체는 개발되고 있지 않습니다.

AutoGen의 라이선스는 그 자체로 플래그를 달 가치가 있습니다. 왜냐하면 이것은 기술적인 문제가 아니라 조달(procurement) 문제이기 때문입니다: GitHub는 해당 레포지토리를 CC-BY-4.0으로 감지하고, README에는 이중 CC-BY-4.0 및 MIT 배열이 설명되어 있으며, PyPI는 MIT를 보고합니다. 귀하의 법무팀은 그 대화를 즐기지 못할 것입니다.

LangGraph가 프로덕션에서 깨지는 지점

실패 지점은 API가 아닙니다. 툴링(tooling)도 아닙니다.

체크포인터(checkpointer), 그리고 특히 아무도 체크포인트 증가를 계획하지 않았을 때 Postgres 인스턴스에 무슨 일이 발생하는지입니다.

Tiendanube의 엔지니어인 Tadeo Donegana Braunschweig가 2026년 4월에 이 주제에 대한 가장 명확한 공개 계정을 발표했습니다. 주당 12만 건 이상의 대화량을 처리하면서, 그의 팀의 체크포인트 테이블은 무한정 증가했습니다. 오픈 소스 체크포인터에는 네이티브 TTL(Time-To-Live) 기능이 없습니다. 평균적인 대화는 단 두 개의 메시지와 세 번의 도구 호출 후에도 네 개의 체크포인트 테이블에 걸쳐 약 93개의 행을 생성했습니다.

메시지 두 개만으로 데이터베이스가 93개 행 더 무거워집니다.

스테이징 환경에서 checkpoint_blobs만 단 일주일간의 트래픽 후 56MB에 달했습니다. 그의 요약은 다음과 같습니다: 운영 데이터베이스는 운영 상태를 저장해야 하며, 역사적 기록(historical exhaust)을 저장해서는 안 됩니다.

이는 한 팀의 불운한 설정 문제가 아닙니다. LangGraphJS 추적기에서 #1138 이슈,

하지만 이것에만 의존하기 전에 세 가지 주의사항이 있습니다. 이 기능은 2026-05-12일 LangGraph 1.2.0 버전으로 출시되었으며, 베타(beta)로 표시되어 있고 옵트인(opt-in) 방식입니다. 즉, 실제로 특정 채널을 어노테이션(annotate)하지 않는 한 업그레이드한다고 해서 아무런 변화가 없습니다. 이미 테이블에 작성된 데이터는 그대로 남아 있습니다.

여기서 운영 작업 예산을 책정하지 않은 팀들에게 비용 문제가 발생합니다. LangGraph의 체크포인트 패키지(checkpoint, checkpoint-postgres, checkpoint-sqlite)는 핵심(core) 버전과 분리되어 관리됩니다. 만약 core 버전을 고정하고 체크포인터들을 유동적으로 사용한다면, 스택의 절반만 확보하게 되는 것입니다. 출시 전에 지속성(persistence) 작업을 예산에 포함해야 하며, 나중에 처리해서는 안 됩니다.

브라운슈바이크가 제시한 세 가지 수정 사항은 일반적입니다. 체크포인트 테이블 생성은 LangGraph의 setup()을 호출하는 대신 Alembic 마이그레이션으로 통합하여, 모든 것과 마찬가지로 스키마를 버전 관리해야 합니다. 또한 분석에 필요하다면 히스토리를 오브젝트 스토리지(object storage)로 아카이브하는 주간 작업을 병행하여 주기적인 TTL 삭제를 실행해야 합니다. 그리고 체크포인트는 선택적으로 수행하세요: 슈퍼바이저 그래프(supervisor graph)만 지속성 있게 유지하고 서브그래프(sub-graph)는 상태 비저장(stateless)으로 유지합니다. 이 중 어느 것도 생소한 작업이 아니며, 바로 이것 때문에 에이전트 프로토타입이 이미 존재하는 제품에 덧붙여질 때 건너뛰어지게 됩니다.

타입 지정(typed-state) 관련 불만

지속성 문제와는 별개로, 상태 타입 지정에 대한 반복적인 사용 편의성(ergonomics) 반론이 있으며, 이는 신중하게 언급해야 합니다. 왜냐하면 이 주장의 강한 버전은 틀렸기 때문입니다. StateGraph는 실제 스키마인 TypedDict, 데이터클래스(dataclass), 또는 재귀적 유효성 검사(recursive validation)를 원한다면 Pydantic BaseModel을 수용합니다. LangGraph가 비타입 지정 방식은 아닙니다.

문제는 한 단계 위에서 발생합니다. LangChain 자체 문서에서도 상위 레벨의 create_agent 팩토리가 Pydantic 상태 스키마를 지원하지 않는다고 언급하며, 대부분의 팀이 시작하는 곳이 바로 이 팩토리입니다. 따라서 타입 지정 기능은 사용자가 진급하게 될 API에서는 제공되지만, 사용자가 시작하는 API에서는 그렇지 않습니다. Hacker News의 한 엔지니어는 이러한 좌절감을 이렇게 표현했습니다:

저의 langgraph 경험에 비추어 볼 때, 모든 그래프의 상태가 타이핑이 매우 최소화된 어리석은 JSON 블롭(JSON blob)이라서 런타임 타입 에러를 고치는 데 너무 많은 시간을 소비하게 됩니다. 그리고 데이터가 시스템을 어떻게 통과하는지 알아내기가 정말 어렵습니다.

이것은 한 가지 의견일 뿐입니다. 하지만 증거가 없는 것은 아니며, 그 증거들은 같은 부분(seam)을 가리킵니다. Issue #5891의 TypeError: Type is not msgpack serializable: Send는 create_react_agent 버그이며, 이는 Pydantic 스키마를 받아들일 수 없는 정확한 팩토리 경로입니다. Issue #740의 (상태 쓰기 시 InvalidUpdateError)는 같은 근본 원인을 지적합니다: 상태 모양이 정의 시간(definition time)이 아니라 런타임(runtime)에 발견된다는 것입니다.