Mac 디스크가 가득 찬 이유는 파일이 아니라 스냅샷입니다. 증명하는 방법

macOSTahoe ·
Mac 디스크가 가득 찬 이유는 파일이 아니라 스냅샷입니다. 증명하는 방법

macOS 27로 업그레이드하기 전에 macOS가 숨기고 있는 공간을 찾아보세요: APFS 스냅샷, 제거 가능한(purgeable) 콘텐츠, Preboot와 스왑까지. 명령어와 절대 삭제하면 안 되는 것들을 함께 정리했습니다.

40GB 분량의 동영상을 정리하고 휴지통을 비워도 여유 공간 수치는 거의 움직이지 않습니다. 반대의 경우도 있습니다. Finder는 300GB의 여유 공간이 있다고 태연히 보고하는데, macOS 27 설치 프로그램은 공간 부족을 이유로 시작조차 거부합니다. 두 현상은 사실 같은 원인에서 비롯됩니다. APFS에서 '여유 공간'이라는 수치는 합의된 값일 뿐이며, Finder로는 보이지 않는 디스크의 일부 — 스냅샷, 제거 가능한(purgeable) 콘텐츠, 같은 컨테이너를 공유하는 다른 볼륨들 — 이 그 차이를 만들어냅니다. 9월 14일 대규모 업그레이드를 앞둔 지금, 실제 숫자를 읽는 법을 알아둘 가치가 있습니다.

핵심 요약

  • df와 Finder는 원래 그렇게 설계되어 있어 부정확합니다. 설치 프로그램이 실제로 신경 쓰는 숫자는 APFS 컨테이너의 여유 공간이며, 이는 diskutil info /로 확인합니다.
  • 시스템 볼륨에는 절대 삭제해서는 안 되는 스냅샷이 있습니다 — 지금 부팅 중인, 봉인되고 서명된 시스템 볼륨 자체입니다. 이 스냅샷은 diskutil에는 나타나지만 tmutil에는 나타나지 않으며, 바로 이 차이가 진단의 핵심입니다.
  • 공간이 사라지는 원인은 대개 Time Machine 로컬 스냅샷입니다. 이 스냅샷은 24시간 후, 또는 공간이 부족해지면 삭제되지만, 그 '부족'의 기준은 여러분이 원하는 것보다 훨씬 낮습니다.
  • 제거 가능한(purgeable) 공간은 압박이 가해지면 macOS가 실제로 해제해주는 진짜 공간입니다 — 다만 대규모 업그레이드가 적절한 시점에 적절한 종류의 압박을 만들어내지 못할 수 있습니다.
  • 같은 컨테이너 안의 다른 볼륨들도 공간을 차지합니다. 이 Mac에서는 Preboot가 9GB, VM 볼륨의 스왑이 18GB를 차지하고 있지만 둘 다 Finder 어디에도 나타나지 않습니다.

숫자는 네 개, 디스크는 하나

먼저 이 불일치를 놓고 따지기보다는 있는 그대로 확인하는 것부터 시작하겠습니다. 이 Mac은 1TB SSD에 macOS 26.5.2를 실행 중입니다.

$ df -h / /System/Volumes/Data
Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   395Gi     3%    /
/dev/disk3s5     926Gi   493Gi   395Gi    56%    /System/Volumes/Data

두 볼륨 모두 926GiB라고 주장하고, 둘 다 동일하게 395GiB의 사용 가능 공간을 보고합니다. 어느 쪽도 틀리지 않았고, 어느 쪽도 완전한 진실은 아닙니다. APFS 볼륨은 하나의 컨테이너를 공유하며 그 안에서 자라나기 때문에, '크기'는 사실 컨테이너의 크기이고 '사용 가능'은 컨테이너의 여유 공간이 볼륨마다 한 번씩 반복 표시된 것뿐입니다.

이제 컨테이너에 직접 물어보겠습니다.

