Google Research가 공개한 Agentic RAG: 부족한 정보를 끝까지 찾아내는 멀티 에이전트 검색

9bow · 6월 9, 2026, 3:30오전

Gemini Enterprise의 Agentic RAG 소개

검색 증강 생성(Retrieval-Augmented Generation, RAG)은 대규모 언어 모델(Large Language Model, LLM)이 학습하지 않은 사내 문서나 최신 데이터를 답변에 반영하기 위한 핵심 기법으로 자리 잡았습니다. 질문이 들어오면 관련 문서를 검색해 그 내용을 모델에 함께 넣어주는 방식인데, 이 덕분에 모델이 근거 없는 답을 지어내는 환각(hallucination)을 줄이고 출처에 기반한 답변을 만들 수 있습니다. 그러나 오늘날 기업에서 실제로 던지는 질문은 한 번의 검색으로 끝나지 않는 경우가 많습니다.

Google Research가 공개한 이번 글은 이런 한계를 정면으로 다룹니다. 기존의 단일 단계(single-step) RAG는 "여러 데이터 소스에 걸쳐 있고, 여러 단계를 거쳐야 답이 나오는" 질문을 처리하도록 설계되지 않았다는 문제의식에서 출발합니다. 이를 해결하기 위해 Google은 검색 과정을 계획하고, 추론하고, 데이터 소스와 반복적으로 상호작용하는 에이전틱 RAG(Agentic RAG) 를 Gemini Enterprise Agent Platform에서 교차 코퍼스 검색(Cross-Corpus Retrieval) 기능으로 제공한다고 발표했습니다.

이번에 Google Research가 공개한 글에서 가장 주목할 부분은 단순히 여러 에이전트를 붙였다는 점이 아니라, 시스템이 "지금 가진 정보로 정말 답할 수 있는가" 를 스스로 판단하는 충분한 컨텍스트 에이전트(Sufficient Context Agent) 라는 구성 요소입니다. Google은 표준 RAG 대비 사실성(factuality) 데이터셋에서 정확도가 최대 34% 향상되었으며, 내부 도메인 데이터셋에서도 더 나은 근거 기반(grounding)과 추론 정확도를 확인했다고 밝혔습니다. 본 게시물에서는 멀티 에이전트 RAG가 어떤 구조로 동작하는지, 무엇이 이 시스템을 다르게 만드는지, 그리고 실험 결과가 무엇을 보여주는지를 차례로 정리합니다.

단일 단계 RAG의 한계: 정보가 여러 섬으로 흩어져 있을 때

기존 RAG의 한계를 이해하려면 구체적인 질문 하나를 떠올리는 편이 빠릅니다. 원문은 "프로젝트 X에 사용된 서버의 사양은 무엇인가?" 라는 질문을 예로 듭니다. 단일 단계 RAG는 프로젝트 X에 관한 문서를 찾아낼 수는 있지만, 그 문서에는 서버의 ID만 적혀 있을 수 있습니다. 사양을 알려면 그 ID를 들고 다른 데이터베이스로 가서 두 번째 검색을 해야 하는데, 단일 단계 시스템은 그 두 번째 검색을 해야 한다는 사실 자체를 모릅니다. 결국 정보가 서로 다른 데이터의 "섬(island)"에 흩어져 있을 때, 시스템은 "부분적인 답" 이나 "찾을 수 없음" 이라는 응답을 내놓게 됩니다.

이 문제를 더 정확히 표현하면 두 가지 축으로 나눌 수 있습니다. 하나는 멀티홉(multi-hop), 즉 한 검색의 결과가 다음 검색의 입력이 되어 여러 단계를 거쳐야 답에 도달하는 경우입니다. 다른 하나는 멀티소스(multi-source), 즉 답에 필요한 조각들이 재무 데이터베이스, 프로젝트 관리 로그, 임상 노트처럼 서로 다른 출처에 흩어져 있는 경우입니다. 전통적인 RAG, 즉 흔히 "바닐라(Vanilla) RAG" 라 부르는 방식은 질문을 받아 매칭되는 문서를 한 번 찾고 그것으로 답변을 생성하는 구조이기 때문에, 이 두 축의 복잡도를 감당하기 어렵습니다.

