Xcode Simulator가 Mac에서 공간을 차지한다면? 먼저 정리할 것

Xcode Simulator가 Mac에서 공간을 차지하고 있다면, 무엇이든 삭제하기 전에 시뮬레이터 런타임과 시뮬레이터 디바이스 데이터를 먼저 구분하세요. 무엇이 사용 불가능한지, 무엇이 비활성인지, 테스트에 여전히 필요한지 먼저 검토하세요. 모든 Apple 측 폴더를 일회용 캐시처럼 취급하면 시뮬레이터 정리가 위험해지기 때문입니다.

이것이 개발자들이 하나의 정리 규칙을 배운 뒤 어디에나 적용하면서 저지르는 실수입니다. DerivedData는 한 가지입니다. 시뮬레이터 런타임과 시뮬레이터 디바이스 상태는 또 다른 것입니다.

스토리지는 복구 가능할 수 있습니다. 결과는 그저 덜 균일할 뿐입니다.

빠른 요약

Xcode 시뮬레이터가 무엇을 저장하고 왜 누적되는지

시뮬레이터 스토리지는 하나가 아닙니다. 함께 누적되는 여러 레이어입니다.

높은 수준에서, Xcode 시뮬레이터 스토리지는 대개 다음을 포함합니다:

• 다양한 iOS 플랫폼 버전의 런타임 이미지;
• 다양한 iPhone과 iPad 모델용으로 생성된 시뮬레이터 디바이스;
• 시뮬레이터 내부의 디바이스별 앱 데이터, 설정, 상태;
• SDK, 디바이스 유형, Xcode 버전을 전환할 때 증가하는 Apple 측 개발 체인.

이것이 개발자들이 종종 CoreSimulator에 혼란을 느끼는 이유입니다. 폴더 크기를 보고 전체를 단순한 캐시라고 가정하기 쉽습니다. 실제로 일부는 일회용 테스트 상태에 가깝고, 일부는 여전히 의존하는 런타임 지원입니다.

증가 패턴은 정상입니다:

• 새 Xcode나 SDK를 설치합니다;
• 새 런타임이 나타납니다;
• 새 시뮬레이터 디바이스가 생성됩니다;
• 앱, 테스트 데이터, 설정이 그 안에 누적됩니다;
• SDK 변경이나 Xcode 업그레이드 후 오래된 디바이스가 사용 불가능해집니다;
• 머신에 여전히 충분한 여유 공간이 있기 때문에 몇 달 동안 검토되지 않습니다.

그러다 어느 날 시뮬레이터 스토리지가 작은 디테일이 아니라 주요 이슈가 됩니다.

시뮬레이터 런타임 vs 시뮬레이터 데이터: 차이점은 무엇인가요?

이것이 가장 중요한 구분입니다.

Apple의 simctl 도구는 런타임 작업과 디바이스 작업을 분리합니다. 이것만으로도 정리 모델이 레이어화되어 있음을 알 수 있습니다. 디바이스는 런타임과 같은 것이 아니며, 디바이스를 지우는 것은 런타임 이미지를 삭제하는 것과 같지 않습니다.

이것이 “그냥 CoreSimulator를 지워라” 같은 광범위한 조언이 약한 이유입니다. 서로 다른 정리 결과를 하나의 감정적 액션으로 축소합니다.

DerivedData는 어디에 해당하는가

DerivedData는 인접하지만, 같은 문제는 아닙니다.

DerivedData는 대개 생성된 빌드 출력입니다. 시뮬레이터 스토리지는 더 혼합되어 있습니다. 여전히 필요한 런타임, 더 이상 필요 없는 생성된 디바이스, 관심 있을 수도 있고 없을 수도 있는 디바이스 내부 상태가 포함될 수 있습니다.

압박이 대부분 생성된 빌드 출력이라면, 올바른 가이드는 Xcode DerivedData가 Mac에서 공간을 너무 많이 차지할 때 먼저 정리할 것입니다. 압박이 대부분 런타임 이미지와 시뮬레이터 상태라면, 시뮬레이터 워크플로우를 계속하세요.

