LangChain RAG 완전 가이드: 검색 증강 생성의 구조와 실무 적용

RAG는 Retrieval-Augmented Generation, 즉 검색 증강 생성을 의미합니다. 쉽게 말하면 LLM이 답변하기 전에 기업 내부 문서, 매뉴얼, PDF, DB, 위키, 정책 문서 같은 외부 지식을 먼저 검색하고, 그 검색 결과를 근거로 답변하게 만드는 구조입니다.

기존 LLM은 학습된 지식 안에서만 답변합니다. 하지만 기업 시스템에서는 최신 정보 반영, 사내 문서 활용, 환각 답변 완화, 비용, 답변 근거 추적성 같은 문제가 자주 발생합니다. LangChain은 이런 RAG 시스템을 빠르게 만들 수 있도록 돕는 대표적인 오픈소스 프레임워크입니다.

배경 및 필요성

기업이 LLM을 도입할 때 가장 먼저 부딪히는 문제는 “우리 회사 데이터를 어떻게 이해하게 만들 것인가?”입니다. 예를 들어 “우리 회사 보안 정책상 외부 저장소에 고객 데이터를 업로드해도 되나요?”라는 질문은 일반적인 보안 원칙만으로는 정확히 답하기 어렵습니다.

일반 LLM은 인터넷에 공개된 보안 원칙은 설명할 수 있지만, 회사 내부 보안 정책 문서를 모르면 정확한 답변을 할 수 없습니다. 이때 선택지는 프롬프트에 문서를 직접 삽입하는 방식, 파인튜닝, RAG로 나뉩니다.

실무에서는 대부분 RAG를 먼저 도입하고, 필요할 때 일부 파인튜닝을 조합합니다. RAG는 사내 지식을 최신 상태로 유지하면서도 모델 자체를 매번 다시 학습하지 않아도 되는 현실적인 접근입니다.

핵심 개념 및 원리

LangChain이란?

LangChain은 LLM 애플리케이션을 만들기 위한 오픈소스 프레임워크입니다. 단순히 OpenAI API를 호출하는 수준이 아니라, 문서 로딩, 텍스트 분할, 임베딩, 벡터 저장소, 검색기, Prompt Template, LLM, 관측 도구를 하나의 흐름으로 연결할 수 있게 해줍니다.

LangChain의 핵심 가치는 교체 가능한 부품 구조입니다. 처음에는 Chroma를 쓰다가 운영 단계에서 Milvus, Qdrant, Elasticsearch, OpenSearch, PostgreSQL pgvector로 바꿀 수 있고, LLM도 OpenAI, Anthropic, Ollama, Hugging Face 기반 모델 등으로 교체할 수 있습니다.

RAG의 기본 동작 흐름

RAG는 크게 문서를 미리 읽고 검색 가능한 형태로 저장하는 Indexing 단계와, 사용자가 질문했을 때 관련 문서를 검색하고 LLM으로 답변을 생성하는 Retrieval & Generation 단계로 나뉩니다.

문서 수집
→ 문서 정제
→ Chunk 분할
→ Embedding 생성
→ Vector DB 저장

사용자 질문
→ 질문 Embedding 생성
→ Vector DB 검색
→ 관련 Chunk 반환
→ Prompt 구성
→ LLM 답변 생성

RAG 핵심 컴포넌트 비교

LangChain을 사용하는 이유

LangChain은 RAG 구성 요소를 빠르게 연결할 수 있습니다. 직접 구현하면 PDF 로딩, 텍스트 분할, Embedding 생성, Vector DB 저장, 검색기 구현, Prompt 조합, LLM 호출, 응답 파싱, 로그 추적을 모두 직접 만들어야 합니다.

LangChain은 이 과정을 표준화된 인터페이스로 연결합니다. 또한 벤더 종속성을 줄여 초기 PoC에서 쓰던 도구를 운영 단계에서 다른 도구로 바꾸기 쉽습니다.

단순 RAG는 질문, 검색, 답변으로 끝납니다. 하지만 실무에서는 질문 분석, 검색 필요 여부 판단, 문서 검색, 검색 결과 품질 평가, 재검색, 답변 생성, 출처 검증 같은 복잡한 흐름이 필요해집니다.

질문 → 검색 → 답변

질문 분석
→ 검색 필요 여부 판단
→ 문서 검색
→ 검색 결과 품질 평가
→ 부족하면 재검색
→ 답변 생성
→ 출처 검증

이런 복잡한 흐름은 LangGraph와 함께 구성하는 것이 좋습니다. LangGraph는 상태 기반 워크플로를 구성하기 쉬워 Agentic RAG나 반복 검색 구조에 적합합니다.

실무 적용 예시

아래 예시는 LangChain으로 가장 기본적인 RAG 시스템을 구성하는 코드입니다. 먼저 LangChain, OpenAI 연동 패키지, Chroma, PDF 로더를 설치합니다.

pip install -U langchain langchain-openai langchain-community chromadb pypdf

예시 1. PDF 문서 기반 RAG

import os

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma
from langchain_core.prompts import ChatPromptTemplate

