Agentic RAG란? 고전적 RAG와 다른 핵심 기술·프레임워크·활용 사례 총정리

“이번 분기 계약 갱신 대상 고객 중, 보안 부속합의서가 누락됐고 최근 30일간 장애 티켓을 등록한 기업은 어디인가요?”

이 질문에 정확히 답하려면 계약서 PDF만 읽어서는 안 됩니다. 고객 관리 데이터베이스, 티켓 시스템, 보안 문서 저장소의 정보를 함께 확인해야 합니다. 계약서마다 표현 방식도 다르고, 데이터베이스에는 날짜·고객 ID·상태값처럼 구조화된 정보가 들어 있습니다.

그런데 고전적인 RAG는 보통 다음 흐름으로 작동합니다.

1. 질문을 벡터로 변환합니다.
2. 벡터 데이터베이스에서 관련 문서 조각을 몇 개 검색합니다.
3. 검색 결과를 LLM에 전달해 답변을 생성합니다.

이 방식은 사내 규정 한 조항을 찾거나, 매뉴얼의 특정 절차를 요약하는 데는 빠르고 효율적입니다. 하지만 여러 문서와 시스템을 대조해야 하는 질문에서는 곧 한계가 드러납니다.

RAG의 고정된 검색 흐름이 놓치는 것들

벡터 검색은 의미가 비슷한 문서를 찾는 데 강합니다. 하지만 “계약 갱신”, “보안 부속합의서 누락”, “최근 장애 티켓”처럼 조건이 여러 개인 질문은 단순 유사도 검색만으로 해결하기 어렵습니다.

예를 들어 시스템은 다음과 같은 판단을 해야 합니다.

• 계약서에서 갱신일과 보안 조항을 찾아야 하는가?
• 고객 ID를 기준으로 계약서와 CRM 데이터를 연결해야 하는가?
• 장애 티켓은 SQL 데이터베이스에서 기간 조건을 걸어 조회해야 하는가?
• 서로 다른 출처의 정보가 충돌할 때 무엇을 우선해야 하는가?
• 증거가 부족하면 추가 검색을 해야 하는가, 아니면 모른다고 답해야 하는가?

전통적인 RAG 파이프라인은 이런 판단을 대부분 하지 못합니다. 정해진 인덱스에서 top-K 문서를 가져온 뒤 바로 답변을 만들기 때문입니다. 검색 결과에 핵심 근거가 없더라도 LLM은 문맥을 그럴듯하게 연결하려 할 수 있고, 이 과정에서 추측이나 불완전한 결론이 섞일 위험이 생깁니다.

복잡한 업무 질문의 핵심은 “관련 문서를 찾는 것”이 아니라, 어떤 정보를 어떤 순서로 확인하고 검증할지 결정하는 것입니다.

단일 검색이 부족해지는 순간

특히 다음과 같은 질문은 한 번의 검색으로 답하기 어렵습니다.

• 여러 계약서의 조항을 비교해 예외 조건을 찾아야 하는 경우
• 문서 내용과 실시간 매출·재고·로그 데이터를 함께 확인해야 하는 경우
• 고객, 제품, 담당자, 사건처럼 엔터티 간 관계를 추적해야 하는 경우
• 답변의 근거와 최신성, 모순 여부를 반드시 검증해야 하는 경우
• 질문을 여러 개의 하위 질문으로 나누어 순서대로 풀어야 하는 경우

이때 필요한 것은 더 많은 문서를 무작정 프롬프트에 넣는 방식이 아닙니다. 질문의 구조를 이해하고, 필요한 데이터 소스를 선택하며, 결과가 부족하면 다시 탐색하는 능력입니다.

바로 이 지점에서 RAG는 단순한 검색→생성 모델을 넘어, 검색 계획과 검증을 수행하는 능동형 구조로 진화하기 시작합니다.

RAG가 답을 찾는 방식에서, 답을 조사하는 방식으로