에이전틱 RAG(Agentic RAG)는 바로 이 지점을 겨냥합니다. 검색을 단순한 한 번의 조회로 보지 않고, 계획을 세우고 추론하며 데이터 소스와 반복적으로 상호작용하는 에이전트(agent) 들의 협업으로 재구성합니다. 그 결과 복잡한 질의를 다룰 수 있게 되고, 답변의 신뢰도(dependability)와 정확도가 올라갑니다.

멀티 에이전트 RAG의 작동 방식: 검색을 하나의 연구 부서로 바라보기

멀티 에이전트 RAG를 이해하는 좋은 비유는 그것을 단일 검색 엔진이 아니라 조직화된 연구 부서로 보는 것입니다. "모놀리식(monolithic)" 또는 바닐라 RAG에서는 검색 컴포넌트가 질문을 보고 매칭되는 문서를 찾은 뒤, LLM이 응답을 생성하는 것으로 끝납니다. 반면 멀티 에이전트 프레임워크는 이 작업을 여러 전문 역할로 분담합니다. 원문이 설명하는 다섯 가지 역할은 다음과 같습니다.

오케스트레이터(Orchestrator): 복잡한 요청을 평가해 "이건 한 단계로 끝날 일이 아니다" 라고 판단하고, 작업을 하위 에이전트들에게 위임합니다.
플래너 에이전트(Planner Agent): 정보를 찾아갈 경로를 설계합니다. 예를 들어 어떤 프로젝트의 예산과 일정을 물으면, 플래너는 "먼저 재무 데이터베이스를 확인하고, 그다음 프로젝트 관리 로그를 확인해야 한다" 처럼 순서를 정합니다.
쿼리 리라이터(Query Rewriter): 사용자의 요청을 여러 개의 검색 쿼리로 번역합니다. "프로젝트 X는 어떻게 돼가나요?" 라는 모호한 질문을 "프로젝트 X의 3분기 상태 보고서", "프로젝트 X 팀의 핵심 병목" 같은 구체적 검색어로 바꿉니다.
검색 팬아웃 에이전트(Search Fanout Agent): 다듬어진 쿼리들을 받아 여러 검색 소스로 동시에 보내 정보 조각(snippet)을 수집합니다.
LLM 종합: 마지막으로 LLM이 모든 컨텍스트를 모아 최종 응답을 만들어냅니다.

이렇게 역할을 나누면, 질문을 던진 사람의 한 문장을 계획(planning), 재작성(rewriting), 라우팅(routing) 이라는 단계로 분해해 처리할 수 있습니다. 이 구조 자체는 HuggingFace의 멀티 에이전트 RAG 쿡북이나 LangGraph 기반의 오픈소스 구현처럼 이미 여러 프레임워크에서 시도되어 온 접근입니다. 그렇다면 Google의 방식은 무엇이 다를까요?

Google Agentic RAG의 차별점: 정보가 충분한지 스스로 아는 시스템

원문이 꼽는 핵심 차별점은 지속성(persistence) 입니다. 다른 RAG 솔루션과 비교했을 때, Google의 프레임워크가 효과적인 이유는 "자신이 정보를 빠뜨리고 있다는 사실을 알고, 컨텍스트가 완성될 때까지 검색을 계속한다" 는 점에 있습니다. 이 성질은 두 가지 흔한 실패를 막아줍니다. 하나는 첫 검색이 비었을 때 AI가 "추측(guessing)" 으로 답을 지어내는 것이고, 다른 하나는 정보가 분명히 어딘가에 있는데도 "정보가 충분하지 않습니다" 라며 너무 일찍 포기하는 것입니다. 물론 후자가 적절한 응답인 경우도 있지만, 정보가 실제로 존재한다면 그것을 끝까지 찾아내는 편이 옳습니다.

