Xcode DerivedData가 Mac에서 너무 많은 공간을 차지하나요? 먼저 정리해야 할 것

Mac에서 매일 앱을 빌드한다면, DerivedData는 결국 중요하면서도 누군가가 이미 정리해주었으면 하는 폴더 중 하나가 됩니다.

그러다 어느 날 폴더가 거대해지고, 디스크 공간이 부족해지고, Xcode가 평소보다 무거워 보이면서, 정리 질문이 즉각적인 것이 됩니다: 안전하게 삭제할 수 있을까요, 아니면 하루 작업을 재구축 혼돈으로 만들려는 건가요?

짧은 대답은 DerivedData가 대개 더 안전한 Xcode 정리 대상 중 하나라는 것입니다. 더 긴 대답은 개발자들이 종종 DerivedData에 과도하게 집중하고 바로 근처에 있는 나머지 Apple 에코시스템 사용 공간을 놓친다는 것입니다.

빠른 요약

대개 안전하게 정리할 수 있는 것과 주의가 필요한 것

Xcode DerivedData의 실체

DerivedData는 Xcode가 개발 워크플로우를 위해 생성된 빌드 출력 및 관련 작업 데이터를 보관하는 곳입니다. 실제로는 대개 빌드 산출물, 인덱스, 중간 파일, 미리보기 관련 출력, Xcode가 다음에 빌드하거나 프로젝트를 열 때 더 빠르게 작동하도록 돕는 기타 생성된 아티팩트를 의미합니다.

이것이 폴더가 이렇게 쉽게 커지는 이유입니다. 모든 프로젝트, 타겟, 브랜치, SDK 조합, 시뮬레이터 워크플로우가 시간이 지나면서 더 많은 생성된 상태를 추가합니다.

이것은 또한 개발자들이 DerivedData를 일반적인 프로젝트 파일과 다르게 취급하는 이유를 설명합니다:

• 앱 코드의 진실 공급원이 아닙니다;
• 빌드 및 인덱싱 시간을 절약하기 위해 존재합니다;
• 필요할 때 재생성될 것으로 예상됩니다.

이 재생성 동작이 DerivedData가 대개 많은 앱 소유 또는 시스템 소유 경로보다 더 안전한 정리 대상으로 분류되는 이유입니다.

Xcode DerivedData가 이렇게 커지는 이유

가장 단순한 대답은 축적입니다.

하나의 활성 앱만으로도 많은 빌드 출력을 생성할 수 있습니다. 여러 앱, 여러 브랜치, 미리보기, 시뮬레이터 실행, 테스트 빌드, 패키지 해결 이력이 폴더를 대부분의 개발자가 예상하는 것보다 훨씬 높게 밀어올릴 수 있습니다.

DerivedData가 부풀어 오르는 일반적인 이유:

• 여러 활성 프로젝트가 같은 머신을 공유;
• 프로젝트가 더 이상 중요하지 않은 지 오래된 후에도 오래된 프로젝트별 폴더가 남음;
• 미리보기, 인덱싱, 시뮬레이터 중심 작업이 추가적인 부하를 생성;
• 오래된 Xcode 환경이 생각보다 오래 오래된 빌드 출력을 유지;
• 다른 것들은 정리하지만 생성된 Apple 개발자 아티팩트는 전혀 건드리지 않음.

중요한 점은 큰 DerivedData가 개발자 Mac에서 특이한 일이 아니라는 것입니다. 올바른 대답이 항상 “지금 모든 것을 삭제하라”인 것으로 가정하지 않고, 다른 것도 큰지, 타이밍이 좋은지 확인하지 않을 때만 문제가 됩니다.

DerivedData 근처에서 보통 또 무엇이 커지는지

개발자들은 익숙하기 때문에 종종 DerivedData를 탓하지만, 이는 Apple 에코시스템 사용 공간의 한 프로필일 뿐입니다.

StorageRadar의 현재 Apple 측 개발자 프로필은 동일한 위험 모델을 공유하지 않기 때문에 이 Xcode 인근 영역들을 분리합니다:

이것이 전체 Developer Folder 스캔이 한 디렉토리에 대한 터널 시야보다 더 유용한 진짜 이유입니다. DerivedData가 12 GB이지만 CoreSimulator가 35 GB이고 Archives가 18 GB이라면, 정리 계획이 완전히 달라집니다.

DerivedData와 함께 자주 커지는 Apple 개발자 폴더

Archives

아카이브는 단순한 생성된 임시 공간이 아닙니다. 실제로 보관하고 싶을 수 있는 인도물을 나타낼 수 있습니다. 그래서 DerivedData와 다른 정리 버킷에 속합니다.

CoreSimulator

