「충분한가」를 판단하는 것 ― Agentic RAG (RAG 제4회)

지난 회차까지는 검색 도구들을 살펴보았습니다.

BM25.

벡터 검색 (Vector Search).

RRF.

grep.

reranker.

모두 빠질 수 없는 요소들입니다.

하지만 RAG의 문제는 검색기를 선택한다고 해서 끝나는 것이 아닙니다.

정말로 어려운 것은 다음의 질문입니다.

'이 정보로 이제 답변해도 되는가.'

'아직 부족한가.'

'부족하다면, 다음에 무엇을 찾아야 하는가.'

여기에 Agentic RAG의 입구가 있습니다.

Agentic RAG는 'RAG에 Agent를 붙인다'라는 이름만 보면 조금 화려하게 들릴 수 있습니다.

많은 agent가 역할을 분담하고, query를 재작성하며, 여러 데이터 소스를 탐색하고, 마지막에 답을 정리합니다.

물론 그것도 하나의 형태입니다.

하지만 본질은 훨씬 더 담백합니다.

한 번 검색해서 답하는 것이 아니라, 부족하면 다시 조사한다.

그리고, 답하기 전에 「정보가 충분한가」를 확인한다.

제4회에서는 Agentic RAG를 이러한 관점에서 정리합니다.

일반적인 RAG는 대략 다음과 같이 동작합니다.

질문을 받음
검색함
상위 문서를 가져옴
...

이 형태는 단순한 질문에는 효과적입니다.

"이 사양서에서 API 인증 방식은 무엇인가"

"이 의사록에서 결정된 다음 마감일은 언제인가"

"이 에러 코드에 대한 설명은 어디에 있는가"

필요한 정보가 하나의 문서, 혹은 소수의 문서에 모여 있다면 단발성 RAG로도 충분한 경우가 많습니다.

하지만 현실의 질문은 금방 복잡해집니다.

예를 들어, 기업 내부에서 다음과 같은 질문을 받았다고 가정해 봅시다.

"Project X의 운영 서버 스펙은 현재 부하를 감당하기에 충분합니까?"

이 질문에 답하기 위해서는 하나의 문서만으로는 부족합니다.

Project X의 설계 자료에는 서버 ID가 있습니다.

인프라 대장에는 해당 서버의 CPU와 메모리가 있습니다.

모니터링 대시보드에는 최근의 부하 데이터가 있습니다.

장애 보고서에는 과거의 병목 현상이 있습니다.

운영 규칙에는 허용 한계치가 있습니다.

첫 번째 검색에서 Project X의 자료만 찾아낸다면 답을 낼 수 없습니다.

그곳에는 서버 ID만 적혀 있을 수도 있기 때문입니다.

단발성 RAG는 여기서 멈추기 쉽습니다.

관련 문서는 찾았다. 하지만 답에 필요한 정보는 아직 부족하다.

그런데도 모델이 그 단편적인 정보만 보고 답해버립니다.

이것이 위험합니다.

찾아낸 것과 답변할 수 있는 것은 다릅니다.

Agentic RAG의 핵심은 검색 횟수를 늘리는 것이 아닙니다.

중요한 것은 검색 결과를 본 뒤에, 한 번 더 판단을 거치는 것입니다.

이 근거로 답변할 수 있는가?

답변할 수 있다면 생성(Generation)으로 진행합니다.

부족하다면 무엇이 부족한지를 언어화하여 다음 검색으로 돌립니다.

이 「무엇이 부족한지에 대한 판단」이 들어가는 것만으로도 RAG는 완전히 다른 것이 됩니다.

예를 들어, 첫 번째 검색에서 Project X의 설계 자료가 발견되었다고 합시다.

그곳에는 server-prod-17이라는 ID만 적혀 있습니다.

일반적인 RAG는 그 자료를 근거로 답하려고 할지도 모릅니다.

Agentic RAG에서는 여기서 멈춥니다.

현재 있는 정보:

Project X의 운영 서버 ID는 server-prod-17

부족한 정보:

