- 모든 질문에 RAG를 적용하면 embedding, 검색, context 구성 비용이 매번 발생한다.
- 문서 근거 질문은 RAG 경로, 요약/재작성 요청은 LLM 단독 경로가 적합하다.
- 완벽한 intent 분류보다 불필요한 RAG 호출을 줄이는 것이 먼저다.
RAG, 즉 Retrieval-Augmented Generation는 기업용 AI Agent의 기본 구조처럼 이야기된다. 하지만 실제 운영 환경에서 가장 먼저 부딪히는 문제 중 하나는 이것이다.
“왜 이렇게 느리고, 왜 이렇게 비용이 많이 들지?”
이 문제의 원인은 종종 RAG 그 자체가 아니라, RAG를 쓰는 방식에 있다.
RAG는 강력하지만, 비싸고 느리다
RAG는 다음 과정을 포함한다.
- embedding 생성
- vector DB 검색
- 검색 결과를 context로 구성
- LLM 호출
즉, 모든 질문에 RAG를 적용한다는 것은 모든 질문에 가장 무거운 경로를 태운다는 의미다. 이 구조는 데모 단계에서는 괜찮지만, 운영 단계에서는 곧 한계를 드러낸다.
질문은 모두 같지 않다
실제 사용자 질문을 살펴보면 크게 두 가지로 나뉜다.
문서 근거가 반드시 필요한 질문
- “사내 규정 기준 알려줘”
- “이전 프로젝트 문서 내용 설명해줘”
이런 질문은 RAG가 필요한 질문이다.
이미 정보가 주어진 질문
- “이 문단 요약해줘”
- “보고서 형식으로 다시 써줘”
이런 질문은 굳이 문서를 검색할 필요가 없는 질문이다.
그럼에도 모든 질문을 RAG로 처리하면 불필요한 검색이 발생하고, 응답은 느려지고, 비용은 계속 쌓인다.
그래서 필요한 것이 경로 분리다
운영 환경에서는 보통 사용자 질문을 먼저 분류한 뒤, 문서 근거가 필요하면 RAG 경로로 보내고 생성이나 요약 중심 요청이면 LLM 단독 경로로 보낸다.
이 단순한 분기만으로도 latency, 비용, 시스템 부하가 눈에 띄게 개선된다.
질문 분류는 어떻게 구현할까
처음부터 복잡할 필요는 없다.
- 1단계: 키워드 기반 rule
- 2단계: LLM 기반 intent 분류
- 필요 시: 간단한 classifier 모델
중요한 건 완벽한 분류가 아니라 불필요한 RAG를 최대한 줄이는 것이다.
정리하며
RAG는 기업용 AI Agent의 핵심 구성 요소지만, 모든 질문에 적용해야 하는 만능 해법은 아니다.
운영 환경에서 중요한 것은 정확도만이 아니라 속도와 비용까지 포함한 전체 균형이다. 질문 유형에 따른 경로 분리는 그 균형을 맞추기 위한 가장 현실적인 첫 단계다.