화면정의서는 화면에 무엇이 어떻게 놓이는지를 적는 문서고, 기능정의서는 그 화면이 어떻게 동작하는지를 적는 문서입니다. 둘은 하나가 다른 하나를 대신하는 관계가 아니라 서로를 채워주는 관계입니다. 회사에 따라 화면정의서를 화면설계서라고 부르기도 하는데, 가리키는 건 같습니다.
집 짓는 일에 빗대면 조금 선명해집니다. 화면정의서는 건물이 전체적으로 어떻게 생겼는지 보여주는 조감도에 가깝고, 기능정의서는 층마다 방마다 붙는 도면에 가깝습니다. 개발자는 그 도면을 들고 실제로 벽을 세우는 쪽이고요. 조감도만 받아 든 목수는 결국 되물을 수밖에 없습니다.
회원가입 하나만 놓고 갈라 보면 이렇습니다. 화면정의서에는 이메일과 비밀번호 입력칸이 어떤 순서로 놓이는지, 약관 동의는 어디에 붙는지, 버튼에 뭐라고 쓰는지, 에러 메시지는 어느 자리에 뜨는지, 무언가를 기다리는 동안 화면에 무엇이 보이는지를 적습니다. 화면마다 번호를 매기고 어느 화면에서 어느 화면으로 넘어가는지도 여기서 정합니다.
기능정의서에는 그 칸에 무엇을 넣어야 통과인지를 적습니다. 비밀번호는 몇 자 이상에 어떤 조합이어야 하는지, 이미 가입된 이메일을 넣으면 어떻게 되는지, 인증 메일은 몇 분 동안 유효하고 만료되면 어디로 보내는지, 탈퇴한 사람이 같은 주소로 다시 오면 받아줄 것인지. 화면에는 그려지지 않는 규칙들이 여기 모입니다.
두 가지를 나누지 않고 스토리보드 한 장에 몰아 쓰면, 문서가 설계서가 아니라 사용 설명서에 가까워집니다. 사용자가 이렇게 하면 이렇게 된다는 이야기는 촘촘한데, 그렇게 되지 않는 경우에 무엇을 해야 하는지가 비어 있는 겁니다. 그리고 그 빈칸은 사라지지 않습니다. 개발자에게 넘어가서, 그가 알아서 정하거나 정하기 전에 물어보러 오거나 둘 중 하나가 됩니다.
개발자가 구현을 시작할 때 먼저 펴는 쪽은 대개 기능정의서입니다. 화면은 보면 알지만 규칙은 보이지 않으니까요. 그래서 질문이 터지는 자리도 거의 정해져 있습니다. 하나는 경계에 걸린 값입니다. 비밀번호를 여덟 자 이상으로 정했다면 정확히 여덟 자는 통과인지, 닉네임에 공백만 넣은 사람은 어떻게 할 것인지 같은 것들이요. 다른 하나는 아무도 그리지 않은 예외입니다. 인증 메일을 기다리다 창을 닫아버린 사람이 다시 들어왔을 때 어느 화면으로 보낼 것인지 같은.
물론 현실에서는 문서 하나로 끝내는 팀도 많고, 그게 늘 틀린 것도 아닙니다. 다만 하나로 갈 거라면 규칙을 어디에 적을지는 미리 정해두는 편이 낫습니다. 저도 매번 깔끔하게 나누지는 못합니다.
문서를 아무리 촘촘히 나눠도, 마지막에 남는 건 서로 같은 그림을 떠올리게 만드는 일이었습니다.