시뮬레이터 데이터는 특히 여러 런타임에서 테스트하거나 시뮬레이터 상태를 오랫동안 유지하는 경우, 조용히 DerivedData를 능가할 수 있습니다. 이는 단순한 일회성 캐시 폴더가 아닙니다. 여전히 신경 쓰는 시뮬레이터 환경을 포함할 수 있습니다.

시뮬레이터 저장 공간이 실제 문제라면, Xcode Simulator가 Mac에서 공간을 차지하나요? 먼저 정리해야 할 것에 대한 집중 가이드에서 런타임, 장치 상태, 정리 장단점에 대해 더 자세히 다룹니다.

iOS DeviceSupport

이 영역은 다양한 물리적 장치 버전과 지원 에셋이 축적되면서 커집니다. DerivedData만큼 유명하지 않아 종종 간과되지만, 여전히 충분히 커서 중요합니다.

패키지 관련 캐시

이들은 시뮬레이터나 아카이브 데이터보다 더 안전한 정리 대상일 수 있지만, 여전히 DerivedData와는 별개입니다. 확보 가능한 공간을 진지하게 추적 중이라면, 각 프로필을 자체적인 정리 문제로 취급하세요.

선택적 정리가 전체 삭제보다 나은 경우

기본 개발자 반사 신경은 종종 전체 정리입니다: 전체 폴더를 지우고, Xcode가 재구축하게 하고, 넘어갑니다.

괜찮을 수도 있지만, 항상 최선의 선택은 아닙니다.

선택적 정리가 대개 더 나은 경우:

• 오래된 프로젝트 몇 개가 크기의 대부분을 차지;
• 현재 활성 앱에 대해 빠르고 예측 가능한 빌드가 필요;
• 오늘 모든 것에 대해 전체 재인덱싱을 강제하고 싶지 않음;
• 오래된 브랜치나 폐기된 워크스페이스가 현재 프로젝트가 아닌 실제 문제라고 의심.

전체 삭제가 더 합리적인 경우:

• 전체 폴더가 많은 오래된 프로젝트에 걸쳐 부풀어 오름;
• 생성된 출력의 깔끔한 리셋을 원함;
• 현재 속도 저하가 통제된 재구축 윈도우와 교환할 가치가 있음;
• 전역 생성 상태가 문제의 일부라고 의심.

이것은 실제로 저장 공간 결정으로 위장한 타이밍 결정입니다. 공간 절약은 비슷할 수 있지만, 워크플로우 비용은 다릅니다.

재구축 혼돈 없이 Xcode DerivedData를 정리하는 방법

안전한 목표는 단순히 “공간 확보”가 아닙니다. 안전한 목표는 “다음 몇 시간의 개발을 예측 가능하게 유지하면서 올바른 공간을 확보하는 것”입니다.

1. 전체 개발자 상황을 먼저 검토

격리된 DerivedData가 아닌 Developer Folder에서 시작하세요. 요점은 Xcode 출력이 정말로 지배적인 문제인지, 다른 Apple 개발자 프로필이 더 큰지 확인하는 것입니다.

더 광범위한 개발자 사용 공간이 문제라면, DerivedData만 정리하면 기대보다 적게 확보할 수 있습니다.

2. 안전한 생성 출력과 주의 프로필 분리

이 구분이 중요합니다:

• DerivedData와 캐시는 생성되었기 때문에 대개 안전한 스타일의 정리 대상입니다;
• Archives, CoreSimulator, iOS DeviceSupport는 여전히 필요한 아티팩트, 런타임 또는 상태를 보존할 수 있으므로 더 많은 주의가 필요합니다.

이것들을 혼동하기 시작하면, “개발자 정리”는 그냥 또 다른 위험한 폴더 삭제가 됩니다.

3. 선택적 정리와 전체 정리 사이에서 의도적으로 결정

무엇이든 제거하기 전에 다음 질문에 대답하세요:

1. 가장 큰 DerivedData 디렉토리가 오래되었거나 활성 프로젝트와 연결되어 있는가?
2. 오늘 빠른 빌드와 인덱싱이 필요한가?
3. 인근 프로필이 실제로 DerivedData보다 큰가?
4. 전체 재구축 윈도우가 현재 스프린트, 데모 또는 릴리스 작업에 영향을 줄 것인가?

이 짧은 검토가 대부분의 불필요한 전체 삭제를 방지합니다.

4. 데이터 손실이 아닌 재구축 비용 예상

DerivedData의 경우, 정리의 일반적인 비용은 대개:

• 다음 빌드가 느려짐;
• 인덱스 재구축;
• 미리보기 또는 시뮬레이터 시작이 느려짐;
• 생성된 출력이 돌아올 때까지 일시적인 마찰.

