백업 파일 수가 같아도, 내용이 같은지는 따로 확인해야 한다

파일 수와 크기가 같은 두 폴더라도 내용이 모두 같지는 않을 수 있다. 미디어플럭스는 텍스트의 숫자를 바이트 크기 변화 없이 바꾸고 해시를 비교했다. 이 작은 예제로 파일 목록, 내용 비교, 실제 복원이 각각 무엇을 확인하는지 살펴본다.

미디어플럭스는 이 차이를 보여주기 위해 개인 자료가 없는 임시 텍스트 파일로 복사·변경·복원 예제를 실행했다. 클라우드나 특정 저장 장치의 성능 시험은 아니다. 어떤 확인이 무엇을 증명하는지 구분하기 위한 작은 실험이다.

먼저 파일 목록으로 보관 범위를 대조한다

점검의 기준은 보관하려고 한 자료의 목록이다. 폴더별 파일 이름과 상대 경로, 바이트 크기를 남기면 다른 위치에 복사한 자료와 비교할 수 있다. 파일 이름만 적으면 서로 다른 폴더의 같은 이름을 구분하기 어렵다.

목록에는 보관 시점과 제외한 자료도 기록한다. 예를 들어 원본 사진은 포함하고 임시 출력 파일은 제외했다면, 제외 자체를 누락과 혼동하지 않도록 적어 둔다. 원래 폴더에 새 자료가 추가된 후 앞선 백업과 개수를 비교하면 차이가 나는 것이 자연스러울 수 있다.

실제 파일과 바로가기를 구분하는 것도 중요하다. 바로가기나 온라인 보관 항목이 보인다는 사실만으로 독립적으로 열 수 있는 파일 사본이 생긴 것은 아니다. 장기 보관 점검에서는 외부 계정이나 원래 위치 없이도 자료를 읽을 수 있는지 확인한다.

같은 크기를 유지하면서 내용을 바꿔 봤다

실험은 Python 표준 라이브러리와 격리된 임시 폴더에서 실행했다. 원본 텍스트를 복사한 뒤 복사본의 수량: 10을 수량: 11로 바꿨다. 두 숫자는 같은 바이트 길이이므로 파일 크기를 유지하면서 내용만 달라지는 예제가 된다.

실행 결과 기록에서 확인한 값은 다음과 같다.

실제 개인 자료는 사용하지 않았다. 원본 제거도 실험용 임시 파일에만 적용했다. 이 결과로 어떤 저장 장치나 클라우드가 더 안전하다고 평가할 수는 없다. 파일 수·크기·내용 확인이 서로 다른 역할이라는 점만 보여준다.

해시가 다른 파일을 찾았을 때 곧바로 손상으로 처리하지 않는다

복사 전후의 해시가 다르면 바이트가 다르다는 뜻이다. 그러나 비교한 두 파일이 애초에 같은 버전인지 먼저 확인해야 한다. 작업 중 원본을 수정했거나 사진을 다른 형식으로 내보냈다면 서로 다른 파일을 정확히 보관했을 수도 있다. 해시 비교의 기준 시점과 파일의 역할이 필요하다.

이번 예제에서는 수량: 10이 들어 있는 텍스트를 복사했다. 복사본의 10을 11로 바꾸면 바이트 크기는 유지되지만 SHA-256 값이 달라졌다. 다시 깨끗한 사본으로 복원한 결과의 SHA-256은 ffe3fe133891969a02791390b9296ee019bc890cfd76330dd0c3c3490dd4db69였다. 입력과 결과는 실행 기록에 남겼다. 실제 개인 자료와 클라우드 계정은 사용하지 않았다.

이 긴 값을 외울 필요는 없다. 중요한 것은 같은 알고리즘으로 계산한 기준값과 다시 읽은 값의 관계다. 기준 목록이 어떤 원본의 어느 시점인지 모르면, 값이 달라도 복사 오류인지 정상적인 버전 차이인지 판단할 수 없다.

비교 기준은 복사할 때 함께 만든다

사본을 만들기 전에 상대 경로와 바이트 크기, 필요한 경우 해시를 기록한다. 전체 폴더를 다시 복사하는 작업에서는 원본에 새 자료가 생겼는지도 확인한다. 복사 중에 파일이 수정될 수 있는 환경이라면 어느 시점의 자료를 보관했는지 작업 범위를 명확히 한다.

차이가 있는 파일은 이름만 바꿔 덮어쓰지 않고 원본과 사본을 분리해 둔다. 사진의 편집·형식 변환이나 문서의 버전 변경처럼 정상적인 차이인지 살핀다. 설명되지 않는 차이는 다시 복사하거나 원본의 상태를 확인할 대상으로 남긴다. 확인한 범위를 기록해야 다음 점검에서도 같은 파일을 추적할 수 있다.

