# Baron Safe 개발 전 검토 및 방식 비교

작성일: 2026-06-30

## 1. 목적

본 문서는 `Baron Safe` 앱 개발 착수 전 검토해야 할 주요 선택지를 정리한다. 회의 중 언급된 "은행앱처럼 앱/웹앱 전환", "Flutter 앱", "웹앱", "네이티브", "푸시 기능", "선승인 후차단" 등의 키워드를 기준으로, Baron SSO 승인 로그인에 적합한 개발 방식과 승인 프로세스를 비교한다.

핵심 판단 기준은 다음과 같다.

- 앱은 단순 명료하고 직관적이어야 한다.
- 앱에 많은 기능을 담으려는 순간 `Baron Safe`의 의미가 흐려진다.
- `Baron Safe`의 본질은 "요청 RP와 요청 기기를 확인하고 승인/거절하는 안전 확인 채널"이다.
- 따라서 앱의 1차 기능은 승인 요청 확인, 승인, 거절, 기기 등록/해제 정도로 제한한다.
- 복잡한 관리자 기능, RP 목록 탐색, 일반 포털 기능, 대시보드 기능은 Baron Safe 앱에 넣지 않는다.

## 2. 전제

Baron SSO 사용자는 불특정 다수가 아니라 내부 사용자, 협력사/고객사 사용자, 그리고 Baron SSO 연동 RP를 인지하고 사용하는 등록 사용자로 한정된다. 따라서 앱 설치와 기기 등록은 다소 번거롭더라도 보안상 수용 가능한 절차로 볼 수 있다.

단, 사용자에게 앱 설치를 요구하는 대신 앱은 아주 명확한 가치를 제공해야 한다.

```text
내가 방금 요청한 로그인이 맞는가?
어느 RP가 요청했는가?
어떤 기기/브라우저에서 요청했는가?
승인할 것인가, 거절할 것인가?
```

이 네 가지 질문에 빠르고 안전하게 답하는 것이 `Baron Safe`의 1차 목표다.

## 3. 앱 기능 범위 원칙

### 3.1 반드시 포함할 기능

| 기능 | 설명 |
| --- | --- |
| 기기 등록 | 사용자 계정과 앱 기기를 사전 바인딩 |
| 승인 요청 수신 | Push 또는 앱 내 목록으로 요청 확인 |
| 요청 정보 표시 | RP명, 요청 기기, IP/위치, 요청 시각, 만료 시간 |
| 승인 | 생체 인증/PIN 후 승인 |
| 거절 | 요청자가 본인이 아니면 즉시 거절 |
| 요청 코드 확인 | number matching 또는 request code 입력/확인 |
| 기기 해제 | 분실/교체 시 기기 연결 해제 |

### 3.2 넣지 않는 것이 좋은 기능

| 기능 | 제외 이유 |
| --- | --- |
| 일반 SSO 포털 전체 기능 | 앱 목적이 흐려짐 |
| RP 즐겨찾기/런처 | 승인 앱이 포털 앱으로 변질됨 |
| 상세 감사 로그 전체 조회 | 관리자/웹 포털 영역에 적합 |
| 조직도/프로필/설정 전체 | 앱 복잡도 증가 |
| 자체 메신저/공지 기능 | 푸시 피로도 증가 |
| 다수 메뉴 기반 대시보드 | 사용자가 승인 순간에 집중하기 어려움 |

## 4. 구현 방식 비교

### 4.1 요약 판단

| 방식 | Android/iOS 공통성 | 푸시 신뢰성 | 보안 저장소 | 개발 속도 | 운영 적합성 | 판단 |
| --- | --- | --- | --- | --- | --- | --- |
| 네이티브 앱 | 낮음 | 매우 높음 | 매우 좋음 | 느림 | 매우 좋음 | 장기 고보안 최적 |
| Flutter 앱 | 높음 | 높음 | 좋음 | 빠름 | 좋음 | 1차 권장 |
| React Native 앱 | 높음 | 높음 | 좋음 | 빠름 | 보통 | 대안 |
| PWA/웹앱 | 높음 | 보통/제약 있음 | 제한적 | 매우 빠름 | 제한적 | 단독 인증앱으로 비권장 |
| WebView/하이브리드 | 중간 | 높음 | 네이티브 보완 가능 | 보통 | 보통 | 단순 래핑은 비권장 |

1차 권장안은 `Flutter 앱 + 네이티브 보안 기능 연동`이다. Android/iOS 공통 개발이 가능하고, 기존 `userfront`가 Flutter 기반이라 기술 일관성도 있다. 푸시는 FCM/APNs를 네이티브 앱 수준으로 사용할 수 있다.

PWA/웹앱은 설치와 배포가 쉽지만, 승인 로그인용 인증 장치로 사용하기에는 기기 바인딩, 보안 저장소, 앱 무결성, 푸시 일관성 측면에서 약점이 있다.

