728x90 SMALL PulseBoard/Profile7 프로필 온보딩 로직 설계하기: ViewModel 책임 분리와 검증 로직의 경계 프로필 온보딩 ViewModel 설계 점검 기록소셜 로그인을 구현한 뒤, 다음으로 마주한 문제는“사용자 프로필을 언제, 어떻게 작성하게 할 것인가”였다. 이 글은 Firebase 기반 iOS 앱에서프로필 온보딩을 담당하는 ViewModel을 설계하며 고민했던 로직과,그 로직을 역할과 책임 관점에서 점검하며 정리한 기록이다. 1. 처음에 생각했던 프로필 온보딩 로직처음 설계한 흐름은 다음과 같았다.사용자가 소셜 로그인을 완료한다.HomeViewController로 이동한다.이 시점에 Firestore에 사용자 프로필이 존재하는지 확인한다.프로필이 없다면,UISheetPresentationController (detent: .medium) 방식으로ProfileViewController를 표시한다.사용자는 다.. 2026. 1. 6. FirebaseProfileImageUploader 설계 — 프로필 이미지를 왜 분리해야 하는가 사용자 프로필을 구현할 때 가장 흔한 실수 중 하나는프로필 이미지 업로드 로직을 Firestore 사용자 저장 로직과 섞어버리는 것이다. 이 글에서는 Firebase를 사용하는 iOS 앱에서프로필 이미지 업로드를 왜 별도의 계층으로 분리했는지,그리고 그 결과물인 ProfileImageUploading 프로토콜과FirebaseProfileImageUploader 구현체를 어떻게 설계했는지를 정리한다. 1. 문제 정의: 프로필 데이터에는 두 종류가 있다사용자 프로필을 구성하는 데이터는 크게 두 가지로 나뉜다.1️⃣ 구조화된 데이터사용자 이름프로필 이미지 경로기타 메타 정보👉 Firestore에 저장 2️⃣ 바이너리 데이터프로필 이미지 파일 (UIImage)👉 Firebase Storage에 저장 이 둘을.. 2026. 1. 5. FirestoreUserRepository 설계 — 사용자 프로필을 안전하게 관리하는 방법 소셜 로그인(Google / Apple / Kakao / Naver)을 Firebase Authentication으로 구현한 뒤,다음으로 해결해야 할 문제는 “사용자 프로필을 어디서, 어떻게 관리할 것인가”였다. 이 글에서는 Firebase Firestore를 사용하는 iOS 앱에서FirestoreUserRepository를 왜 도입했고, 어떤 기준으로 설계했는지를 정리한다. 특히 이번 단계에서 반드시 기억해야 할 핵심 포인트들을 함께 다룬다. 1. 왜 FirestoreUserRepository가 필요한가?가장 단순한 구현은 ViewModel에서 Firestore를 직접 호출하는 것이다.Firestore.firestore() .collection("users") .document(uid) .. 2026. 1. 4. UserRepository 설계 — Firebase 프로필 데이터를 어떻게 다룰 것인가 소셜 로그인(Google / Apple / Kakao / Naver)을 Firebase Authentication으로 구현한 뒤,다음으로 마주한 문제는 “사용자 프로필 데이터를 어떻게 관리할 것인가”였다. 이 글에서는 Firebase Firestore를 사용하는 환경에서사용자 프로필을 다루기 위한 UserRepository 프로토콜을 왜, 어떻게 설계했는지를 정리한다.특히,Repository를 왜 도입했는지async/await를 선택한 이유completion handler 방식과의 차이로그아웃 / 회원 탈퇴 시 캐시 처리 설계를 중심으로 설명한다. 1. 왜 UserRepository가 필요한가?가장 단순한 방식은 ViewModel에서 Firestore를 직접 호출하는 것이다.Firestore.firest.. 2026. 1. 3. Firebase 기반 사용자 프로필 관리 전략 — 서버 단일 소스 + 세션 캐시 소셜 로그인(Google, Apple, Kakao, Naver)을 Firebase Authentication으로 구현한 뒤,다음으로 반드시 고민하게 되는 주제가 있다.“사용자 프로필 정보는 어디에, 어떻게 저장하고 관리해야 할까?” 이 글에서는 Firebase Firestore를 단일 소스(Single Source of Truth)로 두고,앱에서는 세션 단위 메모리 캐시만 사용하는 프로필 관리 전략을 정리한다. 1. 문제 상황 정리현재 앱의 구조는 다음과 같다.인증(Auth): Firebase Authentication사용자 프로필: Firestore에 저장프로필 이미지: Firebase Storage사용자는 로그인 후 프로필을 작성하고,그 정보는 Firestore에 저장된다.여기서 자연스럽게 떠오르는 .. 2026. 1. 3. PulseUser 모델 설계 — Firebase Auth 이후 사용자 프로필을 어떻게 정의할 것인가 소셜 로그인(Google, Apple, Kakao, Naver)을 Firebase Authentication 기반으로 구현한 뒤,다음 단계로 반드시 마주하게 되는 질문이 있다.“로그인이 끝난 사용자를, 서비스에서는 어떤 모델로 표현해야 할까?” Firebase Auth에는 이미 User 객체가 존재한다.그렇다면 이 User를 그대로 써도 되는 걸까? 이 글에서는 Firebase Auth의 User와 분리된 서비스 레벨 사용자 모델 PulseUser를 왜, 어떻게 설계했는지를 정리한다. 1. Auth User ≠ 서비스 User가장 먼저 명확히 해야 할 개념은 이거다.Firebase Authentication의 User는 ‘인증 객체’이지,서비스에서 사용하는 사용자 프로필이 아니다. Firebase Aut.. 2026. 1. 3. 소셜 로그인 이후 프로필 작성 온보딩 설계 (Firebase Auth + Firestore + Storage) 소셜 로그인(Google / Apple / Kakao / Naver)을 모두 구현한 뒤,다음으로 고민해야 할 것은 **“로그인 이후 사용자를 어떻게 서비스에 진입시킬 것인가”**이다. 단순히 로그인에 성공했다고 해서 바로 서비스를 사용하게 만드는 것이 항상 최선은 아니다.대부분의 서비스는 로그인 이후 최소한의 사용자 프로필 정보를 요구한다. 이 글에서는 Firebase Auth 기반 소셜 로그인 이후, 최초 1회만 프로필 작성 화면을 노출하는 온보딩 로직을 어떻게 설계했는지 정리한다. 1. 문제 정의현재 앱의 상태는 다음과 같다.Firebase Auth로 소셜 로그인 완료 가능uid 발급 및 인증 상태 관리 가능아직 서비스 레벨의 “회원 프로필”은 존재하지 않음이 상태에서 발생하는 질문은 하나다.“로그인.. 2026. 1. 1. 이전 1 다음 728x90 LIST