# 니즈 분석 — 가족 소통·웰니스 앱 React Native 프론트엔드 개발

> 원문: [모집공고](가족%20소통%20웰니스%20앱%20React%20Native%20프론트엔드%20개발.txt) · [RFP v2](RFP_공개용_위시켓_v2.pdf)
> 예산 2,000만원 · 60일 · 2026-08 초 착수 → 9월 말 심사 제출 → 10월 정식 출시

## 1. 의뢰자가 명시한 니즈 (Explicit Needs)

### 1-1. 서비스 본질
- **성인 자녀 ↔ 부모 세대를 "하루 한 번의 공동 미션"으로 연결**하는 가족 소통·웰니스 앱
- 발주처는 **식품·헬스케어 기업** → 미션 달성 → **재료 획득 → 레시피 잠금 해제**라는 게이미피케이션이 서비스의 심장 (자사 식품 커머스/브랜드와의 연결 고리로 추정)
- 웹 MVP로 이미 검증을 마친 상태 → 이번 발주는 "검증된 기획을 앱으로 완성"하는 단계

### 1-2. 과업 범위 (프론트엔드 한정)
| 영역 | 내용 |
|---|---|
| 화면 | **총 24개** — 온보딩 5 · 홈/미션 6 · 레시피 3 · 피드 1 · 건강 2 · 랭킹 2 · 설정 5 |
| 인증 | 카카오 소셜 로그인 · PASS 본인인증(가입 시) |
| 가족 그룹 | 그룹 생성 · 초대 코드 발급 · **카카오톡 초대 공유** · 코드 입력 합류 |
| 건강 데이터 | Apple HealthKit / Health Connect(삼성헬스) 걸음 수 → API 동기화 |
| 수면 | **에이슬립(A-sleep) SDK** — 수면 시간·단계·주간 데이터 수신·표시 |
| 미션 | 카메라/앨범 권한 → 인증 사진 등록, **가족 전원 달성 판정** → 재료 획득 → 레시피 해제 UI |
| 푸시 | 핑거푸시 SaaS(변경 가능성 있음) — 토큰/기기 등록, 수신·탭 이벤트, **딥링크 라우팅**, 로그아웃 시 기기 해제 |
| 출시 | 양대 스토어 심사 등록 + **반려 대응·재제출까지** 책임 |

### 1-3. 우선순위와 성향 읽기
- 우선순위: **① 산출물 완성도 ② 일정 준수 ③ 금액** — 싸게보다 "제대로, 제때"
- 기획·IA·와이어프레임 확정, 디자인 별도 업체(Figma, ~7월 말), 백엔드·관리자 자체 보유 → **역할 경계가 명확한 발주처**. 경계를 존중하면서 협업 인터페이스(디자인 QA·API 스펙 협의)를 잘 다루는 팀을 원함
- 견적을 화면개발/외부연동 6종/스토어 출시로 **분할 제시** 요구 → 산출 근거의 투명성 중시
- 자산(Git·스토어 계정·인증서·키스토어) 소유권 발주처 귀속 명시 → 벤더 종속(lock-in) 경계

## 2. 의뢰자가 생각하지 못한 부분 / 추가 제안 (Gap Analysis)

### A. 일정·리스크 (제안서에서 반드시 짚어야 신뢰를 얻는 지점)
1. **디자인 지연 = 착수 지연 리스크**: 디자인이 7월 말 완료 전제인데 지연 시 60일 일정 전체가 밀림 → **디자인 없이 진행 가능한 선행 작업**(프로젝트 셋업, API 연동 레이어, 네이티브 모듈 브릿지, 내비게이션 골격)을 1~2주차에 배치하는 "디자인 비의존 트랙" 제안
2. **iOS 심사 리스크 선제 대응**: 건강 데이터(HealthKit) + 마이크(에이슬립 호흡음) + 사진 권한이 몰린 앱은 심사 반려 단골. 권한 사용 목적 문구(Purpose String), 개인정보처리방침 URL, 계정 삭제 기능(App Store 필수), 심사용 데모 계정 준비를 **9월 중순 사전 점검 체크리스트**로 제시
3. **애플 로그인 의무화**: 카카오 등 서드파티 로그인만 제공하면 **Sign in with Apple 필수**(App Store 심사 가이드라인 4.8) — RFP에 누락. 발주처 백엔드 협의 필요 사항으로 조기 플래그
4. **푸시 솔루션 미확정("변경 가능성 있음")**: 푸시 모듈을 어댑터 패턴으로 추상화해 솔루션 교체 비용 최소화 제안

### B. 기술·품질
5. **시니어 사용자 접근성**: 부모 세대가 핵심 사용자인데 RFP에 접근성 요구 없음 → 큰 글씨 모드(OS 폰트 스케일 대응), 명도 대비, 터치 타깃 48dp 이상, **시니어 온보딩 간소화**(자녀가 대신 초대·설정하는 흐름) 제안
6. **걸음 수 동기화 신뢰성**: 백그라운드 전환 시 누락 방지는 명시됐지만, **기기 교체·미접속 기간 데이터 보정, iOS/Android 측정치 차이**에 대한 정책(서버 기준 시각, 중복 제거)을 착수 시 API 스펙과 함께 확정해야 함
7. **오프라인·저사양 대응**: 부모 세대 구형 기기 비율 높음 → 최소 지원 OS 협의, 이미지 캐싱, 스켈레톤 로딩, 네트워크 실패 시 재시도 UX
8. **에이슬립 SDK 검증 선행**: 마이크 상시 사용 SDK는 배터리·권한 UX 민감 → 1주차에 **기술 검증(PoC) 스파이크** 배치 제안

### C. 서비스 관점 (발주처가 반길 플러스 알파)
9. **리마인드 넛지 설계**: "가족 전원 달성" 모델은 1명만 빠져도 실패 → 미달성 가족에게 보내는 **콕 찌르기(넛지)** 인터랙션 (썸원의 리마인드, 카톡 공유 재활용)
10. **연속 달성(스트릭)·주간 리포트**: 리텐션 핵심 장치. 랭킹 2개 화면과 자연스럽게 연결
11. **가족 기념일·시즌 미션**: 식품 기업 특성상 명절(추석 데모 시나리오) 한정 레시피 이벤트 확장 여지
12. **출시 후 계측 준비**: Firebase Analytics 이벤트 스키마(미션 달성률, 초대 전환율)를 개발 중 심어두면 발주처 운영에 즉시 도움 — 관련 기술에 Firebase 이미 명시됨

## 3. 데모사이트가 증명하는 것
- 24개 화면 구조(IA)를 **실제 인터랙션이 도는 폰 프레임 데모**로 재현 → "기획 이해도"를 말이 아닌 화면으로 증명
- 미션 → 가족 전원 달성 → 재료 획득 → 레시피 해제의 **핵심 루프** 시연
- 걸음 수·수면(에이슬립 스타일 리포트)·랭킹·넛지 등 위 갭 분석 제안을 UI로 선반영