Claude Code와 함께 Gemini File Search로 나만의 RAG 시스템 구축하기

Claude Code를 나만의 워크스페이스로 사용한지 약 1달 반.

그 사이 약 1000개의 파일이 쌓였다.

Daily Note, 프로젝트 문서, 아이디어를 기록했다.

그런데 문제가 생겼다.

"강릉 카페 프로젝트에서 배운 교훈이 뭐였지?"

찾을 수가 없다.

Obsidian 검색창에 "강릉"을 쳐보니 23개 파일이 나온다.

하나씩 열어봐야 한다.

30분이 걸렸다.

"예전에 정리한 그 명언... 뭐였더라?"

키워드를 기억 못 하면 찾을 수 없다.

grep으로 텍스트를 검색할 수는 있지만, 정확한 문구를 알아야 한다.

"AI와 바텀업 관련해서 뭐 썼었는데..."

바텀업이라고 쓴 게 아니라 "Bottom-Up"이라고 영어로 썼다면?

못 찾는다.

키워드 검색의 한계다.

단어가 정확히 일치해야만 찾는다.

의미는 모른다.

그래서 만들었다.

시맨틱 검색이 되는 RAG 시스템을.



그런데 왜 RAG인가?

Ctrl+F로 검색하면 되는 거 아닌가?

RAG가 필요한 이유가 따로 있다.

LLM은 전체를 못 읽는다

GPT-4: 10만 단어까지
Claude: 15만 단어까지

내 PKM: 851개 파일 = 수십만 단어

→ 한 번에 못 넣는다

그래서 필요한 부분만 찾아서 넣어준다.

RAG가 하는 일이다.

시맨틱 검색은 덤이다

RAG를 만드는 진짜 이유:

  • 컨텍스트 제약 해결 (메인)

  • 최신 정보 제공

  • 비용 절감

  • 시맨틱 검색 (부수적 장점)

시맨틱 검색은 "어떻게 관련 문서를 찾을까"의 방법론.

RAG의 목적이 아니다.

비유:

RAG = 도서관 사서

목적: 10만 권을 다 못 읽으니 → 필요한 5권만 찾아줌
방법: 시맨틱 검색 → 내용도 이해해서 찾음


RAG 시스템, 그런데 너무 복잡한

RAG(Retrieval-Augmented Generation).

문서를 벡터로 변환해서 의미 기반으로 검색하는 시스템.

문제는 구축 과정이다.

전통적인 RAG 구축 단계:

1. 벡터 데이터베이스 선택
   - Pinecone? Weaviate? Qdrant?
   - 비용 구조 비교
   - 인프라 설정

2. 청킹 전략 설계
   - 청크 크기: 500 tokens? 1000 tokens?
   - 오버랩: 50 tokens? 100 tokens?

3. 임베딩 모델 선택
   - OpenAI ada-002? text-embedding-3?
   - 한국어 성능 비교

4. 검색 로직 최적화
   - 유사도 계산 방식
   - Top-K 설정

5. 인프라 운영
   - 데이터베이스 관리
   - 백업 전략
   - 비용 모니터링

며칠 걸리는 작업이다.

개인 PKM에 쓰기엔 너무 무겁다.

"더 간단한 방법 없나?"



해결: Gemini File Search

2025년 11월 7일.

Google이 Gemini File Search를 공개했다.

핵심 차별점:

  1. 완전 관리형 RAG - 벡터 DB, 청킹, 임베딩 자동 처리

  2. 파격적 가격 - 저장소 무료, 쿼리 임베딩 무료, 인덱싱만 $0.15/1M tokens

  3. 즉시 사용 - 파일 업로드하면 끝

벡터 DB 설정할 필요 없다.

청킹 전략 고민할 필요 없다.

임베딩 모델 선택할 필요 없다.

그냥 파일 올리면 끝.



11월 16일, Claude Code와 대화로 만들었다

나: "RAG 시스템 만들고 싶은데 너무 복잡해"

PKM 949개 파일을 RAG로 만들고 싶었다.

근데 벡터 DB 설정, 청킹 전략, 임베딩 모델 선택...

복잡해서 계속 미루고 있었다.

그러다 Gemini File Search API를 발견했다.

완전 관리형 RAG.

"이걸로 내 PKM RAG 만들 수 있을까?"

나: "Claude, Gemini File Search API 문서 확인해줘. 내 PKM 949개 파일로 RAG 구축 가능할지 봐줘."

Claude Code가 문서를 읽고 분석했다.

Claude Code 분석 결과:

✅ 벡터 DB 설정 불필요 (Google이 관리)
✅ 청킹 전략 고민 불필요 (자동)
✅ 임베딩 모델 선택 불필요 (자동)
✅ 저장소 무료 (Free tier 1GB)
✅ 인덱싱 비용 저렴 ($0.15/1M tokens)

