시각적 회귀 테스트와 단위 테스트는 무엇이 다른가요?

단위 테스트는 코드 로직이 올바른 결과를 내는지 확인하고, 시각적 회귀 테스트는 렌더링된 UI가 기대한 모습인지 확인합니다. CSS 변경으로 화면이 깨져도 로직 단위 테스트는 통과할 수 있습니다.

시각적 회귀 테스트에서 잘못된 차이가 생기는 원인은 무엇인가요?

운영체제별 안티앨리어싱과 글꼴 렌더링, 시각이나 광고 같은 동적 콘텐츠, 애니메이션 타이밍이 실제 회귀가 아닌 픽셀 차이를 만들 수 있습니다.

필수는 아니지만 Playwright나 Puppeteer 같은 브라우저 자동화는 같은 조건의 스크린샷을 반복하기 쉽고 CI에서는 헤드리스 실행을 흔히 사용합니다. 중요한 것은 헤드리스 여부보다 브라우저·운영체제·글꼴·데이터를 고정하는 것입니다.

시각, 사용자 아바타, 광고, 애니메이션처럼 실행마다 바뀌는 영역은 데이터를 고정하거나 마스킹하세요. 대부분의 시각 테스트 도구는 요소 마스킹 또는 제외 영역을 지원합니다.

UI에 영향을 주는 풀 리퀘스트와 변경마다 CI에서 실행하면 배포 전에 차이를 검토할 수 있습니다. 테스트 비용이 크다면 핵심 화면부터 시작해 위험도에 맞춰 범위를 넓히세요.

시각적 회귀 테스트는 변경 전후의 UI 스크린샷을 자동으로 비교해 의도하지 않은 시각적 차이를 찾는 테스트 방식입니다.

캡처, 비교, 검토의 순서로 진행합니다. 먼저 페이지, 컴포넌트, 특정 뷰포트 같은 각 UI 상태의 기준 스크린샷을 만듭니다. 이 이미지가 기대하는 화면 모양을 나타냅니다.

코드가 바뀌면 같은 조건으로 다시 캡처합니다. 테스트 도구는 새 이미지와 기준 이미지를 픽셀 단위 또는 지각 기반 알고리즘으로 비교하고 달라진 영역을 표시합니다.

차이가 있으면 사람이 확인합니다. 새 디자인이나 의도한 색상 변경은 승인해 기준 이미지로 갱신하고, 어긋난 요소나 깨진 레이아웃은 회귀 문제로 보고 수정합니다.

이 흐름을 CI/CD에서 실행하면 프로덕션에 배포하기 전에 시각적 변화를 검토할 수 있습니다. 기준 이미지 갱신을 자동 승인하지 않고 코드 변경과 함께 검토하는 것이 중요합니다.

디자인 시스템 — 공용 컴포넌트 변경이 여러 제품의 화면을 의도하지 않게 바꾸지 않았는지 확인합니다.
브라우저 호환성 테스트 — Chrome/Chromium, Firefox, Safari 또는 WebKit 계열 목표 환경에서 같은 화면을 비교합니다. 특정 브라우저와 정확히 같아야 한다면 에뮬레이션이 아니라 실제 대상 브라우저에서 검증하세요.
반응형 레이아웃 — 여러 뷰포트 너비에서 중단점이 예상과 다르게 동작하는지 찾습니다.
테마 변경 — 다크 모드, 브랜드 색, 글꼴 변경이 다른 UI 영역에 예상하지 않은 영향을 주지 않았는지 확인합니다.
접근성 점검 보조 — 코드 변경 뒤 대비, 포커스 표시, 가독성에 영향을 주는 시각적 변화를 찾을 수 있습니다. 자동 접근성 검사와 키보드·보조 기술 테스트를 대신하지는 않습니다.

주요 방식은 픽셀 단위 비교와 지각 기반 비교입니다.

픽셀 비교는 두 이미지의 같은 위치를 하나씩 대조해 아주 작은 변화도 표시합니다. 정확하지만 안티앨리어싱, 서브픽셀 글꼴 렌더링, 애니메이션 타이밍 차이도 잡아 잡음이 많을 수 있습니다. 허용 임계값을 조금 두어 환경 차이를 줄일 수 있습니다.

지각 기반 비교는 사람이 알아차리기 어려운 작은 색 변화와 서브픽셀 차이를 덜 중요하게 처리합니다. 잘못된 차이를 줄일 수 있지만 매우 미세한 실제 회귀도 놓칠 수 있습니다.

처음에는 낮은 허용값의 픽셀 비교로 시작하고, 테스트가 커져 잡음 때문에 검토가 어려워질 때 지각 기반 비교를 검토할 수 있습니다.

신뢰할 수 있는 테스트에는 고정된 글꼴, 결정적인 테스트 데이터, 마스킹한 동적 영역이 필요합니다. 같은 입력에서도 계속 달라지는 스크린샷이라면 팀은 차이 결과를 믿지 않게 됩니다.

동적 콘텐츠를 고정하지 않습니다. 시각, 실시간 데이터, 무작위 콘텐츠, 광고는 캡처마다 달라집니다. 데이터를 모의 처리하거나 해당 영역을 마스킹하세요.
서로 다른 환경에서 캡처합니다. macOS와 Linux는 글꼴 렌더링과 기본 브라우저 설정이 달라 같은 화면도 다르게 보일 수 있습니다. 같은 컨테이너 또는 고정된 실행 환경을 사용하세요.
허용값을 너무 높게 둡니다. 잡음뿐 아니라 실제 회귀까지 숨길 수 있습니다. 낮은 값으로 시작해 파이프라인에서 관찰한 실제 변동만큼 조절하세요.
기준 이미지를 관리하지 않습니다. UI가 바뀌면 기준도 오래됩니다. 변경 내용을 검토한 뒤 의도한 경우에만 갱신하고 모든 차이를 자동으로 받아들이지 마세요.