RAG(검색 증강 생성, Retrieval-Augmented Generation)란 무엇인가

참고: 이 문서는 영문 원본의 자동 번역본입니다.

RAG(검색 증강 생성, Retrieval-Augmented Generation)란 무엇인가

오픈북 시험을 치르는 학생을 상상해 보세요. 모든 문제를 기억만으로 답하는 대신, 학생은 교과서를 넘기며 가장 관련 있는 페이지를 찾아 읽고, 기억한 지식과 방금 찾아본 사실을 결합해 답을 씁니다. **검색 증강 생성(RAG)**은 대규모 언어 모델에 대해 동일한 방식으로 작동합니다. 모델은 학습 중 암기한 것에만 의존하지 않고 — 먼저 외부 지식 베이스를 검색하고, 가장 관련 있는 문서를 가져와, 응답을 생성할 때 그것을 추가 컨텍스트로 사용합니다.

이 기법이 중요한 이유는, 가장 강력한 LLM조차 지식 컷오프 날짜를 가지고 있고, "환각"(그럴듯하지만 부정확한 진술 생성)을 일으킬 수 있으며, 특화 도메인 지식이 부족할 수 있기 때문입니다. RAG는 모델이 질문에 답할 때마다 최신의, 도메인 특화된, 검증 가능한 출처에 접근하게 함으로써 이 세 가지 약점을 한 번에 해결합니다.

요약: RAG는 검색 시스템과 LLM을 결합하는 아키텍처 패턴입니다. 별도의 모델 유형이 아니라 — 외부 지식과 컨텍스트를 다루는 방식입니다.

작동 방식

RAG 파이프라인은 명확한 5단계 시퀀스를 따릅니다. 각 단계를 이해하면 RAG를 주장하는 프로젝트가 진정으로 작동하는 검색 계층을 가지고 있는지, 아니면 단지 표준 LLM 호출을 감싸고 있는지 평가하는 데 도움이 됩니다.

1단계 — 사용자 쿼리

이 과정은 사용자가 질문, 명령, 또는 프롬프트를 제출할 때 시작됩니다. 이 쿼리는 이후 모든 것의 출발점입니다. 예를 들어, 사용자가 이렇게 물을 수 있습니다: "지난 한 달간 이더리움의 주요 거버넌스 제안은 무엇이었나요?" 시스템은 LLM의 기억만으로 답하려 하지 않고 — 대신 쿼리를 검색 지시로 다룹니다.

2단계 — 쿼리 임베딩

원시 텍스트 쿼리는 임베딩이라는 수치 표현으로 변환됩니다 — 쿼리의 의미를 포착하는 숫자 벡터입니다. 이 단계는 특화 임베딩 모델(OpenAI의 text-embedding-ada-002 또는 E5나 BGE 같은 오픈소스 대안 등)을 사용합니다. 그 결과 벡터는 시스템이 시맨틱 검색을 수행하게 합니다 — 정확한 키워드 일치가 아니라 의미로 문서를 찾는 것입니다.

3단계 — 지식 베이스로부터의 검색

쿼리 임베딩은 문서, 구절, 또는 데이터 청크의 사전 계산된 임베딩을 보유한 벡터 데이터베이스(벡터 스토어라고도 함)와 비교됩니다. 데이터베이스는 의미적으로 가장 유사한 상위 k개 항목을 반환합니다. 흔한 벡터 데이터베이스로는 Pinecone, Weaviate, Qdrant, Milvus, Chroma가 있습니다.

검색 품질은 여러 요인에 따라 달라집니다:

청킹 전략 — 원본 문서가 어떻게 더 작은 조각으로 분할되었는지. 너무 큰 청크는 관련성을 희석하고, 너무 작은 청크는 컨텍스트를 잃습니다. 적절한 청크 크기를 찾는 것은 RAG 파이프라인에서 가장 영향력 있는 엔지니어링 결정 중 하나입니다.
임베딩 모델 — 의미가 벡터에 얼마나 정확히 포착되는지. 약한 임베딩 모델은 데이터베이스와 무관하게 약한 검색으로 이어집니다.
관련성 랭킹 — 검색이 진정으로 관련 있는 결과를 반환하는지, 아니면 단지 표면적으로 유사한 것을 반환하는지. 일부 시스템은 크로스 인코더를 사용해 초기 결과를 재채점하는 재랭킹 단계를 추가합니다.

