Xcode DerivedData와 개발자 캐시 안전하게 삭제하기

DerivedData는 무엇이고 왜 이렇게 커지나요

DerivedData는 Xcode가 소스 코드에서 파생시킨 모든 것을 보관하는 곳입니다. 중간 빌드 오브젝트, 컴파일된 산출물, 모듈 캐시, 코드 완성과 정의로 이동에 쓰이는 심벌 인덱스, 빌드 로그가 들어 있습니다. 기본 위치는 ~/Library/Developer/Xcode/DerivedData이며, 그동안 열어 본 프로젝트나 워크스페이스마다 하위 폴더가 하나씩 생깁니다.

커지는 데는 구조적인 이유가 있습니다. Xcode는 여는 프로젝트마다 — 한 번 빌드하고 다시는 안 건드린 일회성 클론까지 포함해 — DerivedData 폴더를 만들고, 그 어느 것도 삭제하지 않습니다. 각 폴더는 구성과 대상별(Debug와 Release, 시뮬레이터와 실기기)로 빌드 산출물을 따로 보관하므로, 중간 규모 프로젝트 하나가 수 GB를 차지할 수 있고, 폴더 전체는 현역 개발 머신에서 20-50 GB에 이르는 게 보통입니다.

안에 든 것은 정의상 전부 다시 만들 수 있습니다 — "derived(파생됨)"라는 이름 그대로입니다. DerivedData를 지워도 소스 코드, 프로젝트 설정, 버전 관리 아래의 그 무엇도 건드리지 않습니다. 유일한 대가는 시간입니다. 각 프로젝트의 다음 빌드는 완전한 클린 빌드가 되고, 인덱싱이 몇 분간 배경에서 다시 돌아갑니다.

DerivedData 삭제하기

방법은 세 가지이고 결과는 같습니다. Xcode의 Clean Build Folder 명령(Product > Clean Build Folder, 또는 Command-Shift-K)은 현재 열린 프로젝트의 빌드 산출물만 지웁니다 — 이상한 빌드 오류를 고칠 땐 유용하지만, 디스크 용량엔 거의 티가 나지 않습니다. 진짜 공간을 되찾으려면 DerivedData 폴더 자체를 삭제해야 합니다.

프로젝트별로 지우는 것이 정밀한 방법입니다. 매일 빌드하는 두세 개 프로젝트의 DerivedData는 남기고 나머지 폴더만 지우세요. 통째로 지우는 것은 빠른 방법이고, 그것도 괜찮습니다 — 다만 모든 프로젝트에서 한꺼번에 전체 재빌드 비용을 치르게 됩니다.

1. 먼저 Xcode를 종료하세요. Xcode가 실행 중일 때 DerivedData를 지우면 인덱서가 꼬일 수 있고, Xcode가 열어 둔 파일은 깔끔하게 지워지지 않을 수 있습니다.
2. 폴더 위치를 찾으세요. Xcode에서 Settings > Locations를 열고 DerivedData 경로 옆의 작은 화살표를 클릭하면 Finder에서 열립니다. 또는 Finder에서 Command-Shift-G를 누르고 ~/Library/Developer/Xcode/DerivedData를 직접 입력하세요.
3. 프로젝트 하위 폴더를 크기순으로 정렬해 지울 것을 선택하고(전부 지우려면 Command-A), 휴지통으로 옮기세요. 휴지통을 먼저 거치는 것이 더 안전한 습관입니다 — 마음이 바뀌면 즉시 복원할 수 있으니까요.
4. 터미널로 하려면 rm -rf ~/Library/Developer/Xcode/DerivedData 한 줄로 전부 삭제됩니다. 아주 큰 폴더는 Finder보다 빠르지만, 사용 전에 아래 안내를 꼭 읽으세요.
5. Xcode를 다시 열고 빌드하세요. 각 프로젝트의 첫 빌드는 눈에 띄게 오래 걸리고, 활동 표시줄에 "Indexing"이 한동안 표시됩니다 — 둘 다 한 번만 치르는 비용입니다.

