들어가며
작년 생성형 AI 분야에서 가장 주목받은 기술은 단연 RAG(Retrieval-Augmented Generation)입니다.
RAG는 모델이 이미 학습한 지식만으로 텍스트를 생성하는 대신, 외부 문서를 실시간으로 검색하고 참고해 더 정확하고 신뢰할 수 있는 답변을 만들어내는 기술입니다.
하지만 RAG 시스템을 직접 구축하다 보면 이게 생각보다 꽤 번거롭다는 걸 깨닫게 됩니다.
문서를 적절히 쪼개야 하고(chunking), 임베딩 모델을 써서 벡터로 변환해야 하며, 그걸 저장하고 검색할 Vector DB까지 세팅해야 합니다. 이 모든 과정을 연결하는 로직까지 직접 짜야 하니 꽤 손이 많이 가게됩니다.
그러나 최근, 구글이 이 복잡한 과정을 단 한 번에 해결할 수 있는 도구를 Gemini API 내에 공개했습니다.
바로 완전 관리형 RAG 시스템인 ‘File Search Tool’입니다.
File Search tool?
기존에는 RAG 시스템을 만들려면
문서를 나누고 → 임베딩 생성하고 → 인덱싱하고 → 검색 로직을 짜서 → 모델 프롬프트에 주입하는 과정을 모두 직접 처리해야 했습니다.
하지만 File Search tool은 이 모든 단계를 알아서 처리합니다.
파일을 업로드하기만 하면 자동으로 청킹되고, Gemini Embedding 모델로 임베딩이 생성되며, 전용 검색 스토어에 인덱싱까지 완료됩니다.
이후 사용자가 질문을 하면 시맨틱 서치로 관련 문서를 찾아 Gemini 모델의 프롬프트에 자동으로 추가해줍니다
이 과정을 코드로 살펴보면 다음과 같습니다.
# 검색 스토어 생성
store = client.file_search_stores.create(
config={'display_name': 'my_first_search_store'}
)
# 파일 업로드 (자동으로 청킹, 임베딩, 인덱싱)
operation = client.file_search_stores.upload_to_file_search_store(
file='/path/to/document.pdf',
file_search_store_name=store.name
)질문에 답변받는 과정도 거의 한 줄로 가능합니다.
기존 generateContentAPI에 File Search 도구만 추가하면 끝입니다.
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="google file search에 대해 알려주세요.",
config={
'tools': [{
'file_search': {
'file_search_store_names': [store.name]
}
}]
}
)
print(response.text)Google File Search는 Google Gemini API에 통합된 완전 관리형 검색 증강 생성(RAG) 시스템으로, 사용자가 복잡한 엔지니어링 과정 없이 자체 데이터를 활용하여 AI 애플리케이션을 구축할 수 있도록 돕습니다. 이는 RAG 시스템 구축의 진입 장벽을 크게 낮춰, 벡터 데이터베이스나 인프라 운영에 대한 전문 지식 없이도 개인화된 AI 경험을 만들 수 있게 합니다.
**주요 특징 및 자동화:**
* **RAG 파이프라인 자동화**: 기존 RAG 시스템은 문서 청킹, 임베딩 생성, 데이터베이스 구축, 검색 로직 최적화 등 여러 복잡한 단계를 거쳐야 했습니다. File Search는 이 모든 과정을 자동화하여, 파일을 업로드하면 자동으로 문서를 적절한 크기로 나누고(청킹), Google의 최신 Gemini Embedding 모델로 임베딩을 생성하며, 전용 저장소에 인덱싱합니다.
* **의미 기반 벡터 검색**: 사용자 질문이 들어오면 의미 기반 벡터 검색을 통해 관련 문서를 찾아 Gemini 모델의 프롬프트에 자동으로 주입하여 답변을 생성합니다. 이는 사용자가 정확한 단어를 입력하지 않아도 관련 정보를 찾아서 응답을 생성할 수 있게 합니다.
* **자동 인용**: AI 모델의 답변에는 어떤 문서의 어느 부분을 참조했는지 자동으로 표시되어, 답변의 근거를 쉽게 확인하고 검증할 수 있습니다.
**개발자 경험을 위한 기능:**
* **청킹 전략 커스터마이징**: 기본 설정 외에 필요에 따라 청크 크기나 겹치는 토큰 수를 직접 조정하여 검색 정밀도를 높일 수 있습니다.
* **메타데이터 필터링**: 파일 업로드 시 커스텀 메타데이터를 추가하면, 검색 시 특정 태그가 있는 문서만 대상으로 지정할 수 있습니다.
* **Google AI Studio 데모**: 유료 API 키만 있으면 Google AI Studio에서 File Search를 테스트해보고, 데모 앱을 리믹스하여 자신만의 버전을 만들 수도 있습니다.
...
이렇게 하면 Gemini가 자동으로 스토어를 검색해 관련 문서를 찾아 답변을 생성합니다.
별도의 검색 로직이나 데이터베이스 세팅 없이, 진짜 “업로드하고 바로 질문”할 수 있는 RAG 환경이 완성되는 셈입니다.
File Search의 얼리 액세스 프로그램에 참여 중인 개발자들은 이 기능을 활용해 고객 지원용 챗봇, 사내 지식 관리 서비스, 콘텐츠 큐레이션 플랫폼 등 폭넓은 서비스를 구현하고 있습니다.
대표적인 사례로, Phaser Studio가 개발한 AI 게임 생성 플랫폼 Beam이 있는데, Beam은 File Search를 워크플로우에 통합해 매일 수천 건의 검색을 실행하며, 수천 개의 템플릿 데이터와 코드 라이브러리를 대상으로 실시간 결과를 결합합니다.
이 과정은 평균 2초 이내에 완료되며, 이전에 수시간 걸리던 작업을 완전히 file search로 대체했다고 합니다.
File Search가 제공하는 주요 기능
File Search는 단순히 자동 청킹과 검색만 해주는 도구가 아닙니다.
조금 더 세밀한 제어와 관리가 필요한 상황에서도 충분히 대응할 수 있도록 여러 기능을 제공한다.
대표적으로 커스텀 청크 구성, 메타데이터 기반 필터링, 인용 표시, 스토어 관리 API가 있습니다.
🔹 커스텀 청크 구성
파일을 업로드하면 File Search가 자동으로 문서를 적절한 크기로 나누고, 임베딩을 생성해 인덱싱까지 처리합니다.
하지만 프로젝트에 따라 “chunk size”나 “olverlap size”를 직접 조정해야 할 때가 있습니다. 이럴 땐 chunking_config 설정을 사용해 chuking 전략을 세밀하게 제어할 수 있습니다.
# 사용자 지정 청킹 설정으로 파일 업로드
operation = client.file_search_stores.upload_to_file_search_store(
file_search_store_name=file_search_store.name,
file_name=sample_file.name,
config={
'chunking_config': {
'white_space_config': {
'max_tokens_per_chunk': 500,
'max_overlap_tokens': 50
}
}
}
)이렇게 하면 각 청크당 최대 500 토큰, 중복 50 토큰 기준으로 분할됩니다. 즉, 단순 자동 분할 대신 프로젝트의 성격에 맞게 문서 단위를 세밀하게 조정할 수 있는 것입니다.
🔹 파일 메타데이터 설정 및 필터링
File Search는 단순 검색 이상의 기능을 지원한다.
각 파일에 커스텀 메타데이터를 추가할 수 있어, 나중에 특정 조건에 맞는 문서만 검색하는 게 가능합니다.
예를 들어 문서의 저자나 발행 연도를 메타데이터로 추가해보겠습니다.
# 메타데이터를 포함해 파일 가져오기
op = client.file_search_stores.import_file(
file_search_store_name=file_search_store.name,
file_name=sample_file.name,
custom_metadata=[
{"key": "author", "string_value": "Robert Graves"},
{"key": "year", "numeric_value": 1934}
]
)이제 “저자가 Robert Graves인 문서만 검색”하는 것도 가능합니다.
# 메타데이터 필터링을 사용한 검색
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="Tell me about the book 'I, Claudius'",
config=types.GenerateContentConfig(
tools=[
types.Tool(
file_search=types.FileSearch(
file_search_store_names=[file_search_store.name],
metadata_filter="author=Robert Graves",
)
)
]
)
)
print(response.text)대량의 문서를 한 스토어에 저장하더라도, 메타데이터 필터를 통해 필요한 문서만 효율적으로 검색할 수 있습니다.
🔹 인용 정보 표시
RAG 시스템의 핵심 중 하나는 출처가 명확한 답변이다.
File Search는 모델이 어떤 문서 chunk를 참고했는지 명시하는 인용(grounding) 정보를 함께 제공한다.
print(response.candidates[0].grounding_metadata)
...
GroundingSupport(
grounding_chunk_indices=[
0,
1,
],
segment=Segment(
end_index=3313,
start_index=2988,
text="""**경쟁 제품 및 차별점:**
Google File Search는 OpenAI의 '어시스턴트 API', AWS의 '베드록', 마이크로소프트의 '애저 AI 서치' 등과 경쟁하며, 단순히 일부 구성 요소만 관리하는 것이 아니라 RAG 파이프라인 전체를 자동화한다는 점을 차별점으로 내세웁니다."""
)
)
이 정보를 활용하면 모델이 실제로 어떤 문서 내용을 근거로 답변을 생성했는지 검증할 수 있습니다.
또한 출력 예시처럼 start_index와 end_index가 제공되기 때문에, 인용된 텍스트의 정확한 위치까지 파악할 수 있습니다.
File Search pricing
File Search의 검색 store 유지비와 질문에 대한 임베딩 생성 비용이 완전히 무료입니다.
비용이 드는 구간은 오직 파일을 업로드한 뒤 인덱싱을 수행할 때뿐이며, 이 비용 역시 100만 토큰당 $0.15로 고정되어 있습니다.
즉, 한 번 인덱싱을 마치고 나면 이후 검색은 얼마든지 수행해도 추가 비용이 들지 않는다는 점이 큰 장점입니다.
다만 저장 용량이 1GB를 초과하는 경우에는 별도의 저장 비용이 부과될 수 있지만, 1GB까지는 무료로 제공됩니다.
이러한 구조 덕분에 개발자는 운영비를 명확하게 예측할 수 있고, 다양한 시도를 거의 비용 부담 없이 진행할 수 있다는 점에서 File Search를 매우 매력적으로 활용할 수 있습니다.
File Search 단점?
File Search는 완전 관리형 서비스인 만큼, 세부적인 조정이 필요한 개발자 입장에서는 다소 답답할 수 있습니다.
예를 들어 chunking 전략을 커스텀할 수 있다고는 해도, 세부적인 chunking 전략(semantic chunking, Recursive Chunking)을 적용할 수 없으며, 임베딩 모델 자체를 교체하거나 reranking과 같은 검색 성능 최적화는 지원하지 않습니다.
모든 과정이 내부적으로 완전히 추상화되어 있어 “어떻게 돌아가는지”를 세세하게 제어할 수 없다는게 가장 큰 단점입니다.
또한 File Search는 gemini api에 종속되어 있기 때문에 다른 LLM과 함께 사용할 순 없습니다.
마무리
file search와 관련해서 전체 내용을 요약하자면 다음과 같습니다.
| 항목 | File Search tool 특징 |
|---|---|
| 형태 | 완전 관리형 RAG 시스템 |
| 엔진 | Gemini Embedding + 벡터 검색 |
| 비용 | 데이터 인덱싱 시 100만 토큰당 $0.15 |
| 지원 포맷 | PDF, DOCX, TXT, JSON, 코드 파일 등 |
| 장점 | 손쉬운 통합, 빠른 구축 |
| 한계 | 커스터마이징 제약, gemini api와 함께 사용되어야함. |
File Search는 아직 완성된 형태의 RAG 플랫폼이라기보다는, “RAG의 방향성을 제시한 프로토타입”에 더 가깝습니다.
그럼에도 불구하고 구글이 보여준 File Search가 중요한 이유는 RAG 시스템 구축의 진입 장벽을 완전히 무너트렸습니다.
이제 vector db와 관련된 지식이 없어도, 인프라 운영 경험이 없어도 자신의 데이터로 AI 애플리케이션을 만들 수 있게되었습니다.
개인적으로 작년에 출시돼 큰 이슈를 몰고왔던 Notebook LM을 API화한 형태에 가장 근접한 제품을 내놓았다고 생각됩니다.
향후에는 기업별 데이터 규모나 보안 정책, 검색 전략에 맞춘 확장 옵션이 추가되었으면 좋겠지만, gcp의 vertex AI와 겹치는 영역이 있기 때문에, 더이상의 업데이트가 되지 않을 수 도 있겠단 생각이 듭니다.
그럼에도 이번에 출시된 File Search는 RAG 기술의 대중화를 한 단계 앞당긴 사례로 볼 수 있습니다. 앞으로 이 방향성이 더 많은 실험과 발전으로 이어지길 기대합니다.
Reference
'AI' 카테고리의 다른 글
| RAG #2 - Chunking (0) | 2025.12.28 |
|---|---|
| RAG #1 (0) | 2025.12.28 |
| Agile is Out, Architecture is Back (0) | 2025.11.09 |
| LangGraph를 활용한 에이전트 디자인 패턴 (1) | 2025.10.31 |
| AI Agent vs Agentic AI (3) | 2025.07.27 |
