모바일 웹 서비스를 앱으로 확장할 때 회의는 흔히 기술 스택 선택부터 시작합니다. React Native로 만들지, 웹뷰 중심으로 구성할지부터 정하려는 방식입니다. 그러나 요구사항 단계에서 더 먼저 답해야 할 질문은 따로 있습니다. 이 서비스의 어느 화면에서 사용자는 앱다운 조작 경험을 기대하며, 어느 화면은 웹에서 빠르게 고쳐 보여주는 편이 더 나은가입니다.
모든 화면을 네이티브로 다시 구현하면 웹과 앱이 같은 내용을 각각 관리하게 될 수 있습니다. 반대로 모든 화면을 웹뷰로 처리하면 입력, 인증, 알림 진입처럼 앱 안에서 매끄럽게 이어져야 하는 흐름이 약해질 수 있습니다.
따라서 앱 전체에 하나의 구현 방식을 선언하기보다, 화면과 사용자 흐름마다 구현 책임을 나누는 편이 현실적입니다. 이 글의 결정 질문은 하나입니다.
우리 서비스의 각 화면을 네이티브로 만들지, 웹뷰로 재사용할지 어떤 기준과 순서로 결정해야 하는가?
화면 이름보다 사용자가 하려는 일을 먼저 적는다
같은 “페이지”라도 사용자가 하는 일은 다릅니다. 회사 소개나 FAQ는 내용을 읽고 다음 정보를 찾는 화면입니다. 반면 회원가입과 사업자 정보 입력은 여러 항목을 입력하고, 오류를 확인하고, 다음 단계로 이동해야 하는 흐름입니다.
이 차이를 기준으로 화면을 분류하면 기술 논의가 빨라집니다.
| 비교 축 | 네이티브 구현을 우선 검토할 조건 | 웹뷰 재사용을 우선 검토할 조건 |
|---|---|---|
| 사용자 행동 | 여러 입력값을 수정하고 검증하며 다음 단계로 이어진다 | 읽기, 안내 확인, 정보 탐색이 중심이다 |
| 기기 기능 의존도 | 푸시 알림, 생체 인증, 앱 내부 라우팅처럼 기기와 앱 상태가 중요하다 | 별도 기기 기능 없이 콘텐츠를 보여주는 역할이 크다 |
| 콘텐츠 변경 빈도 | 화면 구조와 동작 규칙이 비교적 안정적이다 | 문구, 배너, 안내, 정책처럼 웹에서 수시로 고칠 내용이 많다 |
| 배포 부담 | 앱 업데이트와 검증을 감수할 만큼 사용자 경험의 중요도가 높다 | 작은 콘텐츠 변경까지 앱 배포 과정에 묶고 싶지 않다 |
이 표는 자동 판정표가 아닙니다. 다만 팀이 “이 화면은 앱에 있으니 네이티브로 만든다” 또는 “기존 웹이 있으니 그대로 띄운다”는 식으로 결정하는 일을 막아 줍니다.
예를 들어 회사 소개, FAQ, 블로그, 릴리즈 노트, 파트너 등록 안내처럼 정보 전달 비중이 큰 화면은 웹뷰 후보로 분류할 수 있습니다. 웹 콘텐츠를 바꿀 때 앱 화면까지 따로 고치고 배포해야 하는 부담을 줄일 여지가 있기 때문입니다.
반면 약관 동의, 아이디와 비밀번호 입력, 사업자등록번호 검증처럼 사용자가 여러 번 입력하고 오류를 수정하는 구간은 네이티브 구현을 우선 검토할 이유가 있습니다. 이 구간에서는 화면의 모양보다 키보드, 포커스 이동, 오류 메시지, 제출 동작이 사용 경험을 좌우합니다.
입력 화면은 디자인보다 실패 장면으로 평가한다
가입이나 등록 흐름을 검토할 때 “입력 필드가 몇 개인가”만 세면 판단이 부족합니다. 사용자가 어느 순간 멈추거나 다시 입력해야 하는지를 확인해야 합니다.
가령 여러 단계의 가입 흐름에서는 다음 상황이 함께 발생할 수 있습니다.
- 키보드가 올라온 뒤 현재 입력칸이나 오류 메시지가 가려진다.
- 다음 입력칸으로 이동했지만 화면이 따라가지 않는다.
- 하단의 계속하기 또는 제출 버튼이 키보드 뒤에 숨는다.
- 체크박스와 작은 아이콘은 보이지만 누르기 어렵다.
- 검증 실패 문구는 표시되지만 사용자가 무엇을 고쳐야 하는지 알기 어렵다.
React Native의 KeyboardAvoidingView는 가상 키보드가 나타날 때 높이, 위치 또는 하단 여백을 조정할 수 있습니다. 다만 iOS와 Android는 이 동작을 다르게 처리할 수 있습니다. 따라서 키보드 대응 컴포넌트를 적용했다는 사실만으로 입력 품질을 판단하기는 어렵습니다.
요구사항에는 “키보드 대응”처럼 넓은 표현 대신 확인 장면을 적는 편이 좋습니다. 예를 들면 다음과 같습니다.
- iOS와 Android에서 마지막 입력칸이 키보드에 가려지지 않아야 한다.
- 오류가 난 항목으로 이동했을 때 오류 문구와 수정 대상이 함께 보여야 한다.
- 약관 라벨을 눌러도 선택 동작이 가능해야 한다.
- 제출 중에는 같은 요청이 반복되지 않아야 한다.
이런 항목은 개발 후반의 디자인 QA 목록이 아닙니다. 해당 흐름을 웹뷰로 둘지 네이티브로 구현할지 판단하는 요구사항입니다.
웹뷰는 재사용 범위와 이동 규칙을 함께 정해야 한다
웹뷰는 기존 모바일 웹을 앱 안에서 보여줄 수 있는 선택지입니다. 하지만 URL을 열어 주는 것만으로 화면 책임이 정리되지는 않습니다. 앱 헤더와 웹 헤더가 겹치거나, 웹의 링크가 예상하지 못한 외부 화면으로 이동하거나, 웹에서 시작한 행동이 앱의 다음 단계와 연결되지 않으면 사용자는 흐름이 끊겼다고 느낄 수 있습니다.
웹뷰를 쓰기로 했다면 다음 네 가지를 화면 명세에 남기는 편이 좋습니다.
-
앱 안에서 허용할 경로
어떤 페이지를 웹뷰로 열지 정합니다. 정보성 페이지를 허용하더라도 로그인, 인증, 외부 도메인처럼 별도 판단이 필요한 경로는 구분해야 합니다. -
앱과 웹 중 누가 화면 장식을 맡는지
앱이 네이티브 헤더를 제공한다면, 웹은 앱 안에서 열렸을 때 자체 헤더나 푸터를 숨길 수 있어야 합니다. 웹뷰 진입 여부를 쿼리 파라미터나 쿠키 같은 식별 정보로 전달하는 방식도 검토할 수 있습니다. -
웹에서 네이티브로 넘길 행동
안내 페이지는 웹뷰로 제공하되, 사용자가 등록이나 가입을 시작하는 시점에는 네이티브 화면으로 넘길 수 있습니다. 이때 어떤 버튼과 URL을 앱 라우팅으로 전환할지 정하지 않으면 화면마다 예외 처리가 생깁니다. -
외부 인증 후 돌아올 위치
외부 본인인증 모듈처럼 웹 기반 흐름을 거쳐야 하는 경우도 있습니다. 인증 결과 URL에서 어떤 식별값을 읽고, 사용자를 어느 가입 단계로 돌려보낼지 합의해야 합니다.
웹뷰의 장점은 정보성 화면을 기존 웹 운영 흐름 안에서 관리할 수 있다는 데 있습니다. 대신 앱과 웹의 경계가 불분명하면 유지보수 부담이 사라지는 것이 아니라 다른 형태로 옮겨 갈 수 있습니다.
푸시 알림은 알림 화면과 별도로 설계한다
앱 안에 알림함 화면이 있다고 해서 잠금 화면이나 알림 센터에 푸시가 도착하는 것은 아닙니다. 사용자가 앱을 열지 않은 상태에서 알림을 받고, 그 알림을 누른 뒤 목적 화면까지 이동하게 하려면 별도 요구사항이 필요합니다.
특히 계약, 견적, 채팅처럼 응답 시점이 중요한 서비스라면 다음을 분리해 적어야 합니다.
- 사용자가 알림 권한을 언제 요청받는가
- 발급된 디바이스 토큰을 서버에 언제 등록하고 갱신하는가
- 로그아웃 시 토큰을 어떻게 처리하는가
- 기존 알림톡이나 다른 알림 발송 지점과 앱 푸시를 어떻게 연결하는가
- 앱이 종료된 상태에서 푸시를 누르면 어느 화면으로 이동하는가
- 권한을 거부한 사용자는 앱 안에서 어떤 안내와 알림함을 보게 되는가
여기서 중요한 검증 장면은 콜드 스타트입니다. 앱이 완전히 종료된 상태에서 사용자가 푸시를 눌렀을 때, 알림 페이로드에 담긴 정보가 올바른 화면으로 이어져야 합니다. 이 이동이 불안정하면 알림을 보냈더라도 사용자를 필요한 업무 화면까지 데려가지 못합니다.
구현 전에는 화면 목록 대신 전환 지도를 만든다
요구사항 단계에서 먼저 만들 문서는 전체 화면 목록만이 아닙니다. 웹뷰와 네이티브 화면이 어디서 만나고 갈라지는지 보여 주는 전환 지도입니다.
다음 순서로 정리하면 논의가 구체화됩니다.
-
각 화면의 사용자 목적을 한 줄로 적습니다.
읽기, 탐색, 입력, 검증, 인증, 알림 확인 중 무엇이 핵심인지 표시합니다. -
네 가지 비교 축으로 화면을 평가합니다.
입력 마찰, 기기 기능 의존도, 변경 빈도, 앱 배포를 감수할 이유를 검토합니다. -
웹뷰와 네이티브 사이의 이동 지점을 표시합니다.
예를 들어 안내 웹뷰에서 가입 네이티브 화면으로 넘어가는 시점, 외부 인증 웹뷰에서 가입 단계로 돌아오는 시점을 흐름도로 남깁니다. -
같아야 하는 로직과 달라도 되는 로직을 나눕니다.
입력 검증, 오류 문구, API 호출 조건, 중복 요청 방지처럼 일관되어야 하는 규칙은 공통 명세나 공통 코드로 관리합니다. 플랫폼별로 다르게 동작시키기로 한 부분은 이유와 조건을 함께 기록합니다. -
위험한 상태부터 검증합니다.
키보드가 열린 상태, 네트워크가 지연된 상태, 앱이 종료된 상태에서 푸시로 진입하는 경우, 외부 인증에서 돌아오는 경우, 뒤로 가기 동작을 우선 점검합니다.
요구사항 문서에 “FAQ는 웹뷰”라고만 적어 두면 다음 질문이 남습니다. 앱 헤더는 누가 보여주는지, 링크는 어디로 이동하는지, 웹에서 가입 버튼을 누르면 무엇이 일어나는지 알 수 없기 때문입니다.
반대로 “FAQ는 앱 헤더를 사용한 웹뷰로 제공하고, 등록 시작 버튼은 네이티브 가입 흐름으로 전환한다”까지 적으면 개발, 디자인, QA가 같은 경계를 공유할 수 있습니다. 앱 전환의 첫 결정은 기술 이름이 아니라 이 경계를 합의하는 일에서 시작합니다.
