RAG 개념과 아키텍처

들어가며

ChatGPT나 Claude 같은 챗봇을 쓰다 보면 아래와 같은 답변을 받을 때가 있습니다.

Q: 우리 회사 신입사원 교육 자료 어디 있지?

A: 죄송합니다. 귀하의 회사 내부 정보는 알 수 없습니다.

Q: 최신 iPhone 스펙 알려줘

A: 학습 시점 이후의 정보는 제공할 수 없습니다.

LLM은 학습한 데이터만 알고 있기 때문에 사내 문서나 학습 이후의 정보에는 답하지 못합니다. 이 한계를 보완하는 방식이 RAG(Retrieval-Augmented Generation)입니다.

RAG는 질문이 들어올 때 관련 문서를 먼저 검색하고, 그 내용을 근거로 답변을 생성합니다.

이 시리즈에서는 RAG의 기본 개념에서 시작해 실제로 동작하는 시스템을 구축하는 과정까지 단계별로 정리합니다.

1. RAG란

RAG는 Retrieval-Augmented Generation의 줄임말로, 한국어로는 "검색 증강 생성"이라고 옮깁니다.

Retrieval(검색): 질문과 관련된 정보를 찾아옵니다.
Augmented(증강): 찾아온 정보를 모델의 입력에 덧붙입니다.
Generation(생성): 덧붙인 정보를 바탕으로 답변을 만듭니다.

RAG 기본 개념 (RAG = 검색 + 답변 생성)

일반 LLM과 RAG의 차이

시험에 비유하면 두 방식의 차이가 분명해집니다.

일반 LLM (ChatGPT): 교과서를 외워서 시험을 보는 학생

학습한 내용은 잘 알지만
최신 뉴스나 개인 문서는 알지 못합니다.

RAG: 시험장에서 자료를 찾아볼 수 있는 학생

문제가 나오면 관련 자료부터 찾고
그 자료를 근거로 답안을 작성합니다.

2. RAG가 필요한 이유

일반 LLM의 한계

1. 지식 시점의 한계

AI: "학습 시점까지의 내용만 알고 있어요. 그 이후는 몰라요 😅"

2. 개인/기업 정보 부족

AI: "당신 회사 내부 자료는 제가 학습한 적이 없어서..."

3. 할루시네이션 (헛소리) 문제

AI: "확실하지 않지만 아마도... (그럴듯한 거짓말)"

기존 AI의 한계 (LLM이 답하기 어려운 경우)

RAG로 해결되는 문제

최신 정보: 최신 문서를 검색해서 사용할 수 있습니다.
개인·사내 정보: 내 문서와 회사 자료를 활용할 수 있습니다.
정확성: 실제 문서를 근거로 답하므로 근거 없는 답변이 줄어듭니다.
출처 확인: 답변이 어느 문서에서 왔는지 확인할 수 있습니다.

RAG의 장점 (RAG로 해결되는 문제)

3. RAG의 동작 방식

기본 흐름

RAG 작동 과정 (RAG의 기본 동작 과정)

단계별 흐름

Step 1: 질문 입력

사용자 질문: "Docker 컨테이너 만드는 방법은?"

Step 2: 관련 문서 검색

시스템: Docker 관련 문서들을 데이터베이스에서 찾아봄
- docker_tutorial.md
- container_guide.pdf  
- dockerfile_examples.txt

Step 3: 컨텍스트 구성

AI에게 전달되는 내용:
"다음 문서들을 참고해서 답변해줘:
[문서 내용들...]

질문: Docker 컨테이너 만드는 방법은?"

Step 4: 답변 생성

AI: "제공된 문서에 따르면, Docker 컨테이너는 다음과 같이 만들 수 있습니다..."

4. RAG 시스템 아키텍처

전체 구조

RAG 시스템은 준비 단계(오프라인) 와 실행 단계(온라인) 로 나뉩니다.

준비 단계(오프라인): 문서를 미리 처리해서 검색할 수 있는 상태로 만듭니다.
실행 단계(온라인): 사용자 질문이 들어오면 검색하고 답변합니다.

