# Agent 미팅: InsuRo 구글 트렌드 구현 아키텍처 설계

**날짜**: 2026-04-23
**소집 이유**: pytrends 실시간 호출 → Google 429 rate limit 반복. 제이회장님이 3가지 대안 + 로드맵 제시, 최적 아키텍처 결정 필요
**참여 페르소나**: 불칸, 토르, 야누스, 오딘, 이리스, 프레이야, 미미르, 아테나, 로키, 마아트, 비너스, 아틀라스, 다빈치, 헤르메스, 다그다, 비슈누, 마르둑, 페룬, 이참나 (19명)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 1 (Cycle 1에서 전원 합의 달성)

---

## Cycle 1 (Independent — 병렬 소집)

### 전원 합의 사항

#### 1. 대안 선택: B안 (pytrends + Cron 데이터 파이프라인)
- A안(Iframe) **만장일치 탈락**: UI 커스터마이징 불가, 데이터 가공 불가, White-labeling 불가
- B안 **만장일치 채택**: Cron 배치 수집 → DB 저장 → 자체 API 제공
- C안(유료 API): Phase 1 미도입, 설계 추상화만 준비 (오딘), 스케일 시 전환 (아틀라스)
- 로키 초경량 MVP 제안 ("링크만 제공"으로 사용 의향 먼저 검증): 아틀라스 동의, 다만 제이회장님이 이미 B안 방향 제시했으므로 파일럿 겸용 구현

#### 2. 아키텍처 구조 (3레이어)
```
[수집 레이어] systemd timer → pytrends 배치 수집 (매일 새벽)
  ↓
[저장 레이어] Supabase PostgreSQL (만장일치)
  ↓
[서비스 레이어] FastAPI → 프론트엔드 Recharts 차트
```

#### 3. Cron 실행 위치
- **systemd timer** (야누스, 토르, 마르둑): API 프로세스와 분리
- APScheduler 내장도 가능 (이참나): MVP에서는 더 간단
- **합의**: systemd timer 우선 (API 장애와 수집 장애 격리)

#### 4. 키워드 관리
- Phase 1: 고정 리스트 20~30개 (보험 핵심 키워드)
- DB 테이블 관리 (`trend_keywords`)
- Phase 2: 카테고리별 그룹 (생명/손해/연금/건강/자동차)
- Phase 3: 사용자별 커스텀

#### 5. DB 스키마 (Supabase PostgreSQL)
```sql
trend_keywords(id, keyword, category, is_active, created_by, created_at)
trend_data(id, keyword_id, region, date, value, source, collected_at)
trend_collection_runs(id, started_at, finished_at, status, keywords_count, errors)
```
- `(keyword_id, date, region)` 유니크 제약
- `source` ENUM('pytrends', 'serpapi') — 향후 전환 대비
- `raw_response` JSONB 컬럼 (페룬 제안) — 원본 보존

#### 6. 프론트엔드
- Recharts 유지 (이리스, 미미르)
- 키워드 선택: Combobox 자동완성 (사전 수집 키워드 한정)
- 키워드 비교: 최대 3개 멀티셀렉트 + 컬러 코딩
- 기간 선택: 프리셋 버튼 (7/30/90/365일)
- 카테고리: 생명/손해/연금/건강/자동차 + 인기급상승
- 갱신 안내: "최종 업데이트: YYYY-MM-DD HH:MM" 상시 표시
- 기본 뷰: "오늘의 인기 키워드 TOP 5" (아테나)
- Iframe 불채택, "Google Trends에서 보기" 링크로 대체

#### 7. 담당팀
- **1팀(헤르메스) 단독** (비슈누, 마르둑, 페룬, 이참나 동의)
- 5팀(마르둑) 모니터링/알림 지원
- 4태스크: T1 DB스키마, T2 수집기, T3 API수정, T4 프론트차트

#### 8. 리스크 대응
- pytrends 429: 키워드 간 랜덤 딜레이(30~60초) + 일일 1회 제한 (마르둑)
- 수집 실패: Telegram 알림 (야누스), `trend_collection_runs` 이력 (오딘)
- pytrends 라이브러리 death: Collector 인터페이스 추상화 (오딘) — Phase 2
- stale 데이터: 48시간 초과 시 경고 배지 (마아트)
- 데이터 상대성 오해: 0-100은 상대 지수임을 UI에 명시 (마아트)

