스토리보드(화면 설계서): 화면이 아니라 상태와 분기를 적는 문서

화면 설계서를 받아 보면 대부분 정상 흐름만 그려져 있습니다. 로그인 화면, 목록 화면, 상세 화면, 결제 완료 화면. 그림은 깔끔하고 흐름도 자연스럽습니다.

그런데 개발을 시작하면 이 문서에 없는 질문이 쏟아집니다. 목록이 0건이면 무엇을 보여 주는가. 결제가 중간에 끊기면 어디로 돌아가는가. 권한이 없는 사람이 이 링크를 열면 어떻게 되는가. 화면은 네 개인데 실제로 만들어야 하는 상태는 그보다 훨씬 많습니다.

화면이 아니라 분기를 적는 문서

스토리보드를 화면 그림으로 이해하면 이 간극이 계속 생깁니다. 화면은 눈에 보이는 결과일 뿐이고, 설계서가 실제로 담아야 하는 것은 어떤 조건에서 무엇이 보이는가입니다.

같은 목록 화면 하나에 최소 네 가지 상태가 있습니다. 데이터를 불러오는 중, 0건, 정상 목록, 불러오기 실패. 여기에 권한에 따라 보이는 항목이 달라지면 경우의 수가 더 늘어납니다. 화면 한 장으로 그리면 하나지만, 만드는 입장에서는 넷 이상입니다.

와이어프레임·프로토타입과 다른 역할

이 문서들이 자주 뒤섞이는데, 각각 답하는 질문이 다릅니다.

문서	답하는 질문	바뀌어도 되는 것
와이어프레임	무엇이 어디에 놓이는가	배치는 나중에 바뀌어도 범위가 안 바뀜
디자인 시안	어떻게 보이는가	색·서체·간격 전부
프로토타입	눌러 보면 어떤 느낌인가	대부분. 버리려고 만드는 것
스토리보드	어떤 조건에서 무엇이 보이는가	바꾸면 범위가 바뀜

앞의 셋은 표현을 다루고 스토리보드만 규칙을 다룹니다. 프로토타입은 특히 성격이 반대입니다. 프로토타입은 빨리 틀리려고 만드는 것이라 버리는 것이 정상이고, 스토리보드는 남겨서 근거로 쓰려고 만드는 것이라 버리면 곤란합니다. 둘을 같은 산출물로 묶어 일정에 넣으면 한쪽이 반드시 부실해집니다.

171개 프로젝트에서 확인되지 않은 「지연 효과」

여기서 흔히 따라붙는 말이 있습니다. 설계 단계에서 놓친 것을 나중에 고치면 몇 배 더 비싸다는 주장입니다. 배리 보엠이 1981년에 낸 결함 수정 비용 곡선이 출처로 자주 인용되고, 단계마다 10배씩 늘어난다는 표가 널리 돌아다닙니다.

저는 이 숫자를 근거로 쓰지 않는 편이 낫다고 봅니다. 검증이 약하기 때문입니다.

팀 멘지스 등이 2006년부터 2014년 사이 전 세계 171개 소프트웨어 프로젝트를 대상으로 이 효과를 검증했습니다. 저자들이 이 주제로 발표된 가장 큰 규모의 연구라고 밝힌 작업입니다. 결과는 이렇습니다.

우리는 지연 이슈 효과에 대한 증거를 찾지 못했다. 즉 나중 단계에서 이슈를 해결하는 데 드는 노력이, 이슈가 발생한 직후에 해결할 때보다 일관되게 또는 실질적으로 더 크지는 않았다. (Menzies et al., 2017)

연구는 이 효과가 모든 프로젝트에 적용되는 상수가 아니라 특정 종류의 프로젝트에서 간헐적으로 나타나는 역사적 잔재일 수 있다고 덧붙입니다. 보엠 본인도 2001년에 소규모 비핵심 시스템의 경우 비율이 100대 1보다는 5대 1에 가깝다고 조정한 바 있습니다.

그래도 분기를 미리 적어야 하는 진짜 이유

그러면 스토리보드에 예외를 적을 이유가 사라지는가. 저는 이유가 바뀔 뿐 사라지지는 않는다고 봅니다. 외주에서 화면 설계서가 중요한 이유는 기술적 비용이 아니라 계약 범위이기 때문입니다.

