RAG란? LLM에 외부 지식을 연결하는 핵심 기술 총정리

 

 

 

LLM(대규모 언어 모델)의 가장 큰 한계는 학습 데이터에 없는 정보를 모른다는 점입니다. ChatGPT에 우리 회사 내부 문서에 대해 물어봐도 답을 줄 수 없죠. 이 문제를 해결하는 기술이 바로 RAG(Retrieval-Augmented Generation)입니다.

RAG는 LLM이 답변을 생성하기 전에 관련 문서를 먼저 검색해서 참고하게 만드는 아키텍처입니다. 2026년 현재, RAG는 엔터프라이즈 AI 도입의 핵심 패턴으로 자리 잡았습니다. 이 글에서는 RAG 파이프라인을 처음부터 구축하는 방법을 단계별로 알려드리겠습니다.

RAG가 뭔가요?

RAG는 두 단계로 작동합니다. 먼저 사용자 질문과 관련된 문서 조각(chunk)을 벡터 검색으로 찾고, 이 문서를 LLM의 프롬프트에 함께 넣어서 답변을 생성합니다. "오픈북 시험"과 비슷합니다 — LLM이 답을 만들어내는 게 아니라, 실제 문서를 참고해서 답하는 구조입니다.

// RAG 파이프라인 흐름

사용자 질문
  → 임베딩 변환 (텍스트 → 벡터)
  → 벡터 DB 검색 (유사도 기반)
  → 관련 문서 조각 추출 (Top-K)
  → LLM 프롬프트에 컨텍스트로 삽입
  → LLM이 문서 기반 답변 생성
  → 출처(source) 함께 반환

RAG 파이프라인 핵심 구성 요소

구성 요소	역할	대표 도구 (2026)
Document Loader	PDF, Word, Notion 등 문서 로드	LangChain, LlamaIndex
Text Splitter	문서를 검색 가능한 크기로 분할	RecursiveCharacterTextSplitter
Embedding Model	텍스트를 벡터(숫자 배열)로 변환	OpenAI text-embedding-3, Cohere Embed v4
Vector DB	벡터를 저장하고 유사도 검색	Pinecone, Weaviate, Chroma, pgvector
LLM	검색된 문서 기반으로 답변 생성	Claude 4, GPT-5.4, Gemini 3.1

벡터 DB 선택 가이드

RAG에서 가장 중요한 선택 중 하나가 벡터 DB입니다. 프로젝트 규모와 요구사항에 따라 선택이 달라집니다.

벡터 DB	유형	가격	장점	추천 대상
Chroma	로컬/오픈소스	무료	설치 쉬움, 빠른 프로토타이핑	개인/PoC
pgvector	PostgreSQL 확장	무료	기존 PG 인프라 활용	PG 사용 팀
Pinecone	매니지드 클라우드	프리티어 있음	스케일링, 관리 불필요	스타트업/프로덕션
Weaviate	오픈소스/클라우드	오픈소스 무료	하이브리드 검색, GraphQL API	엔터프라이즈

 

실천 팁: 처음 시작한다면 Chroma + LangChain 조합을 추천합니다. 로컬에서 바로 돌릴 수 있고, 나중에 Pinecone이나 Weaviate로 마이그레이션하기도 쉽습니다.

RAG 파이프라인 구축 5단계

1단계. 문서 수집 및 전처리

PDF, Word, Notion, Confluence 등에서 문서를 수집합니다. 이 단계에서 불필요한 헤더/푸터 제거, 표 구조 보존, 이미지 내 텍스트 OCR 처리 등의 전처리가 필요합니다. 문서 품질이 RAG 성능의 70%를 결정합니다.

2단계. 청킹(Chunking) — 문서 분할

문서를 검색에 적합한 크기로 나눕니다. 일반적으로 500~1000 토큰 단위가 적당하며, 청크 간 20% 정도 오버랩을 두면 문맥 유실을 방지할 수 있습니다.

chunk_size=800, chunk_overlap=150  ← 대부분의 문서에 적합한 기본값

3단계. 임베딩 생성 및 벡터 DB 저장

각 청크를 임베딩 모델로 벡터화하고 벡터 DB에 저장합니다. OpenAI의 text-embedding-3-large(3,072차원)가 2026년 기준 가장 널리 쓰이며, 한국어 성능도 우수합니다. 비용은 100만 토큰당 약 $0.13입니다.

4단계. 검색(Retrieval) 최적화

단순 벡터 유사도 검색만으로는 한계가 있습니다. 실무에서는 하이브리드 검색(벡터 + 키워드 BM25)과 리랭킹(Cohere Rerank, Cross-Encoder)을 함께 사용해 정확도를 높입니다. Top-K는 보통 3~5개가 적당합니다.

5단계. 프롬프트 구성 및 답변 생성

검색된 문서 청크를 LLM 프롬프트의 컨텍스트로 삽입합니다. 이때 "제공된 문서에 없는 내용은 답하지 마세요"라는 지시를 포함해 할루시네이션을 방지합니다. 답변과 함께 출처(문서명, 페이지)를 반환하면 사용자 신뢰도가 올라갑니다.

실무에서 바로 쓰는 RAG 최적화 팁

메타데이터 필터링: 벡터 검색 전에 문서 유형, 작성일, 부서 등의 메타데이터로 검색 범위를 좁히면 정확도가 크게 향상됩니다. 예를 들어 "인사팀 규정"을 물어보면 인사팀 문서만 검색하는 식입니다.

Contextual Retrieval: 각 청크에 문서 전체 맥락을 요약한 프리픽스를 붙이는 기법입니다. "이 청크는 2026년 인사규정 중 연차 사용 관련 섹션입니다"와 같은 맥락 정보를 추가하면 검색 정확도가 최대 49% 향상된다는 연구 결과가 있습니다.

평가(Evaluation) 체계 구축: RAG 성능은 반드시 정량적으로 측정해야 합니다. Faithfulness(답변이 검색된 문서에 기반하는지), Relevancy(검색된 문서가 질문과 관련 있는지), Answer Correctness(답변이 정확한지) 3가지 지표를 RAGAS 같은 프레임워크로 자동 평가하세요.

자주 하는 실수

1. 청크 사이즈를 너무 크게 잡는 실수 — 5000토큰짜리 청크는 검색 정밀도를 떨어뜨립니다. 500~1000 토큰이 적정선입니다.

2. 임베딩 모델과 검색 모델 불일치 — 인덱싱할 때 쓴 임베딩 모델과 검색할 때 쓰는 모델이 반드시 같아야 합니다.

3. 전처리 무시 — PDF에서 표가 깨지거나, 헤더/푸터가 섞이면 검색 품질이 급격히 떨어집니다.

4. 프롬프트에 할루시네이션 방지 지시 누락 — "문서에 없으면 모른다고 답해"라는 지시가 없으면 LLM이 지어내기 시작합니다.

마무리

RAG는 2026년 현재 가장 실용적인 엔터프라이즈 AI 패턴입니다. 사내 문서, 고객 데이터, 기술 문서 등 어떤 데이터든 LLM과 연결할 수 있습니다. 처음에는 Chroma + LangChain으로 빠르게 PoC를 만들고, 검증된 후에 Pinecone이나 Weaviate로 스케일업하는 전략을 추천합니다.

핵심은 문서 전처리 품질과 검색 최적화입니다. 이 두 가지만 잘 잡으면 RAG 기반 AI 챗봇의 답변 품질이 크게 달라집니다.

 

이 글에 소개된 서비스와 도구는 작성 시점(2026년 3월) 기준이며, 업데이트에 따라 변경될 수 있습니다.