→ 개인 PKM에 완벽합니다!

나: "좋아, 만들어줘."



Claude Code: "Store 구조부터 설계하죠"

Claude Code가 제안했다.

"PKM을 10개 Store로 나누는 게 좋겠어요. 검색 정확도가 올라갑니다."

왜?

전체 검색 vs Store 분리 검색:

전체: "강릉 프로젝트" 검색 → 851개 파일 전체 검색
분리: consulting-active Store만 검색 → 72개만 검색

→ 정확도 ⬆️, 속도 ⬆️

Claude Code가 만든 구조:

Phase 1: Core Knowledge (CRITICAL)
├── claude-code-kb (81 files)
└── knowledge-ai-business (191 files)

Phase 2: Active Projects (HIGH)
├── education-projects (156 files)
├── consulting-active (72 files)
├── imi-work-brand (39 files)
└── operations (67 files)

Phase 3: Context & History (MEDIUM)
├── daily-notes (40 files)
├── personal-workspace (44 files)
├── system-config (42 files)
└── archive (119 files)

총 10개 Store, 851개 파일

"Phase 1-3으로 나눈 이유는요, 자주 쓰는 것부터 우선순위를 둬서 나중에 검색 범위를 좁힐 수 있어요."

"좋아, 이대로 만들자."



Claude Code: "스크립트 3개 만들게요"

1. init.py - Store 생성:

# Claude Code가 작성
import google.generativeai as genai

for store_config in STORE_CONFIGS:
    store = client.create_file_search_store(
        name=store_config['name'],
        display_name=store_config['display_name']
    )
    print(f"✅ Created: {store.name}")

"실행할게요."

python3 init.py
✅ Created: claude-code-kb
✅ Created: knowledge-ai-business
✅ Created: education-projects
...

30분 만에 10개 Store 생성 완료.



나: "파일 업로드 시작해줘"

2. sync.py - 파일 업로드

Claude Code가 업로드를 시작했다.

그런데 에러.

❌ Error: 400 INVALID_ARGUMENT
한글 파일명은 HTTP 헤더에서 지원되지 않습니다

나: "이거 어떻게 해?"

Claude Code가 알아서 해결:

"HTTP 헤더는 ASCII만 지원하네요. 파일명을 순차 번호로 바꿔서 업로드하겠습니다. 원본은 그대로 두고요."

# Claude Code가 수정한 코드
for idx, file_path in enumerate(files, 1):
    display_name = f"{store_id}_{idx:04d}.md"  # 한글 제거

    client.file_search_stores.upload(
        path=str(file_path),
        config={'display_name': display_name}
    )

"다시 실행할게요."

claude-code-kb: 81/81 uploaded ✅
knowledge-ai-business: 191/191 uploaded ✅
education-projects: 156/156 uploaded ✅
consulting-active: 72/72 uploaded ✅
...

Total: 851 files, 0 errors

15분 만에 완료.

나는 아무것도 안 했다.

Claude Code가 문제를 발견하고, 해결하고, 재실행했다.



나: "검색이 안 돼"

3. query.py - 검색 실행

Claude Code가 처음 만든 코드:

response = client.models.generate_content(
    model='gemini-2.0-flash-exp',
    ...
)

에러.

❌ Error: 400 INVALID_ARGUMENT

나: "왜 안 돼?"

Claude Code가 문서 다시 확인:

"아, gemini-2.0-flash-exp는 File Search를 지원 안 하네요. 2.5-flash로 바꿔야 해요."

"그리고 file_search 파라미터가 snake_case가 아니라 camelCase예요. fileSearch로 써야 합니다."

# Claude Code가 수정
response = client.models.generate_content(
    model='gemini-2.5-flash',  # 모델 변경
    contents=query,
    config=types.GenerateContentConfig(
        tools=[
            types.Tool(
                fileSearch=types.FileSearch(  # camelCase
                    fileSearchStoreNames=[store_name]
                )
            )
        ]
    )
)

"다시 실행할게요."

✅ 검색 성공!

## PKM 검색 결과

**질의**: 강릉 프로젝트 교훈

### Consulting Projects
강릉 지역 카페의 차별화 전략은...

작동했다.




나: "Skill로 만들어서 자동화하자"

검색은 작동한다.

근데 매번 python3 query.py "강릉 프로젝트 교훈" 치기 귀찮다.

나: "Claude Code Skill로 만들어줘. '찾아줘', '검색' 같은 말만 하면 자동으로 실행되게."

나: "참고로, 내가 정리해둔 Skill 문서 있어. @pkm/30-knowledge/37-claude-code/37.04-skills-and-case-studies/00-official-docs/claude-skills-official-docs.md 이거 보고 만들어."

Claude Code가 문서를 읽고 Skill을 작성했다.

