[코드스테이츠 PMB14] 네이티브 앱? 웹 앱? 앱의 형태와 장단점 비교

 

애플에서 아이폰이 나오던 때가 아직도 생생합니다. 저는 그땐 고등학생이라 스마트폰이 아닌 아이팟 터치를 사용했습니다. 그걸로 스마트폰 있는 사람들과 카카오톡 주고 받았던 기억이 납니다. 그때 앱스토어에서 별의 별 기능을 가진 앱들이 많았던 것 같아요. ㅎㅎ 

 

스마트폰 성장과 함께 웹 브라우저도 모바일 사용이 용이하도록 형태가 바뀌었습니다. 그렇게 현재 크게 1) 네이티브 앱 , 2) 모바일 웹앱, 3) 웹 앱, 4) 하이브리드 앱 총 네 가지 형태로 나뉘어집니다. 오늘은 앱의 네 가지 형태의 역할과 장단점을 알아보려고 합니다. 

 

네이티브 앱: 내가 쓰는 스마트폰에 최적화

네이티브 앱이란? 

네이티브 앱이란 스마트폰의 운영 체제(iOS, Android) 에 맞춰 개발된 프로그램입니다. 네이티브 앱을 개발하려면 iOS, Android 에서 사용하는 언어를 이용해 코딩을 해야합니다. 각 운영체제의 플랫폼을 이해해 서비스 및 시스템을 개발/개선해야하기 때문에 iOS 개발자, Android 개발자를 따로 채용하는 기업도 있습니다. 

 

네이티브 앱의 장단점은?

장점	1. 프로그램을 다운한 기기 전체에 액세스 권한을 가질 수 있어서 카메라, 연락처, 지문인식 등 기본 기능 활용  2. 각 운영체제에 최적화되어 안정적인 서비스 제공 3. 높은 그래픽과 성능 4. 빠른 구동 속도와 안정성
단점	1. 다른 형태의 앱에 비해 높은 기술력 요구 2. 운영체제 별로 앱을 개발/관리해야함으로 개발 비용, 개발 기간(PC로 접속 불가) 3. iOS 경우 앱스토어에 심사를 받고 통과 후 앱 등록 가능(업데이트도 마찬가지) 4. Android 경우 플레이 스토어에 바로 등록이 가능하나 구글 심의에 따라 등록된 앱이 삭제될 수 있음

 

모바일 웹 앱: iOS? 안드로이드? 모르겠고 일단 접속해봐

모바일 웹 앱이란? 

모바일 웹 앱이란 사용하는 기기(PC, 스마트폰, 태블렛 등), 기기의 운영체제에 상관없이 무엇으로 접속하든 동일한 콘텐츠를 볼 수 있습니다. PC 웹페이지를 모바일에 맞게 줄인 형태라 생각하면 됩니다. 웹 개발방식과 동일하게 html, css, javascript 등으로 이루어져있으며 웹 브라우저에 url 로 접속해 이용할 수 있습니다. 

 

모바일 웹 앱의 장단점은?

장점	1. 운영체제 별로 앱을 개발할 필요가 없어 개발 비용, 개발 기간이 절감됨 2. 업데이트 용이 3. 브라우저 내에서 실행되기에 항상 최신 버전(별도의 다운로드/업그레이드 필요없음)
단점	1. 디바이스 액세스 권한에 제한(최근에는 웹 기술이 발전해 앱처럼 사용할 수 있는 기능 있음)

 

웹 앱: 모바일 웹 앱이랑 무슨 차이야?

웹 앱이란? 

웹 앱? 모바일 웹 앱이랑 무슨 차이인가 싶죠? 모바일 웹 앱은 웹페이지를 모바일 화면에 맞게 구성한 앱이라면, 웹 앱은 '구동방식이 앱처럼 보이게 한 웹'입니다. 그래서 웹 앱은 모바일에 더욱 최적화된 웹페이지입니다. 

 

웹 앱의 장단점은?

장점	1. 운영체제 별로 앱을 개발할 필요가 없어 개발 비용, 개발 기간이 절감됨 2. 업데이트 용이 3. 브라우저 내에서 실행되기에 항상 최신 버전(별도의 다운로드/업그레이드 필요없음)
단점	1. 디바이스 액세스 권한에 제한(최근에는 웹 기술이 발전해 앱처럼 사용할 수 있는 기능 있음)

 

하이브리드 앱: 하이브리드 힘이 샘이솟아 리오레이비

하이브리드 앱이란? 

하이브리드 앱은 네이티브 앱의 장점과 웹 앱의 장점을 결합하여 개발한 앱입니다. iOS 와 Android 에서 다운로드(업데이트)받아 모바일에서 구동하되 특정 역영은 브라우저를 띄운 화면을 보여줍니다. 네이티브 앱의 안정성과 웹 앱의 편리한 관리라는 장점을 가지고 있습니다. 자주 수정하지 않는 영역은 네이티브 앱으로, 자주 수정해야하는 영역은 웹 앱으로 개발합니다. 

 

 하이브리드 앱의 장단점은?

장점	1. 네이티브 앱에 비해 수정, 관리가 수월함 2. 웹 브라우저 기반인 웹 앱보다 빠른 속도 3. 디바이스 액세스 권한을 가질 수 있음
단점	1. 내부 리소스와 비용 2. 네이티브 앱에 비해 느린 속도(웹 브라우저 기반의 웹 앱 영역 로드 시)

 

---

 

프로덕트의 PM이라면 기획하는 과정에서 각 앱의 형태를 어떻게 선정할것인가?

