"RAG 쓰지 말고 Agent한테 시켜라" — 이 말, 진짜일까?

최근 AI 커뮤니티에서 흥미로운 주장이 돌고 있다. "RAG 파이프라인 만들지 말고, 그냥 Agent한테 직접 찾게 해라." 벡터 DB에 문서를 청킹해서 넣고 유사도 검색을 돌리는 대신, Agent에게 도구를 쥐어주고 스스로 탐색하게 하라는 것이다.

 

실제로 SOC(보안관제센터) 환경에서 WAF 로그 분석 Agent를 직접 구현해보면서, 이 주장에 대해 꽤 깊이 고민하게 되었다. 결론부터 말하면, 이건 반은 맞고 반은 과장이다.

[ RAG의 고질적인 문제 ]

RAG가 만능이 아니라는 건 써본 사람이면 다 안다. 대표적인 문제는 세 가지다.

 

첫째, 청킹 전략이 도메인마다 다르다. 보안 로그를 500토큰 단위로 자르는 것과, 법률 문서를 500토큰 단위로 자르는 건 완전히 다른 문제다. 청킹 하나 잘못 잡으면 retrieval 품질이 바닥을 친다.

* retrieval: LLM이 답변을 생성하기 전에, 외부 데이터 소스(벡터 DB, 문서, API 등)에서 질문과 관련된 정보를 찾아오는 과정으로, RAG에서 R에 해당한다.

 

둘째, 임베딩 기반 유사도 검색이 생각보다 부정확하다. "이 IP의 최근 접속 패턴"을 물었는데, "IP 주소 체계 설명" chunk가 올라오는 식이다. 의미적으로 비슷해 보이지만 실제로는 엉뚱한 결과가 나오는 경우가 많다.

 

셋째, 원본 문서의 맥락이 소실된다. 문서를 chunk 단위로 쪼개는 순간, 앞뒤 문맥이 사라진다. 특히 표나 코드 블록이 포함된 기술 문서에서 이 문제가 심각하다.

 

이런 문제들이 "RAG 쓰지 마라"는 주장의 배경이다. 충분히 일리가 있다.

[ 그래서 등장한 Agentic RAG ]

"RAG vs Agent"라는 이분법은 사실 잘못된 프레이밍이다. 업계와 학계가 수렴하고 있는 방향은 Agentic RAG라는 패러다임이다. 이건 내가 만든 용어가 아니라, 2025년 1월 arXiv에 올라온 서베이 논문에서 체계적으로 정리된 개념이다.

 

핵심 아이디어는 단순하다. retrieval 자체를 Agent의 도구 중 하나로 편입시키는 것이다.

 

전통적인 RAG는 파이프라인이 고정되어 있다. 쿼리가 들어오면 무조건 임베딩 → 벡터 검색 → top-k chunk 반환 → LLM에 주입이다. 이 고정된 경로가 모든 종류의 질문을 감당해야 한다.

 

반면 Agentic RAG에서는 Agent가 질문의 성격에 따라 다른 도구를 선택한다. "이 IP의 최근 7일 로그 보여줘"는 ES aggregation 쿼리를 직접 날리고, "이 공격 패턴이 과거에도 있었어?"는 벡터 검색 도구를 쓰는 식이다.

 

A-RAG 논문(2026)에서는 기존 RAG를 두 가지로 분류한다. 한 번에 여러 패시지를 검색해서 모델 입력에 붙이는 방식과, 미리 정의된 워크플로우를 단계별로 따르는 방식이다. 둘 다 진정한 의미의 "에이전틱"은 아니다. 모델이 작업에 따라 전략을 적응시키거나, 충분한 근거가 모였는지 스스로 판단하는 자율성이 없기 때문이다.

 

결국 "RAG 쓰지 마라"는 말의 정확한 번역은 "RAG만으로 끝내지 마라, Agent에게 더 많은 자율성을 줘라"인 것이다.

[ RAG는 파인튜닝의 대안인가? ]

