2년 전에 열었던 팀들의 페이지가 남아 있지 않았다. 그 팀이 무엇을 다뤘고 파트너(팀 하나를 맡아 이끄는 사람)가 누구였는지 확인할 길이 없었다.

시즌(3개월마다 팀을 새로 여는 단위)마다 팀이 열여덟에서 스무 개 열리고, 각각 상품 페이지가 하나씩 있다. 3개월 뒤 새 시즌이 오면 또 스무 장이다.

이 반복에서 오래 곤란했던 건 만드는 일이 아니라 지난 것이 사라지는 일이었다.

지난 시즌이 조용히 없어진다

새 시즌 상품을 만들 때 지난 시즌 것을 고치게 된다. 같은 팀이 이어서 열리면 날짜와 회차만 바꾸는 게 빠르니까. 그러면 지난 시즌 페이지가 덮어써진다.

몇 시즌 지나고 나서야 알았다. 회차 주제가 뭐였는지도 찾을 수 없었다.

이게 왜 문제냐면, 멤버가 예전에 들었던 팀을 다시 찾을 때 보여줄 게 없다. 그리고 우리 스스로도 2년 전에 이 주제를 어떻게 다뤘는지 확인할 수 없다.

백업, 평가, 보완, 동기화

그래서 상품을 다루는 일을 네 단계로 묶었다.

먼저 백업이다. 어떤 작업을 하기 전에 지금 웹사이트에 올라가 있는 상품 본문을 전부 노트로 내려받는다. 이게 첫 단계인 이유는, 뒤에서 무슨 일이 생겨도 되돌릴 수 있어야 하기 때문이다. 실제로 한 번 배포 도구(노트를 웹사이트에 올려 주는 프로그램)가 상품 본문을 망가뜨린 적이 있는데, 그날 복구할 수 있었던 건 백업이 있어서였다.

다음이 평가다. 스무 개 페이지가 같은 항목을 다 갖추고 있는지 본다. 회차가 여섯 개인지, 파트너 소개가 있는지, 정원이 적혀 있는지. 사람이 스무 개를 눈으로 비교하면 열두 번째부터 흐려진다.

세 번째가 보완이다. 빠진 걸 채운다.

마지막이 동기화다. 노트가 정본이고 웹사이트가 사본이다. 노트를 고치고 올리는 방향으로만 흐른다. 웹사이트에서 직접 고치는 건 안 한다. 그러면 두 곳이 갈라지고, 갈라지면 어느 쪽이 맞는지 알 수 없게 된다.

이전 시즌은 복사본으로 남긴다

여기에 하나를 더했다. 팀을 다음 시즌으로 옮길 때 원래 카테고리에 복사본을 남긴다. 옮기기 전에 먼저 복제한다.

이게 지난 시즌이 사라지는 걸 막았다. 지금은 몇 년 전 팀들의 페이지가 그대로 있다.

따라 해보기

주기적으로 갱신하는 자료가 있다면, 갱신 전에 지금 상태를 복사해 두는 단계를 흐름의 맨 앞에 넣으면 된다. 나중에 백업하겠다는 계획은 지켜지지 않는다.