---
task_id: task-2133
type: context
scope: task
created: 2026-04-23
updated: 2026-04-23
status: in-progress
---

# 맥락 노트: task-2133

**task**: task-2133

---

## 결정 근거

### B안(Cron 데이터 파이프라인) 채택
- pytrends 실시간 호출 시 Google 429 rate limit 반복 발생 (사용자 경험 저하)
- 에이전트 미팅 19명 전원 합의로 B안 채택
- A안(실시간 + 캐싱) 기각 이유: 첫 호출 시 여전히 429 위험, 캐시 만료 시 재호출 필요
- B안 장점: 429 에러 완전 해소, 응답 속도 < 50ms, 예측 가능한 수집 스케줄

### 3 Step Why 자문
- 1st Why: "왜 이 설계가 필요한가?" → pytrends 실시간 호출이 Google 429 rate limit을 유발하여 사용자가 구글 트렌드 탭을 사용할 수 없음
- 2nd Why: "왜 Cron 배치 수집이 최선인가?" → 수집 시간을 새벽 고정으로 분산하면 rate limit 회피 가능 + DB 캐시로 응답 속도 개선
- 3rd Why: "왜 다른 대안(실시간 캐싱, SerpAPI)보다 나은가?" → 실시간 캐싱은 첫 호출 429 위험 잔존, SerpAPI는 유료(Phase 3), Cron은 무료 + 안정적

## 참조 자료

- 미팅 합의: `/home/jay/workspace/memory/meetings/2026-04-23-google-trends-architecture.md`
- 기존 API 코드: `/home/jay/projects/InsuRo/server/main.py` L896~967
- 프론트엔드: `/home/jay/projects/InsuRo/src/pages/KeywordAnalysis.tsx`

## 주의사항

- pytrends 수집 시 랜덤 딜레이 30~60초 필수 (rate limit 방지)
- Supabase RLS: 읽기는 Public, 쓰기는 service_role만 가능
- 기존 프론트엔드 응답 형식(timeline, related_queries) 유지 필수
- main.py가 2271줄로 대형 파일 — Edit 시 주의