RAG + Agent: 차세대 AI 애플리케이션 아키텍처

어느 회사가 3개월 동안 구축한 RAG 시스템이 출시 첫 주부터 사장에게 지적받았습니다. “이게 왜 간단한 출장비 정산 질문조차 제대로 답하지 못하지?”

기존 RAG는 사전만 찾을 줄 아는 학생과 같습니다. 질문을 받으면 그대로 검색할 뿐, 질문 뒤에 숨은 의도는 전혀 생각하지 못합니다. 사용자가 “지난달 출장비 정산이 거절된 이유가 무엇인가요?”라고 물으면 기존 RAG는 출장 정책 문서를 잔뜩 찾아낼 수는 있지만, 먼저 사용자의 실제 정산 기록을 확인해야 한다는 사실은 알지 못할 수 있습니다.

바로 이것이 Agentic RAG가 해결하려는 문제입니다.

이 글에서는 기업용 AI 애플리케이션을 재편하고 있는 RAG + Agent 융합 아키텍처를 다룹니다. 아키텍처의 발전 과정부터 프레임워크 선택, 구체적인 구현 로드맵까지 살펴보고, AI 고객 지원의 실제 사례도 공유하겠습니다. 여러분에게 유용한 힌트가 되기를 바랍니다.

기존 RAG에서 Agentic RAG로: 아키텍처의 발전

기존 RAG의 작동 원리는 사실 매우 간단합니다. 사용자 질문 → 벡터 검색 → 관련 문서 가져오기 → LLM에 전달해 답변 생성. 세 단계면 끝입니다.

이 아키텍처의 장점은 분명합니다. 빠르고 저렴하며 구현하기 쉽습니다. 하지만 문제도 함께 따라옵니다.

부정확한 검색. 사용자가 모호한 질문을 하면 벡터 유사도 검색이 “겉으로는 비슷하지만 실제로는 관련 없는” 문서를 잔뜩 찾아낼 수 있습니다. 예를 들어 “데이터베이스 연결을 어떻게 설정하나요?”라고 물었는데 검색 결과에 MySQL과 PostgreSQL 문서가 섞여 나오면 사용자가 직접 구분해야 합니다.

추론하지 못함. 기존 RAG는 “검색-생성”이라는 동작만 수행할 수 있어 여러 단계가 필요한 문제를 만나면 막힙니다. “방안 A와 방안 B의 장단점을 비교해 주세요”라고 물었는데 한쪽 방안의 문서만 검색한 뒤 자신 있게 엉뚱한 답을 내놓을 수도 있습니다.

"McKinsey 조사에 따르면 GenAI 사용자의 47%가 부정적인 결과를 경험했으며, 모든 출력을 검토하는 사용자는 27%에 불과합니다."

Agentic RAG가 가져오는 변화

Agentic RAG의 핵심 아이디어는 AI가 검색-생성을 기계적으로 실행하는 대신, 문제를 어떻게 해결할지 능동적으로 “생각”하게 만드는 것입니다.

핵심 루프는 다음과 같습니다.

Plan → Retrieve → Act → Reflect → Answer

하나씩 설명하겠습니다.

Plan(계획): 먼저 사용자의 질문을 분석하고 하위 작업으로 나눕니다. “지난달 출장비 정산이 거절됐습니다”라는 문제는 사용자의 정산 기록 확인, 출장 정책 확인, 거절 사유 비교 분석으로 나눌 수 있습니다.

Retrieve(검색): 계획에 따라 어디에서 무엇을 검색할지 결정합니다. 지식 베이스와 데이터베이스를 동시에 확인하거나 외부 API까지 호출해야 할 수 있습니다.

Act(행동): 검색을 실행하고 도구를 호출해 정보를 확보합니다. 이 단계에서 새로운 문제가 발견되면 다시 계획해야 할 수도 있습니다.