## 5. 네이티브 앱

Android는 Kotlin, iOS는 Swift로 각각 개발하는 방식이다.

장점:

- APNs, FCM, Android Keystore, iOS Keychain/Secure Enclave를 가장 직접적으로 제어할 수 있다.
- 생체 인증, 앱 무결성 검증, 백그라운드 알림 처리가 가장 안정적이다.
- 장기적으로 금융앱 수준의 보안 요구에 대응하기 좋다.

단점:

- Android/iOS 개발을 각각 진행해야 한다.
- 동일 기능을 양 플랫폼에서 반복 구현해야 한다.
- 초기 개발 기간과 유지보수 비용이 크다.

적합한 경우:

- 금융앱 수준의 강한 보안 통제와 장기 운영을 최우선으로 할 때
- 플랫폼별 세밀한 보안 정책을 직접 제어해야 할 때
- 충분한 Android/iOS 네이티브 개발 인력이 있을 때

## 6. Flutter 앱

Flutter는 하나의 코드베이스로 Android/iOS 앱을 개발하고, 필요한 보안 기능은 플랫폼 플러그인 또는 Method Channel로 연동하는 방식이다.

장점:

- Android/iOS 공통 UI와 승인 로직을 빠르게 개발할 수 있다.
- 기존 Baron SSO `userfront`가 Flutter 기반이므로 내부 기술 친화성이 높다.
- FCM/APNs, local_auth, secure storage 등 승인 앱에 필요한 주요 기능을 연동할 수 있다.
- 앱 화면을 단순하게 유지하기 쉽다.

단점:

- 일부 보안 기능은 네이티브 플러그인 품질에 의존한다.
- App Attest, Play Integrity, Secure Enclave 세부 제어는 네이티브 연동이 필요할 수 있다.

적합한 경우:

- 1차 MVP를 빠르게 만들고 양 플랫폼을 동시에 지원해야 할 때
- 앱 기능을 승인/거절 중심으로 단순하게 제한할 때
- 플랫폼별 고급 보안 기능은 단계적으로 붙일 계획일 때

권장:

- 1차 Baron Safe는 Flutter로 시작한다.
- 단, private key 생성/보관, 앱 무결성 검증, 생체 인증은 네이티브 플러그인 또는 Method Channel로 신중하게 구현한다.

## 7. 웹앱/PWA

PWA는 웹 기술로 만든 앱을 홈 화면에 설치해 앱처럼 사용하는 방식이다.

장점:

- 앱스토어 배포 없이 빠르게 제공할 수 있다.
- Android/iOS/데스크톱에서 같은 웹 코드로 접근할 수 있다.
- 단순 승인 화면 프로토타입을 빠르게 검증할 수 있다.

단점:

- iOS Web Push는 홈 화면에 추가된 웹앱에서 동작하는 방식이며, 사용자가 직접 홈 화면 추가와 알림 허용을 해야 한다.
- 브라우저/OS별 Push API, Service Worker, 권한 정책 차이가 있다.
- 기기 private key 보호, 앱 무결성, 루팅/탈옥 탐지 등 고보안 요구에 한계가 있다.
- 사용자가 URL만 보고 접근하므로 피싱/가짜 PWA에 취약할 수 있다.

적합한 경우:

- 사전 PoC 또는 내부 데모
- 앱 설치 전 임시 승인 채널
- 낮은 위험도의 보조 확인 화면

비권장:

- Baron Safe의 최종 인증 장치 역할을 PWA만으로 구현하는 것은 비권장이다.
- 특히 "등록 기기에서 서명된 승인"을 핵심 보안 근거로 삼으려면 네이티브 앱 또는 Flutter 앱이 더 적합하다.

## 8. WebView/하이브리드 방식

네이티브 앱 껍데기에 웹 화면을 담는 방식이다. 은행앱처럼 일부 화면은 앱, 일부 화면은 웹으로 전환하는 구조도 여기에 포함된다.

장점:

- 앱 배포 후 UI 일부를 웹에서 빠르게 바꿀 수 있다.
- 네이티브 푸시와 웹 UI를 결합할 수 있다.
- 기존 웹 자산을 재사용할 수 있다.

단점:

- 인증 승인 앱의 핵심 화면이 웹으로 과도하게 넘어가면 보안 경계가 흐려진다.
- WebView 내 세션, 쿠키, 딥링크, 리다이렉트 처리가 복잡해질 수 있다.
- 피싱 화면과 진짜 승인 화면을 사용자가 구분하기 어려워질 수 있다.

권장 방향:

- Baron Safe의 핵심 승인 화면은 앱 네이티브/Flutter 화면으로 유지한다.
- 약관, 도움말, 공지, 기기 관리 안내처럼 보안 민감도가 낮은 화면만 WebView로 처리한다.
- 승인/거절/서명/생체 인증은 WebView가 아니라 앱 네이티브 레이어에서 수행한다.