여기서 자주 나오는 오해 하나를 짚고 넘어가자. "RAG는 파인튜닝할 리소스가 없을 때 쓰는 차선책"이라는 인식이다.

 

반은 맞다. RAG가 주목받은 초기 맥락 중 하나는 확실히 그것이었다. 파인튜닝에 필요한 고품질 데이터, GPU 인프라, ML 엔지니어 인력을 감당하기 어려운 팀이 "inference 시점에 외부 지식을 주입하자"는 대안으로 RAG를 택한 건 사실이다.

 

하지만 이 둘은 근본적으로 해결하는 문제가 다르다.

 

파인튜닝은 모델의 행동 패턴을 바꾼다. "의료 보고서 스타일로 답변하라", "보안 로그의 위협 등급을 분류하라" 같은 것이다. 모델의 파라미터 자체에 패턴을 새기는 작업이다.

 

RAG는 모델이 접근할 수 있는 지식의 범위를 확장한다. 모델이 학습 시점에 보지 못한 최신 정보, 사내 문서, 실시간 데이터를 inference 때 가져다 쓰게 하는 것이다.

 

이 차이가 중요한 이유는, 파인튜닝을 아무리 잘 해도 해결 못 하는 문제가 있기 때문이다.

 

대표적으로 데이터의 시의성(recency) 문제다. 모델을 오늘 파인튜닝해도 내일 발표되는 새로운 CVE 취약점은 모른다. 이건 리소스 문제가 아니라 구조적 한계다. 또 하나는 traceability다. RAG는 "이 답변이 어떤 문서에 근거했는지" 추적이 되지만, 파인튜닝된 모델의 출력은 역추적이 불가능하다.

 

SOC 환경에서 예를 들면 이렇다.

파인튜닝	모델의 판단 패턴 학습	보안 로그 포맷 이해, 위협 등급 분류
RAG	최신 컨텍스트 데이터 주입	"이 IP의 최근 7일 행동", "이 시그니처 ID의 공격 매핑"
Agentic	동적 의사결정	"로그를 먼저 조회하고, 결과를 보고 추가 분석 필요 여부 판단"

이 셋은 경쟁 관계가 아니라 상호 보완적 기술이다. "파인튜닝 못 해서 RAG 쓴다"는 인식은 2022~2023년 초기 프레이밍에 가깝다.

[ RAG의 실질적 비용 구조 ]

그러면 RAG는 공짜인가? 당연히 아니다. 비용 구조를 뜯어보자.

 

임베딩 비용은 사실 미미하다. OpenAI text-embedding-3-small 기준 토큰 100만 개당 $0.02 수준이다. 문서 수천 건은 몇 센트면 된다. 다만 문서가 수십만 건 이상이면 초기 인덱싱과 재임베딩 비용이 누적된다.

 

벡터 DB 운영 비용이 실제로 제일 부담스러운 경우가 많다. Pinecone 같은 매니지드 서비스는 월 $70~수백 달러다. Chroma, Milvus, Qdrant 같은 오픈소스를 셀프호스팅하면 SaaS 비용은 없지만, 서버 인프라와 운영 인력이 든다.

 

LLM generation 비용은 RAG 특유의 비용이라기보다 LLM 사용 비용 자체다. 다만 RAG는 retrieved chunk를 프롬프트에 붙이니까 입력 토큰이 늘어난다는 점은 고려해야 한다.

임베딩을 직접 서빙하면?

"임베딩 API 비용이 부담된다"는 질문을 받을 수 있는데, 오픈소스 임베딩 모델을 로컬에서 돌리는 건 생각보다 간단하다.

 

sentence-transformers/all-MiniLM-L6-v2는 약 80MB로 가볍고, BAAI/bge-m3는 다국어 지원이 좋아서 한국어 문서에도 잘 동작한다.

 

Python에서 sentence-transformers 라이브러리를 쓰면 model.encode(texts) 한 줄이면 벡터가 나온다. CPU에서도 충분히 돌아간다.

