[PMB 8기] 앱을 만들기 전 반드시 알아야할 Mobile App 유형

 

약 10년 전 아이폰의 출시와 함께 열린 스마트폰 시대로 인해, 앱은 생활과 떼려야 뗄 수 없는 관계가 되었다. 우리들은 하루에도 수 십 번씩 앱을 사용하고 있으며 앱이 없는 상황은 상상하기도 힘들다.

 

이렇게 친숙한 앱은 어떤 모습을 하고 있을까? 깊게 생각해본 적이 없는 문제였다. 하지만 PM으로서 앞으로 서비스를 만드는 입장이라면 반드시 앱의 유형을 알아놓을 필요가 있다. 각 앱 유형마다 장점과 단점이 있고 이를 상황에 맞춰 적절히 적용했을 때, 서비스에 적합한 앱을 효율적으로 구축할 수 있기 때문이다.

 

또한 개발 리소스를 적절히 분배하고 일정을 조율하는 역할이 PM의 중심 업무란 점을 고려한다면, 앱 유형의 이해는 매우 중요한 주제이다. 이는 개발자와의 커뮤니케이션의 관점에서도 마찬가지일 것이다. 

 

이러한 관점에서 오늘은 모바일 앱의 다양한 유형과 특장점을 살펴보고, PM으로서 어떤 기준으로 앱 유형을 선택해야 하는지 고민해보려고 한다. 

 

---

 

모바일 웹(Mobile Web)

앱의 형태를 이해하기 위해 모바일 웹에 대한 이해가 필요하다. 모바일 웹은 말 그대로 모바일 환경(화면)에 최적화된 웹을 말한다. 작은 스마트폰 화면에 PC에서 보이는 웹 사이트를 본 경험은 누구나 한 번쯤은 있을 것이다. PC 화면에 맞춘 웹을 스마트폰에서 그대로 볼 경우 굉장히 불편하다. 이러한 문제에 대응하기 위해 모바일 환경에 최적화시킨 웹을 모바일 웹(Mobile Web)이라고 한다. 

 

모바일 웹은 크게 적응형, 반응형으로 나뉜다. 

 

웹 브라우저의 크기에 따라 자동으로 웹의 구성 요소의 크기와 구조가 변경되는 형태를 반응형 웹이라고 한다. 반대로 접속한 기기를 인식해 웹 구성 요소의 크기와 구조를 바꾸어 보여주는 방법을 적응형 웹이라고 한다. 후자에 경우 각 기기(PC, 스마트폰, 패드 등)의 화면 사이즈에 맞춰 보일 화면을 개별적으로 제작하며 전자는 하나의 웹 페이지가 화면 사이즈에 따라 자동으로 변환된다. 일반적으로 모바일로 웹을 접속했을 때 보이는 페이지를 생각하면 된다.

 

모바일 웹앱(Mobile WebAPP)

위의 모바일 웹처럼 브라우저를 통해 웹에 접속했을 때, 웹 페이지를 앱처럼 구현시켜놓은 일종의 '유사 앱'을 말한다. 앱 설치 과정이 없으며 웹 메일, E-commerce, 인터넷 게시판 등을 웹앱으로 구현하는 경우가 많다. 웹 기술 스택인 HTML, CSS, JS를 사용해서 만들어지며 브라우저 주소창이 존재하는 것이 특징이다. 

장점 

• 기본적으로 웹 기술이기 때문에 다양한 언어로 개발이 가능하다. 
• 어떤 기기에서든 설치 없이 브라우저만으로 사용할 수 있다. 
• 비교적 쉽게 개발할 수 있고 개발에 들어가는 시간과 비용도 적은 편이다.

단점

• 모바일 기기의 접근할 수 있는 권한이 없어 센서, 카메라 등의 하드웨어 기능을 활용할 수 없다.
• 애초에 웹이기에 모바일 환경 최적화가 힘들어 속도가 느릴 수 있다.

 

 

네이티브 앱(Native APP)

