GitHub 공식 문서는 자체 호스팅 Runner가 호스트 컴퓨터에서 실행되며 GitHub Actions와 통신해야 한다고 안내합니다. Runner의 실행 및 통신 요건을 충족할 수 있을 때만 배포하세요.
증상 → 연구용 macOS 빌드가 필요하고 팀이 호스트를 관리할 수 있습니다. 빠른 해결 → 격리된 저장소에서 Runner 등록과 최소 작업을 검증한 뒤, 신뢰할 수 없는 PR 작업은 실행하지 마세요.
이 글은 macOS 연구 앱을 만드는 대학원생, 자체 도구가 필요한 연구 개발자, Runner의 권한과 유지 관리를 검토하는 실험실 담당자를 위한 절차 안내입니다.
배포 전에 실행 위치와 책임 범위를 결정합니다
GitHub Actions 자체 호스팅 macOS Runner 배포는 macOS에서만 가능한 빌드나 테스트가 필요하고, 팀이 호스트 업데이트와 접근 권한을 관리할 수 있을 때 적합합니다. GitHub에서 제공하는 호스팅 Runner로 요구 사항을 충족한다면 굳이 별도 호스트로 옮길 이유는 없습니다.
먼저 작업에 필요한 macOS 도구와 저장소 종류를 확인하세요. 인증 정보, 연구 데이터, 빌드 산출물이 호스트에 남는지도 목록에 넣습니다. 기관의 보안 승인 여부와 GitHub의 Runner 권한 설정은 서로 다른 점검 항목입니다. 공식 설정을 완료해도 기관 정책을 충족한다고 단정할 수 없습니다. 원격 호스트를 검토할 때는 원격 맥 환경과 이용 안내도 확인하되, 실제 데이터 처리와 기관 승인 조건은 별도로 점검하세요.
| 선택지 | 적합한 경우 | 주요 부담 | 판단 점수 |
|---|---|---|---|
| GitHub 호스팅 Runner | 제공 환경에서 빌드와 테스트가 가능함 | 필요한 도구나 실행 환경을 직접 통제하기 어려울 수 있음 | 높은 편 |
| 실험실 Mac의 자체 호스팅 Runner | 기기를 직접 관리하고 작업 범위를 제한할 수 있음 | 업데이트, 접근 통제, 정리 책임이 팀에 있음 | 조건부 |
| 원격 Mac의 자체 호스팅 Runner | macOS 환경이 필요하지만 팀에서 기기를 보유하지 않음 | 네트워크 통신, 계정 권한, 데이터 처리 조건 확인이 필요함 | 조건부 |
저장소를 격리하고 등록 정보를 준비합니다
원격 Mac에서 GitHub Actions macOS 작업을 실행할 수 있나요? 가능합니다. 다만 해당 Mac에 Runner를 설치하고 GitHub와 통신할 수 있어야 하며, 작업이 요구하는 도구와 권한도 준비되어야 합니다. 네트워크 연결만 확인한 상태와 실제 작업 성공은 구분하세요.
처음에는 별도의 테스트 저장소나 복구할 수 있는 프로젝트 사본을 사용하세요. 외부 기여자의 코드, 민감한 연구 데이터, 배포용 인증 정보가 들어간 워크플로를 그대로 가져오지 않습니다. 테스트 작업은 민감한 자료 없이 결과를 쉽게 확인할 수 있게 구성합니다.
GitHub의 기본 Runner 라벨은 운영체제, 아키텍처, self-hosted 정보로 제공됩니다. 워크플로는 지정한 라벨 조건에 맞는 Runner를 선택하므로, Runner 선택 문법과 실제 호스트 라벨을 대조하세요. 저장소에 연결할지 조직 범위로 관리할지도 미리 정해야 합니다. Runner 접근 범위 관리 안내를 보고 실제 작업을 실행할 저장소만 접근하도록 제한하세요.
| 확인 항목 | 준비할 내용 | 통과 조건 |
|---|---|---|
| 저장소 | 격리된 테스트 저장소 또는 복구 가능한 사본 | 외부 기여자 코드와 민감 데이터가 배제됨 |
| 호스트 | 지원되는 macOS 환경, 필요한 도구, 통신 경로 | 담당자가 환경과 접근 권한을 관리할 수 있음 |
| 권한 | 저장소 범위, 작업별 토큰 권한, 비밀 정보 | 최소 권한으로 시험 작업을 실행할 수 있음 |
| 정리 | 임시 파일, 캐시, 테스트 데이터 처리 방식 | 실행 뒤 잔여물을 확인하고 제거할 수 있음 |
Runner를 등록하고 재시작 동작을 확인합니다
GitHub Actions 자체 호스팅 Runner를 macOS 호스트에 어떻게 추가하나요? 저장소 또는 조직 설정에서 Runner 추가 절차를 시작하고, 화면에 표시되는 설정 파일과 등록 토큰을 사용해 호스트를 연결합니다. 공식 Runner 추가 단계를 현재 화면과 대조하고, 토큰은 저장소에 커밋하거나 로그에 남기지 마세요.
등록 때는 Runner 이름과 라벨을 실제 역할에 맞게 정합니다. macOS 작업만 받을 호스트라면 라벨을 작업 파일의 runs-on 조건과 일치시켜야 합니다. 여러 저장소에서 공유할 계획이라면 그 필요성부터 따져보세요. 공유 범위가 넓을수록 접근 검토와 실행 후 정리가 복잡해집니다.
| 설정 또는 작업 | 확인할 내용 | 남길 기록 |
|---|---|---|
| Runner 이름과 라벨 | 워크플로의 실행 조건과 정확히 맞는지 | 이름, 라벨, 연결 저장소 |
| 등록 범위 | 저장소 또는 조직 중 어느 범위인지 | 승인된 접근 범위와 담당자 |
| 자동 시작 | 호스트 재시작 뒤 서비스가 복구되는지 | 시작, 상태 확인, 제거 절차 |
| 등록 토큰 | 설정에만 사용하고 노출하지 않았는지 | 토큰 값이 아닌 발급 및 폐기 담당자 |
최소 작업을 실행하고 결과를 단계별로 검증합니다
자체 호스팅 macOS Runner에서 연구 프로젝트의 빌드와 테스트를 어떻게 확인하나요? 작은 워크플로부터 실행해 Runner 선택, 명령 실행 환경, 로그와 산출물을 차례로 점검하세요. Runner가 온라인으로 표시되는 것, 작업이 성공하는 것, 연구용 소프트웨어가 정상 동작하는 것, 결과를 연구자가 재검토하는 것은 각각 별도의 확인 단계입니다.
처음 실행할 워크플로에는 민감 데이터나 배포용 비밀 정보를 넣지 않습니다. 저장소의 워크플로 구문과 Runner 지정 방식에 맞춰 라벨을 지정하고, 실행 로그에서 실제 호스트와 명령 결과를 확인하세요. 이어서 프로젝트가 요구하는 도구를 실행하고 결과 파일을 연구자가 직접 검토합니다.
| 검증 단계 | 확인할 증거 | 실패하면 할 일 |
|---|---|---|
| 연결 | Runner가 온라인이며 작업을 수신함 | 통신 상태와 서비스 상태를 다시 점검함 |
| 작업 배정 | 지정 라벨과 Runner가 일치함 | 라벨과 runs-on 조건을 맞춤 |
| 실행 환경 | 필요한 명령과 도구가 예상대로 동작함 | 호스트 도구와 경로를 확인함 |
| 결과 검토 | 로그와 산출물을 연구자가 확인함 | 원인과 재현 조건을 기록하고 재실행함 |
| 종료 정리 | 임시 파일과 테스트 자료가 남지 않음 | 잔여물을 제거하고 정리 절차를 보완함 |
작업에 필요한 권한만 설정하고, GITHUB_TOKEN도 업무에 필요한 범위로 제한하세요. 토큰 인증 설정 안내를 확인해 토큰 권한을 정한 뒤, 실행이 끝났을 때 캐시와 임시 데이터가 정리되는지 시험합니다. 이 절차는 위험을 줄이는 운영 점검이지, 보안이나 기관 규정 준수를 보증하는 인증은 아닙니다.
운영 기준을 기록하고 도입 여부를 다시 판단합니다
운영을 시작한 뒤에는 macOS와 개발 도구, Runner 버전, 저장소 접근 권한이 바뀌었는지 주기적으로 확인하세요. 실패 로그와 작업 환경의 기준을 기록하고, 담당자가 바뀌어도 시작·상태 확인·제거 절차를 이어갈 수 있도록 인계 문서를 유지합니다. 연구 결과의 재현성은 CI 작업 성공만으로 판단하지 말고, 입력 자료와 실행 조건, 결과 검토 기록을 별도로 남겨야 합니다.
현재 실험실의 Linux나 Windows 환경을 계속 쓰는 방식은 기존 장비와 운영 절차를 활용할 수 있지만, macOS 전용 작업을 대신 실행할 수 없고 별도의 Mac이 없다면 테스트가 막힙니다. Mac을 직접 마련하면 관리와 유지에 드는 책임이 생기며, 원격 호스트도 데이터 접근과 네트워크 조건을 확인해야 합니다. 먼저 격리된 작업으로 필요성을 확인하고, 지속적인 macOS 환경이 필요한 경우에만 MACGPU의 원격 Mac 이용 안내에서 조건을 검토하세요. 상시 대량 작업이나 물리 장비 연결이 필요한 프로젝트, 기관 승인을 받지 못한 민감 데이터 작업에는 임대 Mac이 적합하지 않을 수 있습니다.