Agentic RAG: 검색을 스스로 판단하는 에이전트

RAG는 LLM의 답을 실제 데이터에 근거 지어 품질과 신뢰성을 높이는 기법이다. 여기에 에이전트를 얹으면 Agentic RAG가 된다. 단순히 검색해서 답하는 데 그치지 않고, LLM이 어떤 지식 소스를 쓸지, 어떻게 답할지 스스로 판단한다.

 

1. RAG 빠른 복습

RAG(Retrieval-Augmented Generation)는 질문을 그대로 프롬프트에 넣는 대신, 벡터 데이터베이스에서 관련 데이터를 검색해 맥락으로 덧붙인 뒤 LLM에 넘긴다. 그러면 LLM이 구체적이고 정확한 정보에 근거해 답하게 되어 환각이 줄고 신뢰성이 올라간다.

그림 1. 기본 RAG. 검색 결과를 맥락으로 붙여 LLM이 근거 있는 답을 만든다.

 

그런데 일반 RAG는 LLM을 딱 한 번, 생성에만 쓴다. 검색은 무조건 같은 방식으로 이뤄진다.

 

 

2. Agentic RAG — LLM을 "에이전트"로

Agentic RAG는 LLM을 단순 생성기가 아니라 결정을 내리는 에이전트로 쓴다. 질문의 맥락에 따라 이런 것들을 스스로 판단한다.

• DB가 여러 개라면 어떤 벡터 DB를 검색할지.
• 답을 텍스트로 줄지, 차트·코드로 줄지.
• 가진 소스로 답할 수 없으면 어떻게 처리할지(fail-safe).

예시 — 다중 소스 라우팅

지식 소스가 둘 있다고 하자. 내부 문서(정책·절차·가이드라인)와 일반 지식(업계 표준·모범 사례·공개 자료). 에이전트는 LLM의 언어 이해로 질문을 해석해 알맞은 DB로 라우팅한다.

• "회사의 명절 기간 원격근무 정책은?" → 내부 문서로.
• "테크 기업의 원격근무 업계 표준은?" → 일반 지식으로.
• "2015년 월드시리즈 우승팀은?" → 두 소스와 무관 → fail-safe로 보내 "해당 정보가 없습니다" 응답.

그림 2. Agentic RAG. 에이전트가 질문을 해석해 알맞은 지식 소스로 라우팅하고, 없으면 fail-safe로 보낸다.

 

이 라우팅은 우리가 앞서 배운 LangGraph의 조건부 엣지와 정확히 같은 구조다. 에이전트(노드)가 질문을 보고 다음에 어떤 검색 노드로 갈지 결정하는 route 함수를 두면 된다.

 

 

3. 어디에 쓰나

Agentic RAG는 여러 지식 소스를 넘나드는 현장에 잘 맞는다. 고객 지원(문의 유형에 따라 다른 지식베이스)과 리걸텍(변호사가 한 질문은 내부 브리프에서, 다른 질문은 공개 판례 DB에서)이 대표적이다. 에이전트가 최적의 소스를 스스로 고르고, 필요하면 실시간 데이터·외부 서비스까지 끌어와 더 정확하고 적응적인 파이프라인을 만든다.

 

여기까지가 Agentic AI의 개념부터 LangGraph 구현, 자기개선(Reflection·Reflexion), 멀티 에이전트, Agentic RAG까지의 핵심 흐름이다. 이어지는 편에서는 AI 에이전트의 종류와 Agentic AI의 위험·거버넌스를 정리한다.