RAG란 무엇인가 — 검색 증강 생성의 핵심 개념

RAG란 무엇인가 — 검색 증강 생성의 핵심 개념

LLM(대형 언어 모델)은 놀라운 능력을 갖추고 있지만, 치명적인 약점이 하나 있습니다. 바로 학습 데이터의 한계입니다. GPT-4는 2023년까지의 정보만 알고 있고, 사내 문서나 최신 기술 명세는 전혀 모릅니다. RAG(Retrieval-Augmented Generation)는 이 문제를 해결하기 위해 등장한 아키텍처 패턴입니다.

RAG의 핵심 아이디어

RAG는 세 단계로 동작합니다.

1. 검색 (Retrieval) 사용자 질문을 벡터로 변환한 뒤, 문서 데이터베이스에서 의미적으로 가장 유사한 청크(chunk)를 찾아옵니다.

2. 증강 (Augmentation) 검색된 문서를 LLM 프롬프트에 컨텍스트로 삽입합니다. "다음 문서를 참고해서 답하시오: [문서 내용]"

3. 생성 (Generation) LLM이 제공된 컨텍스트를 바탕으로 답변을 생성합니다. 모델이 직접 알고 있는 것이 아니라, 제공된 문서를 근거로 답합니다.

사용자 질문
    ↓
임베딩 모델 (질문 → 벡터)
    ↓
벡터 DB (유사 문서 검색)
    ↓
프롬프트 구성 (질문 + 검색 결과)
    ↓
LLM (최종 답변 생성)

왜 파인튜닝 대신 RAG인가?

파인튜닝도 모델에 지식을 주입하는 방법이지만, RAG와는 근본적으로 다릅니다.

파인튜닝은 스타일이나 포맷을 바꾸는 데 적합하고, RAG는 지식을 주입하는 데 적합합니다.

RAG의 한계도 알아야 한다

RAG가 만능은 아닙니다. 자주 마주치는 실패 케이스를 정리하면 다음과 같습니다.

• 검색 실패: 관련 문서가 있어도 임베딩 유사도가 낮아 못 찾는 경우
• 컨텍스트 넘침: 검색 결과가 너무 많아 LLM 컨텍스트 윈도우 초과
• 충돌하는 정보: 검색된 문서들이 서로 모순된 내용을 담고 있을 때
• Hallucination 지속: 컨텍스트가 불충분하면 여전히 환각이 발생

이 시리즈에서는 각 단계별로 이런 문제를 어떻게 해결하는지 상세히 다룹니다.

이 시리즈에서 배우는 것

• EP 02: 벡터 DB 선택 — Pinecone, Weaviate, pgvector 비교
• EP 03: 청킹 전략 — 문서를 어떻게 쪼개야 검색이 잘 되나
• EP 04: RAGAS로 RAG 파이프라인 성능 평가하기

RAG는 LLM 애플리케이션의 표준 아키텍처가 되었습니다. 제대로 이해하고 구현할 수 있도록 처음부터 차근차근 따라가 봅시다.

가장 단순한 RAG, 코드로 보기

개념을 코드 한 조각으로 압축하면 다음과 같습니다. (의사코드)

# 1) 사전 준비: 문서를 청크로 쪼개 임베딩 → 벡터 DB에 저장
chunks = split(documents)            # 청킹
vectors = embed(chunks)              # 임베딩 모델
db.upsert(vectors, chunks)

# 2) 질의 시점
q_vec = embed(user_question)
ctx = db.search(q_vec, top_k=4)      # 의미 유사 청크 검색
answer = llm.generate(
    system="다음 컨텍스트만 근거로 답하라. 모르면 모른다고 답하라.",
    prompt=f"[컨텍스트]\n{ctx}\n\n[질문]\n{user_question}"
)

핵심은 마지막 system 지시 — **"컨텍스트 밖의 내용은 지어내지 말라"**가 환각을 줄이는 첫 번째 안전장치입니다.

RAG가 필요한 경우 vs 아닌 경우

자주 묻는 질문 (FAQ)

Q. RAG를 쓰면 환각이 완전히 사라지나요? 아닙니다. 검색이 엉뚱한 문서를 가져오거나 컨텍스트가 불충분하면 여전히 환각이 발생합니다. 검색 품질(청킹·임베딩·리랭킹)이 곧 답변 품질입니다.

Q. 파인튜닝과 RAG를 같이 쓸 수 있나요? 네. 말투·도메인 적응은 파인튜닝으로, 사실·지식 주입은 RAG로 — 둘은 경쟁이 아니라 보완 관계입니다.

에디터 노트 — 현장에서는

RAG를 도입한 팀들을 보면, 실패의 8할은 '검색이 안 돼서'가 아니라 평가 체계를 안 만들어서입니다. 데모는 잘 되는데 운영에서 답변 품질이 들쭉날쭉한 원인을 못 찾습니다. 첫 스프린트부터 골든 질문셋 20~30개를 만들어 회귀 테스트처럼 돌리세요. 청킹·임베딩 모델을 바꿀 때마다 이 점수가 오르는지 확인하는 것 — 그게 RAG 운영의 절반입니다. 화려한 아키텍처보다 '측정 가능한 루프'가 먼저입니다.