2026 6개 리전 원격 Mac 스토리지 부족: 1TB/2TB 확장 vs 캐시 거버넌스 vs 제2대 추가 FinOps 3택1 매트릭스

약 11분 읽기 · MACCOME

핵심 결론: 싱가포르·일본·한국·홍콩·미동부·미서부의 전용 원격 Mac(M4 / M4 Pro)에서 「디스크가 거의 찼는데 빌드는 점점 느려진다」는 상황이 반복되면, 본문은 서명 가능한 답을 제공합니다. 1TB/2TB 확장, 캐시 거버넌스, 피크용 제2대 중 3택1 결정 매트릭스 + 6단계 Runbook + 3개 수위 임계값으로 선택하고 일/월/분기 리스와 연결합니다. 리전 지연·POC 전체 흐름은 반복하지 않고, 프로덕션 전 안정성 수용 이후 가장 흔한 다음 질문—디스크에 돈을 쓸지, 사용법을 바꿀지—에 답합니다.

원격 Mac 디스크 만료 시 가장 잘못 읽히는 6가지痛点

  1. 「지울 수 있는 팽창」을 「구조적 디스크 부족」으로 착각: DerivedData, 구 Simulator runtime, Docker 레이어, Gradle 캐시가 회수 가능 공간의 40–70%를 차지하는 경우가 많습니다. 주간 정리 후에도 7일 내 여유 15% 미만이면 확장/제2대 논의로 들어갑니다.
  2. df 퍼센트만 보고 디렉터리 귀속을 보지 않음: APFS 스냅샷, 로컬 Time Machine 스냅샷, 「기타 사용자」가 루트를 빨갛게 보이게 해도 Xcode를 느리게 하는 것은 단일 디렉터리의 선형 성장인 경우가 많습니다. 일괄 rm -rf 대신 계층 du 샘플링이 필요합니다.
  3. 디스크 확장을 만능으로 보고 CPU/메모리 큐 무시: iostat에서 디스크 이용률이 장기 40% 미만인데 빌드가 느리면 병목은 병렬도 또는 링커 메모리입니다. M4 Pro 또는 제2대가 2TB보다 효과적입니다.
  4. Monorepo + 다중 Simulator를 256GB 기준선으로 운영: partial clone은 fetch 크기를 줄이지만 로컬 중간 산출물·시뮬레이터 이미지는 브랜치·OS 버전마다 누적됩니다. Monorepo 슬림화 체크리스트와 함께 읽으십시오.
  5. 6개 리전에서 「한 대가 전부」: 빌드·UI 테스트·서명 업로드가 같은 디스크면 피크 주에 수위가 동시에 찹니다. 다중 빌드 풀 FinOps는 역할 분담을 다루고, 본문은 단일 노드 디스크 정책을 먼저 결정합니다.
  6. 단기 프로젝트에 월간 확장, 장기 기준선에 일일 삭제만: FinOps상 예측 가능한 상주 팽창은 1TB/2TB + 월/분기 리스, 2주 스프린트는 정리 + 일일 임대 제2대가 맞습니다. 14일 때문에 연간 티어를 고정하지 마십시오.

6개 리전 전용 Mac의 강점은 물리 디스크 경계가 명확하다는 점이지만, 명확함이 workload에 자동 맞춤을 의미하지는 않습니다. Apple Silicon 통합 메모리에서는 디스크·메모리 압력이 동상으로 나타납니다: Simulator 병렬, Swift 증분 컴파일, 컨테이너 레이어 캐시가 IO와 RAM을 동시에 올립니다. 3택1 결정 없이는 「다시 디스크 비우기」와 「한 대 더 추가」 사이를 오가며 리스를 낭비하고 릴리스를 지연합니다.

다지역 노드 리스·비용 가이드는 「어느 국가·어떤 리스 기간」을, 본문은 이미 고른 노드에서 디스크 병목의 1차 처리 순서를 답합니다. CocoaPods/SPM 미러·디스크 체크리스트와 보완—의존성 최적화는 「가짜 만디스크」를 줄이지만 DerivedData·시뮬레이터 자산 거버넌스를 대체하지 못합니다.

시그널 우선: 캐시 거버넌스 우선: 1TB/2TB 확장 우선: 제2대 / Pro
정리 후 7일 여유 <15% du 회수 가능 >30%이고 표준 정리 미실행일 때만 기본: 구조적 성장(다중 브랜치 DerivedData) CPU 큐 p95 동시 포화
단일 저장소 <8GB, Simulator OS 3+ 미사용 runtime·디바이스 세트 제거 2+ 대형 OS 이미지 상주 병렬 UI 테스트 worker >2
Monorepo + affected 활성화에도 매주 만디스크 blobless·캐시 경로 점검 기본: 중간 산출물 디렉터리 격리 실패 빌드·테스트 디스크/기기 분리 필수
릴리스 피크 10–14일만 기본: 정리 + 스냅샷 내보내기 2주를 위해 분기 리스 고정 비권장 일/주 임대 제2대가 유리
2TB 후 iowait <8%인데 느림 디스크 주원인 아님, 확장 중단 거부: 디스크 추가 금지 기본: 연산/동시성 병목
storage

