[AI] RAG 개념 정리

참고 영상

• 영상: 초보자들을 위한 RAG 개념 20분 마스터클래스
• 채널: 샘 호트만 : AI 엔지니어의 시선

이 영상은 RAG를 처음 접하는 사람이 전체 구조를 잡을 수 있도록 Embedding, Vector Database, Chunking, Hybrid Search, Reranker, Contextual Retrieval, Late Chunking까지 하나의 파이프라인으로 연결해 설명한다.

핵심 메시지는 단순하다.

RAG가 죽은 것이 아니라, 단순한 RAG만으로 충분하던 시기가 끝났다.

RAG란?

RAG는 Retrieval-Augmented Generation의 약자다. 한국어로 풀면 검색 증강 생성 정도로 이해할 수 있다.

LLM은 학습된 지식만으로 답변하면 최신 정보, 사내 문서, 개인 데이터, 도메인 특화 지식에 약하다. RAG는 질문과 관련된 외부 문서를 먼저 검색하고, 검색된 문서를 LLM의 컨텍스트로 넣어 답변을 생성하게 한다.

즉, RAG는 다음 문제를 해결하기 위한 구조다.

• 모델이 모르는 최신 정보를 반영한다.
• 사내 문서나 업무 지식처럼 공개 학습 데이터에 없는 정보를 활용한다.
• 답변 근거를 문서에서 찾게 만들어 환각을 줄인다.
• 모델을 매번 학습시키지 않고도 지식 업데이트를 빠르게 반영한다.

기본 파이프라인

RAG는 크게 색인 단계와 질의 단계로 나눌 수 있다.

1. 문서 수집과 Parser

RAG의 출발점은 문서다. PDF, HTML, Word, Notion, Slack, DB 등 다양한 원천에서 문서를 가져온다.

Parser는 이 문서를 검색 가능한 텍스트로 바꾸는 역할을 한다. 이 단계가 부실하면 이후 Embedding이나 검색 모델이 좋아도 품질이 잘 나오지 않는다.

특히 PDF처럼 표, 머리글, 바닥글, 이미지, 다단 문서가 섞인 파일은 Parser 품질이 중요하다. 문서 구조가 깨지면 검색 대상 자체가 잘못 만들어진다.

2. Chunking

LLM이나 검색 시스템은 전체 문서를 한 번에 다루기 어렵다. 그래서 문서를 작은 조각으로 나누는데, 이 과정을 Chunking이라고 한다.

Chunking에서 중요한 것은 단순히 글자 수로 자르는 것이 아니다. 의미 단위가 유지되어야 한다.

나쁜 Chunking은 다음 문제를 만든다.

• 질문과 관련된 정보가 여러 조각으로 찢어진다.
• 문맥 없이 일부 문장만 검색된다.
• 검색 결과는 맞는 것처럼 보이지만 답변 생성에 필요한 근거가 부족하다.

좋은 Chunking은 제목, 문단, 표, 섹션 구조를 고려한다. 필요하면 overlap을 둬서 앞뒤 문맥이 끊기지 않게 한다.

3. Embedding

Embedding은 텍스트를 숫자 벡터로 바꾸는 과정이다. 컴퓨터는 문장의 의미를 그대로 이해하지 못하므로, 문장의 의미가 비슷하면 벡터 공간에서도 가까워지도록 숫자로 표현한다.

예를 들어 다음 두 문장은 표현은 다르지만 의미가 비슷하다.

• RAG는 외부 문서를 검색해 답변에 활용한다.
• 검색된 지식을 LLM 컨텍스트에 넣어 답변을 만든다.

Embedding 모델이 잘 동작하면 이런 문장들이 벡터 공간에서 가깝게 배치된다.

Vector Database

Vector Database는 Embedding된 벡터를 저장하고, 질문 벡터와 가까운 문서 벡터를 빠르게 찾는 저장소다.

일반적인 데이터베이스가 id, name, created_at 같은 필드 기반 검색에 강하다면, Vector Database는 의미 기반 유사도 검색에 강하다.

대표적으로 사용하는 검색 방식은 다음과 같다.

