모바일 웹의 핵심 화면이 잘 작동하는데도 앱을 검토하게 되는 순간이 있습니다. 사용자가 서비스 밖에 있을 때 중요한 상태 변경을 놓치거나, 로그인과 인증 흐름이 모바일 환경에서 반복적으로 끊기거나, 카메라·파일·알림 같은 기기 기능이 제품 흐름의 일부가 되는 때입니다.
이때 CTO나 개발 리드가 답해야 할 질문은 “어떤 앱 기술이 최신인가”가 아닙니다. 웹의 어느 기능을 그대로 유지하고, 어느 사용자 경험부터 앱의 책임으로 옮길 것인가입니다.
Next.js 모바일 웹을 앱으로 전환하는 선택지는 PWA, 웹뷰 기반 앱, Expo/React Native, iOS·Android 네이티브로 나뉩니다. 네 방식은 모두 사용할 수 있지만, 알림·인증·기기 기능·운영 역량이라는 네 축에서 감당해야 할 비용과 위험이 다릅니다.
앱 전환 전에 먼저 분리할 두 가지
앱 전환 논의가 길어지는 이유는 보통 “모바일 웹 전체를 앱으로 다시 만들어야 하는가”와 “알림 문제를 해결해야 하는가”를 같은 문제로 다루기 때문입니다. 둘은 분리해서 판단하는 편이 낫습니다.
첫째, 앱 전환의 목적을 한 문장으로 적어야 합니다. 예를 들면 계약 승인, 업무 요청, 예약 변경처럼 사용자가 늦게 확인하면 손실이 생기는 이벤트를 제때 전달하려는 것인지, 아니면 더 빠르고 앱다운 화면 경험을 제공하려는 것인지 구분합니다.
둘째, 그 목적을 이루기 위해 앱 화면이 꼭 필요한 범위를 정합니다. 알림을 눌렀을 때 특정 상세 화면으로 이동하는 흐름만 앱이 맡으면 되는지, 로그인 이후의 주요 업무 화면 전체를 앱으로 옮겨야 하는지에 따라 선택지가 달라집니다.
여기서 “앱을 만든다”는 말은 하나의 결정이 아닙니다. 앱 패키지, 인증 상태, 알림 수신, 딥링크, 화면 구현, 배포와 장애 대응을 각각 어디에서 맡을지 정하는 여러 결정의 묶음입니다.
네 가지 방식은 전환 범위가 다르다
| 방식 | 웹과 앱의 관계 | 우선 검토할 조건 | 주된 확인 과제 |
|---|---|---|---|
| PWA | 웹을 중심으로 유지 | 앱 패키지보다 웹 경험의 연속성이 우선일 때 | 목표 기기·브라우저·배포 환경에서 알림, 인증, 설치 경험이 요구사항을 충족하는지 |
| 웹뷰 기반 앱 | 기존 웹을 앱 컨테이너 안에서 사용 | 화면 재구현보다 빠른 전환 범위 검증이 우선일 때 | 로그인 콜백, 외부 브라우저 이동, 뒤로 가기, 알림 클릭 후 목적 화면 이동 |
| Expo/React Native | 앱 화면은 별도로 구현하되 React 기반 자산을 일부 공유 | 앱 경험이 필요하지만 iOS·Android를 한 팀이 함께 운영해야 할 때 | 공유할 코드와 플랫폼별로 남길 코드를 처음부터 분리하는 일 |
| 네이티브 | iOS와 Android를 각 플랫폼 방식으로 구현 | 플랫폼 기능, 각 OS 도구, 세밀한 제어가 제품 경쟁력에 직접 연결될 때 | Swift와 Kotlin 두 구현을 유지·검증할 인력과 릴리스 체계 |
이 표에서 중요한 점은 네이티브가 언제나 더 좋고, 웹뷰가 언제나 임시방편이라는 식으로 순위를 매길 수 없다는 것입니다. 전환의 목표가 다르기 때문입니다.
예를 들어 앱 전환의 이유가 중요한 알림이라면, 화면을 얼마나 많이 네이티브로 다시 만들었는지보다 알림 권한 획득, 수신 상태, 알림을 누른 뒤의 이동, 로그아웃 사용자 처리까지 끊기지 않는지가 더 중요합니다. 반대로 앱의 핵심 가치가 기기 기능과 플랫폼별 화면 경험에 있다면, 웹을 많이 재사용하는 편의가 장기 비용을 줄여 주지 않을 수 있습니다.
알림은 “보내기”가 아니라 상태별 동작으로 검증해야 한다
Expo의 푸시 알림 기능도 iOS와 Android의 네이티브 알림 동작 위에서 작동합니다. Expo Go만으로 푸시 알림을 검증할 수 없고, 개발 빌드가 필요합니다. 이 사실은 Expo를 선택할지 여부보다 더 넓은 의미를 갖습니다. 알림은 프론트엔드 화면에서만 확인할 기능이 아니라는 뜻입니다.
알림 검증 계획에는 최소한 다음 상태를 넣는 편이 좋습니다.
- 앱이 화면에 떠 있을 때 알림을 어떻게 보여 줄지
- 앱이 백그라운드에 있을 때 운영체제가 보여 주는 알림을 눌렀을 때 어디로 이동할지
- 앱이 종료된 상태에서 알림을 눌렀을 때 인증과 화면 이동을 어떤 순서로 처리할지
- Android에서 사용자가 시스템 설정으로 앱을 강제 종료한 뒤에는 알림 동작에 제한이 있을 수 있다는 점을 어떻게 안내하고 대응할지
- 사용자가 알림 권한을 거부했을 때 핵심 업무를 어떤 다른 경로로 전달할지
특히 B2B 서비스는 “알림이 도착했는가”보다 “누가 어떤 업무를 확인해야 하는가”가 중요합니다. 알림을 받은 사람이 권한이 없거나, 이미 처리된 업무를 열거나, 인증이 만료되어 목적 화면에 도달하지 못하면 알림 인프라가 정상이어도 제품 흐름은 실패합니다.
Expo/React Native를 고를 때는 UI 공유율보다 의미 공유를 본다
React Native는 iOS와 Android에서 구현을 공유하는 비용 절감 수단으로 널리 선택되어 왔습니다. Shopify 역시 React Native 도입으로 기능을 한 번 구현하고, 모바일 경험이 적은 개발자도 기여하며, 플랫폼 간 기능 차이를 줄이는 데 도움을 받았다고 설명했습니다.
다만 Shopify는 이후 자사 조건에서 네이티브 전환을 선택했습니다. 코딩 모델의 발전으로 두 플랫폼 구현 간 변환과 검증 비용이 달라졌고, 플랫폼 기능과 공식 도구에 가까이 가는 이점이 더 커졌다는 판단입니다. 그렇다고 React Native가 부적합하다는 결론은 아닙니다. 같은 기술도 조직 규모, 플랫폼 전문 인력, 앱의 핵심 기능, 유지보수 방식에 따라 결론이 달라진다는 사례에 가깝습니다.
Next.js 팀이 Expo/React Native를 검토한다면, 다음처럼 나누는 편이 현실적입니다.
- 공유 후보: API 호출 규칙, 도메인 타입, 입력 검증 규칙, 에러 문구, 분석 이벤트 이름, 디자인 토큰
- 분리 후보: 웹 DOM에 의존하는 컴포넌트, 포커스와 포털 처리, 브라우저 전용 라우팅, iOS·Android 화면 전환과 제스처
- 별도 검증 대상: 알림 권한, 기기 토큰 등록, 딥링크, 스토어용 빌드와 배포 과정
여기서 흔한 실패는 React를 쓴다는 이유만으로 웹 UI 컴포넌트와 앱 UI 컴포넌트를 하나로 묶으려는 일입니다. 웹과 네이티브는 화면을 그리는 기반과 상호작용 방식이 다릅니다. 구현체를 억지로 통합하기보다, 색상·간격·타이포그래피 같은 디자인 토큰과 비즈니스 규칙의 이름을 맞추는 편이 관리하기 쉬운 경우가 많습니다.
네이티브 전환은 기능 요구보다 운영 능력에서 결정된다
Swift와 Kotlin으로 각각 구현하는 방식은 플랫폼 기능과 공식 도구에 더 가깝게 작업할 수 있다는 장점이 있습니다. 대신 iOS와 Android를 두 구현으로 유지해야 하는 사실 자체는 사라지지 않습니다.
AI 코딩 도구가 플랫폼 간 구현을 돕더라도, 제품 책임이 자동으로 줄어들지는 않습니다. 두 플랫폼에서 같은 인증 정책이 적용되는지, 알림을 눌렀을 때 같은 업무 상태를 여는지, 오류와 분석 로그가 같은 기준으로 남는지는 팀이 계속 확인해야 합니다.
따라서 네이티브는 다음 조건이 겹칠 때 더 진지하게 검토할 만합니다.
- 특정 OS 기능과 시스템 도구를 제품의 핵심 경험으로 사용해야 한다.
- iOS와 Android의 차이를 흡수할 모바일 전문 인력 또는 유지보수 체계가 있다.
- 앱의 주요 화면과 상호작용을 장기적으로 플랫폼별로 다듬을 계획이 있다.
- 프레임워크와 외부 의존성을 한 겹 더 두는 것보다 플랫폼에 직접 맞추는 편이 더 중요한 제품이다.
반대로 현재 목표가 알림 기반 재방문 흐름을 검증하고, 웹의 업무 규칙을 최대한 유지하는 데 있다면 네이티브 전체 재구축부터 시작할 이유는 약합니다.
기술 선택보다 먼저 합의할 전환 로드맵
탐색 단계에서는 한 번의 아키텍처 결정으로 모든 화면의 운명을 정하지 않는 편이 안전합니다. 다음 순서로 범위를 좁혀 보십시오.
-
놓치면 문제가 되는 이벤트를 고릅니다. 단순 공지와 업무 마감, 승인 요청, 결제 상태 변경을 같은 알림으로 취급하지 않습니다.
-
알림을 받은 뒤 완료해야 할 행동을 정의합니다. 사용자가 알림을 누른 뒤 로그인, 권한 확인, 상세 확인, 처리 완료까지 어떤 흐름을 지나야 하는지 적습니다.
-
그 흐름 하나를 후보 기술로 검증합니다. 웹뷰든 Expo든 네이티브든, 앱 종료 상태와 인증 만료 상태를 포함해 확인해야 합니다.
-
공유 자산의 경계를 문서화합니다. “공유한다”가 아니라 어떤 타입, 규칙, 토큰, API 계층을 공유하고 어떤 UI 구현은 분리할지 적습니다.
-
운영 주체를 지정합니다. 푸시 발송 실패, 인증 오류, 스토어 빌드 문제, OS 업데이트 대응을 누가 어떤 로그로 확인할지 정합니다.
앱 전환의 첫 산출물은 완성된 앱이 아니라, 중요한 사용자 흐름 하나가 어떤 조건에서 실패하는지 보여 주는 검증 결과여야 합니다. 그 결과를 바탕으로 웹뷰에서 멈출지, Expo/React Native로 화면을 확장할지, 네이티브 역량에 투자할지를 정하면 기술 선택이 제품 요구와 분리되지 않습니다.