4단계 — 컨텍스트 주입

가져온 문서는 사용자의 원래 쿼리와 결합되어 LLM에 전송되는 단일 프롬프트("증강된 프롬프트"라고도 함)가 됩니다. 이 프롬프트는 일반적으로 제공된 컨텍스트를 사용해 질문에 답하고, 컨텍스트에 충분한 정보가 없을 때 이를 표시하도록 모델에 지시합니다.

5단계 — LLM 생성 및 출력

LLM은 증강된 프롬프트를 읽고, 사전 학습된 지식과 검색된 증거 양쪽에 근거한 응답을 생성합니다. 잘 설계된 RAG 시스템은 답변의 일부를 특정 출처 문서에 다시 연결하는 인용 계층을 포함해, 사용자가 주장을 검증할 방법을 제공하기도 합니다.

단계	입력	출력	핵심 구성요소
쿼리	사용자 텍스트	원시 쿼리	사용자 인터페이스
임베딩	원시 쿼리	쿼리 벡터	임베딩 모델
검색	쿼리 벡터	관련 문서	벡터 데이터베이스
컨텍스트 주입	쿼리 + 문서	증강된 프롬프트	프롬프트 템플릿
생성	증강된 프롬프트	최종 답변	LLM

RAG가 중요한 이유

RAG는 독립형 LLM의 잘 알려진 세 가지 한계를 해결합니다:

환각. LLM은 확신에 차 있지만 부정확한 답을 산출할 수 있습니다. RAG는 응답을 실제 문서에 근거시킴으로써 이를 줄입니다. 모델이 특정 구절을 참조할 수 있을 때, 날조의 위험이 크게 떨어집니다.
오래된 지식. 사전 학습된 모델은 지식 컷오프 날짜를 가집니다. RAG는 신선하고 지속적으로 갱신되는 데이터에 접근하게 합니다 — 외부 데이터베이스는 매일 또는 실시간으로도 갱신될 수 있습니다.
도메인 특화성. 좁은 도메인을 위해 LLM을 파인튜닝하는 것은 비싸고 시간이 많이 듭니다. RAG는 재학습 없이 범용 모델이 특화 지식 베이스와 함께 작동하게 하여, 도메인 특화 애플리케이션을 더 빠르고 저렴하게 배포할 수 있게 합니다.

RAG 대 파인튜닝

RAG와 파인튜닝은 모두 특정 작업에서 LLM의 성능을 개선하는 것을 목표로 하지만, 근본적으로 다른 방식으로 작동합니다.

측면	RAG	파인튜닝
지식이 추가되는 시점	인퍼런스 시(매 쿼리마다)	학습 시(한 번, 이후 정적)
갱신 비용	낮음 — 지식 베이스 갱신	높음 — 모델 재학습 또는 재파인튜닝
지식 신선도	거의 실시간 가능	학습 컷오프에 고정
학습 인프라 필요	아니오	예(GPU, 데이터셋, 학습 파이프라인)
가장 적합한 용도	사실 회상, 문서 Q&A	스타일, 톤, 형식, 좁은 작업 최적화
감사 가능성	높음 — 검색된 출처를 로깅 가능	낮음 — 지식이 가중치에 내장됨

실무에서 많은 프로덕션 시스템은 둘을 결합합니다: 파인튜닝된 모델이 적절한 톤과 작업 동작을 제공하고, RAG가 최신 사실적 근거를 공급합니다.

고급 RAG 패턴

위에서 설명한 기본 5단계 파이프라인은 때때로 **나이브 RAG(naive RAG)**라 불립니다. 기법이 성숙하면서 엔지니어들은 더 정교한 변형을 개발했습니다:

