프로모

Apple Silicon 클라우드 Mac Runner 디스크·inode 거버넌스: Derived Data, 컨테이너 레이어, 통합 로그·캐시——할당량 경보, 계층형 정리와 요금제 저장 한계의 용량 계획

Runner 운영·용량
2026-05-08 읽는 데 약 6분

무인 클라우드 Mac Runner에서 먼저 터지는 것은 CPU가 아니라 디스크 용량과 inode입니다. DerivedData, Docker 레이어, ~/Library/Logs 통합 로그, npm·pip·Maven 로컬 캐시가 겹치면 큐만 깊어져도 “돌아가는데 쓰기 실패”가 납니다. 이 글은 관측 지표, 계층형 정리 순서, 요금제 SSD 경계 세 축으로 런북에 바로 붙일 수 있게 정리합니다.

핵심 요약

  1. 블록 사용량과 inode를 동시에 본다. 작은 파일 폭주는 node_modules, 인덱스, 로그 샤드에서 흔하다.
  2. 정리는 재다운로드 가능 캐시 → 재빌드 가능 산출물 → 승인 필요 데이터 순으로 층을 나누고, 야간 스크립트가 비밀·아티팩트 캐시를 건드리지 않게 한다.
  3. 컨테이너와 호스트는 별도로 계량한다. docker system df와 APFS 여유를 같이 보며, 명령·경계는 Apple Silicon 클라우드 Mac에서 프로덕션 Docker: arm64/amd64 이미지, 바인드 마운트·빌드 캐시 문제 해결 핸드북(요금제 리소스 한계 포함)과 맞춘다.
  4. Xcode·서명 파이프라인과 디스크 예산을 같이 볼 때는 Apple Silicon 클라우드 Mac에서 iOS/macOS CI: codesign, Notarization, stapler와 키체인 경계——재현 가능한 파이프라인과 흔한 거절 코드·오류 대응 표의 체크리스트와 짝지어 온콜이 한 화면에서 끝나게 한다.
데이터센터 스토리지 랙 분위기, 클라우드 Mac Runner 디스크·용량 계획을 상징
표지는 분위기용이다. 운영에서는 실제 df, df -i, 통합 로그·CI 산출물 보존 정책을 기준으로 삼는다.

1. 이중 천장: 블록과 inode

APFS에서 “수십 GB 남았는데” No space left on device가 나오면 대개 inode·메타데이터 압박이다. Runner에서 흔한 원인은 잡마다 생기는 Xcode DerivedData, 회전 없는 통합 로그, npm·pip·Maven 로컬 저장소, 저장소를 컨테이너에 바인드할 때 생기는 소량 파일 폭증이다. 경보는 disk > 85%와 inode > 85%(또는 파일 수 프록시)로 나누고, Grafana·슬랙 등에서 색을 달리해 용량 막대만 보는 실수를 줄인다.

2. 계층형 정리: 순서가 정책이다

첫 층은 다시 받거나 다시 빌드해도 되는 경로만: 언어 패키지 캐시, 잡별 /tmp 워크스페이스, 오래된 .xcresult 묶음이다. 둘째 층은 재현 가능하지만 시간이 드는 DerivedData, Docker BuildKit 캐시, 댕글링 이미지·시뮬레이터 런타임 캐시로, 앞서 Docker 핸드북의 명령·한도와 맞춘다. 셋째 층은 변경 요청이 필요한 아티팩트 캐시·감사 로그로, 야간 일괄 삭제를 금지하고 보존 주기를 문서화한다.

층 대표 경로·대상 위험·조치
L1 폐기 가능 패키지 캐시, 잡 workspace/tmp 낮음. 잡 finally에서 비우거나 임시 볼륨을 분리한다.
L2 재빌드 DerivedData, Docker 레이어, 시뮬레이터 캐시 중간. 정리 전 태그·이미지 버전을 남기고 실행 중 인덱싱과 겹치지 않게 한다.
L3 승인 필요 아티팩트 캐시, 감사 로그, 업로드 디렉터리 높음. 보존·법무 주기를 따르고 스크립트 일괄 삭제를 금지한다.

동시에 돌아가는 잡 수를 늘리기 전에, 디스크·inode P95와 정리 잡이 겹치는지부터 본다. “한 번에 비우기”보다 잡 단위로 L1을 비우고, 주간 창에만 L2를 돌리면 운영이 예측 가능해진다.

3. 컨테이너 레이어, 통합 로그, 요금제 경계

Docker 이미지 레이어는 SSD에서 중첩 쓰기로 쌓여 병렬 빌드가 IOPS와 가용 블록을 동시에 깎는다. 통합 로그를 용량 한도 없이 두면 수개월 만에 단일 Runner에서도 수 GB를 먹는다. 256 GB / 512 GB 요금제는 “시스템·툴체인·2주 롤링 산출물·15% 버퍼”로 모델링하고, 버퍼가 바닥나면 CI 실패뿐 아니라 Spotlight·키체인 유지보수까지 느려진다. 컨테이너 log 옵션의 max-size와 호스트 newsyslog·aslmanager 정책을 골든 이미지에 박아 두는 편이 사후 rm -rf보다 싸다.

Xcode와 컨테이너 단계를 한 호스트에서 돌리면 주간 고정 창에 읽기 전용 점검을 넣는다. df -h, df -ih, 상위 몇 개 du -sh *, docker system df 결과를 객체 스토리지나 티켓에 append해 “지난주 무엇이 커졌는지”를 비교하면 디스크가 붉을 때만 grep하는 상황을 줄인다.

4. 맺음말

좋은 Runner 거버넌스는 할당량을 볼 수 있고, 정리는 반복 가능하며, 경계는 설명 가능해야 한다. 같은 숫자가 SRE 경보와 조달 설명(다음 디스크 단계가 왜 필요한지)에 모두 쓰이게 표를 온보딩에 붙이면 첫 당번이 inode 함정을 덜 밟는다.

클라우드 Mac mini에서 용량과 성능이 더 예측 가능해진다

Apple Silicon 통합 메모리는 Xcode·시뮬레이터·병렬 빌드를 같이 올릴 때 스왑 트리거로 “가짜 멈춤”이 덜 나게 한다. macOS에서 APFS·통합 로그·네이티브 툴체인 의미가 한 줄로 이어져 리눅스 호스트와 macOS 게스트 사이를 오가며 번역할 필요가 줄어든다. 단독 클라우드 Mac은 디스크 I/O·inode 압력을 이웃 테넌트와 분리하고, M 시리즈는 에너지 효율과 부피가 작아 7×24 Runner의 총소유비용이 노트북을 빌드기로 쓰는 경우보다 유리한 경우가 많다. Gatekeeper·SIP는 공급망 변조 면도 줄여 준다.

CI·셀프호스팅 Runner에 관측 가능한 디스크 할당과 정리 런북을 심고 있다면, kvmboot 클라우드 Mac mini M4는 비용 대비 좋은 출발점이다——요금제 안내를 바로 본다면 Derived Data와 컨테이너 캐시가 큐를 망가뜨리는 일을 줄이는 데 도움이 된다.