Runner가 온라인이라는 사실만으로 처리 용량이 확보되지는 않습니다. 자체 호스팅 Runner는 작업 라우팅 조건을 만족해야 하며, 하나의 Runner에 작업이 몰리면 나머지 Runner가 유휴 상태여도 대기열은 줄지 않을 수 있습니다. GitHub의 자체 호스팅 Runner 라우팅 동작을 먼저 확인해야 합니다.

프로젝트별로 다음 항목을 작업 기록에서 추출합니다.

평균 실행 시간만 사용하면 안 됩니다. 배포일, 대규모 병합, 업무 시작 직후처럼 작업이 몰리는 구간을 별도로 보고 상위 백분위 실행 시간을 기준선으로 삼아야 합니다. GitHub Actions의 모니터링 및 문제 해결 지표는 대기와 실행 상태를 구분해 확인하는 데 활용할 수 있습니다.

원격 Mac 구축 노드 수는 작업 시간으로 어떻게 계산합니까?

작업 도착률을 λ, 대표 실행 시간을 T로 두고 같은 시간 단위를 사용하면 최소 동시 처리량은 다음처럼 계산할 수 있습니다.

필요 슬롯 N ≥ λ × T

이 값은 운영 권장 수가 아니라 부하가 계속 들어올 때의 이론적 하한입니다. 여기에 허용 대기 시간, 실패 재실행, 노드 점검과 장애 예비분을 별도로 더해야 합니다. 따라서 실제 노드 수는 N을 그대로 Mac 대수로 바꾸지 말고, 피크 구간의 측정값과 대조해야 합니다.

PR 빌드는 코드 검사, 단위 테스트, 증분 빌드가 지속적으로 도착하는 형태입니다. 한 작업이 아주 길지 않아도 제출이 겹치면 대기열이 빠르게 늘어납니다. 기본 노드 풀의 목적은 최대 처리량보다 개발자가 결과를 받는 시간을 일정하게 유지하는 데 있습니다.

먼저 Mac이 꼭 필요한 단계를 분리합니다. 순수한 정적 분석, 일부 스크립트 검사, 서버에서 실행 가능한 테스트를 Linux 작업으로 옮기면 Mac 슬롯을 확보할 수 있습니다. 이전 커밋의 PR 작업을 취소할 수 있다면 GitHub Actions 동시성 설정으로 오래된 작업을 정리합니다.

그다음 검사 항목을 무조건 여러 작업으로 나누지 말고 합칠 수 있는 단계를 확인합니다. 작업을 나누면 실행 시간이 짧아질 수도 있지만, 각 작업이 Runner를 별도로 점유해 대기열을 키울 수 있습니다. 반대로 지나치게 합치면 한 번의 실패가 전체 피드백을 늦춥니다.

Xcode CI 대기 시간이 어느 수준이면 Mac 노드를 늘려야 합니까?

고정된 분 단위 기준을 적용하기보다 프로젝트의 목표 대기 시간과 비교해야 합니다. 피크 구간에서 대기 시간의 상위 백분위가 목표를 반복해서 넘고, 작업 도착률을 낮출 수 있는 취소와 단계 재배치도 끝났다면 기본 노드 증설을 검토합니다. 단 한 번의 긴 작업보다 같은 현상이 여러 작업 기록에서 반복되는지가 중요합니다.

PR 풀을 계산할 때는 다음 조건을 확인합니다.

• 오래된 커밋 작업이 자동 취소되는지 확인합니다.
• Mac이 필요하지 않은 검사를 다른 실행 환경으로 옮깁니다.
• 공통 검사와 중복된 검사를 합칠 수 있는지 봅니다.
• 증분 빌드 캐시가 무효화되어 실행 시간이 길어지는지 기록합니다.
• 피크 시간대와 평상시를 나누어 λ와 T를 각각 계산합니다.

