2. LangGraph 기본기
외부 자료로 답하기, 그리고 설계 패턴 일곱
이 차시를 마치면
외부 자료를 근거로 답하는 두 방식을 비교하고 설계 패턴 일곱 가지를 고릅니다.
모델은 학습한 것만 압니다. 우리 회사 문서는 모릅니다. 그 간극을 메우는 구조가 RAG 이고, 여기에 지금까지 배운 조각을 얹으면 설계 패턴이 됩니다.
RAG 란 무엇인가
RAG 는 외부 지식원에서 관련 정보를 retrieve 한 후, 그 context 를 바탕으로 답하는 구조입니다.
| 구분 | deterministic RAG | agentic RAG |
|---|---|---|
| 경로 | 질문 → 검색 → 문서 → 답변 (고정) | Agent 가 검색 여부, 횟수, 도구를 판단 |
| 장점 | 예측 가능 · 평가 쉬움 · 비용과 지연 통제 쉬움 | 복잡한 탐색 · 여러 데이터소스 · 반복 검색과 검증 |
| 단점 | — | 비용 증가 · 실행 경로 변동 · 평가 복잡 |
raw/03_IMAGES/README_이미지출처.md)무엇부터 만들 것인가
단일 지식베이스에서 근거 있는 답변이 목적이면 deterministic RAG 부터 시작합니다. 검색 전략 자체가 과업의 일부일 때 agentic RAG 를 고려합니다.
비유
도서관에서 책을 찾는 일에 비유하면, deterministic RAG 는 정해진 서가로 곧장 가는 것이고 agentic RAG 는 사서에게 물어 가며 여러 서가를 도는 것입니다. 찾는 책이 어디 있는지 아는 상황에서 사서를 부르면 시간과 비용만 늘어납니다.
LangGraph 는 retrieve → relevance judge → rewrite query → retrieve 반복 → answer 같은 조건부 반복 구조를 명시적으로 만들기에 좋습니다.
설계 패턴 일곱 가지
| # | 패턴 | 언제 쓰는가 |
|---|---|---|
| 1 | Simple Tool Agent | 가장 먼저 시도합니다. LangChain create_agent |
| 2 | Deterministic workflow + 일부 LLM | 업무 규칙이 고정되어 있으면 StateGraph 에서 LLM Node 를 필요한 곳에만 둡니다 |
| 3 | Router | 분류 결과에 따라 서로 다른 Node, Agent, RAG source 로 보냅니다 |
| 4 | Human approval | 위험한 action 전에 interrupt |
| 5 | Reflection / retry | 결과를 판정하고 기준에 못 미치면 다시 씁니다. 최대 반복 횟수를 State 로 관리합니다 |
| 6 | Multi-agent | 전문 Agent 를 분리합니다. "Agent 수가 많을수록 좋다"는 가정은 피합니다. 분리 근거가 역할, 도구, context, 권한 차이로 명확해야 합니다 |
| 7 | Map-reduce / parallel | 독립 문서나 하위 과업을 병렬 처리한 뒤 모읍니다 |
7번 병렬 처리를 쓸 때는 앞 차시의 Reducer 가 필요합니다. 여러 갈래가 같은 키를 갱신하기 때문입니다.
모든 것을 Agent 로 만들 필요는 없습니다
학습팩의 FAQ 는 이렇게 답합니다. deterministic 작업 흐름이 더 단순하고 검증 가능하면 Agent 를 쓰지 않는 편이 낫습니다.
보안 관점에서도 같은 결론이 나옵니다. 실행 경로가 고정되어 있으면 무엇이 일어날 수 있는지 미리 셀 수 있습니다. Agent 가 판단하는 부분이 늘어날수록 경우의 수가 늘고 검증이 어려워집니다. 분석
무엇을 어디에 쓰는가
| 목적 | 도구 |
|---|---|
| 빠른 일반 Agent | LangChain |
| 정확한 workflow 제어 | LangGraph |
| 성능 검증과 trace | LangSmith |
둘 이상을 함께 쓰는 것이 일반적입니다.
여기까지 오면
입문 과정이 끝났습니다. 이제 3번 트랙에서 이 개념들을 어떤 파일에 어떻게 나눠 담을지, 그리고 무엇을 바꿔도 되고 무엇을 바꾸면 안 되는지를 다룹니다.