# Agent 미팅: InsuRo 전체 심층 점검

**날짜**: 2026-03-14
**소집 이유**: InsuRo 코드베이스 전체 감사 후 개선점, 추가개발, 싱크 불일치 심층 논의
**참여 페르소나**: 헤르메스(1팀장), 오딘(2팀장), 아테나(UX), 프레이야(프론트), 아르고스(테스터), 로키(레드팀/DA)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 3

---

## Cycle 1 — Independent 의견 수집

### 아누 분석
InsuRo 전체 감사 결과 핵심 발견: 42개 페이지 중 11개 미구현 라우트(404), Dashboard/Sidebar 하드코드 60+항목, any 타입 13개, console.log 13개, Threads 카드뉴스/영상 미구현, /chat/:token 보안 우려, 금소법 감사 로그 부재.
근거: `memory/reports/insuro-audit-2026-03-14.md`

### 페르소나 의견

**헤르메스(1팀장)**: 미구현 라우트 → 4개 즉시 삭제(patent/npv/ai-onestop/ai-automation), 5개 Coming Soon(health/analysis/consult-card/ai-guide/report), 2개 Phase 2 개발(keyword-rank/adjust). 하드코드 → `navigation.ts` 정적 config 파일이 정답(DB는 과잉). 태스크 3개로 분해.

**오딘(2팀장)**: any 타입 → 점진적 제거(파일 단위 strict opt-in). console.log → vite-plugin-remove-console + logger wrapper(`src/lib/logger.ts`). Sentry는 나중. Analytics/Contents → 네이밍 정리 후 분리 유지. **비관습적 대안**: routes.ts 단일소스 추출 → 메뉴-라우트 불일치 구조적 불가능.

**아테나(UX)**: 404는 신뢰 파괴. Coming Soon > 메뉴 숨김(로드맵 가시성). premiumOnly + 개발예정 뱃지 조합 최선. 16개 섹션 60+ 항목은 Miller의 법칙 3배 초과 → 3개 허브로 압축(콘텐츠 생성/고객 관리/분석·리포트). **DA 관점**: 11개 전부 Coming Soon은 "베이퍼웨어" 인상 → 핵심 5개만 전면 노출.

**프레이야(프론트)**: menuStructure.ts는 `{ id, label, icon, href, requiredRole }[]` 구조로 충분. 카드뉴스 먼저(ImageGeneratorPanel 재활용 + Pillow 파이프라인 존재), 영상(Remotion)은 후순위. 미사용 shadcn 4개는 삭제보다 유지 권장(번들 미포함).

**아르고스(테스터)**: 가장 취약 영역: 라우트-사이드바 싱크(E2E 0건). 조용한 catch → 실패가 성공처럼 보임. **핵심 제안**: 라우트 일관성 자동 테스트 1개 > 단위 테스트 100개. sidebar-routes.test.ts 작성 가능.

**로키(레드팀)**: CRITICAL: /chat/:token 토큰 예측 → 고객 채팅 노출. HIGH: RLS 정책 우회(anon key 직접 PostgREST), FastAPI PDF 무인증. MEDIUM: 404 라우트 정보 노출, console.log 민감 정보. **비관습적**: 금소법 감사 로그 부재가 해킹보다 즉각적 위협.

### Devil's Advocate (로키)
**지정**: 로키 (레드팀)
1. **실패 시나리오**: Coming Soon 5개가 영구 방치 → 기술부채 누적
2. **후회 이유**: 보안 "나중"으로 미룸 → 금소법 규제 리스크 즉각적
3. **더 단순한 대안**: 미구현 라우트 전부 삭제 (Coming Soon 자체가 기술부채)

**반박**: Coming Soon은 사용자 기대 관리에 유효(아테나). 단, 기한 설정 필수.
**판정**: 부분 수용 — 기한부 Coming Soon + patent/npv/ai-onestop/ai-automation 삭제

### 비관습적 대안
**제시자**: 로키
**대안**: 기능 개발 전면 동결 → 보안 3종(인증/RLS/감사로그) 선처리 후 재개
1. 지지 논거: 금소법 위반 시 서비스 전체 중단 가능
2. 반론: 출시 지연으로 시장 기회 손실
3. 이상적 시나리오: 실제 고객 데이터 다루기 전 단계
4. 노력: 중간
5. 리스크: 미처리 시 치명적
**판정**: 전면 동결 기각, 보안을 Phase 우선 배치로 타협

