AI agent framework를 고를 때 LangGraph, CrewAI, AutoGen 이름을 자주 보게 됩니다. 셋 다 에이전트를 만들 수 있지만, 같은 문제를 같은 방식으로 푸는 도구는 아닙니다.
핵심은 프레임워크 이름보다 내가 만들려는 agent의 제어 방식이 무엇인지 먼저 정하는 것입니다. stateful workflow인지, 역할 기반 multi-agent인지, 대화형 agent 실험인지에 따라 선택 기준이 달라집니다.
LangGraph는 언제 먼저 볼까
LangGraph는 상태가 오래 유지되고, 중간에 멈췄다가 이어가고, 사람이 개입하고, workflow를 그래프로 제어해야 하는 agent에 잘 맞습니다. 공식 문서도 long-running, stateful agent orchestration을 강조합니다.
- 명시적인 state graph가 필요하다
- 단계별 control flow를 직접 설계하고 싶다
- human-in-the-loop가 중요하다
- trace와 eval을 운영 흐름에 붙이고 싶다
CrewAI는 어떤 문제에 어울릴까
CrewAI는 agent의 역할과 crew, flow를 중심으로 생각하기 쉽습니다. 리서처, 작성자, 리뷰어처럼 역할을 나누고 협업 흐름을 구성하는 데 초점을 맞춘 접근이 자연스럽습니다.
- 역할 기반 agent 구성이 직관적이다
- crew 단위로 작업을 나누고 싶다
- 업무 자동화 flow를 빠르게 만들고 싶다
- memory, knowledge, observability 같은 운영 요소를 함께 보고 싶다
AutoGen은 언제 후보가 될까
AutoGen은 conversational single/multi-agent application을 만들기 위한 AgentChat과, 더 확장된 event-driven multi-agent system을 위한 Core를 제공합니다. 대화형 agent 실험과 multi-agent 연구/프로토타입에 잘 맞는 편입니다.
같은 agent라도 설계 출발점이 다르다
세 프레임워크의 차이는 기능 목록보다 설계 출발점에서 더 잘 보입니다. LangGraph는 상태와 노드를 먼저 생각하게 만들고, CrewAI는 역할과 작업 분담을 먼저 생각하게 만들며, AutoGen은 agent 간 대화와 이벤트 흐름을 먼저 생각하게 만듭니다.
- 상태 전이가 복잡하다: LangGraph 쪽이 먼저 후보가 된다
- 역할 기반 작업 분담이 핵심이다: CrewAI가 읽기 쉽다
- agent 간 대화와 실험이 중요하다: AutoGen이 자연스럽다
- 단순 tool calling loop라면 굳이 큰 프레임워크가 필요 없을 수도 있다
비교 기준을 코드보다 먼저 정한다
- 작업이 graph workflow인지 role collaboration인지 정한다
- 상태를 얼마나 오래 보존해야 하는지 본다
- tool 호출과 외부 실행 권한이 얼마나 중요한지 본다
- 관찰성, eval, 재시도, 중단 복구가 필요한지 본다
- 팀이 이해하고 운영할 수 있는 추상화 수준인지 확인한다
예시 상황 1: 승인 단계가 있는 업무 자동화
문서 수집, 초안 작성, 검토, 승인, 발행처럼 중간에 사람이 확인해야 하는 흐름이라면 LangGraph가 잘 맞을 수 있습니다. 상태가 오래 살아 있고, 특정 지점에서 멈췄다가 다시 이어가는 구조가 중요하기 때문입니다.
collect_sources
-> draft
-> human_review
-> revise
-> publish예시 상황 2: 역할을 나눠 협업하는 리서치 작업
리서처, 분석가, 작성자, 리뷰어처럼 역할이 뚜렷한 작업은 CrewAI식 사고가 직관적일 수 있습니다. 각 agent의 목표와 책임을 분리하고, crew 단위로 결과를 모으는 방식이 설명하기 쉽습니다.
예시 상황 3: agent 간 대화 실험
서로 다른 agent가 대화하며 결론을 만들거나, multi-agent 패턴을 연구하고 싶다면 AutoGen이 후보가 됩니다. 특히 AgentChat처럼 대화형 추상화로 시작하고 나중에 Core로 확장하는 흐름을 볼 수 있습니다.
운영에서 꼭 봐야 할 리스크
- 프레임워크가 대신 품질을 보장해주지는 않는다
- 도구 권한과 side effect를 제한하지 않으면 위험하다
- agent가 많아질수록 디버깅과 비용 추적이 어려워진다
- 프롬프트 수정 후 회귀 테스트가 없으면 이전 작업이 망가질 수 있다
- 로그와 trace 없이 production agent를 운영하면 실패 원인을 찾기 어렵다
선택을 미루는 것도 전략이다
처음부터 큰 agent framework를 고르면 구조가 빨리 잡히는 대신, 문제 자체를 프레임워크 방식에 맞추게 될 수 있습니다. 간단한 tool calling loop로 충분한지 먼저 확인하고, 상태 관리와 관찰성이 실제로 필요해질 때 프레임워크를 도입해도 늦지 않습니다.
- 단일 LLM 호출로 되는지 확인한다
- tool calling이 필요한지 확인한다
- 상태가 여러 단계에 걸쳐 유지되어야 하는지 확인한다
- 사람 승인이나 중단 복구가 필요한지 확인한다
- 그때 LangGraph, CrewAI, AutoGen 중 맞는 추상화를 고른다
특히 production에서는 데모가 잘 되는 것보다 실패했을 때 어디서 멈췄고 어떤 도구를 왜 호출했는지 설명할 수 있는지가 더 중요합니다. 이 기준을 만족하지 못하면 프레임워크를 바꿔도 운영 품질은 크게 좋아지지 않습니다.
한 줄로 정리하면
- LangGraph: 세밀하게 제어하는 stateful workflow
- CrewAI: 역할 기반 crew와 업무 flow
- AutoGen: conversational multi-agent와 event-driven 확장
정리
LangGraph, CrewAI, AutoGen은 모두 AI agent를 만들 수 있지만 선택 기준은 다릅니다. 복잡한 상태 흐름을 직접 제어해야 하면 LangGraph, 역할 기반 협업을 빠르게 구성하려면 CrewAI, 대화형 multi-agent 실험과 확장을 보려면 AutoGen을 먼저 검토할 수 있습니다.
최신 세부 기능은 각각 LangGraph 문서, CrewAI 문서, AutoGen 문서를 기준으로 확인해야 합니다. tool 설계는 tool description 글과 함께 보면 좋습니다.
