데이터 백업을 다룬 웹사이트 중에는 제품 비교표나 벤치마크 대신 짧은 우화 한 편으로 이야기를 여는 곳이 있다. 'The Tao of Backup'은 한 초심자가 백업의 도를 배우고 싶어 하자, 스승이 "깨달음을 얻으려면 백업의 일곱 가지 머리를 익혀야 한다. 그 머리들을 아는 자는 자신의 데이터를 영원히 지킬 것"이라고 답하는 장면으로 시작한다. 기술 문서라기보다 선문답에 가까운 이 도입부는 일부러 추상적이다. 구체적인 명령어나 솔루션 이름을 앞세우지 않고, 백업을 하나의 수양 과정으로 바라보게 만든다는 점에서 지금 읽어도 신선하다.
이 우화가 겨냥하는 지점은 분명하다. 대부분의 조직은 '백업을 하고 있는가'라는 질문에는 이미 "그렇다"고 답할 수 있다. 야간 스케줄러가 돌고, 스토리지 어딘가에 사본이 쌓인다. 문제는 그 다음이다. 정작 데이터를 잃는 사고의 상당수는 백업이 아예 없어서가 아니라, 백업이 있다고 믿었던 것이 실제로는 조건을 충족하지 못했기 때문에 발생한다. 스승이 '하나의 머리'가 아니라 '일곱 개의 머리'를 말한 이유가 여기에 있다. 백업은 단일 행위가 아니라 여러 조건이 동시에 성립해야 의미를 갖는 복합적인 상태라는 선언인 셈이다.
일곱 개의 머리가 암시하는 것
이 우화의 전통적인 해석에서 일곱 가지 축은 흔히 다음과 같이 정리된다. 어떤 데이터를 빠짐없이 담고 있는가(범위), 얼마나 자주 받는가(주기), 원본과 물리적으로 떨어뜨려 두었는가(분리), 과거 시점으로 되돌아갈 수 있는가(이력), 실제로 복구해 봤는가(테스트), 사본 자체가 안전하게 보관되는가(보안), 그리고 복원한 데이터가 손상 없이 온전한가(무결성)이다. 각 항목은 독립적이면서도 서로를 떠받친다. 아무리 자주 백업해도 범위에서 핵심 데이터베이스가 빠져 있으면 소용이 없고, 범위가 완벽해도 복구를 한 번도 시험해 보지 않았다면 그 사본이 쓸모 있는지는 사고가 난 뒤에야 알게 된다.
특히 '분리'와 '테스트'는 실무에서 가장 쉽게 무너지는 축이다. 분리는 원본과 사본이 같은 서버, 같은 랜섬웨어의 사정권, 같은 전원 계통 안에 있으면 성립하지 않는다. 테스트는 복구 리허설을 정기 업무에 넣지 않으면 늘 '언젠가 할 일'로 밀려난다. 우화가 굳이 복구 가능 여부를 별도의 머리로 세운 것은, 백업의 목적이 사본을 만드는 것이 아니라 복원에 있다는 당연한 사실을 자주 잊기 때문이다.
한국 실무 환경에 놓고 보면
이 원칙들은 오늘날의 운영 환경과 그대로 맞물린다. 랜섬웨어는 네트워크에 연결된 백업까지 함께 암호화하므로 오프라인 또는 불변(immutable) 사본이라는 '분리'의 현대적 변형을 요구한다. 규제와 감사 대응은 특정 과거 시점의 데이터를 꺼낼 수 있어야 한다는 '이력'의 문제다. 클라우드로 옮겨가면 사본이 늘어난 듯 보이지만, 동일 리전·동일 계정 안에만 머문다면 분리 조건을 충족한 것이 아니다. 업계에서 널리 쓰이는 3-2-1 원칙처럼 구체적인 지침들도 결국 이 우화가 던진 질문의 변주에 가깝다.
다만 이 글이 우화라는 점은 장점이자 한계다. 어떤 도구를 어떤 주기로, 어떤 암호화 방식과 보존 기간으로 운영해야 하는지 같은 실행 수준의 답은 담겨 있지 않다. 복구 목표 시간(RTO)이나 목표 시점(RPO) 같은 수치화된 기준, 비용과 성능의 절충도 각자의 몫으로 남는다. 그럼에도 이 오래된 비유가 여전히 인용되는 이유는, 백업을 '설정해 두고 잊는 자동화'가 아니라 주기적으로 점검해야 할 체크리스트로 되돌려 놓기 때문이다. 담당자가 스스로에게 일곱 개의 질문을 던지고 그중 하나라도 자신 있게 답하지 못한다면, 그 지점이 바로 다음 장애에서 데이터를 잃을 자리라는 경고를 이 짧은 우화는 담담하게 전한다.