From c3c1a00eaa147d78bc0f41eb55bdb4e1e2552051 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=EB=AC=B8=ED=98=95=EC=84=9D?= <moon79@hanmaceng.co.kr>
Date: Tue, 30 Jun 2026 13:04:17 +0900
Subject: [PATCH] =?UTF-8?q?Update=20Baron=20Safe=20PWA/WebView=20=ED=95=98?=
 =?UTF-8?q?=EC=9D=B4=EB=B8=8C=EB=A6=AC=EB=93=9C=20=EC=95=B1=20=EC=B6=94?=
 =?UTF-8?q?=EC=A7=84=20=EC=88=98=EC=A0=95=EC=95=88.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...� 초안.md => WebView 하이브리드 앱 추진 수정안.md} | 76 +++++++++----------
 1 file changed, 34 insertions(+), 42 deletions(-)
 rename Baron Safe PWA/{WebView 하이브리드 앱 추진 초안.md => WebView 하이브리드 앱 추진 수정안.md} (76%)

diff --git a/Baron Safe PWA/WebView 하이브리드 앱 추진 초안.md b/Baron Safe PWA/WebView 하이브리드 앱 추진 수정안.md
similarity index 76%
rename from Baron Safe PWA/WebView 하이브리드 앱 추진 초안.md
rename to Baron Safe PWA/WebView 하이브리드 앱 추진 수정안.md
index 98005f7..77cc430 100644
--- a/Baron Safe PWA/WebView 하이브리드 앱 추진 초안.md	
+++ b/Baron Safe PWA/WebView 하이브리드 앱 추진 수정안.md	
@@ -1,4 +1,4 @@
-# Baron Safe PWA/WebView 하이브리드 앱 추진 초안
+# Baron Safe PWA/WebView 하이브리드 앱 추진 수정안
 
 작성일: 2026-06-30
 
@@ -6,15 +6,16 @@
 
 본 문서는 기존 `Baron Safe 기반 휴대폰 승인 로그인 제안안`을 실제 앱 개발 과제로 진행하기 위한 초기 실행 초안이다.
 
-팀 회의에서 제시된 방향에 따라 Baron SSO의 기존 `userfront` 화면 자산을 활용하여, PWA 또는 WebView/하이브리드 기반 `Baron Safe` 모바일 앱을 구상한다.  
+팀 회의에서 제시된 방향에 따라 Baron SSO의 기존 `userfront`는 그대로 유지하고, 그 안에서 활용 가능한 화면 자산과 구현 패턴을 Baron Safe 앱 개발 시 가져다 쓰는 방향으로 구상한다.
+Baron Safe 앱 자체는 PWA 또는 WebView/하이브리드 기반 모바일 앱으로 검토한다.
 이 앱은 단순 로그인 화면이 아니라, 등록된 휴대폰을 인증 장치로 사용하여 사용자가 로그인 요청을 확인하고 승인 또는 거절하는 보안 승인 앱으로 정의한다.
 
 ## 2. 추진 배경
 
-현재 논의 중인 휴대전화번호 기반 로그인은 사용자 편의성은 높지만, 전화번호만으로는 실제 사용자가 해당 번호의 소유자인지,  
+현재 논의 중인 휴대전화번호 기반 로그인은 사용자 편의성은 높지만, 전화번호만으로는 실제 사용자가 해당 번호의 소유자인지, 
 현재 로그인 요청을 직접 승인했는지 확인하기 어렵다.
 
-이를 보완하기 위해 사용자의 휴대폰에 `Baron Safe` 앱을 설치하고, 해당 앱을 사용자 계정에 사전 등록된 인증 장치로 사용한다.  
+이를 보완하기 위해 사용자의 휴대폰에 `Baron Safe` 앱을 설치하고, 해당 앱을 사용자 계정에 사전 등록된 인증 장치로 사용한다. 
 사용자는 PC, 브라우저, 키오스크 또는 RP 서비스에서 로그인 요청을 시작하고, 휴대폰 앱에서 요청 서비스, 요청 기기, 요청 시간, IP 정보를 확인한 후 승인한다.
 
 이 구조는 OpenID Connect CIBA와 유사한 Out-of-Band 인증 흐름이며, Baron SSO의 Hydra/Kratos 기반 인증 흐름과도 연결할 수 있다.
