Update Baron Safe 하이브리드 앱 개발 정책.md

Baron Safe 하이브리드 앱 개발 정책.md

@@ -247,9 +247,55 @@ AI 사용 제한:
 - WebView bridge 허용 명령은 정책 문서에 정의된 목록을 벗어나지 않는다.
 - 생성된 암호화/서명 코드는 공식 라이브러리와 플랫폼 문서를 기준으로 재검증한다.
 
-## 5. 단계별 개발 순서
+## 5. 플랫폼 개발 전략
 
-### 5.1 0단계: 요구사항 및 설계 확정
+Flutter는 하나의 코드베이스로 Android와 iOS를 함께 지원할 수 있다. 다만 Baron Safe 앱은 일반 화면 앱이 아니라 푸시, 생체 인증, 보안 저장소, WebView-native bridge, 향후 기기 서명까지 포함하는 보안 앱이므로 양 플랫폼을 어떤 순서로 검증할지 정책이 필요하다.
+
+### 5.1 개발 방식 후보
+
+| 안 | 방식 | 설명 | 장점 | 단점 | 적합성 |
+| --- | --- | --- | --- | --- | --- |
+| 1안 | Android 우선 개발 후 iOS 확장 | Android에서 PoC와 주요 네이티브 기능을 먼저 검증하고 이후 iOS로 확장한다. | 초기 PoC가 빠름. FCM, WebView, local_auth, Keystore 검증이 상대적으로 수월함. 내부 테스트 배포가 쉬움. | iOS APNs, Keychain, WebView 정책 이슈가 뒤늦게 발견될 수 있음. | 높음 |
+| 2안 | Android/iOS 동시 개발 | 처음부터 Android와 iOS를 같은 수준으로 개발하고 검증한다. | 양 플랫폼 차이를 초기에 발견할 수 있음. 최종 품질 균형이 좋음. | Xcode, APNs, 인증서, TestFlight까지 동시에 준비해야 하므로 초기 부담이 큼. | 중간 |
+| 3안 | 공통 Flutter/WebView 코드 먼저 개발 후 플랫폼 기능 순차 적용 | 화면, 라우팅, API, 상태관리, WebView 구조를 먼저 만들고 Android/iOS 네이티브 기능을 순차 적용한다. | 공통 구조를 안정화한 뒤 플랫폼 기능을 붙일 수 있음. 코드 중복이 줄어듦. | 푸시, 생체 인증, 보안 저장소 같은 핵심 기능 검증이 늦어질 수 있음. | 높음 |
+| 4안 | WebView/PWA PoC 먼저, 이후 앱화 | 기존 `userfront` 활용 화면과 기본 사용자 흐름을 웹/PWA 수준에서 먼저 검증한 뒤 앱으로 감싼다. | 화면과 정책을 빠르게 검증 가능. 앱 개발 전에 UX를 확정하기 좋음. | 네이티브 푸시, 생체 인증, 보안 저장소 검증은 별도 단계가 필요함. | 높음 |
+| 5안 | iOS 우선 개발 후 Android 확장 | iOS의 제약을 먼저 해결하고 Android로 확장한다. | Apple 배포, APNs, Keychain 제약을 조기에 확인 가능. | 초기 개발 속도가 느릴 수 있고 테스트 환경 준비가 번거로움. | 낮음 |
+
+### 5.2 권장 전략
+
+권장안은 `3안 + 1안` 조합이다.
+
+즉 소스코드는 Flutter 공통 코드로 처음부터 Android와 iOS를 고려해서 작성하되, 실제 네이티브 기능 검증은 Android를 먼저 진행하고 이후 iOS로 확장한다.
+
+권장 순서:
+
+1. 공통 Flutter/WebView 구조를 먼저 개발한다.
+2. 세션/접속이력/연결 앱 조회, 차단 UI, API 연동 구조를 공통 코드로 만든다.
+3. Android에서 FCM, WebView-native bridge, local_auth, Android Keystore를 먼저 검증한다.
+4. Android 기준으로 선승인 후확인 후차단 PoC를 완성한다.
+5. iOS에서 APNs, WKWebView, Face ID/Touch ID, Keychain/Secure Enclave를 확장 검증한다.
+6. Android/iOS 차이를 반영하여 공통 UI와 플랫폼별 bridge를 정리한다.
+7. 양 플랫폼에서 푸시 수신 상태, 앱 재설치, 기기 변경, 세션 차단을 반복 검증한다.
+
+### 5.3 플랫폼별 검증 우선순위
+
+| 단계 | Android | iOS |
+| --- | --- | --- |
+| PoC | WebView, FCM, 세션 조회, 차단 API, local_auth 우선 검증 | WebView 표시와 기본 로그인 세션 유지 수준 확인 |
+| MVP | Android Keystore, push background/terminated 수신, 차단/해제 생체 인증 검증 | APNs, Keychain, Face ID/Touch ID, WKWebView 정책 검증 |
+| 운영 전 | APK/AAB 배포, Play Integrity 검토 | TestFlight/MDM 배포, DeviceCheck/App Attest 검토 |
+
+### 5.4 결정 원칙
+
+- 공통 Flutter 코드는 처음부터 Android/iOS 모두를 고려해 작성한다.
+- 플랫폼별 네이티브 기능은 Android에서 먼저 PoC를 완성한 뒤 iOS로 확장한다.
+- iOS를 너무 늦게 검증하지 않는다. PoC 중에도 최소한 WebView, 로그인 세션, APNs 준비 가능 여부는 확인한다.
+- 푸시, 생체 인증, 보안 저장소, bridge는 플랫폼별 차이가 크므로 공통 인터페이스와 플랫폼 구현체를 분리한다.
+- 운영 배포 전에는 Android/iOS 모두 동일한 보안 기준을 통과해야 한다.
+
+## 6. 단계별 개발 순서
+
+### 6.1 0단계: 요구사항 및 설계 확정
 
 목표는 개발자가 바로 구현에 들어갈 수 있는 계약을 만드는 것이다.
 