서비스가 어떤 모양을 하고선 사용자에게 다가가는지 결정하기 위해선 여러가지 요소를 파악하고 있어야할 것 같습니다. 먼저 사용자가 서비스를 사용하는 이유, 즉 서비스의 목적에 대해 잘 파악해야합니다. 그리고 조직 내부적으로 인력과 비용을 어느정도 투자할 수 있는지에 대해서도 인지하고 있어야겠지요. 

 

사용자가 서비스를 사용하는 이유: 행동패턴과 체류시간

사용자가 서비스를 사용하는 이유에따라 서비스의 형태도 달라질 수 있을 것 같습니다. 고객의 행동패턴과 체류시간에 따라 서비스 형태를 선정할 수 있습니다. 

 

1) 고객의 행동패턴을 분석(페르소나와 JTBD)

예를들어 '퍼블리'의 경우 웹(웹 앱)과 네이티브 앱을 현재 제공하고 있는데요. 퍼블리는 '일을 하다가, 공부를 하다가 궁금한 게 생겼을 때 접속해 콘텐츠를 읽는다' 라는 패턴을 가지고 있습니다. PC를 사용하는 환경에 놓인 페르소나를 떠올릴 수 있습니다. 그리고 '출퇴근길, 등하교길 대중교통에서 시간을 생산적으로 보내기 위해' 라는 사용자의 JTBD 을 떠올릴 수 있고요. 사용자의 행동패턴을 분석하고 니즈를 파악에 그에 맞는 앱 형태를 선정합니다. 

 

또 다른 예시로는 카카오네비는 네이티브 앱으로 제공합니다. 만약 웹 브라우저 기반으로 네비게이션을 제공한다면 디바이스에 접근이 제한되어 음성안내가 원활하지 않을 수 있고요. 또 검색, url 접속으로 불편함을 불러일으킵니다. 

 

2) 체류시간

저는 체류시간도 앱 형태를 결정짓는데 영향을 미친다고 생각합니다. 특히 페이지 간 이동이 적고 오래 머무를수록 좋은 서비스는 네이티브 앱, 고객여정이 짧고 고객의 빠른 JTBD 위해 도움을 주는 서비스는 웹 앱의 형태로 제공이 될 수 있다고 생각합니다. 예를들어, 모바일로 만화나 소설을 읽을 땐 웹 브라우저 기반의 웹 페이지를 보게되면 가독성이 떨어집니다. 모바일에 최적화된 환경을 제공하는 편이지요. 반대로 어글리어스(못난이채소구독서비스)나 위잇딜라이트(점심구독서비스)혹은 필리(영양제구독서비스) 등 '구독 가입 > 결제 > 완료' 등 짧은 체류시간, 그리고 문의 혹은 구독해지가 아닌 이상 서비스 앱 방문이 잦을 필요가 없기 때문에 네이티브 앱 개발이 아닌 웹 개발로 치중되는 듯 합니다.

 

(게다가 서비스 페이지 방문을 낮추어 내가 이 서비스를 구독하고 있다는 것을 까먹게 만드는 것도 전략일 것 같은데... 꼭 모든 서비스가 체류시간이 길면 네이티브 앱, 짧으면 웹 앱은 아니니 개인의 의견으로만 봐주십시오)

 

또 체류시간 뿐만 아니라 위에 예시로 든 서비스의 경우 네이티브/하이브리드 앱 서비스로 구현할 정도로 서비스/기업이 고도화되지 않아 가장 빠르고 (비교적) 쉬운 웹 형태로 개발을 했을 거라고 생각합니다. 또 서비스 특성 상 웹 개발이 적합했고요. 네이티브/하이브리드 앱이 출시가 된다면 핵심 프로덕트를 보조하는 형태의 서비스(예. 요리 커뮤니티, 식단 관리, 영양 관리)가 추가 개발해 인앱쇼핑이 가능하도록 하지않을까 생각됩니다. 

 

 

기업은 어떤 상태인가

내부 리소스와 비용

너무나도 당연한 요소이지만, 조직의 리소스와 예산은 어느정도인지에 따라 앱의 형태도 달라질 것 같습니다. 초기 서비스는 네이티브 앱에 비해 비교적 리소스와 비용이 적은 웹 개발(웹 앱)을 진행할 가능성이 높습니다. 

 

하지만 제공하는 서비스 목적에 따라 내부 리소스와 비용의 한계를 넘어야하는 경우도 있을 것 같습니다. 앱과 웹은 퍼널 구조 자체가 다릅니다. 그렇기 때문에 초기 기획 시 어떤 전략과 목적을 위해 서비스를 시장에 내놓는지 잘 파악해야합니다. 예산에 맞추기 위해 목적에 적절하지 않은 앱 형태로 개발 후 다시 개발하는 경우는 프로덕트 매니지먼트 실패라고 볼 수 있겠지요. 어쩌면 리소스와 예산의 확보도 PM의 역할일까요...?  > 이는 C 레벨이 하는 일인걸로... 

 

---

나가며...

앱의 다양한 형태를 학습하면서 내가 자주 사용하는 서비스는 어떤 형태인지 다시금 돌아보게 되었습니다. 그리고 한 서비스를 시장에 내놓기까지 정말 얼마나 많은 과정을 거치고 고됨과 성취를 오갔을까 생각도 들고요... 저는 사용하면서 조금만 불편한 서비스가 있으면 이거는 어떻고 저떻고 어쩌구 저쩌구 컴플레인을 얘기한 적이 있습니다. 철이 없었죠... 물론 불편한 지점을 발견하고 논의하는 것도 좋은 방향이지만... 프로덕트를 공부하면서 과거를 되돌아보는 그런 시간을 가지네요. 프로덕트는 인생이다.