앱/웹 개발 기획 시 과정을 지켜야 하는 이유

종종 앱/웹 개발 프로젝트를 하다 보면 기획을 단순히 화면을 문서에 그리는 것으로 이해하는 경우가 있습니다. 이 경우 높은 확률로 프로젝트는 망치게 됩니다. 개발자와 디자이너는 기획자의 문서를 보고 작업을 하는데 이 문서에는 개발되어야 하는 앱/웹에 대한 정의가 없기 때문입니다.

 

 

 

앱/웹 개발 기획 과정 요약

 

이 블로그에는 앱/웹 개발 기획 프로세스와 관련하여 정리한 글이 다수 존재합니다. 그러므로 여기서는 간단히 기획 과정을 정리 요약하고, 다음으로 왜 이 과정을 맞추어 기획해야 하는지에 이유에 대해 세부적으로 살펴보겠습니다.

 

SI, 웹에이전시 등 외주 개발을 가정하겠습니다.

 

먼저 요구사항을 정리합니다. 여기서 요구사항을 정리한다는 말은 개발될 앱/웹에 맞추어 요구 사항을 상세화 한다는 것을 의미합니다. 이를 통해 프로젝트 계약이 목표로 하는 앱/웹을 구체화하게 합니다. 이는 기획이 목표에 대한 달성 계획이라는 점에서 앱/웹 프로젝트 기획자가 해야 할 기본적인 일이 됩니다.

 

요구사항 상세화는 기획자 외에도 PM, PL이 진행하기도 합니다. 개발 기능 분야에 전문성이 필요한 상세화 영역이 존재하기 때문입니다.

 

이렇게 상세화 된 요구사항에서 기능정의서와 화면정의서가 작성됩니다. 개인적 경험으로 기능정의서가 화면정의서보다 먼저 진행하는 것이 더 효율적인 것 같습니다.

 

그러나 기존 앱/웹이 있는 상황에서 개발 프로젝트라면 화면정의서 작업이 먼저 진행됩니다. 보통 ASIS 화면정의 작업을 한 후 여기에 요구사항 상세화 내용을 적용하여 TOBE 기능과 화면을 정리해 나가게 됩니다.

 

기존 앱/웹이 있으므로  ASIS 화면정의에는 화면 구성과 UI 뿐 아니라 기능에 대한 정의도 되어야 합니다.

 

프로젝트를 하다 보면 때로는 그냥  ASIS 화면을 캡처한 것을 화면정의라 하는 경우도 있습니다. 이는 화면정의가 아니고 그냥 화면 캡처입니다. 보통 신입 기획자가 오면 트레이닝(연습/훈련)을 위해 역기획을 시기키도 합니다. 신입 기획자의 역기획도 단순 화면 캡처는 아닙니다.

 

이렇게 프로젝트에서 개발되어야 할 기능과 화면이 정의되면 이를 기반으로 스토리보드가 작성됩니다.

 

 ASIS와 TOBE의 기능과 화면이 정의되기 위해서는 정책이 정리되어야 합니다. 요구사항 상세화 및 기능정의, 화면정의 작업의 또 다른 작업은 그 기능과 화면이 작동하는데 필요한 정책도 포함되는 것입니다. 

 

스토리보드는 요구사항 상세화, 기능정의서, 화면정의서, 앱/웹 정책에 대한 기획 작업을 바탕으로 작업되게 됩니다. 한 앱/웹 화면이라도 기능정의와 화면정의, 정책에 따라 화면의 내용은 달라질 수 있습니다.

 

반드시 이해해야 하는 사실은 스토리보드가 앱/웹 화면을 그리고 설명을 적는 것이라고 해서 앱/웹 디자인이나 html/css 작업은 아니라는 것입니다. 앱/웹 기획은 요구사항 상세화를 통해 정의된 앱/웹을 개발하기 위한 기획이어야 합니다. 디자인이나 html/css는 개발을 위한 한 기능 영역일 뿐입니다. 여기에 기획이 함몰되면 프로젝트는 망치게 됩니다.

 

 

 

요구사항 상세화 및 기능정의, 화면정의의 필요성

 

최근 들어 만나는 기획자 중에 종종 기획은 개발과 상관없다는 주장을 하는 분도 있습니다. 때로는 개발자와 작업한 경험이 거의 없는 고급 기획자도 보았고, 기획 PL이 프런트엔드와 백엔드 개발을 구분하지 못하는 것도 볼 수 있었습니다.

 

심지어 기획 PL이 요구사항 상세화를 모르는 경우도 있었습니다.

 

