맥 디스크가 꽉 찼는데 남은 게 없다고요? 루트의 로그 폴더를 확인하세요

Q: rtcreportingd는 무엇인가요?

/usr/libexec/rtcreportingd에 있는 Apple 시스템 데몬으로, com.apple.rtcreportingd에 의해 실행되며 root 권한으로 동작합니다. Apple은 이를 문서화하지 않았습니다. 내부 구조를 보면 HTTP로 Apple 백엔드와 통신하고 로컬 캐시를 유지하는 리포팅 서비스로 보입니다. 정상적인 Mac에도 존재하며, 그 자체가 문제는 아닙니다.

Q: 이것은 악성코드인가요?

아닙니다. 봉인된 시스템 볼륨 안의 launch 데몬이 실행하는, /usr/libexec에 있는 Apple의 바이너리입니다. 서명을 직접 확인할 수 있습니다.

Q: root의 Logs 폴더는 어느 정도 용량이 정상인가요?

정상적인 Mac이라면 작습니다 — 원래 여러분이 눈치챌 수 있는 폴더가 아닙니다. sudo du -sh /private/var/root/Library/Logs가 두 자리 수 기가바이트 이상의 값을 반환한다면 그것이 문제입니다. Apple이 공식적으로 정한 기준값은 없으며, 실질적인 기준은 Mac이 유휴 상태일 때 그 값이 계속 커지는지 여부입니다.

Q: Apple에 이 문제를 신고해야 하나요?

이 문제를 겪었다면 그렇게 하세요. sudo du -h -d 2 /private/var/root/의 출력, rtcreportingd와 fileproviderd의 CPU 수치, 그리고 어떤 동기화 클라이언트를 멈췄더니 해결되었는지를 포함하세요. Apple은 이에 관해 아무것도 공개하지 않았으며, 구체적인 신고들이 쌓여야 그것이 바뀝니다.

저장 공간 분석 도구는 /private/var/root에 숨겨진 수십 기가바이트를 놓칩니다. 폭주하는 RTCReporting 로그를 찾는 방법과, 대개 이를 유발하는 동기화 버그를 소개합니다.

대부분의 사람들이 손을 뻗는 모든 도구를 무력화하는 저장 공간 문제가 있습니다.

Mac이 디스크가 거의 꽉 찼다고 알려줍니다. 저장 공간 분석 도구를 열어 찾아낸 항목들을 모두 더해 보지만, 그 합계는 macOS가 사용 중이라고 표시하는 용량보다 수십 기가바이트 적습니다. Disk Utility는 스냅샷이 없다고 보고합니다. 앱을 삭제하고, 사진을 오프로드하고, 휴지통을 비워도 숫자는 거의 움직이지 않습니다. 재시동하면 한 시간 정도는 도움이 되지만, 그 뒤 공간은 다시 사라집니다.

파일들은 실제로 존재합니다. 여러분의 도구들이 이를 보지 못하는 이유는 그 파일들이 /private/var/root — 루트(root) 계정의 홈 디렉터리 — 안에 있고, 그 도구들은 모두 여러분의 사용자 권한으로 실행되기 때문입니다.

이 문제가 가장 심하게 나타나는 Mac에서는 그 대부분이 한 가지 원인입니다. 바로 rtcreportingd라는 시스템 데몬이 기록하는 로그 파일로, 그 양이 수십 기가바이트에 달합니다. Michael Tsai는 2026년 8월 21일, M4 MacBook Air에서 /private/var/root/Library/Logs 하나만으로 74GB를 차지하고 있었고, 이를 비운 지 단 하루 만에 폴더가 다시 27GB까지 늘어난 사례를 기록했습니다.

이 로그는 병 그 자체가 아닙니다. 아무도 온도계를 들여다보지 않을 때 멈춰버린 데몬이 어떤 모습으로 나타나는지를 보여주는 증상일 뿐입니다. 이 글에서는 이 공간을 찾는 방법, 작업 전체를 헛수고로 만드는 흔한 실수 없이 이를 되찾는 방법, 그리고 실제로 이를 발생시키는 프로세스를 찾는 방법을 다룹니다.

핵심 요약

/private/var/root는 여러분의 사용자 권한으로 실행되는 그 무엇에게도 보이지 않습니다. macOS 26.5.2에서 ls /private/var/root가 Permission denied를 반환하는 것을 직접 확인했습니다. 저장 공간 분석 도구, Finder, Disk Utility의 사용량 수치 모두 그 내부 내용을 놓칩니다.
rtcreportingd는 root 권한으로 실행되는 실제 Apple 시스템 데몬입니다. 해당 launchd 작업이 UserName => root를 선언하고 있음을 확인했으며, 이것이 바로 로그가 여러분이 아닌 root의 홈 디렉터리에 쌓이는 이유입니다.
보고된 용량은 수십 기가바이트에 달하며, 빠르게 다시 자랍니다. 기록된 사례에서는 74GB였고, 삭제 후 하루 만에 27GB로 되돌아왔습니다. 근본 원인이 여전히 실행 중이었기 때문입니다.
흔한 실수는 작업 전체를 헛수고로 만듭니다. sudo 권한으로 실행되는 GUI 도구로 파일을 삭제하면 그 파일들은 root의 보이지 않는 휴지통으로 이동합니다. 공간은 되찾아지지 않습니다. 즉시 삭제하거나, root의 휴지통을 비워야 합니다.
멈춰버린 동기화 클라이언트를 찾아보세요. 기록된 사례에서는 rtcreportingd와 fileproviderd가 각각 CPU 사용량 100%에 가깝게 고정되어 있었고, Dropbox를 종료하자 둘 다 멈췄습니다. fileproviderd는 클라우드 저장소의 File Provider 확장 기능을 구동하는 macOS 프로세스입니다.
/private/var/root 안의 것들을 무작위로 삭제하지 마세요. 로그와 캐시는 삭제해도 안전합니다. 그 안의 다른 것들은 그렇지 않으며, 이 글에서 어느 쪽이 어느 쪽인지 구체적으로 구분합니다.

