iOS 패키징 서버 디스크 부족? 2026 Xcode 27 정리할까 확장할까

iOS 패키징 서버 디스크 부족은 곧바로 확장할 문제가 아닙니다. 이번 주에는 빌드 캐시, 시뮬레이터 구성 요소, 의존성 캐시, 배포 산출물을 나누어 확인한 뒤 재생성 가능한 항목부터 정리하십시오. 저빈도 단일 앱이면 보존 규칙을 먼저 만들고, 여러 앱에서 반복적으로 저장 공간이 바닥나면 확장이나 별도 원격 맥을 선택하는 편이 안전합니다.

이 글은 원격 맥 한 대로 빌드와 배포를 운영하는 독립 개발자에게 맞습니다. Xcode 27과 여러 시뮬레이터 구성 요소, 과거 아카이브를 함께 보존해야 하는 개발자도 정리 경계를 판단할 수 있습니다. 여러 앱의 자동화 빌드를 관리하는 작은 팀은 단일 서버를 계속 관리할지, 저장 공간을 늘릴지, 역할을 나눌지 결정하는 데 활용할 수 있습니다.

먼저 확인할 것: 디스크 경고와 실제 원인은 다릅니다

원격 Archive가 갑자기 실패했다면 소스 코드나 계정이 아니라 작업 공간 부족이 원인일 수 있습니다. 그러나 사용자의 홈 디렉터리 전체를 지우거나 Keychain과 모든 Xcode 버전을 삭제하는 방식은 복구 경로를 없앱니다.

Xcode 빌드 시스템은 빌드 중간 파일과 결과물을 별도 경로에 만들 수 있습니다. DerivedData의 위치는 프로젝트 설정이나 xcodebuild 실행 방식에 따라 달라질 수 있으므로, 먼저 실제 작업에서 사용한 경로를 기록해야 합니다. 공식 빌드 시스템 문서와 xcodebuild의 파생 데이터 경로 예시를 기준으로 확인하십시오.

이번 주 점검 순서는 다음과 같습니다.

• 현재 Build, Test, Archive, Export 작업이 실행 중인지 확인합니다.
• 디스크 사용량을 폴더 이름만 보고 추정하지 말고 프로젝트와 작업별로 분류합니다.
• 재생성 가능한 캐시와 복구에 필요한 배포 증거를 분리합니다.
• 삭제 전에 활성 작업이 끝났다는 로그와 보존할 파일의 대체 위치를 남깁니다.
• 정리 뒤에는 같은 프로젝트의 전체 Archive와 내보내기 또는 업로드 경로를 검증합니다.

정리와 확장을 가르는 결정 체크리스트

아래 항목을 실제 점검 기록에 복사해 사용하십시오. 각 조건을 확인한 뒤 해당되는 분기로 이동하면 됩니다.

1단계: 작업 중단 위험 확인

• [ ] Build, Test, Archive, Export 작업이 실행 중이 아닙니다.
• [ ] CI 작업과 예약된 자동화 작업이 같은 서버에서 실행되고 있지 않습니다.
• [ ] 현재 삭제 대상이 실행 중인 작업의 출력 경로가 아님을 확인했습니다.

세 항목 중 하나라도 확인하지 못했다면 정리하지 않고 작업 종료 로그를 확보합니다. 실행 중인 작업의 캐시나 출력물을 지우면 단순한 공간 부족이 아니라 빌드 실패를 만들 수 있습니다.

2단계: 파일의 재생성 가능성 확인

• [ ] 대상이 특정 프로젝트의 DerivedData 또는 임시 Build Products입니다.
• [ ] 같은 커밋과 잠금 파일을 다시 받을 수 있습니다.
• [ ] Swift Package Manager, CocoaPods, 사설 의존성을 다시 해결할 인증이 있습니다.
• [ ] 정리 뒤 차가운 빌드와 Release Archive를 수행할 담당자가 있습니다.

네 항목이 모두 맞으면 프로젝트별 캐시 정리를 선택합니다. 하나라도 빠지면 캐시를 보존하고 복원 테스트 또는 백업을 먼저 수행합니다.

3단계: 장기 운영 선택

• [ ] 단일 앱의 저빈도 Archive가 중심이고 정리 뒤 공간 경고가 반복되지 않습니다.
  → 보존 규칙과 정기 점검을 유지합니다.
• [ ] 여러 앱과 여러 Xcode 버전을 운영하며 정리 뒤에도 공간이 빠르게 줄어듭니다.
  → 디스크 확장을 검토합니다.
• [ ] UI 테스트, 여러 Simulator Runtime, 자동화 배포가 같은 서버에서 계속 충돌합니다.
  → 테스트와 배포를 별도 원격 맥으로 분리합니다.
• [ ] 출시 집중 기간이나 짧은 버전 검증 때문에 일시적으로 공간이 필요합니다.
  → 유일한 생산 서버를 지우지 말고 기간별 독립 환경을 추가합니다.

이 체크리스트의 기준은 삭제량이 아닙니다. 삭제 뒤 같은 작업을 검증하고 복구할 수 있는지가 기준입니다. 복구 경로를 설명할 수 없다면 저장 공간이 부족해도 확장 또는 분리를 먼저 선택하십시오.

