사내 백업 솔루션을 한 달 복구 테스트해봤더니

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

백업은 있는데 복구가 안 되는 회사의 공통점

파일은 쌓였지만, 복구 절차는 비어 있었습니다

사내 백업 솔루션을 도입했다고 해서 데이터 보호가 끝난 것은 아닙니다. 실제로 한 달 동안 복구 테스트를 해보니 가장 자주 드러난 문제는 백업 성공률이 아니라 복구 가능성이었습니다. 관리자 화면에는 초록색 성공 표시가 떠 있는데, 막상 특정 시점의 파일을 꺼내려 하면 권한, 경로, 버전, 보관 기간이 서로 맞지 않아 시간이 늘어지는 경우가 많았습니다.

특히 중소기업이나 성장 단계의 조직에서는 백업을 ‘보험’처럼 생각하다가 실제 사고가 난 뒤에야 절차의 빈틈을 확인합니다. 랜섬웨어, 실수 삭제, 장비 장애, 퇴사자 계정 정리 같은 사건은 갑자기 오지만, 복구는 갑자기 잘되지 않습니다. IT의 기본 개념이 정보 처리와 활용 전반을 다룬다는 점을 떠올리면, 백업도 단순 저장이 아니라 업무 연속성을 지키는 운영 체계에 가깝습니다.

이번 점검에서 가장 인상적이었던 장면은 회계팀 공유 폴더 일부를 되살리는 테스트였습니다. 백업 파일은 있었지만 폴더 구조가 바뀐 뒤라 담당자가 찾는 파일명과 실제 저장 경로가 달랐습니다. 결국 IT 담당자가 로그를 뒤지고, 사용자에게 대략적인 작업 시간을 물어보고, 여러 복구 지점을 열어 비교해야 했습니다. 백업 솔루션은 작동했지만, 복구 경험은 매끄럽지 않았던 셈입니다.

• 백업 성공 알림만 믿는 실수: 백업 작업이 완료됐다는 메시지는 저장이 끝났다는 뜻이지, 원하는 시점과 권한으로 바로 복구된다는 보장은 아닙니다.
• 중요 데이터 기준이 모호한 문제: 모든 데이터를 같은 주기로 백업하면 비용은 늘고, 정작 핵심 데이터의 복구 우선순위는 흐려집니다.
• 담당자 개인 기억에 의존: 어느 서버에 어떤 업무 데이터가 있는지 한 사람만 알고 있다면, 휴가나 퇴사 시 복구 시간이 크게 늘어납니다.
• 복구 테스트 생략: 백업 솔루션을 도입한 뒤 실제 파일, DB, 가상머신을 복원해보지 않으면 장애 대응 문서는 장식이 됩니다.

팁: 백업 솔루션을 고를 때는 저장 용량보다 먼저 ‘원하는 파일을 누가, 몇 분 안에, 어떤 권한으로 되살릴 수 있는가’를 질문해야 합니다.

한 달 테스트에서 발견한 고장 원인

백업 실패의 원인은 생각보다 화려하지 않았습니다. 대부분은 에이전트 미설치, 저장소 용량 초과, 네트워크 경로 변경, 계정 권한 만료처럼 일상적인 운영 이슈였습니다. 하지만 이 작은 원인이 누적되면 장애 당일에는 큰 문제로 바뀝니다. 특히 클라우드 저장소와 온프레미스 서버를 함께 쓰는 환경에서는 데이터 위치가 분산되어, 어느 솔루션이 어떤 범위까지 보호하는지 먼저 정리해야 합니다.

한 달 동안 매주 복구 시나리오를 바꿔보니, 단순 파일 복구보다 더 까다로운 것은 업무 단위 복구였습니다. 예를 들어 영업팀의 견적서 폴더는 파일만 되살리면 끝나는 것처럼 보이지만, 실제로는 CRM 내 첨부 기록, 승인 메일, 전자계약 파일과 연결됩니다. 이때 IT 서비스 운영 관점이 필요합니다. 데이터 하나가 어느 업무 흐름에 묶여 있는지 알아야 복구 후 사용자 혼란을 줄일 수 있습니다.