이 지속성을 실제로 가능하게 하는 장치가 바로 충분한 컨텍스트 에이전트(Sufficient Context Agent) 입니다. 이 구성 요소는 Google Research가 앞서 발표한 충분한 컨텍스트가 RAG에 미치는 역할에 관한 연구에서 출발합니다. 핵심 아이디어는 답변을 생성하기 전에 "지금 검색해 온 내용만으로 정확하고 근거 있는 답을 만들 수 있는가" 를 먼저 판정한다는 것입니다. 이 판정 단계가 있기 때문에 시스템은 부족함을 감지하고 다시 검색하는 루프를 돌 수 있습니다.

의사의 질문으로 따라가 보는 다섯 단계 동작 흐름

원문은 의료 현장의 까다로운 질문 하나로 전체 흐름을 보여줍니다. 어떤 의사가 다음과 같이 묻는 상황입니다.

"존 도(John Doe)가 무릎 수술을 받은 후의 퇴원 약물과 식이 제한은 무엇이며, 입원 기간 중 알레르기 반응이 있었는가? 단, 헤파린 IV 점적(heparin IV drip)이나 테넥테플라제(Tenecteplase)를 제외하고, 입원 또는 응급실 방문 중에만 투여된 약물은 포함하지 말 것."

하나의 질문 안에 약물, 식이, 알레르기라는 세 가지 정보 요구와 까다로운 예외 조건까지 섞여 있습니다. 이 질문이 들어오면 여러 전문 에이전트가 작동하기 시작합니다. 아래 그림은 Google이 제시한 전체 솔루션의 개요이며, 이어서 각 단계를 자세히 설명합니다.

1단계: 오케스트레이션, 작업을 쪼개고 위임하기

루트 에이전트(Root Agent)가 의사의 요청을 파싱하고 작업을 하위 에이전트들에게 위임합니다. 플래너 에이전트는 약국(Pharmacy), 영양(Nutrition), 임상 노트(Clinical Notes)라는 세 가지 서로 다른 영역을 확인해야 한다는 점을 식별합니다. 쿼리 리라이터는 길고 복잡한 요청을 검색기가 더 정확히 찾을 수 있도록 단순하고 검색 가능한 질문들로 쪼갭니다.

2단계: 검색, 한 번에 가능한 만큼 찾기

RAG 에이전트가 분해된 쿼리들을 한꺼번에 환자 기록에서 검색합니다. 약물과 식이 정보는 찾아내지만, 가장 눈에 띄는 파일들에서는 알레르기에 대한 언급을 찾지 못합니다. 바로 이 지점이 일반적인 바닐라 RAG와 갈리는 분기점입니다. 표준 RAG라면 여기서 불완전한 답변을 내놓으며 과정이 끝나버릴 수 있습니다.

3단계: 충분한 컨텍스트 에이전트, 답하기 전에 점검하기

충분한 컨텍스트 에이전트는 조립 라인의 끝에 서 있는 품질 검사관 에 비유할 수 있습니다. 응답이 생성되도록 허용하기 전에 다음 세 가지를 구체적으로 검사합니다.

1. 검색된 스니펫(Retrieved snippets): RAG 에이전트가 데이터베이스에서 실제로 끌어온 텍스트 청크(chunk)를 평가합니다. 의사의 사례라면 "퇴원 요약(Discharge Summary)"과 "영양 노트(Nutrition Notes)"에서 찾은 구체적인 문단들이 여기에 해당합니다. 에이전트는 이 문장들을 읽고, 질문에 답하는 데 필요한 정보가 실제로 그 안에 들어 있는지를 확인합니다.