순수 Archive 서버는 무엇부터 줄여야 하는가

Release Archive만 수행하는 서버는 증분 개발과 SwiftUI Preview를 담당하는 환경보다 캐시 정리의 허용 범위가 넓습니다. 반대로 개발 환경에서 DerivedData를 지우면 다음 빌드가 전체 재빌드가 되고, 의존성이나 인덱스가 다시 만들어질 수 있습니다. 따라서 삭제 가능 여부와 운영 중단 비용을 함께 판단해야 합니다.

DerivedData와 임시 결과

DerivedData는 프로젝트별 파생 빌드 데이터가 모이는 영역입니다. 현재 작업이 끝났고 해당 프로젝트를 다시 빌드할 수 있는 소스와 의존성 정보가 있다면 오래된 항목을 후보로 삼을 수 있습니다. 다만 실제 경로는 고정값으로 가정하지 말고 Xcode 설정 또는 xcodebuild의 -derivedDataPath 사용 여부를 확인하십시오. Build Settings 기준 문서에도 빌드 경로를 결정하는 설정이 설명되어 있습니다.

정리 전에는 다음을 기록합니다.

• 실행 중인 작업의 프로세스와 로그가 종료되었는지 확인합니다.
• 삭제 대상이 현재 Archive의 출력 경로가 아닌지 확인합니다.
• 같은 커밋을 다시 받아 의존성을 복원할 수 있는지 확인합니다.
• 정리 후 차가운 상태의 빌드와 Archive를 검증할 담당자를 정합니다.

경로를 확인한 뒤 특정 프로젝트의 파생 데이터만 제거하는 방식이 안전합니다. 예를 들어 실제로 확인한 경로가 ~/Library/Developer/Xcode/DerivedData/프로젝트폴더라면 해당 프로젝트 폴더만 대상으로 삼을 수 있습니다. 이 명령은 실행 중인 빌드를 중단시키는 안전 장치가 아니므로 작업 종료 확인 뒤에 사용해야 합니다. 삭제 전 백업이 필요한 프로젝트라면 먼저 복사하십시오.

Build Products와 임시 출력

빌드 결과가 별도 출력 디렉터리에 쌓이는 구성이라면 그 위치를 DerivedData와 혼동하지 마십시오. Scheme과 빌드 설정에 따라 출력 위치가 달라질 수 있으므로 Scheme 구성 문서를 확인하고, 현재 Archive가 쓰는 위치와 일반 디버그 빌드 위치를 구분해야 합니다.

저빈도 단일 앱에서 오래된 디버그 출력만 남아 있다면 재생성 후보입니다. 그러나 자동화 작업이 다음 단계에서 해당 경로를 입력으로 사용한다면 삭제하지 말고 작업 정의를 먼저 바꾸십시오. 현재 파이프라인이 참조하는 경로인지 설명할 수 없다면 정리를 중단하는 것이 맞습니다.

Xcode 27 패키징 서버 디스크가 찼을 때 시뮬레이터를 어떻게 다룰까

시뮬레이터 구성 요소는 하나의 캐시가 아닙니다. 설치된 Simulator Runtime, 생성된 가상 기기, 앱 데이터, 테스트 결과, 스크린샷을 분리해서 봐야 합니다. 추가 Xcode 구성 요소 관리 문서를 기준으로 설치된 런타임과 프로젝트가 실제로 요구하는 런타임을 확인하십시오.

순수 Archive 서버라면 UI 테스트나 다중 운영 체제 회귀 테스트에 필요하지 않은 런타임을 계속 보존할 이유가 적습니다. 하지만 여러 시스템 버전을 검증하는 팀이라면 테스트 매트릭스에 포함된 런타임을 남겨야 합니다. 사용하지 않는다고 추정해서 삭제하지 말고, 최근 테스트 기록과 CI 설정에서 실제 참조 여부를 확인하십시오.

생성된 가상 기기는 런타임과 별도입니다. 가상 기기를 지워도 런타임 자체가 제거되는 것은 아니며, 앱 데이터나 테스트 상태만 사라질 수 있습니다. 테스트 결과와 스크린샷은 실패 분석에 필요할 수 있으므로 자동으로 함께 지우지 마십시오.

시뮬레이터는 실기기 검증을 대신하지 않습니다. 공식 안내도 시뮬레이터와 실제 기기에서 확인할 수 있는 동작이 다를 수 있음을 구분합니다. 시뮬레이터와 실기기 테스트 안내를 근거로, 시뮬레이터 정리 때문에 실기기 검증을 생략하는 운영 규칙을 만들지 않아야 합니다.

의존성 캐시와 여러 프로젝트의 충돌을 막는 운영 규칙

여러 앱과 여러 Xcode 버전을 한 서버에서 빌드하면 Swift Package Manager, CocoaPods, 사설 의존성 저장소가 서로 다른 방식으로 공간을 사용합니다. “모든 캐시 삭제”는 간단해 보이지만, 다음 실행에서 네트워크 복원과 차가운 빌드가 동시에 발생해 장애 원인을 더 어렵게 만들 수 있습니다.