다단계(반복) RAG. 한 번 검색하는 대신, 시스템은 검색하고, 중간 답변을 생성하고, 지식 격차를 식별하고, 정제된 쿼리로 다시 검색하며, 답변이 충분히 완전해질 때까지 반복합니다. 이 접근법은 단일 검색 패스로 답할 수 없는 복잡한 질문을 처리합니다.
에이전트형 RAG(Agentic RAG). 검색 단계가 AI 에이전트 프레임워크 안에 감싸집니다. 에이전트는 언제 검색할지, 어떤 지식 베이스를 쿼리할지, 쿼리를 재구성할지, 그리고 최종 답변을 생성할 충분한 컨텍스트를 언제 갖췄는지 결정합니다. 이 패턴은 RAG와 자율 에이전트 사이의 경계를 흐립니다.
하이브리드 검색. 동일한 검색 단계에서 벡터 기반 시맨틱 검색과 전통적 키워드 검색(BM25)을 결합합니다. 하이브리드 검색은 의미 기반과 용어 기반 일치를 모두 포착해, 특정 기술 용어나 고유명사를 포함하는 쿼리에 대한 재현율을 개선합니다.
그래프 RAG. 평면적인 문서 청크 대신, 지식 베이스가 지식 그래프 — 엔티티와 관계 — 로 구조화됩니다. 검색은 벡터 유사도 대신(또는 그에 더해) 그래프 엣지를 따라가며, 구조화된 데이터에 대한 다중 홉 추론을 가능하게 합니다. 이 패턴들은 평가에 중요합니다: 반복 검색을 갖춘 그래프-RAG 파이프라인을 설명하는 프로젝트는, 단지 "우리는 RAG를 사용한다"고 말하는 프로젝트보다 더 구체적이고(그리고 위조하기 더 어려운) 주장을 하는 것입니다.

RAG의 실제 사례

RAG는 이론적 개념이 아닙니다 — 오늘날 가장 널리 사용되는 일부 AI 제품을 구동합니다.

Bing Chat(Microsoft Copilot). Bing Chat에 질문하면, 웹을 검색하고 관련 페이지를 가져와 그 페이지를 LLM 답변의 컨텍스트로 사용합니다. 응답에 보이는 인라인 인용은 검색 단계의 직접적 결과입니다.
Perplexity. Perplexity는 RAG 아키텍처를 중심으로 구축되었습니다: 모든 사용자 쿼리가 웹 검색을 트리거하고, 결과가 LLM에 공급되며, 답변에는 번호가 매겨진 출처 참조가 포함됩니다. 사용자는 클릭해서 각 주장을 검증할 수 있습니다.
엔터프라이즈 지식 어시스턴트. 기업은 내부 RAG 시스템을 사용해 직원이 자연어로 HR 정책, 엔지니어링 문서, 또는 법률 계약을 쿼리하게 합니다. 검색 계층은 오픈 웹이 아니라 회사의 내부 문서 저장소를 검색합니다. 이 사례들은 RAG가 주류 기술임을 보여줍니다. 크립토 AI 프로젝트가 "우리는 RAG를 사용한다"고 말할 때, 질문은 RAG가 실제 기술인지가 아니라 프로젝트의 구체적 구현이 견실한지입니다: 어떤 데이터가 검색되고, 어떻게 인덱싱되며, 검색 품질이 측정되었는지.

크립토 AI 프로젝트에 RAG가 등장하는 이유

많은 크립토 AI 프로젝트가 아키텍처에서 RAG를 사용하거나 사용한다고 주장합니다. 흔한 사용 사례는 다음과 같습니다:

문서 어시스턴트 — 프로토콜 규칙이나 파라미터에 대한 사용자 질문에 답하기 위해 프로토콜 문서, 백서, 또는 거버넌스 제안을 검색.
크립토 인텔리전스 도구 — 분석 요약이나 알림을 생성하기 위해 실시간 시장 데이터, 온체인 이벤트, 또는 뉴스 기사를 가져옴.
에이전트를 위한 지식 베이스 — AI 에이전트가 행동하기 전에 쿼리할 수 있는 구조화된 저장소를 구축해, 결정이 최신 데이터에 근거하도록 보장.
온체인 데이터 그라운딩 — 검색 계층을 블록체인 인덱서에 연결해, LLM이 학습 시점 스냅샷이 아니라 현재 정보로 지갑 잔액, 거래 이력, 또는 스마트 컨트랙트 상태에 대한 질문에 답할 수 있게 함.

