Gen AI Prime Guide: RAG (검색 증강 생성) 해설서

CTU-COE_남정현 · 6월 4, 2025, 11:47오전

Gen AI Prime Guide는 Gen AI에 관하여 누구나 알아야 할 엔지니어링 수준의 기초 지식을 공유하고 전파하기 위한 목적으로 쓰여지는 가이드입니다. 피드백, 궁금한 점, 개선할 점을 댓글로 달아주시면 계속해서 보완해 나가도록 하겠습니다!

RAG란 무엇인가? – 배경과 정의

오늘날 많은 LLM 기반 AI 서비스는 거대한 사전학습 데이터에 의존하여 답변을 생성합니다. 하지만 모델이 학습한 지식은 언제나 한계가 있으며, 정보가 빠르게 변하는 환경에서는 최신 정보, 사내 문서, 맞춤형 레퍼런스 등 외부 지식의 실시간 활용이 필수가 되고 있습니다.

이런 배경에서 등장한 개념이 바로 RAG(Retrieval-Augmented Generation) 입니다. RAG는 “모델이 모든 답을 기억하고 있는” 구조를 벗어나, 외부의 지식 소스(문서, 데이터베이스 등)에서 실시간으로 필요한 정보를 검색(Retrieval)하고, 이를 모델의 입력(프롬프트)에 통합하여 더 정확하고 풍부한 답변을 생성하는 기술 프레임워크를 말합니다.

즉, RAG의 본질은 “검색”과 “생성”의 결합입니다. LLM 혼자만의 힘이 아니라, 외부 지식 자산과 결합해 실제 업무, 고객 서비스, 사내 지식관리 등에서 현실적이고 신뢰할 수 있는 AI를 실현하는 핵심 구조라 할 수 있습니다.

RAG의 전체 동작 흐름 – 단계별 해설

사용자 질의(Query) 입력
- 사용자가 자연어로 질문을 입력합니다.
질의에 기반한 문서 검색
- 이 질의를 임베딩 모델을 이용하여 벡터(수치화된 표현) 값을 계산합니다.
- 변환된 벡터 값을 벡터 데이터베이스(Vector DB)에 전달하여, 수학적 유사도 계산(예: 코사인 유사도 등)을 통해 의미적으로 가장 가까운 문서, 데이터 조각(청크)을 검색합니다.
  - 이 방식은 단순 키워드 검색이나 패턴 매칭과 달리, 문장 전체의 의미론적 유사성을 정량적으로 비교한다는 점이 핵심입니다.
  - 이 때 벡터 DB는 각 벡터와 원문 텍스트, 메타데이터를 연결하는 인덱싱 DB의 역할을 수행하며, 벡터 값 자체만으로는 원문 내용을 역산(복원)할 수 없습니다. 그래서 벡터 DB와 원문 DB는 약한 참조 관계로 이어진 상태로 관리됩니다.
검색된 문서를 프롬프트에 결합
- 벡터 DB에서 반환된 **문서 인덱스 번호(참조 키)**를 이용해, 해당 문서 조각을 원문 DB에서 가져와 “context”로 활용합니다.
- 이렇게 수집한 문서 조각들은, 질문, 검색된 문서 스니펫, 그리고 지시문 등과 함께 LLM에게 입력될 프롬프트로 조립됩니다.
LLM이 결합된 정보를 바탕으로 답변 생성
- 프롬프트를 입력받은 LLM이, 검색된 외부 정보를 최대한 활용하여 질문에 대한 답변을 만듭니다.
최종 답변 출력
- 사용자에게 답변을 제공합니다. 필요한 경우, 참고한 문서 출처도 함께 제시할 수 있습니다.

이 흐름의 핵심은 "모델이 스스로 모든 답을 만들어내는 것"이 아니라, 실시간으로 외부에서 정보를 찾아와 함께 조합한다는 점입니다. 이를 통해, 최신 정보 반영, 사내 정책이나 고객 전용 문서 반영 등 실제 업무 현장에 적합한 AI 시스템을 구현할 수 있습니다.

프롬프트와 RAG의 결합 – 작동 방식의 실체

RAG라는 기술이 복잡하게 들릴 수 있지만, 실제 동작 원리는 매우 단순합니다.

RAG 없이 질문을 한다면, LLM은 자신이 학습한 지식에만 의존해 답변해야 하며, 별도의 인터넷 검색이나 외부 지식 접근이 없다면, 답을 모르는 경우에도 “답변하지 못하겠습니다”라는 식으로 깔끔하게 빠져나가지 못하고, 오히려 그럴듯한 ‘환각 답변(hallucination)’을 만들어내기 쉽습니다.