### 합의/결론
- 4개 삭제, 5개 기한부 Coming Soon, 2개 즉시 개발
- navigation.ts 정적 config 파일 생성
- 보안을 Phase 우선 배치
- 카드뉴스 먼저, 영상 후순위

### 미해결 항목
- Phase 구체 순서 확정
- Coming Soon 기한 설정
- 메뉴 재구조화 시점

---

## Cycle 2 — Sequential 심화 (미해결 쟁점)

### 아누 분석
Cycle 1의 미해결 3건: (1) 보안 3종 구체 설계, (2) routes.ts 설계, (3) Phase 실행 순서

### 페르소나 의견

**오딘(2팀장)**: 감사 로그 → `audit_logs` 테이블 + DB Function trigger(pg_audit보다 정밀). RLS 검증 → pytest + supabase-py 역할별 CRUD 시나리오. FastAPI JWT → python-jose + Depends(verify_token). routes.ts → `RouteConfig` 타입({path, label, icon, element, requiredRole}) + lazy import.

**헤르메스(1팀장)**: Phase 1(routes.ts+라우트정리) → Phase 2(외부화+코드품질 병렬) → Phase 3(보안 3종). routes.ts가 URL 상수 기준이므로 외부화보다 선행. 보안은 독립 레이어라 마지막 집중.

### Devil's Advocate (로키)
**지정**: 로키
1. **실패 시나리오**: Phase 1에서 삭제+Coming Soon과 Phase 3 메뉴 재구조화가 같은 라우트를 건드리면 병합 충돌
2. **후회 이유**: 메뉴 재구조화를 Phase 1에 묶으면 범위 2배. routes.ts가 메뉴 구조까지 책임지면 수정 범위 과대
3. **더 단순한 대안**: 메뉴 재구조화를 Phase 1에서 빼고 별도 1시간 작업으로 처리

**반박**: routes.ts는 라우트 정의만 담당, 메뉴 구조는 별도 config → 책임 분리
**판정**: 수용 — 메뉴 재구조화 Phase 1에서 분리

### 합의/결론
- Phase 1: routes.ts + 라우트 정리만 (메뉴 재구조화 분리)
- 보안 구체 설계 확정 (audit_logs trigger + RLS pytest + FastAPI JWT)
- routes.ts RouteConfig 타입 정의 확정

### 미해결 항목
- Phase 순서에서 보안 위치 (먼저 vs 나중)
- 테스트 전략 구체화

---

## Cycle 3 — 최종 합의

### 아누 분석
남은 쟁점: Phase 순서 최종 확정, 테스트 전략, 보안 시점

### 페르소나 의견

**헤르메스(1팀장)**: Phase 1(routes.ts+라우트정리, Lv.1, 1팀) → Phase 2(보안3종, Lv.2) → Phase 3(메뉴재구조화, Lv.2) → Phase 4(Threads 카드뉴스, 별도). Coming Soon 기한: 3개월 내 최소 2개 착수 권고.

**아르고스(테스터)**: P1후 Playwright 404확인+sidebar href전수검사. P2후 RLS침투(타user_id조회403확인)+JWT변조+audit_logs삽입확인. P3후 Playwright 메뉴전수클릭. 자동화 우선순위: P2 RLS > P1 404 > P3 리그레션.

### Devil's Advocate (로키)
**지정**: 로키
1. **실패 시나리오**: Phase 1과 Phase 3이 같은 라우트 건드리면 병합 지옥 (순차 강제인데 팀이 경계 무시하면 덮어씌움)
2. **후회 이유**: 보안을 Phase 1 이후에 하면 삭제된 라우트 4개가 audit_log 흔적 없이 증발. "보안 잠금 후 삭제"가 옳다
3. **더 단순한 대안**: Phase 1+2 병합하여 Phase 수 축소

**반박**: 삭제되는 라우트는 미구현이라 audit_log 대상 아님. Phase 병합은 범위 복잡화.
**판정**: 부분 수용 — Phase 2(보안)를 Phase 1과 **병렬 시작** 가능하게 변경. 병합은 기각.

### 합의/결론
최종 Phase 구조 확정 (아래 "최종 합의 사항" 참조)

---

## 최종 합의 사항

### 1. Phase 구조 확정

