Apple은 Mac의 저장 공간을 범주별로 확인하고 관리하도록 안내합니다. Mac 저장 공간 관리 안내에 따라 가용 공간이 0바이트에 가까워진 상태라면 새 빌드를 계속 실행하지 말아야 합니다. 이번 주에는 작업을 중지하고 증거를 보존한 뒤, 작업 공간·DerivedData·Simulator runtime·아카이브·패키지 캐시 순서로 점검하십시오. 재생성 가능한 데이터만 확인 후 삭제하고, 정상 작업량이 계속 공간을 모두 사용하면 반복 삭제 대신 보존 정책을 바꾸거나 노드를 분리하거나 확장해야 합니다.
이 글을 읽어야 하는 담당자
원격 Mac에서 Xcode 빌드가 중단되어 낮은 위험으로 작업 공간을 복구해야 하는 당직 개발자를 위한 글입니다. 공유 원격 Mac Runner의 캐시와 Simulator를 관리하는 DevOps 엔지니어도 대상입니다. 노드 용량과 배포 검증을 맡은 플랫폼 엔지니어에게는 정리, 재구성, 확장 사이의 판단 기준을 제공합니다.
첫 번째 대응은 삭제가 아니라 쓰기 중지입니다
로그에 No space left on device가 표시되면 실패한 명령의 뒤에 이어진 오류를 모두 원인으로 간주해서는 안 됩니다. 먼저 새 빌드와 테스트 큐를 멈추고, 현재 실행 중인 프로세스와 실패한 작업을 기록합니다. Apple의 Xcode 명령 줄 도구 설명은 xcodebuild와 관련 도구의 실행 범위를 설명하므로, 실제 노드에서 사용하는 명령과 계정을 대조하는 출발점으로 삼을 수 있습니다.
다음 명령은 경로와 계정 이름을 실제 값으로 바꿔 실행합니다.
whoami
pwd
df -h /
df -i /
ps aux | grep -E 'xcodebuild|simctl|swift|clang'
확인할 증거는 다음과 같습니다.
- 시스템 볼륨의 가용 공간과 파일 시스템의 inode 상태
- 실패한 작업의 커밋, 빌드 설정, 실행 계정과 작업 번호
- 같은 노드에서 병렬로 실행 중인
xcodebuild, 테스트, 아카이브 프로세스 - 오류가 처음 발생한 로그 한 줄과 그 직전의 쓰기 대상
- 작업 공간, 임시 폴더, 아카이브와 로그의 생성 시점
df -h의 여유 공간이 있어도 inode가 고갈되면 새 파일을 만들지 못할 수 있습니다. 반대로 특정 디렉터리만 비정상적으로 커지는 경우에는 전체 노드를 재구성할 이유가 아직 없습니다. 시스템 볼륨 전체를 바로 지우거나 노드를 다시 만드는 조치는 아카이브, 서명 자료와 진단 증거를 함께 없앨 수 있으므로 마지막 수단으로 남겨야 합니다.
당직 개발자는 작업 공간과 단일 빌드를 먼저 복구합니다
당직 개발자의 목표는 노드 전체를 깨끗하게 만드는 것이 아니라, 실패한 작업이 다시 실행될 수 있는 최소 범위를 확보하는 것입니다. 작업 공간 안에서 소스 코드, 생성물, 임시 파일, 중복 복제본을 나눠 보십시오.
du -sh /path/to/workspace/*
find /path/to/workspace -type f -size +1G -print
위 명령의 출력은 삭제 목록이 아니라 조사 목록입니다. 소스 코드와 아직 전달되지 않은 아카이브는 보존해야 합니다. 중단된 작업이 만든 임시 압축 파일, 재생성 가능한 테스트 출력, 종료한 작업의 임시 빌드 폴더는 소유자와 작업 상태를 확인한 뒤에만 처리합니다.
작업을 멈춘 뒤 다음 순서로 단일 재현을 진행합니다.
- 실패한 커밋과 동일한 소스 상태를 확보합니다.
- 동일한 Xcode 선택값과 빌드 설정을 기록합니다.
- 다른 작업이 사용하지 않는 것으로 확인된 재생성 가능 파일만 정리합니다.
- 같은 대상과 같은 아카이브 또는 테스트 명령을 다시 실행합니다.
- 성공 여부가 아니라 생성된 파일, 로그, 테스트 결과와 남은 공간 변화를 확인합니다.
공간을 조금 확보한 뒤 바로 다시 가득 찬다면 반복 빌드를 중지해야 합니다. 이 시점의 인계 자료는 삭제한 파일 목록, 삭제 전후의 df 출력, 실패한 커밋, 실행 계정과 함께 구성합니다. 원인이 공유 캐시나 보존 정책에 있을 수 있으므로 당직 개발자가 임의로 노드를 재생성해서는 안 됩니다.
빌드 유지보수자는 DerivedData와 의존성 캐시의 소유권을 확인합니다
DerivedData는 프로젝트와 실행 계정, Xcode 설정에 따라 위치가 달라질 수 있습니다. 고정된 경로를 모든 원격 Mac CI에 적용하면 다른 작업의 빌드 결과를 지울 수 있습니다. 먼저 현재 작업에서 사용하는 경로를 로그와 빌드 설정으로 확인하고, 디렉터리의 소유자·최근 수정 시각·실행 중인 프로세스를 함께 살펴봅니다.
xcodebuild -showBuildSettings \
-workspace /path/to/Workspace.xcworkspace \
-scheme /path/to/Scheme \
| grep -E 'OBJROOT|SYMROOT|CONFIGURATION_BUILD_DIR|DERIVED_DATA'
프로젝트가 위 명령을 사용하지 않는 구조라면 실제 CI 명령에 지정된 -derivedDataPath와 환경 변수를 확인해야 합니다. 경로를 확인하지 못한 상태에서 rm을 실행하는 것은 복구가 아니라 증거 훼손입니다.
패키지 캐시도 같은 방식으로 구분합니다.
- Swift Package 캐시: 다른 프로젝트가 공유하는지 확인합니다.
- Homebrew 또는 개발 도구 캐시: 재설치와 재해석에 걸리는 작업을 고려합니다.
- 프로젝트 전용 생성물: 해당 커밋에서 다시 만들 수 있는지 확인합니다.
- 실행 중인 캐시: 프로세스가 파일을 열고 있는지 확인합니다.
삭제 전에 병렬 작업이 모두 종료되었는지 확인합니다. 필요하다면 실행기를 일시적으로 격리하고, 캐시 디렉터리를 통째로 지우기보다 오래된 프로젝트 전용 생성물부터 처리합니다. Apple의 Command-line tools 문서는 명령 줄 개발 도구의 구성과 사용 범위를 확인하는 기준이 됩니다.
정리 뒤에는 캐시가 없어도 성공하는 깨끗한 빌드와, 같은 소스에서 캐시를 재사용하는 두 번째 빌드를 구분해 검증합니다. 첫 번째 빌드가 성공했다는 사실만으로는 캐시 정리가 안전했다고 볼 수 없습니다. 두 번째 실행에서 의존성 해석, 컴파일, 테스트가 정상적으로 이어지고 공간이 다시 비정상적으로 줄지 않아야 합니다.
담당자별 정리 범위와 보존 항목을 나눕니다
다음 표는 삭제 명령을 대신하는 판단표입니다. 실제 경로와 작업 상태는 노드마다 다르므로 표의 항목을 현장 증거와 대조해야 합니다.
| 담당자 | 먼저 확인할 대상 | 처리할 수 있는 대상 | 반드시 보존할 대상 | 복구 완료 조건 |
|---|---|---|---|---|
| 당직 개발자 | 실패 작업, 작업 공간, 중복 복제본 | 종료된 작업의 재생성 가능 임시 파일 | 소스, 미전달 산출물, 최초 오류 로그 | 같은 커밋과 설정으로 단일 빌드 재현 |
| 빌드 유지보수자 | DerivedData, Swift Package와 도구 캐시 | 병렬 사용이 없고 재생성 가능한 캐시 | 다른 작업이 공유하는 캐시와 진행 중인 파일 | 깨끗한 빌드와 재사용 빌드 모두 통과 |
| 테스트 담당자 | Simulator runtime, 기기 인스턴스, 테스트 출력 | 사용하지 않는 기기와 오래된 테스트 출력 | 현재 테스트 행렬의 runtime과 필요한 기기 | 기기 부팅, 테스트, 연결 복구 통과 |
| 릴리스 담당자 | 아카이브, 내보내기 패키지, 기호 파일 | 전달 상태가 끝난 중복 임시 산출물 | 승인 전 아카이브, 서명 자료, 키체인과 인증서 | 아카이브와 내보내기 또는 업로드 통과 |
| 플랫폼 담당자 | 계정별 증가량, 보존 기간, 재시작 후 상태 | 정책에 맞는 오래된 데이터 | 감사와 복구에 필요한 기록 | 재시작 뒤 예상 용량과 작업 복구 확인 |
테스트 담당자는 Simulator를 구성 요소별로 정리합니다
iOS Simulator의 저장 공간은 runtime, 기기 인스턴스, 앱 데이터와 테스트 생성물로 나누어 봐야 합니다. runtime을 삭제하면 특정 테스트 행렬을 실행하지 못할 수 있고, 기기 인스턴스만 정리해도 설치된 runtime 자체의 용량은 줄지 않을 수 있습니다.
먼저 실제 장치와 runtime 목록을 저장합니다.
xcrun simctl list devices
xcrun simctl list runtimes
xcrun simctl help
Apple의 시뮬레이터와 실제 기기 실행 안내와 Device Hub 관리 문서를 기준으로 현재 테스트 대상과 사용하지 않는 대상을 나눕니다. 명령 줄 도움말의 실제 출력이 설치된 Xcode와 다르면 문서의 예시보다 현장 출력이 우선입니다.
정리 조건은 다음과 같습니다.
- 현재 또는 예약된 테스트가 사용하는 runtime인지 확인합니다.
- 실패한 작업이 만든 기기 인스턴스와 테스트 출력인지 확인합니다.
- 다른 프로젝트가 공유하는 기기 이름과 식별자를 확인합니다.
- 공식 Xcode 구성 요소 관리 화면이나 지원되는 명령 줄 방식으로 처리합니다.
- 시스템 보호 디렉터리를 직접 수정하지 않습니다.
삭제 후에는 목록이 줄었다는 사실만 확인해서는 안 됩니다. 필요한 runtime을 인식하는지, 테스트 기기가 부팅되는지, 앱 설치와 테스트가 끝나는지, SSH 연결이 끊겼다가 다시 연결된 뒤 작업 상태가 올바른지 확인해야 합니다. runtime을 지운 뒤 다운로드가 다시 필요해지는 경우도 있으므로, 테스트 일정이 임박했다면 먼저 대체 노드나 격리된 검증 노드를 확보해야 합니다.
릴리스 담당자는 아카이브와 서명 자료를 정리 대상에서 분리합니다
아카이브는 단순한 캐시가 아닙니다. 승인, 오류 분석, 재배포와 감사에 필요한 전달 증거일 수 있습니다. Apple의 앱 아카이브와 배포 절차는 아카이브 이후의 내보내기와 배포 단계를 구분하므로, 파일 상태를 확인하지 않고 자동 삭제 규칙에 넣어서는 안 됩니다.
다음 항목을 상태별로 기록합니다.
- 아직 내보내지 않은
xcarchive - 내보내기가 끝났지만 업로드하지 않은 패키지
- 업로드와 검증이 끝난 배포 산출물
- 디버깅과 오류 분석에 필요한 기호 파일
- 키체인, 인증서, 프로비저닝 프로파일과 서명 설정
Apple의 디버깅 정보가 포함된 빌드 문서를 참고해 기호 파일과 아카이브의 보존 목적을 분리합니다. 키체인이나 인증서 파일을 공간 확보 대상으로 취급해서는 안 됩니다. 해당 자료를 지우면 다음 빌드가 공간 문제와 무관하게 서명 단계에서 실패할 수 있습니다.
정리 뒤에는 아카이브 생성, 내보내기 또는 업로드 중 실제 파이프라인에서 사용한 경로를 재검증합니다. 성공한 파일이 생겼더라도 로그와 산출물의 위치가 보존 정책에 맞는지 확인해야 합니다.
플랫폼 담당자는 재발 방지와 확장 여부를 결정합니다
공유 노드가 다시 가득 차는 문제는 단일 캐시 삭제로 끝나지 않습니다. 프로젝트별 작업 공간, DerivedData, 패키지 캐시, Simulator 데이터와 아카이브에 소유자를 지정하고, 작업 종료·배포 완료·노드 재시작 시점마다 정리와 보존 결과를 관찰해야 합니다.
다음과 같은 운영 기록을 남기는 방식이 적합합니다.
df -h /
df -i /
du -sh /path/to/workspace
du -sh /path/to/derived-data
du -sh /path/to/archive
xcrun simctl list
공유 Mac Runner의 보존 규칙에는 최소한 다음 조건이 들어가야 합니다.
- 실행 중인 작업이 사용하는 파일은 자동 삭제하지 않습니다.
- 배포 전 아카이브와 서명 자료는 별도 보존 영역으로 둡니다.
- 프로젝트 전용 캐시는 재생성 비용과 재사용 가치를 함께 평가합니다.
- Simulator runtime은 테스트 행렬에 필요한 버전과 분리합니다.
- 작업 종료 뒤 정리 결과와 남은 공간을 로그로 남깁니다.
- 재시작 뒤 도구 선택, SSH 연결, 테스트와 배포 작업을 다시 확인합니다.
정상적인 빌드·테스트·아카이브를 보존 정책대로 유지했는데도 공간이 반복해서 부족하다면 전면 삭제를 계속할 이유가 없습니다. 개발 빌드와 릴리스 아카이브를 다른 노드로 나누거나, 유휴 데이터의 보존 기간을 줄이거나, 더 큰 저장 공간을 가진 원격 Mac으로 옮기는 판단이 필요합니다. 원격 Mac 구성 선택 가이드를 검토할 때도 광고 문구보다 실제 프로젝트의 빌드, Simulator 테스트, 아카이브와 재시작 복구를 기준으로 비교해야 합니다.
복구 전후를 확인하는 실행 목록
아래 항목은 노드 재구성 전에 책임자별 인계를 완료하기 위한 체크 목록입니다.
- [ ] 새 빌드와 테스트 큐를 멈추고 실패한 작업의 최초 오류를 보존했습니다.
- [ ] 실행 계정, 작업 경로, 커밋, Xcode 설정과 병렬 작업을 기록했습니다.
- [ ]
df -h와df -i결과를 저장했습니다. - [ ] 작업 공간에서 소스 코드와 재생성 가능한 산출물을 구분했습니다.
- [ ] DerivedData의 실제 경로와 사용 중인 프로세스를 확인했습니다.
- [ ] Swift Package와 도구 캐시의 소유자와 재사용 여부를 확인했습니다.
- [ ] 현재 테스트 행렬이 사용하는 Simulator runtime과 기기를 기록했습니다.
- [ ] 아카이브, 내보내기 패키지, 기호 파일과 서명 자료의 상태를 확인했습니다.
- [ ] 삭제 대상이 병렬 작업에서 사용되지 않는다는 증거를 남겼습니다.
- [ ] 같은 커밋과 설정으로 깨끗한 빌드를 재현했습니다.
- [ ] 캐시 재사용 빌드와 Simulator 테스트를 완료했습니다.
- [ ] 아카이브와 내보내기 또는 업로드를 다시 검증했습니다.
- [ ] 노드 재시작 뒤 도구, 연결, 테스트와 복구 상태를 확인했습니다.
- [ ] 정상 보존 범위가 노드 용량을 넘는다면 분리·정책 변경·확장 중 하나를 결정했습니다.
현재 방식이 작은 Linux 서버나 임시 가상 환경에 의존하고 있다면, macOS 전용 Xcode와 Simulator를 같은 방식으로 다루기 어렵고, 공유 디스크의 캐시와 아카이브가 한 노드에 쌓이며, 물리 Mac이 없는 상태에서는 재시작 후 실제 배포 경로를 검증하기도 어렵습니다. 안전한 정리 뒤에도 정상 작업량이 계속 용량을 소진한다면, NodeMini의 원격 Mac 주문 옵션에서 실제 프로젝트로 저장 공간, 장시간 실행, Simulator와 아카이브 복구를 먼저 검증하는 편이 합리적입니다. 단기간의 CI 복구나 테스트 노드가 필요할 때는 구매보다 렌탈 기간과 작업 보존 정책을 맞추기 쉽지만, 장기적으로 계속 높은 부하를 유지하거나 특정 물리 포트가 필요한 팀이라면 직접 장비를 운영하는 편이 나을 수 있습니다.