## 9. 앱/웹앱 전환 방식

회의에서 언급된 "은행앱처럼 앱/웹앱 전환"은 다음 구조로 해석할 수 있다.

### 9.1 웹에서 앱으로 전환

사용자가 웹 로그인 화면에서 전화번호를 입력하면, Baron SSO가 승인 요청을 만들고 앱으로 전환한다.

가능한 방식:

- Universal Links(iOS), App Links(Android)
- 커스텀 URL Scheme
- Push 알림 탭
- QR 코드 스캔

권장:

- 기본은 Push 알림으로 앱을 열게 한다.
- 앱이 이미 설치되어 있으면 Universal/App Link로 바로 열 수 있다.
- 앱이 없으면 설치 안내 페이지로 이동한다.

### 9.2 앱에서 웹으로 복귀

사용자가 앱에서 승인하면 요청 기기 웹 화면은 poll 또는 server push로 승인 상태를 확인하고 로그인 완료를 진행한다.

권장:

- 앱이 요청 기기로 직접 토큰을 전달하지 않는다.
- 앱은 Baron SSO 서버에 승인만 보낸다.
- 요청 기기는 Baron SSO 서버에서 승인 상태를 확인한다.
- 최종 RP 로그인은 기존 Hydra/OIDC 흐름으로 완료한다.

## 10. 푸시 기능 비교

### 10.1 플랫폼별 푸시 구조

| 대상 | 기본 푸시 채널 | 설명 |
| --- | --- | --- |
| Android 네이티브/Flutter | FCM | Google Firebase Cloud Messaging 사용 |
| iOS 네이티브/Flutter | APNs, 또는 FCM 경유 APNs | Apple Push Notification service 사용 |
| Android PWA | Web Push + Service Worker | Chrome/브라우저 기반 |
| iOS PWA | Web Push + Home Screen web app | iOS/iPadOS 16.4 이후 홈 화면 웹앱에서 지원 |

참고:

- Firebase Cloud Messaging은 Android, iOS, Web에 메시지를 보낼 수 있는 공식 서비스다.
- Apple은 iOS/iPadOS 16.4부터 홈 화면에 추가된 웹앱의 Web Push를 지원한다고 설명한다.
- Web Push API는 Service Worker 기반으로 서버가 웹앱에 비동기 메시지를 보낼 수 있게 한다.

### 10.2 푸시 효율성 비교

| 방식 | 도달 안정성 | 즉시성 | 사용자 설정 영향 | 구현 난이도 | Baron Safe 적합성 |
| --- | --- | --- | --- | --- | --- |
| 네이티브 앱 + FCM/APNs | 높음 | 높음 | 알림 권한/절전 정책 영향 | 중간 | 매우 높음 |
| Flutter 앱 + FCM/APNs | 높음 | 높음 | 알림 권한/절전 정책 영향 | 중간 | 높음 |
| PWA Web Push | 중간 | 중간 | 브라우저/홈화면/권한 영향 큼 | 중간 | 제한적 |
| 웹 폴링 | 낮음 | 낮음 | 사용자가 화면을 열어둬야 함 | 낮음 | 보조 수단 |
| SMS | 중간 | 중간 | 통신사/비용/지연 영향 | 낮음 | fallback |

판단:

- 승인 로그인에서 가장 중요한 것은 "요청이 왔을 때 사용자가 빠르게 인지하고 승인할 수 있는가"이다.
- 이 기준에서는 네이티브 앱 또는 Flutter 앱의 FCM/APNs 기반 푸시가 가장 적합하다.
- PWA Web Push는 가능하지만, iOS에서는 홈 화면 추가와 권한 허용이 전제이며, 운영 통제가 네이티브 앱보다 약하다.
- SMS는 앱 미설치자 fallback으로는 가능하지만, Baron Safe의 주 인증 채널로 삼기에는 비용과 보안 한계가 있다.

## 11. 승인 프로세스 선택지

### 11.1 기본 권장: 요청 생성 -> 앱 승인 -> 로그인 진행

프로세스:

1. 요청 기기에서 전화번호 입력
2. Baron SSO가 승인 요청 생성
3. Baron Safe 앱으로 Push 발송
4. 사용자가 요청 정보를 확인
5. 사용자가 승인
6. 앱이 서명된 승인 응답 전송
7. 요청 기기 로그인 진행

장점:

- 가장 명확하고 안전하다.
- 사용자가 요청을 확인한 뒤에만 로그인이 진행된다.
- 감사 로그와 상태 전이가 단순하다.

단점:

- 앱 푸시 지연 또는 사용자가 앱을 보지 않으면 로그인 대기 시간이 발생한다.

