# Mac 로컬 Time Machine 스냅샷 삭제하기
> tmutil로 로컬 스냅샷을 나열·축소하고, purgeable 풀을 이해하며, 실제 백업 디스크를 지우지 않고 공간을 확보한다.
Published: 2026-07-28 | Updated: 2026-08-08
20 GB 분량의 내보내기 파일을 삭제하고 휴지통까지 비웠는데, 사용 가능 용량은 거의 늘지 않습니다. 본능적으로 클리너 앱을 설치하고 싶어집니다. 더 흔한 원인은, 그 블록을 여전히 시작 볼륨의 **로컬 Time Machine 스냅샷**이 붙잡고 있는 경우입니다. 저장 공간 설정은 그 효과를 [시스템 데이터](https://mole.fit/ko/blog/what-is-system-data-on-mac)나 모호한 제거 가능 용량 숫자로 묶어 보여 주기 때문에, 이미 합리적인 조치를 한 뒤에도 회색 막대는 크게 남습니다.
이 글은 실험실 스타일의 가이드입니다. APFS 쓰기 시 복사(copy-on-write)가 블록을 고정하는 방식, 시스템 도구로 스냅샷을 측정하는 방법, `tmutil`이 실제로 바꾸는 것, 그리고 실제 백업 디스크를 지우지 않고 공간을 확보하는 방법을 다룹니다. 끝나면 스냅샷 고정과 실제로 폴더가 사라진 문제를 5분 안에 구분할 수 있어야 합니다.
**한 줄 요약:** 파일을 삭제해도 공간이 늘지 않으면 `tmutil listlocalsnapshots /`로 스냅샷을 나열하고, `tmutil thinlocalsnapshots`로 줄인 뒤 APFS가 고정된 블록을 해제하도록 두십시오. 외부 Time Machine 디스크의 백업은 어느 쪽이든 그대로 유지됩니다. 로컬 스냅샷은 시작 볼륨에만 있는 임시 복사본입니다.
## 잘못된 사고 모델
사람들은 여유 공간을 “보이는 파일의 합”으로 취급합니다. APFS에서는 “남은 참조가 없는 블록”에 더 가깝습니다. 파일이 Finder에서 사라져도 스냅샷이 참조하는 익스텐트는 남을 수 있습니다. 마지막 참조가 떨어질 때까지 `df`는 그 블록을 사용 중으로 셉니다.
대화에서 흔히 섞이는 숫자는 세 가지입니다.
| 숫자 | 무엇을 답하는가 |
|---|---|
| Finder / 앱의 “크기” | 아직 볼 수 있는 이름 있는 파일의 논리 크기 |
| `df` 사용/가용 | 마운트된 파일 시스템이 회계 규칙 적용 후 보고하는 값 |
| 저장 공간의 “제거 가능” | 섞인 회수 가능 풀의 상한 |
제거 가능은 폴더가 아닙니다. 로컬 스냅샷, 일부 캐시, 축출 가능한 클라우드 콘텐츠, 회계 여유분까지 포함할 수 있습니다. 전후 `df`를 보여 주지 않고 “제거 가능 47.2 GB를 확보한다”고 약속하는 도구는 추측하고 있는 것입니다.
## 내부 구조: 쓰기 시 복사와 스냅샷
Time Machine이 **로컬 스냅샷**을 만들면, 볼륨은 익스텐트의 고정된 뷰를 기록합니다. 이후 쓰기는 새 블록을 할당합니다. 어떤 스냅샷이든 그 블록을 필요로 하는 한 옛 블록은 살아 있습니다. 파일을 삭제하면 라이브 볼륨의 포인터만 제거됩니다.
그래서 이런 순서가 흔합니다.
1. `df -h /`로 여유 공간을 기록합니다.
2. 본인이 통제하는 큰 임시 파일을 삭제하고 휴지통을 비웁니다.
3. 여유 공간은 거의 늘지 않습니다.
4. `tmutil listlocalsnapshots /`에 항목이 아직 보입니다.
5. 로컬 스냅샷을 thin 하거나 삭제한 뒤 여유 공간이 올라갑니다(수 분에 걸쳐 늘어나는 경우도 있습니다).
Apple은 로컬 스냅샷을 자동 관리된다고 문서화합니다. 외부 백업 사이에 만들어지고, 짧은 기간 유지되며, [공간이 필요할 때 thin 됩니다](https://support.apple.com/102154). 백업 디스크가 분리되어 있을 때 최근 버전을 복원하는 데 도움이 됩니다. 외부 미디어에 있는 전체 Time Machine 이력을 대체하지는 않습니다.
Finder에서 삭제하면 라이브 참조만 사라집니다. 그 익스텐트를 가리키는 모든 로컬 스냅샷이 thin 되거나 삭제될 때까지 할당은 유지됩니다.
로컬 스냅샷 이름은 보통 다음과 같습니다.
```
com.apple.TimeMachine.2026-07-28-091530.local
```
`.local` 접미사는 보통 디스크 위 로컬 스냅샷임을 뜻하며, 백업 대상 항목이 아닙니다.
## 로컬, 외부, 그 밖의 스냅샷
| 종류 | 위치 | 할 일 |
|---|---|---|
| `/`의 로컬 TM 스냅샷 | 시작 볼륨 | 용량이 빠듯할 때 `tmutil`로 thin |
| Time Machine 백업 | 외부 또는 네트워크 볼륨 | 실제 이력; 내부 여유 공간 때문에 지우지 말 것 |
| 기타 APFS 스냅샷 | 같은 볼륨, 다른 이름 | 소유자를 알 때만 삭제 |
| iCloud 저장 공간 최적화 | 클라우드 + 로컬 구체화 | 축출 정책이며 `tmutil`이 아님 |
`diskutil apfs listSnapshots /`는 Time Machine만 보여 주는 것보다 많을 수 있습니다. 다른 소프트웨어도 APFS 스냅샷을 만들 수 있습니다. 출처를 모르는 비 TM 스냅샷을 임의의 최적화 도구로 지우지 마십시오.
물리적 용량은 파일, 스냅샷, 제거 가능 데이터, 여유 공간으로 나뉩니다. 시스템 데이터는 저장 공간 분류이며, 비우면 되는 단일 폴더가 아닙니다.
## 실험: 무엇을 지우기 전에 측정하기
Terminal을 열고 기준값을 기록합니다. 숫자를 적어 두십시오. 기억은 거짓말합니다.
```
date
df -h /
tmutil listlocalsnapshots /
diskutil apfs listSnapshots /
diskutil apfs list
```
### 출력을 읽는 방법
**`listlocalsnapshots`가 비어 있음.** 로컬 TM 스냅샷이 원인이 아닙니다. `du` 또는 treemap([큰 파일](https://mole.fit/ko/blog/how-to-find-large-files-on-mac))으로 폴더를 매핑하고 캐시, Photos, Docker, 기기 백업을 살피십시오.
**스냅샷이 있고 여유 공간이 부족함.** 고정이 그럴듯합니다. thin 한 뒤 다시 측정하십시오.
**`diskutil apfs list`에 여러 볼륨이 있는 컨테이너가 보임.** 여유 공간은 컨테이너 수준에서 공유됩니다. 두 번째 볼륨 때문에 한 볼륨 라벨은 가득 찬 것처럼 보여도 컨테이너에는 여유가 있을 수 있고, 그 반대도 가능합니다. 부팅 볼륨 라벨만이 아니라 항상 컨테이너 여유 공간을 보십시오.
**권한 오류.** Terminal에 일부 보호된 트리에 대한 Full Disk Access가 없을 수 있습니다. 접근 문제이지, 디스크가 비어 있다는 증거가 아닙니다.
### 통제된 실험
자신의 Mac에서 확인하려면:
1. `df` 가용 바이트를 기록합니다.
2. 큰 임시 파일(다시 만들 수 있는 디스크 이미지 등)을 내부 볼륨에 복사한 뒤 삭제하고 휴지통을 비웁니다.
3. 몇 초 안에 `df`를 다시 비교합니다.
4. 스냅샷을 나열합니다.
5. 여유 공간이 거의 안 늘었고 스냅샷이 있으면 thin 하고, 2분 기다린 뒤 `df`를 다시 봅니다.
이제 “Finder에서 파일이 사라짐”과 “새 쓰기를 위한 블록이 비었음”을 분리한 것입니다.
## `tmutil`이 할 수 있는 일
### 먼저 시스템이 thin 하도록 두기
가용 용량이 살짝만 빠듯하면 그대로 작업하십시오. 업데이트를 설치하거나, 큰 파일을 쓰거나, 가득 찬 상태에 가깝게 쓰면 macOS가 개입 없이 가장 오래된 로컬 스냅샷을 버리는 경우가 많습니다. 부작용이 가장 적고, 최근 복원 지점을 더 오래 남깁니다.
### 여유 공간 목표까지 thin 하기
`tmutil thinlocalsnapshots`는 로컬 스냅샷에서 요청한 양까지 회수하도록 시스템에 요청할 수 있습니다. 플래그는 macOS 버전마다 조금 다릅니다. 고치는 기기에서 `man tmutil`을 확인하십시오. 개념적으로는 “로컬 스냅샷에서 최대 N 바이트를 확보하라”는 뜻이며, “이 이름의 한 시간을 지워라”가 아닙니다.
설치 프로그램에 여유가 필요하고, 시스템이 가능하다면 더 새 로컬 복원 지점을 남기고 싶을 때 사용합니다.
### 볼륨의 로컬 스냅샷 삭제
디스크가 거의 가득 차고 `listlocalsnapshots`에 항목이 보일 때:
```
tmutil deletelocalsnapshots /
```
일부 버전은 슬래시 한 번 형태 대신 이름 있는 로컬 스냅샷의 날짜 기반 삭제를 씁니다. OS 문서 형태를 우선하고, 항상 다시 나열하십시오.
```
tmutil listlocalsnapshots /
df -h /
```
여유 공간은 수 초에서 수 분에 걸쳐 늘 것으로 기대하십시오. APFS는 익스텐트를 비동기로 해제할 수 있습니다. 두 번 측정하십시오.
### 이 명령과 혼동하지 말 것
- **백업 대상에 대한 `tmutil delete`**는 실제 백업 이력을 지웁니다. 다른 작업이며 위험이 큽니다.
- **Finder에서 `/.MobileBackups` 아래 폴더 삭제**는 지원되는 정리 경로가 아닙니다. `tmutil` 또는 시스템 회수를 사용하십시오.
- **Time Machine 끄기**는 로컬 스냅샷 공간을 확보하는 데 필요하지 않으며, 아직 필요한 백업 정책까지 없앨 수 있습니다.
- **APFS 모델을 설명하지 않고 root를 요구하는 서드파티 “스냅샷 최적화” 도구**는 `df`로 다시 확인할 수 있는 것을 가르치지 않으면서 위험만 더합니다.
## 실무 예(숫자를 외우지 말고 이야기를 읽기)
주말 동안 영상 내보내기를 한 뒤라고 가정합니다.
- 저장 공간에 시스템 데이터가 약 120 GB, 제거 가능이 “최대” 40 GB로 보입니다.
- 내보내기 25 GB를 삭제하고 휴지통을 비웁니다.
- `df` 가용은 약 2 GB만 늘습니다.
- `tmutil listlocalsnapshots /`에 지난 하루의 `.local` 항목이 여러 개 있습니다.
해석: 삭제된 내보내기의 대부분은 여전히 로컬 스냅샷이 참조합니다. 다음 실험은 `~/Library`를 무작위로 지우는 것이 아니라 로컬 스냅샷 thin 입니다.
`tmutil deletelocalsnapshots /`(또는 성공한 thin) 이후:
- 스냅샷 목록이 비거나 짧아집니다.
- `df` 가용이 수 분에 걸쳐 수십 GB 올라갑니다.
- 저장 공간의 시스템 데이터 숫자는 늦게 따라오거나 재분류될 수 있습니다. `df`와 실제 작업 부하를 믿으십시오.
스냅샷 목록이 이미 비어 있는데도 여유 공간이 안 늘면 스냅샷과의 싸움을 멈추십시오. 다른 문제입니다. 큰 라이브 폴더, 스파스 파일, 클론, 같은 볼륨의 휴지통, 또는 컨테이너의 다른 볼륨입니다.
## thin 후에도 여유 공간이 늘지 않을 수 있는 이유
로컬 스냅샷이 없어도:
- 다른 제거 가능 클래스가 저장 공간 추정치를 지배했습니다(클라우드 구체화, 재생성 가능한 캐시).
- 스파스 파일과 클론 때문에 논리 크기와 물리 크기가 갈라집니다
([합계가 어긋나는 이유](https://mole.fit/ko/blog/daisydisk-alternative)).
- 휴지통에 삭제 항목이 아직 같은 볼륨에 있습니다.
- APFS 컨테이너의 두 번째 볼륨이 여유 풀을 공유합니다.
- 비 TM 스냅샷이나 Time Machine 대상이 관련 데이터를 아직 잡고 있습니다.
각각 자체 측정 경로가 있습니다. 스냅샷은 한 장뿐입니다.
## 안전 전제
적극적으로 thin 하기 전에:
1. 외부 Time Machine 또는 실제로 열어 본 다른 복원 경로에 **최근 성공한 백업**이 있는지 확인합니다.
2. 지운 중간 로컬 버전은 새 스냅샷이 생길 때까지 오프라인으로 복원할 수 없음을 받아들입니다.
3. 전후 여유 공간 차이를 보여 주지 못하는 도구보다 문서화된 `tmutil`을 우선합니다.
로컬 스냅샷은 정상입니다. 내부 볼륨이 가득 차고 최근 삭제한 데이터가 여전히 고정되어 있을 때만 급해집니다.
## 흔한 실수
**시스템 데이터 숫자를 쫓기.** 목표는 쓸 수 있는 용량과 업데이트·저장이 되는 Mac이지, 회색 막대를 보기 좋게 줄이는 것이 아닙니다.
**내부 여유 공간이 부족하다고 외부 백업 디스크를 지우기.** 로컬 스냅샷과 백업 이력을 혼동한 것입니다.
**제거 가능이 커 보여서 Library 폴더를 무작위로 삭제하기.** 제거 가능은 안전한 경로 지도가 아닙니다.
**thin 직후 한 번만 측정하기.** 기다렸다가 `df`를 다시 보십시오.
**컨테이너 회계를 무시하기.** APFS에서 한 볼륨 라벨이 전부는 아닙니다.
## 검토 도구가 맞는 위치
[Mole](https://mole.fit/)의 Analyze 보기에 있는 디스크 맵은 큰 라이브 폴더를 보여 줄 수 있습니다. Mole은 디스크 분석, 앱 관리, 검토 우선 정리를 네이티브 Mac 앱으로 모읍니다. 시스템 데이터는 여전히 macOS와 해당 앱이 관리합니다. 스냅샷에 대해서는 `tmutil`과 전후 `df` 수치가 진실의 원천입니다.
## 작업 순서
1. 실제 백업 경로가 아직 있는지 확인합니다.
2. `df -h /`와 `tmutil listlocalsnapshots /`를 기록합니다.
3. 스냅샷이 있고 용량이 부족하면 `tmutil`로 로컬 스냅샷을 thin 하거나 삭제한 뒤 기다리고 다시 측정합니다.
4. 스냅샷이 더 이상 없으면 폴더를 측정하고 소유권에 따라
[소유 캐시](https://mole.fit/ko/blog/how-to-clear-cache-on-mac)나 큰 사용자 파일을 정리합니다.
5. 삭제를 받아들인 뒤에만 휴지통을 비웁니다.
6. 이전에 실패했던 작업(설치 프로그램, 내보내기, 업데이트)을 다시 실행해 맞는지 확인합니다.
## 더 읽기
- Apple: [About Time Machine local snapshots](https://support.apple.com/102154)
- Apple: [macOS Storage](https://support.apple.com/guide/mac-help/syspf5a64aa6/mac)
- 이 사이트의 관련 글: [시스템 데이터](https://mole.fit/ko/blog/what-is-system-data-on-mac),
[공간 확보](https://mole.fit/ko/blog/how-to-free-up-space-on-mac),
[큰 파일 찾기](https://mole.fit/ko/blog/how-to-find-large-files-on-mac)
로컬 스냅샷은 APFS가 Time Machine에 부팅 디스크 위 단기 실행 취소를 주는 방식입니다. `tmutil`과 `df`를 함께 읽는 법을 익히면 “30 GB를 지웠는데 아무 일도 없다”는 검증 가능한 메커니즘이 되고, 공포 마케팅 도구를 믿을 이유가 되지 않습니다.
## 자주 묻는 질문
### 로컬 스냅샷을 지우면 Time Machine 백업 디스크에 영향을 줍니까?
아닙니다. 로컬 스냅샷은 시작 볼륨에 있으며 설계상 임시입니다. 외부 백업 디스크는 자체 전체 이력을 유지합니다. 로컬 스냅샷을 thin 하거나 삭제해도 백업 디스크의 어떤 것도 다시 쓰지 않습니다.
### 휴지통을 비운 직후에도 여유 공간이 안 바뀌는 이유는 무엇입니까?
APFS에서는 마지막 참조가 떨어질 때까지 파일의 블록이 할당된 채로 남습니다. 스냅샷이 그 익스텐트를 아직 참조하면 `df`는 계속 사용 중으로 세기 때문에, 스냅샷이 thin 되거나 만료된 뒤에야 공간이 돌아옵니다.
### 로컬 스냅샷을 한 번에 모두 지워도 안전합니까?
디스크 공간 관점에서는 그렇습니다. 백업 디스크에 모든 백업이 남아 있습니다. 포기하는 것은 백업 사이 시점의 시작 볼륨을 복원하는 능력이며, macOS는 원래 약 24시간 안에 그 지점을 버렸을 것입니다.
---
Canonical HTML page: https://mole.fit/ko/blog/how-to-delete-local-time-machine-snapshots-mac
Blog index for agents: https://mole.fit/ko/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt
