---
title: NotebookLM 및 Google Drive 연동 기반 RAG 시스템 구축
date: 2026-02-25
status: planning
---

# NotebookLM 및 Google Drive 연동 AI 검색 (RAG) 시스템

## 1. 개요
* 프로젝트: InsuWiki
* 목표: 구글 드라이브를 지식 저장소(서버)로 활용하고, NotebookLM을 파이프라인으로 연결하여 InsuWiki 내부에 질의응답 기능 구축하기
* 담당: 9-Agent 전체 (Data, Backend, Frontend 집중)

## 2. 세부 구현 목표
1. **Google Drive Sync**: 백엔드 API 및 Firestore 트리거를 이용하여 사용자 문서를 구글 드라이브(특정 폴더)에 `.md` 형식으로 실시간 동기화 및 덮어쓰기.
2. **NotebookLM 세팅**: 동기화된 구글 드라이브 폴더를 소스로 지정하는 노트북 매핑. 데이터 식별자 역추적을 위한 프론트매터(Frontmatter) 메타데이터 주입.
3. **MCP 브릿지 서버**: `notebooklm-mcp`를 통해 NotebookLM의 Q&A 기능을 API로 외부에 노출시켜 브릿지 구축.
4. **InsuWiki AI UI**: 전역 검색창(`SearchModal`)에 AI 질문 탭 신설, 스트리밍 타이핑 효과 및 정확한 출처 링크(Citation) 표시 UI 연동.

## 3. 리스크 평가 및 대응 방안 (Edge Cases)
이 시스템 구축을 위해 에이전트 미팅에서 도출된 핵심 리스크와 해결 방안은 다음과 같습니다.

1. **Google Drive API Rate Limit (호출 제한)**
   - *문제*: 사용자가 문서를 연속 저장 시 API 요금 및 트래픽 제한.
   - *대응*: 실시간 Push 기반을 버리고, 1시간 또는 커밋 주기 기반의 **배치(Batch) 덤프 업로드** 방식 도입 (디바운싱).

2. **NotebookLM 50개 소스 파일 한계 (대규모 PDF 약관 처리 불가)**
   - *문제*: 회사별 약관/매월 소식지 등 중요 문서가 50개를 넘어가는 순간 NotebookLM은 아예 수용 자체가 불가능함. (가장 치명적인 System Blocker)
   - *대응*: NotebookLM을 폐기하고, 파일 갯수 제한이 없는(수천~수만 개 지원) **[대안 A: 구글 공식 클라우드 Vertex AI Search 연동]** 또는 **[대안 E: 구글 드라이브 + Gemini File API 직결]** 구조로 아키텍처 전면 전환(Pivot).

3. **초대용량 데이터(수백 기가) 4대 데스 밸리 및 하이브리드 아키텍처 도입**
   - *문제*: PDF 통째 전송 시 **Vercel 10초 타임아웃**, 대상 파일의 **사전 선별 불가(RAG 부재)**, Gemini File API의 **48시간 단기 TTL**, 그리고 파일당 수만 토큰이 소모되는 **롱 컨텍스트 과금 폭탄(128k 초과 구간)** 이라는 4대 치명적 한계(대안 E의 구멍)에 봉착.
   - *최종 아키텍처 결론 (The Masterpiece)*: 
      - 단일 아키텍처의 한계를 인정하고, 데이터 특성별로 파이프라인을 나누는 **[대안 F: 데이터 맞춤형 하이브리드 아키텍처]** 로 최종 확정(Pivot).
      - 1) **가벼운 위키/소식지**: Dify.ai 또는 Firestore Vector RAG 운영.
      - 2) **보험료 표(Table)**: Firestore 구조화 컬렉션에 직접 파싱 후 단순 조건 쿼리로 100% 무결점 조회.
      - 3) **약관 PDF 선별 질의**: 회사/상품 메타데이터로 사전 경량 인덱싱. 사용자가 UI에서 먼저 조건을 좁히면(선별), 해당 단일 PDF만 Gemini 롱 컨텍스트 1회성 쿼리로 넘겨서 비용/타임아웃/정확도를 완벽히 통제.

