마치며. RAG 마스터 — 전체 정리

출처: 『RAG 마스터: 랭체인으로 완성하는 LLM 서비스』(브라이스 유·조경아·박수진·김재웅, 프리렉 2025) | 공식: https://www.langchain.com/

0장 환경 설정부터 9장 임베딩 파인튜닝까지, 이 책이 다룬 RAG의 전 여정을 한눈에 되짚는다. 각 기법이 어디에서 왜 등장했는지 한 줄기로 꿰면, 실제 프로젝트에서 "지금 여기에 뭘 쓸까?"를 빠르게 판단할 수 있다.


실습 — 책 공식 repo 전체: langchain-kr/langchain-tutorial — 1~9장 모든 노트북을 다시 종합해 보며 자기 프로젝트에 맞는 RAG 조합 결정.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

  • RAG 전체 파이프라인(로드→분할→임베딩→저장→검색→생성)을 단계별로 요약한다.
  • 기본 RAG·고도화 RAG·그래프 RAG·에이전트 RAG·파인튜닝을 상황별로 비교하고 적합한 기법을 선택한다.
  • 검색 품질·생성 품질·흐름 구조·데이터 구조 네 축에서 각 기법이 어떤 문제를 해결하는지 설명한다.
  • 시나리오별 의사결정 가이드를 참조해 실전 프로젝트에 적용할 RAG 기법 조합을 결정한다.
  • 단계별 로드맵(Phase 1~4)에 따라 RAG 시스템의 구축·고도화 순서를 수립한다.

전체 흐름도

[문서 · 이미지 · 지식그래프]
        ↓
  (1) 로드 — DocumentLoader (텍스트/PDF/웹) · unstructured (멀티모달)  ← 2장·3장
        ↓
  (2) 분할 — TextSplitter · SemanticChunker · 부모-자식 분할            ← 2장·4장
        ↓
  (3) 임베딩 — OpenAIEmbeddings · HuggingFace · 파인튜닝 임베딩         ← 2장·9장
        ↓
  (4) 저장 — Chroma · FAISS · Neo4j(그래프)                             ← 2장·5장
        ↓
  (5) 검색 ─────────────────────────────────────────────────────────────
       ├─ 기본: as_retriever() (유사도 k개)                              ← 2장
       ├─ 고도화: 멀티쿼리 · HyDE · 앙상블(BM25+Dense) · 리랭킹          ← 4장
       ├─ 그래프: 로컬/글로벌 검색 · Cypher                              ← 5장
       └─ 에이전트: ReAct가 도구로서 검색                                ← 7장
        ↓
  (6) 생성 ─────────────────────────────────────────────────────────────
       ├─ 기본: retriever | prompt | LLM | parser                        ← 1장·2장
       ├─ Self-RAG: 검색 필요 여부 자체 판단 + 품질 자체 평가             ← 4장
       ├─ LangGraph: StateGraph로 분기·루프 제어                         ← 6장
       └─ 파인튜닝 LLM: RAFT+LoRA로 도메인 특화                          ← 8장
        ↓
    [최종 답변]

인덱싱(1~4)은 사전 준비, 쿼리(5~6)는 실시간 처리. 고도화·그래프·에이전트는 (5)~(6) 사이에 껴들어 검색 품질과 답변 품질을 각각 높인다.


1. 단계별 핵심 요약

주제 핵심 기법 한 줄 takeaway
0장 실습 환경 Colab · .env · API 키 환경부터 잡아야 코드가 돌아간다
1장 랭체인 기초 LCEL · Runnable · 프롬프트 · 출력 파서 · 메모리 prompt \| model \| parser 조합이 RAG의 뼈대다
2장 RAG 기초 로드→분할→임베딩→저장→검색→생성 파이프라인 6단계를 직접 조립하면 RAG가 완성된다
3장 멀티모달 RAG unstructured · MultiVectorRetriever · MLLM 이미지·표를 텍스트와 함께 검색·생성할 수 있다
4장 RAG 고도화 청킹 전략 · 질의 변형 · 앙상블 · 리랭킹 · Self-RAG 검색 품질과 생성 품질은 각 단계에서 따로 올린다
5장 그래프 RAG 지식 그래프 · Neo4j · Cypher · 커뮤니티 탐지 관계형 데이터는 벡터 DB 대신 그래프로 다룬다
6장 LangGraph StateGraph · 분기 · 루프 · 체크포인트 · Human-in-the-loop 복잡한 흐름은 상태 그래프로 선언적으로 설계한다
7장 ReAct 에이전트 ReAct 방법론 · ToolNode · LangGraph 에이전트 루프 LLM이 생각→행동→관찰을 반복하며 자율적으로 문제를 푼다
8장 LLM 파인튜닝 RAFT · SFT · LoRA · QLoRA · RunPod 도메인 데이터로 모델 자체를 RAG에 맞게 튜닝할 수 있다
9장 임베딩 파인튜닝 sentence-transformers · MNRL · 하드 네거티브 마이닝 검색 품질의 뿌리인 임베딩 모델 자체를 개선할 수 있다

