GitHub Actions macOS Runner 비용 판단

GitHub Actions macOS Runner 비용은 다음처럼 나눠서 계산해야 합니다.

총비용 = 호스팅 청구액 + 저장소 및 산출물 비용 + 원격 맥 임대료 + 유휴 시간 비용 + 유지보수 시간 비용 + 장애 손실

호스팅 Runner는 실제 작업 시간에 따라 비용이 움직입니다. 자체 운영 Runner는 작업이 없어도 노드가 켜져 있는 기간에 비용이 발생합니다. GitHub는 호스팅 Runner 작업을 분 단위로 청구하지만, 자체 운영 Runner를 사용할 때는 장비 임대와 운영을 사용자가 부담합니다. (GitHub Actions 요금 기준)

따라서 최근 완료된 전체 청구 기간의 데이터를 기준으로 비교해야 합니다. 일부 성공한 빌드나 이상적으로 높은 이용률을 가정하면 결론이 흔들립니다.

먼저 다음 값을 수집합니다.

• 저장소별 macOS 작업 실행 횟수
• 작업마다 청구된 시간과 실제 실행 시간
• 대기 시간과 실행 시간
• 실패 후 재시도 횟수
• 캐시 복원 시간과 캐시 적중 여부
• 서명, 보관, 테스트 작업의 비중
• 자체 운영 노드의 예상 점유 기간
• 업데이트와 장애 대응에 들어간 사람 시간

간헐적 릴리스

주기적인 배포와 수동 검증이 중심이면 호스팅 Runner의 탄력성이 유리합니다. 사용하지 않는 시간에 노드를 유지할 필요가 없기 때문입니다.

자체 운영 원격 맥을 일정 기간 임대해도 실제 빌드가 며칠에 그친다면 유휴 시간이 총비용을 키울 수 있습니다. 이 유형에서는 고정 환경보다 필요할 때만 실행하는 구조가 더 중요합니다.

매일 반복되는 빌드

매일 같은 프로젝트를 여러 차례 빌드한다면 자체 운영 Runner의 환경 재사용 효과를 검토할 수 있습니다. 호스팅 환경은 작업마다 새 실행 환경에서 시작하므로 의존성 설치와 캐시 복원 시간이 반복될 수 있습니다. (호스팅 Runner 실행 방식)

반면 자체 운영 Runner는 Xcode와 패키지 도구를 미리 설치할 수 있습니다. 대신 이전 작업의 파일, 키체인, 시뮬레이터 상태가 남을 수 있습니다. 빌드가 빠르더라도 재현성이 떨어지면 운영 비용이 다시 커집니다.

여러 브랜치의 동시 빌드

동시성이 높으면 단일 자체 운영 노드가 대기열 병목이 됩니다. 호스팅 Runner는 작업을 분산하기 쉽지만, 사용량 증가가 청구액 증가로 이어집니다.

월간 실행 시간만 보지 말고 대기 시간, 실제 실행 시간, 노드 점유 시간을 함께 기록해야 합니다. GitHub 문서에 따르면 일치하는 온라인 유휴 Runner가 없으면 작업은 대기하며, 일정 시간 이상 대기한 작업은 실패할 수 있습니다. (자체 운영 Runner 참고 문서)

iOS 빌드량이 어느 정도가 되면 자체 운영 Runner로 바꿔야 합니까?

모든 팀에 적용되는 고정 분량 기준은 없습니다. 아래 계산에서 자체 운영 비용이 호스팅 청구액보다 낮고, 대기 시간과 실패율도 허용 범위 안에 있을 때 전환 후보가 됩니다.

자체 운영 후보 비용 = 월 임대료 + 유휴 시간 비용 + 관리 시간 × 내부 시간 단가 + 장애 손실

핵심은 분당 요금이 아니라 최근 실제 사용량입니다.

자체 운영 원격 맥의 장점은 환경을 오래 유지할 수 있다는 점입니다. Xcode, 패키지 관리자, 시뮬레이터, DerivedData를 미리 준비할 수 있습니다. 하지만 캐시가 빠르다는 이유만으로 비용이 낮아졌다고 결론 내리면 안 됩니다.

