웹뷰 개발을 설계하는 방식

앱을 만들기 위한 방식은 다양하게 존재합니다.

순수 네이티브 앱이 존재하느냐? 요즘의 앱 개발에서는 글쎄! 입니다.

예전부터 웹 기술을 사용한 하이브리드 앱이 많이 시도되었고,

현재에는 예전에 비해 이런 하이브리드 앱 개발이 성능도 많이 좋아졌습니다.

네이티브 앱 패키징을 보통 많이 사용하지만, 모든것을 네이티브로 개발하기는 힙듭니다.

그래서 웹뷰를 이용한 개발을 합니다.

그렇다면 웨뷰 개발을 할 때 어떤 부분들을 고려해야할까요?

웹뷰를 사용하는 방식은 3가지 정도로 분류됩니다.

네이티브 컨테이너 + 단일웹뷰

네이티브 앱을 컨테이너로 사용하고 웹앱을 올리는 경우가 있습니다.

이러한 경우 이미 모웹이 있는데 빠르게 앱에 적용하고 싶을 때 많이 사용이 됩니다.

하지만 안드로이드 심사에서는 문제가 많지 않지만 앱스토어에서는 규약 위반 가능성이 있기 때문에

이러한 사항들이 고려사항이 됩니다.

이러한 경우에는 네이티브 기능을 어느정도 탑재하면 통과할 수 있습니다.

ex) 푸시, 카메라, 네이티브인증 (페이스타임, 지문인식 등등)

네이티브 + 멀티웹뷰

화면의 변화가 굉장히 많고, 시기적절할 때 스토어의 심사를 받지 않고 올릴 수 있는 화면을 네이티브 앱에 적용할 때 사용되는 경우이빈다. 이러한 방식을 사용할 때는 웹뷰간 데이터 교환방법을 초기부터 고안해야합니다.

앱에 저장소를 만들고, 웹뷰에게 인터페이스를 제공하는 방법들이 많이 쓰입니다.

EX) 주문목록, 주문서, 결제화면 등등에서는 내용이 바뀌는 경우가 많기 때문에 이런 부분을 고려해 웹 기술을 곁들여 쓰게 됩니다.

우리 코박 서비스에서는 커뮤니티 특성상 HTML 코드를 공통으로 데이터를 받아 사용하기 때문에 게시글 상세화면에서 웹뷰를 사용합니다.

네이티브 + RN(React Native)

스타트업처럼 개발 리소스가 적은 서비스에서는 RN를 사용하는 경우가 많습니다. 하지만 이러한 경우에 네이티브 개발자가 아예 필요 없느냐? 는 문제에 부딪혀보면 네이티브 개발자가 꼭 필요하다는 것을 알게 됩니다.

앱이 크레시가 난다던지, 어떤 문제 때문에 작동하지 않는다던지 등등 이러한 경우에는 일반적인 앱 개발 보다는 더 난이도 있는 코드를 봐야하는 경우가 생기기 때문에, 많은 앱 개발자가 필요한 건 아니지만 역량있는 개발자가 필요합니다.

앱 패키징 아키텍쳐와 무관한 고려사항

1. 네비게이션 룰을 확립하자.

웹은 화면마다 고유한 url을 생성할 수 있습니다. 특정한 화면으로 direct로 접근할 수 있습니다.

하지만 앱은 그렇지 않기 때문에 앱은 실제 어떤 화면이든 어떤 플로우로 상관없이 접근할 수 있는 경로를 만들어 놓는 것이 중요합니다. 그런 것들을 우리는 deep link라고 하고, deep link는 어떠한 경우에는 웹일수도 있고 네이티브 화면일 수도 있습니다.

서비스를 배포하면 사용자에게 앱 업데이트를 강제할 수가 없기 때문에 (강제 업데이트는 엄청나게 큰 결정이됩니다.) 초기에 버전과 관련된 feature들은 네비게이션을 잘 확립하고 모든 화면에 대한 deep link로 가지고 간다면 유연하게 화면을 가져갈 수 있다는것을 알고 있으면 좋습니다.

 

2. 공개용 웹뷰와 내부용 웹뷰를 분리

외부에 공유되는 웹뷰인지? 앱 내에서만 진입할 수 있는 화면인지의 분류를 해야합니다.