from sentence_transformers import SentenceTransformer

model = SentenceTransformer('BAAI/bge-m3')
vectors = model.encode(["WAF 로그에서 SQL Injection 패턴 탐지", "FortiGate IPS 시그니처 분석"])

이게 전부다. Ollama에서 LLM 서빙하는 것보다 훨씬 간단한 작업이다.

진짜 비용은 돈이 아니라 엔지니어링 복잡도

임베딩 서빙 자체는 쉽지만, 잘 동작하는 RAG 시스템을 만들려면 청킹 전략 튜닝, retrieval 품질 평가 체계 구축, chunk가 실제 질문의 답을 포함하는지 검증하는 파이프라인이 필요하다. 이 부분이 삽질의 대부분을 차지한다.

 

"RAG를 쓰지 말고 Agentic하게 하라"는 주장의 실질적 맥락도 바로 이것이다. API 비용이 아니라, 청킹/retrieval 튜닝의 엔지니어링 오버헤드를 Agent의 자율적 탐색으로 대체하자는 논의인 것이다.

[ 엔지니어링 오버헤드는 사라지지 않는다. 이동할 뿐이다. ]

여기서 핵심적인 반론 하나를 짚어야 한다.

 

"Agentic RAG에서 Agent의 도구 중 하나가 벡터 검색이면, 결국 청킹 전략도 잘 짜야 하고, retrieval 품질도 평가해야 하는 거 아닌가? 엔지니어링 오버헤드가 똑같이 발생하는 거 아닌가?"

 

맞는 말이다. Agent가 아무리 똑똑해도 도구 자체가 쓰레기를 반환하면 쓰레기 기반으로 판단하게 된다. garbage in, garbage out 문제가 레이어만 바뀌었을 뿐 본질적으로 사라진 게 아니다.

 

하지만 오버헤드의 성격이 달라진다는 점이 중요하다.

 

전통적인 RAG에서는 파이프라인이 고정되어 있다. 하나의 retrieval 경로가 단순 사실 질문, 비교 질문, 요약 질문을 전부 커버해야 한다. 하나의 청킹 전략이 모든 케이스에서 잘 동작해야 하니까 튜닝 난이도가 극도로 높아진다.

 

반면 Agentic 방식에서는 Agent가 질문 유형에 따라 다른 도구를 선택한다. 벡터 검색이라는 도구의 책임 범위가 좁아지기 때문에, "모든 질문에 범용적으로"가 아니라 "이 특정 유형의 질문에 특화해서" 최적화하면 된다.

 

비유하자면, 전통 RAG는 만능 스위스 아미 나이프 하나를 완벽하게 만들어야 하는 것이고, Agentic RAG는 도구 상자를 갖고 있는 것이다. 각 도구는 자기 역할만 잘 하면 되고, 어떤 도구를 꺼내 쓸지는 Agent가 판단한다.

 

그러면 다음 질문이 자연스럽게 나온다. "Agent가 올바른 도구를 선택하는 판단력은 어떻게 보장하는가?"

 

오버헤드가 사라지는 게 아니라 재분배되는 것이다. 전통 RAG에서는 "retrieval 품질 튜닝"에 집중되고, Agentic RAG에서는 "Agent의 도구 선택 판단력 + 각 도구의 개별 품질"로 분산된다.

 

그래서 데이터의 이질성(heterogeneity)이 높을수록 Agentic 방식의 이점이 커진다.

 

WAF 로그는 ES에 구조화되어 있고, FortiGate 정책 문서는 비정형 텍스트고, 인시던트 히스토리는 또 다른 포맷이다. 이런 환경에서 전부 청킹해서 하나의 벡터 DB에 넣는 건 정보 손실이 심하다. 반면 Agentic 방식이면 로그는 ES 쿼리, 정책 문서는 벡터 검색, 인시던트 히스토리는 DB 쿼리로 각각 최적의 경로를 탈 수 있다.

 

