GitHub Actions Mac Runner 고정 아니면 탄력 확장? 2026년 방안

고정 Mac Runner를 유지할지 탄력 확장할지는 개발자 수가 아니라 작업의 시간대, 격리 수준, 도구 체인 유지 비용으로 결정해야 합니다. 평소 부하가 안정적이면 고정 노드를 남기고, 출시 피크와 여러 저장소 공유가 문제라면 임시 Runner를 추가하는 방식이 우선입니다. 대부분의 팀에는 고정 기반 노드와 탄력 풀을 함께 두는 이중 구성이 가장 현실적입니다.

이번 주 권장 순서: 먼저 최근 작업 기록에서 대기 시간, 노드 점유, 실패 원인을 분리해 확인합니다. 그다음 일상 작업과 출시 피크를 나누고, 서명 작업은 일반 테스트와 다른 노드 경계에 둡니다. 아래 판단은 2026년 9월 5일 기준으로 작성했으며, 공식 문서와 공식 저장소 상태를 기준으로 확인했습니다.

이 글을 읽어야 하는 팀

모바일 개발팀 리더는 출시 때 작업이 밀리지만 평소 Mac 노드가 놀고 있는 문제를 해결할 수 있습니다. DevOps와 플랫폼 엔지니어는 Runner 등록, 라우팅, 격리, 회수 흐름을 설계할 수 있습니다. 보안 및 배포 담당자는 인증서와 키체인을 임시 노드에 넣어도 되는지 판단할 수 있습니다.

먼저 나눠야 할 것은 일상 부하와 출시 피크입니다

작업 기록을 개발자 수의 대리 지표로 사용하면 안 됩니다. 확인해야 할 것은 다음 세 가지입니다.

• 작업이 대기열에 머문 시간
• Runner가 실제 작업을 수행한 시간과 유휴 시간
• 실패가 용량 부족인지, 엑스코드 버전·서명·네트워크 문제인지

일상 부하가 작고 안정적인데 출시 주간에만 대기열이 길다면 상시 노드를 늘리는 것은 비용 대비 효율이 낮을 수 있습니다. 반대로 빌드와 테스트가 매일 이어지고 도구 체인과 캐시를 다시 준비하는 시간이 크다면 고정 노드가 운영상 유리합니다.

GitHub의 자체 호스팅 Runner 참고 문서는 Runner가 조직 또는 저장소 작업을 실행하는 방식과 관리 경계를 설명합니다. 이 문서만으로 필요한 Mac 수를 계산할 수는 없으므로, 실제 작업 기록을 함께 봐야 합니다.

장면별 선택 조건

• 작업 출처가 제한되고 저장소 수가 적으며 도구 체인을 오래 보존해야 한다면 고정 Runner를 선택합니다.
• 출시와 대규모 병합이 특정 시간대에 반복되고, 평소에는 노드가 비어 있다면 임시 Runner를 선택합니다.
• 여러 저장소가 하나의 Mac 풀을 공유하지만 신뢰 수준이 다르면 저장소별 노드 풀을 나눕니다.
• 서명과 내부 네트워크가 필요한 배포 작업은 일반 테스트와 같은 Runner에 배치하지 않습니다.
• 탄력 제어면이나 Mac 공급 흐름이 아직 검증되지 않았다면 핵심 배포를 고정 기반 노드에 남깁니다.

고정 Runner가 맞는 운영 장면

고정 방식은 단순히 Mac을 계속 켜 두는 전략이 아닙니다. 저장소 접근 범위, 유지보수 시간, 장애 시 대체 경로까지 함께 관리해야 합니다.

고정 Runner가 특히 적합한 경우는 다음과 같습니다.

• 엑스코드와 패키지 도구의 버전 조합을 장기간 유지해야 하는 경우
• 빌드 캐시가 크거나 작업 시작 때마다 설치 시간이 발생하는 경우
• 서명 과정에 키체인, 인증서, 내부 패키지 저장소가 함께 필요한 경우
• 평소에도 작업량이 꾸준해 노드 유휴 시간이 짧은 경우

다만 장기 실행 노드는 이전 작업의 작업 공간, 캐시, 환경 변수, 로그인 상태를 남길 수 있습니다. 따라서 작업 완료 뒤 임시 디렉터리와 생성물을 정리하고, 저장소에서 Runner에 접근할 수 있는 범위를 제한해야 합니다. Runner Group 접근 권한 문서와 안전한 사용 안내를 함께 확인하는 편이 좋습니다.

고정 노드에도 예비 경로가 필요합니다. 기본 노드가 업데이트 실패나 디스크 문제로 멈췄을 때 중요한 배포만 처리할 별도 노드를 남기거나, 작업을 일시 중지하고 수동 승인을 거치는 기준을 미리 정해야 합니다.

