앱 서비스 기획 이후 진행되는 앱 개발 기획 내용 정리

앱 관련 서비스 기획이 진행되었다면 앱 핵심 사용자 그룹에 대한 정의와 함께 사용자 경험 구체화를 위한 앱 정책, 구조, 기능에 대한 정리가 끝났을 것입니다. 이 내용은 어떤 앱을 개발해야 할 지에 대한 정리인 요구사항이 됩니다. 그리고 요구사항에 따라 앱의 개발이 진행됩니다.

 

 

요구사항의 의미

 

앱(웹) 서비스가 앱을 통한 수익성 있는 사용자 경험이라 할 수 있습니다. 요구사항은 특정 앱을 통한 사용자 경험을 형성하기 위한 바로 그 특정 앱의 개발을 요구하는 내용이 됩니다.

 

이점에서 요구사항은 앱(웹) 서비스 기획과 앱 개발 기획의 교집합 요소라 할 수 있습니다. 

 

앱(웹) 개발 기획자가 요구사항을 제대로 이해하고 기능정의서, 스토리보드 등을 작성할 수 있다면 앱 개발자가 굳이 앱 서비스 기획의 내용을 알고 있을 필요는 없습니다. 단지 앱 개발 기획서 내용대로 개발만 하면 자연스럽게 서비스 기획의 요구가 반영되는 것입니다.

 

그러기에 앱(웹) 개발 기획자의 기획서는 화면 설계를 넘어 앱 설계를 담고 있어야 합니다. 화면 설계는 기능 설계 등과 함께 앱 개발 설계의 한 부분이기 때문입니다.

 

그리고 특정 기간에 진행되는 앱 개발은 전체 서비스 기획의 한 부분에 지나지 않습니다. 과거 소셜커머스 3사가 경쟁하던 시절의 쿠팡 앱과 지금의 쿠팡 앱은 다릅니다. 각 시기 쿠팡 앱은 특정 기능과 디자인을 적용한 개발을 진행하였고, 이런 기기간 개발과 사용자 반응, 서비스 전략에 따라 진화해 왔습니다.

 

앱(웹) 개발 요구사항은 이 특정 기간의 개발 요구를 지정하여 표시하는 문서인 것입니다. 이는 단지 전체 앱 서비스 개발과 제공, 유지/보수와 업그레이드의 단지 한 부분의 개발일 뿐입니다.

 

 

앱(웹) 개발 기획의 내용

 

개발 요구사항은 목적한 기간에 개발 목적한 앱을 표시하는 내용입니다. 이를 정리한다는 것은 앱 개발 업무의 정의를 의미하기도 합니다. 그러므로 요구사항 정리 없이 또는 부족한 상태에서 개발을 진행할 경우 중간에 문제가 생길 가능성이 커집니다. 일종의 불안전 계약 후 분쟁이 일어나는 것과 비슷한 상황이 되는 것입니다.

 

개발 관련 기획자의 역량은 이 부분에서 대부분 나타나게 되는 것과 바로 위의 이유 때문입니다.

 

앱(웹) 개발 기획은 서비스 기획 내용을 받아서 기획자가 어떻게 잘 기획 문서로 풀어내느냐가 관건이라 할 수 있습니다. 개발자 앱 개발을 위해 보는 문서는 결국 앱 개발 기획 문서이기 때문입니다.

 

일반 개발자와 디자이너가 참고하는 기획 문서는 스토리보드입니다. 그러나 PL 또는 개발/디자인 설계 담당자의 경우 기능정의서, 화면정의서를 통해 전체 앱 설계와 관리 포인트를 정리합니다. 

 

앱 개발 기획 프로세스와 작업 정리

  

앱(웹) 개발 시 기획자가 개발자(프로그래머)나 앱 디자이너(광의의 앱 개발자에 포함)와 커뮤니케이션하는 최종 기획 문서는 스토리보드가 됩니다. 그러나 스토리보드를 만들기 위한 과정의 기획 문서로 화면정의서, 기능정의서(기능 상세화 시트)는 기획의 질을 가름하는 중요한 문서입니다. 이 두 문서가 잘 작성되어 있다면 초급 기획자도 수준 높은 스토리보드를 작성할 수 있게 됩니다.

 

 

스토리보드의 양과 질

 

설계 문서인 스토리보드가 보기 좋게 잘 정리되어 있어야 하는 것도 중요합니다. 개발자나 디자이너의 내용 가독성에 도움이 되기 때문입니다. 그렇다고 내용이 없어도 된다는 것은 아닙니다. 말 그대로 스토리보드는 설계 문서이기에 내용이 없다면 개발을 위한 문서가 아닙니다.

 

때로는 스토리보드를 화면 설계 문서로 취급하는 경우도 있습니다. 그래서 일종의 피그마 같은 디자인 툴에 적용할 화면을 그대로 PPT 같은 문서 툴에 표현한 내용으로 작성되기도 합니다. 마치 화면만 있는 프로토타입 문서로 스토리보드를 인식하는 경우도 있습니다.

 

그러나 이는 잘못된 것입니다.

 

스토리보드는 앱(웹) 개발을 위한 문서이지, 앱 화면을 만들기 위한 문서가 아니기 때문입니다.

 

앱(웹) 개발 작업이 화면 작업이라면 굳이 많은 비용이 들어가는 개발자를 고용해서 앱 개발을 할 이유가 없습니다. 디자이너만으로 프로토타입핑 툴에 디자인을 입혀 작동시키면 되기 때문입니다.

 

그러므로 만약 화면 설계 스토리보드를 작성했다면 기능 개발 스토리보드도 있어야 합니다.      

 

그리고 수 백 페이지 스토리보드를 열심히 일한 많은 작업 산출물로 과시하는 경우도 있습니다. 때로는 기획 분석을 해 왔던 입장에서 보면 이런 기획서로 개발된 앱은 대부분 문제가 있는 경우가 많습니다. 실제 너무 많은 페이지로 작성된 스토리보드 때문에 개발이 엉켜 있는 앱도 확인한 적이 있습니다.

 

무조건 적은 양의 스토리보드를 만들라는 의미가 아닙니다. 항상 적절한 양의 스토리보드가 작성되어야 합니다. 그럼 스토리보드의 적정한 양은 어느 수준일까 궁금할 수 있습니다. 이는 위의 기능정의서와 화면정의서를 작성했다면 알 수 있습니다.

 

양을 중시하는 스토리보드에는 항상 작성 내용이 중간에 끊겨 있거나, 의외의 페이지에서 중복되는 내용들이 너무 자주 나타나기도 하고 때로는 중복 내용을 다르게 표시하는 실수도 범해 놓는 경우도 생기게 됩니다.

 

개발자가 코드를 작성하는 데 중간에 논리가 끊겨 있다면, 수만 줄 작성했다는 것으로 의미를 찾을 수 없을 것입니다. 오히려 수만 줄 때문에 코드의 문제 부분을 찾기 어려울 수도 있습니다. 스토리보드도 마찬가지입니다.  

 

좋은 코드는 간략하면서도 작동이 잘되는 것이라면 스토리보드도 같습니다. 반대로 나쁜 코드가 버그를 가지고 있는 너무 긴 코드라면 스토리보드 역시 문제가 있는 너무 양이 많은 문서라 할 수 있습니다.