이벤트 지면이라면 사용자간의 공유를 하는 경우가 있고, url이 공유되기 때문에 앱 설치 전까지는 여러 데이터들이 url에 노출되는 경우가 생깁니다. 이를 분리하지 않는다면, 내부에서만 쓰는 웹뷰 url에 정보가 포함되어있는 경우가 많아 이런 것들이 외부에 노출되면 보안 이슈를 가지게 됩니다. 따로 분리하는 폴더를 만들어 외부인지 내부인지 성격 규정에 따라 배포 위치를 다르게 하면 보안 이슈등에서 위험 요소를 피할 수 있습니다.

 

3. 개발환경을 구축하자

크롬 브라우저에서 시뮬레이션하고 웹뷰로 작동시킬 때, 웹뷰 내에서는 이상동작을 할 때가 있습니다.

(우리 서비스의 경우, 크롬에서 에디터 기능에 이미지 복붙일 때 잘 올라가는데 디바이스에서 복붙이 제대로 되지 않는 이슈가 있었습니다.)

초기 개발환경을 어떻게 세팅하는지에 따라 이러한 상황을 피할 수 있습니다.

시뮬레이터에서 웹뷰를 개발할 수 있는 환경을 만드는 것도 좋습니다.

이러한 개발환경은 네이티브 개발자들의 도움이 필요합니다.

 

4. 런타임 오류를 수집하라

실제로 디바이스 환경이 브라우저 환경보다 훨씬 더 다양한 상황을 가지고 있습니다.

ios같은 경우에는 상대적으로 디바이스의 갯수도 적고 브라우저도 통일화되어있어서 환경이 몇개 없지만, 안드로이드에서는 다양한 브랜드와 다양한 디바이스가 있기 때문에 더 많은 환경을 가지고 있기도 합니다.

에러가 날 때마다 고객에게 항상 어떤 상황에서 에러가 났고 어떤 디바이스인지 디테일을 물어볼 여건이 충분하지 않습니다.

이런 경우에 미연에 방지하기 위해서는 Sentry라던지 런타임 오류를 수집하는 기능을 가지고 있다면, 오류에 대한 대응도 할 수 있고, 어떤 디바이스에서 문제가 있는지 대비할 수 있습니다.

 

5. 캐싱을 적극적으로 사용하라

네트워크가 순간적으로 작동하지 않는 경우는 상당히 많습니다.

그럴 때 사용자들이 멈춰버리는 앱보다는 무언가 보여줄 수 있는 앱과는 확실히 유저경험이 달라집니다. 데이터는 실제로 서버로부터 온 것인지, 캐싱된 것인지가 다르기 때문에 캐싱을 적용한다면 아키텍쳐 디자인이 달라질 수 있습니다.

하지만 전체적으로 사용자 경험을 끌어올릴 수 있는 가치가 있다면 적극적으로 적용할 수 있는 부분입니다.

 

6. 웹뷰의 라이프사이클을 인지할 수 있는 인터페이스를 설계하라

네이티브 웹에서 웹뷰를 로드시킬 때 로드가 먼저되고, 그 다음에 부르는 네이트브 화면에 가려져서 안 보이는 경우가 있습니다.

예를들자면 텝바의 인터페이스를 보면 2,3번째가 웹뷰고 4번째 탭이 네이티브 화면일 때 2페이지를 나중에 다시 누르는 경우 웹뷰에서 다시 서버에서 데이터를 패치해서 가지고 오고 싶을 때, 웹 기술에서는 사용자가 다시 페이지를 로드하고 있는지를 가져오기가 힘들기 때문에 네이티브에서 노티를 주는 인터페이스를 구축해 놓으면, 향후에 웹에서 그 인터페이스를 사용하며 굉장히 좋은 효과를 이후에 얻을 수 있습니다.

 

7. 앱내의 웹뷰에서의 접근성

웹뷰에서 접근성은 굉장히 중요하기 때문에 고려해서 개발해야합니다.

접근성 부분에서 많은 사용자들이 요청하고있습니다. 개발자의 작은 고려사항들이 서비스에 대한 이미지를 굉장히 많이 끌어올릴 수 있는 부분입니다.

 

관련 강의

React 와 Redux로 구현하는 아키텍쳐와 리스크 관리 강의를 듣고 정리했습니다.