핵심 포인트:

  • description에 트리거 키워드 명시 ("찾아줘", "검색", "과거에")

  • allowed-tools로 Bash, Read만 허용 (안전성)

  • Model-invoked 방식으로 자동 실행

# pkm-file-search Skill
---
name: pkm-file-search
description: |
  PKM에서 과거 내용을 검색.
  "찾아줘", "검색", "과거에", "예전에", "언제"
  같은 검색 의도 표현 시 자동 실행.
allowed-tools: Bash, Read
---

이제는 이렇다.

나: "강릉 프로젝트 교훈 찾아줘"

Claude: [pkm-file-search Skill 자동 실행]
        [Gemini File Search 검색]
        [검색 결과 제공]

스크립트 명령어 칠 필요 없다.

그냥 대화로 검색한다.

Skill의 장점:

  • Model-invoked: Claude가 알아서 판단하고 실행

  • description 트리거: "찾아줘" 같은 자연스러운 표현으로 실행

  • 재사용: 모든 프로젝트에서 동일하게 작동




Before & After

Before (키워드 검색)

시나리오 1: 강릉 프로젝트 교훈 찾기

1. Obsidian에서 "강릉" 검색
2. 23개 파일 나옴
3. 하나씩 열어서 확인
4. 시간 소요: 30분

시나리오 2: "평균점에 돈을 지불하는 사람은 없다" 명언 찾기

1. "평균" 검색 → 없음
2. "돈" 검색 → 너무 많음
3. 포기

시나리오 3: AI 바텀업 현상 관련 내용

1. "AI" 검색 → 158개 파일
2. "바텀업" 검색 → 12개 파일
3. "bottom-up" 검색 → 5개 파일
4. 각각 읽어가며 관련 내용 찾기
5. 시간 소요: 45분

After (시맨틱 검색)

시나리오 1: 강릉 프로젝트 교훈

나: "강릉 프로젝트 교훈 찾아줘"
Claude: [관련 파일 3개 + 핵심 요약 제공]
시간: 30초

시나리오 2: 명언 찾기

나: "평균점에 돈을 지불하는 사람은 없다"
Claude: [정확한 파일 + 앞뒤 문맥 제공]
시간: 20초

시나리오 3: AI 바텀업

나: "AI와 바텀업 관련 내용"
Claude: [Bottom-Up AI Phenomenon 파일 찾음]
       [영어로 쓴 것도 한글 검색으로 찾음]
시간: 25초

개선점:

  • 키워드 검색 → 개념 기반 시맨틱 검색

  • 여러 파일 수동 확인 → 자동으로 가장 관련성 높은 파일

  • 정확한 문구 기억 필요 → 대략적인 개념만으로 검색 가능



비용: 월 $0.27

초기 구축:

임베딩 생성: 851 files × ~2K tokens = ~1.7M tokens
비용: 1.7M / 1M × $0.15 = $0.25 (1회만)

월간 운영 (일 10회 검색 기준):

검색: 10 queries/day × 30 days = 300 queries/month

각 검색당:
- Input: ~550 tokens (질의 50 + 검색 결과 500)
- Output: ~300 tokens (응답 생성)

비용:
- Input: 550 / 1M × $0.30 = $0.000165
- Output: 300 / 1M × $2.50 = $0.00075
- Total per query: ~$0.0009

월간: 300 × $0.0009 = ~$0.27/month

커피 한 잔도 안 된다.



좋은데, 아쉬운 점도 있다

사용하면서 몇 가지 아쉬운 점을 발견했다.

1. 완전 관리형이라 커스터마이징이 안 된다

편한데, 고칠 수 없다.

검색 결과가 이상해도 검색 방식을 조정할 수 없다.

임베딩 모델도 바꿀 수 없다.

완전 관리형의 양날의 검.

개인 PKM에서는: 괜찮다. 대부분 잘 찾는다.

앞으로 개선되면 좋을 것: 임베딩 모델 선택, 검색 가중치 조정 같은 옵션이 생기면 좋겠다.

2. 중복 파일 관리를 직접 해야 한다

같은 파일을 여러 번 업로드하면 모두 저장된다.

중복을 자동으로 방지하지 않는다.

파일 업데이트 관리는 직접 해야 한다.

개인 PKM에서는: 간단한 스프레드시트로 추적하면 된다.

앞으로 개선되면 좋을 것: 파일 해시 기반 중복 감지, 버전 관리 기능.

3. 정확한 키워드 검색이 약하다

시맨틱 검색만 된다.

"API-2024-001" 같은 정확한 코드 찾기는 약하다.

개인 PKM에서는: 그냥 grep과 병행하면 된다.

  • Gemini: 개념 검색

  • grep: 정확한 패턴 검색

앞으로 개선되면 좋을 것: 하이브리드 검색 (시맨틱 + 키워드) 지원.

