홈페이지가 하나 완성되면 다음에도 비슷하게 만들 수 있을 것 같다. 폴더를 복사하고 이름과 사진을 바꾸면 되는 것처럼 보인다. 그런데 화면을 조금씩 고치다 보면 원래 잘 움직이던 메뉴가 달라지고, 이전 사이트의 문구나 이미지가 뜻밖의 곳에 남는다. 빨리 시작하는 것과 안전하게 이어가는 것은 다른 문제였다.
나는 한 제작 작업의 구조와 움직임을 보존하면서 자료를 교체하는 템플릿을 만들었다. 여기서 내가 보존한 것은 내가 처음부터 발명한 디자인이라고 주장할 대상이 아니라, 해당 작업에서 기준으로 삼고 확인한 화면과 동작이다. 다음 작업의 목적에 맞게 바꿀 정보와 보존할 구조를 먼저 나누는 것이 중요했다.
고객이 궁금해하는 것은 다음 수정의 비용이다
재사용할 수 있다고 말하면 같은 모양의 홈페이지가 나온다는 뜻으로 들릴 수 있다. 내가 중요하게 본 것은 수정의 범위다. 제목을 바꿀 때 어느 파일을 읽고, 사진을 바꿀 때 어디까지 확인하며, 자료가 없는 페이지는 어떻게 처리하는지 알 수 있어야 한다. 다음 변경의 출발점을 알아야 재사용이 실제 운영의 도움이 된다.
모든 것을 고정하면 사업의 차이를 담을 수 없다. 모든 것을 자유롭게 바꾸면 검증한 구조를 다시 검사해야 한다. 나는 고정하는 이유와 바꿀 수 있는 이유를 각각 적어두었다. 색상과 문구를 바꿔도 되는 것과 메뉴의 구조나 전환 로직을 함부로 바꾸면 안 되는 것은 다른 종류의 선택이다.
나는 구조를 보존하는 영역을 먼저 정했다
설계 계약에는 헤더와 전체 메뉴, 하위 메뉴, 본문을 감싸는 구조, 푸터를 보존한다고 적었다. 원본 CSS의 기하 구조와 타이포그래피, 모바일 분기점, 슬라이드와 등장 효과의 순서도 기준에 포함했다. 예약 팝업의 달력과 시간 선택, 오류와 성공 상태 역시 화면의 일부였다.
이 영역은 보기 좋은 장식만 모은 것이 아니다. 다른 요소와 연결되어 움직이는 부분이다. 클래스 하나가 바뀌면 메뉴나 전환 스크립트가 대상을 찾지 못할 수 있다. 그래서 새 자료를 넣는 사람이 구조를 고치는 대신, 별도로 정리한 입력 항목을 바꾸게 만들었다.
바꾸는 자료는 이름이 있는 입력 항목으로 만들었다
그때의 교체 카탈로그에는 문구 308개와 이미지·미디어 슬롯 106개, 페이지 경로 18개가 기록되어 있었다. 이 수는 모든 홈페이지에 필요한 표준 수량이 아니다. 그 작업의 기준 화면에서 무엇을 교체할 수 있는지 구체적으로 찾은 결과였다.
슬롯은 자료가 들어갈 자리와 역할을 알려준다. 메인 이미지, 공유 이미지, 본문 도면처럼 역할을 나누면 같은 파일을 여러 곳에 무심코 붙이는 일을 줄일 수 있다. 자료의 상태, 종류, 맞춤 방식, 생성 여부도 함께 적었다. 자료가 확인됐다는 표시와 파일이 실제로 존재한다는 확인은 둘 다 필요했다.
나는 내용과 운영 설정도 구별했다. 문의 수신자와 인증 정보는 방문자가 볼 자료가 아니다. 화면의 연락 문구를 바꾸는 것과 실제 문의가 도착할 서버의 대상을 바꾸는 것은 별도의 확인이다. 이번 공개 예시에는 기존 사이트의 연락처나 운영자 정보를 남기지 않는다.
자료가 없는 경우와 아직 모르는 경우는 달랐다
없는 자료는 없는 것으로 정리할 수 있다. 그 메뉴와 연결된 홈 영역을 빼고, 남은 메뉴의 순서와 연결을 유지하면 된다. 하지만 자료가 아직 확인되지 않았다면 없다고 결정한 것이 아니다. 나는 확인됨, 없음, 미확인의 세 상태를 구별했다.
배포용 빌드는 미확인 상태를 거부하도록 만들었다. 미리보기에서는 준비 중인 부분을 살펴볼 수 있지만, 검수용 화면이 운영 상태로 오해되어서는 안 된다. 빈 파일이나 임시 문구가 들어갔다는 이유로 자료 준비가 끝났다고 판단하지 않았다. 이 기준은 사람의 메모를 실제 실행 조건으로 바꾸는 역할을 했다.
코드와 구현 살펴보기
구조를 설명하기 위해 새로 정리한 입력 예시
const page = {
status: "pending", // confirmed | absent | pending
title: "자료 페이지",
items: []
};
function canRelease(page) {
if (page.status === "pending") return false;
if (page.status === "absent") return true;
return page.items.length > 0;
}보존과 교체는 서로 다른 검사로 확인했다
원본이 그대로 남았는지는 해시를 비교해 확인했다. 새 사이트가 올바르게 바뀌었는지는 메뉴와 자료 경로, 이전 이름의 잔존, 미연결 문의 기능을 검사했다. 원본 보존에 성공했다고 새 자료가 맞는 것이 아니고, 새 제목이 보인다고 원본이 보존된 것도 아니었다.
과거 검수 기록에는 원본 1,497개 파일의 보존 대조와 26개 자동 검사, 원본 자료 비교용 빌드와 일부 자료가 없는 시험 빌드가 따로 남아 있다. 이번 글을 쓰면서는 원본 해시 보존, 자료가 없는 메뉴 제거, 남은 메뉴 연결, 미확인 입력 거부, 도면 크롭 거부, 비공개 설정 제외, 집계 근거 비공개의 관련 검사 7개를 다시 실행했고 모두 통과했다.
이 결과는 그 검사들이 확인하는 범위에 대한 근거다. 모든 사업의 자료와 모든 모바일 브라우저를 검증했다는 뜻은 아니다. 새 사이트의 실제 자료, 도면, 예약 수신, 작은 화면에서의 읽기는 적용할 때 다시 확인해야 한다.
새 홈페이지를 맡길 때 나는 이런 질문을 남긴다
재사용 템플릿은 사업을 이해하는 과정을 대신하지 않는다. 자료를 교체하는 순서와 실패를 막는 기준을 남기는 도구다. 새로운 목적 때문에 구조 자체가 달라져야 한다면, 그것은 단순 교체가 아니라 새로운 설계 작업으로 판단해야 한다.
- 이번 사업에 그대로 보존할 화면과 동작은 무엇인가.
- 문구·이미지·페이지를 바꿀 입력 위치가 분명한가.
- 없는 자료와 확인 중인 자료가 구별되어 있는가.
- 이전 이름·연락처·이미지·운영 설정이 섞이지 않는가.
- 원본 보존 검사와 새 자료 확인 검사를 따로 수행하는가.
- 검수용 미리보기와 실제 발행 결과를 구별하는가.
나는 빠른 복사보다 다음 변경의 기준을 남기고 싶다
같은 출발점을 쓰면 다음 제작이 빨라질 수 있다. 다만 속도를 얻는 대가로 무엇이 같고 무엇이 달라졌는지 잃어버리면, 작은 수정이 다시 큰 조사로 돌아온다. 나는 보존할 구조와 교체할 자료, 확인할 조건을 한 흐름으로 남기려 했다.
내가 없어도 다음 사람이 어디를 고쳐야 할지 알 수 있으면 좋겠다. 이 템플릿에서 얻은 방법은 모든 홈페이지를 같은 모습으로 만드는 비법이 아니라, 다음 변경을 설명할 수 있게 만드는 작업 방식이다.