검색 결과가 부족하거나 서로 모순된다면 어떻게 해야 할까요? 전통적인 RAG는 보통 가장 관련성이 높은 몇 개의 문서를 가져온 뒤, 그 안에서 곧바로 답변을 생성합니다. 빠르고 효율적이지만, 복잡한 질문에서는 첫 검색 결과가 충분하지 않을 수 있습니다.

예를 들어 “지난 분기 매출 감소의 원인과 제품별 영향, 대응 방안은 무엇인가?”라는 질문을 생각해 보겠습니다. 이 질문에는 매출 데이터, 고객 피드백, 장애 로그, 시장 보고서처럼 서로 다른 정보원이 필요합니다. 단일 벡터 검색만으로는 일부 문서만 찾아낼 가능성이 높고, 서로 다른 자료의 수치나 설명이 충돌할 수도 있습니다.

Agentic RAG는 이 지점에서 작동 방식이 달라집니다. 검색된 정보를 그대로 믿고 답을 내놓는 대신, 에이전트가 먼저 다음을 판단합니다.

• 현재 근거만으로 질문에 답할 수 있는가?
• 빠진 정보는 무엇인가?
• 문서 검색, SQL 조회, 지식 그래프, 외부 API 중 어떤 도구가 필요한가?
• 검색 결과 사이에 모순은 없는가?
• 추가 조사가 필요하다면 어떤 하위 질문부터 해결해야 하는가?

즉, 기존 RAG가 “찾은 자료로 답하는 시스템”에 가깝다면, Agentic RAG는 “답을 내기 전에 조사 계획을 세우고 증거를 검증하는 시스템”에 가깝습니다.

이 과정은 대개 반복 루프로 구성됩니다. 에이전트는 질문을 여러 개의 하위 질문으로 나누고, 각 질문에 맞는 데이터 소스를 선택합니다. 이후 검색 결과의 충분성과 신뢰도를 평가합니다. 근거가 약하거나 상충하는 내용이 발견되면, 검색 범위를 넓히거나 다른 도구를 호출해 다시 확인합니다.

예를 들어 계약 조건을 묻는 기업 질의라면 문서 검색만으로 끝내지 않을 수 있습니다. 에이전트는 계약서 원문에서 조항을 찾고, 최신 수정 이력을 확인하며, 고객 데이터베이스에서 실제 적용 상태를 조회할 수 있습니다. 마지막에는 “어떤 문서와 데이터에 근거해 답했는지”를 정리하고, 확인되지 않은 부분은 불확실하다고 명시합니다.

이러한 변화의 핵심은 단순히 검색 횟수가 늘어나는 데 있지 않습니다. Agentic RAG는 검색을 고정된 전처리 단계가 아니라, 추론과 검증에 따라 계속 바뀌는 의사결정 과정으로 다룹니다. 그래서 복잡한 리서치, 다부서 데이터 분석, 규정 검토, 의료·과학 문헌 탐색처럼 정확성과 근거가 중요한 업무에서 특히 강점을 보입니다.

계획자부터 검증자까지: Agentic RAG 내부의 작동 원리

겉으로 보면 하나의 AI가 질문을 받고 곧바로 답하는 것처럼 보입니다. 하지만 복잡한 질문을 정확하게 처리하는 Agentic RAG 내부에서는 역할이 나뉘어 움직일 수 있습니다. 누군가는 질문을 해석하고, 누군가는 자료를 찾으며, 또 다른 역할은 답변의 근거가 충분한지 검증합니다.

핵심은 단순합니다. 기존 RAG가 “찾고, 읽고, 답한다”는 직선형 흐름에 가까웠다면, Agentic RAG는 필요한 경우 계획 → 검색 → 판단 → 재검색 → 종합을 반복하는 연구 프로세스에 가깝습니다.

질문을 해석하는 계획자

첫 단계는 사용자의 질문을 그대로 검색창에 넣는 일이 아닙니다. 계획자 역할의 에이전트는 질문의 의도와 난이도를 먼저 판단합니다.