설계서에 적힌 것은 하기로 한 일이고, 안 적힌 것은 정해지지 않은 일입니다. 결제 실패 화면이 설계서에 없으면 그것을 만드는 일이 범위 안인지 밖인지 문서가 말해 주지 않습니다. 개발 중에 그 화면이 필요해졌을 때 벌어지는 것은 기술 문제가 아니라 협상입니다.

비용이 늘어나는 것도 사실이지만, 늘어나는 이유가 "고치기 어려워서"가 아니라 "누가 부담할지 정해지지 않아서"인 경우가 훨씬 많습니다. 앞의 연구가 뒤집은 것은 앞쪽 설명이고, 뒤쪽 설명은 그대로 남습니다.

정상 흐름만 그린 설계서가 남기는 공백

이 관점에서 보면 설계서의 빈칸은 전부 미결 항목입니다.

화면에 그려진 것	그려지지 않아 남는 질문
목록 화면	0건일 때, 로딩 중일 때, 실패했을 때
로그인 화면	비밀번호 5회 틀렸을 때, 탈퇴한 계정일 때
결제 화면	결제 중 이탈, 중복 결제, 승인 지연
관리자 화면	권한 없는 접근, 동시 수정 충돌

오른쪽 칸이 비어 있으면 그 항목들은 없는 것이 아니라 나중에 협의할 것으로 남습니다. 그리고 협의는 개발이 진행된 뒤에 벌어지므로 그때는 이미 한쪽이 불리합니다.

예외 하나가 늘리는 화면과 API의 개수

예외를 적는 일이 문서 한 줄로 끝나지 않는다는 점도 같이 봐야 합니다. 결제 실패 하나를 처리하려면 실패 화면이 필요하고, 실패 사유를 구분해 보여 주려면 서버가 사유 코드를 내려 줘야 하고, 사용자가 재시도할 수 있게 하려면 직전 상태를 어딘가 남겨 둬야 합니다. 화면 한 장이 늘어나는 것이 아니라 화면·API·데이터가 같이 늘어납니다.

그래서 예외를 전부 적는 것이 항상 옳지는 않습니다. 저라면 기준을 하나 두겠습니다. 그 예외가 발생했을 때 사용자가 돈이나 데이터를 잃는가. 잃는 쪽은 반드시 적고, 잃지 않는 쪽은 기본 동작 한 줄로 묶어 둡니다. 예를 들어 "정의되지 않은 오류는 공통 오류 화면으로 보내고 재시도 버튼을 둔다" 같은 문장 하나가 수십 개의 사소한 분기를 대신합니다.

화면 수로 견적을 낼 때 빠지는 상태

견적 단계에서도 같은 문제가 나타납니다. "화면 20개짜리 프로젝트"라는 표현은 상태를 세지 않습니다. 정상 흐름 20개와 예외를 포함한 20개는 만드는 양이 다른데, 견적서에는 같은 20으로 적힙니다.

이건 맨먼스 견적을 다룬 글에서 본 문제와 뿌리가 같습니다. 세는 단위가 만들어지는 것을 반영하지 못하면 숫자는 정확해 보이지만 비어 있습니다. 화면 수는 맨먼스보다 산출물에 가깝긴 하지만, 상태를 빼고 세면 여전히 겉모습만 셉니다.

스토리보드에 적을 것과 적지 않을 것의 경계

정리하면 스토리보드의 성격은 두 가지입니다. 만들 것을 정하는 설계 문서이면서, 동시에 하기로 한 범위를 적어 둔 계약 문서입니다. 앞의 성격만 보면 예쁘게 그리는 데 시간을 쓰게 되고, 뒤의 성격을 같이 보면 빈칸을 찾는 데 시간을 쓰게 됩니다.

디자인 시안과 스토리보드를 구분하는 기준도 여기서 나옵니다. 색과 간격은 나중에 바꿔도 범위가 안 바뀌지만, 분기는 바꾸는 순간 범위가 바뀝니다. 설계서에서 공을 들일 곳은 전자가 아니라 후자입니다.