brunch

매거진 말랑말랑한 서비스기획

라이킷 635 댓글 29

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 김광섭 Sep 10. 2019

고양이도 할 수 있는 앱 설계서 작성법

화면 설계서(와이어프레임) 이렇게 만듭니다

앱 화면 설계서(와이어프레임) 작성 매뉴얼입니다. 원래 나중에 후배가 생기면 한껏 차갑고 전문적인 표정을 지으면서 ‘OO씨 이거 내일까지 다 읽어오세요’ 하고 싀-크하게 건네주려던 글이었습니다. 하지만 후배는 도통 들어올 기미가 안 보이고.. 지금 하는 일은 언제까지 할지 모르겠고..(...)

그래서 제가 예전에 그랬던 것처럼, 오늘도 언 땅에 호미질을 하고 있을 수많은 초보 기획자분들께 작게나마 도움이 되고 싶어 그간의 경험을 미주알고주알 정리했습니다. 이 매뉴얼은 고양이도 알아들을 수 있을 만큼 쉽고, 쉽고... 음 그냥 쉽습니다. 전문지식이 전혀 없어도 이해할 수 있습니다.

이 글은 다음과 같은 분들이 읽으시면 좋습니다.

겁나 대박인 아이디어가 생각났는데 앱 설계를 어디서부터 시작해야 할지 모르겠는 경우

어느 날 갑자기 나이 지긋하신 상무님이 ‘거 우리도 앱이란 거 한번 만들어보지?’ 하고 막 던지셨는데 우리 팀장님이 거부를 못했고, 마침 그게 나한테 떨어진 경우

개발자(프로그래밍)랑 디자이너(디자인)가 무슨 일을 하는지는 알겠는데 서비스 기획자는 도대체 밥만 축내는 인간 아닌가 하는 (고약한) 생각이 드는 경우

지금 쓰고 있는 수많은 앱들이 처음 만들어질 때 어떤 과정을 거쳤는지 궁금한 경우

목차는 다음과 같습니다.

시작하기
화면(스크린) 그리기
정보구조도(IA) 만들기
화면 이름(스크린 아이디) 짓기
화면 경로(스크린 패스) 쓰기
컴포넌트(디스크립션) 붙이기
시나리오 만들기
버전 관리하기
공통 요구사항 쓰기

*위 용어는 업계에서 쓰는 단어들인지라 우리말과 영어를 어쩔 수 없이 혼용하도록 하겠습니다.

*UX/UI 디자인 가이드는 아닙니다. 이 글은 앱 기획 초심자가 따라 할 수 있는 '화면 설계서(문서) 작성 가이드'입니다. UX/UI 가이드가 궁금하시다면 최철호 작가님을 추천드립니다.

시작하기

꼭 만들고 싶은 (혹은 누가 시켜서 만들어야만 하는) 앱이 생겼습니다. 고객 조사도 충분히 했고 필요한 서비스가 무엇인지도 알았습니다. 하지만 앱 기획을 한 번도 해본 적이 없는 꼬마 기획자는 화면을 도대체 어디서부터 그려야 할지 감도 오지 않습니다. 밥 아저씨가 ‘껄껄 참 쉽죠?’ 하고 가르쳐주면 좋겠지만 우리 현실은 절대 그렇게 녹록하지 않습니다. 초심자는 아래 과정을 따라 합니다.

그립읍니다..밥아저씨..

우선 플레이스토어나 앱스토어를 엽니다. 그리고 내가 만들려는 서비스와 같은 분야의 키워드를 3개 정도 검색합니다. 그러면 비슷한 앱들이 시리얼 광고 속 우유처럼 쏟아져 내립니다. 이중에 가장 '잘 나가는' 앱을 5개 정도 다운로드합니다. 예전에 써봤던 앱도 상관없습니다. 오히려 구면인 친구가 더 좋을 때도 많습니다. 저는 이걸 일짱 앱이라고 부릅니다. 이제 그 일짱 앱들의 화면을 콩밥에서 콩을 골라내는 꼬맹이처럼 뚫어져라 읽어봅니다. 동시에 그 앱의 구성 방식을 공책에 똑같이 따라 그립니다. 주요 화면을 10개 정도를 고른 뒤 디자인을 걷어내고 선(와이어)으로만 이루어진 구조(프레임)를 만듭니다.

여기 이미 모범 답안이 있습니다

참고용 일짱 앱을 고를 때 알아두면 좋은 팁이 몇 개 있습니다. 하나는 현재 업계의 표준이 된 앱을 고르는 겁니다. 숙박? 에어비앤비, 채팅? 카카오톡, 음악? 멜론, 호텔? 트리바ㄱ..처럼 분야별로 가장 잘 나가는 앱을 봐야 합니다. 잘 나가는 서비스는 무조건 잘 나가는 이유가 있기 때문입니다. (따라서 공공기관 앱 같은 건 절대 네버 노노) 둘째는 앱스토어 (한국) 국가 제한을 없애는 것입니다. 지구는 넓고 해외에는 좋은 앱들이 무진장 많습니다. 우리는 외국인 선생님도 가리지 않습니다. (구글에 ‘앱스토어 국가 제한 풀기’를 검색합니다)

