diff --git a/Baron Safe PWA/WebView 하이브리드 앱 추진 초안.md b/Baron Safe PWA/WebView 하이브리드 앱 추진 초안.md
index 8d2ef65..86e143c 100644
--- a/Baron Safe PWA/WebView 하이브리드 앱 추진 초안.md	
+++ b/Baron Safe PWA/WebView 하이브리드 앱 추진 초안.md	
@@ -6,13 +6,16 @@
 
 본 문서는 기존 `Baron Safe 기반 휴대폰 승인 로그인 제안안`을 실제 앱 개발 과제로 진행하기 위한 초기 실행 초안이다.
 
-팀 회의에서 제시된 방향에 따라 Baron SSO의 기존 `userfront` 화면 자산을 활용하여, PWA 또는 WebView/하이브리드 기반 `Baron Safe` 모바일 앱을 구상한다. 이 앱은 단순 로그인 화면이 아니라, 등록된 휴대폰을 인증 장치로 사용하여 사용자가 로그인 요청을 확인하고 승인 또는 거절하는 보안 승인 앱으로 정의한다.
+팀 회의에서 제시된 방향에 따라 Baron SSO의 기존 `userfront` 화면 자산을 활용하여, PWA 또는 WebView/하이브리드 기반 `Baron Safe` 모바일 앱을 구상한다.
+이 앱은 단순 로그인 화면이 아니라, 등록된 휴대폰을 인증 장치로 사용하여 사용자가 로그인 요청을 확인하고 승인 또는 거절하는 보안 승인 앱으로 정의한다.
 
 ## 2. 추진 배경
 
-현재 논의 중인 휴대전화번호 기반 로그인은 사용자 편의성은 높지만, 전화번호만으로는 실제 사용자가 해당 번호의 소유자인지, 현재 로그인 요청을 직접 승인했는지 확인하기 어렵다.
+현재 논의 중인 휴대전화번호 기반 로그인은 사용자 편의성은 높지만, 전화번호만으로는 실제 사용자가 해당 번호의 소유자인지, 
+현재 로그인 요청을 직접 승인했는지 확인하기 어렵다.
 
-이를 보완하기 위해 사용자의 휴대폰에 `Baron Safe` 앱을 설치하고, 해당 앱을 사용자 계정에 사전 등록된 인증 장치로 사용한다. 사용자는 PC, 브라우저, 키오스크 또는 RP 서비스에서 로그인 요청을 시작하고, 휴대폰 앱에서 요청 서비스, 요청 기기, 요청 시간, IP 정보를 확인한 후 승인한다.
+이를 보완하기 위해 사용자의 휴대폰에 `Baron Safe` 앱을 설치하고, 해당 앱을 사용자 계정에 사전 등록된 인증 장치로 사용한다. 
+사용자는 PC, 브라우저, 키오스크 또는 RP 서비스에서 로그인 요청을 시작하고, 휴대폰 앱에서 요청 서비스, 요청 기기, 요청 시간, IP 정보를 확인한 후 승인한다.
 
 이 구조는 OpenID Connect CIBA와 유사한 Out-of-Band 인증 흐름이며, Baron SSO의 Hydra/Kratos 기반 인증 흐름과도 연결할 수 있다.
 
@@ -20,7 +23,9 @@
 
 `Baron Safe`는 Flutter 기반 설치형 모바일 앱, PWA, WebView/하이브리드 앱 중 하나로 구현할 수 있다.
 
-다만 현재 Baron SSO `userfront`는 이미 모바일 화면을 고려한 포털 UI, 연결 앱 현황, 접속 이력, QR 진입 흐름 등을 포함하고 있으므로, 팀장 구상은 `userfront`를 모바일 WebView 또는 PWA 형태로 감싸고, 푸시/생체 인증/보안 저장소 같은 일부 기능만 네이티브로 보강하는 하이브리드 구조에 가까웠던 것으로 해석된다.
+다만 현재 Baron SSO `userfront`는 이미 모바일 화면을 고려한 포털 UI, 연결 앱 현황, 접속 이력, QR 진입 흐름 등을 포함하고 있으므로,
+ `userfront`를 모바일 WebView 또는 PWA 형태로 감싸고, 
+ 푸시/생체 인증/보안 저장소 같은 일부 기능만 네이티브로 보강하는 하이브리드 구조에 가까웠던 것으로 해석된다.
 
 기본 방향은 다음과 같다.
 
@@ -31,7 +36,9 @@
 - 푸시 알림은 로그인 요청을 전달하는 채널일 뿐이며 인증 수단으로 보지 않는다.
 - 승인 요청, 승인, 거절, 만료, 실패는 모두 감사 로그로 남긴다.
 
-따라서 본 초안에서는 `userfront`를 단순 참고 자료가 아니라, PWA/WebView 방식에서 재사용 가능한 기존 화면 자산으로 본다. 단, 보안 인증 장치 역할에 필요한 private key, 생체 인증, 푸시 수신, 앱 무결성 검증은 WebView 내부 웹 코드만으로 처리하지 않고 네이티브 계층 또는 Flutter 플러그인 계층에서 담당하는 방향으로 검토한다.
+따라서 본 초안에서는 `userfront`를 단순 참고 자료가 아니라, PWA/WebView 방식에서 재사용 가능한 기존 화면 자산으로 본다. 
+단, 보안 인증 장치 역할에 필요한 private key, 생체 인증, 푸시 수신, 앱 무결성 검증은 WebView 내부 웹 코드만으로 처리하지 않고 
+네이티브 계층 또는 Flutter 플러그인 계층에서 담당하는 방향으로 검토한다.
 
 ## 4. 대상 앱 정의
 
