AI/LLM

RAG 구현 가이드 — 검색 증강 생성의 실전 적용

한 줄 요약: RAG(검색 증강 생성)는 LLM이 외부 지식을 참조해 정확한 답변을 생성하는 아키텍처로, 할루시네이션을 줄이고 최신 정보를 반영하는 가장 실용적인 방법이다. 파인튜닝 없이 LLM에 도메인 지식을 주입하는 가장 효율적인 방법이 RAG다. RAG(Retrieval-Augmented Generation) 은 LLM이 답변할 때 외부 데이터를 검색해서 참조하는 패턴입니다.

by Lee발행: 2026-03-29

한 줄 요약: RAG(검색 증강 생성)는 LLM이 외부 지식을 참조해 정확한 답변을 생성하는 아키텍처로, 할루시네이션을 줄이고 최신 정보를 반영하는 가장 실용적인 방법이다.

파인튜닝 없이 LLM에 도메인 지식을 주입하는 가장 효율적인 방법이 RAG다. 문서를 벡터로 변환하고, 질문과 관련된 문서를 검색해 LLM 프롬프트에 넣는 구조다. 이 가이드는 RAG 파이프라인의 설계부터 프로덕션 최적화까지 정리한다.

RAG란?

RAG(Retrieval-Augmented Generation)은 LLM이 답변할 때 외부 데이터를 검색해서 참조하는 패턴입니다. 모델을 재학습하지 않고도 최신 정보나 내부 문서 기반 답변이 가능해집니다.

RAG 파이프라인은 크게 3단계로 구성된다. 1) 인덱싱: 문서를 청크로 분할하고, 각 청크를 임베딩 모델로 벡터로 변환해 벡터 DB에 저장한다. 2) 검색: 사용자 질문을 벡터로 변환하고, 코사인 유사도로 관련 청크를 검색한다. 3) 생성: 검색된 청크를 LLM 프롬프트의 컨텍스트로 넣어 답변을 생성한다.

LangChain으로 기본 RAG 구현
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_chroma import Chroma

# 1. 문서 분할
splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
chunks = splitter.split_documents(documents)

# 2. 벡터 DB에 저장
vectorstore = Chroma.from_documents(chunks, OpenAIEmbeddings())

# 3. 검색 + 생성
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
chain = RetrievalQA.from_chain_type(llm=ChatOpenAI(), retriever=retriever)
result = chain.invoke("API 인증은 어떻게 구현하나요?")

청크 크기는 RAG 성능에 큰 영향을 미친다. 너무 작으면(200토큰 이하) 문맥이 손실되고, 너무 크면(2000토큰 이상) 노이즈가 섞인다. 일반적으로 500~1000 토큰이 최적이며, 코드 문서는 함수 단위, 기술 문서는 섹션 단위로 분할하는 것이 효과적이다.

기본 아키텍처

RAG의 흐름: 문서 → 청킹 → 임베딩 → 벡터 DB 저장 → 질문 시 유사 문서 검색 → LLM에 컨텍스트로 전달 → 답변 생성. 벡터 DB로는 Pinecone, Weaviate, Chroma 등을 사용합니다.

실전 팁

RAG 품질을 높이는 핵심: 청킹 전략(너무 크면 노이즈, 너무 작으면 맥락 손실), 하이브리드 검색(벡터 + 키워드), 리랭킹(검색 결과 재정렬).

벡터 DB 선택 가이드

Pinecone: 완전 관리형, 스케일링 자동화, 필터링 강력. 프로덕션 SaaS에 적합. Chroma: 로컬 개발에 최적, 임베디드 모드로 별도 서버 없이 사용 가능. pgvector: PostgreSQL 확장, 기존 DB 인프라에 벡터 검색 추가. Weaviate: 하이브리드 검색(벡터+키워드) 기본 지원.

RAG 성능 최적화 전략

하이브리드 검색: 벡터 유사도만으로는 키워드 매칭이 약하다. BM25(키워드 검색) + 벡터 검색을 결합하면 정확도가 15~30% 향상된다. 리랭킹: 초기 검색 결과를 Cross-Encoder 모델로 재정렬하면 상위 문서의 관련성이 높아진다. 쿼리 확장: 사용자 질문을 LLM으로 재작성하거나, 여러 각도의 쿼리를 생성해 검색 커버리지를 넓힌다.

주의: RAG는 검색 품질에 전적으로 의존한다. '가비지 인, 가비지 아웃' — 소스 문서가 부정확하거나 오래됐으면 LLM 답변도 부정확하다. 문서 최신성 관리와 인덱스 갱신 주기를 반드시 설계해야 한다.

자주 묻는 질문

RAG 구현 가이드, 한 줄로 정리하면 어떻게 되나요?

