한번 검색하고 끝나는 RAG의 한계

일반적인 RAG 파이프라인은 미리 정한 절차대로 자료를 검색하고, LLM은 그 검색 결과를 바탕으로 응답을 생성합니다. 검색 대상과 처리 순서가 분명한 업무라면 이런 고정형 검색 절차로 충분합니다.

문제는 처음 찾은 자료만으로 응답에 필요한 정보가 다 모이지 않을 때입니다. 예를 들어 검색된 문서가 다른 규정을 참조하면 그 규정까지 확인해야 합니다. 고정형 파이프라인은 미리 정해 두지 않은 추가 검색을 하지 못합니다.

Agentic RAG: 다음에 찾을 것을 에이전트가 정한다

이럴 때 쓰는 것이 Agentic RAG입니다. Agentic RAG는 AI 에이전트가 질문과 검색 결과를 분석해 더 필요한 정보가 무엇인지 판단하고, 다음 검색 대상과 사용할 도구를 스스로 정하는 RAG 방식입니다.

그림 1의 Step 1에서 에이전트는 2025년 ○○ 문서를 검색해 자료 두 건을 찾았습니다. Step 2에서는 이 자료를 분석한 뒤 ○○ 규정에 관한 정보가 더 필요하다고 판단해 관련 자료 두 건을 추가로 조회했습니다. 검색 대상과 순서를 모두 미리 정해 두지 않아도, 에이전트가 앞선 결과를 보고 다음에 찾을 자료를 정합니다.

Agent Trajectory: 에이전트가 무엇을 읽었는지 남기는 기록

Agentic RAG의 또 다른 장점은 에이전트가 수행한 작업을 기록으로 남겨 검토하고 재사용할 수 있다는 점입니다. 관리자는 에이전트의 검색·도구 호출 기록을 검토해 빠진 자료를 보완하고, 검증을 마친 기록은 반복되는 질문에 응답할 때 재사용합니다.

에이전트는 외부 정보를 검색하거나 데이터를 조회할 때 도구 호출(Tool Calling)을 활용합니다. LLM이 호출할 도구를 지정하면 에이전트 환경이 그 도구를 실행해 결과를 LLM에 전달하고, LLM은 결과를 분석한 뒤 도구를 더 호출하거나 최종 응답을 작성합니다.

에이전트 실행 궤적(Agent Trajectory)은 에이전트가 수행한 일련의 작업 과정과 단계별 실행 결과를 말합니다. Agentic RAG에서 Agent Trajectory에는 검색 질의, 호출한 도구와 입력 인수, 도구가 반환한 데이터, 작업 수행 순서가 담깁니다.

검색 결과 검토 및 보완

관리자는 Agent Trajectory를 검토해 질문과 관련이 적은 문서를 재사용 대상에서 제외하고, 외부나 특정 사용자에게 공개하면 안 되는 보안 문서가 포함되어 있으면 그 문서와 그에 영향을 받은 후속 검색 기록까지 모두 제거합니다. 반대로 응답에 필요한 핵심 자료가 빠졌다면 관련 문서나 데이터를 추가로 검색해 근거를 보완합니다. 권한이 없는 문서는 사용자별 접근 권한에 따라 처음부터 검색에서 제외되며, 이 검토 과정은 조직 전체가 재사용할 기록의 범위를 다듬는 단계입니다.

그림 2의 왼쪽 숫자 1~4는 에이전트의 검색 단계를, 주황색 원은 각 단계까지 수집된 검색 결과를 나타냅니다. 관리자는 정답 문서를 응답의 근거로 유지하고, 불필요한 검색 결과와 보안 문서를 재사용 대상에서 제외합니다. 그림 아래쪽이 이렇게 검토 결과를 반영해 수정한 Agent Trajectory입니다.

예를 들어 실제 구축 사례에서는 에이전트가 적은 초기 정보로 키워드 검색을 시작합니다. 이 때문에 단어만 비슷하고 관련 없는 조건이나 필드가 초반에 자주 조회됩니다. 후속 추론으로 무관한 정보임을 파악하더라도 과정이 길어지면 컨텍스트만 비효율적으로 차지합니다. 이에 현업 피드백을 반영해 질문 유형별 핵심 조건, 필드 외의 초기 기록은 제거했습니다.

사람이 검토한 궤적만 FAQ로 다시 쓴다