권장:

- Baron Safe 기본 프로세스로 채택한다.

### 11.2 선승인 후차단 방식

회의 중 언급된 "선승인 후차단"은 두 가지로 해석될 수 있다.

해석 A:

- 낮은 위험도의 RP는 일단 승인 흐름을 빠르게 진행하고, 이상 징후가 있으면 사후 차단한다.

해석 B:

- 사용자가 사전에 특정 RP/기기를 신뢰 등록해두고, 이후 요청은 자동 승인에 가깝게 처리하되 위험 발생 시 차단한다.

검토:

- 이 방식은 UX는 빠르지만 Baron Safe의 핵심인 "요청별 명시 승인"이 약해진다.
- 전화번호 단독 로그인의 문제를 다시 일부 가져올 수 있다.
- 고위험 RP에는 부적합하다.

허용 가능 조건:

- 동일 기기, 동일 RP, 동일 네트워크 등 낮은 위험 조건이 모두 충족될 때
- 짧은 기간의 trust window 안에서만
- 사용자가 명시적으로 "이 기기에서 24시간 동안 다시 묻지 않기"를 선택한 경우
- 관리자 정책상 허용된 RP에 한정

권장:

- 1차 개발에서는 제외한다.
- 2차 이후 "신뢰 기기/신뢰 RP" 기능으로 제한 검토한다.

### 11.3 선차단 후승인 방식

위험 신호가 있는 요청은 앱에 바로 승인 버튼을 주지 않고, 추가 확인 또는 관리자 확인을 요구하는 방식이다.

예시:

- 평소와 다른 국가/IP
- 짧은 시간 내 반복 요청
- 미등록 RP
- 고위험 관리자 기능 접근

장점:

- 공격성 요청을 사용자가 실수 승인하는 위험을 줄인다.

단점:

- 정책과 UX가 복잡해진다.

권장:

- 1차에서는 위험 요청을 "승인 불가/거절 권고"로 표시하는 정도로 시작한다.
- 관리자 승인까지 포함하는 복잡한 흐름은 후속 단계로 둔다.

## 12. 푸시 피로 공격 방지

Baron Safe는 푸시 기반 승인 앱이므로 푸시 피로 공격을 반드시 고려해야 한다.

필수 대책:

- 사용자별, 전화번호별, IP별, RP별 rate limit
- 같은 요청을 반복 발송하지 않는 collapse key 또는 deduplication
- 승인 화면에 number matching 표시
- 요청 기기 화면에도 동일한 숫자 코드 표시
- 앱에서 해당 숫자를 확인하거나 입력해야 승인 가능
- 반복 요청 발생 시 자동 차단 및 감사 로그 기록
- 고위험 요청은 앱에서 기본 버튼을 "거절" 중심으로 배치

예시 UX:

```text
한맥 ERP 로그인을 승인하시겠습니까?

요청 기기: Chrome on Windows
요청 위치: 203.0.113.xxx
요청 코드: 42

요청 기기에 표시된 숫자와 일치할 때만 승인하세요.

[거절] [승인]
```

## 13. 최종 권고

1차 개발은 다음 방향이 가장 현실적이다.

1. 앱은 Flutter 기반으로 개발한다.
2. 기능은 승인 요청 확인, 승인, 거절, 기기 등록/해제로 제한한다.
3. 핵심 승인 화면은 WebView가 아닌 앱 화면으로 구현한다.
4. Push는 FCM/APNs 기반으로 구현한다.
5. PWA/Web Push는 PoC 또는 fallback으로만 검토한다.
6. 승인 응답은 기기 private key로 서명한다.
7. 앱 승인 전 생체 인증 또는 앱 PIN을 요구한다.
8. 푸시 피로 공격 방지를 위해 rate limit와 number matching을 1차부터 포함한다.
9. 선승인 후차단 방식은 1차에서 제외하고, 신뢰 기기/신뢰 RP 기능으로 후속 검토한다.

Baron Safe는 "작은 앱"이어야 한다. 기능을 많이 넣는 앱이 아니라, 로그인 요청을 안전하게 확인하고 승인하는 단 하나의 일을 확실히 하는 앱으로 설계해야 한다.

## 14. 참고 공식 문서

- Firebase Cloud Messaging: https://firebase.google.com/docs/cloud-messaging
- Firebase Cloud Messaging for Flutter: https://firebase.google.com/docs/cloud-messaging/flutter/get-started
- Apple Notifications: https://developer.apple.com/notifications/
- Web Push for Web Apps on iOS and iPadOS: https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/
- MDN Push API: https://developer.mozilla.org/en-US/docs/Web/API/Push_API
- Android Notifications: https://developer.android.com/develop/ui/views/notifications
- Flutter platform channels: https://docs.flutter.dev/platform-integration/platform-channels
