인프콘2023

웹앱과 모바일 앱의 구조 차이를 도표로 보여 주며 브릿지(bridge) 개념을 꺼낸다. 둘 다 네이티브 플랫폼·OS 위에서 동작하는데, 그 사이에서 네이티브와 웹이 소통하게 해 주는 인터페이스가 브릿지다. 개발자가 굳이 신경 쓰지 않아도 되는 도구로, 이를 통해 시스템 API를 호출할 수 있다. 플러터·리액트 네이티브가 스위프트·코틀린 코드를 호출하는 것도 같은 원리이며, 웹뷰는 자바스크립트를 통해 네이티브 기능과 통합 할 수 있다는 점이 가장 큰 장점이다. 대표적인 브릿지로 윈도우 객체의 postMessage 를 든다. 윈도우 객체에 이벤트를 바인딩해 두면 postMessage가 전달한 메시지를 받을 수 있다는 것 하나만 기억해도 많은 기능을 적용할 수 있다. 웹뷰의 진짜 강점은 양방향 개발이 아니라 웹앱과 완전히 격리된 샌드박스 환경 이라는 점이다. 웹뷰 내 런타임 에러로 웹사이트가 꺼져도 앱은 꺼지지 않고, 서버가 죽어도 앱은 살아 있어 개발자가 웹뷰를 독립적으로 핸들링할 수 있다. 그래서 웹뷰를 쓰면 웹 서비스 코드가 웹뷰를 거쳐 네이티브 앱과 소통하므로 네이티브 앱의 모든 기능을 활용하듯 확장성 있게 구현할 수 있다.

앱을 만들기 전 마주하는 리액트 네이티브 대 플러터 논쟁을 다룬다. 리액트 네이티브는 아직 메이저 버전(0.7x대)에 오르지 못한 채 패치를 이어 가고, 플러터 는 구글 주도로 코드 푸시까지 모든 플랫폼에 적용한다. 스택오버플로 추세상 초기엔 메타의 힘으로 리액트 네이티브가 압도적이었으나 2023년 메타가 손을 떼 커뮤니티 팀으로 넘어갔고 플러터는 꾸준히 상승 중이다. 발표자는 이런 의사결정에 지치지 말라며 극단적으로 단순한 기준 을 제시한다. 웹 서비스 없이 앱을 만들고 iOS·안드로이드 개발자를 뽑을 리소스가 없으면 플러터, 웹 서비스가 있거나 리액트를 해 봤다면 리액트 네이티브 를 하라는 것이다. 기술적 숙련도보다 현실적으로 가능한 수단이 중요하며, 이 발표는 리액트 청중을 위해 리액트 네이티브로 준비했다고 밝힌다. 리액트 네이티브도 웹뷰처럼 프로퍼티와 메서드 로 양방향 메시지를 주고받는다. 앱 쪽의 injectedJavaScript 는 웹뷰가 웹을 열 때 스크립트를 먼저 주입·실행시키고, 웹에서 앱으로 보낼 때는 HTML이 postMessage 를 호출하고 앱 쪽 웹뷰의 onMessage 가 받아 처리한다. 이렇게 하면 웹 코드를 수정하지 않고도 웹뷰에서 임의로 핸들링 할 수 있다.

시작 방법으로 Expo 를 권한다. 순수 리액트 네이티브는 커스텀 설정을 모두 직접 해야 해 번거롭지만, Expo는 그 위에 편한 워크플로를 얹은 툴이다. Expo CLI로 프로젝트를 생성하고 react-native-webview 를 설치하면 적은 변경만으로 웹 서비스가 "앱"이 되지만, 노치에 화면이 가려지고 스크롤·스와이프가 이상하며 인터넷이 끊기면 하얀 화면이 떠 죽은 것처럼 보이는 피드백이 돌아온다. 그래서 개발이 필요하다. 핵심은 웹의 사고방식을 버리는 것 이다. 앱은 브라우저가 아니라 라우팅이 없으므로 URL·라우팅 설계를 버리고 그 역할을 내비게이션 으로 대체한다. 앱은 메모리에서 스크린을 스택으로 관리 하며, 최상위 NavigationContainer 하위에서 스택 내비게이션, 드로어 내비게이션, 바텀 탭이 동작한다. 각 내비게이션은 스크린에 navigation·route 를 주입하고, 풀스크린 웹뷰가 아닐 때는 useNavigation·useRoute 훅 으로 동일하게 핸들링한다. 실습으로는 흔한 투두 대신 RealWorld 앱을 가져와 "최소한의 개발로 최대한 빠른 릴리즈"를 추구한다. 웹은 헤더를 고정하지만 모바일에서는 그 역할을 드로어(햄버거 메뉴) 가 대신하므로 라우팅을 일으키는 웹 헤더는 보통 쓰지 않기로 한다.

구체적으로 웹에서 앱(웹뷰)인지 판단 하는 방법으로 윈도우 객체의 userAgent, 웹뷰가 주입하는 window.ReactNativeWebView 존재 여부, 스크린 max 크기 체크를 든다(모바일 웹 반응형과 구분하려면 조건 결합). 웹 코드에서는 Next.js 라우터를 한 번 더 래핑 해 웹뷰일 때는 postMessage를, 아닐 때는 router.push를 호출하며, 로그인·회원가입 후에는 replace로 정리한다. 앱 쪽에서는 onMessage 핸들러의 nativeEvent 문자열을 JSON 파싱한 뒤 StackActions.push·dispatch 로 화면을 제어한다. 로그인 유저 제어 는 중첩 내비게이션과 저장소로 다루며, 정보 저장은 반드시 로컬 스토리지/AsyncStorage 를 써야 앱 종료 후에도 데이터가 살아 있다. 알림 은 로컬과 푸시로 나뉘는데, 푸시 알림 은 구글·애플 정책상 보통 외부 푸시 알림 서버 를 두고 HTTP로 소통하며, 권한 확인·요청 후 유저별 푸시 토큰 을 DB에 저장해 발송한다. 빌드는 EAS Build 한 줄로 끝나지만 iOS 번들은 유료 라 안드로이드를 먼저 올리길 권한다. 출시 시 애플은 "웹과 똑같은데 왜 앱이냐"는 피드백을 주므로 최소한의 네이티브 기능(알림 등) 개발이 필요하다. 마지막으로, 웹뷰 앱은 부족해도 일단 동작하니 시작할 수 있되, 파일·카메라·화면 보호·버전 관리·로그 수집을 더하고 네트워크에 취약한 부분을 점차 네이티브로 끌어내려야 하며, 제대로 확장하려면 네이티브 개발자가 반드시 있어야 한다 는 "만고불변의 진리"로 마친다.