그렇게 하루 이틀 날을 잡고 나랑 비슷한 생각을 했던 과거의 사람들과 허심탄회하게 대화합니다. 이렇게 잘 만든 앱을 물고 뜯고 하다 보면 내가 아무 생각도 없이 쓰던 앱이 사실 누군가가 등골 휠만큼 노력해서 나왔구나 하는 것을 느낄 수 있습니다. 하지만 감탄도 잠시, 이제는 내 등골이 휠 차례입니다. 문방구에 가서 공책과 펜을 사 옵니다.

화면(스크린) 그리기

이제 우리(나의) 서비스를 담은 화면을 삐뚤빼뚤 그려봅니다. 똑같이 베끼는 것이 아닙니다. 이미 있는 서비스라면 내가 굳이 만들 필요도 없습니다. 기존 앱을 참고하되 내 생각을 반드시 넣어서 그립니다. 가끔 대기업이 스타트업 앱을 똑같이 카피하는 경우가 있는데 이건 범죄입니다.

처음 그려보는 화면은 누구나 못 그립니다. 따라서 열에 아홉은 초등학생 그림일기 같은 결과가 나오지만 실망할 필요는 없습니다. '처음인데 뭐'하고 뻔뻔하게 생각하는 게 중요합니다.

처음인데 뭐

기획자가 초기 화면을 그리는 도구는 굉장히 다양합니다. 금손(혹은 경험자)이라면 스케치나 XD처럼 디자인 툴을 사용하면 좋습니다. 이 중에서 어도비의 XD는 배우기도 쉽고 일단 한번 배워 놓으면 두고두고 큰 도움이 됩니다. (영상 툴처럼 엄청 어렵지 않습니다.) 앞으로도 왠지 이 일을 계속할 것 같다 싶으면 처음부터 배워두시는 것이 좋습니다. XD는 최근에도 계속 업데이트되는 서비스이며, 개발 시 연계도 편하기 때문에 무척 좋은 도구입니다.

XD를 통해 간편하고 깔끔하게 편집할 수 있습니다

금손까지는 아니지만 어느 정도 손재주가 있는 경우에는 오븐이나 액슈어같은 프로토타이핑 도구를 써도 됩니다. 특히 오븐은 다음카카오에서 만든 서비스입니다. (아마 스타트업이 개발한 프로그램을 인수한 것 같습니다) 화면 프레임이나 버튼들이 도구 모음으로 잘 정리되어 있어 초보자가 쓰기에도 간편합니다. 하지만 최근 전혀 관리를 안 하고 있는 것 같다는 단점도 있습니다. (업데이트 좀..)

그런데 ‘나는 금손도 은손도 아니다, 똥손이다’ 하는 경우도 있습니다. 그럴 때는 파워포인트를 이용해 네모, 세모 도형을 넣거나 손으로 슥삭슥삭 그려도 아무 문제없습니다. 화면을 그리는 도구 자체는 하나도 중요하지 않기 때문입니다. 초기 화면을 그리는데 정말 중요한 것은 '이 화면의 중심 기능을 다른 사람도 이해할 수 있게끔 큼직큼직하게 만드는 것'입니다. 그러니까 대충일지라도 최대한 빨리 그려서 누군가를 보여주는 것이 화면 만들기의 제1원칙입니다.

이렇게 알림장 낙서 같은 화면이라도 일단 그리고 나면 이제 조금도 망설이지 말고 고객을 찾아갑니다. 앞서 고객이라고 거창하게 표현했습니다만 그냥 지금 만드는 서비스를 쓸 만한 아는 사람을 찾아가면 됩니다. (지금 옆자리에 앉아 있는 사람도 괜찮습니다) 초심자가 처음 만든 화면은 당연히 저세상급-저퀄이기 때문에 망태기 자루처럼 후줄근합니다. 이미 월드클래스 앱들만 쓰고 계신 고객님 눈에 이런 화면이 성에 찰 리 없습니다.

기획자는 이때 잠시 심리학자가 되어 사람의 본성을 자극합니다. 화면을 보는 고객에게 ‘내가 해도 이것보단 잘하겠다’는 생각이 들게끔 노력합니다. 인상을 잔뜩 쓰는 아저씨(고객)에게 속없는 철면피처럼 다가가서 '님이라면 여기 어떻게 만들 거 같음?’하고 뻔뻔하게 묻습니다. 그러면 그 고객은 기다렸다는 듯 시어머니 잔소리 폭탄을 한 무더기 쏟아놓습니다.

