AskCleanAskClean

크래시 심볼을 잃지 않고 오래된 Xcode Archives 삭제하기

AskClean 팀 · 업데이트 2026-07-31

Xcode Archive는 해당 앱 버전이 더 이상 배포되지 않고, 앞으로 그 dSYM으로 크래시를 분석할 필요도 없다고 확인한 뒤에만 삭제하세요. Xcode Organizer에서 항목별로 검토하고 App Store, TestFlight, Enterprise, Ad Hoc에서 아직 쓰이는 빌드는 남긴 채 은퇴한 아카이브만 휴지통으로 옮기는 것이 가장 안전합니다.

보호해야 할 현재 릴리스와 검토 후 제거할 수 있는 이전 Xcode 아카이브
Archive는 일반 캐시가 아니라 릴리스 증거입니다. 현재 빌드는 보호하고 은퇴한 빌드만 하나씩 검토하세요.

Archives가 DerivedData와 다른 이유

Product > Archive를 실행하면 Xcode는 배포 가능한 빌드를 .xcarchive 번들로 보존합니다. 기본 위치는 ~/Library/Developer/Xcode/Archives이며 날짜별 폴더와 Organizer에서 확인할 수 있습니다. 오래 운영한 앱에는 릴리스 후보, TestFlight, 프로덕션 빌드가 여러 세대 쌓입니다.

DerivedData는 소스에서 다시 만들 수 있지만 Archive에는 그 릴리스의 정확한 바이너리, 빌드 메타데이터, dSYM이 들어 있을 수 있습니다. Apple 설명처럼 dSYM은 UUID로 특정 바이너리와 연결됩니다. 같은 커밋을 다시 빌드해도 원래 심볼의 대체품이 되지 않습니다.

따라서 삭제 비용도 다릅니다. DerivedData는 다음 빌드와 인덱싱이 느려질 뿐입니다. Archive를 잘못 지우면 해당 바이너리의 크래시 주소를 함수명과 소스 위치로 되돌리지 못할 수 있습니다.

삭제 목록보다 보존 목록을 먼저 만들기

Finder의 날짜만 보지 말고 Window > Organizer에서 Archives를 여세요. 앱을 선택한 다음 버전, 빌드 번호, 생성 날짜와 배포 상태를 확인합니다. 이 정보가 오래되어 보이는 폴더명보다 안전한 판단 근거입니다.

현재 App Store에 제공되는 버전, 활성 TestFlight 빌드, 아직 설치된 Enterprise 또는 Ad Hoc 빌드, 크래시 조사 기간 안에 있는 이전 프로덕션 버전은 보존합니다. 재내보내기, 서명 확인, 사고 대응에 쓰는 기준 릴리스도 남겨야 합니다.

업로드 성공만으로 로컬 Archive가 불필요하다고 가정하지 마세요. 설정에 따라 Apple에 심볼이 전달됐을 수 있지만 Apple 디버깅 문서도 배포한 각 빌드의 아카이브 보존을 권합니다. 로컬 Archive는 바이너리, dSYM, 버전과 빌드 번호를 연결하는 명확한 기록입니다.

  1. Window > Organizer를 열고 Archives를 선택합니다.
  2. 프로덕션, TestFlight, Enterprise, Ad Hoc에서 현재 사용 중인 버전과 빌드 번호를 기록합니다.
  3. 필요한 심볼 업로드를 확인하고 보존 정책이 있다면 백업된 저장소에 복사합니다.
  4. 대체된 릴리스 후보, 중단된 내부 빌드, 조사 기간이 끝난 버전만 삭제 후보로 표시합니다.
  5. Organizer에서 하나씩 삭제하고 필요한 항목이 남았는지 확인한 뒤 휴지통을 비웁니다.

날짜만으로 결정하면 안 됩니다. 새 버전이 출시된 뒤에도 이전 프로덕션 바이너리가 사용자 기기에 오래 남을 수 있습니다.

삭제하지 않고 크기 측정하기

Finder에서 Command-Shift-G를 누르고 ~/Library/Developer/Xcode/Archives를 엽니다. 목록 보기에서 모든 크기 계산을 켜고 크기순으로 정렬하면 파일을 바꾸지 않고 큰 항목을 찾을 수 있습니다.

