기획자의 앱, 웹 설계 프로세스 그리고 이유

여기서 앱, 웹 설계는 독립적인 화면 UI, 디자인, 코딩 등을 의미하는 것이 아닙니다. 이들의 유기적 결합으로 작동되는 시스템으로의 앱, 웹 설계를 의미합니다. 또한 프로그래머나 디자인 관점이 아니라 기획자 관점에서의 설계 프로세스라는 점을 미리 밝혀 둡니다.

 

 

 

첫 번째 단계 : 앱, 웹 정의

 

기획자의 앱, 웹 설계의 시작은 정확한 설계 대상인 앱 또는 웹의 정의입니다. 이는 어떤 기획이든지 무조건 먼저 시작/완료되어야 하는 작업입니다.

 

앱. 웹 정의가 먼저 이루어져야 그 이후 설계 작업을 할 수 있는 이유는 간단합니다.

 

목표점이 없는 여행, 지역에 대한 정확한 이해가 없는 여행은 즐거운 여행이 아닌 괴로운 여행이 됩니다. 사막을 여행하는데 수영복을 챙기고 북국에 오로라를 보러 가는데 반팔을 가져갑니다. 이렇게 여행지와 목적지를 파악하지 못한 상태에서는 온전한 여행 설계를 할 수 없게 됩니다. 이런 여행은 고생의 연속이 됩니다.

 

앱, 웹 설계에서도 제대로 해당 정의가 이루어져 있지 않다면 앞으로 설계는 고생의 연속일 것입니다. 아니 같은 일을 계속 반복하게 될 수도 있습니다. 어떤 기획자는 자신이 왜 이 작업을 하고 있는지 이해하기 힘든 상황에 처할 수도 있습니다. 이런 상황에서 설계된 자료를 가지고 앱과 웹은 개발되지 못합니다.

 

제대로 된 정의가 없는 설계는 개발에 필요 없는 그냥 문서를 위한 설계가 됩니다.

 

 

 

앱, 웹 정의 부실 징후

 

앱, 웹 정의에 대해서는 이 블로그 글들에서 산발적으로 이야기하기는 했습니다. 후에 좀 더 자세히 다시 한번 정리하는 시간을 가지도록 하겠습니다.

 

이 글에서 앱, 웹 정의 부실 징후에 대해 정리해 보도록 하겠습니다. 이 부실 내용을 제대로 하는 것만으로도 정의를 할 수 있을 것이라 생각합니다.

 

앱, 웹 부실의 징후는 여러 가지가 있으나, 프로젝트 경험에서 몇 가지 확실한 징후에 대해 적어 보겠습니다.

• 앱, 웹 정책이 모호하거나 부실합니다.
• 이 앱/웹에도 적용되고, 저 앱/웹에도 적용되는 내용을 말합니다.
• 시스템 구성에 대해 명확하지 않습니다.
• 내용 정리가 되어 있지 않습니다.

 

앱, 웹 정책이 모호하다는 것은 어떤 앱/웹을 지향하는지 모르고 있다는 말이 됩니다. 그러므로 설계를 진행하게 되면 답하지 못하는 빈 곳이 생기게 됩니다.

 

이 앱/웹에도 적용되고, 저 앱/웹에도 적용되는 내용으로 정의된다는 말은 아직 결정이 되지 못하고 의사 결정자의 마음이 움직이고 있다는 말이 됩니다. 결국 이런 상태에서 설계는 끝이 나지 않을 것입니다.

 

시스템 구성에 대해 명확하지 않다는 것은 연동이나 처리 등의 부실하다는 것을 의미합니다. 이런 경우 API나 설치 솔루션 등의 처리에 대해 알기 어려운 상태입니다. 설계뿐 아니라 개발 시에도 예상보다 더 많은 작업과 시간이 걸리게 될 것입니다. 또한 연동 시스템 문제로 개발이 진행되지 못하는 일이 생길 수도 있습니다.

 