Reflect(성찰): 검색 결과가 충분한지, 답변이 합리적인지 평가합니다. 부족하다면 Plan 단계로 돌아가 다시 시작할 수 있습니다.

Answer(답변): 마지막으로 출처 인용을 포함한 답변을 생성합니다.

쉽게 말해 기존 RAG가 사전을 찾는 것이라면, Agentic RAG는 연구 조교를 두는 것과 같습니다. 문제를 분석하고, 자료를 찾고, 정보를 검증한 뒤 신뢰할 수 있는 답변을 내놓습니다.

이 수치는 기업이 AI에 기대하는 수준이 “쓸 수 있음”에서 “잘 쓸 수 있음”으로 높아지고 있음을 보여 줍니다. Agentic RAG는 바로 이 전환의 핵심 단계입니다.

10가지 RAG 아키텍처 패턴 상세 설명

다룰 내용이 많아 핵심을 중심으로 설명하겠습니다. 전체 아키텍처 비교표는 뒤에 있으니 먼저 전반적인 그림부터 잡아 보세요.

Naive RAG: 입문용 선택

가장 단순한 아키텍처입니다. 사용자 질문 → 벡터 검색 → 답변 생성. 아이디어를 빠르게 검증하는 데 적합하지만, 프로덕션 환경에는 대체로 부족합니다.

대표적인 문제는 낮은 검색 정확도, 컨텍스트 창 낭비, 심각한 환각입니다. 개인적으로 POC나 내부 도구를 만들 때만 사용하는 것을 권합니다.

Hybrid RAG: 엔터프라이즈 프로덕션 표준

현재 이 패턴은 사실상 엔터프라이즈 프로덕션 환경의 기준입니다. 핵심은 어휘 검색(키워드 일치)과 의미 검색(벡터 유사도)이라는 두 가지 검색 방식을 결합하는 것입니다.

왜 그럴까요? 두 검색 방식은 서로 다른 장점이 있기 때문입니다. 어휘 검색은 정확한 일치에 강하고, 의미 검색은 의도 파악에 강합니다. 두 방식을 결합하면 자연스럽게 결과가 좋아집니다.

구현할 때는 BM25로 어휘 검색을 수행하고 벡터 데이터베이스(Pinecone, Weaviate, Milvus 모두 가능)로 의미 검색을 수행한 뒤, 역순위 융합(RRF)을 통해 결과를 합칠 수 있습니다.

Graph RAG: 다중 홉 추론의 강력한 도구

비즈니스에서 “왜 그런가”, “어떻게 연결되는가”와 같은 질문에 답해야 한다면 Graph RAG를 고려할 만합니다.

문서에서 엔티티를 추출해 지식 그래프를 구축하고 다중 홉 추론을 지원합니다. 예를 들어 “어떤 제품이 이 공급업체의 부품을 사용하나요?”라고 물으면 Graph RAG가 그래프의 관계 사슬을 따라 답을 찾을 수 있습니다.

대신 비용은 기본 RAG보다 3~5배 높습니다. 지식 그래프를 구축하고 유지하는 데 모두 큰 비용이 들기 때문입니다.

Agentic RAG: 능동적 사고형

앞에서 핵심 루프를 설명했습니다. 여기서 한 가지 덧붙이자면 Agentic RAG의 유연성은 양날의 검입니다.

장점은 복잡한 문제를 처리할 수 있다는 것이고, 단점은 지연 시간이 길고 비용을 통제하기 어렵다는 것입니다. 간단한 질문 하나가 여러 번의 검색과 도구 호출을 일으켜 API 호출 비용이 빠르게 늘어날 수 있습니다. 따라서 실제 배포에서는 보통 라우팅 전략을 함께 사용합니다. 간단한 질문은 기존 RAG로 처리하고 복잡한 질문만 Agentic 프로세스로 보냅니다.

Self-RAG: 자가 교정형

이 패턴의 핵심은 모델이 자신의 출력을 평가하게 하는 것입니다. 검색된 문서가 충분히 관련성이 있는가? 생성한 답변에 환각은 없는가?

