자바스크립트를 활용한 나의 200GB iCloud 정리 작업

 (andykong.org)
4P by GN⁺ | ★ favorite | 댓글 1개
  • iCloud 저장공간이 200GB 한도에 가까워지고 사진만 약 127GB를 차지하자, 1TB 업그레이드 대신 큰 동영상을 직접 찾아 지우는 우회 방법을 시도함
  • Apple Photos와 iCloud 웹에는 파일 크기순 정렬이 없고, 별도 앱도 iCloud에 오프로드된 사진을 0B처럼 보여 정리 기준으로 쓰기 어려웠음
  • iCloud Photos 웹의 동영상 재생시간 배지가 video-text-badge HTML 요소라는 점을 이용해, JavaScript로 긴 동영상을 찾아 빨간 테두리로 표시함
  • 30초 초과 동영상을 내려받고 삭제한 결과, 내려받은 파일은 약 7GB였지만 iCloud 저장공간은 약 55GB 줄어드는 예상 밖의 차이가 나타남
  • 새 4K 동영상은 파일 크기와 iCloud 표시 변화가 거의 맞았지만, 오래된 동영상은 실제 파일보다 iCloud에서 더 크게 잡혀 오래된 큰 동영상이 정리 우선순위가 될 수 있음

iCloud 웹에서 긴 동영상 골라내기

  • Apple의 저장공간 경고 이후, 200GB에서 1TB로 올리면 비용이 3배 이상 뛰어 대안을 찾기 시작함
  • 저장공간 대부분은 사진이었고 약 127GB를 차지했지만, Apple Photos와 iCloud 브라우저에는 사진을 파일 크기순으로 정렬하는 기능이 없었음
  • 중복 사진이나 동영상 파일 크기를 보여주는 앱도 iCloud에 오프로드된 사진을 0B처럼 표시해 실제 정리에 크게 도움이 되지 않았음
  • iCloud 웹사이트의 Photos -> Media Types -> Videos로 이동한 뒤 화면을 최대한 축소해 많은 동영상을 한 번에 보이게 함
  • 각 동영상의 재생시간 배지가 HTML 요소라면 JavaScript로 검색·필터링할 수 있다고 보고, 긴 동영상을 강조하는 코드를 작성함
    • 재생시간 배지의 클래스는 video-text-badge
    • 페이지 안의 배지를 찾아 재생시간 기준으로 정렬하고, 특정 임계값을 넘는 항목을 강조함
    • iCloud는 화면에 로드된 요소만 불러오기 때문에, 새로 스크롤되어 들어오는 요소도 처리되도록 타이머로 반복 실행함
  • 사용 방법은 iCloud 페이지에서 JavaScript 콘솔을 열고 전체 gist를 붙여넣는 방식임
  • 결과적으로 20초보다 긴 동영상이 빨간 박스로 표시되어, 여러 큰 동영상을 선택하고 내려받은 뒤 삭제하기 쉬워짐

