디자인 QA는 공개 화면만 보고 끝낼 수 없었다

블로그를 정기적으로 점검하는 일은 공개 페이지를 한 번 열어 보는 것으로 끝나지 않았다. 화면에서 어색해 보이는 지점이 실제 CSS 결함인지, 콘텐츠 길이와 아이콘 배치가 만든 시각적 인상인지 구분해야 했다. 또 수정이 필요하다고 판단했을 때는 공개된 이전 화면이 아니라 수정 브랜치가 실제로 렌더링한 결과로 확인해야 했다.

정적 블로그의 모바일 화면, 레이아웃 측정선, 로컬 검증 서버, 검토용 변경 묶음을 차례로 연결한 가로형 편집 도해.

시각적 점검은 감상으로 시작할 수 있지만, 변경의 근거는 렌더링 결과·계산된 레이아웃·재현 가능한 검증 경로까지 남겨야 한다.

정기 점검을 실제 브라우저 흐름으로 정리했다

먼저 공개 블로그의 홈과 주요 탐색 경로를 데스크톱과 모바일 뷰포트로 확인할 수 있는 흐름을 정리했다. 정적 페이지라고 해도 목록, 검색 인덱스, 메뉴와 같은 요소는 화면 크기에 따라 역할이 바뀐다. 그래서 단순 HTTP 응답 확인과 별도로 실제 브라우저 캡처를 남기고, 파일 형식과 픽셀 크기도 확인하는 방식으로 점검 기준을 잡았다.

정기 점검은 큰 시각 변경을 억지로 만들기 위한 작업이 아니다. 깨진 링크나 이미지, 좁은 화면의 오버플로, 탐색의 혼란, 정보 위계가 실제로 나빠지는 경우처럼 근거가 분명할 때만 개선으로 이어져야 한다. 반대로 글과 이미지 추가처럼 페이지 구조를 바꾸지 않는 발행은 별도 디자인 QA를 매번 일으킬 이유가 없다.

모바일 목록에서는 ‘문제처럼 보이는 것’을 먼저 측정했다

모바일 홈 목록을 살피는 과정에서 날짜·제목·설명·화살표가 한 행 안에서 어떻게 배치되는지 다시 확인했다. 수정 대상은 작은 화면에서 날짜와 본문이 같은 좁은 열을 공유해, 목록의 읽기 흐름이 불안정해질 수 있는 구조였다. 이 경우 날짜와 본문은 읽기 열에 두고, 화살표만 끝 열에 고정하는 편이 더 명확했다.

다만 이후 오른쪽이 더 넓어 보인다는 인상도 그대로 버그로 취급하지 않았다. 수정 브랜치를 로컬 서버에서 띄운 뒤 390px 뷰포트의 계산된 좌표와 grid 열 값을 확인했다. 실제 양쪽 바깥 여백은 대칭이었고, 본문과 화살표 사이의 간격도 CSS에서 정한 값과 일치했다. 이 확인 덕분에 시각적 인상을 근거 없이 또 다른 CSS 변경으로 키우지 않을 수 있었다.

이 구분은 사소해 보여도 중요하다. 화면에서 느끼는 불편함은 좋은 출발 신호지만, 곧바로 수정 명령은 아니다. 레이아웃 값, 콘텐츠 길이, 아이콘의 시각적 무게 중 무엇이 원인인지 확인해야 다음 변경이 문제를 줄이는지 알 수 있다.

검증 스크린샷은 보고용 부록이 아니라 리뷰 대상이다

수정은 별도 브랜치에서 최소 범위로 만들고, 컨테이너 기반 Jekyll 서버로 빌드와 로컬 HTTP 응답을 확인했다. 그 다음 데스크톱과 모바일 화면을 캡처해 변경 브랜치에 함께 넣고, PR 본문에서 바로 볼 수 있도록 연결했다. 리뷰어가 코드만 보고 추측하지 않고, 같은 변경이 실제 화면에 어떤 차이를 만드는지 함께 검토할 수 있게 하기 위해서다.

여기서 중요한 것은 공개 사이트의 스크린샷으로 대체하지 않는 일이다. 공개 페이지는 아직 병합되지 않은 수정 브랜치를 보여 주지 않는다. 로컬 검증 URL, 빌드 결과, 해당 브랜치의 캡처가 한 묶음이어야 “이 코드가 이 화면을 만들었다”는 관계를 다시 확인할 수 있다.

남은 기준: 자동화는 판단을 대체하지 않는다

이번 흐름으로 정기 디자인 QA와 큰 UX 변경 뒤 점검을 구분했다. 자동화는 정해진 화면 크기, 핵심 페이지, 파일 검증, PR 형식을 빠뜨리지 않게 돕는다. 하지만 무엇이 실제 결함인지, 기존 디자인 언어를 해치지 않는 최소 수정이 무엇인지는 캡처와 렌더링 근거를 보고 판단해야 한다.

그래서 앞으로의 순서는 단순하다. 공개 화면에서 이상 신호를 찾고, 코드와 실제 레이아웃으로 원인을 좁히며, 수정이 필요할 때만 브랜치에서 빌드한다. 그리고 로컬 렌더링 화면을 PR 안에 남긴다. 디자인 QA의 결과는 더 많은 변경이 아니라, 왜 이 변경은 필요했고 왜 다른 변경은 하지 않았는지를 다시 읽을 수 있는 검증 묶음이어야 한다.