@@ -47,7 +54,8 @@
 - 기기 private key를 이용한 승인 응답 서명
 - 기기 분실, 교체, 해제 대응
 
-앱은 브라우저에서 열리는 웹앱이 아니라 휴대폰에 설치되는 모바일 앱이다. 따라서 사용자의 브라우저가 열려 있을 필요는 없다. 다만 보안상 승인 행위는 사용자가 앱을 열어 직접 수행해야 하며, 백그라운드 자동 승인은 허용하지 않는다.
+앱은 브라우저에서 열리는 웹앱이 아니라 휴대폰에 설치되는 모바일 앱이다. 따라서 사용자의 브라우저가 열려 있을 필요는 없다. 
+다만 보안상 승인 행위는 사용자가 앱을 열어 직접 수행해야 하며, 백그라운드 자동 승인은 허용하지 않는다.
 
 ## 5. 지원 플랫폼 및 배포
 
@@ -97,11 +105,13 @@
 | 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`를 최대한 활용하여 PWA 또는 WebView/하이브리드 방식으로 앱처럼 제공하는 방향으로 볼 수 있다. 
+이 방식은 현재 구현된 모바일 포털 화면을 재사용할 수 있으므로 초기 개발 속도와 화면 일관성 측면에서 장점이 있다.
 
 | 방식 | 설명 | 장점 | 주의점 |
 | --- | --- | --- | --- |
@@ -198,11 +208,14 @@ PoC 단계에서는 기기 서명을 단순화할 수 있으나, API 구조는 
 
 ### 8.3 사용자 흐름 제안안 비교
 
-Baron Safe 앱의 사용자 경험은 하나의 방식으로 고정하기보다, 현재 구현된 `userfront`의 연결 앱/접속 이력 흐름과 향후 앱 승인 흐름을 함께 비교하여 결정하는 것이 좋다.
+Baron Safe 앱의 사용자 경험은 하나의 방식으로 고정하기보다, 
+현재 구현된 `userfront`의 연결 앱/접속 이력 흐름과 향후 앱 승인 흐름을 함께 비교하여 결정하는 것이 좋다.
 
-특히 현재 화면에는 `나의 App 현황`, `연동앱`, `해지됨`, `접속이력`, `현재 세션`, `성공/비활성` 등의 정보가 이미 표현되어 있다. 이는 사용자가 사전에 RP 앱 연결을 허용하고, 이후 필요 시 연결을 해지하거나 차단하는 `선승인 후차단` 방식에 가까운 UX로 볼 수 있다.
+특히 현재 화면에는 `나의 App 현황`, `연동앱`, `해지됨`, `접속이력`, `현재 세션`, `성공/비활성` 등의 정보가 이미 표현되어 있다. 
+이는 사용자가 사전에 RP 앱 연결을 허용하고, 이후 필요 시 연결을 해지하거나 차단하는 `선승인 후차단` 방식에 가까운 UX로 볼 수 있다.
 
-반면 Baron Safe 승인 로그인은 사용자가 매 로그인 요청마다 앱에서 승인 또는 차단을 결정하는 `요청 시 승인/차단` 방식에 가깝다. 두 방식은 보안성과 편의성의 균형이 다르므로, 아래와 같이 제안안을 나누어 비교한다.
+반면 Baron Safe 승인 로그인은 사용자가 매 로그인 요청마다 앱에서 승인 또는 차단을 결정하는 `요청 시 승인/차단` 방식에 가깝다. 
+두 방식은 보안성과 편의성의 균형이 다르므로, 아래와 같이 제안안을 나누어 비교한다.
 
 | 안 | 방식 | 설명 | 장점 | 단점 | 적합한 용도 |
 | --- | --- | --- | --- | --- | --- |
@@ -216,9 +229,11 @@ Baron Safe 앱의 사용자 경험은 하나의 방식으로 고정하기보다,
 
 초기 PoC에서는 1안과 2안을 모두 화면상으로 보여주는 방식이 좋다.
 
-1안은 현재 개발된 `userfront`의 `나의 App 현황`, `접속이력`, `해지됨` 화면을 활용하여 구현한다. 사용자는 이미 연결된 앱과 최근 인증 이력을 확인하고, 필요 시 앱 연결을 해지하거나 차단한다.
+1안은 현재 개발된 `userfront`의 `나의 App 현황`, `접속이력`, `해지됨` 화면을 활용하여 구현한다. 
+사용자는 이미 연결된 앱과 최근 인증 이력을 확인하고, 필요 시 앱 연결을 해지하거나 차단한다.
 
-2안은 Baron Safe의 핵심 인증 흐름으로 구현한다. 사용자가 로그인 요청을 하면 앱 또는 WebView 하이브리드 화면에 승인 요청이 표시되고, 사용자가 직접 승인 또는 차단을 결정한다.
+2안은 Baron Safe의 핵심 인증 흐름으로 구현한다. 사용자가 로그인 요청을 하면 앱 또는 WebView 하이브리드 화면에 승인 요청이 표시되고, 
+사용자가 직접 승인 또는 차단을 결정한다.
 
 PoC 이후에는 다음과 같은 단계적 적용을 권장한다.