server-prod-17의 CPU / 메모리
최근 부하
허용 한계치
...

다음에 찾아야 할 것:

인프라 대장에서 server-prod-17을 검색한다
모니터링 데이터에서 최근 30일간의 부하를 확인한다
장애 보고서에서 server-prod-17을 찾는다

이처럼 검색 결과를 그대로 답에 사용하는 것이 아니라, 다음 조사 계획으로 전환합니다.

이것이 Agentic RAG의 강점입니다.

이 방향성을 알기 쉽게 보여주는 것이 Google Research와 Google Cloud가 2026년 6월 5일에 공개한 Gemini Enterprise Agent Platform의 Agentic RAG입니다.

중요한 것은 이름에 Agent가 들어있다는 사실이 아닙니다.

핵심은 Sufficient Context Agent라는 역할입니다.

한국어로 말하자면, 「이 문맥으로 충분한가」를 확인하는 검사역입니다.

이 메커니즘에서는 검색한 단편을 그대로 합성(Synthesis) 단계로 넘기지 않습니다.

먼저 검색 결과와 중간 생성물을 보고, 답변을 위한 정보가 충분한지 확인합니다.

충분하다면 최종 답변으로 진행합니다.

부족하다면 어떤 정보가 결여되었는지를 명확히 하여 다음 검색으로 돌립니다.

이 설계는 단순하지만, 실무에서 상당히 효과적입니다.

RAG의 실패에는 두 가지 종류가 있습니다.

하나는 아무것도 찾지 못하는 실패입니다.

다른 하나는, 조금 찾아낸 탓에 정보가 부족한 상태로 답변해 버리는 실패입니다.

후자가 더 위험할 때가 있습니다.

왜냐하면, 모델이 "그럴듯한 근거"를 가지고 있기 때문입니다.

완전히 비어 있다면 "모르겠습니다"라고 말할 수 있을지도 모릅니다.

하지만 근거가 절반만 있다면, 나머지를 추측으로 채워버리는 경우가 있습니다.

Sufficient Context Agent의 가치는 바로 여기에 있습니다.

그것은 답을 만드는 agent가 아닙니다.

답변해도 되는지를 제어하는 agent입니다.

Google의 예시에서는 여러 가지 역할이 등장합니다.

전체를 편성하는 역할.

정보의 경로를 생각하는 역할.

query를 재작성(rewrite)하는 역할.

여러 검색을 병렬로 던지는 역할.

문맥이 충분한지 확인하는 역할.

마지막으로 답을 합성하는 역할.

이렇게 쓰면 상당히 거창해 보일 수 있습니다.

하지만 개인이나 작은 프로젝트에서 처음부터 전부를 만들 필요는 없습니다.

중요한 것은 agent의 수가 아니라, 역할을 섞지 않는 것입니다.

검색하는 역할.

읽는 역할.

부족함을 확인하는 역할.

답변하는 역할.

이 네 가지를 머릿속에서 나누는 것만으로도 설계는 달라집니다.

예를 들어, 일반적인 RAG에서는 검색 결과가 LLM에 전달되고, 그대로 답변이 생성됩니다.

Agentic RAG에서는 답변하기 전에 다음과 같은 체크를 넣습니다.

질문에 포함된 조건을 모두 확인했는가
필요한 수치, 날짜, 고유명사는 원문에서 확인했는가
여러 정보원이 필요한 질문이라면, 그 양쪽을 모두 확인했는가
...

이를 별도의 agent로 구성해도 좋습니다.

같은 모델에게 별도의 단계(step)로서 수행하게 해도 좋습니다.

규칙 기반(rule-based) 체크를 섞어도 좋습니다.

구현 형태는 다양합니다.

본질은 생성 전에 "검수"를 두는 것입니다.

Agentic RAG에 대한 설명에서는 query rewrite가 자주 등장합니다.

사용자의 질문을 분해한다.

검색하기 쉬운 형태로 바꾼다.

여러 개의 query로 나눈다.

다른 방식으로 다시 찾는다.