출시 피크에는 임시 Runner가 더 합리적인 경우

출시와 집중 병합으로 짧은 시간에 작업이 몰리는 경우에는 세 가지 방식을 비교합니다.

• 상시 Runner를 추가합니다. 준비된 상태를 계속 유지할 수 있지만 피크가 끝난 뒤 유휴 자원이 남습니다.
• 임시 Runner를 미리 준비합니다. 출시 시작 전에 공급해 대기열을 줄일 수 있지만, 실제 준비 시간이 일정한지 확인해야 합니다.
• 대기열 신호에 따라 노드를 시작합니다. 평소 비용을 줄일 수 있지만 Mac 부팅, 도구 설치, Runner 등록 시간이 피크를 따라가지 못할 수 있습니다.

판단 기준은 단순한 작업 수가 아닙니다. 피크 작업의 종류, 허용 가능한 대기 시간, Mac 노드가 작업 가능 상태가 되는 시간, 작업 종료 뒤 회수 성공 여부를 함께 측정해야 합니다.

Runner 라벨 관리 문서에 따라 엑스코드 버전과 작업 종류를 라벨로 구분할 수 있습니다. 라벨만 추가한다고 격리가 완성되는 것은 아닙니다. 라벨을 잘못 붙이면 서명 작업이 일반 테스트 노드로 향할 수 있으므로, 허용 저장소와 그룹 범위를 함께 확인해야 합니다.

여러 저장소를 공유할 때는 노드 풀부터 분리합니다

조직 전체가 하나의 Mac 풀을 사용하면 비용은 관리하기 쉬워 보이지만, 실제로는 세 가지 문제가 생깁니다.

첫째, 신뢰 수준이 다른 저장소의 코드가 같은 호스트에 도착할 수 있습니다. 둘째, 저장소마다 요구하는 엑스코드 버전과 시뮬레이터 상태가 다를 수 있습니다. 셋째, 작업이 끝난 뒤에도 캐시와 인증 정보가 남을 수 있습니다.

따라서 다음과 같이 풀을 나누는 편이 안전합니다.

• 공개 코드와 내부 코드의 Runner Group을 분리합니다.
• 일반 빌드, 테스트, 서명 배포에 서로 다른 라우팅 라벨을 사용합니다.
• 저장소가 사용할 수 있는 그룹과 라벨의 범위를 최소화합니다.
• 작업 로그를 Mac 내부가 아닌 외부 저장 위치에도 남깁니다.
• 회수에 실패한 호스트는 자동으로 작업 대상에서 제외합니다.

임시 등록은 좋은 출발점이지만 완전한 삭제를 뜻하지 않습니다. ephemeral runner가 작업 뒤 등록을 해제하더라도 Mac 호스트 자체의 파일, 키체인, 캐시, 로그가 남아 있을 수 있습니다. 따라서 Runner 등록 해제와 호스트 초기화·삭제를 서로 다른 검증 단계로 다뤄야 합니다.

서명 작업은 일반 테스트와 다른 경계에 둡니다

Apple Silicon 기반 빌드 노드는 엑스코드와 최신 개발 도구를 사용하는 흐름에 적합할 수 있지만, 칩 종류만으로 서명 안전성이 결정되지는 않습니다. 실제 판단 대상은 키체인, 인증서, 프로비저닝 파일, 내부 의존성 저장소, 사설 네트워크입니다.

고정 노드는 복잡한 상태를 지속적으로 관리하기 쉽습니다. 대신 실행 가능한 저장소와 작업을 좁혀야 합니다. 임시 노드는 작업마다 인증 정보를 주입하고, 완료 뒤 폐기하거나 철회할 수 있어야 합니다. 이 과정이 자동화되지 않았다면 서명 작업을 탄력 풀로 보내지 않는 편이 낫습니다.

저장소 보안 정책과 자체 호스팅 환경을 검토할 때는 GitHub의 자체 호스팅 Runner 보안 지침을 기준으로 삼습니다. 일반 테스트는 임시 노드에서 처리하고, 서명과 최종 배포는 제한된 고정 노드에서 처리하는 이중 경계가 대부분의 팀에 적합합니다.

Runner Scale Set Client는 Mac 공급자가 아닙니다

2026년 9월 5일 기준으로 공식 Runner Scale Set Client 저장소는 macOS를 포함한 사용자 지정 탄력 Runner 구성에 사용할 수 있다고 설명하지만, 상태는 Public Preview입니다. 확인된 역할은 Runner Scale Set API와 연결하고 임시 설정을 생성하며 확장 신호를 전달하는 부분입니다.

반대로 다음 책임은 팀의 인프라에 남습니다.