RAG는 모델을 재학습하지 않고도 외부 문서를 검색해 참조시켜, 할루시네이션을 줄이고 최신·내부 지식을 답변에 반영하는 패턴입니다. 동작은 인덱싱(문서를 청크로 쪼개 임베딩해 벡터 DB 저장) → 검색(질문을 벡터로 바꿔 유사 청크 찾기) → 생성(찾은 청크를 LLM 프롬프트 컨텍스트로 넣어 답변)의 3단계로 끝납니다. 결국 답변 품질은 모델보다 검색 품질에 달려 있어서, 청크 크기를 500~1000 토큰으로 맞추고 벡터+키워드 하이브리드 검색과 리랭킹을 더하는 것이 핵심입니다.

실무에서 처음 도입할 때 가장 먼저 확인할 것은 무엇인가요?

청크 크기와 벡터 DB 선택, 이 두 가지를 먼저 정하시길 권합니다. 본문에서 다뤘듯이 청크는 보통 500~1000 토큰이 최적이지만, 코드 문서는 함수 단위, 기술 문서는 섹션 단위로 자르는 편이 검색 정확도가 더 좋습니다. 벡터 DB는 처음 검증 단계라면 별도 서버 없이 임베디드로 돌아가는 Chroma로 시작하고, 기존에 PostgreSQL을 쓰고 있다면 pgvector 확장으로 인프라를 늘리지 않는 것이 비용 면에서 유리합니다. 그리고 OpenAI 임베딩 API를 쓴다면 문서량에 비례해 임베딩 호출 비용이 발생하므로, 인덱싱 대상 문서 분량을 미리 계산해 한 달 비용을 추정해두는 것이 좋습니다. 본격 확장은 그 뒤 Pinecone 같은 관리형으로 옮겨도 늦지 않습니다.

가장 자주 발생하는 실수나 함정은 무엇인가요?

가장 근본적인 함정은 검색 단계를 소홀히 한 채 LLM 프롬프트만 다듬는 것입니다. 본문 주의 박스의 가비지 인, 가비지 아웃이 핵심인데, 소스 문서가 오래됐거나 부정확하면 아무리 좋은 모델을 써도 답변이 틀립니다. 문서 최신성 관리와 인덱스 갱신 주기를 처음부터 설계하세요. 두 번째 함정은 청킹 실수입니다. 200토큰 이하로 너무 잘게 쪼개면 문맥이 끊기고, 2000토큰을 넘기면 노이즈가 섞여 검색 정확도가 떨어집니다. 세 번째는 벡터 유사도만 믿는 것인데, 코드명이나 고유명사 같은 키워드 매칭이 약해 BM25 키워드 검색을 결합한 하이브리드 검색과 리랭킹을 추가하면 정확도가 크게 올라갑니다.

다른 대안과 비교했을 때 어떤 상황에 적합한가요?

RAG는 자주 바뀌는 내부 문서나 최신 정보를 모델에 물려야 할 때 가장 적합합니다. 사내 위키, 제품 매뉴얼, 고객 응대 지식베이스처럼 내용이 계속 갱신되는 자료를 답변에 반영해야 한다면 문서만 다시 인덱싱하면 되니 RAG가 정답입니다. 반대로 독자적인 말투나 고정된 출력 형식, 도메인 특유의 표현 자체를 모델이 체화해야 하는 경우라면 RAG보다 파인튜닝이 맞습니다. 또 지식 주입이 아니라 단순한 형식 변환이나 분류처럼 검색이 필요 없는 작업이라면 RAG는 과한 설계이고, 잘 짠 프롬프트와 few-shot 예제만으로 충분합니다. 벡터 DB도 검증 단계엔 Chroma, 기존 PostgreSQL이 있으면 pgvector, 대규모 프로덕션엔 Pinecone처럼 단계에 맞춰 고르시면 됩니다.

더 깊게 공부하려면 어떤 자료를 보면 좋을까요?

본문 코드에 쓴 LangChain의 공식 문서(Retrieval 섹션)를 먼저 따라가 보시길 권합니다. 청킹, 임베딩, 리트리버 설정이 예제와 함께 잘 정리돼 있어 코드를 바로 변형해볼 수 있습니다. 검색 품질을 한 단계 올리고 싶다면 하이브리드 검색의 BM25 알고리즘과 Cross-Encoder 리랭킹을 키워드로 파보세요. 임베딩 모델 선택이 고민이라면 Hugging Face의 MTEB 리더보드에서 언어별·작업별 임베딩 성능 순위를 확인할 수 있고, 한국어 문서가 많다면 다국어 임베딩 모델의 한국어 점수를 꼭 비교하시는 것이 좋습니다.

RAG검색증강벡터DB임베딩LLM