---
task_id: task-1964
type: context
scope: task
created: 2026-04-19
updated: 2026-04-19
status: completed
---

# 맥락 노트: task-1964

**task**: task-1964

---

## 결정 근거

### 3 Step Why

1st Why: "왜 이 설계가 필요한가?"
→ 보험 설계사가 매번 긴 대화를 처음부터 읽어야 현재 상태를 파악 — AI 자동 요약으로 인지 부하 최소화

2nd Why: "왜 MVP 단순 접근이 최선인가?"
→ 설계 문서의 Phase 1 MVP 정의. 빠른 검증이 목적. Celery/Redis 등 인프라는 Phase 2에서 도입.

3rd Why: "왜 동기 요약 생성이 비동기 큐보다 나은가?"
→ MVP에서는 설계사가 수동 클릭 시점에만 요약 생성. 동기 처리로 충분하며, 비동기 큐 인프라 복잡도를 낮춤.

### agent_id FK 패턴
- 기존 conversations 테이블에서 agent_id는 FK 없이 UUID로 선언 (auth.users와 RLS로 접근 제어)
- 동일 패턴을 conversation_summaries에도 적용

### sender_type vs role
- conversation_messages 테이블의 실제 컬럼명은 `sender_type` ("agent"|"customer")
- 설계 문서의 `role` 표기와 다름 → sender_type으로 통일

### structured 컬럼명
- 설계 문서의 `structured` JSONB 컬럼명 그대로 사용 (structured_data → structured)

## 참조 자료

- 설계 문서: `memory/research/insuro-chat-summary-design.md`
- 기존 conversations migration: `supabase/migrations/20260308182738_92f55a9c-b1de-46c4-a9e5-aab796d1e693.sql`
- customer_activities migration: `supabase/migrations/20260309_phase_j_timeline.sql`

## 주의사항

- AI 직접 호출 금지 — anu_provider.generate() CLI 기반 호출만 사용
- premiumOnly 미완성 디자인 절대 건드리지 말 것
- 벡터 검색 제외 — 키워드 검색(ILIKE)만 구현
- trigger 컬럼을 migration에 추가 (설계 문서에는 없었으나 API에서 필요)