현장 노트: Agentic RAG가 기업 데이터의 실제 혼란을 처리하는 방법

🙋‍
저는 Luhui Dev로, Agent 엔지니어링을 분석하고 AI가 교육에 어떻게 적용될 수 있는지 탐구해 온 개발자입니다.
저는 Agent Harness, LLM 애플리케이션 엔지니어링, 수학을 위한 AI, 그리고 교육 SaaS의 제품화에 집중하고 있습니다.

데이터 미로를 여는 지원 티켓

당신의 회사가 방금 AI 고객 지원 시스템을 출시했다고 가정해 봅시다.

한 주요 고객사가 티켓을 보냅니다: "지난 분기 Project Alpha 하에 구매한 서버의 남은 보증 기간은 어떻게 되나요? 또한 원래 계약 조건과 현재 기술 지원 담당자 연락처도 공유해 주실 수 있나요?"

평범한 질문처럼 들립니다. 하지만 기술 팀장이 이 티켓을 읽을 때, 그들은 잠시 멈칫합니다.

왜냐하면 이 질문에 답하기 위해서는 시스템이 다음을 수행해야 한다는 것을 알기 때문입니다:

CRM에서 고객 프로필과 프로젝트 이력을 조회
**ERP / 계약 관리 시스템 (contract management system)**에서 Project Alpha에 대한 조달 계약 및 보증 조건을 조회
**자산 관리 시스템 (asset management system)**에서 해당 서버 배치의 입고 날짜와 장치 일련번호를 조회
HR 시스템에서 현재 고객 성공 담당자(customer-success owner)를 조회

이 네 가지 시스템은 서로 다른 팀에 의해 유지 관리되고, 서로 다른 데이터베이스에서 실행되며, 서로 다른 액세스 제어(access controls)를 적용합니다.

표준 RAG 시스템은 여기서 무력합니다. 시스템이 할 수 있는 최선은 "죄송합니다, 관련 정보를 찾을 수 없습니다."라고 말하는 것뿐입니다.

이것이 바로 Agentic RAG가 해결하기 위해 만들어진 문제입니다.

전통적인 RAG: 일회성 검색 사무원

RAG가 어떻게 작동하는지 빠르게 요약해 보겠습니다.

**RAG (Retrieval-Augmented Generation, 검색 증강 생성)**의 핵심 아이디어는 간단합니다. LLM의 학습된 지식은 정적인 반면, 기업 데이터는 동적이고 비공개적이라는 점입니다. 해결책은 답변을 생성하기 전에 데이터베이스에서 관련 문서 청크(chunks)를 검색하여 컨텍스트(context)에 집어넣고, LLM이 해당 자료를 바탕으로 답변하게 하는 것입니다.

사용자 질문 → [벡터 검색 (vector search)] → 관련 청크 검색 → [LLM] → 답변 생성

이 파이프라인은 지식 베이스가 단일하고 질문이 명확할 때는 잘 작동합니다. 하지만 두 가지 근본적인 한계가 있습니다.

한계 1: 단일 검색 단계, 반복 없음. 한 번 검색하고, LLM에 한 번 전달하면 끝입니다. 만약 첫 번째 단계에서 핵심 정보를 놓치면 전체 체인이 무너지고, LLM은 추측을 하거나 "모르겠습니다"라고 말하게 됩니다.

한계 2: 단일 코퍼스 (corpus), 라우팅 없음. 전통적인 RAG는 모든 지식이 하나의 통합된 벡터 데이터베이스 (vector database)에 있다고 가정합니다. 실제 기업 환경에서 데이터는 CRM, ERP, Confluence, 데이터 웨어하우스 (data warehouses), 개인 문서 저장소 등에 흩어져 있으며, 각각 고유한 접속 지점과 권한 경계 (permission boundary)를 가지고 있습니다.

비유를 들자면, 전통적인 RAG는 1층에 있는 책만 찾을 수 있는 사서와 같습니다. 정작 당신에게 필요한 책은 4층에 있고, 다른 출입증이 있어야만 접근할 수 있을지도 모릅니다.

Agentic RAG: 스스로 생각하는 검색 부서

