등원도우미 - 틈틈히 고도화
소개
지난주에 만들었던 등원도우미 를 태블릿에서 아이들 등원시에 써보았습니다.
아이들이 실제 써보니, 너무 좋아해서 게임하는듯 하니 그런지 요즘 등원의 속도가 빨라졌습니다.
엄마가 만들었다고 하니 아이들의 요구사항이 많아서 적극 의견을 수렴하여 소소하게 수정사항 반영하였고, 기기간 동기화가 필요할듯하여 일단 조금씩 고도화를 진행하고 있습니다.
진행 방법
지난번에 아이들의 등원 도우미를 만들어서 타이머 형태로 만든것을 좀더 고도화하고 있습니다.
잠자리 준비 모드도 추가
부모 설정 화면 추가
데이터 동기화
현재는 웹에서 localStorage만 쓰는 형태라서 기기간 동기화가 되지 않아서 질문을 했습니다.
Firebase는 안써보긴했는데, 클로드코드는 일단 Firebase를 추천하는것같아요.
데이터 동기화가 어떤 방식으로 되는지 설명해줘
Read 2 files (ctrl+o to expand)
⏺ 현재 데이터 동기화 구조입니다:
데이터 저장 방식
1차: localStorage (기본, 항상 동작)
- Zustand persist 미들웨어 사용
- useSettingsStore → 설정 (프로필, 태스크, 목표시간 등)
- useStatsStore → 통계 기록 (일간 별점, 소요시간)
- 브라우저/기기에 저장되므로 같은 기기, 같은 브라우저에서만 유지
2차: Firebase Realtime Database (선택, 설정 시 동작)
- 설정 페이지에서 Firebase 정보 (API Key, Database URL, Project ID) 입력 시 활성화
- 설정값은 localStorage에 mrt-firebase-config로 저장
동기화 흐름:
설정/통계 변경 → Zustand store 업데이트 → localStorage 저장 (자동)
→ Firebase에 저장 (설정된 경우)
데이터 경로: mrt/{deviceId}/settings, mrt/{deviceId}/stats
- deviceId는 기기별 고유 ID로, 기기 간 데이터가 분리됨
- 즉 현재는 같은 Firebase DB를 쓰더라도 기기 A와 기기 B의 데이터가 서로 다름
현재 한계
- 단방향 동기화: 로컬 → Firebase로만 저장 (백업 용도)
- 기기 간 공유 안됨: deviceId로 분리되어 있어서 태블릿 A에서 변경해도 태블릿 B에 반영 안됨
- Firebase에서 로컬로 복원하는 기능은 구현되어 있지만 (loadFromFirebase, subscribeToFirebase), 실제로 앱 시작 시 Firebase 데이터를 로컬에
덮어쓰는 로직은 없음
요약
┌───────────────────────┬─────────────────┬────────────────────┐
│ 항목 │ 방식 │ 범위 │
├───────────────────────┼─────────────────┼────────────────────┤
│ 기본 저장 │ localStorage │ 같은 기기/브라우저 │
├───────────────────────┼─────────────────┼────────────────────┤
│ 원격 백업 │ Firebase (선택) │ 기기별 분리 저장 │
├───────────────────────┼─────────────────┼────────────────────┤
│ 기기 간 실시간 동기화 │ 미구현 │ - │
└───────────────────────┴─────────────────┴────────────────────┘
기기 간 동기화가 필요하시면 deviceId를 공유하거나, 가족 단위 공용 경로를 사용하도록 수정할 수 있습니다.
❯ /bkit:pdca 기기간 동기화 보다, login 기능 추가 하는건 어때
⏺ 좋은 아이디어입니다. 이 앱의 상황을 고려하면:
로그인 vs 기기간 동기화 비교
┌─────────────┬───────────────────────────────────────────┬────────────────────────────────────────────────
───┐
│ │ 로그인 (Firebase Auth) │ 기기간 동기화 (현재 구조 개선)
│
├─────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────
───┤
│ 구현 난이도 │ 중간 (Firebase Auth SDK 추가) │ 낮음 (deviceId를 가족 코드로 변경)
│
├─────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────
───┤
│ 사용자 경험 │ 구글/애플 로그인 → 어디서든 내 데이터 │ 가족 코드 입력 → 같은 데이터 공유
│
├─────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────
───┤
│ 데이터 구조 │ mrt/{userId}/settings, mrt/{userId}/stats │ mrt/{familyCode}/settings,
mrt/{familyCode}/stats │
├─────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────
───┤
│ 장점 │ 개인별 데이터 분리, 보안 │ 별도 계정 불필요, 간단
│
├─────────────┼───────────────────────────────────────────┼────────────────────────────────────────────────
───┤
│ 단점 │ 아이가 로그인 못함, 과한 구조 │ 코드 유출 시 데이터 접근 가능
│
└─────────────┴───────────────────────────────────────────┴────────────────────────────────────────────────
───┘
추천
이 앱은 가족 단위로 한 세트의 데이터를 공유하는 구조이므로, 본격적인 로그인보다는 가족 코드(Family Code)
방식이 더 적합합니다:
1. 설정에서 "가족 코드" 생성 (예: happy-bear-1234)
2. 다른 기기에서 같은 코드 입력
3. 같은 Firebase 경로를 공유 → 설정/통계 자동 동기화
Firebase Auth 로그인은 나중에 사용자 수가 늘어나거나, 가족별 데이터 보안이 필요할 때 추가해도 늦지
않습니다.
어떤 방향으로 진행하시겠어요?
1. 가족 코드 방식 (간단, 빠른 구현)
2. Firebase Auth 로그인 (구글/애플, 확장성)
3. 둘 다 (가족 코드 + 선택적 로그인)
─────────────────────────────────────────────────
📊 bkit Feature Usage
─────────────────────────────────────────────────
✅ Used: (컨설팅/상담)
⏭️ Not Used: /pdca plan (사용자 방향 결정 대기)
💡 Recommended: 방향 결정 후 /pdca plan family-sync 또는 /pdca plan user-auth
─────────────────────────────────────────────────
❯ 1
⏺ 가족 코드 방식으로 Plan을 작성하겠습니다.
⏺ Write(docs/01-plan/features/family-sync.plan.md)
⎿ Wrote 129 lines to docs/01-plan/features/family-sync.plan.md
1 # Plan: family-sync (가족 코드 기반 기기간 동기화)
2
3 ## 1. 기능 개요
4
5 현재 deviceId 기반의 단방향 백업을 **가족 코드(Family Code)** 기반 양방향 실시간 동기화로 변경한다.
6 같은 가족 코드를 입력한 모든 기기가 동일한 설정/통계 데이터를 공유한다.
7
8 ## 2. 요구사항
9
10 ### R1. 가족 코드 생성
… +119 lines (ctrl+o to expand)
⏺ Plan 작성 완료. 진행 방향:
핵심 변경: Firebase 경로를 mrt/{deviceId}/ → mrt/families/{familyCode}/로 바꾸고, onValue 구독으로 양방향 실시간 동기화
구현하면 이런 흐름입니다:
1. 기기 A: 설정에서 "가족 코드 만들기" → happy-bear-1234 생성
2. 기기 B: 같은 코드 입력 → 기기 A의 데이터가 자동으로 내려옴
3. 이후 어느 기기에서든 설정/통계 변경 시 상대방에 실시간 반영
바로 Design → 구현으로 넘어갈까요?
─────────────────────────────────────────────────
📊 bkit Feature Usage
─────────────────────────────────────────────────
✅ Used: /pdca plan (family-sync), Write
⏭️ Not Used: /pdca design (사용자 확인 대기)
💡 Recommended: /pdca design family-sync → 구현
─────────────────────────────────────────────────firebase와 superbase 와 차이점이 뭐야? 어떤게 지금 프로젝트에 더 맞을까?
⏺ Firebase vs Supabase 비교
┌───────────────┬────────────────────────┬────────────────────────────────┐
│ │ Firebase Realtime DB │ Supabase │
├───────────────┼────────────────────────┼────────────────────────────────┤
│ DB 타입 │ NoSQL (JSON 트리) │ PostgreSQL (관계형) │
├───────────────┼────────────────────────┼────────────────────────────────┤
│ 실시간 동기화 │ 네이티브 (매우 빠름) │ Realtime 채널 (약간 지연) │
├───────────────┼────────────────────────┼────────────────────────────────┤
│ 설정 난이도 │ 쉬움 │ 쉬움 │
├───────────────┼────────────────────────┼────────────────────────────────┤
│ 무료 티어 │ 1GB 저장, 10GB/월 전송 │ 500MB DB, 5GB 대역폭 │
├───────────────┼────────────────────────┼────────────────────────────────┤
│ 인증 │ Firebase Auth (별도) │ 내장 Auth + Row Level Security │
├───────────────┼────────────────────────┼────────────────────────────────┤
│ SDK 크기 │ 큼 (~100KB+) │ 작음 (~30KB) │
├───────────────┼────────────────────────┼────────────────────────────────┤
│ 오프라인 지원 │ 내장 │ 없음 (별도 구현 필요) │
└───────────────┴────────────────────────┴────────────────────────────────┘
이 프로젝트에는 Firebase가 더 적합
이유:
1. 실시간 동기화가 핵심 — 가족 기기간 설정/타이머 동기화가 목적인데, Firebase Realtime DB는 이게 네이티브 기능. Supabase는 Realtime이 부가 기능이라 약간 불안정
2. 데이터 구조가 단순 — settings, stats 두 개의 JSON 덩어리만 동기화. 관계형 DB가 필요 없음
3. 이미 구현 완료 — firebase.ts, sync.ts가 Firebase SDK 기반으로 작성됨
4. 오프라인 지원 — 태블릿이 Wi-Fi 끊겨도 Firebase는 로컬 캐시로 동작. Supabase는 별도 구현 필요
5. 로그인 불필요 — 가족 코드 방식이라 Auth 기능이 필요 없어서, Supabase의 내장 Auth 장점이 의미 없음
▎ Supabase가 더 나은 경우: 사용자 계정/로그인이 필요하거나, 복잡한 쿼리(통계 분석 등)가 필요할 때
결론: 현재 구조 그대로 Firebase로 진행하는 게 맞습니다. 바꿀 이유가 없어요.
─────────────────────────────────────────────────
📊 bkit Feature Usage
─────────────────────────────────────────────────
✅ Used: PDCA context (do phase - family-sync 기술 선택 검토)
⏭️ Not Used: Agents (기술 비교 질문, 코드 작업 아님)
💡 Recommended: Firebase 설정 진행 → /pdca analyze family-sync
─────────────────────────────────────────────────
❯ 나중에 로그인 붙이고 싶은데?
⏺ 그래도 지금은 Firebase로 진행하는 게 맞아요.
로그인 추가 시나리오
방법 1: Firebase + Firebase Auth (추천)
- 현재 Realtime DB 코드 그대로 유지
- 나중에 firebase/auth 모듈만 추가
- Google/Apple 소셜 로그인 쉽게 붙음
- 보안 규칙에서 auth.uid 기반으로 전환하면 끝
현재: mrt/families/{familyCode}/settings
나중: mrt/users/{uid}/settings (규칙에서 본인만 읽기/쓰기)
방법 2: Supabase로 전환
- firebase.ts, sync.ts 전체 재작성 필요
- 실시간 동기화 로직도 다시 구현
- 지금 한 작업을 버리는 셈
권장 로드맵
지금: Firebase Realtime DB + 가족 코드 (인증 없음)
↓
다음: Firebase Auth 추가 (Google/Apple 로그인)
↓
가족 코드 → uid 기반으로 마이그레이션
보안 규칙 강화
Firebase Auth는 같은 Firebase 프로젝트 안에서 켜기만 하면 되니까, 지금 만드는 Firebase 프로젝트에 나중에 Auth만 추가하면 됩니다. 코드 변경도 최소화됨.그래서 그냥 추천대로 Firebase를 써보기로 합니다.
일단 firebase 설정까지하고.. 또 다음에 설정을 이어가도록..하겠습니다.
결과와 배운 점
저희 아이들에게는 이 앱이 많은 도움이 되고 있어서
저처럼 필요한 사람이 있을까 싶어, 앱스토어나 구글스토어에 올릴려고 생각은 해보는데,
마음속 스토어 등록의 허들이 있네요. 비용도 지불해야하고, 과연 사람들이 다운로드할까.. 란 생각이네요.
댓글 1개
로그인하고 댓글을 작성하세요
황인준2026. 4. 1.
파이어베이스도 좋은 옵션입니다!
저희 아이들에게는 이 앱이 많은 도움이 되고 있어서
저처럼 필요한 사람이 있을까 싶어, 앱스토어나 구글스토어에 올릴려고 생각은 해보는데,
마음속 스토어 등록의 허들이 있네요. 비용도 지불해야하고, 과연 사람들이 다운로드할까.. 란 생각이네요.
-> 이 내용 그대로 SNS에 한번 올려보고 결정해보는 건 어떨까요?!
한 사람에게 도움이 되고 있다면 충분히 다른 사람들에게도 도움 될거라고 생각해요,
만들다보면 결국에 나조차도 안쓸걸 만드는 경우도 많거든요!
한번 SNS에 이게 어떤 서비스인지 올려보면 좋은 결과 있을거 같습니다 ㅎㅎㅎ