Google이 2026년 5월 5일 Gemini API File Search is now multimodal: build efficient, verifiable RAG를 공개했다. Gemini API의 File Search 도구가 이제 텍스트뿐 아니라 이미지까지 함께 처리하고, metadata filtering과 page-level citation을 지원한다는 내용이다.

이번 업데이트는 RAG를 단순한 문서 검색 보조 기능으로 보면 놓치기 쉽다. 핵심은 실제 업무 데이터가 텍스트만으로 이루어져 있지 않다는 점이다. PDF 안의 도표, 제품 이미지, 디자인 자료, 연구 이미지, 스캔 문서까지 검색 대상이 되기 시작하면 RAG의 역할도 달라진다.

한눈에 보기

  • 발표 내용: Gemini API File Search에 멀티모달 검색, custom metadata filtering, page-level citations가 추가됐다.
  • 핵심 변화: 텍스트 문서 중심 RAG에서 이미지와 문서가 섞인 데이터베이스를 다루는 방향으로 확장됐다.
  • 개발자 관전 포인트: 검색 정확도만큼 metadata 설계와 출처 검증 UX가 중요해진다.
  • 한 줄 결론: RAG는 이제 "찾아주는 기능"보다 "검증 가능한 근거 검색 시스템"에 가까워지고 있다.

Gemini API File Search 대표 이미지

무엇이 바뀌었나

Google이 공개한 업데이트는 세 가지다.

  • multimodal support
  • custom metadata
  • page-level citations

첫 번째는 File Search가 이미지와 텍스트를 함께 처리한다는 점이다. Google은 이 기능이 Gemini Embedding 2 모델을 기반으로 native image data를 이해한다고 설명했다. 기존처럼 파일명, 태그, OCR 텍스트에만 기대는 검색보다 한 단계 넓은 접근이다.

두 번째는 custom metadata filtering이다. 예를 들어 파일이나 문서에 department: Legal, status: Final 같은 key-value label을 붙이고, query time에 검색 범위를 좁힐 수 있다.

세 번째는 page-level citations다. File Search가 indexed information마다 page number를 붙여 모델 응답이 원본 문서의 어느 페이지에서 왔는지 확인할 수 있게 한다.

멀티모달 RAG가 중요한 이유

많은 RAG 시스템은 여전히 텍스트 문서 중심으로 설계된다. FAQ, 정책 문서, 기술 문서, 회의록처럼 텍스트로 잘 정리된 데이터에는 이 방식이 꽤 잘 맞는다.

하지만 실제 업무 데이터는 그렇게 깔끔하지 않다.

  • PDF 안에 표와 그림이 섞여 있다.
  • 제품 자료는 이미지와 설명문이 같이 있다.
  • 디자인팀은 시각 자료 자체를 검색해야 한다.
  • 연구팀은 microscopy image, plot, chart, report를 함께 본다.
  • 개발팀은 architecture diagram, ERD, sequence diagram을 코드 맥락과 같이 찾아야 한다.

Google이 이번 글에서 강조한 것도 이 지점이다. File Search가 이미지와 텍스트를 함께 처리하면 사용자는 "파일 이름이 뭐였지"가 아니라 "이런 분위기의 이미지", "이런 구조를 가진 다이어그램", "이 문서의 특정 페이지에 있던 근거"처럼 자연어 기준으로 검색할 수 있다.

Gemini File Search 멀티모달 RAG 구조

metadata filtering은 운영 품질 문제다

RAG에서 자주 생기는 문제는 검색이 아예 안 되는 것이 아니라 관련 없는 문서가 너무 많이 섞이는 것이다. 모델이 좋은 답을 만들려면 retrieval 단계에서 불필요한 noise를 줄여야 한다.

custom metadata filtering은 이 문제를 줄이는 기본 장치다. 같은 질문이라도 법무팀 최종 문서만 봐야 하는 경우가 있고, 초안과 archived 문서는 제외해야 하는 경우가 있다. 제품별, 부서별, 상태별, 권한별로 검색 범위를 나누지 않으면 모델은 그럴듯하지만 잘못된 문서를 근거로 답할 수 있다.

