클라우드 기반이라고 해서 데이터가 절대 안전하다고 생각하는 것은 큰 오산입니다. 실제로 실수로 데이터를 삭제하거나, 잘못된 수식으로 전체 시트를 망가뜨린 경험이 있는 분들이 많습니다. 구글 시트는 기본적으로 버전 기록 기능을 제공하지만, 이것만으로는 완벽한 백업 체계라고 할 수 없습니다. 체계적인 백업 시스템을 구축하면 언제든 이전 상태로 복원할 수 있고, 중요한 데이터 손실을 방지할 수 있습니다. 이 글에서는 구글 드라이브 버전 관리 활용법, 앱스 스크립트 자동 백업 코드 작성, 그리고 백업 복원 프로세스 설계를 다루겠습니다. 다양한 기업 환경에서 백업 시스템을 구축하며 얻은 실전 노하우를 바탕으로, 누구나 따라할 수 있도록 단계별로 안내하겠습니다. 데이터는 기업의 자산이며, 백업은 선택이 아닌 필수입니다.
구글 드라이브 버전 관리 활용법
구글 시트의 가장 기본적인 백업 기능은 버전 기록입니다. 파일 메뉴에서 버전 기록을 선택하면 과거의 모든 편집 내역을 시간순으로 확인할 수 있습니다. 구글은 자동으로 변경사항을 저장하며, 특히 중요한 시점에는 수동으로 이름이 지정된 버전을 만들 수 있습니다. 예를 들어 월말 결산 후 최종 확정본이라는 이름으로 버전을 저장해두면, 나중에 해당 시점으로 쉽게 돌아갈 수 있습니다. 버전 기록의 장점은 별도의 파일을 생성하지 않고도 과거 상태를 조회할 수 있다는 점입니다. 각 버전을 클릭하면 당시의 시트 상태가 미리보기로 표시되며, 필요하다면 해당 버전으로 복원하거나 사본을 만들 수 있습니다. 하지만 버전 기록에도 한계가 있습니다. 보관 기간이 무제한은 아니며, 구글의 정책에 따라 오래된 버전은 자동으로 삭제될 수 있습니다. 또한 파일 자체가 삭제되면 버전 기록도 함께 사라집니다. 따라서 중요한 데이터는 추가적인 백업 전략이 필요합니다. 구글 드라이브의 휴지통 기능도 활용해야 합니다. 실수로 파일을 삭제했다면 30일 이내에 휴지통에서 복구할 수 있습니다. 하지만 휴지통을 비우거나 30일이 지나면 영구 삭제되므로, 정기적으로 중요 파일의 백업 사본을 만들어두는 습관이 중요합니다. 사본 만들기 기능을 활용하면 현재 시트의 완전한 복사본이 생성됩니다. 이때 파일명에 날짜를 포함시키면 백업 시점을 명확히 알 수 있습니다. 예를 들어 매출관리_2025년10월18일_백업 같은 형식으로 저장하면 나중에 찾기도 쉽고, 여러 백업 파일을 시간순으로 정리할 수 있습니다. 공유 설정도 백업의 중요한 요소입니다. 백업 파일은 원본과 동일한 권한으로 공유되지 않도록 주의해야 하며, 특히 민감한 데이터의 경우 백업 폴더는 관리자만 접근할 수 있도록 권한을 제한해야 합니다.
앱스 스크립트 자동 백업 코드 작성
수동 백업은 번거롭고 잊어버리기 쉽기 때문에, 자동화가 필수적입니다. 구글 앱스 스크립트를 활용하면 원하는 주기로 자동 백업이 가능합니다. 스크립트 편집기를 열고 새 프로젝트를 시작하면 됩니다. 기본적인 백업 스크립트는 현재 스프레드시트를 복사하여 지정된 폴더에 저장하는 방식입니다. SpreadsheetApp.getActiveSpreadsheet 메서드로 현재 시트를 가져온 후, makeCopy 메서드로 사본을 생성합니다. 이때 파일명에 타임스탬프를 추가하면 각 백업을 구분할 수 있습니다. Utilities.formatDate 함수를 사용하면 현재 날짜와 시간을 원하는 형식으로 변환할 수 있습니다. 백업 파일은 특정 폴더에 정리되어야 관리가 편리합니다. DriveApp.getFolderById 메서드로 대상 폴더를 지정하고, 생성된 사본을 해당 폴더로 이동시킵니다. 폴더 ID는 구글 드라이브에서 폴더를 열었을 때 URL에 포함된 긴 문자열입니다. 자동 실행을 위해서는 트리거 설정이 필요합니다. 스크립트 편집기의 시계 아이콘을 클릭하면 트리거 관리 화면이 나타나며, 여기서 실행 함수와 주기를 설정할 수 있습니다. 매일 자정에 실행되도록 설정하면 매일 자동으로 백업이 생성됩니다. 더 고급 기능으로는 오래된 백업 파일을 자동 삭제하는 로직도 추가할 수 있습니다. 백업이 계속 쌓이면 드라이브 용량을 차지하므로, 30일 이상 된 백업은 자동으로 삭제하는 코드를 작성하면 효율적입니다. 폴더 내 파일을 순회하면서 생성일을 확인하고, 기준 날짜보다 오래된 파일은 setTrashed 메서드로 휴지통으로 보냅니다. 백업 성공 여부를 이메일로 알림받는 기능도 유용합니다. MailApp.sendEmail 메서드를 사용하면 백업이 완료되었을 때 관리자에게 자동으로 메일을 발송할 수 있습니다. 백업 실패 시에도 즉시 알림을 받을 수 있도록 try-catch 구문으로 오류를 처리하고, 오류 발생 시 별도의 알림 메일을 보내도록 설정하면 안정성이 높아집니다.
백업 복원 프로세스 설계
백업을 만드는 것만큼 중요한 것이 복원 절차입니다. 데이터 손실이 발생했을 때 당황하지 않고 신속하게 대응할 수 있도록 명확한 프로세스가 필요합니다. 첫 번째 단계는 손실 범위 파악입니다. 전체 파일이 삭제되었는지, 특정 시트만 문제가 있는지, 일부 데이터만 변경되었는지를 먼저 확인해야 합니다. 범위에 따라 복원 방법이 달라집니다. 소규모 변경이라면 버전 기록에서 직접 복원하는 것이 가장 빠릅니다. 파일 메뉴의 버전 기록에서 문제가 발생하기 전 시점을 찾아 복원하면 됩니다. 하지만 특정 시트만 복원하고 싶다면 백업 파일을 열어 해당 시트를 복사한 후, 원본 파일에 붙여넣는 방식이 효율적입니다. 대규모 손실이라면 백업 파일로 완전히 대체해야 합니다. 이때 주의할 점은 공유 설정과 스크립트 연결입니다. 단순히 백업 파일을 열어서 사용하면 원본 파일과 연결된 스크립트나 외부 연동이 끊어질 수 있습니다. 따라서 원본 파일의 내용을 모두 삭제하고 백업 파일의 내용을 복사해서 붙여넣는 방식이 안전합니다. 복원 후에는 반드시 검증 절차를 거쳐야 합니다. 주요 수식이 정상 작동하는지, 데이터 범위가 올바른지, 차트와 피벗 테이블이 제대로 연결되어 있는지 확인해야 합니다. 특히 다른 시트나 외부 파일을 참조하는 수식은 복원 후 연결이 끊어질 수 있으므로 세심한 확인이 필요합니다. 복원 이력도 문서화해야 합니다. 언제 어떤 문제가 발생했고, 어떤 백업을 사용해 복원했는지 기록해두면 향후 유사한 상황에 대응하기 쉽습니다. 별도의 복원 로그 시트를 만들어 날짜, 담당자, 복원 사유, 사용한 백업 파일명 등을 기록하는 것을 권장합니다. 팀 단위로 사용하는 시트라면 복원 권한도 명확히 정해야 합니다. 모든 사용자가 마음대로 복원할 수 있으면 혼란이 발생하므로, 관리자나 책임자만 복원할 수 있도록 규정을 만들고 교육하는 것이 중요합니다.