앱, 웹 개발을 위한 기획 과정 요약

간단하게 앱, 웹 기획 과정을 요약 정리해 보고자 합니다. 아마도 스토리보드나 화면 설계 양식은 인터넷을 검색하면 쉽게 찾을 수 있으므로 내용을 넣지는 않겠습니다. 솔직히 제가 보려고 요약하는 것이기는 합니다. 최근 투입되었던 프로젝트에서 발생한 문제점과 수정/보완점을 검토해 보면서 정리해 보는 것이기도 합니다.   

 

 

 

앱, 웹 기획 시 기본적으로 갖추어야 하는 자세

 

개인적으로 개발을 위한 앱/웹 기획은 말 그래도 개발 가능성을 염두에 두고 기획되어야 합니다.

 

단순히 앱이나 웹 화면을 기획하는 것은 디자인과 다를 것이 없다고 생각합니다. 아니 아무리 기획자가 피그마로 작업한다고 해도 디자인은 될 수 없습니다.

 

엄연히 기획, 개발, 디자인 투입 인력이 구분되어 있는 것은 다 역할 구분이  앱과 웹 개발에 필요하기 때문이라 생각합니다. 그러기에 기획 또한 독립된 가치를 가져야 한다 생각합니다.   

 

기획이 코딩과 디자인 작업 전에 완료되는 것에서 그 이유를 찾을 수 있습니다. 개발자와 디자이너는 기획자의 작업물을 바탕으로 코딩 및 디자인 작업을 합니다. 바로 이 프로세스 지점이 기획이 앱/웹 개발 과정에서 가지는 독립된 가치라 생각합니다.

 

바로 개발될 앱과 웹의 설계 작업이라는 점입니다.

 

이는 화면 설계나 UI 기획이 단지 화면을 그리는 작업이 아님을 의미합니다. 화면을 그리는 것만으로는 개발이 이루어질 수 없기 때문입니다.

 

바로 전에 진행했던 프로젝트는 이러한 기획의 자세를 간과하였습니다. 기획은 단지 수 백장의 문서에 화면을 표시한 것이라는 자세로 기획을 했기에 개발자가 기획서를 가지고 작업하기 어려웠고, 디자이너와 협업은 주로 말로 진행될 수밖에 없었습니다.

 

또한 ASIS(기존 시스템)가 존재하는 상태에서 ASIS 분석이 화면 캡처 수준에 그치면서 전체 시스템과 상품, 각 상품과 고객 처리 프로세스, 규정 정책 등에 대한 파악이 부실하여 TOBE의 적용 내용의 파악이 불가능해졌습니다.

 

이로 인해 결국 TOBE 화면설계는 ASIS화면을 그대로 옮겨 문서화하고 기획자별로 약간씩 변화를 주는 정도에 그칠 수밖에 없었다 생각합니다.     

 

ASIS 기능과 화면에 대한 정의/분석이 부실하니 복잡한 시스템에서 TOBE를 진행하기 어려운 것이었습니다. 게다가 시스템에 대한 분석이 없었으니 특별한 조건하에 나타나는 화면은 파악조차 못하기도 했습니다. 물론 보안 때문이 레거시 시스템을 오픈하지 않고 분석 자료로 일부만 오픈하고 조건에 따라 특정 화면은 노출해 주는 형식으로 개발 프로젝트 진행된 이유도 어려움이 있었습니다.

 

이러한 과정을 앱/웹 개발에서 기획이 참여하여 작업하는 프로세스 흐름에 따라 정리하면 다음과 같습니다.

 

  

 

앱/웹 기획 프로세스 요약

 

요즘 고급 기획자, 기획 PL, PM을 만나서 작업을 하다 보면 기획의 분석/설계를 화면 설계로 이해하시는 분들도 있었습니다. 그러나 기획자가 투입되어 작업하는 전체 기획 작업 중 화면 설계는 가장 마지막에 하는 것입니다.

 

물론 규모가 작고 간단한 시스템 경우 화면 설계 시 진행되어야 할 선행 기획 작업을 할 수 있습니다. 그러나 규모가 크고 복잡한 시스템의 경우 이렇게 화면 설계 시 한꺼번에 하는 것은 불가능합니다.

 

이를 기획적으로는 업무 복잡도 관리 또는 일머리라 부릅니다.  

 

그러므로 앞으로 정리한 기획 프로세스는 복잡도(카오스)가 높은 앱/웹 기획에 적용되는 방식이라 할 수 있습니다.

 

그리고 보통 UI/UX라 하지만 이 프로세스에서는 UX에 대한 것은 감안되지 않습니다. 

 

학문적으로나 기술적으로 UX를 개발 때 기획/설계 작업하지는 않습니다. 앞서 기획된 UX(사용자 경험 형성/관리 구조 및 요소 설계)를 구현하기 위한 UI와 화면 구성이 개발 때 적용되는 것이 적절한 작업 과정입니다. 그러므로 UX는 화면 설계 시 설계 의도가 반영되는 것으로 보겠습니다.

 

