문구 하나 바꾸려고 관리자 화면을 열었다가, 저장 버튼을 누르는 순간 첫 화면이 통째로 깨진다. 하필 점심시간, 접속자가 가장 많은 시간이다. 사장님은 아직 모르는데 손님은 이미 무너진 화면을 보고 있다. 식당이라면 영업 중에 홀 한복판에서 타일을 뜯는 셈이다. 큰 회사는 이런 사고를 막으려고 스테이징(staging), 즉 손님이 볼 수 없는 연습 무대를 따로 둔다. 작은 회사도 규모에 맞게 갖출 수 있다.
원칙 1 — 손님이 보는 화면에서는 직접 고치지 않는다
가장 중요한 원칙이자 나머지 네 가지의 출발점이다. 운영 중인 사이트는 무대 위다. 수정·실험·업데이트는 모두 무대 뒤에서 끝내고, 확인이 끝난 결과만 올린다. 거창한 장비가 필요한 게 아니다. 같은 사이트를 복사해 둔 test.우리도메인.com 같은 주소 하나면 시작할 수 있고, 홈페이지 빌더라면 '복제 페이지'나 '임시 저장·미리보기' 기능이 그 역할을 한다.
원칙 2 — 연습 무대는 실제 무대와 같게 꾸민다
연습 무대가 실제와 다르면 연습의 의미가 없다. 내 컴퓨터에서는 멀쩡했는데 서버에 올리니 깨지는 사고는 대부분 두 환경이 달라서 생긴다. 프로그램 버전, 설치된 기능, 데이터 구조를 운영 환경과 최대한 맞춰야 연습 무대에서 통과한 것이 실제 무대에서도 통한다. 단, 손님의 개인정보만은 복사하지 말고 가짜 데이터로 채우는 것이 안전하다.
원칙 3 — 무엇을 바꿨는지 목록으로 남긴다
사고가 나면 첫 질문은 언제나 같다. "마지막으로 뭘 건드렸죠?" 이 질문에 바로 답할 수 있으면 복구는 몇 분이면 끝나고, 답하지 못하면 밤을 새운다. 날짜·바꾼 곳·바꾼 사람 세 칸짜리 표면 충분하다. 개발자와 함께 일한다면 깃(Git) 같은 버전 관리 도구가 이 목록을 자동으로 남겨 준다.
원칙 4 — 되돌아갈 길을 먼저 만들고 나서 바꾼다
수정보다 먼저 할 일은 백업이다. 바꾸기 직전 상태를 저장해 두면 최악의 순간에도 '어제의 사이트'로 몇 분 만에 돌아갈 수 있다. 되돌릴 길이 있다는 확신이 있어야 개선도 과감해진다. 반대로 백업 없는 수정은 브레이크 없는 내리막과 같아서, 결국 아무것도 못 바꾸는 낡은 사이트로 굳어 버린다.
원칙 5 — 확인은 사장님 컴퓨터가 아니라 손님의 눈으로 한다
올리기 전 마지막 점검은 손님의 조건에서 해야 한다. 대부분의 손님은 휴대폰으로 들어오므로 모바일 화면을 먼저 보고, 브라우저의 시크릿 창을 열어 로그인도 저장된 기록도 없는 상태로 접속해 본다. 첫 화면·메뉴·문의 폼 전송까지 손님이 걷는 길을 그대로 한 번 걸어 보면, 사장님 화면에서는 보이지 않던 문제가 드러난다.
연습 무대는 겁이 아니라 자신감을 위한 것이다
스테이징은 사고를 두려워하는 장치가 아니라, 마음 놓고 바꾸기 위한 장치다. 무대 뒤가 있는 사이트는 자주, 과감하게 개선되고 그 차이가 몇 년 뒤 사이트의 수준을 가른다. CYAN 에이전시는 제작 단계부터 스테이징 환경과 배포 절차를 함께 설계해, 사이트를 연 뒤에도 사장님이 안심하고 고치고 키울 수 있는 구조를 만들어 드린다.