1. 1단계: 보호 대상 목록 작성 - 서버, NAS, SaaS, 임직원 PC, 데이터베이스를 구분하고 각 항목의 업무 담당 부서를 적습니다.
2. 2단계: 복구 목표 설정 - RPO는 어느 시점까지 되돌릴지, RTO는 몇 분 또는 몇 시간 안에 복구할지 정합니다.
3. 3단계: 실제 복구 실행 - 샘플 파일이 아니라 최근 업무 파일, 권한이 걸린 폴더, 퇴사자 계정 데이터를 포함해 테스트합니다.
4. 4단계: 사용자 확인 - IT팀 기준으로 열리는 파일이라도 실무자가 찾는 형태와 다를 수 있으니 부서 확인을 받습니다.

백업 솔루션 선택보다 먼저 해야 할 복구 설계

가격표보다 업무 흐름을 먼저 봐야 합니다

백업 솔루션 비교를 시작하면 자연스럽게 월 비용, 저장 용량, 압축률, 클라우드 지원 여부에 눈이 갑니다. 물론 비용은 중요합니다. 국내 기업 환경에서 소규모 파일 서버와 PC 일부만 보호한다면 월 수만 원대부터 시작할 수 있고, 서버 이미지 백업, DB 백업, 장기 보관, 랜섬웨어 격리 저장소까지 포함하면 월 수십만 원에서 수백만 원대로 올라갈 수 있습니다. 문제는 가격이 비싸다고 우리 회사 복구 속도가 자동으로 빨라지지는 않는다는 점입니다.

좋은 IT 솔루션은 기능이 많은 제품이 아니라, 조직의 업무 흐름에 맞게 운영되는 제품입니다. 예를 들어 디자인 파일을 다루는 팀은 대용량 파일의 증분 백업 효율이 중요하고, 콜센터는 녹취 파일 보관 기간과 검색 속도가 중요합니다. 회계팀은 월말과 분기 마감 시점의 복구 지점이 중요하고, 개발팀은 소스 저장소와 배포 설정의 일관성이 중요합니다. 같은 백업 솔루션이라도 부서별 복구 질문은 완전히 다릅니다.

여기서 ‘백업 주기’를 단순히 하루 한 번으로 정하면 애매해집니다. 오전에 작성한 견적서가 오후에 삭제됐는데 전날 밤 백업만 있다면, 사용자는 백업이 없다고 느낍니다. 반대로 모든 파일을 5분마다 백업하면 저장소 비용과 네트워크 부하가 커집니다. 따라서 핵심은 모든 데이터를 똑같이 보호하는 것이 아니라, 데이터의 중요도와 변경 빈도에 따라 보호 수준을 나누는 것입니다.

• 핵심 업무 데이터: 계약서, 회계 자료, 고객 정보, 운영 DB처럼 손실 시 매출과 법적 책임에 영향을 주는 데이터입니다. 짧은 주기와 별도 보관이 필요합니다.
• 협업 데이터: 문서, 기획안, 디자인 시안처럼 자주 수정되는 파일입니다. 버전 관리와 사용자 셀프 복구 기능이 있으면 문의가 줄어듭니다.
• 보관성 데이터: 오래된 로그, 완료 프로젝트, 아카이브 자료입니다. 빠른 복구보다 저렴한 장기 보관과 검색 가능성이 중요합니다.
• 개인 장비 데이터: 임직원 PC의 바탕화면, 다운로드 폴더, 로컬 작업 파일입니다. 정책 없이 방치하면 퇴사와 장비 교체 때 문제가 됩니다.

복구 시나리오를 표로 만들면 선택 기준이 선명해집니다

솔루션 검토 회의에서 “안전한가요?”라고 묻는 대신, “이 사고가 났을 때 어떻게 되나요?”라고 물어보면 대화가 훨씬 구체적으로 바뀝니다. 아래처럼 복구 시나리오를 표로 만들면 기술 담당자와 현업 담당자가 같은 화면을 보며 우선순위를 정할 수 있습니다.

