GitHub Actions macOS Runner는 어떻게 선택할까? 호스팅형과 자체 호스팅형 (2026)

GitHub Actions macOS Runner는 빌드가 드물고 표준 환경이면 호스팅형을 먼저 선택하고, 환경을 고정해 반복 사용하거나 실행을 직접 통제해야 할 때 자체 호스팅형을 검토하세요. 이번 주에는 워크플로 실행 기록과 실패 원인을 확인하고, 유지 관리에 쓸 수 있는 시간을 기준으로 선택하면 됩니다.

이 글은 가끔 iOS 빌드를 실행하며 Runner 운영을 줄이고 싶은 독립 개발자를 위한 안내입니다.
고정된 macOS 도구 체인이 필요하거나 자동 배포를 장기 운영하려는 개발자와 소규모 팀도 대상입니다.

이번 주에 확인할 빌드 작업량

선택 대상은 Mac을 어디에 둘지가 아니라 누가 Runner 환경을 관리하는가입니다. 자체 호스팅 Runner는 직접 관리하는 장비에서 실행할 수도 있고, 원격 Mac 환경에서 운영할 수도 있습니다. 따라서 자체 호스팅을 곧바로 “사무실에 Mac을 사서 설치하는 방식”으로 해석하지 마세요.

먼저 워크플로 실행 기록에서 빌드가 언제, 얼마나 자주 발생하는지 확인하세요. 동시에 실행되는 작업 수와 대기 상황도 살펴보세요. 공통으로 적용되는 대기 시간이나 성능 차이를 가정하지 말고, 네 저장소와 실행 시점의 실제 기록을 기준으로 판단해야 합니다.

GitHub 문서에 안내된 제한은 실제 용량 계획에 반영해야 합니다. 예를 들어 작업 실행 시간 한도는 6시간이며, 워크플로 실행 전체의 한도는 35일입니다. 매트릭스 작업은 최대 256개로 제한됩니다. 이 숫자만으로 네 작업이 적합한지 결론 내릴 수는 없지만, 장시간 빌드나 큰 병렬 작업을 설계할 때는 GitHub Actions 사용 제한과 워크플로 문법의 매트릭스 제한을 먼저 확인해야 합니다.

환경 제어와 운영 책임 비교

환경이 특별히 복잡하지 않다면 호스팅 Runner부터 시험하는 편이 단순합니다. 반대로 특정 Xcode, 도구 버전, 캐시 또는 시스템 설정을 장기간 반복해서 써야 한다면 자체 호스팅이 맞을 수 있습니다. 단, “한 번 설정하면 계속 안정적으로 작동한다”는 뜻은 아닙니다.

비용 비교는 월 지출 하나만 놓고 끝내지 마세요. 호스팅 방식은 실제 사용량과 해당 Runner 유형의 요금 조건을 확인하고, 자체 호스팅은 환경 사용료나 장비 비용에 업데이트와 장애 대응에 들어가는 시간을 더해야 합니다. 정확한 금액은 실행량, 선택한 환경, 계약 조건에 따라 달라지므로 확인하지 않은 가격을 기준으로 결론 내리지 마세요. GitHub가 제공하는 호스팅 Runner의 현재 유형과 사양도 선택 전에 확인하세요.

자체 호스팅의 유지 관리에는 Runner가 오프라인일 때 상태 확인, 운영체제 및 도구 업데이트, 디스크 공간 확보, 실행 실패 뒤 작업 복구가 포함됩니다. 특히 빌드 머신이 계속 켜져 있다는 사실은 업데이트나 장애 대응이 필요 없다는 보장이 아닙니다. GitHub의 자체 호스팅 Runner 안내와 모니터링 및 문제 해결 문서를 바탕으로 담당자와 복구 절차를 정하세요.

서명 정보와 작업 접근 경계

iOS 서명 인증서와 프로비저닝 정보는 단순한 빌드 파일이 아닙니다. 저장소 비밀 정보는 필요한 작업에만 제한적으로 전달하고, 작업이 접근할 수 있는 저장소와 네트워크 자원도 점검하세요. 자체 호스팅 환경은 작업 뒤 파일이 남는지, 다음 작업이 앞선 작업의 파일이나 자격 증명에 접근할 수 있는지 확인해야 합니다.

특히 외부 기여자가 제출한 변경을 처리하는 워크플로와 서명 또는 배포 비밀 정보를 같은 권한으로 실행하지 마세요. GitHub는 위험한 상황에서 pull_request_target을 안전하게 사용하는 방법을 별도로 설명합니다. 관련 워크플로를 운영한다면 pull_request_target 보안 지침을 검토하고, 자체 호스팅 Runner가 접근할 수 있는 저장소도 Runner 그룹 접근 설정 안내에 따라 제한하세요. 구체적인 격리 수준은 문서 설명뿐 아니라 네 Runner 설정과 실제 작업 구성으로 확인해야 합니다.

장면을 하나 들어 보겠습니다. 개인 앱에서 테스트 빌드는 자주 돌지만, 배포는 드물게 수동 승인 뒤 실행한다고 가정해 보세요. 두 작업을 같은 Runner와 같은 비밀 정보 권한으로 운영할 필요는 없습니다. 테스트를 호스팅 Runner에 남겨 두고, 환경 고정이 필요한 배포 작업만 별도 자체 호스팅 환경에서 검증하는 식으로 워크플로를 나눌 수 있습니다. 판단 기준은 “전체를 옮길 수 있는가”가 아니라 “어떤 작업이 고정 환경과 추가 운영을 실제로 필요로 하는가”입니다.

