Google이 2026년 5월 5일 Gemini API의 File Search 업데이트를 발표했습니다.

핵심은 세 가지입니다.

  1. 텍스트뿐 아니라 이미지까지 함께 검색하는 multimodal File Search
  2. 파일에 붙인 custom metadata 기준 필터링
  3. PDF 같은 문서에서 답변 근거를 페이지 번호까지 보여주는 citation

한 줄로 줄이면, RAG가 단순 문서 검색에서 이미지와 문서 근거를 같이 다루는 관리형 검색 도구 쪽으로 이동하고 있습니다.

바로 보기

File Search가 원래 하던 일

RAG는 보통 모델에게 외부 자료를 붙여 답변하게 만드는 방식입니다.

예전에는 직접 해야 할 일이 많았습니다.

  • 파일을 나눈다
  • 임베딩을 만든다
  • 벡터 데이터베이스에 넣는다
  • 검색 결과를 다시 프롬프트에 넣는다
  • 답변이 어느 문서에서 나왔는지 추적한다

Gemini API File Search는 이 흐름을 Google 쪽 관리형 기능으로 줄여주는 도구입니다.
파일을 File Search store에 넣고, generateContent에서 File Search를 tool로 붙이면 모델이 관련 문맥을 찾아 답변에 활용합니다.

이번 업데이트는 이 관리형 RAG의 범위를 넓힌 것입니다.

1. 이미지까지 검색한다

가장 큰 변화는 multimodal File Search입니다.

Google 문서 기준으로 멀티모달 검색을 쓰려면 File Search store를 만들 때 기본 텍스트 임베딩이 아니라 models/gemini-embedding-2를 지정해야 합니다. 이 설정을 쓰면 텍스트와 이미지가 함께 검색 대상이 됩니다.

이 변화는 생각보다 큽니다.

문서 RAG에서는 “계약서 몇 페이지에 어떤 문장이 있나”가 중요했습니다.
멀티모달 RAG에서는 이런 질문이 가능해집니다.

  • 이 제품 사진과 비슷한 카탈로그 이미지를 찾아줘
  • 이 화면 캡처와 관련된 매뉴얼 문서를 찾아줘
  • 아키텍처 다이어그램과 설명 문서를 같이 찾아줘
  • 연구 PDF 안의 그래프와 본문 설명을 같이 확인해줘

Google 문서 기준 이미지 파일 요구사항은 아직 좁습니다.
현재 문서에 나온 범위는 PNG, JPEG, 최대 4K x 4K 해상도입니다.

즉 “모든 미디어를 다 넣으면 된다”가 아니라, 우선 이미지와 텍스트가 같이 필요한 서비스에 맞는 업데이트로 보는 편이 정확합니다.

2. 메타데이터로 검색 범위를 줄인다

두 번째 변화는 custom metadata입니다.

파일에 이런 식의 정보를 붙일 수 있습니다.

  • department: Legal
  • status: Final
  • year: 2026
  • source: internal-wiki
  • product: mobile-app

그리고 검색할 때 이 메타데이터로 범위를 좁힐 수 있습니다.

이건 정확도보다 운영성에 더 중요합니다.

RAG 품질이 나빠지는 흔한 이유는 “모델이 검색을 못해서”만이 아닙니다.
검색 대상이 너무 넓어서 엉뚱한 문서까지 같이 들어오는 경우가 많습니다.

예를 들어 회사 내부 지식 검색을 만든다고 하면, 전체 문서에서 바로 찾는 것보다 아래처럼 범위를 줄이는 쪽이 더 안정적입니다.

  • 공개 가능한 문서만
  • 최신 승인본만
  • 특정 제품군만
  • 한국어 고객지원 문서만
  • 특정 연도 이후 자료만

메타데이터 필터는 이런 노이즈를 줄이는 장치입니다.

3. 페이지 단위 출처가 중요해진다

세 번째 변화는 page-level citation입니다.

Google 문서 기준으로 File Search를 사용할 때 모델 응답에는 grounding_metadata가 포함될 수 있고, PDF처럼 페이지가 있는 문서에서는 retrieved_context.page_number로 페이지 번호를 확인할 수 있습니다.

이건 단순한 장식이 아닙니다.