RAG 패턴을 포함하는 DecAIHub 프로젝트 카드의 전형적인 AI 구성요소 값에는 다음이 있습니다: "3D AI agents (RAG/memory/LLM catalog)", "AI summaries + crypto intelligence terminal", "AgentData (real-time data streams for AI agents)".

RAG는 모델이 아니다

흔한 오해는 RAG를 AI 모델의 한 유형으로 다루는 것입니다. 그렇지 않습니다. RAG는 아키텍처 패턴입니다 — 검색 시스템과 LLM을 결합하는 방식입니다. RAG 파이프라인 내부의 모델은 GPT, DeepSeek, Mistral, 또는 다른 어떤 LLM일 수 있습니다. 검색 구성요소는 벡터 데이터베이스, 검색 API, 또는 구조화된 지식 그래프일 수 있습니다.

"우리는 RAG를 사용한다"는 말은 시스템이 어떻게 조직되어 있는지 알려줍니다. 어떤 모델이 사용되는지, 독점인지, 검색 품질이 얼마나 좋은지는 알려주지 않습니다. 두 프로젝트가 모두 RAG를 주장하면서도 정교함 수준이 크게 다를 수 있습니다 — 하나는 세심하게 큐레이션된 지식 베이스와 커스텀 임베딩을 갖추고, 다른 하나는 관련 문서를 거의 반환하지 못하는 급조된 프로토타입일 수 있습니다.

RAG가 증명하지 못하는 것

RAG를 사용한다고 해서 기저 LLM이 독점이거나 파인튜닝되었다는 것이 증명되지 않습니다. 프로젝트는 제3자 API를 호출하고 있을 수 있습니다.
RAG 파이프라인을 구축한다고 해서 검색 품질이 높다는 것이 증명되지 않습니다. 품질은 지식 베이스, 청킹 전략, 임베딩 모델, 검색 관련성에 달려 있습니다.
RAG 아키텍처를 가지고 있다고 해서 답변이 정확하다는 것이 증명되지 않습니다. 부실한 검색은 무관한 컨텍스트를 공급할 수 있고, LLM은 여전히 환각할 수 있습니다.
랜딩 페이지에 RAG를 언급한다고 해서 시스템이 실제로 검색을 수행한다는 것이 증명되지 않습니다. Tier-1 증거 — 코드, 아키텍처 다이어그램, 데모 로그 — 없이 그 주장은 검증되지 않은 채로 남습니다. 크립토 AI 프로젝트가 RAG를 주장할 때 평가한다면, 구체성을 찾아보세요: 어떤 지식 베이스가 검색되는지, 어떤 임베딩 모델이 사용되는지, 관련성이 어떻게 측정되는지, 그리고 품질 지표가 공개되어 있는지.

DecAIHub 프로젝트 카드에서 나타나는 곳

RAG는 일반적으로 AI 구성요소 필드에서 참조됩니다 — 직접적으로, 또는 검색 + 생성 파이프라인을 암시하는 설명을 통해. AI_1 플래그는 AI 구성요소가 충분한 구체성으로 설명되었는지 확인합니다. 단지 "RAG"라고 쓰는 것으로는 충분하지 않습니다; 카드는 무엇이, 어디서, 어떤 목적으로 검색되는지 설명해야 합니다.

혼동하지 마세요

LLM — RAG 파이프라인 내부의 생성 엔진입니다. RAG는 그 위에 검색을 추가합니다.
학습 — RAG는 인퍼런스 시점 패턴입니다. 모델을 재학습하지 않고, 검색된 컨텍스트로 프롬프트를 증강합니다.
AI 에이전트 — 에이전트는 RAG를 자신의 도구 중 하나로 사용할 수 있지만, RAG만으로 시스템이 에이전트가 되지는 않습니다.
파인튜닝 — 파인튜닝은 학습 단계에서 모델 가중치를 조정합니다. RAG는 모델을 수정하지 않고 인퍼런스 시점에 외부 지식을 주입합니다.
검색 / 지식 계층 — 검색 구성요소는 RAG의 절반입니다. RAG는 순수 검색 위에 생성 단계를 추가합니다.