@@ -23,21 +24,20 @@
 
 `Baron Safe`는 Flutter 기반 설치형 모바일 앱, PWA, WebView/하이브리드 앱 중 하나로 구현할 수 있다.
 
-다만 현재 Baron SSO `userfront`는 이미 모바일 화면을 고려한 포털 UI, 연결 앱 현황, 접속 이력, QR 진입 흐름 등을 포함하고 있으므로,  
- `userfront`를 모바일 WebView 또는 PWA 형태로 감싸고, 
- 푸시/생체 인증/보안 저장소 같은 일부 기능만 네이티브로 보강하는 하이브리드 구조에 가까웠던 것으로 해석된다.
+다만 현재 Baron SSO `userfront`는 이미 모바일 화면을 고려한 포털 UI, 연결 앱 현황, 접속 이력, QR 진입 흐름 등을 포함하고 있다.
+따라서 기존 `userfront`를 직접 변경하거나 앱으로 전환하기보다는, Baron Safe 앱에서 필요한 화면 흐름과 구현 패턴을 가져와 활용하고, 푸시/생체 인증/보안 저장소 같은 기능은 Baron Safe 앱의 네이티브 또는 Flutter 플러그인 계층으로 보강하는 하이브리드 구조가 적절하다.
 
 기본 방향은 다음과 같다.
 
 - Android와 iOS를 모두 지원한다.
-- 기존 Baron `userfront`의 Flutter 기술 스택과 UI/상태관리 패턴을 최대한 재사용한다.
+- 기존 Baron `userfront`는 그대로 두고, Baron Safe 앱 개발 시 활용 가능한 Flutter 기술 스택과 UI/상태관리 패턴을 재사용한다.
 - 전화번호는 인증 수단이 아니라 사용자 식별자로만 사용한다.
 - 실제 인증 근거는 등록된 앱 기기, 기기 private key, 생체 인증 또는 앱 PIN, 승인 응답 서명으로 확보한다.
 - 푸시 알림은 로그인 요청을 전달하는 채널일 뿐이며 인증 수단으로 보지 않는다.
 - 승인 요청, 승인, 거절, 만료, 실패는 모두 감사 로그로 남긴다.
 
-따라서 본 초안에서는 `userfront`를 단순 참고 자료가 아니라, PWA/WebView 방식에서 재사용 가능한 기존 화면 자산으로 본다.   
-단, 보안 인증 장치 역할에 필요한 private key, 생체 인증, 푸시 수신, 앱 무결성 검증은 WebView 내부 웹 코드만으로 처리하지 않고   
+따라서 본 초안에서는 `userfront`를 수정 대상이 아니라, Baron Safe 앱에서 활용 가능한 화면/패턴 자산으로 본다. 
+단, 보안 인증 장치 역할에 필요한 private key, 생체 인증, 푸시 수신, 앱 무결성 검증은 WebView 내부 웹 코드만으로 처리하지 않고 
 네이티브 계층 또는 Flutter 플러그인 계층에서 담당하는 방향으로 검토한다.
 
 ## 4. 대상 앱 정의
@@ -54,8 +54,7 @@
 - 기기 private key를 이용한 승인 응답 서명
 - 기기 분실, 교체, 해제 대응
 
-앱은 브라우저에서 열리는 웹앱이 아니라 휴대폰에 설치되는 모바일 앱이다. 따라서 사용자의 브라우저가 열려 있을 필요는 없다.   
-다만 보안상 승인 행위는 사용자가 앱을 열어 직접 수행해야 하며, 백그라운드 자동 승인은 허용하지 않는다.
+앱은 브라우저에서 열리는 웹앱이 아니라 휴대폰에 설치되는 모바일 앱이다. 따라서 사용자의 브라우저가 열려 있을 필요는 없다. 다만 보안상 승인 행위는 사용자가 앱을 열어 직접 수행해야 하며, 백그라운드 자동 승인은 허용하지 않는다.
 
 ## 5. 지원 플랫폼 및 배포
 
@@ -88,7 +87,7 @@
 | 이미지/SVG | flutter_svg |
 | 로깅 | logging, logger |
 
-`Baron Safe` 앱은 이 구성을 기본으로 가져가되, 모바일 인증 앱에 필요한 보안/푸시 기능을 추가한다.
+`Baron Safe` 앱은 이 구성을 참고하여 필요한 부분을 가져가되, `userfront` 원본은 그대로 유지한다. 모바일 인증 앱에 필요한 보안/푸시 기능은 Baron Safe 앱 쪽에 별도로 추가한다.
 
 ### 6.2 추가 검토 기술
 
