RAG의 전체 흐름 이해하기

RAG는 하나의 기능이 아니라 흐름이다

RAG를 처음 접하면 "문서를 벡터 DB에 넣고 검색하는 것"으로 이해하기 쉽습니다. 하지만 실제로는 더 넓은 흐름입니다. 문서를 모으고, 읽기 좋은 텍스트로 바꾸고, 적절한 단위로 나누고, 검색 가능한 형태로 저장한 뒤, 질문이 들어오면 관련 내용을 찾아 LLM에 전달합니다. 마지막으로 답변과 출처를 함께 보여주어 사용자가 확인할 수 있게 만듭니다.

즉 RAG는 문서 처리, 검색, 생성, 검증이 연결된 시스템입니다. 어느 한 단계가 약하면 전체 답변 품질이 흔들립니다.

1. 문서 수집: 지식의 원천을 모은다

RAG의 시작은 문서 수집입니다. 원천 문서는 다양합니다. PDF, 마크다운 파일, 웹페이지, 블로그 글, 회의록, 노트, 책, 고객지원 문서, 사내 위키가 모두 대상이 될 수 있습니다.

중요한 것은 파일 형식이 아니라 "LLM이 참고할 수 있는 텍스트로 바꿀 수 있는가"입니다. PDF라면 본문을 추출해야 하고, 웹페이지라면 HTML에서 실제 글만 가져와야 합니다. 이미지로 된 문서는 OCR을 통해 글자를 인식해야 할 수도 있습니다.

이 단계에서는 문서의 제목, 작성자, 날짜, URL, 카테고리 같은 기본 정보도 함께 모아두는 것이 좋습니다. 나중에 검색 결과를 필터링하거나 출처를 표시할 때 필요하기 때문입니다.

2. 전처리: 검색 가능한 문서로 다듬는다

수집한 문서는 그대로 쓰기 어렵습니다. 웹페이지에는 메뉴, 광고, 추천 글, 푸터 문구가 섞여 있습니다. PDF에서 추출한 텍스트는 줄바꿈이 깨지거나 페이지 번호가 중간에 들어가기도 합니다. 같은 문장이 여러 번 반복될 수도 있습니다.

전처리는 이런 불필요한 요소를 제거하는 과정입니다. 대표적으로 다음 작업을 합니다.

• HTML 태그, 광고 문구, 내비게이션 제거

• 깨진 줄바꿈과 공백 정리

• 중복 문장 제거

• 본문과 관련 없는 문구 삭제

• 제목, 소제목, 문단 구조 복원

전처리를 잘하면 검색 품질이 올라갑니다. 반대로 지저분한 문서를 그대로 저장하면, AI는 광고 문구나 깨진 문장을 근거로 엉뚱한 답변을 만들 수 있습니다.

3. 청킹과 임베딩: 문서를 검색 단위로 바꾼다

LLM에게 책 한 권이나 긴 문서 전체를 매번 넣을 수는 없습니다. 그래서 문서를 적절한 크기의 조각으로 나눕니다. 이 과정을 청킹이라고 합니다.

청크는 검색의 기본 단위입니다. 너무 작으면 문맥이 부족하고, 너무 크면 질문과 정확히 맞는 부분을 찾기 어렵습니다. 예를 들어 책이라면 장, 절, 문단 구조를 고려해 나누는 것이 좋습니다. 노트라면 제목과 본문 단락을 함께 보존하는 방식이 유리합니다.

나눈 청크는 임베딩을 거쳐 숫자 벡터로 변환됩니다. 임베딩은 문장의 의미를 숫자 좌표처럼 표현하는 방식입니다. 이렇게 만든 벡터와 원문 청크, 제목, 문서 ID, 작성일 같은 메타데이터를 함께 벡터 DB에 저장합니다. 이 과정을 색인이라고 부릅니다.

4. 검색: 질문과 가까운 문서를 찾는다

사용자가 질문을 입력하면 RAG 시스템은 먼저 질문도 임베딩으로 바꿉니다. 그리고 벡터 DB에서 의미가 가까운 청크를 찾습니다. 예를 들어 "내 노트를 기반으로 요약해줘"라는 질문이 들어오면, 단순히 같은 단어가 있는 문서만 찾는 것이 아니라 의미적으로 관련 있는 문서 조각을 찾습니다.

검색 결과는 보통 여러 개가 나옵니다. 이때 Top-K, 즉 가장 관련 있어 보이는 상위 몇 개의 청크를 가져옵니다. 하지만 검색 결과가 항상 완벽하지는 않습니다. 이후 장에서 다룰 하이브리드 검색, 리랭킹 같은 방법은 이 검색 품질을 높이기 위한 기술입니다.

5. 프롬프트 구성과 답변 생성

검색된 문서 조각은 그대로 사용자에게 보이지 않습니다. 먼저 LLM이 읽을 수 있도록 프롬프트 안에 정리해 넣습니다. 프롬프트에는 보통 사용자 질문, 검색된 문서 내용, 답변 규칙이 함께 들어갑니다.

예를 들면 다음과 같은 지시가 포함될 수 있습니다.

• 제공된 문서만 근거로 답변하라

• 문서에 없는 내용은 모른다고 말하라

• 답변 끝에 사용한 출처를 표시하라

• 핵심을 먼저 말하고 필요한 설명을 덧붙여라

이렇게 하면 LLM은 자신의 일반 지식만으로 답하는 것이 아니라, 검색된 문서를 참고해 답변을 생성합니다. RAG의 핵심은 바로 여기에 있습니다. 모델을 새로 학습시키지 않아도, 외부 문서를 근거로 답변하게 만드는 것입니다.

6. 출처 표시: 사용자가 검증할 수 있어야 한다

문서 기반 AI에서 답변만큼 중요한 것이 출처입니다. 사용자는 AI가 왜 그런 답을 했는지 확인할 수 있어야 합니다. 그래서 각 답변에는 사용된 문서 조각을 연결해야 합니다.

출처에는 문서 제목, 섹션명, 작성일, 원문 링크, 청크 위치 같은 정보가 들어갈 수 있습니다. 책 기반 RAG라면 "3장 2절", 노트 기반 RAG라면 "프로젝트 회의 노트 / 2026-05-01"처럼 표시할 수 있습니다.

출처가 있으면 사용자는 답변을 신뢰할 수 있고, 필요할 때 원문으로 돌아가 더 자세한 내용을 확인할 수 있습니다. 또한 잘못된 답변이 나왔을 때 어떤 문서 조각이 문제였는지도 추적할 수 있습니다.

전체 흐름을 한 줄로 정리하기

RAG의 기본 흐름은 다음과 같습니다.

문서 수집 → 전처리 → 청킹 → 임베딩 → 벡터 DB 저장 → 질문 입력 → 관련 문서 검색 → 프롬프트 구성 → 답변 생성 → 출처 표시

이 흐름을 이해하면 RAG를 더 이상 막연한 기술로 보지 않게 됩니다. 각 단계는 독립된 기능이면서 동시에 서로 연결되어 있습니다. 좋은 답변은 좋은 검색에서 나오고, 좋은 검색은 좋은 청킹과 전처리에서 시작됩니다. 다음 장부터는 이 흐름의 핵심인 임베딩과 벡터 검색을 더 자세히 살펴보겠습니다.