@@ -276,7 +322,7 @@ AI 사용 제한:
 - Docker 구성 초안
 - VS Code 설정 및 AI 개발 가이드
 
-### 5.2 1단계: 앱 뼈대 및 WebView PoC
+### 6.2 1단계: 앱 뼈대 및 WebView PoC
 
 목표는 Baron Safe 앱에서 기존 화면 흐름을 앱처럼 보여주는 것이다.
 
@@ -302,7 +348,7 @@ AI 사용 제한:
 - 로그인 세션이 유지되는지 확인한다.
 - 네트워크 오류, 인증 만료, 뒤로가기 동작을 확인한다.
 
-### 5.3 2단계: 기기 등록 및 push token 등록
+### 6.3 2단계: 기기 등록 및 push token 등록
 
 목표는 Baron Safe 앱을 사용자 계정에 연결된 기기로 등록하는 것이다.
 
@@ -321,7 +367,7 @@ AI 사용 제한:
 - push token 갱신이 누락되지 않는지 확인한다.
 - 기기 해제 후 푸시가 발송되지 않는지 확인한다.
 
-### 5.4 3단계: 세션/연결 앱 조회 화면
+### 6.4 3단계: 세션/연결 앱 조회 화면
 
 목표는 사용자가 Baron Safe 앱에서 최근 로그인과 연결 앱 상태를 확인할 수 있게 하는 것이다.
 
@@ -339,7 +385,7 @@ AI 사용 제한:
 - 세션 상태가 실시간 또는 준실시간으로 갱신되는지 확인한다.
 - 사용자가 본인 요청 여부를 판단할 수 있는 정보가 충분한지 확인한다.
 
-### 5.5 4단계: 로그인 발생 푸시
+### 6.5 4단계: 로그인 발생 푸시
 
 목표는 로그인 발생 시 Baron Safe 앱으로 알림을 보내는 것이다.
 
@@ -357,7 +403,7 @@ AI 사용 제한:
 - iOS foreground/background/terminated 상태별 푸시 수신을 확인한다.
 - 푸시 클릭 deep link가 정확한 세션 상세로 이동하는지 확인한다.
 
-### 5.6 5단계: 차단/해제 기능
+### 6.6 5단계: 차단/해제 기능
 
 목표는 의심 세션 또는 RP 연결을 사용자가 앱에서 차단할 수 있게 하는 것이다.
 
@@ -377,7 +423,7 @@ AI 사용 제한:
 - 차단한 세션이 다시 활성화되지 않는지 확인한다.
 - 본인 현재 세션 차단 시 UX가 자연스러운지 확인한다.
 
-### 5.7 6단계: 민감 저장소 및 서명 기반 보강
+### 6.7 6단계: 민감 저장소 및 서명 기반 보강
 
 목표는 민감 정보를 WebView가 아닌 기기 보안 계층에서 관리하는 것이다.
 