$ diskutil apfs list disk3 | grep -E "Capacity|Volume Disk|Consumed"
    Size (Capacity Ceiling):      994662584320 B (994.7 GB)
    Capacity In Use By Volumes:   570712170496 B (570.7 GB) (57.4% used)
    Capacity Not Allocated:       423950413824 B (424.0 GB) (42.6% free)
    |   APFS Volume Disk (Role):   disk3s1 (System)
    |   Capacity Consumed:         12568809472 B (12.6 GB)
    |   APFS Volume Disk (Role):   disk3s2 (Preboot)
    |   Capacity Consumed:         8995532800 B (9.0 GB)
    |   APFS Volume Disk (Role):   disk3s3 (Recovery)
    |   Capacity Consumed:         1304084480 B (1.3 GB)
    |   APFS Volume Disk (Role):   disk3s5 (Data)
    |   Capacity Consumed:         529380937728 B (529.4 GB)
        APFS Volume Disk (Role):   disk3s6 (VM)
        Capacity Consumed:         18253713408 B (18.3 GB)

이것이 정직한 집계입니다. 다섯 개의 볼륨 중 Finder에서 실제로 탐색할 수 있는 것은 529GB짜리 Data 볼륨 하나뿐입니다. Preboot는 9GB, VM 볼륨은 18GB입니다. 이 둘을 합치면 대부분 사람들의 문서 폴더보다 큰 공간을 차지하지만, Mac의 어떤 저장공간 관리 화면에도 표시되지 않습니다.

설치 프로그램이 신경 쓰는 단 하나의 숫자는 다음과 같습니다.

$ diskutil info / | grep "Container Free Space"
   Container Free Space:      423.9 GB (423947014144 Bytes)

이 숫자를 기준으로 삼으십시오. 이 값이 Finder의 표시와 수십 기가바이트 차이가 난다면, 아래 내용이 그 차이가 어디로 갔는지 설명해줄 것입니다.

절대 삭제해서는 안 되는 스냅샷

당연해 보이는 명령을 실행하면 결과는 꽤 불안하게 보입니다.

$ diskutil apfs listSnapshots /
Snapshot for disk3s1s1 (1 found)
|
+-- B8B12570-09B5-402F-99BB-F383487AD69D
    Name:        com.apple.os.update-5B92CE4BA1034457A0921532291F4A4AD939CBE...
    XID:         17495484
    Purgeable:   No
    NOTE:        This snapshot limits the minimum size of APFS Container disk3

제거 불가(Purgeable: No)로 표시된 스냅샷이, 컨테이너의 최소 크기를 제한하고 있다고 명시적으로 설명되어 있습니다. 이것이 디스크를 잡아먹는 범인이라고 결론짓고 싶은 유혹이 듭니다.

하지만 아닙니다. 이것은 지금 여러분이 실행 중인 운영체제 그 자체입니다.

macOS 11부터 시스템 볼륨은 봉인되어 암호학적으로 검증되며, Mac은 그 볼륨 자체를 부팅하는 것이 아니라 그 볼륨의 스냅샷을 부팅합니다. diskutil apfs list도 이를 직접 알려줍니다.

|   APFS Volume Disk (Role):   disk3s1 (System)
|   Snapshot:                  B8B12570-09B5-402F-99BB-F383487AD69D
|   Snapshot Disk:             disk3s1s1
|   Snapshot Mount Point:      /
|   Snapshot Sealed:           Yes

Snapshot Sealed: Yes이며 /에 마운트되어 있습니다. com.apple.os.update- 접두사는 OS 업데이트가 적용될 때 생성되는 스냅샷의 명명 규칙입니다. 이것을 삭제하는 행위는 정리 작업이 아니라 실행 중인 시스템을 삭제하는 것입니다. macOS는 대체로 이를 거부하지만, '대체로'라는 말과 부팅 불가능한 Mac 사이에는 되도록 아무것도 두고 싶지 않을 것입니다.

삭제해도 되는 스냅샷과 이것을 구분하는 결정적인 단서는 다음과 같습니다.

$ tmutil listlocalsnapshots /
Snapshots for disk /:

$ tmutil listlocalsnapshots /System/Volumes/Data
Snapshots for disk /System/Volumes/Data:

둘 다 비어 있습니다. tmutil은 오직 Time Machine 스냅샷만 보고합니다 — 백업을 위해 생성되어 정리해도 안전한 종류입니다. 반면 diskutil은 봉인된 시스템 스냅샷을 포함해 모든 APFS 스냅샷을 보고합니다. diskutil에는 스냅샷이 보이는데 tmutil에는 보이지 않는다면, 그것은 여러분이 삭제할 수 있는 것이 아닙니다.

