# Agent 미팅: 트렌드 인사이트 키워드 풀 한계 극복

**날짜**: 2026-04-30
**소집 이유**: 풀 밖에서 급등하는 키워드(월 15회→1,000회)를 감지할 수 없는 근본적 한계 극복
**참여 페르소나**: 므네모시네, 아폴론, 에이레네, 로키, 야누스, 다빈치, 프로메테우스, 비너스(3회), 아틀라스(3회)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 10 (발산 5 → 정리 3 → 만장일치 2)

---

## Cycle 1 (Independent) — 9인 독립 의견 수집

### 므네모시네 (데이터 아키텍트)
- 뉴스 API + TF-IDF → SearchAd 검증 2단계 파이프라인
- 풀 티어링: Tier-1(2,000, 매일) / Tier-2(주2회) / Tier-3(월1회)
- API 복수 운용: 용도별 2~3개는 합리적 범위, 쿼터 회피 라운드로빈은 금지
- 뉴스 노이즈 70% 예상 → 도메인 사전 300개 교차 필터링 + 2일 연속 빈도 기준
- 금융위/금감원 보도자료 RSS 파싱 (공개 RSS, 법적 리스크 제로)

### 아폴론 (프로덕트 매니저)
- ★ 풀 밖 급등이 연간 몇 건인지 먼저 정량화 필요 (연 5~10건 추정, 의미 있는 건 2~3건)
- 풀 확장보다 "추천 정확도"가 핵심 가치 (설계사 월 활용 키워드 50~100개)
- Blog Search 게시물 증감률 = DataLab 대체 proxy 가능성 (API 한도 근본 해소)
- 뉴스 MVP: "오늘의 보험 뉴스 키워드" (정확도보다 신선함이 가치)
- 우선순위: 법규 변경 > 시즌성 > 커뮤니티

### 에이레네 (UX 리서처)
- 감지보다 "남보다 빨리 콘텐츠 만드는 것"이 관건 → 원스탑 포스팅 연동 필수
- 풀 확장보다 개인화 워치리스트 기능이 체감 가치 훨씬 큼
- "이 뉴스 때문에 이 키워드 검색량이 올랐다"는 인과 연결이 핵심 UX
- 커뮤니티(맘카페, 블라인드) 바이럴이 진짜 골든타임이지만 크롤링 없이는 어려움

### 로키 (레드팀 DA)
- ★ 풀 밖 급등 빈도부터 정량화하라 — 없으면 프로젝트 자체 불필요
- API 복수 운용 = 명백한 약관 위반. 적발 시 전체 키 차단 → 기존 모니터링도 중단
- 뉴스 키워드 노이즈 치명적: "보험사기", "보험금 살인" → 브랜드 리스크
- ★ "만들었지만 안 쓰는 기능" 위험 — 기존 2,000개 활용률 먼저 점검

### 야누스 (DevOps)
- 뉴스→후보→SearchAd 검증 2단계 파이프라인 + diff
- DataLab 3티어 로테이션으로 쿼터 내 해결
- API 복수 운용 대신 티어링 (약관 리스크 회피)
- 크론 분산: DataLab 02시, 뉴스 06시, Blog 10시

### 다빈치 (크리에이티브)
- ★ 역발상: 키워드가 찾아오게 하라 — 커뮤니티 RSS 구독 (크롤링 아님)
- ★ 이벤트 드리븐 풀 확장: 트리거(뉴스 3회+, 금감원 보도, 국회 법안) → 자동 편입
- ★ 시즌 캘린더 부스트: 해당 시즌 2주 전부터 관련 키워드 모니터링 빈도 자동 증가
- ★ LLM 키워드 예측기: 뉴스 100건 → GLM에 "급등 예측 10개" 요청 (간접 키워드 포착)

### 프로메테우스 (풀스택 아키텍트)
- "닫힌 풀" → "반개방 풀" 전환 설계 (뉴스 시그널 → SearchAd 게이트 → 자동 편입)
- 적응적 샘플링: 변동률 상위 500개 매일, 나머지 3일/7일 주기 → 일일 호출 700회로 절감
- 활성 풀 2,000 + 대기 풀 3,000 이원화 (대기 풀은 주간 SearchAd만)
- 키워드 상태 머신: 탐지됨→검증됨→추적중
- 뉴스 2단 필터: 도메인 사전 교차(느슨) + SearchAd 검증(엄격)