이것이 핵심입니다.

단, query rewrite 자체가 목적은 아닙니다.

목적은 부족한 정보에 도달하는 것입니다.

첫 번째 검색에서 답변에 필요한 정보가 일부만 발견되었다면,

그때 무엇이 부족한지를 보고 다음 query를 만듭니다.

이것이 핵심입니다.

예를 들어, 질문이 다음과 같다고 가정해 봅시다.

이 계약은 중도 해지 시 환불 조건을 충족합니까?

처음에 계약서의 "해지" 조항이 발견되었습니다.

하지만 환불 조건에는 "이용 시작일", "최소 이용 기간", "통지 기한", "예외 조항" 등이 연관되어 있습니다.

이때 다음에 찾아야 할 query는 단순히 해지가 아닙니다.

환불
최소 이용 기간
통지 기한
...

나아가 계약서뿐만 아니라 신청서나 청구 이력도 확인해야 할 수도 있습니다.

query rewrite는 이러한 부족함으로부터 생겨나야 합니다.

처음부터 화려하게 query를 늘리는 것이 아닙니다.

그렇다면 어떤 때에 Agentic RAG가 필요할까요?

크게 네 가지가 있습니다.

첫 번째는 멀티홉(multi-hop) 질문입니다.

하나의 문서에 답이 없습니다.

문서 A에서 ID를 찾고, 문서 B에서 사양을 찾고, 문서 C에서 현재 값을 확인하는 식입니다.

이런 질문들입니다.

두 번째는 다중 소스(multi-source) 질문입니다.

정보가 여러 시스템에 나뉘어 있습니다.

사내 wiki, 티켓, 로그, DB, 스프레드시트, 이메일 등.

어디를 봐야 할지부터 판단해야 합니다.

세 번째는 부족한 정보를 파악해야 하는 질문입니다.

법률, 의료, 금융, 보안, 인프라 운영처럼 조건의 누락이 위험한 영역입니다.

하나의 근거만으로 답변하면 사고로 이어질 수 있습니다.

네 번째는 답변의 근거를 나중에 추적하고 싶은 상황입니다.

왜 그런 결론에 도달했는지.

어떤 문서를 보았는지.

어떤 정보는 찾지 못했는지.

어디에서 추가 검색을 했는지.

이러한 추적(trace)이 필요한 상황에서는 단발성 RAG보다 Agentic RAG가 설계하기 쉽습니다.

반대로 Agentic RAG가 필요 없는 상황도 있습니다.

질문이 단순하고 답이 하나의 문서에 있는 경우.

검색 대상이 작은 경우.

지연 시간(latency)을 늘리고 싶지 않은 경우.

비용을 억제하고 싶은 경우.

답변 실패의 비용이 낮은 경우.

사용자가 검색 결과를 보면서 스스로 판단할 수 있는 경우.

이 경우에는 일반적인 RAG로 충분합니다.

Agentic RAG는 검색을 늘립니다.

LLM 호출도 늘어납니다.

구현도 복잡해집니다.

실패의 종류도 늘어납니다.

예를 들어, Sufficient Context Agent가 지나치게 신중하면 언제까지나 검색을 계속합니다.

반대로 너무 관대하면 결국 정보가 부족한 채로 답변하게 됩니다.

Planner가 잘못된 데이터 소스를 선택하면 검색 횟수만큼 낭비가 늘어납니다.

query rewrite (쿼리 재작성)가 너무 넓게 퍼지면 노이즈도 늘어납니다.

따라서 Agentic RAG는 "고급 기술이니까 도입한다"는 것이 아닙니다.

단발성 RAG로는 부족한 이유가 있을 때 도입하는 것입니다.

구현을 고민한다면 처음부터 복잡한 multi-agent (멀티 에이전트) 구성으로 할 필요는 없습니다.

최소 구성은 다음의 3단계로 충분합니다.

1. retrieve (검색)
2. check sufficiency (충분성 확인)
3. answer or search again (답변 또는 재검색)

먼저 검색합니다.

