주말 행사를 앞두고 쇼핑몰 메인 화면을 고치고 있었습니다.
지난 행사의 배너를 내리고, 이번 주에 밀어줄 상품을 위로 올리려던 참이었습니다.

행 하나를 지운 뒤에야 그 안에 배너만 있었던 것이 아니라는 사실을 알아챕니다.
함께 진열해 둔 상품과 안내 문구까지 화면에서 사라졌습니다.

삭제하는 데는 몇 초도 걸리지 않았습니다.
하지만 원래대로 만드는 데 얼마나 걸릴지는 알 수 없습니다.

어떤 상품을 골랐는지, 칸의 넓이는 얼마였는지, 모바일에서는 몇 개씩 보이게 했는지 다시 떠올려야 합니다. 기억나지 않으면 지난 화면을 본 사람에게 묻거나, 개발자에게 연락해 남아 있는 기록부터 찾아달라고 해야 합니다.

연락을 받은 쪽도 난감하기는 마찬가지입니다.
남은 흔적을 뒤져 어제 화면을 짐작으로 되살리는 일은, 새로 만드는 것보다 오래 걸릴 때가 많습니다.

이런 일을 한 번 겪고 나면 사람은 편집기를 대하는 방식부터 달라집니다.
새로운 구성을 시도하기보다 지금 화면을 건드리지 않는 쪽을 택합니다.

실수의 비용은 사라진 화면만이 아닙니다

네 번째 글 「블록 시스템」에서 운영자가 기능을 직접 배치할 수 있어야 한다고 적었습니다.

하지만 손댈 수 있게 하는 것만으로는 충분하지 않습니다.
잘못 손댔을 때 돌아올 수 없다면 자유는 곧 부담이 됩니다.

삭제 버튼 앞에 경고창을 하나 더 띄우는 방법도 있습니다. 확인 문구를 입력하게 하거나 권한을 가진 사람만 누르게 할 수도 있습니다.

필요한 장치지만 그것만으로 실수는 없어지지 않습니다.
사람은 경고를 잘못 읽고, 익숙한 버튼을 빠르게 누르고, 맞는 대상을 보고 있다고 생각한 채 틀린 대상을 고릅니다.

실수를 막는 일에는 한계가 있습니다.
그래서 중요한 것은 실수를 하지 않게 만드는 것만이 아니라, 실수한 뒤에도 일이 파멸이 되지 않게 만드는 것입니다.

저장하기 전에 이전 상태를 남깁니다

머블로는 편집 화면에서 블록 행을 저장하거나 삭제하기 전에 지금 상태를 먼저 기록합니다.
행의 위치와 넓이 같은 설정뿐 아니라 그 안의 칸과 콘텐츠까지 하나의 스냅샷으로 남깁니다.

수정한 뒤 결과가 마음에 들지 않으면 변경 이력에서 이전 상태를 골라 복구할 수 있습니다.
행을 아예 삭제했다면 블록 행 관리의 삭제 이력에서 다시 화면에 추가할 수 있습니다.

블록 킷으로 기존 구성을 교체할 때 사라지는 행도 같은 이력에 남습니다.
한 번에 화면을 바꾸는 기능일수록 돌아오는 길도 함께 있어야 하기 때문입니다.

복구 역시 현재 상태를 지우고 과거로 뛰어가는 동작입니다.
그래서 복구하기 직전의 상태도 다시 이력으로 남깁니다. 어제의 화면으로 돌아갔다가 오늘의 화면이 더 나았다는 것을 깨달아도 다시 선택할 수 있어야 합니다.

이력은 실수를 없었던 일로 만들지 않습니다.
다만 실수 때문에 처음부터 다시 만들어야 하는 일을 줄여줍니다.

이미지도 이력의 일부입니다

설정만 남겨두고 그 설정이 가리키는 이미지를 지워버리면 복구는 겉모양뿐인 약속이 됩니다.
지난 상태를 골랐는데 배너가 빈칸으로 돌아온다면 원래 화면을 복구한 것이 아닙니다.

그래서 블록에서 빠진 이미지를 곧바로 삭제하지 않습니다.
현재 화면의 다른 블록이 쓰고 있는지 확인하고, 변경 이력이나 삭제 이력이 여전히 그 이미지를 가리키고 있는지도 확인합니다.

어디에서도 쓰지 않고, 돌아갈 이력에서도 필요하지 않을 때 비로소 파일을 정리합니다.

반대쪽도 마찬가지입니다.
새 이미지를 올린 뒤 저장에 실패했다면 화면에는 기록이 없는데 파일만 남아서는 안 됩니다. 데이터 저장과 파일 정리는 같은 성공과 실패의 경계를 따라야 합니다.

복구할 수 있다는 말은 데이터 한 줄만 남겨둔다는 뜻이 아닙니다.
그 상태를 다시 화면으로 만들기 위해 필요한 것의 수명까지 함께 책임진다는 뜻입니다.

모든 것을 되돌릴 수 있는 것은 아닙니다

머블로의 변경 이력은 행마다 최근 30개까지 보관합니다.
서버 전체의 백업이나 데이터베이스 복구를 대신하는 기능은 아닙니다.

도메인을 삭제하거나 시스템 데이터를 초기화한 경우, 저장소 자체를 잃어버린 경우까지 이 이력으로 되돌릴 수는 없습니다.
그런 작업에는 여전히 별도의 백업이 필요합니다.

블록 킷으로 페이지를 교체한 경우에도 행은 삭제 이력에서 복구할 수 있지만, 페이지의 레이아웃과 검색 설정까지 한꺼번에 자동 복구되지는 않습니다.

어디까지 돌아갈 수 있는지 분명히 말하지 않으면 복구 기능은 오히려 잘못된 안심을 줍니다.
되돌릴 수 있는 범위와 백업이 필요한 범위를 나누는 것도 이 구조가 지켜야 할 경계입니다.

시도할 수 있는 화면

화면을 고치는 사람과 그것을 되살려야 하는 사람이 같은 곳입니다.

메인 화면에서 상품 순서를 바꾸는 일마다 복사본을 따로 만들고, 혹시 잘못될까 개발자에게 먼저 확인받을 수는 없습니다.
그렇다고 운영자가 아무것도 건드리지 않는 것이 안전한 운영도 아닙니다.

지난 행사의 배너를 잘못 지워도 삭제 이력에서 다시 가져올 수 있는 것.
새 구성이 마음에 들지 않으면 저장하기 전의 화면으로 돌아갈 수 있는 것.
어제의 화면으로 돌아갈 때 그 화면에 쓰였던 이미지도 함께 남아 있는 것.

이런 장치가 있다고 해서 사람의 실수가 사라지지는 않습니다.
대신 한 번의 실수가 다음 시도까지 막는 일은 줄어듭니다.

운영자가 화면을 직접 바꿀 수 있다는 말은 버튼을 누를 권한이 있다는 뜻만은 아닙니다.
잘못 눌렀을 때 돌아올 길까지 가지고 있다는 뜻이어야 합니다.

되돌릴 수 있어야 시도할 수 있습니다.