GitHub Copilot cloud agent는 기본적으로 표준 호스팅 Runner를 사용합니다. 조직 관리자는 필요에 따라 Runner 그룹이나 라벨을 지정할 수 있습니다. 설정 가능한 항목과 저장소의 덮어쓰기 허용 여부는 GitHub의 cloud agent Runner 설정 문서에 따르세요.

모든 코드 작업에 Mac Runner가 필요한 것은 아닙니다. 코드 분석이나 일반적인 텍스트 수정은 기본 환경으로 충분할 수 있습니다. 반대로 Xcode, macOS 전용 도구, 사내 네트워크에서만 접근되는 의존성이 작업에 필요하다면 Mac 환경을 검토해야 합니다. 프로젝트에 Xcode가 필요하다는 이유만으로 Agent의 모든 작업이 반드시 Xcode를 실행한다고 가정하지 마세요.

먼저 다음 조건으로 선택하세요.

• 프로젝트 준비 단계가 macOS 전용 명령이나 Xcode 도구에 의존한다면, 해당 도구가 갖춰진 Mac Runner를 선택합니다. 준비 단계가 통제된 저장소에서 정상 실행되지 않으면 확대하지 말고 기본 호스팅 Runner로 되돌립니다.
• 필요한 의존성이 내부 네트워크에서만 제공된다면, 해당 접근을 허용해도 되는 저장소와 Runner 그룹을 먼저 확인합니다. 접근 범위를 최소화할 수 없다면 연결을 보류합니다.
• Agent가 코드 변경만 하고 Apple 플랫폼 빌드 검증은 별도 CI에서 수행한다면, Agent Runner와 Xcode CI Runner를 분리하는 방안을 검토합니다. 한 번의 Agent 실행이 전체 출시 검증을 대신한다고 간주하지 마세요.

설정 담당자가 조직의 Runner 정책을 바꿀 수 있는 권한을 보유하는지 확인하세요. 이어서 대상 저장소, 접근 가능한 Runner 그룹, 저장소가 조직 기본값을 덮어쓸 수 있는지 검토합니다. Runner 그룹 접근 정책은 그룹을 사용할 수 있는 저장소와 조직 범위를 정할 때 참고할 기준입니다.

호스트가 조직에서 접근 가능한 네트워크에 연결되어 있고, 작업을 받을 수 있도록 온라인 상태인지 확인합니다. Runner가 온라인으로 보인다는 사실만으로 저장소 접근이나 내부 의존성 연결까지 입증되지는 않습니다.

프로젝트 담당자에게 필요한 환경을 목록으로 받으세요. 예를 들면 Xcode와 명령줄 도구, 프로젝트 패키지, 사설 패키지 저장소, 내부 서비스 접근입니다. Mac의 운영체제와 아키텍처 지원 범위는 GitHub의 자체 호스팅 Runner 참고 문서에서 다시 확인하세요. 실제 호스트와 Runner 설정이 맞는지도 함께 검증해야 합니다.

조직 설정에서 cloud agent가 사용할 표준 호스팅 환경 또는 지정 Runner 그룹이나 라벨을 선택합니다. 저장소 준비 단계 워크플로가 다른 Runner를 가리키는 구성이 가능하더라도, 조직 정책에서 덮어쓰기를 막으면 그 설정은 적용되지 않을 수 있습니다. 먼저 조직의 기본 설정과 저장소별 허용 범위를 맞추세요.

일반 GitHub Actions 워크플로의 Runner 지정은 다음과 같은 형태를 취할 수 있습니다. 아래 값은 형식 설명을 위한 자리표시자이며, 실제 조직 이름이나 내부 라벨이 아닙니다.

runs-on: [self-hosted, macOS, ARM64, '<조직에서-정한-라벨>']

이 예시는 일반 워크플로가 라벨로 Runner를 선택하는 방식입니다. cloud agent의 조직 설정과 동일한 구성이라고 보면 안 됩니다. 실제 라벨은 등록한 호스트와 조직 설정에 맞추고, cloud agent가 그 그룹을 사용할 수 있는지 별도로 확인하세요. GitHub의 cloud agent Runner 설정 안내에서 조직 설정과 저장소 덮어쓰기 제어를 대조할 수 있습니다.

GitHub의 자체 호스팅 Runner 추가 절차에 따라 등록 범위를 정하고, 올바른 그룹과 라벨을 적용하세요. 등록 뒤에는 호스트가 온라인으로 표시되는지, 대상 저장소가 지정 그룹에 접근할 수 있는지, 필요한 네트워크 경로가 열려 있는지 각각 확인합니다.

Agent가 작업을 시작하기 전 필요한 도구와 프로젝트 의존성은 환경 설정 및 준비 단계에서 관리합니다. cloud agent 환경 사용자 지정 문서를 참고해 저장소에 필요한 설정을 구성하세요. 준비 단계는 작업 환경을 마련하는 역할입니다. 일반 GitHub Actions CI가 성공했다거나, Xcode Archive와 서명까지 검증됐다는 의미는 아닙니다.

여기서는 세 가지를 따로 확인해야 합니다.

• Runner가 등록되어 있고 대상 그룹에서 작업을 받을 수 있는지.
• Agent가 작업을 시작하기 전에 필요한 의존성이 준비되는지.
• 프로젝트에서 요구하는 Xcode 명령과 빌드가 별도 검증에서 통과하는지.

