2026년 2월 5일 GitHub는 Runner Scale Set Client를 Public Preview로 공개했습니다(공식 변경 기록). 결론은 분명합니다. 시험할 가치는 있지만 기존 고정 맥 풀을 전부 바꾸면 안 됩니다. 맥 호스트를 자동으로 만들고, 작업 뒤 환경을 지우며, 로그를 외부에 남기고, 장애 때 고정 노드로 넘길 수 있을 때만 임시 빌드 작업부터 탄력형 풀에 넣는 편이 안전합니다.
이 글은 여러 저장소의 GitHub Actions 맥 Runner를 관리하는 플랫폼 팀을 위한 글입니다. 배포 피크의 대기열, 브랜치 간 잔여 파일, 서명 자격 증명, 고정 구매와 원격 맥 용량의 TCO를 함께 판단해야 한다면 계속 읽어 보시기 바랍니다.
마지막 업데이트: 2026년 9월 20일. 공개 변경 기록, 공식 문서와 actions/scaleset 저장소를 기준으로 확인했습니다. 이 기능은 여전히 Public Preview로 취급해야 하며, 이후 인터페이스와 예시는 공식 자료를 다시 확인해야 합니다(공식 저장소).
SECTION 01첫 번째 판단: 책임 경계
Runner Scale Set Client는 GitHub의 Scale Set API와 통신하고 작업을 받을 Runner를 준비하는 구성 요소입니다. 그러나 실제 맥을 생성하거나, macOS를 초기화하거나, Xcode를 준비하거나, 작업 뒤 디스크와 자격 증명을 지우지는 않습니다. 그 부분은 기업의 호스트 공급 자동화가 맡아야 합니다.
따라서 다음 조건 중 하나라도 충족하지 못하면 바로 전환하지 않는 것이 좋습니다.
- 맥 호스트 생성, 초기화, 회수, 삭제를 자동화할 수 없습니다.
- 작업 종료 뒤 소스, 캐시, 키체인, 로그를 검사할 방법이 없습니다.
- 서명 작업과 외부 기여자의 검증 작업이 같은 실행 환경을 공유합니다.
- Runner 장애 때 고정 맥 노드나 별도 원격 맥으로 넘길 경로가 없습니다.
- 팀이 GitHub App 권한, 토큰 교체, 로그 보관을 운영할 담당자를 정하지 않았습니다.
Runner Scale Set Client가 맥 빌드기를 직접 만들어 줍니까?
아닙니다. Client는 확장 신호와 Runner 등록 흐름을 연결하지만, 실제 Mac 공급과 수명 주기는 기업이 구현해야 합니다. 공식 저장소도 사용자 인프라에서 맥을 공급하는 구조를 전제로 설명합니다(Scale Set 확장 설명).
선택 기준
| 선택지 | 맞는 작업 | 필요한 운영 능력 | 먼저 확인할 위험 |
|---|---|---|---|
| 고정 맥 풀 | 생산 서명, 낮은 지연 시간이 필요한 작업 | 패치, 용량 계획, 장기 유지 | 유휴 용량과 잔여 환경 |
| 탄력형 Scale Set 풀 | 재현 가능한 PR 빌드, 피크성 검증 | 맥 자동 공급, 초기화, 회수, 외부 로그 | 콜드 스타트와 공급 실패 |
| 혼합 풀 | 검증은 탄력형, 서명과 긴급 배포는 전용 풀 | 라우팅 규칙과 장애 전환 | 잘못된 라벨 또는 권한 연결 |
SECTION 02용량 지표: 대기열을 노드 수로 바꾸지 않기
탄력 확장은 이벤트 하나가 올 때마다 맥 한 대를 추가하는 방식으로 설계하면 안 됩니다. 확인해야 할 값은 TotalAssignedJobs, 실행 중 작업, 대기 작업, 현재 공급 가능한 맥 수입니다. 이 값은 작업 도착률, 작업별 실행 시간, 초기화 시간과 함께 봐야 합니다.
예를 들어 대기 작업이 늘어도 작업이 곧 끝나는 상황이면 새 맥을 만드는 것보다 기존 노드의 회수나 라우팅 오류를 먼저 조사해야 합니다. 반대로 작업 도착이 짧은 시간에 몰리고 맥 초기화가 오래 걸리면, 완전한 주문형 생성만으로는 피크를 따라가지 못합니다.
너희 팀의 기록에는 다음 항목을 남겨야 합니다.
- 작업이 대기열에 들어온 시각
- 실제 Runner가 작업을 받은 시각
- 맥 호스트가 사용 가능한 상태가 된 시각
- 작업 종료와 호스트 회수 시각
- 공급 실패, 중복 전달, 재할당 횟수
- 작업 유형별 평균 실행 시간과 최대 실행 시간
이 기록으로 필요 노드 수 = 동시에 실행할 작업 수 + 초기화 중인 노드 수라는 운영 가설을 검증할 수 있습니다. 다만 실제 수량은 고정하지 말고, 저장소별 작업 도착 분포와 시작 지연 기록으로 조정해야 합니다.
GitHub Actions 탄력형 맥 Runner에 Kubernetes가 꼭 필요합니까?
아닙니다. Kubernetes는 하나의 자동화 선택지일 뿐입니다. 자체 호스트 공급기, 가상화 계층, 원격 맥 렌탈 API 또는 사내 오케스트레이터로도 맥 수명 주기를 관리할 수 있습니다. 중요한 것은 Kubernetes 사용 여부가 아니라 Client가 요청한 Runner와 실제 맥 호스트를 안정적으로 연결하는 공급 경계입니다(Runner Controller 문서).
탄력 운영의 장점과 한계
탄력형 풀의 장점은 피크 시간에만 맥 용량을 늘릴 수 있다는 점입니다. 여러 저장소가 동시에 검증을 시작해도 유휴 맥을 계속 보유하지 않아도 됩니다. 반면 공급 자동화가 느리거나 실패하면 대기열이 더 길어질 수 있습니다.
또한 작업이 끝났다고 호스트가 깨끗해지는 것은 아닙니다. 자동 로그아웃, 디스크 삭제, 키체인 제거, 캐시 정리는 별도 검증 항목입니다. 이 부분을 증명하지 못하면 탄력성보다 잔여 데이터 위험이 더 커집니다.
SECTION 03격리 지표: JIT Runner와 깨끗한 맥의 차이
JIT Runner는 한 번의 작업에 맞춰 Runner 등록 수명을 짧게 만드는 데 유용합니다. 하지만 Runner 등록이 사라졌다는 사실은 macOS 호스트가 새 상태가 되었다는 뜻이 아닙니다. 다음 네 수명을 분리해서 설계해야 합니다.
- Runner 등록 수명
- macOS 호스트 수명
- 작업 공간 수명
- 키체인과 서명 자격 증명 수명
JIT Runner만으로 Xcode 작업 공간과 서명 자격 증명을 격리할 수 있습니까?
그것만으로는 부족합니다. JIT Runner가 등록 해제된 뒤에도 소스, Derived Data, 패키지 캐시, 환경 변수, 키체인 항목이 호스트에 남을 수 있습니다. 생산 서명 작업은 신뢰할 수 없는 브랜치와 같은 탄력 실행 환경에 배치하지 말고, 전용 맥 또는 별도의 신뢰 경계에 두어야 합니다.
Runner 그룹과 저장소 접근 권한도 함께 제한해야 합니다. GitHub는 자체 호스팅 Runner의 접근 범위를 그룹 단위로 관리할 수 있도록 문서화하고 있습니다(Runner 그룹 접근 제어). 보안 검토에서는 다음을 확인해야 합니다.
- 외부 기여자 PR이 서명용 Runner 라벨을 선택할 수 없는가
- GitHub App 또는 토큰에 필요한 범위만 부여했는가
- 작업 종료 뒤 작업 공간과 임시 파일을 삭제하는가
- 키체인 잠금과 인증서 회수 상태를 확인하는가
- 삭제 전 진단 로그를 외부 저장소로 전송하는가
GitHub도 자체 호스팅 Runner에서 신뢰할 수 없는 작업을 실행할 때의 위험을 별도로 설명합니다(보안 사용 기준). JIT라는 이름만 보고 격리가 끝났다고 판단하면 안 됩니다.
SECTION 04시작 지표: 콜드 스타트의 실제 구성
맥 탄력 용량의 이득은 노드가 작업을 받을 때부터 계산해야 합니다. 다음 단계를 하나의 시작 시간으로 뭉뚱그리면 원인을 찾기 어렵습니다.
- 맥 호스트가 공급되는 단계
- macOS가 부팅되고 잠금 상태가 해제되는 단계
- Runner가 등록되는 단계
- Xcode와 필요한 SDK 상태를 확인하는 단계
- 첫 Job을 받아 작업을 시작하는 단계
Apple Silicon 맥을 사용하더라도 Xcode 버전, 패키지 의존성, 시뮬레이터 이미지, 인증서 준비 상태에 따라 시작 지연은 달라집니다. 이 글에서는 공개 자료만으로 특정 초 단위 성능이나 고정 비용을 단정하지 않습니다. 그런 값은 기업의 실행 기록 또는 실제 맥 공급자의 실측으로 확인해야 합니다.
운영 전략은 세 가지로 나눌 수 있습니다.
- 완전 주문형: 평소 비용은 줄일 수 있지만 첫 작업 지연과 공급 실패에 취약합니다.
- 최소 예열 용량: 피크가 아닌 시간에도 일부 맥을 유지해 응답성을 확보합니다.
- 고정 기본 풀과 탄력 풀의 혼합: 짧은 작업은 고정 풀에서 처리하고, 반복 가능한 피크 작업만 탄력 풀로 보냅니다.
여기서 Xcode 초기화나 의존성 다운로드 시간을 일반적인 숫자로 대신하지 마십시오. 너희 조직의 로그에 없는 성능 주장은 용량 계획을 왜곡합니다.
SECTION 05제어면 지표: 인증과 장애 회복
Scale Set Client의 운영 안정성은 프로세스가 살아 있는지보다 작업이 유실되지 않는지로 판단해야 합니다. 메시지 확인, 중복 전달, 작업 재할당, 노드 실종을 별도 상태로 기록해야 합니다. 인증 방식과 필요한 권한은 공식 인증 안내를 기준으로 검토해야 합니다(Scale Set 인증 안내).
장애 시나리오는 다음처럼 분리해 시험해야 합니다.
- Client 프로세스가 종료되는 경우
- 맥 공급이 실패하는 경우
- Runner가 등록된 뒤 연결을 잃는 경우
- 작업은 끝났지만 회수 요청이 실패하는 경우
- 로그 전송 전에 노드가 사라지는 경우
임시 맥에서 진단 로그를 로컬에만 남기면 노드 삭제와 함께 증거도 사라집니다. 삭제 전에 외부 저장소로 전송하고, 전송 확인이 없으면 회수 단계를 중단하는 방식이 필요합니다. GitHub의 모니터링 문서도 자체 호스팅 Runner의 상태와 문제 원인을 별도로 확인하도록 안내합니다(모니터링과 장애 대응).
GitHub REST API를 이용해 Runner 목록, 상태, 라벨을 주기적으로 대조하는 것도 도움이 됩니다. 다만 API 응답을 실제 맥의 청결 상태로 오해해서는 안 됩니다(자체 호스팅 Runner API).
SECTION 06TCO 지표: 고정 용량과 탄력 용량의 역할
기업의 Mac CI TCO는 임대료나 구매 가격만으로 계산하면 안 됩니다. 다음 변수를 같은 기간에 넣어야 합니다.
- 고정 맥의 구매 또는 임대 비용
- 예열 노드의 유지 비용
- 주문형 맥의 사용 시간 비용
- 공급 자동화와 유지 관리에 투입되는 인력
- 로그 저장과 모니터링 비용
- 서명 사고, 작업 재실행, 배포 지연으로 인한 손실
- 고장과 장애 때 사용할 예비 용량
고정 Mac Runner와 탄력형 Scale Set은 어떻게 나눠야 합니까?
PR 빌드와 재현 가능한 테스트는 탄력 풀의 우선 후보입니다. 시뮬레이터 회귀도 환경을 매번 다시 만들 수 있고 캐시 정책을 검증했다면 탄력 풀로 보낼 수 있습니다. 반면 생산 아카이브, App Store 배포, 장기 보관 키체인을 사용하는 서명 작업은 전용 또는 예열 맥에 두는 편이 안전합니다.
이 기준은 아래처럼 결정하면 됩니다.
- 작업이 외부 코드에 노출될 수 있고 서명이 필요하면 전용 맥으로 보냅니다.
- 작업이 재실행 가능하고 호스트를 완전히 재구성할 수 있으면 탄력 풀을 검토합니다.
- 시작 지연이 사용자 배포 일정에 직접 영향을 주면 예열 용량을 남깁니다.
- 회수와 로그 전송을 증명하지 못하면 고정 풀을 유지합니다.
- 대기열 데이터가 없으면 노드 수를 늘리기보다 먼저 관측을 구축합니다.
고정 구매는 장기적으로 일정한 부하와 물리 장치 접근이 필요한 조직에 맞습니다. 반면 원격 맥 탄력 용량은 피크, 단기 프로젝트, 여러 팀의 실험에 유리할 수 있습니다. MACNOX의 한국어 맥 이용 경로를 검토할 때도 호스트 전달 방식, 초기화 범위, 회수 절차와 장애 전환을 가격보다 먼저 확인해야 합니다. 비용 항목을 직접 비교하려면 MACNOX 요금 안내와 사내 작업량 기록을 함께 놓고 계산하십시오.
현재 고정 맥만 사용하는 방식은 유휴 용량을 계속 부담하고, 피크 때는 대기열이 생기며, 여러 팀이 같은 호스트를 재사용하면 잔여 파일과 인증 정보가 남을 수 있습니다. 반대로 탄력형 맥만 사용하면 콜드 스타트, 공급 실패, 서명 경계가 운영 리스크가 됩니다. 그래서 임시 PR 빌드부터 MACNOX의 실제 원격 맥 전달과 회수 방식을 검증하고, 생산 서명은 기존 전용 풀에 남기는 혼합 구성이 더 현실적인 출발점입니다.
첫 시험은 재구축 가능한 PR 작업 한 종류로 제한하십시오. 시작 지연, 작업 대기, 로그 보관, 호스트 회수, 장애 때 고정 풀 전환을 기록한 뒤 통과 기준을 정하십시오. 이 증거가 없으면 생산 서명 파이프라인을 탄력 풀로 옮기지 않는 것이 맞습니다.