RAG(검색 보강 생성)가 대세인 이유: 최신 LLM의 한계를 어떻게 보완하는가

🧩 RAG가 대세인 이유: LLM의 한계를 보완하는 법

1. 왜 지금 RAG인가?

2024년 이후로 대형 언어모델(LLM)의 성능은 GPT-4o, Claude 3, Gemini 1.5 같은 초대형 모델로 정점을 찍었습니다.
하지만 여전히 “모델이 얼마나 많이 알고 있는가”보다 “얼마나 정확히 최신 정보를 가져올 수 있는가”가 더 중요한 시대입니다.

이 한계를 해결하기 위한 핵심 키워드가 바로 RAG(Retrieval-Augmented Generation), 즉 검색 보강 생성입니다.

2. LLM의 한계 — 단순히 모델을 키운다고 해결되지 않는다

📌 2.1 망각과 환각

LLM은 학습 시점 이후의 정보를 알 수 없고, 때로는 그럴듯한 거짓을 만들어냅니다.
이걸 흔히 “Hallucination(환각)”이라 부릅니다.

📌 2.2 비용과 지연

모델 파라미터 수가 커질수록 API 호출 비용과 응답 시간이 급격히 증가합니다.
실시간 챗봇 서비스에서는 치명적인 병목입니다.

📌 2.3 보안·프라이버시

내부 데이터를 학습 모델에 직접 집어넣을 수 없기 때문에, 사내 정보 보호형 챗봇에는 별도의 접근법이 필요합니다.

3. RAG란 무엇인가?

RAG는 LLM 앞단에 검색 계층을 붙여주는 방식입니다.

“모델이 기억하지 못하는 정보를, 검색 시스템이 찾아주고
모델은 그 결과를 바탕으로 답을 생성하는 구조.”

출처 : https://pureinsights.com/blog/2023/what-is-retrieval-augmented-generation-rag/


“사용자 질문 → 인덱스 검색 → 관련 문서 반환 → LLM이 생성” 흐름

🔹 주요 구성 요소

구성요소 역할
② Retriever 질문과 관련된 문서 검색
③ Vector DB 문서를 벡터화하여 저장
④ LLM Generator 검색된 문서를 바탕으로 응답 생성

4. 최신 동향과 도입 사례

  • 클라우드 플랫폼 RAG 강화 - Azure AI Search는 `agentic retrieval` 기능을 도입해, 복합 쿼리를 분해하고 병렬 검색을 실행하는 구조를 제공합니다. 기존 단일 쿼리 RAG 방식보다 응답 정확성 + 구조화된 결과 생성 가능성이 높아집니다.  
  • 복수 모달 + 멀티 코퍼스 RAG - UniversalRAG 논문은 텍스트 + 이미지 + 비디오 등 다양한 모달리티와 서로 다른 문서 소스를 동시에 다루는 방식 제시합니다. 질문에 따라 적절한 모달/소스를 선택하는 동적 라우팅 구조입니다.  
  • Agentic RAG & 추천 응용 - ARAG는 다중 에이전트를 활용해 사용자 선호도를 본문 문맥과 연결해 추천을 생성하는 방식입니다. 단순 RAG보다 추천 품질이 크게 좋아졌다는 평가가 있습니다.  
  • 응용 지향적 RAG+: RAG + 추론 결합 - RAG+는 검색된 지식뿐 아니라 응용 목적 기반 Reasoning 단계를 추가해 응답을 더 정교하게 만듭니다. 법률, 의료, 수학 등 응용 중심 도메인에서 성능 향상이 보고됩니다.  
  • 시장 성장 & 상업화 예측 - RAG 시장은 2025년 기준 약 **1.96 십억 달러** 규모이며, 2035년경엔 **40.34 십억 달러**까지성장할 것으로 예상됩니다.  
  • 공공 서비스 챗봇 도입 사례 - 인도 IIT-Kanpur + UP 경찰이 1,000여 개의 순환 문서를 바탕으로 한 RAG 챗봇을 배포했습니다. 시민들이 질문하면 관련 문서를 요약해 답해주는 시스템입니다.  
  • RAG 진화 흐름: 구조 복잡도 증가 - 단순 RAG를 넘어서, 복수 검색 소스, 쿼리 라우팅, 평가 기반 재검색 등이 RAG 시스템 내 필수가 되어가고 있습니다. “RAG는 죽었다”고 말하는 기사들도 있는데, 실제로는 더 복합적이고 진화된 형태로 재정의되는 중입니다. 

5. 개발자 관점에서 본 RAG 설계 포인트

💡 5.1 데이터 인덱싱 전략

  • 문서를 의미 단위로 쪼개서(chunking) 저장해야 검색 효율이 높습니다.
  • 일반적으로 chunk_size=800~1200, overlap=100~200 권장합니다.
  • 다양한 문서 형식(보고서, 문서, 코드, 이미지 설명 등)도 고려해야 합니다.

💡 5.2 검색 품질 → 생성 품질

  • 검색 결과가 좋지 않으면 생성 품질도 낮아집니다.
    → Retriever 튜닝이 성능의 70%를 결정합니다.
  • Baseline retrieval model→ Re-ranking / re-filtering 구조가 필수입니다.

💡 5.3 성능·지연 균형

  • 벡터DB: FAISS(로컬) / Pinecone, Milvus(클라우드)
  • 캐싱 전략 + 비동기 쿼리로 응답속도를 개선해야 합니다.

💡 5.4 보안

  • 민감 데이터는 인덱스 생성 시 암호화 또는 온프레미스 보관을 권장합니다.
  • 내부 인덱스는 온프레미스 또는 전용 인프라로 관리합니다

6. 코드 예시: Minimal RAG Pipeline

from langchain.embeddings import OpenAIEmbeddings
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.vectorstores import FAISS
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI

def build_rag_pipeline(documents: list[str], openai_api_key: str):
    embedder = OpenAIEmbeddings(openai_api_key=openai_api_key)
    splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
    docs = splitter.split_documents([{"page_content": d} for d in documents])
    vector_db = FAISS.from_documents(docs, embedder)

    qa_chain = RetrievalQA.from_chain_type(
        llm = OpenAI(temperature=0),
        chain_type = "stuff",
        retriever = vector_db.as_retriever(),
    )
    return qa_chain

if __name__ == "__main__":
    documents = [
        "서울은 한국의 수도이다.",
        "AI는 다양한 산업에서 활용된다.",
        "RAG는 검색과 생성을 결합한다."
    ]
    api_key = "YOUR_OPENAI_KEY"
    qa = build_rag_pipeline(documents, api_key)
    
    query = "RAG란 무엇인가?"
    answer = qa.run(query)
    print("Q:", query)
    print("A:", answer)

 

7. 앞으로의 전망

  • LLM들이 검색 기능을 기본 내장할 가능성이 높습니다.
  • RAG는 기업 내부 지식 연결 + Agent 기반 AI와 융합되는 방향으로 진화 중입니다.
  • 2025년 이후엔 RAG + 멀티모달 + 실시간 데이터 + 에이전트의 조합이 핵심 트렌드가 될 것입니다.

8. 결론

모델은 ‘기억’을 잘하지만, 현실의 최신 정보를 스스로는 알지 못합니다.
RAG는 이 간극을 메워주는 지식 보조 엔진입니다.
앞으로의 챗봇, 검색엔진, 개인 비서형 AI는 거의 모두 RAG 기반 구조로 나아갈 거고,
중요한 건 “어떻게 전략적으로 설계하느냐”가 경쟁력이 될 것입니다.

📚 참고자료

세야코
세야코
기록이 곧 성장

티스토리툴바