저장 공간 분석 도구가 이를 찾지 못하는 이유

해결책에 앞서 먼저 그 원리부터 살펴봅니다. 이를 이해해야 다음에 엉뚱한 것을 쫓는 일을 막을 수 있기 때문입니다.

루트에도 홈 디렉터리가 있고, 데몬들이 이를 사용합니다

macOS에서 root 계정의 홈 디렉터리는 /private/var/root입니다. 대부분의 사람들은 이 디렉터리가 사실상 비어 있고, macOS 복구 모드에서 터미널을 실행할 때나 건드리게 되는 곳이라고 생각합니다. 하지만 그것은 수년 전부터 사실이 아니었습니다. root 권한으로 실행되면서 상태, 캐시, 로그를 저장하고 싶은 시스템 데몬들은 여러분 자신의 홈 디렉터리가 쓰는 것과 동일한 Library 구조를 사용해 이곳에 기록합니다.

/private/var/root/Library/Logs
/private/var/root/Library/Caches

이 디렉터리가 여러분에게 접근 금지되어 있다는 것은 명령어 하나로 확인할 수 있습니다. 터미널이 상승된 권한을 갖고 있지 않은 Mac에서 다음을 실행합니다.

ls /private/var/root

macOS 26.5.2(빌드 25F84)에서 이를 그대로 실행해 다음 결과를 얻었습니다.

ls: /private/var/root: Permission denied

이것은 단순한 Unix 권한 거부입니다 — root의 홈 디렉터리는 root에게만 허용되도록 모드가 제한되어 있습니다. 이는 TCC 개인정보 보호 기능이 아니며, 전체 디스크 접근 권한(Full Disk Access)으로 해결되는 것도 아닙니다. Dock에서 실행한 저장 공간 분석 도구는 여러분의 권한으로 실행되므로 파일 시스템도 여러분의 권한으로 탐색하며, 이 디렉터리 아래의 모든 것은 그 지도상의 구멍이 됩니다.

숫자가 서로 맞지 않는 이유

사람들이 흔히 말하는 증상은 “내 저장 공간 도구의 합계가 맞지 않는다”는 것이며, 그 이유가 바로 이것입니다. 기록된 사례에서 OmniDiskSweeper의 폴더 합계는 macOS가 보고한 사용량보다 대략 90GB 적었습니다.

Mac의 여유 공간 숫자가 맞지 않는 다른 이유들과 이를 구분해 둘 필요가 있습니다. 그런 이유는 여러 가지가 있고, 그중 이 버그는 단 하나에 불과하기 때문입니다.

Howard Oakley는 2026년 8월 21일 일반적인 산술 구조를 정리했으며, 자신의 Mac mini에서 나온 숫자가 이를 잘 보여줍니다.

출처	동일 볼륨에서 사용 중이라고 보고된 값
`diskutil apfs list` 컨테이너 차이	837.101 GB
볼륨별 Capacity Consumed 합계	837.027 GB
Finder에서 볼륨의 정보 가져오기(Get Info)	826.67 GB
Disk Utility	814.03 GB

네 개의 도구, 네 개의 숫자, 약 23GB의 편차, 그리고 아무런 이상도 없습니다. 이 차이는 컨테이너 대 볼륨 회계 방식, 제거 가능(purgeable) 공간, APFS 특수 파일 동작에서 비롯됩니다.

컨테이너 대 볼륨. 하나의 APFS 컨테이너는 여유 공간을 공유하는 여러 볼륨을 담고 있습니다. “Macintosh HD의 여유 공간”과 “컨테이너의 여유 공간”은 서로 다른 질문이고, 답도 다릅니다.
제거 가능 공간(Purgeable space). macOS는 캐시, 일부 스냅샷, 일부 다운로드된 콘텐츠 등 일부 항목을 필요 시 제거 가능한 것으로 표시합니다. Disk Utility 자체 도움말에는 “제거 가능(purgeable)으로 지정된 파일은 수동으로 삭제할 수 없지만, macOS가 공간이 필요할 때 이를 제거합니다”라고 나와 있습니다. Oakley는 자신의 Data 볼륨에서 47.04GB가 제거 가능 상태인 것을 확인했습니다.
특수 파일. APFS 클론 파일은 서로 달라지기 전까지는 저장 공간을 공유합니다. 스파스(sparse) 파일은 값이 있는 데이터만 저장합니다. 일부 시스템 파일은 압축되어 있습니다. 데이터리스(dataless) 파일은 데이터를 클라우드에 두고 필요할 때 실체화합니다. 여유 공간 회계는 지금 디스크에 실제로 있는 것을 기준으로 합니다.

