앱의 형태를 구분하는 2가지 기준 (feat.오늘의 집) | 코드스테이츠 PMB 14기

 PM은 프로덕트를 성공으로 이끌기 위해 프로덕트를 이루고 있는 부분들을 모두 논리적인 근거에 기반하여 전략을 짜야한다. 온라인 프로덕트를 기획 중이라면 해당 프로덕트가 어떤 루트로 서비스 되어야 하는가에 대해 생각해야 한다. 프로덕트를 이용자들의 행동 패턴을 고려하여 웹과 앱으로 1차적으로 나눌 수 있다. 만약 모바일로 서비스가 이용되어야 한다면, 어떤 형태의 앱으로 배포할 것인지도 고려해야 한다. 아니 앱이 1가지 종류가 아니라고?!

 

모바일 앱의 형태

 모바일 앱은 4개의 형태로 구분할 수 있다. 형태에 따라 구현되는 방식이 달라지기 때문에 필요한 인력 리소스도 다르다!

• 네이티브 앱
  모바일 운영체제에 최적화된 언어를 사용해 개발한 앱
  💻 iOS, 안드로이드 개발자 (요즘 스타트업은 플러터 개발자도 많이 뽑는듯!)
• 모바일 웹
  모바일 기기에서 사용하기 편한 방식으로 개발된 '웹 페이지' 기반 서비스
  💻 프론트엔드 개발자
• 웹 앱
  앱의 형태를 가지고 있지만 웹에서 구현해 보여주는 페이지
  💻 프론트엔드 개발자 (SPA 프레임워크 사용 가능자)
• 하이브리드 앱
  네이티브 앱의 구조로 되어 있으나, 일부 기능들을 웹으로 구현해 개발하는 방식
  하나의 코드로 iOS, 안드로이드 모두 배포할 수 있는 것을 의미하기도 함 (=플러터)
  💻 iOS, 안드로이드 개발자 + 프론트엔드 개발자

 

 위에 정리된 내용만 봤을 때 서로 성격이 겹치는 부분이 있어서 여전히 헷갈리는 부분이 있다. 보다 쉽게 이해를 하기 위해 1차적으로 프로덕트가 서비스되는 창구로 분류한 다음, 2차적으로 기술적인 부분에 근거하여 분류해 보았다.

 

1. 앱으로 구현 vs 웹으로 구현
   - 앱으로 구현된 프로덕트들은 안드로이드는 구글 플레이스토어에서, iOS는 앱 스토어에서 다운로드할 수 있다.
   - 웹으로 구현되는 프로덕트는 크롬, 사파리, 웨일 등 모바일 내 설치된 브라우저를 통해 접근 가능하다. 따라서 url을 가진다.
   
   
2. 화면/페이지 구현 방식 (기술)
   - 프론트엔드에서 어떤 기술로 화면을 노출하는가에 따라 형태가 달라진다.
   
   

	네이티브 앱	하이브리드 앱	모바일 웹	모바일 웹앱
서비스 창구	앱		웹
화면 구현 방식	우리가 일반적으로 생각하는 앱의 형태	네이티브 앱의 구조이나 일부 기능이 웹으로 구현	각 페이지가 개별적인 html으로 구성되어 있음	SPA로 구현
	1️⃣ 모바일 운영체제에 맞춰 제작되어 빠른 속도 + 안정적 2️⃣ 디바이스 기능 적용 가능	1️⃣ 모바일 운영체제에 맞춰 제작되어 빠른 속도 + 안정적 (네이티브 앱 보단 덜함) 2️⃣ 디바이스 기능 적용 가능 3️⃣ 웹으로 구현한 부분을 수정할 땐 별도의 업데이트를 하지 않아도 됨	1️⃣ 운영체제 별 개발하지 않으므로 비용과 시간이 절감됨 2️⃣ 별도의 심사 과정이 없음	1️⃣ 운영체제 별 개발하지 않으므로 비용과 시간이 절감됨 2️⃣ 별도의 심사 과정이 없음 3️⃣ 한 페이지에서 화면만 바뀌므로 로딩 속도가 빠름 (웹에서 구현되는 네이티브 앱 같은 느낌!)
	1️⃣ 각 운영체제 별 유지보수가 필요하여 인력 리소스 필요 2️⃣ 심사과정 + 수정할 때 버전 업데이트 필요	1️⃣ 각 운영체제 별 유지보수가 필요하여 인력 리소스 필요 2️⃣ 심사과정 + 수정할 때 버전 업데이트 필요 3️⃣ 웹에서 정보를 불러오는 부분은 로딩 속도가 더딤	1️⃣ URL필요 + 접근성 떨어짐 2️⃣ 페이지가 이동하는 텀이 발생하여 로딩 속도가 더딤	1️⃣ URL필요 + 접근성 떨어짐 2️⃣ 페이지가 이동하는 텀이 발생하여 로딩 속도가 더딤
