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

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

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

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

빠른 요약

CoreSimulator란 무엇인가요

CoreSimulator는 Xcode가 iOS, iPadOS, watchOS, tvOS 앱을 빌드하고 테스트할 때 쓰는 시뮬레이터 런타임과 생성된 시뮬레이터 기기를 보관하는, Apple이 관리하는 폴더입니다. 대부분의 Mac에서는 ~/Library/Developer/CoreSimulator에 있으며, 런타임을 추가하고 기기를 만들고 그 안에 앱 데이터가 쌓일수록 커집니다.

일반적인 캐시가 아닙니다. 이 폴더에는 아직 필요할 수 있는 런타임 이미지와, 많은 경우 초기화하거나 삭제해도 되는 기기 상태가 섞여 있습니다. “CoreSimulator가 수십 GB를 차지한다”에 답이 하나로 정해지지 않는 이유입니다.

CoreSimulator 폴더를 삭제해도 되나요

폴더째 무작정 지우는 방식은 피하세요. 경로 전체를 지우는 대신 알맞은 계층을 비우면 공간 대부분을 되찾을 수 있습니다.

~/Library/Developer/CoreSimulator를 손으로 통째로 지우면 Xcode가 시뮬레이터 상태를 다시 만들어야 하고, 아직 필요한 런타임도 함께 사라집니다. 안전한 대안은 Apple의 simctl에 정말 버려도 되는 부분을 맡기는 것입니다.

• 현재 SDK가 더 이상 지원하지 않는 기기는 xcrun simctl delete unavailable로 삭제합니다;
• 앱 상태가 부풀어 있는 것이 문제라면 xcrun simctl erase <device>로 기기의 콘텐츠와 설정을 초기화합니다;
• 해당 OS 버전을 더 이상 테스트하지 않을 때만 xcrun simctl runtime delete로 런타임을 삭제합니다.

CoreSimulator 공간은 계층별로 되찾는 것이지, 폴더를 지우고 Xcode가 알아서 복구하기를 기대하는 것이 아닙니다.

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 폴더.

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

Xcode에서 시뮬레이터를 삭제하는 방법

살펴보는 데서 그치지 않고 실제로 삭제하려면 안전한 경로가 두 가지 있습니다. Xcode 화면과 simctl 명령줄입니다. 둘 다 아직 필요한 런타임은 건드리지 않고 오래된 시뮬레이터만 정리합니다.

Xcode 앱에서:

1. Xcode를 열고 Window → Devices and Simulators로 이동합니다.
2. Simulators 탭을 선택합니다.
3. 더 이상 필요 없는 시뮬레이터를 마우스 오른쪽 버튼으로 클릭해 Delete를 고르거나, 현재 SDK가 지원하지 않는 기기를 한 번에 정리하는 Delete Unavailable Simulators를 사용합니다.

명령줄에서:

# 먼저 목록부터 확인
xcrun simctl list devices

# 현재 SDK가 unavailable로 표시한 기기 전부 삭제
xcrun simctl delete unavailable

# UDID로 특정 기기 하나만 삭제
xcrun simctl delete <device-UDID>

사용 불가 시뮬레이터 삭제가 가장 깔끔한 첫 단계입니다. Apple이 이미 미지원으로 표시한 기기만 사라지기 때문입니다. 특정 기기를 삭제하면 그 시뮬레이터 인스턴스만 없어지고 런타임 이미지는 남으므로, 프로젝트에 필요하면 다시 만들 수 있습니다.

공간 확보가 목적이라면 런타임을 건드리기 전에 여기서 시작하세요. 삭제한 기기는 금방 다시 만들 수 있지만, 삭제한 런타임은 더 무거운 결정입니다.

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

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

CoreSimulator는 디스크의 어디에 있나요

시뮬레이터 저장 공간을 점검할 때 중요한 경로는 두 개입니다.

~/Library/Developer/CoreSimulator/Devices에는 직접 만든 시뮬레이터 기기가 들어 있습니다. 각 기기는 UDID를 이름으로 하는 폴더이고, 그 안의 data/가 설치된 앱, 앱 데이터, 설정을 담습니다. simctl erase가 초기화하고 simctl delete가 제거하는 대상이 이 계층입니다.

시스템 수준의 /Library/Developer/CoreSimulator는 런타임 쪽을 담습니다. Xcode 버전에 따라 런타임 이미지는 Profiles/Runtimes 아래의 .simruntime 번들로 있거나, xcrun simctl runtime list가 보여 주는 다운로드형 런타임으로 Xcode가 관리합니다. 여기서 무엇을 지우든 Mac의 모든 사용자 계정에 영향을 주므로 더 무거운 결정으로 다루세요.

du -sh ~/Library/Developer/CoreSimulator/Devices
du -sh /Library/Developer/CoreSimulator
xcrun simctl runtime list

Devices가 크다면 문제는 쌓인 기기 상태와 현재 SDK가 더 이상 지원하지 않는 기기입니다. 시스템 폴더가 크다면 문제는 런타임 이미지입니다.

CoreSimulator를 외장 드라이브로 옮길 수 있나요

내장 디스크가 작고 시뮬레이터 폴더가 40 GB를 넘어설 때 나오는 질문입니다. Apple은 이동을 위한 공식 설정을 제공하지 않기 때문에 개발자들은 심볼릭 링크를 씁니다. ~/Library/Developer/CoreSimulator를 외장 볼륨으로 복사하고, 복사본을 확인하고, 원본을 지운 뒤 예전 경로를 새 위치로 연결하는 방식입니다.

무엇을 감수하게 되는지 알아 두세요:

• 드라이브가 마운트되지 않으면 경로가 사라지므로 Xcode가 시뮬레이터를 실행하지 못합니다;
• 버스 전원 USB 드라이브에서는 내장 SSD보다 시뮬레이터가 느리게 부팅합니다;
• Xcode나 SDK 업데이트가 원래 경로에 폴더 구조 일부를 다시 만들 수 있습니다;
• 백업과 권한 동작이 외장 볼륨에서는 달라집니다.

폴더 전체를 옮기기 전에 회수 가능한 공간부터 재 보세요. 사용 불가 기기와 더는 테스트하지 않는 런타임을 지우는 편이 이동보다 더 많이 비우는 경우가 많고, Apple이 지원하는 구성도 그대로 유지됩니다.

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

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

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

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 측 정리를 유지하세요.