다음 조건을 고정한 뒤 비교해야 합니다.

• 동일한 저장소와 커밋
• 동일한 Xcode 버전
• 동일한 의존성 잠금 파일
• 동일한 빌드 대상
• 캐시를 끈 실행과 켠 실행
• 동일한 산출물 검증 방식

Apple은 Xcode 버전마다 필요한 macOS 범위와 지원 SDK가 달라질 수 있다고 안내합니다. 따라서 Xcode 버전을 고정해야 하는 프로젝트는 Runner 유형보다 먼저 macOS와 Xcode의 호환 범위를 검증해야 합니다. (Apple Xcode 시스템 요구 사항)

장기 보존 환경은 상태 오염이라는 반대 비용도 만듭니다. 캐시 적중률이 높아졌더라도 새 노드에서 같은 결과가 나오는지, 작업 종료 뒤 임시 파일과 키체인이 삭제되는지 확인해야 합니다.

모든 macOS 작업이 자체 운영을 필요로 하지는 않습니다. 일반적인 린트, 단위 테스트, 공개 저장소 검증은 호스팅 Runner로 충분할 수 있습니다. 다음 조건이 있으면 자체 운영 원격 맥을 우선 검토할 수 있습니다.

• 특정 Xcode 버전을 계속 유지해야 하는 빌드
• 인증서와 프로비저닝 프로파일을 사용하는 서명
• 사내 패키지 저장소나 내부 API 접근
• 장시간 보관 파일 생성
• 고정된 시뮬레이터 상태가 필요한 테스트
• 여러 저장소가 같은 도구 캐시를 공유하는 작업

호스팅 Runner가 모든 사설망에 접근할 수 없다고 단정해서는 안 됩니다. GitHub는 일부 네트워크 접근 구성을 제공하며, 고정 주소 범위가 필요할 때는 별도 Runner 유형이나 자체 운영 방식을 검토하도록 안내합니다. (호스팅 Runner 네트워크 안내)

서명 자료를 자체 운영 노드에 오래 보관하면 작업은 편해지지만 키체인과 인증서가 장기간 남는 위험이 커집니다. 호스팅 환경은 격리성이 장점이지만, 비밀 값을 안전하게 주입하고 작업 종료 뒤 제거하는 절차가 필요합니다.

원격 맥을 GitHub Actions Runner로 사용할 때 어떤 숨은 비용을 계산해야 합니까?

다음 항목을 임대료와 별도로 기록해야 합니다.

• 사용하지 않는 시간의 노드 비용
• macOS 업데이트와 재부팅 확인
• Xcode 교체와 디스크 정리
• Runner 프로그램 업데이트
• 인증서와 키체인 교체
• 네트워크 단절 뒤 작업 복구
• 빌드 실패 원인 분석
• 노드 재설치와 재등록

실제 시험을 시작하기 전 CALMVPS 요금과 이용 기간을 확인하고, 임대 기간 동안 노드 점유 시간과 관리 기록을 따로 남겨야 합니다.

아래 조건을 순서대로 적용하면 단일 추천보다 정확한 결론을 얻을 수 있습니다.

• [ ] 빌드가 드물고 공개 저장소 중심입니까? 그렇다면 호스팅 Runner를 우선 선택합니다.
• [ ] 노드 업데이트와 장애 복구를 맡을 담당자가 없습니까? 그렇다면 자체 운영을 선택하지 않습니다.
• [ ] 동일한 Xcode와 의존성을 매일 반복 사용합니까? 그렇다면 자체 운영 원격 맥을 시험합니다.
• [ ] 코드 서명, 보관, 내부망 접근이 필수입니까? 그렇다면 해당 작업만 자체 운영 Runner로 분리합니다.
• [ ] 캐시를 적용한 뒤 대기 시간과 실행 시간이 실제로 줄었습니까? 그렇지 않다면 자체 운영의 비용 이점을 인정하지 않습니다.
• [ ] 여러 브랜치가 동시에 실행됩니까? 그렇다면 단일 노드의 대기열을 먼저 측정합니다.
• [ ] 재부팅, 단절, 작업 중단, 노드 재생성 시험을 통과했습니까? 통과하지 못했다면 호스팅 방식으로 되돌립니다.
• [ ] 자체 운영 비용에 유휴 시간과 관리 시간을 포함했습니까? 포함하지 않았다면 비교를 다시 계산합니다.

