RAG를 검색하면 이제 Classic RAG, GraphRAG, Agentic RAG 같은 이름이 한꺼번에 나옵니다. 처음 보는 입장에서는 서로 완전히 다른 기술처럼 느껴질 수 있습니다.
하지만 공통된 질문은 단순합니다. “모델이 답하기 전에 어떤 정보를 어떻게 찾아서 전달할 것인가?”
Classic RAG: 관련 문서를 찾아서 읽힌다
가장 기본적인 RAG는 질문과 관련된 문서 조각을 검색해 LLM의 입력에 넣습니다. 사내 규정, 제품 매뉴얼처럼 외부 지식을 참고해야 하는 챗봇에서 자주 쓰입니다.
먼저 RAG의 기본 검색·생성 흐름을 이해하면 다른 변형도 훨씬 쉬워집니다.
GraphRAG: 관계 자체가 중요한 문제
문서 조각의 내용만 비슷한 것이 아니라 사람, 조직, 사건, 개념 사이의 관계가 중요할 때 그래프 구조를 활용할 수 있습니다.
예를 들어 “A 회사와 관련된 공급망 위험은 무엇인가?” 같은 질문은 여러 문서에 흩어진 엔터티와 관계를 연결해야 할 수 있습니다. GraphRAG 계열 접근은 이런 관계 구조를 검색과 요약에 활용합니다.
Agentic RAG: 검색도 하나의 행동이 된다
기본 RAG에서는 검색 절차가 비교적 고정되어 있습니다. Agentic RAG는 AI가 질문을 보고 어떤 검색을 할지, 추가 검색이 필요한지, 다른 도구를 사용할지 등을 더 능동적으로 결정하는 접근입니다.
즉 검색이 단순한 한 단계가 아니라 에이전트의 작업 중 하나가 됩니다.
더 복잡한 RAG가 항상 더 좋은 것은 아닙니다
작은 문서 모음에 단순 질문을 하는 서비스라면 기본 RAG로도 충분할 수 있습니다. 관계 그래프나 에이전트 루프를 추가하면 구축·운영 비용과 실패 가능성도 늘어납니다.
그래서 이름보다 먼저 확인할 것은 문제입니다.
- 질문이 단순 검색으로 해결되는가?
- 문서 사이 관계를 연결해야 하는가?
- 검색 전략을 상황에 따라 바꿔야 하는가?
문제가 복잡해질 때 그에 맞는 구조를 선택하는 것이 핵심입니다.