예를 들어 “지난 분기 매출이 감소한 이유와 대응 방안을 알려줘”라는 질문에는 여러 종류의 정보가 필요합니다.

• 매출 데이터와 전 분기 비교 수치
• 제품·지역·고객군별 변화
• 영업 활동 및 캠페인 기록
• 고객 문의, 장애, 시장 이슈
• 내부 대응 정책과 실행 가능성

계획자는 이 질문을 작은 과제로 분해합니다. “매출은 얼마나 감소했는가?”, “어떤 사업 부문이 영향을 받았는가?”, “관련 운영 이슈가 있었는가?”처럼 서브 질문을 만들고, 각 질문에 적합한 데이터 소스를 연결합니다.

이 과정에서 단순 문서 검색이 필요한지, SQL 데이터 조회가 필요한지, 지식 그래프 탐색이 필요한지도 결정합니다. 즉, Agentic RAG의 계획자는 답을 생성하기 전에 답을 얻기 위한 조사 경로부터 설계합니다.

자료를 수집하는 검색자와 도구 라우터

계획이 세워지면 검색자 역할이 움직입니다. 다만 여기서의 검색은 벡터 데이터베이스만 조회하는 작업이 아닙니다.

Agentic RAG는 질문 성격에 따라 서로 다른 도구를 선택할 수 있습니다.

정보 유형	활용 도구	적합한 질문 예시
사내 문서, 매뉴얼, 회의록	벡터 DB	“보안 정책의 예외 조건은 무엇인가?”
매출, 주문, 사용자 로그	SQL	“지난달 이탈률이 가장 높았던 고객군은?”
조직, 제품, 계약 간 관계	지식 그래프	“이 계약과 연결된 담당 부서는 어디인가?”
최신 외부 정보	웹 검색·외부 API	“오늘 환율과 경쟁사 발표 내용은?”

이 구조의 장점은 분명합니다. 자연어 설명이 필요한 질문에는 문서 검색을, 정확한 수치 계산에는 SQL을, 관계 중심 탐색에는 그래프를 활용할 수 있습니다.

예를 들어 “특정 고객의 계약 갱신 가능성을 평가해 달라”는 요청이 들어오면, 에이전트는 계약서를 검색하고, CRM 데이터를 조회하며, 최근 고객 문의나 장애 이력을 확인할 수 있습니다. 하나의 검색 방식으로는 놓치기 쉬운 근거를 여러 소스에서 모으는 것입니다.

충분한지 판단하는 검증자

Agentic RAG의 차별점은 검색 결과를 그대로 답변에 붙이지 않는다는 데 있습니다. 검증자 역할은 수집된 근거가 질문을 제대로 뒷받침하는지 점검합니다.

검증 과정에서는 보통 다음과 같은 질문이 활용됩니다.

• 이 자료가 사용자의 질문에 직접 답하는가?
• 핵심 주장마다 출처와 증거가 있는가?
• 서로 다른 문서나 데이터 사이에 모순이 있는가?
• 정보가 오래되었거나 권한상 제한된 것은 아닌가?
• 확신할 수 없는 부분을 명확히 표시했는가?

가령 정책 문서에는 “승인 가능”이라고 적혀 있지만, 최신 공지에는 해당 정책이 변경되었다고 나와 있다면 검증자는 추가 검색을 요청해야 합니다. 이때 에이전트는 더 최신의 문서를 찾거나, 담당 부서 데이터베이스를 확인하거나, 답변에 “정책 변경 여부를 추가 확인해야 한다”고 명시할 수 있습니다.

좋은 Agentic RAG 시스템은 모르는 내용을 그럴듯하게 채우기보다, 근거 부족 자체를 판단 결과로 다룹니다.

재검색과 반성 루프: 한 번에 끝내지 않는 이유

