AI튜터랩의 영상 **「구글이 RAG를 끝냈다」**에서는 Gemini API의 **File Search** 기능을 이용해 기존 RAG 구축 과정의 상당 부분을 Google이 관리형 서비스로 대신해 주는 방식을 소개합니다. > 영상 제목처럼 RAG 자체가 사라진 것은 아닙니다. 정확히는 **RAG를 직접 구축해야 하는 범위를 크게 줄여 주는 Managed RAG 방식**에 가깝습니다. ## 기존 RAG는 왜 복잡했나? 일반적인 RAG를 직접 구축하려면 보통 다음 작업이 필요합니다. - 문서 업로드 - Chunking - Embedding 생성 - Vector DB 저장 - 검색 로직 - Query Embedding - Top-K Retrieval - Context 구성 - LLM Prompt 연결 - 출처 관리 즉, 단순히 AI에게 문서를 읽히는 것이 아니라 **검색 파이프라인 전체를 개발·운영해야 했습니다.** ## Gemini File Search란? Gemini API의 File Search는 이 RAG 파이프라인을 Google이 관리해 주는 도구입니다. 사용자는 파일을 File Search Store에 넣고, Gemini 요청에서 해당 Store를 검색 대상으로 지정하면 됩니다. Google 공식 문서 기준으로 File Search는 데이터를: **Import → Chunk → Index → Retrieve → Context 제공** 하는 과정을 관리합니다. 즉, 개발자가 직접 Vector DB와 검색 파이프라인을 모두 만들지 않아도 됩니다. ## 기본 동작 구조 전체 흐름은 다음과 같습니다. **문서 업로드** ↓ **자동 Chunking** ↓ **Embedding 생성** ↓ **File Search Store에 Index** ↓ **사용자 질문** ↓ **관련 문서 검색** ↓ **검색 결과를 Gemini Context로 전달** ↓ **근거 기반 답변 생성** 즉, RAG의 핵심 구조는 그대로지만 구현과 운영을 Google이 추상화합니다. ## 왜 편한가? 기존에는 개발자가: - 어떤 Vector DB를 쓸지 - Chunk 크기를 어떻게 할지 - Embedding을 어디서 만들지 - 검색 Index를 어떻게 운영할지 - Query를 어떻게 Vector로 바꿀지 를 직접 설계해야 했습니다. File Search를 사용하면 이런 작업의 상당 부분을 API 뒤로 숨길 수 있습니다. 그래서 작은 팀이나 빠른 Prototype에서는 RAG 구축 시간이 크게 줄어들 수 있습니다. ## 비용 구조는 어떻게 되나? 영상에서는 Query 비용이 무료라고 설명합니다. 현재 Google 공식 문서 기준으로 더 정확히 표현하면: - **File Search 저장 비용: 무료** - **Query-time Embedding: 무료** - **초기 Indexing Embedding: 유료** - **검색된 문서 토큰: 일반 Context Token 요금 적용** - **Gemini 모델 Input / Output Token: 일반 모델 요금 적용** 입니다. 즉, 검색 질의를 위한 Embedding 자체는 무료지만 **전체 질의가 완전히 비용 0원이라는 의미는 아닙니다.** ## 출처 기반 답변 File Search는 검색한 문서를 Context로 넣기 때문에 일반적인 LLM 단독 답변보다: - 사내 문서 - 기술 매뉴얼 - 정책 - 논문 - 사업 공고 같은 특정 자료를 기반으로 답변하게 만들 수 있습니다. 영상에서는 예비창업패키지 공고 PDF를 넣고 지원 대상을 질문하는 데모를 보여줍니다. ## ChatGPT에 PDF를 올리는 것과 무엇이 다른가? 사용 경험만 보면 비슷할 수 있습니다. 하지만 File Search는 개발자가 자신의 앱이나 서비스에서 API로 사용할 수 있다는 점이 중요합니다. 즉: **일회성 문서 Q&A → 일반 Chat UI** **반복적으로 사용하는 서비스형 문서 검색 → File Search API** 처럼 구분할 수 있습니다. ## 기존 직접 구축 RAG와 비교 ### 직접 구축 RAG - Vector DB 직접 선택 - Chunking 전략 직접 설계 - Embedding 모델 직접 선택 - 검색 알고리즘 직접 조정 - Hybrid Search 구현 가능 - Reranking 직접 적용 가능 - 권한·보안·필터링 세밀 제어 ### Gemini File Search - 빠른 구축 - 인프라 관리 부담 감소 - API 중심 - Chunking / Indexing 자동화 - Gemini와 자연스럽게 통합 - Prototype과 중소 규모 서비스에 편리 ## File Search가 모든 RAG를 대체하지는 않는다 직접 구축 RAG가 여전히 필요한 경우도 많습니다. 예를 들어: - 사내망 완전 폐쇄 환경 - 자체 Vector DB가 필요한 경우 - 세밀한 Chunking 전략 - Custom Embedding - Hybrid Search - Reranker - 문서별 복잡한 권한 제어 - GraphRAG - Multi-stage Retrieval - 여러 LLM을 함께 사용하는 구조 에서는 직접 RAG 파이프라인을 구축하는 것이 더 적합할 수 있습니다. ## 현재 공식 제한사항도 있다 Google 공식 문서 기준으로 File Search에는 몇 가지 제한이 있습니다. - 문서당 최대 100MB - 프로젝트별 Store 용량은 Tier별 제한 - 낮은 Retrieval Latency를 위해 Store당 20GB 이하 권장 - Live API에서는 File Search 미지원 - 일부 다른 Built-in Grounding Tool과 동시에 사용 불가 따라서 관리형 RAG라고 해도 서비스 요구사항을 먼저 확인해야 합니다. ## 핵심 정리 이 영상의 제목처럼 Google이 RAG를 없앤 것은 아닙니다. 더 정확한 표현은: > **Gemini File Search가 RAG의 Chunking·Embedding·Indexing·Retrieval 인프라를 관리형 API로 추상화했다.** 입니다. 그래서 RAG를 처음 만들거나 빠르게 Prototype을 만들 때는: **파일 업로드 → File Search Store → Gemini Query** 만으로 시작할 수 있습니다. 반면 복잡한 검색 품질 튜닝이나 권한·보안·Graph 구조가 필요해지면 여전히 직접 구축 RAG가 필요합니다.