RAG (Retrieval-Augmented Generation) 완벽 가이드

기초 개념부터 고급 구현까지

들어가며

현재 LLM 기반 시스템 아키텍처 중에서 RAG(Retrieval-Augmented Generation)는 AI 실무자라면 반드시 알아야 하는 핵심 아키텍처로 자리 잡았다.
RAG는 2020년 NeurIPS/Meta 연구에서 처음 소개됐는데, 밀집 신경망 리트리버(dense neural retriever)와 seq2seq 생성기를 결합해 지식 집약적 쿼리에 답변하는 방식을 제안했다.
그 이후 산업계와 연구계 모두에서 널리 활용되며 다양한 변형과 개선이 이루어졌다.

RAG란 무엇이고, 어떤 문제를 해결하는가?

RAG는 LLM의 응답을 생성하기 전에 외부 지식베이스를 참조해 출력 품질을 높이는 AI 아키텍처다. 학습 데이터에서만 답을 찾는 것이 아니라, 외부 DB나 문서에서 최신 정보를 끌어와 더 정확하고 최신의 답변을 만들어낸다.

RAG가 해결하는 3가지 핵심 문제:

•      환각(Hallucination) 문제: LLM은 학습 데이터의 패턴만으로 텍스트를 생성하기 때문에, 학습 데이터 밖의 정보나 사실 정확도가 중요한 질문에서 자신감 있지만 틀린 답변을 내놓는 경우가 많다.

•      지식 컷오프(Knowledge Cutoff) 문제: 모든 LLM에는 학습 종료 날짜가 존재한다. 2024년 초에 학습된 모델은 2024년 후반이나 2025년의 정보를 알 수 없다.

•      도메인 특화 문제: 의료 문헌, 법률 문서, 사내 지식 등 특정 도메인에 맞게 LLM을 파인튜닝하려면 막대한 컴퓨팅 자원, 방대한 레이블 데이터, 수백만 달러의 인프라 비용이 필요하다.

 

RAG의 핵심 아이디어는 단순하다. 모든 지식을 모델 파라미터 안에 구겨 넣는 대신, 지식 저장소(검색 가능한 DB)와 추론 능력(LLM)을 분리하는 것이다. 이 구조적 결정 덕분에 AI 시스템을 더 유연하고 검증 가능하게 만들 수 있다.

RAG 작동 원리: 핵심 아키텍처와 구성 요소

RAG 시스템은 여러 컴포넌트로 이루어진 파이프라인으로 동작한다. 각 단계를 순서대로 살펴보자.

Stage 1: 데이터 준비 및 인제스천(Ingestion)

쿼리에 답하려면 먼저 외부 지식 소스를 시스템에 입력하고 준비해야 한다. LLM에서 항상 그렇듯 데이터 품질이 핵심이다. 이 단계의 데이터 품질이 나쁘면 검색이나 생성 단계를 아무리 잘 설계해도 결과가 나빠진다.

① 문서 로딩 (Document Loading)

PDF, Word 문서, 웹페이지, DB, API 등 다양한 소스에서 데이터를 수집하는 단계다.
포맷에 맞는 파싱이 필요하다:

•      웹 스크레이퍼: 웹페이지에서 주요 콘텐츠 추출

•      OCR 모델: PDF 문서를 LLM 친화적인 마크다운 형식으로 변환

•      CSV/Excel 파서: 스프레드시트의 컬럼 구조와 관계 유지

② 텍스트 청킹 (Text Chunking)

100페이지짜리 PDF 같은 원본 문서는 LLM이 한 번에 처리하기엔 너무 크다. 청커(Chunker)가 문서를 의미 있는 작은 단위로 분할하는데, 이건 RAG 시스템 설계에서 가장 중요한 결정 중 하나다. 청크는 완전한 아이디어를 담을 만큼 충분히 크되, 모델의 컨텍스트 한계에 맞을 만큼 작아야 한다.

대표적인 청킹 전략:

•      고정 크기 청킹: N 문자/단어/토큰마다 분할. 경계에서 컨텍스트가 잘리지 않도록 오버랩 포함 (예: 500토큰, 50토큰 오버랩)

•      문장 기반 청킹: 자연어 경계를 활용해 의미적으로 완결된 청크 생성

•      재귀적 청킹: 단락 경계 우선 시도 → 문장 → 고정 크기 순으로 폴백

•      시맨틱 청킹: 임베딩을 활용해 토픽 전환점을 감지하고 개념적 경계에서 분할

③ 임베딩 생성 (Embedding Generation)

