서비스 기획서 가이드 마무리
PC/모바일! 모바일도 고려 안 하면 나중에 고생~~!!
스토리보드 작성하는데 체크해야 할 포인트가 계속 늘어나지요? 4편에 이어서 스토리보드나 업무 요청 시에 미리 챙겨야 나중에 고생하지 않는 사항들을 쭉 이어서 보겠습니다. 정리하다 보니 모바일에 대한 얘기가 많네요.
6. 웹앱, 하이브리드 앱, 네이티브 앱 용어에 대한 정의
모바일 앱을 어떤 방식으로 진행하느냐에 따라 개발 단계에서 업무 진행 부서나 담당자가 달라질 수 있기 때문에 초반에 잘 설정해야 합니다.
네이티브 앱 : 모든 기능과 이미지를 기기에 저장하면서 설치하는 방식입니다. 이 경우는 디자이너가 스케치로 디자인하고 제플린으로 가이드 제시하면 앱 개발자가 바로 앱을 만들게 됩니다. 일단 앱의 속도가 빠르고, 사용성이 좋아지는 장점이 있지만, 사소한 변경에도 앱 업데이트를 해야 하는 부분이 있어서, 게임과 같이 패키징 된 서비스나 업데이트 정책이 잘 세워진 시스템에서 많이 사용합니다.
웹앱 : 앱의 대부분의 기능이나 서비스 구현을 모바일 웹으로 만들고, 기본적인 앱의 기능 (자동 로그인, 푸시 알람 설정, 다운로드 파일 확인, 동영상 플레이어)만 네이티브로 구현하는 방법. 서비스의 대부분이 유연하게 변경되는 사항이고, AB 테스트 등 다양하게 진행하려고 할 때나 모바일 브라우저에서 도메인을 부여해서도 서비스가 가능하게 할 때 사용합니다. 기본을 네이티브 앱으로 생각해본다면 이미지 하나만 변경하려고 해도 앱 업데이트를 해야 하기 때문에, 많은 변화의 가능성을 내포하고 있거나 확장성을 고려한다면 웹앱을 많이 씁니다. 대부분의 쇼핑몰이 모바일 브라우저에서도 동일하게 구현되는 이유가 그런 부분이 됩니다.
인터넷 속도의 이슈가 있는데요. 이미지를 기기 자체에서 가지고 있느냐 순으로 네이티브 > 하이브리드 > 웹앱 이기 때문에 앱 호출할 때마다 많은 이미지를 불러와야 하는 웹앱이 속도가 느릴 수 밖엔 없습니다.
하이브리드 앱 : 하이브리드 정의는 앱 개발자분들에게 물어보면 조금씩 해석이 다르지만, 우선 제일 중요한 부분은 모바일 웹 개발은 프런트엔드 개발자들이 주축으로 진행하게 되지만, 하이브리드와 네이티브는 앱 개발자 추축으로 개발이 진행된다는 부분입니다. HTML 파일을 앱에서 내려받는 방식이라서 앱 구동할 때마다 최신 파일을 내려받는 방식으로 되어 있는 앱들이 통상 하이브리드 앱입니다. 변경이 잦더라도 초기에 HTML을 내려받는 방식을 쓰기 때문에 앱 업데이트를 하지 않아도 되고, 앱에서 이미지와 소스를 호출하기 때문에 속도면에서도 가볍고 사용성도 좋습니다.
위와 같은 특성을 잘 이해한 선에서 초기에 앱을 어떤 방식으로 가져갈 것인지를 정해야 할 부분이 있습니다. 네이티브 앱은 퍼블리싱이 필요 없는 부분도 있고, 앱개발팀, 프런트엔드개발팀 등 리소스 투입의 구성비가 변경될 수 있고, 한번 정하고 나면 변경이 어렵기 때문에 초기에 짚고 가야 합니다.
요즘엔 플러터 (Flutter)처럼 템플릿 기반으로 안드로이드, iOS 동시에 제작이 가능한 Tool 도 나오고 있어서 이 부분에 대한 기술 트렌드도 잘 파악하고 있으면 좋겠네요.
7. 안드로이드와 iOS 간의 특성을 잘 파악한 사용자 경험을 기획서에 담아내야 합니다. 자판 호출부터 알럿 창, 선택 방식 등 두 기기의 경험이 서로 다릅니다. 일단 파악하고 난 후에 스토리보드에 담는 것이 필요한 거죠. 저희가 참고하는 사이트는 아래와 같습니다.
구글에서 제시하는 안드로이드의 사용자 경험 :
https://developer.android.com/design/get-started/principles.html
아이폰에서 제시하는 사용자 경험 :
그럼에도 불구하고 따로 가야 하는 경험과 공통의 경험을 잘 정리해놓아야 나중에 개발 진행 시 혼란이 줄어듭니다.
OS 특성별 사용자 경험 예제
OS와 관계없이 정의해서 통일할 수 있는 사용자 경험 예제8. 검색 기능에 대해 정의할 때는 아래 사항들이 꼭 기재되면 좋습니다.
검색에 대한 필수 기능 - 최소/최댓값의 정의, 입력 가능한 값 정의, 입력값없을 시 정의, 검색 결과의 정렬 조건 정의. 기존에 있다고 생각하고 넘어가면 나중에 결국 개발자들에게 부담이 되는 부분입니다.
기능 정의가 제대로 되어 있지 않아서, 나중에 개발자나 퍼블리셔가 부담을 가지게 되도록 진행되는 부분을 저희는 기획 부채라고 표현하고 있습니다. 기능 정의의 중요성은 앞선 부분에서도 많이 얘기된 부분이라 1~4편을 쭉 읽어보시면 좋겠습니다.
더 디테일한 얘기들도 있지만, 우선 스토리보드를 처음 써보시거나, 별도의 가이드 없이 어디선가 양식을 다운로드하여서 기획을 해보신 분들을 위한 서비스 기획서 가이드는 여기까지 하고, 다음부터는 실무사례 중심으로 얘기를 좀 해볼까 합니다. ^^
아래 제가 빈양식 하나 공유드립니다. 그간 5편에 걸쳐 말씀드렸던 부분을 채우시는 것은 여러분의 몫입니다. ^^ (모바일 그리드는 슬라이드 마스터에 포함되어 있습니다.)