이 표를 만들고 나면 제품 설명서에서 봐야 할 항목도 달라집니다. 단순히 “클라우드 백업 지원”이라고 적혀 있어도 실제로는 특정 SaaS의 메일만 지원하고 드라이브 권한은 지원하지 않을 수 있습니다. 또는 서버 이미지는 백업하지만 데이터베이스 트랜잭션 일관성은 별도 설정이 필요할 수 있습니다. 그래서 도입 전 데모에서는 예쁜 대시보드보다 복구 버튼을 누른 뒤 어떤 선택지가 나오는지를 끝까지 봐야 합니다.

현장 조언: 백업 솔루션 데모를 볼 때는 공급사에 “어제 오후 3시 20분 파일을 다른 폴더로 복구해 주세요”처럼 구체적인 요청을 던져보세요. 답변 속도와 절차가 실제 운영 난이도를 보여줍니다.

또 하나 놓치기 쉬운 부분은 보안과 백업의 경계입니다. 백업 저장소가 운영망과 같은 계정으로 열려 있으면 공격자가 운영 데이터와 백업 데이터를 함께 암호화할 수 있습니다. 따라서 관리자 계정 분리, 다중 인증, 변경 불가 저장소, 오프라인 또는 격리 보관 정책을 함께 봐야 합니다. 정보기술 관련 설명에서도 기술은 도구 자체보다 활용 체계와 맞물릴 때 의미가 커집니다. 백업 역시 보안, 운영, 비용이 함께 설계되어야 효과가 납니다.

1. 질문 1: 랜섬웨어 감염 후 백업 파일 자체가 변조되지 않았음을 어떻게 확인합니까?
2. 질문 2: 특정 사용자 권한까지 포함해 복구할 수 있습니까, 아니면 파일 내용만 복구됩니까?
3. 질문 3: 복구 테스트 리포트를 자동으로 남기고 감사 자료로 활용할 수 있습니까?
4. 질문 4: 저장소 용량 초과 시 백업이 중단됩니까, 오래된 백업을 자동 정리합니까?
5. 질문 5: 퇴사자 계정, 외주 계정, 임시 프로젝트 폴더는 어떤 정책으로 보존합니까?

복구 훈련을 해보니 자동화만으로는 부족했습니다

자동 백업은 시작점이고, 운영 습관이 성패를 갈랐습니다

한 달간 복구 테스트를 하며 가장 크게 바뀐 생각은 “자동화가 많을수록 안전하다”는 믿음이었습니다. 자동 백업은 분명 필요합니다. 하지만 알림을 읽는 사람, 실패를 조치하는 기준, 복구 요청을 접수하는 창구, 현업 확인 방식이 없으면 자동화는 조용히 실패합니다. 특히 야간 백업 실패 알림이 여러 시스템 알림에 묻히면, 담당자는 다음 장애가 나기 전까지 문제를 모를 수 있습니다.

운영이 잘되는 조직은 백업 솔루션 화면을 매일 오래 들여다보지 않았습니다. 대신 알림 기준이 명확했습니다. 예를 들어 핵심 서버 백업 1회 실패는 즉시 확인, 일반 파일 서버 백업 2회 연속 실패는 티켓 생성, 장기 보관 저장소 80% 도달 시 비용 검토처럼 행동으로 이어지는 기준이 있었습니다. 이것이 없는 조직은 알림은 많지만 책임은 흐려지는 패턴이 반복됐습니다.

또한 포스트 코로나 이후 원격근무와 분산 협업이 자리 잡으면서 데이터는 사무실 서버 안에만 있지 않습니다. 개인 노트북, SaaS, 협업 도구, 클라우드 드라이브가 얽혀 있습니다. 변화한 업무 환경에 대한 배경은 포스트 코로나 설명에서도 확인할 수 있습니다. 원격 업무가 늘어난 조직이라면 백업 범위가 사무실 장비에 갇혀 있지 않은지 먼저 살펴봐야 합니다.

