RAG 아키텍처 구현 가이드 2025: 프로덕션급 검색 증강 생성 시스템 구축

{</* resource-info */>}

LLM은 방대한 지식을 갖추고 있지만, 학습 데이터에 없는 최신 정볼나 기업 내 납부 문서에 대해서는 답변할 수 없습니다. RAG(Retrieval-Augmented Generation)는 외부 지식 베이스에서 관련 정보를 검색해 LLM의 문맥으로 제공함으로써 이 문제를 해결합니다. 이 글에서는 RAG 아키텍처의 기본부터 고급 기법, 프로덕션 배포까지 전 과정을 다룹니다.

RAG란? 검색 증강 생성 이해하기 #

기본 RAG 개념과 워크플로우 #

RAG는 2020년 Meta AI의 논문에서 처음 제안된 아키텍처로, 크게 3단계로 동작합니다:

인덱싱: 문서를 임베딩 벡터로 변환해 벡터 데이터베이스에 저장
검색: 사용자 질문과 유사한 벡터를 데이터베이스에서 검색
생성: 검색된 문맥을 LLM에 전달해 답변 생성

RAG가 중요한 이유: 할루시네이션 감소 #

LLM만 사용할 때의 사실 오류율은 15~~30%에 달하지만, RAG를 적용하면 3~~5%로 감소합니다. 특히 기술 문서, 의료, 법률 분야에서 정확성이 매우 중요할 때 RAG는 필수적입니다.

RAG vs 파인튜닝: 언제 어떤 것을 사용할까? #

구분	RAG	파인튜닝
지식 업데이트	실시간 가능	재학습 필요
구현 복잡도	중간	높음
비용	상대적으로 낮음	GPU 리소스 필요
사용 목적	최신 정보 기반 답변	모델 동작/말투 변경
데이터 필요량	소규모 문서셋	대규모 고품질 데이터

RAG와 파인튜닝을 동시에 적용하면 시너지 효과를 얻을 수 있습니다.

RAG 아키텍처 구성 요소 #

문서 수집 파이프라인 #

문서는 PDF, 웹 페이지, 마크다운, 데이터베이스 등 다양한 형태로 존재합니다. LangChain의 문서 로더(PyPDFLoader, WebBaseLoader, CSVLoader)로 형태별 수집이 가능합니다.

텍스트 분할과 청킹 전략 #

청크 크기는 RAG 성능에 가장 큰 영향을 미치는 하이퍼파라미터입니다.

청킹 전략	설명	적합한 상황
고정 크기	일정한 토큰 수로 분할	일반적인 문서
재귀적	문단 → 문장 순으로 분할	계층 구조 문서
의미 기반	의미적 유사도로 분할	긴 논문, 보고서
마크다운	헤더 기준으로 분할	구조화된 문서

일반적으로 청크 크기는 256~~1024 토큰, 오버랩은 10~~20%가 권장됩니다.

임베딩 모델 선택 #

모델	차원	MTEB 순위	특징
OpenAI text-embedding-3-large	3072	상위 5%	유료, 고성능
BGE-M3	1024	상위 10%	물로, 다국어
E5-Mistral	4096	상위 3%	LLM 기반
multilingual-e5	1024	상위 15%	다국어 지원

BGE-M3는 한국어 포함 100개 이상 언어를 지원하며 MTEB 리더보드에서 우수한 성능을 보여줍니다.

벡터 데이터베이스 저장 #

Chroma(프로토타입), Pinecone(클리우드), Milvus(대규모) 등을 선택합니다.

검색 메커니즘 #

밀집 검색: 의미적 유사도 기반
희소 검색: 키워드 매칭 기반(BM25)
하이브리드 검색: 둘의 결합 (alpha 파라미터로 가중치 조절)

재랭킹과 문맥 압축 #

처음 검색된 상위 k개 문서를 더 정밀한 재랭킹 모델(Cohere Rerank, BGE Reranker)로 다시 정렬합니다. 이 과정을 통해 검색 품질이 15~25% 향상됩니다.

단순 RAG(Naive RAG): 기초 구현 #

LangChain으로 기본 RAG 구현 #

from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.chains import RetrievalQA

# 1. 문서 로드와 분할
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter

