모바일 신분증으로 이어지는 비대면 가입
실물 신분증 외에 모바일 신분증으로 인증할 수 있도록 Web2App 연동을 제안했습니다. iOS, Android 담당자와 앱 이동과 복귀 규격을 맞추고, WebView 화면부터 Spring Boot 서버 연동까지 구현했습니다.
고객의 인증 수단과 이후 운영 방식을 함께 고려했습니다
기존에는 실물 신분증 중심으로 인증해야 했습니다. 모바일 신분증을 추가하면서 App2App과 Web2App 중 어떤 방식이 개발 일정과 이후 유지보수에 적합한지 비교했습니다.
App2App은 OS별 네이티브 개발과 앱 심사 일정의 영향을 받았습니다. 웹에서 수정할 수 있는 범위를 늘리고 운영 변경에 빠르게 대응하기 위해 Web2App을 제안했고, 선임 검토 후 채택됐습니다.
| 비교 | App2App | 선택한 Web2App |
|---|---|---|
| 변경 중심 | OS별 네이티브 연동 | 웹 화면과 서버 로직 |
| 배포 의존성 | 네이티브 수정과 심사 일정 | 웹 변경은 웹 배포 / 브리지 수정은 네이티브 배포 |
| 초기 협업 | iOS 및 Android 담당자 | iOS 및 Android 브리지 담당자와 초기 연동 |
앱으로 이동하고 돌아오는 규격을 맞췄습니다
WebView의 앱 호출과 복귀 화면, Spring Boot의 인증 결과 검증 및 토큰 연동을 담당했습니다. iOS와 Android의 브리지 구현은 각 네이티브 담당자와 협업했습니다. 콜백 시점과 데이터 형식의 차이를 확인하고 전달 규격을 조율했습니다.
앱과 WebView 사이의 세션, 토큰 전달뿐 아니라 서버 구간마다 다른 응답 형식도 맞춰야 했습니다. Spring Boot 서버의 인증, 검증, 토큰 처리와 화면 연동을 함께 맡았습니다.
- WebView: 인증 시작
- 네이티브 브리지: 외부 앱 호출
- 모바일 신분증 앱: 인증
- 앱 복귀: 결과 전달
- Spring Boot: 인증 결과 검증
- WebView: 가입 흐름 계속
문서에서 불명확한 부분은 연동 기관에 확인했습니다
개발 가이드만으로 판단하기 어려운 규격은 담당 기관에 직접 문의했습니다. 각 통신 구간에서 전달하는 값과 응답 처리 방식을 확인하면서 화면과 서버의 데이터를 맞췄습니다.
웹 개발 범위가 늘어나는 선택이었지만, 이후 웹에서 처리 가능한 변경은 네이티브 양쪽을 수정하는 부담을 줄일 수 있다고 판단했습니다.
2025년 9월부터 10월까지 모바일 신분증 인증을 구현하고 운영 배포했습니다. 초기 연동에는 네이티브 담당자와 협업했고, 이후 웹 로직 변경은 웹 배포로 대응할 수 있도록 구성했습니다.
네이티브 브리지를 바꿔야 하는 작업과 웹 배포로 반영할 수 있는 작업을 구분해, 변경 내용에 맞는 배포 경로를 정리했습니다.
지금 팀이 풀고 있는
문제는 무엇인가요?
서비스 출시 부터 운영까지,
제가 기여할 수 있는 일을 함께 하고 싶습니다.
