---
task_id: task-1983
type: context
scope: task
created: 2026-04-20
updated: 2026-04-20
status: completed
---

# 맥락 노트: task-1983

**task**: task-1983

---

## 결정 근거

### 이전 task에서 완료된 항목 스킵
- task-1969에서 Phase A(브랜치 머지) + Phase B 대부분(B-1,4,5,7) + Phase C(C-8,10,11,12) + Phase D(C6) 수정 완료
- task-1973에서 B-2(subprocess.run → asyncio) 전환 완료
- 잔여 3건만 수정하여 불필요한 중복 작업 방지

### B-3 _keyword_jobs: Supabase 직접 이관 (Redis 미사용)
- InsuRo는 Supabase + PostgREST 스택이므로 Redis 추가 인프라 불필요
- keyword_jobs 테이블 + status 컬럼으로 job lifecycle 관리
- Supabase SDK의 upsert/select로 충분한 성능 (분석 job은 저빈도)

### B-6 랭킹: Supabase RPC 사용
- PostgREST는 GROUP BY를 직접 지원하지 않으므로 RPC(SQL function) 사용
- Supabase RPC를 통해 서버사이드 SQL 집계 (GROUP BY user_id + SUM(points) + ORDER BY + LIMIT)
- Python-side 집계를 제거하여 네트워크 전송량 및 메모리 사용 절감

### C-9 Settings.tsx: as any → 타입 정의
- Supabase에서 생성된 Database 타입을 활용하여 payload 타입 지정
- `Record<string, unknown>` + 필요 필드만 명시적 캐스팅

## 3 Step Why 자문

### 1st Why: "왜 이 설계가 필요한가?"
A: 전수조사와 Gemini PR 리뷰에서 적발된 코드 품질 문제를 해결하여 프로덕션 안정성을 확보해야 함. 특히 _keyword_jobs 인메모리 관리는 서버 재시작 시 데이터 유실, Python 합산은 데이터 증가 시 성능 저하 위험.

### 2nd Why: "왜 A가 최선의 접근인가?"
B: 기존 인프라(Supabase)를 활용하므로 추가 의존성 없이 데이터 영속성 + 쿼리 최적화를 달성할 수 있음. Redis 같은 새 인프라 도입은 운영 복잡도를 높이고 InsuRo MVP 단계에 불필요.

### 3rd Why: "왜 B가 다른 대안보다 나은가?"
C: 대안1(Redis) → 인프라 추가 비용/관리. 대안2(파일 기반) → crash recovery 어려움. 대안3(현상 유지) → Gemini/전수조사 적발 항목 미해결로 기술부채 누적. Supabase 이관은 이미 사용 중인 스택이므로 학습 비용 0, 배포 변경 최소.

## 참조 자료

- 전수조사 보고서: `memory/reports/task-1967+1.md`
- Gemini 원인 분석: `memory/reports/task-1968.md`
- task-1969 보고서 (이전 수정): `memory/reports/task-1969.md`
- task-1973 보고서 (subprocess 전환): `memory/reports/task-1973.md`

## 주의사항

- premiumOnly 미완성 디자인 절대 건드리지 말 것
- API 직접 호출 금지 — AI 호출은 CLI로만
- 기존 테스트 회귀 금지
- Supabase migration은 별도 파일로 관리 (SQL 파일 생성)