경험상 고객의 5명 중 한 분은 금붙이처럼 소중한 피드백을 줍니다. 보통 ‘와 이거 너무 불편하다, 내가 쓰는 다른 앱에서는 이 기능은 이렇게 만드는데 말이지’ 하는 식으로 레퍼런스까지 알려줍니다. 기획자는 이런 잔소리를 꼼꼼히 적어서 돌아온 뒤 한 땀 한 땀 내 화면을 업그레이드합니다. 그리고 반복입니다. 도르마무와 협상하는 닥터 스트레인지처럼 계에에-속합니다. 제 경우에는 개인, 단체, 관계자 인터뷰 그리고 UX디자이너 회의까지 한 달 넘게 이 일만 했었습니다. 그리고 나면 화면이 넝마자루 수준에서 세련된 에코백으로 천지개벽합니다.

도르마무 화면을 수정하러왔다

처음 화면을 그릴 때 초보자가 하는 가장 흔한 실수는 ‘화면을 예쁘게 만드는 것'입니다. 처음 그리는 화면은 절대 예쁘게 만들면 안 됩니다. 그 이유는 3가지입니다. 첫째 예쁘게 만드는 데는 시간이 많이 듭니다. 예쁘게 만들 시간에 고객 인터뷰를 한 번이라도 더하는 게 기획자가 할 일입니다. 앞에서도 이야기했지만 앱은 혼자 만드는 것이 아니라 쓸 사람에게 물어보며 만들어야 합니다. 잘못하면 예쁜 쓰레기가 됩니다.

이런 마인드 절대 안됨 (대학일기)

둘째, 내가 예쁘게 만들어도 안 예쁩니다. 기획자가 아무리 용을 쓰고 밤을 새 가며 그린 화면도 나중에 디자이너가 보면 초등학교 3학년이 과학의 달에 그린 해저도시 상상화 정도로 보입니다. 마지막 셋째, 어차피 지금 그린 화면은 99.99% 확률로 버려야 합니다. 다수의 고객이 마음에 안 든다고 하면 한치의 망설임 없이 지금 화면을 폐기합니다. 괜히 예쁘게 만드는 동안 들인 시간 때문에 미운 정이 생기면 버려야 할 못난 UI를 못 버리게 됩니다.

어느 정도 화면이 정리되었다 싶으면 앞서 말씀드렸던 도구들을 활용해 화면을 정리합니다. 그리고 화면 설계서의 좌측 중앙에 큼직하게 박아 넣습니다. 저는 보통 파워포인트 기본 툴이나 파워 목업 기능을 사용합니다. 디자인 쪽으로 강점이 있는 분들은 스케치라는 도구를 활용합니다. 스케치는 몇 년 전부터 워낙 핫한 툴이라 여기저기 설명이 많습니다.

정보 구조도(IA) 만들기

두 번째는 정보 구조도입니다. 업계에서는 보통 인포메이션 아키텍처라고 부르거나 이것을 줄여 IA라고도 씁니다. 이름에서부터 알 수 있듯이 IA는 앱의 정보가 담긴 형태를 알려줍니다. IA라는 이과풍(?) 이름은 문과생 찌랭이가 괜히 함부로 열었다간 폭발할 것 같은 위압감을 줍니다. 하지만 이 문서는 의외로 매우 간단하기 때문에 기획자가 직접 만듭니다. 내 머릿속에만 있던 앱을 모든 사람이 볼 수 있도록 뼈대를 세우는 작업으로 보시면 됩니다.

IA는 일반적으로 엑셀에 적습니다. (그냥 그리는 경우도 있습니다.) 우선 엑셀을 켜고 첫 번째 열에 ‘인덱스’, 두 번째 열에 ‘기능’이라고 씁니다. 그리고 2,3,4… 열에는 뎁스 1(Depth), 뎁스 2, 뎁스 3...(처음에는 보통 6까지 적습니다)이라는 식으로 적습니다. 여기서 뎁스란 해당 화면까지 접근하기 위해 얼마나 많은 화면을 지나쳐왔는지를 나타냅니다. 쉽게 말해 버튼을 몇 번 눌러야 이 ‘깊이’까지 들어갈 수 있는지 알려주는 것입니다. 추가적으로 뎁스 뒤에는 설명, 타입, 디렉토리 등을 적을 수 있습니다. 하지만 어차피 나중에 개발 문서를 또 만들기 때문에 일단 위 세 가지 사항은 생략합니다.

IA 예시화면입니다

IA는 엑셀로 만든다고 말씀드렸습니다. 하지만 이것을 처음부터 엑셀로 만드는 것은 인피니티 스톤을 맨손으로 잡는 것처럼 무모한 행동입니다. 만드는 중간에 빼먹는 화면이 계속 생겨서 엄청 헷갈리기 때문입니다. 그래서 다짜고짜 엑셀 시트를 붙들고 있는 작업자는 ‘아 맞다' 소리를 반복하며 세월아 네월아 ‘열 추가’, ‘행 추가’ 지옥에 빠지게 됩니다. 깔끔해야 할 파일은 누더기가 됩니다.