원칙은 이렇습니다. 행동은 tmutil이 보여주는 것을 기준으로 하고, diskutil은 판단이 아니라 이해를 위해서만 읽으십시오.

실제로 디스크를 잡아먹는 스냅샷

Time Machine은 백업 드라이브뿐 아니라 Mac 자체에도 로컬 스냅샷을 생성하며, '80GB는 대체 어디로 간 걸까?'라는 질문에 대한 답은 대개 이것입니다.

작동 원리는 단순하지만 그 결과는 단순하지 않습니다. 스냅샷은 특정 시점의 볼륨 상태를 보존합니다. 이후 파일을 수정하면 원래 블록은 새 블록과 함께 그대로 유지되어야 합니다. 스냅샷이 찍힐 당시 존재했던 20GB짜리 동영상을 삭제해도 공간은 돌아오지 않습니다 — 스냅샷이 여전히 그 블록을 참조하고 있기 때문입니다. 예외는 두 스냅샷 사이에 생성되고 삭제된 파일뿐이며, 이런 파일은 정말로 사라져서 복구할 수 없습니다.

Apple의 자체 정리 기준은 경과 시간과 공간 압박 두 가지입니다. 24시간이 지난 스냅샷은 제거되고, 여유 공간이 심각하게 부족해지면 더 오래된 것들도 정리됩니다. 이 두 규칙 사이에서, Time Machine 일정이 활성화되어 있고 파일 변경이 잦은 하루를 보낸 Mac은 시계가 되었든 압박 임계값이 되었든 조건이 충족될 때까지 수십 기가바이트를 붙들고 있을 수 있습니다.

이 Mac에는 Time Machine 대상 디스크가 설정되어 있지 않습니다.

$ tmutil destinationinfo
tmutil: No destinations configured.

— 그래서 스냅샷 목록이 비어 있고, Data 볼륨에서도 No snapshots for disk3s5라고 표시됩니다. 여러분의 Mac에 Time Machine이 설정되어 있다면(그리고 설정되어 있어야 합니다 — 최신 백업 전략 가이드 참고), 여러 개의 스냅샷이 발견될 것입니다.

디스크 유틸리티에서 확인하기

터미널을 쓰고 싶지 않다면, 디스크 유틸리티를 열어 보기 → 모든 기기 보기를 선택한 다음 Data 볼륨을 선택하고 보기 → APFS 스냅샷 보기를 켜면 됩니다. 그러면 크기가 표시된 목록과 개별 스냅샷을 삭제할 수 있는 상황별 메뉴가 나타납니다. Howard Oakley의 조언은 되새길 가치가 있습니다 — 가장 최근 스냅샷은 남겨두십시오. 전부 삭제하면 다음 번 Time Machine 실행 시 전체 백업 주기로 넘어갈 수 있습니다.

디스크 유틸리티에 표시된 Mac 데이터 볼륨의 APFS 스냅샷 목록

의도적으로 스냅샷 정리하기

스냅샷 공간을 회수하는 공식적으로 지원되는 방법은 thinlocalsnapshots이며, 마운트 지점, 확보를 시도할 바이트 수, 그리고 1에서 4까지의 긴급도를 인자로 받습니다.

# Ask macOS to free roughly 20 GB from Data volume snapshots, highest urgency
sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4

긴급도 4는 가장 공격적인 수준으로, 필요하다면 가장 최근 스냅샷을 제외한 모든 것을 제거합니다. 이는 macOS가 공간 압박을 받을 때 스스로 하는 일이며, 수동으로 실행하는 것은 그 일을 미리 하는 것일 뿐입니다.

볼륨 단위로 정리하는 대신 특정 스냅샷 하나를 제거하려면 다음과 같이 합니다.

# List them first
tmutil listlocalsnapshots /System/Volumes/Data

# Delete one by its date stamp
sudo tmutil deletelocalsnapshots 2026-09-10-140233

그리고 UUID, XID, 이름 등으로 모든 APFS 스냅샷에 대해 동작하는 더 저수준의 대응 명령은 다음과 같습니다.

diskutil apfs deleteSnapshot disk3s5 -uuid <snapshot-UUID>

