상태 다이어그램

동작을 문장으로만 적으면 빠진 조합이 눈에 보이지 않습니다. 조건이 세 개 겹치면 경우의 수는 여덟 개가 되는데, 문장은 그중 실제로 떠올린 것만 적습니다. 적지 않은 경우는 없는 것이 아니라 정하지 않은 것으로 남습니다.

페이지덱 초대 기능에서 그 일이 있었습니다. 기능 명세에 조건과 결과를 짝지어 스무 줄쯤 적었고, 지현이 보기에 빠진 것이 없었습니다. 출시하고 나서 문의가 들어왔습니다. 만료된 초대 링크를 누르면 수락되는 계정이 생겼고, 취소한 초대와 같은 주소로 다시 초대하면 앞의 초대가 되살아났습니다. 초대가 가질 수 있는 상태는 다섯 개였는데 문서는 그중 세 개에서 출발하는 경우만 다루고 있었습니다.

이런 누락은 글을 더 꼼꼼히 읽어도 잡히지 않습니다. 빠진 칸이 문장 사이의 빈자리에 있기 때문입니다. 상태를 점으로 늘어놓고 오갈 수 있는 길을 화살표로 이으면 화살표가 없는 칸이 그림에 그대로 남고, 그 자리를 보고 막을지 열지를 그때 정하게 됩니다.

먼저 대상을 하나로 못 박습니다. 초대 한 건, 문서 한 개, 결제 한 건처럼 상태를 갖는 단위를 정해야 그림이 섭니다.

그다음 채우는 칸은 다섯 개입니다.

1. 상태 목록. 그 대상이 있을 수 있는 모습을 빠짐없이 셉니다. 초대 한 건이면 발송됨·수락됨·거절됨·만료됨·취소됨 다섯입니다. 이름은 서로 겹치지 않게 짓습니다. 대기중과 미처리처럼 뜻이 겹치는 이름이 둘 들어가면 개발과 검수가 서로 다른 것을 가리킵니다.
2. 전이 화살표. 어느 상태에서 어느 상태로 갈 수 있는지를 잇습니다. 방향이 있어서 수락됨에서 발송됨으로는 돌아가지 않습니다.
3. 전이를 일으키는 것. 화살표마다 무엇이 그 이동을 만드는지 적습니다. 셋뿐입니다. 사람의 행동, 시간의 경과, 다른 시스템이 보낸 신호입니다. 발송됨에서 만료됨으로 가는 화살표에는 사람이 없고 7일이 지났다는 조건만 붙습니다.
4. 시작과 끝. 어디에서 시작하는지와 더 나가지 않는 상태가 무엇인지 표시합니다. 수락됨과 거절됨은 끝이고, 만료됨은 재요청으로 다시 발송됨으로 갈 수 있으니 끝이 아닙니다.
5. 같은 행동에 붙는 조건. 한 행동이 상태에 따라 다른 곳으로 가면 화살표에 조건을 적습니다. 초대 링크를 누르는 행동은 발송됨에서는 수락됨으로 가고 만료됨에서는 재요청 안내로 갑니다.

다 그린 뒤에는 상태를 세로로, 행동을 가로로 둔 격자를 만들어 칸을 채워 보는 것입니다. 상태 다섯에 행동 넷이면 칸이 스무 개이고, 화살표가 없는 칸에 무엇을 보여 줄지를 적습니다. 드물게 생기지만 정의는 필요한 엣지 케이스가 대부분 여기서 나옵니다. 그림은 있을 수 있는 길을 보여 주고 격자는 없는 길을 보여 줍니다.

쓰는 사람은 그 기능을 맡은 제품 담당자입니다. 페이지덱에서는 지현이 상태 목록과 화살표를 먼저 그리고, 상태가 화면으로 드러나는 기능이면 민서가 함께 채웁니다. 같은 요소가 상황에 따라 달라지는 모습을 다루는 UI 상태와 이 그림은 층이 다릅니다. 초대가 발송됨 상태라는 사실과 그 줄에 회색 배지가 붙는다는 사실은 따로 적습니다.

읽는 사람은 셋이고 각자 다른 것을 꺼내 갑니다.

1. 태오 — 저장할 상태 값과 허용할 전이를 여기서 가져갑니다. 화살표가 없는 이동은 코드에서 막아야 할 동작이라, 이 그림이 곧 막을 목록입니다.
2. 민서 — 상태마다 화면이 어떻게 보이는지를 셉니다. 상태 다섯이면 그려야 할 모습이 최소 다섯이고, 화면 정의서에 그 다섯을 나눠 적습니다.
3. 검수하는 쪽 — 출시 전 품질을 점검하는 품질 보증 단계에서 화살표가 없는 칸을 일부러 시도합니다. 만료된 링크를 눌러 보고 취소한 주소로 다시 초대해 보는 일이 그것입니다. 인수 조건에 그 시도 결과가 한 줄씩 들어갑니다.

만드는 중에 상태가 하나 늘면 그림도 같이 고칩니다. 낡은 그림은 없는 것보다 나쁩니다. 아무도 의심하지 않고 그대로 만들기 때문입니다.

"상태 다이어그램 먼저 그려 주세요. 만료된 건을 어떻게 할지가 안 적혀 있어요."

상태 사이의 빠진 길을 정하고 오라는 요청입니다.

"이 화살표는 누가 눌러서 생기는 거예요, 시간이 지나서 생기는 거예요?"

전이를 일으키는 것이 사람인지 시간인지 적혀 있지 않다는 지적입니다.

"취소됨에서 발송됨으로 가는 화살표는 없는 게 맞죠? 그럼 그 버튼은 막습니다."

그림에 없는 이동은 구현에서 막겠다는 확인입니다.

페이지덱에서는 상태가 셋을 넘는 기능에만 이 그림을 그립니다. 초대, 결제, 문서 공유 권한이 그 대상이고, 버튼 문구를 바꾸는 일에는 그리지 않습니다. 그리는 데 드는 시간이 만드는 시간보다 길어지면 그 문서는 이미 제 몫을 넘긴 것입니다.

지현이 화이트보드에 점 다섯 개를 찍고 태오와 함께 화살표를 그으면 그 자리에서 빠진 칸이 두세 개 나옵니다. 회의 30분에 문의 열 건이 줄어드는 셈이라, 만드는 쪽이 이 자리를 먼저 요청하기도 합니다.

개발자가 보는 문서라서 제품 담당자는 안 그려도 된다고 여기는 경우가 많습니다. 화살표와 도형이 나오니 기술 문서처럼 보입니다. 하지만 어느 상태에서 어느 상태로 갈 수 있는지는 구현이 아니라 결정입니다. 만료된 초대를 수락할 수 있게 할지는 코드로 정할 일이 아니라 제품이 정할 일이고, 개발이 대신 정하면 그 결정은 문서에 남지 않은 채 코드 안에만 있게 됩니다. 반년 뒤에 왜 이렇게 도는지 물으면 아무도 답하지 못합니다.

상태를 잘게 쪼갤수록 정확해진다고 보는 것도 흔합니다. 불러오는 중과 저장 중까지 점으로 세우면 더 정확해 보이지만, 점이 열다섯을 넘으면 그림이 읽히지 않고 읽히지 않는 그림은 갱신되지 않습니다. 기준은 그 값을 저장해 두어야 하는지입니다. 초대가 만료됐다는 사실은 저장해 두고 나중에 다시 꺼내 보지만, 지금 저장 중이라는 사실은 화면에서만 잠깐 쓰입니다. 앞엣것만 올립니다.