플로우 차트

기능을 글로만 적으면 조건이 겹치는 순간부터 읽기가 어려워집니다. "초대 링크를 누른 사람에게 계정이 있으면 문서로 보내고, 없으면 가입 화면으로 보내되, 이미 만료된 링크라면 계정 유무와 관계없이 재요청 안내로 보낸다" 정도까지는 버팁니다. 여기에 초대한 사람이 이미 팀을 떠났을 때와 플랜 인원 한도를 넘겼을 때가 더 붙으면, 같은 문장을 세 번 읽어도 어떤 경우에 어디로 가는지가 머리에 그려지지 않습니다.

그래서 명세를 읽는 자리에서는 늘 같은 질문이 나왔습니다. 개발자가 "만료된 링크를 계정 없는 사람이 누르면 가입부터 시키나요, 아니면 바로 막나요" 라고 물으면 문서를 쓴 사람이 그 자리에서 다시 생각하기 시작합니다. 대개 그 경우를 아예 정하지 않았던 것이고, 정하지 않았다는 사실조차 글로는 드러나지 않았습니다. 빠진 칸이 보이지 않는 것이 글의 약점입니다.

플로우 차트는 경우를 나누는 지점을 도형 하나로 세워 이 문제를 풉니다. 갈라지는 자리마다 마름모를 놓고 거기서 나가는 화살표를 그리면, 나가는 길이 하나뿐인 마름모는 그림만 봐도 이상해 보입니다. 정하지 않은 경우가 빈 자리로 드러나는 것이 글과 다른 점입니다.

그림에 들어가는 것은 도형 네 종류와 화살표 하나입니다. 도형마다 뜻이 정해져 있고, 그 약속을 지켜야 다른 팀이 설명 없이 읽습니다.

1. 시작과 끝 — 둥근 모서리 도형으로 그립니다. 하나의 그림에 시작은 하나만 두고, 끝은 여럿이어도 됩니다. 초대 수락 흐름이라면 시작은 링크를 누른 순간 하나이고 끝은 문서 진입·가입 완료·차단 안내 셋입니다.
2. 처리 — 사각형입니다. 갈라지지 않고 그냥 일어나는 일을 적습니다. "초대 메일을 보낸다", "권한을 편집자로 설정한다" 처럼 동사로 끝나는 한 줄이 들어갑니다.
3. 분기 — 마름모입니다. 예와 아니오로 답할 수 있는 질문을 넣습니다. "계정이 있는가" 는 되고 "계정 상태를 확인한다" 는 안 됩니다. 답이 둘로 갈리지 않으면 나가는 화살표에 이름을 붙일 수 없기 때문입니다.
4. 다른 그림으로 연결 — 흐름이 길어져 한 장에 담기지 않을 때 다음 장으로 넘긴다는 표시를 둡니다. 스무 개 넘는 도형이 한 장에 들어가면 읽는 속도가 글보다 느려집니다.

화살표에는 조건을 적습니다. 마름모에서 나가는 두 화살표에 예와 아니오를 각각 붙이고, 조건이 셋 이상이면 갈래마다 값을 적습니다. 여기서 빠지기 쉬운 것이 되돌아오는 화살표입니다. 가입을 마친 사람을 다시 초대 확인 단계로 보내야 하는데 그 선을 안 그리면, 읽는 사람은 가입이 끝나면 흐름도 끝난다고 이해합니다.

그리는 쪽은 대개 그 기능을 맡은 프로덕트 매니저이고, 경로가 화면을 여럿 거치면 디자이너가 함께 손봅니다. 디자이너가 와이어프레임으로 화면 순서를 먼저 잡아 둔 경우에는 그 순서를 그대로 옮기고 갈라지는 지점만 마름모로 세우는 편이 빠릅니다.

읽는 쪽은 셋이고 각자 다른 것을 봅니다. 개발자는 마름모의 개수를 세서 조건문이 몇 개 필요한지를 가늠합니다. 마름모가 일곱 개면 테스트해야 할 경로도 그만큼 늘어난다는 뜻이라 일정 답이 달라집니다. 디자이너는 사각형을 보고 그려야 할 화면이 몇 개인지 셉니다. 품질 보증을 맡은 쪽은 시작에서 끝까지 가는 경로를 하나씩 따라가며 검수 목록을 만들고, 그 목록이 인수 조건과 어긋나면 그 자리에서 되묻습니다.

그림 한 장으로 문서가 끝나지는 않습니다. 플로우 차트는 순서와 갈래만 보여 주므로 각 단계에서 무엇을 어떻게 보여 줄지는 기능 명세와 화면 정의서가 맡습니다. 세 문서를 짝으로 두고, 그림에서 마름모 하나를 고치면 대응하는 조건 문장도 같이 고칩니다. 한쪽만 고치면 두 주 뒤에 어느 쪽이 맞는지 아무도 모르게 됩니다.

"이 케이스 플로우 차트에 없는데요. 만료된 링크로 들어온 사람은 어디로 가나요?"

그림에 빈 자리가 있다는 지적이고, 대개 아직 결정되지 않은 경우를 찾아낸 것입니다.

"분기가 아홉 개라서 이번 스프린트에 다 못 합니다. 앞의 네 개만 먼저 할게요."

마름모 수를 작업량으로 환산해 범위를 자르자는 제안입니다.

"플로우 차트만 그려 놓고 화면 정의서를 안 썼네요. 빈 화면일 때 뭐가 보이죠?"

순서는 정해졌지만 각 단계의 내용이 비어 있다는 말입니다.

페이지덱에서 초대 기능을 다시 손보던 주에 지현이 이 그림을 한 장 그렸습니다. 링크를 누른 뒤 계정 유무로 한 번, 초대가 유효한지로 한 번, 팀 인원 한도로 한 번 갈라져 마름모가 셋이었고 끝은 다섯 개였습니다. 초대한 사람이 이미 퇴사한 경우가 어디로 가는지는 그림을 그리는 도중에 비어 있다는 것이 드러났습니다.

태오는 그 그림을 보고 경로 다섯 개 가운데 둘은 이미 있는 코드로 처리된다고 답했고, 나머지 셋만 새로 만들기로 정리됐습니다. 그림이 없었다면 같은 결론에 닿는 데 회의 두 번이 더 들었을 자리입니다. 그림의 값어치는 정확한 표현이 아니라 빠진 경우를 눈에 보이게 만드는 데 있습니다.

도구와 모양새를 먼저 신경 쓰는 경우가 흔합니다. 그림이니 보기 좋아야 할 것 같고, 잘 그린 그림을 본 적이 있어서 생기는 마음입니다. 실제로 읽는 사람이 보는 것은 갈래가 빠짐없이 그려져 있는지 하나뿐입니다. 색과 정렬에 반나절을 쓰면 그 시간만큼 경우를 따져 보는 시간이 줄어들고, 예쁘지만 마름모 하나가 빠진 그림이 회의에 올라갑니다.

플로우 차트가 명세를 대신한다고 보는 것도 자주 보입니다. 순서와 조건이 다 들어 있으니 이걸로 충분해 보이기 때문입니다. 하지만 그림은 "권한이 없으면 차단 안내로 보낸다" 까지만 말하고 그 안내 화면에 무엇이 적혀 있는지, 버튼이 몇 개인지는 말하지 않습니다. 그림만 넘기면 개발은 시작되지만 화면을 만들 때마다 질문이 하나씩 돌아오고, 검수하는 쪽은 무엇을 기준으로 판정할지 정하지 못합니다.