가능하면 tmutil을 사용하십시오. diskutil apfs deleteSnapshot은 잘못된 볼륨을 아무렇지 않게 가리킬 수 있으며, 여기서 잘못된 볼륨이란 바로 여러분이 부팅한 그 볼륨입니다.

'제거 가능(Purgeable)'이 실제로 의미하는 것

macOS는 일부 공간을 제거 가능(purgeable)으로 표시합니다. 디스크가 가득 차면 자동으로 삭제할 준비가 되어 있는 콘텐츠라는 뜻입니다. 여기에는 보존 기간이 지난 스냅샷, 클라우드에 이미 존재하는 캐시된 iCloud 파일, 이미 업로드된 사진 원본, 다운로드된 미디어, 각종 캐시가 포함됩니다.

제거 가능한 공간은 분명히 되찾을 수 있는 공간입니다 — 다만 그 회수는 반응적으로만 일어납니다. macOS는 무언가가 공간을 요구할 때만 이를 해제하며, 그 요구는 macOS가 인식할 수 있는 형태로 도착해야 합니다. 대용량 cp 명령은 이를 유발하지만, 실제로 쓰기 작업을 하기도 전에 여유 공간을 미리 점검하고 거부해버리는 설치 프로그램은 그렇지 않을 수 있습니다.

이것이 바로 업그레이드 당일에 벌어지는 실패 패턴입니다. 수백 기가바이트가 제거 가능한 상태로 남아 있는데도 설치 프로그램은 시작조차 하지 않고, 시스템이 움직이도록 설득할 뚜렷한 방법도 없습니다. 이 문제를 무식하지만 안전하게 강제로 해결하는 방법은 실제로 공간 압박을 만들어내는 것입니다.

# Write a large file to force macOS to reclaim purgeable space, then delete it
mkfile -n 30g ~/Desktop/ballast
rm ~/Desktop/ballast

mkfile -n은 스파스 파일을 생성하므로 쓰기 작업 자체는 빠르게 끝납니다. 회수를 유발하는 것은 바로 이 공간 할당 과정입니다. 여유 공간 수치가 움직이는 즉시 이 파일을 삭제하십시오.

아무도 언급하지 않는 볼륨들

컨테이너 안의 다섯 볼륨 중 두 개는 좀 더 자세히 들여다볼 가치가 있습니다. 계속 커지는데도 아무도 신경 쓰지 않기 때문입니다.

Preboot — 이 Mac에서는 9.0GB. 이 볼륨은 컨테이너가 지금까지 설치했던 모든 OS의 부팅 시 자산을 보관합니다. 복구 환경과 볼륨별 암호화 자료도 포함됩니다. 대규모 업그레이드마다 커지며 자동으로 정리되지 않습니다. 손으로 정리할 대상도 아닙니다. 여기서 잘못된 것을 삭제하면 Mac이 부팅되지 않습니다. 지금까지 진행한 업그레이드들의 고정 비용이라고 생각하십시오.

VM — 이 Mac에서는 18.3GB. 이것은 스왑입니다. 그 안에 정확히 무엇이 들어 있는지 확인할 수 있습니다.

$ ls -lh /System/Volumes/VM/
-rw-------  1 root  wheel   1.0G ... swapfile0
-rw-------  1 root  wheel   1.0G ... swapfile1
-rw-------  1 root  wheel   1.0G ... swapfile10
...

$ sysctl vm.swapusage
vm.swapusage: total = 17408.00M  used = 16258.81M  free = 1149.19M  (encrypted)

1GB짜리 스왑 파일 17개 중 16GB가 사용 중입니다. macOS는 필요에 따라 스왑을 늘리지만 적극적으로 줄이지는 않으며, 이를 확실하게 회수하는 방법은 재시동입니다. 업그레이드를 앞두고 공간이 빠듯하다면, Mac을 재시동하는 것은 미신이 아닙니다 — 몇 주째 켜져 있던 Mac이라면 실제로 몇 기가바이트를 되돌려받을 수 있습니다.

macOS 27에는 얼마나 많은 공간이 필요할까

Apple이 공식적으로 명시하는 대규모 업그레이드의 최소 요구 공간은 시작 버전에 따라 역사적으로 25~45GB 범위였고, 설치 프로그램 자체만 해도 약 17GB에 달합니다 — 설치 카탈로그 기준으로 Tahoe는 17,953,734KiB이며, Golden Gate도 비슷한 수준일 것으로 보입니다.