2. RAG를 키우는 4개의 축

RAG의 성능을 높이는 방향은 크게 네 가지다. 각 축에서 어떤 기법이 무엇을 해결하는지 정리한다.

축 1. 검색 품질 (무엇을 가져오는가)

문서를 얼마나 잘 찾아오느냐가 생성 품질의 상한선이다.

  • 청킹: 부모-자식 분할(ParentDocumentRetriever)로 정밀 검색 + 풍부한 컨텍스트
  • 질의 변형: 멀티쿼리 생성(MultiQueryRetriever) · HyDE로 질문과 문서 간 표현 차이 극복
  • 하이브리드 검색: BM25(희소) + Dense(밀집) → EnsembleRetriever로 각 방식의 약점 보완
  • 리랭킹: Cross-Encoder로 초기 결과를 재정렬해 진짜 관련 문서만 LLM에 전달
  • 임베딩 파인튜닝: 도메인 특화 쌍(질문-정답) + 하드 네거티브로 검색 임베딩 자체 개선

축 2. 생성 품질 (어떻게 답하는가)

가져온 컨텍스트로 LLM이 얼마나 좋은 답을 내는가.

  • 프롬프트 최적화: 퓨샷 · 예제 선택기 · rag-prompt 허브로 지침 품질 향상
  • Self-RAG: 검색 필요 여부 판단 → 관련성 평가 → 답변 품질 자가 평가 → 루프
  • LLM 파인튜닝: RAFT로 RAG 형식(컨텍스트 포함 Q&A)에 맞게 모델 훈련

축 3. 흐름 구조 (어떻게 조율하는가)

단순 체인을 넘어 분기·루프·멀티스텝이 필요한 경우.

  • LangGraph: StateGraph + 조건부 엣지로 "질문 분류 → 검색 경로 선택 → 생성" 같은 복잡한 흐름 선언
  • ReAct 에이전트: Thought → Action → Observation 루프로 LLM이 도구를 선택·실행
  • Human-in-the-loop: 중간 상태에서 사람이 개입·수정·승인하는 체크포인트

축 4. 데이터 구조 (어떻게 저장하는가)

데이터의 성격에 따라 저장소 선택이 검색 품질을 좌우한다.

  • 벡터 DB(Chroma·FAISS): 의미 유사도 기반 비구조화 텍스트
  • 그래프 DB(Neo4j): 개체 간 관계·다층 추론이 필요한 지식 구조
  • 멀티벡터 저장소: 원본(docstore) + 요약/임베딩(vectorstore) 분리로 멀티모달·대용량 문서 처리

3. 언제 무엇을 쓰나 — 의사결정 가이드

상황 권장 접근 핵심 기법
처음 RAG를 만든다 기본 RAG (2장) RecursiveTextSplitter + Chroma + as_retriever
검색 정밀도가 부족하다 청킹·검색 고도화 (4장) 부모-자식 분할 · 앙상블 · 리랭킹
질문과 문서 표현이 안 맞는다 질의 변형 (4장) MultiQueryRetriever · HyDE
이미지·표·차트가 섞여 있다 멀티모달 RAG (3장) unstructured + MultiVectorRetriever + MLLM
개체 간 관계가 중요한 데이터 그래프 RAG (5장) Neo4j + Cypher + 커뮤니티 탐지
검색→판단→검색 루프가 필요하다 LangGraph (6장) StateGraph + 조건부 엣지 + 체크포인트
LLM이 스스로 도구를 선택해야 한다 ReAct 에이전트 (7장) ToolNode + LangGraph create_react_agent
도메인 특화 답변 품질이 낮다 LLM 파인튜닝 (8장) RAFT + SFT + LoRA/QLoRA
검색 자체의 벡터 품질이 낮다 임베딩 파인튜닝 (9장) sentence-transformers + MNRL + 하드 네거티브
Self-RAG처럼 자체 검증을 원한다 Self-RAG (4장) 관련성 평가 토큰 + 조건 분기