일반적으로 앱 스토어에서 설치해 사용하는 앱을 말한다. IOS, AOS로 대표되는 모바일 플랫폼 API를 이용해 개발된다. IOS는 대표적으로 Swift로 개발하며 AOS는 Kotlin라는 언어로 개발한다. 앱에서 생각할 수 있는 거의 모든 것을 구현할 수 있을 정도로 가장 높은 퍼포먼스를 보여준다. 모바일 하드웨어 기능 대부분을 사용할 수 있어 다양한 기능을 구현할 수 있는 것도 높은 퍼포먼스를 만드는 하나의 이유이다. 그에 따라 속도도 빠르다고 할 수 있다. 일반적으로 비즈니스 성숙도가 높은 기업에서 개발한다.

장점 

• 생각하는 모든 기능을 구현할 수 있고, 하드웨어 기능을 사용한 앱을 만드는데 자유롭다.(ex. 캘린더, 주소록)
• 앱의 품질이 매우 높고 구동 속도가 매우 빠르다.
• Native 플랫폼의 UI를 따르기 때문에 기존 경험과 비슷하거나 통일된 UX를 제공하기에 유리하다.

단점

• 개발 자원이 매우 많이 들어간다. IOS, AOS 개발자가 모두 필요하다.
• 같은 기능이라도 두 개의 언어로 개발해야 되기 때문에 최소 2배의 시간이 소요된다.
• 앱스토어 심사과정으로 개발이 지연될 수 있고, 이로 인하여 잦은 업데이트에 제약이 있다.

 

하이브리드 앱(Hybrid APP)

네이티브 앱의 단점(개발에 소요되는 비용이 큰 점)을 보완한 것에서 출발하여 웹앱의 장점(개발 비용이 적고 빠른 개발이 가능)을 수용한 것이 하이브리드 앱이다. 비교적 개발이 편리한 웹앱을 네이티브 형태로 제작하는 것이라 보면 된다. 예를 들면, 콘텐츠 영역은 웹앱을 기반으로 개발하되, 네이티브 앱처럼 포장하는 것처럼 개발하는 것이다. 그에 따라 앱스토어에서 다운을 받을 수도 있고 하드웨어의 기능도 일부 사용이 가능하다. 이러한 하이브리드 앱을 만들기 위해 웹 화면을 보여주는 웹뷰 기능을 사용하는데 PhoneGap, Cordova, Ionic 등의 프레임워크를 사용하여 구현한다.

장점

• 웹 개발을 기반으로 제작할 수 있어 네이티브 앱보다 개발 자원이 덜 소요된다. 
• 네이티브 앱보다 비교적 짧은 시간 안에 제작할 수 있다. 
• 웹앱보다 다양한 하드웨어 기능을 활용할 수 있다.

단점

• 네이티브 앱보다 속도가 느리다. 각각의 구성요소를 웹에서 불러오기 때문이다.
• 하드웨어 기능 중에서도 모든 기능을 자유롭게 사용할 수 있는 것은 아니다. 기능 사용에 제약이 있다.
• 앱 스토어를 통해 제공되기에 업데이트에도 제약이 있다.

 

 

모바일 웹, 웹앱, 하이브리드 앱, 네이티브 앱의 예시 

 

(좌) 모바일 웹, (중) 웹앱, (우) 하이브리드 앱 or 네이티브 앱

 

최근 웹앱의 정의는 보통 모바일 브라우저 환경에서 앱과 같은 기능을 구현한 것을 말한다. 하지만 전통적으로, 앱 개발이 어려웠을 과거에는 모바일 웹에서 '바탕화면에 추가하기'를 했을 때 모바일 브라우저 켜지는 것이 아니라 앱처럼 구동되는 것을 일컬었다. 바탕화면에 추가했을 경우 인스타그램은 중간 사진에서 볼 수 있듯이 앱처럼 구동되며 URL은 존재하나 주소창이 보이지 않는 것을 확인할 수 있다. 

 

가장 오른쪽 사진은 인스타그램 앱의 화면이다. 가운데 버튼이 릴스 버튼으로 바뀐 점, 사진 추가나 찍기 기능이 바로 연결된다는 점에서 좌측의 모바일 웹, 웹앱과의 큰 차이를 보여준다. 또한 다크 모드가 설정되어 있는 디바이스의 설정을 자동으로 로드하는 것을 보아 하이브리드 앱이나 네이티브 앱으로 볼 수 있다. (하이브리드 앱이나 네이티브 앱 모두 디바이스 기능에 접근할 수 있기 때문에 두 가지를 구별하는 것은 쉽지 않다.)

 