그래서 이 기능은 편의 기능이라기보다 production RAG에 필요한 운영 기능에 가깝다. 실제 성능은 metadata schema를 얼마나 잘 설계하느냐에 따라 달라진다.

page-level citations는 신뢰의 문제다

RAG를 업무에 붙이면 사용자는 거의 항상 같은 질문을 한다.

"그 답의 근거가 어디야?"

파일명만 보여주는 것으로는 부족하다. 긴 PDF, 계약서, 기술 명세서, 연구 보고서에서는 정확히 어느 페이지, 어떤 문맥에서 나온 정보인지 확인할 수 있어야 한다.

Google은 File Search가 indexed information마다 page number를 capture하고, 모델 응답을 원본 source와 연결한다고 설명했다. 이건 법무, 의료, 연구, 금융, 기술 지원처럼 근거 확인이 중요한 분야에서 특히 중요하다.

page-level citations가 있으면 사용자 경험도 달라진다. 답변을 믿으라고 강요하는 대신, 사용자가 바로 원본 위치로 이동해 확인할 수 있다. RAG 시스템이 "잘 말하는 챗봇"에서 "검증 가능한 업무 검색 도구"로 넘어가려면 이런 장치가 필요하다.

Gemini File Search 업데이트 요약 카드

개발자에게 주는 신호

이번 업데이트는 Gemini API의 File Search가 더 많은 인프라 부담을 흡수하려는 방향으로 보인다. 파일 업로드, indexing, retrieval, citation을 직접 쌓지 않고 API 기능으로 처리할 수 있다면 작은 팀도 더 빨리 RAG 제품을 만들 수 있다.

다만 그만큼 설계 책임이 사라지는 것은 아니다.

  • 어떤 파일 형식을 지원하는지 확인해야 한다.
  • 이미지와 텍스트가 섞인 데이터에서 retrieval quality를 직접 검증해야 한다.
  • metadata schema를 업무 권한과 문서 상태에 맞게 설계해야 한다.
  • citation을 사용자에게 어떻게 보여줄지 UI를 정해야 한다.
  • latency, quota, 비용을 실제 사용량 기준으로 측정해야 한다.

즉 "RAG가 쉬워졌다"보다 "RAG에서 직접 구현해야 했던 일부 기반 기능이 API 쪽으로 이동했다"에 가깝다.

주의할 점

Google 공식 글은 기능 방향을 잘 설명하지만, 모든 세부 운영 조건을 한 번에 공개한 문서는 아니다. 실제 적용 전에는 Gemini API 문서에서 지원 파일 형식, 파일 크기 제한, 가격, quota, region, metadata query 제약을 확인해야 한다.

또 멀티모달 검색이 가능하다고 해서 모든 이미지 데이터에서 항상 원하는 수준의 검색 품질이 나온다고 가정하면 안 된다. 업무 데이터는 도메인별로 모양이 다르다. 제품 이미지, 기술 다이어그램, 연구 이미지, 스캔 문서는 각각 평가 기준이 다르다.

마지막으로 page-level citations도 만능은 아니다. citation이 있다고 해서 답이 자동으로 맞아지는 것은 아니다. 모델이 인용한 페이지가 질문에 실제로 적절한지, 사용자가 확인할 수 있는 UX가 있는지까지 같이 봐야 한다.

결론

Gemini API File Search의 이번 업데이트는 RAG가 실무형으로 가는 방향을 잘 보여준다. 텍스트만 넣고 답을 받는 단계에서 벗어나, 이미지와 문서가 섞인 데이터베이스를 검색하고, metadata로 범위를 좁히고, page-level citation으로 근거를 확인하는 쪽으로 이동하고 있다.

앞으로 RAG 제품의 품질은 모델 성능만으로 갈리지 않는다. 어떤 데이터를 어떻게 구조화하고, 검색 범위를 어떻게 통제하며, 사용자가 근거를 얼마나 쉽게 검증할 수 있는지가 더 중요해진다. 이번 Gemini File Search 업데이트는 그 흐름을 보여주는 실용적인 신호다.

출처