UI 테스트는 일반 컴파일과 부하 형태가 다릅니다. 여러 Simulator와 테스트 작업자가 같은 Mac의 CPU, 메모리, 저장 장치, 그래픽 자원을 동시에 사용하기 때문입니다. 워크플로 작업 수와 한 Mac 안의 테스트 작업자 수를 더해 용량을 계산하면 실제 처리량을 과대평가하게 됩니다.

Apple의 병렬 테스트 설정과 테스트 작업자 옵션을 확인한 뒤, 실제 프로젝트에서 작업자 수를 단계적으로 바꿔야 합니다. xcodebuild의 -parallel-testing-worker-count 설정은 병렬 실행을 제어하지만, 작업자 수가 늘어나는 만큼 완료 시간이 항상 줄어든다는 뜻은 아닙니다.

iOS UI 테스트와 컴파일 작업을 같은 Runner에서 실행해도 됩니까?

짧은 컴파일과 가벼운 UI 검증은 공유할 수 있지만, 장시간 UI 테스트와 PR 증분 빌드를 같은 풀에 넣는 방식은 피하는 편이 좋습니다. Simulator 프로세스가 남거나 캐시와 작업 공간이 오염되면 다음 작업의 실패 원인을 추적하기 어렵습니다.

작업자 수를 높였을 때 테스트 시간이 줄지 않고 불안정성이 커지면 단일 Mac의 내부 병렬성을 제한합니다. 그 대신 독립적인 테스트 노드를 추가합니다. 이 판단은 Apple의 기능 설명만으로 결정할 수 없으며, 프로젝트의 자원 사용량과 실제 완료 기록으로 검증해야 합니다. Apple의 빌드 시간 분석 안내도 증분 빌드와 테스트 시간을 구분해 기록하는 데 도움이 됩니다.

배포 작업은 실행 횟수가 적다는 이유만으로 PR Runner와 합치면 안 됩니다. 인증서, 키체인, 프로비저닝 파일, 작업 공간 상태가 남을 수 있고, 실패 뒤 복구 절차도 일반 빌드보다 민감합니다.

GitHub Actions에서는 Runner 라벨과 그룹을 이용한 작업 라우팅을 구성할 수 있습니다. 예를 들어 PR 작업에는 일반 빌드 라벨을, 서명과 아카이브에는 통제된 배포 라벨을 부여합니다. Runner Group 관리 방식으로 저장소와 조직별 접근 범위도 나눌 수 있습니다.

배포 라우팅은 실제 전체 아카이브 작업으로 검증해야 합니다.

• 올바른 Runner Group으로 작업이 전달되는지 확인합니다.
• 키체인 잠금 해제와 인증서 접근이 비대화형 환경에서 되는지 확인합니다.
• 작업 완료 뒤 민감한 파일과 임시 산출물이 삭제되는지 확인합니다.
• 일반 PR 작업이 배포 예약 노드를 선점하지 않는지 확인합니다.
• 노드 장애 뒤 다른 배포 노드로 전환할 수 있는지 기록합니다.

일상 부하, 야간 회귀 테스트, 버전 출시 직전의 집중 작업은 한 숫자로 묶지 않아야 합니다. 야간 회귀가 마감 시간에 영향을 주지 않는다면 큐와 시간 창으로 분산할 수 있습니다. 반대로 출시 전에 완료되어야 하는 작업은 단기 원격 Mac을 추가해 피크만 흡수하는 편이 합리적입니다.

고정 노드를 늘릴 조건은 평상시에도 대기 시간이 지속되고, 작업 최적화 뒤에도 기본 용량이 부족할 때입니다. 일정 조정이 적합한 조건은 작업에 명확한 마감이 없고, 야간 창으로 이동해도 개발 또는 출시 일정에 영향이 없을 때입니다. 단기 확장은 출시일이나 대규모 테스트처럼 피크가 예측되지만 반복 주기가 짧을 때 선택합니다.