4. 포괄적 데이터 추출이 안 된다

"모든 인용구 나열해줘" 같은 건 못 한다.

시맨틱 검색은 "의미"를 찾지, "패턴"을 찾지는 못한다.

개인 PKM에서는: grep으로 충분히 해결된다.

앞으로 개선되면 좋을 것: 패턴 매칭 기능 추가.

5. Store와 검색 개수 제한

  • Store는 10개까지만

  • 한 번에 5개 Store만 검색 가능

개인 PKM에서는: 10개면 충분하다. 5개 제한도 큰 문제는 아니다.

앞으로 개선되면 좋을 것: Store 개수 확장, 동시 검색 개수 증가.

6. 저장 공간이 3배 사용된다

실제 파일 75MB인데, Gemini에서는 225MB 사용한다.

임베딩 벡터와 인덱스 때문이다.

개인 PKM에서는: Free Tier 1GB면 충분하다.

앞으로 개선되면 좋을 것: 더 효율적인 저장 방식.



정리하면

개인 PKM에는 충분히 좋다 ✅

내 현재 상황:

✅ 851개 문서 검색
✅ 개념 기반 시맨틱 검색
✅ 월 $0.27 저렴한 비용
✅ 하루 만에 구축
✅ 검색 시간 30분 → 30초

→ 이 정도면 완전히 만족!

대부분의 개인 프로젝트, PKM, 소규모 지식 베이스에는 이것만으로 충분하다.

더 디테일한 RAG가 필요할 때는

이런 경우엔 직접 구축 고려:

- 정확한 키워드 검색이 핵심인 경우
- 여러 LLM을 동시에 써야 할 때
- 엔터프라이즈급 서비스
- 검색 알고리즘 튜닝이 필요할 때

그땐 Pinecone + LangChain 같은 커스텀 RAG를 구축하면 된다.

복잡하고 비싸지만, 완전한 제어권을 얻는다.

앞으로 기대하는 것

Gemini File Search는 2025년 11월에 나온 서비스다.

이제 막 시작했다.

앞으로 개선될 여지가 많다:

  • 하이브리드 검색 지원

  • 파일 버전 관리

  • Store 제한 완화

  • 더 효율적인 저장

  • 임베딩 모델 선택

지금도 충분히 좋지만, 앞으로 더 좋아질 것이다



사용 팁

지금 당장 (이번 주)

할 일:

  1. 저장 용량 모니터링 (실제 크기 × 3)

  2. 중복 업로드 방지 (간단한 추적 시스템)

  3. Store 구조 최적화 (자주 쓰는 것 위주)

필요할 때 (나중에)

더 정교한 검색이 필요하면:

  • Gemini: 개념 검색

  • grep: 정확한 패턴 검색

  • 두 개 병행하면 됨

예시:

질문: "강릉 프로젝트 교훈 + 정확한 매출 수치"

Claude Code:
1. Gemini로 "강릉 프로젝트 교훈" 검색
2. grep으로 "매출" 숫자 검색
3. 두 결과 합쳐서 제공



마무리

851개 파일 PKM을 1분 만에 검색할 수 있게 됐다.

하루 만에 구축했다.

월 $0.27 비용으로 운영한다.

개인 PKM, 소규모 프로젝트에는 이것만으로 충분하다.

디테일한 RAG 시스템이 필요할 땐, 그때 가서 Pinecone 같은 걸 쓰면 된다.

지금은 Gemini File Search로 충분히 만족스럽다.

앞으로 더 좋아질 것이다



기술 스펙

구축 시간:

  • Phase 1 (계획)

  • Phase 2 (환경 설정)

  • Phase 3 (Store 생성)

  • Phase 4 (파일 업로드)

  • Phase 5 (검색 스크립트)

  • Phase 6 (Skill 통합)

시스템 구조:

pkm/00-system/02-scripts/gemini-file-search/
├── init.py           # Store 생성
├── sync.py           # 파일 업로드
├── query.py          # 검색 실행
├── config.json       # Store 설정
└── requirements.txt  # 의존성

~/.claude/skills/pkm-file-search/
└── SKILL.md          # Claude Code 통합

비용 구조:

  • 초기 인덱싱: $0.25 (1회만)

  • 월간 운영: $0.27 (일 10회 검색)

  • 저장 공간: 무료 (Free tier 1GB)



Before & After 요약

Before (수동 검색)

  • 키워드만 검색 가능

  • 정확한 문구 기억 필요

  • 여러 파일 수동 확인

  • 시간 소요: 30-45분

After (시맨틱 검색)

  • 개념 기반 검색

  • 대략적인 의미만으로 검색

  • 자동으로 가장 관련성 높은 파일

  • 시간 소요: 30초

4
9개의 답글

뉴스레터 무료 구독

👉 이 게시글도 읽어보세요