요약

  • Atlas의 Backup Compliance Policy를 켜면 프로젝트 소유자도 보호 중인 스냅샷을 삭제하거나 이미 정한 보존 기간을 줄일 수 없다. 프로젝트 전체의 기존·신규 클러스터에 최소 정책이 적용된다.
  • 클러스터를 종료해도 해당 정책에 따른 기존 백업은 남는다. 보호 기간 뒤의 추가 보존 기간에는 적절한 권한을 가진 사용자가 삭제할 수 있어, 오래 남아 있다는 사실과 삭제로부터 보호된다는 사실을 구분해야 한다.

소유자라는 직함으로 열리지 않는 문

프로젝트를 소유하고도 지우지 못하는 파일이 있다. MongoDB Atlas의 Backup Compliance Policy는 바로 그 불편함을 상품으로 만든다. 관리자가 실수로, 또는 공격자가 관리자 권한으로 백업까지 없애는 상황에 대비하려면 삭제 권한이 늘 넓을수록 좋은 것은 아니다. 미래의 자신에게서 지우개를 거둬 두는 선택도 필요하다.

문제는 그 선택을 보안 화면 안에만 가두는 데서 시작된다. 보호 기간을 승인하는 순간 기업은 그 기간에 필요한 저장 비용과, 실제 서비스가 사라진 뒤에도 기록을 맡을 사람을 함께 정해야 한다. 살아 있는 데이터베이스의 책임자와 퇴역 후 남은 기록의 책임자가 언제까지 같은 사람일 것인가.

MongoDB의 정책 문서는 M10 이상 전용 클러스터를 적용 대상으로 제시한다. 여기서 다루는 것은 Atlas Core의 그 전용 환경이다. 정책은 클러스터 하나에만 붙이는 표지가 아니라 프로젝트의 최소 백업 기준이다. 기존 클러스터의 설정도 그 기준에 맞춰지고 새로 만드는 클러스터도 적용받는다. 더 긴 보존을 정한 개별 정책은 그보다 높게 남을 수 있다. 바닥을 깔았다고 천장까지 생기지는 않는다.

예산 회의가 과거의 만료일을 고칠 수는 없다

정책이 켜진 동안에는 역할에 관계없이 보호 중인 스냅샷을 삭제하거나, 촬영 후 보존 기간을 줄이거나, Cloud Backup을 끌 수 없다. 클러스터별 설정을 프로젝트의 최소 기준 아래로 내리는 것도 막힌다. MongoDB는 그 결과로 백업 저장 비용을 낮출 수 있는 수단이 제한된다고 명시한다.

이 대목은 보호 장치의 장점과 비용이 같은 곳에서 나온다는 사실을 보여 준다. 회사 사정을 이유로 오늘 삭제할 수 있다면, 회사의 관리자 권한을 빼앗은 사람도 같은 문을 두드릴 수 있다. 따라서 삭제를 어렵게 만든 기능에 다음 달 예산 회의만을 위한 비밀 통로를 기대하기는 어렵다.

대신 결정 시점을 앞으로 옮겨야 한다. 어떤 데이터를 얼마나 오래 보호할 것인지, 그 프로젝트에 실험용 클러스터까지 넣을 것인지부터 비용 책임자가 참여해야 한다. 가령 짧은 시험 서비스를 운영하는 팀이 장기간 보존하는 업무와 같은 프로젝트를 쓴다면, 서비스의 종료일보다 백업의 보호 의무가 길어질 수 있다.

종료 버튼은 백업 달력의 지름길이 아니다

클러스터 종료 절차에서 보호 정책이 켜진 경우 Atlas는 기존 스냅샷을 백업 정책에 따라 유지한다. Atlas Core의 시점 복구용 작업 기록도 사용할 수 있는 범위까지 정적인 상태로 남는다. 종료된 데이터베이스가 계속 새 거래를 기록하는 구조가 아니라, 이미 존재하는 복구 이력이 남는 것이다.

보호 정책 없이 Cloud Backup을 쓰는 경우에는 종료 화면에서 기존 스냅샷 유지 여부를 별도로 선택한다. Cloud Backup이 꺼져 있으면 그 선택 자체가 없다. 따라서 모든 Atlas 종료가 자동으로 백업을 보관한다는 식으로 운영 절차를 기억하면 서로 다른 경우를 섞게 된다.