삭제 후 저장공간 변화와 두 번의 실험

  • 스크립트로 iCloud 동영상 중 30초 초과 항목을 모두 제거했을 때, 내려받은 동영상은 약 7GB였지만 iCloud 저장공간은 약 55GB 줄어듦
    • 내려받은 전체 동영상은 디스크에서 8GB를 차지함
    • iCloud 사용량은 199GB에서 143GB로 줄어듦
  • 첫 번째 실험에서는 움직임이 많은 4K 동영상을 업로드해 iCloud 저장공간 반응을 확인함
    • 업로드한 파일 크기는 281MB
    • 업로드 후 iCloud 사용량은 145.33GB
    • 내려받고 삭제한 뒤 파일은 여전히 281MB
    • 삭제 후 iCloud 사용량은 145.6GB로 표시되어, 표시값 차이는 약 270MB 수준이었음
  • 두 번째 실험에서는 오래된 동영상 중 iCloud가 큰 파일로 표시하는 짧은 동영상을 골라 확인함
    • iCloud는 해당 동영상을 128MB로 표시함
    • 내려받은 파일은 47MB였음
    • 삭제 전 iCloud 사용량은 145.29GB, 삭제 후는 145.12GB로 약 170MB 줄어듦
  • 약 7GB 파일 삭제로 7배가 넘는 저장공간이 해방됐고, 오래된 큰 동영상은 실제 파일보다 iCloud에서 더 큰 저장공간 점유량을 갖는 듯했음
  • 원인은 확인되지 않았지만, 결과적으로 50GB 이상의 iCloud 저장공간을 확보했고 같은 작업을 다시 할 수 있는 작은 JavaScript 스크립트가 남음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Photos.app에는 파일 크기가 표시되지 않아서, 큰 파일을 찾아주는 Photos.app 확장이나 별도 앱을 만들어볼까 했음
    그런데 API가 “파일 크기”를 노출하지 않는 듯했고, 적어도 간단한 방법은 찾지 못함
    “사진”이나 “동영상”은 underlying “photo or video object”를 보여주는 뷰에 가깝다고 봄. 동영상을 잘라도 원본 전체 동영상은 남아 있고, 내보내기를 해야 잘린 더 작은 파일 크기가 실제로 생기는 듯함
    그래서 파일 크기가 다르게 보이는 것 같음. 추가로 누군가 파일 크기를 조회하는 AppleScript를 만들었다고 함: https://discussions.apple.com/docs/DOC-250000422

    • 맞음, Photos 앱은 수정되지 않은 원본 파일을 유지하고 편집/자르기 정보는 따로 저장함. 언제든 원본으로 되돌리고 다시 편집할 수 있으니, 편집 전후의 같은 이미지를 여러 벌 저장하고 있을 수도 있음
      “파일 크기”는 어떤 API에서 찾고 있었는지 궁금함
      PhotoKit API로 Photos.app에서 크기 데이터를 가져올 수 있었음: https://alexwlchan.net/2023/finding-big-photos/
      약 2.6만 개 항목이 있는 내 라이브러리에서만 테스트했지만 가장 큰 항목을 찾는 지표로는 유용했음. 다만 1GB 동영상을 내보내면 iCloud 사용량이 1GB 줄어드는지는 확인하지 못함
    • 여기에 더해 아직 자세히 보진 않았지만, RAW+JPG 사진을 가져오면 “원본”을 둘 중 하나로 설정할 수 있음. 메뉴를 확인하지 않으면 어느 쪽이 쓰이는지 모른 채 가져오고 편집할 수 있음
      그래서 라이브러리에는 썸네일 하나로 보이는 갓 가져온 사진이 실제로는 5MB일 수도, 50MB일 수도 있음
    • 코드를 쓸 의향이 있다면 내부 데이터베이스를 확인해봤는지 궁금함. 마지막으로 봤을 때 그냥 sqlite였고, 대충 훑어봐도 어느 정도 이해 가능했음
    • 파일 크기가 달라지는 이유로는 이게 가장 그럴듯함. 나도 예상치 못한 미디어 복원을 본 적이 있음. 동영상을 자르거나 편집했다고 생각했는데 전체 길이와 해상도로 그대로 남아 있었음
      iPhone 저장공간이 그렇게 강박적으로 관리해도 늘 한계에 가까운 이유도 설명됨
    • https://github.com/RhetTbull/osxphotos로 가능함:
      osxphotos query --min-size 100MB --add-to-album "Big Files"
      100MB보다 큰 모든 사진과 동영상을 찾아 “Big files” 앨범에 추가함
      자세한 내용은 osxphotos query --help, 브라우저에서 문서를 열려면 osxphotos docs를 보면 됨. 참고로 내가 만든 도구임

  • 버그일 수도 있지만, 어떤 경우에는 iCloud가 같은 파일의 여러 버전을 몰래 저장하고 있을 가능성도 있음. Apple은 다른 미디어 파일에서도 비슷한 일을 하니까
    마지막 예시가 흥미로움:
    “iCloud는 동영상이 128MB라고 하는데, 내려받아보니 실제 동영상은 48MB였고, 삭제하니 여유 공간이 약 170MB 늘었다”
    이건 iCloud가 단순히 예시 파일 크기를 잘못 표시하는 게 아니라는 쪽을 시사함. 128MB 파일을 지우면 iCloud 공간도 약 128MB만 비어야 할 텐데, 실제로는 표시된 크기 128MB와 다운로드된 버전 48MB를 합친 176MB에 가까운 공간이 비었음. iCloud가 여유 공간을 10MB 단위로 반올림해 표시한다면 충분히 맞아 보임

    • 차등 백업이나 어떤 형태의 버전 관리가 가장 obvious한 원인 중 하나로 보였음. 파일 보존을 위한 완전 중복 저장도 가능하고. 문제는 이 모든 게 완전히 불투명하다는 점임
      결국 저장공간을 어떤 서비스에 점점 더 묶이게 되고, 총 저장량 기준으로 정기 결제하지만 그 저장공간을 어떻게 최적화해야 하는지 정보가 거의 없음. 고정 비용 구간에 머물거나 저장공간/비용 비율을 낮추고 싶은 소비자 입장에서는 그냥 손 놓고 계속 돈을 더 내야 하는 건가 싶음
      기술 업계의 현대적 사업 전략은 복잡성 뒤에 숨는 것임. 비용은 너무 복잡해서 이해하기 어렵고, 내부 정보를 경쟁사에 너무 많이 노출한다는 식임. 그런데 회사가 비용 이상으로 운영되는지 확인할 때는 그런 지표를 어떻게든 산출함. 소비자가 이해하려 하면 갑자기 너무 복잡해짐
      문제는 기술이 실제로 너무 복잡한 규모까지 커지는 경우가 많고, 경영진도 이를 알기 때문에 꽤 유효한 변명거리가 된다는 것임. 그리고 편리하게도 바로 그 지점에 투자를 집중하고 마진을 붙임
    • iPhone에서는 사진과 동영상 편집이 메타데이터일 뿐이고 원본 파일은 유지됨. 방금 동영상을 녹화해서 절반으로 자른 뒤 iCloud에서 파일을 내려받아 테스트해봄
      잘린 파일은 iCloud가 표시한 크기보다 작았지만, 수정되지 않은 원본을 내려받도록 선택하니 크기가 iCloud 표시 크기와 일치했음
    • 혼란의 근본에는 Photos 라이브러리의 사진과 동영상이 단순히 저장소에 복사된 파일이 아니라는 점도 있음. Photos는 편집, 렌더링본, 썸네일, 앱 기능에 필요한 여러 데이터를 위한 메타데이터도 저장함
      따라서 사진을 iCloud에 동기화할 때 개별 파일만 동기화되는 게 아니라 Photos 앱이 관리하는 “Photos Library” 컨테이너가 동기화됨
      Finder나 Files 앱에서 개별 파일을 직접 추가하면 iCloud와 로컬 파일 시스템에서 크기가 정확히 일치함
    • 아마 실제로 그런 경우일 수 있지만, 그렇다고 면책되지는 않음
      하드디스크나 USB 스틱을 사면 일정한 GB를 원하는 대로 쓸 수 있음. 1GB 파일을 넣으면 여유 공간은 1GB 줄어듦. 파일 시스템에 따라 메타데이터 몇 KB 정도는 잃을 수 있지만, 파일 시스템 선택은 사용자에게 있고 저장 장치가 강제하지 않음
      NAND 컨트롤러가 블록 매핑 테이블을 저장하려고 오버프로비저닝 영역 몇 MB를 썼거나, 편의를 위해 데이터를 중복 저장했더라도 사용자는 그 오버프로비저닝 영역 비용을 청구받지 않음
      여기서는 HTTP로 접근하는 저장 장치를 판매하면서, 1GB 파일을 쓰면 자기들 편의를 위해 복제/변환 등을 하고 사용자가 요청하지 않은 그 복제본 저장 비용까지 청구함. 이건 새롭고 예상 밖임

  • 이 아이디어/해결책을 TamperMonkey/Greasemonkey 스크립트로 바꿨음
    기준에 맞지 않는 모든 요소를 “숨기는” 기능도 추가함
    https://github.com/seffignoz/icloudcleanup

  • 내가 셀프 호스팅을 하는 이유 중 하나가 이거임. 클라우드 제공자의 명확성과 투명성을 신뢰하지 않음. 셀프 호스팅 솔루션이 훨씬 덜 안정적이고 덜 안전하며 성능이 낮더라도 아마 바꾸지 않을 것 같음
    개인적으로는 immich를 쓰고 있음. iOS/Android 앱, 서버 컴포넌트, 동기화/백업 옵션을 갖춘 꽤 완성도 높은 솔루션임
    https://immich.app/

    • Apple은 아직 할당량 관리 UI가 얼마나 훌륭한 판매 기회인지 깨닫지 못한 것 같음. 저장공간을 더 팔기에 이보다 좋은 위치가 없음
      Google은 그렇게 함. https://one.google.com/storage와 https://photos.google.com/quotamanagement를 보면 삭제할 항목을 잘 찾게 해주고, 결국 삭제에 지쳐 더 많은 저장공간을 사게 만들려는 구조임
    • 흥미로워 보이지만 상단의 경고를 보면 더 안정화될 때까지 기다려야 할 것 같음

  • iCloud는 전체 품질 원본을 저장하고, 휴대폰에는 더 낮은 품질의 최적화 버전을 내려받는 것으로 알고 있음
    iPhone 설정에서 Apple ID > iCloud > Photos로 가면 기본적으로 켜져 있는 “Optimise iPhone Storage” 옵션이 있음
    이 옵션 설명에는 휴대폰 공간이 부족하면 전체 해상도 사진과 동영상이 자동으로 더 작은 기기용 버전으로 대체되고, 전체 해상도 버전은 언제든 iCloud에서 내려받을 수 있다고 되어 있음
    이건 꽤 합리적으로 보임

    • 그래도 다운로드는 원본 파일을 반환해야 하므로, 저장공간 크기 차이를 설명하는 데는 쓸 수 없음
    • 작성자가 새 파일을 업로드했다가 다운로드했을 때는 파일 크기 차이가 크지 않았던 경우를 설명하지 못함. 파일 크기 차이는 오래된 동영상 파일에서만 생기는 듯함
    • 이건 관련 없음
      이건 Settings > Manage storage에서 볼 수 있는 휴대폰 저장공간에 대한 내용이고, 클라우드 저장공간과는 관계가 없음

  • 흥미로운 글임. 나도 비슷한 문제 때문에 iCloud 요금제를 올려야 했고, 그래서 Apple 입장에서는 고칠 우선순위가 높지 않을 수도 있음
    RAW+JPEG로 촬영하면 Apple Photos가 두 이미지를 묶음. 사진 애호가에게 아주 드문 방식도 아니고, 라이브러리에 중복 비슷한 사진이 잔뜩 쌓이지 않고 RAW와 JPEG를 쉽게 전환할 수 있어 유용함
    하지만 이 결합 방식과 글에서 설명한 파일 시스템 설계 때문에, 둘을 쉽게 분리해서 RAW만 삭제하는 게 불가능해 보임. 몇 년이 지난 지금 절대 건드리지 않을 거대한 RAW 파일들이 남아 있는데, 훨씬 작은 JPEG는 유지하고 싶어서 삭제할 수 없음
    원본을 내보내고 라이브러리에서 삭제한 뒤 JPEG만 다시 가져오는 식이 가장 쉬워 보이지만, 그러면 라이브러리에 쌓아온 수년치 메타데이터를 잃게 됨
    그래서 요금제를 올릴 수밖에 없음

    • 멍청한 질문일 수도 있지만, 메타데이터를 내보내고 다시 가져올 수는 없나? EXIF 데이터 외에 다른 메타데이터가 있는 건지, 아니면 Apple이 전부 내보내지 않는 건지 궁금함
      얼굴 인식 같은 추가 기능을 말하는 거라면 JPEG를 다시 가져온 뒤 앱이 다시 처리하지 않나?
    • 오픈소스 도구 osxphotos(https://github.com/RhetTbull/osxphotos)가 도움이 될 수 있음. 서드파티 exiftool 유틸리티로 메타데이터를 보존하면서 JPEG 이미지를 내보낼 수 있음:
      osxphotos export /path/to/export --has-raw --skip-raw --exiftool
      RAW 쌍이 있는 모든 이미지를 내보내되 RAW 구성요소는 건너뛰고, exiftool(https://exiftool.org/)을 사용해 키워드 같은 메타데이터를 내보낸 JPEG 파일에 기록함. 이후 Photos로 드래그하거나 osxphotos import /path/to/export/*를 실행해 다시 가져올 수 있음
      export와 import 명령에는 내보내기 디렉터리 등을 제어하는 다른 옵션도 많음. osxphotos help export나 브라우저에서 문서를 열려면 osxphotos docs를 쓰면 됨. 참고로 내가 osxphotos 작성자임
    • 지금 같은 상황은 아니지만 사진 덕후라서 결국 나도 겪게 될 것 같아 찾아봄
      File/Export Unmodified Originals를 실행하면 RAW+HEIC와 메타데이터가 담긴 별도 사이드카 파일이 내보내지는 듯함. 그다음 RAW 파일을 따로 치우고 HEIC 파일을 가져오면 사이드카 메타데이터 파일도 자동으로 가져온다고 함
      다만 편집 내용은 잃음. 그래도 somehow “copy edits”가 가능한 것 같음. 기술적인 사람이라면 AppleScript로 이 과정을 자동화할 수 있을 듯함
      하지만 불필요하게 번거롭고 Photos.app에 내장 기능으로 있어야 함. 더 높은 iCloud 요금제로 유도하는 데 도움이 되니 우선순위가 낮은 게 분명해 보임
    • 나도 현재 같은 처지이고 이 번거로운 작업을 아직 시작하지 못했음. 확실히 해결책을 찾고 있음

  • 놀랍게도 연휴 전에 Apple에서 비슷한 저장공간 알림을 받았고, iCloud에 올려두는 대신 모든 사진/동영상을 내 미디어 서버로 내려받기로 했음
    iCloud에서 아카이브를 내려받는 쉽고 직관적인 방법은 없음. 여러 머신과 기기를 써서 천천히 진행 중임
    최근 Apple 변화의 문제는 별 이유 없이 가격을 올린다는 점임. 우리는 계속 사진과 동영상을 찍을 것이고, 최신 기술과 기능 때문에 파일 크기는 계속 커질 수밖에 없음

    • 데이터를 가져오는 쉬운 방법은 있음. 다만 좀 숨겨져 있음
      Google Takeout과 비슷하게 동작함. Mac, iPhone, iPad, PC에서 appleid.apple.com의 Apple ID 계정 페이지에 로그인하고, “Data & Privacy”로 가서 “Manage Your Data and Privacy”를 선택함
      다음 페이지에서 “Get a copy of your data”로 가서 “Get started”를 선택하면 됨
    • 삶을 바꿔줄 도구:
      https://github.com/icloud-photos-downloader/icloud_photos_downloader
    • 나는 PhotoSync(https://www.photosync-app.com/home)로 iPhone 사진을 NAS에 복사함. 훌륭한 프로그램임
      필요하면 iCloud에서 사진도 내려받고 형식 변환도 가능함. 며칠마다 새 사진을 NAS로 보내 로컬 사본을 항상 유지하고, 이 사본들은 매일 밤 Backblaze B2에도 백업함
      형식 변환 덕분에 사진을 HEIC+JPG 쌍으로 유지할 수 있어 원본과 더 쉽게 쓸 수 있는 버전을 함께 가질 수 있음
      정말 원하는 건 iCloud Drive에도 같은 일을 해주는 도구임. 거기에 여러 자료를 넣어두는데, 합리적으로 백업할 방법이 없어서 신경 쓰임. Apple의 권장 방법(https://support.apple.com/en-us/HT204055)은 많이 아쉬움
    • MacOS가 있다면 Photos 앱은 어떤가? 나는 iCloud Photo Library의 로컬 사본을 유지하고 MacOS Photos 앱으로 동기화함

  • 가장 싫은 건 200GB에서 2TB로 뛰는 이상한 요금제 구간임. 많은 가족에게 딱 맞을 500GB나 1TB를 증분으로 결제할 방법이 없음
    저장공간이 범용재가 된 시대에는 사용한 GB당 과금되어야 함

    • 그렇게 해야 무료 구간을 보조할 수 있음
    • 필요하면 200GB에 50GB 단위를 원하는 만큼 붙일 수 있음

  • 내 iCloud 저장공간을 크게 잡아먹는 건 사진의 “live” 동영상 버전임. 아주 짧은 움직임 조각이 함께 있는 사진보다 파일 크기가 더 큼
    지금까지 찾은 처리 방법은 파일을 로컬로 내려받고, iCloud에서 삭제한 뒤, 로컬 동영상을 지우고 남은 정지 이미지만 업로드하는 것뿐임
    시간이 오래 걸리고 투박하며, 과정 중에 뭔가 삭제하거나 중요한 것을 잃을까 봐 불안함
    실제로 보관하고 싶은 소수의 “live” 이미지를 식별해 남길 수 있는 편집 통제를 어느 정도 제공하면서 이 과정을 자동화해주는 도구가 있는지 궁금함

  • 내가 제대로 읽은 건가?
    이게 널리 퍼진 현상이라면 Apple이 업그레이드를 유도하려고 수치를 부풀린 것으로 볼 수 있고, 소송으로 이어질 수도 있지 않나?
    법률 전문가는 아님

    • 원글은 Photos에 미디어를 추가하는 게 단순한 “파일 복사 후 저장”이 아니라는 점을 고려하지 않음. Photos 앱도 다른 앱처럼 자체 Photos Library 파일 형식이 있음
      사진이나 동영상을 추가하면 Photos 앱이 이를 분석하고, 편집 기록을 포함해 앱이 동작하는 데 필요한 여러 메타데이터를 저장함. 결국 이게 iCloud로 동기화됨
    • 사진/동영상을 새 파일로 저장하지 않고 제자리에서 편집하면, iOS는 실행 취소나 되돌리기를 위해 원본 파일을 유지함. Photos나 iCloud 갤러리 어디에도 원본을 보여주지는 않음. 그게 이유일 수 있음
    • 나도 이 글을 그렇게 읽었음. 한 클라우드 저장소에서 일정량의 파일을 내려받아 다른 클라우드에 올려보면 뚜렷한 차이가 있는지 확인할 수 있을 듯함
      Apple이 iCloud에 아직 예전 파일 시스템 형식을 쓰고 있을 수도 있음. 나온 지 꽤 됐고 저장 형식을 바꾸는 데 신경 쓰지 않았을지도 모름. 오래된 계정의 이미지/동영상이 “오래된” 드라이브에 있을 가능성도 있음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.