@@ -105,30 +104,28 @@
 | Deep Link | app_links 또는 firebase_dynamic_links 대체 검토 | 푸시/QR/등록 링크 진입 |
 | App Integrity | Play Integrity API, DeviceCheck/App Attest 검토 | 위변조 앱과 위험 기기 탐지 |
 
-초기에는 기존 `userfront`와의 일관성을 위해 `flutter_riverpod`, `go_router`, `http`를 유지하는 것이 좋다.   
-단, 인증 앱 특성상 private key 생성/서명은 일반 secure storage만으로 끝내지 말고 Android/iOS 보안 키 저장소와 직접 연동하는 방안을 검토해야 한다.
+초기에는 기존 `userfront`와의 일관성을 위해 `flutter_riverpod`, `go_router`, `http`를 유지하는 것이 좋다. 단, 인증 앱 특성상 private key 생성/서명은 일반 secure storage만으로 끝내지 말고 Android/iOS 보안 키 저장소와 직접 연동하는 방안을 검토해야 한다.
 
 ### 6.3 PWA/WebView/하이브리드 방식 검토
 
-팀장 구상은 기존 `userfront`를 최대한 활용하여 PWA 또는 WebView/하이브리드 방식으로 앱처럼 제공하는 방향으로 볼 수 있다. 
-이 방식은 현재 구현된 모바일 포털 화면을 재사용할 수 있으므로 초기 개발 속도와 화면 일관성 측면에서 장점이 있다.
+팀장 구상은 기존 `userfront`의 활용 가능한 부분을 Baron Safe 앱에서 재사용하여 PWA 또는 WebView/하이브리드 방식으로 앱처럼 제공하는 방향으로 볼 수 있다. 이 방식은 현재 구현된 모바일 포털 화면과 흐름을 참고할 수 있으므로 초기 개발 속도와 화면 일관성 측면에서 장점이 있다.
 
 | 방식 | 설명 | 장점 | 주의점 |
 | --- | --- | --- | --- |
-| PWA | 웹앱을 브라우저 또는 홈 화면 설치 형태로 사용하는 방식 | 배포가 쉽고 기존 `userfront` 재사용성이 높음 | iOS/Android별 푸시, 백그라운드 동작, 보안 저장소 제약 검토 필요 |
-| WebView 앱 | Android/iOS 앱 안에 `userfront` 웹 화면을 띄우는 방식 | 앱 설치형 UX 제공, 기존 화면 재사용 가능 | 민감 기능은 WebView JS가 아니라 네이티브 브리지에서 처리해야 함 |
+| PWA | 웹앱을 브라우저 또는 홈 화면 설치 형태로 사용하는 방식 | 배포가 쉽고 기존 `userfront`의 화면/패턴 활용성이 높음 | iOS/Android별 푸시, 백그라운드 동작, 보안 저장소 제약 검토 필요 |
+| WebView 앱 | Android/iOS 앱 안에 Baron Safe용 웹 화면을 띄우는 방식 | 앱 설치형 UX 제공, 기존 `userfront`의 화면 흐름을 활용 가능 | 민감 기능은 WebView JS가 아니라 네이티브 브리지에서 처리해야 함 |
 | 하이브리드 앱 | 주요 화면은 WebView, 푸시/생체인증/키서명은 네이티브 또는 Flutter 플러그인으로 처리 | 개발 속도와 보안 기능을 절충 가능 | 웹-네이티브 메시지 경계와 인증 토큰 전달 방식 설계 필요 |
 | 순수 Flutter 앱 | Baron Safe 전용 화면과 기능을 Flutter로 별도 구현 | 보안 기능과 앱 UX 제어가 가장 명확함 | 기존 `userfront` 화면 재사용성이 낮고 초기 구현량 증가 |
 
 현 시점의 현실적인 권장안은 하이브리드 방식이다.
 
