이미 전용 원격 Mac에서 xcodebuild archive를 안정적으로 돌릴 수 있어도, XCTest + 시뮬레이터는 병렬성·헤드리스 가정·드문 GUI 의존성에서 여전히 발목을 잡습니다. 이 글은 Linux에서 샤딩한 테스트에 익숙하고 macOS에서도 같은 큐잉·격리를 원하는 팀을 위한 것입니다. 테스트 특유의 분산을 드러내는 점검 7가지, 빌드 전용 CI 대비 테스트 러너를 가르는 결정표, 그리고 6단계 인수인계 런북을 러너·재현 가능 빌드·스냅샷과 장기 노드 글과 맞물리게 정리했습니다. 실패가 제품 회귀로 오독되지 않도록 합니다.
원격 Mac은 컴파일 중에는 오래 살아 있는 빌드 서버처럼 느껴지지만, xcodebuild test에 들어가면 CoreSimulator 수명주기, Metal·윈도 서비스, 그리고 많은 컴파일 그래프를 압도하는 메모리 스파이크를 함께 떠안습니다. 아래 7항은 플랫폼 체크리스트입니다. 해당이 많을수록 테스트 페르소나를 컴파일 페르소나에서 분리해야 합니다.
병렬 워커 vs 실제 코어: 측정 없이 -parallel-testing-worker-count를 올리면 시뮬레이터 부팅 폭풍이 I/O와 RAM을 포화시키고, 큐는 건강해 보이는데 개별 테스트만 타임아웃합니다.
UI 테스트와 헤드리스 단위 테스트 혼합: UI 흐름은 윈도 스택과 스크린샷을 치고, 헤드리스 대량 배치와 GPU를 다투면 “로컬은 초록, CI에서는 가끔 빨강”이 됩니다.
기본 DerivedData 충돌: 프로젝트별 캐시 루트 없이 병렬 레포/브랜치를 돌리면 모듈 캐시가 손상되어 빌드는 통과하지만 테스트 해석만 수수께끼처럼 실패합니다.
비대화형 세션의 냉 CoreSimulator: 데스크톱과 같은 로그인 가정을 두지 못한 SSH에서는 첫 번들 대량 기동이 연쇄 실패하며 flaky로 위장합니다.
xcode-select와 xcrun 드리프트: 여러 Xcode와 사용자(러너 vs 개발자)가 섞이면 “simctl은 있는데 xcodebuild는 다른 SDK”가 됩니다.
키체인·푸시·네트워크 권한 테스트: TCC 프롬프트나 대화형 키체인 언락이 필요한 케이스는 CI에서 스킵하거나 스텁해야 하며, 그렇지 않으면 병렬 풀 전체가 재시도 스팸에 빠집니다.
아티팩트와 로그 계약 부재: 종료 코드만 있고 xcresult가 없으면 셸에서 수작업 조사를 강제하며, “VPS처럼 인수인계”와는 반대입니다.
근본 원인은 “컴파일이 초록이면 테스트도 안정”이라는 가정입니다. 테스트는 세션 모델, GPU, RAM 스파이크, 캐시 네임스페이스에 더 민감합니다. 원장에 기록한 뒤 다음 표로 전용 노드를 공유할지 빌드 러너와 테스트 러너로 나눌지 결정합니다.
운영 관점에서 XCTest 병렬은 Linux의 pytest -n auto와 같지 않습니다. 시뮬레이터는 값싼 프로세스 풀이 아니라 이미지·디바이스 상태·시스템 서비스를 묶습니다. 리뷰에는 피크 동시성(용량)과 정상 동시성(일일 SLA)을 모두 적고, CPU 수만으로 조달하면 메모리 병목을 가리는 경우가 많습니다.
빠지기 쉬운 또 하나는 테스트 데이터와 외부 의존성입니다. 고정 localhost 포트의 스텁·모크는 병렬에서 충돌하므로 동적 포트나 더 강한 격리가 필요합니다. 러너가 컴파일 캐시를 마운트한다면 테스트와 같은 마운트 네임스페이스를 공유하지 말거나, “테스트 정리가 컴파일 워밍을 날린다”는 전제를 받아들여야 합니다.
마지막으로 “flaky”라는 말을 원장 필드로 바꿉니다. 실패 테스트 이름, 병렬도, 디바이스 타입, 첫 번들 vs 안정 상태, 유지보수 창입니다. 필드가 없으면 팀은 무분별 재실행으로 클라우드 Mac 분을 태웁니다. 아래 표는 아키 논쟁을 한 장짜리 승인으로 바꿉니다.
만능 답은 없습니다. 소규모 팀은 기계를 아끼려 병합하고, 성장 팀은 큐를 나눠 컴파일 쪽 핫 캐시를 지키면서 테스트는 제어된 병렬로 다른 메모리 곡선을 태웁니다. 리뷰에 세 가지 SLA를 적습니다: 큐 지연, 실패 설명 가능성, 복구 비용입니다.
| 차원 | 빌드+테스트 공유 전용 노드 | 분리 큐(두 번째 머신 또는 추가 라벨) |
|---|---|---|
| 이점 | 동일 툴체인·서명 맥락; tarball 없이 로컬 아티팩트에서 테스트 | 병렬 폭풍 격리; 컴파일 캐시가 테스트 I/O에 굶지 않음; 테스트 전용 노드에서 스냅샷 운용이 쉬움 |
| 리스크 | RAM/GPU 경합; 큰 UI 배치가 긴급 컴파일 핫픽스를 늦출 수 있음 | 아티팩트 계약과 런타임 정렬 필요; 다중 노드 페르소나 드리프트는 감사 부담 증가 |
| 큐 적합성 | 릴리스 빈도 낮고 컴파일 비중이 크며 테스트 양은 적당 | 커밋 속도 높고 샤드 많으며 테스트 독립 스케일아웃 |
| 러너 라벨 | 워크플로가 충돌 단계를 직렬화하면 단일 라벨로도 가능 | mac-ci-build / mac-ci-test 파티션 권장—러너 글 참고 |
| 복구 전략 | 한 번의 스냅샷이 컴파일과 테스트 모두 커버 | 테스트 노드는 더 자주 복구, 컴파일 노드는 장수명 캐시 유지 |
테스트 레이어에서 “Mac을 VPS처럼 빌린다”는 것은 노트북식 랜덤 빨강이 아니라 예측 가능한 세션·자원 곡선을 산다는 뜻입니다. 병렬도와 SLA를 협상하기 전에 테스트 부하를 독립 페르소나로 다룹니다.
엔터프라이즈 빌드 풀을 운영한다면 쿼터 문서에서 테스트 동시성을 상한하고, 서명 아티팩트를 강화 파티션에 두어 테스트 잡이 릴리스 키체인에 닿지 않게 합니다.
분리 큐를 선택하면 아티팩트 전송 계약을 갱신합니다. 바이너리와 dSYM은 체크섬이 있는 객체 스토리지로 흐르거나 단일 호스트 디스크에 머뭅니다. 네트워크를 탄다면 TLS·검증·재시도를 워크플로에 박아 두지 않으면 일시적 지터가 “테스트 불안정”처럼 보입니다. 중견 팀은 두 번째 박스 구매 전에 라벨 분할 + 충돌 단계 직렬화로 시작하고, 간섭이 지표로 입증될 때만 완전 분리합니다.
스냅샷과 장기 노드 글과 짝을 이룹니다. 테스트 러너는 시뮬레이터 상태가 더 빨리 드리프트하므로 복구가 더 잦습니다. 테스트 쪽 복구 루프를 짧게 가져가면 컴파일 캐시 수명을 희생하지 않고 분산을 줄입니다.
순서가 중요합니다. 먼저 프로파일, 다음 병렬화, 마지막 최적화입니다. 지문 스크립트를 재현 가능 빌드 글에 맞춰 테스트가 둘째의 문서 밖 환경을 끌어오지 않게 합니다.
Xcode와 명령 접두사 고정: CI 사용자로 xcode-select -p와 xcodebuild -version을 원장에 기록하고, 테스트 잡 내부의 임시 경로 전환을 금지합니다.
테스트 전용 DerivedData 루트: -derivedDataPath를 컴파일 잡과 분리된 레포/브랜치 버킷으로 넘겨 캐시 밟기를 막습니다.
병렬도를 의도적으로 선택: 보수적 워커 수로 시작해 RAM과 simctl 안정성을 본 뒤 단계적으로 올립니다. UI와 단위는 워크플로나 스테이지로 나눕니다.
필요 시 시뮬레이터 워밍업: 한가할 때 동일 비대화형 세션에서 부팅/종료 카나리를 돌리고, 첫 번들 실패율을 헬스 지표로 추적합니다.
관측 가능한 아티팩트 강제: -resultBundlePath 등을 켜고, 실패 시 잘린 콘솔과 xcresult 포인터를 반드시 남깁니다.
복구 케이던스에 맞추기: 대형 업그레이드나 이미지 롤백 후에는 전체 병렬로 돌아가기 전에 같은 카나리 스위트를 재실행합니다. 스냅샷과 장기 노드의 유지보수 창 흐름과 짝을 이룹니다.
#!/usr/bin/env bash set -euo pipefail xcode-select -p xcodebuild -version xcrun simctl list devices available | head -n 40 sysctl hw.memsize hw.ncpu
참고: 같은 호스트에서 Fastlane 릴리스도 돌린다면 GPU나 키체인을 다투는 릴리스 시간대 밖으로 테스트 잡을 빼고, 유지보수 창이나 강한 라벨로 격리합니다.
GitHub Actions 등에서는 “testing”을 최소 두 잡으로 쪼갭니다. 빠른 게이트(낮은 병렬·크리티컬 패스)와 야간 전체 매트릭스(더 높은 병렬)입니다. 전용 원격 Mac은 주간 큐가 줄고 게이트 실패로 환경 대 코드를 더 빨리 가릅니다. timeout-minutes와 재시도 정책을 문서화해 나쁜 커밋이 큐를 막지 못하게 합니다.
Test Plan이나 태그 타깃을 쓴다면 Xcode에서 마지막으로 클릭된 상태가 아니라 CI의 CLI 진입점을 고정합니다. 그렇지 않으면 “로컬은 모두 초록”과 “CI는 부분집합”이 영원히 갈라집니다. 진입 명령을 Dockerfile처럼 리뷰 가능한 인프라로 취급합니다.
Apple 계열에서 “헤드리스”가 그래픽 스택 제로를 뜻하는 경우는 드뭅니다. 많은 팀이 맨 SSH에서 모든 UI 테스트를 돌리기보다 불필요 UI를 끈 고정 로그인 세션을 둡니다. 스위트를 분류합니다: 순수 로직 단위, 시뮬레이터가 필요하지만 비윈도 흐름, 진짜 UI 드라이버. 마지막 묶음은 야간이나 전용 라벨에 둡니다.
디버깅에서는 먼저 같은 디바이스 타입을 재현 가능하게 부팅할 수 있음을 증명합니다. 부팅 시점 실패는 서비스·디스크·권한, 부팅 후 무작위 크래시는 RAM 스파이크나 병렬도 쪽이 흔합니다. SSH 대 VNC를 교차 확인하고, VNC는 대화형 트리아지의 좁은 창으로만 쓰며 CI의 상시 의존으로 두지 않습니다.
경고: “첫 실행 허용 대화상자”류 테스트를 스텁이나 골든 이미지에 문서화된 일회 허가 없이 병렬 CI에 넣지 마세요. 복구 때마다 대량 실패가 반복됩니다.
Metal·카메라 부하가 큰 스위트에 자원 등급 라벨을 붙이고 맞는 전용 노드를 예약합니다. 큐 지연을 정의한다면 무거운 UI와 큰 헤드리스 배치를 함께 스케줄하지 않습니다. 제품이 고해상 스크린샷이나 영상을 꼭 요구하면 저빈도 파이프라인으로 옮깁니다.
재현 가능 빌드 키체인 정책에 맞춥니다. 테스트 사용자와 릴리스 사용자가 다르면 시뮬레이터 전용 실행에도 최소 서명 재료에 닿는지 검증하고, 사용자를 공유하면 디렉터리와 키체인 파티션을 조여 한 테스트 실패가 릴리스 자산을 오염시키지 않게 합니다.
임계값은 병렬도와 스위트 조합에 맞게 조정하세요. 여기는 정렬용 앵커이지 벤더 보장이 아닙니다.
jetsam이나 Terminated (exit code: 137)가 잦으면 맹목 재시도 전에 병렬도를 내립니다.노트북은 절전·업데이트·무작위 데스크톱 부하로 테스트를 깨뜨리고, Linux는 Apple 공식 시뮬레이터 스택을 호스트할 수 없습니다. 테스트를 전용·상시 가동·프로파일된 원격 Mac으로 옮기면 병렬과 헤드리스 전략이 “누가 화면 잠금을 풀었는지”가 아니라 계약이 됩니다. 임시 하드웨어나 시끄러운 공유 러너에 비해 NodeMini Mac Mini 클라우드 대여는 고정 SSH, 명확한 디스크 등급, 반복 가능한 페르소나로 XCTest를 플랫폼 엔지니어링에 맞춥니다. 사양은 Mac Mini 대여 가격에서 비교하고 온보딩은 헬프 센터로 마무리합니다.
내부 “CI 단계”로 이 런북을 운영에 옮깁니다: L1 컴파일만, L2 게이트 단위, L3 전체 시뮬레이터 스위트, L4 야간 UI만. 각 승격에는 모니터링 게이트가 필요하며 제품에서 던지는 임시 범위가 아니라 재무와 엔지니어링이 같은 큐·비용 스토리를 읽게 합니다.
필수는 아닙니다. 아티팩트 이동을 없애고 동일 서명 맥락을 원하면 공존하고, 컴파일 캐시가 테스트 I/O와 싸우면 안 될 때는 라벨이나 호스트를 나눕니다. 분리 후에는 Xcode 버전과 프로필 출처를 맞춰 거짓 “빌드 초록·테스트 빨강” 신호를 피합니다.
1) xcodebuild 콘솔 꼬리와 xcresult, 2) CoreSimulator 오류 주변 통합 로그, 3) 디스크·메모리 압박 순입니다. 에스컬레이션 때는 조각을 묶어 헬프 센터로 티켓을 엽니다.
가장 무거운 테스트 워크플로를 카나리 호스트에서 돌려 RAM·I/O 피크를 잡은 뒤 Mac Mini 대여 가격의 단계에 매핑합니다. 컴파일에 충분한 CPU 등급이 병렬 시뮬레이터에도 충분하다고 가정하지 마세요.