각 청크를 임베딩 모델(OpenAI text-embedding-3, Sentence-BERT, Cohere embed 등)을 통해 의미를 담은 수백~수천 차원의 벡터로 변환한다.
의미적으로 유사한 텍스트는 유사한 벡터를 가지게 된다. 임베딩 모델 선택은 검색 품질, 저장 효율, 비용에 직접 영향을 미친다.

④ 벡터 인덱싱 (Vector Indexing)

임베딩된 청크들은 벡터 DB(Weaviate, Chroma, Pinecone, Qdrant, FAISS 등)에 저장된다. 이 DB들은 유사도 검색(Similarity Search)에 최적화되어 있어 쿼리와 관련된 청크를 빠르게 찾을 수 있다.

Stage 2: 쿼리 타임 리트리벌 (Retrieval)

사용자가 쿼리를 입력하면 리트리벌 프로세스가 작동한다(Retrieval : 사용자의 질문과 관련된 정확한 외부 정보(문서, 데이터 등)를 지식 베이스(벡터 저장소 등)에서 찾아내는 프로세스):

•      쿼리 임베딩: 인제스천 단계와 동일한 임베딩 모델로 쿼리 벡터 생성

•      ANN 검색: Approximate Nearest Neighbor 알고리즘(HNSW 등)으로 수백만 벡터 중 가장 유사한 것들을 빠르게 탐색. 전수 비교 없이 밀리초 단위 검색 가능

•      유사도 측정: 주로 코사인 유사도(Cosine Similarity) 사용 - 벡터의 방향/각도 기준으로 유사성 판단

•      메타데이터 필터링: 문서 타입, 날짜 범위, 권한 등 메타데이터로 사전 필터링 가능

Stage 3: 증강 및 생성 (Augmentation & Generation)

검색된 컨텍스트를 프롬프트에 삽입해 LLM에게 전달한다. 전형적인 프롬프트 구조는 '컨텍스트 정보 + 사용자 질문 + 지침'으로 구성되며, LLM(GPT-4, Claude, Llama, Gemini 등)이 이를 종합해 출처가 명시된 응답을 생성한다.

 

Core Component Summary

Component	Purpose	Common Tools/Technologies
Document Loader	Ingest data from various sources	LangChain loaders, PyPDF, Unstructured.io
Chunker	Split documents into manageable segments	LangChain text splitters, spaCy, custom logic
Embedder	Convert text to vector representations	OpenAI embeddings, Sentence-BERT, Cohere
Vector Database	Store and retrieve embeddings efficiently	Pinecone, Weaviate, Chroma, FAISS, Qdrant
Retriever	Find relevant chunks for queries	DPR, BM25, Hybrid search
Generator	Synthesize final responses	GPT-4, Claude, Llama, Gemini

---

컴포넌트 선택 실전 가이드

임베딩 모델 선택

임베딩 모델 선택은 검색 품질에 직접적인 영향을 미친다.

고려할 요소:

•      도메인 특화 여부: 범용 모델(OpenAI text-embedding-3-small, all-MiniLM-L6-v2)은 일반 용도에 적합하지만, 의료 텍스트엔 BioBERT처럼 특화 모델이 훨씬 좋은 성능을 낸다.

•      차원수 트레이드오프: 고차원(1536+)은 더 섬세한 의미를 잡지만 저장공간과 연산이 많이 필요하다. 저차원(384~768)은 대부분 애플리케이션에서 품질 손실 없이 빠른 검색이 가능하다.

•      다국어 지원: Cohere 다국어 임베딩, BGE-M3 같은 모델은 글로벌 서비스에 필수다.

 

💡 실전 팁: BEIR, MTEB 같은 벤치마크도 참고하되, 실제 유저 쿼리 20~30개와 예상 검색 문서로 구성한 자체 테스트셋을 만들어 Recall@5(상위 5개 결과 중 정답 포함 비율)나 MRR(Mean Reciprocal Rank)을 직접 측정하는 것이 가장 신뢰할 수 있는 방법이다.

최적 청크 크기 결정

•      너무 작을 때 (<128 토큰): 컨텍스트 부족으로 파편화된 정보, 낮은 검색 관련성

•      너무 클 때 (>1024 토큰): 여러 토픽이 혼재해 검색 정밀도 저하, 컨텍스트 윈도우 한계 도달 가속

•      최적 구간 (256~512 토큰): 대부분의 애플리케이션에서 좋은 성능