-- `userfront`의 연결 앱 현황, 접속 이력, QR 화면, 기본 포털 UI는 WebView 또는 PWA 화면으로 재사용한다.
+- `userfront`의 연결 앱 현황, 접속 이력, QR 화면, 기본 포털 UI 중 Baron Safe에 필요한 부분은 Baron Safe 앱 화면으로 활용한다.
 - 로그인 승인 알림 수신은 FCM/APNs 기반 네이티브 푸시로 처리한다.
 - 승인 전 생체 인증은 Android/iOS 네이티브 또는 Flutter `local_auth` 계층에서 처리한다.
 - private key 생성과 서명은 Android Keystore, iOS Keychain/Secure Enclave 계층에서 처리한다.
 - WebView 화면은 승인 요청 표시와 사용자 인터랙션을 담당하되, 실제 서명과 민감 토큰 저장은 네이티브 계층에 위임한다.
 
-즉 `userfront`를 앱 화면으로 활용하더라도 Baron Safe의 인증 근거는 웹 세션 자체가 아니라, 앱에 등록된 기기 키와 네이티브 보안 기능에서 나와야 한다.
+즉 `userfront`의 화면/패턴을 Baron Safe 앱에서 활용하더라도 Baron Safe의 인증 근거는 웹 세션 자체가 아니라, 앱에 등록된 기기 키와 네이티브 보안 기능에서 나와야 한다.
 
 ## 7. 주요 기능 범위
 
@@ -208,14 +205,11 @@ PoC 단계에서는 기기 서명을 단순화할 수 있으나, API 구조는 
 
 ### 8.3 사용자 흐름 제안안 비교
 
-Baron Safe 앱의 사용자 경험은 하나의 방식으로 고정하기보다, 
-현재 구현된 `userfront`의 연결 앱/접속 이력 흐름과 향후 앱 승인 흐름을 함께 비교하여 결정하는 것이 좋다.
+Baron Safe 앱의 사용자 경험은 하나의 방식으로 고정하기보다, 현재 구현된 `userfront`의 연결 앱/접속 이력 흐름과 향후 앱 승인 흐름을 함께 비교하여 결정하는 것이 좋다.
 
-특히 현재 화면에는 `나의 App 현황`, `연동앱`, `해지됨`, `접속이력`, `현재 세션`, `성공/비활성` 등의 정보가 이미 표현되어 있다. 
-이는 사용자가 사전에 RP 앱 연결을 허용하고, 이후 필요 시 연결을 해지하거나 차단하는 `선승인 후차단` 방식에 가까운 UX로 볼 수 있다.
+특히 현재 화면에는 `나의 App 현황`, `연동앱`, `해지됨`, `접속이력`, `현재 세션`, `성공/비활성` 등의 정보가 이미 표현되어 있다. 이는 사용자가 사전에 RP 앱 연결을 허용하고, 이후 필요 시 연결을 해지하거나 차단하는 `선승인 후차단` 방식에 가까운 UX로 볼 수 있다.
 
-반면 Baron Safe 승인 로그인은 사용자가 매 로그인 요청마다 앱에서 승인 또는 차단을 결정하는 `요청 시 승인/차단` 방식에 가깝다. 
-두 방식은 보안성과 편의성의 균형이 다르므로, 아래와 같이 제안안을 나누어 비교한다.
+반면 Baron Safe 승인 로그인은 사용자가 매 로그인 요청마다 앱에서 승인 또는 차단을 결정하는 `요청 시 승인/차단` 방식에 가깝다. 두 방식은 보안성과 편의성의 균형이 다르므로, 아래와 같이 제안안을 나누어 비교한다.
 
 | 안 | 방식 | 설명 | 장점 | 단점 | 적합한 용도 |
 | --- | --- | --- | --- | --- | --- |
@@ -229,11 +223,9 @@ Baron Safe 앱의 사용자 경험은 하나의 방식으로 고정하기보다,
 
 초기 PoC에서는 1안과 2안을 모두 화면상으로 보여주는 방식이 좋다.
 
-1안은 현재 개발된 `userfront`의 `나의 App 현황`, `접속이력`, `해지됨` 화면을 활용하여 구현한다. 
-사용자는 이미 연결된 앱과 최근 인증 이력을 확인하고, 필요 시 앱 연결을 해지하거나 차단한다.
+1안은 현재 개발된 `userfront`의 `나의 App 현황`, `접속이력`, `해지됨` 화면을 활용하여 구현한다. 사용자는 이미 연결된 앱과 최근 인증 이력을 확인하고, 필요 시 앱 연결을 해지하거나 차단한다.
 
