이번 Flutter Firebase 구글, 카카오 로그인 시스템 개선 과정에서 발생했던 핵심 문제들, 그에 대한 구체적인 원인과 해결, 그리고 최종 구조의 장점까지 포괄적으로 정리한 트러블슈팅 리포트입니다. 각 이슈는 서로 얽혀 있었기 때문에 문제 흐름 중심으로 서술합니다.
LoginPage → MainPage(user) → SettingsPage(user) 식으로 UserModel을 전체 페이지에 직접 전달함UserModel이 여전히 남아 있어 프로필 수정 시 다른 계정 정보로 덮어씌워지는 심각한 문제 발생UserModel 전달 방식 → userIdProvider 중심 참조 방식으로 전환userIdProvider의 상태를 갱신 (ref.read(userIdProvider.notifier).state = userId)ref.watch(userIdProvider)를 통해 항상 현재 로그인된 계정 ID만 참조UserModel은 Firestore의 해당 userId 문서를 StreamProvider로 구독하여 실시간으로 사용userProfileProvider가 이전에는 AsyncNotifierProviderFamily 기반이어서, 한 번 불러오면 갱신되지 않음refresh()를 명시적으로 호출하지 않는 한, 프로필 페이지에 이전 상태 그대로 유지userProfileProvider를 StreamProvider.family<UserModel?, String> 구조로 완전히 재작성.doc(userId).snapshots()를 통해 해당 문서의 실시간 변화를 감지하여 반영UserProfilePage, SettingsPage 등은 ref.watch(userProfileProvider(userId))를 사용user 전달 구조가 복잡하고 오류 유발UserModel user를 로그인 후부터 모든 페이지에 명시적으로 전달user 객체가 최신 상태로 갱신되지 않아서 정보 불일치 발생UserModel 전달을 완전히 제거ref.watch(userIdProvider)와 userProfileProvider(userId)를 통해 동적 접근MainPage, SettingsPage, UserProfilePage 모두 전달인자 없이 구성됨loginWithKakaoAccount() 또는 loginWithKakaoTalk() 호출 시 항상 발생getCurrentUserId() 값을 체크하여, 없으면 무조건 로그인 페이지로 이동SharedPreferences에 저장된 로그인 정보도 로그아웃 시 clearLoginInfo()로 완전 삭제set(newUser.toJson(), merge: true)로 저장userIdProvider 상태를 설정하고, 그 ID에 해당하는 문서만 생성 또는 불러오기if (!userDoc.exists) 조건 하에서만 새 문서를 생성| 항목 | 이전 방식 | 개선된 방식 |
|---|---|---|
| 사용자 정보 전달 | UserModel user를 매 페이지에 전달 | 전역 userIdProvider, userProfileProvider로 전환 |
| 프로필 동기화 | AsyncProvider + 수동 refresh 필요 | StreamProvider 기반 실시간 반영 |
| 계정 전환 | 이전 정보가 남아 정보 덮어쓰기 발생 | userIdProvider 상태로 강제 동기화 |
| 로그아웃 후 자동 로그인 | 알림창 계속 뜸 | 자동 로그인 제거 + SharedPrefs 정리 |
| 설정 페이지 구조 | user 전달 필요 | userIdProvider 참조로 통일 |