STEP 3 - RAG란 무엇인가

RAG란 무엇인가 - 개념과 전체 아키텍처 이해하기

지난 글에서 LLM은 확률적으로 다음 단어를 예측해 문장을 만들다 보니 Hallucination과 Knowledge Cutoff라는 한계를 가진다는 걸 정리했습니다. 이번 글에서는 이 한계를 보완하기 위해 등장한 RAG(Retrieval-Augmented Generation)의 개념과 전체 동작 구조를 정리합니다.

1. RAG의 핵심 아이디어

RAG를 한 문장으로 요약하면 "질문에 답하기 전에, 관련된 문서를 먼저 찾아서 모델에게 함께 넘겨주는 방식"입니다. 이름 그대로 세 단어로 쪼개보면 이해가 쉽습니다.

구성	의미
Retrieval (검색)	질문과 관련 있는 문서를 외부 저장소에서 찾아온다
Augmented (증강)	찾아온 문서를 프롬프트에 추가해 모델에게 넘긴다
Generation (생성)	모델이 그 문서를 참고해서 답변을 생성한다

즉 모델 자체를 재학습시키는 게 아니라, 답변을 만들기 직전에 "참고 자료"를 붙여주는 방식입니다. 시험을 볼 때 아무것도 안 보고 암기한 것만으로 답을 쓰는 게 기존 LLM이라면, RAG는 오픈북 시험처럼 관련 자료를 펼쳐놓고 답을 쓰는 것에 비유할 수 있습니다.

2. 왜 이 방식이 Hallucination과 Knowledge Cutoff를 해결하는가

지난 글에서 다룬 두 가지 문제를 다시 떠올려보면, RAG가 왜 효과적인지 명확해집니다.
[기존 LLM]
질문 → 학습된 패턴만으로 답변 생성 → 모르면 그럴듯하게 지어냄(Hallucination)
→ 최신 정보는 아예 모름(Knowledge Cutoff)
[RAG]
질문 → 관련 문서 검색 → 문서 + 질문을 함께 모델에 전달 → 문서를 근거로 답변 생성

모델이 "기억"에만 의존하지 않고, 실제 문서를 눈앞에 두고 답하기 때문에 존재하지 않는 내용을 지어낼 확률이 크게 줄어듭니다. 또한 검색 대상 문서를 최신 데이터로 계속 갱신하면, 모델을 재학습시키지 않고도 최신 정보에 대응할 수 있습니다.

3. RAG의 전체 아키텍처

RAG는 크게 두 단계로 나뉩니다. 문서를 미리 준비해두는 단계와, 실제 질문이 들어왔을 때 답변을 생성하는 단계입니다.

3-1. 사전 준비 단계 (Indexing)
원본 문서(PDF, 위키, DB 등)
↓ 1. Chunking (문서를 작은 단위로 분할)
↓ 2. Embedding (텍스트를 벡터로 변환)
↓ 3. Vector DB에 저장

서비스에 사용할 문서(사내 위키, 매뉴얼, FAQ 등)를 미리 작은 단위로 쪼개고, 각 조각을 벡터(숫자 배열)로 변환해서 벡터 데이터베이스에 저장해둡니다. 이 작업은 질문이 들어오기 전에 미리 끝내두는 준비 과정입니다.

3-2. 질의응답 단계 (Retrieval + Generation)
사용자 질문
↓ 1. 질문도 동일한 방식으로 Embedding
↓ 2. Vector DB에서 유사도 높은 문서 조각 검색
↓ 3. 검색된 문서 + 원래 질문을 하나의 프롬프트로 조합
↓ 4. LLM에 전달 → 문서를 근거로 답변 생성

사용자가 질문을 입력하면, 그 질문 역시 벡터로 변환해서 미리 저장해둔 문서 벡터들과 유사도를 비교합니다. 가장 관련 있는 문서 조각 몇 개를 찾아서, "이 문서를 참고해서 다음 질문에 답해줘"라는 형태로 LLM에게 넘기는 것이 핵심입니다.

4. 간단한 예시로 보는 RAG

사내 휴가 정책을 묻는 챗봇을 예로 들어보겠습니다.
[RAG 적용 전]
질문: "우리 회사 연차는 며칠이야?"
LLM: 학습 데이터에 없는 내용이라 일반적인 답변을 지어내거나
"회사마다 다릅니다" 같은 원론적인 답변만 가능
[RAG 적용 후]
질문: "우리 회사 연차는 며칠이야?"

질문을 벡터로 변환
사내 규정 문서 중 "연차" 관련 조각을 벡터 DB에서 검색
검색된 조각: "입사 1년 미만은 월 1일, 1년 이상은 15일 부여..."
LLM에 전달: "다음 문서를 참고해서 질문에 답해줘: [검색된 문서] / 질문: 연차는 며칠이야?"
LLM 답변: "입사 1년 이상이시면 연차는 15일입니다."

같은 모델이라도 참고할 문서를 함께 넘겨주는 것만으로 정확도가 완전히 달라지는 걸 확인할 수 있습니다.

5. Fine-tuning과 비교

지난 글에서 언급했던 Fine-tuning과 비교하면 RAG의 장점이 더 뚜렷해집니다.

구분	Fine-tuning	RAG
지식 갱신	재학습 필요	문서만 교체하면 즉시 반영
비용	학습 비용 큼	검색 인프라 구축 비용 (상대적으로 낮음)
최신성	재학습 전까지 반영 안 됨	문서 업데이트 즉시 반영
근거 추적	모델이 왜 그렇게 답했는지 알기 어려움	어떤 문서를 참고했는지 확인 가능

특히 "근거 추적이 가능하다"는 점이 실무에서 큰 장점입니다. RAG는 답변과 함께 "어떤 문서를 참고했는지"도 함께 보여줄 수 있어서, 사용자가 답변의 신뢰도를 스스로 판단할 수 있습니다.

6. 정리

• RAG는 질문에 답하기 전 관련 문서를 검색(Retrieval)해서, 이를 프롬프트에 추가(Augmented)한 뒤 모델이 답변을 생성(Generation)하는 구조입니다.
• 모델을 재학습하지 않고도 문서만 갱신하면 최신 정보에 대응할 수 있어 Knowledge Cutoff 문제를 해결합니다.
• 실제 문서를 근거로 답변하기 때문에 Hallucination을 크게 줄일 수 있고, 답변의 출처도 함께 제시할 수 있습니다.

지금까지는 개념 위주로 살펴봤다면, 다음 글부터는 실제로 이 구조를 구현하는 데 필요한 첫 번째 기술 요소인 임베딩(Embedding), 즉 텍스트를 벡터로 바꾸는 원리를 다뤄보겠습니다.