•      오버랩 전략: 연속 청크 간 10~20% 오버랩으로 경계에서 정보 유실 방지 (저장 공간은 증가)

RAG vs 파인튜닝: 무엇을 선택할까?

RAG - 비용 효율적이고 빠른 선택:

•      재학습 불필요 - 문서만 연결하면 바로 동작

•      문서 변경 시 즉시 반영

•      최소한의 데이터만 필요 (레이블 데이터셋 불필요)

•      높은 투명성 - 어떤 소스에서 답을 가져왔는지 추적 가능

→ 자주 변하는 지식, 출처 인용이 필요한 경우, 예산/시간이 제한된 프로젝트에 적합

 

파인튜닝 - 파라미터 최적화 접근법:

•      도메인 특화 지식을 모델에 내재화 가능

•      일관된 톤, 스타일, 전문 지식 표현에 유리

•      비용 높음, 대량의 고품질 학습 데이터 필요

•      업데이트 시 전체 재학습 사이클 필요

→ 예산과 데이터가 충분하고, 도메인이 안정적이며, 빠른 추론과 일관된 포맷이 중요한 경우에 적합

RAG의 한계와 도전 과제

RAG는 파이프라인 시스템이므로 각 컴포넌트의 오류가 연쇄적으로 전파된다. 나쁜 청크 → 낮은 검색 품질 → 약한 답변으로 이어진다. 각 컴포넌트를 독립적으로 테스트하는 것이 필수다.

•      검색 품질 문제: 임베딩 모델이 도메인 특화 용어나 미묘한 관계를 파악하지 못해 관련 문서를 낮은 순위로 밀어낼 수 있다.   
  해결책: 도메인 특화 임베딩, 하이브리드 검색, 가상 질문 생성, 풍부한 메타데이터 추가

•      환각 지속: RAG가 환각을 크게 줄이지만, LLM이 여전히 소스를 잘못 해석하거나 근거 없이 그럴듯한 추론을 할 수 있다.
  해결책: 소스 인용 강제, 자기 평가 프롬프트, 중요 애플리케이션에 인간 검수

•      상충하는 정보: 검색된 문서들이 모순된 정보를 담고 있을 수 있다.
  해결책: 문서 최신성 기반 리랭킹, 소스 신뢰도 점수, LLM으로 충돌 인식 및 고지

•      확장성 및 레이턴시: 수백만 문서 규모에서 검색 레이턴시가 UX에 영향을 줄 수 있다.
  해결책: HNSW 인덱스/양자화 최적화, 공통 쿼리 캐싱

•      컨텍스트 윈도우 오버플로우: 많은 긴 청크를 가져올 때 컨텍스트 한계에 도달할 수 있다.
  해결책: 요약으로 컨텍스트 압축, 리랭킹으로 가장 관련성 높은 청크 우선화

고급 RAG 기법

1. 메타데이터 증강 + 가상 질문 생성

청크에 구조화된 메타데이터(source, page, department, last_updated 등)를 저장해 시맨틱 검색 전에 필터링을 가능하게 한다. 더 나아가, LLM으로 각 청크가 답할 수 있는 질문들을 미리 생성해 저장하고, 쿼리 타임에 원문 텍스트 대신 이 질문들과 비교한다. 질문-질문 비교가 의미적 매칭 정확도를 크게 높인다.

2. 리랭킹 (Reranking) & LLM-as-a-Judge

초기 검색 결과를 정교하게 재순위화하는 단계다.

두 가지 접근법:

•      크로스 인코더 리랭킹: 쿼리와 문서를 함께 처리해 어텐션 메커니즘으로 깊은 의미적 유사도를 계산한다. 비용이 크기 때문에 초기 검색(수백만 문서 → Top 50~100)에는 쓸 수 없고, 후처리 단계(Top 50~100 → Top K)에 사용한다.

•      LLM-as-a-Judge: LLM에게 쿼리와 검색 문서 목록을 주고, 특정 평가 기준(사실 일치도, 비즈니스 제약 등)을 자연어 지침으로 프롬프트에 담아 관련도 점수를 0~1로 출력하게 한다. 복잡한 비즈니스 제약 조건을 반영할 수 있어 유용하다.

3. 멀티 스테이지 LLM 오케스트레이션

•      쿼리 최적화: 검색 전에 LLM으로 모호한 쿼리를 구체적으로 재구성 (예: "육아휴직" → "회사 가족 및 의료 휴가 정책에서 유급 육아휴직의 자격 조건, 기간, 급여 비율은?")

