AI가 틀린 말을 자신 있게 내뱉는 걸 본 적 있다면, 그 현상의 이름은 환각(Hallucination)이다. RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 이 문제를 정면으로 다루는 기술이다. 2025년 현재 RAG는 엔터프라이즈 AI의 사실상 표준 아키텍처로 자리 잡았으며, 시장 규모는 2030년까지 연평균 38.4% 성장이 예상된다. 트렌드가 아니라, AI를 실제로 쓸 만하게 만드는 핵심 기반 기술이다.
1. LLM은 왜 거짓말을 할까?
대규모 언어 모델(LLM, Large Language Model)은 방대한 데이터를 학습해 텍스트를 생성한다. 문제는 그 학습에는 반드시 끝이 있다는 것이다.
LLM이 학습을 마친 날짜 이후의 정보는 모델이 전혀 알 수 없다. 예를 들어, 2025년 1월에 학습이 완료된 모델은 그 이후의 정치 이슈, 기업 실적, 신기술 발표를 알지 못한다.
더 큰 문제는 모델이 “모른다”고 솔직히 말하는 대신, 그럴듯한 거짓 답변을 만들어내는 경향이 있다는 것이다. 구글이 Google Bard(현 Gemini)를 처음 공개했을 때 제임스 웹 우주망원경에 관한 오답을 당당히 내놨고, 이 사건은 구글 주가를 하루 만에 100억 달러 이상 떨어뜨렸다. 이것이 Hallucination의 현실적 파급력이다.
RAG는 이 문제에 대한 실용적인 해결책이다. 모델을 다시 학습시키는 게 아니라, 답변 생성 직전에 관련 정보를 외부에서 실시간으로 검색해 모델에게 건네주는 방식이다.
2. RAG란 정확히 무엇인가?
RAG(Retrieval-Augmented Generation)는 Meta AI Research(FAIR)의 Patrick Lewis 연구팀이 2020년 NeurIPS 논문 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」에서 처음 공식 제안한 개념이다.
쉽게 비유하면 이렇다. 아무것도 가져가지 못하는 시험이 기존 LLM이라면, RAG는 참고 자료를 꺼내 보면서 답을 작성하는 오픈북 시험에 가깝다. 단, 아무 자료나 보는 게 아니라 질문에 정확히 관련된 것만 골라서 본다.
3. RAG는 어떻게 작동할까?
RAG의 작동 원리는 크게 4단계로 나뉜다. 각 단계는 유기적으로 연결되어 있어, 앞 단계의 품질이 뒤 단계에 그대로 영향을 미친다.
Step 1 — 질문 벡터화 (Vectorization): 사용자의 질문을 수치 벡터로 변환한다. 이를 임베딩(Embedding)이라 부른다. 텍스트의 의미를 수치 공간에 표현하기 때문에, 정확히 같은 단어가 없어도 의미적으로 유사한 문서를 찾아낼 수 있다.
Step 2 — 관련 문서 검색 (Retrieval): 벡터 데이터베이스(Vector DB)에서 질문 벡터와 가장 유사한 문서 조각(Chunk)을 Top-K개 검색한다. 코사인 유사도(Cosine Similarity) 등 수학적 거리 계산으로 관련성을 판단한다.
Step 3 — 컨텍스트 증강 (Augmentation): 검색된 문서를 원래 질문과 함께 LLM의 프롬프트에 삽입한다. 이를 프롬프트 스터핑(Prompt Stuffing) 또는 컨텍스트 주입이라고 한다. LLM은 이 추가 정보를 기존 학습 데이터보다 우선 반영한다.
Step 4 — 근거 기반 답변 생성 (Generation): LLM이 주입된 컨텍스트를 바탕으로 답변을 생성한다. 이 과정에서 출처(Source Document)를 함께 인용할 수 있어, 사용자가 원본 문서를 직접 확인할 수 있다.
4. 코드로 보는 RAG 구현
말로만 설명하면 추상적이니, 실제로 Python과 LangChain으로 구현해보자. 아래 코드는 회사 내부 문서를 로컬 벡터 DB에 저장한 뒤, 질문에 맞는 문서를 검색해 GPT-4o로 답변을 생성하는 간단한 RAG 파이프라인이다.
# 필요 라이브러리 설치
# pip install langchain langchain-openai chromadb
from langchain.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA
# 1. 문서 로드 및 청킹(Chunking)
loader = TextLoader("company_docs.txt")
docs = loader.load()
splitter = RecursiveCharacterTextSplitter(
chunk_size=500, # 청크 크기 (토큰 수)
chunk_overlap=50 # 청크 간 중복 (문맥 보존)
)
chunks = splitter.split_documents(docs)
# 2. 벡터 임베딩 & DB 저장
embeddings = OpenAIEmbeddings()
vectordb = Chroma.from_documents(
documents=chunks,
embedding=embeddings,
persist_directory="./chroma_db"
)
# 3. RAG 체인 구성 (검색 + 생성)
llm = ChatOpenAI(model_name="gpt-4o", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
llm=llm,
chain_type="stuff",
retriever=vectordb.as_retriever(search_kwargs={"k": 3})
)
# 4. 질문 → 검색 → 답변
response = qa_chain.run("우리 회사 휴가 정책이 어떻게 되나요?")
print(response)• Chroma — 로컬 개발·프로토타이핑, 무료 오픈소스
• Pinecone — 완전 관리형 클라우드, 대규모 프로덕션에 적합
• Weaviate — 멀티모달 지원, 하이브리드 검색 강점
• FAISS (Meta) — CPU 기반 고속 검색, 경량 로컬 환경에 적합
코드에서 핵심은 chunk_size와 chunk_overlap 설정이다. 청크가 너무 크면 무관한 내용이 섞이고, 너무 작으면 문맥이 끊긴다. 실무에서는 청크 크기 300~800 토큰, 오버랩 10~15%가 일반적인 출발점이다.
5. RAG의 진화 — Naive에서 Agentic까지
RAG는 2020년 등장 이후 빠르게 진화했다. 2025~2026년 현재, RAG는 단순한 선형 파이프라인에서 벗어나 모듈형·에이전틱 단계로 접어들었다.
| 구분 | Naive RAG | Advanced RAG | Agentic RAG |
|---|---|---|---|
| 등장 시기 | 2020~2022 | 2023~2024 | 2025~ 현재 |
| 검색 방식 | 단순 유사도 검색 | 하이브리드 검색 + 리랭킹 | 자율적 다중 검색 |
| 파이프라인 | 고정 순차 처리 | 모듈형 파이프라인 | 반복·자기수정 루프 |
| 자율성 | 없음 | 부분적 | 완전 자율 에이전트 |
| 대표 사례 | 초기 ChatGPT 플러그인 | Microsoft Copilot | LangGraph, AutoGPT |
Agentic RAG는 현재 기술의 최전선이다. 자율 에이전트가 RAG 파이프라인에 직접 개입해 검색 전략을 스스로 결정하고, 결과를 평가한 뒤 필요하면 재검색을 수행한다. Self-RAG, Corrective RAG(CRAG) 같은 프레임워크가 대표적이다.
6. RAG vs Fine-tuning, 어느 쪽을 선택할까?
RAG와 함께 자주 비교되는 것이 Fine-tuning(파인튜닝)이다. 둘은 경쟁이 아니라 쓰임새가 다른 도구다.
- ✅ 데이터가 자주 업데이트됨
- ✅ 최신 정보 실시간 반영 필요
- ✅ 출처·근거 제시가 중요
- ✅ 비용·시간 효율 중시
- ✅ 기업 내부 문서 연동
- ✅ 특정 도메인 언어·스타일 학습
- ✅ 고정된 지식 베이스 활용
- ✅ 응답 형식 완전 커스터마이징
- ✅ 외부 DB 연결 불필요
- ✅ 추론 속도 최우선 시
데이터가 자주 바뀌거나 출처 제시가 중요하다면 RAG가 맞다. 특정 전문 도메인의 말투나 출력 형식을 완전히 바꾸고 싶다면 Fine-tuning을 검토한다. 두 기법을 함께 쓰는 것도 물론 가능하다.
7. 실제로 어디에 쓰이나?
RAG는 이미 우리가 매일 사용하는 서비스 안에 들어와 있다.
- Microsoft Copilot — GPT-4와 Bing 검색을 통합한 가장 대표적인 RAG 상용 사례. 답변마다 출처 링크를 각주 형태로 제공한다.
- Google AI Overviews — 검색 결과 상단에 AI가 생성한 요약 제공. Google의 검색 인덱스를 외부 지식 베이스로 활용한다.
- Perplexity AI — 검색과 생성의 결합에 특화된 AI 검색 엔진. 모든 답변에 실시간 웹 소스를 인용한다.
- 기업 내부 지식 베이스 — 사내 문서, 매뉴얼, CRM 데이터를 연결해 임직원용 AI 어시스턴트를 구축하는 데 가장 활발히 활용된다.
- 의료·법률·금융 — 정확성이 생명인 분야에서 최신 가이드라인, 판례, 규정을 실시간 검색해 전문가용 AI 서비스에 적용한다.
8. RAG 도입 전에 알아둬야 할 함정들
RAG가 만능은 아니다. 실제 구현에서 빠지기 쉬운 함정들이 있다.
9. 2025년 RAG 시장 규모와 앞으로의 방향
MarketsandMarkets에 따르면, 글로벌 RAG 시장은 2025년 19억 4천만 달러 규모에서 2030년까지 98억 6천만 달러로 성장할 것으로 전망되며, 연평균 성장률(CAGR)은 38.4%에 달한다. 금융, 의료, 법률, 고객 지원 분야가 가장 적극적인 도입 주체로 꼽힌다.
기술 방향으로는 멀티모달 RAG(텍스트·이미지·표 동시 검색), Graph RAG(지식 그래프 기반 관계형 검색), 그리고 Agentic RAG로의 진화가 빠르게 진행 중이다. 단순한 검색-생성 파이프라인에서, 스스로 계획하고 판단하는 지식 런타임(Knowledge Runtime)으로 발전하고 있다.
AI가 “모른다”고 하는 것이 미덕인 시대는 이미 지났다. RAG는 AI가 틀리지 않으면서도 최신 정보를 다루게 하는, 지금 당장 현장에서 쓸 수 있는 기술이다.