2. 중간 초안(Intermediate draft): 시스템은 "러프한 초안(rough draft)" 응답도 함께 만듭니다. 충분한 컨텍스트 에이전트는 프롬프트, 초안, 검색된 스니펫을 함께 검토해 모델이 포괄적이고 근거 있는 답변을 내놓는 데 필요한 모든 것을 갖췄는지 평가합니다. 질문이 세 가지(약물, 식이, 알레르기)를 요구하는데 스니펫에는 두 가지 정보밖에 없다면, 에이전트는 이를 "불충분한 컨텍스트(insufficient context)" 로 표시합니다.

3. 빠진 조각 분석(Missing pieces analysis): 가장 중요한 부분입니다. 이 에이전트는 단순히 "불충분하다" 고 출력하는 데 그치지 않고, 무엇이 없는지를 정확히 짚어 구체적인 "이유(Reason)" 와 "피드백(Feedback)" 로그를 생성합니다. 예를 들어 발견: "약물 목록과 저염식 지침은 확보했다", 공백: "입원 중 알레르기 반응이나 이상 반응에 대한 원본 문서의 정보가 빠져 있다" 와 같은 식입니다.

충분한 컨텍스트 에이전트는 찾아낸 것과 원래 요청을 비교하며 "알레르기 질문에 답했는가?" 라고 묻습니다. 답하지 못했다면 "불충분한 컨텍스트" 신호를 보내고, "약물과 식이는 찾았지만 알레르기를 놓쳤다. 'rashes(발진)'나 'adverse events(이상 반응)'를 구체적으로 다시 검색하라" 처럼 구체적인 피드백을 제공합니다. 여러 소스가 얽힌 상황에서는 추가 정보를 요청하거나, 특정 소스가 질문과 무관하다고 판단할 수도 있습니다.

4단계: 반복, 빠진 조각을 다시 파고들기

충분한 컨텍스트 에이전트의 피드백 덕분에, 쿼리 리라이터는 "발진(rashes)" 을 겨냥한 새 검색을 만듭니다. 그러면 RAG 에이전트는 처음에는 그냥 지나쳤던 파일들을 더 깊이 파고들어 빠져 있던 정보를 찾아냅니다. 이 반복 루프가 바로 앞서 말한 지속성 의 실체입니다.

5단계: 종합, 검증된 답변 작성하기

충분한 컨텍스트 에이전트가 마지막으로 데이터를 한 번 더 점검합니다. 이제 약물, 식이, 알레르기 정보를 모두 확보했으므로 검색을 멈춰도 된다고 판단합니다. 마지막으로 종합 에이전트(Synthesis Agent)가 의사를 위한 깔끔하고 정확한 요약을 작성합니다.

더 알아보기: 충분한 컨텍스트(Sufficient Context)

Deeper insights into RAG: The role of sufficient context (영문 블로그)

Vanilla RAG vs Agentic RAG 비교 글 (영문)

실험과 결과: FramesQA로 검증한 멀티홉 추론과 교차 코퍼스 라우팅

Google은 이 시스템을 FRAMES 논문에 기반한 FramesQA 벤치마크에서 평가했습니다. FramesQA는 여러 단계를 거쳐야 답할 수 있는 멀티홉 질문들로 구성되어 있습니다. 원문이 든 예시는 다음과 같습니다.

"2024년 6월 기준으로 가장 많이 시청된 두 개의 TV 시즌 피날레 중, 어느 피날레가 가장 길게 방영되었으며 그 차이는 얼마인가?"

이 질문에 답하려면 RAG 시스템이 여러 단계를 밟아야 합니다. 먼저 가장 많이 시청된 두 피날레가 M*A*S*H와 Cheers의 것임을 식별하고, 각각의 방영 시간을 찾은 뒤, 그 길이의 차이를 계산해야 합니다. 바닐라 RAG나 충분한 컨텍스트가 없는 에이전틱 RAG에서는 다음과 같은 막다른 답변에 도달하기 쉽습니다.

"여러 번 검색했지만 M*A*S*H나 Cheers의 명시적인 방영 시간을 찾지 못했습니다. 문서에는 시청자 데이터는 있지만 분 단위나 시간 단위의 길이는 없습니다."