rm -rf는 조심하세요. 휴지통을 거치지 않고 영구 삭제하며 되돌릴 수 없습니다. 경로를 정확히 입력하고, 이 작업에 sudo는 절대 쓰지 마세요. 터미널이 익숙하지 않다면 Finder 방식이 같은 일을 되돌릴 수 있게 해 줍니다.

오래된 시뮬레이터 런타임 정리하기

시뮬레이터는 보통 DerivedData 다음으로 큰 개발자 공간 대식가입니다. 그동안 내려받은 iOS, watchOS, tvOS 런타임 하나하나가 5-8 GB를 차지하고, 시뮬레이터 기기마다 ~/Library/Developer/CoreSimulator/Devices 아래에 자기 데이터 폴더를 둡니다. Xcode 업그레이드를 몇 번 거쳤다면, 몇 년 전에 지원을 끝낸 iOS 버전의 런타임이 남아 있을 가능성이 큽니다.

가장 빠른 성과는 내장 정리 명령입니다. 터미널에서 xcrun simctl delete unavailable을 실행하세요. 런타임이 더 이상 설치되어 있지 않은 시뮬레이터 기기 — 옛 Xcode 버전이 남긴 고아들 — 를 모두 삭제하고, 아직 쓸 수 있는 것은 하나도 건드리지 않습니다.

런타임 자체는 Xcode의 Settings > Platforms(구버전 Xcode에서는 Components)에서 관리합니다. 설치된 시뮬레이터 런타임이 크기와 함께 표시되니, 오래된 것을 선택해 삭제하세요. 구버전 OS에서 적극적으로 테스트하는 게 아니라면 플랫폼마다 최신 런타임 하나만 남기면 됩니다.

Window > Devices and Simulators에서 시뮬레이터 기기를 개별적으로 정리할 수도 있습니다. Simulators 탭으로 전환해, 전혀 쓰지 않는 기기 — 옛 테스트 데이터가 든 중복 iPhone 모델 여섯 대 같은 — 를 마우스 오른쪽 클릭하고 Delete를 선택하세요. 각 기기에 저장된 데이터와 앱도 함께 사라집니다.

아카이브, 기기 지원 파일, 캐시

아카이브는 배포용 빌드를 만들 때(Product > Archive) ~/Library/Developer/Xcode/Archives에 하나씩 쌓입니다. 아카이브마다 완전한 앱 빌드와 dSYM 디버그 심벌이 들어 있어 흔히 개당 100 MB에서 1 GB에 이릅니다. 지우기 전에 한 가지를 알아 두세요. 안에 든 dSYM이 바로 그 빌드의 충돌 보고서를 기호화(symbolicate)할 수 있게 해 주는 것입니다. App Store나 TestFlight에 아직 살아 있는 버전의 아카이브는 남기고(또는 App Store Connect에 dSYM이 있는지 확인하고) 나머지를 지우세요 — 가장 안전한 경로는 Xcode의 Organizer(Window > Organizer > Archives)에서 맥락을 보며 검토·삭제하는 것입니다.

iOS DeviceSupport(~/Library/Developer/Xcode/iOS DeviceSupport)는 그동안 연결했던 모든 iPhone·iPad에서 Xcode가 복사해 온 디버깅 심벌을 보관합니다 — iOS 버전마다 폴더 하나씩, 보통 각 2-5 GB입니다. 이제 어떤 기기도 쓰지 않는 iOS 버전의 폴더는 순전한 짐이니 지우세요. 그 버전의 기기를 다시 연결하면 Xcode가 심벌을 다시 복사할 뿐입니다("Preparing debugger support"가 한 번 표시됩니다). watchOS와 tvOS 기기용 형제 폴더도 있습니다.

