---
task_id: task-1956
type: context
scope: task
created: 2026-04-19
updated: 2026-04-19
status: in-progress
---

# 맥락 노트: task-1956

**task**: task-1956

---

## 결정 근거

### 3 Step Why 자문

**1st Why: "왜 이 설계가 필요한가?"**
→ A: 인슈로 Phase 0(보안 핫픽스) 완료 후, Phase 1은 기술부채 해소와 기반 안정화가 목표. 타입 불완전(5개 테이블 미정의), CORS 에러, AI 호출 비일관성, 스텁 엔드포인트 등이 사용자 경험과 개발 생산성을 저해함.

**2nd Why: "왜 A가 최선의 접근인가?"**
→ B: 타입 보완(M1)을 먼저 하면 as any 캐스트(M6)가 연쇄적으로 해소되어 전체 타입 안전성 확보. CORS 프록시(M4)는 서버사이드 프록시가 유일한 해법(Naver API가 CORS 허용 안함). AI 통일(M3→H7)은 보안(API키 노출 방지)+비용 관리(CLI 경유 단일 경로)에 필수.

**3rd Why: "왜 B가 다른 대안보다 나은가?"**
→ C: 대안1(프론트에서 CORS proxy 서비스 사용) — 외부 의존성+비용, 거부. 대안2(as any 그대로 두고 기능만 추가) — 타입 에러 누적으로 Phase 2 결제 연동 시 위험 증대, 거부. 대안3(API 직접 호출 유지) — API 키 클라이언트 노출 위험, 태스크 지시서에서 명시적 금지, 거부. 현재 접근이 최소 비용으로 최대 안정성 확보.

### M1: 타입 보완 전략
- 마이그레이션 파일 `20260316130000_token_system_and_ai_models.sql`에서 5개 테이블 스키마 확인
- types.ts의 기존 패턴(Row/Insert/Update 삼중 정의)에 맞춰 추가
- Relationships도 FK 기반으로 정의

### M3: AI 호출 통일
- ai_parser.py는 이미 subprocess CLI 방식 → 유지
- anu_provider.py가 httpx 직접 API 호출 → subprocess CLI로 변환
- `claude -p --model {model}` 패턴 사용

### M4: Naver CORS 프록시
- server/main.py에 `/api/insuro/naver/datalab` 및 `/api/insuro/naver/search` 추가
- JWT 인증 필수 (user_naver_keys에서 키 조회)
- KeywordAnalysis.tsx는 프록시 경유로 변경

### H6: DigitalNamecard CTA
- customer_chat_tokens 테이블 활용하여 공개 채팅 토큰 생성
- 에이전트 프로필에서 토큰 생성 → /chat/:token 으로 이동

## 참조 자료

- 전수조사: `memory/research/insuro-page-audit.md`
- 시스템 체크리스트: `memory/plans/insuro-system/checklist.md`
- 마이그레이션: `supabase/migrations/20260316130000_token_system_and_ai_models.sql`

## 주의사항

- API 직접 호출 금지 — LLM 호출은 CLI만 사용
- premiumOnly 미완성 디자인 절대 건드리지 말 것
- worktree 브랜치에서만 작업 (main 직접 수정 금지)