새 디자인이 준비되면 정해진 날에 전부 켜고 싶어집니다. 발표하기도 좋고, 두 디자인이 섞여 있는 어색한 기간도 없습니다. 그런데 이 방식에는 대가가 하나 있습니다 — 문제가 생겼을 때 무엇이 원인인지 알 수 없습니다.
전면 교체 다음 날 유입이 흔들렸다고 해 봅시다. 원인 후보는 주소 변경일 수도, 제목 태그일 수도, 페이지 속도일 수도, 내부 링크 구조일 수도, 그냥 그 주의 계절성일 수도 있습니다. 동시에 바꿨기 때문에 가설을 하나씩 지울 방법이 없습니다.
전환의 단위는 템플릿입니다
첫 회차에서 페이지가 아니라 템플릿을 셌던 이유가 여기서 드러납니다. 템플릿 하나를 켜면 그 템플릿으로 그려지는 화면 전부가 함께 바뀌고, 바뀐 집합이 명확합니다. 관측할 대상도 그 집합입니다.
순서의 원칙은 위험은 낮고 학습은 큰 것부터 입니다. 글 상세는 화면 수가 많아 실제 콘텐츠의 다양성이 바로 드러나고, 그러면서도 전환 경로의 중심은 아닙니다. 여기서 배운 것 — 긴 제목, 표, 인용, 이미지 처리 — 이 나머지 템플릿에 그대로 반영됩니다.
홈은 마지막입니다. 노출은 가장 많고 배울 것은 가장 적기 때문입니다. 홈은 화면이 하나뿐이라 콘텐츠 다양성에서 배울 것이 없고, 대신 잘못됐을 때 잃는 것이 가장 큽니다.
두 디자인이 공존하는 기간
점진 전환의 대가는 한동안 사이트가 섞여 있다는 점입니다. 이 어색함을 줄이는 방법이 있습니다 — 헤더와 푸터를 먼저 통일하는 것입니다. 방문자가 화면 전환을 인식하는 가장 큰 단서가 상단과 하단이므로, 이 둘이 같으면 본문 레이아웃이 달라도 “같은 사이트” 로 읽힙니다.
버튼 · 링크 색 · 본문 타이포처럼 전 화면에 걸치는 요소도 먼저 옮깁니다. 새 디자인 시스템의 토대를 먼저 깔고 템플릿을 하나씩 그 위로 올리는 순서가, 템플릿마다 다른 규칙을 들고 가는 것보다 언제나 빠릅니다.
단계마다 무엇을 보는가
템플릿 하나를 켠 뒤에는 며칠 두고 봅니다. 볼 것은 셋입니다 — 그 템플릿의 화면들이 여전히 색인되고 있는가, 속도가 나빠지지 않았는가, 그리고 그 화면에서 이어지던 다음 행동이 그대로인가. 세 가지가 괜찮으면 다음 템플릿으로 갑니다.
이 관측 방식과 정상 범위의 판단 기준은 배포 후 점검을 다루는 회차에서 자세히 이어집니다.
단계적 배포와 검증 절차는 개발 워크플로우 아카이브에서 더 다루고, 무중단으로 단계를 나눠 진행하는 실제 작업 방식은 최적화 지원 사업에서 그대로 쓰고 있습니다.
다음 회차
템플릿을 하나씩 켜다 보면 반드시 만나는 것이 있습니다 — 새 디자인을 따르지 않는 옛 본문입니다. 다음 회차의 주제입니다.