반대로, 데이터가 전부 비정형 텍스트 문서만 있는 환경이라면 Agentic RAG를 써도 벡터 검색의 품질 문제를 똑같이 풀어야 한다. 이 경우에는 잘 튜닝된 전통 RAG가 오히려 실용적일 수 있다.

[ 결국 LLM 성능이 천장을 결정한다 ]

Agent를 직접 구현해보면 한 가지 사실을 체감하게 된다. 도구 품질도 중요하고, 워크플로우도 중요하지만, 결국 LLM의 추론 능력이 Agent 시스템의 천장을 결정한다는 것이다.

 

Agent에서 LLM이 담당하는 역할을 분해하면 이렇다.

• 사용자 의도를 파악하는 것
• 어떤 도구를 어떤 순서로 쓸지 계획하는 것
• 도구 결과를 해석해서 다음 행동을 결정하는 것
• "이제 충분한 정보를 모았다"는 종료 판단을 내리는 것

모든 단계에서 LLM의 추론 능력이 기반이 된다. 도구가 아무리 좋아도, "지금 이 상황에서 ES aggregation을 쓸지 단건 조회를 쓸지" 판단을 잘못하면 의미가 없다.

 

문제는 여기서 트레이드오프가 발생한다는 것이다. 그것도 단일 축이 아니라 최소 3축이 동시에 얽힌다.

 

모델 품질 vs 비용. Claude Opus 같은 고성능 모델은 도구 선택 정확도가 높지만 토큰당 비용이 높다. 로컬 오픈소스 모델은 추론 비용이 전기세 수준이지만 복잡한 멀티스텝 판단에서 실수가 잦다.

 

모델 품질 vs 레이턴시. 큰 모델일수록 응답이 느리다. SOC 환경에서 인시던트 대응은 속도가 중요한 상황이 많다.

 

Agent 루프 횟수 vs 총 비용. 이게 가장 미묘하다. 똑똑한 모델은 한두 번의 도구 호출로 답을 내지만, 덜 똑똑한 모델은 같은 문제를 풀려고 5~6번 루프를 돈다. 싼 모델을 썼는데 호출 횟수가 늘어서 총 비용은 비슷하거나 오히려 더 높아지는 역설이 생긴다.

[ Model Routing: 현실적인 해법 ]

이 트레이드오프에 대한 현실적 해법이 Model Routing이다. 모델 하나로 모든 작업을 처리하는 대신, 작업 난이도에 따라 다른 모델로 분기하는 것이다.

 

구현 방식은 네 단계의 스펙트럼으로 존재한다.

Level 1: 정적 라우팅 (Rule-Based)

가장 단순한 if문 기반 방식이다.

if "IP 조회" in query or "로그 검색" in query:
    model = "local-qwen-35b"  # 단순 쿼리 생성
elif "위험도 분석" in query or "공격 패턴" in query:
    model = "claude-sonnet"   # 복합 판단
else:
    model = "local-qwen-35b"  # 기본값은 저비용 모델

구현이 간단하고 예측 가능하다. 도메인의 쿼리 유형이 명확하게 분류되는 환경에서는 이것만으로도 충분하다. 단점은 경계가 애매한 쿼리에 취약하다는 것이다.

Level 2: 시맨틱 라우팅 (Classifier-Based)

쿼리를 임베딩해서 어떤 유형의 작업인지 자동으로 분류하는 방식이다.

 

Red Hat의 LLM Semantic Router가 대표적이다. BERT 모델로 요청의 의미를 파악한 다음, 수학 문제는 수학 특화 모델로, 창작 작업은 글쓰기 모델로 보낸다.

 

if문으로 잡기 어려운 애매한 쿼리를 자연어 의미 기반으로 분류한다는 게 핵심이다. 다만 벡터 DB와 임베딩 모델이라는 추가 컴포넌트가 필요하고, 참조 프롬프트 셋의 커버리지가 정확도에 직결된다.

Level 3: 학습 기반 라우팅 (Learned Routers)

라우터 자체를 학습시키는 방식이다.

 