이러한 현상을 방지하기 위해, RAG는 프롬프트 앞에 **검색된 외부 지식(문서, 데이터 등)**을 명시적으로 삽입합니다. 그리고 LLM이 그 “지식 범위 내에서만” 질문에 답을 하도록 유도하는 것이 핵심입니다.

아래는 실제 프롬프트 예시입니다.

You are a helpful assistant. Use the following context to answer the question.

Context:
[검색된 문서 조각들이 들어가는 자리]

Question:
[사용자의 원 질문]

Answer:

위의 Context: 아래 부분에는 벡터 DB에서 가져온 실제 문서 청크, 스니펫, 요약문 등이 들어갑니다.

LLM은 이 context를 참고하여, 단순 “사전지식에만 의존한 답변”이 아닌, 최신 정보와 정확성이 높아진 응답을 생성할 수 있습니다.

이 방식을 통해 “잘못된 환상 답변(hallucination)”을 최소화하고, 실제 비즈니스 현장에서 신뢰할 수 있는 답변을 끌어낼 수 있습니다.

참고로, 최근 AI 챗봇들이 제공하는 “인터넷 검색” 기능도 결국 대규모 RAG 구조의 일종입니다. 서비스 제공사들이 웹에서 최신 정보를 수집·색인하고, 사용자 질문과 의미적으로 가장 가까운 문서·콘텐츠를 검색해 이를 LLM 프롬프트에 삽입하는 방식으로 동작합니다.

즉, “외부 지식 검색 + 프롬프트 결합 + LLM 답변 생성” 이라는 RAG의 핵심 원리가 인터넷 검색 연동 AI에서도 동일하게 활용되고 있습니다.

임베딩 모델과 벡터 DB – 검색의 핵심 메커니즘

1. 임베딩(Embedding) 모델

자연어(문서, 질문 등)를 수치 벡터(Embedding) 로 변환합니다.
동일하거나 유사한 의미의 텍스트는 벡터 공간에서 가까이 위치하게 됩니다.
대표적으로 OpenAI Embedding API, HuggingFace의 sentence transformers, Cohere, Azure OpenAI 등 다양한 임베딩 모델이 사용됩니다.

여기서 한 가지 기술적으로 고려할 것이 있습니다. 임베딩 모델의 종류나 버전이 다르면 동일한 원문이라도 생성되는 벡터 값이 달라지므로, 서로 다른 임베딩 모델이나 버전 간에는 벡터 데이터의 호환성이 보장되지 않습니다.

예를 들어, OpenAI의 이전 버전 임베딩과 최신 버전 임베딩, 혹은 서로 다른 프레임워크(HuggingFace vs Cohere 등)에서 생성된 벡터는 직접적인 의미 비교나 검색에 사용할 수 없습니다. 이러한 상호 운용성(Interoperability)에 대한 연구가 현재 학계와 업계에서 활발히 진행 중이며, 다양한 임베딩 모델 간의 벡터 공간 정렬(alignment), 변환(embedding mapping), 호환 표준 등에 대한 실험과 논의가 이루어지고 있어서 향후 추이를 지켜볼 필요가 있습니다.

2. 벡터 DB(Vector Database)

수많은 벡터(임베딩 결과)를 저장, 인덱싱, 고속 검색할 수 있도록 설계된 특수 DB입니다.
대표적으로 Pinecone, Weaviate, Qdrant, Milvus, Chroma 등이 있습니다.
새로운 질의(질문 벡터)가 입력되면, DB는 가장 유사한 벡터(즉, 가장 의미적으로 가까운 문서)를 찾아냅니다.

3. RAG를 위한 데이터베이스 구축 실무

문서 수집 및 분할(Chunking)
- PDF, HTML, 텍스트, FAQ, 사내 문서 등 다양한 소스를 수집합니다.
- 긴 문서는 500~1,000자 내외로 “청크” 분할합니다.
임베딩 생성
- 각 청크별로 임베딩 모델을 적용, 고차원 벡터로 변환합니다.
벡터 DB에 저장
- (임베딩 벡터, 원문, 메타데이터)를 저장합니다.
- 메타데이터는 문서 유형, 날짜, 작성자, 출처 등 추가 정보로, 나중에 검색 결과 신뢰성 향상에 기여합니다.
검색 및 결과 활용
- 사용자의 질문도 임베딩 모델로 벡터화 → 벡터 DB에서 가장 유사한 청크 여러 개(3~10개 등) 반환 → 이 청크들을 프롬프트 context로 조립합니다.