RAG 서비스에서 사용자는 결국 이런 질문을 합니다.

  • 이 답변이 어느 문서에서 나온 건가
  • 문서의 몇 페이지를 보면 되나
  • 모델이 내용을 지어낸 것은 아닌가
  • 답변 근거를 사람이 직접 검토할 수 있나

페이지 번호 citation은 이 검증 흐름을 제품 안에 넣기 쉽게 만듭니다.

특히 다음 분야에서는 citation이 없으면 서비스 신뢰도가 낮아집니다.

  • 계약서 요약
  • 기술 매뉴얼 검색
  • 정책 문서 질의응답
  • 연구 논문 검색
  • 고객지원 지식베이스
  • 규정 준수 문서 확인

AI 답변이 좋아지는 것과 별개로, 사용자가 바로 원문으로 돌아갈 수 있어야 실무 도구가 됩니다.

어디에 잘 맞나

이번 업데이트는 “챗봇 만들기”보다 “근거가 필요한 검색형 AI 기능”에 더 잘 맞습니다.

예를 들어 이런 서비스에 어울립니다.

1. 제품 카탈로그 검색

상품명이나 태그가 부실해도 이미지와 설명을 같이 찾을 수 있습니다.
쇼핑몰, 부품 카탈로그, 인테리어 샘플, 디자인 레퍼런스 검색에 잘 맞습니다.

2. 사내 문서 검색

부서, 승인 상태, 문서 버전 같은 메타데이터를 붙이면 검색 범위를 안정적으로 제한할 수 있습니다.
여기서는 메타데이터 설계가 모델 선택만큼 중요합니다.

3. 연구 자료와 기술 문서 검색

PDF 안의 본문, 표, 그림을 함께 다루고 페이지 번호로 근거를 돌려줄 수 있습니다.
”그림 3의 실험 결과가 무슨 뜻인가” 같은 질문을 다룰 때 유용합니다.

4. 코드베이스와 설계 문서 검색

아키텍처 다이어그램, ERD, 시퀀스 다이어그램, README를 함께 검색하면 에이전트가 더 좋은 문맥을 얻을 수 있습니다.
다만 소스코드 전체 분석은 별도 코드 인덱싱 도구와 역할을 나눠야 합니다.

그래도 직접 설계해야 하는 것

관리형 File Search가 생겨도 모든 RAG 설계가 사라지는 것은 아닙니다.

여전히 직접 정해야 할 것이 있습니다.

  • 어떤 문서를 넣을지
  • 문서 버전을 어떻게 관리할지
  • 어떤 메타데이터를 붙일지
  • 오래된 파일을 언제 삭제할지
  • 검색 결과를 사용자에게 어떻게 보여줄지
  • 민감한 문서를 어떤 계정과 권한으로 제한할지

Google 문서 기준으로 File Search store에 들어간 임베딩은 직접 삭제하거나 모델이 deprecated 되기 전까지 유지됩니다. 반면 업로드된 raw File 객체는 48시간 뒤 삭제될 수 있다고 설명됩니다.

이 차이를 이해해야 합니다.
”원본 파일은 사라졌으니 검색 데이터도 사라졌겠지”라고 생각하면 안 됩니다.

작은 개발자가 볼 포인트

작은 팀이나 개인 개발자에게는 세 가지가 중요합니다.

첫째, 처음부터 자체 벡터 DB를 운영하지 않아도 실험할 수 있습니다.
RAG가 필요한지 검증하는 단계에서는 관리형 도구가 빠릅니다.

둘째, citation을 제품 요구사항으로 넣어야 합니다.
AI 검색은 “답변이 그럴듯하다”보다 “근거를 확인할 수 있다”가 더 중요해지고 있습니다.

셋째, 메타데이터 설계를 대충 하면 나중에 다시 넣어야 합니다.
문서를 넣을 때부터 source, version, status, locale, product, owner 같은 필드를 생각해두는 편이 좋습니다.

한 줄 결론

Gemini API File Search 업데이트는 RAG를 더 쉽게 만드는 소식이지만, 핵심은 단순 편의성이 아닙니다.

이미지, 문서, 메타데이터, 페이지 단위 근거를 한 흐름으로 묶으면서 검증 가능한 AI 검색의 기본 요구사항이 올라가고 있습니다.

같이 보면 좋은 글

출처