[LangChain(LangGraph), Spring AI] 라는 대목으로 여러 포스팅을 작성할 예정이지만,
이번 포스팅에서는 주로 LangChain과 LangGraph에 관해 설명하려고 한다.
내 블로그를 자주 확인하시는 분이 있을 지는 모르겠지만,
지금껏 SpringBoot, Infra, DB 등의 내용이 주를 이뤘던 내 블로그에서 왜 갑자기 "LangChain과 LangGraph?" 라고 하실 수 있는 분이 계실 수도 있기에 간략하게 이유(?)에 대해 얘기하고 시작하려고 한다.
아래 내용이 이 포스팅의 주 내용은 아니기에 LangChain과 LangGraph에 관해서만 궁금하신 분들은 스킵하셔도 됩니다.
갑자기 LangChain, LangGraph?
현재 재직 중인 회사에서 챗봇을 개발하게 되었다. 챗봇의 요구사항은 정확한 데이터 기반의 근거있는 답변을 내놓는 리테일 챗봇이었다.
해당 요구사항에 마주하고 `SpringBoot + Java` 기술스택을 주로 활용해 주로 개발해왔던 나는 자연스럽게 Spring AI를 접하게 되었다.
당시, Spring AI와 관련된 학습 자료를 찾던 중 유튜브 개발자 유미님의 Spring AI 강의를 보게 되어 동영상을 통해 학습했고,
간단하게 여러 벤더 활용을 체험하는 간단 채팅 서비스를 제작했다.
하지만, 이때 뭔가가 부족한 느낌이 들었다.(후술)
사실 지금와서 보면 Spring AI로도 관련 서비스를 제작할 수 있지 않았을까? 라는 생각이든다.
하지만 그 당시에는 많은 자료 조사를 하며, 아래의 이유로 LangChain, LangGraph를 선택했다.
- `Python` 진영의 프레임워크인 `LangChain`, `LangGraph`가 러닝 커브를 감당할만큼 너무 강력하다.
- `langchain4j`, `langgraph4j`와 같은 Java 기반 구현체들은 LangChain 본가의 공식 지원 프로젝트가 아닌 커뮤니티 주도 오픈소스라는 점도 고려 대상이었다.
- 더불어 Spring AI 역시 초기에는 실험적 성격이 강했으며, LangChain 계열처럼 빠른 실험과 복잡한 에이전트 구성을 중심으로 한 프레임워크라기보다는, 엔터프라이즈 환경에서 LLM을 안정적으로 통합하기 위한 추상화 계층에 가까웠다는 점도 선택에 영향을 주었다.
이런 이유로 나는 재직 중인 회사에서 기존 기술스택과 다른 LangChain, LangGraph를 선택하게 되었다.
서론이 길었다. 바로 본 내용인 LangChain과 LangGraph에 관한 설명으로 넘어가자.
LangChain이 등장한 배경
LLM(OpenAi, Claude, Gemini 등)을 실제 서비스에 적용해보면 단순히 프롬프트 -> 응답으로 끝나지 않는다.
현실의 문제는 다음과 같다.
- 여러 프롬프트를 순차적으로 실행해야 한다.
- 이전 응답을 맥락(Context)으로 유지해야 한다.
- 외부 데이터(DB, API, 파일, 벡터스토어)를 조합해야 한다.
- LLM에게 도구(Tool)를 사용하게 만들어야 한다.
- 실패 시 재시도 / 분기 / fallback 이 필요하다.
즉, LLM 호출은 비즈니스 로직의 일부가 되었고 LLM 오케스트레이션(Orchestration)이 필요해졌다.
이 문제를 해결하기 위해 등장한 대표적인 프레임워크가 LangChain 이다.
LangChain의 핵심 컨셉
LangChain을 간단하게 요약하자면 "LLM 기반의 애플리케이션을 만들기 위한 프레임워크" 라고 할 수 있다.
LangChain은 LLM 애플리케이션을 여러 추상 레이어로 나누어 설계한다.
LangChain의 전체 구조
LangChain의 핵심 구성 요소는 다음과 같다.
Prompt → LLM → Output Parser
↓ Memory
↓ Tools
↓ Chains / Agents
↓ (RAG Pipeline)LangChain은 단순히 LLM 호출만 감싸는 라이브러리가 아니라,
LLM + 데이터 + 실행 흐름 + 상태 관리를 포괄한다.
LLM 추상화
LangChain은 특정 LLM 벤더에 종속되지 않는다.
- OpenAI
- Anthropic
- Azure OpenAI
- Local LLM (LLaMA 등)
을 동일한 인터페이스로 추상화한다.
특징
- 모델 교체 용이
- 벤더 락인 최소화
Prompt Template (프롬프트 관리)
LangChain에서 프롬프트는 단순한 문자열이 아니다.
PromptTemplate 개념
- 변수 바인딩 지원
- 재사용 가능
- 역할(Role) 분리 가능
PromptTemplate( input_variables=["question"], template="질문: {question}" )
SystemMessagePromptTemplate.from_template(prompt_data["inner_call"])
의미
- 프롬프트를 코드 자산으로 관리
- 비즈니스 로직과 분리
- 테스트 및 버전 관리 가능
Output Parser (응답 구조화)
LLM의 응답은 기본적으로 비정형 텍스트다.
`LangChain`은 이를 구조화하기 위해 `Output Parser`를 제공한다.
- JSON Parser
- Pydantic 기반 Schema Parser
- Custom Parser
목적
- LLM 응답을 객체로 변환
- 후속 로직에서 안정적으로 사용
LLM을 “자유로운 텍스트 생성기”가 아닌 구조화된 추론 엔진처럼 사용하게 해준다.
Memory (상태 및 대화 관리)
LangChain에서 Memory는 LLM 애플리케이션의 상태 저장소다.
주요 Memory 유형
- ConversationBufferMemory
- ConversationSummaryMemory
- VectorStore 기반 Memory
특징
- 이전 대화를 자동으로 프롬프트에 포함
- 토큰 제한을 고려한 요약 전략
Tools (외부 기능 연계)
Tool은 LLM이 호출할 수 있는 외부 기능이다.
- DB 조회
- 외부 API 호출
- 파일 읽기
- 계산 로직
- Python 코드 실행기
LLM은 “어떤 도구를 사용할지”를 추론을 통해 결정한다.(이 개념이 Agent로 확장된다.)
Chains (체인)
Chain은 LangChain의 기본 실행 단위다. 즉, 여러 컴포넌트를 순차적으로 연결한 파이프라인
특징
- 선형 흐름에 적합
- 단순한 Use Case에 강점
- 복잡한 분기에는 한계 존재
LangChain이 RAG 프레임워크로 쓰이는 이유
LangChain의 실제 강점은 Agent보다 RAG에 있다. LangChain은 RAG의 전 과정을 End-to-End로 지원한다.
LangChain은 아래와 같은 아주 강력한 기능을 제공한다.
1. Document 추상화
모든 데이터는 Document 객체로 통합된다.
장점
- 데이터 소스 독립적
- 메타데이터 기반 필터링
- 출처 추적 가능
2. Document Loader (데이터 수집)
LangChain은 다양한 Loader를 제공한다.
- PDF, TXT, HTML, Markdown
- 웹 크롤링
- DB
- S3, GCS
- API 기반 Loader
3. Text Splitter (문서 분할)
LLM의 컨텍스트 제한을 해결하기 위한 핵심 단계다.
제공 전략
- Character Split
- Recursive Split
- Token 기반 Split
- Code / Markdown 특화 Split
중요 포인트
- Chunk Size
- Overlap 설정
- 문맥 단절 최소화
RAG 품질의 절반은 Split 전략에서 결정된다고 한다.
4. Embedding 계층
LangChain은 임베딩 모델을 인터페이스로 추상화한다.
- OpenAI
- HuggingFace
- Local Embedding Model
특징
- 모델 교체 용이
- 실험 친화적
- 벤더 종속성 최소화
5. Vector Store (벡터 저장소)
LangChain은 주요 벡터 DB를 대부분 지원한다.
- FAISS
- Chroma
- Pinecone
- Milvus
- Redis
- PostgreSQL (pgvector - 필자 사용)
6. Retriever (검색 전략)
Retriever는 “무엇을, 어떻게 가져올지”를 결정한다.
전략
- Similarity Search
- MMR
- Hybrid Search(필자가 주로 사용)
- Multi-Query Retriever
- Parent-Child Retriever
7. RAG Chain
`LangChain`에서는 `RAG`도 하나의 `Chain`으로 표현된다.
여기까지가 LangChain의 기초 개념과 특징들이라고 할 수 있다.
하지만, 아쉽게도 LangChain에는 살짝 아쉬운 부분이 있다.
그건 바로 `직선적인 흐름`의 성격을 갖는다는 것이다. 그렇기에 나온 것이 `LangGraph`이며 바로 설명하려고 한다.
LangGraph의 등장 배경
LangChain은 강력하지만 다음과 같은 한계가 있다.
- 실행 흐름이 암묵적
- 상태 추적 어려움
- 분기/재시도 제어 부족
- 프로덕션 안정성 부족
실제로 업무는 직선적이지 않다.
- 질문했더니 자료가 부족해서 다시 검색 지시
- A 방법이 안 되면 B 방법 시도
- 결과가 이상해서 다시 한번 검토
- 질문 수정
위와 같은 반복과 조건부 판단이 필요하다.
이를 해결하기 위해 등장한 것이 LangGraph다.
LangGraph의 핵심 개념
LangGraph는 LLM 워크플로우를 그래프로 표현한다.
- Node: 작업 단위
- 업무의 각 단계를 의미. (예: '데이터 검색', 'LLM 분석', '결과 검토', '계산 도구 사용')
- Edge: 실행 흐름
- 노드 간의 흐름(Flow)을 의미.
- 단순히 다음 단계로 넘어갈 수도 있고, 조건에 따라 흐름이 바뀔 수도 있습니다.
- 노드 간의 흐름(Flow)을 의미.
- State: 공유 상태
- 전체 업무를 수행하는 동안 공유되는 기억 공간.
- 각 노드가 처리한 정보를 이 상태에 기록하고 업데이트
- (예: 사용자의 원래 질문, 검색된 문서 목록, Agent들의 생각과정, 현재까지의 대화 기록 등)
- 각 노드가 처리한 정보를 이 상태에 기록하고 업데이트
- 전체 업무를 수행하는 동안 공유되는 기억 공간.
LangGraph + RAG
LangGraph를 사용하면 RAG를 워크플로우로 설계할 수 있다.
LangGraph With Multi Agents
LangGraph의 Graph를 여러 개 정의하여 각각을 Agent로 정의한 뒤 `Multi Agents` 시스템을 구축할 수 있다.
각 Agent는 내부적으로 여러 개의 `Node`를 갖고 동적으로 작업을 수행하고, 수행되지 않기도 한다.
필자의 경우
- Orchestartor Agent
- Multi Agents 아키텍처 환경 전체를 지휘
- SQLAgent
- SQL의 생성/수리/실행을 담당
- AnalysisAgent(Outer/Inner)
- 사용자 질문을 분석 및 담당 Agent 선별
- ...
등과 같은 Multi Agents를 구성하기도 했다.
지금까지가 LangChain과 LangGraph에 관한 설명이다.
- 솔직히 내용이 워낙 많고 필자도 완벽하게 알고있지는 않기에 틀린 부분이 있을 수 있다.
하지만, Agentic이 대세인 요즘 시대에서 LangChain과 LangGraph는 정말 필수로 알아야 하는 프레임워크라고 할 수 있다.
회사에서 직접 구현한 내용을 담기는 어렵지만, LangChain과 LangGraph를 알아가며 원하던 요구사항의 챗봇을 제작할 수 있었다.
다음 포스팅은 LangChain, LangGraph를 통한 챗봇(Multi Agents)시스템을 구축할 때는 잘 알지 못했던 Spring AI에 관해 다뤄볼 생각이다.
학습 참고
출처
LangGraph 이 무엇인지 알아보자
이전 설명에서 LangChain이 여러 AI 구성 요소(데이터, 모델, 도구)를 순서대로 연결(Chain)하여 복잡한 작업을 처리한다고 배웠습니다. 하지만 이 'Chain'은 보통 직선적인 흐름(Linear flow)입니다.예: 질
velog.io
Home - Docs by LangChain
Agent Builder Create helpful AI agents without code. Start from a template, connect your accounts, and let the agent handle routine work while you stay in control.
docs.langchain.com
'Spring' 카테고리의 다른 글
| Spring Security 7 MFA 토이 프로젝트 (2) | 2026.02.24 |
|---|