이런 요인들 중 어느 것도 지속적으로 커지는, 설명되지 않는 90GB를 만들어내지는 않습니다. 여러분의 차이가 작고 안정적이라면 정상적인 회계 방식일 뿐입니다. 크고, Mac이 유휴 상태인데도 계속 커진다면, 여러분이 볼 수 없는 무언가가 파일을 쓰고 있는 것입니다.

줄어들지 않는 System Data, 해제되지 않는 스냅샷처럼 더 흔한 저장 공간 혼란에 관해서는 Mac의 System Data 저장 공간이 거대해지는 문제와 macOS 저장 공간 관리 가이드에서 따로 다루고 있습니다. 먼저 그쪽을 확인해 보세요. 이 글은 그런 설명들이 들어맞지 않는 경우를 다룹니다.

rtcreportingd의 정체

여기서는 우리가 아는 것의 한계를 솔직하게 밝혀두겠습니다. 조만간 인터넷에는 Apple이 한 번도 문서화한 적 없는 이 데몬에 대한 자신만만한 설명들이 넘쳐날 것이기 때문입니다.

우리가 직접 확인한 것, macOS 26.5.2(빌드 25F84) 기준:

이 실행 파일은 /usr/libexec/rtcreportingd에 존재하며 크기는 약 1.45MB입니다. launchd 작업은 /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist에 있으며, 내용은 다음과 같습니다.

{
  "EnablePressuredExit" => true
  "EnableTransactions" => true
  "Label" => "com.apple.rtcreportingd"
  "MachServices" => {
    "com.apple.rtcreportingd" => true
  }
  "ProgramArguments" => [
    0 => "/usr/libexec/rtcreportingd"
  ]
  "UserName" => "root"
}

여러분의 Mac에서도 직접 확인해 보세요 — 이 plist는 누구나 읽을 수 있습니다.

plutil -p /System/Library/LaunchDaemons/com.apple.rtcreportingd.plist

UserName => root가 로그가 어디로 가는지에 대한 설명의 전부입니다. root 권한으로 실행되며 ~/Library/Logs에 기록하는 데몬은 곧 /private/var/root/Library/Logs에 기록하는 것입니다. 특별히 이상한 점은 없습니다.

이 바이너리는 Swift로 작성되었으며, 내부 클래스 이름은 strings 명령으로 확인할 수 있습니다. 여기에는 BackendHTTP, TransparencyLog, StorebagCache, StorebagCoordinator, SessionCoordinator, XPCActivity, 그리고 — 이 부분을 주목하세요 — CacheCleanupActivity가 포함됩니다. Mach 서비스 이름에는 com.apple.rtcreporting, com.apple.rtcreporting.pathmonitor, com.apple.rtcreportingd.storebag이 포함됩니다.

우리가 알려드리지 않을 것은 “RTC”가 무엇의 약자인지, 혹은 이 데몬이 정확히 무엇을 보고하는지입니다. Apple은 이를 문서화하지 않았고, 우리 역시 약어의 뜻을 지어내 사실인 것처럼 제시하지는 않겠습니다. 클래스 이름들이 뒷받침하는 것은 소박한 설명뿐입니다. HTTP를 통해 Apple 백엔드와 통신하고, 상태를 로컬에 캐시하며, 네트워크 경로 가용성을 모니터링하고, 자체 캐시를 정리하는 예약된 작업을 갖고 있는 리포팅 또는 텔레메트리 서비스라는 것입니다.

마지막 부분이 흥미로운 대목입니다. 이 데몬에는 정리(cleanup) 로직이 있습니다. 로그가 수십 기가바이트까지 자라난다면, 합리적인 해석은 “Apple이 로그 순환을 깜빡했다”가 아니라 “데몬이 처리하고 정리할 수 있는 속도보다 더 빠르게 무언가가 이벤트를 만들어내고 있다”는 쪽입니다. 그리고 이는 그 이벤트를 만들어내는 대상 쪽을 가리킵니다.

경계를 분명히 해두자면, 이는 클래스 이름으로부터 도출한 추론일 뿐, Apple의 실제 구현에 대한 단정이 아닙니다. 관찰된 동작과 우연히 들어맞는 하나의 가설로 받아들이시기 바랍니다.

macOS에서 디스크 사용량을 분석 중인 터미널

공간 찾기

이 작업 전체에는 sudo가 필요하며, 각 명령을 실행하기 전에 반드시 내용을 읽어야 합니다.

1. 차이가 실제로 존재하는지 확인하기

먼저, macOS가 사용 중이라고 판단하는 용량을 확인합니다.

df -h / /System/Volumes/Data

최신 Mac에서는 두 줄이 출력됩니다. 시스템 볼륨은 봉인된 읽기 전용 스냅샷이고, 여러분의 데이터는 같은 컨테이너 안의 별도 볼륨에 있기 때문입니다. 테스트에 사용한 Mac에서는 다음과 같이 나왔습니다.