• Cosine Similarity: 벡터의 방향이 얼마나 비슷한지 비교한다.
• Dot Product: 두 벡터의 내적을 사용한다.
• Euclidean Distance: 벡터 사이의 거리를 계산한다.

실무에서는 Milvus, Pinecone, Weaviate, Qdrant, Chroma, Elasticsearch/OpenSearch의 vector search 기능 등을 선택할 수 있다.

실무에서 RAG가 실패하는 이유

RAG가 실패할 때 원인을 LLM에서만 찾으면 안 된다. 대부분의 문제는 답변 생성 이전 단계에서 생긴다.

대표적인 실패 원인은 다음과 같다.

• 문서 파싱이 잘못되어 검색 대상 텍스트가 깨져 있다.
• Chunking이 부적절해 필요한 문맥이 누락된다.
• Embedding 모델이 도메인 언어를 충분히 표현하지 못한다.
• 검색 결과 top-k에 정답 근거가 들어오지 않는다.
• 검색 결과는 들어왔지만 순위가 낮아 LLM 컨텍스트에 포함되지 않는다.
• 질문이 짧거나 모호해 검색 쿼리 자체가 부정확하다.

따라서 RAG를 디버깅할 때는 최종 답변만 보지 말고 검색 결과를 먼저 봐야 한다.

확인해야 할 질문은 다음과 같다.

• 정답 문서가 실제로 색인되어 있는가?
• 질문과 관련된 chunk가 검색 결과에 포함되는가?
• 포함된다면 몇 번째 순위로 올라오는가?
• 검색된 chunk만 보고도 사람이 답변할 수 있는가?
• LLM이 근거를 제대로 사용하고 있는가?

Dense, Sparse, Hybrid Search

RAG 검색은 크게 Dense Search와 Sparse Search로 나눌 수 있다.

Dense Search

Dense Search는 Embedding 벡터를 이용한 의미 기반 검색이다. 단어가 정확히 일치하지 않아도 의미가 비슷하면 찾을 수 있다.

장점은 자연어 질문에 강하다는 것이다. 사용자가 문서에 있는 표현과 다른 말로 질문해도 관련 문서를 찾을 수 있다.

단점은 고유명사, 코드명, 숫자, 약어처럼 정확한 키워드가 중요한 검색에서는 약할 수 있다.

Sparse Search

Sparse Search는 BM25 같은 전통적인 키워드 기반 검색을 말한다. 문서와 질문에 같은 단어가 등장하는지를 중요하게 본다.

장점은 정확한 용어 매칭에 강하다는 것이다. 제품명, 법 조항, 에러 코드, 함수명처럼 단어 자체가 중요한 경우 유리하다.

단점은 의미는 같지만 표현이 다른 질문을 놓칠 수 있다는 것이다.

Hybrid Search

Hybrid Search는 Dense Search와 Sparse Search를 함께 쓰는 방식이다.

실무 RAG에서는 둘 중 하나만 고집하기보다, 의미 기반 검색과 키워드 기반 검색을 결합하는 편이 안정적이다. 특히 사내 문서, 법률, 금융, 제조 도메인처럼 전문 용어와 고유명사가 많은 환경에서는 Hybrid Search가 중요하다.

Reranker

초기 검색은 후보 문서를 넓게 가져오는 단계다. 하지만 top-k로 가져온 결과가 항상 최적 순서라는 보장은 없다.

Reranker는 검색된 후보 문서를 다시 평가해서 질문과 더 관련 높은 순서로 재정렬한다.

흐름은 보통 다음과 같다.

1. Vector DB나 Hybrid Search로 후보 문서 20개에서 100개 정도를 가져온다.
2. Reranker가 질문과 각 후보 문서의 관련도를 다시 계산한다.
3. 상위 몇 개 문서만 LLM 컨텍스트에 넣는다.

Reranker를 쓰면 검색 recall과 최종 context precision을 동시에 노릴 수 있다. 다만 추가 모델 호출이 필요하므로 지연 시간과 비용을 함께 고려해야 한다.

Contextual Retrieval