예시	배달의 민족, 당근마켓, 스노우	원티드, 바이브, 카카오톡	서핏, 29cm, 구글	커리어리, 지마켓, 네이버

 

 

---

 4가지 유형의 앱을 살펴보았는데, 어떤 유형의 앱을 선택하여 고객에게 서비스하는 것이 좋을까? 대다수의 쇼핑몰은 웹앱 형태를 추구하지만 29CM, 지그재그와 같은 의류 플랫폼은 그 규모가 크기 때문에 웹 서비스 외 하이브리드 앱 또는 네이티브 앱을 운영한다. 만약 모바일 기능이 프로덕트의 핵심 기능에 해당된다면 안정적인 UX 경험을 위해 네이티브 앱으로 구현될 확률이 높다. 즉, 프로덕트의 특성과 회사 상황에 따라 어떤 형태의 앱으로 서비스할지 결정될 것이다. 추후 PM이 되었을 때 어떤 앱 형태를 선택할지 한번 생각해보고자 내가 만약 오늘의 집 PM이라면?이라는 가정하에 오늘의 집을 어떤 앱 형태로 서비스하면 좋을지 생각해보았다.

 

오늘 분석할 프로덕트 : 오늘의 집

 자취생들의 필수 어플인 '오늘의 집'은 커머스 서비스를 넘어 하나의 인테리어 플랫폼으로 자리 잡았다. 지원하고 있는 기능이 확장되어도 커머스에 머무르는 서비스가 있다면, 오늘의 집은 사용자들의 앱 이용 행태를 통해 인테리어 플랫폼으로 확장하는 데 성공했다!

 조사 응답자 중 주 3회 이상 방문하는 헤비 유저가 17%라는 점에서 SNS 또는 콘텐츠 서비스와 거의 비슷한 행태를 보인다고 느꼈다. 또한, 월평균 구매 횟수에서 '구매하지 않고 콘텐츠만 시청'하는 비율이 무려 56%라는 점에서 사용자들이 이제는 오늘의 집에서 인테리어 콘텐츠 기능을 주로 이용하고 있다는 것을 알 수 있다.

출처 : 더에스엠씨 콘텐츠연구소

 

 

만약 내가 오늘의 집 PM이었다면? (그랬으면 좋겠다...)

 

 오늘의 집은 웹과 앱을 모두 지원하고 있다. 앱의 경우 어떤 형태로 구현되었을까? 내가 오늘의 집 PM이었다면 프로덕트를 하이브리드 앱으로 구현했을 것이다. 커머스 서비스로 출발했을 땐 네이티브 앱으로 시작했다가, 콘텐츠 기능이 추가되면서 '사진', '집들이', '노하우'처럼 사용자가 활발하게 참여하여 콘텐츠를 생산하는 서비스 화면은 기존 오늘의 집 웹에서 화면을 끌어와서 노출할 것이다. 앱을 사용해보니 실제로 하이브리드 앱으로 구현된 것 같은 느낌을 받았다. 오늘의 집 앱 개발자 채용 공고를 찾아봤는데 우대사항에 '하이브리드 앱 개발 경험이 있는 분'이 있어서 괜히 뿌듯했다 :)

 

 하이브리드 앱으로 구현 시, 웹에 비해 속도와 안정성 측면에서 우수하며, 푸시 알림을 통한 CRM 마케팅도 가능하다는 장점이 있다. 오늘의 집은 다른 사용자의 인테리어 사진을 보기 위해 팔로우하는 등 SNS 성격도 띠기 때문에 푸시 알림이 필수적이다. 또한 위에서 예상했던 대로 3개의 카테고리(사진, 집들이, 노하우)는 비교적 최근 추가된 기능이므로 웹에서 끌어오도록 설계되어 있다면 기능 개선 시 별도의 업데이트가 필요하지 않다. 따라서 업데이트와 그에 따른 심사에 대한 부담감이 비교적 덜할 것이다. 이러한 명확한 강점이 있기에 유지보수를 위한 인력 리소스와 그에 따른 막대한 비용을 감수하면서, 오늘의 집이 하이브리드 앱으로 만들어졌을 것이다.

 

 

 

글의 마무리는 오늘의 집의 푸시 알림으로 :)

출처 : https://www.openads.co.kr/content/contentDetail?contsId=7745, https://brunch.co.kr/@oeun33/22

---

오늘의 집 기술 스택이 궁금하다면?

기술스택

참고 자료

모바일웹 / 웹앱 / 하이브리드앱 / 네이티브앱  

알아두면 도움되는 앱종류 - 네이티브/하이브리드 : 다이티 데이터 마켓 - 콘텐츠

<오늘의집>은 어떻게 '커뮤니티 커머스'로 성공했나