RAG 파이프라인 (1) 왜 RAG인가 — 도큐먼트 로드와 텍스트 분할

LLM에 사내 문서를 붙이려 할 때 처음 부딪히는 벽은 모델이 아니다. "왜 이 답이 나왔는지 알 수 없다"는 것이다. 파일을 올려서 답이 이상하면 할 수 있는 일이 문서 형태를 바꿔 보는 것뿐인데, 사내 문서 전체의 형태를 바꾸는 것은 현실적으로 불가능하다.

RAG를 직접 구축한다는 것은 그 블랙박스를 8개의 조정 가능한 단계로 펼치는 일이다. 이 글은 그 8단계 지도를 먼저 그리고, 사전처리의 첫 두 단계인 도큐먼트 로드와 텍스트 분할을 단계별 선택지·튜닝 파라미터·실패 모드까지 다룬다. 이어지는 편에서는 임베딩부터 리랭커까지의 검색 계층을, 프롬프트부터 체인까지의 생성 계층을 다룬다.

용어 정리

RAG를 쓰는 이유

순수 LLM의 한계

RAG를 적용하면 무엇이 달라지나

도달점은 방대한 지식 기반으로 답변하는 도메인 특화 챗봇이다. "서울특별시에 사는 특정 인물의 아버지 이름"처럼 내부 문서가 있어야만 답할 수 있는 질문이 이 구조가 필요한 전형적인 유형이다.

파일 업로드로 충분하지 않은 이유

상용 챗봇의 파일 업로드도 내부적으로 RAG를 쓴다. 결정적 차이는 과정이 열려 있는가에 있다.

투명성과 해석가능성이 직접 구축의 핵심 가치다. 추적 도구를 붙이면 "무엇이 검색됐는지"와 "각 문서의 세부 내용"까지 눈으로 확인할 수 있고, 그래야 어느 단계를 고쳐야 하는지 특정된다.

할루시네이션을 어떻게 줄이나

RAG는 할루시네이션을 없애는 방법이 아니라 줄이는 방법이다. 이 구분은 어휘 문제가 아니라 설계 문제다. 검색이 틀린 문서를 가져오면 RAG는 오히려 더 그럴듯한 오답을 만들어 낸다.

전체 파이프라인 — 사전처리 4단계와 런타임 4단계

RAG는 8단계로 구성되며, **사전 준비 단계(14)**와 **런타임 단계(58)**로 나뉜다. 이 구분이 전체의 뼈대다.

이 구분이 중요한 이유는 비용과 지연이 갈리기 때문이다. 앞의 넷은 배치로 한 번 돌고, 뒤의 넷은 질문마다 돈다. 임베딩 모델을 바꾸는 결정과 top-k를 바꾸는 결정은 비용 구조가 완전히 다르다.

단계별 산출물 흐름

각 단계를 도서관에서 공부하는 과정에 대응시키면 역할이 빠르게 잡힌다.

성능은 단계별 기법의 누적으로 오른다

RAG 성능은 한 방에 올라가지 않는다. 각 단계에 기법을 하나씩 적용할 때마다 점진적으로 향상된다.

그래서 "RAG 성능을 어떻게 올리나"라는 질문에는 단일 해법이 존재하지 않는다. 실무에서 답이 되는 것은 어느 단계의 문제인지 진단하고 그 단계의 레버를 조정하는 절차이고, 그 진단 절차는 실패 모드 종합 진단표에 정리했다.

단계 1 — 도큐먼트 로드

외부에 흩어져 있는 이질적 데이터를 시스템이 다룰 수 있는 단일 형식(Document)으로 수집·정제하는 단계다. 파이프라인의 첫 단추라 여기서의 정확성이 전체 출력 품질을 좌우한다.

소스별 로더 선택

전처리에서 반드시 제거할 것

튜닝 포인트

실패 모드

# 단계 1: 문서 로드(Load Documents)
from langchain_community.document_loaders import PyMuPDFLoader

loader = PyMuPDFLoader("data/문서.pdf")
docs = loader.load()

단계 2 — 텍스트 분할

크고 복잡한 문서를 LLM이 받아들일 수 있는 작은 조각으로 나눠, 질문에 대해 필요한 정보만 압축·선별해 가져오게 만드는 단계다. "구글이 앤스로픽에 투자한 금액은 얼마인가" 같은 한 문장에 답하려고 보고서 전체를 LLM에 넣을 이유가 없다.

분할이 필요한 두 가지 이유

분할 과정 4단계

분할기 선택

튜닝 포인트

트레이드오프 한 줄 요약: 청크가 작을수록 검색 정밀도가 오르고 답변 문맥이 줄어든다. 반대도 성립한다. 정답은 문서 성격과 질문 유형에 달렸고, 실측으로 정한다.

실패 모드

# 단계 2: 문서 분할(Split Documents)
from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=50)
splits = text_splitter.split_documents(docs)

여기까지가 원문을 검색 가능한 조각으로 만드는 구간이다. 다음 편에서는 그 조각을 벡터로 바꿔 저장하고 다시 꺼내 오는 임베딩·벡터스토어·검색기·리랭커를 다룬다.