시뮬레이터가 얼마나 많은 공간을 사용하는지 확인하는 방법

첫 번째 단계는 검사이지, 삭제가 아닙니다.

Apple 자체 도구를 사용하여 실제로 어떤 디바이스와 런타임이 존재하는지 확인하세요:

xcrun simctl list devices
xcrun simctl list runtimes

디스크에서 광범위한 Apple 측 스토리지 사용 공간을 검사하고 싶다면, 주요 폴더를 직접 비교할 수도 있습니다:

du -sh ~/Library/Developer/CoreSimulator
du -sh ~/Library/Developer/Xcode/DerivedData
du -sh ~/Library/Developer/Xcode/Archives

이것이 중요한 이유는 가장 큰 Apple 측 폴더가 항상 예상한 것이 아닐 수 있기 때문입니다. 때로는 DerivedData가 지배적인 문제입니다. 때로는 CoreSimulator가 조용히 그것을 능가합니다.

먼저 무엇을 찾아야 하는지

• Unavailable 아래에 나열된 디바이스;
• 더 이상 테스트하지 않는 OS 버전의 런타임;
• 여러 런타임 세대에 걸친 많은 생성된 디바이스;
• 여러 Xcode 업데이트 이후 정리된 적이 없는 시뮬레이터 중심 상태의 머신;
• 현재 테스트 필요와 일치하지 않는 큰 CoreSimulator 폴더.

정리가 반응적이 아니라 합리적으로 시작되는 지점이 바로 여기입니다.

Mac에서 시뮬레이터 런타임을 삭제해도 안전한가요?

때로는 안전하지만, 가장 안전한 첫 번째 단계는 아닙니다.

Apple의 simctl runtime 도움말은 런타임 이미지가 자체 관리 객체임을 명확히 합니다. 런타임 삭제는 시뮬레이터 내용을 지우는 것과 다릅니다. 사용 불가능한 디바이스를 삭제하는 것과도 다릅니다.

즉, 런타임 삭제가 가장 좋은 경우는:

• 해당 iOS 버전을 더 이상 테스트에 필요로 하지 않을 때;
• 오래된 Xcode나 SDK 세대를 넘어섰을 때;
• 런타임이 사용되지 않아 공간이 편의성보다 가치 있을 때;
• 먼저 런타임 목록을 확인하고 무엇을 제거하는지 정확히 알 때.

더 나쁜 아이디어인 경우:

• 활성 프로젝트가 여전히 해당 런타임 제품군을 타겟으로 할 때;
• SwiftUI 미리보기, QA 재현 단계, 회귀 테스트가 여전히 의존할 때;
• 곧 오래된 타겟에서 이슈를 데모하거나 디버그하려 할 때;
• 실제 테스트 필요보다 크기만으로 삭제하려 할 때.

더 나은 첫 번째 단계: 명백한 불필요 항목 제거

가장 안전한 시뮬레이터 정리는 종종 사용 불가능한 디바이스부터 시작합니다.

Apple은 simctl delete에서 이것을 직접 문서화합니다. unavailable 별칭은 현재 Xcode SDK에서 지원하지 않는 디바이스를 삭제합니다.

xcrun simctl delete unavailable

이것은 보편적인 답은 아니지만, 현재 SDK 맥락에서 이미 지원되지 않는 것으로 표시된 디바이스를 대상으로 하기 때문에 가장 깔끔한 첫 번째 패스 중 하나입니다.

개발 환경을 잃지 않고 시뮬레이터 데이터 정리하기

이것이 개발자들이 종종 잘못된 도구를 사용하는 부분입니다.

문제가 오래된 앱 데이터이거나 시뮬레이터 내부의 비대해진 디바이스 상태라면, 런타임을 전혀 삭제할 필요가 없을 수 있습니다. 시뮬레이터 디바이스만 초기화하면 됩니다.

Apple의 simctl erase 도움말은 erase를 디바이스의 내용과 설정을 지우는 것으로 정의합니다:

xcrun simctl erase <device>

이것은 런타임 제거 작업이 아닌 초기화 작업입니다.

erase가 좋은 경우