### 비너스 (3회 의견)
- (a) 신규 키워드에 "데이터 수집 중" 배지 필수 — 불완전 데이터를 동일 표시하면 신뢰 상실
- (b) 뉴스 키워드→실제 검색 키워드 괴리 → SearchAd 연관 키워드 매핑 레이어 필요
- (c) 차별화는 풀 크기가 아니라 해석 깊이 (법규 영향, 시즌 예측, 상품 매핑)
- 풀 확장보다 개인화 즐겨찾기 + "내 키워드" 기능
- 뉴스 출처 링크 함께 표시 → 콘텐츠 소재 활용
- 감성 필터(부정적/선정적 키워드 제외) 필요
- 법규→일반어 매핑 사전 필수 ("보험업감독규정" → "실비 자부담")

### 아틀라스 (3회 의견)
- (a) 뉴스 API 일 200~500회 + Mecab 형태소 분석(로컬) = 추가 비용 거의 제로
- (b) 뉴스 장애 시 "최근 7일 급등" 폴백. 기사 ID 멱등성 보장 필요
- (c) 뉴스 키워드 정규화 형태 불일치 → SearchAd 연관 키워드 매핑 + 캐싱
- 적응적 샘플링 시 인터럽트 메커니즘 (뉴스 시그널 → 관련 키워드 즉시 조회)
- 복수 출처 동시 감지 키워드에 높은 신뢰도 점수 부여
- 금감원 RSS 포맷 변경 대비 주간 헬스체크 + 복수 소스(생보협/손보협) 확보

---

## Cycle 1 교차 분석 — 9인 합의/분기 매핑

### 만장일치 (9/9)
1. **API 복수 운용 배제** — 약관 리스크가 이득보다 큼 (전원 동의)
2. **뉴스 API 기반 시그널 탐지 도입** — 구현 방식은 다르나 방향 전원 동의

### 다수 합의 (7/9 이상)
3. **적응적 샘플링 / 티어링** — DataLab 쿼터 내에서 풀 확장 (므네모시네, 야누스, 프로메테우스, 아틀라스, 다빈치, 비너스, 에이레네)
4. **금융위/금감원 RSS 법규 시그널** — 무료+합법+고정밀 (므네모시네, 야누스, 다빈치, 프로메테우스, 비너스, 아틀라스, 에이레네)
5. **뉴스 노이즈 방어: SearchAd 검증 게이트** — 2단 필터 (대다수)
6. **키워드→검색어 매핑 레이어 필요** — 비너스, 프로메테우스, 아틀라스 강조

### 주요 분기점 (추가 논의 필요)
7. **풀 밖 급등 빈도 정량화** — 로키/아폴론: 먼저 검증 필수 vs 다빈치/프로메테우스: 구조부터 만들자
8. **LLM 키워드 예측** — 다빈치 제안, 나머지 미언급
9. **개인화 워치리스트** — 에이레네/비너스 강조, 나머지 미언급
10. **Blog Search proxy** — 아폴론 제안 (DataLab 대체 가능성), 검증 필요

## Cycle 2~5 (발산) — 요약

### Cycle 2: 풀 밖 급등 빈도 정량화
- 로키: 2024~2026 사례 — 블랙스완 연 1~2건(티메프 여행자보험), 뉴스 선행 급등 연 3~5건(무해지환급금, 4세대실손, 반려동물보험)
- 아폴론: ROI 판정 → 투자 비용(크론 1개) 대비 기대 가치 압도적. 단, ThreadAuto 연계가 전제
- 다빈치: 한계 비용 제로 → "안 만드는 게 더 손해"
- 합의: **뉴스 시그널 감지 구축 확정. 블랙스완까지 잡으려는 과도 설계 금지**