평가를 통과하지 못하면 모델이 능동적으로 다시 검색하거나 답변을 수정합니다. 이상적으로 들리지만 추론 비용이 늘어나고, 평가 자체도 잘못될 수 있습니다.

Agentic Graph RAG: 최고 수준

현재 가장 발전된 패턴입니다. 지식 그래프 검색에 Agent 오케스트레이션 능력을 결합해 다중 홉 추론과 능동 계획 능력을 모두 갖춥니다.

물론 비용도 최고 수준이므로 핵심 비즈니스 시나리오에만 사용하는 것이 좋습니다.

아키텍처 패턴 비교표

아키텍처 패턴	복잡도	적합한 시나리오	상대 비용	지연 시간
Naive RAG	낮음	빠른 검증, 내부 도구	1x	<1s
Hybrid RAG	중간	엔터프라이즈 프로덕션 표준	1.5x	1-2s
Graph RAG	높음	다중 홉 추론, 지식 집약형	3-5x	2-4s
Agentic RAG	높음	복잡한 의사결정, 다단계 작업	3-8x	3-10s
Self-RAG	중상	높은 정확도가 필요한 시나리오	2-3x	2-4s
Agentic Graph RAG	매우 높음	핵심 비즈니스, 복잡한 추론	5-10x	5-15s

Hybrid RAG로 시작해 실제 요구에 따라 단계적으로 확장하는 것을 권합니다. 처음부터 가장 발전된 아키텍처만 좇으면 실패하기 쉽습니다.

프레임워크 선택: LangChain vs LlamaIndex vs CrewAI vs AutoGen

저도 이 부분에서 시행착오를 겪었습니다. 예전 프로젝트에서 처음 선택한 프레임워크의 생태계가 충분히 성숙하지 않았다는 사실을 중간에 깨닫고 결국 리팩터링해야 했습니다. 시간도 낭비했고 팀 사기에도 영향을 미쳤습니다.

그래서 프레임워크 선택은 정말 중요합니다. 시행착오를 줄이는 데 도움이 되도록 주요 프레임워크의 특징과 사용 시나리오를 정리했습니다.

LangChain / LangGraph: 가장 완성도 높은 생태계

무엇을 선택할지 모르겠다면 LangChain을 고르는 것이 대체로 안전합니다. 현재 가장 완성도 높은 생태계를 갖춘 프레임워크로, 문서가 잘 갖춰져 있고 커뮤니티가 활발하며 LangGraph의 GitHub stars는 25K를 넘습니다.

LangGraph는 LangChain 팀이 만든 그래프 상태 머신 프레임워크로, 상태가 있는 Agent 워크플로를 구축하는 데 특화되어 있습니다. 핵심 장점은 프로덕션급 영속성을 지원한다는 것입니다. Agent 상태를 데이터베이스에 저장할 수 있으며, 중단 지점에서 이어서 실행하거나 시간 여행 디버깅을 수행할 수 있습니다.

적합한 시나리오: 프로덕션급 워크플로, 상태 영속성이 필요한 작업, 복잡한 Agent 오케스트레이션.

# LangGraph 간단 예제: 쿼리 계획 에이전트
from langgraph.graph import StateGraph

def plan_query(state):
    """사용자 질문을 분석하고 검색 단계를 계획합니다."""
    query = state["query"]
    # 문제를 분해하고 하위 쿼리를 생성합니다.
    sub_queries = decompose(query)
    return {"sub_queries": sub_queries}

def retrieve(state):
    """검색을 실행합니다."""
    results = []
    for q in state["sub_queries"]:
        docs = retriever.invoke(q)
        results.extend(docs)
    return {"context": results}

# 워크플로를 구성합니다.
workflow = StateGraph(AgentState)
workflow.add_node("plan", plan_query)
workflow.add_node("retrieve", retrieve)
workflow.add_edge("plan", "retrieve")