Runner 선택과 전환 순서

다음 조건으로 선택하세요.

• 빌드가 가끔 실행되고 제공되는 이미지로 충분하다면 GitHub 호스팅 Runner를 선택합니다. 운영할 머신을 추가하지 않고 워크플로부터 검증하세요.
• Xcode나 의존 도구의 구성을 고정해야 하고 환경을 직접 유지할 담당자가 있다면 자체 호스팅 Mac Runner를 검토합니다.
• 빌드가 반복되지만 운영 담당자가 없거나 장애 복구가 어렵다면 자체 호스팅으로 바로 전환하지 않습니다. 우선 호스팅 환경에서 실제 병목과 제약을 기록합니다.
• 서로 다른 작업의 요구가 다르면 전부 한쪽으로 옮기지 않습니다. 테스트, 패키징, 서명, 배포를 권한과 환경 요구에 맞춰 분리합니다.

실제 전환은 아래 순서로 진행하세요.

1. 현재 워크플로의 실행 빈도, 작업 시간, 병렬 실행 여부, 실패 원인을 기록합니다. 특정 기간의 기록만으로 일반적인 성능을 단정하지 말고 평소 작업 패턴과 비교합니다.
2. 필요한 macOS, Xcode, 의존 도구와 캐시 조건을 목록으로 만듭니다. 호스팅 Runner를 고려한다면 현재 레이블과 이미지가 요구 조건에 맞는지 Runner 선택 문서에서 확인합니다.
3. 자체 호스팅을 검토한다면 업데이트, 공간 정리, Runner 재시작, 작업 실패 대응을 누가 맡을지 정합니다. 담당자를 정할 수 없다면 운영 부담을 과소평가한 것입니다.
4. 서명과 배포 비밀 정보를 사용하지 않는 테스트 작업부터 새 Runner에서 실행합니다. 작업 결과뿐 아니라 도구 버전, 생성 파일, 접근 가능한 저장소와 네트워크도 확인합니다.
5. 테스트가 통과하고 권한과 정리 절차가 검증된 뒤에 서명 또는 배포 작업을 옮깁니다. 문제가 생기면 기존 경로로 되돌릴 수 있게 워크플로를 단계적으로 변경합니다.

자체 호스팅으로 옮길 때는 Runner 그룹과 저장소 접근 범위를 먼저 결정하세요. 워크플로에서 실행 대상과 작업 조건을 명시하는 방법은 GitHub Actions 워크플로 문법에서 확인할 수 있습니다. 레이블이나 사용 조건은 변경될 수 있으므로, 이전에 확인한 값을 그대로 전제하지 말고 전환 시점의 공식 문서를 다시 살펴보세요.

자주 묻는 선택 기준

개인 프로젝트라도 표준 환경과 낮은 운영 부담이 우선이면 호스팅 Runner로 시작하는 편이 합리적입니다. 반면 팀에서 같은 빌드 환경을 반복 재사용해야 하거나 로컬 Mac을 계속 켜 두기 어렵다면 원격 Mac 기반 자체 호스팅도 비교 대상이 됩니다. 그때는 원하는 macOS와 도구 체인, 연결 방식, 접근 권한을 먼저 확인하세요. 원격 Mac 환경 안내를 검토할 때도 실제 제공 조건이 워크플로 요구와 맞는지 확인해야 합니다.

보안 검토는 Runner 종류만으로 끝나지 않습니다. 어떤 작업이 비밀 정보에 접근하는지, 작업 후 파일을 어떻게 정리하는지, 누가 Runner를 등록하고 관리하는지를 함께 정하세요. 데이터 보호 관련 기준은 MangoVM 데이터 보호 안내에서 확인할 수 있지만, 저장소와 워크플로의 접근 권한은 네 설정에 맞춰 별도로 점검해야 합니다.

다음 빌드 환경 결정

호스팅 Runner는 시작과 유지 관리가 간편한 대신 제공 이미지와 사용 조건에 맞춰야 합니다. 자체 호스팅은 환경을 통제하고 반복 재사용할 여지가 있지만, 업데이트와 디스크 정리, 보안, 장애 복구까지 직접 책임져야 합니다. 낮은 빈도의 표준 빌드는 호스팅형부터, 고정 환경과 지속적인 재사용이 필요한 작업은 운영 시간을 포함한 비교 뒤 자체 호스팅형으로 결정하세요.

현재 빌드가 개인 Mac이나 다른 개발 환경에 묶여 있다면 전부 옮기기 전에 필요한 작업부터 나누세요. 로컬 장비는 물리적인 제어가 필요하거나 장기간 고정된 부하를 직접 관리하려는 경우 적합할 수 있습니다. 반면 장비를 계속 켜 두고 관리하는 부담이나 초기 구매를 피하고 싶은 상황이라면 원격 Mac 대여를 대안으로 비교할 수 있습니다. MangoVM을 검토한다면 먼저 필요한 macOS, 도구 체인, 지속 접속 조건이 맞는지 확인한 뒤 MangoVM 환경 안내에서 실제 이용 조건을 살펴보세요.

자주 묻는 질문