스토리북

부품 하나가 제대로 만들어졌는지 보려면 그 부품이 쓰이는 화면을 실제로 열어야 했습니다. 버튼의 비활성 상태를 확인하려면 로그인해서 폼을 찾아 들어가고 비활성이 되는 조건을 손으로 만들어야 했습니다. 서버에 특정 데이터가 있어야 나오는 상태면 그 데이터를 넣는 일까지 붙었습니다. 한 상태를 보는 데 몇 분이 걸린 셈입니다.

그래서 자주 나오는 상태만 확인하고 나머지는 넘어갔습니다. 오류가 난 상태, 글자가 아주 긴 상태, 누른 뒤 결과를 기다리는 상태는 아무도 열어 보지 않았습니다. 이런 상태는 운영에서 처음 드러났습니다. 버튼이 결과를 기다리는 동안 다시 눌려서 문서가 두 번 저장되는 문제가 배포 뒤에 보고되는 식이었습니다.

시안과 코드가 어긋나는 것도 같은 자리에서 생겼습니다. 시안에는 버튼의 평소 모습과 마우스를 얹은 모습 둘만 그려져 있는데 코드에는 여섯 가지 상태가 필요합니다. 나머지 넷은 만드는 사람이 알아서 정하고, 그 결과를 확인하는 자리가 없었습니다. 스토리북은 그 확인을 할 자리를 만들어 준 도구입니다.

부품 하나를 보려고 화면과 데이터를 만들어 내는 준비 작업을 없애 줍니다. 부품과 그 부품에 넘길 값을 한 벌 적어 두면 목록에서 눌러 바로 띄웁니다. 이렇게 적어 둔 한 벌을 스토리라고 부르고, 넘어가는 항목은 다섯입니다.

1. 상태를 미리 적어 둡니다. 버튼이라면 평소, 마우스를 얹은 상태, 눌려 있는 상태, 비활성, 결과를 기다리는 상태, 글자가 아주 긴 상태를 각각 한 줄씩 적습니다. 여섯 개가 목록에 나란히 서면 빠진 상태가 바로 눈에 들어옵니다.
2. 화면과 데이터 없이 띄웁니다. 로그인도 서버도 필요 없습니다. 오류 상태를 보려고 일부러 오류를 만들 필요가 없고, 그 값을 스토리에 적어 두기만 하면 됩니다.
3. 시안과 코드를 대조하는 자리가 됩니다. 재사용할 규칙과 부품을 한 기준으로 묶어 둔 것을 디자인 시스템이라 하는데, 그 규칙이 실제 코드로 옮겨졌는지는 코드를 읽지 않고는 알 수 없었습니다. 스토리북이 그 코드를 눈으로 볼 수 있는 화면으로 바꿔 줍니다.
4. 부품 목록 자체가 문서가 됩니다. 화면을 이루는 부품을 모아 둔 컴포넌트 라이브러리를 훑어볼 수 있게 되니, 새로 들어온 사람이 있는 부품을 못 찾아 같은 것을 또 만드는 일이 줄어듭니다.
5. 자동 검사를 붙일 자리가 생깁니다. 각 상태를 이미지로 찍어 두고 다음 배포와 비교하면 의도하지 않은 모양 변화가 잡힙니다. 장애나 상황에 관계없이 쓸 수 있게 만드는 접근성 점검도 부품 단위로 돌릴 수 있습니다.

대가는 사람이 쓰는 파일이 하나 늘어난다는 점입니다. 부품을 고칠 때 스토리를 함께 고치지 않으면 목록에 낡은 모습이 남고, 그 상태가 몇 달 지나면 아무도 믿지 않는 화면이 됩니다.

대안은 셋이고, 셋 다 확인할 자리를 어디에 두느냐로 갈립니다.

