# Mac 로컬 Time Machine 스냅샷 삭제하기

> macOS가 로컬 스냅샷을 관리하는 방식을 이해하고 읽기 전용 명령으로 목록을 확인합니다. 실제 공간 부족으로 작업이 실패할 때만 수동 제거를 검토하세요.

Published: 2026-07-28 | Updated: 2026-10-05

Time Machine 로컬 스냅샷은 백업 디스크를 쓸 수 없을 때 최근 복원 지점을 시동 볼륨에 보관합니다. 오래된 블록을 참조할 수 있지만 존재 자체는 장애가 아닙니다. Apple은 이 공간을 사용 가능으로 계산하고 오래되거나 다른 작업이 용량을 필요로 할 때 자동 삭제합니다.

일반 공간 확인 뒤에도 저장, 복사, 설치가 실패할 때만 고려하세요. `tmutil listlocalsnapshots /` 는 읽기 전용입니다. Apple의 공개 수동 경로는 자동 백업을 잠시 끄고 제거를 기다린 뒤 다시 켜는 것입니다. 고급 삭제는 로컬 복원 지점을 없애므로 정기 정리에 쓰지 않습니다.

## 잘못된 사고 모델

사람들은 여유 공간을 “보이는 파일의 합”으로 취급합니다. APFS에서는 “남은 참조가 없는 블록”에 더 가깝습니다. 파일이 Finder에서 사라져도 스냅샷이 참조하는 익스텐트는 남을 수 있습니다. 마지막 참조가 떨어질 때까지 `df`는 그 블록을 사용 중으로 셉니다.

대화에서 흔히 섞이는 숫자는 세 가지입니다.

| 숫자 | 무엇을 답하는가 |
|---|---|
| Finder / 앱의 “크기” | 아직 볼 수 있는 이름 있는 파일의 논리 크기 |
| `df` 사용/가용 | 마운트된 파일 시스템이 회계 규칙 적용 후 보고하는 값 |
| 저장 공간의 “삭제 가능” | 섞인 회수 가능 풀의 상한 |

삭제 가능한 공간은 폴더가 아닙니다. 로컬 스냅샷, 일부 캐시, 축출 가능한 클라우드 콘텐츠, 회계 여유분까지 포함할 수 있습니다. 전후 `df`를 보여 주지 않고 “삭제 가능 47.2 GB를 확보한다”고 약속하는 도구는 추측하고 있는 것입니다.

## 내부 구조: 쓰기 시 복사와 스냅샷