LlamaIndex: 데이터 집약형 작업의 첫 번째 선택

비즈니스 시나리오에서 대량의 비정형 데이터(문서, 데이터베이스, API)를 다룬다면 LlamaIndex가 더 나은 선택입니다.

쿼리 엔진이 잘 설계되어 있으며 벡터 검색, 키워드 검색, 하이브리드 검색, 지식 그래프 검색 등 다양한 검색 전략을 지원합니다. 또한 여러 데이터 소스를 연결하는 커넥터 지원도 매우 잘 갖춰져 있습니다.

적합한 시나리오: 데이터 집약형 RAG 애플리케이션, 다양한 데이터 소스 연동, 검색 품질을 중시하는 작업.

CrewAI: 빠른 프로토타입을 위한 강력한 도구

CrewAI의 강점은 “역할 중심의 멀티 에이전트 팀”입니다. 여러 Agent 역할을 정의하고 협력해 작업을 완료하도록 만들 수 있습니다.

예를 들어 콘텐츠 제작 팀을 구성할 수 있습니다. 연구원은 자료를 수집하고, 작성자는 글을 쓰며, 편집자는 원고를 검토합니다. 각 역할은 고유한 목표와 도구를 갖습니다.

적합한 시나리오: 빠른 프로토타입 검증, 비즈니스 프로세스 자동화, 역할 분담이 명확한 작업.

현재 CrewAI의 개발자 커뮤니티는 10만 명이 넘고 GitHub stars는 20K를 넘으며 생태계가 빠르게 성장하고 있습니다.

AutoGen: Microsoft가 지원하는 멀티 에이전트 프레임워크

AutoGen은 Microsoft Research가 오픈 소스로 공개한 멀티 에이전트 프레임워크로, 대화형 협업에 중점을 둡니다. 여러 Agent가 대화를 통해 작업을 완수하며 여러 차례 상호작용이 필요한 시나리오에 적합합니다.

특징은 인간과 AI의 협업을 지원한다는 점입니다. 사람이 언제든 대화에 개입해 Agent의 방향을 바로잡을 수 있습니다.

적합한 시나리오: 연구 프로젝트, 인간과 AI의 협업이 필요한 복잡한 작업, 대화형 상호작용.

GitHub stars는 50K를 넘어 현재 stars 수가 가장 많은 Agent 프레임워크입니다.

선택 의사결정 트리

간단한 의사결정 흐름을 그려 보았습니다.

프로젝트 유형은 무엇인가요?
├── 프로덕션급 영속 워크플로 → LangGraph
├── 데이터 집약형 RAG → LlamaIndex
├── 빠른 프로토타입/비즈니스 프로세스 → CrewAI
├── 연구/대화형 멀티 에이전트 → AutoGen
└── 불확실함/최대의 유연성이 필요함 → LangChain + LangGraph

결국 프레임워크 선택에는 정답이 없습니다. 팀의 기술 스택과 프로젝트 요구에 따라 선택하되, 프레임워크의 업데이트 빈도와 커뮤니티 활성도도 확인하는 것이 좋습니다. 이는 이후 유지보수 비용에 직접 영향을 줍니다.

엔터프라이즈 구현 로드맵

여기서는 여러 기업의 실무 경험을 바탕으로 정리한 90일 구현 템플릿을 소개합니다. 물론 회사마다 속도가 다르므로 실제 상황에 맞게 조정할 수 있습니다.

1단계: Day 0-15, 문제와 KPI 정의

많은 사람이 처음부터 기술 선택에 뛰어드는데, 이는 잘못된 접근입니다. 먼저 무엇을 해결하려는지 명확히 해야 합니다.

다음 핵심 질문에 답해야 합니다.

1. 사용자는 누구인가요? 내부 직원인가요, 외부 고객인가요?
2. 핵심 시나리오는 무엇인가요? 질의응답, 검색, 복잡한 추론 중 무엇인가요?
3. 성공 지표를 어떻게 정할까요? 정확도, 응답 시간, 사용자 만족도 중 무엇인가요?