GitHub Copilot cloud agent가 자체 호스팅 Mac Runner를 사용할 수 있나요?
사용할 수 있습니다. 단, 조직 관리자가 Runner 그룹이나 라벨을 설정하고 대상 저장소에 접근을 허용해야 합니다. 러너가 등록됐다는 사실만으로 모든 저장소에 자동 공개되는 것은 아닙니다. 먼저 조직 설정과 그룹 접근 정책을 확인하고, 통제된 저장소에서 배정 결과를 검증하세요.

Agent가 작업을 시작하기 전에 macOS 의존성을 준비하려면 어떻게 하나요?
저장소의 Agent 환경 사용자 지정 및 준비 단계 설정에 프로젝트가 필요한 의존성 설치 절차를 구성합니다. 준비 단계가 Mac Runner에서 실행되는지 확인하고, 프로젝트별 명령과 내부 패키지 접근을 각각 시험하세요. 이 과정은 Agent 환경을 준비하는 절차이지, 일반 CI나 배포 검증 전체를 대신하지는 않습니다.

저장소 설정으로 조직의 Runner 유형을 바꿀 수 있나요?
가능 여부는 조직 관리자가 적용한 덮어쓰기 정책에 달려 있습니다. 저장소에 준비 단계 워크플로가 있다는 사실만으로 조직 기본값을 바꿀 수 있다고 단정하지 마세요. 통제된 저장소에서 설정을 적용한 뒤 실제 배정 Runner를 로그로 확인하고, 정책과 결과가 다르면 조직 설정을 우선 점검합니다.

Mac Runner를 열기 전에 어떤 보안 경계를 확인해야 하나요?
그룹을 사용할 수 있는 저장소, 작업에서 쓰는 토큰과 비밀값의 권한, 내부 네트워크 접근, 이전 작업의 파일 잔류 가능성을 점검합니다. 특히 공개 저장소나 신뢰할 수 없는 코드가 실행될 수 있는지 검토하세요. GitHub Actions 보안 사용 지침을 기준으로 위험을 검토하고, 접근 제한과 정리 절차를 시험하지 못했다면 연결 범위를 넓히지 마세요.

처음에는 비생산 또는 접근 범위가 제한된 저장소에서 작은 작업을 실행하세요. 코드 변경을 크게 맡기기보다, Agent가 실제로 필요한 파일을 읽고 프로젝트 명령을 실행할 수 있는지부터 확인하는 편이 실패 원인을 좁히기 쉽습니다.

실행 결과를 볼 때는 각 항목을 구분하세요.

• Runner 배정: 작업이 의도한 그룹과 라벨의 Mac에서 실행됐는지 확인합니다.
• 저장소 접근: 필요한 파일과 패키지 저장소에 접근했는지 확인합니다.
• 환경 준비: 의존성 설치 및 프로젝트 준비 명령이 예상대로 끝났는지 살펴봅니다.
• Xcode 검증: 프로젝트가 실제로 요구하는 빌드 또는 테스트 명령을 실행하고 로그를 보관합니다.
• 작업 정리: 임시 파일, 접근 토큰, 작업별 데이터가 다음 실행에 남지 않는지 확인합니다.

Runner가 온라인이었다는 결과, Agent가 코드를 수정했다는 결과, Xcode 빌드가 통과했다는 결과는 서로 다른 증거입니다. 각 결과를 별도로 기록하고, 실패하면 해당 단계의 로그와 재현 조건을 남기세요. Xcode CI가 별도 워크플로에 있다면 그 결과가 Agent 세션의 성공으로 합쳐지지 않도록 상태 보고도 분리합니다.

공개 저장소 또는 신뢰할 수 없는 코드가 같은 호스트를 사용할 가능성이 있다면 특히 보수적으로 판단하세요. GitHub는 자체 호스팅 Runner에서 신뢰 경계와 작업 권한을 주의해 다루도록 안내합니다. Actions 보안 사용 권고를 검토하고, 그룹 접근 제한과 작업 뒤 정리 방식이 실제로 작동하는지 시험한 다음 적용 범위를 결정하세요.

승인 기준: Runner 그룹을 사용할 저장소가 명확하고, 비밀값과 내부망 권한을 제한할 수 있으며, 작업 종료 뒤 정리 절차까지 검증됐다면 제한된 저장소부터 사용을 시작하세요. 접근 경계를 확인할 수 없거나 공개 저장소의 코드를 안전하게 분리할 수 없다면 기본 호스팅 Runner를 유지하거나 Mac Runner 연결을 보류하는 편이 낫습니다.

현재 Linux 기반 실행 환경만으로는 macOS 전용 도구를 실행할 수 없고, 기본 호스팅 환경에서 내부 의존성 접근이 허용되지 않을 수도 있습니다. 반면 Mac Runner를 직접 운영하면 접근 제어와 작업 흔적 제거를 팀이 책임져야 합니다. 자체 Mac을 아직 보유하지 않아 시험 환경만 필요하다면 맥 미니 대여 요금 안내와 한국에서 이용하는 맥 미니 안내를 확인해 원격 접속 방식과 이용 조건을 검토할 수 있습니다. 다만 장기간 지속되는 높은 부하나 물리 포트에 직접 연결해야 하는 작업은 자체 장비가 더 적합할 수 있습니다.

결론은 먼저 조직 정책으로 Runner 선택을 제한하고, 시험 저장소에서 Agent 환경과 Xcode 검증을 분리해 확인하는 것입니다. 검증할 Mac이 없다면 임시 클라우드 맥 환경을 비교하되, 지속 운영과 물리 연결이 필요한 팀은 자체 장비와 운영 책임까지 함께 따져보세요.