빌드 횟수는 많지 않은데 매번 환경을 고치는 데 시간이 들고, 반대로 빌드가 몰리는 날에는 Xcode Cloud 사용량이 빠르게 줄어듭니다.
이번 주에는 최근 빌드 기록을 먼저 정리하십시오. 저빈도이고 의존성이 단순하면 Xcode Cloud를 선택하고, 상시 실행 작업과 맞춤 도구가 필요하면 iOS 빌드 서버를 선택하는 것이 빠릅니다. 두 조건이 섞여 있다면 검증은 Xcode Cloud에서, 배포와 특수 작업은 독립된 Mac 환경에서 처리하는 이중 구성이 안전합니다.
이 글은 다음과 같은 개발자를 위한 내용입니다.
- 매달 빌드 횟수가 많지 않고 애플 기본 CI/CD를 빠르게 시작하려는 개인 개발자
- fastlane, 사설 의존성, 맞춤 스크립트를 사용하며 완전한 macOS 제어권이 필요한 개발자
- 클라우드 계산 시간과 장기 Mac 환경의 비용을 비교하는 소규모 앱 팀
SECTION 01 먼저 고정해야 할 비교 기준
Xcode Cloud와 iOS 빌드 서버를 비교할 때는 상품 이름이나 한 번의 빌드 가격부터 보면 안 됩니다. 먼저 최근 기록에서 다음 항목을 분리해야 합니다.
- 커밋 또는 수동 실행에 따른 월간 빌드 횟수
- 일반 빌드와 배포 빌드의 평균 실행 시간
- 병렬 테스트가 필요한지 여부
- TestFlight 또는 App Store Connect 배포 빈도
- 빌드 외에 실행해야 하는 작업
- 캐시, 사설 저장소, 백그라운드 프로세스의 필요성
Xcode Cloud는 작업이 끝나면 임시 빌드 환경이 사라지는 방식입니다. 소스 저장소를 빌드 때만 가져오며, 워크플로에는 빌드, 분석, 테스트, 아카이브, 테스트 배포와 맞춤 스크립트를 넣을 수 있습니다. 반면 iOS 빌드 서버는 로그인해서 상태를 확인하고, 직접 도구를 설치하고, 실패한 환경을 그대로 조사할 수 있는 장기 실행 Mac에 가깝습니다. 애플의 Xcode Cloud 워크플로 문서를 기준으로 두 환경을 구분해야 합니다.
| 비교 지표 | Xcode Cloud | iOS 빌드 서버 |
|---|---|---|
| 기본 운영 방식 | 워크플로를 실행하는 임시 환경 | 계속 사용할 수 있는 Mac 환경 |
| 환경 제어 | 지정 가능한 Xcode와 macOS 범위 안에서 관리 | root 권한으로 도구와 스크립트를 직접 관리 |
| 캐시와 상태 | 빌드 사이에 현장 보존을 전제로 하기 어려움 | 캐시, 로그, 설치 상태를 계속 보존 가능 |
| 시작 난이도 | 저장소 연결 후 워크플로 구성 | Mac 접속, 보안, 도구 설치 필요 |
| 적합한 작업 | 가벼운 검증, 애플 기본 배포 흐름 | fastlane, 사설 의존성, 상시 자동화 |
SECTION 02 비용은 계산 시간보다 작업 형태가 좌우합니다
Xcode Cloud는 계산 자원 사용량을 기준으로 관리합니다. 애플 개발자 프로그램에는 월 25 계산 시간이 포함되고, 공식 안내에는 월 100시간 49.99달러, 250시간 99.99달러, 1,000시간 399.99달러, 10,000시간 3,999.99달러 요금제가 표시되어 있습니다. 사용하지 않은 계산 시간은 다음 달로 이월되지 않습니다. 애플의 계산 시간 안내를 기준으로 확인해야 합니다.
반대로 iOS 빌드 서버는 보통 사용 기간을 기준으로 비용을 계산합니다. 따라서 실제 비교에는 임대 기간뿐 아니라 다음 비용도 포함해야 합니다.
- 실패한 빌드의 재실행
- 병렬 테스트에 필요한 추가 환경
- 매번 내려받는 의존성
- Xcode와 도구를 직접 업데이트하는 시간
- 사용하지 않는 시간에도 유지되는 장기 실행 비용
| 부하 형태 | 더 먼저 검토할 선택 | 판단 이유 |
|---|---|---|
| 저빈도 빌드와 단순 의존성 | Xcode Cloud | 사용한 계산 자원만 관리하기 쉽고 초기 운영이 간단함 |
| 안정적인 고빈도 빌드 | iOS 빌드 서버 또는 혼합 구성 | 반복 작업과 캐시 보존이 비용과 대기 시간에 영향을 줌 |
| 특정 시기에만 빌드가 몰림 | 이중 구성 | 평소 검증과 배포 작업을 서로 다른 환경에 나눌 수 있음 |
계산 시간이 부족할 때 바로 요금제를 올려야 합니까?
빌드가 단순하고 사용량이 꾸준히 늘어난다면 먼저 Xcode Cloud의 계산 시간 확대를 검토할 수 있습니다. 하지만 계산 시간 부족의 원인이 병렬 테스트, 의존성 재설치, 긴 배포 스크립트라면 요금제만 올려도 운영 문제가 남습니다. 최근 빌드의 실패 재실행과 비빌드 작업을 따로 집계한 뒤, 지속적인 Mac 환경이 문제를 줄이는지 시험해야 합니다.
단일한 손익분기점은 제시하기 어렵습니다. 같은 빌드 횟수라도 작업 시간, 재시도, 병렬성, 유휴 시간에 따라 결과가 달라지기 때문입니다.
SECTION 03 환경 제어권이 복잡한 프로젝트를 가릅니다
Xcode Cloud에서도 맞춤 빌드 스크립트와 Homebrew 기반 도구를 사용할 수 있습니다. 다만 필요한 의존성이 빌드 환경에서 접근 가능해야 하며, 워크플로에서 선택한 Xcode와 macOS 조합이 프로젝트와 맞아야 합니다. 애플은 사용 가능한 환경을 변경할 수 있으므로, 특정 도구 버전에 의존하는 프로젝트는 워크플로 설정을 정기적으로 확인해야 합니다.
다음 조건이 있으면 iOS 빌드 서버의 장점이 커집니다.
- 특정 버전의 Homebrew 도구를 계속 유지해야 하는 경우
- 사설 저장소나 내부 네트워크에만 있는 의존성을 사용하는 경우
- 큰 파생 데이터와 패키지 캐시를 다시 만들고 싶지 않은 경우
- fastlane 외에 별도의 감시 작업이나 예약 작업을 실행하는 경우
- 빌드 실패 뒤에 직접 로그인해 프로세스와 파일을 확인해야 하는 경우
다만 완전한 제어권은 유지보수 책임과 함께 옵니다. Xcode 업데이트, 디스크 정리, 키체인 접근, 백업, 원격 접속 보안까지 직접 관리해야 합니다. 따라서 root 권한이 있다는 사실만으로 더 좋은 선택이 되는 것은 아닙니다.
Xcode Cloud와 직접 관리하는 Mac 중 어떤 방식이 개인 개발자에게 적합합니까?
개인 개발자가 매일 여러 도구를 설치하고 유지할 필요가 없다면 Xcode Cloud가 적합합니다. 반대로 하나의 앱이라도 사설 의존성, 여러 대상, 맞춤 스크립트, 장시간 실행 작업이 핵심이면 관리 가능한 Mac 환경이 시간을 절약할 수 있습니다. 선택 기준은 앱의 크기보다 빌드 과정의 상태를 얼마나 오래 보존해야 하는지에 있습니다.
주의: 한 번 성공한 빌드만 보고 안정성을 판단하지 마십시오. 최소한 일반 빌드, 서명 빌드, TestFlight 업로드 실패와 재실행 기록을 연속으로 확인해야 합니다.
SECTION 04 서명과 배포는 자동화 방식이 갈립니다
Xcode Cloud는 애플 도구와 연결된 기본 워크플로를 빠르게 구성하기 좋습니다. 자동 서명은 등록된 앱 식별자, 인증서, 권한 정보를 기준으로 필요한 프로파일을 관리하는 데 유리합니다. 애플은 App Store Connect 업로드 과정에서 자동 서명을 선택하면 Xcode가 배포용 프로비저닝 프로파일을 관리할 수 있다고 안내합니다. 애플의 프로비저닝 프로파일 안내를 함께 확인하십시오.
반면 여러 앱과 여러 대상의 서명 자산을 동일한 방식으로 관리해야 한다면 fastlane의 match가 더 명확한 구조를 제공합니다. match는 인증서와 프로비저닝 프로파일을 별도 저장소에 보관하고, 새 Mac에서 이를 다시 설치할 수 있도록 설계되어 있습니다. CI 환경에서는 기존 자산을 가져오기만 하는 readonly 사용이 권장됩니다. fastlane의 match 문서에서 저장 구조와 옵션을 확인할 수 있습니다.
App Store Connect 업로드에는 API 키를 사용할 수 있습니다. fastlane 문서에 따르면 API 키 방식은 이중 인증 입력을 줄이고, 공식 API를 이용하며, match, pilot, deliver 같은 작업과 연결할 수 있습니다. 키 파일과 발급자 식별자는 저장소에 직접 넣지 말고 CI 비밀 변수나 접근 제한된 저장소에서 주입해야 합니다.
TestFlight 빌드는 애플 안내상 최대 90일 동안 테스트할 수 있습니다. 따라서 배포가 성공했다는 사실만 기록하지 말고, 업로드 이후 처리 상태, 수출 규정 정보, 테스터 배포 상태까지 기록해야 합니다. App Store Connect 빌드 상태 안내도 배포 점검 기준으로 사용할 수 있습니다.
fastlane 자동화는 Xcode Cloud와 원격 Mac 중 어디에 두는 편이 낫습니까?
fastlane이 단순히 아카이브와 TestFlight 업로드만 담당한다면 Xcode Cloud의 맞춤 스크립트로 시작할 수 있습니다. 하지만 match 저장소, 여러 대상, 내부 도구, 예약 실행, 실패 뒤 수동 조사가 함께 필요하면 원격 Mac이 더 다루기 쉽습니다. 배포 작업은 모든 커밋마다 실행하기보다 태그나 수동 릴리스 작업으로 제한하는 편이 안전합니다.
SECTION 05 복구 능력까지 포함한 실행 순서
다음 순서로 시험하면 두 환경의 차이를 실제 기록으로 비교할 수 있습니다.
- 최근 빌드 기록에서 일반 빌드, 테스트, 아카이브, TestFlight 업로드를 분리합니다.
- 각 작업의 실행 시간과 실패 재실행 횟수를 기록합니다.
- 사설 패키지, Homebrew 도구, 환경 변수, 인증서, API 키 의존성을 목록으로 만듭니다.
- 대표적인 브랜치 하나를 Xcode Cloud 워크플로에 연결하고, 같은 커밋으로 빌드합니다.
- 동일한 커밋과 동일한 스크립트를 iOS 빌드 서버에서 실행합니다.
- 첫 실행뿐 아니라 의존성이 이미 내려받아진 두 번째 실행도 비교합니다.
- 의도적으로 서명 오류나 잘못된 환경 변수를 넣고 로그와 복구 절차를 확인합니다.
- 결과를 비용, 대기 시간, 수정 가능성, 재현성으로 나눠 기록합니다.
- 한 달 뒤 다시 계산해 유휴 시간과 유지보수 시간을 반영합니다.
이번 주에 확인할 항목
- [ ] 최근 빌드 기록에서 월간 실행 횟수를 분리했습니다.
- [ ] 일반 빌드와 배포 빌드의 평균 시간을 따로 기록했습니다.
- [ ] 실패 재실행과 병렬 테스트 여부를 확인했습니다.
- [ ] 사설 의존성과 맞춤 도구 목록을 만들었습니다.
- [ ] 인증서와 API 키를 저장소 밖에서 주입하도록 바꿨습니다.
- [ ] 같은 커밋을 두 환경에서 실행했습니다.
- [ ] 첫 실행과 캐시가 있는 실행을 모두 비교했습니다.
- [ ] 실패 후 로그 확인과 복구에 걸린 시간을 기록했습니다.
- [ ] 장기 실행 작업이 실제로 필요한지 확인했습니다.
SECTION 06 조건별 최종 선택
다음 표에서 가장 많은 항목에 표시되는 쪽을 1차 선택으로 삼으면 됩니다.
| 조건 | 추천 환경 |
|---|---|
| 애플 기본 도구와 자동 서명을 주로 사용함 | Xcode Cloud |
| 빌드 빈도가 낮고 환경 변화가 적음 | Xcode Cloud |
| fastlane과 여러 앱 대상을 운영함 | iOS 빌드 서버 |
| 캐시와 설치 상태를 계속 보존해야 함 | iOS 빌드 서버 |
| 예약 작업과 백그라운드 프로세스가 필요함 | iOS 빌드 서버 |
| 평소 검증과 배포 작업의 성격이 다름 | 이중 구성 |
| 자체 운영 부담을 거의 지고 싶지 않음 | Xcode Cloud |
iOS 빌드 서버는 항상 온라인이어야 합니까?
모든 개발자가 상시 온라인 환경을 필요로 하지는 않습니다. 단순한 수동 배포라면 작업할 때만 접근해도 됩니다. 그러나 야간 빌드, 예약된 fastlane 작업, 웹훅에 따른 자동 배포, 장시간 테스트가 있다면 지속적으로 접근 가능한 환경이 필요합니다. 이 경우 서버의 전원 상태보다 원격 접속, 저장 공간, 로그 보존, 재시작 절차를 먼저 확인해야 합니다.
Xcode Cloud는 유지해야 할 호스트가 없다는 점이 강점입니다. iOS 빌드 서버는 직접 로그인해 문제를 찾고, 필요한 파일과 캐시를 보존할 수 있다는 점이 강점입니다. 결정이 어려우면 최근 작업 중 가장 복잡한 하나를 기준으로 시험하고, 그 결과를 장기 선택에 반영하십시오.
현재 사용하는 Xcode Cloud 방식은 의존성이 복잡해질수록 스크립트 조정과 계산 시간 관리가 필요하고, 임시 환경이라 실패 당시의 상태를 그대로 보존하기 어렵습니다. 반대로 직접 Mac을 구매해 운영하면 초기 하드웨어 비용, 저장 공간 관리, 업데이트, 전원과 원격 접속 유지까지 맡아야 합니다. 이런 부담을 줄이면서 완전한 macOS 제어권과 상시 실행 환경이 필요하다면 VPSNIX의 원격 Mac 이용 안내와 요금제 정보를 비교해 보는 편이 합리적입니다.
가장 안전한 순서는 최근 빌드 기록을 먼저 내보내고, 대표 워크플로를 두 환경에서 실행한 뒤 결정하는 것입니다. 결과가 지속적인 환경과 root 권한을 요구한다면 모델명만 보고 고르지 말고, 실제 작업에 필요한 저장 공간, 접속 방식, 로그 확인 절차를 기준으로 VPSNIX의 Mac 환경을 검토하십시오.