### Cycle 3: 적응적 샘플링 구체 설계
- 프로메테우스: T1(50개/매일) + T2(100개/3일) + T3(150개/7일)
- 아틀라스: ★쿼터 경고 — 개별 호출 기준 일 1,428건으로 한도 초과!
- 합의: **배치 5개 묶기 전제로 일 22호출. Plan B: T3를 SearchAd 대체**
- 워밍업 기간: 승격 직후 3일간 변동률 계산 제외

### Cycle 4: 뉴스 키워드 추출 구체안
- 므네모시네: Mecab + LLM 2단계 (비용 월 $3)
- 비너스: 분리 표시, 수동 승인 UX, precision > recall 전략
- 로키 DA: 민감 키워드(보험사기, 보험금 살인) 편입 최악 시나리오 → 블랙리스트 + 수동 승인으로 구조적 차단
- 합의: **Mecab + 사전 매칭 + 인접어 패턴 → 블랙리스트 → SearchAd 검증 → 수동 승인**

### Cycle 5: Blog Search proxy + 추가
- 아폴론: Blog Search는 후행 지표. DataLab 대체 불가. 경쟁밀도 지표로만 독립 가치
- 다빈치: 시즌 캘린더(JSON 1개 + 10줄), LLM 예측(Phase 3), 커뮤니티 RSS(보류)
- 에이레네: ★가장 먼저 쓰고 싶은 것 = 시즌 캘린더, 필요 없는 것 = LLM 예측
- 합의: **Blog Search는 경쟁도 지표. 시즌 캘린더 Phase 2 도입. LLM 예측 Phase 3**

---

## Cycle 6~8 (정리)

### Cycle 6: 적응적 샘플링 쿼터 해결
- DataLab 배치 5개 묶기 → 일 22호출 (한도 1,000의 2.2%)
- 여유분 978호출 = 급등 재검증 + 뉴스 시그널 검증에 활용
- Plan B: 배치 미지원 시 T3→SearchAd 대체 (일 83호출)
- **만장일치 성립**

### Cycle 7: 뉴스 키워드 파이프라인 최종 스펙
- 추출: Mecab 명사 + 보험 사전 매칭 + 인접어 패턴 ('보험/보장/특약' 앞뒤 2글자+)
- 필터: 블랙리스트 → SearchAd 월간볼륨 100+ → keyword_candidates 테이블
- UX: 대시보드 "뉴스 키워드 후보" 분리 섹션, 승인/거부/블랙리스트 3버튼
- 승인된 키워드 → T3 풀 자동 편입
- **만장일치 성립**

### Cycle 8: Phase 분리 확정
- Phase 2: 적응적 샘플링 + 시즌 캘린더 + 급등 감지 + 뉴스 시그널 + 승인 UX
- Phase 3: LLM 예측, 커뮤니티 RSS, 자동 편입, 경쟁 역분석
- 배제: API 복수 운용, Blog→DataLab 대체, 실시간 스트리밍
- **만장일치 성립**

---

## Cycle 9~10 (만장일치)

### Cycle 9: 로키 DA 최종 검증
1. "배치 5개 묶기 미검증" → Plan B 즉시 전환 가능. 수용
2. "급등 200% 임계값 계절 오탐" → 시즌 캘린더 기간 300% 자동 상향. 수용
3. "뉴스 후보 쌓이기만 하면?" → 주 1회 알림 + 30일 자동 아카이브 + 뱃지. 수용

### Cycle 10: 9인 전원 만장일치

---

## 최종 합의 사항 (10사이클 확정)

1. **적응적 샘플링**: T1(50개/매일) + T2(100개/3일) + T3(150개/7일), 배치 5개 묶기로 일 22호출
2. **급등 감지**: 전일 대비 200% 임계값 (시즌 기간 300% 상향)
3. **뉴스 키워드 파이프라인**: Mecab + 사전 매칭 + 인접어 → 블랙리스트 → SearchAd 검증 → keyword_candidates 테이블 → 수동 승인 → T3 편입
4. **후보 큐 관리**: 주 1회 미처리 알림, 30일 자동 아카이브, 대시보드 뱃지
5. **시즌 캘린더**: JSON 정적 데이터, 부스트 기간 임계값 연동
6. **Phase 2 범위**: 적응적 샘플링 + 시즌 캘린더 + 급등 감지 + 뉴스 시그널 + 승인 UX
7. **Phase 3**: LLM 예측, 커뮤니티 RSS, 자동 편입
8. **배제**: API 복수 운용, Blog→DataLab 대체, 실시간 스트리밍
9. **아키텍처**: Supabase 중심, Cron 배치, 대시보드 통합
10. **9인 만장일치 확정**

