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

저장 공간게시 2026년 7월 28일수정 2026년 9월 24일8분 읽기

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

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

잘못된 사고 모델

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

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

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

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

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

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

파일이 현재 볼륨에서 사라져도 로컬 스냅샷은 오래된 블록을 참조할 수 있고 다른 작업이 용량을 필요로 하면 macOS가 관리되는 스냅샷을 회수합니다. — 물리 블록을 유지하면서도 그 용량을 새 작업에 사용 가능하다고 계산할 수 있습니다.

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

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

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

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

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

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

사용자 파일, 스냅샷, 삭제 가능한 공간, 여유 공간으로 나뉜 APFS 컨테이너입니다 — 물리적 용량은 파일, 스냅샷, 삭제 가능한 데이터, 여유 공간으로 나뉩니다. 시스템 데이터는 저장 공간 분류이며, 비우면 되는 단일 폴더가 아닙니다.

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

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

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

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

출력을 읽는 법

listlocalsnapshots 가 비어 있음. 로컬 TM 스냅샷은 원인이 아닙니다. du 나 트리맵으로 폴더를 측정하고(큰 파일 찾기) 캐시, 사진, 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 후에도 여유 공간이 늘지 않을 수 있는 이유

로컬 스냅샷이 없어도:

다른 삭제 가능한 클래스가 저장 공간 추정치를 지배했습니다(클라우드 구체화, 재생성 가능한 캐시).
스파스 파일과 클론 때문에 논리 크기와 물리 크기가 갈라집니다 (합계가 어긋나는 이유).
휴지통에 삭제 항목이 아직 같은 볼륨에 있습니다.
APFS 컨테이너의 두 번째 볼륨이 여유 풀을 공유합니다.
비 TM 스냅샷이나 Time Machine 대상이 관련 데이터를 아직 잡고 있습니다.

각각 자체 측정 경로가 있습니다. 스냅샷은 한 장뿐입니다.

안전 전제

적극적으로 thin 하기 전에:

외부 Time Machine 또는 실제로 열어 본 다른 복원 경로에 최근 성공한 백업이 있는지 확인합니다.
삭제한 로컬 스냅샷에만 있던 버전은 사라집니다. 새 스냅샷이 만들어져도 그 이전 버전이 복구되지는 않습니다.
전후 여유 공간 차이를 보여 주지 못하는 도구보다 문서화된 tmutil을 우선합니다.

로컬 스냅샷은 정상적인 기능입니다. 실제 용량 부족으로 작업이 실패하고, 최신 백업이 있으며, 일반 파일로 원인을 설명할 수 없을 때만 수동 제거를 고려하세요.

흔한 실수

시스템 데이터 숫자를 쫓기. 목표는 쓸 수 있는 용량과 업데이트·저장이 되는 Mac이지, 회색 막대를 보기 좋게 줄이는 것이 아닙니다.

내부 여유 공간이 부족하다고 외부 백업 디스크를 지우기. 로컬 스냅샷과 백업 이력을 혼동한 것입니다.

삭제 가능한 공간이 커 보여서 Library 폴더를 무작위로 삭제하기. 삭제 가능한 공간은 안전한 경로 지도가 아닙니다.

thin 직후 한 번만 측정하기. 기다렸다가 df를 다시 보십시오.

컨테이너 회계를 무시하기. APFS에서 한 볼륨 라벨이 전부는 아닙니다.

검토 도구가 맞는 위치

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

작업 순서

백업 대상과 자동 백업을 확인합니다.
Finder, diskutil info /, 실패한 작업을 기록합니다.
큰 사용자 파일과 휴지통을 먼저 측정합니다.
로컬 스냅샷을 읽기 전용으로 나열합니다.
같은 작업이 계속 실패할 때만 Apple 경로나 현재 매뉴얼을 씁니다.
백업을 다시 켜고 작업이 성공하면 멈춥니다.

더 읽기

Apple: About Time Machine local snapshots
Apple: macOS Storage
이 사이트의 관련 글: 시스템 데이터, 공간 확보, 큰 파일 찾기

로컬 스냅샷은 APFS가 Time Machine에 부팅 디스크 위 단기 실행 취소를 주는 방식입니다. tmutil과 df를 함께 읽는 법을 익히면 “30 GB를 지웠는데 아무 일도 없다”는 검증 가능한 메커니즘이 되고, 공포 마케팅 도구를 믿을 이유가 되지 않습니다.

자주 묻는 질문

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

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

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

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

전부 지워도 안전한가요?

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