인트로!
회사에서 지난 해 말부터 일부 기능을 웹뷰 구현방식으로 개발해오고 있는데, 그 과정에서 정리한 레슨런들을 공유해보려고 합니다.
메이저 피쳐 단위로는 처음으로 웹뷰 개발을 진행하다보니 여러 좌충우돌도 있었고, 아직 개선할 부분도 많긴 하지만 저와 같이 웹뷰용 페이지 개발이 처음인 프론트엔드 개발자분들에게는 약간의 웹뷰 미리보기가 되었으면 합니다 😃
+프로젝트 관련해 약간의 배경 설명을 드리면,
이번에 진행한 프로젝트는 기존에 개발되어 있는 앱에 신규 피쳐를 웹뷰로 개발하여 추가하는 방식이었습니다. 요런 약간은 특수한 프로젝트 특성상 발생했던 특이점(?!)도 있었던 점을 미리 밝히고 들어가겠습니다.
이번 게시물은..
- 읽는 데 걸리는 시간 ⌛️
대충 보면 5 min Read, 다 읽으면 12 min Read
- 읽고나서 알 수 있는 것 🧠
웹뷰와 네이티브 앱의 차이점과 장단점, 웹뷰 구현 시 신경써야 할 것들 미리보기
- 미리 알아야 할 것 🎳
React와 React-native를 예시가 일부 나옵니다. 하지만 몰라도 무관합니다!
🔹 Webview 개발 방식이란?
웹뷰 개발방식은 간단하게 말해서 네이티브 앱의 프레임워크에 내장된 <웹 브라우저 컴포넌트>로 뷰(View)의 형태로 앱에 임베딩하여 컨텐츠를 보여주는 구현 방식입니다.
React Native(이하 RN)와 React로 예시를 들면,
RN의 <Webview/> 컴포넌트에 React로 개발된 html 페이지를 임베드해서 컨텐츠를 보여주는 방식입니다. (RN외에 Flutter나 안드로이드/iOS 네이티브 프레임웍에서도 각자 제공되는 웹뷰용 뷰가 존재합니다. UIWebView, WKWebView, SFSafariView, 등등..)
즉 웹페이지를 앱으로 감싼 형태로 생각하시면 이해가 쉬울 것 같습니다.
📌 웹뷰 / plain 웹 차이점은?
먼저 웹페이지 개발시 앱내 웹뷰를 목적으로 개발할 때와, 일반 웹페이지(plain 웹)로 개발할 때 어떤 차이점이 있는지 알아보겠습니다.
1. 앱과 브라우저의 네비게이션 로직 차이
💻 브라우저의 라우팅 : Page 이동 📑
웹에서는 라우트 이동시 대부분 현재 활성화된 브라우저 프로세스 내에서의 페이지 이동만 신경 쓰면 됩니다. 아래와 같은 라우팅 로직이 있습니다.
- 네비게이션 동작 : 페이지 이동, 새탭에서 열기, 새창에서 열기, 뒤로가기📱 앱의 라우팅 : Screen 이동 & Stack 간의 이동 🥞
(앱개발자는 아닌지라 용어나 설명에 모자란 부분이 있을 수 있으니 틀린 부분은 댓글로 짚어주시면 감사하겠습니다 🙇♂️)
반면 모바일 앱에서는 한 가지 추가되는 개념이 Stack입니다.
모바일 앱을 사용하다 보면 화면 전환시 케이스별로 미묘한 차이가 있죠.
예를 들어 게시판에서 게시물을 누르면 상세 화면 스크린이 새롭게 추가되(쌓이는) 경우, 1번 게시물에서 3번 게시물로 바로 화면이 이동되는 경우, 그리고 헤더의 뒤로가기 버튼을 누르거나 iOS에서 좌우 스와이핑시 현재 화면이 사라지고 이전 화면이 드러나는 경우 등등..
브라우저 환경에서 위 내용을 구현했다면 모두 a 링크와 window history back과 같은 단순 라우트 이동으로 가능했을테지만 앱에서는 상황별로 취해야 하는 액션이 달라집니다.
react-navigation의 경우에는 아래와 같은 액션들이 존재합니다.
- 네비게이션 동작 : push, pop, cancel & pop, reset, navigate 등 아래는 위에서 언급한 화면 전환 케이스들의 간단한 예시입니다.
기존 앱 내에 추가되는 페이지들이었기 때문에 위와 같이 화면 이동 케이스를 고려할 필요가 있었습니다.
물론 웹개발자가 단순 웹뷰용 지면만 개발하고 앱개발자에게 라우트 이동 로직을 일임한다면 이 라우팅 로직 차이를 이해하지 않아도 되겠지만, 앱/웹개발자가 협업해서 조금 더 개선된 결과물을 만들기 위해서는 웹개발자도 위 내용을 이해하는 것이 도움이 될 것 같습니다.
2. 앱 ↔️ 웹뷰간의 통신
Window 객체의 postMessage() 메소드를 활용하여 RN앱과 웹뷰 지면(html 페이지. 이 경우 React 어플리케이션)간에 서로 데이터를 교환할 수 있습니다.
앱에서 웹으로 & 웹에서 앱으로 쌍방향 통신이 가능하며, 앱이나 웹에서 발생한 이벤트를 서로 알아야 하거나 데이터를 교환해야 하는 경우에 유용합니다.
예를 들어 웹뷰 지면 내에서 에러 발생시 앱에서 핸들링을 해줘야 하는 경우나 앱에서 초기 데이터를 웹으로 넘겨줘야 하는 경우, 또는 웹뷰에서 페이지 이동이 필요할 때 앱으로 메세지를 보내서 스크린 제어를 하는 등 케이스는 무궁무진합니다.
그렇기에 단순 postMessage를 이벤트 단위로만 필요할 때마다 무한히 늘려가다보면 관리해야 할 케이스가 늘어나고 재사용도 어려워질 수 있습니다. 따라서 확장성을 고려한 메시지 컨벤션 구상이 중요해집니다. (이 부분은 저도 고민되는 부분인지라 코드 예시는 패스하고 중요성만 짚고 넘어갈게요 ^.^)
- 스몰 팁 💁♂️
앱 ➡ 웹 메시지 통신시 유의!
Webview 컴포넌트의 message 인터페이스가 Android는document, iOS의 Safari 웹뷰는window로 각각 상이합니다. 따라서 웹뷰 지면에서 (이 경우 react 소스코드에서) 앱에서 발신한 메시지를 수신할 때 iOS/android 환경에 따른 분기처리를 추가해주어야 합니다. 일종의 크로스 브라우징이라고 할 수 있죠!
💡 Webview 구현 방식의 장점과 단점
실제 프로젝트 진행하며 체감한 포인트 위주로 작성했습니다. 프로젝트 특성과 연결
👍 장점
- 수정이 자유롭다
네이티브앱 업데이트가 불필요하고, 웹 배포시 바로 사용자에게 최신 버전 전달이 가능합니다. 대부분 웹뷰 개발 방식 채택시 가장 큰 유인으로 작용하는 점인 것 같습니다. (유저 반응성 테스트가 빈번하게 필요한 피처의 경우 더더욱)
- 라이브러리 선택 폭이 비교적 넓다
이 부분은 사실 웹뷰 구현방식 그 자체보다는 React / React-Native 의 차이이긴 합니다. 이번 프로젝트에서 차트 UI로 정보를 시각화하는 것이 중요한 부분이었는데, 아무래도 웹뷰로 개발하다보니 React 생태계의 넓은 라이브러리 풀에서 고를 수 있어 꽤나 큰 장점으로 작용했던 것 같습니다.
- 구현 비용 절감
기존에 앱/웹 분리 개발시 비슷한 내용을 앱과 웹에서 각각 구현해야 했다면, 웹뷰로 개발시에는 웹으로 개발하고 모바일앱에서 재사용이 가능합니다. 단순 계산하면 구현 비용이 절반이 된 것이죠?! (물론 네이티브 환경 대응 및 앱내 로직 수정 등등 기타 비용도 고려해야 합니다만. 이 부분은 단점에서 다루도록 하겠습니다)
더불어 데스크톱 UI로 확장하여 개발시에도 반응형으로 구현하거나 코드 재사용 통해 개발 비용을 줄일 수도 있습니다.
- QA 테스팅 생산성 증가
이건 의도한 부분은 아니었으나(?) 생각보다 QA/PM팀의 반응이 좋았던 포인트였습니다. 웹 기반이다보니 웹 배포시 바로 브라우저 상에서 최신 개발본을 확인할 수 있고 브라우저 개발자 도구도 확인할 수 있어 api 테스팅 시에도 유용했습니다. 앱 배포버전 확인이 필요하지 않은 것도 생각보다 커뮤니케이션 비용을 줄일 수 있었던 것 같습니다.
👎 단점
물론 프로젝트 진행하면서 느꼈던 웹뷰 구현 방식의 단점도 꽤 있었습니다. 단점 및 웹뷰이기에 추가로 고려하거나 필요했던 작업들 위주로 정리해보았습니다.
- 네이티브 기능 제약 존재
일부 네이티브 기능 사용이 어려우므로 네이티브와 같은 사용자 경험을 온전하게 주기가 어렵습니다.
HTML 기반인 만큼 상대적으로 반응성이 약하고, 애니메이션등의 다양한 UI 효과를 넣기도 어렵구요.
컴포넌트 태생 자체가 OS에 맞게 일부 기능들을 제외하고 작게 만든 웹브라우저이므로 비교적 낮은 최대 메모리 제한, 렌더링 성능 등의 제약이 있기 때문입니다.
(→ 하지만 이번에 진행한 프로젝트 스콥 내에서는 크게 성능상의 제약 체감하지 못 했습니다. 어떤 피쳐를 개발하는지에 따라 크게 단점으로 작용하지 않을 수도 있을 것 같다는 생각입니다.)
- 상대적으로 느린 페이지 로드 속도
아무래도 큰 마이너스가 될 수 있는 단점인 것 같습니다. 네이티브 앱의 경우 스토어를 통해 이미 빌드된 앱을 다운받아서 실행하므로 페이지가 거의 즉시 보여지는 반면에, 웹뷰는 추가적으로 HTML, CSS, JS 리소스를 다운받아 파싱하고 렌더링하는데에 시간이 소요되므로 페이지 로드 속도가 비교적 느릴 수 밖에 없습니다.
따라서 웹뷰 구현시 페이지 로드 속도를 커버하기 위해 성능적으로는 최적화 및 pre fetching 등 알맞은 렌더링 전략을 채택하는 것이 중요하고, 그 외에 시각적으로 속도를 보정하기 위해 스켈레톤 UI나 로딩 상태에 신경을 쓰는 것도 고려해야 합니다.
- 추가적인 서버 자원 사용
위에서 언급한 것과 같이 웹뷰는 HTML, CSS, JS 리소스 로딩에 대한 추가적인 네트워크 통신이 발생하여 네이티브 앱보다 서버 자원을 더 사용하게 됩니다.
- 내가 웹뷰라는 것을 알리지 마라
네이티브 앱을 다운 받았는데 브라우저와 비슷한 느낌이 들면 사용자 입장에서 앱의 완성도가 약간은 떨어져보일 수 있는 우려가 있는 것 같습니다.
조금 더 높은 완성도를 위해 UI 상에서 보여지는 브라우저의 특징들을 숨겨주는 처리를 해야했는데, 은근히 손이 많이 가는 부분이었습니다. 🤔 처리해야 했던 부분들은..
- 웹 콘텐츠 스케일 조정 (pinch to zoom & zoom-in action 차단)
- 텍스트 long press시 텍스트 선택됨 → user-select: none처리
- link Long touch 막기
- 등등..
(+) SPA여도 MPA 처럼 동작한다?! (아마도 Controversial한 단점..!)
이 부분은 스크린 이동 전략에 따라 차이가 존재할 것 같습니다. 만약 모든 페이지 이동을 웹뷰 지면 내에서 router 이동으로 해결했다면 발생하지 않았을 단점이었겠죠.
다만 이번 프로젝트에서는 페이지(스크린)마다 새로운 컴포넌트를 로드하는 구조로 구현을 했는데(웹뷰에서 페이지 이동 로직 제어시 기기의 백버튼/스와이프 동작에 대한 처리가 어려웠기 때문), 그러다보니 React로 개발된 SPA임에도 MPA처럼 매번 새로운 HTML, CSS, JS를 다운받아서 보여주는 구조가 되었고.. SPA의 이점인 (초기페이지 로드 이후) 페이지 이동이 빠르다는 장점을 보지 못 했습니다. 😅
그리고 이렇게 스크린별로 웹뷰 페이지가 독립적으로 존재하는 구조 때문에 전역적인 상태를 공유하지 못 하므로 상태 최신화가 굉장히 번거로웠습니다.
예를 들어 게시물 리스트 페이지에서 게시물 상세 페이지로 이동하여 게시물 title을 수정하고 게시물 리스트 페이지로 다시 돌아온 경우, 수정된 title로 게시물 리스트의 제목도 최신화가 되어야 할텐데요.
(단순화하면 A스크린 → B스크린으로 이동한 뒤, 뒤로가기 액션(pop screen)을 통해 A스크린으로 포커싱된 경우)
이 경우 A스크린으로 돌아왔을 때 최신 데이터 상태를 보여주기 위해서 추가적인 웹/앱 통신 필요했습니다. 아래 예시 코드와 같이 네이티브 앱에서 webview로 메시지 전달 ➡️ 웹에서 수신하여 상태 최신화 수행하는 방식으로 통신 단계가 추가된 거죠. (아래 코드는 의사 코드 느낌으로 봐주세요..!)
👪 협업시 차이점
프로젝트 진행방식/설계방식에 따른 차이가 크게 존재하는 부분이긴 하지만, 이번 프로젝트 한해서 느꼈던 협업시 차이점도 있었습니다. 이 부분은 간단하게만 리스트업 해봤습니다.
-
앱 ↔ 웹 개발자의 상호 온보딩 과정이 필요하다
각 플랫폼에 대한 앱/웹 개발자의 상호 이해가 있어야 협업이 수월! -
빌드/업데이트시 앱/웹 모두 설정 필요
개발환경 세팅시 앱/웹 양쪽 플랫폼 모두 설정 필요하다
(앱에도 변경사항 있을 시) 테스트 플라이트or 코드푸시 세팅, 웹 배포 모두 필요
-
화면별로 어디까지 네이티브인지 웹인지 추가 파악이 필요
기존 앱 내에 해당 피쳐만 웹뷰 컴포넌트로 구현되었기 때문에 어느 페이지는 네이티브이고, 어느 페이지는 웹뷰인지 헷갈릴 수 있음
✅ 네이티브 OR 웹뷰? 체크포인트
웹뷰로 구현할지, 네이티브로 구현할지 고민하고 있다면 고려해봐야 할 것들은 크게 아래 세 가지 정도인 것 같습니다.
1. 개발 생산성(코드 재사용성)
✔ 모바일 + 앱 + 데스크톱 모두 지원 필요한지?→ 모바일 페이지가 앱 내에서 재사용 가능하고, 데스크톱 화면이 모바일 페이지의 반응형 또는 컴포넌트 단위 재사용성이 높다면 웹뷰 방식의 개발 생산성이 높을 것!
2. 업데이트 빈도
✔ 배포가 빈번하게 일어나야 하는지→ 앱 업데이트는 심사기간 소요된다는 단점(코드푸시 제외)과 업데이트가 잦을 시 사용자 이탈 리스크가 있으므로 업데이트가 얼마나 자주 일어날 것인지 고려하여 선택.
3. 성능
✔ 사용성/속도 측면에서 어느 정도의 완성도가 필요한지 요약하면
- 구현비용 절감 측면에서는 모바일/앱 웹뷰가 동일하거나, 데스크톱 반응형 대응하는 경우 이점이 있다.
- 앱 품질/사용성 측면에서는 네이티브 앱에 가까운 수준으로 구현하기 위해서는 많은 처리가 필요하다.
- 결국에 웹뷰 개발 방식은 여러 구현 전략 중의 하나. 페이지/피쳐에 따라 어떤 것이 유리한지를 잘 따져보고 판단하자.
