Apple 공식 요구 사항에서 Xcode 27은 아직 베타로 표시됩니다. Xcode 시스템 요구 사항이 바뀔 수 있는 시점에는 모든 작업을 한 종류의 노드에 맡기지 않는 편이 안전합니다. Kotlin Multiplatform iOS CI는 표준 PR 검증과 일반 시뮬레이터 빌드는 호스팅 macOS Agent로, 생산 서명과 사설망 의존성은 전용 원격 Mac으로 분리하십시오. 피크가 큰 팀이라면 고정된 생산 기준선에 호스팅 탄력 용량을 붙이는 혼합 구성이 기본 선택입니다.
마지막 업데이트: 2026년 8월 27일. Xcode 상태는 제조사 공식 시스템 요구 사항, KMP 흐름은 공식 iOS CI/CD 문서를 기준으로 확인했습니다.
이 글은 Kotlin Multiplatform 프로젝트의 iOS 자동 빌드와 TestFlight 배포를 운영하는 플랫폼 팀을 위한 글입니다. 서명 키, 내부 저장소, 소스 코드 접근 범위를 관리해야 하는 기업 IT 및 보안 담당자에게도 적합합니다. 단순히 Mac 한 대의 가격이 아니라 작업별 격리와 복구 가능성을 비교하려는 기술 결정자가 읽어야 합니다.
SECTION 01먼저 작업을 다섯 가지 시나리오로 나누십시오
Kotlin Multiplatform의 공유 코드 테스트와 iOS 결과물 생성은 같은 작업처럼 보이지만 필요한 실행 환경이 다릅니다.
- 공유 Kotlin 테스트와 정적 검사: macOS가 없어도 처리할 수 있는 작업이 많습니다.
- iOS framework 빌드: Apple 도구 체인을 호출하므로 macOS와 Xcode가 필요합니다.
- 시뮬레이터 검증: 대상 기기와 런타임이 맞아야 하며, 단순 컴파일 성공만으로는 부족합니다.
- 실제 기기용 archive: 인증서, 프로비저닝 프로파일, Keychain 접근이 필요합니다.
- TestFlight 배포: 빌드 성공 외에 App Store Connect 권한과 감사 가능한 자격 증명 흐름이 필요합니다.
Kotlin 공식 문서는 CI에서 iOS 애플리케이션을 빌드하고 서명하며 배포하는 흐름을 설명합니다. 따라서 “Kotlin Multiplatform은 Mac 없이 전부 처리할 수 있다”는 식의 판단은 정확하지 않습니다.
주의: 공유 모듈 테스트가 통과했다는 결과는 Kotlin 코드의 검증 결과일 뿐입니다. iOS framework 링크, 시뮬레이터 실행, archive 생성과 서명까지 통과했다는 뜻은 아닙니다.
SECTION 02PR 검증에서는 어떤 작업을 Mac 밖으로 옮길 수 있습니까?
PR 단계에서는 작업을 두 층으로 나누면 Mac 대기열을 줄일 수 있습니다. 먼저 공통 Kotlin 테스트, 코드 형식 검사, 의존성 확인을 일반 실행 환경에서 처리합니다. 그 다음 변경된 iOS 모듈만 macOS Agent에서 빌드합니다.
Kotlin 문서에 나오는 네이티브 바이너리 대상에는 iosArm64와 iosSimulatorArm64가 구분되어 있습니다. Kotlin 네이티브 바이너리 대상 문서를 기준으로 보면 두 대상은 결과물과 검증 목적이 다릅니다.
iosArm64빌드 성공: 실제 기기용 결과물을 만들 수 있는지 확인합니다.iosSimulatorArm64빌드 성공: Apple Silicon 시뮬레이터용 결과물을 확인합니다.- 공유 테스트 성공: 공통 로직의 테스트 결과를 확인합니다.
- 링크와 실행 성공: Xcode 프로젝트, 프레임워크 연결, 런타임까지 확인합니다.
호스팅 Agent는 이런 표준 PR 작업에 유리합니다. 작업이 끝난 뒤 실행 자원을 반납할 수 있고, 여러 PR을 동시에 검증하기 쉽기 때문입니다. 반면 캐시와 설치 상태가 매번 달라질 수 있으므로 재현성이 중요한 릴리스 작업에는 별도 기준이 필요합니다.
첫 단계: 파이프라인을 결과물 기준으로 분리하십시오
각 작업에 “무엇이 통과하면 다음 단계로 가는가”를 적으십시오. 공유 테스트 통과만으로 배포 승인을 내리지 말고, iOS 대상별 결과물을 별도 상태로 기록해야 합니다.
둘째 단계: Xcode와 Kotlin 조합을 고정하십시오
Xcode 27은 공식 문서에서 베타 상태이므로 생산 배포의 기본값으로 바로 채택하지 않는 편이 안전합니다. 현재 사용 중인 정식 Xcode를 생산 노드에 고정하고, 새 버전은 별도 검증 노드에서 시험하십시오. 호스팅 이미지가 예고 없이 바뀌는 서비스라면 이미지 변경 알림과 재검증 절차도 함께 마련해야 합니다.
SECTION 03시뮬레이터와 원격 Mac 중 어디에 고정해야 합니까?
시뮬레이터 빌드와 실행 검증은 호스팅 Agent로 시작할 수 있습니다. 대상 런타임이 사전에 준비되어 있고, 테스트가 특정 하드웨어나 장시간 캐시에 의존하지 않는 경우입니다.
전용 원격 Mac은 다음 조건에서 더 적합합니다.
- 특정 Xcode 버전을 장기간 유지해야 합니다.
- 시뮬레이터 런타임과 의존성 캐시를 보존해야 합니다.
- 사내 네트워크나 고정된 프록시를 거쳐야 합니다.
- 장애 발생 시 작업 디렉터리와 로그를 직접 확인해야 합니다.
- 릴리스 직전의 동일한 환경을 반복해서 재현해야 합니다.
호스팅과 자체 운영의 판단을 작업 시나리오에 맞추면 다음과 같습니다.
| 작업 시나리오 | 호스팅 macOS Agent | 전용 원격 Mac | 우선 판단 |
|---|---|---|---|
| 공유 Kotlin 테스트 | 적합 | 과도할 수 있음 | Mac 점유를 줄임 |
| PR용 iOS framework 빌드 | 적합 | 기준 환경이 필요할 때 사용 | 변경량에 따라 탄력 배정 |
| 시뮬레이터 검증 | 런타임이 제공되면 적합 | 런타임과 캐시 고정에 유리 | 재현성 우선 |
| 기기용 archive | 가능하지만 자격 증명 경계 확인 필요 | 격리와 감사에 유리 | 생산 기준선은 전용 노드 검토 |
| TestFlight 배포 | 공식 절차로 가능 | 장기 키와 네트워크 통제에 유리 | 서명 노드 분리 |
| 사내 저장소와 내부 패키지 | 네트워크 정책 확인 필요 | 고정 출구와 접근 통제에 유리 | 보안 경계가 우선 |
| 피크 PR 동시 처리 | 확장에 유리 | 유휴 비용과 대기열 발생 가능 | 혼합 운영 |
이 표에서 “전용 원격 Mac”은 자동으로 안전하다는 뜻이 아닙니다. 계정 분리, 작업 공간 삭제, 무인 재시작, 접근 로그, 복구 테스트를 확인해야 합니다. 반대로 호스팅 Agent도 보안 통제가 없는 것이 아닙니다. 호스팅 Runner와 자체 운영 Runner의 공식 구분을 읽고, 저장소 권한과 비밀 값의 전달 방식을 실제로 점검해야 합니다.
SECTION 04TestFlight 서명은 어떻게 격리해야 합니까?
TestFlight 배포에서는 빌드 성공보다 자격 증명이 더 큰 운영 위험이 될 수 있습니다. 일반적인 흐름은 다음과 같습니다.
배포 작업 승인 → App Store Connect API key 또는 인증 정보 주입 → 임시 Keychain 사용 → archive 서명 → 업로드 → 임시 파일과 작업 공간 삭제
배포 노드에는 개발용 인증서와 배포용 인증서를 같은 방식으로 보관하지 마십시오. 배포에 필요한 API key, Distribution certificate, 프로비저닝 프로파일, Keychain 권한을 각각 분리하고, PR 작업에는 배포용 비밀 값을 전달하지 않는 구조가 좋습니다.
빌드 업로드 절차에 관한 공식 문서는 App Store Connect에 빌드를 올리는 과정을 설명합니다. 이 절차를 CI에 넣을 때는 누가 실행했는지, 어떤 커밋이었는지, 어떤 노드에서 서명했는지를 로그로 남겨야 합니다.
셋째 단계: 서명 작업을 승인된 경로로만 제한하십시오
PR에서 실행되는 스크립트가 배포용 비밀 값에 접근하지 못하게 하십시오. 배포 환경은 보호된 브랜치나 수동 승인 뒤에만 열고, 작업 종료 후 임시 Keychain과 인증서 파일을 삭제하십시오.
넷째 단계: 다중 앱 공유 여부를 따로 평가하십시오
여러 앱이 하나의 서명 노드를 공유하면 편리하지만, 키 교체와 사고 조사 범위가 함께 커집니다. 앱별 서비스 계정 또는 앱별 작업 공간을 사용하고, 공용 관리자 권한은 배포 흐름에서 제거하는 편이 낫습니다.
운영 경험상 중요한 지점: 사설망에 접속하려고 호스팅 Agent에 과도한 저장소 권한이나 장기 인증 키를 추가하면, 노드 선택 문제를 자격 증명 문제로 바꾸게 됩니다. 네트워크 경계를 만족하지 못하면 전용 노드나 별도 중계 구조를 검토하십시오.
SECTION 05사설망 의존성이 있으면 무엇을 먼저 확인해야 합니까?
내부 Git 저장소, 사설 패키지 저장소, 기업 프록시, 고정된 외부 IP가 필요하면 다음 항목을 먼저 목록화하십시오.
- 빌드 노드가 접근해야 하는 도메인과 포트를 적습니다.
- 읽기 전용으로 충분한 저장소와 쓰기 권한이 필요한 시스템을 분리합니다.
- 내부 인증서와 프록시 설정의 배포 경로를 정합니다.
- 소스 코드와 빌드 산출물이 저장되는 위치를 확인합니다.
- 작업 종료 뒤 캐시와 임시 파일의 삭제 범위를 정의합니다.
- 네트워크 단절과 노드 재시작 뒤 자동 복구를 시험합니다.
자체 운영 Runner는 네트워크와 환경을 더 세밀하게 통제할 수 있지만, 패치, 계정 회수, 디스크 정리, 장애 대응 책임도 함께 가져옵니다. 자체 운영 Runner 보안 문서처럼 실행 노드의 신뢰 경계를 별도로 다루는 이유가 여기에 있습니다.
SECTION 06다섯째 단계: 고정 생산 용량과 탄력 용량을 계산하십시오
용량은 평균 작업량만 보고 정하면 안 됩니다. 다음 네 가지 상태를 별도로 기록하십시오.
- 평상시 PR 대기열
- TestFlight 또는 스토어 제출 전의 배포 피크
- 노드 장애로 인한 우회 작업
- Xcode 업그레이드 검증 기간
혼합 모델의 월간 비용은 다음처럼 변수로 두고 비교할 수 있습니다.
고정 노드 비용 + 호스팅 작업 시간 비용 + 운영 인력 비용 + 장애로 인한 지연 비용
전용 원격 Mac의 사용률이 낮더라도 생산 서명과 사설망 의존성을 안정적으로 처리해 배포 중단 위험을 낮출 수 있습니다. 반대로 PR 수가 불규칙하고 피크가 짧다면 호스팅 Agent를 늘리는 편이 유리할 수 있습니다. 금액이나 절감률을 미리 단정하지 말고, 실제 대기 시간과 복구 기록을 입력해 판단해야 합니다.
Kotlin 공식 문서에는 CI 흐름을 구성하는 여러 방식이 제시되어 있으며, 보안 비밀 값 사용에 관한 공식 지침은 비밀 값과 작업 권한을 별도로 관리하도록 안내합니다. 특정 CI 플랫폼의 기능보다 네 작업 경계와 복구 절차가 먼저입니다.
최종 진입 기준
다음 조건이면 호스팅 macOS Agent로 시작하십시오.
- PR 작업이 대부분이고 사설망 접근이 없습니다.
- 생산 서명 키를 작업 노드에 보관할 필요가 없습니다.
- 표준 Xcode 이미지로 결과물을 재현할 수 있습니다.
- 피크 때만 실행 자원이 많이 필요합니다.
다음 조건이면 전용 원격 Mac을 생산 기준선으로 두십시오.
- TestFlight 배포가 핵심 업무입니다.
- 내부 저장소나 고정 네트워크 출구가 필요합니다.
- Xcode 버전과 캐시를 고정해야 합니다.
- 장애 조사와 접근 감사가 필수입니다.
두 목록이 모두 해당하면 고정 생산 노드와 호스팅 탄력 용량을 함께 운영하십시오. 기업용 원격 Mac 환경을 확인할 수 있는 MACNOX 안내에서 접근 방식과 운영 조건을 먼저 확인한 뒤, 실제 KMP 파이프라인으로 검증하는 순서가 안전합니다.
매일 쓰는 Mac을 직접 구매하는 방식은 하드웨어 통제와 장기 고정 환경에는 강점이 있지만, 초기 구매비, 유휴 시간, 교체와 장애 대응, 원격 근무자의 접근 관리가 함께 따라옵니다. 일반 클라우드 빌드는 빠르게 늘릴 수 있어도 사설망과 장기 서명 자격 증명에서 제약이 생길 수 있습니다. 이런 조건에서 MACNOX의 원격 Mac을 격리된 생산 노드로 시험하면, 구매 전에 실제 대기열, 빌드 결과, 재시작과 복구 시간을 확인할 수 있습니다. 다만 장기간 높은 사용률이 계속되거나 물리 기기 연결이 필요한 팀이라면 직접 보유가 더 적합할 수 있습니다.
먼저 네 작업을 생산 서명, 사설망 의존성, 피크 PR로 표시하십시오. 그 뒤 MACNOX의 원격 Mac 신청 경로로 격리 노드 시범 운영을 구성하고, 비용 절감 약속이 아니라 실제 전달과 복구 기록으로 Kotlin Multiplatform iOS CI의 최종 구성을 결정하십시오.