2026 GitHub Actions Mac Runner에서 외부 PR을 어떻게 격리하나요?

외부 기여자의 코드가 장기 실행형 맥 러너에 들어올 때 무엇을 차단하고 확인해야 하는지 안내합니다. 코드 출처와 러너 그룹, 비밀값, 작업 후 정리, 노드 복구를 점검하고 통과하지 못했을 때의 분기 기준을 제공합니다.

외부 PR을 돌린 뒤 맥 러너에 작업 파일과 실행 중인 프로세스가 남아 있습니까?

가장 빠른 해결: 신뢰할 수 없는 PR을 민감한 비밀값이나 이전 작업 상태가 남은 장기 자체 관리 맥 러너에 직접 보내지 마세요. PR 검증과 서명·배포를 분리하고, 러너 그룹 접근 범위와 작업 후 정리를 실제로 시험해야 합니다.

이 글이 필요한 독자

• 오픈 소스 유지 관리자: 외부 기여자 PR이 자체 관리 러너에 접근하는 방식을 결정해야 합니다.
• iOS 보안 담당자: 테스트 빌드와 서명·배포 작업을 나누려 합니다.
• 플랫폼 엔지니어: 러너 그룹, 노드 정리, 실행 기록을 관리합니다.

코드 출처와 실행 경계

GitHub Actions는 이벤트에 따라 어떤 워크플로가 실행되는지가 달라집니다. 외부 기여자의 PR, 조직 내부 PR, 신뢰된 브랜치의 푸시를 같은 신뢰 수준으로 취급하면 안 됩니다. 러너는 YAML에 적힌 의도만 처리하는 것이 아니라, 선택된 워크플로와 그 안에서 호출되는 작업을 실제로 실행합니다. 이벤트별 워크플로 실행 조건을 먼저 대조하세요.

특히 pull_request_target은 이벤트를 처리하는 워크플로의 신뢰 경계가 일반적인 PR 실행과 다를 수 있습니다. GitHub는 이 이벤트를 안전하게 쓰는 별도 지침에서 신뢰되지 않은 PR 코드를 권한이 있는 맥락에서 실행하지 말라고 경고합니다. 안전한 pull_request_target 사용 지침에 따라 체크아웃 단계와 스크립트 실행을 따로 검토하세요.

러너 그룹과 저장소 접근

자체 관리 러너 보안은 워크플로의 runs-on 값만으로 결정되지 않습니다. 조직 또는 저장소 설정에서 러너 그룹에 어떤 저장소가 접근할 수 있는지 확인해야 합니다. 러너 그룹 접근 제어 문서는 그룹별 허용 범위를 지정하는 방법을 설명합니다.

레이블은 적절한 러너를 찾기 위한 라우팅 정보입니다. 레이블이 지정된 러너만 선택하게 했다고 해서 권한이 제한되는 것은 아닙니다. 러너 그룹의 개념과 접근 범위는 러너 그룹 설명에서도 확인할 수 있습니다.

이 점검은 GitHub Actions 자체 관리 러너 보안의 기본 경계입니다. 허용 저장소가 불필요하게 넓거나 신뢰되지 않은 워크플로가 그룹에 접근할 수 있다면, 레이블을 바꾸는 대신 그룹 정책부터 수정해야 합니다.

서명 비밀값과 테스트 작업 분리

포크에서 발생한 PR 워크플로는 일반적으로 비밀값을 전달받지 않으며, GITHUB_TOKEN 권한도 읽기 전용으로 제한됩니다. 구체적인 조건은 이벤트와 저장소 설정에 따라 확인해야 합니다. 포크 PR에서 비밀값을 사용하는 조건과 안전한 사용 문서를 함께 확인하세요.

비밀값이 로그에 출력되지 않았다는 사실은 워크플로가 그 비밀값에 접근하지 못했다는 증거가 아닙니다. 테스트 작업의 환경 변수, 키체인, 임시 파일, 이전 작업에서 남은 설정 파일까지 확인해야 합니다. 서명용 키를 같은 노드에 두고 PR 작업과 배포 작업이 차례로 실행된다면, 워크플로를 나눈 것만으로는 충분하지 않습니다.

주의: pull_request의 포크 보호 동작을 근거로 자체 관리 러너를 안전하다고 판정하지 마세요. 러너에 남은 파일과 다른 접근 경로는 별도로 점검해야 합니다.

중간 점검 FAQ

외부 PR과 러너 접근

외부 PR을 실행해야 한다면 먼저 비밀값이 없고, 신뢰된 작업과 상태를 공유하지 않는 격리 환경을 준비합니다. 그런 환경을 보장할 수 없다면 외부 PR은 자체 관리 맥 러너에서 실행하지 않는 방향으로 분기하세요. 실행 허용은 워크플로 이벤트와 러너 그룹 정책을 함께 검토한 뒤 결정합니다.

저장소 허용 범위 확인