Xcode 자체 캐시는 ~/Library/Caches/com.apple.dt.Xcode에, 시뮬레이터 캐시는 ~/Library/Developer/CoreSimulator/Caches에 있습니다 — 둘 다 Xcode와 Simulator 앱이 실행 중이 아닐 때 지워도 안전하고, 필요할 때 다시 만들어집니다.

패키지 관리자 캐시 (SwiftPM, CocoaPods, npm, Homebrew)

패키지 관리자는 다음 설치를 빠르게 하려고 그동안 내려받은 모든 의존성을 보관합니다. 훌륭한 엔지니어링이지만 디스크 위생에는 나쁩니다. 캐시는 늘기만 하고, 몇 년치 프로젝트를 거친 머신에서는 조용히 10-20 GB까지 쌓입니다. 전부 지워도 안전합니다 — 최악의 경우라 해 봐야 다음 설치 때 패키지를 다시 내려받는 것뿐입니다.

Swift Package Manager는 내려받은 패키지를 ~/Library/Caches/org.swift.swiftpm에 캐시하고, 각 프로젝트의 체크아웃은 해당 DerivedData 폴더 안에도 있습니다 — 그래서 DerivedData를 지우면 그것들은 이미 함께 지워집니다. 공유 캐시는 Finder에서 지우거나 해당 경로에 rm -rf를 쓰면 됩니다.

CocoaPods는 내려받은 pod을 ~/Library/Caches/CocoaPods에 보관합니다. 깔끔하게 비우는 방법은 내장 명령인 pod cache clean --all입니다. 프로젝트의 Pods 폴더는 그대로이고, 다운로드 캐시만 사라집니다.

npm 캐시는 ~/.npm에 있으며 JavaScript를 많이 쓰는 머신에서는 수 GB에 이를 수 있습니다. npm cache clean --force로 비우세요(캐시가 자가 복구형이라 원래 비울 필요가 없다는 이유로 npm이 플래그를 요구하지만 — 지워도 여전히 완전히 안전합니다). pnpm 사용자는 대신 pnpm store prune을 실행하면 됩니다.

Homebrew는 오래된 다운로드와 구버전 패키지를 쌓아 둡니다. brew cleanup은 구버전과 묵은 다운로드를 지우고, brew cleanup --prune=all은 다운로드 캐시 전체까지 비웁니다. 무엇이 지워질지 목록만 먼저 보고 싶다면 brew cleanup -n을 실행하세요.

자동화하기

위의 모든 방법이 통하지만, 개발자 찌꺼기 정리는 쳇바퀴 같습니다. DerivedData는 평소처럼 일하면 일주일 만에 돌아오고, 캐시는 다시 차오르고, Xcode 업데이트마다 낙오된 런타임이 하나씩 또 늘어납니다. 여섯 가지 수동 절차를 매달 반복하고 싶지 않다면, 바로 이 부분이 자동화할 가치가 있는 곳입니다 — 말없이 몽땅 지우는 대신 판단 근거를 보여 주는 도구로요.

AskClean은 개발자 파일을 일급 분류로 다룹니다. 한 번의 스캔으로 Xcode DerivedData를 프로젝트별로, 오래된 시뮬레이터 런타임을(simctl로 읽어 플랫폼별 최신은 남기고), 기기 지원 파일과 npm·SwiftPM·cargo·uv 등의 패키지 관리자 캐시를 항목별로 보여 줍니다. 요즘의 새로운 공간 대식가 — Hugging Face와 Ollama 모델 캐시 — 도 모델별로 나열하며, 기본은 선택 해제 상태로 둡니다.

모든 항목에 설명이 따라옵니다 — 무엇인지, 다시 만들 수 있는지, 지우면 무엇을 치르는지 — 그리고 직접 확인하기 전까지는 아무것도 실행되지 않습니다. 삭제는 휴지통으로 가므로 잘못 누른 클릭도 드래그 한 번이면 되돌릴 수 있고, 소스 코드·문서·사진은 절대 건드리지 않습니다. 이 가이드와 같은 체크리스트에서, 한 시간의 터미널 작업만 뺀 셈입니다.

FAQ