• Mac 호스트의 생성 또는 임대
• 호스트의 시작과 네트워크 연결
• 필요한 엑스코드와 도구 체인 준비
• 작업 종료 뒤 Runner 등록 해제
• 호스트의 초기화와 삭제
• 시작 실패 및 회수 실패 처리

이를 컨테이너 기반 ARC의 방식과 혼동하면 안 됩니다. Actions Runner Controller 개념 문서는 Kubernetes Runner Pod 흐름을 설명하지만, 실제 Mac 호스트를 같은 방식으로 자동 공급한다는 의미는 아닙니다.

최소 검증 흐름

1. 대기열 증가 신호가 탄력 제어면에 도착하는지 확인합니다.
2. Mac 공급 계층이 요청을 받아 실제 노드를 준비하는지 확인합니다.
3. 노드가 정확한 그룹과 라벨로 한 작업만 등록하는지 확인합니다.
4. 작업 성공과 실패 뒤 Runner 등록이 해제되는지 확인합니다.
5. 호스트의 작업 공간, 캐시, 키체인, 임시 파일이 정리되는지 확인합니다.
6. 공급 실패, Runner 업데이트 실패, 외부 로그 누락 때 고정 기반 노드로 되돌아가는지 확인합니다.

Runner 모니터링과 장애 해결 문서는 상태 확인과 문제 분석의 기준을 제공합니다. 이 여섯 단계를 실제 작업 흐름으로 검증하지 않았다면 탄력 확장을 운영 기능으로 간주해서는 안 됩니다.

결정 도구: 조건을 확인해 운영 방식을 고릅니다

아래 항목은 회의에서 바로 사용할 수 있는 선택 목록입니다. 해당하는 항목을 확인한 뒤, 한쪽 조건만 충족하지 않고 여러 조건이 겹치는지 함께 봐야 합니다.

고정 Runner를 선택하는 조건

• [ ] 평소에도 빌드와 테스트 작업이 꾸준히 발생합니다.
• [ ] 엑스코드 버전, 캐시, 내부 의존성을 계속 유지해야 합니다.
• [ ] 키체인과 인증서 상태를 임시 노드에 안전하게 주입하고 회수할 수 없습니다.
• [ ] Mac 노드가 준비되는 시간보다 허용 가능한 작업 대기 시간이 짧습니다.
• [ ] 노드 장애 때 사용할 예비 고정 경로가 있습니다.

위 항목 중 세 가지 이상이 해당하면 고정 Runner를 기본으로 두는 편이 적합합니다. 다만 저장소가 여러 개라면 Runner Group과 라벨을 분리해야 합니다.

임시 Runner를 선택하는 조건

• [ ] 출시나 대규모 병합 때만 대기열이 뚜렷하게 증가합니다.
• [ ] 평소에는 기존 Mac 노드의 유휴 시간이 깁니다.
• [ ] 작업마다 도구 체인과 인증 정보를 반복해서 준비할 수 있습니다.
• [ ] 임시 Runner 등록 해제와 Mac 호스트 삭제를 별도로 검증했습니다.
• [ ] 공급 실패 때 고정 기반 노드로 되돌릴 수 있습니다.

위 항목 중 네 가지 이상이 해당하면 임시 Runner를 피크 대응 수단으로 검토할 수 있습니다. 단, 서명 작업이 포함되면 인증 정보의 주입과 철회가 자동화되었는지 먼저 확인해야 합니다.

이중 구성을 선택하는 조건

• [ ] 일상 작업과 출시 피크의 작업 특성이 서로 다릅니다.
• [ ] 일반 테스트는 격리된 임시 노드로 보낼 수 있습니다.
• [ ] 서명과 최종 배포를 제한된 고정 노드에 고정할 수 있습니다.
• [ ] 탄력 풀이 실패해도 핵심 배포를 계속할 수 있습니다.

이 조건을 충족하는 팀은 고정 기반 노드가 일상 작업과 핵심 배포를 담당하고, 탄력 풀이 출시 피크와 일반 테스트를 흡수하는 구성이 적합합니다. 이는 모든 노드를 한 번에 바꾸는 방식보다 실패 범위를 줄이고 검증 순서를 나누기 쉽습니다.

장애와 회수 실패를 전제로 운영합니다

탄력 제어면이 멈추거나 Mac 노드가 준비되지 않을 때 무한 재시도는 대기열과 비용을 함께 키울 수 있습니다. 따라서 최대 대기 시간을 정하고, 그 시간이 지나면 확장을 일시 중지하거나 고정 기반 노드로 작업을 보내야 합니다.

다음 상황에서는 자동 확장을 중단하고 수동으로 전환합니다.

