UI.UX / 화면 설계서 이야기. 2
PART.3 화면 설계서 구성요소 - 표지
"시작이 있으면 끝이 있다" 반대로 말하면 "끝이 있으면 시작이 있다" 설계서 역시 하나의 결과물로 완성되기 위해서는 시작과 끝이 있다. 이번 주제에서는 설계서의 시작이 무엇인지 함께 살펴보도록 하자.
잠깐, 우리는 무에서 유를 창조하는 작업을 하는 것이 아니다. 무조건 새롭게 만들려고 하는 것보다 기존에 작성된 화면 설계서의 존재 여부를 먼저 확인하자. 기존 화면 설계서야 말로 우리 서비스의 기초가 되는 내용들을 확인할 수 있는 가장 쉬운 방법이다. 또한 내가 맡은 업무의 학습이 가능하며 그간의 작업 히스토리를 확인할 수 있다.
표지 - 설계서의 시작
- 프로젝트명: 진행 중인 프로젝트명이나 시스템명이 들어간다. 설계서를 보는 사람은 프로젝트명을 통해 어떤 프로젝트인지 쉽게 확인이 가능하다. 동일한 메뉴의 설계서라 하더라도, 고도화 시기에 작성된 것인지 운영 업무 시기에 작성된 것인지에 따라 정의된 내용은 달라질 수 있다. 따라서 누가 봐도 명확한 프로젝트명을 기재해주는 것이 중요한 부분이다.
- 담당 메뉴명: 설계서가 어떤 메뉴에 대해 작업되어 있는지 확인이 가능하다. 만약 한 개의 설계서가 2개 이상의 메뉴를 포함하고 있다면, 위의 그림과 같이 구체적으로 명시하자. 만약 위의 그림에서 담당 메뉴명을 '회원'으로만 명시한다면 '회원가입'이나 '로그인'의 설계서라고 즉시 예측하기는 어려울 것이다. 문서의 기본은 문서를 보는 사람의 입장에서 작성되어야 한다. 또한 문서를 통해 서로 간 달리 해석이 돼서는 안 된다. "쉽게 보여주고 있는가?" "누가 봐도 명확한가?" 이 질문의 끈을 놓지 말자.
- 버전: 일반적으로는 버전이 변경됨에 따라 이전 버전과의 내용이 차이가 있음을 알 수 있다. 여기서의 차이란 이전 버전과 비교했을 때 추가되는 내용이 있거나 수정 및 삭제된 내용이 있음을 말한다. 더불어 프로젝트에서 버전의 의미는 약속의 의미를 내포하기도 한다. 버전 표기를 통해 약속된 '설계의 단계'를 예측할 수 있다.
예를 들어 0.1~0.4 버전은 현업에 공유되지 않은 초안, 0.5~0.9는 현업의 공유를 통해 수정사항을 반영된 안, 1.0은 설계서의 확정 안과 같이 각 단계의 범위를 정해 놓는 것이다. 범위를 정하여 약속을 하는 이유는 프로젝트이기 때문인데, 상세한 내용은 아래의 박스를 참고하자.
프로젝트는 정해진 기간과 범위라는 것이 존재한다. 특히나 워터폴 방식의 프로젝트에서는 '확정'이라는 개념이 중요하다. 정해진 기간 동안 각 단계를 수행하기 위해 단계별 '확정'을 하여 다음 단계로 넘어간다. 한번 떨어진 폭포는 다시 위로 올라가지 못하듯이, 한번 정해진 설계서는 누락이 발생하지 않는 한 추가적인 수정과 기능 추가가 발생할 수는 없는 것이다. 만약 설계서가 언제든지 수정할 수 있다면 디자인, 퍼블, 개발 파트도 끝없는 수정을 해야 함과 동시에 프로젝트의 종료 일정을 맞추기는 어려우며, 프로젝트 일정이 지연됨으로써 책임의 원인을 묻게 되는 끔찍한 일이 생길 것이다.
※ 워터폴 방식의 프로젝트라 하여 확정된 설계서가 무조건 수정이 안 되는 것은 아니다. PM (Project Manager)의 결정과 역량 내에 말도 안 되거나? 합리적인 선에서 기능이 추가될 수도 있음을 알아두자.
- 작성일: 설계서는 기획자가 며칠에 걸쳐 작성을 할 수도 있는데, 동일한 버전에서 문서의 차별이 필요할 때 작성일자를 통해 구별이 가능하다. 예를 들어 현재 작성하고 있는 버전이 0.5이며 아직 현업 및 타파트에는 공유를 하지 않았다. 그런데 팀 내부 검토를 통해 몇 가지 보완된 내용이 발생하게 되었고, 작업일정을 산정해보니 1일 정도는 더 필요할 것으로 보였다. 이럴 때 설계서는 버전을 그대로 두고 작성일만 마지막 최신일로 업데이트를 해두면 이전 내용과도 구별하기가 수월하다. 작성한 날짜라서 작성일이라고만 생각하지 말고, 명시한 내용의 특징을 파악하여 어떻게 쓰이는지 계속해서 고민해보는 자세가 중요하다.
※ 만약 동일한 날짜에 수정이 계속 발생하여 빨리 이해관계자들과 공유를 해야 하다면 작성일은 어떻게 표기해야 할까? 정해진 룰을 깨지 않는 한 룰 내에서 파생적으로 다른 룰을 협의하에 추가할 수 있다. 글쓴이 같은 경우애는 위와 같은 상황이라 한다면 현업이나, PM, PL과 협의하여 버전의 방식을 추가한다. 예를 들어 현재 버전이 0.5인데 수정후 바로 공유를 해야 한다면 버전 뒤에 자릿수를 추가하여 0.5.1과 같이 구별을 하는 것이다. '안 되는 것은 없다.' 다만 그것이 필요하다고 모두가 공감이 갈 때 원활한 협의를 통해서 작업의 방식을 업그레이드하는 것이다.
※ 누군가는 이렇게 얘기한다. "원래 설계서는 업데이트될 때마다 버전을 업데이트해줘야 해! 그게 당연한 거야" 너무나 답답하고 듣기 싫은 소리가 따로 없다. 설계서 작성 방식이 최초의 하나님이 천지를 창조하실 때부터 정해진 것인가? 아니면 우주의 빅뱅이 시작됐을 때 정해진 것인가? 반복해서 말하지만 원래라는 것은 없으며, 그 모든 것은 필요에 의해서 만들어진 것이다.
단, 우리는 조직이 그동안 시스템을 효율적으로 운영하기 위해 만들어진 룰을 따를 필요가 있다. 그것은 모두가 동의한 내용이며 어려운 과정을 통해 이루어낸 것이다. 나라는 개인이 멋대로 그것을 바꾼다는 것은 나 때문에 모두가 합의한 내용을 바꿔 사용해야 한다는 말과도 동일하다.
따라서 위 경우처럼 '설계서를 업데이트할 때마다 버전 업데이트'를 해야 하는 조직의 룰이 분명하다면
"그냥 하라면 해"가 아닌 "우리의 약속이며 가이드이다"라는 전제조건을 충분히 공감하게 해 주어 혼선 없는 업무의 지시가 필요하다.
- 저작권 및 로고: 설계서는 '갑' 사의 재산과도 같다. 따라서 무단으로 반출되거나 도용을 해서는 안된다. 때문에 명확한 저작권 표시와 로고가 표시되어야 한다. 설계서는 외부로 반출되는 것만으로도 일반적인 보안서약에 위배가 되는 경우이며, (일부 프로젝트는 해당 안될 수 있음) 반출한 사람이 발각될 경우 소속된 회사는 막대한 비용을 배상할 수도 있다. 기획자 본인이 만든 설계서가 '자신'의 것이라고 생각하지 말자. 우리는 '갑'인 고객사에게 '설계서'라는 '산출물' 제공한 것이며 소유의 주체는 '갑'에게 있음을 정확히 인지하자.
'무슨 표지 하나로 이렇게 오래 설명하느냐'라고 생각이 들 수도 있겠지만, 글쓴이는 화면 설계서를 주제로 글을 쓰기로 마음을 먹었을 때, '단순하게 화면 설계서는 이렇게 작성하는 겁니다.'라는 방식으로 공유하고 싶지 않았다. 기획자의 일부 업무인 '화면 설계서'이지만, 글쓴이가 생각하는 본질에 대해서 이야기하고 싶었으며, 화면 설계서가 일부 업무인 동시에 '왜' 메인 업무가 될 수밖에 없는지를 설명하고 싶어서 '표지'파트부터 내용이 길어질 수 밖에는 없었다.
다른 얘기지만, 우리가 하고 있는 일의 특성상 '의심하는 사람'이 되어야 한다. "이게 정말 맞는 건가?" "시키니까 했지만 정말 맞는 거야?"라는 의심하는 자세가 필요하다. 의심을 한 후 잘못되었다고 조금이나마 판단되었을 때는 용기를 내어 사수나 리더에게 문의를 해야 한다. 만약 본인이 이러한 경험이 있는데 사수나 리더에게 냉정한 피드백을 들었다 하더라도 결코 포기해서는 안된다. 만약 글을 읽고 본인이 그러한 사람이라면 글쓴이는 진심으로 일어서서 박수치며 위로와 격려를 하고 싶다. 대부분 일의 구멍과 사고는 의심을 하지 않기 때문에 발생하는 것이기 때문에 '시키는 데로만 하는 수동적인 태도'로써 일을 하면 안 되는 것이다.
이하 막론하고 '화면 설계서'에 대해 본질적인 이야기를 다음화에서도 계속 이어 나가 보도록 하겠으며, 오늘도 항상 적극적인 자세로 일하는 기획자들에게 진심으로 존경의 마음을 표한다.
끝.