복잡한 질문은 첫 검색만으로 해결되지 않는 경우가 많습니다. 그래서 Agentic RAG는 검색 결과를 평가한 뒤, 필요하면 새로운 질문을 만들고 다시 탐색합니다.

흐름은 다음과 같습니다.

1. 사용자의 원래 질문을 분석합니다.
2. 질문을 여러 서브 질문으로 나눕니다.
3. 각 질문에 맞는 도구와 데이터 소스를 선택합니다.
4. 검색 결과의 관련성·최신성·일관성을 검토합니다.
5. 근거가 부족하거나 모순이 있으면 재검색합니다.
6. 충분한 증거가 확보되면 최종 답변을 종합합니다.

이 반복 구조를 흔히 Reflection Loop, 즉 반성 또는 자기 검증 루프라고 부릅니다. 중요한 것은 무한히 반복하지 않도록 제한을 둔다는 점입니다. 실무에서는 최대 반복 횟수, 시간 제한, 호출 비용, 신뢰도 임계값을 설정합니다.

예를 들어 “최대 5회까지 추가 검색”이라는 규칙을 두고도 근거가 충분하지 않다면, 시스템은 추측으로 결론을 내리지 않고 조사 한계와 추가 확인이 필요한 항목을 보고해야 합니다.

하나의 에이전트처럼 보이는 멀티 에이전트 구조

모든 역할을 하나의 모델이 수행할 수도 있습니다. 그러나 대규모 기업 환경이나 복잡한 리서치 업무에서는 역할을 분리한 멀티 에이전트 구조가 효과적일 수 있습니다.

대표적인 구성은 다음과 같습니다.

• Planner: 질문을 분석하고 조사 계획을 수립합니다.
• Researcher: 문서, 데이터베이스, API 등에서 자료를 수집합니다.
• Verifier: 근거의 품질, 최신성, 모순 여부를 점검합니다.
• Synthesizer: 검증된 자료를 바탕으로 읽기 쉬운 답변이나 보고서를 작성합니다.

이 분리는 단순히 기능을 나누는 일이 아닙니다. 각 단계의 로그를 남기면 “어떤 데이터에 근거해 답변했는지”, “왜 추가 검색이 일어났는지”, “어떤 이유로 결론을 보류했는지”를 추적할 수 있습니다. 특히 규제 산업, 의료, 금융, 보안처럼 설명 가능성이 중요한 환경에서 큰 장점이 됩니다.

설계의 핵심은 ‘더 많이 찾기’가 아니다

Agentic RAG의 목표는 가능한 많은 정보를 가져오는 것이 아닙니다. 질문에 맞는 도구를 선택하고, 필요한 만큼만 검색하며, 충분한 근거가 확보됐는지 판단하는 데 있습니다.

따라서 좋은 시스템은 복잡한 질문에만 깊은 계획과 검증을 사용합니다. 단순 FAQ나 반복 질문은 캐시 또는 일반 RAG로 빠르게 처리하고, 다단계 추론·여러 데이터 소스·높은 정확성이 필요한 업무에서만 에이전트 루프를 활성화합니다.

결국 Agentic RAG의 내부 구조는 하나의 똑똑한 답변기가 아니라, 계획하고 조사하고 의심하고 검증하는 디지털 연구팀에 가깝습니다. 이 역할 분담이 제대로 설계될수록 AI의 답변은 더 정확해지고, 조직은 그 답변을 더 신뢰할 수 있게 됩니다.

더 정확한 답의 대가: Agentic RAG의 비용, 지연, 그리고 활용 현장

복잡한 질문일수록 한 번 검색하고 바로 답하는 방식은 쉽게 한계에 부딪힙니다. 계약서와 사내 규정이 서로 충돌할 수 있고, 매출 데이터는 SQL에서 확인해야 하며, 최신 시장 정보는 외부 검색이 필요할 수도 있습니다. 이때 Agentic RAG는 질문을 분해하고, 필요한 도구를 고르고, 근거가 부족하면 다시 검색하면서 답의 신뢰도를 높입니다.