@@ -396,7 +442,7 @@ AI 사용 제한:
 - private key export가 불가능한지 확인한다.
 - 위조된 차단 요청이 거부되는지 확인한다.
 
-### 5.8 7단계: 고위험 로그인 사전 승인 확장
+### 6.8 7단계: 고위험 로그인 사전 승인 확장
 
 목표는 기본안으로 부족한 고위험 상황에 사전 승인 방식을 추가하는 것이다.
 
@@ -422,7 +468,7 @@ AI 사용 제한:
 - 승인 만료, 거절, 중복 승인 요청이 정상 처리되는지 확인한다.
 - 일반 RP의 로그인 UX가 과도하게 느려지지 않는지 확인한다.
 
-### 5.9 8단계: 운영 배포 준비
+### 6.9 8단계: 운영 배포 준비
 
 목표는 내부/협력사 사용자가 안정적으로 설치하고 사용할 수 있게 하는 것이다.
 
@@ -443,7 +489,7 @@ AI 사용 제한:
 - push 장애 시 대체 확인 흐름을 테스트한다.
 - backend 장애 시 앱 화면의 오류 처리를 테스트한다.
 
-## 6. WebView-Native Bridge 정책
+## 7. WebView-Native Bridge 정책
 
 WebView에서 네이티브 기능을 호출할 때는 허용된 명령만 처리한다.
 
@@ -465,7 +511,7 @@ WebView에서 네이티브 기능을 호출할 때는 허용된 명령만 처리
 - WebView JS에서 생체 인증 성공 여부를 임의로 조작할 수 없게 한다.
 - bridge 명령에는 origin 검증과 session 검증을 적용한다.
 
-## 7. Backend API 준비 목록
+## 8. Backend API 준비 목록
 
 초기 기본안에 필요한 API:
 
@@ -485,7 +531,7 @@ WebView에서 네이티브 기능을 호출할 때는 허용된 명령만 처리
 - `POST /api/v1/auth/baron-safe/requests/{authReqId}/decision`
 - `POST /api/v1/auth/baron-safe/login/poll`
 
-## 8. 감사 로그 정책
+## 9. 감사 로그 정책
 
 최소 감사 로그 이벤트:
 
@@ -518,9 +564,9 @@ WebView에서 네이티브 기능을 호출할 때는 허용된 명령만 처리
 - reason
 - created_at
 
-## 9. 테스트 정책
+## 10. 테스트 정책
 
-### 9.1 기능 테스트
+### 10.1 기능 테스트
 
 - 기기 등록/해제
 - push token 등록/갱신
@@ -531,7 +577,7 @@ WebView에서 네이티브 기능을 호출할 때는 허용된 명령만 처리
 - RP 연결 차단
 - 생체 인증 성공/실패
 
-### 9.2 보안 테스트
+### 10.2 보안 테스트
 
 - 미등록 기기의 API 접근 차단
 - 다른 사용자의 세션 차단 시도 차단
@@ -540,7 +586,7 @@ WebView에서 네이티브 기능을 호출할 때는 허용된 명령만 처리
 - 만료된 세션 차단 요청 처리
 - 반복 요청 rate limit 확인
 
-### 9.3 플랫폼 테스트
+### 10.3 플랫폼 테스트
 
 - Android foreground/background/terminated push 수신
 - iOS foreground/background/terminated push 수신
@@ -548,7 +594,7 @@ WebView에서 네이티브 기능을 호출할 때는 허용된 명령만 처리
 - iOS Keychain/Secure Enclave 동작
 - 앱 재설치/기기 변경 시 동작
 
-## 10. 단계별 완료 기준
+## 11. 단계별 완료 기준
 
 | 단계 | 완료 기준 |
 | --- | --- |
@@ -562,7 +608,7 @@ WebView에서 네이티브 기능을 호출할 때는 허용된 명령만 처리
 | 7단계 | 고위험 로그인 사전 승인 흐름 검증 |
 | 8단계 | Android/iOS 배포 및 운영 절차 확정 |
 
-## 11. 결론
+## 12. 결론
 
 Baron Safe 앱은 초기에는 하이브리드 방식으로 진행하는 것이 현실적이다. 기존 `userfront`의 화면과 구현 패턴을 활용하면 PoC 속도를 높일 수 있고, 로그인 이력 확인 및 차단이라는 기본 흐름과도 잘 맞는다.