그래서 저 같은 경우에는 포스트잇을 활용한 꼼수(?)를 씁니다. 우선 회사에서 넓직한 회의실을 하나 빌립니다. 그리고 작은 포스트잇에 프로토타입으로 만든 화면의 주요 기능을 슥삭 적습니다. 다음으로 가장 큼직한 주요 화면(보통 하단 탭이나, 메뉴바의 주요 기능)을 좌에서 우로 혹은 위에서 아래로 충분한 간격을 두고 띄엄띄엄 붙입니다.

주요 기능을 붙였으면 이제 그 주요 기능 밑(옆)으로 내려가며 세부 기능을 붙입니다. 카카오톡을 예를 들자면 주요 화면은 ‘친구’, ‘채팅’, ‘검색’, ‘게임’, ‘더보기’입니다. ‘친구’ 아래에는 ‘나’, ‘생일 친구’, ‘즐겨찾기’, ‘추천 친구’, ‘플러스친구’, ‘설정’ 등 다양한 기능이 두 번째 뎁스에 따라붙습니다. 각각의 상세 기능 역시 그 밑에 세부 기능이 따라옵니다. ‘설정’을 누르면 세 번째 뎁스에 ‘편집’, ’ 친구 관리’, ‘전체 설정’이 나오는 식입니다.

예시를 위해 일부만 작성해 보았습니다

이렇게 1-2시간 정도 작업을 하고 나면 내가 만드는 앱이 어떤 형태이며 각 화면이 연결되는 경로를 한눈에 파악할 수 있습니다. 마지막, 제일 말단(맨 밑에 있는 화면들)에는 최종 화면까지 오기 위해 지나온 경로를 줄줄 써줍니다. (예시: 친구 -> 설정 -> 편집) 보통 다른 색깔의 포스트잇을 사용하여 작성하는데 이 포스트잇은 따로 쓸 곳이 있습니다. 스크린 패스를 작성할 때 참고할 겁니다.

다 그린 IA는 화면 설계서의 3번째 장에 붙여놓습니다. 보통의 화면 설계서는 표지 -> 버전 관리 -> IA -> 화면 설계서 -> 시나리오 -> 기타 사항 순으로 구성됩니다. 이렇게 IA를 초반에 붙이는 이유는 IA가 화면 설계서에서 목차 역할도 할 수 있기 때문입니다. 개발자나 디자이너는 문서 앞에 있는 IA를 보고 해당 자료가 어떤 기능의 화면을 담고 있는지 파악합니다.

화면 설계서를 여러 개로 쪼개는 기준도 IA를 통해 정합니다. 예를 들어 카카오톡처럼 거대한 서비스는 하나의 화면 설계서 안에 욱여넣을 경우 문서가 수백 장에 달할 만큼 커집니다. 화면 설계서는 기본적으로 개발자와 디자이너가 편하게 작업하도록 만드는 문서입니다. 문서 하나가 이렇게 커지게 되면 읽기에 무척 불편하기 때문에 본래의 목적을 잃습니다. 따라서 IA상 크게 구분되는 기능(채팅/검색)이 있다면 화면 설계서를 여러 개로 분할하여 가독성을 올립니다.

화면 이름(스크린 아이디) 짓기

이제 소중하게 만든 앱 화면에 이름을 붙여줘야 합니다. 그 이름을 스크린 아이디라고 합니다. 스크린 아이디를 쓸 때는 다음 2가지 원칙을 지킵니다. 첫째로 유일해야 합니다. 하나의 화면은 반드시 하나의 아이디를 가집니다. 비슷한 화면이라고 같은 이름을 쓰면 네버 에버 안됩니다. 가끔 한 화면에 기능이 엄청나게 많은 경우 화면 설계서가 여러 장 나올 수도 있습니다. 이때도 여러 장의 화면에 같은 스크린 아이디를 씁니다.

둘째로 규칙적이어야 합니다. 예쁜 이름을 짓는 것이 아닙니다. 실용적인 이름을 짓는 겁니다. 앱 화면은 설계 도중에도 계-속 추가됩니다. 아이디가 규칙적이어야 나중에 화면이 추가되어도 손쉽게 끼워 넣을 수 있습니다. 그래서 보통 스크린 아이디는 주기능-보조기능-001-(001) 형태로 적습니다. 완성한 스크린 아이디는 앞으로 진행될 모든 개발의 중심이 됩니다. 학교에서 온갖 학사관리를 학번 중심으로 하는 것과 같습니다.

주요기능(홍철)이 담긴 이름이여야 합니다(...)

스크린 아이디가 중요한 이유는 앱 개발이 다양한 분야의 전문가가 함께하는 작업이기 때문입니다. 스크린 아이디가 뒤죽박죽 섞이거나, 자기 마음대로 규칙 없이 작성되거나, 개발 도중 살그머니 귀여운 애칭 등으로 바뀌게 되면 상상치도 못했던 오류가 발생합니다. 한 명의 실수가 여러 사람에게 막대한 헛수고를 선물합니다.(탄식)

