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

# 맥락 노트: task-1980

**task**: task-1980

---

## 결정 근거

### 코드 변경 불필요 판단
- 모든 6개 작업 항목이 이미 구현/제거 완료 상태
- .env: 새 Supabase URL/key 이미 설정됨
- lovable 디렉토리: 이미 삭제됨
- AuthForm.tsx: 이미 supabase.auth.signInWithOAuth 사용 중
- package.json: lovable 의존성 없음
- vite.config.ts: componentTagger 없음

### 빌드 에러 해결
- `@dnd-kit/core` 미설치 → npm install로 해결
- 이 에러는 main 브랜치에서도 동일하게 발생하는 기존 이슈 (본 작업 범위 외)

## 3 Step Why

### 1st Why: "왜 이 설계(Lovable→Supabase 전환)가 필요한가?"
A: 외부 의존성(@lovable.dev/cloud-auth-js) 제거로 인증 흐름 간소화, 유지보수성 향상

### 2nd Why: "왜 Supabase 네이티브가 최선인가?"
B: Supabase에 이미 Google OAuth가 설정되어 있고, SDK 내장 signInWithOAuth로 추가 래퍼 불필요

### 3rd Why: "왜 다른 대안(Auth0, Firebase)보다 나은가?"
C: DB/RLS를 이미 Supabase로 운영 중이므로 인증도 동일 생태계 사용이 아키텍처 일관성 최적

→ A-B-C 논리적 일관성 확인: 외부 의존성 제거 → 이미 구축된 Supabase 활용 → 동일 생태계 일관성

## 참조 자료

- 태스크 파일: `/home/jay/workspace/memory/tasks/task-1980.md`
- Supabase client: `/home/jay/projects/InsuRo/src/integrations/supabase/client.ts`

## 주의사항

- AdminAIConfig.tsx의 "lovable" AI provider 옵션은 auth와 무관 — 건드리지 말 것
- AdminCrmConfig.tsx의 "Lovable AI" 텍스트도 동일 — 건드리지 말 것