RAG 아키텍처 전체 (RAG 시스템의 전체 아키텍처)

준비 단계 (Document Processing Pipeline)

1단계: 문서 수집

📁 문서들 모으기
- PDF 파일
- Word 문서  
- 웹페이지
- 텍스트 파일

2단계: 전처리

🧹 문서 정리하기
- 불필요한 내용 제거
- 텍스트만 추출
- 인코딩 통일

3단계: 청킹 (Chunking)

✂️ 문서를 적당한 크기로 나누기
긴 문서 → 여러 개의 작은 덩어리들
(예: 1000자씩 나누기)

4단계: 임베딩 (Embedding)

🔢 텍스트를 숫자 벡터로 변환
"안녕하세요" → [0.1, 0.5, 0.2, 0.8, ...]
(의미가 비슷한 텍스트는 가까운 벡터가 됨)

5단계: 저장

💾 벡터 데이터베이스에 저장
검색할 수 있도록 인덱싱

문서 처리 파이프라인 (문서 처리 과정)

실행 단계 (Query Processing Pipeline)

1단계: 질문 분석

사용자 질문 → 벡터로 변환
"Git 사용법" → [0.3, 0.7, 0.1, 0.9, ...]

2단계: 유사도 검색

질문 벡터와 문서 벡터들을 비교
가장 비슷한 문서들 찾기 (보통 3-5개)

3단계: 컨텍스트 구성

질문 + 찾은 문서들 = 완전한 프롬프트

4단계: AI 모델 호출

완성된 프롬프트를 AI에게 전달
AI가 문서 기반으로 답변 생성

5단계: 결과 반환

답변 + 참고한 문서 출처까지 함께 제공

쿼리 처리 과정 (질문 처리 과정)

5. RAG의 핵심 컴포넌트

검색기 (Retriever)

역할: 질문과 관련된 문서를 찾습니다.
기술: 벡터 유사도 검색, 키워드 검색 등
참고: 관련 없는 문서를 가져오면 LLM이 엉뚱한 답변을 만들기 때문에 검색 품질이 전체 품질을 좌우합니다.

지식 베이스 (Knowledge Base)

역할: 검색 대상 문서를 저장합니다.
기술: 벡터 데이터베이스 (Chroma, Pinecone 등)

생성기 (Generator)

역할: 검색된 문서를 바탕으로 자연어 답변을 생성합니다.
기술: GPT, Claude, Llama 등의 대화형 LLM

프롬프트 설계

역할: 검색된 문서를 어떤 지시와 함께 LLM에 전달할지 정합니다.
예시: "다음 문서를 참고해서 친절하게 설명해줘"
참고: 같은 문서라도 프롬프트에 따라 답변 품질이 크게 달라집니다.

RAG 핵심 컴포넌트 (RAG 시스템의 주요 구성 요소)

6. 다른 방식과의 비교

Fine-tuning과의 차이

구분	Fine-tuning	RAG
비용	높음	보통
시간	오래 걸림	빠름
업데이트	재학습 필요	문서만 추가하면 됨
투명성	근거를 알기 어려움	출처 확인 가능
적합한 용도	말투·형식·특정 작업 방식 학습	문서 속 최신·사내 지식 참조

일반 검색엔진과의 차이

구분	검색엔진	RAG
결과	링크 목록	자연어 답변
문서 확인	사용자가 직접 확인	검색된 문서를 LLM이 종합해서 정리

마무리

1편에서는 RAG의 개념, 필요한 이유, 동작 방식과 아키텍처를 정리했습니다.

RAG = 검색 + 답변 생성
최신 정보 부족, 사내 정보 접근 불가 같은 LLM의 한계를 보완합니다.
문서를 근거로 답하므로 답변의 신뢰도를 높일 수 있습니다.

다음 2편에서는 RAG 구현에 널리 쓰이는 LangChain을 정리합니다. LangChain이 무엇이고 어떤 컴포넌트로 구성되는지, 코드 예제와 함께 살펴봅니다.

Sourcetree 기본 사용법: Clone, Commit, Push (2편)RAG 시리즈 (2편): LangChain으로 RAG 구현하기