다음으로, 현재의 근거로 답변할 수 있는지 확인합니다.

부족하다면 부족한 부분을 명시하여 다시 한번 검색합니다.

충분하다면 답변합니다.

이때, check sufficiency (충분성 확인)의 출력은 가능한 한 구조화하는 것이 좋습니다.

status: sufficient / insufficient
known_facts:
missing_facts:
...

이것만으로도 RAG는 상당히 다루기 쉬워집니다.

중요한 것은, 단순히 "부족하다"라고 말하는 것만으로는 불충분하다는 점입니다.

무엇이 부족한가.

왜 그것이 필요한가.

다음에 무엇을 찾아야 하는가.

이 정도까지 도출하지 않으면 다음 검색으로 이어지지 않습니다.

Agentic RAG에는 독자적인 실패 유형도 있습니다.

첫 번째는 과도한 검색 문제입니다.

정보가 부족하다고 판단할 때마다 검색을 늘리면 비용과 지연(latency)이 불어납니다.

게다가 검색을 늘린다고 해서 반드시 정확해지는 것도 아닙니다.

노이즈도 함께 늘어나기 때문입니다.

두 번째는 질문을 너무 넓게 확장하는 문제입니다.

query rewrite (쿼리 재작성)가 잘 이루어지는 것처럼 보여도, 너무 넓게 확장하면 다른 주제를 건드리게 됩니다.

최초의 질문에서 벗어난 자료가 섞이게 되고, 모델이 그쪽으로 끌려가게 됩니다.

세 번째는 검사역의 과신입니다.

Sufficient Context Agent도 LLM입니다.

충분한지 여부에 대한 판단을 틀릴 때가 있습니다.

따라서 중요한 영역에서는 체크 기준이나 평가 데이터가 필요합니다.

네 번째는 trace (추적)가 남지 않는 문제입니다.

Agentic RAG는 여러 단계로 이루어집니다.

어떤 query (쿼리)를 던졌는가.

어떤 문서를 보았는가.

어디에서 충분하다고 판단했는가.

어떤 정보를 찾지 못했는가.

이를 남겨두지 않으면 나중에 검증할 수 없습니다.

Agentic RAG는 RAG를 똑똑하게 만드는 메커니즘인 동시에, 운영 대상이기도 합니다.

도입하면 끝나는 것이 아니라, 평가하고 로그를 보며 실패를 수습해야 합니다.

여기까지를 한마디로 요약하자면, Agentic RAG는 RAG를 "검색"에서 "조사"로 바꿉니다.

검색은 후보를 가져오는 것입니다.

조사는 답변에 필요한 재료가 갖춰질 때까지 질문을 분해하고, 자료를 확인하며, 부족함이 있으면 되돌아가는 것입니다.

이 차이는 매우 큽니다.

검색기를 강하게 만드는 것만으로는 조사가 되지 않습니다.

조사에는 진행 방식이 있습니다.

멈추는 방법이 있습니다.

근거를 보는 방법이 있습니다.

부족함을 인정하는 판단이 있습니다.

Agentic RAG가 지향하는 지점이 바로 여기입니다.

그래서 제1회에서 썼듯이, RAG는 "검색해서 답변하는 구조"가 아닌 방향으로 가고 있습니다.

어떤 정보를, 어떤 순서로, 어디까지 보고, 언제 멈출지를 결정하는 구조가 되어가고 있습니다.

제4회의 결론은 이렇습니다.

Agentic RAG의 가치는 agent (에이전트)의 수가 아닙니다.

답변하기 전에 정보가 충분한지를 판단할 수 있다는 점입니다.

다음 회차에서는 이 "어디를 보러 갈 것인가"를 또 다른 각도에서 살펴보겠습니다.

PageIndex입니다.

긴 문서를 평면적인 chunk (청크)의 집합으로 다루는 것이 아니라, 위에서부터 순서대로 따라갈 수 있는 지도로 다루는 개념을 살펴보겠습니다.

―― AI 미래 편집실 「AI 워치」