이 단계에서는 간단한 사용자 조사를 수행해 실제 질문 50~100개를 수집하는 것이 좋습니다. 이 질문들은 이후 테스트 세트와 평가 기준으로 활용됩니다.

2단계: Day 16-45, 데이터 준비와 검색 계층

데이터 준비는 많은 수작업이 필요하지만 시스템의 성능 상한을 결정합니다.

데이터 정제: 중복되거나 오래되었거나 민감한 콘텐츠를 제거합니다. 이 단계는 쉽게 간과되지만 오염된 데이터는 검색 품질을 크게 떨어뜨립니다.

청킹 전략: 문서 유형에 따라 적절한 청크 크기를 선택합니다. 기술 문서는 청크당 500~1,000자 정도가 적합할 수 있고, 법률 조문은 조항 단위로 나눠야 할 수 있습니다.

Embedding 선택: OpenAI의 text-embedding-3 시리즈, Cohere, BGE 모두 좋은 선택입니다. 먼저 소규모 데이터 세트에서 비교 테스트하는 것을 권합니다.

검색 계층 구축: BM25와 벡터 검색을 결합한 Hybrid RAG부터 시작합니다.

3단계: Day 46-75, Agent 오케스트레이션과 도구 통합

이 단계부터 Agent 기능을 도입합니다.

라우팅 전략: 모든 질문에 Agent가 필요한 것은 아닙니다. 간단한 FAQ는 기존 RAG로 바로 처리하고 복잡한 질문만 Agent 프로세스로 보냅니다. 이렇게 하면 비용과 지연 시간을 통제할 수 있습니다.

도구 통합: MCP 프로토콜을 통해 내부 시스템에 연결합니다. 데이터베이스 쿼리, API 호출, 문서 검색 등이 포함될 수 있습니다.

오케스트레이션 설계: LangGraph 또는 비슷한 도구로 워크플로를 설계합니다. 간단한 ReAct 패턴으로 시작해 점차 복잡도를 높이는 것이 좋습니다.

4단계: Day 76-90, 평가, 테스트, 강화

평가에는 RAGAS 프레임워크를 사용하고 다음 세 가지 지표에 집중하는 것을 권합니다.

• Faithfulness(충실도): 생성한 답변이 검색 문서를 충실히 따르는지 평가하며, 목표는 >= 0.8입니다.
• Answer Relevance(답변 관련성): 답변이 사용자의 질문에 제대로 응답하는지 평가합니다.
• Context Relevance(컨텍스트 관련성): 검색된 문서의 관련성이 충분한지 평가합니다.

그 밖에 다음 기술 지표도 있습니다.

• Recall@K >= 0.85: 상위 K개 검색 결과의 재현율
• P95 latency <= 2.5s: 요청 중 95%의 응답 시간
• 비용 관리: 요청당 API 호출 횟수와 Token 소비량

흔히 빠지는 함정

마지막으로 자주 발생하는 문제 몇 가지를 짚겠습니다.

1. 접근 제어 우회: Agent가 도구 호출을 통해 권한 제어를 우회할 수 있으므로 보안 테스트를 철저히 해야 합니다.
2. 컨텍스트 만료: 대화가 길어지면 초기 정보가 사라질 수 있으므로 컨텍스트 관리 전략을 설계해야 합니다.
3. 비용 통제 실패: Agent가 여러 차례 검색을 일으켜 API 호출 비용이 빠르게 증가할 수 있습니다.

실전 사례: AI 고객 지원 도우미 아키텍처 설계

이 사례는 예전에 한 기업을 지원하며 진행한 프로젝트로, 효과가 꽤 좋았습니다.

