검사 통과가 완성이 아니다

화면을 네 단계까지 만들면서 매 단계마다 검증을 돌렸다.

타입 체크      통과
린트           통과
포맷           통과
스모크 테스트  통과

lint 도 포맷도 스모크 테스트도 전부 통과라 완료로 보고했는데 실제 화면을 열어 본 사람에게 강한 지적을 받았다. 경쟁사 UX 를 분석해 놓고 겨우 이런 인터페이스냐는 것이었다.

Open Table of contents

검사가 못 잡는 것

지적을 받고 실제 화면을 열어 보니 빠진 것이 이랬다.

다크모드 토글 누락
채팅 패널 미반영
모바일 네비게이션 접근 수단 누락

전부 재작업이었고 배치도 화면 정의서와 달랐다.

그런데 그중 어느 것도 돌리던 검사에는 걸리지 않았다.

타입 체크  →  타입이 맞나
린트       →  코드 스타일이 맞나
스모크     →  주요 경로가 동작하나

토글이 없어도 타입은 맞고 패널이 없어도 스모크는 지나간다. 「보이는 것이 맞나」를 보는 검사가 하나도 없었다.

그중에서도 아예 빠져 있던 항목이 가장 큰 문제로 남았다. 잘못 만든 것은 검사에 걸릴 수 있지만 아예 안 만든 것은 내가 만든 것을 훑는 검사로는 걸릴 방법이 없다.

스모크 테스트도 내가 만든 것을 보고 쓴 시험 케이스 안에서만 도는 것이라서 안 만든 것은 애초에 목록에 없다. 시험 케이스가 내가 아는 범위를 넘지 못한다는 것이 이 방식의 구조적인 한계였다. 시험 케이스를 아무리 늘려도 그 한계 자체는 그대로 남아 있었다.

정리하면 형식 검사 통과는 완료의 필요조건이지 충분조건이 아니어서 통과하지 못하면 확실히 미완이지만 통과했다고 완성인 것은 아니었다.

이 둘을 구분하지 않고 검사 통과를 완료로 보고한 것이 지적의 요지였다. 완료를 판정하려면 무엇과 대조할 것인지가 먼저 있어야 한다. 형식 검사는 대조할 상대가 아니라 최소 기준일 뿐이었다.

더 문제인 것은 첫 단계에서 화면을 안 열어 본 채로 네 단계까지 쌓았다는 점이었다. 첫 단계에서 생긴 오해 위에 세 단계를 더 얹어 놓은 상태였다.

검증 방식이 틀리면 그 위에 쌓은 것이 전부 흔들린다. 첫 단계에서 한 번만 열어 봤으면 그 자리에서 끝났을 일이었다. 초기에 잡는 것과 나중에 잡는 것의 비용 차이가 그만큼 컸다.

이 프로젝트에는 기준이 될 자료가 둘 있었다.

경쟁사 UX 리서치 노트
확정 디자인 시스템 문서

그 UX 노트와 디자인 시스템 문서로 만들라고 준 것인데 내가 검증한 것은 그 기준이 아니었다. 코드가 문법에 맞고 동작하는지를 봤을 뿐이고 화면 정의서가 말하는 「이렇게 보여야 한다」는 다른 차원이었다.

형식 검사를 통과했다는 것으로 그 기준을 대신할 수는 없는 일이었다. 그래서 단계마다 실제 화면과 화면 정의서를 나란히 놓고 대조하는 절차를 넣었다. 기준이 이미 있는데 다른 것으로 대신하려 한 것이 이 일의 시작이었다.