일반적인 Chunking은 문서를 조각으로 나눈 뒤 각 chunk만 Embedding한다. 문제는 chunk가 너무 짧으면 원래 문서의 큰 맥락을 잃는다는 점이다.

Contextual Retrieval은 chunk에 문서 전체의 맥락 정보를 추가해 검색 품질을 높이는 접근이다.

예를 들어 chunk 자체에는 “이 정책은 2025년 3월부터 적용된다”라고만 적혀 있을 수 있다. 이 문장만 보면 어떤 정책인지 알기 어렵다. 여기에 문서 제목, 섹션 제목, 요약 맥락을 함께 붙이면 검색과 답변 품질이 좋아진다.

Late Chunking

Late Chunking은 먼저 문서 전체 또는 더 큰 단위를 Embedding 모델에 통과시켜 문맥을 반영한 뒤, 나중에 chunk 단위 표현을 만드는 방식으로 이해할 수 있다.

일반 Chunking은 문서를 먼저 자르고 각 조각을 따로 Embedding한다. 그래서 각 chunk가 주변 문맥을 충분히 반영하지 못할 수 있다.

Late Chunking은 이 문제를 줄이기 위한 고급 기법이다. 긴 문서에서 앞뒤 문맥이 중요한 경우 검색 품질을 높이는 데 도움이 된다.

“RAG is dead” 논쟁에 대한 정리

영상의 핵심 관점은 “RAG가 죽었다”가 아니라 “단순 RAG만으로는 부족하다”에 가깝다.

코딩 에이전트나 긴 컨텍스트 모델이 발전하면서 일부 상황에서는 별도의 RAG가 덜 중요해 보일 수 있다. 하지만 대부분의 프로덕션 AI 시스템에서는 여전히 외부 지식 검색이 필요하다.

특히 다음 환경에서는 RAG가 여전히 중요하다.

• 사내 문서 기반 질의응답
• 자주 업데이트되는 업무 지식
• 법률, 금융, 제조처럼 근거가 중요한 도메인
• 데이터 접근 권한을 통제해야 하는 서비스
• 답변 출처와 감사 가능성이 필요한 시스템

결국 중요한 질문은 “RAG를 쓸 것인가?”가 아니라 “어떤 검색 아키텍처를 설계할 것인가?”이다.

RAG 구축 체크리스트

RAG 시스템을 만들 때는 다음 순서로 점검하면 좋다.

1. 문서가 올바르게 수집되고 있는가?
2. Parser가 표, 제목, 목록, 문단 구조를 잘 보존하는가?
3. Chunk 크기와 overlap이 문서 성격에 맞는가?
4. Embedding 모델이 도메인 용어를 잘 표현하는가?
5. Dense Search와 Sparse Search 중 무엇이 더 잘 맞는가?
6. Hybrid Search가 필요한 도메인인가?
7. Reranker를 적용했을 때 검색 순위가 개선되는가?
8. 검색된 chunk만 보고 사람이 답변할 수 있는가?
9. LLM이 근거 문서를 충실히 사용하고 있는가?
10. 실패 케이스를 별도 데이터셋으로 관리하고 있는가?

정리

RAG는 단순히 Vector DB를 붙이는 기능이 아니다. 문서 수집, 파싱, 청킹, 임베딩, 검색, 재정렬, 컨텍스트 구성, 답변 생성까지 이어지는 검색 시스템이다.

초기에는 “질문을 임베딩하고, 비슷한 문서를 찾아서, LLM에게 넣는다” 정도로 시작할 수 있다. 하지만 실무에서는 이 단순 구조만으로 부족한 경우가 많다.

검색 품질을 높이려면 다음 관점이 필요하다.

• 검색 대상 문서가 깨끗해야 한다.
• 의미 단위로 chunk를 만들어야 한다.
• Dense Search와 Sparse Search의 장단점을 이해해야 한다.
• Reranker로 최종 컨텍스트 품질을 높여야 한다.
• Contextual Retrieval, Late Chunking 같은 고급 기법을 문제 상황에 맞게 검토해야 한다.

RAG를 제대로 이해한다는 것은 LLM을 잘 쓰는 것뿐 아니라, 검색 시스템을 잘 설계하는 것에 가깝다.