2026년 6월 25일 GitHub는 macOS Runner를 Runner Groups에 포함해 관리하는 기능을 발표했습니다. 적용 계획은 Team 및 Enterprise이며, macOS Runner는 네트워크 구성을 지원하지 않는다고 안내했습니다. GitHub 공식 발표를 기준으로 보면, 먼저 신뢰 경계에 따라 그룹과 저장소 권한을 나누고 워크플로 라우팅을 설정해야 합니다. 대표 파이프라인을 검증하기 전에는 표준 Runner 레이블을 비활성화하지 마세요.
이 글은 GitHub 조직 또는 기업 관리자, macOS 작업을 Runner Group별로 보내려는 CI 플랫폼 엔지니어, 실행 환경의 접근 경계를 검토하는 기술·보안 책임자를 위한 내용입니다.
마지막 업데이트: 2026년 11월 4일. GitHub 공식 발표와 Actions 문서에서 계획 적용 범위, 접근 제어, 워크플로 구문 및 네트워크 제한을 확인했습니다.
구성 전에 확인할 Runner 유형과 계획
먼저 설정 대상이 GitHub-hosted macOS runners인지 자체 호스팅 Runner인지 구분하세요. Runner Group의 관리 단계와 사용 가능한 설정을 혼동하면 잘못된 권한 모델을 적용할 수 있습니다. 이 글의 절차는 GitHub가 공식 발표에서 다룬 GitHub-hosted macOS Runner에 초점을 둡니다.
기능 적용 계획은 Team 및 Enterprise로 발표됐지만, 실제로 보이는 설정과 선택 가능한 범위는 조직 계정과 현재 GitHub 관리 화면에서 다시 확인해야 합니다. Runner Group 접근 제어 문서와 계정 설정을 함께 확인하고, 화면에 나타나는 옵션을 현재 정책의 근거로 삼으세요.
구성 목표도 먼저 나누는 편이 안전합니다.
- 특정 저장소만 Runner를 사용하게 하려는 경우에는 그룹의 저장소 접근 정책을 확인합니다.
- 작업 종류에 따라 실행 대상을 고르려는 경우에는 워크플로의 Runner Group 라우팅을 확인합니다.
- 동시 실행량을 조정하려는 경우에는 계정에서 제공하는 그룹 설정과 지원 범위를 확인합니다.
- 네트워크 경로 또는 네트워크 격리가 필요하다면 Runner Group이 이를 해결한다고 가정하지 말고 별도 요구사항으로 검토합니다.
신뢰 경계에 맞춰 그룹과 저장소를 나누는 기준
그룹을 만들기 전에 저장소 소유 조직, 팀의 책임, 워크플로가 다루는 코드와 자격 증명을 기준으로 사용 범위를 정하세요. 목적이 다른 작업을 한 그룹에 몰아넣으면 저장소 권한만으로 충분히 관리되는 것처럼 오해하기 쉽습니다.
예를 들어, 공개 저장소의 외부 기여 작업과 비공개 저장소의 서명·배포 작업은 같은 접근 범위로 묶기 전에 각각 검토해야 합니다. 외부 기여 코드가 자격 증명을 다루는 작업과 같은 Runner 사용 권한을 가져도 되는지 확인하고, 필요하면 그룹 또는 워크플로 정책을 분리하세요. 이는 실제 권한 설정을 대신하는 보안 보장이 아니라, 설정 전에 팀이 결정해야 할 경계입니다.
각 그룹에 대해 용도, 소유 책임자, 허용할 저장소, 연결되는 워크플로를 기록해 두세요. 나중에 접근 허용과 거부 결과를 확인할 때 이 기록이 기대 동작의 기준이 됩니다.
Runner Group 생성과 저장소 접근 정책
GitHub Actions macOS Runner Groups 구성의 핵심은 그룹을 만든 뒤 사용할 저장소 범위를 명시하는 것입니다. 허용할 저장소를 정하고, 대표 저장소에서 실제 접근 결과를 확인한 다음에만 그룹을 배포하세요.
| 설정 항목 | 확인할 내용 | 운영상 의미 |
|---|---|---|
| 적용 범위 | 조직 또는 기업의 현재 관리 화면에서 지원되는 범위 | 계정에 없는 설정을 전제로 절차를 설계하지 않습니다. |
| 그룹 접근 | 허용할 저장소와 현재 접근 정책 | 그룹 사용 권한과 네트워크 격리는 서로 다른 통제입니다. |
| 실행 경로 | 워크플로가 참조하는 그룹 이름과 Runner 레이블 | 그룹 이름이나 레이블이 맞지 않으면 의도한 경로로 배정되지 않을 수 있습니다. |
| 동시 실행 | 계정에서 제공하는 그룹 수준 제어와 지원 범위 | 실제 빌드 수요를 바탕으로 조정하고, 고정 용량을 임의로 가정하지 않습니다. |
GitHub의 Runner Group 접근 제어 안내는 접근 설정의 기준으로 활용하되, 관리 화면의 실제 옵션과 계정별 이용 가능 여부를 함께 확인해야 합니다. 기본 그룹과 이미 사용 중인 Runner도 살펴보세요. 새 그룹을 만들었더라도 기존 실행 경로가 남아 있다면 다른 저장소나 작업이 계속 기존 Runner를 사용할 수 있습니다.
macOS 워크플로를 지정된 그룹으로 보내는 방법
그룹을 생성하고 접근 범위를 저장한 뒤에는 워크플로에서 그룹을 지정합니다. runs-on의 그룹 및 레이블 구문은 GitHub Actions 워크플로 구문 문서를 기준으로 확인하세요. 다음은 구문의 형태를 보여주는 예시입니다. 그룹 이름과 레이블은 실제 계정에서 지원되는 값으로 바꿔야 합니다.
jobs:
build:
runs-on:
group: macos-build-group
labels: 실제_지원_레이블
steps:
- name: 소스 가져오기
uses: actions/checkout@v4
Runner 레이블만 고르는 것과 그룹을 지정하는 것은 같은 설정이 아닙니다. 레이블은 실행 환경의 선택 조건에 쓰이고, 그룹은 접근 제어와 실행 경로를 관리하는 단위입니다. 다만 구체적인 동작은 현재 공식 구문과 계정 설정을 따라야 하므로, 예시를 그대로 복사해 적용하지 마세요.
| 확인할 대상 | 테스트 작업에서 볼 결과 | 실패 시 점검할 부분 |
|---|---|---|
| 허용 저장소 | 의도한 그룹의 Runner에서 작업이 시작되는지 | 저장소 권한, 그룹 이름, 레이블 |
| 비허용 저장소 | 그룹 접근이 허용되지 않는지 | 다른 그룹이나 기존 실행 경로가 남았는지 |
| 대상 워크플로 | 의도한 그룹으로 배정되는지 | runs-on 구문과 실제 그룹 이름 |
| 변경 영향 | 기존 작업이 계속 실행되는지 | 표준 레이블 의존성과 설정 변경 기록 |
대표 파이프라인 검증과 변경 기록
구성을 운영에 반영하기 전에 위험이 낮은 빌드 작업으로 그룹 라우팅을 확인하세요. 실제 배포 작업을 바로 바꾸기보다, 대표 저장소에서 허용되어야 하는 작업과 차단되어야 하는 작업을 각각 시험하는 편이 원인을 좁히기 쉽습니다.
Runner Group은 사용 권한을 나누는 설정이지 네트워크 격리 기능이 아닙니다. GitHub는 발표에서 macOS Runner의 네트워크 구성이 지원되지 않는다고 밝혔습니다. 네트워크 접근 제어가 요구사항이라면 그룹 설정만으로 해결됐다고 판단하지 마세요.
이때 다음 순서로 확인하면 설정 누락을 발견하기 쉽습니다.
- 조직 계획과 관리 화면에서 Runner Group 설정이 제공되는지 확인합니다.
- 그룹의 목적, 책임자, 허용 저장소를 문서로 정리합니다.
- 그룹을 만들고 허용 대상과 기존 Runner의 귀속을 확인합니다.
- 저위험 워크플로에 그룹 및 실제 지원 레이블을 지정합니다.
- 허용 대상과 비허용 대상에서 각각 작업 결과를 확인하고 기록합니다.
- 실패 시 되돌릴 설정과 변경 책임자를 변경 기록에 남깁니다.
설정 변경을 관리할 때는 조직의 Actions 제한 정책도 확인해야 합니다. GitHub 조직의 Actions 제한 설정 문서는 조직 수준에서 Actions를 제한하는 설정을 설명합니다. 그룹 라우팅 변경과 조직 전체 제한을 같은 변경으로 취급하지 말고, 각각의 영향을 별도로 검증하세요. 더 큰 Runner에 관한 관리 항목은 GitHub의 Runner 관리 문서에서도 확인할 수 있습니다.
표준 Runner 레이블 변경과 네트워크 요구사항
표준 GitHub-hosted Runner 레이블을 계속 사용할지 여부는 마이그레이션 이후에 판단하세요. 기존 레이블을 참조하는 저장소와 워크플로를 먼저 찾아야 합니다. 확인 없이 비활성화하면 작업이 시작되지 않거나 예상하지 못한 실행 경로를 탈 수 있습니다. 설정을 바꿀 때는 현재 관리 화면에서 제공하는 범위와 되돌리는 방법을 확인하고, 변경 후 같은 대표 작업을 다시 실행하세요.
다음 조건으로 선택하면 변경 순서를 정하기 쉽습니다.
- 허용·비허용 저장소 검증과 대표 워크플로 검증을 모두 마쳤다면: 표준 레이블 의존성을 목록화하고, 영향받는 작업을 확인한 뒤 제한 변경을 검토합니다.
- 그룹 라우팅이나 접근 거부가 기대대로 동작하지 않는다면: 표준 레이블을 유지하고 권한, 그룹 이름, 레이블 구성을 다시 점검합니다.
- 필요한 것이 저장소별 접근 제어라면: Runner Group 권한 설정을 사용하고, 대표 저장소에서 결과를 확인합니다.
- 필요한 것이 네트워크 구성 또는 네트워크 격리라면: Runner Group으로 해결하려 하지 말고 요구사항에 맞는 실행 환경을 별도로 평가합니다.
조직 정책을 결정할 때는 접근 통제와 데이터 취급 기준도 함께 살펴보세요. VPSMerge의 데이터 개인정보 안내와 도움말은 별도 실행 환경을 검토할 때 확인할 참고 자료입니다.
실행 환경의 공백과 다음 검토 단계
GitHub-hosted macOS runners의 그룹 설정은 저장소 접근과 워크플로 경로를 정리하는 데 유용하지만, 발표된 macOS 네트워크 구성 한계를 없애지는 않습니다. 또한 계정에서 제공되는 설정 범위와 조직의 워크플로 의존성에 따라 관리 선택지가 달라질 수 있습니다. 네트워크 설정이 필요한 작업, 독립된 실행 환경이 필요한 작업, 기존 표준 레이블을 계속 써야 하는 작업을 분리해 어떤 요구가 현재 방식으로 충족되지 않는지 먼저 기록하세요.
현재 Runner를 유지하는 방식은 별도 환경 운영 부담이 적을 수 있지만, 지원되는 기능과 계정 정책에 제약을 받습니다. 반대로 원격 Mac은 실제 Mac 실행 환경을 별도로 마련하는 선택지이지만, GitHub와의 연동 가능성이나 보안 요구 충족을 자동으로 보장하지 않습니다. 그런 기능을 전제로 하지 말고 팀의 워크플로, 접근 방식, 데이터 정책을 기준으로 검증해야 합니다.
현재 Runner의 기능 경계가 필요한 작업과 맞지 않는다면, 임시 또는 별도 macOS 실행 환경으로 원격 Mac을 비교 검토할 수 있습니다. 다만 장기적으로 안정된 고정 부하를 직접 관리하거나 물리 인터페이스가 필요한 팀에는 임대가 적합하지 않을 수 있습니다. 실제 제공 정보와 조건은 VPSMerge의 한국 원격 Mac 안내에서 확인하고, GitHub Actions와의 연동은 별도로 검증하세요.