내용 정리가 안되어 있다는 말은 한마디로 설계자가 설계를 해본 적이 없다는 것을 의미할 수도 있습니다. 내용이 다 있고 정리가 안된 수준이면 큰 문제가 없다고 생각할 수도 있습니다. 그런데 여기서 내용 정리는 잘 정리된 문서를 의미하는 것이 아니고 앱, 웹 설계 대상과 작업에 대한 정리라는 점에서 문제는 있습니다.

 

보통의 경우 내용 정리가 안되어 있다는 것은 설계자가 대상이 되는 앱, 웹 설계를 해 본 적(앱/웹 설계 규모에 따른 미숙함일 수도 있습니다)이 없을 수 있습니다. 정리는 인터넷이나 다른 작업자의 자료를 모아 놓은 것일 수 있습니다. 그러므로 이후 설계 진행과 적합성이 떨어지게 되고 해설과 보충이라는 추가 작업이 필요하게 됩니다. 그리고 여러 명의 후속 기획자가 있는 경우 기획자에 따른 일관성도 떨어지게 됩니다.

 

 

 

두 번째 단계 : 앱, 웹 부분 설계

 

영화 시나리오나 소설을 쓸 때 시작부터 그냥 자리에 앉아서 쓰는 것이 아닙니다. 이야기와 관련한 조사도 하고, 캐릭터도 구상합니다. 사건들도 생각해 보고 이 사건들의 연결 과정도 그려봅니다.

 

그리고 이러한 사건마다 배경이 되는 곳을 방문하여 여러 지형과 배경, 사건이 일어날 때의 디테일도 챙겨 봅니다.

 

이외에도 다양한 조사와 정리/설계 작업을 통해 자료를 완성해야 비로소 글을 쓸 수 있게 됩니다. 보통의 경우 한 권의 영화 시나리오나 소설을 쓰는데 적게는 여러 권, 많게는 수 십 권의 조사 자료가 준비되고는 합니다.

 

이 단계는 바로 시나리오나 소설을 시작하기 전에 자료를 모으고, 각 부분의 내용을 설계하는 작업입니다. 많은 기획자나 개발자가 하는 착각 중에 기획자는 그냥 컴퓨터 앞에 앉아서 바로 스토리보드를 작성하는 것이라 생각하는 것입니다.

 

보통 영화를 제작하는 데 100억 전후, 많은 경우 200억 원 정도 비용이 들어갑니다. MVP나 스타트업의 앱/웹이 아니고 규모가 있는 앱/웹의 경우도 이 정도 비용이 들어갑니다. 뉴스에 나오는 큰 프로젝트의 경우는 1000억이 넘는 경우도 있습니다.

 

이 정도 규모의 앱/웹을 바로 스토리보드 또는 화면 설계로 개발할 수 있다고 생각하는 것은 순진하거나 모르는 것입니다. 아니면 막 학원에서 나와 처음 설계 해보는 것일 수 있습니다.

 

몇 번 프로젝트를 하다 보면 자연스럽게 시행착오를 통해 학습을 하게 됩니다. 아무리 맨 땅에 헤딩하면서 기획/설계를 했더라도 몇 번 프로젝트를 했다면 스토리보드(화면 설계)를 하기 전에 필요한 기획/설계 과정이 있다는 것은 자연스럽게 알게 됩니다.     

 

 

 

앱, 웹 기능 관련 설계

 

어떤 기능이 앱과 웹에 있어야 하고, 이 기능이 어떻게 작동하는지 정의/설계가 되어야 합니다.

 

이렇게 정의/설계된 내용들은 연동/프로세스 처리와 코딩을 할 때도 사용되지만,  화면 설계를 할 때 서버에서 처리되어 피드백되는 내용으로 이용되게 됩니다. 화면 설계 시 화면과 서버 인터페이스를 알아야 하기 때문입니다.

 

이렇게 정리된 내용은 기능정의서라고도 합니다.

 

기획자의 기능 설계는 사용자가 이용하게 될 기능의 정의와 작동, 이용 흐름 등을 통해 이루어집니다. 직접적인 코딩을 위한 기능 설계와는 차이가 있습니다.    

 

 

앱, 웹 화면 관련 설계

 

이 단계의 화면 설계는 스토리보드/화면 설계를 말하는 것은 아닙니다. 오히려 스토리보드/화면 설계를 위해서 필요한 설계 작업을 지칭하는 것이 더 정확합니다.

 

