AI Agent를 공부하다 보면 LangChain, LangGraph라는 이름을 자주 접하게 된다.
처음에는 둘이 비슷해 보이지만 역할에는 차이가 있다.
간단하게 정리하면 다음과 같다.
LangChain은 LLM에게 Prompt와 Tool을 붙여 Agent를 만드는 프레임워크이고,
LangGraph는 그 Agent와 작업들이 어떤 순서로 실행될지 관리하는 오케스트레이션 프레임워크다.
LangChain 공식 문서에서는 Agent를 Model + Harness로 설명한다. 여기서 Harness는 모델 주변의 Prompt, Tool, Middleware 등을 의미한다.

LLM만 사용하면 구조는 단순하다.
사용자
↓
LLM
↓
답변
하지만 실제 서비스를 만든다면 LLM 혼자서 할 수 없는 일이 많다.
예를 들어 서버 장애를 분석하는 AI라면 다음과 같은 작업이 필요할 수 있다.
사용자
"server-01 장애 원인을 찾아줘"
↓
LLM
│
┌──────┼──────┐
↓ ↓ ↓
DB 로그 Metric
조회 조회 조회
이때 DB 조회, API 호출, 검색 같은 기능을 Tool로 만들어 LLM에게 제공할 수 있다.
LangChain은 이런 식으로
LLM
+
Prompt
+
Tools
+
Agent
를 쉽게 구성할 수 있도록 도와준다.
즉 AI에게 어떤 능력을 줄 것인가에 가까운 프레임워크라고 이해하면 쉽다.

간단한 Agent라면 LangChain만으로도 충분하다.
하지만 시스템이 복잡해지면 실행 순서를 제어해야 한다.
예를 들어 장애 분석 시스템이 있다고 해보자.
사용자 요청
↓
로그 조회
↓
Metric 조회
↓
AI 분석
↓
장애인가?
┌────┴────┐
Yes No
↓ ↓
조치 검토 종료
↓
관리자 승인
↓
조치 실행
여기에는 단순한 LLM 호출뿐만 아니라
등이 필요하다.
이런 실행 흐름을 관리하기 위한 것이 LangGraph다.
LangGraph 공식 문서에서는 이를 장시간 실행되고 상태를 가지는 Agent를 위한 low-level orchestration framework/runtime으로 설명한다.
또한 일반 코드처럼 동작하는 deterministic step과 LLM이 판단하는 agentic step을 하나의 Graph 안에서 함께 사용할 수 있다.
LangGraph를 처음 공부한다면 세 가지만 먼저 이해하면 된다.
Node는 하나의 작업이다.
[로그 조회]
[DB 조회]
[AI 분석]
각각 하나의 Node가 된다.
Edge는 Node 사이의 이동 경로다.
로그 조회 → DB 조회 → AI 분석
여기에서 →가 Edge다.
조건에 따라서 다음 Node를 바꾸는 것도 가능하다.
AI 분석
↓
문제 있음?
┌───┴───┐
Yes No
↓ ↓
재분석 종료
State는 여러 Node가 공유하는 현재 작업 데이터다.
처음에는
serverId
만 있었다가 로그를 조회하면
serverId
logs
Metric을 조회하면
serverId
logs
metrics
분석까지 끝나면
serverId
logs
metrics
analysis
처럼 데이터가 계속 추가될 수 있다.
즉 LangGraph는 아주 단순하게 표현하면
State를 가지고
Node를 실행하면서
Edge를 따라 이동하는 구조
라고 볼 수 있다.

LangGraph 공식 문서에서 가장 중요하게 구분하는 개념이다.
실행 경로가 미리 정해져 있다.
로그 조회
↓
Metric 조회
↓
분석
↓
보고서 생성
개발자가 실행 순서를 결정한다.
LLM이 다음 행동을 결정한다.
사용자
↓
LLM
↓
어떤 Tool이 필요하지?
↓
Tool 실행
↓
결과 확인
↓
추가 Tool이 필요한가?
↓
...
공식 문서에서는 Workflow를 predetermined code paths, Agent를 자신의 실행 과정과 Tool 사용을 동적으로 결정하는 구조로 구분한다.
즉,
Workflow = 개발자가 흐름을 결정
Agent = AI가 흐름을 결정
이라고 생각하면 된다.

