모바일 팀은 Mac mini M4마다 “시뮬레이터를 전부” 돌리고 싶어 하지만, 과구독의 첫 신호는 CPU가 아니라 압축 메모리, 멈춘 SpringBoard 기동, 병렬도를 하나만 낮추면 사라지는 XCTest 타임아웃입니다. 이 글은 (1) RAM 계층별 안전한 병렬 시뮬레이터 레인 수와 (2) 스로틀 대 샤드 전환 타이밍을 담은 두 매트릭스, 변경 티켓에 붙일 수 있는 8단계 롤아웃, 운영자가 Slack 스레드를 다시 읽지 않아도 되는 FAQ 구조화 데이터를 묶습니다.
2026년 기준 전제는 Xcode 16 세대 런타임과 Apple Silicon M4, 스크린샷을 찍는 UI 테스트입니다. 같은 호스트에서 컴파일도 돌리고 컴파일 전용 풀이 없다면 표의 대수를 한 단계 낮춰 읽으세요. 야간 배치와 주간 PR 검증이 같은 풀로 들어오면, 주간에 보이던 여유가 야간에만 사라지는 전형적인 “가짜 용량” 문제가 납니다. 대기열 길이를 짧게 보이게 하려고 병렬도만 올리면 페이징 스톰이 지배적이 되어 p95가 악화됩니다.
대기열을 줄이는 대신 시뮬레이터 병렬만 늘리고 있다는 신호
- 플레이크가 밤에 몰림: 야간 파이프라인에서 네 개의 UI 스위트가 한 호스트에 겹치는데 노트북에선 시뮬레이터 두 대면 녹색.
- SpringBoard나 backboardd 워치독 종료가 늘어나는데
xcodebuild는 간헐적으로 성공을 보고함. - 디스크 성장 가속:
~/Library/Developer/CoreSimulator아래가 부풀고 CPU는 60% 미만—메모리 압력이 페이징과 이미지 churn을 유발.
이미 번들을 호스트 간에 샤딩한다면 Mac mini M4 UI 테스트 샤딩에서 수평 분할을 확인하세요. 이 기사는 물리 머신당 수직 상한을 규정합니다.
감사·용량 계획 맥락에서는 “몇 대의 시뮬을 올렸는가”보다 “깨끗한 부팅을 몇 번 했는가”, “압축 메모리 피크가 몇 GB로 얼마나 지속됐는가”가 설명 책임에 더 잘 견딥니다. 경영진에게는 “CPU 사용률이 낮다=여유”로 오해되기 쉬우므로 통합 메모리 실측과 디스크 수위를 같은 대시보드에 올리세요.
매트릭스 A — 통합 메모리 계층 대 안전한 병렬 시뮬레이터 레인
Xcode 16 세대 런타임, Apple Silicon M4, 스크린샷을 포함하는 UI 테스트를 가정합니다. 같은 호스트에서 컴파일도 돌린다면 한 단계 낮춰 해석하세요.
| RAM | 병렬 UI 시뮬레이터(동일 OS 메이저) | 유닛 테스트 전용 병렬 시뮬레이터 | 중단 증상 |
|---|---|---|---|
| 16 GB | 1(아주 작은 스위트면 2까지 시도) | 엄격한 티어다운 시 최대 3 | SpringBoard 재시작 루프가 시간당 2를 넘음 |
| 24 GB | 스크린샷 상한이 있는 UI 레인 2 | 유휴 종료 훅이 있으면 4 | 압축 메모리가 5 GB를 지속적으로 초과 |
| 32 GB 이상 | 컴파일이 분리되면 UI 레인 3 | 잡별 RSS 예산이 있으면 최대 6 | 스위트 중 APFS 여유가 45 GB 미만 |
표는 출발점입니다. Metal이나 큰 메모리 맵을 쓰는 앱이면 시뮬레이터당 상시 RSS가 예상보다 큽니다. 그때는 “대수”보다 “잡당 RSS 상한”과 “스크린샷 장수 상한”을 먼저 조입니다. 반대로 유닛만 있고 화면 그리기가 거의 없으면 오른쪽 열을 조심스럽게 늘릴 수 있지만, 그 경우에도 CoreSimulator 디스크 팽창은 별도로 감시해야 합니다.
매트릭스 B — 스로틀 정책 대 정리 주기(✓ / ✗)
| 정책 | RAM에 도움 | 과하면 처리량 손해 | 도입 시점 |
|---|---|---|---|
| 잡마다 시뮬레이터 종료 | ✓ | ✓ | 컴파일 전용 호스트가 없는 혼합 테넌트 풀 |
| 파이프라인 전체에서 부팅 상태 재사용 | ✗ | ✗ | 단일 팀 전용 호스트에 일일 퍼지 창이 있을 때만 |
| 주간으로 사용 불가 기기 지우기 | ✓ | ✓ | 항상. 디스크 보존 지표와 짝 |
“매 잡마다 지우기”와 “오래 재사용”의 중간으로, 나이틀리 직전에만 풀 지우기를 하는 운용도 있습니다. 중요한 것은 지우기 잡이 실패했을 때 누가 알아차리느냐입니다. 10분을 넘기면 이상 징후로 알리고 수동 개입 Runbook에 연결하세요.
페이징이 top이 아니라 CoreSimulator 안에 숨는 이유
활동 모니터에는 작은 발자국의 프로세스가 많이 보이지만, 시뮬레이터 스택은 그래픽과 파일 시스템용 큰 백킹 스토어를 잡고 앱 설치 구간에서 스파이크합니다. Apple Silicon 통합 메모리에서는 그 스파이크가 컴파일 데몬·Swift 런타임 캐시와 경쟁합니다. 실무적 수정은 xcodebuild -parallel-testing-worker-number를 올리는 것이 아니라 조직 SKU에 맞는 매트릭스 A 행에 맞추는 것입니다.
원격 Mac 플릿은 문제를 증폭시킵니다. 러너가 홍콩·일본·한국·싱가포르·미국에 있을 때 개발자는 지연시간을 병목으로 가정하기 쉽지만, 도쿄 16 GB RAM 위의 시뮬레이터 네 대는 버지니아 16 GB 위의 네 대와 같이 행동합니다. 지리는 기가바이트를 만들지 않습니다.
병렬 계획은 큐 SLO용 풀 크기와 함께 읽고, “ui-heavy” 라벨이 너무 작은 호스트에 절대 닿지 않게 오케스트레이터를 설정하세요.
한 걸음 더 들어가면 시뮬레이터 부팅 횟수 자체가 비용입니다. 부팅은 테스트가 아니라 인프라 작업이며, 부팅 빈도가 머지율을 앞지르면 큐가 막힌 게 아니라 시뮬레이터를 너무 자주 죽이고 있을 수 있습니다. 티어다운을 지나치게 빡빡하게 하면 역효과이므로, 매트릭스 B의 ✓/✗를 테넌트 분리 정도에 맞춰 조정하세요.
오케스트레이터 라벨이 현실을 드러내는 이름인가
macos-latest 같은 친숙한 라벨은 큐가 16 GB인지 32 GB인지 숨깁니다. 풀 이름에 RAM 등급과 시뮬 정책을 넣고 예를 들어 mac-m4-24g-ui-max2처럼 하면 제품 팀이 스크린샷 무거운 스위트를 컴파일 전용으로 산 호스트에 실수로 흘려보내는 사고를 막습니다.
라벨 변경과 함께 시간당 시뮬레이터 부팅 수를 그리는 대시보드를 두세요. 부팅이 머지된 PR 수보다 빠르게 오르면 코드를 테스트하는 게 아니라 시뮬레이터를 헛돌리는 상태입니다. 임원이 “무해한 Xcode 패치 뒤 모바일 속도가 수수께끼처럼 떨어졌다”고 묻기 전에 스로틀하세요.
Runbook에 한 번 써 둘 숫자 기본값
- 유휴 타임아웃: XCTest 트래픽이 20분 없으면 시뮬레이터 전원 내림.
- 재시도 상한: PR당 UI 테스트 재시도는 2회로 캡—시스템적 메모리 압력을 가리지 않기.
- 워치독 예산: 천 테스트당 SpringBoard 크래시가 0.5%를 넘으면 강제 스로틀 트리거.
황금률: 주간 CoreSimulator 크기가 디스크 가드 아래로 떨어지고 압축 메모리가 나이틀리에서 평탄해질 때까지 병렬 워커를 올리지 말 것.
여덟 가지 롤아웃 단계
- 측정: 병렬 워커, p95 UI 잡 시간, CoreSimulator 디렉터리 크기의 베이스라인.
- 태그: 호스트를 RAM 계층으로 분류하고 16 GB에 UI 무거운 라벨을 명시 승인 없이 금지.
- 구현: 파이프라인 티어다운에 종료 훅—성공 경로뿐 아니라 실패 경로에도.
- 스케줄: 주간 지우기 잡, 소요 10분 초과 시 알림.
- 문서: 롤백은 병렬을 절반으로 하는 단일 환경 플래그면 충분하게.
- 교육: 로컬에서 시뮬레이터 여덟 대가 돌았다고 CI 용량 증명이 되지 않음을 모바일 엔지니어에게.
- 짝: 스크린샷·비디오 산출물 정책을 맞춰 밤에 디스크가 다시 채워지지 않게.
- 스케일 아웃: 스로틀이 정직한데도 큐가 SLO를 깨면 NodeMac 호스트를 UI 전용으로 추가.
여덟 단계는 변경 관리 관점에서도 붙이기 좋은 입도입니다. “측정 없는 병렬도 변경”은 거의 항상 롤백 티켓이 되므로 티켓에 베이스라인 수치를 반드시 붙이세요. 호스트 추가 판단은 감정이 아니라 SLO 위반 지속 시간과 비용으로 설명이 통합니다.
FAQ
Apple Silicon이 Intel보다 시뮬레이터를 “알아서” 더 많이 처리하나요?
와트당 처리량은 낫지만 RAM은 여전히 유한합니다. M4는 CPU 변명을 줄일 뿐 물리는 바뀌지 않습니다.
시뮬레이터가 DerivedData 볼륨을 공유해도 되나요?
잡마다 DerivedData 루트를 분리해 inode churn을 줄이는 편을 권합니다. 캐시 병합은 컴파일 전용 호스트에만.
SSH 중심 러너 가이드는 어디서 읽나요?
시뮬레이터 미세 조정 전에 NodeMac 도움말 센터에서 원격 접근 패턴을 확인하세요. 고지연 링크에서 화면 조작까지 무리하게 SSH에만 기대면 인위적 플레이크가 늘어납니다.
솔직한 시뮬레이터 병렬성이야말로 Apple Silicon M4 GPU와 Neural Engine이 진가를 내는 조건입니다. RAM 스래싱이 멈추면 UI 테스트는 “수수께끼 타임아웃”이 아니라 실제로 끝납니다. 자동화에는 네이티브 macOS 위의 SSH, 막힌 시뮬 확인에는 VNC—디자이너가 로컬에서 하는 것과 같은 형태입니다. 리전별 전용 Mac mini M4 렌탈로 UI 풀과 컴파일 풀을 분리하면 동료에게 공유 Jenkins Mac 재부팅을 부탁할 필요가 줄어듭니다. 호스트당 예측 가능한 RAM이 설명의 핵입니다. 매트릭스가 “UI 전용 한 대 더”를 요구하면 무리하게 대수만 쌓기 전에 리전별 요금을 비교하세요.