4. 실전 적용 로드맵

단계별로 RAG를 구축·고도화하는 권장 순서다. 각 단계를 완료한 후 다음으로 넘어간다.

Phase 1 — PoC (개념 검증)

  • [ ] 환경 설정: .env, API 키, 패키지 설치 (0장)
  • [ ] 기본 파이프라인 동작 확인: 로드 → 분할 → 임베딩 → Chroma → 검색 → 생성 (2장)
  • [ ] prompt | model | StrOutputParser() LCEL 체인 작동 확인 (1장)

Phase 2 — 검색 품질 고도화

  • [ ] 청킹 전략 실험: 고정 분할 → SemanticChunker → 부모-자식 분할 비교
  • [ ] 질의 변형 적용: MultiQueryRetriever 또는 HyDE 중 선택
  • [ ] 하이브리드 검색: BM25 + Dense → EnsembleRetriever
  • [ ] 리랭킹 추가: Cross-Encoder로 초기 결과 재정렬
  • [ ] (선택) Self-RAG로 검색 필요 여부 자동 판단

Phase 3 — 구조 고도화

  • [ ] 복잡한 흐름은 LangGraph StateGraph로 전환 (6장)
  • [ ] 다중 도구가 필요하면 ReAct 에이전트 도입 (7장)
  • [ ] 멀티모달 데이터(이미지·표)가 있으면 3장 전략 적용
  • [ ] 관계형 데이터가 있으면 Neo4j 그래프 RAG 검토 (5장)

Phase 4 — 운영 최적화

  • [ ] 도메인 특화 품질이 부족하면: LLM 파인튜닝(8장) 또는 임베딩 파인튜닝(9장) 중 선택
  • [ ] LangSmith로 평가·모니터링 파이프라인 구축
  • [ ] 검색 성능 지표(MRR·NDCG·Precision·Recall) 정량 측정

핵심 개념 정리

개념 한 줄 요약
RAG 외부 문서를 검색해 LLM의 생성에 주입. 최신·도메인 정보를 반영하는 실용 기법
LCEL 러너블을 \| 로 잇는 선언적 체인. invoke·batch·stream 공통 인터페이스
임베딩 텍스트(또는 이미지)를 숫자 벡터로 변환. 유사도 계산의 기반
청킹 긴 문서를 검색·생성에 최적화된 단위로 분할. 전략에 따라 검색 품질이 달라진다
앙상블 검색 BM25(키워드) + Dense(의미) 하이브리드로 두 방식의 장점을 결합
리랭킹 초기 검색 결과를 Cross-Encoder로 재정렬. 노이즈를 걸러 LLM 부담을 줄인다
Self-RAG LLM이 검색 필요 여부·관련성·품질을 스스로 평가해 결과를 개선하는 고도화 방법론
그래프 RAG 개체-관계를 그래프로 저장(Neo4j)하고 Cypher·커뮤니티 탐지로 다층 추론
LangGraph StateGraph 기반 워크플로. 분기·루프·체크포인트·Human-in-the-loop 지원
ReAct Thought→Action→Observation 루프. LLM이 도구를 자율적으로 선택·실행
RAFT RAG 형식(컨텍스트 포함 Q&A + 산만 문서)으로 LLM을 파인튜닝해 도메인 정확도 향상
LoRA 원본 가중치를 고정하고 저랭크 행렬만 학습. GPU 메모리 효율적 파인튜닝
MNRL MultipleNegativesRankingLoss. 배치 내 다른 샘플을 네거티브로 활용하는 대조 학습 손실 함수
하드 네거티브 의미상 비슷하지만 정답이 아닌 어려운 부정 예시. 임베딩 모델 변별력을 높인다