기획 PL이 요구사항 상세화를 해 본 적이 없거나 필요성을 이해하지 못하는 경우 우선 함께하는 기획 PA들이 어려움을 겪게 될 것입니다. 개발을 위한 기획 대상이 구체적으로 정의되지 못하기 때문입니다. 그러면 이후 기획서를 가지고 개발을 해야 하는 개발자와 디자이너들이 어려움에 빠지게 됩니다.

 

요구사항 상세화는 해당 프로젝트의 범위와 내용을 정의하는 작업이기 때문입니다. 이 작업이 없이 고객이 제공하는 요구사항만으로 작업하는 경우 때로는 너무 넓은 범위의 앱/웹을 개발하게 됩니다. 고객 입장에서 개발을 많이 해주면 좋은 것은 당연합니다. 개발자 입장에서는 명확한 내용을 정리하고 그것을 개발하는 것이 개발 안정성과 기간뿐 아니라 작업량을 줄일 수 있습니다.

 

요구사항 상세화는 프로젝트에 참여하는 각 플레이어의 니즈를 조정하는 과정이기도 한 것입니다.

 

요구사항 상세화가 잘 되지 않는다면 기능정의, 화면정의도 제대로 되지 않습니다. 아니면 기능정의서, 화면정의서 작업 시 요구사항 상세화 작업을 해야 함께 합니다. 결국 진행될수록 일이 많아지게 되는 것입니다.

 

프로젝트가 진행된다는 것은 남은 기간이 줄어든다는 의미이기도 합니다. 결국 시간은 없고 일은 많은 상황이 되는 것입니다.

 

또 화면정의서, 기능정의서 작업이 제대로 되지 않는다면, 스토리보드 작업을 하면서 고객과 계획 기능과 화면에 대해 회의를 해야 합니다. 기획자는 한 화면을 설계하면서 이 화면에 있는 기능과 내용에 대해 고객에게 물어보면서 작업해야 합니다.

 

보통 이러한 상황이 되면 분석/설계가 되지 않았다고 말하기도 합니다. 이는 기획 차원에서는 해당 프로젝트에 대해 기획해해야 할 목표와 내용에 대한 정의와 정리가 되어 있지 않았다는 것을 의미합니다.

 

여행의 끝판왕이라는 아프리카를 여행하면서 출발 전에 아무런 준비 없이 여행 가는 것과 같습니다. 야생동물의 습격, 독충과 독뱀 위험, 심지어 남아공 우범지대를 아무 준비 없이 국내에서처럼 밤에 돌아다니게 될 수도 있습니다.

 

화면정의서, 기능정의서 없이 화면설계/스토리보드를 작업하는 것은 위와 같은 여행 상황인 것입니다.

 

저의 경우 회사에서 우리 앱/웹을 기획/개발하기도 했고, 제가 투자해 앱/웹을 개발하기도 했습니다. 이때 기획은 제가 했습니다. 이 과정을 통해 기능정의서와 화면정의서가 값이 바로 스토리보드 작업을 하는 경우 발생하는 문제를 보아왔습니다. 

 

보통 기획 시 이렇게 하는 것은 모르기 때문입니다. 최근 들어 외주 개발 현장이 개발이 아닌 검수 문서 작업을 중요시하는 경향이 생기면서 기획자가 기획이 아닌 문서 작성 중심으로 투입되는 경향이 커지면서 이런 현상이 더  일어나는 것으로 생각됩니다.

 

그래도 개발 프로젝트가 검수 문서가 목표가 아닌 앱/웹 개발 완료가 목표라면 최소 기능정의서, 화면정의서 작성은 스토리보드 작업 전에 되어야 합니다.

 

외주 개발 프로젝트라면 아주 당연하게 요구사항 상세화 작업이 선행되어야 합니다. 검수 문서 작업에서는 요구사항 상세화는 필요하지 않을 수 있습니다.

 

 

     

스토리보드 작성의 이유  

 

앱/웹 스토리보드는 해당 앱/웹 개발을 위해 작성됩니다. 여기에는 프런트엔드와 백엔드가 존재합니다. 프런트엔드에도 디자인과 개발로 구분할 수 있습니다. 

 

스토리보드는 이에 따라 세분화될 수 있습니다.

 

이를 기능 중심 스토리보드, 화면 중심 스토리보드라고 합니다.

 

기능 중심 스토리보드는 개발될 기능의 이용을 목표로 기능 프로세스를 바탕으로 작업됩니다. 화면도 사용자의 기능 이용 프로세스로 작성됩니다. 화면 설명에는 기능의 정의와 정책, 기능이 작동될 때 필요한 요구사항을 정리합니다.

 