---

---

## Cycle 11~13 (추가 — API 2개 운용 반영 재설계)

### 변경 트리거
제이회장님 결정: 2인 각각 1앱 등록 → DataLab 2,000회/일 확보

### Cycle 11: 아키텍처 재설계 (발산)
- 적응적 샘플링 불필요해짐 → 전수 매일 vs 하이브리드 논의
- 아폴론: 보험 키워드 2,815개 + 버퍼 20% = **3,500개가 데이터 기반 적정선**
- 로키 DA: 약관 리스크 완화 필요(앱 용도 분리), 5,000개는 과잉(DB 비용)
- 아틀라스: 3,000개 전수 매일 = 연 220MB, 압축 후 60MB → Supabase 무료 내 안전

### Cycle 12: 수렴
- 풀 크기: **3,500개** (코어 3,000 + 탐색 500)
- 수집: **하이브리드** (코어 매일 전수 600회 + 탐색 주 2회 100회 = 일 700회, 여유 1,300회)
- 키 관리: **Primary/Standby** (키1 상시, 키2 대기. 3단계 Degradation)
- DB 압축: 90일 이전 raw → weekly_summary, 상시 70MB

### Cycle 13: 만장일치
6인 전원 4개 항목 모두 찬성

### 최종 합의 사항 (13사이클 통합)

1. **키워드 풀: 3,500개** (코어 3,000 + 탐색 500)
2. **수집: 하이브리드** (코어 매일 전수 + 탐색 주 2회)
3. **API: Primary/Standby** (키1 상시, 키2 대기, 3단계 Degradation)
4. **급등 감지: 200%** (시즌 기간 300%)
5. **뉴스 키워드: Mecab + 사전 매칭 → 수동 승인** → T3 편입
6. **시즌 캘린더 부스트** (JSON + 부스트 로직)
7. **코어/탐색 재분류: 매월 1일** (90일간 100회 이상 유지 기준)
8. **DB 압축: 매분기** (raw → weekly_summary)
9. **약관 리스크 완화**: 앱 용도 분리 필수
10. **Phase 2 범위**: 코어/탐색 이원 수집 + 키 관리 + 급등 감지 + 뉴스 시그널 + 시즌 캘린더 + 승인 UX + 데이터 압축

---

## Cycle 14-15 (추가 — 실행 스펙 구체화)

### Cycle 14: 실행 스펙 (Sequential)

**핵심 결정 사항:**

1. **풀 확장 방법**: 기존 2,000개 코어 편입 + SearchAd 하한 50으로 확장 + 도메인 필터
2. **코어/탐색 분류**: CV 기준 제거(로키 DA). 2조건만: 월검색량>=100 + 도메인>=0.7
3. **뉴스 추출**: Mecab 불필요(다빈치). 정규식+도메인사전(500개)으로 Phase 1 시작. Phase 2에서 Kiwi 검토
4. **시즌 캘린더**: 6개 시즌 JSON, overlap_strategy=max_boost
5. **크론**: 8개, 의존성 순서 확정 (시즌01→코어02→탐색03→급등03:30→뉴스08,20)
6. **API 환경변수**: _STANDBY 접미사, FAILOVER_THRESHOLD=3
7. **사용자 분류**: 코어/탐색 미노출. 안정/급상승/신규 3분류
8. **급등 알림**: Telegram(즉시) + 대시보드(상세) 이중 채널
9. **DB**: 4테이블 추가 (keyword_pool, news_keyword_candidates, surge_events, keyword_stats_monthly)
10. **비관습적 대안 채택**: SearchAd 재귀 확장(역방향 디스커버리) → Phase 2 이후

### Cycle 15: 만장일치 + Temporal Interrogation

**6인 전원 만장일치** (4개 안건 모두 찬성)