-2안은 Baron Safe의 핵심 인증 흐름으로 구현한다. 사용자가 로그인 요청을 하면 앱 또는 WebView 하이브리드 화면에 승인 요청이 표시되고, 
-사용자가 직접 승인 또는 차단을 결정한다.
+2안은 Baron Safe의 핵심 인증 흐름으로 구현한다. 사용자가 로그인 요청을 하면 앱 또는 WebView 하이브리드 화면에 승인 요청이 표시되고, 사용자가 직접 승인 또는 차단을 결정한다.
 
 PoC 이후에는 다음과 같은 단계적 적용을 권장한다.
 
@@ -372,13 +364,13 @@ POST /api/v1/auth/baron-safe/login/poll
 | 단계 | 기간 | 산출물 |
 | --- | --- | --- |
 | 0단계 | 1주 | 상세 요구사항, 화면 흐름, API 계약 초안 |
-| 1단계 PoC | 2~3주 | Android 중심 Flutter 앱, 기기 등록 Mock, 승인 요청 조회/승인 API 연동 |
+| 1단계 PoC | 2~3주 | Android 중심 Baron Safe 하이브리드 앱, 기기 등록 Mock, 승인 요청 조회/승인 API 연동 |
 | 2단계 MVP | 4~6주 | 푸시, 생체 인증, key pair, 서명 검증, Hydra login challenge 연동 |
 | 3단계 운영화 | 4주 이상 | iOS 검증, 배포 체계, 감사 로그, 관리자 기기 관리, 보안 강화 |
 
 ## 13. 우선 결정 필요 사항
 
-1. `Baron Safe`를 기존 `userfront` 프로젝트 내부 앱 모드로 둘지, 별도 Flutter 앱 프로젝트로 분리할지 결정해야 한다.
+1. `userfront` 원본은 유지하고, Baron Safe 앱에서 어떤 화면/패턴/API 흐름을 활용할지 결정해야 한다.
 2. 초기 PoC 대상 플랫폼을 Android 우선으로 할지, Android/iOS 동시로 할지 결정해야 한다.
 3. 앱 배포 방식을 사내 배포, MDM, 스토어 배포 중 어떤 방식으로 가져갈지 결정해야 한다.
 4. 기기 등록 시 기존 SSO 로그인 기반으로 할지, 관리자 초대/등록 코드 기반으로 할지 결정해야 한다.
@@ -387,34 +379,34 @@ POST /api/v1/auth/baron-safe/login/poll
 
 ## 14. 권장 추진안
 
-초기에는 기존 `userfront` 화면 자산을 활용하는 WebView/하이브리드 방식을 우선 검토하고, 보안 기능은 네이티브 또는 Flutter 플러그인 계층으로 분리하는 것을 권장한다.
+초기에는 기존 `userfront`는 그대로 두고, 그 안에서 활용 가능한 화면 자산과 구현 패턴을 Baron Safe 앱에서 가져다 쓰는 WebView/하이브리드 방식을 우선 검토한다. 보안 기능은 네이티브 또는 Flutter 플러그인 계층으로 분리하는 것을 권장한다.
 
 이유는 다음과 같다.
 
 - 현재 `userfront`는 이미 모바일 포털 화면과 연결 앱 현황, 접속 이력, QR 진입 등 Baron Safe와 가까운 화면 흐름을 일부 포함하고 있다.
-- 팀장 구상은 PWA 또는 WebView/하이브리드 방식으로 현재 화면 자산을 앱처럼 활용하는 방향에 가까워 보인다.
-- 초기 PoC에서는 화면을 새로 만들기보다 기존 화면을 활용하는 편이 빠르다.
+- 팀장 구상은 PWA 또는 WebView/하이브리드 방식으로 현재 화면 자산과 구현 패턴을 Baron Safe 앱에서 활용하는 방향에 가까워 보인다.
+- 초기 PoC에서는 화면을 전부 새로 만들기보다 기존 `userfront`의 활용 가능한 부분을 가져오는 편이 빠르다.
 - 다만 푸시, 생체 인증, private key, 보안 저장소, 앱 무결성은 WebView 내부 웹 코드에만 맡기기 어렵다.
-- 따라서 화면은 `userfront` 재사용, 인증 장치 기능은 네이티브/Flutter 앱 계층 담당으로 역할을 나누는 것이 적절하다.
+- 따라서 `userfront`는 유지하고, Baron Safe 앱은 활용 가능한 화면/패턴을 가져오며, 인증 장치 기능은 네이티브/Flutter 앱 계층이 담당하도록 역할을 나누는 것이 적절하다.
 