실제 업무에서는 고객이나 업무 건이 달라도 비슷한 질문이 반복됩니다. 예를 들어 여러 고객이 같은 서비스의 이용 가능 여부를 묻는다면, 고객별 정보는 달라도 확인해야 할 운영 정책과 관련 규정은 같을 수 있습니다.

이런 질문이 들어올 때마다 이전 검색 기록 없이 새로 검색하면 에이전트는 같은 자료를 매번 다시 조회합니다. 검색 시점에 따라 결과가 달라져 같은 유형의 질문에 서로 다른 근거가 제시될 위험도 있습니다.

AIWORKX는 반복되는 질문에 에이전트가 빠르게 응답하도록 Agent Trajectory 기반의 FAQ 관리 체계를 구축했습니다. FAQ로 등록할 질문 유형이 지정되면 에이전트가 응답에 필요한 자료를 검색하고, FAQ 관리 시스템이 이때 생성된 Agent Trajectory를 저장합니다. 관리자는 Agent Trajectory에 담긴 검색 결과와 작업 절차를 검토한 뒤 등록을 승인하거나 재분석을 요청합니다. 검토를 통과한 Agent Trajectory만 FAQ 시스템에 최종 등록됩니다.

그림 3은 “2025년 ○○ 규정 좀 알려줘”라는 질문에 대응하는 실행 기록을 FAQ 저장소에서 불러오는 예시입니다. 저장소에는 규정, 법령, 소스코드 등 질문 유형별로 검증된 Agent Trajectory가 등록되어 있습니다. 사용자가 해당 FAQ 항목을 선택하면 시스템은 “2025년 ○○ 규정 질의”에 연결된 Agent Trajectory를 불러와 에이전트의 프롬프트에 주입합니다.

에이전트는 불러온 기록의 검색 결과와 분석 순서를 참조하되, 현재 질문의 입력 데이터를 반영해 응답을 새로 생성합니다. 검증된 실행 기록은 재사용하고 응답은 새로 생성하므로, 과거 응답을 그대로 반환하는 캐시 방식과 다릅니다. 같은 유형의 질문이라도 업무 건마다 그 데이터에 맞는 응답을 제공할 수 있습니다.

FAQ 기반 재사용 방식을 도입하면 같은 자료를 반복해 검색하고 도구를 호출하는 일이 줄어 응답 시간이 짧아집니다. 질문 유형마다 검증된 근거를 일관되게 활용하므로 응답의 신뢰도와 일관성도 높아집니다. 업무 전문가가 검증한 자료와 분석 절차를 조직 전체가 함께 활용할 수 있다는 점도 장점입니다.

적용: 국내 대형 카드사의 심사 해설 에이전트

AIWORKX는 국내 대형 카드사의 기업카드 심사 결과를 해설하는 AI 에이전트 서비스를 구축했습니다. 이 서비스는 Agentic RAG로 관련 심사 규정을 탐색하고, 관리자가 검증한 Agent Trajectory를 유사한 문의에 재사용합니다.

심사는 기존 규칙 엔진(Rule Engine)이 맡고, 에이전트는 심사 결과가 나온 원인과 판단 근거를 추적해 사용자에게 설명합니다. 확인해야 할 심사 규칙은 규칙 엔진에 정의되어 있으며 수많은 규칙이 서로 복잡하게 얽혀 있습니다. AIWORKX는 이러한 심사 규정을 그래프 구조로 구성해 규칙 간의 연결 관계를 따라 필요한 규정을 탐색하도록 설계했습니다.

예를 들어 사용자가 심사 탈락 사유를 물으면 에이전트는 검색 도구를 호출해 부적격을 결정한 규칙을 조회합니다. 그 규칙의 조건값이 다른 규칙에서 생성되었다면 그 값을 산출한 이전 규칙까지 연쇄적으로 확인합니다. 방대한 규칙 파일 전체를 분석하지 않고도 해설에 필요한 규정만 단계적으로 추려 낼 수 있습니다.

이 과정에서 어떤 규칙을 어떤 순서로 조회했고 도구가 어떤 결과를 반환했는지가 Agent Trajectory로 저장됩니다. 심사 탈락 사유나 한도 산출 근거를 묻는 질문은 건마다 입력 데이터가 달라도 참조하는 규칙과 분석 절차가 비슷한 경우가 많습니다. 그래서 같은 규칙을 매번 처음부터 검색하지 않도록, 앞서 설명한 절차로 검토·승인한 Agent Trajectory를 FAQ에 등록해 재사용합니다. 운영 환경에서는 일반 사용자에게 자유 입력을 열지 않고 등록된 질문만 허용해 검증된 경로로만 답하도록 했습니다. 데모 기준으로 처음부터 탐색하면 약 100초가 걸리지만, 사전에 등록된 Agent Trajectory를 재사용하면 약 30초로 단축됩니다.