loader = TextLoader("documents.txt")
docs = loader.load()
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(docs)

# 2. 임베딩과 저장
vectorstore = Chroma.from_documents(chunks, OpenAIEmbeddings())

# 3. 검색 + 생성
qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o"),
    retriever=vectorstore.as_retriever(search_kwargs={"k": 5})
)
result = qa.invoke({"query": "RAG가 무엇인가요?"})

Naive RAG의 한계와 실패 모드 #

질문이 청크와 정확히 일치하지 않음: 동의어나 개념적 변형에 취약
청크 경계에서 정보 분할: 연속된 내용이 다른 청크에 분리됨
관련 없는 문서 검색: 쿼리가 모호할 때 부정확한 검색
문맥 초과: 너무 많은 청크를 가져와 LLM의 컨텍스트 윈도우 초과

고급 RAG 기법 #

쿼리 재작성과 확장 #

사용자의 원본 질문을 더 검색에 적합한 형태로 변환합니다. Multi-Query 기법은 하나의 질문을 여러 관점에서 재구성해 검색 범위를 넓힙니다.

하이브리드 검색 (밀집 + 희소) #

retriever = vectorstore.as_retriever(
    search_type="mmr",  # Max Marginal Relevance
    search_kwargs={"k": 10, "lambda_mult": 0.5}
)

MMR(최대 한계 관련성)은 관련성과 다양성을 동시에 고려해 중복된 내용의 청크를 줄입니다.

문맥 압축과 재랭킹 #

from langchain.retrievers import ContextualCompressionRetriever
from langchain_community.document_transformers import EmbeddingsRedundantFilter

compression_retriever = ContextualCompressionRetriever(
    base_retriever=retriever,
    base_compressor=EmbeddingsRedundantFilter(embeddings=OpenAIEmbeddings())
)

멀티 쿼리 검색 #

하나의 질문을 5개의 서로 다른 표현으로 확장해 각각 검색한 후 결과를 통합합니다.

부모 문서 검색 #

작은 청크로 검색하고, 해당 청크가 속한 원본 큰 문서(부모)를 LLM에 전달합니다. 검색 정확도와 문맥의 완전성을 동시에 확보합니다.

문장 창 검색 #

검색된 문장 앞뒤 N개 문장을 함께 가져와 문맥을 풍부하게 합니다.

HyDE (Hypothetical Document Embedding) #

사용자 질문으로 가상의 이상적인 답변을 LLM이 생성하고, 이 답변을 임베딩하여 검색에 사용합니다. 의미적 검색 품질이 20% 이상 향상됩니다.

모듈형 RAG와 에이전틱 RAG #

Self-RAG: 반성적 검색 #

LLM이 생성 과정에서 스스로 “추가 정보가 필요한가?“를 판단하고 필요하면 검색을 반복합니다. 토큰별로 Retrieve, Generate, Critique 동작을 결정합니다.

Corrective RAG (CRAG) #

검색된 문서의 관련성을 평가하여 관련성이 낮으면 웹 검색으로 대체합니다.

에이전틱 RAG with 도구 사용 #

ReAct 에이전트 패턴으로 LLM이 검색 외에도 계산기, API 호출, 데이터베이스 쿼리 등 다양한 도구를 활용합니다.

단계별: 프로덕션 RAG 시스템 구축 #

단계 1: 데이터 수집과 전처리 #

원본 문서를 수집하고 중복 제거, 형식 통일, 개인정보 마스킹을 수행합니다.

단계 2: 임베딩 모델 선택 #

OpenAI 임베딩은 고성능이지만 비용이 발생합니다. 물로 대안으로 BGE-M3가 2025년 기준 최고의 오픈소스 임베딩 모델입니다.

단계 3: 청킹 전략 최적화 #

청크 크기를 256, 512, 1024 토큰으로 각각 테스트하고 검색 정확도를 비교합니다. 의료나 법률 분야에서는 작은 청크(256~384)가 더 효과적입니다.

단계 4: 벡터 데이터베이스 설정 #

프로토타입: Chroma → 프로덕션: Pinecone/Zilliz/Milvus로 마이그레이션합니다.

단계 5: 검색 튜닝과 평가 #