실제로 필요한 숫자는 공식 수치보다 높습니다. 대규모 업그레이드를 시작하기 전에는 컨테이너 여유 공간 60GB를 목표로 잡으십시오. 이유는 세 가지입니다. 설치 프로그램 다운로드, 설치 과정에 필요한 작업 공간, 그리고 업그레이드 전에 macOS가 시스템을 대상으로 찍는 스냅샷인데, 이 스냅샷은 과정 중에는 정리할 수 없습니다.

추측하지 말고 직접 확인하십시오.

diskutil info / | grep "Container Free Space"

또 하나의 낙관적인 숫자: iCloud와 사진

두 가지 기능은 디스크를 실제보다 여유 있어 보이게끔 의도적으로 공간을 보고합니다.

**iCloud Drive의 'Mac 저장 공간 최적화'**는 최근 사용하지 않은 파일의 실제 내용을 지우고, 필요할 때 다운로드되는 껍데기(stub)만 남깁니다. Finder에는 파일이 원래 크기로 표시되지만, 디스크에는 거의 아무것도 남아 있지 않습니다. 설치 프로그램이 얼마나 여유 공간이 있는지 묻기 전까지는 훌륭한 동작입니다. 지워진 콘텐츠는 여유 공간이 아니라 제거 가능한 공간으로 집계되기 때문입니다.

**사진 앱의 'Mac 저장 공간 최적화'**도 원본에 대해 같은 일을 하며, 로컬에는 더 작은 버전만 남겨둡니다. 200GB짜리 라이브러리가 디스크에서는 30GB만 차지할 수 있고, 잘못된 시점에 잘못된 화면을 열면 조용히 대량으로 다시 다운로드될 수 있습니다.

둘 다 고쳐야 할 문제는 아닙니다. 다만 이것이 바로 아무것도 하지 않았는데도 Mac이 '여유 충분'에서 '디스크 가득 참'으로 바뀔 수 있는 이유이며, 지난주에 측정한 여유 공간 수치가 오늘은 아무 의미가 없는 이유이기도 합니다. 업그레이드 전날 밤이 아니라, 업그레이드 직전에 측정하십시오.

업그레이드 전 공간 점검, 다섯 개의 명령으로

다음을 순서대로 실행하면 1분도 안 되어 현재 상태를 정확히 파악할 수 있습니다.

# 1. The number that matters
diskutil info / | grep "Container Free Space"

# 2. Every volume in the container, with what it is consuming
diskutil apfs list $(diskutil info / | awk '/Part of Whole/ {print $4}') | grep -E "Capacity|Volume Disk"

# 3. Snapshots that are actually yours to remove
tmutil listlocalsnapshots /System/Volumes/Data

# 4. Swap, which a restart returns
sysctl vm.swapusage