실제로, 임베딩 모델 선택/세팅, 청크 분할 전략, 메타데이터 구성 등이 RAG 시스템의 성능과 신뢰성에 큰 영향을 미칩니다.

실전 예시 – 프롬프트와 검색 흐름

사용자가 “리소스 그룹이 여러 지역의 리소스를 포함할 수 있습니까?”라는 질문을 한다고 가정합시다. RAG 시스템은 다음과 같이 작동합니다.

질문 임베딩 생성 → 벡터 DB에서 유사 문서 검색
아래와 같은 문서 청크 3개가 검색됨
- “Azure의 리소스 그룹은 논리적으로 리소스를 그룹화하는 데 사용됩니다.”
- “리소스 그룹 내의 모든 리소스는 동일한 지역에 있을 필요는 없습니다.”
- “리소스 그룹 삭제 시 그룹 내 리소스도 함께 삭제됩니다.”

프롬프트 조립 예시

Context:
- Azure의 리소스 그룹은 논리적으로 리소스를 그룹화하는 데 사용됩니다.
- 리소스 그룹 내의 모든 리소스는 동일한 지역에 있을 필요는 없습니다.
- 리소스 그룹 삭제 시 그룹 내 리소스도 함께 삭제됩니다.

Question:
리소스 그룹이 여러 지역의 리소스를 포함할 수 있습니까?

Answer:

LLM이 답변 생성
- LLM은 context 정보에 기반해, “네, 리소스 그룹은 여러 지역의 리소스를 포함할 수 있습니다.”라는 답변을 신뢰성 있게 제공합니다.

이런 구조는 검색 → 프롬프트 조립 → 답변 생성의 연속 흐름을 통해,
단순 검색 결과 나열이 아닌, 맥락과 논리를 가진 문장으로 최종 응답을 만듭니다.

코드 수준의 예시 – .NET 기반 RAG 구현 흐름(의사 코드)

// 1. 사용자 질문을 임베딩 벡터로 변환
var questionEmbedding = embeddingModel.Encode(userQuery);

// 2. 벡터 DB에서 유사 문서 검색
var results = vectorDb.Search(questionEmbedding, topN: 3);

// 3. 검색 결과를 프롬프트로 조립
var context = string.Join("\n", results.Select(r => r.Text));
var prompt = $"Context:\n{context}\n\nQuestion:\n{userQuery}\n\nAnswer:";

// 4. LLM에 프롬프트 전달, 답변 생성
var answer = llmApi.Generate(prompt);

실제로는 문서 수집/임베딩 생성/DB 구축/검색/프롬프트 조립/답변 생성 등 각 단계를 자동화한 파이프라인을 구성하는 것이 일반적입니다.
LLM, 임베딩 엔진, 벡터 DB 등 각 구성요소는 별도의 서비스 또는 라이브러리로 운용될 수 있습니다.

RAG 아키텍처 설계·운영의 실무적 유의점

임베딩 모델과 LLM은 서로 다른 엔진(예: OpenAI text-embedding-3-small + GPT-4o)이어도 무방하나, 임베딩 모델 선택과 버전 일관성은 검색 품질에 영향
질문/문서 임베딩은 동일 모델로 생성하는 것이 정밀 검색에 유리
청크 분할 전략(문장/단락 단위, 개수 등)은 검색 정확도와 LLM 입력 토큰 한도에 영향을 미침
메타데이터(출처, 날짜, 작성자 등)는 신뢰성, 필터링, 감사기록에 활용 가능
실시간 업데이트가 필요한 경우, 임베딩 파이프라인의 자동화 및 데이터 싱크 주기 설계 필요

요약 및 적용 포인트

RAG는 외부 지식 자산을 LLM에 접목해 최신, 정확, 맞춤형 답변을 만들어내는 검색+생성 하이브리드 AI 프레임워크입니다.
임베딩 모델과 벡터 DB는 RAG의 “지식 검색”을 담당하는 핵심 구성요소이며, 프롬프트 조립이 LLM 품질을 좌우합니다.
실무적 관점에서, 임베딩/청크/메타데이터/프롬프트 조립/엔진 선택 등 각 단계가 전체 시스템의 성능과 신뢰성에 직접적인 영향을 미칩니다.
RAG는 단순 챗봇을 넘어, 사내 지식 관리, 도메인 특화 검색, 복잡한 질의 응답 등 다양한 엔터프라이즈 AI 솔루션의 기반이 되는 구조입니다.