과제 ) 다양한 서비스 유형으로 제공하는 프로덕트를 분석합시다.
- 다양한 서비스 유형으로 제공하는 프로덕트를 선정하고 그 유형별로 장단점을 간략하게 정리해봅니다.
- (예) 트위터(PC 웹, 웹앱, 네이티브앱), 유튜브(PC 웹, 웹앱, 네이티브앱) 등...
- 선정한 프로덕트가 서비스를 런칭할 때 왜 그 서비스 유형을 선택하게 되었는지를 분석해봅니다.
- (예) 트위터는 PC 웹으로 서비스를 런칭했습니다. 이 경우, PC 웹을 선택하게 된 이유를 생각해봅니다.
- 본인이 선정한 프로덕트의 PM이고, 현재 런칭 후 PMF를 달성한 시기라고 한다면 어떤 다른 서비스 유형으로 서비스를 확장할 것인지 아이디어를 구상해주세요.
- 각 서비스 유형의 특징을 고려하여 왜 그 유형으로 서비스를 확장해야 하는지 논리적으로 작성해주세요.
선정한 프로덕트의 서비스 유형과 장단점에 대해 정리하였는가? |
선정한 프로덕트의 초기 서비스 유형을 잘 파악하였는가? |
초기 서비스 유형을 선택한 이유를 논리적으로 잘 설명하였는가? |
PM으로서 서비스를 확장할 때 (앱이나 웹) 유형의 특징을 고려하였는가? |
⊙ 과제의 핵심 용어(또는 이론)
웹 – 앱 통합환경 구현 서비스 유형
pc 웹: 익히 아는 그것
모바일 웹: 모바일 크기에 맞춰서 웹을 조정함
웹앱: 앱의 탈을 쓴 웹 (신문사 어플)
하이브리드 앱: 네이티브 앱을 바탕으로 특정 웹페이지를 불러옴
네이티브 앱: 익히 아는 전형적인 어플
웹이냐 앱이냐에 따라 서버와 DB를 어떻게 구성할지 여부가 달라진다. 서비스 환경을 파악하는 게 오늘 과제의 핵심이다.
(드디어 채널을 정식 명칭으로 쓸 수 있게 되었다! 모바일 어플 이렇게 표기하던 나날은 안녕...)
다룰 Product
위키백과
위키백과의 다언어판 가운데 하나로서, 2002년 10월 11일에 시작되었다.
한국어를 쓰는 사람들은 주로 대한민국과 조선민주주의인민공화국에 거주하고 있으나 조선민주주의인민공화국 사람들은 인터넷 검열로 인해 접속을 하지 못하므로 '조선어'를 쓰지 않고 '한국어'를 쓰고 있다. 위키백과는 중립적 시각을 지키고 출처가 있어야 하는 등 진입 장벽은 높은 편인데 반해, 나무위키는 편향적 서술을 허용하고 편집도 엄격하지 않게 되어있는 등 진입 장벽이 낮은 편이라 한국어 사용자한테 밀렸다. 소개글 출처 위키백과:소개
이름 | 채널 | 분야 | 단계 | 시장 상황 | 출시 | 국내외 |
위키백과 | 네이티브 앱, 모바일 웹, PC 웹 | 위키위키 | 세계 최대 | ? | 2002(한국어판) | 국내 |
⊙ 선정 사유
과제에서 요구하지 않았기 때문에 자세한 말은 생략하기는 무슨 짧게 말하자면
원래 위키 도메인에 관심이 많은데, 이번 과제를 통해 위키를 들여다보면 배우는 게 있을 거라고 판단하였다.
생긴 것도 나무위키에 비해 딱딱하게 생겼다. 나무위키는 마스코트 캐릭터도 있고 커뮤니티도 운영하던데 위키백과는 아니다. 그래도 그런 규칙 덕분에 당당히 출처라고 남길 수 있다. 네이버 지식백과에 검색하면 나무위키는 안나오는데 위키백과는 잘 나온다. 나무위키는 보다보면 화가 나는데 위키백과는 어려워도 화는 안난다.
내가 본 중 제일 사전답지 못한 위키위키는 네이버 오픈사전PRO다. 작년에 없어진 위키독은 그래도 위키 구조는 있었는데, 이건 게시글 형태라 그런지 챌린지 사전 보면... 사용자들을 밴드로 인도해주고 싶다.
| 위키 백과 서비스 유형 파악
PC 웹: 편집하기 편한데 정신 사나움
모바일 웹: 편집하기 힘든데 깔끔함
앱: 일부 하이브리드 형태인 네이티브 앱으로 판단, 읽기 테마 등 편리한 기능이 있지만 시각적 편집 불가능
-
PC 웹으로 시작했는데 스마트폰이 보급되지 않았던 시대적 요인, 텍스트와 클릭 위주 등의 원인
⊙ 서비스 유형과 장단점
- PC 웹
- 모바일 웹
- 네이티브 앱
3가지로 구성되어있다.
- PC웹
PC 화면이 넓으므로 넓게 보도록 화면을 확장하는 기능이 달려있다. 총 문서 갯수와 최근 기여자 통계가 상단에 나와있다.
장점: 기능이 많아서 위키를 제대로 이용하고자 할 때 유용하다.
특히 편집을 자주 하는 이용자들은 토론, 편집 역사, 편집 정책, 사용자 모임 등의 기능을 활용할 것이므로 이 경우에는 모바일보단 PC가 편리하다.
단점: 텍스트가 많아 초행길인 사용자의 경우에는 정신 사납다고 느껴질 수도 있고, 뭐가 뭔지 어렵게 다가올 염려가 있으며, 비교적 복잡한 느낌을 준다.
◁ PC 웹 사이드바. 기능이 많다.
- 모바일 웹
장점: 전체적으로 UI를 개선하여 모바일 화면에 맞게 깔끔하면서도 풍부해보인다. 꼭 필요한 기능만 넣어 정보를 찾는 사용자에 맞추었다.
단점: 편집 기능이 대폭 줄어 정보 기여자가 사용하기는 불편하다. 이 문서가 편집 토론은 문서의 신뢰성을 더하는 요소인데, 토론은 모바일에서는 확인할 수 없다. 편집 역사는 문서 페이지 맨 아래 마지막 수정 시각을 클릭하면 확인할 수 있다.
◁ 모바일 웹 사이드바. 꼭필요한 기능만 들어가있다.
메인화면과 사이드 바 두군데에서 찾을 수 없는 기능들이 있는데 대표적으로 토론 페이지와 편집 역사 페이지, 표제어 총합 블록이다. 모바일에서 잘 찾으면 볼 수 있을지 모르지만, 접근성은 PC가 낫다.
- 모바일 웹과 pc 웹 대조
좌측) 모바일 | 우측) pc
웹은 둘다 시각적 편집(일반 에디터)과 원본 편집(위키 언어 중심) 중에 선택 가능함.
- 네이티브 앱
▼ 앱 내부 살펴보기 (이미지 많아서 접은글 처리)
모바일 앱은 2012년 출시하였다.
인터넷 브라우저처럼 문서를 분리하여 탭 처리 할 수 있고 어떤 문서도 선택하지 않고 탐색하기를 눌렀을 때는 대문이 나온다. 그럼에도 하이브리드 앱이나 웹앱 형태가 아니라 네이티브 앱이라고 생각하는 이유는 웹에는 찾아볼 수 없는 앱만의 기능이 많이 있으며 웹과 구성이 매우 다르기 때문이다. 편집 기능, 문서 탐색 기능 또한 웹과는 다르게 구현 되어있다.
인터넷 어플의 검색과 탭 분류를 가져왔지만 위키백과 내부 문서만 열람할 수 있다는 차이가 있다.
내가 애용하는 네이버 사전 어플은 header 영역에 naver 로고를 클릭하면 네이버 모바일 메인 화면으로 이동할 수 있다. (이런 꼼수로 학창시절에 휴대폰 잠금해도 몰래 인터넷 했다.) 네이버 사전은 이런 점으로 하이브리드 앱이 아닐까 싶은데, 위키백과는 외부 사이트로 이동할 수 없으므로, 네이티브 앱이지 않을까? 사전 앱이 왜 웹앱이 아니라 하이브리드라고 판단했냐면 앱만의 UI나 기능이 있는 듯 하기 때문이다.
카카오톡은 전형적인 네이티브 앱이지만 더보기 탭만 인터넷 통신으로 새 콘텐츠를 갱신받게 해두었다. 네이티브 앱 안의 일부 영역만 하이브리드 앱의 방식을 띄는 것이다. 이처럼 위키백과도 수정된 문서만 새로고침해서 갱신 받는다고 하면, 네이티브 앱 안에 일부 기능(문서 탐색, 편집, 메인화면)만 하이브리드 앱의 형태를 띄는 거라고 볼 수 있지 않을까? 특히 문서 탐색 전 메인화면은 모바일 웹을 반응형으로 재배열한 형태다.
일부 하이브리드면 그냥 하이브리드 앱인 거 아니냐고 할 수 있지만 앱적인 요소가 많아서 네이티브 기반이라고 판단했는데 사실 정확히 모르겠다.
아 그럼 네이버 블로그도 하이브리드 앱인가?
근데 앱 서버랑 웹 서버랑 따로 두는 건 문서 수정에 착오가 생길테니 하나의 커다란 데이터베이스를 갖고 있을 거 같은데 앱 DB와 웹 DB가 겹친다면 무조건 하이브리드인가? 그래야만 한다는 보장은 없나?
요컨대 위키백과 어플: 어플만의 기능이 많기 때문에, 네이티브 앱 안에 일부 기능만 하이브리드 앱인 형태로 판단하였음.
장점: 문서 북마크, 탭 분리, 읽기 테마 선택 등 탐색형 사용자 친화적인 기능. 여러 화면으로 분리되어 있어 한 화면이 간결하게 구성되어 있고 깔끔함. 다양한 탐색 피드 기준을 사용자가 지정할 수 있음, 백과 선정 알찬글, 조회수 높은 글, 요즘 화제 키워드, 오늘의 역사적 사건, 임의 문서 등.
단점: 위키 편집에디터가 적용되어 있긴 하지만 pc 편집보다는 불편함. 메인화면으로 돌아갈 때 뒤로가기로만 돌아갈 수 있기 때문에 현재 열어놓은 개별 문서탭이 닫힘. 메인화면에서만 쓸 수 있는 기능(저장된 문서 확인, 편집, 탐색 등)에는 문서 탐색 중에 동시에 접근하기 불편함. (= 문서 편집 중에 관련 문서를 찾아보기 힘듬), 시각적 편집이 불가능하고 원본 편집만 가능
⊙ 선정한 프로덕트의 초기 서비스 유형
모바일 앱은 2012년에 출시되었고 한국어판 위키백과는 2002년에 나왔다. 내 기억이 맞다면 2002년에는 스마트폰이 없었고 2008년에는 휴대폰으로 인터넷 들어가면 요금폭탄을 맞았었다. 모바일 웹은 앱과 비슷한 시기에 구현되었을 가능성이 높다. 따라서 PC 웹으로 시작되었다고 판단하는 게 적절하다.
왜 PC 웹으로 시작했을까? 그 이유는 상술했듯 기술적 요인이 첫번째다 .
두 번째로, 위키위키 서비스는 웹이 적절하기 때문이다. 앱보다 웹인데 특히 PC는 다양한 내용을 담을 수 있다.
- 텍스트와 하이퍼링크 위주의 콘텐츠를 탐색하는 서비스이므로
- 카메라나 센서 등 모바일 기기의 하드웨어 기능을 사용할 필요가 없다. (그나마 음성인식 검색)
- 거의 클릭 동작만 사용하므로 줌인, 줌아웃, 스와이프, 스프레드 등의 다양한 동작을 담을 필요가 없다.
- 정보를 확인할 때는 크기가 작아서 스낵 컬쳐에 적합한 모바일 기기보다는 아무래도 큼직큼직해서 가독성이 더 좋은 거 같은 PC가 걸맞다.
- 공공성을 표방하고 있기 때문에 오로지 기부만 받는다.
- 앱을 개발하게 되는 최대 원인 중 하나인 '광고를 많이 붙일 수 있는 환경'은 매력 요소가 되지 못함
- 정보를 찾아보는 행위 자체가 가진 특수성으로 인해, 설치가 필요한 앱 개발까지 안가도 됨
- 검색 플랫폼에서 입력한 키워드를 통해 개별 문서로 유입되는 경우가 많음
- 콘텐츠 탐색은 웹으로 충분해도 편리한 에디터를 구현하려면 앱이 필요한데, 개인 블로그에 비해 편집 장벽이 높아서(신중하게 써야 하고 전용 언어도 배워야 하며 단락별 수정이 힘듬) 콘텐츠 생산자 수요가 적음
- 알아야 하는 정보가 당장 없어도 위키를 재밌어서 들락날락하는 사용자층은 적을 것
- 어플은 접근성이 높고 일상적이어서, 모드 전환의 영향을 받음.
- 위키는 핫미디어므로 목표 지향적 모드에서 선택될 확률이 높은 제품임. 과제, 업무 등 의무성을 띈 작업을 하는 중에 선택될 가능성이 높음.
- 목표 지향적 모드가 일상적인 사람은 쾌락 모드와 번갈아 사용하는 사람에 비해 적음
- 전환 이론에 따르면 쾌락 지향적 모드는 위험 회피 성향이 낮어서 자기계발적 인식이 큰(통상적인 공부와 닮은) 사전 읽는 행동을 덜 선택하므로 여가 시간을 보내는 행동으로 거의 채택되지 않음.
- 단, 이성 제품군이지만 저관여 제품이라 영 불리하진 않기에, 사정이 된다면 위키를 재미로 읽는 사람들을 주요 고객군으로 앱 개발을 해도 되긴 함
- 위키 생태계를 구축하려면 토론, 편집 역사 등의 기능도 포함시켜야 함
- 자리 차지: 이런 내용들은 필수적인 것만큼 일반 사용자(이용자 대다수인 단순 소비자)에게는 불필요한 정보라 자리만 차지함. 그래서 외곽에 치우는 게 좋은데 PC는 화면 자체가 커서 괜찮지만 모바일은 아님. (이 부분 다른 위키 보면서 확인 필요)
- 모바일 화면 크기, 타자 입력 방법을 고려해볼 때 단문을 끊어 입력하는 방향으로 발전함. 장문의 문서를 고밀도로 편집하는 건 PC가 편리함. 화면 자체가 크고 단축키를 입력할 수 있으며 손가락 사용 갯수가 많은 키보드를 통해 빠른 작업이 가능하기 때문. 따라서 토론 등의 부가적 기능이 모바일 웹에서보다 PC 웹에서 빈도 높게 쓰일 확률이 높음.
- 문서 수정이 잦기 때문에 하나의 데이터베이스를 쓰는 게 데이터 간 혼선이 오지 않음. 앱 서버를 따로 구축하면 효율이 떨어짐. (사실 확인 필요)
▷ 요컨대 스마트폰이 보급되지 않은 시대적·기술적 요인, 텍스트와 클릭 위주, 쉴 때 안 봄, 콘텐츠 소비자 수와 생산자 수가 차이가 많이 남, 도메인 특성 등의 이유로 웹 PC로 출발하는 것 같다.
왜 여가 시간에 위키 안보는 사람이 많은지 근본적인 이유에 대한 설명이 부족한 것 같다. 이런 부분에서 자료를 찾으려면 뭐라고 검색해야 하지?
위키처럼 데이터베이스가 중요한 서비스는 웹 서버랑 앱 서버 같이 쓰나?
비교적 최근에 나온 위키위키 서비스들이 웹부터 시작했다는 근거와 그 이유를 가져와야 설득력이 높아질텐데 일단 생략한다.
| 내가 초창기 PM이라고 상상해보자
문서 탐색을 접근성 좋게 하기 위해서 앱을 만든다!
콘텐츠 갱신이 잦으면서 편의 기능을 추가해야 하므로 하이브리드 형식으로 만든다!
+ 브라우저 기반 편집 특화 툴
⊙ 런칭 후 막 PMF를 달성한 시기라면 어떤 유형으로 확장할지?
반응형 웹으로 제작해서 PC와 모바일 웹은 당연히 있을 것이다.
안나온 유형은 일반 모바일 앱, 태블릿 등 특수 디바이스 앱, SaaS 정도인 거 같다.
그럼 해야할 건 뚜렷하다.
- 브라우저형 SaaS (피그마처럼) : 편집용
- 하이브리드 앱 (네이버 사전처럼) : 탐색용
브라우저형 saas는 편집에 특화된 외부 편집기다. 편집 내용이 실시간으로 반영될 수 있도록 설치형 소프트웨어가 아니라 브라우저로 기능한다. 마크업 언어 말고도 다양한 방식으로 누구나 편하게 편집할 수 있도록 에디터를 제공하고, 기여가 필요한 문서를 큐레이션 해서 보여주며, 토론방 등 편집자 커뮤니티를 활성화하고, 편집에 유용한 기능을 다운 받아 적용하는 형태로 추가적으로 배포한다. 가입자끼리 그룹을 만들 수 있게 하거나, 기여도에 따른 랭킹 시스템이나 보상을 추가하는 방안도 고려할 수 있다. 원래 편집 방법에서 어떻게 차별화를 두길래 따로 프로그램까지 만들어야 되느냐고 물으신다면 좀더 고민해봐야 한다. 위키위키는 집단지성 서비스니까 사용자들의 참여가 중요하다. 그래서 편집광들이 편하게 사용할 수 있도록, 초심자도 쉽게 유입되도록 편집에 특화된 무언가가 따로 있었으면 하는 생각에서 꺼내보았다.
하이브리드 앱은 문서를 탐색하는데 특화된 앱이다. 현재 위키백과 어플과 비슷한 형태로 가되 사용성을 보완한다. 형광펜과 메모 기능을 넣어서, 읽으면서 활용할 수 있게 한다. 예를 들어 이렇게 사용할 것이다: 핵심에 분홍색 긋기, 출처가 없는듯 하여 미심쩍거나 토론이 필요한 부분 노란색 긋기, 추가적으로 알아보고 싶은 부분 초록색 긋기, 쪽지를 붙여서 해당 부분 적기. 또한 문서를 큐레이션하여 목록화할 수 있게 만든다. 그 목록에 설명을 붙일 수 있고 공개할 수 있으며 형광펜을 사용한 부분을 공유할지말지 정하는 것도 가능하다. 문서를 읽은 일자와 시간을 기록하여 관심사와 전문 영역을 분석한다. 또는 특정 구간을 달성하면 그간의 성장 기록이라며 개인화된 통계 페이지를 만들어 출력해서 보여주고 하단에 트로피 획득 버튼을 추가한다. 그렇다면 앱에 편집 기능은 어떻게 넣을 것인가? 누구나 편집할 수 있어서 잘못 건드리면 문서가 롤백되니까 에디터에 공들여야 하는데, 이 부분은 더 고민해야 한다. 획득한 트로피를 기반으로 '편집인'들이 편집에 끌어들일 '오직 탐색인' 사용자를 추천받아 초대할 수 있게 한다.
⊙ 왜?
냐고 물으시면 대답해드리는 게 인지상정..
사전을 자주 찾아봐야 하는 유저에게 인터넷 바로가기 말고도 더 편하게, 접근성 좋게 사용할 수 있도록 앱을 통해 편의성을 제공해야 한다. 모바일에서 슬라이드 해서 문서나 설명용 이미지를 넘기는 동작, 탭하고 드래그하면 구글 번역기로 바로 이동할 수 있는 기능 등은 문서를 탐색할 때 더욱 유용하게 작용한다. 아까 적은 콘텐츠 가독성이랑 충돌하는 문장 같은데, 뷰어에 따라 가독성이 떨어져서 스낵 컬쳐가 흥하는 경향이 있지만 그만큼 모바일만의 특성으로 득을 보기도 한다는 거다. 뷰어를 보기 편하게 만드는 게 필요하다. 사전 앱까지 설치할 정도면 불편함은 어느정도 감수하겠다는 의지가 있는 사용자다.
왜 하이브리드 앱이냐면 서비스 특성 상 콘텐츠 갱신이 잦고 빠르므로 html 파일을 서버로부터 다운받는 형태가 효율적이기 때문이다. 사용자 편의성을 더하려면 읽기 테마(밝기) 설정, 음성 인식 검색 등 다양한 기능을 추가해야 하기 때문에 설치형 웹 서비스에 가까운 웹앱 형식보다는 일반 앱처럼 권한을 받아서 기능을 구현할 수 있으면서 웹앱의 장점도 가져가는 하이브리드 형식이 적절하다.
saas는 이런 게 있으면 좋겠다는 생각에서 적은터라 고찰이 더 필요하므로 생략하겠다.
여담
내가 위키 도메인에 관심있는 이유는 위키러여서X 컨셉질X
문명은 기록되어야 하므로O
피드백 주시면 감사하겠습니다
- 제가 못보고 지나친 점 있을까요? 있어야 하는데 빠진 내용 있나요?
- 근거가 부족하거나 표현이 모호해서 설득력이 떨어지는 부분 있나요?
- 서비스를 확장할 생각을 해도 웹과 앱 안에서만 생각이 나는데, 또 뭐가 있을까요? saas로 확장하는 경우 있나요? 그 외에 어떻게 또 확장할 수 있을까요? 오프라인?
- 그 외 질문 (다 답변 안해주셔도 괜찮습니다..)
- 왜 여가 시간에 위키 안보는 사람이 많은지 자료를 어떻게 어떤 키워드로 찾아야 할까요?
- 위키처럼 데이터베이스가 중요한 서비스는 웹 서버랑 앱 서버 같이 쓰나요?
앱 서버랑 웹 서버랑 따로 두는 건 문서 수정에 착오가 생길테니 하나의 커다란 데이터베이스를 갖고 있을 거 같은데 앱 DB와 웹 DB가 겹칠 거 같아서요... - 네이버 사전 어플은 하이브리드 앱인가요? 네이버 블로그는 네이티브 앱인가요?
- 위키백과는 일부 하이브리드 요소가 들어간 네이티브 앱으로 보는 게 맞나요? 아니면 하이브리드 앱인가요?
- 위키와 saas의 결합, 가당찮을까요?
분석 참고 글
W7D2 [코드스테이츠 PMB 16기] 과제
웹 – 앱 통합환경 구현 서비스 유형 분석
'PM 부트캠프(22.12.12~23.03.15) > 과제' 카테고리의 다른 글
Flow Chart를 Technical Flow Chart로 승진시켜보자 (W7D4) (0) | 2023.01.31 |
---|---|
오픈 API 탐색 - 카카오 로그인 API (W7D3) (0) | 2023.01.28 |
네이버 지식백과 메인 화면을 프론트 언어로 해부해보자 (W7D1) (0) | 2023.01.25 |
가설 시각화 (W6D4) (1) | 2023.01.19 |
통계 자료를 보고 가설을 찾아내는 연습 (W6D3) (2) | 2023.01.19 |