• 월 1회 복구 리허설: 핵심 파일, 부서 폴더, 서버 이미지 중 하나를 골라 실제로 복구합니다. 성공 여부보다 걸린 시간과 막힌 지점을 기록합니다.
• 분기별 권한 점검: 백업 관리자, 읽기 전용 감사 계정, 현업 셀프 복구 권한을 분리하고 퇴사자 권한을 제거합니다.
• 반기별 비용 점검: 중복 백업, 오래된 보관 정책, 필요 이상으로 빠른 스토리지를 정리해 비용을 낮춥니다.
• 장애 후 리뷰: 복구가 빨랐는지보다 사용자가 업무를 재개하는 데 무엇이 걸림돌이었는지 확인합니다.

모든 데이터를 지키려는 전략이 오히려 위험할 때

반대 의견도 있습니다. “그래도 모든 데이터를 최대한 자주 백업하면 좋은 것 아닌가요?”라는 질문입니다. 얼핏 맞는 말처럼 들리지만, 실제 운영에서는 비용과 복잡도가 빠르게 올라갑니다. 중요하지 않은 임시 파일까지 고빈도로 백업하면 저장소 비용이 늘고, 복구 화면에서 필요한 데이터를 찾는 시간이 길어집니다. 백업이 많아질수록 복구가 쉬워지는 것이 아니라, 분류가 없으면 더 어려워질 수 있습니다.

그래서 G2프로 같은 IT 전문 서비스 관점에서는 백업 솔루션을 제품 하나로 보지 않고, 업무 중요도 분류, 보안 정책, 복구 훈련, 비용 관리가 결합된 솔루션으로 봅니다. 도입 초기에는 완벽한 체계를 만들기보다 핵심 업무 세 가지를 정해 작게 시작하는 편이 효과적입니다. 예를 들어 회계 자료, 고객 계약 파일, 운영 서버 설정부터 복구 테스트를 반복하면 조직이 백업의 언어를 익히게 됩니다.

마지막으로 고려할 다른 관점은 ‘백업하지 않을 데이터’를 정하는 일입니다. 임시 렌더링 파일, 재생성 가능한 캐시, 보관 기한이 지난 개인정보, 중복 다운로드 파일은 무조건 보호 대상이 아닐 수 있습니다. 오히려 불필요한 데이터를 오래 들고 있으면 비용과 보안 부담이 커집니다. 백업 전략은 많이 저장하는 경쟁이 아니라, 장애가 났을 때 회사가 다시 움직이는 데 필요한 데이터를 정확히 남기는 기술입니다.

1. 먼저 버릴 데이터부터 정합니다. 재생성 가능한 파일과 법적으로 오래 보관하면 안 되는 데이터를 구분하면 저장소가 가벼워집니다.
2. 그다음 반드시 살릴 데이터를 정합니다. 매출, 고객, 계약, 운영, 인증과 연결된 데이터는 별도 등급으로 묶습니다.
3. 복구 담당자를 한 명으로 고정하지 않습니다. 최소 2명 이상이 절차를 실행할 수 있어야 야간 장애나 휴가 기간에도 대응됩니다.
4. 솔루션 변경 가능성을 열어둡니다. 백업 제품은 바꿀 수 있지만, 데이터 등급표와 복구 시나리오는 조직 자산으로 남습니다.

백업 솔루션을 한 달 동안 복구 중심으로 써보면, 제품의 장단점보다 조직의 습관이 더 또렷하게 보입니다. 어떤 회사는 저렴한 도구로도 빠르게 복구하고, 어떤 회사는 고가 솔루션을 쓰면서도 파일 하나 찾는 데 반나절을 씁니다. 차이는 대개 기능 수가 아니라 질문의 품질에서 갈립니다. “백업됐나요?”에서 멈추지 않고 “누가, 언제, 무엇을, 어디로, 얼마나 빨리 되살리나요?”까지 묻는 순간 IT 서비스의 수준이 달라집니다.