ChatGPT한테 회사 내부 자료 기반으로 답변해달라고 했다가 엉뚱한 말을 들어본 적 있으세요?
LLM은 기본적으로 학습이 끝난 순간부터 '지식이 멈춥니다'. 이후에 생긴 일은 모르고, 기업 내부 데이터는 애초에 학습에 없으니까요. 거기다 모른다고 솔직하게 말하는 대신, 그럴듯하게 지어내는 '할루시네이션' 문제까지 있어요.
랭체인(LangChain)과 RAG는 바로 이 지점을 파고든 기술이에요.
LLM을 더 똑똑하게 쓰는 게 아니라, LLM의 구조적 한계를 우회하는 방법을 설계한 거거든요. 이 글에서는 LangChain이 뭔지, RAG가 어떤 흐름으로 동작하는지, 그리고 AI 에이전트가 이 둘과 어떻게 연결되는지를 실제 구조 기준으로 정리해볼게요.
LangChain이 하는 일, 한 줄로 정리하면
랭체인을 처음 들으면 '새로운 AI 모델인가?' 싶은데, 그게 아니에요.
LangChain은 LLM을 이용한 앱을 만드는 오케스트레이션 프레임워크입니다. 쉽게 말하면, GPT나 Claude 같은 AI 모델을 외부 데이터·API·검색 엔진과 연결해서 쓸 수 있게 해주는 연결 도구예요.
2022년 오픈소스로 공개됐고, 2025년 말 버전 1.0이 정식 출시됐어요. 핵심 구성 요소는 다섯 가지예요.
- 체인(Chain): 여러 작업을 파이프라인처럼 연결. "질문 → 문서 검색 → 요약 → 답변"을 하나로 묶는 구조
- 프롬프트(Prompt): 모델에 넣을 텍스트를 템플릿으로 관리. 변수 삽입이나 시스템 메시지 분리 처리
- 모델(Model): OpenAI, Anthropic, Google 등 다양한 LLM을 같은 코드 구조로 연결
- 메모리(Memory): 이전 대화를 기억해서 연속된 맥락으로 응답하게 함
- 도구(Tool): 검색 API, 계산기, DB, 파일 읽기 등을 에이전트가 호출할 수 있도록 등록
LangChain 커뮤니티 관련 포럼들을 보면, 초반에는 코드가 좀 복잡하다는 반응이 많았는데, 1.0 이후부터 LCEL(파이프 연산자 | 방식)로 훨씬 직관적으로 바뀌었다는 얘기가 많더라고요.
RAG가 LLM의 한계를 어떻게 우회하는가
LLM의 문제는 세 가지로 압축됩니다.
첫째, 지식 컷오프. 모델 학습이 끝난 시점 이후 발생한 정보를 모른다.
둘째, 할루시네이션. 모르는 걸 모른다고 하지 않고 그럴듯하게 만들어낸다.
셋째, 내부 데이터 접근 불가. 기업 내부 문서나 개인화된 자료는 학습에 없다.
RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 이 세 가지 모두에 대응하는 구조예요.
방식은 간단합니다. LLM이 답변을 생성하기 전에, 관련 문서를 먼저 '검색'해서 컨텍스트로 넣어주는 거예요. LLM 자체를 바꾸는 게 아니라, 입력 방식을 바꾸는 거거든요. 직접 RAG를 구현해보면서 느낀 건, 이게 의외로 단순한 발상인데 효과는 꽤 크다는 점이에요.
RAG 파이프라인은 7단계로 동작해요.
- 외부 문서(PDF, HTML 등)를 불러온다
- 텍스트를 정제하고 전처리한다
- 긴 문서를 검색 가능한 작은 단위(청크)로 쪼갠다
- 각 청크를 고차원 벡터(임베딩)로 변환한다
- 벡터를 FAISS, Chroma 같은 벡터 데이터베이스에 저장한다
- 사용자 질문을 임베딩해 유사도 높은 청크를 검색한다
- 검색된 청크 + 질문을 함께 LLM에 전달해 답변을 생성한다
RAG를 적용하면 사실 정확도가 기존 LLM 대비 평균 20% 이상 향상됐다는 연구 결과도 있어요. (출처: gttkorea.com, 2024) 당뇨병 지침 기반 의료 AI에 적용한 사례에서는 할루시네이션이 유의미하게 줄었다는 논문도 나왔고요.
핵심은 LLM을 바꾸는 게 아니라 컨텍스트를 설계하는 것이라는 점이에요.
AI 에이전트는 RAG와 무엇이 다른가
RAG가 "질문에 맞는 문서를 찾아서 LLM에 넘기는 구조"라면, AI 에이전트는 목표를 주면 스스로 계획 세우고 도구를 쓰는 자율 시스템이에요.
차이를 명확히 하면 이렇습니다.
| 구분 | RAG | AI 에이전트 |
|---|---|---|
| 역할 | 질문과 관련 문서를 검색해 LLM에 전달 | 목표를 스스로 분해하고 도구를 선택해 실행 |
| 도구 사용 | 없음 (검색만 수행) | 검색·계산기·API·파일 등 여러 도구 호출 |
| 루프 | 단방향 (1회 검색 → 1회 생성) | 반복 루프 (관찰→계획→행동→관찰 반복) |
에이전트는 ReAct 패턴으로 동작하는 경우가 많아요. Reasoning(추론)과 Acting(행동)을 번갈아가며 진행하는 방식이에요. "이 질문을 해결하려면 먼저 검색이 필요하다 → 검색 도구 호출 → 결과 확인 → 추가 계산이 필요하다 → 계산기 호출 → 최종 답변" 같은 흐름이죠.
LangChain에서 에이전트에 등록할 수 있는 도구 예시를 보면 실시간 웹 검색(Tavily), Python 코드 실행, 파일 읽기, 기업 내부 API 연동까지 다양해요.
2024~2025년을 거치면서 AI의 패러다임이 단순 챗봇에서 자율 행동 에이전트로 옮겨가고 있는데, LangGraph(그래프 기반 멀티 에이전트 오케스트레이션)가 그 중심에 있어요. LangChain 위에서 동작하면서 루프, 조건 분기, 체크포인트 같은 복잡한 흐름을 제어하거든요. (출처: DataCamp 비교 가이드, 2025)
LLM에 지식을 어떻게 넣느냐가 진짜 설계 문제예요
파인튜닝, RAG, 에이전트 세 가지를 두고 어떤 게 맞는 방법인지 헷갈리는 분들이 꽤 있어요.
간단하게 기준을 나눠보면 이래요.
- 파인튜닝: 모델 행동 방식이나 말투를 바꾸고 싶을 때. 특정 도메인 스타일로 응답하게 만드는 것
- RAG: 최신 정보나 방대한 내부 문서 기반으로 정확하게 답변해야 할 때. 데이터가 자주 바뀌는 경우
- 에이전트: 단순 답변이 아니라 여러 단계의 작업을 자동화해야 할 때
세 가지를 조합하는 경우도 많아요. 파인튜닝된 모델에 RAG를 붙이고, 에이전트가 이를 도구로 사용하는 식이죠.
LangChain이 주목받는 이유가 여기 있어요. 이 세 가지 접근을 하나의 프레임워크 안에서 조합할 수 있게 해주거든요. 모델을 교체하거나 벡터DB를 바꾸거나 새 도구를 추가하는 작업이 구성 요소를 갈아끼우는 수준으로 단순해집니다.
LLM 자체를 더 크게 만드는 것만이 해결책이 아니에요. 어떤 정보를 어떻게 넣어주느냐, 그 구조를 어떻게 설계하느냐가 실제 성능을 가릅니다.
참고: 삼성SDS - 랭체인 LangChain이란, gttkorea.com - RAG 기반 LLM 부상 (2024)