13. 스토리 보드는 앱 제작의 설계도

앱 제작비용 산정, 왜 어려울까? 

 앱스토어에 대한 관심이 가속화되면서 앱 개발비용과 관련된 질문을 하는 분들이 많아졌다. 사실 국내 앱 시장은 아직 초기단계라 표준가격에 대한 명확한 기준이 없다. 사람마다 산정하는 금액이 상이하며 개발비용에 다소 거품도 존재한다. 

상황이 이러하다 보니 개발비용에 대한 타협이 어렵고 프로젝트 진행이 늦어지는 경우도 쉽게 볼 수 있다. 심지어 몇 달 전에는 한 분이 자신의 아이디어를 구현해 줄 개발자를 구하기 위한 글을 개발자 카페에 올렸는데 개발자마다 요구하는 비용이 10배까지 차이가 나서 개발자들을 비난했다고 한다. 그런데 필자의 주변을 유심히 관찰해 본 결과 개발비용을 산정하기 까다로운 또 다른 이유가 있었다. 

바로 아이디어를 제시하는 사람이 본인의 머리 속에 있는 것을 표현하는 것이 서투르다는 것이다. 앱 개발은 한정된 화면에서 여러 가지 고려해야 할 내용이 많기 때문에 과거 모바일 경험이 없는 사람이 다른 사람에게 자신의 의도를 명확히 전달하는 것이 쉽지 않기 때문이다. 

 앱 제작의 설계도 ‘스토리보드’의 중요성 

스토리 보드란 앱을 개발하기 위한 기초 설계도면이다. 건축물을 짓기 위해 설계도가 필요하듯 앱을 개발하기 위해서는 스토리보드가 꼭 필요하다. 프로젝트를 제안할 때, 개발자를 구할 때, 심지어 여럿이 공모전을 준비할 때도 스토리보드의 역할은 매우 크게 작용한다. 

스토리 보드는 단순히 앱을 한눈에 보기 위해 만드는 것이 아니다. 스토리 보드가 잘 작성돼야 토론이 효율적으로 진행된다. 주변사람에게 투자를 받거나 수익을 배분 할 때, 개발비용을 산정 할 때에도 핵심 근거 자료로 이용될 수 있다. 또한 개발이 진행된 상태에서도 스토리 보드가 얼마나 잘 작성되었는지에 따라 프로젝트의 갑작스런 수정에 빠르게 대처하고 보완소요를 쉽게 파악할 수 있다. 

이처럼 중요한 스토리 보드이지만 앱 시장에 처음 발을 들인 초보자는 이를 가볍게 생각하는 경향이 있는 것 같다. 그래서 오늘은 스토리 보드를 만드는 과정에 있어 중요한 요소들을 하나씩 살펴보려 한다. 

 

스토리보드의 예

1. 시스템 구성도 작성하기 (연동형 앱인 경우) 

스토리 보드를 만들기에 앞서 자신이 생각한 아이디어가 어떤 형태의 앱 인지 알아야 한다. 탑재형 앱이란 앱이 외부의 서버와 별도의 연동과정 없이 자체적으로 가진 리소스 정보를 활용하여 동작하는 앱을 말한다. 쉬운 예로 이북을 들 수 있다. 반면 연동형 앱이란 수시로 보여주는 데이터가 바뀌어야 하는 경우나 외부의 특정DB정보를 이용하는 경우로써 매일 기사내용이 바뀌는 뉴스 앱이 대표적인 예에 속한다. 보통 개인 개발자가 만드는 앱은 탑재형이 많으며, 기업을 대상으로 하는 앱인 경우 대다수가 연동형 앱에 속한다. 

당신이 만들 앱이 탑재형 앱이라면 바로 스토리 보드를 작성해도 무방하다. 하지만 연동형 서비스를 하는 경우라면 먼저 단말기가 어느 위치에 있는 어떤 서버와 통신을 하는지 한눈에 볼 수 있는 시스템 구성도를 작성해야 한다. 먼저 높은 곳에서 전체 윤곽을 보여주고 세부 내용을 설명하는 것이 상대방을 이해시키기 쉽기 때문이다. 또한 향후 서비스에 문제가 발생하는 경우에도 시스템 구성도가 잘 정리돼 있으면 문제점을 쉽게 파악하고 해결 할 수 있다. 여러 가지 면에서 필요한 작업이니 본인의 앱이 연동형 앱인 경우 시스템구성도를 먼저 그리도록 하자. 

2. 앱 설명 및 전체 개요

 

다음은 앱에 대한 전반적인 설명을 하는 페이지가 필요하다. 먼저 이 앱의 주요 목적이 무엇인지 어떤 대상에게 어떤 기능을 제공하는 앱 인지 간단히 설명해주는 페이지가 필요하다. 여기서는 세부적인 내용을 언급할 필요가 없으며 가장 핵심적인 컨셉만 대표화면과 함께 요약해서 보여주면 된다. 

그 다음 장은 세부메뉴에 대한 단계 별 트리구조를 통해 앱에서 제공하는 모든 내용을 한 눈에 볼 수 있는 페이지가 있어야 한다. 앞서 언급한 연동형 앱의 시스템 구성도가 앱과 외부서비스들과의 연관관계를 한 장에 표현했던 것처럼 앱에서 제공하는 기능들도 한 눈에 볼 수 있는 페이지가 필요하다. 이 트리구조를 보면 대략적인 개발 범위를 쉽게 파악할 수 있기 때문에 개발 진행 정도를 파악하거나 추가개발에 대한 자료로도 활용될 수 있다. 

3. 전체 플로우 

개별 화면에 대한 상세설명에 앞서 각각의 서브 메뉴들이 어떤 화면들을 거쳐서 진행되는지 과정을 보여주는 화면이 필요하다. 예를 들어 공지사항 확인이란 메뉴가 있을 경우 어떤 버튼을 누르면 어떤 이벤트가 발생하는지, 다음 화면은 무엇인지, 어느 화면에서 서버와 통신이 발생하여 공지사항 리스트를 가져오는지 등을 표시해 한 메뉴에 대한 일련의 사용과정을 한 장에 보여주는 페이지다. 특히 연동형 서비스의 경우 화면전환 시 서버와 통신하는 부분이 있다면 그 위치를 별도의 기호로 표시하도록 하자. 

4. 각 화면 별 상세설명 

메뉴에 대한 플로우 페이지 작성이 끝났다면 이제부터는 각각의 화면에 대한 상세설명 페이지를 작성하게 된다. 상세설명 페이지는 크게 이등분 해, 한쪽은 화면의 UI 모습을 보여주고, 다른 한쪽은 이에 대한 설명을 자세히 적는다. 설명을 적을 때에는 개발자나 디자이너가 해당 화면에 대해 쉽게 이해할 수 있도록 구체적인 예를 통해 설명을 하는 것이 좋으며 연결되는 서버가 있다면 그 URL이나 관련정보도 같이 적도록 하자.