---
task_id: task-2252
type: context
scope: task
created: 2026-04-27
updated: 2026-04-27
status: completed
---

# 맥락 노트: task-2252

**task**: task-2252

---

## 결정 근거

### 3 Step Why 자문

**1st Why: "왜 이 설계가 필요한가?"**
→ 증권분석 결과가 현재 user_id로만 관리되어 CRM 고객과 연결 불가. 동일 고객의 여러 분석을 통합 조회할 수 없음.

**2nd Why: "왜 customer_id FK + 임시 등록이 최선인가?"**
→ 기존 CRM customers 테이블을 그대로 활용. temporary 태그로 데이터 유실 없이 점진적 고객 관리 가능. 별도 status 컬럼 대신 tags 배열의 'temporary' 활용 — 기존 스키마 변경 최소화.

**3rd Why: "왜 이것이 다른 대안보다 나은가?"**
→ 대안1(별도 테이블): 스키마 복잡도 증가, 조인 필요. 대안2(이름 기반 매칭만): 동명이인 문제, 정합성 미보장. FK 방식은 DB 레벨 정합성 + 기존 테이블 재활용 + CRM에서 바로 조회 가능.

### customer_stage 대신 tags 사용 결정
- customers 테이블의 stage 필드는 enum 타입(customer_stage)으로 'temporary' 값이 없음
- enum 변경은 마이그레이션 리스크가 높으므로, tags 배열에 'temporary' 추가로 대체
- CRM에서 필터링 가능 + 나중에 정식 전환 시 태그 제거만 하면 됨

### Codex 사전 검증 대응
- Codex: pass=false, risks=6 → 모든 리스크가 이번 task에서 해결 대상
- critical: customer_id FK 미존재 → 마이그레이션으로 해결
- high: 고객 검색 UI 미존재 → PolicyAnalysis에 검색/선택 추가
- high: 임시 등록 플로우 미존재 → 모달 + API 추가
- medium: 이력 탭 미존재 → CrmCustomerDetail에 추가

## 참조 자료

- 작업 지시서: `/home/jay/workspace/memory/tasks/task-2252.md`
- customers 스키마: `supabase/combined-migration.sql:911-932`
- 기존 증권분석 API: `server/main.py:4707-4901`

## 주의사항

- policy_analyses 테이블은 Supabase에서 직접 생성됨 (combined-migration에 미포함)
- customer_stage enum에 'temporary' 없음 → tags 배열로 우회
- Pyright 진단 경고(line 908, 920, 922)는 기존 코드 이슈 (이번 작업 범위 밖)