Google 저장 공간이 거의 다 찼다.
사진과 영상을 Synology NAS로 옮기면 공간을 비울 수 있다는 결론은 금방 나왔다. 어려운 것은 복사가 아니었다. Google Photos의 원본을 지워도 된다고 무엇으로 판단할 것인가가 더 어려웠다.
NAS에 폴더가 보인다는 것만으로는 부족했다. ZIP 하나가 빠졌을 수도 있고, 압축이 손상됐을 수도 있고, 앨범 때문에 같은 사진이 여러 폴더에 들어 있을 수도 있었다. Synology Photos가 만든 인덱스 파일을 사진으로 잘못 셀 수도 있었다.
그래서 이번 이전의 기준을 “복사가 끝났다”가 아니라 원본에서 최종 반입 경로까지 파일 단위로 설명할 수 있다로 잡았다.
먼저 Google Photos만 Takeout으로 내보냈다
Google Takeout에서 전체 제품 선택을 해제하고 Google Photos만 선택했다. 내보내기는 한 번만 실행했고 ZIP 형식을 사용했다. 데이터가 커서 결과는 여러 보관 파일로 나뉘었다.
Google의 데이터 다운로드 도움말에도 데이터를 다운로드한다고 해서 Google 서버의 원본이 삭제되지는 않는다고 적혀 있다. 이 점이 중요했다. 내보내기와 삭제를 한 작업으로 묶지 않고, 검증할 시간을 확보할 수 있었기 때문이다.
받은 ZIP은 Synology NAS의 별도 공유 폴더에 원본 그대로 보존했다.
GooglePhotoMigration/
├── takeout-20260716/ # 원본 ZIP
├── GoogleTakeout_Staging/ # 압축 해제·검사
├── SynologyPhotos_Import_Ready/ # 반입 대상
└── Reports/ # 체크섬·매니페스트·로그원본 ZIP과 작업용 폴더를 분리했다. 압축을 풀고 파일명을 바꾸거나 촬영시각을 적용하더라도 원본 ZIP까지 건드리지 않기 위해서였다.
24개 ZIP부터 의심했다
NAS에 도착한 원본은 ZIP 24개, 총 48,124,398,860바이트였다. 먼저 각 파일의 MD5를 NAS 내부에서 계산하고 ZIP 중앙 디렉터리를 열어봤다.
| 검사 | 결과 |
|---|---|
| 원본 ZIP | 24개 |
| MD5 계산 | 24/24 성공 |
| ZIP 구조 검사 | 24/24 성공 |
| 압축 해제 오류 | 0건 |
| 0바이트 파일 | 0개 |
23개 ZIP에는 실제 사진과 영상이 들어 있었고, 나머지 작은 ZIP 하나에는 archive_browser.html만 있었다. 이 파일은 미디어와 섞지 않고 별도로 보존했다.
메인 압축 해제 결과는 13,807개 파일, 48,118,014,566바이트였다.
| 구분 | 파일 수 |
|---|---|
| 이미지 | 6,477 |
| 동영상 | 989 |
| JSON | 6,327 |
| 기타 | 14 |
| 합계 | 13,807 |
앨범 복사본을 바로 중복으로 지우지 않았다
Takeout을 풀어보면 같은 사진이 연도별 폴더와 사용자가 만든 앨범 폴더에 함께 나타날 수 있다. 처음에는 파일명과 크기가 같은 후보가 70그룹, 140개였다.
하지만 이름과 크기만 같다는 이유로 삭제하면 안 된다. 후보 114개의 내용을 MD5로 다시 비교했고, 그중 57개만 정확히 같은 파일로 확정했다.
중복 57개는 원본 Takeout에서 삭제하지 않았다. Synology Photos에 넣을 대상에서만 제외했다.
이렇게 하면 중복 제거 판단이 잘못됐더라도 원본 ZIP과 Staging에서 다시 복원할 수 있다.
JSON 메타데이터는 촬영시각과 함께 보존했다
Google Photos Takeout에는 사진·영상 옆에 supplemental-metadata.json이 붙는다. 파일의 촬영시각, 설명, 위치 같은 정보가 들어 있을 수 있다.
이번에는 JSON의 촬영시각을 반입 복사본 6,249개의 파일 수정시각에 적용했다. 촬영시각 sidecar가 없는 1,160개는 억지로 추정하지 않았다. 기존 미디어 내부 EXIF도 변경하지 않았다.
GPS 정보가 있는 sidecar는 4,352개였다. NAS 환경에서 안전하게 EXIF를 다시 쓸 도구가 준비되지 않은 상태였기 때문에 사진 파일 안에 GPS를 새로 삽입하지 않았다. 대신 원본 경로, 대상 경로, 촬영시각과 GPS를 전체 매니페스트에 남겼다.
7,409개를 두 경로에 복사하고 SHA-256으로 다시 비교했다
원본 미디어는 7,466개였다. 정확 중복 57개를 제외해 최종 반입 대상은 7,409개가 됐다.
원본 미디어 7,466개
- 정확 중복 57개
= 최종 반입 7,409개이 파일들을 먼저 SynologyPhotos_Import_Ready에 만들고, 다시 Synology Photos 공유 공간인 /photo/Google Photos Takeout 2026-07-16으로 복사했다. Synology 공식 도움말에서도 공유 공간의 파일은 /photo에 보존된다고 설명한다.
마지막 검증에서는 매니페스트의 원본, Import Ready, /photo 세 위치를 파일별 SHA-256으로 비교했다.
| 검증 항목 | 결과 |
|---|---|
| 최종 파일 수 | 7,409개 |
| 검증 용량 | 47,797,389,971바이트 |
| 누락 | 0개 |
| 크기 불일치 | 0개 |
| 촬영시각 불일치 | 0개 |
| SHA-256 불일치 | 0개 |
| JSON 파싱 오류 | 0개 |
처음 검증에서는 /photo 파일이 8,387개로 집계돼 실패로 처리했다. 복사 과정에서 파일이 늘어난 것처럼 보였다.
원인은 Synology Photos가 생성한 @eaDir 인덱스 산출물이었다. 사용자 미디어와 인덱스 파일을 분리해 다시 세니 /photo의 사용자 미디어도 정확히 7,409개였다. 자동 인덱싱 산출물은 4,380개가 별도로 존재했다.
그래도 ‘완벽하다’고 쓰지 않은 이유
파일 시스템 기준 이전과 무결성 검증은 끝났지만, 확인할 내용이 하나 남았다.
보조 메타데이터 JSON은 있는데 미디어 본체가 없는 것으로 보이는 MP4가 1건 있었다. ZIP 전송이나 압축 해제 오류는 아니었다. Google이 Takeout을 만들 때부터 본체가 빠졌을 가능성이 있어 Google Photos 원본 계정에서 따로 찾아봐야 했다.
또 자동화 계정에는 Synology Photos 앱 내부 데이터베이스를 읽는 권한이 없었다. 따라서 내가 완료했다고 말할 수 있는 범위는 다음과 같다.
- 원본 ZIP의 구조와 압축 해제 검증
- 반입 대상의 중복·메타데이터 처리
- 원본부터
/photo까지 7,409개 전체의 SHA-256 비교 - Synology Photos 인덱스 생성 시작 확인
반대로 Synology Photos 화면에서 모든 항목이 보이는지, 대표 사진과 영상이 실제로 재생되는지, HEIC·HEVC 미리보기가 잘 생성되는지는 앱 권한이 있는 사용자 계정에서 별도로 봐야 한다. NAS의 한 사본만으로는 백업이 완성됐다고 할 수도 없다.
Google 원본을 지우기 전에 세운 기준
이번 작업을 하며 삭제 기준을 이렇게 정리했다.
- Takeout 원본 ZIP을 그대로 보존한다.
- ZIP 수, 체크섬, 압축 구조와 0바이트 파일을 확인한다.
- 중복은 이름이 아니라 내용 해시로 판단한다.
- 반입 대상 전체를 매니페스트로 남긴다.
- 원본과 NAS 최종 경로의 SHA-256을 전수 비교한다.
- Synology Photos 화면에서 대표 사진과 영상을 직접 열어본다.
- NAS와 다른 물리 장치에 두 번째 사본을 만든다.
- 그 뒤에 Google Photos의 오래된 자료부터 소량씩 휴지통으로 옮긴다.
- 휴지통은 바로 비우지 않는다.
사진을 옮기는 명령보다 더 오래 걸린 것은 “빠진 것이 없다”는 근거를 만드는 일이었다. 그래도 이 과정을 거치고 나니 7,409개라는 숫자가 단순한 파일 개수가 아니라, 원본과 최종 복사본이 실제로 일치한 결과가 됐다.
클라우드 원본을 지우는 일은 복사 버튼을 누른 다음 단계가 아니었다. 검증할 수 있는 사본과 되돌아갈 수 있는 원본을 만든 뒤에야 시작할 수 있는 별도 작업이었다.
답글 남기기