예를 들어 개발자는 001 화면의 코드를 쓰는데 디자이너는 002 화면의 이미지를 만들어주면 로그인을 눌렀는데 로그아웃이 될 수도 있습니다. 더 큰 문제는 나중에 누가 잘못한 건지 찾기도 어렵다는 겁니다. 비유하자면 병원에서 아기가 바뀌는 것과 비슷한 셈입니다. (이럴 때는 무조건 화면 설계서를 관리하는 기획자 잘못입니다) 그러므로 스크린 아이디는 처음에 잘 정해야 하고 나중에 바꾸게 되면 나 혼자 바꾸는 것이 아니라 모든 사람에게 '나 이거 바꾼다!!'알리고 함께 바꿔야 합니다.

지금부터 스크린 아이디를 002로 바꾸겠소

현실적으로 기획자가 처음 화면 설계서 문서를 만들 때부터 스크린 아이디를 모두 적을 수는 없습니다. 심지어 앱을 다 만든 뒤에도 화면이 추가되는 경우가 있기 때문입니다. 그래서 일단은 앞서 그렸던 화면을 설계서에 최대한 붙여 넣습니다. '질린다 정말! 이 정도면 충분하지 않아!'같은 권태기 연인의 감정이 들 때까지 합니다. 그리고는 스크린 아이디를 규칙적으로, 그리고 꼼꼼히 작성합니다. 경험상 처음에 아무리 화면을 열심히 넣더라도 완성본과 비교하면 60% 수준이었던 것 같습니다.

화면 경로(스크린 패스) 쓰기

다음은 패스입니다. 쉽게 말하면 '내가 지금 보고 있는 화면까지 가기 위한 경로'입니다. 브런치로 예를 들어보겠습니다. 브런치에 '작가 프로필 수정'이라는 화면으로 진입하는 패스는 다음과 같습니다. [홈->메뉴바->설정->작가 프로필 수정]이나 [홈->메뉴바->작가(프로필)->작가 프로필 수정]입니다. 이렇게 패스를 지정하면 해당화면이 이전에 어느 화면에서부터 출발했는지 알 수 있습니다.

앱을 만들다 보면 화면을 수정하거나 추가, 혹은 삭제하는 경우가 생각보다 빈번하게 발생합니다. 서버 구조부터 시작해서 고객 불만까지 별의별 일이 다 있기 때문입니다. 앞서 말했던 스크린 아이디는 수정이 쉽습니다. 화면이 바뀌면 기획자가 그 자리에서 고치면 됩니다. 하지만 스크린 패스는 수정에 주의를 기울여야 합니다. 여러 화면이 고리처럼 물려있는 경우가 많습니다.

변경 화면에 물려있는 화면을 모두 검토하지 않으면 화면에 잘못된 패스가 남게 됩니다. 잘못된 패스는 앞서 말했던 것처럼 앱에 오류를 발생시키거나, 사용자를 막다른 길(다른 화면으로 이동할 수 없는 화면)로 몰아넣습니다. 따라서 스크린 자체를 추가, 삭제하는 경우 단순히 그 스크린뿐만 아니라 화면 설계서 스크린 패스를 꼼꼼히 확인해야 합니다.

컴포넌트(디스크립션) 붙이기

이제 화면에 들어갈 인포메이션 리스트를 작성합니다. 앱 기획, 개발은 기본적으로 레고 혹은 마인크래프트와 똑같습니다. 레고에서 성이나 배를 만들기 위해선 설명서에서 말하는 재료가 있어야 합니다. 앱도 마찬가지입니다. 화면을 만들기 위해서는 화면에 들어갈 구성물을 확실하게 준비합니다. 예를 들어 아무리 잘 만든 쇼핑 앱일지라도 결제 버튼이 없으면 무용지물인 것과 같습니다.

마인크래프트와 동일한 방식입니다

이제 실제로 컴포넌트 리스트를 만드는 방법을 알아보겠습니다. 우선 아까 그린 화면 프로토타입을 설계서 좌측 중앙에 붙입니다. 이제 좌 상단에서 우 하단까지 따로 떼어낼 수 있는 항목에는 전부 번호(알파벳)를 붙입니다. 컴포넌트를 최대한 자세하게 식별하는 것이 중요합니다. 저희 팀은 이걸 인형 눈깔 붙이기라고 표현했었는데 1.뭐하나 붙들고, 2.뚫어지게 쳐다보면서, 3.끝도없이 한다는 점에서 아주 비슷합니다.

컴포넌트를 뽑을 때는 이제 화면 설계서를 자주 볼 개발자나 디자이너에게 연애편지를 쓴다는 마음으로 작성해야 합니다. 왜냐하면 이 인형 눈 작업이 실제로 해보면 매-우 귀찮기 때문입니다. 하지만 내가 정성을 들인 만큼 이 문서를 읽는 사람은 편해집니다. 저는 이걸 '고통 총량 보존의 법칙'이라고 불렀습니다. 기획 문서 중간에 빠진 항목이 생기면 개발자나 디자이너가 여기저기 찾아다니며 기획 의도를 물어야 합니다. 이런 고통이 다 낭비입니다. 따라서 컴포넌트 작성은 로맨스 비슷한 박애정신이 많이 요구되는 작업이라 하겠습니다.

