설계는 화면이 아니라 구조에서 시작된다

많은 사람들이 기획을 ‘화면을 만드는 일’이라고 생각합니다. 어떤 버튼을 어디에 배치할지, 어떤 문구를 넣을지, 어떤 색을 사용할지부터 고민하는 경우가 많습니다. 그러나 진짜 기획은 화면에서 시작하지 않습니다. 그보다 먼저, 사용자가 어떤 흐름으로 움직일지, 시스템이 그 움직임에 어떻게 반응할지, 그리고 그 모든 과정이 어떤 비즈니스 목적과 연결되어 있는지를 구조적으로 설계하는 일에서 출발합니다. 화면은 결과물일 뿐입니다. 그 화면을 움직이게 하는 논리와 흐름, 정책과 정의가 먼저 정리되지 않으면, 아무리 예쁜 UI를 만들어도 서비스는 흔들립니다.

그래서 기획자는 세 가지를 동시에 다루어야 합니다.
사용자의 경험 흐름을 설계하는 서비스 플로우, 그 흐름을 정확히 구현하도록 정의하는 개발정의서, 그리고 그 구조를 시각적으로 정리하는 스토리보드입니다. 이 세 가지가 분리되어 있으면 프로젝트는 엇나가고, 유기적으로 연결되어 있을 때 비로소 설계는 힘을 갖습니다.

이제 그 구조를 하나씩 살펴보겠습니다.

 

1. 서비스 플로우: 사용자의 길을 먼저 설계하는 일

서비스 플로우는 단순히 화면 이동을 나열하는 작업이 아닙니다. 그것은 사용자가 우리 서비스를 어떻게 ‘경험하게 될지’를 미리 그려보는 과정입니다. 사용자가 어떤 디바이스로 들어와, 어떤 페이지에서 무엇을 누르고, 어떤 감정을 느끼며, 어떤 선택을 하게 되는지를 시간의 흐름에 따라 구조화하는 일입니다.

특히 중요한 것은 사용자만 그리는 것이 아니라, 그 흐름 속에서 시스템이 어떤 역할을 수행하는지까지 함께 정리하는 것입니다. 사용자는 버튼을 클릭하지만, 그 뒤에서는 데이터가 임시 저장되고, 매핑되고, 검증되고, 최종적으로 DB에 기록됩니다. 이 보이지 않는 시스템의 움직임을 함께 명시해 주면, 개발자는 기능 구현의 맥락을 훨씬 선명하게 이해하게 됩니다.

좋은 서비스 플로우는 “이 화면 다음에 이 화면으로 이동한다”에서 끝나지 않습니다.
“왜 이 단계가 필요한지”, “여기서 사용자가 이탈할 가능성은 없는지”, “불필요하게 복잡한 과정은 아닌지”까지 고민해야 비로소 설계라고 할 수 있습니다.

예를 들어 가입 프로세스를 생각해보면, 약관 동의 → 정보 입력 → DB 저장 → 가입 완료라는 단순한 구조처럼 보이지만, 그 안에는 여러 판단 지점이 존재합니다. 약관을 체크하지 않으면 어떻게 할 것인지, 입력값이 유효하지 않으면 어떤 메시지를 보여줄 것인지, 중복 이메일일 경우 어떤 흐름으로 되돌릴 것인지까지 설계해야 합니다.

서비스 플로우를 그리는 이유는 결국 하나입니다. 화면을 만들기 전에, 경험을 먼저 설계하기 위함입니다.

 

2. 개발정의서(기능명세서): 그림이 아니라 실행을 위한 문서

스토리보드가 ‘보여주는 문서’라면, 개발정의서는 ‘만들게 하는 문서’입니다.
많은 프로젝트에서 스토리보드만으로 개발을 진행하려다가 오해가 생깁니다. 화면은 그려져 있지만, 실제 동작 규칙과 예외 상황이 명확하지 않기 때문입니다.