남은 스냅샷은 관리 조직에도 흔적을 남긴다. 보호 정책 아래에서는 스냅샷이 존재하는 프로젝트를 삭제할 수 없다. 모든 프로젝트를 제거하지 못하면 조직도 삭제할 수 없다. 문서는 종료된 클러스터의 이름을 스냅샷 식별에 사용하므로 같은 이름의 클러스터를 새로 만들 수 없다고도 설명한다. 퇴역 계획에는 계산 자원을 끄는 날 외에 기록의 보존 일정과 식별자를 다룰 일이 남는다.

활성 클러스터 시간에 대한 요금과 남은 백업 저장 요금은 각각의 대상에 붙는다. 백업이 남아 있다는 사실을 꺼진 클러스터의 컴퓨트 요금이 계속된다는 말로 바꾸면 계산이 틀어진다.

비어 있는 프로젝트의 정의가 더 엄격하다

정책 해제에는 지정된 보안·법무 담당자가 지원 요청을 내고 검증 절차를 거쳐 MongoDB Support의 승인을 받는 경로가 있다. 승인 뒤에는 프로젝트 소유자가 정책을 끌 수 있다. 화면의 소유자 역할과 정책 해제를 요청할 자격이 같은 것은 아니다.

예외도 구체적이다. 활성 클러스터도, 일시 중지된 클러스터도, 종료된 클러스터의 보관 스냅샷도 없는 빈 프로젝트에서는 조직 또는 프로젝트 소유자가 정책을 해제할 수 있다. 운영 목록에서 클러스터가 사라졌다는 이유만으로 이 예외를 사용할 수는 없다. 남은 기록까지 확인해야 한다.

담당자의 연락처 역시 이 통제의 일부다. 정책 설정 화면은 지정 담당자의 이름과 이메일을 받으며 지원 포털에 쓰는 주소를 요구한다. 잘못된 주소는 Support와 수정해야 한다. 사람이 퇴사한 뒤에도 직함만 남아 있는 주소록이라면, 회사가 스스로 정한 절차를 이어 갈 사람이 누구인지부터 정리해야 한다. 문서에는 특정 고객의 지원 지연이나 요청 거절에 대한 자료가 없다.

보관 중이라는 표시만으로는 부족하다

백업 일정 문서에는 추가 스냅샷 보존이 나온다. 보호 기간이 끝난 뒤에도 사본을 더 오래 둘 수 있는 기능이다. 이 추가 기간에는 적절한 역할을 가진 사용자가 스냅샷을 삭제할 수 있고, 기간이 끝나면 Atlas가 자동으로 삭제한다.

오래 남긴 백업이 전부 같은 강도로 보호되는 것은 아니다. 기업이 전체 보존 일수만 보고 “그동안은 누구도 삭제할 수 없다”고 생각하면, 보존은 이어지지만 보호는 끝나는 날짜를 놓친다. 더 긴 보관을 산 조직이 더 긴 삭제 방지를 샀다고 보고할 수도 있다. 대시보드에는 두 날짜가 따로 필요하다.

일정이 겹칠 때도 단순 합산은 맞지 않는다. MongoDB가 제시한 예처럼 일일 스냅샷은 이틀, 토요일 주간 스냅샷은 3주 보존하도록 정해 같은 스냅샷이 만들어지면 더 긴 주간 기준을 따른다. 이 예의 3주는 모든 프로젝트의 기본값이 아니라 일정이 겹쳤을 때의 처리 방식이다.

스냅샷 개수에 단가를 곱하면 틀리는 이유

전용 클러스터 백업 요금 설명에 따르면 일반 Cloud Backups는 대체로 증분 방식이며 저장 사업자의 보고값과 리전별 저장량을 바탕으로 계산한다. 월 GB 기준 요금을 일별 GB-day 항목으로 보여 주는 것은 같은 비용을 중복 청구하는 방식이 아니다. 지속적 백업에는 스냅샷과 내부 작업 기록을 함께 계산하는 별도 요율이 적용된다.

일부 구성 변경이나 장애 조치, 기반 클라우드 유지보수 등으로 완전한 스냅샷이 여러 개 필요해질 수 있다. 반대로 스냅샷 하나를 없애도 다른 스냅샷이 참조하는 데이터는 계속 남는다. 개수 감소와 비용 감소의 비율을 같게 놓을 근거가 없다. 구체적인 지출을 계산하려면 청구 대상 저장량, 리전, 보존 날짜와 적용 요율이 필요하다.

이 제품의 상업적 약속은 선명하다. 회사가 과거를 지우기 어렵게 만들어 준다. 그 약속을 제대로 산 회사라면 보안 담당자의 확인 옆에, 보존 기간 동안 비용과 기록을 맡을 사람의 이름도 적어 둘 것이다.