배포 화면에 되돌리기 버튼이 있으면 수정에 대한 부담이 조금 줄어듭니다. 그런데 되돌릴 수 있는 것이 프로그램인지, 프로그램이 바꾼 자료까지인지 묻기 시작하면 답이 길어집니다. 작은 서비스를 운영할 때에도 두 가지는 따로 확인해야 할 수 있습니다. 편한 배포 도구를 살펴보는 날, 데이터가 어느 시점으로 돌아가야 하는지도 함께 적어 두면 좋겠습니다.
Aven은 자신의 서버에서 사용하는 오픈소스 배포 플랫폼으로 소개됩니다. 공식 안내에는 배포 전환과 롤백, 데이터베이스 백업 기능 등이 설명되어 있으며, 아직 젊은 프로젝트라는 주의도 남아 있습니다. 이 글은 해당 기능을 직접 실행한 운영 후기나 제품 간 성능 비교가 아닙니다. 배포와 복원을 한 단어로 묶지 않기 위한 가상의 작업 예시를 다루려 합니다.
참고 원문: Aven maintainer turin의 관련 원문
프로그램 버전과 자료의 모양
메모를 저장하는 작은 앱을 가정해 보겠습니다. 첫 버전은 제목과 본문을 저장하고, 다음 버전은 ‘보관함’이라는 상태를 추가합니다. 새 버전을 올린 뒤 문제가 생겨 이전 프로그램으로 돌아간다고 해 봅니다. 이전 버전이 새 상태를 모른다면 화면에서 어떤 메모를 보여 줄까요. 예전 프로그램이 다시 실행되었다는 사실만으로 질문이 끝나지는 않습니다.
이 예시의 결과는 처음 정한 구현에 따라 달라집니다. 이전 버전이 모르는 필드를 무시할 수도 있고, 입력을 엄격하게 검사해 읽기를 거부할 수도 있습니다. 어느 쪽이 실제로 일어나는지 확인하지 않은 채 ‘코드만 되돌리면 된다’고 적지 않는 편이 좋겠습니다. 앱의 버전과 데이터의 모양을 각각 적은 표가 필요한 이유입니다.
표에는 프로그램 버전, 데이터 변경 시점, 그 조합을 확인한 결과를 놓아 볼 수 있습니다. ‘첫 버전과 변경 전 자료는 확인함’, ‘첫 버전과 변경 후 자료는 미확인’처럼 적으면 됩니다. 미확인 칸이 보이면 다음에 할 일이 구체적입니다. 실제 운영 자료를 바로 건드리기 전에 공개해도 되는 시험 자료로 그 조합부터 살펴볼 수 있습니다.
백업이 있다는 말 뒤에 붙일 질문
백업 기능의 존재와 원하는 상태를 복원할 수 있다는 판단도 구분해야 합니다. 언제 만들어진 것인지, 어떤 자료가 포함되는지, 복원에 필요한 설정은 어디에 있는지 확인합니다. 메모 본문은 남아 있어도 첨부 파일의 위치나 접근에 필요한 정보가 빠지면 처음 기대한 서비스 상태와 다를 수 있습니다. 무엇을 한 묶음으로 보관할지부터 정해야 합니다.
가상의 메모 앱에는 데이터베이스와 첨부 파일이 따로 있다고 해 보겠습니다. 둘을 서로 다른 시각의 사본으로 복원하면 메모가 가리키는 파일이 없을 수 있습니다. 이런 문제를 알아보려면 백업 파일의 개수보다 사본끼리 어떤 시점을 공유하는지 살펴야 합니다. 이 예시는 특정 플랫폼에서 실제로 발생한 장애를 보고한 것이 아니라 복원 범위를 설명하기 위한 상황입니다.
복원 절차를 적을 때에는 파일을 가져오는 방법만 남기지 않았으면 합니다. 복원 뒤 확인할 행동도 함께 적어 봅니다. 예시라면 메모 하나를 읽고, 첨부 파일을 열고, 시험 메모를 새로 저장할 수 있는지 확인할 수 있습니다. 여기서 마지막 행동은 실제 서비스 이용자를 대신해 운영 자료를 바꾸라는 뜻이 아닙니다. 분리된 시험 환경에서 정해 둘 확인 항목입니다.
암호화된 설정이나 자료가 있다면 복구에 필요한 열쇠의 보관 문제도 생깁니다. 그렇다고 절차 문서에 비밀값을 그대로 적는 것은 다른 위험을 만듭니다. 필요한 정보의 종류와 승인된 보관 위치를 구분하고, 실제 값을 누가 어떤 절차로 사용할 수 있는지 확인해야 합니다. 복구를 쉽게 설명하려고 보호해야 할 자료까지 넓게 복제할 필요는 없습니다.
한 번의 복구 연습으로 확인할 범위
처음 연습을 한다면 모든 장애를 한꺼번에 만들기보다 작은 범위를 정하는 편이 낫겠습니다. 예시 앱의 시험 메모와 첨부 파일 한 묶음을 복원해 본다고 정합니다. 원본 사본은 남기고 별도 위치에서 진행한 뒤, 읽기와 연결이 유지되는지 봅니다. 연습을 했다는 기록에는 사용한 사본과 절차의 버전도 함께 남길 수 있습니다.
연습 결과가 좋았더라도 다른 상황까지 검증했다고 넓혀 적지 않습니다. 시험 자료가 작았다는 한계, 실제 이용 중 변경이 들어오는 상황은 다루지 않았다는 한계가 있을 수 있습니다. 그 빈칸을 적어 두어야 다음 연습을 정할 수 있습니다. ‘복구 가능’이라는 큰 표시 하나보다 확인한 동작의 범위가 나중에 더 쓸모 있을 것 같습니다.
시간도 같은 방식으로 다룹니다. 한 번의 시험이 빨리 끝났다고 모든 자료를 같은 시간 안에 복원할 수 있다고 약속하지는 않습니다. 자료의 크기와 연결 상태, 확인할 항목이 달라질 수 있기 때문입니다. 실제로 측정하지 않은 복구 시간을 숫자로 만들어 적기보다, 무엇을 재야 할지부터 정해 두면 됩니다.
편해진 기능만큼 줄어들지 않는 책임
자기 서버에 배포 도구를 둔다는 설명은 비용과 운영에 관한 질문을 없애 주지 않습니다. 서버와 저장 공간을 누가 관리하는지, 업그레이드 뒤 무엇을 확인할지, 문제가 생기면 누가 대응할지가 남습니다. 소프트웨어가 무료라는 소개를 서비스 운영의 모든 비용이 없다는 뜻으로 읽지는 않아야겠습니다. 이 글에서는 어떤 서버도 새로 설치하거나 변경하지 않았습니다.
기존 도구가 필요한 기능을 제공하고 있다면 먼저 그 도구의 실제 복원 경로를 살펴볼 수 있습니다. 새 제품을 도입하는 일이 오래된 빈칸을 자동으로 채워 주지는 않습니다. 예시의 앱 버전과 자료 버전을 적은 표는 어떤 제품을 쓰더라도 질문을 정리하는 출발점이 될 수 있습니다. 제품 소개표를 그대로 운영 계획으로 옮기지 않으려는 것입니다.
실제 변경을 앞두고 있다면 중단할 기준도 미리 적어 두고 싶습니다. 시험 환경에서 자료를 읽지 못했거나, 필요한 사본의 시점을 알 수 없다면 다음 변경을 서두르지 않는 식입니다. 진행하지 않은 일을 실패로 숨길 필요는 없습니다. 지금 확인할 수 없는 조건을 설명하면 독립적으로 할 수 있는 준비도 나누어 볼 수 있습니다.
나는 되돌리기 버튼을 믿기 전에 그 버튼이 되돌리는 대상을 알고 싶습니다. 프로그램과 자료를 같은 시점으로 돌릴 수 있는지, 그 뒤에 할 일을 확인했는지 살펴봅니다. 다음 배포를 준비하는 날에는 변경 목록 옆에 복원할 자료의 범위를 한 줄 적어 두면 어떨까요. 편리함을 포기하는 일이 아니라, 편리함을 사용할 조건을 분명히 하는 일일 것입니다.
함께 읽기: 사이드 프로젝트 백업: 서버 복구에 필요한 기록과 복원 연습
공개 원문을 참고하고 AI의 도움으로 구성한 글입니다. 자체 예시는 본문에 구분했으며, 원문의 제품이나 실험을 직접 실행한 후기가 아닙니다.
