Apple Silicon 클라우드 Mac Runner 메모리 피크와 스왑 거버넌스: 컴파일·Docker·Xcode

핵심 요약

스왑 증가 + 압축기 큐 상승을 사용자 타임아웃보다 먼저 SLO 위반으로 보세요. 꼬리 지연부터 터집니다.
풀 Docker 빌드와 전체 iOS 아카이브를 한계 없이 동시에 돌리면 최악의 피크가 재현됩니다. 순서를 나누거나 러너를 분리하세요.
CI 컨테이너에는 RSS 한도, 네이티브 빌드에는 명시적 -j를 노출하세요. 노트북 기본값은 7×24 호스트에 맞지 않습니다.
피크 RSS와 에이전트 오버헤드를 요금 RAM − macOS 베이스라인에 맞추고, 직렬화로 못 없애는 스파이크용 약 2~4GB 여유를 남깁니다.

클라우드 Mac Runner에서 컴파일과 컨테이너 단계가 겹칠 때의 메모리 계획을 상징하는 노트북 화면 — 스톡 이미지는 리듬용입니다. 실제 기준은 컴파일·컨테이너 단계가 겹칠 때 직접 찍은 `vm_stat` 샘플입니다.

1. 왜 피크가 겹치나: 컴파일러, 컨테이너, Xcode

네이티브 컴파일러는 코어 수에 맞춰 잡을 때 큰 AST와 병렬 코드젠 아레나를 씁니다. Docker Desktop·Colima류는 가상화 페이지·오버레이 캐시를 더하고, 파이프라인에 amd64 이미지가 섞이면 Rosetta 경로로 메모리·헬퍼가 불어납니다. Xcode는 모듈 그래프·Swift explicit modules·진단이 켜진 스킴까지 합치면 CI가 데스크톱 설정을 물려받을 때 특히 무겁습니다.

이들은 “잘못”이라기보다 동일한 통합 메모리에 대한 동시 출금입니다. 클라우드 러너는 비용 절감을 위해 릴리스·야간 퍼즈·컨테이너 통합 테스트를 한 호스트에 몰기 쉬워 패턴이 증폭됩니다. 컨테이너 가드레일과 메모리 상한은 자연스럽게 한 세트인데, 이미지 클래스 선택으로 의도치 않은 멀티아키 폭발을 줄이려면 Apple Silicon 클라우드 Mac에서 프로덕션 Docker: arm64/amd64 이미지, 바인드 마운트·빌드 캐시 문제 해결 핸드북(요금제 리소스 한계 포함)를 함께 두면 좋습니다.

2. SSH만 있어도 통하는 관측

세 밴드를 잡으세요: 호스트 적분, 용의 프로세스, 컨테이너 예산. 호스트에서는 vm_stat로 페이지아웃·압축 통계를, 지원 빌드에서는 memory_pressure류 CLI를 소크 구간에 페어링하세요. 일반 “메모리 사용률” 그래프와 별도로 스왑파일 발자국을 추적합니다. Apple Silicon은 압축이 공격적이라 스왑은 늦게 오지만 결정적 신호입니다.

Docker는 대표 파이프라인에서 docker stats RSS와 한도를 긁고, 컨테이너 안 컴파일 병렬도와 한도를 맞춰 cgroup 스로틀과 호스트 전역 스왑 사이의 진동을 줄입니다. Xcode 중심 레인에서는 Derived Data 전략을 바꿀 때 피크 상주 크기를 로그로 남기세요. 디스크 압력은 캐시 축출로 RAM을 간접 압박하므로 inode·SSD 여유는 Apple Silicon 클라우드 Mac Runner 디스크·inode 거버넌스: Derived Data, 컨테이너 레이어, 통합 로그·캐시——할당량 경보, 계층형 정리와 요금제 저장 한계의 용량 계획과 같은 런북으로 정리해 유지보수 스크립트가 빌드와 I/O·메모리 대역폭을 다투지 않게 하세요.

# 가벼운 샘플링 훅(CI 진단 사용자로 실행)
vm_stat | head -n 20
sysctl vm.swapusage
docker stats --no-stream 2>/dev/null || true

3. 텔레메트리가 노란불일 때 성능 저하 플레이북

무거운 레인 직렬화: RAM이 빠듯한 요금에서 한도 검증 없이 xcodebuild archive와 다중 서비스 Docker 빌드를 동시에 돌리지 마세요.

병렬도 클램프: 컨테이너가 있을 때 Swift/clang 잡 수를 물리 코어와 반비례하게 줄이고, sysctl hw.ncpu에서 에이전트 예약을 뺀 고정 -j를 권장합니다.

CI 매트릭스 샤딩: UI 테스트·백엔드 통합·패키징을 한 거대 그래프 대신 큐 단계로 나누면 벽시계는 조금 늘어도 꼬리 지연은 줄어듭니다.

arm64 네이티브 이미지 우선과 qemu 무거운 경로 축소, 작은 빌드 컨텍스트로 BuildKit이 거대 중간 레이어를 RAM에 붙잡는 일을 줄입니다.

4. 요금 RAM 경계와 헤드룸 계산

kvmboot 요금은 16GB 통합 메모리와 더 큰 번들의 24GB를 중심으로 합니다(요금제 및 사양). macOS·호스트화된 CI에서 못 떼는 서비스·모니터링 에이전트·SSH 세션에 약 4~6GB를 빼고, Screen Sharing 등 원격 GUI가 항상 켜져 있으면 약 1GB를 더 빼세요.

남는 용량이 병렬도 예산입니다. 큰 iOS 아카이브 한 번이 링킹 구간에서 두 자릿수 GB RSS로 치솟을 수 있고, 여기에 소형 Docker 서비스 두 개만 더해도 16GB 요금은 악의 없이 포화됩니다. 24GB는 레인을 어느 정도 겹치거나 아카이브 직렬화를 줄이면서도 스왑 여유를 남기려는 팀에 맞습니다. 동시성을 RAM 폭으로 살지 추가 러너로 살지는 조직 큐 경제와 함께 보세요.

5. 증상·원인·조치

증상	가능성 높은 원인	권장 조치
로컬에선 통과하는데 CI에서 CPU 한가한 타임아웃	스왑 스래싱 또는 압축기 정체	병렬도 하향; 스왑 측정; Docker와 Xcode 피크 시간 분리
Docker 빌드가 하루 첫 성공 후 같은 날 실패	데몬 RSS 누적·누수된 빌더	빌더 주기 재시작; 메모리 한도; buildkit 캐시 정리
의존성 업그레이드 직후 급격한 느려짐	모듈 그래프 팽창·더 큰 clang 모듈	캐시 오프라인 재구축; 동시 스킴 캡; 더 큰 RAM 요금 검토

6. 맺음말

Apple Silicon에서 스왑은 도덕적 실패가 아니라 스케줄링 신호입니다. 컴파일러·컨테이너·Xcode를 통합 메모리 위의 경쟁 테넌트로 보고, 불평 전에 계측하고, 산 피크를 실제로 산 RAM 요금에 맞추면 미스터리 아웃티지 대신 계획된 알람을 얻습니다.