첫째는 앱 안에 개발용 화면을 하나 만드는 것입니다. /dev/components 같은 주소를 두고 거기에 부품을 늘어놓습니다. 도구를 새로 설치하지 않아도 되고 반나절이면 만듭니다. 대신 운영 빌드에서 그 화면을 빼는 처리를 직접 해야 하고, 값을 바꿔 보는 조작판까지는 만들지 않게 되니 결국 대표 상태 몇 개만 늘어놓은 화면이 됩니다.

둘째는 눈으로 보는 자리를 두지 않고 테스트 코드만 두는 것입니다. 부품이 어떤 값으로 어떻게 그려지는지를 코드로 검사합니다. 사람 없이 깨진 것을 잡아 주지만 디자이너가 열어 볼 수 없습니다. 여백이 4픽셀 어긋난 것은 테스트가 통과시키고 사람 눈이 잡습니다.

셋째는 확인을 디자인 도구 쪽에서 하는 것입니다. 시안 파일에 모든 상태를 그려 두고 그것을 기준으로 삼습니다. 한계는 분명합니다. 시안은 코드가 아니라서 실제 결과와 다를 수 있고, 어긋났는지 보려면 사람이 두 화면을 나란히 놓아야 합니다.

부품이 스무 개 아래이고 만드는 사람이 둘인 팀에서는 세 대안 중 첫째로 충분한 경우가 많습니다. 스토리를 유지하는 비용이 얻는 것보다 큰 구간이 있습니다.

"이 상태 스토리가 없어요. 추가해 주세요."

확인할 자리가 빠져 있으니 목록에 채우자는 말입니다.

"스토리북에서는 되는데 실제 화면에서 깨져요."

부품만 떼어 놓고 보는 환경의 한계에 걸렸다는 뜻입니다.

"시안엔 두 상태인데 여기엔 여섯이에요. 시안을 채워야 합니다."

코드가 요구하는 상태 수를 디자인이 못 따라왔다는 지적입니다.

페이지덱은 버튼과 입력 칸을 고칠 때 스토리북을 먼저 봅니다. 태오가 부품을 고치면 민서가 목록을 열어 여섯 상태를 훑고, 시안과 다른 곳을 그 자리에서 적어 둡니다. 예전처럼 화면을 만들어 조건을 맞추던 방식으로는 하루 걸렸습니다.

한 번은 반대 방향으로 쓰인 적도 있습니다. 민서가 글자가 아주 긴 상태를 스토리로 추가해 달라고 했고, 띄워 보니 버튼 안에서 글자가 두 줄로 넘치며 높이가 무너졌습니다. 시안에 없던 경우였으니 스토리를 추가하지 않았으면 배포 뒤에 발견됐을 문제입니다.

스토리북이 테스트를 대신한다고 보는 경우가 가장 많습니다. 여섯 상태를 눈으로 다 봤으니 검증이 끝난 것처럼 느껴집니다. 하지만 여기서 확인하는 것은 부품 하나의 모습이고, 실제 문제는 대개 부품을 이어 붙인 자리에서 생깁니다. 목록 안에 버튼이 스무 개 들어갔을 때의 동작이나 두 부품이 같은 데이터를 다르게 읽는 경우는 이 화면에서 드러나지 않습니다. 눈으로 본 것을 통과로 기록하면 릴리스 뒤에 화면 단위 문제가 밀려 들어옵니다.

개발자만 쓰는 도구라고 보는 시각도 자주 나옵니다. 코드 옆에 파일을 두고 명령으로 띄우는 도구이니 그렇게 보입니다. 실제로는 디자이너가 열어 보지 않으면 값의 절반이 사라집니다. 시안과 코드가 어긋난 것을 잡아내는 일은 시안을 그린 사람이 가장 빠르게 하고, 그 확인을 개발자 혼자 하면 애초에 시안에 없던 상태는 판단 기준 없이 정해집니다. 주소를 팀 모두가 열 수 있게 올려 두고 시안 검토 자리에 함께 띄웁니다.