Agentic RAG의 핵심적인 변화는 이것입니다: 단일 검색 단계를 계획적이고 반복적인 검색 프로세스로 전환하는 것입니다.

더 이상 수동적인 쿼리 및 반환 (query-and-return) 파이프라인이 아닙니다. 이는 각각 고유한 책임을 가진 여러 전문 에이전트 (agents)에 의해 실행되는 워크플로우 (workflow)입니다.

고객 지원 티켓 (support-ticket) 사례를 통해 전체 워크플로우가 어떻게 작동하는지 살펴보겠습니다.

1단계: 오케스트레이터 (Orchestrator)의 작업 분해

사용자의 질문은 먼저 **오케스트레이터 (Orchestrator)**에 도달합니다.

오케스트레이터는 직접적으로 무언가를 검색하지 않습니다. 대신 질문의 구조를 먼저 이해합니다: 얼마나 많은 독립적인 정보 요구 사항이 포함되어 있는가? 그들 사이에 의존 관계가 있는가? 어떤 데이터 소스에 접근해야 하는가?

우리의 티켓 사례의 경우, 오케스트레이터는 이를 다음과 같이 분해합니다:

Subtask A: CRM에서 고객의 "Project Alpha" 기본 정보(고객 ID, 프로젝트 번호)를 조회합니다.
Subtask B: 프로젝트 번호를 사용하여 계약 시스템(contract system)에서 보증 조건(warranty terms)을 조회합니다.
Subtask C: 프로젝트 번호를 사용하여 자산 관리 시스템(asset management system)에서 장치 일련번호(serial numbers) 및 입고일(stock-in dates)을 조회합니다.
Subtask D: HR 시스템에서 현재 기술 지원 담당자(technical support owner)를 조회합니다.

Subtask B와 C는 Subtask A의 결과에 의존한다는 점(먼저 프로젝트 번호가 필요함)에 유의하세요. Subtask D는 병렬로 실행될 수 있습니다.

이 의존성 그래프(dependency graph)는 Planner Agent가 생성한 실행 계획(execution plan)입니다.

Step 2: 각 데이터 소스에 대한 쿼리 재작성 (Query Rewriting)

모든 데이터 소스는 서로 다른 형태의 쿼리를 기대합니다. CRM은 키워드 검색(keyword search)이 필요할 수 있고, 계약 시스템은 구조화된 SQL이 필요할 수 있으며, 벡터 데이터베이스(vector database)는 의미론적 검색(semantic search)이 필요할 수 있습니다.

Query Rewriter는 각 자연어 서브태스크(natural-language subtask)를 대상 소스가 이해할 수 있는 쿼리 형식으로 변환합니다:

CRM 벡터 스토어(vector store)용: "Alpha project procurement record {customer name}"
계약 시스템용: SELECT warranty_terms FROM contracts WHERE project_id = 'Alpha-XXX'
자산 관리용: "Alpha project server stock-in date serial number"

Step 3: 권한 경계를 가로지르는 병렬 검색 (Parallel Retrieval)

Search Fanout Agent는 여러 데이터 소스에 동시에 쿼리를 보냅니다.

여기에는 핵심적인 엔지니어링 문제인 권한(permissions) 문제가 있습니다.

데이터 소스마다 서로 다른 액세스 제어(access controls)가 적용됩니다. CRM 데이터는 영업 팀에 공개되어 있을 수 있고, HR 데이터는 관리자만 접근할 수 있을 수 있으며, 계약 데이터는 법무팀의 승인이 필요할 수 있습니다. Agentic RAG 프레임워크는 이 계층에서 각 데이터 소스에 대한 서로 다른 액세스 토큰(access tokens)인 "자격 증명 풀(credential pool)"을 유지해야 하며, 검색(retrieval)이 현재 사용자의 실제 권한 범위(authorization scope)를 절대 초과하지 않도록 보장해야 합니다.

이것은 단순한 기술적 문제가 아니라 컴플라이언스 (compliance) 문제이기도 합니다. AI는 단지 자연어 (natural language)로 요청을 구성했다는 이유만으로, 사용자가 원래 접근할 수 없었던 데이터 접근 제어 (data access controls)를 우회해서는 안 됩니다.