Filesystem        Size    Used   Avail Capacity  Mounted on
/dev/disk3s1s1   926Gi    12Gi   331Gi     4%    /
/dev/disk3s5     926Gi   568Gi   331Gi    64%    /System/Volumes/Data

두 줄 모두 동일한 Size와 Avail을 보고한다는 점에 주목하세요 — 이는 볼륨별 할당량이 아니라 공유되는 컨테이너의 여유 공간입니다. 앞서 설명한 컨테이너 대 볼륨의 구분이 구체적으로 드러난 예입니다.

그다음 스냅샷을 확인해서 그 가능성을 배제합니다.

diskutil apfs listSnapshots /System/Volumes/Data

그리고 컨테이너 전체 관점도 확인합니다.

diskutil apfs list

스냅샷이 미미한데도 컨테이너의 Capacity In Use가 저장 공간 분석 도구가 찾아낸 값보다 훨씬 높다면, 보이지 않는 파일 문제를 안고 있는 것입니다.

2. 루트의 홈 디렉터리 용량 측정하기

이 명령이 바로 그것을 찾아냅니다.

sudo du -h -d 2 /private/var/root/

-d 2는 탐색 깊이를 두 단계로 제한합니다. 전체 순회를 기다리지 않고도 Library/Logs와 Library/Caches 중 어느 쪽이 범인인지 파악하기에 충분합니다. 큰 문제를 안고 있는 기기라면 1~2분 정도 걸릴 것으로 예상하세요.

한 단계 더 깊이 들어가 가장 심각한 항목들을 정렬된 형태로 보려면 다음과 같이 합니다.

sudo du -h -d 3 /private/var/root/Library | sort -h | tail -20

정상적인 Mac이라면 이 합계는 작습니다 — 기가바이트가 아니라 메가바이트 단위입니다. /private/var/root/Library/Logs가 뒤에 “G”가 붙고 앞자리가 두 자리 이상인 숫자로 돌아온다면, 그것이 바로 사라진 공간입니다.

3. 내부를 확인하기

무엇이든 삭제하기 전에 먼저 살펴봅니다.

sudo ls -la /private/var/root/Library/Logs
sudo du -h -d 1 /private/var/root/Library/Logs | sort -h | tail

기록된 사례에서 그 내용물은 “거의 전부가 RTCReporting에서 나온 것”이었습니다. 여러분의 경우 다른 무언가가 대부분을 차지하고 있다면, 취해야 할 조치는 달라집니다 — 이 글에서 다루는 진단 방식 자체는 여전히 적용되지만, 범인은 다른 하위 시스템이 될 것입니다.

4. GUI 대안

창(윈도) 형태로 확인하고 싶다면 OmniDiskSweeper가 무료이며, 원본 보고서에서 이 문제를 드러낸 도구이기도 합니다. 중요한 점은 root의 홈 디렉터리를 보려면 반드시 상승된 권한으로 다시 실행해야 한다는 것입니다. 일반적으로 실행하면 다른 모든 도구와 마찬가지로 불완전한 그림만 보여줍니다.

저희의 저장 공간 분석 도구 모음에서 여러 선택지를 다루고 있지만, 동일한 한계가 그 모두에 적용된다는 점을 알아두세요. 도구가 root 권한으로 실행되지 않는 한, 이 공간은 그 도구에게 보이지 않습니다.

공간 되찾기 — 그리고 작업을 전부 헛수고로 만드는 실수

여기 함정이 하나 있는데, 꽤나 교묘한 함정입니다.

sudo 권한으로 실행 중인 GUI 도구로 이 파일들을 삭제하면, 그 도구는 평소 하던 대로 동작합니다. 파일을 휴지통으로 옮기는 것입니다. 하지만 그 프로세스가 root 권한으로 실행되고 있기 때문에, 그것은 root의 휴지통, 즉 /private/var/root/.Trash입니다. 이는 여러분의 Dock에 나타나지 않으며, 여러분이 비워야겠다는 생각조차 하지 못할 곳입니다. 파일은 여전히 디스크에 남아 있습니다. 여유 공간은 변하지 않습니다. 여러분은 삭제가 제대로 되지 않았다고 결론짓게 됩니다.

특히 OmniDiskSweeper에서는 Option 키를 누른 채로 있으면 Delete가 Delete Immediately(즉시 삭제)로 바뀝니다.

터미널에서는 로그 내용을 직접 삭제합니다.

