많은 기업과 개발자들이 LLM(대규모 언어 모델)의 환각 현상을 해결하기 위해 RAG(검색 증강 생성)를 도입했습니다. 하지만 실제 서비스에 적용해 본 이들은 곧 예상치 못한 문제에 직면합니다. 모든 질문에 대해 무조건 외부 지식 베이스에서 데이터를 검색해 밀어 넣는 방식이, 때로는 AI의 추론 능력을 방해하거나 불필요한 노이즈를 생성해 답변의 질을 오히려 떨어뜨린다는 점입니다.

우리는 흔히 ‘더 많은 데이터가 더 좋은 답변을 만든다’고 믿지만, AI에게는 그렇지 않습니다. 질문의 성격에 따라 모델이 이미 알고 있는 지식으로 충분한 경우가 있고, 반드시 최신 외부 데이터가 필요한 경우가 있습니다. 이 구분을 AI가 스스로 내리게 하는 기술, 그것이 바로 ‘Retrieval on Demand(온디맨드 검색)’의 핵심입니다.

왜 모든 질문에 검색이 필요하지 않은가

기존의 표준 RAG 파이프라인은 [질문 → 검색 → 생성]의 선형적 구조를 가집니다. 하지만 이 구조는 효율성 측면에서 치명적인 약점을 가집니다. 예를 들어 “안녕? 오늘 기분 어때?”라는 단순한 인사말이나 “1+1은 뭐야?” 같은 상식적인 질문에도 시스템은 벡터 데이터베이스를 뒤져 관련 문서를 찾으려 노력합니다. 이는 불필요한 컴퓨팅 자원 낭비일 뿐만 아니라, 검색된 무관한 문서 조각들이 모델의 컨텍스트 윈도우를 오염시켜 엉뚱한 답변을 유도하는 원인이 됩니다.

결국 핵심은 ‘검색의 트리거’를 어디에 두느냐입니다. 모델이 자신의 내부 지식만으로 답변할 수 있는지, 아니면 외부의 구체적인 팩트나 최신 정보가 필요한지를 먼저 판단하는 ‘라우팅’ 단계가 추가되어야 합니다. 이것이 구현될 때 비로소 AI는 단순한 문서 요약기가 아니라, 상황에 맞게 도구를 사용하는 지능형 에이전트로 진화합니다.

Retrieval on Demand의 기술적 구현 메커니즘

온디맨드 검색을 구현하기 위해서는 단순한 파이프라인을 넘어 ‘판단 레이어’를 구축해야 합니다. 일반적으로 다음과 같은 세 가지 접근 방식이 사용됩니다.

• 분류기 기반 라우팅 (Classifier-based Routing): 질문이 들어오면 먼저 소형 모델(sLLM)이나 분류기가 이 질문이 ‘지식 검색이 필요한 유형’인지 ‘일반 대화 유형’인지 분류합니다. 검색이 필요하다고 판단된 경우에만 RAG 모듈을 활성화합니다.
• 자기 성찰 루프 (Self-Reflection Loop): 모델이 먼저 답변을 생성한 뒤, 스스로 “내 답변에 근거가 부족한가?” 혹은 “최신 정보가 필요한 부분인가?”를 검토합니다. 확신이 없을 때만 선택적으로 검색을 수행하는 방식입니다.
• 도구 호출 (Tool Use/Function Calling): LLM에게 ‘검색’이라는 도구를 부여하고, 모델이 추론 과정에서 스스로 search_database()와 같은 함수를 호출하도록 설계하는 방식입니다. 이는 최근 ReAct(Reasoning and Acting) 프레임워크의 핵심이기도 합니다.

온디맨드 방식의 명확한 득과 실

모든 기술적 선택에는 트레이드오프가 존재합니다. 온디맨드 검색 역시 무조건적인 정답은 아닙니다. 아래 표를 통해 기존 RAG와 온디맨드 RAG의 차이를 살펴보겠습니다.

실무 적용 사례: 지식 관리 시스템의 진화

실제로 대규모 기업용 위키(Wiki) 시스템에 이를 적용한 사례를 들어보겠습니다. 기존 시스템은 사용자가 “휴가 규정 알려줘”라고 하면 모든 휴가 관련 문서를 긁어와서 요약했습니다. 하지만 “내일 날씨 어때?”라고 물어도 휴가 규정 문서 중에서 ‘날씨’라는 단어가 포함된 엉뚱한 문장을 찾아내어 답변하는 오류가 잦았습니다.

여기에 온디맨드 로직을 도입하여, 질문의 의도를 먼저 분석하게 했습니다. ‘규정’, ‘절차’, ‘가이드라인’과 같은 키워드나 의도가 감지될 때만 내부 DB를 검색하게 하고, 일반적인 질문은 LLM의 기본 지식으로 처리하거나 외부 API(날씨 API 등)로 연결했습니다. 결과적으로 사용자 만족도는 상승했고, 벡터 DB의 부하량은 약 40% 감소하는 성과를 거두었습니다.

지금 당장 실행할 수 있는 액션 아이템

단순히 최신 논문을 읽는 것보다 중요한 것은 현재 운영 중인 AI 서비스에 작은 실험을 시작하는 것입니다. 실무자라면 다음 단계를 따라 적용해 보시기 바랍니다.

• 로그 분석: 최근 일주일간의 사용자 질문 로그를 분석하여, 실제로 검색 결과가 답변에 기여하지 않았던 ‘불필요한 검색’의 비율이 얼마나 되는지 파악하십시오.
• 가드레일 프롬프트 설정: 메인 모델 앞에 아주 가벼운 프롬프트를 배치하여 “다음 질문이 외부 지식이 필요한 질문이면 ‘SEARCH’, 아니면 ‘DIRECT’라고 답하라”는 분류 단계를 추가해 보십시오.
• 임계값(Threshold) 최적화: 벡터 검색의 유사도 점수(Similarity Score)가 일정 수준 이하일 경우, 검색 결과를 과감히 버리고 모델의 자체 지식으로 답변하게 하는 필터링 로직을 구현하십시오.

결론: 지능형 검색으로 가는 길

AI의 발전 방향은 단순히 모델의 크기를 키우는 것이 아니라, 주어진 자원을 얼마나 효율적으로 사용하는가에 있습니다. Retrieval on Demand는 AI가 ‘무엇을 아는지’와 ‘무엇을 찾아야 하는지’를 구분하게 만드는 고도의 전략입니다.

데이터를 많이 넣는 것에 집착하는 단계는 지났습니다. 이제는 어떤 순간에, 어떤 데이터를, 얼마나 정밀하게 가져올 것인가를 고민해야 합니다. 온디맨드 전략을 통해 비용은 줄이고, 답변의 순도는 높이는 최적화된 AI 아키텍처를 구축하시기 바랍니다.