메커니즘: APFS copy-on-write 때문에 대용량 디렉터리 삭제 후에도 「여유 공간」 표시가 즉시 회복되지 않을 수 있습니다(로컬 스냅샷 존재 시). 거버넌스 단계에 스냅샷 목록 확인을 포함하지 않으면 「200GB 지웠는데 df는 20GB만 회복」 같은 오판으로 확장을 선택하게 됩니다.

6단계 Runbook: 샘플링에서 3택1 서명까지

  1. 수위 기준선 고정: 총 용량, 여유율, 주요 마운트 기록. 노드 ID, Xcode 버전, 최근 정리 commit(스크립트 버전) 기재.
  2. 계층 du 샘플링(Top 12 디렉터리): ~/Library/Developer, DerivedData, CoreSimulator, ~/.gradle, ~/Library/Containers 등 계층 샘플, CSV 감사용 출력.
  3. 표준 정리 패키지 실행: 순서대로 DerivedData(현재 scheme 유지 가능), 미사용 Simulator runtime, Docker dangling 이미지, 구 Archives(릴리스 담당 확인).
  4. 24시간 기울기 재측정: 설명 가능한 릴리스 없이 여유가 하루 3%p 이상 감소하면 구조적 성장 표시.
  5. 매트릭스로 분기 선택: 캐시 거버넌스 / 1TB·2TB / 제2대. 근거 없이 「정리+확장+가機」 동시 투입 금지.
  6. FinOps 메모로 리스 고정: 구조적 → 월/분기 + 확장; 단기 피크 → 일/주 제2대. 대장에 재검토일 기록.
bash
# 디스크 Top 디렉터리 샘플링(원격 Mac에서 실행, WORK 경로 교체)
export WORK="$HOME"
df -h /
echo "---- top dirs under Library/Developer ----"
du -hd 1 "$HOME/Library/Developer" 2>/dev/null | sort -hr | head -12
echo "---- DerivedData total ----"
du -sh "$HOME/Library/Developer/Xcode/DerivedData" 2>/dev/null
echo "---- CoreSimulator ----"
du -sh "$HOME/Library/Developer/CoreSimulator" 2>/dev/null

리뷰 회의에 넣을 3가지 정량 임계값(상수는 팀 기준선으로 교체)

  • 정리 수익 비율: 표준 패키지는 현재 사용 중 공간의 18% 이상 회수해야 합니다. 12% 미만이면 팽창이 구조화—확장/제2대 매트릭스로 진입.
  • 여유 공간 레드라인: 프로덕션 빌드 호스트는 여유 20% 이상 유지. 15% 미만 시 전체 Archive + 병렬 UI 테스트 금지(POC 확장 KPI와 게이트 필드 공유 가능).
  • 확장 후 IO 검증: 1TB/2TB 확장 후 48시간 내 디스크 busy% 중앙값 <25%인데 빌드 시간 개선 없으면 리뷰에서 「디스크 추가」 옵션 종료, CPU/메모리·아티팩트 RTT 조사.

마무리: 「디스크 한 장 더」로 아키텍처 분담을 가리지 말 것

6개 리전 원격 Mac에서 디스크 결정의 본질은 압축 불가능한 working set과 압축 가능한 캐시를 분리하는 것입니다. 지울 수 있으면 거버넌스, 지울 수 없으면 확장 또는 분기, 지울 수 없고 연산도 포화면 디스크 추가를 멈추십시오—그것은 큐 병목에 대한 위로일 뿐입니다.

자체 Mac 호스팅·단기 클라우드 인스턴스는 「디스크」와 「운영」을 두 장의 청구서로 나누어 스냅샷·시뮬레이터 자산·공유 디스크의 복리를 과소평가하기 쉽습니다. 노트북 빌드 인계는 릴리스 주에 디스크와 절전 정책을 동시에 밟습니다. 전용 Apple Silicon, 예측 가능한 디스크 티어, 6개 리전 근접 노드가 필요한 팀은 본 매트릭스를 조달 부록에 넣고 MACCOME Mac 클라우드에서 1TB/2TB와 리스를 한 번에 맞추는 편이 임시 디스크 추가·무분별한 제2대보다 총소유비용이 낮고 CI·온콜이 같은 수위 언어를 공유합니다.

확장 또는 제2대가 확정되면 노드 리전과 리스 항목을 같은 리뷰에 가져오십시오. 가격·주기는 제품 페이지를 참고하고, 안정성 수용·Monorepo 글을 부록으로 남겨 릴리스 주에 용량과 파이프라인을 함께 논의하십시오.

FAQ

DerivedData를 지워도 디스크가 가득 찼습니다. 확장과 제2대 추가 중 무엇을 선택해야 하나요?

정리 후 7일 내 여유 15% 재하락, Developer 하위 디렉터리 du 비중이 높으면 1TB/2TB와 월간 리스를 우선 검토하십시오. CPU/메모리 큐도 포화되면 다중 빌드 풀 글을 참고해 제2대를 추가합니다. 티어·가격은 대여 가격을 참고하십시오.

2TB로 확장했는데도 빌드가 느립니다. 디스크 문제인가요?

반드시 그렇지는 않습니다. IO가 한가한데 컴파일이 느리면 안정성 수용·아키텍처 매트릭스로 연산과 네트워크를 구분하십시오. 운영 세부는 고객 센터를 참고하십시오.