수학퍼즐게임 모바일 어플용 인프라
목표: 실습 + 배포 + 수익화 + 인프라 운영 경험 확보
전략 비교
| Firebase only | 싱글플레이, 랭킹 없음, 서버 로직 거의 없음 |
| 자체 서버 only | 인프라 학습이 최우선, 모바일 기능 직접 구현 감수 |
| 하이브리드 | 학습 + 실전 경험 + 빠른 출시 모두 필요할 때 |
학습 포인트
| 인증 흐름 | Firebase Auth → JWT 발급 → 서버 검증 |
| 동기화 | 오프라인 → 온라인 sync, 충돌 처리 |
| 배포 전략 | Rolling update, Zero downtime |
| 장애 대응 | 노드 복구, DB failover |
| Observability | 로그 · 메트릭 · 알림 |
Firebase vs 자체 서버 비교
| 불필요 | 직접 설계 · 운영 |
| Auth / Push / Analytics 내장 | 직접 구현 필요 |
| 거의 없음 | 높음 (k8s, 장애, 배포 경험) |
| 후반 증가, 벤더 종속 | 하드웨어 있으면 거의 0 |
| 낮음 | 높음 |
| 빠름 | 초기 구축 시간 큼 |
하이브리드 아키텍처
flowchart TD
A["Flutter App"]
A --> B["Firebase Auth\n(로그인/JWT 발급)"]
A --> C["Firebase Cloud Messaging\n(푸시 알림)"]
A --> D["Custom API Server\n(게임/비즈니스 로직)"]
subgraph cluster["Backend Cluster (mini PC)"]
D --> E["API Server\n(FastAPI / NestJS)"]
E --> F["PostgreSQL\n(Primary + Replica)"]
E --> G["Redis\n(캐시)"]
E --> H["Nginx\n(Reverse Proxy)"]
end
B --> D
자체 서버 스택
| 오케스트레이션 | k3s | 경량 Kubernetes, 학습 가치 높음 |
| API 서버 | FastAPI 또는 NestJS | Python / Node.js 선택 |
| 데이터베이스 | PostgreSQL | Primary + Replica 구성 |
| 캐시 | Redis | 세션, 랭킹 등 |
| Reverse Proxy | Nginx | - |
노드 배분 (N100 × 4대)
| Node 1 | Control Plane + API |
| Node 2 | API + Redis |
| Node 3 | DB Primary |
| Node 4 | DB Replica + Worker |
자체 서버 필수 조건
| 랭킹 시스템 | ✅ 필수 |
| 경제 시스템 (재화) | ✅ 필수 |
| 치팅 방지 | ✅ 필수 |
| 멀티플레이 | ✅ 필수 |
| 싱글플레이 (단순) | ❌ Firebase only 가능 |
수익화 구조
flowchart LR
A["유저 인앱결제"] --> B["Apple / Google Store"]
B --> C["영수증 서버 검증\n(절대 클라이언트 신뢰 금지)"]
C --> D["아이템 지급"]
E["광고 수익"] --> F["AdMob\n(Firebase 계열)"]
| 인앱결제 | Apple / Google Store | 서버 사이드 영수증 검증 필수 |
| 광고 | AdMob | Firebase 계열, Flutter 연동 쉬움 |
단계별 실행 전략
flowchart LR
A["1단계\nFirebase + Flutter\nMVP 출시"] --> B["2단계\n핵심 로직\n자체 서버 이전"]
B --> C["3단계\nmini PC 클러스터\n장애 · 확장 실험"]