먼저 투입된 기획자는 개발될 시스템, 앱/웹을 파악하는 것이 필요합니다. 이를 요구 사항 분석이라 하기도 하고, ASIS/TOBE 분석이라 할 수도 있습니다. 중요한 것은 일단 개발되어야 할 앱 또는 웹이 무엇인지 정확히 파악하는 것이 필요합니다.

 

• 개발될 앱/웹 파악

 

개발될 앱과 웹을 파악하는데 기획자가 필요한 것은 초창기 앱과 웹에 대한 정의가 비즈니스적으로 표현되어 있기 때문입니다. 이렇게 비즈니스적으로 표현되어 있는 내용을 분석하여 개발될 앱과 웹으로 정리하는 것을 분석/설계라 부릅니다.

 

기존 시스템(ASIS)이 존재하는 경우 기존 시스템(ASIS) 분석과 담당자 회의를 통해 분석이 진행됩니다. 그리고 개발될 앱/웹 시스템(TOBE)을 개발될 수 있도록 정의하는 작업을 설계라 합니다.

 

• BM → BA 또는 ASIS → TOBE 분석/설계

 

전체적인 앱/웹 시스템의 내용과 구조를 파악했으면, 세부 시스템의 작동과 구성에 대한 정의가 필요합니다.

이 때는 앞서 BM/BA, ASIS/TOBE 작업 시 정리된 정책과 기능/화면 정의 내용을 반영합니다. 

 

이렇게 정리된 문서를 기능정의서와 화면정의서라 합니다.

 

• 기능정의서, 화면정의서 작성

 

기능정의서는 앱과 웹에 적용될 기능에 대한 정의를 정리한 문서입니다. 화면정의서는 개발된 앱과 웹의 화면에 대한 정의를 정리한 문서입니다.

 

그러므로 기능정의서는 백엔드, 화면정의서는 프런트엔드 개발에 중요한 문서입니다. 그리고 이 두 문서의 결합으로 백엔드와 프런트엔드 인터페이스가 정의됩니다.

 

여기서 IA, UI 및 개발 화면 컴포넌트 정의와 디자인적 요소 등에 대한 것은 화면정의서에 따르게 됩니다. 또한 화면정의서의 흐름은 그대로 사용자가 이용하게 될 화면의 배치와 관계, 이용 흐름을 의미합니다.

 

일반적으로 화면정의서를 가지고 화면을 넣어 작성된 문서를 화면 설계서라 부릅니다.

 

• 화면 설계서 작성

 

또한 기능정의서를 토대로 기능의 사용자 이용 프로세스와 이때 발생하는 데이터 또는 서로 구분될 수 있는 시스템을 연동 과정을 정리한 문서를 프로세스 설계서라 부르기도 합니다. 이 프로세스 설계서는 개발 시 작성되는 로직/다이어그램, ERD/알고리즘 설계서와 구분해야 합니다. 기획 시 프로세스 설계서는 앞서 언급한 BA 하위 문서라 할 수 있습니다.

 

화면 설계서를 연결된 흐름으로 정리할 경우 스토리보드라 합니다. 과거에는 개발 시나리오라고 하기도 했던 것으로 기억합니다.

 

• 스토리보드 작성

 

프로젝트에 따라 앱/웹 화면을 개별적으로 설계하는 경우도 있는 것 같습니다. 이전 제가 투입되었던 기획 PL이 그렇게 웹의  화면 구성을 작성했습니다. 그래서 3 depth만 넘어가도 해당 화면을 어떻게 진입하는지 확인할 수 없는 화면도 나타났습니다, 

 

이전 프로젝트에서 기획을 하다 보면 이렇게 앱/웹의 화면들의 상호 간의 이동/배치 관계를 정의하지 않고, 단지 개발 화면 그 자체만 설계하는 것을 화면 설계, 이 화면들의 이동/배치 관계를 포함하는 설계 문서를 스토리보드라 할 수도 있지 않을까 하는 생각도 들었습니다.    

 

화면정의서만 있다면 화면 간 이동/배치 관계를 포함하지 않고, 개발 화면만 설계해도 화면번호를 통해 화면들 간의 상호 관계를 쉽게 알 수 있습니다.

 

그러나 이전 제가 투입된 프로젝트에서는 화면정의서가 없었습니다. 문서명이 화면정의서인 것은 있었으나 화면의 정의와 화면 간 연결 관계는 없고 ASIS 캡처와 온통 TBD(미정/미결정)로 구성된 수백 페이지 문서들의 집합이었습니다. 한 마디로 사용할 수 없는 형식적으로 작업했으므로 보이기 위한 문서라 저는 생각했습니다. 물론 제가 투입되기 전부터 진행된 문서입니다.

 

결국 화면정의서에 ASIS는 물론 TOBE 화면에 대한 정의가 없으므로 이후 진행되는 화면 설계는 물론 개발자의 작업 내용에도 가이드가 되지 못하는 합쳐 천 페이지가 넘는 문서의 집합이었던 것입니다.

 

 

 