• Mac 공급 요청이 반복해서 실패하는 경우
• Runner가 등록되지만 작업을 받지 못하는 경우
• 작업 종료 뒤 등록 해제와 호스트 삭제 결과가 일치하지 않는 경우
• 외부 로그가 남지 않아 작업과 인증 정보의 상태를 확인할 수 없는 경우
• 엑스코드 또는 서명 도구 업데이트 뒤 재현 테스트가 끝나지 않은 경우

현재 방식이 일반 클라우드 Linux 서버라면 macOS 전용 엑스코드와 서명 도구를 실행할 수 없다는 한계가 있습니다. Mac mini를 직접 운영하는 방식은 물리 장치와 지속적인 유지보수를 확보할 수 있지만, 초기 구매와 고정된 유휴 용량을 감수해야 합니다. 반면 JexMac의 원격 Mac 임대는 출시 기간이나 검증 단계처럼 필요한 기간에 실제 Mac 환경을 확보하는 대안이 될 수 있습니다. 다만 장기간 안정적인 고부하가 계속되거나 특정 물리 포트가 필요한 팀에는 직접 보유가 더 적합할 수 있으므로, 먼저 Mac 임대 기간과 이용 방식을 확인한 뒤 실제 작업 흐름으로 검증하는 편이 안전합니다.

자주 묻는 내용

FAQ는 위의 결정 조건과 별도로, 실제 도입 전에 확인해야 할 경계를 요약합니다.

GitHub Actions의 자체 호스팅 Mac Runner는 자동으로 탄력 확장할 수 있나요?

Runner Scale Set Client를 사용한 구성은 가능하지만, Mac 호스트의 공급과 회수까지 자동으로 해결하지는 않습니다. 대기열 신호, 노드 준비, 임시 등록, 작업 종료, 호스트 초기화와 삭제를 각각 검증해야 합니다. 공식 저장소가 Public Preview 상태인 점도 운영 승인 전에 고려해야 합니다.

엑스코드 지속적 통합에는 고정 Runner와 임시 Runner 중 무엇이 낫나요?

안정적인 일상 작업과 높은 도구 체인 준비 비용에는 고정 Runner가 맞습니다. 출시 피크와 강한 저장소 격리에는 임시 Runner가 유리합니다. 일반 테스트는 탄력 풀로 보내고, 서명과 핵심 배포는 접근 범위가 제한된 고정 노드에 남기는 이중 구성이 보통 더 안전합니다.

Runner Scale Set Client는 macOS 노드를 지원하나요?

공식 설명상 macOS를 포함한 사용자 지정 탄력 Runner 구성에 연결할 수 있습니다. 그러나 이 도구가 Mac을 만들거나 지우는 서비스는 아닙니다. 자체 공급 계층이 필요하며, 컨테이너용 ARC의 Pod 확장 방식을 실제 Mac 호스트 관리에 그대로 적용할 수 없습니다.

Mac Runner를 확장한 뒤 저장소끼리 작업 상태가 섞이지 않게 하려면 어떻게 하나요?

저장소 신뢰 수준, 엑스코드 버전, 작업 종류에 따라 Runner Group과 라우팅 라벨을 분리합니다. 작업 종료 뒤 등록 해제만 확인하지 말고 작업 공간, 캐시, 키체인, 임시 파일, 외부 로그를 함께 검사해야 합니다. 회수 실패 호스트를 다시 예약하지 않는 차단 절차도 필요합니다.

엑스코드 출시 피크에는 상시 노드를 늘릴까요, Mac을 임시로 빌릴까요?

피크가 반복되지만 평소 노드가 비어 있다면 임시 Mac을 추가하는 편이 비용 구조에 맞을 수 있습니다. 반대로 매일 배포하고 서명 상태가 복잡하면 고정 기반 노드가 낫습니다. 최근 작업 기록의 대기 시간과 실제 노드 준비 시간을 비교한 뒤 결정해야 하며, 결과가 불확실하면 이중 구성으로 시작합니다.

출시 피크 때문에 상시 노드를 늘리기 전에 일상 기준선과 급증 작업을 분리해 보시기 바랍니다. 고정 Mac Runner는 도구 체인과 서명 상태를 관리하기 쉽지만 유휴 비용과 장기 잔여 상태가 남고, 임시 Runner는 격리와 탄력성에 유리하지만 Mac 공급·초기화·회수 흐름을 직접 검증해야 합니다. 필요한 기간에만 Mac을 확보해 실제 파이프라인을 시험하려면 JexMac의 원격 Mac 이용 절차를 확인하고, 먼저 한 번의 출시 작업으로 대기·등록·서명·회수 결과를 검증하는 순서가 적절합니다.

자주 묻는 질문