터미널에서는 du -sh ~/Library/Developer/Xcode/Archives로 합계를, du -sh ~/Library/Developer/Xcode/Archives/*로 날짜 폴더별 크기를 확인할 수 있습니다. 두 명령 모두 읽기 전용입니다.

.xcarchive는 Finder에서 하나의 패키지로 보입니다. 조사용 복사본에서 패키지 내용 보기를 사용할 수는 있지만, 원본 번들 내부 파일을 부분적으로 지우지는 마세요. 겉으로 남아 있어도 내보내기나 심볼화가 불가능해질 수 있습니다.

가장 안전한 삭제 흐름

Organizer가 우선입니다. 앱, 버전, 빌드 번호를 보면서 은퇴가 확인된 Archive만 Delete할 수 있어 Finder의 날짜 폴더보다 대상을 잘못 고를 가능성이 낮습니다.

Organizer가 아주 오래됐거나 손상된 번들을 읽지 못할 때만 Finder를 사용하세요. Info.plist의 정보를 감사 기록과 대조한 뒤 정확한 .xcarchive 하나만 휴지통으로 옮기고 날짜 폴더 전체를 지우지 않습니다.

곧바로 휴지통을 비우지 말고 Organizer를 다시 열어 필요한 빌드가 남았는지 확인하세요. 심볼이 중요하다면 대표 크래시 보고서도 테스트합니다. 영구 삭제를 서두른다고 판단이 더 정확해지지는 않습니다.

끝없이 늘어나지 않는 보존 정책

단순한 파일 나이보다 배포 상태를 기준으로 삼으세요. 현재 배포 중인 빌드는 모두 보존하고, 이전 프로덕션 버전은 크래시를 받는 기간까지, Enterprise 빌드는 설치 만료까지 남깁니다. 법무·감사·중대 사고용 빌드는 조직 정책을 따릅니다.

릴리스 체크리스트에 Archive 위치, dSYM 업로드 여부, 복구 권한과 삭제 가능 조건을 적으세요. 외장 또는 클라우드 저장소로 옮길 때는 파일 존재만 확인하지 말고 복원과 내보내기를 실제로 시험합니다.

큰 릴리스 주기마다 짧게 검토하면 시동 디스크가 가득 찬 상황에서 성급히 삭제하지 않아도 됩니다. 긴급할 때는 DerivedData처럼 다시 만들 수 있는 데이터부터 처리하세요.

AskClean이 Archives를 다루는 방식

AskClean은 Xcode Archives를 일반적인 재생성 가능 캐시로 표시하지 않습니다. .xcarchive를 개별 항목으로 보여 주고 되돌릴 수 없는 비용을 경고하므로 전체 폴더를 한꺼번에 지울 필요가 없습니다.

최종 판단은 사용자 몫입니다. AskClean은 크기를 보여 주고 승인한 항목을 휴지통으로 옮길 수 있지만 제품 지원 기간을 결정하거나 잃어버린 dSYM을 재현할 수는 없습니다.

삭제 경계: 다시 만들 수 있는 것과 없는 것

나이와 크기보다 복구 비용을 먼저 봅니다.

항목기본 위치삭제 결과
DerivedData~/Library/Developer/Xcode/DerivedData소스에서 다시 만들며 다음 빌드와 인덱싱이 느려집니다.
Xcode Archive~/Library/Developer/Xcode/Archives보존된 바이너리, 메타데이터와 일치 dSYM을 잃을 수 있습니다.
내보낸 dSYM팀 릴리스 산출물 저장소배포 바이너리에 남은 유일한 심볼일 수 있습니다.
은퇴한 내부 빌드~/Library/Developer/Xcode/Archives더 이상 설치·지원되지 않음을 확인한 뒤 삭제 후보가 됩니다.

자주 묻는 질문

~/Library/Developer/Xcode/Archives를 전부 삭제해도 되나요?

일괄 삭제는 안전하지 않습니다. 배포된 빌드의 정확한 바이너리와 dSYM이 들어 있을 수 있으므로 활성 프로덕션, TestFlight, Enterprise, Ad Hoc 및 조사 대상 버전은 남기세요.

Archive를 지우면 App Store 앱도 삭제되나요?

아닙니다. 로컬 .xcarchive 삭제는 App Store Connect나 사용자 기기에 영향을 주지 않습니다. 다만 재내보내기와 심볼화에 필요한 로컬 릴리스 산출물은 잃습니다.

같은 커밋을 다시 빌드하면 dSYM을 복원할 수 있나요?

신뢰할 수 있는 대체가 아닙니다. dSYM은 배포 바이너리 UUID와 일치해야 하며 새 빌드는 다른 바이너리 ID를 갖습니다.

Archives와 DerivedData 중 무엇을 먼저 지워야 하나요?

보통 DerivedData가 먼저입니다. 재생성할 수 있고 비용은 빌드 시간뿐입니다. Archives는 릴리스별 검토가 필요합니다.

참고 자료

Xcode 저장 공간 점검 계속하기