• 시뮬레이터 내부의 앱 상태 지우기;
• 테스트 환경 초기화;
• 런타임 이미지 자체를 제거하지 않고 비대해진 디바이스 수준 내용 제거;
• 누적된 상태는 버리면서 디바이스 워크플로우 유지.

erase가 아닌 것

• 런타임 정리 명령이 아님;
• DerivedData 정리 명령이 아님;
• 실제로 어떤 디바이스와 런타임이 여전히 필요한지 검토하는 것을 대체하지 못함.

이 구분이 전체 시뮬레이터 정리 이야기입니다. 디바이스 지우기, 디바이스 삭제, 런타임 삭제는 세 가지 다른 결정입니다.

앞으로 시뮬레이터 스토리지를 관리하는 방법

실용적인 목표는 “시뮬레이터가 절대 커지지 않게 하는 것”이 아닙니다. “시뮬레이터 스토리지가 보이지 않게 되는 것을 막는 것”입니다.

다음과 같은 검토 리듬을 사용하세요:

1. 주요 Xcode나 SDK 변경 후 디바이스와 런타임 목록 확인.
2. 사용 불가능한 디바이스가 나타나면 삭제.
3. 문제가 런타임 인벤토리가 아닌 디바이스 상태일 때 오래된 시뮬레이터 디바이스 초기화.
4. OS 버전을 완전히 제거하기 전에 런타임 사용량 검토.
5. Apple 측 스토리지가 증가하기 시작하면 CoreSimulator, DerivedData, Archives를 함께 비교.

이렇게 하면 정리 결정이 실제로 비용이 많이 드는 레이어와 정렬됩니다.

Apple 측 스토리지에 대한 더 나은 사고 모델

• DerivedData는 대부분 생성된 빌드 출력입니다.
• Archives는 산출물과 빌드 기록을 보존합니다.
• CoreSimulator는 런타임 지원과 시뮬레이터 디바이스 상태를 혼합합니다.
• 가장 안전한 정리는 어떤 폴더가 보이는지가 아니라, 어떤 레이어가 큰지에 달려 있습니다.

레이어별로 생각하기 시작하면 시뮬레이터 정리가 훨씬 덜 혼란스러워집니다.

생태계를 인식할 때 개발자 정리가 더 잘 작동하는 이유

Finder만 사용하면 20 GB나 30 GB의 Apple 측 폴더는 하나의 명백한 정리 대상으로 보입니다. 하지만 그렇지 않습니다.

파일 브라우저는 CoreSimulator가 크다는 것을 보여줄 수 있습니다. 하지만 실제로 복구 가능한 공간이 다음 중 어느 것인지는 알 수 없습니다:

• 지원되지 않는 디바이스;
• 초기화 가능한 시뮬레이터 내용;
• 더 이상 필요 없는 런타임;
• 또는 단지 근처에 있을 뿐인 인접 Xcode 프로필.

이것이 시뮬레이터 정리가 일반 파일 정리가 아닌 개발자 정리 내에 속해야 하는 이유입니다.

실제 문제가 “시뮬레이터 + DerivedData + 기타 Apple 개발자 스토리지”라면, 프로필 인식 워크플로우가 한 번에 하나의 폴더 경로를 쫓는 것보다 훨씬 더 유용합니다.

핵심 요약

Xcode Simulator가 Mac에서 공간을 차지하고 있다면, CoreSimulator를 하나의 일회용 캐시 버킷처럼 취급하지 마세요.

먼저 디바이스와 런타임을 검토하세요. 가장 깔끔한 첫 번째 단계로 사용 불가능한 디바이스를 삭제하고, 시뮬레이터 내용과 설정을 초기화하고 싶을 때만 erase를 사용하며, 해당 OS 버전이 정말 더 이상 필요 없을 때만 런타임을 제거하세요.

이것이 더 안전한 정리 경로입니다. 런타임 이미지와 디바이스 상태를 분리하고, 시뮬레이터 스토리지와 DerivedData를 분리하며, 맹목적인 폴더 삭제 대신 실제 테스트 필요에 연결된 Apple 측 정리를 유지하세요.