다만 모든 질문을 이런 방식으로 처리하는 것은 비효율적입니다. 정확도를 높이기 위한 반복 검색과 검증에는 분명한 대가가 따릅니다.

단일 패스 RAG와 Agentic RAG의 현실적인 차이

일반적인 단일 패스 RAG는 사용자의 질문을 벡터로 변환한 뒤, 관련 문서 조각을 몇 개 검색해 LLM에 전달합니다. 구조가 단순하기 때문에 대체로 수백 ms에서 1~2초 내에 답변할 수 있습니다. FAQ, 사내 문서 검색, 제품 기능 안내처럼 질문의 범위가 명확한 업무에 잘 맞습니다.

반면 Agentic RAG는 다음 과정을 반복할 수 있습니다.

• 질문을 여러 개의 하위 질문으로 분해
• 벡터 DB, SQL, 지식 그래프, 외부 API 중 적절한 도구 선택
• 검색 결과의 관련성과 근거 충족 여부 평가
• 부족하거나 모순된 정보가 있으면 재검색
• 최종 답변에 출처와 불확실성 수준 반영

이 과정에서는 LLM 호출과 도구 호출이 여러 번 발생합니다. 따라서 응답 시간은 보통 2~10초 이상으로 늘어날 수 있고, 질의당 실행 비용도 0.01~0.10달러 수준까지 상승할 수 있습니다. 특히 외부 API 호출, 대형 모델 사용, 여러 에이전트 간 협업이 더해지면 비용과 지연은 더욱 커집니다.

Agentic RAG의 핵심 가치는 “더 많이 검색하는 것”이 아니라, 필요한 경우에만 더 깊게 조사하는 것에 있습니다.

어디에 Agentic RAG를 투입해야 할까

Agentic RAG는 속도보다 정확성, 근거, 재검증이 중요한 업무에 우선 적용하는 것이 좋습니다. 대표적인 활용 현장은 다음과 같습니다.

엔터프라이즈 지식 비서

기업 내부에는 문서, 위키, 고객 티켓, 정책 파일, CRM, 데이터베이스, 운영 로그가 흩어져 있습니다. “이 고객에게 적용 가능한 환불 정책은 무엇인가?” 같은 질문은 문서 하나만 검색해서 답하기 어렵습니다.

에이전트는 정책 문서에서 원칙을 찾고, SQL에서 고객의 구매 이력이나 계약 상태를 확인한 뒤, 예외 조항을 다시 검토할 수 있습니다. 이 경우 단순한 답변 속도보다 잘못된 안내를 줄이는 것이 중요하므로 Agentic RAG의 가치가 큽니다.

데이터 분석과 경영 의사결정 지원

“지난 분기 매출 하락의 주요 원인과 지역별 차이를 분석해 달라”는 질문은 문서 검색만으로 해결되지 않습니다. 매출 데이터는 SQL로 조회하고, 캠페인 정보는 마케팅 문서에서 찾으며, 공급 이슈는 운영 보고서에서 확인해야 합니다.

이런 환경에서는 에이전트가 질문을 분석 과제로 분해하고, 데이터 소스를 연결하며, 수치와 서술형 근거를 함께 검증하는 방식이 유리합니다. 단, 최종 결과가 경영 판단에 사용된다면 계산 결과와 인용 근거를 사람이 다시 검토할 수 있도록 설계해야 합니다.

과학·의료·엔지니어링 지원

의료 기록, 연구 논문, 실험 로그, 대규모 코드베이스는 정보량이 많고 정확성 요구 수준도 높습니다. 예를 들어 과학 코드 어시스턴트는 특정 함수의 역할을 설명하기 위해 코드, 의존성 그래프, 실험 설정, 문서화 자료를 함께 확인해야 할 수 있습니다.

