골든 스냅샷은 누구의 이론인가
“골든 스냅샷은 누구의 이론인가?”라는 질문은 화면 테스트가 실패했을 때 자주 나온다. 기준 이미지가 하나 있고, 현재 화면을 그 이미지와 비교한다. 다르면 CI가 빨간불을 켠다. 이 흐름은 단순해서 누군가 한 번에 발명한 단일 이론처럼 보이지만, 실제 계보는 조금 다르다.
가장 가까운 원조는 Michael Feathers다
현재 동작을 먼저 기록하고, 코드를 바꾼 뒤 그 동작이 달라졌는지를 감시하는 생각은 화면보다 훨씬 오래됐다. Michael Feathers는 2002년 글에서 레거시 코드를 안전하게 바꾸기 위한 test covering을 설명했다. 여기서 테스트의 기준은 외부에서 정한 이상적인 정답이 아니라, 시스템이 어제 실제로 하던 동작이다. 그 기준을 먼저 붙잡은 다음 코드를 바꾸고, 변화가 생기면 의도된 것인지 판단한다. Feathers의 2002년 원문에 이 구조가 남아 있다.
이후 이 방식은 characterization test라는 이름으로 널리 설명됐다. 이 이름을 Feathers가 소개했다는 동시대 설명도 남아 있다. 특성화 테스트는 “코드가 무엇을 해야 하는가”보다 “지금 실제로 무엇을 하는가”를 기록한다. 그래서 이 테스트는 처음부터 정답을 증명하는 장치라기보다, 변경으로 인해 행동이 달라졌다는 사실을 알려주는 안전망이다. Alberto Savoia의 2007년 정리는 Feathers의 용어와 알고리즘을 직접 설명한다.
스냅샷은 그 생각을 다른 출력에 적용한 이름이다
출력이 숫자나 문자열이면 그 값을 저장한다. 출력이 HTML 트리나 화면 이미지면 그 결과를 snapshot 또는 golden master로 저장한다. 핵심은 파일 확장자가 아니라 비교 구조다. 처음 승인한 결과를 기준으로 삼고, 다음 실행의 결과가 달라졌는지 확인한다.
웹 UI 쪽에서 이 방식을 대중화한 중요한 전환점은 Jest다. Jest 팀은 2016년 React 트리 snapshot testing을 공개하면서, 컴포넌트를 렌더링하고 그 결과를 파일로 저장한 뒤 다음 실행과 비교하는 흐름을 설명했다. 당시 기능을 만든 사람으로 Ben Alpert와 Cristian Carlesso를 명시했다. Jest 14 공식 글에 이 기록이 있다.
웹 화면의 PNG 비교는 Playwright가 제공하는 visual comparison으로 구현할 수 있다. Playwright는 첫 실행에서 기준 스크린샷을 만들고, 다음 실행부터 toHaveScreenshot()으로 현재 화면과 비교한다. 브라우저와 실행 환경이 달라지면 글꼴과 렌더링이 달라질 수 있으므로 같은 환경에서 기준 이미지를 만들어야 한다. Playwright 공식 문서가 이 동작과 갱신 명령을 명시한다.
따라서 “골든 스냅샷 이론은 누구 것인가?”에 대한 가장 정확한 답은 이렇다. 뿌리가 되는 변경 안전성 개념을 특성화 테스트로 정리한 사람은 Michael Feathers다. Jest와 Playwright는 그 계보를 각각 UI 출력과 화면 이미지에 적용한 도구다. “골든 스냅샷”이라는 표현 자체를 한 사람이 독점하는 정식 학파나 단일 발명품은 아니다. 하지만 이 역사를 실제 개발에 가져오면, 기준 이미지를 어떻게 취급할지라는 더 까다로운 문제가 남는다.
그 문제의 핵심은 기준 이미지가 정답지가 아니라 변경 감지기라는 점이다. 누군가 정상이라고 승인한 결과를 저장하고, 그 뒤의 차이를 알려줄 뿐이다. 처음 저장한 화면에 이미 잘못된 문구나 잘못된 링크가 있었다면, 스냅샷은 그 오류도 금색으로 보존한다.
기준 이미지는 정답지가 아니라 변경 감지기다
이 점은 변경 속도가 빠른 개발에서 특히 중요하다. 변경을 빠르게 만들 수 있어도, 어떤 변경이 의도된 것인지 결정하는 권한은 별개다. 링크의 목적지만 바꾸고 버튼의 크기와 위치를 유지하는 작업은 행동 변경이다. 그 경우에는 href와 클릭 가능 여부를 기능 테스트로 확인하고, 화면 기준은 그대로 둔다. 반대로 버튼을 회색으로 보이게 하거나 레이아웃을 바꾸는 요구라면 시각 변경이다. 그때만 해당 URL, 언어, viewport의 기준 이미지를 새로 승인한다.
그래서 스냅샷 갱신은 “테스트를 초록으로 만드는 정리 작업”이 아니다. 현재 기준을 폐기하고 새 기준을 채택하는 작은 릴리스 승인이다. 전체 폴더를 한꺼번에 다시 생성하는 명령은 편하지만, 그 안에 의도하지 않은 회귀도 함께 저장한다. Jest 문서도 스냅샷을 코드처럼 커밋하고 리뷰하라고 하며, 실패 원인을 확인하지 않은 채 재생성하는 습관을 경계한다.
일반적인 운영 원칙
시각 비교 실패가 많이 발생했다고 해서 기준 이미지가 특별히 권위 있어서인 것은 아니다. 하나의 UI 변경이 여러 경로와 viewport에 동시에 흔적을 남겼을 수 있다. 이 상황에서 해야 할 일은 PNG를 많이 바꾸는 것이 아니라, 실패를 네 가지 질문으로 분해하는 것이다. 어느 URL인가. 어느 언어인가. 어느 viewport인가. 실제 요구가 화면 변경인가, 아니면 동작 변경인가.
그 질문에 답한 뒤에만 기준을 갱신한다. 화면 모양을 유지해야 하는 행동 변경이면 기능 테스트를 보강하고 기준 이미지는 유지한다. 비활성 상태의 색과 모양처럼 시각 변경이 요구되면 그 범위의 이미지만 같은 실행 환경에서 갱신한다. 갱신한 이미지는 코드와 함께 리뷰하고, 검토자는 “현재 화면이 바뀌었다”가 아니라 “요청된 변경만 남아 있는가”를 본다.
이렇게 보면 골든 스냅샷은 낡은 화면을 지키는 종교가 아니다. 변경의 종류를 분리하고, 결과를 사람이 승인 가능한 단위로 줄이는 기록 장치다. Feathers의 특성화 테스트가 코드 행동을 붙잡았다면, Playwright의 화면 기준은 그 원리를 픽셀과 렌더링 환경까지 확장한 셈이다. 무엇을 금색으로 남길지는 도구가 아니라 변경을 승인하는 사람과 리뷰어가 결정해야 한다.