장기 임대가 항상 유리한 것은 아닙니다. 평상시 사용률이 낮고 피크가 특정 기간에만 있다면 단기 임대로 시험한 뒤 유지 여부를 판단해야 합니다. 반대로 매일 빌드와 배포가 이어지고 대기 시간이 반복해서 목표를 넘는다면 장기 노드가 운영 예측성을 높일 수 있습니다. KVMNODE의 원격 Mac 임대 요금과 기간은 실제 구매 기간을 비교할 때 확인하되, 먼저 자신의 작업 기록으로 필요한 용량을 산정해야 합니다.

다음 순서로 시험 운영을 진행하면 개발자 수를 임의의 Mac 대수로 바꾸는 오류를 줄일 수 있습니다.

첫째, PR, UI 테스트, 배포, 야간 작업을 라벨과 Runner Group 기준으로 분류합니다. 둘째, 각 작업의 도착 시각, 대기 시작과 종료 시각, 실행 시간, 실패 및 재실행을 저장합니다. 셋째, 평상시와 피크 구간의 λ, T, Q를 따로 계산합니다.

넷째, 기본 노드에서 PR 작업만 실행하고 대기 시간과 유효 완료 시간을 측정합니다. 다섯째, UI 테스트 작업자를 늘리면서 Simulator 안정성, 메모리 압박, 전체 완료 시간을 비교합니다. 여섯째, 배포 작업을 예약 노드로 보내 전체 아카이브와 복구 경로를 확인합니다.

일곱째, 한 번에 모든 노드를 늘리지 말고 작은 단위로 동시 실행을 올립니다. 여덟째, 아래 조건표로 유지, 최적화, 단기 확장, 장기 증설을 결정합니다.

• 대기 시간은 목표 안에 있고 피크도 짧다면 현재 용량을 유지합니다.
• Mac 작업 중 취소 가능한 작업과 중복 검사가 많다면 노드보다 워크플로를 먼저 최적화합니다.
• 출시나 대규모 회귀 때만 대기열이 길어지면 단기 원격 Mac을 추가합니다.
• 평상시에도 대기 시간이 반복되고 작업 재배치 후에도 개선되지 않으면 장기 노드를 늘립니다.
• UI 테스트 작업자 증가로 실패율 또는 유효 완료 시간이 나빠지면 내부 병렬성을 줄이고 테스트 노드를 분리합니다.
• 배포 노드가 일반 작업에 점유되거나 복구 검증을 통과하지 못하면 전용 예약 용량을 유지합니다.

현재 Windows 또는 Linux 서버를 빌드 중심으로 쓰고 있다면 Mac Runner를 추가하지 않는 선택도 가능합니다. 다만 macOS 전용 도구와 Xcode 서명이 필요한 작업을 다른 서버에 억지로 섞으면 원격 GUI 의존, 인증서 관리, 환경 차이, 대기열 우회 같은 운영 부담이 생깁니다. 반대로 장기간 같은 높은 부하를 유지하거나 물리 장치 연결이 필수라면 직접 Mac을 운영하는 편이 더 맞을 수 있습니다.

그 외에는 개발자 수에 맞춰 Mac을 미리 구매하기보다, 실제 PR·UI 테스트·배포 기록으로 피크를 확인한 뒤 필요한 기간만 KVMNODE의 원격 Mac을 추가하는 편이 조달 위험이 작습니다. 특히 배포 직전처럼 짧은 기간에만 용량이 필요한 팀이라면 단기 확장 시험으로 대기 시간과 복구 가능성을 먼저 확인한 뒤 장기 노드 여부를 결정하는 것이 안전합니다.

먼저 한 번의 일반 작업 구간과 한 번의 피크 구간을 기록하십시오. 그 결과를 위 표에 대입하면 현재 Runner를 유지할지, 워크플로를 줄일지, 테스트 노드를 분리할지, 원격 Mac을 단기간 추가할지 판단할 수 있습니다. KVMNODE의 Mac mini 임대 지역별 선택지도 실제 시험 운영 기간과 접근 위치를 정한 다음 비교하는 것이 좋습니다.