GitHub Actions macOS Runner 선택은 저빈도·변동형 빌드라면 호스팅 Runner를, 고정된 도구 체인·사설망·지속 캐시가 필요하다면 원격 Mac 기반 self-hosted runner를 우선 검토하는 방식이 맞습니다. 대부분의 기업에는 호스팅 Runner로 탄력적 작업을 처리하고, 원격 Mac으로 서명과 운영 빌드를 맡기는 혼합 구성이 가장 현실적입니다.
이 글은 여러 iOS 프로젝트의 CI/CD 비용과 대기 시간을 관리하는 플랫폼 책임자를 위한 내용입니다. 사설 의존성, 서명 인증서, 내부망 접근을 통제해야 하는 IT·보안 담당자와 Mac 빌드 노드 구매·임대를 검토하는 CTO도 대상입니다.
[ SECTION_01 ] 먼저 측정해야 할 다섯 가지 작업 지표
선택 전에 최근 2주간의 빌드 기록을 모아야 합니다. 총 실행 시간만 보면 피크 시간대의 병목과 환경 초기화 비용을 놓치기 쉽습니다.
다음 항목을 프로젝트별로 기록합니다.
- 월간 macOS 빌드 시간
- 최대 동시 실행 수와 평균 대기 시간
- 빌드량의 변동 폭
- 사설망·사설 패키지 저장소 접근 여부
- Xcode, SDK, 인증서, 캐시를 고정해야 하는 정도
| 측정 결과 | 우선 검토할 방식 | 판단 이유 |
|---|---|---|
| 빌드가 드물고 실행량 변동이 큼 | GitHub 호스팅 Runner | 사용한 실행 시간 중심으로 확장하기 쉽습니다. |
| 여러 프로젝트가 같은 시간대에 빌드됨 | 혼합 구성 | 평상시 작업과 피크 작업을 분리할 수 있습니다. |
| 내부 패키지 저장소나 사설망이 필수임 | 원격 Mac self-hosted runner | 네트워크 경계를 직접 통제할 수 있습니다. |
| 고정된 Xcode와 서명 환경이 필요함 | 원격 Mac self-hosted runner | 작업 사이에 도구와 캐시를 유지하기 쉽습니다. |
| 공개 저장소의 외부 기여 코드를 실행함 | 호스팅 Runner | 지속형 호스트에 비신뢰 코드를 올리는 위험을 줄일 수 있습니다. |
GitHub는 macOS 호스팅 Runner에 Intel과 arm64 선택지를 제공합니다. 현재 공식 문서에는 표준 macOS Runner의 메모리와 프로세서 구성이 이미지별로 다르게 제시되어 있으며, arm64 환경에서는 일부 커뮤니티 Action을 별도로 검증해야 한다고 안내합니다. 공식 macOS Runner 사양 문서에서 실제 라벨과 이미지 상태를 배포 전에 확인해야 합니다.
[ SECTION_02 ] 비용은 실행 시간과 유휴 자원을 함께 계산합니다
GitHub 호스팅 Runner는 작업 시간이 바로 청구 기준이 됩니다. 공식 가격표에는 일반 macOS 3코어 또는 4코어 Runner의 단가가 분당 0.062달러로 표시되어 있으며, 작업 시간의 일부도 분 단위로 올림 처리됩니다. 단가는 변경될 수 있으므로 계산 시점에 공식 Runner 가격표를 다시 확인해야 합니다.
호스팅 비용은 다음처럼 계산합니다.
월간 호스팅 비용 = 월간 청구 분 × 적용 macOS 분당 단가
그러나 이것만으로 구매와 임대를 비교하면 안 됩니다. self-hosted runner에는 Mac 자원, 유휴 용량, 초기 설정, 운영체제와 Xcode 업데이트, 장애 대응, 모니터링, 담당자 작업 시간이 들어갑니다.
월간 자체 운영 비용 = Mac 자원 비용 + 유휴 용량 비용 + 초기화·유지보수 비용 + 장애 대응 인건비 + 네트워크·보안 비용
| 비용 항목 | 호스팅 Runner | 원격 Mac self-hosted runner |
|---|---|---|
| 실행 시간 | GitHub 청구 기준 적용 | 계약·자원 사용 기간에 따라 산정 |
| 유휴 용량 | 일반적으로 별도 장비를 확보하지 않음 | 피크를 위해 미사용 자원을 보유할 수 있음 |
| 초기 환경 구성 | 이미지와 Action에 의존 | Xcode, SDK, 인증서, 캐시를 직접 구성 |
| 운영체제 업데이트 | 플랫폼 운영 범위 안에서 처리 | 담당자가 일정과 검증을 관리 |
| 장애 대응 | 플랫폼 상태와 내부 워크플로를 분리해 조사 | 호스트, Runner 앱, 네트워크를 함께 확인 |
| 비용 예측 | 실행 분과 동시성 중심 | 사용 기간과 운영 책임까지 포함해야 함 |
GitHub Actions macOS 호스팅 Runner와 self-hosted runner 중 기업에 더 적합한 쪽은 무엇인가요?
월간 실행 시간이 낮고 작업 형태가 자주 바뀐다면 호스팅 Runner가 유리합니다. 반대로 같은 프로젝트를 반복 빌드하고, 캐시와 Xcode 상태를 유지하며, 내부망에 연결해야 한다면 원격 Mac의 총비용이 더 예측 가능할 수 있습니다.
기업은 먼저 GitHub 청구 화면에서 저장소별 실행 분과 실패 재실행 시간을 내려받아야 합니다. 그다음 원격 Mac 후보의 월 사용료와 운영 담당자 시간을 같은 기간으로 맞춰 비교해야 합니다. GitHub Actions 청구 방식은 플랜별 포함량과 초과 사용량을 구분하므로, 무료 포함량을 실제 비용으로 잘못 계산하지 않도록 주의해야 합니다.
[ SECTION_03 ] 처리량은 평균 속도보다 대기와 초기화가 좌우합니다
호스팅 Runner는 작업마다 새 환경에 가까운 상태에서 시작하므로, Xcode 관련 도구 설치와 패키지 복원이 반복될 수 있습니다. 반면 지속형 원격 Mac은 캐시와 도구를 남겨 둘 수 있어 반복 빌드에 적합합니다.
다만 캐시가 남는다는 점은 장점이면서 위험 요소입니다. 이전 작업의 산출물이나 인증 정보가 다음 작업에 영향을 줄 수 있기 때문입니다. 따라서 캐시 경로, 작업 디렉터리, 키체인, 임시 파일을 작업 종료 후 정리하는 절차가 필요합니다.
처리량을 비교할 때는 다음 순서를 지킵니다.
- 같은 프로젝트와 브랜치 기준을 고정합니다.
- 같은 Xcode 버전과 SDK를 사용합니다.
- 동일한 의존성 잠금 파일을 적용합니다.
- 캐시가 없는 첫 실행과 캐시가 있는 반복 실행을 나눕니다.
- 단일 작업과 동시 작업의 대기 시간을 각각 기록합니다.
- 실패 후 재시작 시간과 노드 복구 시간도 기록합니다.
호스팅 Runner의 동시성은 계정과 조직의 플랜에 영향을 받습니다. 큰 Runner는 별도의 접근 조건과 사용 설정이 필요할 수 있으며, 공식 문서에는 큰 Runner의 초기 할당 대기와 워밍 상태가 일반 Runner와 다를 수 있다고 설명되어 있습니다. 큰 Runner 운영 문서를 기준으로 피크 시간대의 대기 시간을 따로 측정해야 합니다.
[ SECTION_04 ] Apple Silicon과 고정 환경은 별도로 검증합니다
Apple Silicon 기반 빌드는 arm64 호환성이 핵심입니다. 공식 제공 Action과 커뮤니티 Action을 같은 기준으로 보면 안 됩니다. GitHub는 공식 Action이 arm64 Runner와 호환된다고 설명하지만, 커뮤니티 Action은 실행 파일, 셸 스크립트, 사전 설치 도구에 따라 별도 검증이 필요합니다.
다음 조건이 있으면 self-hosted runner 쪽으로 점수가 올라갑니다.
- 특정 Xcode 버전을 장기간 고정해야 합니다.
- 사내 SDK나 내부 명령줄 도구를 설치해야 합니다.
- 사설 패키지 저장소가 외부 호스팅 Runner에서 접근되지 않습니다.
- 반복 빌드에서 큰 의존성 캐시를 유지해야 합니다.
- 서명 인증서와 키체인을 별도 호스트에 두어야 합니다.
- 내부 방화벽에서 허용된 고정 출발지 주소가 필요합니다.
반대로 최신 이미지에서 표준 도구만 설치하고, 각 작업을 깨끗하게 시작하는 것이 더 중요한 경우에는 호스팅 Runner가 관리 부담을 줄입니다.
[ SECTION_05 ] 보안은 Runner 형태보다 작업 신뢰 경계가 먼저입니다
self-hosted runner는 기업이 하드웨어와 운영체제를 통제할 수 있지만, 실행 환경이 자동으로 깨끗해지는 것은 아닙니다. GitHub 공식 보안 문서는 비신뢰 코드가 지속형 Runner를 오염시키거나, 같은 호스트에 남은 비밀 정보와 GITHUB_TOKEN에 접근할 수 있다고 경고합니다. Actions 보안 사용 지침을 보안 검토의 기준 문서로 삼아야 합니다.
self-hosted runner에서 서명 인증서와 저장소를 어떻게 분리해야 하나요?
서명용 Runner Group을 별도로 만들고, 접근 가능한 저장소를 선택 목록으로 제한해야 합니다. 개발·검증용 그룹과 배포용 그룹을 나누고, 배포 그룹에는 승인된 워크플로와 보호된 환경만 연결합니다. 인증서는 호스트에 장기간 평문으로 보관하지 말고, 사용 범위와 교체 주기를 정해야 합니다.
공개 저장소 또는 외부 기여 Pull Request가 들어오는 저장소에서는 지속형 self-hosted runner를 무조건 사용하면 안 됩니다. GitHub는 공개 저장소의 포크가 비신뢰 코드를 실행할 수 있다는 이유로 self-hosted runner 사용을 제한하도록 권고합니다. self-hosted Runner 보안 및 등록 문서를 기준으로 저장소 유형별 허용 범위를 정해야 합니다.
운영 전에는 다음을 확인합니다.
- Runner Group에 허용 저장소만 등록되어 있는지 확인합니다.
- 배포용 인증서와 개발용 인증서를 분리합니다.
- Pull Request 이벤트와 배포 이벤트의 Runner 라벨을 분리합니다.
- 작업 종료 후 키체인, 임시 파일, 로그, 패키지 인증 정보를 삭제합니다.
- 사설망 접근은 필요한 목적지와 포트만 허용합니다.
- Runner 호스트에서 클라우드 관리 주소나 다른 프로젝트의 비밀 저장소로 직접 접근하지 못하게 합니다.
Runner Group은 조직 단위로 접근 가능한 저장소를 제한하는 기능을 제공합니다. Runner Group 접근 제어 문서를 보안 지침과 함께 검토해야 합니다.
[ SECTION_06 ] 운영 책임과 복구 시간까지 점수에 넣습니다
self-hosted runner는 장비를 연결하는 순간부터 운영 대상이 됩니다. Runner 앱은 실행 중이어야 작업을 받을 수 있고, 운영체제와 도구 체인은 별도로 관리해야 합니다. GitHub 문서에는 Runner 버전을 일정 기간 안에 업데이트하지 않으면 작업이 배정되지 않을 수 있다고 안내합니다. self-hosted Runner 운영 문서를 기준으로 업데이트 책임을 정해야 합니다.
다음 점수표는 구매·임대·호스팅을 비교할 때 사용할 수 있습니다. 각 항목을 1점에서 5점으로 평가하되, 조직의 우선순위에 따라 가중치를 적용합니다.
| 평가 기준 | 호스팅 Runner | 원격 Mac self-hosted runner | 혼합 구성 |
|---|---|---|---|
| 변동형 작업 대응 | 5 | 2 | 5 |
| 고정 Xcode 환경 | 2 | 5 | 5 |
| 사설망 연결 | 2 | 5 | 4 |
| 초기 설정 속도 | 5 | 2 | 4 |
| 지속 캐시 활용 | 2 | 5 | 5 |
| 비신뢰 코드 분리 | 5 | 2 | 4 |
| 운영 책임의 단순성 | 5 | 2 | 3 |
| 피크 확장성 | 4 | 3 | 5 |
점수보다 중요한 것은 낮은 점수의 원인입니다. 사설망 점수가 낮은데 호스팅 Runner를 선택하면 빌드 실패가 반복될 수 있습니다. 반대로 운영 책임 점수가 낮은데 self-hosted runner를 선택하면 장비 장애와 인증서 만료가 플랫폼 팀의 업무가 됩니다.
기업은 호스팅 Runner와 원격 Mac 빌드 노드를 함께 사용할 수 있나요?
가능합니다. 일반 테스트와 변동형 빌드는 호스팅 Runner로 보내고, 서명·배포·사설망 의존 작업은 특정 라벨의 원격 Mac으로 보냅니다. 워크플로의 runs-on 라벨과 Runner Group 정책을 분리하면 프로젝트별 라우팅을 명확하게 관리할 수 있습니다. self-hosted runner는 라벨 또는 그룹을 통해 작업 대상을 지정할 수 있습니다. self-hosted Runner 관리 문서를 참고하면 됩니다.
[ SECTION_07 ] 세 가지 기업 유형별 선택 기준
저빈도 소규모 팀
월별 실행량이 낮고 작업 시간이 일정하지 않다면 호스팅 Runner가 적합합니다. 장비를 계속 켜 두지 않아도 되고, Xcode 이미지와 기본 Action을 조합해 빠르게 시작할 수 있습니다.
안정적인 운영 빌드 팀
매일 같은 프로젝트를 빌드하고, 사설 패키지나 고정된 서명 환경이 필요하다면 원격 Mac self-hosted runner가 적합합니다. 단일 노드에 의존하지 않도록 대기 노드와 복구 절차를 함께 설계해야 합니다.
여러 프로젝트를 운영하는 기업
혼합 구성이 적합합니다. 호스팅 Runner는 변동량과 외부 기여 검증을 맡습니다. 원격 Mac은 승인된 저장소의 운영 빌드와 사설망 작업을 맡습니다. 이 방식은 모든 작업을 비싼 고정 자원에 보내는 실수를 줄입니다.
NOVAKVM의 Mac 원격 임대 요금과 이용 조건을 검토할 때도 단순 월 요금만 비교하면 안 됩니다. Xcode 초기화 시간, 네트워크 접근, Runner 설치 방식, 장애 시 교체 절차를 기업의 TCO 표에 함께 넣어야 합니다. 실제 도입 전에는 한국 지역 Mac 주문 방식과 필요한 접속·운영 절차도 확인하는 편이 좋습니다.
[ SECTION_08 ] 배포 전 실무 절차
- 최근 2주간 저장소별 macOS 실행 분을 추출합니다.
- 피크 시간대의 최대 동시 실행 수와 평균 대기 시간을 기록합니다.
- 사설망, 사설 패키지, 서명 인증서의 의존성을 목록화합니다.
- 같은 프로젝트와 Xcode 버전으로 호스팅·원격 Mac 기준 테스트를 실행합니다.
- 캐시 없음, 캐시 적중, 동시 실행 조건을 나누어 측정합니다.
- Runner Group과 저장소 접근 정책을 먼저 설정합니다.
- Pull Request, 테스트, 서명, 배포 작업을 서로 다른 라벨로 분리합니다.
- 비용 표에 실행 분, 유휴 자원, 유지보수 시간, 장애 대응 시간을 입력합니다.
- 한 달 동안 대기 시간과 실패 재시작 시간을 관찰합니다.
- 기준을 넘으면 호스팅에서 원격 Mac으로, 또는 혼합 구성으로 작업을 이동합니다.
최종 판단은 “어느 Runner가 더 빠른가”가 아닙니다. 작업의 변동성은 호스팅 Runner가, 환경 통제와 사설망 의존성은 원격 Mac이 더 잘 처리합니다. 따라서 두 주간의 실제 데이터를 기준으로 작업을 분류한 뒤, 저장소와 보안 경계를 나누는 것이 가장 안전한 접근입니다.
기존에 Mac을 구매해 직접 운영하는 방식은 자산 감가, 유휴 용량, 장애 교체, 운영체제 업데이트, 담당자 대기 시간이 함께 발생합니다. 반대로 호스팅 Runner만 사용하면 고정 Xcode 환경과 사설망 연결이 제한될 수 있고, 반복 설치 시간이 누적될 수 있습니다. 생산 빌드에 고정 환경이 필요하지만 장비 구매와 유지보수까지 맡기기 어렵다면, NOVAKVM의 원격 Mac을 self-hosted runner 후보로 검증하는 편이 더 현실적입니다. 먼저 이 글의 지표표로 작업을 분류하고, 결과가 지속 캐시·고정 Xcode·사설망 접근을 가리킬 때만 원격 Mac 용량 평가로 넘어가야 합니다.