2026 PR 파이프라인에서 Mac 클라우드로 iOS Simulator 병렬 테스트: 동시성, destination, 디스크와 큐
정적 분석을 Linux로 옮긴 뒤에도 머지 빈도를 막는 것은 macOS Simulator 테스트인 경우가 많다. 사무실 Mac mini 풀에서는 Simulator 경합·DerivedData 팽창·큐 가시성 부족이 먼저 한계로 드러난다. 본 글은 PR 테스트를 인프라로 다루려는 팀을 위해 (1) 오해 세 가지 (2) 온프레 풀과 Mac 클라우드 Runner 비교표 (3) 일곱 단계 (4) 검토용 수치 (5) FAQ (6) 마무리를 제시한다.90초 API·CI 연결 및 빌드 큐와 DerivedData 장문과 역할을 나눈다.
목차
1. 오해 세 가지: Simulator를 가벼운 컨테이너로 본다
많은 팀이 Lint와 가벼운 단위 테스트는 이미 Linux로 보냈다. 남은 벽은 Simulator가 동반되는 게이트다. SSH로 서버를 관리하던 엔지니어일수록 PR 상황에서 아래를 과소평가하기 쉽다.
- 워커를 선형으로 늘릴 수 있다는 착각: 한 호스트에서 병렬 플래그와 destination을 난립시키면 CPU 경합과 디스크 I/O 지터가 겹쳐 꼬리가 길어진다. 성능 코어당 Simulator 상한에 대한 내부 베이스라인이 없으면 SLA는 구호에 그친다.
- 릴리즈용 전 destination을 매 PR에 복사: 전 행렬은 제출 직전에는 의미 있으나 각 커밋에는 과도하다. 차단 목적지와 정보용을 나누지 않으면 피크에 큐 깊이가 선형으로 폭증한다.
- DerivedData와 첨부를 소프트 예산으로 취급: 녹화·실패 스크린샷·트레이스를 기본 ON으로 두면 단일 PR이 수 시간에 수십 GB를 쓴다. 주말 청소만으로는 수요일 오후에 디스크가 먼저 쓰러진다. 빌드 측 수위는 다른 글에서 다루고 여기서는 고빈도 짧은 PR Job에 초점을 맞춘다.
먼저 동시 상한·destination 층·가비지 회수를 매개변수화한 뒤 Xcode 마이너 논쟁으로 넘어가라.
2. 비교표: Mac mini 풀과 Mac 클라우드
첫 아키텍처 리뷰에 그대로 붙일 표다. 요구·사무실 풀·형상이 고정된 Mac 클라우드·비고 순이다.
| 요구 | 사무실 Mac mini | Mac 클라우드 PR Runner | 비고 |
|---|---|---|---|
| 피크 동시성 예측 | 데스크톱 사용·업데이트로 흔들림 | 인스턴스 등급을 고정해 코드화 가능 | 호스티드 vs 셀프호스티드 참고 |
| 디스크 수위 | 공유 볼륨에서 누구도 지우지 않음이 잦음 | Job별 볼륨 또는 강제 prune | Job 끝에 DerivedData 하위 트리 삭제 |
| 큐 가시성 | 구두 조율로 흐름이 끊김 | CI 라벨·API 스케일과 정렬 | 가시성 체크리스트 |
| 네트워크 RTT | LAN은 낮지만 경로가 복잡 | Git·아티팩트 저장소에 가까운 리전 선택 | Linux 전처리와 하이브리드에 적합 |
3. 일곱 단계: 동시성·destination·정리
- 베이스라인 표 작성: 대표 프로파일로 PR 길이 Job을 스무 번 돌려 P95 시간과 RSS 피크로 코어당 Simulator 초기 상한을 얻는다.
- destination을 차단 집합과 확장 집합으로 분할: 차단은 최근 두 세대 iOS와 주요 화면 크기만. 확장은 나틀리 또는 릴리즈 브랜치만.
- 하드 타임아웃과 계층적 재시도: 인프라 실패와 단언 실패를 분리한다. Flaky UI는 동일 커밋 한 번까지만 재실행하고 라벨로 표시한다.
- 정리 훅 필수: 성공·실패 무관하게
xcrun simctl shutdown all와 DerivedData 하위 삭제. 거대 첨부는 업로드 전 절단. - 큐 깊이를 메트릭으로: macOS Executor 대기 분포를 측정해 임계 초과 시 스케일 또는 destination 강등.
- Linux 전처리와 아티팩트 경계: 컴파일 산출과 인덱스만 넘기고 서명된 캐시 히트가 없으면 전체 저장소 캐시는 금지.
- 원페이지 Runbook: 「여유 공간 12% 미만이면 확장 집합 중지」처럼 당직이 암기 없이 실행할 문장으로 쓴다.
4. 수치: CPU·디스크·큐 깊이
아래는 합의용 출발점이며 반드시 자체 트레이스로 교정하라. 첫째, M4급에서 성능 코어 약 10~12개가 보이고 메모리 32GB라면 소비자 앱 차단 집합을 「병렬 워커 3~4·동시 Simulator 4대 이하」에서 시작해 UI 스위트가 CPU 한계인 동안만 단계적으로 올린다. 둘째, 단일 PR Job은 최근 성공 빌드 DerivedData 발자국의 약 1.8~2.4배를 디스크 피크로 잡고 전역 여유 12% 미만이면 차단만 자동 강등한다. 셋째, 사용 가능 Executor 수의 네 배를 30분 연속 초과하는 큐 깊이면 기계 추가보다 확장 집합 중지를 먼저 하지 않으면 Flaky가 용량 문제로 위장한다. 넷째, 녹화·성능 트레이스는 PR에서 기본 OFF로 두고 수동·나틀리만 ON이면 첨부를 GB에서 수백 MB대로 압축하기 쉽다. 다섯째, 기본 브랜치 머지마다 전 행렬 JSON을 24~72시간 보관해 좁은 PR 합격·넓은 행렬 실패 회귀를 설명 가능하게 한다.
5. FAQ
매 PR에 iPad와 마이너 OS 전 조합이 필요한가
아니다. 고트래픽 기기를 차단에 두고 조합 폭발은 나틀리나 릴리즈로 돌린다.
병렬이 무작위로 멈춘다
워커를 절반으로 줄이고 녹화를 끈다. 여러 Job이 동일 대화형 사용자를 공유해 Simulator 락을 쥐고 늘지 않았는지 확인한다.
90초 글과 차이
그 글은 Runner 가동. 이 글은 SSH 이후 Simulator·디스크를 운영 품질로 만드는 이야기다.
6. 안정적인 Mac 실행면으로
소수의 Mac mini는 초기에는 충분하지만 PR 빈도와 병렬 부채가 커지면 수동 디스크 청소와 구두 조율이 단일 장애점이 된다. 꼬리 지연은 설명 불가, 큐는 보이지 않으며 심야 머지는 남은 용량에 의존한다. 노트북 환경은 전원·상행·격리 측면에서 CI에 부적합하다. 측정·강등·탄력을 갖춘 PR 게이트를 만들려면 VPSMAC M4 Mac 클라우드를 PR 전용 풀로 임대하는 편이 과밀 데스크톱과 싸우는 것보다 조용하다. SSH 절차는 그대로, 하드 등급은 고정하고 청소·동시 상한을 같은 Runbook에 둔다. 90초 API·DerivedData 큐·Runner 비교 글과 한 줄로 이어진다.