CSS 는 한 곳을 고치면 다른 곳이 바뀝니다. 그것이 CSS 의 장점이자 위험입니다. 공통 컴포넌트의 간격을 한 단계 조정했는데, 그 컴포넌트를 쓰는 열두 개 화면 중 두 곳에서 레이아웃이 틀어지는 일이 실제로 자주 일어납니다.
문제는 고친 사람은 고친 화면만 본다는 데 있습니다. 나머지 열한 개는 아무도 열어 보지 않고, 며칠 뒤 방문자가 먼저 발견합니다.
스크린샷 회귀 검사가 실제로 잡는 것
구조는 단순합니다. 기준 시점의 화면을 이미지로 저장해 두고, 변경 후 같은 화면을 다시 찍어 픽셀 단위로 비교합니다. 차이가 임계값을 넘으면 알립니다.
여기서 오해하기 쉬운 것이 있습니다. 이 검사는 “디자인이 좋은가” 를 판정하지 않습니다. 오직 “바뀌었는가” 만 판정합니다. 그래서 잡아 주는 것은 한 종류입니다 — 의도하지 않은 변화입니다. 의도한 변화는 매번 사람이 승인해 새 기준으로 삼아야 하고, 이 승인 절차가 검사 도입의 실제 비용입니다.
그럼에도 값이 큰 이유는, 의도하지 않은 변화가 가장 발견이 늦고 가장 설명하기 어려운 종류의 문제이기 때문입니다. 릴리스 후에 “언제부터 이랬지” 라고 묻게 되는 상황이 대부분 여기서 나옵니다.
지킬 화면을 고르는 일이 절반입니다
모든 페이지를 찍으면 검사가 느려지고, 무엇보다 차이 보고서가 길어져 아무도 읽지 않게 됩니다. 목록이 길어지는 순간 이 도구는 무력해집니다.
기준은 깨졌을 때의 비용입니다. 매출 경로와 재사용 컴포넌트가 우선이고, 자주 바뀌는 콘텐츠 페이지는 후순위입니다.
특히 유용한 것이 컴포넌트를 모아 놓은 화면을 하나 만들어 그것을 찍는 방법입니다. 버튼 · 카드 · 폼 요소를 모든 상태와 함께 한 페이지에 늘어놓으면, 이미지 한 장으로 디자인 시스템 전체의 회귀를 감시할 수 있습니다.
거짓 경보를 줄이는 것이 나머지 절반입니다
도입에 실패하는 이유는 거의 언제나 같습니다. 매번 차이가 나서 아무도 보지 않게 되는 것입니다. 차이의 원인이 대체로 정해져 있으므로 미리 막을 수 있습니다.
폰트가 가장 흔한 원인입니다. 캡처 시점에 웹폰트가 아직 도착하지 않으면 폴백 글꼴로 그려져 글자 폭이 전부 달라지고, 화면 전체가 차이로 잡힙니다. 폰트 로드 완료를 기다린 뒤 찍는 것만으로 상당수의 거짓 경보가 사라집니다.
애니메이션도 마찬가지입니다. 진입 애니메이션이 도는 중에 찍으면 매번 다른 프레임이 잡힙니다. 캡처하는 동안 모션을 끄는 설정을 켜면 정적 최종 상태가 찍힙니다 — 그리고 이 방법이 통한다는 것 자체가, 그 화면이 모션 없이도 완성된 상태로 만들어져 있다는 증거이기도 합니다.
임계값도 조정합니다. 0에 가깝게 두면 글꼴 렌더링의 미세한 차이까지 잡히고, 너무 크게 두면 실제 붕괴를 놓칩니다. 처음에는 조금 느슨하게 시작해 거짓 경보를 없애 가면서 좁히는 편이 현실적입니다.
이 검사가 대체하지 못하는 것
마지막으로 한계를 분명히 해 둡니다. 스크린샷 비교는 보이는 것만 봅니다. 낭독기가 무엇을 읽는지, 키보드로 순서대로 이동이 되는지, 대비가 기준을 넘는지는 이미지에 나타나지 않습니다.
그래서 이 도구는 접근성 검사나 사람의 리뷰를 대체하지 않고, 그 둘이 이미 통과시킨 상태를 지키는 역할을 합니다. 지켜야 할 기준이 먼저 있고, 그다음이 이 검사입니다.
화면 상태와 규칙을 리뷰에서 확정하는 방법은 개발 워크플로우 아카이브에서 다루고, 이미지에 나타나지 않는 항목들은 접근성 연재에 정리돼 있습니다. 우리가 실제 작업에서 어떤 순서로 검증하는지는 작업 과정에 공개돼 있습니다.