이 영역에서는 오프라인 단계에서 코드 파싱, 메타데이터 구축, 지식 그래프 생성, 임베딩 작업을 미리 수행하고, 온라인 단계에서 Agentic RAG가 필요한 근거만 선택하도록 구성하는 방식이 효과적입니다. 작은 모델을 사용하더라도 도메인 특화 지식을 잘 정리해 두면 높은 품질을 기대할 수 있습니다.

복잡한 규정·계약·감사 업무

규정 준수와 계약 검토는 문장 하나의 예외 조항이 결론을 바꿀 수 있는 분야입니다. 에이전트는 기본 규정, 최신 개정 이력, 계약 부속 문서, 지역별 정책을 교차 확인해야 합니다.

다만 이 경우 Agentic RAG는 최종 판단자가 아니라 근거 수집과 검토 보조 도구로 두는 것이 바람직합니다. 출처가 부족하거나 규정 간 충돌이 감지되면, 답을 단정하기보다 검토가 필요하다고 명시해야 합니다.

가장 현실적인 해법: 계층형 RAG

실무에서는 모든 질의를 Agentic RAG로 보내기보다, 난이도에 따라 처리 경로를 나누는 계층형 RAG가 효율적입니다.

질문 유형	권장 처리 방식	예시
단순·반복 질문	캐시 또는 LLM 단독 응답	“비밀번호는 어떻게 재설정하나요?”
일반 정보 검색	단일 패스 RAG	“우리 제품의 API 제한은 무엇인가요?”
관계·수치 중심 질문	SQL 또는 GraphRAG 연계	“지난달 해지율이 높은 고객군은?”
복잡·고위험 질문	Agentic RAG	“계약 조건과 고객 이력을 반영한 예외 처리 가능 여부는?”

이 구조의 핵심은 복잡한 질문에만 비싼 추론과 검증을 사용하는 것입니다. 질문 분류 단계에서 난이도, 데이터 소스 수, 최신성 요구, 오류 위험도를 평가하면 전체 운영 비용을 크게 낮출 수 있습니다.

정확도만큼 중요한 운영 원칙

Agentic RAG를 실제 서비스에 적용할 때는 성능뿐 아니라 통제 가능성도 함께 설계해야 합니다.

• 반복 횟수 제한: 검색과 반성 루프에 최대 횟수를 두어 무한 실행을 방지합니다.
• 비용 예산 설정: 질의별 LLM 호출 수, API 비용, 실행 시간을 제한합니다.
• 권한 기반 도구 접근: 에이전트가 모든 데이터베이스와 API에 접근하지 않도록 권한을 세분화합니다.
• 근거와 출처 기록: 최종 답변뿐 아니라 어떤 문서와 데이터를 사용했는지 남깁니다.
• 불확실성 표현: 충분한 근거를 찾지 못했다면 그 사실을 명확히 밝혀야 합니다.
• 사람의 최종 검토: 의료, 법률, 재무, 보안처럼 고위험 분야에서는 휴먼 인 더 루프를 유지합니다.

Agentic RAG는 빠른 답변을 위한 기술이라기보다, 복잡한 질문에 대해 더 책임 있는 답을 만들기 위한 기술에 가깝습니다. 단순한 검색에는 가벼운 RAG를 사용하고, 여러 출처의 검증과 추론이 필요한 순간에만 에이전트를 투입해야 비용·속도·정확도 사이의 균형을 잡을 수 있습니다.

RAG 자율 검색을 신뢰할 수 있게 만드는 조건

에이전트가 더 많은 도구를 호출하고 더 많은 단계를 밟을수록, 답변의 가능성은 넓어집니다. 동시에 오류가 퍼질 경로도 늘어납니다. 잘못된 검색어 하나, 권한이 없는 데이터 소스 하나, 검증되지 않은 중간 추론 하나가 이어지면 최종 답변은 그럴듯하지만 위험한 결론이 될 수 있습니다.

