RAG는 어렵게 들리지만 출발점은 간단합니다.

AI 모델이 모든 답을 자기 기억에서 꺼내게 하지 말고, 내 문서에서 먼저 찾아본 뒤 답하게 하는 방식입니다.

예를 들어 회사 규정집, 제품 매뉴얼, 블로그 글, PDF, FAQ가 있다고 해봅니다.
모델에게 그냥 “우리 환불 정책 알려줘”라고 묻는 대신, 관련 문서를 검색해서 그 내용을 근거로 답하게 만드는 구조가 RAG입니다.

정식 이름은 Retrieval-Augmented Generation입니다.
검색으로 찾은 정보를 생성 답변에 붙인다는 뜻에 가깝습니다.

RAG가 필요한 이유

AI 모델은 모르는 것도 그럴듯하게 말할 수 있습니다.

또 모델이 학습한 시점 이후의 정보, 회사 내부 문서, 개인 프로젝트 문서는 기본적으로 알지 못합니다.

RAG는 이 문제를 줄이기 위한 구조입니다.

  • 최신 문서를 반영할 수 있습니다.
  • 내부 문서를 답변 근거로 쓸 수 있습니다.
  • 답변에 출처를 붙일 수 있습니다.
  • 모델을 다시 학습시키지 않아도 됩니다.
  • 잘못된 답변을 사람이 추적하기 쉬워집니다.

즉 RAG는 “AI가 더 똑똑해지는 기술”이라기보다, AI가 봐야 할 자료를 제때 찾아주는 구조입니다.

기본 흐름

RAG는 보통 아래 순서로 움직입니다.

  1. 문서를 모읍니다.
  2. 문서를 작은 조각으로 나눕니다.
  3. 각 조각을 검색 가능한 형태로 저장합니다.
  4. 사용자가 질문합니다.
  5. 질문과 가까운 문서 조각을 찾습니다.
  6. 찾은 조각을 모델에게 같이 보냅니다.
  7. 모델이 답변을 만들고 출처를 표시합니다.

이 중 초급자가 가장 자주 놓치는 것은 1번과 7번입니다.

문서를 잘못 넣으면 검색도 틀립니다.
출처를 표시하지 않으면 답변이 맞는지 확인하기 어렵습니다.

벡터 검색만 있으면 끝인가

아닙니다.

RAG 설명에서 벡터 검색이 자주 나오지만, 벡터 DB 하나를 붙였다고 좋은 RAG가 되는 것은 아닙니다.

Microsoft Azure AI Search 문서는 RAG에서 query understanding, multi-source access, token constraints, response time, security and governance 같은 문제가 함께 생긴다고 설명합니다.

쉽게 말하면 이런 문제입니다.

  • 사용자가 문서와 다른 표현으로 질문합니다.
  • 자료가 PDF, 웹페이지, DB, 이미지에 흩어져 있습니다.
  • 모델에 너무 많은 문서를 넣으면 비용과 속도가 나빠집니다.
  • 검색 결과가 느리면 챗봇처럼 쓰기 어렵습니다.
  • 권한 없는 문서가 답변에 섞이면 큰 사고입니다.

그래서 RAG는 검색 엔진, 문서 관리, 권한 관리, 답변 UI가 같이 맞아야 합니다.

citation이 왜 중요한가

RAG 서비스에서 citation은 장식이 아닙니다.

사용자는 결국 이렇게 물어봅니다.

  • 이 답변은 어느 문서에서 나온 건가
  • 문서 몇 페이지를 보면 되나
  • 모델이 내용을 지어낸 것은 아닌가
  • 최신 문서가 맞나
  • 내가 접근 권한이 있는 문서인가

Google Gemini API File Search 문서는 응답의 grounding_metadata로 어떤 문서 부분이 답변에 쓰였는지 citation을 확인할 수 있다고 설명합니다.

최근 File Search 업데이트에서는 PDF 같은 문서의 page-level citation도 강조됐습니다.

초급자는 RAG를 만들 때 처음부터 아래 화면을 생각해야 합니다.

답변:
이 제품은 30일 이내 환불이 가능합니다.

근거:
- refund_policy_2026.pdf, 3페이지
- customer_faq_ko.md, "환불" 섹션

이런 근거가 없으면 AI 검색은 업무 도구가 되기 어렵습니다.

메타데이터가 품질을 좌우한다

문서 조각만 저장하면 나중에 검색 범위를 줄이기 어렵습니다.

처음부터 메타데이터를 붙이는 편이 좋습니다.

  • source: 어디서 온 문서인가
  • version: 문서 버전
  • status: draft, final, archived
  • locale: ko, en, ja
  • product: 어떤 제품 문서인가
  • owner: 담당 부서
  • updatedAt: 마지막 업데이트 날짜
  • visibility: public, internal, restricted

예를 들어 “2026년 확정된 한국어 고객지원 문서에서만 찾아줘”라는 요청은 메타데이터가 있어야 안정적으로 처리됩니다.

Gemini API File Search의 custom metadata filtering도 이런 흐름과 맞닿아 있습니다.

관리형 File Search를 쓰면 좋은 경우

처음 RAG를 만드는 팀은 자체 벡터 DB부터 운영할 필요가 없을 수 있습니다.

관리형 File Search가 잘 맞는 경우는 이렇습니다.

  • 문서 규모가 아직 작거나 중간 수준입니다.
  • 빠르게 prototype을 만들어야 합니다.
  • citation이 필요합니다.
  • 문서 ingestion, chunking, embedding을 직접 관리하고 싶지 않습니다.
  • Gemini API 같은 특정 모델 생태계 안에서 시작해도 괜찮습니다.

반대로 아래 상황이면 자체 검색 인프라를 더 진지하게 봐야 합니다.

  • 권한 구조가 복잡합니다.
  • 여러 모델 제공자를 바꿔 써야 합니다.
  • 검색 품질을 세밀하게 튜닝해야 합니다.
  • 대량 문서와 비용 최적화가 중요합니다.
  • 사내망 또는 온프레미스 배포가 필요합니다.

첫 RAG 실험은 이렇게 작게 시작한다

처음에는 큰 시스템을 만들지 않는 편이 좋습니다.

추천 실험 순서는 이렇습니다.

  1. 문서 10개만 고릅니다.
  2. 문서마다 제목, 출처, 버전, 날짜를 정리합니다.
  3. 질문 20개를 미리 만듭니다.
  4. 검색 결과와 답변이 맞는지 사람이 채점합니다.
  5. citation이 원문으로 돌아갈 수 있는지 봅니다.
  6. 틀린 답변을 모아 문서와 질문을 고칩니다.
  7. 그 다음에 문서 수를 늘립니다.

RAG는 처음부터 많이 넣으면 좋아지는 구조가 아닙니다.
정답을 아는 작은 세트로 품질을 먼저 봐야 합니다.

한 줄 결론

RAG는 AI에게 내 문서를 붙이는 방법입니다.

하지만 핵심은 벡터 DB 이름이 아니라 좋은 문서, 좁힌 검색 범위, 확인 가능한 citation, 권한 관리입니다.
이 네 가지를 먼저 잡으면 관리형 File Search든 자체 검색 인프라든 선택이 훨씬 쉬워집니다.

같이 보면 좋은 글

출처