sudo rm -rf /private/var/root/Library/Logs/*

이 명령을 실행하기 전에 반드시 읽어보세요. 이 명령은 root의 Logs 디렉터리 내용물만 제거하며, 그 외에는 아무것도 건드리지 않습니다. 경로를 줄여 쓰지 마세요. 슬래시 앞에 공백을 넣지 마세요.

그런 다음 이전 시도에서 root의 휴지통에 남아 있는 것이 있는지 확인합니다.

sudo du -sh /private/var/root/.Trash

있다면 다음을 실행합니다.

sudo rm -rf /private/var/root/.Trash/*

root의 홈 디렉터리에 있는 캐시 역시 일반적으로 안전하게 지울 수 있습니다 — 정의상 재생성 가능한 것들이기 때문입니다.

sudo du -h -d 1 /private/var/root/Library/Caches | sort -h | tail

건드리지 말아야 할 것. /private/var/root 자체를 삭제하지 마세요. /private/var/root/Library를 통째로 삭제하지 마세요. 키체인, 설정 파일, 알아보지 못하는 것들을 함부로 제거하지 마세요. 로그와 캐시만이 안전한 범주이며, 그 안의 다른 모든 것은 이유가 있어 그것을 그곳에 둔 시스템 구성 요소의 소유물입니다.

작업이 끝나면 재시동합니다. 그런 다음 df -h로 다시 확인해서 공간이 실제로 되돌아왔는지 확인합니다.

이제 원인을 찾아봅시다

삭제로 끝낸다면 공간은 되돌아왔다가 다시 사라집니다. 기록된 사례에서는 재시동 후 몇 분 만에 5GB로, 하루 만에 27GB로 되돌아갔습니다.

CPU를 지켜보기

**활성 상태 보기(Activity Monitor)**를 열고 % CPU 기준으로 정렬한 다음, 두 프로세스를 찾습니다.

rtcreportingd — 로그를 기록하는 데몬
fileproviderd — 클라우드 저장소의 File Provider 확장 기능을 구동하는 macOS 프로세스

기록된 사례에서는 Mac이 유휴 상태인데도 둘 다 지속적으로 CPU 사용량 100%에 가깝게 고정되어 있었습니다.

터미널에서는 다음과 같이 확인합니다.

ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

이 두 프로세스는 정상적인 어떤 Mac에서도 존재하고 실행됩니다 — 저장 공간 문제가 전혀 없는 테스트 기기에서도 둘 다 실행 중임을 확인했습니다. 이들이 존재하는 것 자체는 정상입니다. 지속적으로 CPU를 사용하는 것은 정상이 아닙니다. 동기화가 진행 중일 때 몇 퍼센트 정도 사용하는 것은 정상적인 범위입니다. Mac을 아무도 건드리지 않는데도 90~100%에 머물러 있다면 그것이 신호입니다.

로그가 자라나는 것을 지켜보기

가장 직접적인 확인 방법은 두 번 측정해보는 것입니다.

sudo du -sh /private/var/root/Library/Logs

Mac을 유휴 상태로 10분간 둔 다음 다시 실행해 보세요. 정상적인 Mac이라면 숫자가 의미 있게 움직이지 않습니다. 여러분이 아무것도 하지 않는데도 눈에 띄게 늘어난다면, 무언가가 반복(루프)에 빠져 있는 것입니다.

먼저 클라우드 동기화를 의심하기

fileproviderd가 결정적인 단서입니다. 이는 Dropbox, OneDrive, Google Drive, Box, iCloud Drive가 모두 Finder에서 클라우드 파일을 표시하는 데 사용하는 최신 메커니즘인 File Provider 확장 기능을 구동하는 시스템 프로세스입니다. 이 프로세스가 지속적으로 CPU를 태우고 있다면, 그중 하나의 확장 기능이 멈춰 있는 것입니다.

기록된 사례에서 그 클라이언트는 Dropbox였습니다. 해당 Mac에서는 약 1년 동안 이상 동작이 있었는데, 설정한 대로 파일을 오프라인으로 유지하지 않았고, 아무것도 바뀌지 않았는데도 계속 동기화하는 것처럼 보였습니다. Dropbox를 종료하자 CPU 사용량과 로그 증가가 즉시 멈췄습니다.

여러분의 Mac에서 이를 테스트하려면 동기화 클라이언트를 하나씩 종료하며 관찰하세요. 동기화를 일시정지하는 것이 아니라 클라이언트 자체를 완전히 종료해야 합니다 — 메뉴 막대 아이콘에서 Quit(종료) — 일시정지된 확장 기능은 여전히 로드되어 있을 수 있기 때문입니다.

# after quitting a sync client, check whether the load dropped
ps -Ao pid,pcpu,comm | grep -E 'rtcreportingd|fileproviderd'

하나의 클라이언트를 종료했을 때 두 프로세스가 모두 유휴 상태로 떨어진다면, 원인을 찾은 것입니다.

동기화 클라이언트에 대해 할 수 있는 일

조치는 대략 수고가 적은 순서로 다음과 같습니다.

업데이트합니다. File Provider 확장 기능의 버그는 흔하고, 자주 수정됩니다. 다른 무엇보다 먼저 업데이트가 있는지 확인하세요.
로그아웃 후 다시 로그인합니다. 이는 확장 기능의 로컬 상태를 다시 구성하며, 놀라울 만큼 많은 동기화 멈춤 사례를 해결합니다.
클라이언트를 제거하고 다시 설치합니다. 더 번거롭지만 더 철저한 방법입니다.
데이터를 다른 곳으로 옮깁니다. 기록된 사례에서는 결국 iCloud Drive로 이전하는 것으로 마무리되었습니다. Dropbox가 이전을 위해 파일을 안정적으로 다운로드하지 못한다는 것이 드러난 뒤였고, 결국 저자는 Dropbox의 웹 인터페이스에서 폴더를 다운로드하는 방식으로 대신했습니다. 이후 iCloud Drive는 “모든 것을 빠르게 업로드한 뒤 CPU를 전혀 사용하지 않는 상태로 정착했습니다.”

마지막 부분은 솔직히 짚고 넘어갈 가치가 있습니다. 원본 클라이언트가 고장 난 상태에서 클라우드 서비스 간 이전을 하는 것은 실제로 고통스러운 일이며, 웹 인터페이스가 가장 신뢰할 수 있는 내보내기 경로일 수 있습니다. 저희의 iCloud Drive 가이드에서는 이전 대상 쪽을 다루고 있으며, iCloud Drive 자체가 이상 동작을 보인다면 iCloud Drive 자동 다운로드 버그라는 별도의 알려진 문제도 있습니다.

Dropbox만 유독 문제라는 뜻은 아닙니다. 그저 기록된 사례에서의 클라이언트였을 뿐입니다. 어떤 File Provider 확장 기능이든 멈출 수 있으며, 어느 것을 사용하든 진단 방법은 동일합니다.

높은 CPU 사용량을 보여주는 활성 상태 보기

저장 공간이 숨어 있는 또 다른 곳들

root의 홈 디렉터리는 거의 아무도 확인하지 않는 곳이지만, 사용자 수준 도구가 놓치는 유일한 곳은 아닙니다. 여러분의 차이가 /private/var/root에 있지 않다면, 숫자가 거짓말을 하고 있다고 결론짓기 전에 다음 항목들을 차례로 확인해 보세요.

다른 데몬들의 root 소유 데이터. /private/var/root는 root의 홈 디렉터리가 있는 곳이지만, 시스템 구성 요소들은 /private/var/db, /private/var/folders, /Library/Logs 아래에도 기록합니다. 같은 방식으로 측정해 보세요.

sudo du -h -d 1 /private/var/db | sort -h | tail
sudo du -h -d 1 /Library/Logs | sort -h | tail
sudo du -sh /private/var/folders

/private/var/folders에는 사용자별 임시 및 캐시 컨테이너가 들어 있으며, 정상적으로도 수 기가바이트에 이를 수 있습니다. 이는 macOS가 관리하는 영역으로 일반적으로는 그대로 두어야 하며, 재시동하면 휘발성 부분은 정리됩니다.

로컬 Time Machine 스냅샷. 가장 많이 의심받지만 실제 범인인 경우는 가장 드문 원인입니다. 짐작하지 말고 직접 확인하세요.

tmutil listlocalsnapshots /
diskutil apfs listSnapshots /System/Volumes/Data

스냅샷이 정말로 문제라면, macOS는 공간 압박 상황에서 이를 자동으로 정리(thin)합니다. 더 깊이 있는 사례는 저희의 Time Machine 문제 해결 가이드에서 다루고 있습니다.

다른 사용자의 홈 디렉터리. 말하고 나면 당연해 보이지만 실제로는 보이지 않습니다 — Mac의 두 번째 계정에 200GB의 동영상이 있어도, 여러분의 권한으로 실행되는 저장 공간 도구는 이를 보여주지 않습니다. sudo du -h -d 1 /Users 한 줄이면 답을 알 수 있습니다.

실행 중인 프로세스가 열어둔 파일. 삭제되었지만 해제되지 않은 공간으로, 어떤 프로세스가 여전히 그 파일 디스크립터를 붙들고 있기 때문입니다. 재시동하면 사라지는 차이로 나타납니다.

sudo lsof / 2>/dev/null | grep -i deleted | head

Mail의 로컬 저장소, iOS 기기 백업, Xcode. 개발자나 Mail을 많이 쓰는 사용자의 Mac에서 크기가 크고 잊혀지기 쉬운 대표적인 세 디렉터리입니다.

du -sh ~/Library/Mail
du -sh ~/Library/Application\ Support/MobileSync/Backup
du -sh ~/Library/Developer/Xcode/{DerivedData,iOS\ DeviceSupport,Archives} 2>/dev/null

이들은 모두 여러분의 사용자 권한으로 읽을 수 있으므로, 저장 공간 분석 도구가 이를 찾아내긴 합니다 — 다만 긴 목록 속에 묻혀버릴 뿐입니다. sudo로 넘어가기 전에 확인해 볼 가치가 있습니다.

실체화된 클라우드 플레이스홀더 파일. 어떤 동기화 클라이언트에서든 “온라인 상태로만 유지” 설정을 사용하고 있다면, 버그나 전체 텍스트 검색으로 인해 조용히 모든 파일이 다운로드될 수 있습니다. 이는 이 글에서 다루는 것과 같은 종류의 오작동이며, 대개 동기화 폴더 자체가 꾸준히 커지는 형태로 나타납니다.

이 문제는 얼마나 흔할까요?

솔직한 답변은, 우리도 모른다는 것입니다. 이에 대해 글을 쓰는 다른 누구도 마찬가지입니다.

공개된 기록으로 존재하는 것은 구체적인 숫자와 구체적인 해결 방법을 담은 1차 경험담, RTCReporting 저장 공간에 관한 Apple Support Community 스레드, 그리고 무엇이 저장 공간을 차지하고 있는지 묻는 사용자들의 Reddit 스레드입니다. 이 정도면 이 문제가 실재하고 재현 가능하다는 것을 입증하기에는 충분하지만, 얼마나 많은 비율의 Mac이 영향을 받는지를 말하기에는 충분하지 않습니다.

우리가 직접 확인한 결과로부터 말할 수 있는 것은 이렇습니다. rtcreportingd는 저장 공간 문제가 전혀 없는 일반적인 Mac에서도 실행되며, 그곳의 로그는 별다를 것이 없고, 이 데몬은 대부분의 경우 제대로 작동하는 것으로 보이는 정리 로직을 갖고 있습니다. 이것은 기본 동작이 아니라 하나의 오작동 모드입니다. 여러분의 Mac에서 저장 공간 숫자가 맞아떨어진다면, 고칠 것은 아무것도 없습니다.

Apple은 이에 관해 어떤 지원 문서도 공개하지 않았고, 이를 인정한 적도 없으며, 문서화된 수정 사항을 내놓은 적도 없습니다. 이 문제를 겪었다면, Apple에 피드백을 제출하는 5분은 그럴 가치가 있습니다 — 인정받지 못한 문제는 계속 인정받지 못한 채로 남기 때문입니다.

흔한 문제 해결하기

`sudo du`가 끝나지 않아요

크거나 심하게 조각난 디렉터리 트리에서는 정상적인 현상입니다. 먼저 -d 1을 사용해 어느 최상위 폴더가 큰지 찾은 다음, 그 폴더로만 들어가세요. 관심 있는 디렉터리를 이미 알고 있다면 디스크 전체에 대해 du를 실행하는 것은 피하세요.

로그를 삭제했는데 여유 공간이 변하지 않아요

휴지통 문제입니다. sudo du -sh /private/var/root/.Trash로 확인하고 sudo rm -rf /private/var/root/.Trash/*로 비우세요. GUI 도구를 사용한 사람이라면 거의 대부분 여기에 해당합니다.

두 번째 가능성은 삭제된 파일을 어떤 프로세스가 여전히 열어두고 있는 경우로, 이럴 때는 그 프로세스가 종료될 때까지 공간이 해제되지 않습니다. Mac을 재시동하고 다시 확인하세요.

하루 만에 공간이 다시 줄어들었어요

원인을 찾지 못했다면 예상된 결과입니다. 로그를 삭제하는 것은 증상만 다스리는 것일 뿐입니다. 활성 상태 보기 단계로 돌아가 무엇이 반복되고 있는지 찾으세요.

클라우드 동기화 클라이언트가 없는데도 `rtcreportingd`가 CPU를 쓰고 있어요

그렇다면 원인은 다른 무언가입니다. 활성 상태 보기를 CPU 기준으로 정렬해 다른 어떤 것이 바쁘게 돌아가고 있는지 살펴보세요. 통합 로그(unified log)에서 데몬 자체의 활동도 확인할 수 있습니다.

log show --predicate 'process == "rtcreportingd"' --last 1h --info | head -50

통합 로그 조회는 실제로 기록된 것만 반환하며, 로그 데이터는 시간이 지나면 소멸된다는 점을 알아두세요 — 긴 기간을 조회하면 아무것도 나오지 않는 것이 정상일 수 있습니다.

디스크 유틸리티의 응급처치는 디스크가 정상이라고 해요

당연히 그렇게 나옵니다. 이것은 파일 시스템 손상이 아닙니다. 응급처치(First Aid)는 메타데이터의 일관성을 검사할 뿐이며, 크고 유효한 파일로 가득 찬 디렉터리는 완벽하게 일관성이 있는 상태입니다.

rtcreportingd를 그냥 비활성화하면 안 되나요?

저희라면 그렇게 하지 않겠습니다. 이는 System Integrity Protection이 적용된 Mac 위의 Apple 시스템 데몬이며, 증상을 우회하기 위해 시스템 launch 데몬을 비활성화하면 나중에 눈에 덜 띄는 두 번째 문제를 낳는 경향이 있습니다. 대신 이를 유발하는 프로세스를 고치세요. 식별 가능한 원인 없이 데몬이 오작동한다면, 이는 우회할 대상이 아니라 신고할 가치가 있는 Apple의 버그입니다.

지금 당장 공간이 필요해요

진단하는 동안 바로, 안전하게 할 수 있는 조치는 다음과 같습니다. 여러분 자신의 휴지통을 비우고, 위에서 설명한 대로 root의 휴지통을 비우고, root의 Logs 내용을 삭제하고, sudo du -h -d 1 /private/var/root/Library/Caches를 확인하세요. 이 조치들을 합치면 원인을 찾는 동안 Mac을 다시 쓸 수 있을 만큼의 공간이 확보되는 경우가 많습니다. 이것이 특히 macOS 업데이트를 가로막고 있다면, 저희의 공간 부족으로 인한 업데이트 실패 가이드에서 대처 방법을 다루고 있습니다.

FAQ

`/private/var/root`는 무엇인가요?

macOS에서 root 계정의 홈 디렉터리입니다. root만 읽을 수 있으며, 이것이 바로 여러분의 사용자 권한으로 실행되는 도구들이 그 내부를 볼 수 없는 이유입니다. root 권한으로 실행되는 시스템 데몬들은 여러분 자신의 홈 폴더와 동일한 Library 구조를 사용해 이곳에 로그, 캐시, 상태를 저장합니다.

Finder나 저장 공간 앱이 왜 이 파일들을 못 보나요?

그것들이 여러분의 권한으로 실행되고, 그 디렉터리의 Unix 권한이 여러분의 사용자 계정을 제외하기 때문입니다. 이는 전체 디스크 접근 권한으로 풀 수 있는 개인정보 보호 기능이 아니라, 그냥 평범한 파일 권한입니다. GUI 도구가 그 디렉터리를 탐색하려면 상승된 권한으로 다시 실행해야 합니다.

`rtcreportingd`는 무엇인가요?

/usr/libexec/rtcreportingd에 있는 Apple 시스템 데몬으로, com.apple.rtcreportingd에 의해 실행되며 root 권한으로 동작합니다. Apple은 이를 문서화하지 않았습니다. 내부 구조를 보면 HTTP로 Apple 백엔드와 통신하고 로컬 캐시를 유지하는 리포팅 서비스로 보입니다. 정상적인 Mac에도 존재하며, 그 자체가 문제는 아닙니다.

이것은 악성코드인가요?

아닙니다. 봉인된 시스템 볼륨 안의 launch 데몬이 실행하는, /usr/libexec에 있는 Apple의 바이너리입니다. 서명을 직접 확인할 수 있습니다.

codesign -dv --verbose=2 /usr/libexec/rtcreportingd

root의 Logs 폴더는 어느 정도 용량이 정상인가요?

정상적인 Mac이라면 작습니다 — 원래 여러분이 눈치챌 수 있는 폴더가 아닙니다. sudo du -sh /private/var/root/Library/Logs가 두 자리 수 기가바이트 이상의 값을 반환한다면 그것이 문제입니다. Apple이 공식적으로 정한 기준값은 없으며, 실질적인 기준은 Mac이 유휴 상태일 때 그 값이 계속 커지는지 여부입니다.

Mac 정리 앱으로 이 문제를 고칠 수 있나요?

거의 확실히 그렇지 않습니다. 여러분의 저장 공간 분석 도구가 이를 놓쳤던 것과 같은 이유입니다. 그 정리 앱이 권한을 상승시켜 root의 홈 디렉터리를 특별히 탐색하지 않는 한, 그 파일들을 볼 수 없습니다. 그리고 설령 그 파일들을 제거하는 정리 앱이 있다 해도, 다시 생기는 것을 막지는 못합니다. 원인이 쌓인 쓰레기가 아니라 반복되는 프로세스이기 때문입니다.

특정 Mac이나 macOS 버전에서만 발생하나요?

단정할 만큼 충분한 공개 데이터가 없습니다. 기록된 사례는 M4 MacBook Air였습니다. 저희는 macOS 26.5.2에서 해당 데몬과 권한 동작을 확인했습니다. 이 메커니즘 자체에는 특정 칩이나 특정 macOS 버전에만 해당하는 요소가 전혀 없습니다 — root는 macOS가 존재해온 이래로 줄곧 홈 디렉터리를 가지고 있었습니다.

Apple에 이 문제를 신고해야 하나요?

이 문제를 겪었다면 그렇게 하세요. sudo du -h -d 2 /private/var/root/의 출력, rtcreportingd와 fileproviderd의 CPU 수치, 그리고 어떤 동기화 클라이언트를 멈췄더니 해결되었는지를 포함하세요. Apple은 이에 관해 아무것도 공개하지 않았으며, 구체적인 신고들이 쌓여야 그것이 바뀝니다.

결론

이 문제가 이토록 답답한 이유는, Mac 저장 공간에 대해 여러분이 가진 모든 직관이 여기서는 통하지 않기 때문입니다. 파일들은 여러분이 찾을 수 있는 폴더 안에 있지 않습니다. 스냅샷도 아닙니다. 저장 공간 패널이 말하는 의미의 System Data도 아닙니다. 앱을 삭제해도 소용없고, 숫자는 맞아떨어지지 않으며, 이를 보여줄 수 있는 유일한 도구는 여러분이 sudo로 실행할 생각조차 하지 못했던 바로 그 도구입니다.

어디를 봐야 하는지 일단 알고 나면 10분이면 끝나는 작업입니다. du로 /private/var/root를 측정하고, 로그를 삭제하고, root의 휴지통을 비운 다음 — 실제로 중요한 부분인 — 다시 채우고 있는 프로세스를 찾을 때까지 활성 상태 보기를 지켜보세요. CPU 목록에서 fileproviderd가 rtcreportingd 옆에 나란히 있다는 점을 감안하면, 열에 아홉은 몇 달째 조용히 고장 나 있던 클라우드 동기화 클라이언트입니다.

그리고 여러분의 Mac에서 저장 공간 숫자 차이가 90GB가 아니라 몇 기가바이트 정도라면, 안심하세요. 그것은 그저 APFS가 원래 그렇게 동작하는 것일 뿐이며, Howard Oakley의 산술이 그 전부를 설명해 줍니다.

출처: Michael Tsai, “Huge RTCReporting Logs and Dropbox”, 2026년 8월 21일 · The Eclectic Light Company, “The arithmetic of free space”, 2026년 8월 21일 · Apple Support Community 스레드 254838127 (RTCReporting) · Apple, Disk Utility 도움말 (purgeable space) · macOS 26.5.2(빌드 25F84)에서 2026년 8월 22일에 ls, plutil, strings, df, ps를 사용해 직접 검증.