Native와 Web의 결정적 차이
feat. 네이티브 or 웹의 기술 및 운영적 관점
APP을 만들어서 사람들이 사용하는 것은 서비스 개발 관점에서 바라봤을 시 개발한 앱을 iOS의 앱스토어 및 Android의 플레이스토어에 등록하여 사용자들의 앱을 다운로드하고, 자신의 스마트 디바이스에 설치한다라고도 볼 수 있다.
※. 네이티브 개발자가 존재하는가?
기획하고자 하는 APP에 구조가 전체 “네이티브” 가 되었든 전체 “웹뷰”로 되었는 또는 “네이티브” 와 “웹뷰”가 함께 섞여있는 하이브리가 되었는 간에 앱스토어 또는 플레이스토어에 등록할 수 있도록 패키징 처리 및 앱스토어 등록을 할 수 있는 네이티브 개발자는 반드시 필요하다.
[네이티브와 웹의 차이는 무엇일까?]
실제 하나의 앱이 사용자들에게 설치되기 위해서는 하나의 보따리 형태로 패키징 되어 iOS의 앱스토어 및 Android의 플레이스토어에 등록되어야 한다. 이때 패키징이라는 보따리 안에는 다양한 개발소스들이 구조화되어 있다. 그런데 만약 보따리 안에 내용들이 잘못되어 변경이 필요하거나, 추가적인 내용들을 더 담을 경우에는 어떤 상황이 일어날까? 간단하게 추가 수정 처리를 할 수 있을까? 답은 간단하지 않다는 것. 한번 등록된 앱의 수정을 하기 위해서는 위에서 언급한 보따리를 다시 싸서 재등록을 해야 하는 과정이 필요하기 때문이다. 이때 여기서 네이티브와 웹에 극명한 차이가 발생한다.
[수정된 내용이 네이티브인 경우]
간단한 예시로써, 만약 백오피스에서 동적으로 변경할 수 있는 이미지나 텍스트가 아닌, 실제 화면의 Look & Feel에 영향을 주는 폰트의 스타일, 크기, 컬러, 사이즈 및 화면을 구성하는 UI 및 Layout의 변경이 있을 경우, 네이티브 화면은 개발자가 직접 코드를 수정하여 다시 앱스토어에 재 등록 해야 한다.
이때 웹과 가장 큰 차이가 발생하는데 그것은 “즉. 시. 반. 영. 불. 가”이다. iOS 앱스토어와 Android의 플레이스토어 간 차이는 있지만, 양측 OS 간 등록된 내용은 “심사”라는 과정을 거쳐서 스토어에 등록되기 때문에 최소 몇 시간에서 최대 며칠을 기다릴 수밖에 없다. 더군다나 iOS는 심사가 까다로워 며칠을 기다렸다가, “리젝”이라는 상황이 발생한다면 정말 끔찍한 일일 수밖에 없는 것이다.
우여곡절 끝에 앱스토어에 문제없이 잘 등록되었다고 가정해 보자. 그리고 나면 사용자들은 바뀐 내용들을 바로 확인하거나 사용할 수 있을까? 결론은 그렇지 않다는 것. 익숙하게 하고 있는 앱 앱데이트 설치를 통해서만 바뀐 내용들을 확인할 수 있다는 것이다. 앱 업데이트를 하지 않은 사용자들은 이전 버전의 앱을 사용하는 것이며, 앱 업데이트를 설치한 사용자만 바뀐 내용을 확인할 수가 있다.
물론, 강제 업데이트를 통해 사용자가 앱을 실행했을 때 강제적으로 업데이트를 시키는 방법도 있다. 하지만 인기가 없는 앱일 경우 강제 업데이트 사용하면 사용자는 귀찮아하는 성향이 커서 서비스를 이탈할 확률이 클 수밖에 없다고 한다.
[수정된 내용이 웹인 경우]
웹 역시도 백오피스에 동적으로 관리되는 항목이 아닌 경우, 일명 ‘하드코딩’ 된 경우 개발자 또는 퍼블리셔가 직접 코드들을 수정해줘야 한다. 변경하고자 하는 화면이 웹으로 구현되어 있다면, 앱스토어 배포 없이 웹서버 반영, 배포만으로도 사용자들에게 “즉. 시. 사. 용. 가. 능” 하다는 것이다. html, css, javascript, Server side 등 수정된 내용을 웹 서버에 각자 배포 가능하기 때문에 사용자들은 앱 업데이트 설치 필요 없이 바뀐 서비스를 바로 사용할 수 있는 장점이 있다.
이렇게만 보면 네이티브 개발은 웹 개발보다 훨씬 불편한 점이 많은 것 같다. 하지만 그럼에도 불구하고 네이티브 구현이 꼭 필요한 이유는 반드시 존재한다.
[네이티브 뷰를 사용해야 하는 목적과 이유를 분명하게 정의하자.]
불과 몇 년 전까지만 하더라도 네이티브를 사용하는 이유는 사용자에게 훨씬 자연스러운 UX를 제공하기 위해서였다. 부드러운 애니메이션 및 앱에 특화된 인터랙션 등 네이티브에서만 느낄 수 있는 경험이 분명히 있었기 때문에 메인 화면이나 주요 화면들은 네이티브로 구현했었다.
하지만, 근래에는 웹 프런트엔드 기술이 좋아졌기 때문에, 웹이라 할지라도, SPA (Single Page Application) 또는 CSR (Client Side Rendering) 등 프런트엔드의 기술을 통해 자연스럽고 매끄러운 화면을 구현할 수가 있다. 따라서, 본인의 프로젝트에서 이런 프런트엔드의 프레임워크 기술을 반영하고 있고, 화면의 UX 목적이 부드럽고 자연스러운 경험을 주는 경험이라면, 굳이 네이티브 뷰로 구현할 필요는 없다.
단, 본인의 프로젝트에서 위에서 언급한 프런트엔드 프레임워크 기술을 적용하지 않는다라면, 자연스러운 UX를 제공하기 위해서는 메인화면 및 주요 화면들은 네이티브 뷰 구현은 필수불가결하다.
Q. 네이티브로 반드시 구현해야 하는 화면들은 무엇이 있을까?
반드시라는 말을 쓰기는 조금 망설여지지만, 명확한 것은 디바이스의 기능을 사용하는 화면인 경우에는 네이티브로 구현이 되어야 한다.
디바이스 기능이라면 여러 가지 있는데 대표적으로는 카메라 기능, 앱의 알림 및 GPS 기능, 이들을 컨트롤하는 설정 화면이라든지, 생체인증, 디바이스 결제 (ex. 삼성페이, 애플페이) 등 디바이스만이 할 수 있는 기능들은 네이티브로 구현이 되어야 한다.
물론 웹이라 하여 위에 언급한 기능을 할 수 없는 것은 아니다. 다만, 정확히 말해서는 웹과 앱이 약속된 API 개발이 이루어져야만 가능한 부분인 것이기 때문에 순수한 웹의 기능으로만은 위 기능들을 구현해 내기는 불가한 것이다.
쉽게 예를 들어 웹으로 구현된 화면이더라도, 어떤 버튼을 눌렀을 때 웹은 앱에게 “이 버튼 눌렀을 때 카메라를 실행시켜 줘”라고 요청 (Request)을 하게 되고 앱은 해당 요청을 받아, 카메라를 기능을 실행하여 응답 (Response)을 한다.
물론, 아주 간단한 기능이어서, 오픈소스로 사용할 수 있는 라이브러리 이거나, 사파리나 앱에 장착된 브라우저에서 제공하는 API를 사용하는 기능이라면 네이티브 개발자 도움 없이도 가능할 수 있겠지만, 조금이라도 복잡하고 어려운 기능들은 앱 개발자가 구현을 해줘야 하는 것이기 때문에 이러한 경우는, 웹 개발 및 앱개발이 이중적으로 발생할 수 있는 부분이다.
모든 것은 목적과 상황에 따라서 그 역할이 분명해야 한다. 네이티브가 해야만 하는 것은 네이트브로, 웹으로 해야만 하는 것은 웹으로, 뻔한 소리지만 본질을 확인하고 그에 맞는 업무와 역할이 부여되어 일이 진행되어야 한다는 것이다.
[마무리하며]
앱을 기획할 때는 상황과 환경 및 목적에 따라, 정말 많은 것들을 고려해야 하는데, 이번 주제에서는 네이티브와 웹의 구현 및 운영 관점에서 고려해야 하는 부분이 무엇인지 살펴봤다. 무엇이 좋고 나쁨을 떠나, 왜 네이티브여야만 하는지, 왜 웹뷰여야만 하는지를 다시 한번 고려하여 기획하는 데에 포커스를 맞추길 바란다.
끝.