이것은 질문에 대한 답이 아닙니다. 반면 Google의 에이전틱 RAG는 먼저 TV 프로그램을 검색한 뒤, 쿼리 리라이터와 충분한 컨텍스트 에이전트를 활용해 M*A*S*H와 Cheers의 방영 시간을 겨냥한 표적 검색을 수행합니다. 그 결과 Gemini는 "M*A*S*H의 피날레는 150분으로 두 작품 중 가장 길었고, 약 98분간 방영된 Cheers의 피날레보다 52분 더 길었다" 는 정확한 답에 도달합니다.

Google은 이 능력을 대규모로 검증하기 위해 824개의 질의와 2,676개의 PDF 문서로 이뤄진 코퍼스에서 실험을 진행했습니다. 비교 기준이 되는 "바닐라" 설정에서는 고급 검색 엔진, LLM 파서, 리랭커(re-ranker)를 갖춘 Google의 RAG Engine을 사용했습니다. 그리고 이를 두 가지 에이전틱 RAG 설정과 비교했습니다.

설정	검색 대상	핵심 과제
바닐라 RAG	FramesQA 단일 코퍼스	고급 검색 + 리랭킹, 단일 단계
에이전틱 RAG (단일 코퍼스)	FramesQA 문서	계획, 재작성, 충분성 점검의 반복
에이전틱 RAG (교차 코퍼스)	FramesQA + 방해용 3개 데이터셋	플래너가 4개 후보 중 올바른 코퍼스 선택

교차 코퍼스 설정은 서로 다른 팀이 관리하는 별개의 데이터베이스 를 가진 기업 환경을 모사합니다. 플래너 에이전트가 4개의 가능성 중에서 올바른 코퍼스를 골라 검색 쿼리를 라우팅해야 하는 더 어려운 조건임에도, 시스템은 질문의 90.1%를 정확히 답했고 단일 코퍼스 정확도에 거의 근접했습니다. 정확도는 평가자 LLM(LLM-as-a-judge)이 시스템 응답을 데이터셋의 정답과 비교해 측정했습니다. 또한 단일 코퍼스와 교차 코퍼스 버전의 지연 시간(latency)은 평균적으로 3% 이내로 거의 같았습니다. 이는 에이전틱 RAG가 서로 무관한 여러 데이터 소스에 걸쳐 추론할 수 있으며, 더 유연한 검색 시나리오를 열어준다는 점을 보여줍니다.

마무리: 감사와 추적이 가능한 신뢰할 수 있는 AI를 향해

이번 발표의 의미는 고급 쿼리 계획, 라우팅, 그리고 충분한 컨텍스트 판정을 결합함으로써 AI가 생성한 응답을 감사 가능(auditable) 하고, 추적 가능(traceable) 하며, 근거에 기반(grounded) 한 형태로 만든다는 데 있습니다. 기업 환경에서는 "왜 이런 답이 나왔는가"를 설명할 수 있는지가 도입의 결정적 변수인데, 충분한 컨텍스트 에이전트가 남기는 이유 와 피드백 로그는 바로 그 설명 가능성을 위한 단서가 됩니다. 단순히 정확도 숫자를 올리는 것을 넘어, 검색이 언제 멈춰야 하는지를 시스템이 스스로 판단한다는 점이 실무적으로는 더 큰 차이를 만듭니다.

Agentic RAG 기능은 현재 Gemini Enterprise Agent Platform의 공개 미리보기(public preview)로 제공됩니다. RAG를 단일 검색에서 벗어나 계획하고 검증하는 에이전트들의 협업으로 재구성하려는 흐름은 Vertex AI를 비롯한 여러 플랫폼에서 점점 더 보편화되고 있으며, 검색 신뢰성이 곧 LLM 애플리케이션의 신뢰성으로 직결되는 만큼 앞으로의 전개를 지켜볼 만합니다.

Unlocking dependable responses with Gemini Enterprise Agent Platform’s Agentic RAG 원문 블로그

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다!
텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~