하이브리드 앱과 네이티브 앱을 좀 더 구별하기 위해 더 많은 예시를 찾아보았다. 몇 가지 아티클을 읽어본 결과 하이브리드 앱은 기본적으로 '웹뷰' 형식을 사용하기 때문에 모바일 웹이나, 웹앱에서 보이는 페이지(화면)를 그대로 불러온다는 것을 알 수 있었다.

 

 

(좌) CGV, 모바일 앱과 하이브리드 앱 / (우) Naver, 모바일 웹과 네이티브 앱

 

 

CGV와 Naver의 모바일 웹과 앱 화면을 비교하면서 네이티브 앱과 하이브리드 앱의 차이를 추측해볼 수 있었다. 좌측의 CGV에 경우 모바일 웹, 혹은 웹앱에서 보이는 화면을 그대로 앱 화면에서 보여준다. 반면 Naver에 경우 모바일 웹, 혹은 웹앱에서 보이는 화면이 그대로 로드되지 않고 다른 화면과 기능이 노출되는 것을 확인할 수 있다. 

 

인스타그램에 경우 해외 개발자들 사이에서도 네이티브 앱인지 하이브리드 앱인지에 대한 논쟁이 있다고 한다. 앱을 제대로 까 보지 않았기에 확실한 구별이 어렵지만 '웹뷰' 기능의 차이를 통해 위 사진처럼 하이브리드 앱과 네이티브 앱의 차이를 추측해볼 수 있다.

 

 

 

크로스 플랫폼 앱(Cross-Platform APP)

하나의 프로그래밍 언어로 IOS, AOS 두 운영체제에서 동시에 동작하는 앱을 개발한 것을 말한다. 페이스북에서 개발한 React Native, 구글에서 만든 Flutter 언어가 가장 대표적이다. 최근 하이브리드 앱의 대안으로 떠오르고 있으며, 네이티브 앱을 제작하기 버거운 스타트업에서 많이 사용한다.이는 크로스 플랫폼 앱이 네이티브 앱보다 개발 비용이 적게 드는 반면에, 하이브리드 앱보다 하드웨어 기능 사용에 있어 용이하다는 장점 때문이다. 최근 많은 개발자들이 유입되어 React Native, Flutter 커뮤니티가 확장되는 등, 관심이 매우 커지고 있다.

 

위의 내용을 보았을 때는 정말 좋은 앱 형태로 보이지만, 비즈니스의 성숙도가 높은 서비스에 경우 크로스 플랫폼 앱의 사용을 점차적으로 줄이고 네이티브 앱으로 전환하는 경향을 보인다고 한다. 이는 완벽하게 네이티브 앱만큼의 퍼포먼스를 보여주기 어렵기 때문이다. 크로스 플랫폼 앱이 네이티브 앱에 거의 근접한다고 해도, 1%의 기능 적 차이가 수백만이 사용하는 앱에서는 치명적일 수 있다. 에어비앤비가 크로스 플랫폼으로 개발을 시도했다가 다시 네이티브 앱으로 돌아간 사례가 대표적이다. (참조링크)

장점 

• 한 번에 두 플랫폼의 앱을 개발할 수 있어 네이티브 앱보다 자원적 소모가 적다.
• 하드웨어 기능을 사용하는 것에 있어 하이브리드 앱보다 제약이 적다.

단점

• 하드웨어 기능 사용에 제약이 거의 없지만 네이티브 앱만큼은 아니다. 
• 네이티브 앱보다 퍼포먼스가 떨어진다. 거의 근접한 성능을 보여주지만 아무래도 완벽한 네이티브 앱의 룩앤필을 만들지 못한다.
• 한 가지 언어, 프레임워크에 종속되어 있기에 프레임워크 단의 오류가 나타나면 대처가 힘들다. 

 

 

그렇다면 PM으로서 어떤 기준으로 앱의 형태를 결정해야 할까?

1. 서비스 개발에 있어서 소요되는 자원을 고려해야 한다. 

