에이전틱 RAG — 스스로 검색을 계획하는 RAG의 등장

에이전틱 RAG(agentic RAG)는 검색-증강 생성(RAG)에 에이전트의 판단을 얹은 방식이다. 기존 RAG가 "질문이 오면 한 번 검색해서 그 결과로 답한다"는 직선 파이프라인이라면, 에이전틱 RAG는 모델이 스스로 무엇을, 몇 번, 어떻게 검색할지를 판단하며 필요하면 검색을 반복한다. 복잡한 질문 앞에서 단발 검색이 자꾸 헛발질하는 걸 보다가 나온 자연스러운 진화다.

기본 RAG는 훌륭하지만 약점이 뚜렷하다. 질문 한 번, 검색 한 번, 답 한 번. 이 구조는 질문이 단순할 때만 잘 돈다. "우리 회사 A제품과 B제품의 환불 정책 차이"처럼 두 가지를 각각 찾아 비교해야 하는 질문이 오면, 한 번의 검색으론 절반만 건지거나 둘이 뒤섞인 결과가 나온다.

기존 RAG의 한계

기본 RAG의 흐름은 이렇다. 질문을 임베딩해서 벡터 검색으로 유사한 문서 조각 몇 개를 가져오고, 그걸 프롬프트에 붙여 답하게 한다. 단순하고 강력하다. 하지만 이 구조엔 판단이 없다. 검색이 나쁜 결과를 가져와도 그냥 그걸로 답한다. 질문이 여러 하위 질문으로 쪼개져야 해도 통째로 검색한다. 처음 검색이 부족해도 재시도하지 않는다.

에이전틱 RAG가 하는 일

에이전틱 RAG는 검색을 도구로 취급하고, 모델에게 그 도구를 언제 어떻게 쓸지 맡긴다. 대략 이런 판단들이 추가된다.

• 질문 분해 — 복합 질문을 하위 질문으로 나눠 각각 검색한다.
• 재작성 — 사용자의 말 그대로가 아니라 검색에 잘 걸리도록 질의를 다듬는다.
• 출처 선택 — 벡터 검색만이 아니라, 이 질문엔 데이터베이스 조회가 맞는지 웹 검색이 맞는지 고른다.
• 충분성 판단 — 가져온 자료로 답할 수 있는지 스스로 보고, 부족하면 다시 검색한다.

나는 고객 지원 봇을 이 구조로 바꿨을 때 가장 큰 차이를 느꼈다. 예전엔 "결제와 배송 둘 다" 물으면 한쪽만 답했는데, 질문을 쪼개 각각 검색하게 하니 둘 다 제대로 답했다.

공짜가 아니다

대가는 명확하다. 검색을 여러 번 돌고 모델이 매번 판단하니, 지연과 비용이 늘고 시스템이 복잡해진다. 반복이 통제되지 않으면 같은 검색을 맴돌거나 엉뚱한 방향으로 파고들 수도 있다. 그래서 반복 횟수 상한, 검색 결과 재순위화, 그리고 "여기서 멈춰도 되는가"를 판단하는 종료 조건이 반드시 함께 가야 한다.

언제 쓸 것인가

모든 RAG를 에이전틱으로 바꿀 필요는 없다. 질문이 대체로 단순하고 단발 검색으로 충분하다면, 굳이 복잡성과 비용을 떠안을 이유가 없다. 에이전틱 RAG가 값을 하는 건 질문이 복합적이고, 여러 출처를 넘나들어야 하고, 한 번의 검색으로는 자주 실패하는 영역이다. 나는 항상 기본 RAG로 시작해서, "단발 검색이 자꾸 반쪽짜리 답을 낸다"는 신호가 쌓일 때 에이전틱으로 올린다.

자주 묻는 질문

에이전틱 RAG는 기본 RAG를 대체하나요?

대체가 아니라 확장이다. 내부에서 여전히 벡터 검색·재순위화 같은 RAG의 부품을 쓴다. 다만 그 위에 "언제 무엇을 검색할지" 판단하는 층을 얹은 것이다. 단순한 질문엔 기본 RAG가 더 빠르고 싸므로, 질문 성격에 따라 둘을 나눠 쓰거나 하나의 시스템 안에 함께 두는 게 보통이다.

검색을 반복하면 비용이 너무 오르지 않나요?

맞다, 그래서 통제가 필요하다. 반복 횟수에 상한을 두고, 매 반복에서 "지금 자료로 답할 수 있는가"를 판단해 충분하면 즉시 멈춘다. 또 쉬운 질문은 애초에 단발 경로로 보내는 라우팅을 두면, 비싼 반복 경로는 정말 필요한 복합 질문에만 쓰인다. 무한정 도는 걸 막는 게 설계의 핵심이다.

어떻게 시작하면 좋나요?

기본 RAG를 먼저 잘 만드는 게 순서다. 검색 품질(재순위화 포함)과 문서 조각화가 부실하면 에이전틱으로 감싸도 나쁜 결과를 여러 번 가져올 뿐이다. 기본이 탄탄해진 뒤, 자주 실패하는 복합 질문 유형을 골라 "질문 분해"와 "재검색"부터 얹는다. 처음부터 모든 판단을 넣기보다 실패 패턴을 보고 하나씩 붙이는 편이 안전하다.