프로젝트별로 다음 정보를 남기십시오.

• 사용한 Xcode 버전과 빌드 설정
• Swift Package Manager 또는 CocoaPods의 의존성 원천
• 캐시가 공유되는지 프로젝트별인지 여부
• 의존성 재해결에 필요한 인증과 네트워크 조건
• 정리 후 검증할 커밋과 Archive 방식

의존성 캐시는 재생성 가능하더라도 사설 저장소 인증이 사라지면 복원되지 않을 수 있습니다. 캐시를 지우기 전에는 새 작업 공간에서 의존성을 다시 해결할 수 있는지 확인해야 합니다. 복원에 실패하면 캐시 정리를 중단하고 인증서, 토큰, 접근 권한을 먼저 복구하십시오.

검증은 다음 순서로 이어져야 합니다.

1. 같은 커밋을 깨끗한 작업 공간에 준비합니다.
2. 의존성을 다시 해결하고 로그를 저장합니다.
3. 일반 빌드와 테스트를 실행합니다.
4. Release Archive를 생성합니다.
5. 내보내기 또는 App Store Connect 업로드에 필요한 파일을 확인합니다.

이 연결 고리 중 하나라도 확인하지 못했다면 캐시 정리의 성공을 저장 공간 증가만으로 판단하지 마십시오. 정리 뒤 빌드가 실패하면 확보한 공간보다 복구 시간이 더 큰 비용이 될 수 있습니다.

xcarchive, IPA, dSYM, xcresult는 같은 규칙으로 지우면 안 됩니다

xcarchive는 다시 내보내거나 서명 상태와 빌드 기록을 확인할 때 필요할 수 있습니다. IPA는 배포 파일이고, dSYM은 크래시 분석에 필요한 디버깅 기호입니다. 디버깅 정보 문서는 디버그 기호의 역할을 설명하므로, 배포 이후 분석 경로를 확인하기 전에 dSYM을 삭제하지 마십시오.

xcresult에는 테스트와 빌드 결과가 들어갈 수 있습니다. 실패 원인 추적이나 품질 기록에 쓰인다면 보존 대상입니다. 테스트 실행과 결과 해석 문서를 참고해 팀이 필요한 결과 항목을 정한 뒤 보존 기간을 결정하십시오. 특정 기간을 모든 프로젝트에 일괄 적용할 근거는 프로젝트의 장애 대응 정책에서 만들어야 합니다.

주의: 서명 자산, Keychain, Archive, IPA, dSYM, xcresult를 캐시와 같은 삭제 규칙에 넣지 마십시오. 삭제 전에 다른 보관 위치에서 파일을 열 수 있고, 같은 커밋으로 다시 Archive할 수 있는지 둘 다 확인해야 합니다.

최소 복구 조건은 다음과 같습니다.

• 소스 코드와 잠금 파일을 다시 받을 수 있습니다.
• 서명 자산과 인증 절차를 복구할 수 있습니다.
• Archive 또는 동일한 빌드를 다시 만들 수 있습니다.
• 필요한 dSYM과 테스트 결과를 조회할 수 있습니다.
• 내보내기와 업로드 로그를 다시 확인할 수 있습니다.

이 조건을 충족하지 못한 상태에서 xcarchive를 지우면 저장 공간은 늘어도 출시 후 장애 분석과 재배포 능력을 잃을 수 있습니다.

정리, 확장, 서버 분리는 사용 시나리오로 결정합니다

저장 공간을 늘리는 것만으로 잘못된 보존 정책이 해결되지는 않습니다. 반대로 매번 캐시를 지우는 운영도 차가운 빌드와 의존성 복원 실패를 반복시킬 수 있습니다. VPSMAC의 원격 맥 구성을 검토할 때도 현재 서버의 역할이 개발, 테스트, Archive, 배포 중 무엇인지 먼저 정리하십시오. 서울 환경이 작업자와 가까운지 비교하려면 서울 원격 맥 선택지도 함께 확인할 수 있습니다.

현재 방식이 단일 원격 맥이라면 모든 프로젝트가 같은 디스크와 도구 체인을 공유하고, 정리 중 작업 충돌이 발생하며, 출시 시점의 일시적인 공간 수요를 상시 용량으로 떠안게 됩니다. 직접 장비를 확장하는 방식은 구매와 유지 관리, 장애 대응 책임이 남습니다. 기존 서버를 계속 사용하면서 무리하게 파일을 삭제하면 복구 지점도 사라집니다.

이런 조건에서는 VPSMAC에서 독립된 원격 맥 환경을 필요한 기간만 추가해 빌드와 테스트를 분리하는 편이 더 쉽게 되돌릴 수 있습니다. 다만 장기간 일정한 부하가 이어지거나 전용 물리 장치가 필요하다면 직접 보유한 장비가 더 적합할 수 있습니다. 반대로 단기 검증, 출시 집중, 여러 Xcode 조합의 분리가 목적이라면 임대 환경으로 먼저 위험을 낮추고, 이후 실제 사용 기록을 바탕으로 확장 여부를 결정하는 것이 합리적입니다.