결론

 

이런 경험을 검토해 본 결과 기획은 단지 기획 문서는 단순히 기획 문서라 이름 붙인 문서가 아니라 개발에 사용할 수 있는 문서가 되어야 한다는 것을 느끼게 되었습니다.

 

저의 경우 앱/웹 기업에서 사업 기획에서 BM(온라인 비즈니스 모델링)와 온라인 사업/경쟁 전략, 개발을 위한 시스템 설계(BA) 그리고 외주 기획자라 앱/웹 기획, 시스템 기획 등을 모두 작업해 보았습니다.

 

그런데 앱/웹 기업에서의 기획과 외주 기획은 완전히 달랐습니다. 기획적 사고는 물론 대상 또한 달랐습니다. 이는 같은 앱/웹이라도 쿠팡과 같은 앱/웹 기업에서 기획자가 바라보는 앱/웹과 외주 개발의 기획자가 바라보는 앱/웹은 다르다는 것을 의미합니다. 비록 사용자가 보기에는 같은 쿠팡 앱이라도 기획자의 작업 대상으로 쿠팡 앱은 다른 것입니다.

 

그래서 이런 기획 차이는 차치하고,

그냥 결정된 앱과 웹의 개발을 위해 기획자가 어떤 작업 과정을 거쳐야 하는지만 정리해 본 것입니다.

 

이런 과정은 앱/웹 기업이든  외주 개발에서든 동일하게 적용될 수 있도록 제 경험을 바탕으로 정리해 보았습니다.

 

다시 간략히 기획 과정을 정리하고 글을 마치겠습니다.

 

1. 개발될 앱/웹의 파악
2. 개발할 앱/웹의 정의 (BM → BA 또는 ASIS → TOBE 분석/설계)
3. 개발될 앱/웹의 기능과 화면 정의 (기능 프로세스와 화면 플로우 정의. 화면정의에 IA 포함)
4. 스토리보드, 화면 설계 (필요시 디자인 기획. 디자인 기획은 화면 설계와 다름)

 

흔히 요구 사항 분석/상세화는 1과 2 작업 시 진행됩니다. 또한 요구 사항 분석 시 개발될 앱/웹에 적용될 정책 사항이 정리되어야 합니다. 이때 정책은 화면에 노출되는 콘텐츠 정의, 각 화면의 컴포넌트 정의, 연동, 데이터 관리, API 등 앱/웹 개발에 적용될 전반적인 정책과 규칙, 개발 방식 등을 포괄합니다.

 

물론 프로젝트 초기 투입된 기획자가 분석을 할 때 협의/회의를 통해 부족한 정책 부분은 보강하면서 진행합니다.

 

때로는 앱/웹 개발 진행 전에 PI나 UX 등의 컨설팅이 진행되어 이를 반영해야 할 수도 있습니다. 이 또한 분석/설계 작업 시 진행합니다.

 

PI나 UX는 모두 프로세스와 관련이 있습니다. 이 말은 프로세스가 변경될 시 기존 시스템과 다른 시스템이 개발되어야 할 수도 있다는 것입니다.

 

이러한 프로세스 변화에 따른 개발 영향도는 PI나 UX 컨설팅 시 검토되어야 합니다. PI나 UX는 조직 시스템이 아니라 앱/웹에 적용을 위해 컨설팅한 것이기 때문입니다.

 

가끔 프로젝트를 하다 보면 PI 이렇게 이름만 붙이면 컨설팅이라 인식하는 경우도 보게 됩니다. 이러한 형식적 과정을 혁신하려는 컨설팅이 PI 컨설팅입니다. PI 컨설팅이 프로세스를 더욱 꼬이게 하면 안 될 것입니다.

 

또한 요즘은 UX 컨설팅도 많이 하는 것 같습니다. 그런데 UX 컨설팅은 그냥 디자인 제안 또는 화면 설계 가이드 정도에서 문서화하는 경우도 보게 됩니다. 이는 UX가 아니라 화면 설계입니다. 굳이 하게 될 화면 설계를 미리 조금 하면서 UX 컨설팅이라 하는 것은 작업 복잡도만 높이는 것입니다. 

 

UX라는 단어 그대로 사용자 경험에 대한 컨설팅이 되어야 할 것입니다. 그리고 이 자료를 바탕으로 화면 설계가 이루어져야 이론적/학문적으로 적절한 UX 컨설팅이 됩니다. UX는 사용자 인지와 정보의 구성을 바탕으로 형성되므로 기본적으로 데이터 기반 인지 알고리즘, 인지 학습 관련 자료가 정리되어야 하는 것이 맞습니다. 이 결과가 디자인적으로 표현된다고 디자인이 UX는 아닙니다. 디자인이 UX 디자인이 되기 위해서는 최소 인지 심리학이 반영되어야 합니다.