화면 중심 스토리보드는 앱/웹 개발 시 작업되어야 할 앱/웹의 모든 화면을 설계 작성합니다. 사용자 관점에서 앱/웹에 들어왔을 때 보게 되는 모든 화면이 스토리보드에 작성됩니다. 그래서 정적 화면 중심으로 작업되고, 각 화면의 설계 작업이 됩니다. 구성은 메뉴라 할 수 있는 IA를 바탕으로 화면은 정리됩니다.

 

기능 중심 스토리보드와 화면 중심 스토리보드는 프로젝트 성격에 따라 선택 작성되게 됩니다. 보통의 경우 SI 기획자가 투입되는 경우 기능 중심 스토리보드, 웹에이전시 기획자가 투입되는 화면 중심 스토리보드가 작업됩니다.

 

그렇다고 이 두 스토리보드가 완전히 다른 것은 아닙니다. 이 두 스토리보드 모두 앱/웹 개발을 위해 작성되는 것입니다. 그리고 기능정의서와 화면정의서를 참고하여 작업됩니다.

 

만약 기능정의서, 화면정의서가 없다면 기획자는 스토리보드 작업을 위해 화면 하나 작업할 때마다 고객과 개발자를 찾아가 물어보고 확인해야 할 수 있습니다. 이런 경우 스토리보드 작성 시간은 많이 걸릴 수밖에 없고, 기획자가 해야 하는 작업량도 지나치게 많아집니다.

 

이뿐 아니라 스토리보드 완성도 역시 낮아지게 됩니다.

 

이는 마치 고등학교 내내 공부하지 않다가 수능 시험 한 달 남기고 벼락치기하는 것에 비유할 수 있습니다. 물론 엄청난 천재라면 수능을 잘 볼 수도 있지만 대부분의 학생은 시험을 망칠 것입니다.

 

수능 시험 한 달 전 벼락치기 하지 않게 끔 계획을 준비하고, 이를 실행해 나가는 것을 앱/웹 개발에서 기획이라 할 수 있습니다. 앱/웹 개발 기간을 고등학교 3년에 비유한다면 스토리보드 작업은 수능시험에 대응할 수 있습니다. 기획의 가장 마지막 작업인 것입니다. 수능을 보고 대학을 하듯 스토리보드로 개발자는 개발을 하게 됩니다.

 

스토리보드는 화면 설계 말하기도 합니다. 그래서 이를 설계라 아는 기획자도 있습니다. 설계라 해도 앱/웹 개발 프로젝트에는 화면 설계만 있는 것은 아닙니다. 화면 설계는 설계라 부르는 작업 중에 가장 마지막 작업입니다. 그래서 화면 설계 후에는 코딩 개발이 진행되는 것입니다.

 

만약 전체 1년 10개월가량 프로젝트에서 8개월 시점 화면 설계가 들어간다고 하면, 이는 전체 프로젝트 설계 중 마지막 작업을 의미하는 것입니다.

 

앞서 앱/웹 프로젝트 분석/설계자들이 투입되어 작업을 한 것을 바탕으로 화면 설계가 진행되는 것입니다. 쉽게 뛰어 A가 붙은 인력인 BA, DA, TA,  AA 등이 투입되어 작업을 합니다. 이때 분석/설계 기획자도 투입되어 요구사항 상세화, 기능정의, 화면정의 작업을 합니다. 이 기획자는 보통 아키텍처 수준의 대우를 받습니다.  

 

개발될 앱/웹의 정의가 구체화되지 않은 상태에서 스토리보드 작업은 불가능합니다. 화면 설계서 8개월 시점 진행된다면, 프로젝트가 시작되고 7개월까지도 기획자는 소수지만 투입되어 기획 작업을 해야 합니다.

 

때로는 이 7개월까지 과정은 기획자 없이 SI 과정으로 진행하고, 이후 웹에이전시 기획자가 투입되기도 합니다. 이럴 경우 기획 브리지에 대한 문제가 생기기도 합니다. 프로젝트 관리에서 투입 기능 영역이 서로 연동되지 않으므로 발생하는 문제입니다.

 

흔히 WBS에서 선 작업과 후 작업이 독립적으로 규정되어 있는데 후작업이 진행되기 위해서는 선행 작업에서 완료되어야 하는 것이 있을 때 이 선행 완료 작업이 규정되어 있지 않았을 때 문제입니다. 이 경우 WBS 오류라 할 수 있습니다. 이 경우 R&R 이슈가 발생할 수 있습니다.