빌드 대기열은 늘어나는데 새 Mac 노드가 자동으로 생기지 않고, 등록된 Runner만 계속 바빠지고 있습니까?
이번 주에는 Runner Scale Set Client를 바로 운영에 넣지 말고, Mac 노드를 자동으로 만들고 회수하며 외부 로그까지 남길 수 있을 때만 제한적으로 시험하십시오. 그 기능이 없다면 고정 Runner 풀을 유지하면서 예열 노드와 수동 확장을 함께 운영하는 편이 안전합니다.
이 글을 읽어야 하는 팀
여러 GitHub Actions Mac Runner를 관리하면서 빌드 대기열에 따라 노드 수를 바꾸려는 DevOps 엔지니어를 위한 글입니다. 서명 작업을 분리하고 서로 다른 작업 흐름이 같은 작업 공간을 재사용하지 않게 하려는 모바일 개발 플랫폼 팀에도 해당합니다.
고정 원격 Mac 노드, 예열 풀, 작업마다 만드는 임시 노드 중 어떤 구성이 맞는지 비교하는 씨아이 인프라 책임자라면 아래 지표를 기준으로 판단할 수 있습니다.
마지막 업데이트: 2026년 9월 6일. 상태와 기능은 공식 저장소의 공개 시험 상태, 공식 Runner Scale Set 개념 문서, 관련 API 문서를 기준으로 확인했습니다.
Scale Set Client와 Mac 공급 계층의 경계
Runner Scale Set Client는 확장 축소 신호를 받고 Scale Set API를 조정하며, 작업에 사용할 JIT 설정을 준비하는 구성 요소입니다. 이것만 설치한다고 실제 Mac이 생성되거나 Xcode 환경이 준비되지는 않습니다. 공식 저장소도 Mac 노드의 공급과 수명 주기를 사용자가 구현하는 구조로 설명합니다. Client 작업 흐름 설명을 먼저 확인해야 하는 이유입니다.
따라서 다음 항목을 자동으로 증명할 수 없다면 “자동 확장”이라고 부르면 안 됩니다.
- 요청을 받아 새 Mac을 신청하는 과정
- 운영체제와 개발 도구를 준비하는 과정
- Runner 등록과 작업 수락 과정
- 작업 완료 뒤 노드를 격리하고 폐기하는 과정
- 실패한 공급 요청을 되돌리고 원인을 남기는 과정
특히 Kubernetes가 없어도 Client를 사용할 수 있는지는 별도 문제입니다. 핵심은 Kubernetes의 유무가 아니라, 외부 플랫폼이 Mac의 생성·초기화·회수 API를 제공하느냐입니다. Kubernetes 없이도 자체 가상화 계층, 데이터센터 자동화 도구 또는 원격 Mac 임대 자원을 연결할 수 있지만, 그 연결 계층은 팀이 직접 검증해야 합니다. 공급 자동화가 없다면 고정 풀 조정으로 목표를 낮추는 것이 정확합니다.
배포 선택지별 판단표
| 선택지 | 노드 방식 | 격리 수준 | 대기 시간의 특징 | 적합한 단계 | 주요 위험 |
|---|---|---|---|---|---|
| 고정 Runner | 오래 켜 둔 Mac | 낮음에서 보통 | 이미 준비된 노드는 빠름 | 일정한 부하와 소수 노드 | 작업 공간과 비밀 정보 잔류 |
| 예열 임시 노드 | 준비된 Mac을 최소 풀로 유지 | 보통에서 높음 | 공급 시간을 일부 흡수 | 변동 부하와 초기 시험 | 유휴 자원과 관리 비용 |
| 작업별 임시 노드 | 작업마다 만들고 폐기 | 높음 | 첫 작업은 공급과 초기화가 필요 | 서명 분리와 민감 작업 | 환경 재현 실패와 공급 장애 |
Mac Runner가 대기열에 따라 자동으로 늘어나려면 Client의 신호뿐 아니라 실제 노드 공급 결과가 필요합니다. 고정 Runner는 운영이 단순하지만 작업 흔적이 남기 쉽습니다. 반대로 작업별 임시 노드는 격리에 유리하지만 Xcode, 시뮬레이터 런타임, 의존성, 인증서를 매번 복구해야 합니다.
일반 개발 빌드는 예열 풀에서 시험할 수 있습니다. 서명과 배포 작업은 별도 노드 풀과 별도 권한으로 분리하십시오. 공개 저장소 작업, 신뢰하지 않는 변경 요청, 배포 서명 작업을 같은 수락 풀에 넣으면 노드가 작업을 받을 수 있다는 사실만으로 보안 승인이 끝났다고 볼 수 없습니다.
수명 주기와 JIT 경계
장기 온라인 Runner는 관리가 쉽지만 이전 작업의 작업 공간, 캐시, 임시 파일과 비밀 정보가 남을 수 있습니다. 단일 작업용 임시 Runner는 작업 뒤 폐기를 전제로 하므로 격리에는 유리합니다. 예열 임시 노드는 이 둘의 중간 지점이지만, 대기 중인 노드의 상태를 계속 점검해야 합니다.
JIT Runner는 설정 발급, 작업 수행, 등록 해제와 폐기의 경계가 분명해야 합니다. 임시 자체 호스팅 Runner의 수명 주기 권고는 임시 Runner 사용을 권장하는 상황을 설명하며, 보안 사용 지침은 신뢰하지 않는 작업이 자체 호스팅 환경에서 실행될 때의 위험을 다룹니다.
JIT 설정은 로그, 셸 기록, 오류 출력에 그대로 남기지 마십시오. 조직 식별자, 저장소 식별자, 앱 식별자, 토큰, 노드 이름과 경로는 자동화 문서에서도 자리표시자로 관리해야 합니다. 조직용 JIT 설정을 만드는 API의 요청과 응답 형식은 공식 REST API 문서에 맞춰 확인하십시오.
대기열과 냉시작 시간의 분해
전체 작업 시간이 늘었다는 사실만으로 확장 방식이 실패했다고 판단하면 안 됩니다. 다음 흐름을 별도로 기록해야 합니다.
- 작업이 대기열에 들어간 시각
- Mac 노드 공급 요청을 보낸 시각
- 노드가 접속 가능한 상태가 된 시각
- Xcode와 프로젝트 환경을 준비한 시각
- Runner가 등록되어 작업을 받은 시각
- 작업 종료와 노드 회수 결과가 확정된 시각
이 기록이 없으면 순수 JIT 방식이 실제로 느린지, 단지 환경 초기화가 느린지 구분할 수 없습니다. 반대로 예열 풀은 첫 작업을 빠르게 받을 수 있지만 사용하지 않는 노드가 생깁니다. 고정 노드는 공급 실패가 적지만, 피크 시간에 대기열을 흡수하려면 수동 확장이 필요합니다.
공통적인 대기 시간 기준을 임의로 정하지 마십시오. 팀의 실제 작업 대기 기록과 노드 이용 기록을 놓고 순수 JIT, 최소 예열 풀, 고정 풀을 비교해야 합니다. 이 글에서는 검증되지 않은 성능 수치나 비용 수치를 제시하지 않습니다.
Xcode 환경의 재현성
JIT Runner가 등록에 성공해도 실제 빌드가 실행된다는 뜻은 아닙니다. Xcode 버전, 시뮬레이터 런타임, 패키지 의존성, 빌드 캐시, 인증서와 프로비저닝 자산을 새 노드에서 복구할 수 있어야 합니다.
다음 순서로 재현성을 확인하십시오.
- 아무 캐시도 없는 새 Mac 노드에서 실제 개발 빌드를 실행합니다.
- 같은 구성에서 캐시가 있는 두 번째 빌드를 실행합니다.
- 노드를 폐기한 뒤 새 노드에서 같은 입력을 다시 실행합니다.
- 세 결과에서 빌드 도구 버전, 의존성 잠금 상태, 서명 자산 식별자와 실패 로그를 비교합니다.
- 시뮬레이터가 필요한 작업은 런타임 설치와 부팅 상태를 별도로 기록합니다.
이 검증에서 실패하면 Runner Scale Set Client를 고치는 것이 아니라 Mac 이미지와 초기화 자동화를 고쳐야 합니다. Client는 macOS 이미지 제작, 그래픽 세션 준비, Xcode 설치, 서명 환경 초기화를 자동으로 해결하지 않습니다.
원격 Mac 기반의 Xcode 빌드 환경 자동 복구 절차를 먼저 정리하고, 고정 노드에서 성공한 명령을 임시 노드 초기화 단계로 옮기는 방식이 안전합니다. 초기화 스크립트에는 비밀 값을 넣지 말고 외부 비밀 저장소에서 작업 시점에 주입하십시오.
권한과 외부 로그
인증 방식은 편의성보다 회전 책임과 실패 범위를 먼저 비교해야 합니다. GitHub App을 사용하면 조직 단위 권한과 설치 범위를 검토할 수 있지만, 앱 자격 증명의 발급·교체·폐기 절차가 필요합니다. 개인 접근 토큰은 담당자 계정과 연결된 범위가 커질 수 있으므로 장기 운영의 기본값으로 두지 않는 편이 좋습니다.
실제 요청에 사용할 권한은 자체 호스팅 Runner 인증 문서의 현재 요구 사항과 대조하십시오. 문서의 권한을 그대로 넓게 부여하지 말고 조직, 저장소, Runner 그룹별로 필요한 범위를 줄여야 합니다.
노드 안의 로그만 남기는 구성은 폐기 뒤 조사할 수 없습니다. 다음 로그를 노드 밖으로 전송하십시오.
- 공급 요청과 응답 상태
- 노드 초기화 단계별 결과
- Runner 등록과 작업 수락 기록
- 빌드 실패의 명령, 종료 상태와 환경 식별자
- 노드 폐기와 회수 실패 기록
토큰과 인증서 내용은 저장하지 말고 자리표시자로 치환하십시오. 노드가 사라진 뒤에도 작업 식별자와 초기화 버전을 연결할 수 있어야 실패한 빌드를 재현할 수 있습니다.
비용과 운영 부담의 합산
탄력 확장이 항상 더 저렴한 것은 아닙니다. 비교 대상에는 Mac 임대 기간, 예열 노드의 유휴 시간, 환경 준비 작업, 실패한 노드의 재생성, 외부 로그 저장, 인증 자산 관리와 담당자 운영 시간이 포함되어야 합니다. 단순히 실제 빌드가 실행된 시간만 비교하면 결론이 왜곡됩니다.
원격 Mac 요금과 사용 방식을 검토할 때도 표시 가격만으로 판단하지 말고, 노드가 준비되지 않아 대기한 시간과 폐기 후 재구성에 필요한 작업을 함께 기록하십시오. 실제 기록이 없는 상태에서 “탄력 방식이 고정 방식보다 싸다”고 단정하면 안 됩니다.
Mac CI 노드 운영 점검 자료와 연결해 다음 증거를 모으십시오.
- 대기열이 생긴 작업의 수와 발생 시간대
- 노드가 실제로 작업을 수행한 시간
- 예열 상태로 남은 시간
- 초기화 실패와 재생성 횟수
- 폐기 뒤 로그 복구 성공 여부
- 담당자가 수동으로 개입한 단계
이번 주 실행 시간표
첫째 날부터 둘째 날까지: 현재 고정 Mac Runner의 작업 공간 잔류, 인증서 노출 가능성, 로그 보존 상태를 점검합니다. 공개 작업과 서명 작업이 같은 풀을 사용하는지도 확인합니다.
셋째 날부터 넷째 날까지: 버릴 수 있는 원격 Mac 노드 한 대를 준비합니다. 공급, 초기화, JIT 등록, 실제 빌드, 자동 해제, 로그 전송, 노드 재생성을 한 번씩 기록합니다.
다섯째 날부터 여섯째 날까지: 새 노드의 첫 빌드와 캐시 빌드, 폐기 뒤 재생성 빌드를 비교합니다. 대기열, 공급, 환경 준비, Runner 등록을 각각 측정합니다.
일곱째 날: 아래 세 가지 중 하나를 결정합니다.
- Mac 노드 자동 공급과 회수, 외부 로그가 모두 검증되면 비공개 개발 빌드만 제한적으로 시험합니다.
- 부하 변동은 있지만 자동화가 덜 갖춰졌다면 고정 풀과 예열 노드를 함께 운영합니다.
- 작업량이 안정적이거나 노드 수가 적다면 고정 Runner를 유지하고 확장을 보류합니다.
현재 방식과 VMSPIN 원격 Mac의 선택
현재 고정 Mac 방식은 작업이 끝난 뒤 작업 공간과 캐시가 남을 수 있고, 피크 대기열에는 수동 확장이 필요하며, 장기간 켜 둔 노드의 인증 자산과 로그 관리 부담도 커집니다. 반대로 직접 장비를 늘리면 사용량이 낮은 기간에도 하드웨어와 유지 관리 비용을 부담해야 합니다.
시험용으로 독립적으로 다시 만들 수 있는 Mac 노드가 필요하다면 VMSPIN의 원격 Mac을 활용해 비배포 작업 흐름부터 검증하는 방법이 있습니다. SSH, VNC 또는 웹 제어 방식으로 접속할 수 있는 환경에서 공급과 초기화, 단일 작업 회수, 로그 보존을 확인한 뒤 노드 풀 확대 여부를 결정하십시오. 장기간 일정한 고강도 부하가 계속되거나 물리 장비와 직접 연결해야 한다면 직접 구매 또는 전용 운영이 더 적합할 수 있습니다.
이번 주에는 서명 작업을 제외한 테스트 작업으로 시작하고, 노드가 실제로 재생성되는지와 폐기 뒤에도 실패 원인을 찾을 수 있는지를 확인하십시오. 그 증거가 확보된 경우에만 Runner Scale Set Client의 시험 범위를 넓히는 것이 안전합니다.