기능 정의서와 앱/웹 개발을 위한 기획자

그동안 개발 프로젝트 경험을 통한 개인적인 기준으로 앱/웹 기획자가 SI 지향인지, 웹에이전시 지향인지와 초급인지 중급인지를 파악하는데 기능 정의서 존재와 작성 여부를 삼고 있습니다. 간단한 개발이야 상관없지만 복잡한 개발의 경우 작업을 하다 보면 기능 정의서가 필요하다 느끼게 됩니다.

 

 

 기능 정의서 정의와 역할

개발하려는 앱 또는 웹사이트에 어떤 기능이 있고 이 기능 어떤 방식으로 작동되는지를 설명한 문서가 기능 정의서라 할 수 있습니다. 간단하게 개발해야 하는 앱/웹의 기능을 정리한 문서입니다.

 

일정 이상 규모의 앱이나 웹을 기획하다 보면 헷갈리는 부분이 생기게 됩니다. 그러나 보면 기획의 전후 내용 맞지 않거나, 같은 내용이 반복되기도 하고, 있어야 할 내용이 빠지는 경우도 생깁니다. 

 

이 문제는 정리 작업을 통해 해결할 수 있습니다. 앱/웹 개발에 있어 정리 작업 중 하나가 바로 기능 정의인 것입니다.

 

제가 투입된 개발 프로젝트의 상당수는 기능 정의 없이 바로 스토리보드 작업을 하였습니다. 심지어 기획서 현행화로 투입된 프로젝트에서는 여러 개 버전의 스토리보드가 존재했습니다. 기존 프로젝트 투입 인력부터 PM, PL, 고객까지 어느 것이 가장 개발에 부합하는 기획서인지 알고 있지 모르는 경우도 있었습니다.

 

누구도 서로 다른 버전의 스토리보드 중 어느 것이 맞는 것인지 모를 수밖에 없는 것이 스토리보드 외에 정리된 기획 자료가 하나도 없었기 때문입니다. 심지어 개발하고 있는 개발자도 모르고 있는 상황이라 프로젝트에 투입되어 있는 개발자와 이야기를 해 보아도 어떻게 개발되는지도 확인할 수 없었습니다.

 

보통의 경우 연차로 등급을 부여하므로 초급, 중급, 고급은 경력 연차로 규정됩니다. 그렇다고 이것이 실제 역량을 의미하는 것은 아닙니다. 실제 고급 연차로 투입된 기획 PL을 개발 진행을 함께하는 고객 쪽에서 아무래도 고급 실력은 아닌 것 같다는 피드백을 하는 것을 본 적도 있습니다. 요즘 스타트업 개발 의뢰가 많아지면서 연차가 아닌 역량에 대한 이견 발생이 생기는 것 같습니다.

 

제 경우는 바로 스토리보드 작업을 하면 초급, 기능 정의 작업을 하려 하면 초중급, 기능 정의서 내용에 따라 중급으로 판단합니다. 기능 정의서를 제대로 작성할 줄 알면 스토리보드는 문제없이 작성할 수 있기 때문입니다.

 

심각한 오류 중 기획자와 문서 디자이너를 혼동하는 것이 있습니다. 디자이너가 있는데 자꾸 문서 디자인에 신경 써 디자이너의 자율성을 제한하는 문서를 만드는 기획자가 있습니다. 이 또한 협업 관점의 초급이라 할 수 있기는 합니다.        

 

 

기획자 역량과 기능 정의서

왜 앱/웹을 개발하는데 기획을 먼저 하는가를 생각해 보면 기획자 역량 평가에 기능 정의서를 평하는 이유와 기능 정의서의 역할에 대해 더 잘 알 수 있게 됩니다.

 

앱/웹은 다양한 형태로 개발될 수 있습니다. 모든 형태를 다 포함하는 앱/웹 개발은 비용도 너무 많고, 시간도 너무 많이 걸립니다. 이렇게 개발된 앱/웹을 사용자 많이 이용한다는 보장도 없습니다. 그래서 어떤 앱/웹을 개발할지 선택해야 합니다.

 

이렇게 선택된 형태의 뼈대를 정한 문서가 바로 기능 정의서인 것입니다. 기능 정의서는 어떤 앱/웹을 개발할지를 정리한 문서라 할 수 있습니다. 추가하면 이를 어떻게 개발할지에 대한 내용이 포함됩니다.

 

이를 개발자의 설계와 혼동하면 안 됩니다. 앞서 언급했듯이 화면 디자인 설계와 기획을 혼동하면 안 되는 것과 같습니다. 개발 설계는 기능 정의서의 내용을 구현하는 기술적 방식에 대한 것을 의미합니다. 여러 기술 중 어떤 것을 사용할 것이고 이를 어떻게 사용할지를 설계한 것이라 할 수 있습니다. 즉, 기능 정의서 내용을 실제 개발로 구현할 계획에 대한 기획이 기술 기획입니다.

 