**Temporal Interrogation 핵심:**
- HOUR 1: 4테이블 DDL + season_calendar.json + 기존 2,000개 마이그레이션
- HOUR 2-3: 배치 수집 60초/배치, 급등 기준선=직전 4주 같은 요일 평균, 페일오버 3회+30분 복귀
- HOUR 4-5: keyword_stats↔keyword_pool 이중관리 해소, 기존 크론 교체
- HOUR 6+: 경계값 테스트, 인위 급등 INSERT→알림 확인, 90일 압축 검증

### Phase 2 구현 순서 (확정)
1. DB 4테이블 + 기존 2,000개 마이그레이션
2. 코어/탐색 분류 + SearchAd 확장 수집
3. 급등 감지 + surge_events
4. [통합 테스트 게이트]
5. 뉴스 키워드 파이프라인 (정규식+도메인사전)
6. 시즌 캘린더 + 부스트
7. 크론 8개 일괄 등록
8. 대시보드 "오늘 뜨는 키워드" UI
9. Telegram 급등 알림
10. 90일 압축 + 모니터링

---

## Cycle 16-17 (추가 — DA TOP 5 리스크 해결)

### Cycle 16: 5개 리스크 해결안

**리스크 1 해결**: SearchAd API 일일 한도 미검증
→ Standby 키로 실측 스크립트 1회 실행. SearchAd는 공식 일일 한도 없음(rate limit만). DataLab 배치 5개 묶기 실측 완료(코드에서 확인). Phase 1은 월 30콜만 사용하므로 무영향.

**리스크 2 해결**: 자동 재분류 상한선 부재
→ 코어 3,000 / 탐색 500 / 총 3,500 **하드캡** + overflow_strategy=evict_lowest_score + **핀 기능(상한 100개)** + 강등 grace period 90일

**리스크 3 해결**: SearchAd 단일 의존
→ **3단계 Degradation 공식화**: NORMAL(전체) → LEVEL_1(DataLab+Blog, 검색량 스태일) → LEVEL_2(Blog만) → LEVEL_3(캐시만). 기존 데이터로 최소 30일 운영 가능. 네이버 API 전면 폐지 확률 극히 낮음.

**리스크 4 해결**: 크론 체인 의존성
→ **래퍼 스크립트** (run_trend_pipeline.sh) — 크론 5개 → 2개로 축소. flock 이중실행 방지 + 선행 실패 시 후속 자동 스킵. systemd 불필요.

**리스크 5 해결**: 뉴스 키워드 수동 승인 병목
→ **opt-out 모델** (수동 승인 → 자동 편입 + 사후 거부). 블랙리스트 2패턴 추가(살인/자살/..., 파산/횡령/...). 주당 자동 편입 상한 10개. 탐색 풀 전용. 주간 다이제스트 알림.

### Cycle 17: 만장일치
5인 전원 5개 해결안 모두 찬성.

### 기존 합의 수정 3건 + 신규 3건
- 수정: 뉴스 키워드 수동→opt-out, 크론→래퍼 스크립트, 후보 알림→다이제스트
- 신규: is_pinned 컬럼, 3단계 Degradation 정의, BLOCKLIST 2패턴 추가

## 최종 합의 사항 (17사이클 통합)

1. 키워드 풀 3,500개 (코어 3,000 + 탐색 500) + 하드캡 + 핀 100개
2. 하이브리드 수집 (코어 매일 + 탐색 주2)
3. API Primary/Standby + 3단계 Degradation
4. 급등 감지 200% (시즌 300%), 기준선=직전 4주 같은 요일 평균
5. 뉴스 키워드 opt-out 자동 승인 (주 10개 상한, 탐색 전용)
6. 시즌 캘린더 6개 시즌 JSON
7. 재분류 매월 1일 + 핀 면제 + grace period 90일
8. DB 90일 압축
9. 크론 래퍼 스크립트 (5→2 크론)
10. SearchAd 실측 1회 (Standby 키)
11. BLOCKLIST 강화 (선정적/범죄 2패턴 추가)
12. Phase 2 구현 시 반영 변경사항 8개

## 다음 단계
- 3문서 업데이트
- Phase 2 태스크 파일 작성 → 팀 위임