따라서 Agentic RAG의 성패는 에이전트의 자율성 그 자체가 아니라, 자율성을 어디까지 허용하고 어떻게 통제할 것인가에 달려 있습니다.

필요한 만큼만 자율성을 부여해야 한다

모든 질문에 복잡한 에이전트 루프를 적용할 필요는 없습니다. 단순한 사내 규정 확인, 자주 묻는 질문, 캐시된 데이터로 충분한 질의까지 다단계 검색과 검증을 수행하면 비용과 응답 시간만 커집니다.

실무에서는 질의 난이도와 위험도를 기준으로 경로를 나누는 계층형 RAG가 효과적입니다.

• 단순 질의: 캐시 또는 LLM 단독 응답
• 일반 정보 질의: 벡터 검색 기반 단일 패스 RAG
• 복합 분석 질의: SQL, 지식 그래프, 외부 API를 조합하는 Agentic RAG
• 고위험 질의: 다중 근거 검증과 사람 승인 단계를 포함한 제한형 에이전트

핵심은 “가장 똑똑한 경로”가 아니라, 질문에 필요한 최소한의 경로를 선택하는 것입니다. 이는 정확도뿐 아니라 비용, 지연 시간, 운영 안정성까지 함께 개선합니다.

도구 호출에는 권한과 경계가 필요하다

Agentic RAG는 벡터 DB, SQL, 지식 그래프, 웹 검색, 외부 API 등 다양한 도구를 연결합니다. 그러나 도구가 많아질수록 에이전트가 접근할 수 있는 데이터와 실행 가능한 행동도 늘어납니다.

그래서 각 도구는 단순히 연결하는 데서 끝나면 안 됩니다. 다음 통제 장치가 함께 필요합니다.

• 최소 권한 원칙: 에이전트와 사용자에게 필요한 데이터 범위만 허용합니다.
• 읽기·쓰기 분리: 검색과 조회 권한, 데이터 변경 권한을 명확히 분리합니다.
• 도구별 쿼터 설정: API 호출 수, 검색 반복 횟수, 실행 시간을 제한합니다.
• 민감정보 필터링: 개인정보, 계약 정보, 보안 키 등은 검색 결과에 노출되지 않도록 처리합니다.
• 감사 로그 기록: 어떤 에이전트가 언제 어떤 근거를 조회하고 어떤 판단을 했는지 남깁니다.

특히 SQL이나 업무 시스템 API처럼 실제 운영 데이터와 연결되는 환경에서는, 에이전트가 자유롭게 명령을 생성하도록 두는 방식은 위험합니다. 허용된 템플릿, 읽기 전용 인터페이스, 정책 기반 필터를 통해 행동 범위를 좁혀야 합니다.

‘검색했다’가 아니라 ‘근거가 충분하다’를 검증해야 한다

좋은 RAG 시스템은 문서를 많이 찾는 시스템이 아닙니다. 질문에 답하기 위한 충분하고 일관된 근거를 확보하는 시스템입니다.

에이전트의 검증 단계에서는 최소한 다음을 점검해야 합니다.

1. 관련성: 검색된 문서가 실제 질문을 직접 뒷받침하는가
2. 근거 커버리지: 답변의 핵심 주장마다 출처가 존재하는가
3. 일관성: 서로 다른 문서나 데이터 소스가 모순되지 않는가
4. 최신성: 정책, 가격, 제품 정보처럼 시간 의존적인 데이터가 최신인가
5. 출처 신뢰도: 공식 문서, 승인된 내부 위키, 검증된 데이터베이스를 우선했는가

이 검증은 단순히 LLM에게 “답변이 맞는지 확인해 달라”고 요청하는 수준에 머물면 안 됩니다. 주장과 근거를 연결하고, 근거가 부족한 문장은 삭제하거나 불확실성을 표시하도록 설계해야 합니다.

