RAG(검색 증강 생성)는 LLM에 우리 회사의 문서나 최신 정보를 결합해 답하게 만드는 가장 현실적인 방법입니다. 파인튜닝보다 비용이 낮고, 출처를 제시할 수 있으며, 데이터가 바뀌어도 모델을 다시 학습할 필요가 없습니다. 이 글에서는 동작하는 RAG 파이프라인을 다섯 단계로 나눠 구축합니다.
1단계: 문서 적재와 정제
RAG의 품질은 입력 문서의 품질을 넘지 못합니다. PDF, HTML, 노션 등에서 텍스트를 추출할 때 머리말·바닥글·내비게이션 같은 노이즈를 제거하고, 표와 코드 블록의 구조를 최대한 보존해야 합니다. 정제되지 않은 문서를 그대로 넣으면 이후 단계가 아무리 좋아도 엉뚱한 답이 나옵니다.
2단계: 청킹 전략
문서를 검색 단위로 쪼개는 청킹은 RAG에서 가장 과소평가되는 단계입니다. 너무 작게 자르면 문맥이 끊기고, 너무 크게 자르면 관련 없는 내용까지 섞입니다. 일반 문서는 300~600토큰에 10~20% 오버랩을 주는 것이 무난한 출발점입니다.
- 고정 크기 청킹: 단순하지만 문장이 중간에 끊길 수 있음
- 문장/문단 기준 청킹: 의미 단위 보존에 유리
- 구조 기반 청킹: 제목 계층을 활용해 섹션 단위로 분리
3단계: 임베딩과 벡터 저장
각 청크를 임베딩 모델로 벡터화한 뒤 벡터 DB에 저장합니다. 이때 청크 본문뿐 아니라 문서 제목, 출처 URL, 작성일 같은 메타데이터를 함께 저장해야 나중에 필터링과 출처 표시가 가능합니다. 메타데이터 설계를 미루면 운영 단계에서 반드시 후회합니다.
chunk = {
"text": "...본문...",
"embedding": [0.12, -0.04, ...],
"source": "policy_2026.pdf",
"page": 12,
"updated_at": "2026-03-01"
}4단계: 검색과 재정렬
사용자 질문을 임베딩해 벡터 검색으로 상위 K개 청크를 가져옵니다. 여기서 끝내지 말고, 가져온 후보를 리랭커(reranker)로 다시 정렬하면 정확도가 눈에 띄게 올라갑니다. 보통 벡터 검색으로 20~30개를 넉넉히 뽑은 뒤 리랭커로 상위 3~5개만 추리는 2단계 구성을 권장합니다.
5단계: 생성과 출처 표기
마지막으로 추려진 청크를 프롬프트에 문맥으로 넣고 LLM에게 답하게 합니다. 이때 “제공된 문맥에만 근거해 답하고, 근거가 없으면 모른다고 답하라”는 지침을 명시해 환각을 억제합니다. 또한 각 청크의 출처를 답변에 함께 노출해 사용자가 검증할 수 있게 합니다.
처음부터 완벽한 파이프라인을 만들려 하지 마세요. 청킹과 검색 K값만 바꿔도 체감 품질이 크게 달라지므로, 작게 만들고 평가셋으로 반복 개선하는 것이 정석입니다.
다음 단계로는 검색 정확도를 정량 측정하는 방법과, 답변 품질을 평가하는 지표를 도입해 보길 권합니다. 측정 없이 개선하는 RAG는 결국 감에 의존하게 됩니다.