# OpenAI API Key 설정
os.environ["OPENAI_API_KEY"] = "YOUR_API_KEY"

# 1. PDF 문서 로딩
loader = PyPDFLoader("company_security_policy.pdf")
docs = loader.load()

# 2. 문서 Chunk 분할
# chunk_size가 너무 작으면 맥락이 깨지고,
# 너무 크면 검색 정확도가 떨어질 수 있습니다.
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=120
)

splits = text_splitter.split_documents(docs)

# 3. Embedding 모델 설정
embeddings = OpenAIEmbeddings(
    model="text-embedding-3-small"
)

# 4. Vector DB 저장
vectorstore = Chroma.from_documents(
    documents=splits,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

# 5. Retriever 생성
retriever = vectorstore.as_retriever(
    search_kwargs={"k": 4}
)

# 6. LLM 설정
llm = ChatOpenAI(
    model="gpt-4o-mini",
    temperature=0
)

# 7. RAG Prompt 구성
prompt = ChatPromptTemplate.from_template("""
당신은 기업 내부 문서를 기반으로 답변하는 AI 어시스턴트입니다.

아래 Context에 있는 내용만 근거로 답변하세요.
Context에 답이 없으면 "문서에서 확인할 수 없습니다"라고 답변하세요.

Context:
{context}

Question:
{question}

Answer:
""")

# 8. RAG 실행 함수
def ask(question: str):
    # 질문과 관련 있는 문서 검색
    retrieved_docs = retriever.invoke(question)

    # 검색된 문서를 하나의 Context로 합침
    context = "\n\n".join(doc.page_content for doc in retrieved_docs)

    # Prompt 생성
    messages = prompt.invoke({
        "context": context,
        "question": question
    })

    # LLM 답변 생성
    response = llm.invoke(messages)

    return {
        "answer": response.content,
        "sources": [
            doc.metadata for doc in retrieved_docs
        ]
    }


result = ask("외부 클라우드 저장소에 고객 데이터를 업로드해도 되나요?")

print(result["answer"])
print(result["sources"])

예시 2. FastAPI로 RAG API 만들기

실무에서는 RAG를 단순 스크립트가 아니라 API 형태로 제공합니다. FastAPI와 Pydantic을 사용하면 RAG 질의 엔드포인트를 간단히 만들 수 있습니다.

pip install fastapi uvicorn pydantic

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title="LangChain RAG API")


class QuestionRequest(BaseModel):
    question: str


class QuestionResponse(BaseModel):
    answer: str
    sources: list


@app.post("/rag/ask", response_model=QuestionResponse)
def rag_ask(request: QuestionRequest):
    result = ask(request.question)

    return QuestionResponse(
        answer=result["answer"],
        sources=result["sources"]
    )

API 서버는 다음 명령으로 실행합니다.

uvicorn main:app --host 0.0.0.0 --port 8000

요청은 다음처럼 보낼 수 있습니다.

curl -X POST "http://localhost:8000/rag/ask" \
  -H "Content-Type: application/json" \
  -d '{"question": "개인정보가 포함된 로그를 외부 분석 도구에 전송해도 되나요?"}'

예시 3. PostgreSQL pgvector 기반 Vector DB 구성

운영 환경에서는 Chroma보다 PostgreSQL pgvector를 선택하는 경우도 많습니다. 특히 이미 PostgreSQL을 운영 중인 조직이라면 기존 DBA, 백업, 모니터링 체계와 보안 정책을 활용할 수 있다는 장점이 있습니다.

예시 테이블과 인덱스 구성은 다음과 같습니다.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE rag_documents (
    id BIGSERIAL PRIMARY KEY,
    document_id TEXT NOT NULL,
    title TEXT,
    content TEXT NOT NULL,
    metadata JSONB,
    embedding VECTOR(1536),
    created_at TIMESTAMP DEFAULT now()
);

CREATE INDEX idx_rag_documents_embedding
ON rag_documents
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

CREATE INDEX idx_rag_documents_metadata
ON rag_documents
USING gin (metadata);

검색 시에는 벡터 유사도와 메타데이터 필터링을 함께 사용할 수 있습니다.

SELECT
    id,
    title,
    content,
    metadata,
    1 - (embedding <=> :query_embedding) AS similarity
FROM rag_documents
WHERE metadata ->> 'department' = 'security'
ORDER BY embedding <=> :query_embedding
LIMIT 5;

RAG 솔루션 선택 기준

LangChain을 도입할지 판단할 때는 기능이 많은가보다 우리 조직의 운영 모델에 맞는가를 봐야 합니다. 데이터 종류, 문서 갱신 주기, 보안 요구사항, 검색 품질, 운영 환경, 평가 체계, 비용 구조를 함께 검토해야 합니다.

LangChain 기반 RAG 아키텍처 예시

[사용자]
   ↓
[Web / Chat UI]
   ↓
[FastAPI Backend]
   ↓
[LangChain RAG Service]
   ├─ Document Loader
   ├─ Text Splitter
   ├─ Embedding Model
   ├─ Retriever
   ├─ Prompt Template
   └─ LLM
   ↓