컴포넌트 리스트 작성할 때

컴포넌트는 크게 두 가지로 나뉩니다. 하나는 인포메이션이고 다른 하나는 컨트롤입니다. 둘을 분류하지 않고 그냥 컴포넌트 혹은 디스크립션이라고 부르는 경우도 많습니다. 하지만 앱이 크고 복잡해지면 둘을 분류하는 편이 가독성이 높습니다. 보통 관리자용 앱처럼 작은 단위는 디스크립션만 구구절절 달고 기능이 복잡한 사용자 앱의 경우 컴포넌트를 세밀하게 분류합니다.

인포메이션과 컨트롤을 분류하는 기준은 해당 컴포넌트를 눌렀을 때 앱에서 반응이 일어나는지 유무입니다. 별달리 반응이 없으면 인포메이션이고 그게 아니라 앱이 반응하는 버튼이라면 컨트롤입니다. 맨 처음부터 이 둘을 엄격하게 구분 지을 필요는 없습니다. 처음 설계서를 쓸 때는 둘을 구별하는 것보다 컴포넌트를 빠트리지 않는 것이 가장 중요하기 때문입니다. 하지만 어느 정도 얼개가 나왔다면 둘을 차근차근 나눠놓습니다.

브런치 작가 소개 페이지 예시 화면

이때 위의 예시 화면처럼 인포메이션은 설계서의 우측 상단에, 컨트롤은 우측 하단에 적습니다. 일반적으로 주요 페이지(정보구조에서 뎁스가 낮은 경우)는 컨트롤이 많고 상세페이지(정보구조에서 뎁스가 높은 경우)는 인포메이션이 많습니다.

브런치 앱으로 예를 들어서 설명해보겠습니다. 다음 화면은 브런치의 작가 소개 페이지의 글 탭을 분석한 컴포넌트 리스트입니다. 해당 페이지는 약 20개 정도의 컴포넌트로 구성되어있습니다. [메뉴바], [프로필 설정], [프로필], [작가명], [직업명], [구독자/수], [관심작가/수], [제안하기], [글쓰기], [작가소개], [글/수], [작품/수], [매거진명], [제목], [부제], [내용 전반부], [공유/수], [댓글/수], [날짜], [썸네일]가 그것입니다.

작가 소개 페이지의 헤더

우선 위 화면처럼 컴포넌트들에 숫자(인포메이션)와 알파벳(컨트롤)을 붙입니다. 전체 화면이 너무 복잡해서 우선 프로필이 보이는 헤더에만 적용해보았습니다. 지금은 앱의 실제 화면에 컴포넌트 번호를 붙였습니다. 하지만 와이어프레임은 말 그대로 기본 도형과 선으로만 만들기 때문에 이 예시보다 허접해 보이는 게 당연합니다.

인포메이션은 인덱스, 상세, 타입, 표시조건이 나옵니다

이제 인포메이션을 작성합니다. 인덱스, 상세 사항, 데이터 타입, 표시 조건 순으로 적습니다. 보면 아시겠지만 인포메이션은 화면에 '표시'되는 정보입니다. 예를 들어 '구독자' 영역의 경우, [구독자 수]는 정보를 알려주는 단순 인포메이션입니다. 하지만 [구독자+구독자수] 묶음은 버튼 클릭 시 구독자 리스트를 보여줍니다. 따라서 컨트롤입니다.

컨트롤은 좀 더 꼼꼼히 씁니다

컨트롤도 동일하게 작성합니다. 다만 컨트롤의 경우 상세(디스크립션)을 훨씬 자세히 써주셔야 합니다. 아무래도 단순 정보보다는 버튼의 설명이 복잡합니다. 구구절절 쓴다는 느낌이 아니라 핵심을 요약해준다는 생각으로 작성합니다.

잘 작성된 컴포넌트 리스트는 개발자나 디자이너의 의미 없는 노가다를 줄여줍니다. 개발자는 인포메이션을 보고 해당 화면이 서버로부터 어떤 정보를 받아와야 하는지 압니다. 또한 컨트롤 리스트를 통해 화면을 연결합니다. 디자이너도 마찬가집니다. 디자이너는 공통으로 사용하는 디자인을 우선적으로 만들고 세부적인 디자인을 추가하는 식으로 작업할 수 있습니다. 이처럼 기획자는 두 집단이 일하는 방식을 생각하면서 컴포넌트를 적어야 합니다.

시나리오 만들기

다음은 시나리오입니다. 시나리오란 ‘사용자가 앱에 들어와서 정해진 행동을 하기 위해 필요한 절차’를 말합니다. 쉽게 말해 롤러코스터 타이쿤에서 놀이공원을 다 짓고 나면 이용객 입장에서 놀이기구를 어떻게 이용할지 스토리를 작성해보는 것입니다. 예를 들어 숙박 앱 화면을 다 설계하고 나면 ‘실제로 고객이 화면1, 화면2, 화면3을 거쳐 호텔을 예약합니다.’ 라고 시나리오를 만들 수 있습니다. 다시 말해 ‘사용자 행동을 화면으로 정리하는 것’이 시나리오입니다.