열리는 파일과 복원할 수 있는 자료는 함께 점검한다

바이트가 일치해도 암호화 암호나 필요한 앱이 없으면 실제로 쓰기 어려울 수 있다. 보관함 밖의 별도 폴더로 시험 사본을 복원해 사진·영상·문서를 읽어 본다. 이를 위해 원래 자료를 지울 필요는 없다. 중요한 원본을 유지하고 시험 자료나 별도 복원 위치를 이용한다.

큰 보관함에서는 전체 해시를 계산하는 데 시간이 든다. 최초 보관 후 전체 대조와 이후 표본 점검을 나눌 수 있지만 결과의 이름은 정확해야 한다. 표본이 정상이라면 ‘표본 확인’이고, 전체 목록과 바이트를 대조했다면 그 범위를 명시한다. 몇 파일의 성공을 전체 검증으로 기록하지 않는다.

보관 완료 기록에는 원본의 기준 시점, 보관 범위, 사용한 비교 방법, 실제 읽어 본 자료, 복원에 필요한 조건을 남긴다. 파일 수와 해시, 열람과 복원은 서로 다른 질문이다. 이 질문들이 연결돼 있어야 사고가 난 뒤에도 보관함이 무엇을 되돌릴 수 있는지 알 수 있다.

체크섬은 내용 비교에 쓰고 출처 보증으로 오해하지 않는다

체크섬은 파일의 바이트를 바탕으로 계산한 값이다. 같은 파일에 같은 알고리즘을 적용하면 같은 값을 얻는 성질을 이용해 복사 전후를 비교한다. Python hashlib 문서는 SHA-256 등 해시 계산 기능을 설명한다.

해시 값이 다르면 내용이 다르지만, 그 이유가 반드시 저장 장치의 오류라는 뜻은 아니다. 정상적인 형식 변환, 편집, 메타데이터 변경으로도 값은 달라진다. 사진을 JPEG로 변환한 사본과 원래 HEIC 파일의 값이 다른 것은 예상할 수 있는 결과다.

반대로 값이 일치한다는 사실만으로 파일이 신뢰할 만한 출처에서 왔거나 악성 내용이 없다고 판단할 수도 없다. 체크섬은 비교 기준이 된 파일과의 바이트 일치 확인에 쓰는 도구다. 처음부터 잘못된 파일을 기준으로 삼으면 잘못된 파일을 정확히 복사했는지만 알 수 있다.

기준 목록과 해시 기록도 함께 보관한다

파일을 보관한 시점에 상대 경로·크기·알고리즘·계산값을 기록해 두면 나중에 바뀐 자료를 찾기 쉽다. 목록 파일과 실제 보관 폴더의 관계를 명확하게 남긴다. 백업을 갱신할 때 기존 기준을 덮어쓰기 전에 어느 시점의 사본인지 구분한다.

목록이 원본 기기에만 있으면 그 기기를 잃었을 때 비교 기준도 사라질 수 있다. 자료의 사본과 함께 기준 목록을 보관하되, 이름 자체에 민감한 정보가 있을 수 있으므로 공개 공유 폴더에 올리지 않는다.

매번 전체 파일을 읽어 해시를 계산하면 시간과 장치 읽기 작업이 필요하다. 자료 규모와 중요도에 따라 최초 복사 후 전체 대조, 정기 표본 확인, 중요한 자료의 추가 점검처럼 계획을 나눌 수 있다. 표본만 확인했다면 결과도 ‘표본 확인’으로 기록하고 전체 무결성 확인으로 표현하지 않는다.

실제로 사용할 수 있는지도 확인한다

바이트가 같다는 점검과 파일을 다시 활용할 수 있다는 점검은 서로 보완된다. 사진·영상·문서를 각 앱에서 열고, 필요하면 별도 위치로 복원해 읽어 본다. 복구 프로그램, 계정 접근, 암호화 암호가 필요한 자료라면 그 조건도 함께 기록한다.

원본을 지우며 복원을 시험할 필요는 없다. 시험용 자료나 별도 복원 폴더를 이용해 보관함의 자료를 그대로 유지한 상태에서 경로를 확인한다. 복원 결과가 예상과 다르면 원본을 정리하지 않고 원인을 찾는다.

사진처럼 형식 변환과 여러 구성 요소가 있는 자료는 원본 사진 보관의 범위 점검을 함께 해야 한다. 백업이 있다는 말보다 ‘어느 시점의 어떤 파일을, 어떤 방법으로 확인했고, 어떻게 다시 읽을 수 있는가’를 남기는 편이 다음 복구에 더 도움이 된다.