목업은 약속이고, 런타임 스크린샷은 증거다

“비슷해 보여요”라는 말로는 화면을 닫을 수 없었습니다.

처음엔 저도 그 말을 자주 썼습니다.
목업을 보고 구현했고, 코드 리뷰에서 대충 맞아 보였고, 테스트도 통과했습니다.
그러면 완료라고 생각했습니다.

근데 실제 화면을 옆에 놓고 보니 달랐습니다.
간격이 달랐고, 폰트가 달랐고, 어떤 상태는 아예 캡처되지 않았습니다.

가장 무서웠던 건 1px 차이가 아니었습니다.

거짓 PASS였습니다.

증거에는 층이 있었습니다

디자인 작업을 하면서 뒤늦게 배운 게 있습니다.
모든 증거가 같은 주장을 닫지 않습니다.

목업은 “이렇게 만들자”는 약속입니다.

프로토타입 캡처는 “프로토타입은 이렇게 보인다”는 증거입니다.

프로덕션 라우트 스크린샷은 “실제 앱에서 이렇게 보인다”는 증거입니다.

실기기 캡처는 “이 기기에서도 이렇게 보인다”는 증거입니다.

이걸 섞으면 문제가 생깁니다.
프로토타입이 맞다고 해서 실제 앱이 맞는 건 아닙니다.
시뮬레이터에서 괜찮다고 해서 물리 기기에서도 괜찮은 건 아닙니다.

처음엔 이 구분이 과하다고 생각했습니다.
빨리 만들려면 어느 정도는 넘어가야 하지 않나 싶었습니다.

근데 낮은 증거로 높은 주장을 닫으면 결국 다시 엽니다.

All tests skipped도 exit 0이었습니다

한 번은 테스트 명령이 성공했습니다.
exit 0이었습니다.
그런데 캡처 폴더를 보니 새 이미지가 없었습니다.

알고 보니 테스트가 스킵됐습니다.

명령은 성공했지만 산출물은 없었습니다.
그날 이후로 화면 검증은 명령 결과만 보지 않습니다.
파일도 봅니다.

PNG 개수
mtime
SHA
manifest 단계 수
빈 이미지 여부

이 정도는 봐야 합니다.

특히 Flutter 캡처에서는 작은 함정이 많았습니다.
상대 경로를 쓰면 예상한 폴더가 아니라 테스트 파일 기준 경로에 저장될 수 있습니다.
폰트를 미리 로드하지 않으면 아이콘이나 글자가 빈 네모로 나올 수 있습니다.
시뮬레이터 컨테이너 안 파일은 테스트 종료 후 사라질 수 있습니다.

테스트 GREEN만으로는 부족했습니다.

비교자는 두 이미지를 실제로 봐야 합니다

패리티 검증자에게도 계약이 필요했습니다.

“비슷합니다”는 금지했습니다.
대신 두 이미지를 실제로 읽고, 구체 차이 세 개를 말하게 했습니다.

예를 들면 이런 식입니다.

1. 카드 상단 여백이 참조보다 8px 넓음
2. 보조 텍스트 대비가 낮음
3. 빈 상태 아이콘 위치가 중앙보다 위로 치우침

이렇게 나오면 수정할 수 있습니다.
“전체적으로 괜찮음”은 고칠 수 없습니다.

사람 리뷰도 비슷합니다.
기분 좋은 PASS보다, 고칠 수 있는 차이가 더 값집니다.

지금 쓰는 증거 사다리

저는 이제 화면 작업을 닫을 때 이렇게 씁니다.

주장	필요한 증거
목업 방향이 괜찮다	목업 이미지
프로토타입이 목업을 따른다	side-by-side 캡처
실제 앱 라우트가 맞다	route/account/env/commit/screenshot
실기기에서도 맞다	물리 기기 캡처

하나라도 없으면 PASS가 아니라 HOLD입니다.
HOLD가 실패라는 뜻은 아닙니다.
그 주장까지는 아직 안 봤다는 뜻입니다.

이 구분을 하고 나서 보고가 덜 멋있어졌습니다.
“완료”보다 “프로토타입 PASS, 프로덕션 HOLD” 같은 문장이 늘었습니다.

대신 나중에 덜 부끄러웠습니다.

화면은 말로 닫히지 않습니다.

스크린샷이 있어야 합니다.
그리고 그 스크린샷이 무엇을 증명하는지까지 같이 있어야 합니다.