iOS 27 CI에서는 모든 노드에서 Simulator를 삭제하지 말고, Xcode 27의 새 빌드 방식을 쓸 수 있는 가벼운 빌드 노드와 완전한 테스트 노드를 나누는 편이 안전합니다. UIKit 화면 문서의 일부는 Simulator 없이 컴파일할 수 있지만, 앱 실행과 UI 테스트에는 여전히 Simulator 또는 실제 기기가 필요합니다.
이 글은 코드 검사와 빌드 산출물 생성만 담당하는 빌드 엔지니어, XCTest와 UI 자동화를 운영하는 테스트 팀, 원격 맥 노드 풀과 복구 정책을 관리하는 DevOps 및 연구 개발 플랫폼 담당자를 위한 판단 기준입니다.
[ SECTION_01 ] 먼저 나눠야 할 것은 SDK, 런타임, 실행 기기입니다
iOS 27 CI Simulator 문제에서 가장 흔한 오류는 SDK, Simulator runtime, 가상 기기, Interface Builder 컴파일 방식을 하나의 설치 항목처럼 다루는 것입니다.
- SDK: 소스 코드를 컴파일할 때 필요한 개발 키트입니다.
- Simulator runtime: 앱을 실행할 iOS 환경입니다.
- 가상 기기: 특정 기기 설정으로 만든 실행 대상입니다.
- Interface Builder 문서: Storyboard와 XIB 같은 화면 리소스입니다.
- toolchain 방식: UIKit Interface Builder 문서를 컴파일하는 새로운 방식입니다.
- 테스트 destination: 테스트를 실제로 실행할 대상입니다.
Apple은 Xcode 27 Beta 6 발표 자료에서 Apple Silicon 맥에서 Xcode 27을 실행할 수 있으며, UIKit Interface Builder 문서가 기본적으로 Simulator 다운로드 없이 toolchain 방식으로 컴파일될 수 있다고 밝혔습니다. 다만 Xcode 27과 iOS 27은 2026년 9월 8일 기준으로 베타 자료에 해당합니다. 최종 출시판의 동작까지 확정된 것으로 확대해서는 안 됩니다. Xcode 27 발표 자료의 확인 내용을 기준으로 판단해야 합니다.
Xcode 27로 iOS 프로젝트를 빌드할 때 Simulator를 내려받지 않아도 되는 경우가 있습니까?
있습니다. 순수 컴파일과 일부 UIKit 화면 문서 컴파일만 수행하는 작업이라면 가능합니다. 그러나 애플리케이션 프로세스를 시작하거나 iOS 시스템 동작을 검증하는 순간에는 Simulator runtime 또는 실제 기기가 다시 필요합니다.
따라서 “빌드 성공”만으로 Simulator 제거를 결정하면 안 됩니다. 로그에 Simulator destination 요청이 있었는지, 테스트가 실제로 앱을 실행했는지, 산출물이 기존 노드와 같은지까지 확인해야 합니다.
[ SECTION_02 ] 빌드 담당자는 새 컴파일 방식을 범위 안에서 검증합니다
Storyboard와 XIB를 사용하는 프로젝트는 새 방식의 영향을 받을 수 있습니다. 기본 설정이 적용되는 UIKit Interface Builder 문서와, 오래된 프로젝트 설정 또는 직접 ibtool을 호출하는 빌드 단계를 구분해야 합니다.
Apple의 빌드 설정 참고 자료와 대상 빌드 설정 문서에서 IBC_COCOATOUCH_COMPILER_MODE의 정의와 적용 위치를 확인합니다. 프로젝트가 명시적으로 simulator 방식을 지정했는지도 함께 살펴봐야 합니다.
검증은 다음 순서로 진행합니다.
- 기존 CI 노드에서 같은 커밋을 체크아웃합니다.
- 후보 원격 맥 노드에 같은 Xcode 27 베타와 SDK를 준비합니다.
- 순수 빌드 명령을 실행하고 로그에서 Simulator destination 요청을 찾습니다.
- Storyboard와 XIB가 포함된 산출물, 경고, 리소스 오류를 비교합니다.
build-for-testing을 실행해 테스트 산출물 생성 여부를 확인합니다.- 기존 테스트 노드에서
test-without-building으로 해당 산출물을 실행합니다. - 실패하면 simulator 방식으로 돌아갈 설정과 적용 대상을 기록합니다.
명령 자체의 동작은 Xcode 명령줄 도구 참고 자료와 Build For Testing 및 Test Without Building 안내에서 대조할 수 있습니다.
새 방식으로 빌드가 끝났더라도 다음 항목이 다르면 이전이 완료된 것이 아닙니다.
- 생성된 Storyboard 또는 XIB 산출물의 차이
- 리소스 이름과 연결 오류
- 사용자 정의 빌드 설정의 재정의
- 직접 호출하는
ibtool단계 - 아카이브 또는 업로드 단계에서의 추가 처리
[ SECTION_03 ] 테스트 팀은 테스트 호스트와 실행 대상을 기준으로 나눕니다
모든 Unit Tests를 같은 작업으로 취급하면 노드 분리가 잘못됩니다. 순수 Swift 로직 테스트는 앱 프로세스나 iOS 시스템 동작에 의존하지 않을 수 있습니다. 반면 애플리케이션 호스트 테스트는 앱 실행이 필요할 수 있고, 플랫폼 프레임워크 동작을 확인하는 통합 테스트는 Simulator 또는 실제 기기 검증이 필요할 수 있습니다.
어떤 iOS CI 작업에 Simulator runtime이 필요합니까?
앱을 실행하거나 iOS 플랫폼 동작을 관찰하거나 화면 입력을 재현하는 작업입니다. 테스트 대상의 destination, Test Host, SDK, 생성된 테스트 산출물을 확인하면 가벼운 노드로 옮길 수 있는 테스트와 남겨야 하는 테스트를 구분할 수 있습니다.
테스트 담당자는 다음 정보를 테스트 목표별로 저장해야 합니다.
- 테스트 대상의 destination
- Test Host 설정 여부
- 사용한 SDK와 Xcode 버전
- 테스트 번들 및 결과 패키지
- 앱 프로세스 시작 여부
- Simulator runtime 호출 여부
- 실패 시 화면 기록과 로그
테스트 실행 및 결과 해석 문서는 결과 패키지와 테스트 실행 흐름을 확인할 때 기준이 됩니다. Test Plan을 사용한다면 테스트 피드백을 개선하는 구성 방법도 함께 확인해야 합니다.
UI 테스트는 별도 판단이 필요합니다. XCTest UI Tests는 대상 앱을 실행하고 사용자 인터페이스를 조작합니다. 따라서 toolchain 컴파일 방식이 Simulator 실행 환경을 대신하지 않습니다. UI 테스트 노드에는 실행 대상, 필요한 runtime, 초기화된 가상 기기, 실패 기록을 남길 저장 공간이 필요합니다.
병렬 테스트를 운영하는 경우에는 가상 기기 복제, 노드 자원 경쟁, 재시작 후 상태 복구를 따로 측정해야 합니다. 공식 자료나 실제 내부 기록이 없는 상태에서 병렬 실행 수나 필요한 자원량을 숫자로 단정해서는 안 됩니다.
[ SECTION_04 ] 플랫폼 팀은 원격 맥을 두 종류의 노드로 분리합니다
원격 맥 구성은 한 개의 큰 노드 풀보다 업무 경계를 먼저 정하는 편이 관리하기 쉽습니다. Apple의 실행 대상 안내는 앱을 Simulator 또는 실제 기기에서 실행하는 흐름을 설명합니다. 이 차이를 CI 라우팅 조건으로 옮기면 됩니다.
가벼운 빌드 노드
다음 작업을 우선 배치합니다.
- 정적 검사
- Swift 또는 Objective-C 컴파일
- Interface Builder 문서 컴파일
- 아카이브 전 사전 빌드
- 테스트 산출물 생성
- 실행 환경이 필요 없는 코드 생성
이 노드는 Simulator runtime을 기본 구성으로 넣지 않는 선택이 가능합니다. 다만 프로젝트가 실제로 toolchain 방식을 사용하고, 직접 호출하는 빌드 스크립트가 simulator 방식을 요구하지 않는다는 증거가 있어야 합니다.
완전한 테스트 노드
다음 작업은 완전한 테스트 노드에 남깁니다.
- 앱 호스트 테스트
- XCTest UI Tests
- iOS 시스템 동작을 확인하는 통합 테스트
- 여러 OS 버전 또는 기기 조건을 이용한 호환성 검증
- 실제 실행 결과가 필요한 배포 전 검증
배포 담당자는 아카이브 생성 성공과 테스트 통과를 같은 결과로 취급하지 않아야 합니다. App Store Connect 업로드 절차는 빌드 업로드 안내에 설명되어 있지만, 업로드 가능한 산출물이 테스트 실행까지 통과했다는 뜻은 아닙니다.
[ SECTION_05 ] 실제 프로젝트로 이중 실행을 진행합니다
운영 노드를 바로 줄이는 대신, 복구 가능한 후보 원격 맥에서 같은 커밋을 양쪽 경로로 실행합니다. 대상 프로젝트에는 Storyboard 또는 XIB, 앱 호스트 테스트, UI 테스트를 포함해야 합니다. 그래야 새 컴파일 방식이 놓치는 경계를 확인할 수 있습니다.
검증 절차는 다음과 같습니다.
- 기존 노드의 Xcode, SDK, 빌드 설정과 대상 커밋을 기록합니다.
- 후보 노드에서 순수 빌드와
build-for-testing을 실행합니다. - 빌드 로그에서 Simulator destination과 runtime 호출을 확인합니다.
- 테스트 노드에서
test-without-building을 실행합니다. - UI 테스트의 실제 앱 실행, 결과 패키지, 실패 미디어를 확인합니다.
- 노드를 재시작한 뒤 캐시와 가상 기기 상태가 복구되는지 확인합니다.
- 실패 시 기존 노드로 돌아가는 라우팅과 설정 복구 절차를 실행합니다.
이 과정은 Xcode 27 원격 빌드 노드 구성과 호환성 검증 안내처럼 빌드 환경 자체를 고정하는 작업과 함께 진행하는 편이 좋습니다. CI Runner를 따로 운영한다면 원격 맥에 Runner를 배치하는 방식도 별도 검토해야 합니다.
[ SECTION_06 ] 노드 구성은 세 가지 선택지로 평가합니다
아래 점수는 공식 성능 측정값이 아닙니다. 프로젝트 요구 조건에 따른 편집 판단 점수입니다. 5점에 가까울수록 해당 구성이 그 조건에 잘 맞는다는 뜻입니다.
| 구성 | 적합한 작업 | Simulator 정책 | 운영 판단 | 적합도 |
|---|---|---|---|---|
| 단일 완전 노드 | 빌드와 실행 테스트가 강하게 결합된 프로젝트 | 모든 작업에서 유지 | 설정은 단순하지만 불필요한 runtime 의존이 남음 | 3/5 |
| 이중 노드 | 순수 빌드와 UI 테스트를 분리할 수 있는 프로젝트 | 빌드 노드는 조건부 제외, 테스트 노드는 유지 | 라우팅과 산출물 검증이 필요함 | 5/5 |
| 이전 보류 | 오래된 설정, 직접 호출 스크립트, 베타 불확실성이 큰 프로젝트 | 기존 노드 유지 | 변경 위험은 낮지만 비용 절감 판단을 미룸 | 4/5 |
원격 맥 빌드 노드와 테스트 노드는 어떻게 나누는 것이 좋습니까?
빌드 산출물을 생성하는 단계와 앱을 실행하는 단계를 분리합니다. build-for-testing 산출물이 테스트 노드에서 동일한 SDK와 도구 체인으로 실행되는 경우에는 이중 노드가 적합합니다. 반대로 빌드 스크립트가 특정 가상 기기나 Simulator runtime을 직접 요구한다면 단일 완전 노드를 유지하거나 해당 단계만 테스트 풀로 보내야 합니다.
비용과 운영 조건까지 비교할 때는 맥 미니 렌탈 가격 기준을 참고할 수 있습니다. 다만 렌탈 비용만 보고 노드를 줄이면 안 됩니다. 저장 공간, 초기화 시간, 장애 복구, Xcode 캐시 재구성까지 포함해 실제 운영 주기를 계산해야 합니다.
| 확인 항목 | 가벼운 빌드 노드 | 완전한 테스트 노드 |
|---|---|---|
| SDK와 Xcode 일치 | 반드시 확인 | 반드시 확인 |
| Simulator runtime | 프로젝트 검증 후 생략 가능 | 실행 테스트에 맞춰 유지 |
| Interface Builder 문서 | toolchain 방식과 산출물 확인 | 동일 산출물 재사용 |
build-for-testing |
실행 | 산출물 수신 |
test-without-building |
보통 실행하지 않음 | 실행 |
| UI 테스트 | 배치하지 않음 | 배치 |
| 복구 검증 | 빌드 재시작과 캐시 확인 | 가상 기기와 테스트 상태 확인 |
| 변경 승인 조건 | Simulator 호출 없음, 산출물 일치 | 테스트 결과와 실패 기록 일치 |
[ SECTION_07 ] 결론은 베타 자료와 이중 실행으로 확정합니다
2026년 9월 8일 기준으로 Xcode 27 Beta 6은 일부 UIKit Interface Builder 문서를 Simulator 없이 컴파일할 수 있는 경로를 제공합니다. 하지만 이것은 Simulator가 CI 전체에서 불필요하다는 의미가 아닙니다. 순수 빌드와 실행 테스트를 분리할 수 있을 때만 빌드 노드부터 가볍게 만들 수 있습니다.
현재 구성이 모든 작업을 한 노드에서 처리한다면 즉시 runtime을 삭제하지 않는 편이 안전합니다. 먼저 되돌릴 수 있는 원격 맥에서 실제 프로젝트를 이중 실행하고, 빌드 로그와 테스트 결과를 비교해야 합니다. 이후 순수 빌드가 반복해서 통과하고 Simulator를 암묵적으로 호출하지 않는다는 증거가 쌓이면 빌드 풀을 줄입니다.
반대로 UI 테스트와 앱 호스트 테스트가 많은 팀은 완전한 테스트 노드를 유지해야 합니다. 로컬 맥을 직접 구매하면 장기적으로 고정된 부하에는 유리할 수 있지만, 베타 도구 체인을 시험할 때 장비를 추가로 확보해야 하고 장애 시 대체 노드와 복구 절차도 직접 운영해야 합니다. 기존 원격 서버나 리눅스 서버는 macOS 전용 도구 체인과 iOS 실행 검증을 대신하지 못합니다.
이런 경우에는 NOVAKVM에서 필요한 기간만 원격 맥을 빌려 후보 빌드 노드와 테스트 노드를 분리해 검증하는 방식이 더 유연합니다. 운영 노드를 바로 바꾸기보다, 실제 커밋과 테스트 계획을 복제할 임시 환경으로 사용하면 정식 전환 전에 Simulator 의존성과 복구 조건을 확인할 수 있습니다.