4. **대안 F 구현을 위한 3대 과제 돌파 전략 (How to Build)**
   - **구멍 A (테이블 파싱 정확도 및 스키마)**: 코딩 전 **[Phase 0]** 선행. 가장 복잡한 **3대 보험료 표 유형(생보사 가로세로 축, 손보사 실비/운전자 믹스, 변액/CI 등 조건부 특약 레이아웃)** 샘플을 각각 수동으로 Gemini Vision API에 테스트하여 정확도를 검증. **통과 기준은 1원이라도 틀리지 않는 '오류율 0%'**. 단 1건이라도 환각/오차 발생 시, Vision API 자동화를 즉시 포기하고 **[Plan B: 사용자 수동 엑셀(Google Sheets) 입력 -> Firestore 스키마 동기화]** 로 방향을 180도 트는 것을 전제로 설계.
   - **구멍 B (Vercel 타임아웃 & API 보안 & 고아 Job 방어)**: 프론트는 Vercel API에 요청 후 `jobId`만 즉시 응답받고 종료. Vercel 뒤통수에서 **Firebase Cloud Functions 2세대(Blaze 플랜, 최대 타임아웃 9분 연장)** 가 안전한 환경변수로 파일 다운로드 및 Gemini 업로드를 비동기 수행. 프론트는 비용이 폭증하는 실시간 구독(`onSnapshot`)을 버리고, 3~5초 간격의 **REST API Polling** 방식으로 렌더링. 무한 로딩 방어를 위해 Firestore `jobId` 상태를 `pending/complete/failed` 3단계로 엄격히 관리하며 **프론트 최대 대기 시간(예: 3분) 초과 시 강제 `failed` 상태 처리**. 또한 서버 사망 시의 좀비 Job 잔류를 막기 위해 **Firestore TTL(Time-to-Live)을 적용하여 Job 문서 생성 10분 후 자동 완전 삭제** 설정.
   - **구멍 C (좀비 캐시 무효화)**: 최초 업로드된 `file_id`를 Firestore에 48시간 캐싱하되, 구글 드라이브 원본 파일이 갱신(수정/덮어쓰기)될 경우 Webhook 또는 동기화 로직이 해당 Firestore 문서를 즉시 강제 삭제(**Cache Invalidation**)하여 항상 최신 신규 업로드가 발생하도록 통제.

5. **권한 격리 붕괴 (보안)**
   - *문제*: 나만의 일기나 Private 문서를 올릴 경우 다른 사용자에게 유출될 우려.
   - *대응*: **(Phase 1)** 목표를 `isPublic: true` 인 전체 공유된 지식 문서로만 100% 한정. 개인 문서는 연결 타겟에서 제외.

6. **UI 프론트엔드 불안정성 극복**
   - *대응*: 1) MCP/서버 장애 시 `Timeout Fallback` 렌더링. 2) 응답 중단 처리(AbortController). 3) AI 추천 문서 삭제 시 `404 Not Found` 예외 핸들링 보장.

## 4. 진행 현황 (Status)
- [x] (완료) 아키텍처 한계점 심층 분석 및 대안 6종(A~F) 팩트 체크 완료
- [x] (완료) 종혁님 컨펌 획득: 데이터 맞춤형 하이브리드 아키텍처(대안 F) 및 3대 과제 돌파 전략 채택
- [x] (완료) **Phase 0 (Task 1)**: Gemini Vision 기반 보험료 테이블 추출 PoC 테스트 완료 (오차율 0% 달성 및 File API JSON 강제 파싱 채택)
- [x] (완료) **Task 2 (백엔드 인프라)**: Firestore 컬렉션 스키마(`jobs`, `gemini_file_cache`) 정의 및 TTL 정책 10분/48시간 설정
- [x] (완료) **Task 3 (Long-context Worker)**: Cloud Functions V2 (`timeoutSeconds: 540`) `processInsuranceQuery` 함수 작성 및 Google Drive -> Gemini File 직접 비동기 업로드/추론 파이프라인 구축 완료
- [x] (완료) **Task 4 (API Routes)**: Vercel 타임아웃 우회를 위한 Next.js 비동기 트리거 (`/api/ai/query`) 및 상태 조회 폴링 라우트 (`/api/ai/status`) 구현
- [ ] (진행 예정) **Task 5 (Frontend UX)**: 회사/상품 메타데이터 선별 Dropdown UI 컴포넌트 연동 및 폴링 커스텀 훅, 로딩 타임아웃 UX 처리