RAG 2.0: 단순 검색을 넘어 AI가 스스로 판단하는 고급 검색 시스템

AI

RAGAgentic RAGGraph RAGLLM검색 증강 생성

이 글은 누구를 위한 것인가

  • "우리 회사 문서를 AI가 찾아서 답변해주는 시스템"을 만들고 싶은 분
  • RAG를 구축했는데 환각(Hallucination)이나 검색 품질 문제로 고민 중인 개발자
  • Agentic RAG, Graph RAG가 무엇인지 궁금한 AI 엔지니어

들어가며

"우리 사내 문서를 AI에게 학습시켜서 질문에 답하게 하고 싶어요."

이 요청을 받으면 대부분의 팀이 RAG를 구축한다. 문서를 벡터로 변환해서 저장하고, 질문이 오면 관련 문서를 검색해 AI에게 넘겨주는 방식이다. 구현하기 비교적 쉽고 빠르게 결과를 볼 수 있어 인기다.

그런데 몇 달 써보면 한계가 드러난다. "이 계약서에서 해지 조건이 뭐야?"라는 질문에 엉뚱한 조항을 찾아오거나, 여러 문서에 걸쳐있는 정보는 제대로 종합하지 못한다. 그리고 여전히 환각이 생긴다.

이 한계를 넘는 것이 Agentic RAG와 Graph RAG다.

1. 기본 RAG의 작동 방식과 한계

기본 RAG는 이렇게 작동한다.

1. 준비 단계:
   문서 수집 → 청크(조각)로 분리 → 벡터 임베딩 변환 → 벡터 DB 저장

2. 질의 단계:
   사용자 질문 → 질문 벡터화 → 유사한 청크 N개 검색 → LLM에 컨텍스트로 전달 → 답변 생성

간단하고 효과적이지만, 세 가지 근본적인 한계가 있다.

한계 1: "가장 유사한 것"이 "가장 관련 있는 것"이 아닐 수 있다 벡터 유사도는 의미적으로 비슷한 텍스트를 찾지만, 논리적으로 연관된 정보를 항상 찾아주지는 않는다. "환불 정책"을 묻는데, "교환 정책" 문서가 벡터 유사도가 높아서 검색될 수 있다.

한계 2: 여러 문서에 걸친 정보를 종합하지 못한다 "A 계약서와 B 계약서의 배상 조건을 비교해줘" 같은 요청은 두 문서를 동시에 참조해야 하는데, 기본 RAG는 단순히 가장 유사한 청크만 가져온다.

한계 3: 복잡한 질문은 한 번의 검색으로 부족하다 "올해 매출이 작년보다 늘었는지, 그 이유가 무엇인지 분석해줘"는 매출 데이터도 찾고, 사업 환경도 찾고, 이를 종합해 분석하는 여러 단계가 필요하다.

2. Agentic RAG: AI가 검색 전략을 스스로 결정

Agentic RAG는 AI 에이전트가 검색 과정 자체를 관리한다. 단순히 "질문과 유사한 것 찾기"가 아니라, 어떤 정보가 필요한지 스스로 판단하고, 필요하면 여러 번 검색하며, 정보가 부족하면 추가 검색을 요청한다.

[기본 RAG]
질문 → 검색 1회 → 답변 (고정 흐름)

[Agentic RAG]
질문
  → AI: "이 질문에 답하려면 어떤 정보가 필요한가?" 판단
  → 검색 1: 직접 관련 정보 찾기
  → AI: "정보가 충분한가? 계약 조건이 맞는지 확인 필요"
  → 검색 2: 추가 확인 정보 찾기
  → AI: "이제 충분하다. 종합해서 답변"
  → 답변 생성

핵심은 검색 횟수와 전략이 유연하다는 것이다. 간단한 질문은 1번 검색으로 끝내고, 복잡한 질문은 여러 번 검색해 정보를 쌓아간다.

쿼리 분해 (Query Decomposition)

복잡한 질문을 하위 질문으로 분해하는 기법이다.

원래 질문: "2025년에 가장 많이 팔린 상품 3개와 그 재고 현황을 알려줘"

분해된 하위 질문:
1. "2025년 판매량 기준 상위 상품은?"
2. "1번 결과의 각 상품 현재 재고는?"

각 하위 질문에 대해 검색 → 결과 종합 → 최종 답변

3. Graph RAG: 관계를 알면 더 정확해진다

Graph RAG는 Microsoft Research가 2024년 발표한 방식이다. 문서를 단순 벡터로 저장하는 것이 아니라, 문서 속 개체(Entity)들과 그 관계를 지식 그래프로 구성한다.

[기존 벡터 RAG 저장 방식]
텍스트 조각 → 벡터 → 벡터 DB
(관계 정보 없음)