자주 묻는 질문

RAG와 파인튜닝의 차이는 무엇인가요?

파인튜닝은 특화 데이터셋으로 모델을 학습시켜 모델의 가중치를 영구적으로 변경합니다. 새 지식이 모델 자체의 일부가 됩니다. RAG는 모델을 그대로 두고 대신 쿼리 시점에 관련 문서를 공급합니다. 파인튜닝은 모델에 새 스타일이나 작업 형식을 가르치는 데 더 낫고; RAG는 답변을 신선하고 검증 가능한 사실에 근거시키는 데 더 낫습니다. 많은 프로덕션 시스템은 둘을 모두 사용합니다 — 파인튜닝된 모델이 톤과 형식을 처리하고 RAG가 최신 사실적 근거를 제공합니다.

RAG가 LLM을 더 정확하게 만드나요?

RAG는 모델의 출력을 검색된 증거에 근거시킴으로써 환각을 크게 줄일 수 있습니다. 그러나 정확도는 검색 품질에 달려 있습니다. 검색 시스템이 무관하거나 오래된 문서를 반환하면, LLM은 확신에 차서 틀린 답을 — 이제 잘못된 증거로 뒷받침된 채 — 산출할 수 있습니다. RAG는 정확도의 상한을 높이지만 보장하지는 않습니다. 검색 정밀도와 재현율을 측정하는 것은 진지한 모든 RAG 배포에 필수적입니다.

벡터 데이터베이스란 무엇인가요?

벡터 데이터베이스는 고차원 수치 벡터(임베딩)를 보유하고 검색하도록 설계된 특화 데이터 스토어입니다. 쿼리 임베딩이 제출되면, 데이터베이스는 유사도 검색을 수행합니다 — 일반적으로 HNSW나 IVF 같은 알고리즘을 사용해 — 가장 가까운 일치 벡터를 찾습니다. 이는 시맨틱 검색을 가능하게 합니다: 정확한 키워드 일치가 아니라 의미로 문서를 찾는 것입니다. 인기 있는 벡터 데이터베이스로는 Pinecone, Weaviate, Qdrant, Milvus, Chroma가 있습니다.

크립토 AI 프로젝트에서 RAG는 어떻게 사용되나요?

크립토 AI 프로젝트는 RAG를 사용해 LLM을 블록체인 특화 데이터에 연결합니다: 프로토콜 문서, 거버넌스 제안, 온체인 거래 이력, 실시간 가격 피드, 스마트 컨트랙트 소스 코드. 검색 계층은 이런 특화 출처를 검색해 LLM이 오래된 학습 지식에 의존하는 대신 현재 데이터로 도메인 특화 질문에 답하게 합니다. 이런 시스템의 품질은 크게 다릅니다 — 잘 인덱싱되고 큐레이션된 지식 베이스부터 유용한 컨텍스트를 거의 검색하지 못하는 최소한의 구성까지.

RAG는 온체인 데이터와 함께 작동할 수 있나요?

네. RAG 파이프라인의 검색 계층은 블록체인 인덱서, 서브그래프, 또는 온체인 분석 API에 연결할 수 있습니다. 사용자가 지갑 잔액, 거래 이력, 또는 스마트 컨트랙트 상태에 대해 물으면, 검색 시스템이 관련 온체인 데이터를 가져오고, LLM이 사람이 읽을 수 있는 설명을 생성합니다. 주요 과제는 지연(블록체인 쿼리가 느릴 수 있음), 데이터 포매팅(원시 온체인 데이터는 임베딩을 위해 파싱되고 청킹되어야 함), 신선도(인덱스가 현재 체인 상태를 반영할 만큼 자주 갱신되어야 함)입니다.

함께 보기

외부 참고 자료

Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv, 2020. https://arxiv.org/abs/2005.11401
Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv, 2024. https://arxiv.org/abs/2312.10997
AWS. "What is RAG?" https://aws.amazon.com/what-is/retrieval-augmented-generation/
Pinecone. "Retrieval-Augmented Generation (RAG)." https://www.pinecone.io/learn/retrieval-augmented-generation/
Microsoft. "Retrieval-Augmented Generation (RAG) in Azure AI Search." https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview