정보처리기사로 이해하는 데이터 백업과 동기화, 파일을 삭제했을 때 어떤 차이가 있을까?
파일 삭제 결과가 달라지는 핵심 이유
동기화는 상태를 맞추고 백업은 과거 사본을 남긴다
질문에 먼저 답하면, 동기화 폴더에서 파일을 삭제하면 그 삭제도 하나의 변경 사항으로 취급되어 클라우드와 다른 연결 장치에 전달될 수 있다. 반대로 원본과 분리해 둔 백업 사본은 원본의 현재 상태를 즉시 따라가도록 만든 저장소가 아니므로, 삭제 이전 시점의 사본이 남아 있다면 복원에 사용할 수 있다. 화면에 같은 파일이 두 군데 보인다고 해서 둘 다 백업인 것은 아니다. 두 위치가 같은 계정과 동기화 규칙으로 묶여 있다면 실질적으로 하나의 작업 상태를 여러 장소에서 보여 주는 것에 가깝다.
동기화의 목적은 편의성과 일관성이다. 노트북에서 문서를 수정하면 데스크톱과 휴대전화에서도 최신 내용을 열 수 있고, 공동 작업자는 같은 버전을 확인할 수 있다. 이 장점 때문에 이름 변경, 덮어쓰기, 폴더 이동, 삭제도 빠르게 반영된다. 백업의 목적은 장애나 실수 이전 상태로 돌아가는 것이다. 백업 프로그램은 정해진 주기에 사본을 만들고, 여러 시점의 버전을 보존하거나 원본에서 직접 수정하기 어려운 저장소에 기록한다. 따라서 백업 여부는 저장 위치의 개수가 아니라 변경과 삭제가 어떤 규칙으로 전파되는지로 판단해야 한다.
정보처리기사 관점에서는 이를 가용성과 복구 가능성의 차이로 볼 수 있다. 동기화는 여러 장치에서 현재 파일을 이용할 가능성을 높이지만, 잘못된 현재 상태까지 빠르게 복제할 수 있다. 백업은 평소 작업 속도를 높이는 기능이 아니라 데이터 손실 이후의 복구 지점을 제공한다. 휴지통이나 버전 기록이 있는 동기화 서비스는 사고를 완화해 주지만, 보존 기간과 대상, 계정 권한, 관리자 정책에 제한을 받는다. 그래서 중요한 파일은 동기화만 믿지 않고 별도 백업을 함께 두어야 한다.
동기화는 최신 상태를 공유하는 기능이고, 백업은 이전 상태로 돌아갈 독립된 사본을 확보하는 절차다.
PC·클라우드·외장드라이브를 가상으로 구성하기
세 저장 위치가 실제로 맡는 역할을 구분하는 방법
가상 사례를 하나 만들어 보자. 노트북의 ‘업무’ 폴더에는 매일 수정하는 문서가 있고, 이 폴더는 클라우드 서비스와 양방향으로 동기화된다. 외장드라이브에는 백업 프로그램이 하루에 한 번 ‘업무’ 폴더의 사본을 기록하며, 작업이 끝난 뒤에는 드라이브를 분리한다고 가정한다. 여기서 노트북 파일은 원본 작업본, 클라우드 파일은 동기화된 현재본, 외장드라이브 파일은 특정 시점의 복구용 사본이다. 파일 이름이 같아도 세 사본의 목적과 변경 규칙은 서로 다르다.
오전 9시에 보고서를 만들고 10시에 수정하면 노트북과 클라우드는 잠시 후 같은 최신 내용을 갖게 된다. 낮 12시에 실수로 보고서를 삭제하면 동기화가 켜진 환경에서는 삭제가 클라우드와 다른 장치로 전파될 수 있다. 하지만 전날 밤 백업한 외장드라이브가 분리되어 있었다면 낮 12시의 삭제 명령을 받지 않는다. 복원할 때는 외장드라이브의 사본을 새 위치에 먼저 복사하고 내용과 날짜를 확인한 뒤 작업 폴더로 되돌리는 편이 안전하다. 곧바로 같은 이름으로 덮어쓰면 남아 있던 최신본을 잃을 수 있기 때문이다.
- 노트북: 사용자가 직접 수정하는 현재 작업본
- 클라우드 동기화: 여러 장치에서 현재 상태를 맞추는 공간
- 외장드라이브 백업: 정해진 시점의 사본을 따로 보관하는 공간
- 복원 폴더: 되돌리기 전에 사본의 내용과 무결성을 확인하는 임시 위치
다만 외장드라이브에 파일을 수동으로 끌어다 놓은 것만으로 항상 좋은 백업이 되는 것은 아니다. 덮어쓰기만 반복하면 과거 버전이 사라지고, 드라이브를 계속 연결해 두면 악성코드나 사용자 실수의 영향을 함께 받을 수 있다. 자동 백업을 쓰더라도 포함 폴더, 제외 확장자, 실행 주기, 실패 알림, 보존 세대 수를 확인해야 한다. 구성도에서 화살표의 방향과 저장소의 연결 상태를 그려 보면 어느 사고가 어디까지 번지는지 훨씬 쉽게 판단할 수 있다.
삭제가 전파되는 과정을 시간순으로 이해하기
동기화 폴더에서 삭제한 뒤 실제로 일어날 수 있는 일
가상 시나리오에서 오후 2시에 노트북의 동기화 폴더에서 파일 하나를 삭제했다고 하자. 먼저 운영체제는 파일을 로컬 휴지통으로 보내거나 삭제 상태로 표시한다. 동기화 프로그램은 폴더의 변화를 감지해 클라우드에 삭제 명령을 전달한다. 서버가 이를 반영하면 같은 계정으로 연결된 다른 PC도 변경 목록을 받아 해당 파일을 제거한다. 다른 PC가 잠시 오프라인이었다고 해서 안전한 백업이 되는 것은 아니다. 다시 온라인이 되는 순간 대기 중인 삭제 정보가 적용될 수 있기 때문이다.
삭제 직후에는 서비스의 휴지통이나 복구 메뉴가 도움이 될 수 있다. 2026년 10월 공개된 Microsoft 안내에서는 동기화된 OneDrive 파일을 장치에서 삭제하면 클라우드와 다른 장치에서도 제거될 수 있고, 웹 휴지통에서 복원할 수 있다고 설명한다. 개인용과 회사·학교용 계정은 휴지통 정책이 서로 다를 수 있다. Google Drive 도움말도 데스크톱용 Drive에서 미러링하거나 스트리밍하는 파일을 휴지통으로 보내면 모든 위치에 그 상태가 반영된다고 안내한다. 반면 Google Photos로 백업한 사진은 별도의 동작 규칙이 적용될 수 있다.
이 비교가 말해 주는 핵심은 ‘클라우드라서 안전하다’가 아니라 ‘해당 기능이 어떤 방식으로 동작하는지 확인해야 한다’는 점이다. 파일 소유자와 공유받은 사용자의 삭제 권한이 다를 수 있고, 기업 계정은 관리자가 버전 기록이나 보존 정책을 바꿀 수 있다. 휴지통을 비우거나 보존 기간이 지나면 일반 사용자가 되돌릴 수 없는 경우도 있다. 사고를 발견하면 무작정 여러 장치에서 파일을 다시 만들기보다 동기화를 일시 중지하고, 웹 휴지통·버전 기록·관리자 복구·독립 백업 순서로 가능한 복구 지점을 확인해야 한다.
- 삭제 사실과 대상 파일을 확인한다.
- 추가 전파와 덮어쓰기를 막도록 동기화 상태를 점검한다.
- 서비스 휴지통과 버전 기록을 먼저 확인한다.
- 없다면 분리된 백업에서 새 위치로 복원해 내용을 검증한다.
버전 기록과 별도 백업은 어떻게 복원을 돕나
한 개의 최신 파일보다 여러 복구 시점이 중요한 이유
백업의 품질은 파일이 존재하는지만으로 판단할 수 없다. 어제 파일, 일주일 전 파일, 월말 파일처럼 여러 시점의 사본을 남기면 삭제뿐 아니라 잘못된 수정과 암호화에도 대응할 수 있다. 예를 들어 보고서의 표가 사흘 전에 잘못 바뀌었는데 오늘 발견했다면, 오늘의 최신본 하나만 복사해 둔 백업은 이미 오류를 포함한다. 반면 날짜별 버전을 보존했다면 변경 전 사본을 찾아 필요한 부분만 되살릴 수 있다. 버전 관리는 시간축을 가진 백업의 중요한 성질이다.
클라우드의 버전 기록도 유용하지만 독립 백업과 완전히 같지는 않다. OneDrive와 SharePoint는 파일의 이전 버전을 확인하고 복원하는 기능을 제공하며, 계정 유형과 관리자 설정에 따라 이용 조건이 달라질 수 있다. Google Drive의 일반 파일 버전은 보존 조건이 있고, Google 문서·스프레드시트·프레젠테이션의 버전 기록은 일반 파일 관리와 방식이 다르다. 따라서 ‘버전 기록이 있다’는 문구만 확인하지 말고 어떤 파일 형식이 대상인지, 몇 개 또는 얼마나 오래 보존되는지, 계정 삭제 시에도 접근 가능한지를 확인해야 한다.
가상 계산으로 복구 목표를 비교해 보자. 하루 한 번 밤 11시에 백업하고 다음 날 오후 5시에 장애를 발견했다면, 최악의 경우 직전 백업 이후 약 18시간 동안의 변경을 다시 만들어야 할 수 있다. 이를 줄이려면 중요한 폴더의 백업 주기를 더 짧게 잡거나, 동기화·자동 저장·정기 백업을 서로 보완적으로 사용한다. 하지만 백업 주기가 짧아질수록 저장 용량과 전송량, 관리 복잡성도 늘어난다. 업무가 허용할 수 있는 데이터 손실 범위와 복구에 쓸 수 있는 시간을 먼저 정한 뒤 주기와 보존 세대를 정하는 것이 합리적이다.
버전 기록은 편리한 복구 수단이지만, 서비스 계정과 정책에서 분리된 백업 사본을 대신한다고 단정할 수 없다.
3-2-1 원칙을 현실적인 구성으로 바꾸기
세 개의 사본·두 종류의 매체·한 개의 외부 보관
3-2-1 백업 원칙은 중요한 데이터에 대해 원본을 포함한 세 개의 사본을 두고, 이를 두 종류의 저장 매체에 나누며, 한 개는 다른 장소에 보관하라는 지침이다. 가상 구성에 적용하면 노트북의 원본이 첫 번째, 외장드라이브의 정기 백업이 두 번째, 별도 클라우드 백업 저장소가 세 번째가 될 수 있다. 여기서 일반 동기화 폴더를 무조건 세 번째 독립 사본으로 계산하면 안 된다. 삭제와 암호화가 그대로 전파되고 과거 버전을 충분히 남기지 않는다면 동일한 장애 영역에 속할 수 있기 때문이다.
두 종류의 매체라는 조건은 같은 외장드라이브에 폴더를 두 개 만든다는 뜻이 아니다. 장치 자체가 고장 나거나 분실되면 두 폴더를 동시에 잃기 때문이다. 내부 저장장치와 외장드라이브, 또는 로컬 저장장치와 접근 제어된 원격 백업처럼 고장 원인이 겹치지 않게 구성해야 한다. 외부 보관 사본은 화재·침수·도난처럼 한 장소 전체에 영향을 주는 사고를 대비한다. 원격 사본도 평상시 사용자 계정에서 바로 삭제할 수 있다면 독립성이 약해지므로, 별도 자격 증명이나 변경 불가 보존 기능 등 접근 구조를 검토한다.
용량을 단순 계산해 보면 판단이 쉬워진다. 가상으로 중요한 데이터가 200GB이고 전체 백업 두 세대를 각각 완전한 사본으로 보관한다면 원본을 제외한 단순 필요 공간은 400GB다. 여기에 매일 5GB씩 바뀌는 데이터를 14일간 증분 보관한다고 가정하면 약 70GB가 추가되지만, 실제 사용량은 중복 제거·압축·파일 변경 방식에 따라 달라진다. 이 수치는 제품 성능이 아니라 구조를 이해하기 위한 가정값이다. 비용만 줄이려고 한 사본에 의존하기보다, 정말 잃으면 곤란한 데이터를 선별하고 보존 기간을 차등화하면 현실적인 구성이 가능하다.
- 3: 원본 한 개와 복구용 사본 두 개
- 2: 같은 고장에 함께 손상되지 않는 서로 다른 저장 방식
- 1: 주 사용 장소 밖에 둔 사본 또는 논리적으로 격리된 원격 사본
- 추가 확인: 실제로 열리고 복원되는지 정기 시험
백업이 있어도 복구하지 못하는 흔한 원인
연결 상태·권한·암호화·검증에서 생기는 실패
가장 흔한 착각은 외장드라이브가 연결되어 있다는 사실만으로 안전하다고 보는 것이다. 계속 연결된 드라이브는 사용자의 삭제 명령, 랜섬웨어의 암호화, 전원 이상에 원본과 함께 영향을 받을 수 있다. 백업이 끝난 뒤 분리하거나, 백업 전용 계정만 쓰기 권한을 가지도록 구성하면 위험을 줄일 수 있다. 클라우드 백업도 같은 로그인 자격 증명으로 즉시 삭제할 수 있다면 계정 탈취에 취약하다. 다중 인증, 최소 권한, 삭제 보호, 관리자 승인 같은 통제를 서비스가 지원하는지 확인해야 한다.
두 번째 실패 원인은 백업 성공 표시만 믿고 복원을 시험하지 않는 것이다. 백업 대상에서 중요한 폴더가 빠졌거나, 저장 공간 부족으로 최근 작업이 중단됐거나, 암호화 키를 잃어 파일을 읽지 못할 수 있다. 분기마다 표본 파일을 골라 별도 폴더에 복원하고 파일이 열리는지, 날짜와 크기가 예상과 맞는지, 필요한 응용프로그램에서 사용할 수 있는지 확인하는 식의 시험이 필요하다. 조직이라면 누가 복원을 승인하고 어떤 순서로 시스템을 되살리는지도 문서화해야 한다.
세 번째는 보존 정책과 개인정보 보호를 함께 보지 않는 경우다. 오래 보관할수록 복구 지점은 늘지만 민감정보의 노출 기간과 저장 비용도 커진다. 백업 파일을 암호화하더라도 키를 백업과 같은 장소에만 두면 장치 분실이나 계정 잠금 때 문제가 생긴다. 반대로 키를 잃으면 정상적인 사용자도 복원할 수 없다. 보존 기간, 폐기 절차, 암호화 키 관리, 접근 기록을 데이터 중요도에 맞게 정해야 한다. 휴지통과 버전 기록은 편리하지만 그 자체를 영구 보관으로 오해해서는 안 된다.
- 백업 작업의 성공·실패 알림을 확인한다.
- 원본과 백업에 동시에 쓰기 가능한 계정을 줄인다.
- 분리된 환경에서 표본 복원을 정기적으로 시험한다.
- 암호화 키와 복구 절차를 백업 데이터와 별도로 관리한다.
정보처리기사 관점의 복구 설계와 최종 점검
도구 이름보다 복구 목표와 운영 절차를 먼저 정하기
정보처리기사 학습에서 데이터 관리, 운영체제, 보안, 시스템 운영을 따로 배우더라도 실무의 백업은 이 요소가 함께 작동하는 절차다. 시스템 운영자나 데이터 관리 담당자는 어떤 파일이 중요한지 분류하고, 장애가 났을 때 어느 시점으로 돌아가야 하는지 정하며, 저장소 권한과 네트워크 연결을 통제한다. 자격증 지식은 개념을 설명하는 바탕이 되지만 실제 복구 능력은 환경별 설정, 기록 확인, 복원 훈련에서 나온다. 특정 동기화 제품을 사용한다고 해서 자동으로 백업 체계가 완성되는 것은 아니다.
개인 사용자라면 먼저 중요한 폴더 목록을 만들고 각 폴더 옆에 원본 위치, 동기화 여부, 백업 위치, 보존 기간을 적어 보자. 그다음 파일 하나를 시험용으로 만들어 수정·삭제·복원 과정을 확인하면 서비스의 실제 동작을 이해할 수 있다. 이때 중요한 원본을 대상으로 위험한 삭제 실험을 할 필요는 없다. 조직에서는 복구 우선순위, 담당자, 승인 절차, 예상 복구 시간, 마지막 성공 백업 시각을 함께 관리한다. 백업 구성은 한 번 설치하고 끝나는 장비가 아니라 계속 점검해야 하는 운영 과정이다.
마지막으로 삭제 사고가 발생했을 때의 판단 순서를 기억하면 된다. 동기화 중이라면 추가 변경을 줄이고, 서비스 휴지통과 버전 기록을 확인하며, 필요한 경우 관리자의 복구 기능을 검토한다. 그곳에 복구 지점이 없다면 분리된 백업에서 원본과 다른 위치로 복원해 무결성을 확인한다. 평상시에는 3-2-1 원칙을 기준으로 사본을 분산하고, 적어도 하나는 일상 작업의 삭제 명령과 악성코드에서 격리한다. 결국 파일 삭제의 결과를 가르는 것은 ‘클라우드인가 외장드라이브인가’가 아니라 삭제 전파 규칙과 독립된 복구 지점의 존재다.
- 동기화 폴더의 삭제가 어디까지 전파되는지 확인했는가
- 휴지통과 버전 기록의 대상·보존 조건을 확인했는가
- 원본 계정에서 즉시 지울 수 없는 별도 사본이 있는가
- 최근 백업을 실제로 복원해 파일이 열리는지 시험했는가