호스팅 Runner와 자체 운영 Runner를 한 워크플로에서 함께 사용할 수 있습니까?

가능합니다. GitHub Actions는 작업별 runs-on 값을 사용해 실행 위치를 정할 수 있습니다. 린트와 단위 테스트는 호스팅 Runner에서 실행하고, 서명과 보관 작업은 self-hosted와 별도 레이블을 가진 원격 맥으로 보낼 수 있습니다. (Runner 선택 기준)

권장 분리는 다음과 같습니다.

• 린트와 일반 단위 테스트: 호스팅 Runner
• 공개 저장소 검증: 호스팅 Runner
• 내부 의존성 테스트: 접근 정책을 검증한 자체 운영 Runner
• 코드 서명: 자체 운영 Runner
• 보관 파일 생성: 자체 운영 Runner
• 캐시 재사용이 중요한 장시간 빌드: 자체 운영 Runner

이 구조는 모든 작업을 한 번에 이전하지 않고도 통제권이 필요한 단계만 분리할 수 있다는 장점이 있습니다.

1. 최근 전체 청구 기간을 고정합니다

저장소별 작업 수, 실행 시간, 청구 시간, 실패율을 추출합니다. 성공한 작업만 고르지 말고 재시도와 취소 작업도 확인합니다.

2. 작업을 비용과 통제권으로 분류합니다

각 작업에 일반 검사, 단위 테스트, 서명 필요, 내부망 필요, 고정 Xcode 필요, 캐시 효과 큼, 동시 실행 필요라는 분류를 붙입니다.

3. 동일 조건으로 번갈아 실행합니다

같은 커밋과 같은 Xcode 버전으로 호스팅 Runner와 자체 운영 원격 맥을 실행합니다. 캐시를 켠 결과와 끈 결과를 분리해 기록합니다.

4. 돈과 시간을 함께 기록합니다

청구 시간, 실제 실행 시간, 대기 시간, 캐시 복원 시간, 실패 횟수, 수동 개입 시간, 노드 점유 시간을 한 기록에 남깁니다.

5. 서명 또는 보관 파이프라인 하나만 먼저 병행합니다

전체 이전부터 시작하지 마십시오. CALMVPS 원격 맥 주문 안내를 참고해 한 임대 기간 동안 서명이나 보관 작업만 병행하고, 비용과 복구 기록을 비교합니다. 결과가 안정적일 때 자체 운영 작업의 범위를 넓히는 편이 안전합니다.

현재 방식이 호스팅 Runner에만 의존하면 실행마다 환경을 다시 준비해야 하고, 고정 Xcode와 캐시를 세밀하게 통제하기 어렵습니다. 반대로 직접 구매한 맥은 초기 비용이 크고, 장비 교체와 장애 복구를 직접 맡아야 하며, 사용량이 줄어도 자산이 남습니다. 이런 단점을 피하면서 실제 운영성을 확인하려면 CALMVPS의 원격 맥을 한 임대 기간 동안 자체 운영 Runner로 연결해 서명 시간, 대기 시간, 관리 시간을 비교하는 방법이 적절합니다. CALMVPS 이용 시작 안내에서 시험 조건을 확인한 뒤 호스팅, 자체 운영 또는 혼합 구성을 결정하면 됩니다.

마지막 업데이트: 2026년 8월 15일. GitHub Actions Runner 요금과 운영 조건은 GitHub 공식 문서, Apple의 Xcode 시스템 요구 사항, CALMVPS의 현재 이용 안내를 기준으로 확인했습니다.