처음에는 라이브 사이트에서 바로 고치는 것이 합리적입니다. 방문자가 적고, 잘못돼도 금방 되돌리면 되고, 무엇보다 빠릅니다. 그런데 어느 시점부터 같은 행동의 성격이 달라집니다.
기준은 방문자 수가 아니라 실패했을 때 잃는 것입니다. 고치는 동안 화면이 깨져도 아무도 못 보던 상태에서, 그 30초 사이에 누군가 결제를 시도하는 상태로 바뀌는 순간이 그 시점입니다.
이런 신호가 오면 필요합니다
특히 망설임이 정확한 신호입니다. 업데이트 알림을 보고도 미루기 시작했다면, 그것은 신중함이 아니라 안전하게 시험할 곳이 없다는 뜻입니다. 그리고 미뤄진 업데이트는 시간이 갈수록 위험해집니다.
테스트 사이트가 실제로 하는 일
테스트 사이트(스테이징)는 라이브와 같은 구성의 복사본입니다. 여기서 먼저 해 보고, 괜찮으면 라이브에 적용합니다. 목적은 완벽한 검증이 아니라 놀라지 않는 것입니다.
쓸모 있으려면 조건이 있습니다. 구성이 같아야 합니다 — 워드프레스 · 테마 · 플러그인의 버전이 라이브와 다르면 여기서의 결과가 라이브를 예측하지 못합니다. “테스트에서는 됐는데” 의 대부분이 이 차이에서 나옵니다.
지켜야 할 규칙 세 가지
첫째, 검색엔진에서 가립니다. 테스트 사이트가 색인되면 같은 내용이 두 주소에 존재하게 되고, 검색 결과에 테스트 주소가 나오는 일이 실제로 벌어집니다. 만들자마자 색인 차단을 확인하세요.
둘째, 양쪽에서 동시에 고치지 않습니다. 테스트에서 레이아웃을 바꾸는 동안 라이브에서 글을 발행하면, 나중에 어느 쪽을 기준으로 합칠지 정할 수 없게 됩니다. 흐름은 한 방향이어야 합니다.
셋째, 고객 정보를 함부로 복사하지 않습니다. 라이브 데이터를 그대로 복사하면 주문 내역과 문의 내용이 보호가 약한 곳에 한 벌 더 생깁니다. 필요 없다면 개인정보는 비우고 복사하는 편이 안전합니다.
없는 상태에서 오늘 할 수 있는 것
아직 테스트 사이트를 만들 여건이 아니라면, 최소한 순서만이라도 지키세요. 백업을 먼저 받고, 방문이 적은 시간대에, 한 번에 하나씩 바꾸고, 바꾼 직후에 확인합니다. 이것만으로도 사고의 상당수가 걸러집니다.
변경을 안전하게 옮기는 절차는 개발 워크플로우 아카이브에서 더 다루고, 실제 작업에서 스테이징을 어떻게 쓰는지는 작업 과정에 단계별로 공개돼 있습니다.
다음 회차
사이트가 커지면 만지는 사람도 늘어납니다. 다음 회차는 권한 설계입니다 — 모두를 관리자로 두면 왜 아무도 관리자가 아니게 되는지 다룹니다.