시나리오: 기업 고객 지원 부서는 제품, 주문, 애프터서비스, 정책 등 여러 영역에 관한 사용자의 질문에 답해야 합니다. 관련 정보는 지식 베이스, CRM 시스템, 주문 시스템, ERP 시스템에 흩어져 있습니다.

문제: 기존 RAG는 지식 베이스만 검색할 수 있어 사용자의 주문 상태와 과거 기록 같은 개인화된 정보를 조회할 수 없습니다.

아키텍처 설계

저희는 3계층 Agent 아키텍처를 설계했습니다.

1계층: Routing Agent(라우팅 에이전트)

사용자의 질문을 분석해 다음 단계에서 어떤 분기로 보낼지 결정합니다. 예를 들면 다음과 같습니다.

• “제품은 어떻게 사용하나요?” → 지식 베이스 검색
• “제 주문은 어디까지 왔나요?” → 주문 시스템 조회
• “환불 정책이 어떻게 되나요?” → 정책 문서 검색

2계층: Query Planning Agent(쿼리 계획 에이전트)

복잡한 문제를 여러 하위 쿼리로 나눕니다. 예를 들어 사용자가 “지난달에 산 휴대폰을 반품할 수 있나요?”라고 묻는다면 다음 작업이 필요합니다.

1. 사용자의 주문 기록 조회
2. 반품 정책 조회
3. 주문 날짜와 정책의 유효 기간 비교

3계층: ReAct Agent(추론 행동 에이전트)

구체적인 검색과 도구 호출을 실행하고 여러 차례 반복할 수 있습니다.

도구 통합

MCP 프로토콜을 통해 내부 시스템에 연결합니다.

tools:
  - name: knowledge_search
    type: vector_retrieval
    source: product_docs

  - name: order_query
    type: api_call
    endpoint: /api/orders/{user_id}

  - name: policy_search
    type: hybrid_retrieval
    sources: [policy_docs, faq]

결과 비교

출시 후 기존 RAG와 Agentic RAG의 성능을 비교했습니다.

지표	기존 RAG	Agentic RAG
문제 해결률	45%	78%
평균 응답 시간	1.2s	3.5s
사용자 만족도	3.2/5	4.1/5
상담원 개입률	55%	22%

문제 해결률은 33%포인트 높아졌고 상담원 개입률은 절반 이상 줄었습니다. 대신 응답 시간은 늘어났습니다. 이는 Agent 아키텍처가 피하기 어려운 대가이며, 사용자 경험과 효율 사이에서 균형을 잡아야 합니다.

결론

RAG + Agent는 기업용 AI 애플리케이션의 표준 아키텍처로 자리 잡고 있습니다. 수동 검색에서 능동 추론으로 발전한 이 아키텍처를 통해 AI는 실제로 복잡한 문제를 처리할 수 있게 되었습니다.

몇 가지 제안:

1. 간단하게 시작하세요. 처음부터 Agentic Graph RAG를 추구하지 마세요. Hybrid RAG로 시작해 가치를 검증한 뒤 확장하세요.

2. 비용 관리에 집중하세요. Agent의 유연성에는 대가가 따르며 API 호출 비용은 쉽게 통제 불능이 될 수 있습니다. 라우팅 전략과 캐시 메커니즘은 반드시 필요합니다.

3. 평가 체계를 중요하게 다루세요. 정량 지표가 없으면 시스템이 좋은지 나쁜지 알 수 없습니다. RAGAS 프레임워크와 자체 테스트 세트 구축은 기본입니다.

4. 개방형 프로토콜을 주목하세요. MCP는 도구 연결의 표준으로 자리 잡고 있으며 A2A 프로토콜은 프레임워크 간 협업 문제를 해결하고 있습니다. 이러한 프로토콜은 Agent 생태계의 발전에 큰 영향을 미칠 것입니다.

대략 이 정도입니다. RAG 시스템을 구축하고 있다면 이 글이 참고가 되기를 바랍니다. 질문이 있으면 댓글로 함께 이야기해 주세요.