사용자가 장바구니를 지나 배송지 입력 후 결제하는 과정

세상에는 정말 다양한 사람이 있습니다. 그러다 보니 실제 앱을 만들면 ‘아니 대체 어떤 인간이 이 기능을 이따구로 쓰나’ 싶은 애석한(어처구니 없는) 경우도 자주 발생합니다. 하지만 시나리오 문서에서 이런 특이 케이스까지 전부 작성하는 것은 불가능합니다. 따라서 우리가 화면 설계서에 첨부하는 주요 시나리오는 정말 일반적이고 정상적인 사용 패턴으로 한정됩니다. 아웃라이어(드문 경우)의 신박한 사용 패턴은 후일 테스트 케이스 문서에서 잡아냅니다.

모든 화면 설계서에 시나리오가 첨부되는 것은 아닙니다. 대부분의 경우 시나리오가 없더라도 개발자나 디자이너가 화면을 만드는데 전혀 지장이 없습니다. 하지만 시나리오가 꼭 필요한 경우가 있습니다. 이때는 개발자와 디자이너의 분노 관리를 위해 시나리오를 꼼꼼히 써줘야 합니다. 대표적인 예는 ‘일련의 절차를 거쳐’ 기능을 사용하는 경우입니다. 회원가입, 회원정보 찾기, 생체인증 등의 상황이 있습니다.

브런치의 카카오계정 가입 절차

그렇다면 생체인증을 예시로 시나리오를 한번 작성해보겠습니다. 우선 진입하는 사용자의 케이스를 나눠야 합니다. 생체인증을 사용하기 위해서는 우선 사용자가 생체인증을 등록했는지 확인해야 합니다. 따라서 가장 먼저 앱(클라이언트)이 서버에 사용자가 ‘생체인증을 등록한 사람’인지 아니면 ‘생체인증을 등록하지 않은 사람’인지 체크합니다. 서버를 통해 사용자의 생체인증 등록 여부를 확인하면 이제 사용자에게 맞춤형 화면을 노출합니다.

예를 들어 생체 인증 미등록 사용자는 다음 절차를 따릅니다. 1. 생체인증을 등록할 것인지 물어보고, 2. 생체인증 등록을 위해 휴대폰 본인 확인 절차를 거쳐야 하며, 3. 본인 인증이 된 상태에서 자신의 생체 정보를 등록하고, 4. 해당 생체정보를 이용해 인증합니다. 반면 이미 생체정보를 등록한 사용자라면 1,2,3단계를 건너뛰고 바로 4번 화면을 노출합니다.

생체인증을 등록하고 사용하기만 하면 모든 시나리오가 끝난 것 같습니다. 하지만 4번 항목 이후에도 상당히 많은 케이스가 있습니다. 예를 들어 생체인증이 불가능한 경우입니다. 가장 흔한 예는 지문인증을 등록했는데 손가락에 물이 묻어서 인증이 안 되는 경우가 있습니다. 또 극단적인 경우를 들자면 성형수술로 인해 얼굴 인증이 실패하는(…) 사례도 있습니다. 뭐 이런 거까지 생각하나 싶지만 이런 걸 생각하는 앱과 생각하지 않는 앱은 완성도에서 정말 큰 차이가 납니다

전체 파일은 이런 시나리오가 6개 나옵니다

잘 짜인 앱 시나리오는 이런 특이한 상황에서 사용자가 앱을 끄지 않고 재빨리 다른 행동을 할 수 있게끔 유도합니다. 예를 들어 인증이 3회 연속 실패할 경우 휴대폰 인증으로 자동 전환한다, 혹은 생체인증 정보를 재등록한다 등 대안을 제시합니다. 물론 대부분의 사용자는 앱에 이런 과정이 있다는 것을 인식하지 못합니다. 잘 만든 앱은 이 과정이 너무 스-무스해서 내가 그런 행동을 했는지도 모르기 때문이고, 못 만든 앱의 경우 사용자가 굳이 앱에 더 머무르지 않고 강제 종료해버리기 때문입니다. 우리가 유독 은행 앱과 관공서 앱, 결제 앱에 빡친다고 느끼는 것은 이 앱들이 보통 그냥 꺼버릴 수가 없는 이유로 사용되기 때문입니다. (다행히 최근 은행 앱은 상당히 좋아졌습니다)

이처럼 시나리오를 작성하는 것은 단순히 앱 화면에 컴포넌트(인포/컨트롤)로는 설명할 수 없는 복잡한 내용을 개발자나 디자이너에게 알기 쉽게 전달하는데 목적이 있습니다. 따라서 시나리오를 작성할 때 주의해야 하는 점은 모든 케이스를 꼼꼼히 다루는 것도 있겠지만 기본적으로는 읽을 사람이 쉽게 이해할 수 있도록 만들어야 합니다.