[Graph RAG 저장 방식]
텍스트 분석
  → 개체 추출: 김철수(직원), 프로젝트A, 클라이언트B
  → 관계 추출: 김철수 [담당] 프로젝트A, 프로젝트A [관련] 클라이언트B
  → 지식 그래프로 저장 (Neo4j, Amazon Neptune 등)

지식 그래프가 있으면 "프로젝트A를 담당하는 직원이 관리하는 다른 클라이언트는?" 같은 관계 추론 질문에 정확하게 답할 수 있다.

Graph RAG가 특히 강한 케이스

  • 조직 내 인물, 프로젝트, 문서 간 관계 파악
  • 의료 기록에서 약물 상호작용 파악
  • 법률 문서에서 조항 간 의존성 파악
  • 특허 문서에서 기술 계보 추적

Graph RAG의 단점: 그래프 구축에 시간이 걸리고, 데이터가 자주 변하는 환경에서 유지보수가 어렵다.

4. 하이브리드 검색: 벡터 + 키워드의 결합

벡터 검색(의미 기반)과 BM25(키워드 기반) 검색을 결합하면 두 방식의 장점을 모두 취할 수 있다.

질문: "계약 해지 위약금 조항"

벡터 검색 결과: 의미적으로 유사한 문서들 (계약 종료 관련)
BM25 검색 결과: "위약금"이라는 키워드가 정확히 포함된 문서들

결합 전략 (RRF: Reciprocal Rank Fusion):
두 검색 결과를 순위 기반으로 통합
→ 의미적으로도 관련있고 키워드도 포함된 문서가 상위에 오름

특히 전문 용어나 고유명사가 많은 법률, 의료, 기술 문서에서 하이브리드 검색이 순수 벡터 검색보다 크게 우수하다.

5. RAG 평가: RAGAS 프레임워크

RAG를 구축했다면 얼마나 잘 작동하는지 측정해야 한다. RAGAS(RAG Assessment) 프레임워크는 네 가지 지표를 제공한다.

지표측정 내용좋은 값
Faithfulness답변이 검색된 문서에 기반하는가 (환각 측정)0.8 이상
Answer Relevancy답변이 질문에 관련 있는가0.8 이상
Context Precision검색된 문서 중 실제 관련 있는 비율0.7 이상
Context Recall필요한 정보가 실제로 검색됐는가0.7 이상
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall

dataset = # 평가용 Q&A 데이터셋
result = evaluate(
    dataset=dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall]
)
print(result)
# {'faithfulness': 0.83, 'answer_relevancy': 0.79, ...}

6. 한국어 RAG의 특수성

영어 기반 RAG를 그대로 한국어에 적용하면 성능이 떨어진다.

한국어 특수 고려사항

  1. 형태소 분석 필요: 한국어는 조사, 어미가 붙어서 형태가 다양하다. "환불한다", "환불하다", "환불하는" 모두 같은 의미지만 다른 토큰이다. 형태소 분석기(KoNLPy, Kiwi)로 원형을 추출해야 한다.

  2. 임베딩 모델 선택: text-embedding-3-small 같은 영어 중심 모델은 한국어 임베딩 품질이 낮다. BAAI/bge-m3, upskyy/bge-m3-korean 같은 한국어 특화 또는 다국어 모델이 유리하다.

  3. 청크 크기: 한국어는 같은 의미를 영어보다 적은 문자로 표현하는 경우가 많다. 영어 기준 청크 크기를 그대로 적용하면 너무 많은 정보가 잘릴 수 있다.

7. 실무 RAG 구축 시 자주 만나는 문제

문제원인해결책
엉뚱한 문서가 검색됨임베딩 품질 부족더 나은 임베딩 모델로 교체, 청크 크기 조정
답변이 질문과 동떨어짐검색-생성 간 연결 부족쿼리 재작성(Query Rewriting) 추가
환각이 계속 발생LLM이 컨텍스트를 무시프롬프트 강화, Faithfulness 메트릭으로 측정 후 개선
검색 속도가 느림벡터 DB 인덱싱 미흡HNSW 인덱스 최적화, 필터링 선행 적용
문서 업데이트 반영 안 됨인크리멘탈 인덱싱 부재변경 감지 + 부분 재인덱싱 파이프라인 구축

맺으며

RAG는 "AI에게 우리 데이터를 가르치는" 가장 현실적인 방법이다. 모델을 파인튜닝하는 것보다 빠르고, 데이터를 업데이트하기도 쉽다.

기본 RAG로 시작해서 문제가 생기면 고급 기법을 추가하는 접근이 좋다. 완벽한 시스템을 처음부터 만들려 하지 말고, 가장 자주 발생하는 문제 하나씩 해결해나가자. RAGAS로 측정하고, 개선하고, 다시 측정하는 사이클이 RAG 품질을 높이는 가장 확실한 방법이다.