### Devil's Advocate (로키)
1. **실패 시나리오**: pytrends 구조 변경 → Cron 조용히 실패 → stale 데이터 방치
2. **후회 이유**: 트렌드 기능의 실제 사용률 미검증 상태에서 과잉 구축
3. **더 단순한 대안**: Google Trends 링크만 제공 → 클릭률 측정 → 내재화 판단

**반박**: 제이회장님이 이미 B안 방향을 제시했고, 파이프라인 자체가 MVP 수준이므로 과잉이 아님. Cron 실패 모니터링으로 stale 데이터 방지 가능. 로키 제안의 "링크 제공"은 파일럿 단계에서 병행 가능.
**판정**: 반박 수용. B안 진행하되, 사용률 측정 코드 포함.

### 비관습적 대안 (다빈치)
**"보험 날씨 지도"**: 지역별 보험 키워드 트렌드를 한국 지도 위에 날씨 아이콘으로 시각화. 설계사가 자기 영업 지역의 "보험 날씨"를 한눈에 파악.

**5항목 평가**:
1. 최강 지지: 트렌드 → 액션 전환율 극대화, 설계사에게 직관적 가치
2. 최강 반론: 지역별 데이터는 pytrends `geo` 파라미터 세분화 필요, 수집 볼륨 증가
3. 이상적 시나리오: 지역 영업 비중 높은 보험설계사 SaaS
4. 노력 수준: 높음 (지도 시각화 + 지역별 수집)
5. 리스크: 중간 (수집 볼륨 증가 → 429 리스크)

**판정**: Phase 2~3에서 부분 반영 (지역 필터 + 히트맵). Phase 1에서는 제외.

---

## 최종 합의 사항
1. B안(pytrends + Cron 파이프라인) 채택, A안 탈락, C안 Phase 3 대비
2. systemd timer로 매일 새벽 수집, API와 프로세스 분리
3. Supabase PostgreSQL에 3테이블 (keywords, data, runs)
4. 프론트엔드: Recharts, Combobox, 프리셋 기간, 카테고리 그룹핑
5. 1팀 단독 실행, 4태스크, 1~2세션 완료 예상
6. 사용률 측정 코드 포함 (로키 DA 반영)
7. Cron 실패 Telegram 알림 필수
8. "보험 날씨 지도"는 Phase 2~3 검토

## 다음 단계
- 제이회장님 승인 → 1팀(헤르메스) 위임
- 3문서 작성: `memory/plans/insuro-google-trends/`

---

## 2차 미팅: 3단 하이브리드 키워드 소싱 (10사이클)

**날짜**: 2026-04-23
**참가자**: dev1-team 전원(Opus), 로키, 마아트, 비너스, 아틀라스, 다빈치
**사이클**: 10회 (발산 5 + 정리 2 + 구현 3)

### 최종 합의

#### Phase 1 MVP 범위 (8개 모듈)
1. FixedCollector (L1 고정 30개)
2. NaverCollector (L2 네이버 검색광고 API 70개, 주1회)
3. KeywordNormalizer (4단계 + 동의어 30쌍)
4. NegativeFilter (50개 JSON)
5. 키워드 3상태 모델 (active/inactive/retired)
6. 스코어링 v1 (네이버 검색량)
7. REST API 3개 엔드포인트
8. 프론트 리스트 뷰 TOP 20

#### 미확정→확정 4건 (전원 만장일치)
- 비공식 API → Phase 2
- 키워드 정규화 → Phase 1 (최소)
- 네거티브 50개 → Phase 1
- 리스트 뷰 → Phase 1, 버블맵 → Phase 2

#### 위임 계획 (3건 dispatch)
- dev3-team: 백엔드 전체 (DB+Collector+API)
- dev6-team: 프론트엔드 (리스트뷰+컴포넌트)
- composite-team: QA/보안 (테스트 9종+보안 4종)

#### Temporal Interrogation
- [HOUR 1] DB 마이그레이션 + BaseCollector + API 스펙 합의
- [HOUR 2-3] Collector 구현 + 프론트 목업 병렬
- [HOUR 4-5] 통합 + QA 시작
- [HOUR 6+] 버그 수정 + 최종 검증