실무 체크리스트

  • [ ] 기본 RAG 6단계(로드→분할→임베딩→저장→검색→생성)를 직접 조립해 동작을 확인한다.
  • [ ] 검색 품질이 부족할 때 단계별로 원인을 찾는다 — 청킹 → 질의 변형 → 검색 알고리즘 → 리랭킹 순.
  • [ ] 데이터 성격에 맞는 저장소를 고른다 — 비구조화 텍스트는 벡터 DB, 관계형 지식은 그래프 DB.
  • [ ] 흐름이 복잡해지면(분기·루프·Human-in-the-loop) LangGraph로 전환한다.
  • [ ] 도메인 특화 품질을 높이려면 LLM 파인튜닝(RAFT+LoRA)과 임베딩 파인튜닝 중 병목이 어디인지 먼저 진단한다.
  • [ ] 모든 모델명·API 가격은 빠르게 바뀐다. 공식 문서를 항상 최신 기준으로 확인한다.
  • [ ] LangSmith로 각 단계를 추적·평가해 어느 기법이 실제로 성능을 높이는지 정량으로 검증한다.

연습문제

  1. 시나리오 설계. 사내 법무 문서 수천 건을 대상으로 RAG를 구축한다. 문서에는 계약서 이미지·표가 많고, "A 회사와 B 회사의 계약 관계"처럼 개체 간 관계를 묻는 질문이 자주 온다. 어떤 기법 조합을 선택하겠는가? 각 선택의 이유를 단계별로 논하라.

  2. 비교 분석. 기본 RAG와 Self-RAG의 가장 큰 차이를 설명하고, Self-RAG가 비용 측면에서 불리한 이유와 그럼에도 쓸 만한 상황을 제시하라.

  3. 설계 판단. 검색 정밀도를 높이기 위해 "리랭킹"과 "임베딩 파인튜닝" 중 하나를 선택해야 한다. 어느 상황에서 무엇을 먼저 시도할지, 판단 기준과 함께 설명하라.

  4. 구조 선택. 다음 두 요구사항을 가진 시스템을 설계한다: (a) 사용자 질문에 따라 '검색' 또는 '데이터베이스 조회' 중 경로를 자동으로 선택, (b) 답변 전 사람이 승인하는 단계가 있다. 랭체인 기본 체인 대신 LangGraph를 써야 하는 이유와 필요한 핵심 컴포넌트를 설명하라.

  5. 전체 진단. 구축한 RAG 시스템의 답변 품질이 낮다. 검색 단계 문제인지, 생성 단계 문제인지 어떻게 구분하겠는가? 각 단계를 진단하는 방법과 해당 고도화 기법을 매핑하라.


최신 동향 (2026-05 기준)