러너 그룹에서 접근 가능한 저장소 목록과 워크플로 접근 설정을 함께 확인합니다. 운영 중인 러너에 레이블만 붙여 둔 상태는 접근 제한을 증명하지 않습니다. 허용 저장소에 없는 테스트 저장소에서 작업이 배정되지 않는지도 검증하고, 조직의 저장소 추가나 그룹 정책 변경 뒤에는 재검토 담당자를 지정하세요.

비밀값이 없는 테스트 구성

외부 PR 검증과 서명·배포를 별도 작업으로 나누고, PR 작업에 서명 키와 배포용 비밀값을 연결하지 않습니다. 비밀값을 읽지 못하더라도 같은 맥 계정이나 키체인, 파일 시스템에 접근할 가능성은 남습니다. 따라서 워크플로의 비밀값 설정뿐 아니라 노드의 사용자 권한과 잔류 상태도 살펴야 합니다.

작업 뒤 노드 확인

작업이 끝난 뒤에는 작업 디렉터리, 캐시, 임시 파일과 백그라운드 프로세스를 검사합니다. 정리 설정을 확인하는 데서 끝내지 말고, 민감한 정보가 없는 테스트 작업을 실행해 정리 후 상태를 직접 확인하세요. 잔류물이 발견되면 노드를 다시 격리하고 복구 기록과 재검토 책임자를 남깁니다.

작업 후 정리와 복구 시험

장기 실행형 맥 러너는 한 작업이 끝나도 다음 작업에 사용할 수 있는 파일이나 프로세스가 남을 수 있습니다. 공식 문서는 자체 관리 러너가 신뢰 경계에 미치는 영향을 다루며, 작업 전후 스크립트 사용 방법도 안내합니다. 작업 전후 스크립트 설정은 정리 절차를 자동화할 때 참고할 수 있습니다. 다만 스크립트가 있다는 것과 노드가 깨끗하다는 것은 별개의 판정입니다.

아래 항목은 설정 검토가 아니라 실제 시험 결과로 판정합니다.

작업 완료 후 노드를 재사용하는 구조라면 비민감 테스트 워크플로를 실행하고, 다음 작업을 시작하기 전에 파일과 프로세스를 직접 확인합니다. 정리 실패, 민감 비밀값 접근, 허용되지 않은 저장소의 러너 사용 중 하나라도 발견되면 그 노드는 불합격입니다. 자동 복구를 설정했더라도 노드 상태와 기록을 사람이 확인하기 전에는 신뢰된 작업에 다시 배정하지 않습니다.

조건별 승인과 차단

다음 조건을 모두 만족할 때만 자체 관리 맥 러너 사용을 검토합니다.

• 외부 PR이 실행되는 워크플로와 신뢰된 브랜치의 워크플로가 분리되어 있습니까? 그렇다면 다음 항목을 확인합니다. 아니라면 외부 PR을 해당 러너에서 차단합니다.
• 러너 그룹의 허용 저장소와 워크플로 범위가 필요한 대상에 한정되어 있습니까? 그렇다면 실제로 허용되지 않은 저장소의 접근이 거부되는지 시험합니다. 아니라면 그룹 접근 정책을 수정합니다.
• PR 테스트에 서명·배포 비밀값이 연결되지 않고, 노드의 키체인이나 파일에도 민감 정보가 남지 않습니까? 아니라면 테스트를 별도 격리 환경으로 옮깁니다.
• 비민감 테스트 뒤 작업 파일, 캐시, 임시 파일과 프로세스가 정리됩니까? 아니라면 해당 노드를 격리하고 복구 절차를 수행합니다.
• 실행 기록, 노드 복구 결과, 재검토 책임자를 남길 수 있습니까? 아니라면 장기 운영을 시작하지 않습니다.

통과 판정은 한 번의 시험으로 끝나지 않습니다. 러너 그룹에 저장소를 추가하거나 워크플로를 바꾼 뒤에도 같은 기준으로 다시 확인해야 합니다. 이 점검은 운영상의 격리 판단을 돕는 절차이지, 규정 준수나 보안 인증을 보장하지 않습니다.

현재의 장기 자체 관리 러너는 초기 설정과 패치, 잔류 상태 정리, 작업 이후 복구를 직접 책임져야 합니다. 접근 범위가 넓거나 노드를 빠르게 초기화하기 어렵다면 운영 부담이 커집니다. 반대로 지속적인 고부하 작업이나 물리 장치 연결이 필요한 환경은 임대형 맥보다 직접 관리하는 장비가 더 적합할 수 있습니다. 임시 CI 환경을 검토한다면 맥 대여 환경의 운영 조건과 현재 노드의 격리·복구 책임을 먼저 비교하세요.

외부 PR을 기존 노드에 안전하게 분리할 방법이 확인되지 않았다면, 격리 가능한 빌드 노드를 마련하고 실제 정리 결과를 검증하는 편이 낫습니다. ZekVPS의 한국 맥 대여 옵션을 살펴볼 수 있습니다. 다만 대여만으로 임시 노드나 자동 정리가 보장되는 것은 아니므로, 도입 전에 제공되는 노드 방식과 접근 권한, 작업 후 복구 책임을 확인하세요.