4단계: 충분성 검사 (Sufficiency Checking) -- 가장 중요한 혁신

모든 검색 (retrieval) 결과가 돌아오면, 이 결과들은 **충분성 컨텍스트 에이전트 (Sufficient Context Agent)**로 전달됩니다.

이 설계는 Agentic RAG를 전통적인 RAG와 가장 뚜렷하게 구분 짓는 요소입니다. 시스템이 지금까지 수집된 정보가 원래의 질문에 답하기에 충분한지 능동적으로 판단하며, 만약 부족하다면 다시 검색하기 전에 무엇이 누락되었는지 정확하게 명시합니다.

우리의 티켓 예시에서, 검사기 (checker)는 다음과 같은 결과를 찾아낼 수 있습니다:

✅ 발견됨: 고객 프로필, 프로젝트 번호, 장치 일련번호 (serial numbers)
✅ 발견됨: 기술 지원 담당자
❌ 누락됨: 계약 시스템이 문서를 반환했지만, 보증 조건 (warranty terms)은 벡터 검색 (vector search)이 포착하지 못한 첨부된 PDF 파일 안에 있음

검사기는 단순히 "정보가 부족합니다"라고 말하는 대신, 누락된 부분에 대한 정밀한 설명을 출력합니다:

"프로젝트 번호 Alpha-2024-087, 장치 일련번호 SN-XXX-YYY-ZZZ, 그리고 입고일 2024년 3월이 검색되었습니다. 메인 계약 파일은 발견되었으나, 보증 조건은 계약 첨부 파일 B (Contract Attachment B)에 있습니다. 'Attachment B 보증 기간'을 대상으로 계약 첨부 파일 저장소를 다시 검색하십시오."

이 피드백은 **두 번째 검색 라운드 (second retrieval round)**를 유도합니다. 즉, 재작성기 (rewriter)가 계약 첨부 파일에 특화된 더 정밀한 쿼리 (query)를 생성합니다.

이 "검색 → 평가 → 재검색" 루프는 충분성 검사기 (sufficiency checker)가 정보가 완전하다고 판단하거나, 최대 반복 제한 (maximum iteration limit)에 도달할 때까지 계속됩니다.

5단계: 합성을 통한 최종 답변 생성

모든 준비가 완료되면, **합성 에이전트 (Synthesis Agent)**가 네 가지 서로 다른 시스템에서 가져온 파편들을 하나의 일관되고 정확하며 출처가 명시된 (source-attributed) 답변으로 결합합니다:

"Project Alpha(프로젝트 번호 Alpha-2024-087, 일련번호 SN-XXX-001부터 003까지) 하에 구매된 세 대의 서버는 계약 부속서 B(Contract Attachment B)의 섹션 4.2에 따라 입고일(2024년 3월 15일)로부터 36개월간의 보증 기간을 가지며, 2027년 3월 14일에 만료됩니다. 현재 기술 지원 담당자는 Li Ming(내선 번호 4521, liming@company.com)입니다."

모든 문장은 추적 가능한 출처를 가지고 있습니다.

시스템 간 권한 (Cross-System Permissions): 기술보다 더 어려운 문제

**권한 경계 (permission boundaries)**를 처리하는 문제는 별도의 논의가 필요합니다.

실제 기업 환경에서 데이터 권한은 다차원적인 문제입니다:

차원	설명	예시
역할 기반 액세스 (Role-based access)	역할에 따라 서로 다른 데이터를 확인	영업팀은 계약 요약본은 볼 수 있지만 전체 본문은 볼 수 없음
...

Agentic RAG 프레임워크는 인덱싱(indexing) 시점에 단 한 번 액세스를 승인하는 것이 아니라, **모든 개별 검색 호출 (retrieval call)**에 대해 이러한 규칙을 강제해야 합니다.

이는 모든 것을 하나의 거대한 저장소에 벡터화(vectorizing)하는 무차별적인 방식 대신, 아키텍처 차원에서 **쿼리 시점의 권한 확인 (permission checks at query time)**이 필요함을 의미합니다.

