앱, 웹 시스템 개발을 위한 기획 요약

기획된 온라인 서비스 관련 내용을 실행하기 위해 셔는 이용 가능한 앱이나 웹을 개발해야 합니다. 이번에는 목표한 이용 가능한 앱 또는 웹의 기획에 대해 이야기하려 합니다. 온라인 서비스 기획이 시장과 잠재 사용자와의 협업이라면 앱/웹 개발 기획은 개발자와 디자이너와의 협업입니다.

 

 

 

앱, 웹 시스템 개발 기획의 속성

 

기본적으로 앱/웹 개발을 위한 기획은 시장이나 사용자를 우선하지는 않습니다. 이에 대한 것은 이미 요구 사항에 내포되어 있기 때문입니다.

 

앱/웹 시스템 개발에서는 요구 사항의 내용을 개발자와 디자이너와 협업하여 정해진 시간 내에 온전히 개발해 내는 것이 중요합니다.

 

이러한 기획 속성 때문에 약속된 기간 내 개발 작업 내용을 협의 표시한 WBS가 관리 기준이 되는 것입니다. 그리고 이 WBS를 위해 요구 사항을 분석하여 정리한 기능정의서와 화면정의서가 필요한 것입니다.

 

앱/웹 개발 기획의 이러한 흐름은 두 가지 가정을 깔고 있습니다. 외주 개발을 한다와 정해진 기간에 계획된 앱/웹을 개발한다입니다.

 

그러나 온라인 서비스 서비스 시장을 공략하는 방법인 이와 같은 앱/웹 결정론에 근간해서만 있는 것은 아닙니다. 어떤 앱/웹을 개발할지 정하지 않고, 단지 서비스 방향성만을 확정한 후 핵심 기능만 간소하게 개발한 후 시장 반응에 따라 추가로 앱/웹을 개발하는 방식이 있습니다.

 

이를 앞서 외주 개발 및 정해진 기간에 계획된 앱/웹을 개발하는 방식과 구분하여 애자일 개발 방식이라고 합니다. 기획적으로는 린스타트업 또는 MVP 기획법이라고 합니다.

 

이 애자일 개발, 린스타트업 기획의 특징은 특정 시점 개발과 기획이 끝나지 않는다는 것입니다. 사용자의 반응이 있는 순간이라면 기획과 개발은 지속돼야 하는 특징이 있습니다.

 

 

애자일/린 앱/웹 개발 기획      

 

근본적으로 요구 사항을 바탕으로 WBS를 작성하고 개발을 하는 폭포수 방식과 애자일 방식은 다를 수밖에 없습니다. 애자일은 폭포수 개발 같은 WBS를 작성할 수 없습니다. 

 

기존 외주 개발 방식의 경우 계약을 바탕으로 정해진 개발 내용을 정하여 기간 내 개발을 합니다. 그래서 WBS가 작성되는 것입니다.

 

이에 반해 애자일 개발의 경우 사용자 반응에 기반하여 대응 개발이 이루어져야 하므로 계약의 기간이 없고 정해진 완성 개발 내용도 사전에 지정할 수가 없습니다. 그러므로 흔히 외주 개발에서 적용되는 관리 방식을 적용할 수가 없습니다.

 

이에 따라 기능정의서와 화면정의서, 스토리보드 작성도 달라질 수밖에 없습니다.

 

SI나 웹에이전시 같은 외주 개발에서 스토리보드의 사용처는 개발도 있지만 산출물로 보고도 있습니다. 보고적 성격이 강할 경우 화면 설계 중심으로 스토리보드가 작성되기도 합니다.

 

이때 스토리보드는 개발해야 할 앱/웹을 특정하는 성격을 가지게 됩니다.

 

애자일에서는 개발 대상인 앱/웹의 최종 형태를 특정할 수 없습니다. 그러므로 스토리보드를 이와 같이 작성할 수 없습니다. 아니 작성할 수는 있지만 활용도가 매우 낮은 비효율적 기획 문서가 됩니다.

 

이에 따라 애자일에서 스토리보드는 보드라는 말 그대로 개발자와 디지이너, 기획자가 모여 협의할 때 사용한 화이트보드 내용이 되기도 합니다.

 

이 화이트보드 내용을 토대로 개발과 디자인이 이루어지며, 보관 문서로 따라 정리하는 것은 기획자의 부차적 업무일 뿐이니다.

 

이런 방식의 사용자 반응에 따라 빠른 대응을 통해 서비스 유효성과 수익성을 향상하는 목적에서 이루어진 것입니다. 그리고 이러한 시장 반응 대응 방식을 린기획이라고 하기도 합니다.

 

이러한 기획 차이 때문이 보통 우리가 아는 스토리보드 또는 기능정의서, 화면정의서가 애자일 개발, 린기획에서는 나타나지 않습니다.

 

이런 개발 과정 중 산출물의 형태 때문이라도 애자일 개발 방식은 자체 앱/웹 개발 시 적용될 수 있지, 외주 개발 시에 적용하기는 어려움이 있습니다. 

 

또한 애자일/린 방식의 개발/기획의 경우 회사 내부 주요 기밀 정보가 유출될 가능성도 큽니다. 문제는 기존 SI, 웹에이전시에서 해당 고객사의 앱/웹을 기획한 기획자, 개발자라면 경쟁사에서도 외주 개발 시 선호하기에 기본적으로 보안 때문이라도 애자일/린 방식의 개발/기획은 이루어지기 어렵습니다.

 

