설계: 상태관리·DI 도입 검토 — setState 전면 의존 탈피

[seizeh]

현황

38k LOC 를 순수 setState(51개 파일) + static 싱글턴 서비스 ~25개로 운영. DI 부재로 테스트가 http 계층 우회(FakeSupabase)로만 가능 — 예: AuthService.login 성공 경로는 Firebase/Realtime 싱글턴 직접 호출 때문에 테스트 불가(PR #148 참고).

검토할 것

• 후보: Riverpod / provider / 자체 ChangeNotifier 계층 (모션 시스템과의 궁합 포함)
• 싱글턴 서비스의 생성자 주입 전환 순서(테스트 임팩트 큰 auth·push·realtime 우선)
• God Widget 분해(리팩터: 1,000줄+ 화면(God Widget) 분해 — 위젯 추출·책임 분리 #155)와 같은 방향으로 진행

완료 기준

• 결정 기록(ADR) 작성 → 신규 화면부터 적용 → 기존 화면은 분해 시 전환

[seizeh]

결정 기록(PR #161): 프레임워크 없이 ChangeNotifier 상태 홀더로 진행 — 근거·규칙은 docs/architecture-state.md. Riverpod 등 도입 여부는 화면 분해가 진척돼 상태 경계가 드러난 뒤 이 이슈에서 재평가.