비슷한 옷을 입고 있는 두 가지 서로 다른 문제. 작동하는 코드를 통해 30초 만에 이 둘을 구분하는 방법을 알려드립니다.

저는 거의 모든 프로젝트 시작 단계에서 이런 혼란을 목격합니다: 실제 요구사항은 에이전트 방식(agentic)인데 "RAG가 필요해요"라고 말하거나, RAG가 더 간단하고 저렴하며 빠르게 출시할 수 있음에도 "에이전트가 필요해요"라고 말하는 경우 말이죠.

실제로 사용할 수 있는 의사결정 트리와 각 경로에 대한 작동하는 코드로 이 문제를 해결해 보겠습니다.

의사결정 트리 (The Decision Tree)

시스템이 문서로부터 질문에 답변(ANSWER QUESTIONS)해야 합니까?
├── 예, 그리고 그것이 작업의 전부입니다 → RAG
└── 예, 하지만 여러 시스템에 걸쳐 행동(TAKE ACTIONS)을 취해야 합니다
...

대부분의 혼란을 해결하는 테스트 질문은 다음과 같습니다: "이 시스템이 무엇을 할지 결정해야 합니까, 아니면 정보를 찾고 합성(synthesise)해야 합니까?" 정보를 찾고 합성하는 것 → RAG. 결정하고 행동하는 것 → 에이전트(agent).

경로 1: 순수 RAG (Pure RAG)

RAG는 LLM의 응답을 특정 문서 세트에 근거(grounding)시키고, 질문에 답하며, 콘텐츠를 요약하고, 관련 구절을 찾는 것이 작업일 때 적합한 아키텍처입니다.

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import Chroma
...

이것이 작업의 전부입니다: 관련 청크(chunks)를 검색하고, LLM의 답변을 그에 근거하게 하며, 인용(citations)과 함께 응답을 반환합니다. 계획 루프(planning loop), 도구 오케스트레이션(tool orchestration), 다단계 의사결정(multi-step decision-making)이 없습니다. 만약 당신의 유스케이스(use case)가 여기서 끝난다면, 이 위에 에이전트 인프라를 구축하는 것은 불필요한 복잡성을 초래합니다.

경로 2: 순수 에이전트 (Pure Agent, RAG 없음)

에이전트는 작업이 행동을 취하고, 시스템을 확인하며, 작업을 실행하고, 여러 단계에 걸친 결정을 내리는 것이며, 문서 지식 베이스가 관여되지 않을 때 적합합니다.

import anthropic

client = anthropic.Anthropic()
...

문서가 관여되지 않습니다. 에이전트는 재고를 확인하고, 임계값(threshold)에 대해 추론하며, 조건부로 구매 주문을 생성합니다. 이것은 순수한 행동 오케스트레이션(action orchestration)입니다.

경로 3: RAG를 도구로 사용하는 하이브리드 에이전트 (The Hybrid Agent Using RAG as a Tool)

이것이 실제로 대부분의 실제 엔터프라이즈 시스템이 도달하는 지점입니다. 즉, 행동을 취해야 하는 에이전트이며, 그 과정에서 수행해야 할 작업 중 하나가 문서 지식 베이스(knowledge base)에서 무언가를 찾아보는 것입니다.

import anthropic

client = anthropic.Anthropic()
...

에이전트는 issue_refund(환불 실행)를 호출할지 결정하기 전에, 자격 요건을 확인하기 위해 search_policy_documents(정책 문서 검색)를 호출하기로 결정합니다. RAG 시스템은 자신이 잘하는 일인 근거 기반 검색(grounded retrieval)을 정확히 수행하고 있지만, 시스템 전체가 아닌 에이전트의 더 넓은 의사결정을 돕는 도구로서 작동하고 있습니다.

비용과 복잡성의 현실

RAG 전용 시스템은 구축 및 운영 비용이 더 저렴합니다. 단일 검색 호출(retrieval call), 단일 생성 호출(generation call), 예측 가능한 지연 시간(latency), 그리고 더 쉬운 평가(검색 정밀도와 답변 정확도를 독립적으로 측정 가능)가 특징입니다.

에이전트 기반(Agentic) 시스템은 비용이 더 많이 들고 디버깅이 더 어렵습니다. 작업당 여러 번의 LLM 호출이 발생하며, 에이전트가 몇 번의 반복(iteration)을 거치느냐에 따라 지연 시간이 예측 불가능합니다. 또한 실패가 계획 단계(planning stage)나 실행 단계(execution stage) 중 어디에서 발생했는지 알기 어려워 평가가 까다롭습니다. 하지만 여러 시스템에 걸쳐 다단계 행동(multi-step action)이 진정으로 필요한 작업의 경우, 에이전트 방식이 유일한 선택지입니다.

우리가 가장 자주 목격하는 실수는 다음과 같습니다. 팀들이 근본적으로 질의응답(question-answering) 문제인 사안에 대해 에이전트 인프라를 구축하여, 필요하지 않은 기능에 대해 복잡성 비용을 지불하는 것입니다.

전체 RAG vs agentic AI 비교 글에서는 비용 모델링, 지연 시간 벤치마크, 그리고 평가 방법론의 차이점을 더 심도 있게 다룹니다.

이 결정 이후의 단계

아키텍처를 선택했다면, 다음 질문은 '직접 구축할 것인가(build) 아니면 구매할 것인가(buy)'입니다. 이 RAG 파이프라인(pipeline)이나 에이전트 루프(agent loop)를 직접 구축할 것인가요, 아니면 관리형 플랫폼(managed platform)을 사용할 것인가요? 그 답은 여러분의 일정, 팀의 역량, 그리고 특정 유스케이스(use case)가 실제로 얼마나 차별화되어 있는지에 따라 달라집니다. 저희는 바로 이 질문을 위해 비용 모델(cost models), 예상 시간, 그리고 결정 기준을 포함한 프레임워크를 작성했습니다. 어느 쪽으로든 엔지니어링 시간을 투입하기 전에 이 내용을 읽어볼 가치가 있습니다.

Dextra Labs 발행 | AI 컨설팅 및 엔터프라이즈 에이전트 개발