LLM 호출, 메모리, 도구 연동, 에이전트 실행을 표준 부품으로 묶은 오픈소스 프레임워크로, 모델·도구·데이터베이스를 부품처럼 끼웠다 뺐다 하며 문서 기반 챗봇(RAG)이나 도구를 쓰는 AI 에이전트를 Python으로 빠르게 만들 때 쓴다. 대화 기억, 재시도, 모델 교체처럼 매번 반복되는 일을 다시 짤 필요가 없어 앱의 핵심 로직에만 집중할 수 있다.
| 도구 | 역할 | 이럴 때 쓴다 |
|---|---|---|
| LangChain | 기본 부품과 에이전트 | RAG 챗봇, 도구를 쓰는 에이전트 |
| LangGraph | 복잡한 흐름 설계 | 갈라지는 흐름, 오래 걸리는 작업 |
| LangSmith | 실행 과정 확인 | 디버깅, 원인 추적 |
가장 많이 쓰는 곳은 문서를 읽고 답하는 RAG다. 문서를 잘게 쪼개 벡터 저장소에 넣고, 질문이 오면 관련 조각을 찾아 모델에 함께 건네는 과정을 부품을 파이프로 잇듯 연결하면 된다. 사내 문서에 답하는 챗봇을 짧은 코드로 만들 수 있다.
2025년 말 나온 1.0 버전에서는 create_agent 함수 하나로 에이전트를 만든다. 모델이 스스로 도구를 골라 쓰고, 결과를 보고 다음 행동을 정하는 흐름이 이 함수에 들어 있다.
여기에 미들웨어를 끼워 에이전트가 도는 중간에 처리를 더할 수 있다.
| 하고 싶은 일 | 미들웨어로 할 수 있는 것 |
|---|---|
| 기록 남기기 | 단계마다 로그 저장 |
| 개인정보 보호 | 민감한 내용 걸러내기 |
| 비용·부하 관리 | 요청 횟수 제한 |
| 답변 다듬기 | 프롬프트 수정 |
조건에 따라 갈라지거나 여러 갈래가 동시에 도는 흐름이 필요하면 LangGraph를 쓴다. 작업을 노드와 연결선으로 그리듯 설계하며, create_agent도 내부적으로는 LangGraph 위에서 돈다. 상태를 자동으로 저장해서, 서버가 죽거나 사람의 승인을 기다리며 멈춰도 그 지점부터 다시 이어갈 수 있다. 오래 걸리는 작업이나 중간에 사람이 검토해야 하는 업무에 잘 맞는다.
쉽게 시작할 수 있는 대신 내부 동작을 감추는 층이 두꺼워서, 문제가 생기면 원인을 찾기 어렵다는 지적이 오래전부터 있었다. 그래서 실행 과정을 단계별로 들여다볼 수 있는 LangSmith를 함께 쓰는 경우가 많다.
가장 흔한 건 사내 문서에 답하는 챗봇의 뼈대로 쓰는 방식이다. 부품이 표준화되어 있어 모델이나 벡터 저장소를 바꿔 가며 시험하기 쉽고, 흐름이 복잡해지면 LangGraph로 옮겨 간다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 사내 문서 검색 | 문서를 쪼개 벡터 저장소에 넣고, 질문과 관련된 조각을 찾아 모델에 함께 건넨다 |
| 도구를 쓰는 에이전트 | create_agent에 검색·계산·API 호출 도구를 붙이고, 미들웨어로 로그와 요청 횟수를 관리한다 |
| 사람 승인이 필요한 업무 | LangGraph로 흐름을 짜서 승인 단계에서 멈췄다가 검토 뒤 이어간다 |
| 프로토타입 비교 | 같은 코드에서 모델만 바꿔 끼우며 어떤 모델이 작업에 맞는지 비교한다 |