Top-k(5~~20), 유사도 임계값(0.5~~0.8), 하이브리드 가중치를 조정합니다.

단계 6: LLM 선택과 프롬프트 엔지니어링 #

시스템 프롬프트에 “검색된 문맥만 사용하여 답변하세요. 문맥에 없는 내용은 ‘확실하지 않습니다’라고 답변하세요"와 같은 지시를 포함합니다.

단계 7: 엔드투엔드 테스트와 배포 #

LangSmith나 Langfuse로 추적하면서 검색 품질과 생성 품질을 모니터링합니다.

RAG 평가 프레임워크 #

검색 평가 지표 #

Recall@k: 관련 문서가 상위 k개에 포함된 비율
MRR(Mean Reciprocal Rank): 첫 관련 문서의 순위 역수 평균
NDCG: 순위별 관련성 가중 평균

생성 평가 지표 #

Faithfulness: 생성 내용이 검색 문맥에 기반하는가
Answer Relevance: 답변이 질문과 관련 있는가

RAGAS 프레임워크 #

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy

result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, answer_relevancy]
)

RAGAS는 RAG 시스템의 종합적인 평가를 자동화하는 오픈소스 프레임워크입니다.

RAG 성능 최적화 #

최적화 기법	효과
청크 크기 조정	검색 정확도 10~20% 향상
Top-k 조정 (5→10)	재현율 향상
재랭킹 추가	정확도 15~25% 향상
캐싱 (질문→답변)	지연 시간 50% 감소
하이브리드 검색	종합 검색 품질 10~15% 향상

로컬 및 오픈소스 컴포넌트로 RAG 구축 #

Ollama 임베딩 + LLM #

from langchain_community.embeddings import OllamaEmbeddings
from langchain_community.llms import Ollama

embeddings = OllamaEmbeddings(model="nomic-embed-text")
llm = Ollama(model="llama3.1:8b")

BGE 임베딩과 Ollama LLM, Chroma 벡터 DB 조합으로 완전한 물로 RAG 시스템을 구축할 수 있습니다.

RAG 도구와 프레임워크 비교 #

프레임워크	특징	적합한 상황
LangChain	가장 많은 통합, 유연함	커스터마이징이 많은 경우
LlamaIndex	RAG에 특화, 고급 인덱싱	복잡한 문서 처리
Haystack	엔터프라이즈 지향	파이프라인 기반 워크플로우
RAGFlow	딥 도큐먼트 이해	복잡한 테이블, 이미지 문서

자주 묻는 질문 #

RAG와 파인튜닝의 차이점은 무엇인가요?

RAG는 외부 지식 베이스에서 정보를 검색해 답변에 활용합니다. 파인튜닝은 모델의 가중치를 직접 수정해 지식을 내재화합니다. RAG는 실시간 정보 업데이트가 가능하고, 파인튜닝은 모델의 말투와 동작 방식을 바꿀 때 유용합니다.

RAG에 가장 적합한 임베딩 모델은 무엇인가요?

OpenAI text-embedding-3-large가 최고의 성능을 보이지만 비용이 발생합니다. 물로 대안으로 BGE-M3가 MTEB 리더보드 상위권이며 한국어 포함 다국어 지원이 우수합니다.

RAG 시스템 성능을 어떻게 평가하나요?

RAGAS 프레임워크로 Faithfulness, Answer Relevancy, Context Precision, Context Recall 4가지 지표를 종합적으로 측정합니다. 검색 품질은 Recall@k와 MRR로 평가합니다.

로컬 LLM으로 RAG를 구현할 수 있나요?

Ollama로 Llama 3.1 8B와 nomic-embed-text를 실행하고, Chroma를 벡터 DB로 사용하면 완전히 로컬 환경에서 RAG를 구현할 수 있습니다. GPU VRAM 16GB면 충분합니다.

에이전틱 RAG는 일반 RAG와 어떻게 다른가요?

일반 RAG는 한 번의 검색 후 답변을 생성합니다. 에이전틱 RAG는 LLM이 스스로 “추가 검색이 필요한가?“를 판단하고 여러 단계의 검색과 추론을 반복합니다. Self-RAG와 CRAG가 대표적인 예입니다.