시안이 승인되고 구현이 끝나면 리뷰를 받습니다. 이때 스크린샷을 모아 보내는 방식이 편하지만, 스크린샷 리뷰를 통과한 화면이 배포 후에 문제를 내는 일은 아주 흔합니다. 이유는 단순합니다 — 스크린샷은 가장 좋은 조건의 한 순간이고, 실제 사이트는 그 조건 밖에서 대부분의 시간을 보내기 때문입니다.
스크린샷이 감추는 것
특히 실제 콘텐츠 길이가 그렇습니다. 시안의 제목은 두 줄에 딱 맞게 쓰였지만 편집자가 쓰는 제목은 그렇지 않습니다. 카드 세 장이 나란히 서는 레이아웃에서 한 장의 제목만 세 줄이 되면 그 줄이 무너집니다. 이것은 스크린샷에서는 절대 보이지 않고, 실제 데이터가 들어간 화면에서만 보입니다.
상태도 마찬가지입니다. 링크에 마우스를 올렸을 때, 키보드 Tab 으로 이동할 때, 폼에 오류가 났을 때의 화면은 시안에 잘 그려지지 않습니다. 리뉴얼 전 사이트에는 있었던 포커스 표시가 새 디자인에서 사라지는 일이 자주 생기는데, 마우스로만 리뷰하면 아무도 발견하지 못합니다.
스테이징에는 조건이 있습니다
스테이징은 그냥 “복사본” 이 아닙니다. 조건을 갖추지 않은 스테이징은 그 자체로 사고를 만듭니다.
검색 차단은 특히 중요합니다. 스테이징이 색인되면 같은 내용이 두 주소에 존재하게 되고, 검색엔진이 어느 쪽을 원본으로 볼지 모르는 상태가 됩니다. 리뉴얼 중에 이런 일이 생기면 원인 파악이 배로 어려워집니다.
메일 발송도 자주 잊힙니다. 스테이징에서 주문이나 문의를 테스트하면 그 알림이 실제 고객 주소로 나갑니다. 발송을 막거나 전부 한 주소로 몰아 두는 설정을 먼저 합니다.
리뷰를 요청하는 방식
주소만 던지면 “좋네요” 라는 답이 돌아옵니다. 세 가지를 함께 적으면 답의 질이 달라집니다 — 어느 화면을, 무엇을 보고, 어떤 결정이 필요한지. “글 상세 화면입니다. 제목이 세 줄일 때와 인용문이 긴 경우를 봐 주세요. 본문 폭을 지금보다 좁힐지 결정이 필요합니다” 같은 요청은 구체적인 답을 받습니다.
리뷰 대상은 앞 회차에서 만든 유입 상위 목록 순서로 정합니다. 시간이 부족할 때 어느 화면을 먼저 볼지가 저절로 정해집니다.
스테이징 구성과 배포 절차는 개발 워크플로우 아카이브에 더 있고, 우리가 실제로 스테이징을 어떻게 쓰는지는 작업 과정에 단계별로 적혀 있습니다.
다음 회차
리뷰가 끝났습니다. 이제 배포인데, 한 번에 전부 켜지 않습니다 — 다음 회차는 템플릿 단위 점진 전환입니다.