이것은 앱 지원 데이터, 여전히 필요한 아카이브, 또는 신경 쓰던 시뮬레이터 상태를 삭제하는 것과 매우 다릅니다. 개발자 정리는 이 범주들을 분리할 때만 안전하게 유지됩니다.

5. 일반 파일 삭제가 아닌 개발자 정리 워크플로우 사용

일반 파일 브라우저는 무언가가 크다는 것을 알려줄 수 있습니다. 하지만 해당 경로가 알려진 개발자 프로필인지, Safe 또는 Caution 버킷에 있는지, 가능한 결과가 무엇인지, 정리 전에 안내된 사전 점검이 필요한지 알려줄 수 없습니다.

이 누락된 컨텍스트가 위험도가 높아지면 개발자 정리가 일반적인 “가장 큰 파일” 정리로 축소되어서는 안 되는 이유입니다.

Xcode 정리가 일반 파일 정리와 다른 이유

일반 파일 정리는 간단한 질문을 합니다: 무엇이 큰가?

Xcode, Docker, SDK 중심 설정 및 개발자 위험 프로필에 걸친 더 광범위한 가이드를 원한다면, Mac에서 개발자 캐시 안전하게 정리하기를 읽어보세요.

개발자 정리는 더 어려운 질문을 해야 합니다:

• 이것은 생성된 것인가, 사용자가 작성한 것인가;
• 이 프로필은 Safe, Caution, 또는 Dangerous인가;
• 확보 가능한 크기를 신뢰하기 전에 Dry Run이 필요한가;
• 프로필에 워크플로우 위험이 있어 Guided Preflight가 필요한가;
• 어떤 차단 항목, 경고 또는 결과를 먼저 검토해야 하는가?

이 차이는 StorageRadar의 Dev Cleanup 모델에 내장되어 있습니다. 임의의 삭제로 작동하지 않습니다. 알려진 개발자 프로필과 위험 정책에서 작동합니다.

예를 들어, 현재 Apple 개발자 프로필은 다음과 같이 분리합니다:

• Xcode DerivedData는 Safe;
• Xcode Archives는 Caution;
• CoreSimulator Data는 Caution;
• iOS DeviceSupport는 Caution;
• SwiftPM Cache는 Safe.

이것은 정리 혼돈의 반대입니다. 생성된 캐시를 보존된 아티팩트 및 시뮬레이터 상태와 다르게 취급하는 에코시스템 인식 워크플로우입니다.

StorageRadar의 역할

이것이 실제 워크플로우를 변경합니다:

• 전체 Apple 개발자 영역이 부풀어 올랐을 수 있을 때 Developer Folder를 사용;
• 일반 파일 삭제 대신 프로필 인식 정리를 원할 때 Dev Cleanup을 사용;
• DerivedData 같은 Safe 프로필을 Archives 및 시뮬레이터 관련 저장 공간 같은 Caution 프로필과 분리하여 유지.

이 구분이 개발자 머신의 전체 가치입니다. 제품은 단순히 폴더가 크다는 것을 알려주는 것이 아닙니다. 어떤 종류의 개발자 저장 공간인지, 어떤 정리 프로세스를 받아야 하는지 알려줍니다.

피해야 할 행동

다음과 같은 일반적인 실수를 피하세요:

• DerivedData가 확인할 가치가 있는 유일한 Xcode 폴더라고 가정하지 마세요;
• Archives, CoreSimulator, iOS DeviceSupport를 동일한 위험 프로필을 가진 것처럼 지우지 마세요;
• 재구축 시간이 중요한 마감 직전에 전체 리셋을 하지 마세요;
• 에코시스템 컨텍스트가 필요한 개발자 아티팩트에 대해 최대 파일 논리만 사용하지 마세요;
• 생성된 빌드 출력을 프로젝트 데이터, 인도물 또는 보존된 시뮬레이터 상태와 혼동하지 마세요.

Apple 개발자 아티팩트가 System Data를 의심스러울 정도로 크게 보이게 만들고 있다면, 관련 가이드인 Mac System Data가 너무 큰 경우가 다음 읽을 거리로 적합합니다.

결론

DerivedData가 Mac에서 너무 많은 공간을 차지하고 있다면, 안심할 점은 생성된 출력이므로 대개 더 안전한 Xcode 정리 대상 중 하나라는 것입니다. 덜 명확한 부분은 DerivedData가 전체 이야기인 경우가 거의 없다는 것입니다.

최선의 정리 결정은 더 광범위한 개발자 사용 공간을 검토하고, 안전한 프로필과 주의 프로필을 분리하고, 공황 대신 현재 워크플로우에 기반하여 선택적 또는 전체 정리를 선택할 때 나옵니다.