이후 다른 심사 건에서 사용자가 해당 FAQ를 선택하면, 에이전트는 저장된 규칙 조회 결과와 분석 순서를 참조해 현재 심사 건에 맞는 해설을 새로 생성합니다. 반복적인 검색과 도구 호출은 줄이면서도 심사 건마다 그 결과에 맞는 해설을 제공합니다. 또한 응답 옆에는 Agent Trajectory를 근거로 출처와 인용 정보를 함께 표시해 판단 근거를 바로 확인할 수 있습니다.

마치며

Agentic RAG가 필요한 근거를 스스로 찾아가는 기술이라면, Agent Trajectory 검토와 재사용은 그 과정을 관리 가능한 범위 안에 두는 장치입니다. 금융을 비롯한 기업 실무에서는 에이전트의 판단 과정을 통제할 수 있어야 업무를 믿고 맡길 수 있습니다. 결국 현장에서 신뢰할 수 있는 AI는 더 큰 모델이 아니라, 사람이 검증한 기록을 기반으로 답하게 하는 구조에서 나옵니다.

※ 이 글은 〈AIWORKX 금융 AI Agent 세미나〉 발표 내용을 바탕으로 정리했습니다.

자주 묻는 질문 (FAQ)

Q1. Agentic RAG는 어떤 업무에 먼저 적용하면 효과적인가요?

처음 검색 결과에 따라 추가로 확인할 자료나 처리 절차가 달라지는 업무에 먼저 적용하는 것이 효과적입니다. 여러 자료를 종합해 분석해야 하거나, 검색 결과에 따라 데이터베이스 조회나 분석 도구를 추가로 호출해야 하는 업무가 대표적입니다.

Q2. 검증된 Agent Trajectory를 재사용하면 개별 응답은 검증하지 않아도 되나요?

아닙니다. 두 검증은 목적과 대상이 다릅니다. Agent Trajectory 검증은 에이전트의 검색 경로와 참조 자료가 적절한지 확인합니다. 개별 응답 검증은 현재 입력 데이터가 저장된 실행 기록의 적용 조건에 부합하는지, 최종 결론이 인용한 근거와 논리적으로 일치하는지 점검합니다.

Q3. Agent Trajectory 재사용에 따른 운영 효율은 어떻게 측정하나요?

같은 질문 세트를 대상으로, 매번 처음부터 전체 검색을 수행하는 방식과 승인된 Agent Trajectory를 재사용하는 방식을 비교해 측정합니다. 주요 지표는 도구 호출 횟수, 응답 소요 시간, LLM 추론 비용입니다.

근거 누락률과 조건 적용 오류율도 함께 측정하면, 실행 기록의 재사용이 최종 응답의 정확도에 미치는 영향까지 확인할 수 있습니다. 전체 운영 비용을 산출할 때는 Agent Trajectory를 처음 검토하는 시간과 원천 자료 개정에 따른 유지보수 시간도 반영해야 합니다.

Q4. FAQ에 등록되지 않은 새로운 질문에는 어떻게 답하나요?

일반 사용자는 등록되지 않은 질문을 직접 입력할 수 없고, 화면에 등록된 질문만 선택할 수 있습니다. 새로운 질문이 필요하면 관리자가 질문을 입력하고, 에이전트가 관련 자료를 검색해 Agent Trajectory를 생성합니다. 이어서 관리자는 생성된 기록을 검토해 수정한 뒤 새로운 FAQ 항목으로 승인합니다. 승인된 항목이 FAQ에 추가되면, 그때부터 일반 사용자도 해당 질문을 선택해 답변을 받을 수 있습니다.

관련 글

• 당신의 LLM 솔루션이 느린 이유 ︱ PAVE 2호 테크블로그, 이재민 팀장
• 특수 도메인 RAG 생존기: 검색의 진화와 온톨로지 ︱ 황혜수 연구원

* 기획 및 편집: 브랜드&임팩트팀 전혜영 팀장 · impact.brand@aiworkx.ai