-단, 장기적으로 Baron Safe가 고보안 인증 앱으로 커질 경우에는 `baron_safe_app` 형태의 별도 Flutter 앱으로 분리하는 방안도 유지한다. 이 경우 `userfront`는 화면과 UX 패턴의 참조 자산으로 활용하고, 앱 패키지, Android/iOS 설정, 푸시 설정, 앱 서명, 보안 저장소 설정은 독립적으로 관리한다.
+단, 장기적으로 Baron Safe가 고보안 인증 앱으로 커질 경우에는 `baron_safe_app` 형태의 별도 Flutter 앱으로 분리하는 방안도 유지한다. 이 경우에도 `userfront`는 그대로 두고 화면과 UX 패턴의 참조 자산으로 활용하며, 앱 패키지, Android/iOS 설정, 푸시 설정, 앱 서명, 보안 저장소 설정은 Baron Safe 앱에서 독립적으로 관리한다.
 
 따라서 추진 순서는 다음과 같이 잡는다.
 
-1. 기존 `userfront` 화면 중 Baron Safe에 재사용 가능한 화면과 API 흐름을 식별한다.
+1. 기존 `userfront` 화면 중 Baron Safe 앱에서 활용 가능한 화면, 패턴, API 흐름을 식별한다.
 2. PWA 방식과 WebView 앱 방식 중 PoC에 적합한 방식을 결정한다.
 3. Backend에 승인 요청 생성, poll, 앱 상세 조회, 승인/거절 API를 추가한다.
 4. Mock push 또는 수동 refresh 방식으로 end-to-end 승인 PoC를 완성한다.
 5. Android FCM과 iOS APNs 기반 푸시를 연동한다.
 6. 생체 인증과 기기 보안 저장소를 네이티브/Flutter 플러그인 계층으로 연동한다.
 7. 기기 key pair와 승인 응답 서명 검증을 추가한다.
-8. 운영 배포 방식과 장기적으로 별도 `baron_safe_app` 분리 여부를 확정한다.
+8. 운영 배포 방식과 장기적으로 완전 별도 `baron_safe_app`으로 갈지 여부를 확정한다.
 
 ## 15. 결론
 
-Baron Safe 앱은 PWA/WebView/하이브리드 방식과 Flutter 기반 별도 앱 방식을 모두 검토할 수 있다. 현재 Baron `userfront`가 이미 모바일 포털 화면을 상당 부분 갖추고 있으므로, 초기 PoC는 기존 `userfront`를 활용한 WebView/하이브리드 방식이 현실적이다.
+Baron Safe 앱은 PWA/WebView/하이브리드 방식과 Flutter 기반 별도 앱 방식을 모두 검토할 수 있다. 현재 Baron `userfront`가 이미 모바일 포털 화면을 상당 부분 갖추고 있으므로, 초기 PoC는 `userfront`를 그대로 유지한 채 활용 가능한 화면/패턴/API 흐름을 Baron Safe 앱에서 가져다 쓰는 WebView/하이브리드 방식이 현실적이다.
 
-다만 본 앱은 일반 화면 앱이 아니라 인증 장치 역할을 하므로, 화면을 WebView로 재사용하더라도 푸시, 생체 인증, 기기 보안 저장소, private key 서명, 서버 검증, 감사 로그는 핵심 보안 요소로 별도 설계해야 한다. 따라서 PoC 단계에서는 기존 화면을 활용해 승인 흐름을 빠르게 검증하고, MVP 단계에서 네이티브 보안 기능과 기기 서명 구조를 반드시 포함하는 방향으로 추진하는 것이 바람직하다.
+다만 본 앱은 일반 화면 앱이 아니라 인증 장치 역할을 하므로, 화면/패턴을 활용하더라도 푸시, 생체 인증, 기기 보안 저장소, private key 서명, 서버 검증, 감사 로그는 Baron Safe 앱의 핵심 보안 요소로 별도 설계해야 한다. 따라서 PoC 단계에서는 기존 `userfront`의 활용 가능한 부분을 바탕으로 승인 흐름을 빠르게 검증하고, MVP 단계에서 네이티브 보안 기능과 기기 서명 구조를 반드시 포함하는 방향으로 추진하는 것이 바람직하다.
 
 ## 16. 용어 주석