맥을 쓰다 보면 어느 날 불쑥 ‘디스크 여유 공간이 부족합니다’라는 알림이 뜹니다. 설정을 열고 저장 공간 막대 그래프를 확인해 보면 사진이나 문서, 앱보다 회색으로 표시된 ‘시스템 데이터(System Data)’가 60GB, 심하면 150GB 넘게 차지하고 있는 모습을 보게 되죠.
정작 사용자가 직접 찍은 사진이나 다운로드한 파일은 몇 개 안 되는데, 시스템 데이터라는 모호한 이름 뒤에 디스크의 절반이 묶여 있는 셈입니다. 문제는 이 영역이 일반 폴더처럼 Finder에서 열어보고 필요 없는 파일만 쏙 골라 휴지통에 버릴 수 있는 구조가 아니라는 점입니다. 인터넷을 검색하면 온통 특정 유료 청소 앱을 결제하라는 광고 글이 넘쳐나서 더 답답해지기 마련인데요.
유료 프로그램을 구독할 필요는 없습니다. 맥의 시스템 데이터가 비정상적으로 불어나는 원인은 대부분 정해져 있고, 기본 터미널과 사용자 라이브러리 폴더에서 안전하게 비워낼 수 있습니다. 실제로 용량을 가장 많이 잡아먹는 두 가지 주범부터 차례대로 짚어보겠습니다.
가장 흔한 범인, 잠자고 있는 Time Machine 로컬 스냅샷
시스템 데이터 폭증의 1순위 원인은 다름 아닌 Time Machine 로컬 스냅샷(Local Snapshots)입니다. 타임머신 백업용 외장 하드를 항상 맥북에 꽂아두지 않고 며칠에 한 번씩만 연결하는 분들에게서 특히 자주 발생하는데요.
macOS의 APFS 파일 시스템은 외장 하드가 분리되어 있어도 백업 주기가 되면 디스크 내부의 남는 공간에 변경된 파일 기록(스냅샷)을 임시로 저장해 둡니다. 나중에 외장 하드가 연결되면 한 번에 밀어 넣기 위한 배려인 셈인데, 이 임시 백업 덩어리가 고스란히 ‘시스템 데이터’ 용량으로 잡히는 것이죠.
내 맥북에 로컬 스냅샷이 얼마나 쌓여 있는지 확인하려면 Spotlight(Cmd + Space)에서 터미널을 열고 아래 명령어를 입력합니다.
tmutil listlocalsnapshots /
엔터를 눌렀을 때 com.apple.TimeMachine.2026-09... 같은 날짜 문자열이 대여섯 개 이상 주르륵 출력된다면, 로컬 스냅샷이 용량을 수십 기가바이트씩 쥐고 있다는 확실한 증거입니다. 이 임시 스냅샷을 즉시 정리하고 공간을 회수하려면 아래 명령어를 실행하세요.
tmutil thinlocalsnapshots / 10000000000 4
이 명령어는 10GB 이상의 공간을 확보하도록 시스템에 요청하는 명령입니다. 실행 후 몇 초 뒤 ‘Deleted local snapshot’ 메시지가 나타나며 디스크 여유 공간이 즉각 회복됩니다.
참고 — 스냅샷 목록에 com.apple.os.update만 보이는 경우: 만약 tmutil listlocalsnapshots / 실행 결과에 TimeMachine 대신 com.apple.os.update-... 또는 com.apple.os.update-MSUPrepareUpdate만 나온다면, 이는 타임머신이 아니라 macOS 시스템 소프트웨어 업데이트 준비 스냅샷입니다. 이 스냅샷은 tmutil로 삭제되지 않으며, [시스템 설정] > [일반] > [소프트웨어 업데이트]에서 보류 중인 OS 업데이트를 설치하고 재부팅을 마치면 시스템이 알아서 해제합니다. 이 경우 타임머신 스냅샷 문제는 아니므로 아래의 앱 캐시 정리 단계로 바로 넘어가시면 됩니다.
앱을 지워도 남아 있는 사용자 라이브러리의 유령 캐시
스냅샷을 지웠는데도 여전히 시스템 데이터가 크다면, 두 번째는 사용자 홈 디렉터리 안에 숨겨진 캐시 폴더입니다. 앱을 휴지통에 버렸다고 해서 그 앱이 브라우징하고 내려받았던 임시 파일까지 자동으로 지워지지는 않기 때문입니다.
특히 크롬(Chrome)이나 엣지 같은 웹 브라우저, 카카오톡이나 슬랙 같은 메신저의 미디어 캐시, 그리고 프리미어나 파이널컷 프로의 렌더링 캐시 파일이 수십 기가바이트씩 방치되어 있는 경우가 허다합니다.
Finder를 켜고 단축키 Cmd + Shift + G(폴더로 이동)를 누른 뒤 아래 경로를 입력하고 이동합니다.
~/Library/Caches
Finder에서 직접 폴더를 뒤져도 되지만, 터미널을 다룰 줄 아신다면 아래 명령어로 한 번에 깔끔하게 비우는 편이 훨씬 빠릅니다.
rm -rf ~/Library/Caches/*
명령어를 실행하면 zsh가 100개가 넘는 파일을 정말 지울 것인지 묻는 프롬프트(sure you want to delete... [yn]?)를 띄웁니다. 여기서 y를 누르고 엔터를 치면 위 사진처럼 CloudKit이나 Safari, com.apple... 경로 뒤에 Operation not permitted나 Directory not empty 같은 에러가 주르륵 출력되는데요.
처음 마주하면 명령이 실패한 것처럼 보여서 당황하기 쉽지만, 전혀 걱정하실 필요가 없습니다. 이는 macOS의 시스템 무결성 보호(SIP)와 TCC 보안 체계가 애플 순정 데몬의 영역을 터미널 임의 삭제로부터 보호하고, 현재 실행 중인 프로그램들이 캐시 데이터베이스를 잠그고 있어서 건너뛴 것일 뿐입니다. 정작 디스크를 무겁게 짓누르던 수십 기가바이트의 서드파티 웹 브라우징 캐시와 임시 찌꺼기 파일들은 뒤에서 조용히 전부 지워진 상태입니다.
실제로 캐시 삭제 후 터미널에서 df -h /System/Volumes/Data를 입력해 확인해 본 결과입니다. 이전까지 디스크 사용량이 371Gi, 남은 여유 공간이 고작 20Gi에 불과해 95% 위험 수위에 도달해 있었는데요. 캐시를 비우고 잠시 기다리자 가용 공간(Avail)이 39Gi로 수직 상승하면서 단숨에 약 19GB의 실공간이 회복되었습니다. 점유율도 91%로 내려오며 숨통이 트였죠.
백그라운드에서 실행 중이던 앱들이 파일 핸들을 완전히 내려놓는 데 1~2분 정도 걸릴 수 있으므로, 명령어를 친 직후 숫자가 바로 안 바뀌더라도 잠시 기다렸다가 df -h를 다시 입력해 보시면 차츰 용량이 더 늘어나는 것을 체감하실 수 있습니다.
개발자와 영상 편집자를 괴롭히는 빌드 찌꺼기
코딩을 하거나 Xcode를 다루는 분이라면 시스템 데이터의 절반 이상이 Xcode의 파생 데이터(DerivedData)와 시뮬레이터 런타임일 확률이 매우 높습니다. 방치해 두면 50GB에서 100GB까지도 불어나는 대목입니다.
터미널에서 아래 명령어로 쌓여 있는 빌드 임시 파일을 비워낼 수 있습니다.
rm -rf ~/Library/Developer/Xcode/DerivedData
추가로 Docker를 사용하다가 컨테이너를 종료했더라도, 맥용 도커 데스크톱이 미리 잡아둔 가상 디스크(Docker.raw)가 여전히 수십 GB를 붙잡고 있는 경우가 많습니다. 도커 대시보드 설정에서 ‘Clean / Purge data’를 한 번 실행해 주시면 수십 GB가 바로 풀려납니다.
파일을 지웠는데도 용량 막대가 바로 줄어들지 않는 이유
명령어를 실행하고 캐시를 비웠는데도 ‘저장 공간’ 창의 시스템 데이터 막대기가 즉시 줄어들지 않아 의아할 수 있습니다. 이는 macOS가 디스크의 여유 공간을 계산하고 메타데이터를 갱신하는 데 시간차가 있기 때문입니다.
가장 깔끔한 방법은 대용량 파일이나 캐시를 지운 뒤 맥을 한 번 재부팅하는 것입니다. 재부팅 과정에서 시스템이 잠겨 있던 임시 가상 메모리(Swapfile)와 슬립 이미지(Sleepimage)를 함께 비워내면서 비로소 정확한 여유 용량이 표시됩니다.
매달 비싼 클리너 앱에 돈을 낼 필요는 없습니다. 타임머신 스냅샷과 사용자 캐시 폴더, 이 두 가지만 주기적으로 확인해도 시스템 데이터 때문에 맥이 멈춰 서는 일은 충분히 막을 수 있습니다.