흔히 IA/메뉴와 화면에 대한 구성과 주요 화면 컴포넌트 설계를 의미합니다.

 

목적된 앱, 웹의 특성에 따라 사용자가 이용하게 될 화면은 특정화 될 수 있습니다. 그래서 쇼핑 앱, SNS 앱, 동영상 앱 등의 유형별로 유사한 메뉴 구성과 화면 구성을 가지는 것입니다. UI 또한 앱/웹의 유형에 따라 서로 다른 앱/웹이라도 비슷한 이용 방법을 보입니다.

 

이러한 것을 바탕으로 공통 컴포넌트, UI에 대한 정리를 합니다. 이러한 작업은 후에 스토리보드/화면 설계를 여러 명의 기획자가 하더라도 일관성을 유지할 수 있게 하고, 또 작업 속도를 높일 수 있는 요소가 됩니다.

 

화면 구성을 설계하는 것은 앱/웹 유형에 따라 유사할 수 있는 앱/웹의 UX를 차별화하는 앱/웹 아이덴티티를 형성하게 합니다.

 

이렇게 작업된 앱, 웹 화면 관련 설계는 화면정의서라고도 합니다. 예시가 필요한 핵심 화면의 경우 와이어프레임 작업을 통해 전반적인 구성을 정리합니다.

 

화면정의서는 메뉴를 기준으로 해당 앱/웹의 모든 화면을 정의합니다. 이 작업을 통해 반복되고, 여러 메뉴에서 공통으로 쓰는 컴포넌트 UI 경우 정리해 놓을 수 있습니다. 또한 웹 접근성 적용이 중요한 경우 와이프레임을 통해 컴포넌트 배치 예시를 규정해 놓을 수 있습니다.

 

 

 

세 번째 단계 : 스토리보드

 

이제 비로소 스토리보드 작업을 할 수 있게 되었습니다. 스토리보드 작업은 지금까지 기획/설계 자료를 바탕으로 진행합니다. 이는 앞선 예에서 영화 시나리오나 소설의 작업을 하는 것과 같습니다.    

 

우리는 대학수학능력시험을 치르기 위해 초등학교 6년, 중학교 3년, 고등학교 3년의 12년의 선행 작업을 합니다. 만약 어떤 사람이 그냥 하루 시험을 치르는데 왜 12년의 과정이 필요하냐고 말한다면 그냥 교육 과정에 대해 모르는 사람인 것입니다. 단지 뉴스에 나오는 수능 날만 보고 말하는 것입니다.

 

스토리보드에 대해서도 같습니다.

 

만약 스토리보드 작업을 하라고 하는 데 있어야 할 앞선 설계 내용들을 전달해 주지 않는다거나, 아예 스토리보드 작업을 하는데 그런 게 왜 필요하냐고 한다면 기획/설계를 해본 적은 없고 그냥 본 것뿐인 사람입니다.

 

또한 이전에 작업한 내용들이 스토리보드 작업과 연결되지 않는다면 이 또한 기획/설계를 해본 적 없는 사람인 것입니다.   

 

작은 스타트업이 앱이나 웹을 개발하려고 30P~40P 정도 되는 스토리보드를 작성했다고 가정합니다. 이 정도 스토리보드면 작은 앱/웹 정도입니다. 하지만 이 스토리보드에 들어갈 기능과 화면을 구상하기 위해, 또 개발 방식을 고민하기 위해 수 백 페이지의 연구/설계 문서가 있다는 것은 작업을 해본 기획자라면 누구나 알고 있는 사실입니다.

 

마치 대학수능 시험을 보기 전 12년에 해당하는 교육 과정이 있었고, 시나리오로 영화를 찍기 전에 수년간 관련 조사와 캐릭터 구상, 사건 구성 관련 등의 수 천 페이지의 자료가 있다는 사실과 같습니다. 이런 과정이 없다면 제대로 수능 시험을 치르지 못하고, 영화 내용도 말이 되지 않는 엉망이 되듯이 앱, 웹도 단지 스토리보드만으로는 엉망이 됩니다.