•      컨텍스트 요약: 검색 후 긴 컨텍스트를 요약해 노이즈를 줄이고 핵심에 집중

•      응답 자기 평가: 생성 후 LLM이 자신의 답변의 정확성과 관련성을 스스로 비판하게 함

4. GraphRAG: 지식 그래프 통합

벡터 검색과 함께 지식 그래프(Knowledge Graph)를 활용해 엔티티 간 명시적 관계를 탐색한다. "A사와 B사가 2025년에 함께 진행한 프로젝트는?" 같은 관계 중심 질문에 특히 효과적이다. 텍스트에 명시적으로 기술되지 않은 연결 관계도 찾아낼 수 있다. 초기 구축 비용은 높지만 대규모 기업 데이터베이스에서 복잡한 관계 쿼리 성능이 뛰어나다.

5. 하이브리드 검색 (Semantic + BM25)

순수 시맨틱 검색은 키워드 정확 매칭을 놓칠 수 있고, 키워드 검색은 의미적 유사성을 파악 못한다. BM25(또는 TF-IDF) 기반 스파스 검색과 벡터 기반 덴스 검색을 Reciprocal Rank Fusion(RRF)으로 결합하면 두 방식의 장점을 모두 취할 수 있다. 특히 기술 문서, 고유명사, 버전 번호 같은 특수 식별자가 많은 경우에 효과적이다.

6. 구조화된 RAG (Structured RAG)

실제 환경에서는 구조화된 데이터(DB 레코드)와 비구조화 텍스트를 함께 써야 하는 경우가 많다. 멀티 스토어 전략으로 각 데이터 타입에 맞는 저장소(벡터 DB, RDBMS, 그래프 DB, 시계열 DB)를 활용하고, 쿼리 타임에 여러 소스의 결과를 통합해 하나의 컨텍스트로 만든다. 단일 소스로는 불가능한 포괄적인 답변이 가능해진다.

7. 에이전틱 RAG (Agentic RAG)

LLM에게 벡터 검색, SQL 쿼리, 웹 검색, API 호출 등 다양한 도구를 주고, 어떤 도구를 언제 사용할지 스스로 결정하게 한다. 예를 들어 "Q3 매출을 업계 평균과 비교하고 차이 비율을 계산해줘"라는 쿼리를 받으면, 에이전트가 자율적으로 내부 문서 검색 → 웹 검색 → 계산 → 종합 답변 생성 흐름을 실행한다. 초기 검색 품질이 낮으면 쿼리를 재구성해 재시도하는 자기 수정(Self-Correction) 기능도 구현 가능하다.

실제 적용 사례

•      기업 지식 관리: 위키, SharePoint, 파일 서버에 흩어진 문서를 인덱싱해 임직원 질문에 출처와 함께 즉시 답변

•      고객 지원: 트러블슈팅 가이드, FAQ, 과거 해결 사례를 자동으로 검색해 반복 문의 티켓을 40~60% 감소시키고 24/7 대응 가능

•      연구 보조: PubMed, arXiv, 기관 저장소를 검색해 "최근 CRISPR 암 연구 동향은?" 같은 질문에 인용 포함 종합 답변 제공

•      법률 리서치: 판례 및 선례 검색, 계약서 기준 대비 분석, 이슈 플래그 자동화로 수 시간이 걸리던 리서치를 수 분으로 단축

마치며: 신뢰할 수 있는 AI 구축하기

RAG는 LLM이 훨씬 더 좋은 결과를 내도록 돕는 강력하고 신뢰할 수 있는 도구가 됐다. 기본 RAG에서 프로덕션 수준 시스템으로 나아가려면 컴포넌트 선택, 최적화, 한계 대응에 지속적인 주의가 필요하다.

성공을 위한 핵심 원칙:

•      단순하게 시작하라: 기본 RAG부터 구현하고 성능을 측정한 다음, 필요할 때만 복잡도를 높여라

•      검색 품질을 최우선으로: 아무리 좋은 LLM도 나쁜 검색 결과를 극복할 수 없다. 청킹 전략, 임베딩, 메타데이터 설계에 투자하라

•      평가를 내재화하라: 검색 정확도, 답변 품질, 레이턴시 같은 명확한 지표를 정의하고 지속적으로 모니터링하라

•      확장을 처음부터 고려하라: 데이터 볼륨, 쿼리 패턴, 업데이트 빈도를 처음 설계 단계부터 반영하라

---

 

참조 : https://pub.towardsai.net/all-you-need-to-know-about-retrieval-augmented-generation-rag-in-2025-04c386284c18