최신 동향 (검증 2026-05-21) — 책(2025, LangChain 0.3) 이후 변화만 보완 정리.

  • LangGraph 1.0 GA 독립화. 복잡한 분기·루프·에이전트의 표준이 LangGraph로 완전히 이동. StateGraph + checkpointer persistence가 현행 메모리 관리 방식. 책의 RunnableWithMessageHistory는 LangGraph persistence로 대체 권장. (출처: https://langchain-ai.github.io/langgraph/)
  • ReAct 에이전트 간소화. 수동 ReAct 구성은 create_react_agent() 헬퍼로 대폭 단순화. (출처: https://langchain-ai.github.io/langgraph/agents/agents/)
  • 임베딩 파인튜닝 표준화. sentence-transformers v3+ SentenceTransformerTrainer + MNRL + 하드 네거티브 마이닝이 실무 표준. (출처: https://sbert.net/docs/sentence_transformer/training_overview.html)
  • 모델·가격은 수시 변동. 공식 모델 목록 항상 확인: OpenAI(https://platform.openai.com/docs/models) · Anthropic(https://docs.anthropic.com/en/docs/about-claude/models) · Google(https://ai.google.dev/gemini-api/docs/models)

부록 A. 용어 사전

한글 영문 의미
검색 증강 생성 RAG (Retrieval-Augmented Generation) 외부 문서를 검색해 LLM 생성에 주입하는 기법. 최신·도메인 정보를 반영한다
랭체인 표현식 언어 LCEL (LangChain Expression Language) 러너블을 |로 잇는 선언적 체인 구성 방식. invoke·batch·stream 공통 인터페이스 제공
청킹 Chunking 긴 문서를 검색·생성에 최적화된 단위로 분할하는 전처리 단계
앙상블 검색 Ensemble Retrieval BM25(키워드 희소)와 Dense(의미 밀집) 두 방식을 결합해 각각의 약점을 보완하는 검색 전략
리랭킹 Reranking 초기 검색 결과를 Cross-Encoder로 재정렬해 노이즈를 줄이는 후처리 단계
자기 참조 RAG Self-RAG LLM이 검색 필요 여부·관련성·답변 품질을 스스로 평가해 결과를 개선하는 방법론
그래프 RAG Graph RAG 개체-관계를 지식 그래프(Neo4j)로 저장하고 Cypher·커뮤니티 탐지로 다층 추론하는 기법
상태 그래프 StateGraph LangGraph의 핵심 컴포넌트. 상태(state)와 조건부 엣지로 복잡한 워크플로를 선언적으로 설계
ReAct ReAct (Reasoning + Acting) Thought→Action→Observation 루프로 LLM이 도구를 자율적으로 선택·실행하는 에이전트 방법론
검색 증강 파인튜닝 RAFT (Retrieval-Augmented Fine-Tuning) RAG 형식(컨텍스트 포함 Q&A + 산만 문서)으로 LLM을 파인튜닝해 도메인 정확도를 높이는 기법
저랭크 적응 LoRA (Low-Rank Adaptation) 원본 가중치를 고정하고 저랭크 행렬만 학습하는 파라미터 효율적 파인튜닝 기법
다중 부정 랭킹 손실 MNRL (MultipleNegativesRankingLoss) 배치 내 다른 샘플을 네거티브로 활용하는 대조 학습 손실 함수. 임베딩 파인튜닝의 표준

부록 B. 핵심 비교표

RAG 유형별 종합 비교

구분 기본 RAG 고도화 RAG 그래프 RAG 에이전트 RAG
핵심 기법 as_retriever + LCEL 앙상블·리랭킹·Self-RAG Neo4j + Cypher ReAct + ToolNode
데이터 구조 벡터 DB (Chroma·FAISS) 벡터 DB + 멀티벡터 그래프 DB (Neo4j) 혼합 (도구에 따라 선택)
적합 질문 유형 단순 의미 유사도 검색 복잡한 질의·표현 불일치 개체 간 관계·다층 추론 다단계 계획·자율 도구 선택
흐름 제어 단방향 체인 조건 분기 (Self-RAG) 단방향 + Cypher 질의 Thought→Action→Obs 루프
구현 복잡도 낮음 중간 높음 높음
참고 장 2장 4장 5장 7장

파인튜닝 방법 비교

구분 LLM 파인튜닝 (RAFT+LoRA) 임베딩 파인튜닝 (MNRL)
개선 대상 생성 품질 (답변 정확도) 검색 품질 (벡터 유사도)
학습 데이터 컨텍스트 포함 Q&A + 산만 문서 질문-정답 쌍 + 하드 네거티브
필요 자원 GPU 대용량 (RunPod 등 클라우드) GPU 중간 (로컬 가능)
적합 상황 도메인 특화 답변 품질이 낮을 때 검색 임베딩 자체 변별력이 낮을 때
참고 장 8장 9장

부록 C. 추천 참고 자료

검증된 외부 자료 (Tier 1 공식, 생존 확인 2026-05-21)

자료 링크
LangChain 개념 허브 python.langchain.com/docs/concepts
LangGraph 공식 문서 langchain-ai.github.io/langgraph
sentence-transformers 학습 가이드 sbert.net/docs
OpenAI 모델 목록 platform.openai.com/docs/models
Anthropic 모델 목록 docs.anthropic.com/en/docs/about-claude/models
Google Gemini 모델 목록 ai.google.dev/gemini-api/docs/models
Awesome-LangChain (커뮤니티) github.com/kyrolabs/awesome-langchain
책 실습 코드 github.com/langchain-kr/langchain-tutorial
연계 챕터 설명
0장 실습 환경 API 키·패키지 설치·Colab 환경 설정
1장 랭체인 기초 LCEL·Runnable·프롬프트·출력 파서
2장 기본 RAG 6단계 파이프라인 전체 구현
4장 RAG 고도화 청킹·질의 변형·앙상블·리랭킹·Self-RAG
5장 그래프 RAG Neo4j·Cypher·커뮤니티 탐지
6장 LangGraph StateGraph·분기·루프·체크포인트
7장 ReAct 에이전트 ToolNode·create_react_agent
8장 LLM 파인튜닝 RAFT·SFT·LoRA·QLoRA
9장 임베딩 파인튜닝 sentence-transformers·MNRL·하드 네거티브

부록 D. 연습문제 풀이

  1. (멀티모달 + 그래프 RAG 조합) 계약서 이미지·표는 unstructured + MultiVectorRetriever(3장)로 처리하고, "A 회사와 B 회사의 계약 관계"처럼 개체 간 관계 질문은 Neo4j 그래프 RAG(5장)로 다룬다. 즉 저장소를 벡터 DB(비구조화 텍스트)와 그래프 DB(개체-관계)로 이중화하고, 질문 유형에 따라 LangGraph StateGraph가 검색 경로를 분기 선택하는 구조가 적합하다(§3 의사결정 가이드 참조).

  2. (기본 RAG vs Self-RAG) 기본 RAG는 질문이 들어오면 무조건 검색 후 생성하지만, Self-RAG는 LLM이 검색 필요 여부를 먼저 판단하고, 검색 결과의 관련성과 최종 답변 품질까지 자가 평가해 루프를 반복한다(§1, 4장). 이 자가 평가 루프가 LLM 호출을 여러 번 수행하기 때문에 비용·지연이 증가하는 것이 단점이다. 그럼에도 검색 결과의 노이즈가 많거나 답변 품질의 일관성이 중요한 도메인(예: 법률·의료)에서는 정확도 향상 효과가 추가 비용을 정당화한다.

  3. (리랭킹 vs 임베딩 파인튜닝 선택 기준) 리랭킹(Cross-Encoder)은 도메인 특화 학습 데이터 없이도 즉시 적용 가능하므로 초기 단계나 레이블링 비용이 부담될 때 먼저 시도한다. 임베딩 파인튜닝(MNRL + 하드 네거티브)은 질문-정답 쌍 데이터셋 구축이 선행되어야 하지만, 검색 벡터 표현 자체의 변별력이 낮은 경우(즉 리랭킹으로도 개선 한계가 있을 때) 근본 해결책이 된다(§2 축 1, 9장). 판단 순서: 리랭킹 적용 후 지표(MRR·Recall) 개선 폭이 미미하면 임베딩 파인튜닝으로 이동.

  4. (LangGraph를 써야 하는 이유) 랭체인 기본 체인은 단방향 선형 실행만 지원하므로, "검색 경로 자동 선택"(조건부 분기)과 "사람 승인 단계"(Human-in-the-loop 체크포인트) 두 요구사항을 동시에 충족할 수 없다. LangGraph는 StateGraph로 조건부 엣지를 선언해 경로를 분기하고, checkpointer로 중간 상태를 저장해 사람이 승인 후 재개하는 흐름을 구현할 수 있다(§2 축 3, 6장). 필요한 핵심 컴포넌트는 StateGraph, 조건부 엣지(add_conditional_edges), interrupt_before/interrupt_after 체크포인트다.

  5. (검색 vs 생성 단계 진단) 검색 단계 문제인지 확인하려면 검색된 문서를 직접 열람해 정답 문서가 포함되어 있는지 확인하고, Precision·Recall·MRR 같은 검색 지표를 측정한다. 정답 문서가 포함되어 있음에도 최종 답변이 나쁘다면 생성 단계 문제이므로 프롬프트 최적화·Self-RAG·LLM 파인튜닝(RAFT)을 검토한다. 검색 단계 문제라면 청킹 전략 → 질의 변형 → 앙상블·리랭킹 → 임베딩 파인튜닝 순으로 고도화하며, LangSmith로 각 단계를 추적해 병목을 정량적으로 특정한다(§2 실무 체크리스트, §4 Phase 2·4 참조).

난이도
에피소드
질문
카드를 로딩 중...
답변

클릭하거나 Space를 눌러 뒤집기

0 / 0
학습 진도 0%
이동   Space 뒤집기   R 셔플