[Vector DB]
   ├─ Chroma
   ├─ Qdrant
   ├─ Milvus
   ├─ PostgreSQL pgvector
   └─ OpenSearch

운영 규모가 커지면 문서 수집, 정제, Chunking, Embedding 생성, Vector DB 저장을 비동기 파이프라인으로 분리하고, 질의 단계에는 Retriever, Reranker, LLM, 답변과 출처 반환 흐름을 둡니다.

[문서 수집 Worker]
   ↓
[정제 / Chunking Queue]
   ↓
[Embedding Worker]
   ↓
[Vector DB]

[사용자 질문]
   ↓
[Retriever]
   ↓
[Reranker]
   ↓
[LLM]
   ↓
[답변 + 출처]

주의점 및 한계

RAG는 환각을 완전히 없애지 못합니다

RAG는 LLM의 환각을 줄이는 기술이지 완전히 제거하는 기술은 아닙니다. 검색된 문서가 부정확하거나, Prompt가 느슨하거나, LLM이 문서를 잘못 해석하면 여전히 잘못된 답변이 나올 수 있습니다.

Chunking 전략이 품질을 크게 좌우합니다

RAG 품질 문제의 상당수는 LLM이 아니라 Chunking에서 발생합니다. Chunk가 너무 작으면 문맥이 사라지고, 너무 크면 검색 정확도가 떨어집니다. overlap, 제목과 섹션 정보, 표 데이터 보존도 중요합니다.

실무에서는 단순 글자 수 기준보다 문서 구조를 반영한 분할이 좋습니다. 보안 정책 문서라면 대제목, 중제목, 조항, 예외 조건, 표의 단위를 유지하는 것이 좋습니다.

대제목
→ 중제목
→ 조항
→ 예외 조건
→ 표

Vector Search만으로는 부족할 수 있습니다

벡터 검색은 의미 기반 검색에 강하지만 정확한 코드, 제품명, 정책 번호, CVE 번호, IP 주소, 로그 ID 검색에는 약할 수 있습니다. 이런 경우에는 키워드 검색이나 Hybrid Search가 필요합니다.

CVE-2024-12345 영향받는 버전은?
방화벽 정책 FW-SEC-019 예외 조건은?
10.10.20.15 IP의 위협 인텔리전스 결과는?

권한 제어가 어렵습니다

기업 RAG에서 가장 위험한 문제 중 하나는 권한입니다. 사용자가 볼 수 없는 문서가 검색 결과에 포함되면 정보 유출이 발생합니다. 따라서 부서, 접근 등급, 소유자, 문서 유형, 유효 기간 같은 정보를 metadata로 반드시 관리하는 것이 좋습니다.

검색 시에는 반드시 권한 조건을 함께 넣어야 합니다.

retriever = vectorstore.as_retriever(
    search_kwargs={
        "k": 5,
        "filter": {
            "department": "security",
            "access_level": "internal"
        }
    }
)

평가 없는 RAG는 운영하기 어렵습니다

RAG는 PoC 단계에서는 잘 되는 것처럼 보입니다. 하지만 운영에 들어가면 질문 유형이 다양해지고 문서 품질도 일정하지 않습니다. 따라서 검색 정밀도, 답변 정확성, 충실성, 출처 정확도, 지연 시간, 질문당 비용을 측정해야 합니다.

LangChain 도입이 적합한 경우

LangChain vs 직접 구현

LangChain은 시작점으로 좋습니다. 하지만 운영 시스템에서는 LangChain이 모든 것을 해결해주지는 않습니다. 문서 수집 파이프라인, Embedding 재생성 정책, Vector DB 백업, 문서 권한 제어, 응답 로그 저장, 사용자 피드백 수집, 품질 평가 자동화, 비용 모니터링은 별도로 설계해야 합니다.

결론

LangChain은 RAG 시스템을 빠르게 구축하고 실험하기 좋은 대표적인 오픈소스 프레임워크입니다. RAG 도입을 검토하는 조직은 LangChain을 통해 우리 문서가 LLM 답변에 잘 활용되는지, 어떤 Embedding 모델과 Vector DB가 적합한지, 검색 품질이 충분한지, 출처를 제공할 수 있는지, 내부 시스템과 API로 연동 가능한지를 빠르게 검증할 수 있습니다.

하지만 LangChain을 선택한다고 해서 RAG 시스템이 자동으로 완성되는 것은 아닙니다. 좋은 RAG 시스템은 좋은 문서, 좋은 Chunking, 좋은 검색 전략, 좋은 평가 체계가 함께 맞아야 합니다.

좋은 문서
+ 좋은 Chunking
+ 좋은 검색 전략
+ 좋은 평가 체계

LangChain은 이 네 가지를 연결하는 강력한 조립 도구입니다. 도입 조직은 LangChain을 단순 개발 라이브러리가 아니라 RAG 아키텍처를 검증하고 확장하기 위한 실험실이자 운영 기반으로 바라보는 것이 좋습니다. 최종적으로는 작은 PoC에서 시작해 문서 품질과 검색 품질을 측정하고, 권한 제어와 평가 체계를 붙여가며 단계적으로 운영 수준으로 확장하는 접근이 가장 안정적입니다.