**Phase 1** (Lv.1, 1팀)
- routes.ts 단일소스 생성 (RouteConfig 타입)
- 4개 라우트 삭제: patent, npv, ai-onestop, ai-automation (삭제 전 grep 참조 조사 필수)
- 5개 Coming Soon 페이지 생성: health, analysis, consult-card, ai-guide, report
- 2개 즉시 개발: keyword-rank, keyword-adjust
- 테스트: Playwright 404 확인 + sidebar href 전수 검사

**Phase 2** (Lv.2, 1팀+2팀 병렬, Phase 1과 동시 시작 가능)
- **2팀**: 보안 3종 — audit_logs DB Function trigger, RLS pytest 검증, FastAPI JWT Depends
- **1팀**: 하드코드 외부화 — navigation.ts + Dashboard 공지 DB 연동 + 코드 품질(vite-plugin-remove-console, logger wrapper)
- 테스트: RLS 침투 + JWT 변조 + audit_logs 삽입 확인

**Phase 3** (Lv.2, Phase 1+2 완료 후)
- 메뉴 허브 재구조화 (16섹션 → 3허브: 콘텐츠 생성/고객 관리/분석·리포트)
- any 타입 점진적 제거 (신규 파일 strict 강제, 기존 파일 PR 단위)
- Analytics/Contents 라우트 정리 (Analytics.tsx rename + 라우트 분리)
- 테스트: Playwright 메뉴 전수 클릭

**Phase 4** (별도, Phase 3 이후)
- Threads 카드뉴스 모드 개발 (ImageGeneratorPanel 재활용)
- Threads 영상 모드는 후순위 (Remotion 엔진 부담)

### 2. 미구현 라우트 처리

| 라우트 | 처리 | 근거 |
|--------|------|------|
| /tools/patent | 삭제 | 핵심 외 |
| /tools/npv | 삭제 | 핵심 외 |
| /ai-onestop | 삭제 | 기능 정의 불명확, 다른 페이지 흡수 가능 |
| /ai-automation | 삭제 | 향후 개발 시 재추가 |
| /tools/health | Coming Soon | 핵심 워크플로우, 3개월 내 착수 |
| /tools/analysis | Coming Soon | 핵심 워크플로우, 3개월 내 착수 |
| /tools/consult-card | Coming Soon | 유용, 6개월 내 |
| /tools/ai-guide | Coming Soon | 유용, 6개월 내 |
| /tools/report | Coming Soon | 유용, 6개월 내 |
| /tools/keyword-rank | Phase 1 개발 | 단순 폼 구조 |
| /tools/keyword-adjust | Phase 1 개발 | 단순 폼 구조 |

### 3. 보안 우선순위

1. **CRITICAL**: /chat/:token UUID v4 토큰 검증 + TTL 설정
2. **HIGH**: RLS 정책 전수 검증 (pytest + supabase-py)
3. **HIGH**: FastAPI JWT Depends 미들웨어 추가
4. **HIGH**: audit_logs 테이블 + DB Function trigger (금소법 의무)
5. **MEDIUM**: console.log 제거 (정보 노출 방지)

### 4. 코드 품질 로드맵

- 즉시: vite-plugin-remove-console, logger wrapper
- 점진적: any 타입 제거 (파일 단위 strict opt-in)
- 나중: Sentry 도입 (트래픽 증가 후)
- 나중: i18n, E2E 테스트 인프라

### 5. Threads 개발 순서

1. 카드뉴스 먼저 (ImageGeneratorPanel 재활용, Pillow 파이프라인 존재)
2. 영상 후순위 (Remotion 번들 수십MB, Worker 설정 필요)

## 미해결 항목
- Coming Soon 5개의 정확한 착수 일정 (제이회장님 결정 필요)
- /chat/:token 토큰 형식 확인 (UUID v4인지 검증 필요)
- 메뉴 허브 재구조화의 정확한 카테고리 분류 (아테나 에이전트 출력 누락)

## 다음 단계

### 합의 사항 → 3문서 매핑 가이드
- Phase 1~4 실행 계획 → 계획서(plan.md)의 '목표', '범위/포함'
- 삭제 4개 + Coming Soon 5개 결정 근거 → 맥락노트(context-notes.md)
- 보안 우선순위, 코드 품질 로드맵 → 체크리스트(checklist.md)
- 기각된 대안 ("전면 동결", "전부 삭제") → 맥락노트
- 위임: Phase 1(1팀), Phase 2(1팀+2팀 병렬), Phase 3(팀 미정)