LMSYS의 RouteLLM이 가장 잘 알려져 있다. Chatbot Arena의 선호도 데이터를 활용해서 라우터를 학습시켰고, GPT-4 대비 최대 85% 비용 절감에 GPT-4 성능의 95%를 유지하는 결과를 보여줬다.

 

원리는 이렇다. 강한 모델(GPT-4)과 약한 모델(Mixtral-8x7B) 두 개 사이에서 라우팅한다. 단순한 쿼리는 약한 모델로, 복잡한 쿼리만 강한 모델로 보내서 비용을 최소화하면서 특정 성능 목표를 달성하는 것이다.

 

OpenAI 클라이언트를 drop-in으로 교체하는 수준이라 적용도 간단하다.

Level 4: 동적 라우팅 (Universal Routing)

2025년 UniRoute 논문은 한 단계 더 나갔다.

 

고정된 모델 풀이 아니라, 이전에 본 적 없는 새로운 LLM이 테스트 시점에 추가되어도 라우팅이 가능한 방식이다.

 

각 LLM을 대표 프롬프트에 대한 예측 결과 기반의 feature vector로 표현해서, 30개 이상의 unseen 모델에 대해서도 동작한다.

 

AWS에서는 이미 프로덕션 서비스로 제공하고 있다. Amazon Bedrock의 Intelligent Prompt Routing이 그것이다.

 

Claude 3.5 Sonnet과 Haiku 사이에서 프롬프트 복잡도에 따라 자동으로 라우팅해서 최대 30% 비용 절감을 달성한다.

[ 실무 적용 로드맵 ]

이론은 여기까지다. 실무에서 이걸 어떻게 적용할 것인가.

 

지금 당장은 Level 1(정적 라우팅)으로 시작하는 게 맞다. 도메인의 쿼리 유형이 비교적 명확하게 분류되는 환경이라면, if문 몇 개로 대부분의 케이스를 커버할 수 있다. 과도하게 고도화된 라우팅 시스템을 처음부터 만들 필요가 없다.

 

여기에 하나 더 추가할 수 있는 전략은, Agent의 판단 중 패턴화 가능한 부분을 룰로 빼는 것이다. "IP 조회 요청이 들어오면 무조건 ES aggregation 도구를 먼저 쓴다" 같은 건 LLM이 매번 추론할 필요 없이 if문으로 처리할 수 있다.

 

LLM의 추론이 진짜 필요한 구간, 즉 "이 로그 패턴이 정상인지 비정상인지 맥락적으로 판단해야 하는" 부분에만 모델 파워를 집중시키는 것이다.

 

그 다음 단계로 넘어가야 하는 시점은, if문으로 분류가 안 되는 경계 케이스가 체감될 정도로 많아질 때다. 그때 RouteLLM 같은 학습 기반 라우터를 도입하거나, 쿼리 복잡도를 점수화하는 간단한 classifier를 붙이면 된다.

[ 정리 ]

"RAG 쓰지 마라"는 과장된 표현이다. 정확히는 "RAG만으로 끝내지 마라"가 맞다.

• RAG, 파인튜닝, Agentic은 경쟁 관계가 아니라 각각 다른 레이어를 담당하는 상호 보완적 기술이다.
• Agentic RAG는 retrieval을 Agent의 도구 중 하나로 편입시키는 패러다임이다.
• 엔지니어링 오버헤드는 사라지지 않는다. 이동하고 재분배될 뿐이다.
• 데이터의 이질성이 높을수록 Agentic 방식의 이점이 커진다.
• LLM 성능이 Agent 시스템의 천장을 결정하며, Model Routing으로 비용-성능 트레이드오프를 관리한다.
• 정적 라우팅에서 시작해서, 실제 문제가 보이면 그때 고도화하는 게 가장 실용적이다.

이 분야는 아직 best practice가 확립되지 않은 초기 단계다. 직접 구현하고, 부딪히고, 체감하는 과정 자체가 실력을 쌓는 가장 확실한 방법이다.