예를 들어 계약 조항을 묻는 질문이라면, 에이전트는 요약 문서보다 원문 계약서의 해당 조항을 우선해야 합니다. 여러 버전의 계약서가 검색됐다면 최신 버전인지 확인하고, 충돌이 있다면 단정 대신 검토 필요성을 알려야 합니다.

반복 루프에는 종료 조건이 있어야 한다

자율 검색의 장점은 부족한 정보를 발견했을 때 다시 찾아볼 수 있다는 점입니다. 하지만 재검색과 반성 루프가 무제한으로 이어지면 지연 시간과 비용이 급격히 증가하고, 오히려 불필요한 정보가 답변을 흐릴 수 있습니다.

따라서 Agentic RAG에는 명확한 종료 규칙이 필요합니다.

• 최대 검색·검증 반복 횟수
• 최대 LLM 호출 비용
• 허용 가능한 응답 지연 시간
• 근거 신뢰도 임계값
• 새 검색 결과의 추가 가치가 낮아지는 시점
• 답변 대신 “정보 부족”을 반환해야 하는 조건

실무적으로는 5~6회 내외의 반복 상한을 두고, 그 안에 충분한 근거를 확보하지 못하면 정직하게 한계를 보고하는 방식이 현실적입니다. 신뢰할 수 있는 시스템은 항상 답을 만들어 내는 시스템이 아니라, 답할 수 없는 상황을 식별하는 시스템입니다.

사람의 승인이 필요한 지점을 구분해야 한다

모든 과정에 사람이 개입하면 에이전트의 장점이 사라집니다. 반대로 사람의 검토가 전혀 없으면 고위험 업무에서 사고 가능성이 커집니다. 중요한 것은 사람을 모든 단계에 넣는 것이 아니라, 되돌릴 수 없는 결정 앞에 배치하는 것입니다.

다음과 같은 상황에서는 휴먼 인 더 루프가 특히 중요합니다.

• 법률, 의료, 금융처럼 오류 비용이 큰 판단
• 고객에게 공식 답변이나 제안을 발송하는 업무
• 권한 변경, 결제, 계약 갱신 등 실제 행동을 수행하는 작업
• 상충하는 근거를 해석해야 하는 민감한 사안
• 내부 기밀 또는 개인정보가 포함된 질의

에이전트는 자료 수집과 초안 작성, 근거 정리까지 담당할 수 있습니다. 그러나 최종 승인과 책임은 사람에게 남겨야 합니다. 이 구조는 자동화를 늦추는 장치가 아니라, 자동화를 지속 가능하게 만드는 안전장치입니다.

운영 지표는 정확도만으로 충분하지 않다

Agentic RAG의 품질을 평가할 때 정답률만 보면 중요한 실패를 놓치기 쉽습니다. 답변이 사실과 대체로 맞더라도, 잘못된 출처를 사용했거나 민감한 정보를 노출했거나 불필요하게 비싼 경로를 택했다면 운영 품질은 낮습니다.

함께 추적해야 할 지표는 다음과 같습니다.

평가 영역	확인할 지표
답변 품질	정확성, 완전성, 환각 발생률
근거 품질	인용 정확도, 근거 커버리지, 출처 최신성
검색 품질	검색 적합도, 재검색 성공률, 도구 선택 정확도
운영 효율	평균 지연 시간, 질의당 비용, 반복 횟수
안전성	정책 위반, 권한 오류, 민감정보 노출 시도
사용자 신뢰	재질문율, 사람 검토 요청률, 만족도

결국 신뢰할 수 있는 RAG는 더 많이 검색하는 시스템이 아닙니다. 필요한 정보를 적절한 권한 안에서 찾고, 근거를 검증하며, 불확실할 때 멈출 줄 아는 시스템입니다.

자율성은 기능이지만, 통제는 설계입니다. Agentic RAG를 도입할 때 기업이 먼저 구축해야 할 것은 더 강력한 에이전트가 아니라, 그 에이전트가 안전하게 판단하고 실패할 수 있도록 만드는 권한·검증·평가·승인 체계입니다.