공유 Mac에서 병렬 테스트만 켜면 속도가 나는 듯하다가, 곧 CoreSimulator 타임아웃·디바이스 미탑재·로컬에선 재현되지 않는 flake로 바뀝니다. 원인은 종종 테스트 자체보다 동시에 뜨는 시뮬레이터가 RAM·스토리지 대역·백그라운드 서비스를 두고 싸우는 스케줄링 문제입니다. 여기서는 Test Plan 샤딩으로 폭풍 부팅을 피하는 법, 고메모리 노드가 실제 동시성에 기여하는 조건, worker 수를 디스크 워터마크와 맞추는 방법을 FAQ 형태로 정리합니다. 러너를 여러 대로 나누는 오케스트레이션은 OpenClaw·GitHub Actions 다중 러너 실전을, 상시 호스트의 launchd·포트 안정성은 OpenClaw 게이트웨이 launchd 안정성 핸드북과 함께 보세요.
1. 공유 Mac에서 시뮬레이터 경합이 의미하는 것
병렬 XCTest는 CPU만 다투지 않습니다. 각 목적지는 launchd_sim, SpringBoard, 시뮬레이터 데이터 금고에 대한 I/O, Metal·윈도 서버, 간헐적인 런타임 설치까지 끌어옵니다. 한꺼번에 부팅하면 디바이스 사용 불가, test runner exited 같은 메시지가 먼저 옵니다. 증상을 동시 부팅 그래프 문제로 보고, 호스트별 동시성 한도를 계측하세요.
2. Test Plan 샤딩: 머신을 늘리기 전에 계획을 쪼갠다
XCTest Plan(.xctestplan)으로 스위트·태그·구성을 표현하면 스킴 복제 없이 위험 단위를 나눌 수 있습니다. 샤드마다 겹치지 않는 슬라이스—단위, 태그된 통합, 신선 설치가 필요한 UI 흐름—을 매핑하고, 무거운 UI 샤드는 RAM·SSD 여유가 큰 호스트로 라우팅하세요. 모든 플랜을 모든 매트릭스 다리에 얹으면 제거하려던 시뮬레이터 러시가 되살아납니다. 가능하면 호스트당 설치·런치는 직렬로 두고 테스트 본문만 병렬화해 패키지 압축 해제가 CoreSimulator와 싸우지 않게 하세요.
3. Xcode 내부 병렬 worker와 플릿 단위 worker
한 xcodebuild 잡 안의 최대 병렬 테스트 worker는 로컬 팬아웃을 제한합니다. 플릿 전체 팬아웃은 러너 수×매트릭스 다리×잡 내 병렬도의 곱입니다. 둘을 동시에 올리면 통합 메모리 한도에 빨리 닿고, 페이징이 시뮬레이터를 무너뜨립니다. 작은 Mac 한 대에 UI 잡을 몰아 넣기보다, 적당한 잡 내 병렬을 맞춘 뒤 머신 수를 늘리는 쪽이 안전합니다.
4. 고메모리 노드: RAM이 진짜 동시성을 살릴 때
여러 목적지를 동시에 띄우거나 커밋 사이에 시뮬레이터를 따뜻하게 유지할 때 고메모리 Mac이 빛납니다. 반대로 모든 샤드가 같은 CoreSimulator 큐를 두드리면 병목만 옮길 뿐입니다. 샤드당 RSS와 설치·런치 스파이크, Swift 캐시·윈도 서버 여유를 더해 산정하고, 같은 호스트에서 빌드와 테스트를 같이 돌리면 컴파일 데몬과 시뮬레이터가 RAM을 나눠 쓰므로 디스크 지연이 포화면 큰 RAM도 헛돌 수 있습니다.
5. worker 수와 디스크 워터마크의 결합
worker를 늘릴수록 DerivedData, 로그, 스크린샷, 크래시 리포트, CoreSimulator 데이터가 배로 쌓입니다. 컴파일 전용 CI에선 평탄해 보이던 디스크가 UI 스위트에서 기울기 시작합니다. 경고 워터마크(정리·샤드 일시 정지)와 하드 스톱(로그인·러너가 깨지기 전에 우회) 두 단계를 두세요. 시간당 기가바이트가 worker 비에 비례해 늘면 CPU와 무관하게 디스크 한계입니다.
6. FAQ: 팀이 자주 비교하는 선택
Q: 작은 Mac 여러 대 vs 대용량 RAM 소수? 호스트당 시뮬레이터 1~2대 캡으로 폭발 반경을 줄이려면 소형이 유리하고, 캐시를 따뜻하게 유지·컴플라이언스 호스트 수를 줄이려면 대형이 유리합니다. 둘을 섞을 땐 라우팅 규칙을 명시하세요.
Q: Test Plan을 브랜치에 맞출까? 리스크 등급과 런타임 요구에 맞추고, 브랜치 이름에 맞추면 매트릭스가 폭발합니다.
Q: CPU가 낮은데 잡 내 병렬을 올려도 될까? 시뮬레이터 서비스와 디스크가 먼저 포화될 수 있어 CPU만으로 판단하면 안 됩니다.
Q: UI CI에서 가장 먼저 알람을 걸 지표는? 남은 디스크와 하네스 5xx급 실패를 짝으로 두세요. 하나만 보면 오판하기 쉽습니다.
7. 병렬도를 다시 올리기 전 운영 체크리스트
- 샤드마다 겹치지 않는 Test Plan 또는 구성으로 가장 무거운 경로가 중복되지 않는가?
- 호스트별 동시 시뮬레이터 상한이 라벨·오케스트레이터 동시성 그룹으로 강제되는가?
- RAM 여유는 평균이 아니라 최악의 동시 부팅 기준으로 검증했는가?
- 디스크 워터마크가 런 스코프 폴더 자동 정리를 먼저 트리거하는가?
- 병렬 실험을 한 번에 되돌릴 플래그 한 줄이 있는가?
XCTest 풀을 현실적으로 굴릴 때 Mac mini·macOS가 남는 이유
시뮬레이터와 테스트 스택은 지원되는 Mac 하드웨어와 예측 가능한 GPU 전제에 맞춰져 있습니다. Mac mini급 Apple Silicon은 통합 메모리와 낮은 유휴 전력(예: M4급 약 4W)으로 워밍 풀 비용을 줄이고, macOS 안정성과 Gatekeeper·SIP·FileVault는 무인 호스트 설명을 단순화합니다.
Test Plan 규칙과 RAM·디스크 가드레일을 맞추면 Mac mini M4급 호스트에 이미지와 Xcode 핀을 표준화하기 가장 쉽습니다. 위 패턴으로 원격 머신을 맞출 계획이라면 Macstripe 홈에서 리전과 모델을 실제로 돌리려는 동시성에 맞춰 비교해 보세요. 본문과 같은 테스트 흐름을 가장 매끄럽게 돌리려면 Mac mini M4가 여전히 현실적인 출발점입니다.