이점에서 기능 정의서 내용은 기획자가 개발될 앱/웹을 이해하고 있는지 평가 기준이 될 수 있습니다. 또한 어떻게 사용자가 기능을 이용하게 될지를 설명하는 내용이 됩니다.

 

만약 실명 인증을 A라는 시스템을 통해 한다고 했을 때 기능 정의서에는 이를 설명할 것입니다. 연동 시스템과 설명 내용의 구현을 위해 개발는 A시스템 개발자와 연락을 취해 개발을 진행하게 됩니다. 그런데 기획자가 그냥 실명 인증한다고만 표시한다면 이를 어떻게 해야 할지 개발자는 알 수 없습니다. 만약 기존 실명 인증 서비스를 사용하는 것이 아닌 직접 실명 인증 시스템을 만든다면 개발 비용은 달라지게 됩니다.

 

 

기획자의 협업 역량

저를 포함한 사람은 자신을 중심으로 생각과 판단을 합니다. 앱/웹 개발 시 개발자와 디자이너, 기획자 등 서로 다른 업무를 해야 하는 다양한 인력이 투입됩니다. 이렇게 다른 업무를 해왔던 사람들이 생각하는 방식은 다 다릅니다.개발자도 세부적으로는 다른 개 작업을 하는 인력을 구분되고, 디자이너도 역할이 디자이너들이 투입될 수 있습니다.

 

기획자는 이런 여러 유형의 역량과 업무 방식을 가진 사람들을 조율하여 목적한 앱/웹이 개발될 수 있도록 하는 역할을 해야 합니다. 

 

여기서 가정 우선 돼야 하는 것은 위 글에서 나와 있듯이 목적한 앱/웹을 명확히 하는 것입니다. 기획자 스스로가 목적한 앱/웹을 이해하지 못하고 있다면 개발이 되는 것은 물론 투입된 개발자, 디자이너와 커뮤니케이션이 제대로 될 리가 없습니다.    

 

보통의 경우 개발 목적의 앱/웹을 잘 이해 못 하는 경우 정리가 안되기 때문에 일단 스토리보드를 작업하려고 합니다. 일단 스토리보드를 보 사람들이 먼저 눈이 가는 부분은 디자인된 화면입니다. 설명도 있지만 글이 너무 작기도 하고 100페이지가 넘는 문서를 일일이 다 읽는 것은 상당히 어려운 일입니다. 그래서 어느 정도 전문성이 있지 않다면 대부분 깔끔한 문서 구성이나 화면 디자인에 눈이 가게 됩니다.

 

그래서 목적 앱/웹을 잘 이해하지 못하더라도 기존 인기 있는 앱을 고해 화면을 비슷하게 그리려고 하는 것입니다. 이것은 목적 앱/웹을 모르더라도 다른 앱을 구동해 이용하면서 나오는 화면과 비슷하게 그리면 되기 때문입니다. 여기에 포토샵 등의 디자인 툴을 사용할 수 있으면 문서는 더 깔끔해집니다. 

 

그런데 개발자와 디지이너는 이 문서를 보고 직접 개발을 해야 하므로 고객이나 PM보다는 더 자세히 내용을 보게 됩니다. 여기서 문제가 생깁니다. 기존 참고 앱 이용 때 나오는 흐름을 보고 작업한 문서로는 어떻게 개발할지를 알 수 없습니다. 디자인도 기획자가 포토샵 등의 디자인 툴로 일정 부분 한 것이라 디자이너가 작업할 수 있는 부분은 제한적입니다.

 

이러다 보니 개발 프로젝트에 따라서는 기획자와 개발자, 디자이너 투입 시기가 다른 경우도 있습니다. 기획자가 기획을 끝내고 철수하면 개발자와 디자이너가 투입되는 것입니다.

 

제 개인적으로는 요구사항 정리는 기획자 주도로 하지만 개발자와 디자이너가 참여를 해야 한다고 생각합니다. 물론 모든 회의에 참여할 필요는 없고, 기획자 판단에 의해 참여를 하거나 최소한 협의는 해야 합니다.

 

그러므로 기능 정의 시에는 더욱 상호 협의와 토론이 필요합니다.

 

그래서 기능 정의서 작성하는지 안 하는지 보면 역량과 경험이 초급인지 중급인지 파악되고, 작성 내용을 보면 중급 수준을 알 수 있는 것입니다. 기능 정의서는 주로 개발과 관련된 부분을 정리하는 것이고 디자인적 부분은 화면 정의서 부분에서 주로 진행됩니다.