diff --git a/Baron Safe 하이브리드 앱 개발 정책.md b/Baron Safe 하이브리드 앱 개발 정책.md index 6fb2895..f4dc6d4 100644 --- a/Baron Safe 하이브리드 앱 개발 정책.md +++ b/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 속도를 높일 수 있고, 로그인 이력 확인 및 차단이라는 기본 흐름과도 잘 맞는다.