사수 없는 기획자가 '화면설계서'와 맞짱 뜨기
1장에서 7장이 된 나의 회원가입 화면설계서 성장기
서비스 기획자로 일하다 보면 가장 자주 마주하는 것, 바로 화면설계서다. 서비스 구현을 위해 가장 먼저, 그리고 가장 정확하게 되어야 하는 단계이기도 하다.
그렇지만 어느 누구도 잘 알려주지 않았다.
스타트업 기획자라서 알려주는 사수도 없고,
작성하면서도 뭐가 틀린지도 모르고..
내가 부트캠프에서 배울 때에는 유저의 니즈를 파악하고 화면을 그리거나 개선점을 파악하는 위주로 배웠던 것 같다. 정작 버튼 하나 눌렀을 때 서버에서 무슨 일이 일어나는지, 설계서를 어떻게 작성해야 실무에서 통하는지는 아무도 알려주지 않았다.
화면설계서? 그게 뭔데?
본격적으로 나의 삽질기를 풀기 전, 화면설계서가 뭔지부터 짚고 넘어가자. 본질은 단순하다.
화면: 유저가 보게 될 레이아웃 (어디에 버튼이 있고, 어디에 글자가 있는지)
기능 설명(Description): 그 화면에서 일어나는 모든 동작의 '설명서'
아래 화면설계서 예시를 보자.
기본적으로 화면 ID, 화면경로, 화면명이 있다. 나는 화면명으로 소통해서 화면 ID의 중요성을 몰랐었다. 그런데 나중에 안 사실은 개발자끼리는 화면 ID로 자주 소통한다고 한다.
그리고 제일 중요한 부분! 왼쪽에 화면이 있고, 오른쪽에 Description이 있다. 이 모든 것을 포함한 문서를 화면설계서라고 한다. 쉽게 말해 "유저가 여기서 이걸 누르면, 서비스는 저렇게 반응해야 한다"를 그림과 글로 정리한 문서다.
집을 지을 때 설계도가 없으면 안방 문을 열었는데 갑자기 화장실 변기가 튀어나올 수 있듯이, 서비스도 이 설계도가 없으면 버튼을 눌렀는데 무반응이거나 엉뚱한 페이지로 날아가는 대참사가 일어난다.
"페이지 이동"이 전부인 줄 알았던 순진한 시절
입사 초기, 내가 처음 작성했던 회원가입 화면설계서는 참 눈물 나게 심플했다. 사실 그때는 내가 뭘 빼먹었는지조차 몰랐다.
당시의 내 설계서: "가입하기 버튼을 누르면 가입 완료 페이지로 이동한다." (끝)
예외 처리에 대한 언급은 당연히 없었다. 다음 버튼을 클릭했을 때 로직이 어떻게 돌아가는지 관심도 없었다. 그냥 페이지가 넘어가면 장땡인 줄 알았으니까. 결국 개발자가 나를 찾아오기 시작했다.
"기획자님, 아이디 중복이면요? 비밀번호 8자리 안 넘으면요? 가입 누르면 DB에는 들어가나요? 메일은 누가 보내요?"
그때 깨달았다. 아, 나는 설계를 한 게 아니라 그냥 '그림'을 그린 거였구나.
당시 내가 작성했던 화면설계서한 장으로 시작한 회원가입 이제는 일곱 장
2년이 지난 지금, 나의 회원가입 설계서는 상당히 상세해졌다. 예전엔 화면 한 장으로 끝냈을 일을 지금은 회원가입 한 페이지지만 화면설계서 페이지로는 무려 7페이지가 나온다.
단순히 "이동한다"가 아니라, 그 이면에 숨겨진 '진짜 일'들을 적기 시작했기 때문이다.
여러 가지가 있지만 몇 가지 고려해야할 사항들을로 살펴보자.
가장 쉽게 input의 경우에는 다음과 같은 부분을 고려해야 한다.
- input창이 같아 보여도 입력 조건 표기
자율 입력으로 할 수도 있고, 숫자만 입력 가능하게 할 수도 있고(보통 핸드폰 번호 입력), 숫자를 입력하면 날짜 형태로 포맷팅 되도록 할 수 있다. (예를 들면 20260101을 입력하면 자동으로 2026.01.01 입력됨)
- 최대 입력 가능 글자수 표기
놓치기 쉬운 부분은 최대 입력 가능 글자수이다. 말 그대로 최대 몇 자까지 입력 가능한 지다.
이메일/ 인증번호/휴대폰 번호 입력에 따라 최대 입력 가능 글자수가 다르기에 이것 또한 명시해줘야 한다.
이렇게 input 하나만으로도 고려해야 할 것들이 많다.
회원가입 완료 버튼을 클릭한다고 하면 로직의 세분화가 필요하다.
1. 유효성 검사: 이메일 형식 확인, 비밀번호 규칙(특수문자, 자릿수) 검증
2. DB 저장: 조건 충족 시 회원 정보를 데이터베이스에 안전하게 저장
3. 자동화 프로세스: 가입 완료와 동시에 환영 메일 발송 로직 가동
4. 예외 대응: 서버 응답 지연 시 버튼 비활성화, 중복 가입 시 에러메시지 노출 등
회원가입 단계는 아니지만 내가 만드는 서비스 특성 상 여기저기에 날짜를 표기해야하는 부분들이 많다.
만약 날짜를 표기한 다고 하면 YYYY.MM.DD인지, YYYY-MM-DD인지, M월 D일인지, MM월 DD일인지, M월 D일(요일)인지, 심지어 요일은 월요일로 쓸 것인가, '월'로만 표기할 것인가 등등 정말 많은 케이스가 있는데 이걸 정의해주지 않는다면 개발자가 매번 물어보거나 맘대로 해서 기획 의도대로 나오지 않거나 하는 문제가 발생할 수 있다. (이미 경험 다 해봄.. 하하)
이런 것것들을 상세히 작성하고 나니 이제 개발자는 더 이상 나에게 질문 폭탄을 던지지 않는다. 휴. 다행.
기획자.. 생각보다 일이 많다. 정말 많다.
난 분명 꼼꼼히 다 했다고 생각했는데 누락되는 부분이 항상 있다.
언제나 일이 끝이 없듯, 아직도 완성형은 아니지만 나처럼 알려줄 사람도 없어 맨땅에 헤딩하고 있는 기획자를 위해 최근에 작성한 회원가입 프로세스를 일부 수정한 예시를 공유해 본다.
특히 이메일, 휴대폰 인증 단계가 있다면 이건 별도 페이지로 구성해서 각 액션 단계마다 UI와 함께 상세히 설명해야 한다.(이전에는 텍스트 몇 줄로 퉁쳤었...다)
누군가 알려줬다면 참 좋았겠지만, 결국 몸소 부딪히며 배운 것은 이것이다.
화면설계서는 단순히 예쁜 화면을 보여주는 게 아니라, 개발자가 고민할 시간을 줄여주고 유저가 겪을 오류를 미리 예측하고 준비하는 문서랄까.. 내가 자세하게 적을수록 서비스는 단단해지고, 나의 퇴근은 평화로워진다.
여전히 나는 완벽하지 않지만, 적어도 이제는 '이동합니다' 한 줄로 퉁치던 시절보다는 많이 발전한 것 같다. 아이러니하게 기획이란 것을 알면 알수록 더 바빠지는 포지션인 것 같다.
이 글을 보는 모든 기획자들 파이팅!!
회사 다니면서 제일 많이 들었던 생각...
ㅇ ㅣ 것도 제가 해요??? 아.. 나 말고는 할 사람이 없지...