GitHub 문서는 작업 조건에 맞는 온라인 유휴 자체 호스팅 Runner가 없으면 작업이 대기열에 남을 수 있다고 설명합니다(Runner 매칭과 대기 규칙). 따라서 기업 iOS CI 맥 노드 용량은 개발자 수로 환산하지 말고, 실제 대기열과 실행 기록으로 산정해야 합니다. 이번 주에는 작업을 유형별로 나누고 기록 수집을 시작하세요. 시험 운영을 거친 뒤에야 기준 용량과 추가 임대 여부를 결정할 수 있습니다.
기업 IT 책임자는 iOS 빌드 자원의 구매나 임대 규모를 계획할 때 참고할 수 있습니다.
플랫폼 엔지니어는 GitHub Actions 자체 호스팅 맥 Runner의 라우팅과 대기열을 점검할 수 있습니다.
FinOps 담당자는 재계산 가능한 용량 및 예산 모델을 만들 때 활용할 수 있습니다.
기업 iOS CI 맥 노드 용량 추정은 사람 수보다 작업 기록이 먼저입니다
먼저 CI 기록에서 각 작업이 언제 요청되고 시작되어 끝났는지, 어떤 Runner에서 실행됐는지 수집하세요. GitHub의 workflow_job 웹훅은 queued, in_progress, completed 상태를 구분해 전달합니다(작업 상태 웹훅 설명). 이 상태를 기준으로 대기 시간과 실행 시간을 따로 계산하면, 긴 실행 작업과 Runner 부족으로 생긴 대기를 구별하기 쉬워집니다.
모든 워크플로 작업이 맥을 필요로 하지는 않습니다. 코드 검사나 파일 처리처럼 macOS와 Xcode에 의존하지 않는 단계는 다른 실행 환경으로 보낼 수 있는지 확인하세요. 반대로 Xcode 빌드, 시뮬레이터 테스트, 애플 플랫폼 서명은 작업 환경을 확인한 뒤 맥 노드 수요에 포함해야 합니다.
대기열이 길다는 사실만으로 노드를 늘리지 마세요. 작업 레이블이나 Runner Group이 맞지 않아 실행 가능한 노드에 배정되지 않는 경우도 있습니다.
PR 빌드와 일반 작업은 맥 의존성부터 가려냅니다
PR 검사, 주 브랜치 빌드, 병합 후 검증을 각각 살펴보세요. 작업마다 발생 빈도, 실행 시간, 다른 작업과 동시에 겹친 정도를 기록합니다. PR이 몰리는 시간대에 주 브랜치 빌드까지 겹친다면 평균 실행 횟수보다 그 구간의 동시 실행 수가 용량 판단에 더 직접적인 근거가 됩니다.
워크플로를 단계별로 살펴 맥이 꼭 필요한 작업만 남기세요. 작업 실행 위치를 Runner Group과 레이블로 선택할 수 있으며, 이 조건이 작업 라우팅의 기준입니다(워크플로 작업의 Runner 선택, 자체 호스팅 Runner 레이블 적용). 서로 다른 조건을 가진 작업이 한 풀을 공유하면, 단순히 노드를 추가해도 일부 작업은 계속 대기할 수 있습니다.
시뮬레이터와 회귀 검사는 일반 빌드와 따로 검증합니다
시뮬레이터 테스트는 대상 환경이나 테스트 매트릭스에 따라 여러 작업으로 나뉠 수 있습니다. 각 작업이 실제로 어떤 macOS와 Xcode 조합을 요구하는지, 어느 정도 겹쳐 실행되는지 기록하세요. 병렬화가 가능한 설정인지 확인하지 않고 실행 시간을 전체 맥 수요로 간주하면 용량을 과대평가할 수 있습니다.
회귀 테스트도 같은 방식으로 살펴보세요. 대기 시간이 일반 빌드보다 길더라도, 원인이 동시 실행 수인지 특정 환경을 가진 Runner 부족인지에 따라 해결책은 달라집니다. 테스트가 평소에는 일반 풀과 함께 돌지만 출시 전에는 긴 시간 동안 그 풀을 점유한다면, 우선순위 조정이나 피크 시간대 분리 운영을 시험해 볼 수 있습니다.
서명과 배포는 실행 시간보다 권한 경계로 나눕니다
아카이브, 서명, 배포 작업은 일반 빌드와 다른 접근 권한 및 승인 절차를 가질 수 있습니다. 서명 자산을 사용할 수 있는 Runner와 배포 대상 환경을 먼저 확인하세요. 이 제약이 있다면 빌드 시간이 짧더라도 일반 Runner와 무조건 같은 풀에 넣을 수는 없습니다.
Runner Group은 접근 가능한 작업의 경계를 구성하는 데 쓰입니다(Runner Group의 접근 제어와 구성). 정식 서명 작업을 분리할지는 권한 정책, 작업 라우팅, 실제 기록을 함께 보고 결정하세요. 보안 정책상 전용 경로가 필요한지 확인하지 않은 채 예상 실행 시간만으로 동시 처리량을 정하면 안 됩니다.
피크와 전용 도구 체인은 탄력 용량으로 분리합니다
집중 병합이나 회귀 테스트, 버전 출시 때만 대기열이 길어지는지 확인하세요. 짧은 피크와 지속적인 용량 부족은 같은 문제가 아닙니다. 팀이 허용할 대기 시간과 작업 우선순위를 먼저 정하고, 과거 기록에서 피크 구간을 확인한 뒤 추가 용량 가정을 세우세요. 이 버퍼는 공식 플랫폼 기준이 아니라 팀이 시험 운영으로 검증해야 하는 가정입니다.
특정 macOS나 Xcode 버전, 아키텍처를 요구하는 작업은 전용 도구 체인으로 분류하세요. 작업 라벨과 실제 배정 기록을 확인해 일반 풀에서 실행할 수 있는지 판단합니다. 고정된 호환성 제약이 있다면 해당 작업을 위한 별도 용량을 계산하고, 수요가 간헐적인 경우 탄력적인 임대가 적합한지 비교하세요.
GitHub Actions의 플랫폼 동시 실행 제한은 요금제와 기능에 따라 확인해야 하는 별도 조건입니다(GitHub Actions 제한 안내). 이 제한을 자체 호스팅 맥 Runner의 권장 대수로 해석하면 안 됩니다. 자체 노드 수는 실제 작업량, 라우팅 조건, 유휴 상태의 노드 수를 바탕으로 별도로 산정하세요. Runner Scale Sets와 자동 확장 구성은 수요에 맞춰 Runner를 관리하는 방법을 설명하지만, 팀의 적정 용량이나 대기 목표까지 정해 주지는 않습니다(Runner Scale Sets 개념, Runner Scale Sets 배포 안내).
기록에서 기준 용량을 계산하고 단계별로 검증합니다
계산 모델은 작업 유형별로 만드세요. 유형별 작업 수와 실행 시간, 동시에 겹치는 비율을 입력하고, 맥이 필요 없는 단계는 제외합니다. 여기에 피크 여유분, 권한이나 도구 체인에 따른 분리 조건, 노드가 실제로 작업을 받을 수 있는 시간을 반영하면 기준 용량과 추가 용량을 구분할 수 있습니다. 특정 대수나 비용을 기록 없이 미리 정하지 마세요.
아래 항목을 차례로 확인하세요.
- [ ] PR 검사와 주 브랜치 빌드를 나누고, 발생 빈도와 실제 실행 시간을 기록합니다.
- [ ] 각 작업에서 macOS나 Xcode가 필요한 단계와 다른 환경으로 보낼 수 있는 단계를 구분합니다.
- [ ] 시뮬레이터와 회귀 테스트의 동시 실행 및 도구 체인 조건을 기록합니다.
- [ ] 서명·배포 작업의 접근 권한과 실행 가능한 Runner Group을 확인합니다.
- [ ] 작업 대기와 실행 기록을 비교해 피크가 일시적인지 지속적인지 판별합니다.
- [ ] 작업 라벨, 그룹, 유휴 상태를 확인해 대기 원인이 라우팅인지 용량인지 구별합니다.
- [ ] 시험 운영에서 대기 시간과 실행 시간을 다시 측정한 뒤 모델의 기준 용량을 조정합니다.
- [ ] 실제 사용량을 바탕으로 구매, 상시 임대, 피크 시간대 추가 임대 중 적합한 방식을 비교합니다.
시험 운영에서 대기 시간이 줄었더라도 보안 경계나 도구 체인이 다른 작업을 같은 풀에 무리하게 합치지 마세요. 확장 후에도 작업 라우팅과 실제 배정을 다시 확인해야 합니다.
구매와 임대는 피크 대응 및 운영 부담으로 비교합니다
비교할 때는 장비 가격만이 아니라 사용하지 않는 기간의 비용, 교체와 유지 관리, 용량 변경에 필요한 시간, 보안 분리 요구를 함께 살펴보세요. 아래 표는 고정 가격이나 특정 노드 수를 가정하지 않고, 실제 CI 기록을 채워 결정하는 기준입니다.
| 운영 방식 | 적합한 상황 | 확인할 부담과 조건 |
|---|---|---|
| 직접 구매 | 수요가 꾸준하고 장기간 같은 환경을 운영할 때 | 초기 구매와 유지 관리, 교체 시점, 피크를 위한 유휴 용량 |
| 상시 맥 CI 임대 | 팀이 직접 장비를 보유하지 않고 지속적인 빌드 환경을 운영하려 할 때 | 실제 작업과 맞는 구성, 임대 기간, 지역과 제공 조건 |
| 피크용 추가 임대 | 평소보다 출시나 회귀 작업 구간에 수요가 커질 때 | 추가 용량을 받을 수 있는 시점, 환경 일치 여부, 작업 종료 후 회수 |
원격 맥 CI 임대를 검토한다면 팀의 도구 체인과 접근 정책부터 대조하세요. VMSPIN의 요금 안내에서 확인 가능한 임대 조건을 기준으로 비교하고, 지역과 제공 방식이 중요하다면 한국 리전 주문 안내에서 현재 확인할 수 있는 내용을 살펴보세요. 페이지에서 검증할 수 없는 구성이나 제공 조건은 예산에 확정값으로 넣지 않는 편이 안전합니다.
자주 묻는 질문
기존 장비 확장과 맥 임대는 운영 조건으로 비교합니다
현재 방식이 직접 구매 중심이라면 유휴 장비도 보유해야 하고, 증설과 교체 시기를 별도로 관리해야 합니다. 내부 공유 맥 한 대에 작업을 몰아두면 피크 때 대기열이 길어지거나, 권한이 다른 서명 작업과 일반 빌드를 분리하기 어려울 수 있습니다. 반대로 맥 CI 임대도 환경, 접근 통제, 계약 기간이 팀 요구와 맞지 않으면 적합하지 않습니다.
작업 기록으로 상시 수요와 피크 수요를 구분한 뒤, 장기간 안정적인 부하에는 구매나 상시 운영을 검토하고 일시적인 피크에는 추가 임대가 맞는지 비교하세요. 팀의 도구 체인과 운영 조건에 맞는 구성을 확인할 수 있을 때 VMSPIN의 원격 맥 임대 안내를 살펴보고, 먼저 작은 시험 운영으로 대기열과 작업 배정을 검증하세요.