# 5. The largest directories in your home folder
du -sh ~/* 2>/dev/null | sort -rh | head -10

1단계 결과가 60GB를 넘는다면 여기서 멈추십시오 — 준비가 된 것입니다. 그렇지 않다면 2단계부터 5단계까지가 네 가지 원인 중 어디를 공략해야 하는지, 그리고 위험이 가장 적으면서 공간을 되돌려받는 대략적인 순서를 알려줍니다.

안전한 순서로 공간 회수하기

  1. 재시동. 스왑을 해제하고 캐시를 비우며 일부 스냅샷을 제거합니다. 2분이면 끝나고, 종종 10~20GB를 되돌려줍니다.
  2. Time Machine 스냅샷 정리. sudo tmutil thinlocalsnapshots /System/Volumes/Data 20000000000 4. 안전하고 공식적으로 지원되며, 다음 백업이 필요한 것을 다시 만들어낸다는 의미에서 되돌릴 수 있습니다.
  3. 휴지통 비우기. 사진 앱과 메일 앱도 포함됩니다. 이곳에서는 삭제한 항목이 앱 자체의 휴지통에 30일 동안 남아 있습니다.
  4. 수치가 여전히 맞지 않는다면 앞서 소개한 밸러스트 파일 기법으로 제거 가능한 공간의 회수를 강제하십시오.
  5. 개발자 캐시(해당하는 경우). 이 Mac에서는 /System/Library/AssetsV2가 총 25GB이며, 그중 16GB는 iOS 시뮬레이터 런타임입니다. 실제로 사용 중인 개발자 머신에서는 Xcode의 Derived Data, Device Support, 아카이브가 흔히 50GB 이상을 추가로 차지합니다. Xcode 자체의 설정 → 구성 요소(Settings → Components) 화면에서 시뮬레이터 런타임을 깔끔하게 제거할 수 있습니다.
  6. 실제로 소유하고 있는 대용량 파일. 저장 공간 분석 도구를 사용하면 직접 뒤지는 것보다 빠르게 찾을 수 있습니다. 디스크는 가득 찼는데 원인이 될 만한 것이 눈에 안 보인다면, 숨겨진 루트 레벨 로그도 확인해볼 만한 곳입니다.
  7. 외장 저장장치로 옮기기. 디스크가 그저 너무 작을 때 쓰는, 느리지만 확실한 정답입니다.

하지 말아야 할 것들

  • 시스템 볼륨의 com.apple.os.update- 스냅샷을 삭제하지 마십시오. 이것은 현재 실행 중인 OS입니다.
  • /System/Volumes/ 아래의 무엇이든 rm -rf로 지우지 마십시오. Preboot, VM, Recovery는 시스템을 지탱하는 핵심 요소입니다.
  • '공간을 아끼겠다'는 이유로 Time Machine 로컬 스냅샷을 비활성화하지 마십시오. 잘못된 업데이트를 롤백할 능력을 잃게 되는데, 이것이 바로 업그레이드 주간에 가장 필요한 안전망입니다.
  • 이를 위해 정리 앱을 설치하지 마십시오. 위에서 소개한 모든 작업은 macOS 내장 명령으로 할 수 있습니다. 전체 디스크 접근 권한을 요구하며 시스템 파일을 삭제해 공간을 확보해주겠다는 서드파티 도구는 가득 찬 디스크보다 더 위험합니다.
  • 스왑 파일을 손으로 삭제하지 마십시오. macOS는 이를 다시 만들어내며, 사용 중인 파일을 제거하면 그대로 충돌로 이어집니다.

스냅샷 회수 전후의 컨테이너 여유 공간을 비교하는 터미널 출력

자주 발생하는 문제 해결하기

tmutil thinlocalsnapshots는 성공했다고 나오는데 아무것도 회수되지 않는 경우

제거된 스냅샷들이 참조하던 블록을 다른 스냅샷도 함께 참조하고 있었던 것입니다. 겹쳐 있는 여러 스냅샷 중 하나를 제거해도 공간은 회수되지 않으며, 마지막 하나를 제거해야 한꺼번에 전부 회수됩니다. 긴급도 4로 다시 실행하거나, 남은 스냅샷을 하나씩 개별적으로 삭제하십시오.

디스크 유틸리티에는 스냅샷이 없는데 공간이 여전히 사라진 경우

그렇다면 원인은 스냅샷이 아닙니다. 컨테이너의 볼륨별 내역을 확인하십시오 — Preboot와 VM이 흔한 복병입니다 — 그리고 제거 가능한 공간도 확인하십시오. iCloud 사진 라이브러리가 큰 Mac이라면 이상하게 보고되는 최적화된 원본도 갖고 있을 수 있습니다.

설치 프로그램은 공간이 부족하다는데 diskutil은 충분하다고 나오는 경우

지금 보고 있는 것이 볼륨이 아니라 컨테이너인지, 그리고 외장 디스크가 아니라 내장 디스크를 보고 있는지 확인하십시오. 두 값이 모두 공간이 있다고 동의한다면, 실패의 진짜 원인은 대개 공간 오류로 위장한 다른 문제입니다 — 흔한 경우는 서드파티 kext의 승인 실패입니다. 출시 당일 업그레이드 가이드에서 kext 점검 방법을 다룹니다.

공간이 밤사이 계속 사라지는 경우

Time Machine이 실행된 것입니다. 이는 시스템이 정상적으로 작동한다는 뜻입니다. 변경량이 정말로 비정상적으로 많다면, Time Machine 자체가 아니라 무엇이 쓰기 작업을 하고 있는지 살펴보십시오 — 대용량 파일을 재작성하는 동기화 클라이언트, VM 디스크 이미지, 또는 데이터베이스가 흔한 원인입니다.

스냅샷을 삭제한 뒤 Mac이 부팅되지 않는 경우

복구 모드로 부팅한 다음, 남아 있는 이전 스냅샷이 있다면 Time Machine 시스템 복원으로 되돌리십시오. 남은 것이 없다면 현재 시스템 위에 macOS를 재설치하면 Data 볼륨은 보존됩니다. 바로 이런 상황을 막기 위해 '봉인된 스냅샷은 절대 삭제하지 말라'는 규칙이 존재하는 것입니다.

자주 묻는 질문

APFS 스냅샷은 백업인가요?

아닙니다. 스냅샷은 자신이 참조하는 데이터와 같은 디스크에 존재합니다. SSD가 고장 나면 스냅샷도 함께 사라집니다. 스냅샷은 실수나 잘못된 업데이트로부터는 보호해주지만 하드웨어 장애로부터는 보호해주지 못합니다. 진짜 백업은 다른 곳에 있어야 합니다 — 백업 전략 가이드를 참고하십시오.

macOS 27로 업그레이드하기 전에 스냅샷을 삭제해야 하나요?

전부 삭제하기보다는 정리(thin)하고, 가장 최근 것은 남겨두십시오. 업그레이드 자체가 업그레이드 이전 시스템의 새 스냅샷을 만들어내는데, 문제가 생겼을 때 필요한 것이 바로 그 스냅샷입니다.

Finder는 왜 다른 여유 공간 수치를 보여주나요?

Finder는 제거 가능한 콘텐츠까지 포함한 볼륨의 사용 가능 공간을 보고하며, 이는 낙관적인 수치입니다. diskutil info /는 컨테이너의 실제 여유 공간을 보고합니다. 설치 프로그램이 관련된 상황이라면 후자를 신뢰하십시오.

macOS가 로컬 스냅샷을 만들지 않도록 막을 수 있나요?

Time Machine을 완전히 비활성화하면 스냅샷 생성을 막을 수는 있지만, 이는 손해 보는 거래입니다. 24시간 보존 기간과 압박 기반 자동 정리가 함께 작동하기 때문에, 정상적인 Mac에서는 스냅샷이 스스로 한도를 넘지 않습니다.

Preboot가 9GB인 것은 정상인가요?

다소 높은 편이지만, 여러 차례 대규모 업그레이드를 거친 Mac이라면 걱정할 수준은 아닙니다. 컨테이너가 호스팅한 OS 설치 횟수만큼 커집니다. 이를 정리하는 공식적으로 지원되는 방법은 없으며, 굳이 시도할 이유도 없습니다.

재시동이 정말로 공간을 확보해주나요?

네, 측정 가능한 수준으로 확보됩니다. 이 Mac에서는 18GB에 달하는 스왑이 주된 요인이며, 여기에 캐시와 만료된 스냅샷도 더해집니다. 가장 먼저 시도해볼 만하고, 비용이 전혀 들지 않는 유일한 방법이기도 합니다.

결론

Finder의 여유 공간 수치는 안심시키기 위해 쓰인 요약일 뿐이고, 월요일의 업그레이드가 시작될지 여부를 결정하는 것은 컨테이너의 수치입니다. 그 둘 사이의 격차는 정리할 수 있는 스냅샷, 압박이 가해지면 macOS가 풀어줄 제거 가능한 콘텐츠, 그리고 현대적인 Mac을 운영하는 데 드는 비용일 뿐인 두 개의 보이지 않는 볼륨으로 이루어져 있습니다.

이 글에서 명령어를 딱 하나만 기억해야 한다면 diskutil info / | grep "Container Free Space"로 하십시오. 이 글의 나머지는 전부 그 숫자가 왜 여러분이 예상한 숫자와 다른지를 설명하는 내용일 뿐입니다 — 하지만 옳은 숫자는 바로 그것입니다.

관련 글: macOS 27 Golden Gate 출시 당일 업데이트 가이드 · macOS 27이 소프트웨어 업데이트에 나타나지 않는 이유 · 디스크를 채우는 숨겨진 루트 레벨 로그 · Time Machine 문제 해결