공식 문서에서는 여러 가지 대표 패턴을 소개한다.
앞 LLM의 결과를 다음 LLM이 사용한다.
요구사항 분석
↓
코드 생성
↓
코드 리뷰
큰 작업을 작고 검증 가능한 단계로 나누고 싶을 때 적합하다.
서로 독립적인 작업을 동시에 실행한다.
┌→ 로그 분석 ─────┐
사용자 요청 ─┼→ DB 분석 ──────┼→ 결과 통합
└→ Metric 분석 ──┘
순서대로 실행할 필요가 없다면 처리 시간을 줄일 수 있다.
같은 문제를 여러 방식으로 분석한 뒤 결과를 비교하는 방식으로도 활용할 수 있다.
사용자의 요청을 먼저 분류하고 적절한 흐름으로 전달한다.
사용자 요청
↓
Router
↓
┌───┼────┐
↓ ↓ ↓
VM 장애 계정
↓ ↓ ↓
A B C
예를 들어
"VM 생성해줘"
→ VM Workflow
"CPU가 왜 높아?"
→ Monitoring Workflow
처럼 처리할 수 있다.
복잡한 AI 시스템을 여러 전문 영역으로 나눌 때 유용하다.

하나의 Orchestrator가 큰 작업을 여러 개의 작은 작업으로 나눈다.
Orchestrator
↓
┌──────────┼──────────┐
↓ ↓ ↓
Worker A Worker B Worker C
↓ ↓ ↓
└──────────┼──────────┘
↓
결과 통합
특히 코드 수정이나 여러 문서를 분석하는 것처럼 작업 개수를 미리 알기 어려운 경우 유용하다.
LangGraph의 Send API를 사용하면 필요한 Worker를 동적으로 생성해 병렬로 작업하게 만들 수 있다.
결과를 생성한 뒤 다른 단계에서 평가하고 부족하면 다시 수정한다.
Generator
↓
Evaluator
↓
통과?
┌──┴──┐
Yes No
↓ ↓
END Feedback
↓
Generator
예를 들어
코드 생성
↓
코드 리뷰
↓
문제 발견
↓
피드백 반영
↓
다시 코드 생성
과 같은 구조다.
한 번의 LLM 호출만으로 원하는 품질을 얻기 어려운 작업에서 유용하다.

정리하면 다음과 같다.
| 구분 | 역할 |
|---|---|
| LLM | 생각하고 결과 생성 |
| LangChain | Model, Prompt, Tool, Agent 구성 |
| LangGraph | 상태, 순서, 분기, 반복, 병렬 실행 관리 |
| LangSmith | 실행 추적, 디버깅, 평가 |
LangGraph는 LangChain 없이도 사용할 수 있지만, 실제 Agent를 구성할 때는 LangChain의 Model이나 Tool과 함께 사용하는 경우가 많다.
구조로 보면 다음처럼 이해하면 쉽다.
LangGraph
"어떻게 일할까?"
│
┌───────┼───────┐
↓ ↓ ↓
Router Agent Validator
│
↓
LangChain
"무엇을 사용할까?"
│
┌─────┼─────┐
↓ ↓ ↓
LLM Prompt Tool
│
DB / API / MCP

처음 LangGraph를 보면 새로운 AI 기술처럼 느껴지지만, 개발자 입장에서 생각하면 그렇게 어려운 개념은 아니다.
기존 코드에서 사용하던
함수 호출
if / else
반복
병렬 처리
상태 관리
를 AI Agent에 맞게 Graph 형태로 명확하게 관리한다고 생각하면 이해하기 쉽다.
가장 중요한 차이만 기억하면 된다.
LangChain은 AI에게 능력을 붙여주는 프레임워크이고,
LangGraph는 AI가 어떤 순서와 조건으로 일할지 관리하는 프레임워크다.
LangGraph를 공부할 때는 다음 순서로 접근하면 이해하기 편하다.
State / Node / Edge
↓
Prompt Chaining
↓
Parallelization
↓
Routing
↓
Evaluator-Optimizer
↓
Orchestrator-Worker
↓
Agent
특히 복잡한 AI Agent 시스템에서는 모든 판단을 하나의 Agent에게 맡기기보다 정해진 Workflow와 Agent의 자율적인 판단을 적절히 섞는 구조가 중요하다.
이 점이 단순한 Agent Loop와 LangGraph 기반 Agent 시스템의 가장 큰 차이라고 볼 수 있다.