데이터베이스 용어로 설명하자면: 전통적인 RAG는 모든 테이블을 하나의 거대한 테이블로 조인(join)하여 LLM에 전달하는 것과 같습니다. 반면 Agentic RAG는 모든 요청에 대해 권한 필터링이 적용된 SQL 쿼리를 동적으로 생성하는 것과 같습니다.

실제 구축 시 피할 수 없는 세 가지 결정 사항

실제로 운영 환경에서 Agentic RAG를 구축할 때, 매번 세 가지 결정 사항에 직면하게 됩니다.

결정 사항 1: 라우팅 전략 (routing strategy) -- 정적 규칙인가, LLM 라우팅인가?

정적 라우팅 (Static routing): 쿼리의 키워드나 메타데이터를 기반으로 규칙을 미리 정의하여 어떤 데이터 소스를 사용할지 결정합니다. 빠르고 예측 가능하지만, 개방형 쿼리(open-ended queries)에는 취약합니다.

LLM 라우팅 (LLM routing): LLM이 쿼리의 의도(intent)를 이해하고 어디로 라우팅할지 동적으로 결정하게 합니다. 유연하지만, 모든 라우팅 결정마다 LLM 호출이 발생하여 지연 시간(latency)과 비용이 추가됩니다.

결정 사항 2: 반복 깊이 (iteration depth) -- 언제 멈출 것인가?

시스템이 무한 루프에 빠질 수 있습니다. 검색(retrieval)을 수행할 때마다 무언가 계속 누락된 것처럼 느껴져 계속해서 검색을 시도하기 때문입니다.

엔지니어링 측면에서는 다음 요소들이 필요합니다:

최대 반복 횟수 (maximum iteration count) (통상적으로 2~4회)
시간 예산 (time budget) (시간 초과 시 현재 확보된 정보로 답변)
성능 저하 전략 (degradation strategy) (반복 제한에 도달하면 가용한 정보로 답변하되, 정보가 불완전할 수 있음을 표시)

결정 사항 3: 지연 시간(latency) 대 정확도(accuracy)의 트레이드오프

Agentic RAG는 전통적인 RAG보다 느립니다. 이는 피할 수 없는 부분입니다. 여러 번의 LLM 호출, 병렬 검색(parallel retrieval), 그리고 충분성 평가(sufficiency evaluation)가 모든 단계에서 지연 시간을 추가하기 때문입니다.

접근 방식	비용 배수	지연 시간 배수	최적의 용도
전통적인 RAG (Traditional RAG)	1x	1x	단순 질의응답, 단일 지식 베이스
...

모든 시나리오에 완전한 Agentic RAG가 필요한 것은 아닙니다.

쿼리 수준에서 의도(intent)를 분류하여, 복잡한 쿼리는 Agentic 파이프라인으로 라우팅하고 단순한 쿼리는 전통적인 RAG로 보내는 방식은 평균 비용과 지연 시간을 합리적인 범위 내로 유지해 줍니다.

마치며

Agentic RAG의 본질은 검색을 실행 가능한 전략으로 전환하는 것이라고 생각합니다: 한 번의 패스(pass)로 충분하지 않다면, 충분해질 때까지 계속 검색하십시오. 그리고 무엇이 "충분한지"는 시스템 스스로가 결정합니다.

이러한 변화는 단순해 보이지만, 상태가 없는(stateless) "질의-응답" 모델에서 상태를 유지하는(stateful) "목표-계획-실행-평가-반복(goal-plan-execute-evaluate-iterate)" 워크플로우로의 전환을 요구합니다.

이는 모든 에이전트 시스템이 직면하는 동일한 일반적 과제입니다: 상태 관리(state management)가 핵심적인 어려움입니다.

여러 데이터 소스에 걸쳐 있는 기업용 AI 시스템을 구축하고 있다면, Agentic RAG는 단순히 검색 기술을 업그레이드하는 것이 아닙니다. 이는 데이터 아키텍처, 권한 설계, 그리고 워크플로우 오케스트레이션(workflow orchestration)을 재고하도록 강제합니다. 이 세 가지를 제대로 구현하는 것이 어떤 프레임워크나 클라우드 벤더를 선택하느냐보다 더 중요합니다.