버전 관리하기

버전 관리는 보통 표지 다음장에서 관리합니다. 사소하고 귀찮은 일이지만 가장 중요한 일이기도 합니다. 이 페이지에는 [버전, 일자, 상세, 작성자, 비고] 순으로 적습니다. 우선 버전 같은 경우는 1.0, 1.1, 2.0 식으로 적습니다. 컴포넌트나 화면에서 소규모 변동이 있을 경우에는 소수점 버전업을 하고 앱 구조 등 대대적인 개편이 있을 때 앞자리 버전 업을 합니다. 판단은 기획자가 적절히(?) 하시면 됩니다. 저 같은 경우에는 앱 하나를 만들면 3달 동안 보통 버전 5~7까지 업데이트했던 것 같습니다.

버전관리 예시화면

일자나 작성자는 그냥 있는 대로 쓰시면 됩니다. 다만 상세를 적을 때는 주의할 점이 있습니다. 한 페이지짜리 상세에 모든 수정사항을 구구절절 적을 수는 없습니다. 그렇지만 주된 변경 사항은 반드시 기록해야 합니다. 예를 들어 상세에 가끔 ‘컴포넌트 항목 수정’ 이런(or 이딴)식으로 적는 경우가 있는데 이는 매우 잘못된 방식입니다. 저런 수정은 오히려 안 적느니만 못합니다. 버전 관리자는 ‘컴포넌트의 어디를 어떻게 수정한 것'인지 알려줘야 합니다. 예를 들어 ‘로그인 시나리오 5단계 -> 7단계 확장’ 이렇게만 요약해주어도 충분합니다. 변경한 ‘곳’이 아니라 변경한 ‘것’을 적습니다.

버전 관리는 무척 쉬운 일 같지만 생각보다 어렵습니다. 프로젝트 초기에는 화면 설계서를 기획자만 자주 봅니다. 그래서 버전 관리가 어렵다는 것을 당최 이해하지 못합니다. 하지만 본격적으로 코딩과 디자인이 시작되고 중간중간 오류를 수정하다 보면 버전이 섞이기 시작합니다. 기획자는 소스트리같은 협업 툴을 통해 문서 변경을 계속 확인해야 합니다. 더불어 문서를 변경할 필요가 있다면 누가 왜 변경하고자 하며 언제 변경했는지까지 파악해두어야 합니다. 빈틈없는 성격이 필요하다 하겠습니다.

공통요구사항 적기

공통요구사항에는 당연하지만 당연하지 않은 것을 적습니다. 이 역설적인 문장을 설명하기 위한 예를 들어보겠습니다. 우리는 화면을 아래에서 위로 올릴 때 엄지를 화면에 대고 아래에서 위로 끌어올립니다. 이런 행동을 스크롤 업이라고 합니다. 이렇게 당연한 기능의 제스처를 공통 요구사항에서 정의합니다. 제스처 외에도 팝업이나 키보드 설정 혹은 공유처럼 여러 화면에 동시에 등장하는 기능은 공통 요구사항에서 통일합니다.

스와이프 방식 등 설명

디자인 면에서도 공통 요구사항을 적습니다. 이때는 버튼 위치나 화면 구성 원칙들을 나열합니다. 예를 들어 뒤로가기(종료) 버튼은 윈도우 PC의 경우 창의 우측 상단에 있지만 Mac이나 iOS는 좌측 상단에 있습니다. 따라서 'iOS 앱의 뒤로가기 버튼은 좌측 상단에 고정하라'는 공통요구사항에 적을 수 있습니다. 그 외에도 버튼 디자인을 다양하게 구분하여 위계질서를 보여주는 것도 디자인 공통 요구사항에서 정의할 수 있는 요소입니다.

구구절절 길게 적었습니다만 세상만사가 그렇듯 화면 설계서도 실제로 그려보며 배우는 것이 가장 빠릅니다. 다 만들어진 화면 설계서를 보면 ‘와 이걸 어떻게 해’ 싶습니다. 하지만 일주일만 주면 누구나 할 수 있는 것이 이 작업이기도 합니다. 당장 ‘앱 설계학과’나 ‘앱 설계 자격증’같은 것도 없습니다. 누구나 본인이 원하는 서비스를 기획하고 사람들에게 전달할 수 있다는 뜻입니다.

하지만 이 일을 잘하는 것은 완전히 다른 문제입니다. 똑같은 컨셉의 서비스를 만들어도 어떤 앱은 자체 홍보가 필요 없을 정도로 팬층이 생기고 어떤 앱은 제작자를 비꼬는 별점 테러가 횡행합니다. 기획자는 항상 내가 조금 더 조사하고, 조금 더 고생하여 함께 일하는 동료, 그리고 수많은 고객에게 개비스콘을 선사한다는 사명감으로 일합니다. 잘 만든 서비스를 사용자가 좋아하면 그것만큼 뿌듯한 일도 없기 때문입니다.