에이전트 프레임워크 비교, LangChain, LangGraph, CrewAI, AutoGen, n8n
요약
- 다섯 개를 나란히 놓으면 같은 층에 있지 않습니다. LangChain은 컴포넌트 라이브러리, LangGraph는 그 아래의 실행 엔진, CrewAI는 역할 기반 오케스트레이터, Microsoft Agent Framework는 엔터프라이즈 런타임, n8n은 워크플로 자동화 도구입니다. 먼저 층을 맞춰야 비교가 성립합니다.
- 가장 중요한 갈림길은 누가 흐름을 정하느냐입니다. LangGraph는 개발자가 그래프로 못 박고, CrewAI Crews는 에이전트에게 위임하고, n8n은 사람이 캔버스로 그립니다. 이 선택이 디버깅 난이도와 재현성을 통째로 결정합니다.
- AutoGen은 끝났습니다. 공식 저장소가 유지보수 모드를 선언했고 신규 기능이 없습니다. 후속은 Microsoft Agent Framework이며, 마지막 AutoGen 릴리스는 2025년 9월입니다. 지금 새로 시작한다면 AutoGen을 고를 이유가 없습니다.
- n8n은 오픈소스가 아닙니다. Sustainable Use License라는 fair-code 라이선스이고, 파일명에
.ee가 붙은 코드는 엔터프라이즈 라이선스가 있어야 씁니다. 사내 도입 전에 법무 검토가 필요한 유일한 후보입니다. - 자주 하는 오해 하나. CrewAI는 더 이상 LangChain 위에 있지 않습니다. 현행 패키지의 56개 의존성 중 langchain 계열이 하나도 없습니다.
1장. 무엇을 고르는 문제인가
1.1 프레임워크가 실제로 해주는 일
에이전트를 직접 짜면 결국 이 여섯 가지를 만들게 됩니다.
① 모델 호출 추상화
OpenAI, Anthropic, 로컬 모델을 같은 인터페이스로
② 도구 등록과 실행
함수를 스키마로 바꾸고, 모델의 호출 요청을 실제 실행으로 잇기
③ 루프 제어
언제 도구를 더 부르고 언제 멈출지
④ 상태 관리
대화 기록, 중간 결과, 스크래치패드
⑤ 지속성
중간에 죽으면 어디서부터 다시 할지
⑥ 관측
무슨 일이 일어났는지 나중에 들여다보기프레임워크마다 이 여섯 중 어디에 힘을 줬는지가 다릅니다. 그게 사실상 전부입니다.
1.2 층위가 다르다는 것부터
정체성이 서로 다르다
LangChain 모델, 도구, 리트리버를 표준 인터페이스로 감싼 컴포넌트 라이브러리
LangGraph 상태를 들고 노드를 오가는 저수준 실행 엔진
CrewAI 역할을 가진 에이전트들을 묶어 태스크를 굴리는 오케스트레이터
MS Agent Framework .NET 과 Python 을 함께 쓰는 엔터프라이즈 에이전트 런타임
n8n 노드를 캔버스에 연결하는 범용 워크플로 자동화 도구"어느 게 제일 좋냐" 는 질문이 성립하지 않는다
LangChain 과 LangGraph 는 같은 회사의 서로 다른 층이고
n8n 은 애초에 에이전트 전용 도구가 아니다1.3 비교 축 다섯
이 글 전체에서 이 다섯 축으로 봅니다.
① 제어권 흐름을 개발자가 정하나, LLM 이 정하나, 사람이 그리나
② 상태 상태를 명시적으로 다루나, 프레임워크가 감추나
③ 지속성 중단과 재개, 체크포인트가 되나
④ 진입장벽 코드 몇 줄로 시작되나
⑤ 라이선스 상업적 사용에 제약이 있나2장. LangChain
2.1 무엇인가
LLM 애플리케이션의 부품들을 표준 인터페이스로 감싼 라이브러리
채팅 모델, 임베딩, 벡터스토어, 리트리버, 도구, 출력 파서
"모델을 바꿔도 코드가 안 바뀌게" 가 원래 목적이다from langchain.chat_models import init_chat_model
model = init_chat_model("openai:gpt-5.5")
result = model.invoke("Hello, world!")init_chat_model의 문자열 하나만 바꾸면 공급자가 바뀝니다. LangChain이 파는 것의 본질이 이것입니다.
2.2 v1.0에서 무엇이 바뀌었나
LangChain은 오랫동안 "체인을 잇는 라이브러리"였고, 그 시절의 AgentExecutor가 불투명하다는 비판을 받았습니다.
1.0 (2025-10-17) 이후
에이전트 생성이 LangGraph 위에 올라탔다
즉 고수준 API 를 부르면 내부적으로 그래프가 만들어진다
레거시 체인 추상화가 정리되고
"컴포넌트 라이브러리 + 표준 진입점" 으로 역할이 좁혀졌다그래서 지금의 LangChain 을 이렇게 읽으면 정확하다
부품 카탈로그 + 가장 흔한 에이전트를 한 줄로 만드는 진입점
복잡한 제어가 필요해지면 LangGraph 로 내려간다2.3 장점
통합 폭이 압도적이다
모델, 벡터DB, 도구, 로더의 커넥터 수가 다른 프레임워크와 비교가 안 된다
"그 서비스 붙이려면 뭐 써야 하죠" 의 답이 대체로 여기 있다
공급자 교체가 진짜로 쉽다
추상화가 이 목적 하나에 맞춰져 있다
자료가 가장 많다
막혔을 때 검색으로 풀리는 확률이 가장 높다
LangSmith 와의 연결이 매끄럽다
관측과 평가가 별도 통합 작업 없이 붙는다2.4 단점
추상화가 두껍다
무슨 프롬프트가 실제로 나갔는지 추적하기 어렵다는 비판이 오래 있었다
1.0 에서 많이 걷어냈지만 여전히 계층이 있다
버전 변화가 잦았다
0.x 시절 코드가 지금 안 도는 경우가 흔하다
블로그와 튜토리얼의 코드가 오래되기 쉽다
의존성이 무겁다
통합이 많다는 것의 이면이다
세밀한 제어에는 부족하다
조건 분기, 루프, 중단과 재개를 정교하게 다루려면
결국 LangGraph 로 내려가야 한다2.5 언제 고르나
고른다
RAG 파이프라인처럼 부품 조립이 주된 일일 때
여러 모델 공급자를 오갈 계획일 때
표준적인 도구 호출 에이전트 하나면 충분할 때
안 고른다
흐름 제어가 복잡하고 재현성이 중요할 때
의존성을 최소로 유지해야 하는 환경일 때3장. LangGraph
3.1 무엇인가
에이전트를 "상태를 들고 노드 사이를 오가는 그래프" 로 표현하는 저수준 엔진
노드 상태를 받아 상태의 일부를 갱신해 돌려주는 함수
엣지 다음에 어느 노드로 갈지
조건부 엣지 상태를 보고 분기를 결정하는 함수
상태 그래프 전체가 공유하는 자료구조3.2 코드로 보는 형태
from typing import TypedDict, Annotated
from langgraph.graph import StateGraph, START, END
import operator
class State(TypedDict):
messages: Annotated[list, operator.add] # 리스트는 덮어쓰지 않고 이어붙인다
step: int
def plan(state: State) -> dict:
return {"messages": ["계획 수립"], "step": state["step"] + 1}
def act(state: State) -> dict:
return {"messages": ["도구 실행"], "step": state["step"] + 1}
def route(state: State) -> str:
return "act" if state["step"] < 3 else "done"
g = StateGraph(State)
g.add_node("plan", plan)
g.add_node("act", act)
g.add_edge(START, "plan")
g.add_conditional_edges("plan", route, {"act": "act", "done": END})
g.add_edge("act", "plan")
app = g.compile()읽어야 할 지점이 둘입니다.
① Annotated[list, operator.add]
상태 필드마다 "합치는 방법" 을 지정한다
기본은 덮어쓰기, add 를 주면 이어붙이기
여러 노드가 같은 필드를 건드릴 때
충돌 처리를 프레임워크가 아니라 개발자가 정한다
② route 함수
다음 목적지를 코드가 정한다
LLM 이 정하는 게 아니다
흐름이 결정적이라 재현과 테스트가 된다3.3 체크포인터
LangGraph가 다른 프레임워크와 가장 크게 갈리는 부분입니다.
compile(checkpointer=...) 로 저장소를 붙이면
매 노드 실행 후 상태가 저장된다
그래서 가능해지는 것들
중단과 재개 프로세스가 죽어도 이어서
human-in-the-loop 특정 노드 앞에서 멈춰 사람 승인을 받고 재개
타임 트래블 과거 시점 상태로 되돌려 다른 분기 실행
멀티턴 대화 thread 단위로 상태 격리이게 되면 무엇이 달라지나
"몇 시간 걸리는 에이전트" 가 현실적으로 가능해진다
중간에 실패해도 처음부터 다시 안 해도 되기 때문이다3.4 장점
제어가 완전히 명시적이다
흐름이 코드에 그래프로 그려져 있다
"왜 이렇게 동작했지" 를 그래프를 따라가며 답할 수 있다
상태가 1급 시민이다
무엇이 어디서 갱신되는지 타입으로 선언된다
체크포인팅과 재개가 내장이다
직접 만들면 상당한 작업량이다
순환을 정식으로 지원한다
에이전트 루프는 본질이 순환인데
DAG 만 지원하는 도구로는 어색하게 표현된다
스트리밍 입자가 곱다
노드 단위, 토큰 단위 모두 흘릴 수 있다3.5 단점
보일러플레이트가 많다
간단한 도구 호출 에이전트 하나에도 상태 정의와 노드 등록이 필요하다
배워야 할 개념이 있다
상태 리듀서, 조건부 엣지, 서브그래프, 인터럽트
"그냥 에이전트 하나" 를 원하는 사람에게는 과하다
그래프를 잘못 설계하면 그대로 굳는다
초기 상태 스키마 설계가 나중까지 따라온다
멀티에이전트 협업 패턴은 직접 만들어야 한다
CrewAI 처럼 "역할과 태스크" 가 기본 제공되지 않는다3.6 언제 고르나
고른다
실패 시 재개가 필요한 장시간 작업
사람 승인이 중간에 끼어야 하는 워크플로
흐름을 재현 가능하게 못 박아야 하는 프로덕션
분기와 루프가 복잡한 파이프라인
안 고른다
프로토타입을 오늘 안에 보여줘야 할 때
흐름이 단순한 도구 호출 하나로 끝날 때4장. CrewAI
4.1 무엇인가
역할(role), 목표(goal), 배경(backstory)을 가진 에이전트들을 묶어
태스크를 처리하게 하는 오케스트레이터
Python 프레임워크이고 MIT 라이선스다두 개의 실행 모델을 함께 제공한다는 게 핵심입니다.
Crews 자율성과 협업에 최적화
역할 기반 에이전트들이 알아서 나눠 처리한다
Flows 정밀한 제어에 최적화
이벤트 기반으로 단계를 못 박고
필요한 지점에서 Crew 를 호출한다4.2 Crews, 위임 모델
from crewai import Agent, Task, Crew, Process
researcher = Agent(
role="시장 조사원",
goal="주어진 산업의 최신 동향을 수집한다",
backstory="10년차 애널리스트. 1차 자료를 우선한다.",
tools=[search_tool],
)
writer = Agent(
role="보고서 작성자",
goal="수집된 자료를 임원용 요약으로 정리한다",
backstory="복잡한 내용을 한 장으로 압축하는 데 능하다.",
)
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, write_task],
process=Process.sequential,
)
result = crew.kickoff()읽어야 할 지점
role, goal, backstory 는 결국 시스템 프롬프트로 들어간다
"역할 부여" 라는 프롬프트 기법을 API 로 승격시킨 것이다
process 로 실행 방식을 고른다
sequential 태스크를 순서대로
hierarchical 관리자 에이전트가 위임을 결정4.3 Flows, 제어 모델
Crews 만으로는 프로덕션에서 부족하다는 게 드러났다
에이전트가 알아서 정하면 매번 다르게 동작하기 때문이다
Flows 는 그 반대편이다
이벤트 기반으로 단계를 명시하고
상태를 넘기고
필요한 곳에서만 Crew 를 부른다
즉 결정적 골격 안에 자율적 조각을 끼워 넣는 구조다CrewAI를 정확히 이해하려면 이 둘을 같이 봐야 합니다. Crews만 보고 "비결정적이라 프로덕션에 못 쓴다"고 하는 건 절반만 본 것입니다.
4.4 LangChain 의존성을 끊었다
흔한 오해 하나를 여기서 정리합니다.
CrewAI 는 초기에 LangChain 위에 얹혀 있었다
그래서 지금도 "LangChain 래퍼" 라고 소개하는 글이 많다
현행 패키지의 의존성 목록을 직접 확인하면
56 개 중 langchain 계열이 하나도 없다
대신 openai, mcp, chromadb, lancedb, instructor,
opentelemetry 같은 것들을 직접 쓴다그래서 실무적으로 달라지는 것
LangChain 버전 변화에 끌려다니지 않는다
의존성 트리가 독립적이다
반대로 LangChain 의 방대한 통합을 그냥 못 빌려 쓴다4.5 장점
개념이 직관적이다
역할과 태스크는 사람이 일을 나누는 방식 그대로다
비개발자에게 설명하기 쉽다
시작이 빠르다
에이전트 두 개 정의하고 kickoff 하면 돈다
멀티에이전트 협업이 기본 제공이다
위임, 순차, 계층 실행이 옵션 하나로 바뀐다
독립적 의존성 트리
4.4 에서 본 그대로다
MIT 라이선스
상업적 사용에 제약이 없다4.6 단점
Crews 는 비결정적이다
같은 입력에 매번 다른 경로를 탈 수 있다
테스트와 재현이 어렵다
역할 설정이 성능에 크게 영향을 준다
backstory 를 어떻게 쓰느냐로 결과가 흔들린다
조정 근거가 프롬프트 감각에 의존한다
토큰 소모가 크다
에이전트끼리 주고받는 과정이 전부 컨텍스트로 쌓인다
단일 에이전트로 될 일을 3 개로 나누면 비용이 몇 배가 된다
세밀한 제어에는 한계가 있다
Flows 가 그 답이지만
LangGraph 만큼 상태와 재개를 정교하게 다루진 않는다
상업 제품과의 경계
AMP Suite 라는 상용 컨트롤 플레인이 있다
오픈소스 기능과 상용 기능의 경계를 확인해야 한다4.7 언제 고르나
고른다
"여러 전문가가 협업하는" 구조가 문제에 자연스럽게 맞을 때
조사, 분석, 작성처럼 단계가 사람 직무로 나뉘는 일
빠르게 만들어 보여줘야 할 때
안 고른다
같은 입력에 같은 출력이 나와야 할 때
토큰 비용이 빡빡할 때
단일 에이전트로 충분한 일일 때5장. AutoGen과 Microsoft Agent Framework
5.1 AutoGen이 무엇이었나
Microsoft Research 에서 나온 멀티에이전트 프레임워크
핵심 발상은 "에이전트 간 대화" 다
에이전트들이 메시지를 주고받으며 문제를 푼다
AssistantAgent LLM 을 쓰는 에이전트
UserProxyAgent 사람 역할, 코드 실행도 담당
GroupChat 여러 에이전트가 참여하는 대화방차별점이 코드 실행이었다
에이전트가 파이썬 코드를 쓰고
UserProxyAgent 가 실제로 실행하고
에러가 나면 대화로 되돌려 고친다
"대화 = 제어 흐름" 이라는 발상이 당시엔 신선했다5.2 유지보수 모드 전환
지금 AutoGen을 고를지 판단하려면 이 사실부터 알아야 합니다.
공식 저장소 README 상단에 경고가 붙어 있습니다.
"AutoGen is now in maintenance mode. It will not receive new features or enhancements and is community managed going forward."
"New users should start with Microsoft Agent Framework."
패키지 릴리스 기록이 이를 뒷받침한다
autogen-agentchat 0.7.5, 마지막 릴리스 2025-09-30
pyautogen 0.10.0, 마지막 릴리스 2025-07-15
agent-framework 1.0.0 이 2026-04-02
이후 계속 릴리스 중결론이 단순하다
새로 시작한다면 AutoGen 을 고를 이유가 없다
기존 코드가 있다면 공식 마이그레이션 가이드가 제공된다5.3 Microsoft Agent Framework
AutoGen 과 Semantic Kernel 의 후속이자 통합이다
Python 과 C#/.NET 을 동일한 API 로 지원한다
이 조합이 다른 프레임워크에 없는 지점이다공식 문서가 밝히는 성격이 명확합니다.
그래프 기반 워크플로 패턴
sequential, concurrent, handoff, group collaboration
체크포인팅, 스트리밍, human-in-the-loop, 타임 트래블
미들웨어
요청과 응답 처리, 예외 처리, 커스텀 파이프라인
OpenTelemetry 내장
분산 추적이 표준 방식으로 나간다
A2A 와 MCP 를 통한 런타임 상호운용5.4 장점
.NET 을 1급으로 지원한다
기업 백엔드가 C# 인 조직에서 사실상 유일한 선택지다
엔터프라이즈 관심사가 기본 탑재다
내구성, 재시작, 관측, 거버넌스, 사람 개입
Azure 와 Foundry 통합이 깊다
호스팅까지 몇 줄로 이어진다
안정 API 와 장기 지원을 명시한다
AutoGen 시절의 잦은 파괴적 변경에 대한 대응이다5.5 단점
Microsoft 생태계 색이 짙다
Azure 밖에서도 돌지만, 이점의 상당 부분이 그 안에 있다
역사가 짧다
1.0 이 2026-04 다. 커뮤니티 자료가 아직 적다
AutoGen 자산이 그대로 이어지지 않는다
마이그레이션 가이드가 필요할 만큼 API 가 다르다
Python 단독 프로젝트에서의 이점이 상대적으로 작다
.NET 을 안 쓴다면 LangGraph 와 비교 우위가 줄어든다5.6 언제 고르나
고른다
조직이 .NET 을 쓰거나 Python 과 섞여 있을 때
Azure 와 Foundry 위에서 운영할 때
거버넌스와 감사 요구가 강한 환경
안 고른다
Python 만 쓰는 스타트업
클라우드 중립을 유지하고 싶을 때6장. n8n
6.1 무엇인가
노드를 캔버스에 놓고 선으로 이어 워크플로를 만드는 자동화 도구
원래 에이전트 도구가 아니다
Zapier 나 Make 계열의 일반 자동화 플랫폼이고
거기에 AI 노드가 추가된 형태다그래서 강점이 다른 데 있다
Slack, Gmail, Notion, Postgres, HTTP 같은
업무 시스템 커넥터가 수백 개다
LLM 은 그 워크플로 안의 한 노드일 뿐이다6.2 AI Agent 노드
AI Agent 노드 하나에
채팅 모델을 연결하고
도구 노드들을 연결하고
메모리를 연결한다
그러면 그 노드 안에서 도구 호출 루프가 돈다
즉 에이전트가 워크플로 전체가 아니라
워크플로 안의 한 블록이다이 구조가 n8n의 성격을 결정합니다.
에이전트 바깥의 배선은 사람이 그린다
트리거, 전처리, 분기, 후처리, 알림
에이전트 안쪽만 LLM 이 정한다
어느 도구를 몇 번 부를지
자율성의 범위가 명확히 제한된다6.3 라이선스가 특이하다
다섯 후보 중 유일하게 OSI 오픈소스가 아닙니다.
Sustainable Use License (fair-code)
내부 업무용 사용은 자유롭다
소스 열람과 수정도 된다
그러나 "n8n 을 서비스로 되팔기" 같은 사용은 제한된다
추가로
파일명에 .ee 가 들어가거나 디렉터리가 .ee 인 소스는
이 라이선스 대상이 아니다
별도 엔터프라이즈 라이선스가 있어야 한다실무적으로 무엇을 확인해야 하나
사내 자동화로 쓰는 건 대체로 문제없다
고객에게 n8n 기반 기능을 판매하는 형태라면 검토가 필요하다
MIT 인 LangChain, LangGraph, CrewAI 와는 성격이 다르다6.4 장점
비개발자가 만질 수 있다
기획자나 운영자가 직접 흐름을 고칠 수 있다
업무 시스템 통합이 압도적이다
"Gmail 에서 첨부 받아 요약해서 Notion 에 넣기" 같은 게
코드 없이 된다
흐름이 눈에 보인다
캔버스 자체가 문서다
셀프호스팅이 쉽다
Docker 하나로 올라간다. 데이터가 밖으로 안 나간다
실행 이력이 시각적으로 남는다
어느 노드에서 무슨 데이터가 나왔는지 클릭해서 본다6.5 단점
복잡해지면 캔버스가 무너진다
노드 수십 개가 얽히면 코드보다 읽기 어렵다
버전 관리가 코드만 못하다
JSON 으로 내보낼 수 있지만 diff 가 사람이 읽을 만하지 않다
테스트가 어렵다
단위 테스트를 붙일 자리가 마땅치 않다
에이전트 제어의 세밀함이 부족하다
상태 리듀서나 체크포인트 같은 개념이 없다
라이선스 제약이 있다
6.3 참고6.6 언제 고르나
고른다
사내 업무 자동화가 주 목적이고 LLM 은 그중 한 조각일 때
비개발자가 유지보수해야 할 때
기존 SaaS 여러 개를 엮는 일이 대부분일 때
안 고른다
에이전트 로직 자체가 제품의 핵심일 때
CI 와 코드 리뷰 프로세스에 태워야 할 때
외부에 판매하는 제품에 내장할 때7장. 나란히 놓고 비교
7.1 정체성과 제어권
| 정체성 | 흐름을 정하는 주체 | 결정성 | |
|---|---|---|---|
| LangChain | 컴포넌트 라이브러리 | 고수준 API가 정한 표준 루프 | 중간 |
| LangGraph | 저수준 실행 엔진 | 개발자가 그래프로 명시 | 높음 |
| CrewAI Crews | 역할 기반 오케스트레이터 | 에이전트에게 위임 | 낮음 |
| CrewAI Flows | 이벤트 기반 오케스트레이터 | 개발자가 이벤트로 명시 | 높음 |
| MS Agent Framework | 엔터프라이즈 런타임 | 개발자가 워크플로 패턴으로 명시 | 높음 |
| n8n | 워크플로 자동화 도구 | 사람이 캔버스로 그림 (노드 내부만 LLM) | 매우 높음 |
7.2 상태와 지속성
| 상태 모델 | 체크포인트와 재개 | 사람 개입 | |
|---|---|---|---|
| LangChain | 고수준 API에 위임 | LangGraph를 통해 | LangGraph를 통해 |
| LangGraph | 타입 선언 + 리듀서로 명시 | 내장. 타임 트래블까지 | 내장 인터럽트 |
| CrewAI | 태스크 출력이 다음으로 전달 | Flows에서 부분 지원 | 제한적 |
| MS Agent Framework | 워크플로 상태 | 내장. 타임 트래블 언급 | 내장 |
| n8n | 노드 간 데이터 전달 | 실행 단위 재시도 | Wait 노드로 |
7.3 라이선스와 릴리스 상태
실제 패키지 저장소에서 확인한 값입니다.
| 패키지 | 최신 버전 | 최신 릴리스 | 1.0 시점 | 라이선스 |
|---|---|---|---|---|
langchain |
1.3.15 | 2026-08-11 | 2025-10-17 | MIT |
langgraph |
1.2.11 | 2026-08-11 | 2025-10-17 | MIT |
crewai |
1.15.15 | 2026-08-12 | 2025-10-20 | MIT |
agent-framework |
1.13.0 | 2026-07-30 | 2026-04-02 | MIT |
autogen-agentchat |
0.7.5 | 2025-09-30 | 없음 | MIT, 유지보수 모드 |
n8n |
2.34.5 | 2026-08-12 | 해당 없음 | Sustainable Use License |
표에서 읽히는 것
LangChain 과 LangGraph 는 같은 날 1.0 을 냈고 같은 날 갱신된다
한 몸으로 굴러간다는 뜻이다
AutoGen 만 릴리스가 1 년 가까이 멈춰 있다
유지보수 모드 선언과 정확히 맞물린다
n8n 만 라이선스 성격이 다르다7.4 진입장벽과 학습 곡선
낮음 n8n 노드를 끌어다 놓으면 된다
CrewAI 에이전트 둘 정의하고 kickoff
LangChain init_chat_model 한 줄
중간 MS Agent Framework 개념은 명확하나 문서가 아직 얇다
높음 LangGraph 상태, 리듀서, 조건부 엣지, 인터럽트를 알아야 한다주의할 게 있습니다. 진입장벽이 낮은 것과 프로덕션까지 가는 게 쉬운 것은 다릅니다.
CrewAI 는 시작이 쉽고
"재현이 안 된다" 는 문제를 나중에 만난다
LangGraph 는 시작이 어렵고
그 문제를 처음에 미리 치른다7.5 종합
흐름을 못 박아야 한다 ──► LangGraph
.NET 이 섞여 있다 ──► MS Agent Framework
역할 분담이 문제에 자연스럽다 ──► CrewAI
부품 조립과 통합이 주된 일이다 ──► LangChain
LLM 이 업무 자동화의 한 조각이다 ──► n8n8장. LangChain 대 LangGraph
8.1 가장 헷갈리는 쌍
같은 회사의 두 패키지인데 층이 다르다
LangChain
무엇을 쓸지에 관한 라이브러리
모델, 리트리버, 도구, 파서
LangGraph
어떻게 굴릴지에 관한 엔진
상태, 노드, 엣지, 체크포인트1.0 이후 관계가 명확해졌다
LangChain 의 에이전트 생성이 LangGraph 위에서 돈다
즉 LangChain 을 쓰면 이미 LangGraph 를 쓰고 있는 것이다
다만 그래프가 감춰져 있을 뿐이다8.2 어느 쪽으로 갈지
LangChain 만으로 충분한 경우
표준 도구 호출 루프 하나
RAG 파이프라인
모델 교체가 잦은 실험
LangGraph 로 내려가야 하는 경우
노드마다 다른 모델을 써야 한다
중간에 사람 승인이 필요하다
실패 지점부터 재개해야 한다
루프 종료 조건이 복잡하다
서브 에이전트를 병렬로 돌리고 결과를 합쳐야 한다"고수준으로 시작해서 필요할 때 내려간다"가 이 조합의 설계 의도입니다.
9장. 고르는 기준
9.1 결정 흐름
① 코드로 관리해야 하나
아니오 ──► n8n
예 ──► ②
② .NET 이 섞여 있나
예 ──► Microsoft Agent Framework
아니오 ──► ③
③ 흐름이 결정적이어야 하나
예 ──► LangGraph (또는 CrewAI Flows)
아니오 ──► ④
④ 문제가 여러 직무의 협업으로 자연스럽게 나뉘나
예 ──► CrewAI Crews
아니오 ──► ⑤
⑤ 부품 조립과 통합이 주된 일인가
예 ──► LangChain
아니오 ──► 프레임워크 없이 (9.3)9.2 자주 하는 오해
"CrewAI 는 LangChain 래퍼다"
현행 버전은 langchain 계열 직접 의존이 없다 (4.4)
"AutoGen 이 Microsoft 의 주력이다"
유지보수 모드다. 주력은 Agent Framework 다 (5.2)
"n8n 은 오픈소스다"
fair-code 라이선스이고 .ee 코드는 별도 라이선스가 필요하다 (6.3)
"LangChain 과 LangGraph 중 하나를 골라야 한다"
층이 다르다. 함께 쓰는 게 기본 형태다 (8장)
"멀티에이전트가 항상 낫다"
토큰 비용이 몇 배가 되고 실패 지점이 늘어난다
단일 에이전트로 되는 일이면 그게 낫다9.3 프레임워크 없이 가는 선택지
빠뜨리면 안 되는 후보입니다.
모델 공급자의 SDK 만으로도 도구 호출 루프는 짤 수 있다
while True:
응답 = 모델 호출(메시지들, 도구들)
도구 호출이 없으면 break
도구 실행 결과를 메시지에 추가
실제로 이게 전부인 경우가 많다직접 짜는 게 나은 상황
도구가 서너 개뿐이다
흐름이 한 겹 루프로 끝난다
의존성을 최소로 유지하고 싶다
무슨 프롬프트가 나가는지 완전히 통제하고 싶다
프레임워크가 나은 상황
체크포인팅, 재개, 사람 개입이 필요하다
여러 공급자를 오간다
관측과 평가 도구를 붙여야 한다
팀이 같은 구조로 여러 에이전트를 만든다10장. 정리
10.1 한 문단으로
다섯은 경쟁 관계가 아니라 서로 다른 층과 용도다
LangChain 은 부품 카탈로그
LangGraph 는 그 아래의 실행 엔진
CrewAI 는 역할 분담 오케스트레이터
MS Agent Framework 는 .NET 을 포함한 엔터프라이즈 런타임
n8n 은 LLM 을 한 노드로 품는 업무 자동화 도구10.2 지금 시점의 판단
새로 시작한다면
Python 이고 제어가 중요하면 LangGraph
Python 이고 빨리 보여줘야 하면 CrewAI 또는 LangChain
.NET 이 섞여 있으면 Microsoft Agent Framework
비개발자가 유지보수해야 하면 n8n
AutoGen 은 신규 채택 대상에서 뺀다
유지보수 모드이고 후속이 명확하다10.3 프레임워크를 고르기 전에 정해야 할 것
흐름을 누가 정할 것인가
이 하나가 나머지를 거의 다 결정한다
개발자가 정한다 ──► 재현되고 테스트된다. 대신 유연성이 준다
LLM 이 정한다 ──► 유연하다. 대신 재현과 디버깅이 어렵다
사람이 그린다 ──► 명확하다. 대신 규모가 커지면 무너진다프레임워크 선택은 이 질문에 대한 답을 코드로 옮기는 일입니다. 순서를 거꾸로 하면, 도구가 정해준 답을 나중에 되돌리느라 고생합니다.
용어 정리
| 용어 | 한 줄 뜻 |
|---|---|
| LangChain | 모델, 도구, 리트리버를 표준 인터페이스로 감싼 LLM 컴포넌트 라이브러리 |
| LangGraph | 상태를 들고 노드 사이를 오가는 그래프로 에이전트를 표현하는 저수준 실행 엔진 |
| 상태 리듀서 (reducer) | 여러 노드가 같은 상태 필드를 갱신할 때 합치는 방법. 기본은 덮어쓰기 |
| 조건부 엣지 | 상태를 보고 다음 노드를 고르는 함수. 흐름 분기를 코드로 표현 |
| 체크포인터 | 노드 실행마다 상태를 저장해 중단, 재개, 타임 트래블을 가능하게 하는 장치 |
| 타임 트래블 | 저장된 과거 상태로 되돌려 다른 분기를 실행해 보는 기능 |
| human-in-the-loop | 실행 중간에 멈춰 사람의 승인이나 입력을 받고 이어가는 패턴 |
| CrewAI | 역할, 목표, 배경을 가진 에이전트들을 묶어 태스크를 처리하는 Python 오케스트레이터 |
| Crews | CrewAI의 자율 협업 실행 모델. 에이전트에게 흐름을 위임 |
| Flows | CrewAI의 이벤트 기반 실행 모델. 단계를 명시하고 필요한 곳에서 Crew 호출 |
Process.hierarchical |
관리자 에이전트가 위임을 결정하는 CrewAI 실행 방식 |
| AutoGen | Microsoft Research의 대화 기반 멀티에이전트 프레임워크. 현재 유지보수 모드 |
| Microsoft Agent Framework (MAF) | AutoGen과 Semantic Kernel의 후속. Python과 .NET을 함께 지원하는 엔터프라이즈 런타임 |
| A2A | 에이전트 간 상호운용 프로토콜. MAF가 지원을 명시 |
| n8n | 노드를 캔버스에 연결해 워크플로를 만드는 자동화 도구. AI Agent 노드를 제공 |
| Sustainable Use License | n8n의 fair-code 라이선스. 내부 사용은 자유롭지만 재판매를 제한 |
| fair-code | 소스 공개와 사용 자유를 주되 상업적 재판매를 제한하는 라이선스 계열. OSI 오픈소스는 아님 |
.ee 파일 |
n8n에서 별도 엔터프라이즈 라이선스가 필요한 소스 파일 표시 |
| 결정성 (determinism) | 같은 입력에 같은 실행 경로와 출력이 나오는 성질. 테스트와 재현의 전제 |
참고자료
- LangChain 공식 저장소 (v1 이후의 역할 정의와 LangGraph와의 관계)
- LangGraph 공식 저장소 (상태 그래프, 체크포인터, 인터럽트)
- LangChain 공식 문서 (컴포넌트와 에이전트 API)
- CrewAI 공식 저장소 (Crews와 Flows의 정의, MIT 라이선스)
- CrewAI 공식 문서
- microsoft/autogen (유지보수 모드 공지와 마이그레이션 안내)
- microsoft/agent-framework (Python과 .NET, 워크플로 패턴, 체크포인팅, OpenTelemetry)
- AutoGen에서 Microsoft Agent Framework로 마이그레이션 가이드
- n8n 공식 저장소
- n8n LICENSE.md (Sustainable Use License 원문과
.ee예외) - n8n AI Agent 노드 문서
댓글