스냅샷은 생성 당시 extent를 기록하고 이후 쓰기는 새 블록을 사용합니다. 오래된 블록이 남는 이유는 설명하지만 목록에 있는 스냅샷이 현재 작업을 막는다는 증거는 아닙니다. Apple은 [자동 관리](https://support.apple.com/102154)와 사용 가능 용량 계산을 설명합니다.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/local-snapshot-cow.webp" width="1360" height="454" loading="lazy" alt="파일이 현재 볼륨에서 사라져도 로컬 스냅샷은 오래된 블록을 참조할 수 있고 다른 작업이 용량을 필요로 하면 macOS가 관리되는 스냅샷을 회수합니다.">
  <figcaption>물리 블록을 유지하면서도 그 용량을 새 작업에 사용 가능하다고 계산할 수 있습니다.</figcaption>
</figure>

로컬 스냅샷 이름은 보통 이런 형태입니다.

```
com.apple.TimeMachine.2026-07-28-091530.local
```

끝의 `.local` 이 백업 대상의 항목이 아니라 디스크에 있는 로컬 스냅샷이라는 표시입니다.

## 로컬, 외부, 그 밖의 스냅샷

| 종류 | 위치 | 할 일 |
|---|---|---|
| `/`의 로컬 TM 스냅샷 | 시작 볼륨 | 시스템 관리, 필요성이 입증될 때만 수동 제거 |
| Time Machine 백업 | 외부 또는 네트워크 볼륨 | 장기 백업 기록이므로 내부 디스크 공간을 확보하려고 지우지 않음 |
| 기타 APFS 스냅샷 | 같은 볼륨, 다른 이름 | 소유자를 알 때만 삭제 |
| iCloud 저장 공간 최적화 | 클라우드 + 로컬 구체화 | 축출 정책이며 `tmutil`이 아님 |

`diskutil apfs listSnapshots /`는 Time Machine만 보여 주는 것보다 많을 수 있습니다. 다른 소프트웨어도 APFS 스냅샷을 만들 수 있습니다. 출처를 모르는 비 TM 스냅샷을 임의의 최적화 도구로 지우지 마십시오.

<figure class="blog-diagram">
  <img src="https://mole.fit/img/blog/apfs-space-model.webp" width="1360" height="454" loading="lazy" alt="사용자 파일, 스냅샷, 삭제 가능한 공간, 여유 공간으로 나뉜 APFS 컨테이너입니다">
  <figcaption>물리적 용량은 파일, 스냅샷, 삭제 가능한 데이터, 여유 공간으로 나뉩니다. 시스템 데이터는 저장 공간 분류이며, 비우면 되는 단일 폴더가 아닙니다.</figcaption>
</figure>

## 실험: 삭제하지 않고 측정하기

Finder 사용 가능 용량, `diskutil info /`, 실패한 작업을 기록하고 목록만 확인합니다.

```
date
df -h /
tmutil listlocalsnapshots /
diskutil apfs listSnapshots /
diskutil apfs list
```

항목은 복원 지점의 증거이지 용량 장애의 증거가 아닙니다. 분류 막대가 아니라 원래 작업의 성공 여부로 판단하세요.

### 출력을 읽는 법

**`listlocalsnapshots` 가 비어 있음.** 로컬 TM 스냅샷은 원인이 아닙니다. `du` 나 트리맵으로 폴더를 측정하고([큰 파일 찾기](https://mole.fit/ko/blog/how-to-find-large-files-on-mac)) 캐시, 사진, Docker, 기기 백업을 보세요.

**스냅샷이 있고 실제 여유 공간도 적음.** 정상적인 증거일 뿐 진단은 아닙니다. Finder의 사용 가능 용량을 확인하고 공간이 필요한 작업을 다시 실행한 뒤에 Time Machine을 건드리세요.

**`diskutil apfs list` 에 볼륨이 여러 개인 컨테이너가 보임.** 여유 공간은 컨테이너 단위로 공유됩니다. 두 번째 볼륨 때문에 한쪽 볼륨 라벨만 가득 차 보이거나 그 반대일 수 있습니다. 시동 볼륨 라벨만 보지 말고 컨테이너의 여유 공간을 보세요.

**권한 오류.** 터미널에 일부 보호된 경로의 전체 디스크 접근 권한이 없을 수 있습니다. 접근 문제이지 디스크가 비었다는 증거가 아닙니다.

### 통제된 실험

안전하게 비교하려면 Finder의 사용 가능 용량, `diskutil info /`, 실패하는 작업의 결과를 기록하세요. 스냅샷은 삭제하지 말고 나열만 합니다. 복구할 수 있는 사용자 파일 하나를 지우고 내용을 확인한 뒤에 휴지통을 비운 다음 같은 작업을 다시 실행합니다. 저장 공간 분류가 늦게 다시 그려지는 것은 쓰기 실패가 아니며, 판단에 쓸 수 있는 것은 작업 그 자체입니다.

## `tmutil`이 할 수 있는 일

### 먼저 자동 관리에 맡기기

저장과 업데이트가 정상이라면 조치가 필요 없습니다.

### Apple 공개 경로

실제 작업이 공간 때문에 실패하고 다른 파일로 설명되지 않을 때 자동 백업을 잠시 끄고 몇 분 기다린 뒤 반드시 다시 켭니다.

### 고급 명령

현재 `man tmutil` 은 `thinlocalsnapshots mount_point [purge_amount] [urgency]` 를 설명합니다. 최신 백업과 현재 매뉴얼을 확인하고 맥락 없는 명령을 복사하지 마세요. 삭제는 외장 기록을 바꾸지 않지만 Mac의 복원 지점을 없앱니다. 끝나면 백업을 켜고 실패한 작업을 다시 실행합니다.

### 볼륨의 로컬 스냅샷 삭제

디스크가 심각하게 가득 차고 `listlocalsnapshots` 에 항목이 보일 때:

```
tmutil deletelocalsnapshots /
```

버전에 따라 슬래시 하나 형태가 아니라 날짜로 지정한 로컬 스냅샷을 삭제하기도 합니다. 쓰고 있는 OS에 문서화된 형태를 우선하고, 그다음 항상 다시 나열하세요.

```
tmutil listlocalsnapshots /
df -h /
```

APFS가 익스텐트를 비동기로 놓아줄 수 있어 여유 공간은 몇 초에서 몇 분에 걸쳐 늘어납니다. 두 번 측정하세요.

### 이 명령과 혼동하지 말아야 할 것

- **백업 대상에 실행하는 `tmutil delete`** 는 실제 백업 기록을 지웁니다. 다른 작업이고 잃는 것이 큽니다.
- **Finder에서 `/.MobileBackups` 아래 폴더를 지우는 것** 은 지원되는 정리 경로가 아닙니다. `tmutil` 이나 시스템 회수를 쓰세요.
- **수동 제거를 시험한 뒤 Time Machine을 꺼 둔 채로 두는 것** 은 일시적인 용량 확인과 사라진 백업 정책을 맞바꾸는 일입니다. 자동 백업을 다시 켜세요.
- **APFS 모델을 설명하지 않으면서 root를 요구하는 서드파티 “스냅샷 최적화 도구”** 는 위험만 키우고 `df` 로 다시 확인할 수 있는 것은 아무것도 알려 주지 않습니다.

## 실무 예

시스템 데이터와 스냅샷이 커도 macOS 업데이트가 시작되면 고칠 장애가 없습니다. 업데이트가 공간 때문에 실패하면 실제 파일과 휴지통을 측정하고 한 가지를 바꾼 뒤 다시 시도합니다. 그래도 설명되지 않을 때만 스냅샷 제거를 제한된 실험으로 삼고 백업을 다시 켭니다. 계속 실패하면 다른 활성 데이터를 조사하세요.

## 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/ko/)의 분석 화면은 현재 디스크에서 큰 폴더를 찾는 데 도움이 됩니다. Time Machine 스냅샷 관리 정책을 대신하지는 않습니다. 스냅샷은 Apple 안내와 현재 Mac의 `tmutil` 매뉴얼을 따르고, 공간이 필요했던 작업이 실제로 성공하는지 확인하세요.

Mole의 Clean이 다루는 스냅샷은 한 가지입니다. 로컬 스냅샷이 있으면 시스템 데이터 그룹에 ‘Time Machine 로컬 스냅샷’ 항목이 기본 선택 상태로 나타나며, tmutil 명령과 같은 방식으로 삭제합니다. 백업 중에는 이 항목을 숨기고, 백업 디스크와 Time Machine 일정은 건드리지 않습니다. 로컬 복원 지점을 남기려면 선택을 해제하세요.

## 작업 순서

1. 백업 대상과 자동 백업을 확인합니다.
2. Finder, `diskutil info /`, 실패한 작업을 기록합니다.
3. 큰 사용자 파일과 휴지통을 먼저 측정합니다.
4. 로컬 스냅샷을 읽기 전용으로 나열합니다.
5. 같은 작업이 계속 실패할 때만 Apple 경로나 현재 매뉴얼을 씁니다.
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를 지웠는데 아무 일도 없다”는 검증 가능한 메커니즘이 되고, 공포 마케팅 도구를 믿을 이유가 되지 않습니다.

## 자주 묻는 질문

### 로컬 스냅샷 삭제가 외장 백업에 영향을 주나요?

외장 기록을 바꾸지 않지만 Mac 에만 있던 최근 복원 지점은 사라집니다.

### 휴지통을 비워도 바로 늘지 않는 이유는 무엇인가요?

분류 갱신이 느릴 수 있고 오래된 블록 참조도 있을 수 있습니다. 관리 공간은 사용 가능으로 계산되고 필요할 때 회수됩니다. 원래 작업으로 확인하세요.

### 전부 지워도 안전한가요?

정기 정리로 하지 마세요. 실제 용량 장애, 최신 백업, 명확한 증거가 모두 있을 때만 고려합니다.

---

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