추가로 애자일/린 방식에서는 기획 문서를 정형화하기 어렵다는 부분도 있습니다. 기획 과정이 사용자 반응에 따라 시시각각 변하기 때문입니다.

 

 

 

앱/웹 개발 기획 과정 요약        

 

이 개발을 위한 기획 과정은 자체 앱/웹 개발 시보다 외주 개발 시 더 적절합니다. 자체 개발 시는 형식은 이와는 다른 좀 더 유연하고 요약적인 방식을 따르는 것이 더 효율적입니다. 자체라는 말에서 처럼 항상 볼 수 있고 바로 옆에서 일을 하는 같은 회사 동료이기 때문입니다.

 

앱-웹 개발을 위한 기획 과정

 

외주 개발 시 요구 사항을 바탕으로 전반적인 앱/웹 시스템의 구조와 사용자에게 전달되는 정보의 형태를 설계합니다. 단, 이런 설계에 익숙하지 않을 경우 하지 않고 바로 요구사항에서 화면 내역과 기능 내역을 추출하는 작업을 하는 것을 추천합니다. 잘 못할 경우 앱/웹 기능/정보 구조 설계 작업은 개발을 쉽게 하는 것이 아닌 어렵게 하는 요소가 되기 때문입니다.

 

여기서 정보 구조 뒤의 화면 내역의 IA와 다릅니다. 정보 구조의 의미는 요구 사항에 따라 개발될 앱/웹 중 사용자에게 전달되는 시각적 또는 구성적, 맥락적 정보가 어떤 아이덴티티를 가져야 하는지에 대한 것을 의미합니다. 이는 디자인 기획 또는 느낌을 전달하는 콘텐츠를 기획할 때 기본적으로 사전에 정의하는 필수 내용이라 할 수 있습니다. 그래야 작성이 진행되고 또 서로 다른 사람이 작업할 때 통일성을 유지할 수 있게 됩니다.

 

요구 사항에서 화면 내역, 기능 내역이 정리될 수 있지만 모든 외주 개발이 이를 동등하게 적용하여 개발하는 것은 아닙니다.

 

외주 개발 중 SI는 화면 내역보다는 기능 내역에 비중을 두고 개발합니다. 반대로 웹에이전시는 기능 내역보다는 화면 내역에 비중을 두고 개발을 합니다.

 

이는 외주 개발사가 가지고 있는 개발 특성 또는 보유하고 있는 자원의 문제일 뿐 SI는 화면 개발을 안 하고, 웹에이전시는 기능 개발을 안 한다는 의미는 아닙니다.

 

실제 SI에는 개발자는 많아도 화면 기획자나 디자이너는 매우 적도, 웹에이전시에는 개발자는 적도 디자이너와 화면 기획자의 비중이 높습니다.

 

화면 내역의 핵심 문서는 화면정의서입니다. 기능 내역에서는 기능정의서가 중심 문서라 할 수 있습니다. 이 두 문서는 요구 사항에 기반해야 합니다. 다른 내용을 적어서는 안 됩니다.

 

그리고 설명이 부족한 부분에 대하여 와이어프레임, 기능 프로세스로 보완합니다.

 

이러한 작업 흐름이 꼭 이렇게 고정되는 것은 아닙니다. 프로젝트 특성에 따라 요구 사항을 바탕으로 와이어프레임 작업을 먼저 하고 IA와 화면정의를 할 수도 있습니다. 기능 내역에서도 프로세스 설계를 먼저 하고 기능정의를 할 수도 있습니다.

 

기획 편의성에 따라 작업 순서 변경은 가능합니다.

 

스토리보드는 화면 설계서라고도 합니다. 그렇다고 스토리보드를 디자인 문서라 착각해서는 안됩니다. 

 

기획자의 작업은 코딩을 하는 개발자나 앱/웹 화면 디자인을 하는 디자이너와 다르게 개발될 앱/웹의 사용자 이용 플로우를 설계하는 작업을 주로 합니다. 사용자의 앱/웹 이용이 화면을 통해 이루어지므로 기획자가 작성하는 스토리보드를 화면 설계라 하는 것입니다.

 

스토리보드는 화면정의서와 기능정의서만 잘 작성되어 있다면 아무나 할 수 있는 간단한 작업이 됩니다. 화면정의서/기능정의서에 따라 사용자 이용 화면을 넣기만 하면 되기 때문입니다. 이는 앱이나 웹을 이용한 경험이 있다면 누구나 가능합니다.

 

그리고 실제 화면 디자인은 디자이너가 하므로 꼭 진짜 앱/웹 화면처럼 작업할 필요도 없습니다. 그냥 디자이너가 작업할 정도로 표시하면 됩니다.

 

이미 화면정의서외에 와이어프레임, 앱/웹 정보 구조 설계에서 디자인 방향성을 정의했기 때문입니다.

 

개발 또한 기능정의서와 프로세스 설계서를 보고 스토리보드에 옮기기만 하면 되기에 그리 어려운 작업은 아닌 것입니다.

 

단지 이러한 사전 기획이 없을 경우 스토리보드는 상당히 복잡하고 어려운 작업이 될 수도 있습니다. 그래서 때로는 부실한 스토리보드가 작성되기도 합니다. 

 

이는 스토리보드를 개발이나 디자인이 아닌 산출물로만 사용하게 되는 이유가 되기도 합니다. 오히려 스토리보드가 개발에 방해가 된 프로젝트 케이스도 생기게 됩니다.