RAG는 지식베이스보다 똑똑할 수 없다
RAG는 모델이 모르는 문서를 찾아 답변에 참고하게 만드는 강력한 구조입니다. 하지만 검색이 성공했다고 해서 답변이 항상 맞는 것은 아닙니다. 검색된 문서가 오래되었거나, 서로 충돌하거나, 검증되지 않았거나, 필요한 맥락을 빠뜨리고 있다면 모델은 그 잘못된 근거를 바탕으로 그럴듯한 답을 만들 수 있습니다.
그래서 RAG의 품질은 임베딩 모델이나 벡터 DB만으로 결정되지 않습니다. 더 앞단의 문제가 중요합니다. 어떤 문서를 넣을 것인가, 누가 검증했는가, 최신 문서인가, 폐기된 정책은 제거되었는가, 같은 용어를 부서마다 다르게 쓰고 있지는 않은가를 관리해야 합니다. 한 분석에서는 검증되지 않은 데이터가 들어간 RAG가 잘못된 답을 크게 늘릴 수 있으며, 소유자·버전·인증 상태 같은 데이터 거버넌스가 검색 품질에도 영향을 준다고 설명합니다1.
좋은 RAG를 만들려면 지식베이스를 큐레이션해야 합니다. 중복 문서를 줄이고, 낡은 문서를 폐기하고, 공식 문서와 참고 문서를 구분하고, 문서마다 책임자와 수정일을 남겨야 합니다. RAG는 쓰레기 데이터를 정답으로 바꿔 주는 기술이 아닙니다.
AI 생성 이미지
운영에서 더 중요한 것: 최신성, 권한, 보안
RAG는 민감한 데이터를 모델에 직접 학습시키지 않고, 보안 환경 안의 문서나 데이터베이스를 검색해 답변하게 만들 수 있습니다. 이 점은 내부 문서 기반 AI를 만들 때 큰 장점입니다. Oracle도 RAG를 최신 내부 지식과 보안이 중요한 경우에 적합한 방식으로 설명합니다2.
하지만 안전은 자동으로 생기지 않습니다. 검색 단계에서 사용자가 볼 수 없는 문서를 먼저 제외해야 합니다. 프롬프트에 넣기 전에 개인정보, 고객 정보, 계약 정보 같은 민감한 내용을 필터링해야 합니다. 로그에도 질문과 검색 결과가 남기 때문에 운영 로그의 보관 범위와 접근 권한도 정해야 합니다.
특히 삭제된 문서와 수정된 문서가 인덱스에 남아 있으면 위험합니다. 원문에서는 사라진 정책이 벡터 DB에 남아 답변에 쓰일 수 있습니다. 문서 생성, 수정, 삭제가 검색 인덱스에 반영되는 동기화 절차는 선택이 아니라 운영 조건입니다.
Fine-tuning이 더 나은 경우
문서 기반 Q&A라면 보통 RAG부터 시작하는 것이 좋습니다. 내부 문서를 근거로 답하고, 출처를 보여주고, 문서가 바뀌면 빠르게 반영할 수 있기 때문입니다. AWS도 사용자 정의 문서를 참조하는 질의응답에는 RAG 접근을 우선 고려하라고 설명합니다3.
반면 Fine-tuning은 다른 문제에 적합합니다. 모델이 특정 말투를 안정적으로 유지해야 할 때, 회사의 응답 형식을 따라야 할 때, 규제 산업의 표현을 일관되게 써야 할 때, 반복적인 요약이나 분류 방식을 익혀야 할 때 효과적입니다. 즉 RAG가 "무엇을 참고할 것인가"의 문제라면, Fine-tuning은 "어떻게 말하고 행동할 것인가"에 가깝습니다.
둘 중 하나만 선택할 필요는 없습니다. 실무에서는 Fine-tuning으로 응답 스타일과 업무 절차를 맞추고, RAG로 최신 문서와 출처를 연결하는 조합이 자연스럽습니다.
검색만으로 끝나지 않는 일은 Tool Calling으로
사용자가 "지난달 매출을 계산해 줘", "고객의 최근 주문 상태를 확인해 줘", "회의 일정을 잡아 줘", "환불 요청 메일을 보내 줘"라고 말하면 문서 검색만으로는 부족합니다. 이때 필요한 것이 Tool Calling입니다.
Tool Calling에서 LLM은 도구의 이름, 설명, 입력 형식을 보고 어떤 함수를 호출할지 고릅니다. 예를 들어 get_order_status(order_id) 같은 도구가 있다면, 질문에서 주문 번호를 뽑아 구조화된 인자로 넘깁니다. 실제 실행은 애플리케이션 서버, Lambda, API, 데이터베이스 쿼리 같은 외부 시스템이 맡습니다. AWS는 이런 패턴을 언어 모델이 답변만 하는 것이 아니라 계산, DB 조회, API 호출 같은 행동을 수행하게 하는 구조로 설명합니다4.
RAG와 Tool Calling은 잘 어울립니다. RAG가 정책과 설명서를 찾고, Tool Calling이 실제 상태 조회와 실행을 맡는 식입니다.
Agentic RAG의 가능성과 비용
전통적인 RAG는 보통 "질문 → 검색 → 답변" 흐름입니다. Agentic RAG는 여기에 에이전트를 넣어 더 유연하게 만듭니다. 에이전트는 질문을 나누고, 어느 지식원을 검색할지 고르고, 필요한 도구를 호출하고, 중간 결과를 보고 다시 검색할 수 있습니다. IBM은 Agentic RAG를 여러 데이터 소스와 도구를 선택하며 복잡한 워크플로를 처리하는 방식으로 설명합니다5.
예를 들어 "이번 분기 고객 불만의 주요 원인과 개선안을 보고서로 정리해 줘"라는 요청은 단순 검색 하나로 끝나지 않습니다. 고객센터 로그를 검색하고, 제품 릴리스 노트를 확인하고, 통계를 계산하고, 관련 정책을 찾아야 합니다. Agentic RAG는 이런 다단계 작업에 유용합니다.
하지만 대가가 있습니다. 단계가 많아질수록 비용과 지연시간이 늘어납니다. 어떤 도구를 선택했는지, 왜 그 문서를 근거로 삼았는지 평가하기도 어려워집니다. 에이전트가 잘못된 판단을 반복하면 오류가 커질 수 있습니다. 따라서 처음부터 복잡한 에이전트를 만들기보다, 기본 RAG를 안정화한 뒤 필요한 지점에만 도구와 에이전트 흐름을 붙이는 편이 안전합니다.
RAG는 만능 답안이 아닙니다. 문서가 답을 담고 있고, 그 문서가 신뢰할 수 있으며, 사용자가 접근할 권한이 있고, 검색 결과를 근거로 답하면 충분한 문제에 가장 잘 맞습니다. 그 밖의 문제에는 Fine-tuning, Tool Calling, Agentic RAG를 함께 설계해야 합니다.
참고
1LLM Knowledge Base Data Quality: Governed Data Is the RAG Problem
2RAG vs. Fine-Tuning: How to Choose
3Comparing Retrieval Augmented Generation and fine-tuning
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.