Xcode 27 빌드 머신에 시뮬레이터를 설치해야 하나요? Release Archive와 서명, 업로드만 담당한다면 먼저 설치하지 않아도 됩니다. 실제 시뮬레이터 실행, UI 테스트, SwiftUI Preview, 여러 iOS 버전 검증을 수행하는 경우에는 해당 Simulator Runtime을 별도로 준비해야 합니다.
이 글은 원격 맥에서 배포 작업을 줄이려는 독립 개발자, Storyboard와 XIB를 사용하는 UIKit 프로젝트 유지보수자, 시뮬레이터 테스트를 맡은 소규모 팀을 위한 실행 기준입니다. 프로젝트가 iOS를 지원한다는 이유만으로 모든 런타임을 내려받는 방식은 피해야 합니다.
마지막 업데이트: 2026년 9월 5일. Xcode 27 Beta 4와 Interface Builder 관련 동작은 Apple의 Xcode 시스템 요구 사항 및 Xcode 27 릴리스 노트로 다시 확인해야 합니다.
먼저 구분할 네 가지 구성 요소
Xcode 본체, 플랫폼 SDK, Simulator Runtime, 시뮬레이터 기기는 서로 다른 구성 요소입니다. Xcode와 iOS SDK가 있다고 해서 iOS Simulator Runtime이나 가상 기기가 자동으로 같은 역할을 하는 것은 아닙니다.
| 작업 | Simulator Runtime 필요 여부 | 발행 머신에 둘지 |
|---|---|---|
| 소스 컴파일과 Release Archive | 보통 필요하지 않음 | 유지 |
| 코드 서명과 TestFlight 업로드 | 보통 필요하지 않음 | 유지 |
| Storyboard와 XIB 컴파일 | Xcode 27 기본 모드에서는 보통 필요하지 않음 | 프로젝트 설정 확인 |
| 시뮬레이터 대상 단위 테스트 | 필요 | 테스트 머신에 설치 |
| XCTest UI 테스트 | 필요 | 테스트 머신에 설치 |
| SwiftUI Preview와 여러 버전 회귀 테스트 | 필요 | 별도 테스트 환경 권장 |
첫 단계: 발행 머신의 실제 작업을 목록화합니다
설치 여부를 정하기 전에 Scheme, Test Plan, 셸 스크립트와 CI 명령을 확인합니다. 특히 다음 호출이 있는지 찾습니다.
xcodebuild test가 시뮬레이터 목적지를 지정하는지 확인합니다.-destination값에 시뮬레이터 플랫폼과 기기 이름이 들어가는지 확인합니다.simctl을 호출하는 스크립트가 있는지 확인합니다.build-for-testing뒤에test-without-building이 이어지는지 확인합니다.- Preview 생성이나 화면 캡처를 발행 단계에 섞었는지 확인합니다.
xcodebuild의 명령과 옵션은 [Apple의 명령줄 도구 참고 문서](https://developer.apple.com/documentation/xcode/xcode-command-line-tool-reference?changes=la)에서 확인할 수 있습니다. 명령이 성공했다는 한 줄만으로는 테스트가 끝났다고 볼 수 없습니다. 실제 목적지, 테스트 결과, 아카이브 산출물을 함께 남겨야 합니다.
두 번째 단계: UIKit 프로젝트의 컴파일 모드를 확인합니다
Storyboard 또는 XIB를 사용하는 프로젝트는 프로젝트 설정과 빌드 스크립트에서 IBC_COCOATOUCH_COMPILER_MODE를 확인합니다. Xcode 27의 기본 Interface Builder toolchain 모드를 사용한다면, 실제 화면 리소스가 포함된 Archive를 만들어 컴파일 결과를 검증합니다.
이때 빈 프로젝트나 화면 리소스가 없는 예제만 빌드하면 안 됩니다. 실제 앱의 Storyboard, XIB, 이미지 연결, 사용자 정의 클래스가 포함된 동일 커밋을 사용해야 합니다. Apple의 Build Settings Reference에서 설정 이름과 적용 범위를 확인한 뒤 다음을 점검합니다.
- 프로젝트가 simulator 방식으로 컴파일하도록 값을 덮어쓰지 않는지 확인합니다.
- CI 환경 변수에 로컬 개발자의 설정이 남아 있지 않은지 확인합니다.
- 실제 화면 리소스를 포함한 Release Archive를 생성합니다.
xcarchive내부에 예상한 앱과 리소스가 들어갔는지 확인합니다.- 서명과 업로드 전 검증을 별도로 실행합니다.
주의: Xcode 27 베타에서 동작하는 기본 모드와 최종 버전의 동작을 같은 것으로 단정하지 마세요. 베타, 후보 버전, 정식 버전이 바뀔 때마다 최소 Archive를 다시 실행해야 합니다.
세 번째 단계: 테스트 담당자는 목적지별로 나눕니다
테스트 작업은 “컴파일할 수 있는가”와 “시뮬레이터에서 통과했는가”를 분리해야 합니다. macOS에서만 실행되는 테스트와 iOS Simulator에서 실행되는 테스트는 의존성이 다릅니다.
| 테스트 유형 | 런타임 의존성 | 남겨야 할 증거 | 권장 환경 |
|---|---|---|---|
| macOS 대상 단위 테스트 | macOS 테스트 환경 | 테스트 결과 파일 | 발행 머신 또는 별도 테스트 머신 |
| iOS Simulator 단위 테스트 | 일치하는 iOS Simulator Runtime | xcresult | 테스트 머신 |
| XCTest UI 테스트 | 일치하는 런타임과 가상 기기 | 화면 및 테스트 결과 | 테스트 머신 |
build-for-testing | 설정에 따라 다름 | 테스트 번들 | 테스트 머신에서 후속 단계 확인 |
test-without-building | 실행 목적지에 맞는 런타임 | xcresult | 테스트 머신 |
| SwiftUI Preview와 회귀 확인 | 실행 가능한 시뮬레이터 환경 | 재현 기록 | 개발 또는 테스트 머신 |
네 번째 단계: 세 가지 운영 방식 중 하나를 고릅니다
저빈도 개발자는 필요할 때 테스트 런타임을 추가할 수 있습니다. 매일 같은 앱을 배포하는 팀은 발행 머신을 가볍게 유지하고, 테스트용 원격 맥을 별도로 두는 편이 복구와 변경 관리에 유리합니다. 반대로 시뮬레이터 테스트가 파이프라인의 중심이면 하나의 머신에서 모든 작업을 처리하려 하지 않는 편이 낫습니다.
| 운영 방식 | 적합한 팀 | 장점 | 주의할 점 | 평가 |
|---|---|---|---|---|
| 정리된 발행 머신 | Archive와 업로드 중심 | 구성 변경이 적고 복구 기준이 명확함 | UI 테스트를 실행할 수 없음 | 발행 안정성 5점 |
| 발행 및 테스트 분리 | 작은 팀과 지속 배포 팀 | 런타임 변경이 배포에 덜 영향을 줌 | 두 환경의 설정을 기록해야 함 | 균형 5점 |
| 한 대에 모두 설치 | 테스트 빈도가 높고 운영 인력이 적은 팀 | 환경 이동이 적음 | 런타임 변경과 디스크 관리가 발행에 영향을 줌 | 단순성 3점 |
다섯 번째 단계: 냉시작 상태에서 최종 검수합니다
다음 체크리스트를 통과한 뒤에만 “시뮬레이터 없는 발행 머신”을 운영 환경으로 올립니다.
- [ ] 실제 앱 커밋으로 Release Archive를 생성합니다.
- [ ] Storyboard 또는 XIB가 포함된 화면 리소스 컴파일을 확인합니다.
- [ ]
xcodebuild명령에 시뮬레이터 목적지가 숨어 있지 않은지 확인합니다. - [ ]
simctl을 호출하는 사전 및 사후 스크립트를 확인합니다. - [ ] 서명 결과와 프로비저닝 프로파일 적용 상태를 확인합니다.
- [ ] Archive 내부 앱과 리소스의 무결성을 확인합니다.
- [ ] 업로드 전 검증을 실행하고 결과를 보관합니다.
- [ ] 테스트 머신에서는 일치하는 Runtime으로 UI 테스트와 단위 테스트를 실행합니다.
- [ ]
xcresult를 보관하고 실패 시 Runtime을 복구하는 절차를 문서화합니다. - [ ] Xcode 베타가 갱신되면 최소 Archive와 대표 테스트를 다시 실행합니다.
원격 맥을 선택할 때 확인할 조건
이미 로컬 맥을 보유했지만 발행 서버가 필요한 경우에는 테스트 작업과 발행 작업을 나눠 필요한 기간만 원격 맥을 준비하는 방법이 있습니다. 반대로 시뮬레이터와 UI 테스트가 매일 필요하다면 런타임을 계속 유지할 수 있는 테스트 환경을 먼저 선택해야 합니다.
MACGPU의 원격 맥 구성 확인 페이지에서 접근 방식과 작업 조건을 확인한 뒤, 실제 프로젝트로 짧은 검증 기간을 잡는 방식이 안전합니다. 서울 위치가 필요한 경우에는 서울 원격 맥 옵션도 비교할 수 있습니다. 중요한 기준은 빈 프로젝트의 성공 여부가 아니라, 당신의 Archive, 서명, 업로드 전 검증, 테스트 목적지가 같은 환경에서 재현되는지입니다.
현재 환경이 개인 컴퓨터 한 대라면 시뮬레이터 런타임을 무조건 설치하는 방식은 저장 공간과 업데이트 관리 부담을 키울 수 있습니다. 반대로 Windows나 Linux 서버를 계속 발행 머신으로 사용하면 Xcode, 코드 서명, App Store 업로드를 직접 처리할 수 없고, 별도 맥 환경을 붙이는 운영 복잡성도 남습니다. 장기간 고정된 고부하 작업이나 물리 기기 연결이 필요한 경우에는 직접 맥을 마련하는 편이 맞지만, 짧은 검증이나 임시 배포 파이프라인이라면 MACGPU의 원격 맥을 먼저 빌려 실제 프로젝트로 확인하는 편이 비용과 구성 위험을 함께 줄이기 쉽습니다.
자주 확인하는 질문
Xcode 27에서 시뮬레이터 없이 아카이브를 만들 수 있나요?
순수한 Release Archive, 코드 서명, 배포용 검증만 수행한다면 iOS Simulator Runtime 없이 진행할 수 있습니다. 다만 프로젝트 스크립트가 simctl이나 시뮬레이터 전용 목적지를 호출하지 않아야 합니다. 같은 커밋으로 깨끗한 아카이브를 만들고, 서명 결과와 업로드 전 검증까지 확인해야 성공으로 판단할 수 있습니다.
Storyboard 프로젝트는 시뮬레이터 런타임이 없어도 컴파일되나요?
Xcode 27 베타 릴리스 노트에 따르면 UIKit 문서는 기본 Interface Builder toolchain 방식으로 컴파일할 수 있으므로, Storyboard나 XIB가 있다는 이유만으로 런타임을 설치할 필요는 없습니다. 프로젝트가 예전 simulator 방식으로 고정되어 있거나 설정을 덮어쓰는 스크립트가 있다면 해당 런타임을 명시적으로 준비해야 합니다.
원격 iOS 빌드 머신에는 어떤 Xcode 구성 요소가 필요한가요?
Xcode 본체와 프로젝트가 요구하는 플랫폼 SDK가 기본입니다. 여기에 코드 서명에 필요한 키체인과 프로파일, 배포 도구를 준비합니다. iOS Simulator Runtime은 실제 시뮬레이터 실행, UI 테스트, 시뮬레이터 대상 단위 테스트, 여러 시스템 버전 검증을 수행할 때만 작업 목록에 맞춰 추가하는 편이 안전합니다.
TestFlight에 올리기만 한다면 시뮬레이터를 지워도 되나요?
TestFlight 업로드만 담당하는 머신이라면 시뮬레이터 런타임을 제거하는 구성이 가능합니다. 하지만 업로드 전에 실행하는 테스트 단계가 시뮬레이터 목적지를 사용하거나, 빌드 스크립트가 simctl을 호출하면 예외입니다. 배포용 머신과 테스트용 머신의 작업 목록을 먼저 분리하고, 실제 파이프라인을 냉시작 상태에서 확인해야 합니다.
xcodebuild에서 시뮬레이터가 꼭 필요한 작업은 무엇인가요?
일반 아카이브는 시뮬레이터 없이 수행할 수 있지만, 시뮬레이터 목적지로 실행하는 테스트, UI 테스트, 시뮬레이터에서 동작하는 build-for-testing과 test-without-building은 일치하는 런타임이 필요합니다. macOS 대상 테스트는 별도 판단이 필요합니다. 결과는 명령 성공 여부가 아니라 xcresult와 테스트 대상 기록으로 확인해야 합니다.
Xcode 27 빌드 머신은 “모든 구성 요소를 설치한 한 대”보다 “발행에 필요한 구성만 둔 머신과 테스트 머신”으로 나눌 때 관리 기준이 선명해집니다. 먼저 실제 작업 목록으로 Simulator Runtime 의존성을 확인하고, 짧은 기간의 원격 맥 검증에서 Archive와 테스트를 모두 재현한 뒤 필요한 환경만 유지하세요.