개발자는 그림을 보고 레이아웃을 이해할 수는 있지만, 버튼 클릭 시 어떤 로직이 실행되어야 하는지, 어떤 API를 호출해야 하는지, 입력값 검증 기준은 무엇인지까지는 스토리보드만으로 파악하기 어렵습니다. 그래서 개발정의서가 필요합니다. 개발정의서는 기능을 영역별로 나누고, 각 기능의 목적과 동작 방식, 입력값과 출력값, 예외 처리, 필수 여부 등을 텍스트 중심으로 정리합니다. 이 문서는 감성적인 설명이 아니라, 논리적이고 실행 가능한 정의가 중심이 됩니다.

예를 들어 회원가입 기능을 정의할 때는 다음과 같은 질문에 답해야 합니다.

• 이름은 몇 자까지 허용되는가?
• 이메일은 어떤 형식을 통과해야 하는가?
• 비밀번호는 어떤 조합이 필수인가?
• 중복 이메일일 경우 화면은 어떻게 반응하는가?
• 약관 동의 정보는 언제 DB에 저장되는가?

이러한 정의가 명확하면 개발자는 추측하지 않아도 됩니다. 추측이 줄어들면 재작업이 줄어들고, 재작업이 줄어들면 QA 부담이 감소합니다.

결국 개발정의서는 개발자를 통제하기 위한 문서가 아니라, 개발자가 더 잘 만들 수 있도록 환경을 정리해 주는 문서입니다. 그래서 좋은 기획자는 개발자의 실수를 지적하는 사람이 아니라, 실수할 여지를 줄여주는 사람이라고 하는 것입니다.

 

3. 스토리보드 레이아웃과 상세설명: 읽히는 문서를 만드는 기술

스토리보드는 종종 “디자인 초안”처럼 오해받습니다. 하지만 스토리보드는 디자인을 위한 문서가 아니라, 기능과 구조를 전달하기 위한 문서입니다. 그렇기 때문에 시각적으로 화려할 필요는 없습니다. 오히려 단순해야 합니다. 레이아웃과 설명을 배치할 때도 전략이 필요합니다. 사람은 왼쪽에서 오른쪽으로 읽습니다. 따라서 설명을 왼쪽에 두고, 레이아웃을 오른쪽에 배치하면 자연스럽게 텍스트를 먼저 이해한 뒤 화면 구조를 확인하게 됩니다. 이 순서가 중요합니다. 설명을 이해하지 못한 채 화면을 보면, 보는 사람은 자신의 해석을 덧붙이게 됩니다. 그 순간부터 오해가 시작됩니다.

또한 스토리보드는 가능한 한 정량적으로 표현해야 합니다. “적당히”, “넉넉하게”, “충분히” 같은 표현은 개발 단계에서 혼란을 유발합니다. 대신 “최대 30자”, “8~16자”, “3회 제한”처럼 명확한 기준을 제시해야 합니다. 색상 역시 최소화하는 것이 좋습니다. 그레이와 블랙 중심으로 구성하면 문서의 목적이 분명해집니다. 스토리보드는 예쁘게 만드는 문서가 아니라, 이해시키는 문서이기 때문입니다.

그리고 무엇보다 중요한 것은, 이 문서는 내가 보기 위한 문서가 아니라 함께 일하는 사람들이 이해하기 위한 문서라는 점입니다. 기획 문서의 완성도는 디자인 퀄리티가 아니라, 읽는 사람이 얼마나 빠르게 이해하고 실행할 수 있는가로 판단됩니다.

 

정리

서비스 플로우는 사용자의 길을 설계하는 작업이고, 개발정의서는 그 길을 실제로 구현하게 만드는 문서이며, 스토리보드는 그 구조를 시각적으로 공유하는 도구입니다. 이 세 가지가 유기적으로 연결될 때, 기획은 비로소 힘을 가집니다.