앱을 만드는 상황과 환경에 있어 대부분의 경우 자원이 한정적이다. 가장 기본적으로 정해진 예산이 있을 것이고, 개발 시간, 소요되는 인력 등이 이러한 자원이라고 볼 수 있다. 만약 서비스를 구축하는 중인 스타트업에 경우 처음부터 네이티브 앱을 만들려고 한다면 제한된 자원이라는 '큰 벽'에 부딪치게 된다. IOS 개발자와 AOS 개발자를 모두 채용해야 하고, 매출이 없음에도 긴 시간 동안 앱 제작에 매달려야 한다. 만약 솔루션을 검증하는 단계라면 검증 사이클을 반복하는 것이 힘들 것이다.

 

2. 서비스, 솔루션의 단계에 따라 앱의 형태를 고려해야 한다. 

앞서 말한 것과 같이 스타트업은 개발하는 솔루션을 검증해야 한다. 이러한 검증에서 가장 중요한 것은 빠른 반복이다. 가설을 기반으로 기능을 설계하고 소비자에게 배포하여 검증하는 과정을 여러 번 반복해야 하는 것이다. 이를 위해서는 빠른 개발 환경, 용이한 업데이트, 최소의 자원 등이 필수 불가결하다. 만약 스타트업이라면 상대적으로 가장 자원이 적게 드는 하이브리드 앱이나, 크로스 플랫폼 앱 등을 기반으로 앱을 개발하여야 한다.

 

3. 앱 서비스의 유형을 고려해야 한다.

Azar는 한국에서 만들어진 영상 채팅 기반 데이팅 앱이다. 실시간으로 서로의 모습을 보며 대화할 수 있는 특징이 있다.

(이 서비스는 2021년 2월 틴더를 운영 중인 매치 그룹에게 1조 9000억 원에 인수되었다.)

 

실시간으로 카메라의 기능을 활용해야 하고, 위치를 기반으로 상대가 매칭 되기 때문에 위치추적 기능이 계속 활성화되어야 한다. 이렇게 하드웨어적 기능이 돋보이는 앱에 경우 네이티브 앱이 아니라면 높은 퍼포먼스를 만들기 어렵다. 아자르에 사례처럼 하드웨어의 특정 기능을 중점적으로 활용하는 앱들은 반드시 네이티브 앱으로 개발하여야 한다. 

 

4. 고객의 행동이나 퍼널 상의 특징을 고려해야 한다.

필자는 과거 스타트업에 일하면서 앱을 출시한 적이 있다. 당시 웹앱 형태로 앱을 제작했었는데, 푸시 알림 등 기능적인 제약이 있어 하이브리드 앱이나 네이티브 앱으로의 전환을 고려한 적이 있다. 하지만 우리는 결국 웹앱의 형태를 고수할 수밖에 없었다. 왜냐하면 앱 유입 고객의 90%가 SNS의 링크를 통해 유입되었기 때문이다.

 

만약 하이브리드 앱으로 전환하였다면 앱 다운로드 과정이 고개 여정 상에 추가되었을 것이고, 일반적으로 앱 설치에 까다로운 소비자들은 일부 이탈할 수밖에 없다. 당시에 유저 한 명 한 명의 유입이 소중했고, SNS를 통해 마케팅 방법을 바꿀 수 없었기에 웹앱 형태를 지속해야 했다. 이처럼 고객이 보이는 특정한 행동이나 퍼널 상의 데이터를 기반으로도 앱의 형태를 선택하는 기준을 만들 수 있다.

 

 

Comment

앱의 형태를 정리하면서 느낀 점은 결국 앱 유형이 다변화된 과정 또한 문제를 해결하는 과정이었다는 것이다. 웹 개발 언어인 HTML, CSS, JS가 각각의 한계를 넘어서기 위해 개발된 것처럼 웹앱, 하이브리드 앱, 크로스 플랫폼 앱 또한 네이티브 앱과 각각의 형태의 한계를 극복하기 위해 개발되었다는 것을 알 수 있었다. 

 

오늘 가장 의문이었던 것은 '웹과 앱에서 실시간 정보를 동시에 보여준다면 네이티브 앱과 하이브리드 앱 중 어떤 것이 더 유용할 것인지'와 '크로스 플랫폼 앱은 하이브리드 앱인가?'이다. 해당 궁금증에 대한 답은 아직 찾지 못했지만 기회가 된다면 해당 주제로 꼭 포스팅을 진행하고 싶다.