Xcode 아카이브는 대부분 지워도 안전하지만, 몇 개는 크기보다 훨씬 값어치가 있습니다. 각 아카이브는 내보내거나 업로드한 빌드이고, 그 안의 dSYM에는 바로 그 바이너리의 심볼이 들어 있습니다. 아무도 실행하지 않는 빌드의 아카이브는 지우세요. 아직 어딘가에 설치되어 있는 모든 버전의 아카이브는 남기세요. 크래시 리포터나 App Store Connect가 이미 그 심볼을 갖고 있다면 예외입니다.
기본 원칙: 사람들이 아직 실행하는 빌드의 아카이브는 모두 남기고, 나머지는 터미널이 아니라 Xcode의 Organizer에서 지우세요.
빠른 요약
du -sh ~/Library/Developer/Xcode/Archives/* | sort -h | tail로 폴더 크기를 잽니다.- Xcode를 열고 Window, Organizer, Archives로 갑니다.
- 앱마다 가장 최근에 출시한 빌드와, 사용자가 아직 실행하는 이전 빌드를 남깁니다.
- 지우려는 빌드의 심볼을 크래시 리포터나 App Store Connect가 갖고 있는지 확인합니다.
- 테스트용 내보내기, 새 빌드로 대체된 업로드, 만료된 TestFlight 빌드를 지웁니다.
- 확신이 서지 않는 아카이브는 지우지 말고 외장 드라이브로 옮깁니다.
Xcode 아카이브 안에는 무엇이 있나요
Xcode는 Product, Archive나 xcodebuild archive를 실행할 때마다 아카이브를 하나 만듭니다. 아카이브는 ~/Library/Developer/Xcode/Archives에 날짜별 폴더로 정리되고, 각 번들의 이름은 스킴과 시각을 따릅니다. 예를 들면 MyApp 21.09.2026, 14.13.xcarchive 같은 식입니다.
| .xcarchive 안의 항목 | 담고 있는 것 |
|---|---|
dSYMs | 앱과 내장 프레임워크의 디버그 심볼 |
Products | 빌드된 앱 |
Info.plist | 버전, 빌드 번호, 생성 날짜 |
Signatures | 서명 메타데이터 |
2026년 10월 25일, macOS 27.0.1과 Xcode 27.1을 쓰는 제 Mac에서 이 폴더를 재 봤습니다. 크기는 3.9 GB였고, 앱 11개의 아카이브 35개가 들어 있었으며 모두 8월 16일에서 10월 24일 사이에 만든 것이었습니다. 일반적인 아카이브는 약 165 MB, 가장 큰 것은 407 MB였습니다. StorageRadar 아카이브 하나를 열어 보니 dSYMs 폴더가 84 MB, 앱 자체가 39 MB로 심볼이 제품보다 컸습니다.
dSYM이 중요한 이유
릴리스 빌드의 크래시 리포트에는 함수 이름이 아니라 메모리 주소가 찍힙니다. Xcode와 크래시 리포팅 서비스는 크래시가 난 바이너리와 UUID가 일치하는 dSYM으로 이 주소를 함수 이름으로 바꿉니다. dSYM이 어느 빌드의 것인지는 이렇게 확인합니다.
dwarfdump --uuid ~/Library/Developer/Xcode/Archives/2026-09-21/*.xcarchive/dSYMs/*.dSYM같은 커밋을 다시 아카이브하면 새 바이너리가 나오고, 대부분의 환경에서는 UUID도 새로 바뀝니다. 그래서 지운 아카이브는 크래시 리포트 용도로는 다시 만들 수 없습니다. 예전 빌드의 리포트에는 예전 dSYM이 필요합니다.
두 번째 사본을 갖고 있을 수 있는 곳은 두 군데입니다.
- App Store Connect. 앱 심볼을 업로드하는 옵션을 켜고 배포하면, Xcode의 Organizer에 보이는 크래시 리포트를 Apple이 심볼리케이션해 줍니다.
- 크래시 리포터. Sentry나 Firebase Crashlytics 같은 서비스는 프로젝트가 그렇게 설정되어 있으면 빌드 중에 dSYM을 업로드하고 자기 쪽에 보관합니다.
어느 쪽에도 해당하지 않는 빌드라면, 그 아카이브가 심볼의 유일한 사본입니다.
어떤 아카이브를 지워도 되나요
크게 고민하지 않고 지워도 되는 것:
- 무언가를 시험하려고 만든 로컬 또는 Ad Hoc 내보내기의 아카이브;
- 업로드한 뒤 같은 버전의 새 빌드로 대체한 빌드;
- 90일이 지난 TestFlight 빌드. TestFlight는 그 기간이 지나면 빌드를 만료시킵니다.
남길 것:
- App Store에 올라가 있는 빌드의 아카이브, 그리고 사용자가 업데이트를 늦게 한다면 그 이전 빌드 한두 개의 아카이브;
- App Store 밖에서 배포하는 빌드의 아카이브. 바로 그 빌드를 다시 내보내거나 공증해야 할 때가 있습니다;
- 아직 크래시 리포트가 들어오는데 심볼의 두 번째 사본이 없는 모든 아카이브.
아카이브를 지우는 방법
Xcode에서. Window, Organizer를 열고 Archives를 고릅니다. 왼쪽에서 앱을 선택하고 아카이브를 하나 이상 고른 뒤, 컨텍스트 메뉴에서 삭제합니다. Organizer는 아카이브 폴더를 읽어서 보여 주므로, 이렇게 하면 번들이 디스크에서 지워집니다.
Finder에서. open ~/Library/Developer/Xcode/Archives를 실행하고 날짜 폴더를 통째로 휴지통으로 옮깁니다. 옮긴 항목은 Organizer 목록에서 사라집니다.
외장 드라이브로. 오래된 날짜 폴더를 외장 디스크에 복사한 다음 Mac에서 지웁니다. Xcode가 정상적으로 동작하는 데 아카이브가 내장 디스크에 있을 필요는 없고, 오래된 빌드의 크래시 리포트가 들어오면 그때 하나를 다시 복사해 오면 됩니다.
Xcode Settings의 Locations에서 Xcode가 다른 아카이브 폴더를 쓰도록 지정할 수도 있습니다.
Archives와 DerivedData의 차이
두 폴더는 ~/Library/Developer/Xcode에 나란히 있지만 정반대로 동작합니다. DerivedData는 Xcode가 다음 빌드 때 다시 만드는 빌드 결과물이라, 지워도 한 번 느린 빌드를 감수하면 그만입니다. Archives는 출시한 빌드의 기록이고, 무엇도 이것을 다시 만들어 주지 않습니다. DerivedData는 마음 편히 비우고, Archives는 하나씩 검토하세요.
핵심 요약
Xcode 아카이브 삭제는 아무도 실행하지 않는 빌드라면 안전하고, 사람들이 아직 쓰는 빌드라면 대가가 큽니다. 폴더 크기를 재고, Organizer를 열고, 현재 쓰이는 버전마다 그 아카이브를 남기고, 오래된 빌드의 심볼이 어디에 있는지 확인한 뒤에 지우세요. 확신이 없을 때는 외장 드라이브가 읽을 수 없는 크래시 리포트보다 쌉니다.
자주 묻는 질문
Xcode 아카이브를 지워도 안전한가요?
더 이상 아무도 실행하지 않는 빌드의 아카이브라면 안전합니다. 테스트용 내보내기, 새 빌드로 대체된 업로드, 만료된 TestFlight 빌드가 그렇습니다. 아직 어딘가에 설치되어 있는 빌드의 아카이브는 모두 남기세요. 그 안의 dSYM이 해당 빌드의 크래시 리포트를 읽을 수 있는 스택 트레이스로 바꿔 주기 때문입니다.
Xcode 아카이브를 지우면 App Store에서 앱이 내려가나요?
아닙니다. 업로드한 빌드는 App Store Connect가 보관합니다. 아카이브는 그 빌드와 디버그 심볼의 로컬 사본일 뿐입니다.
지운 아카이브를 다시 만들 수 있나요?
같은 커밋을 다시 아카이브할 수는 있지만, 대부분의 환경에서 새 바이너리는 새 UUID를 받습니다. 예전 크래시 리포트에는 예전 UUID의 dSYM이 필요하므로, 그 dSYM이 App Store Connect나 크래시 리포터 같은 다른 곳에 없다면 리포트는 심볼리케이션되지 않은 채로 남습니다.
Mac에서 Xcode는 아카이브를 어디에 저장하나요?
~/Library/Developer/Xcode/Archives에 날짜별로 폴더를 하나씩, 2026-10-24 같은 이름으로 만들어 저장합니다. 경로는 Xcode Settings의 Locations에서 확인할 수 있습니다. 각 아카이브는 앱, dSYM, Info.plist가 든 .xcarchive 번들입니다.
Xcode 아카이브는 공간을 얼마나 차지하나요?
앱에 따라 다릅니다. 제 Mac에서는 일반적인 아카이브가 약 165 MB, 가장 큰 것은 407 MB였습니다. 업로드할 때마다 하나씩 남기 때문에 10주 동안 35개가 쌓여 3.9 GB가 되었습니다.