판정: 신뢰된 비공개 저장소의 빌드만 실행하고 접근 권한과 작업 후 상태를 통제할 수 있다면 상주형 Mac을 선택해도 됩니다. 외부 기여 코드나 높은 권한의 서명 비밀 정보를 다룬다면 격리된 일회성 실행 환경을 우선 검토하세요. 이번 주에는 워크플로의 코드 출처와 비밀 정보 접근부터 확인하세요.
이 글은 GitHub Actions로 iOS 앱을 빌드하며 Runner의 재사용과 관리 부담을 저울질하는 독립 개발자를 위한 내용입니다.
일상 빌드와 서명 배포를 분리하려는 소규모 팀, 상주 Mac의 자격 증명과 작업 흔적을 점검하는 담당자에게도 해당합니다.
먼저 구분할 것은 Runner의 온라인 상태와 작업 환경의 잔류입니다
상주형 Runner는 작업이 없을 때도 등록된 상태로 기다릴 수 있습니다. 하지만 Runner 프로세스가 계속 온라인이라는 사실만으로 이전 작업의 파일이나 자격 증명이 남아 있다고 단정할 수는 없습니다. 반대로 작업 디렉터리를 비웠다고 해서 호스트 전체가 격리됐다고 볼 수도 없습니다.
GitHub 문서는 자체 호스팅 Runner가 워크플로 작업을 실행하는 환경이라고 설명하며, 일반적인 자체 호스팅 Runner는 한 번에 하나의 작업을 처리합니다. 따라서 같은 Runner가 다음 작업을 받는다는 사실과 이전 작업의 상태가 모두 안전하게 초기화됐다는 주장은 별개입니다. 실제 작업 상태는 자체 호스팅 Runner 참고 문서와 호스트 설정을 함께 확인하세요.
여기서 말하는 GitHub Actions 자체 호스팅 Runner는 GitHub가 관리하는 호스팅 실행 환경이 아니라 네가 관리하는 컴퓨터에서 작업을 실행하는 방식입니다. 설정에 따라 작업 디렉터리, 캐시, 로그, 키체인 상태가 남는 위치와 보존 기간이 달라질 수 있습니다.
예를 들어 비공개 저장소의 신뢰된 기본 브랜치에서 앱을 빌드하는 개인 개발자는 상주 Mac을 이용해도 될 수 있습니다. 단, Runner 그룹의 저장소 접근 범위가 필요한 곳으로 제한돼 있고, 빌드 뒤 작업 디렉터리와 자격 증명을 점검하며, 로그를 따로 추적할 수 있어야 합니다. 이 조건을 확인하지 않았다면 재사용의 편의만 보고 상주형을 선택하지 마세요.
02코드 출처에 따라 실행 가능한 환경을 나눕니다
외부 기여 코드와 네가 검토한 코드의 위험은 같지 않습니다. Pull Request의 워크플로가 실행하는 스크립트와 빌드 단계는 해당 코드가 작성된 경로와 권한 설정에 따라 달라집니다. 외부에서 제출된 변경 사항을 상주 Mac에서 실행하면 그 작업이 접근할 수 있는 환경을 신중하게 따져야 합니다.
GitHub는 이벤트별 실행 방식과 보안상 주의점을 따로 안내합니다. 특히 pull_request_target은 기본 브랜치의 권한 맥락에서 실행될 수 있으므로, 외부 코드 체크아웃이나 실행을 무심코 결합하지 않아야 합니다. 워크플로 이벤트별 실행 조건과 pull_request_target 안전 사용 지침을 네 설정과 대조하세요.
외부 Pull Request도 자체 호스팅 Mac Runner에서 실행해도 되나요?
외부 코드 실행을 허용할지는 이벤트 설정, 저장소 정책, Runner 그룹의 접근 범위, 작업에 제공되는 토큰과 비밀 정보에 따라 판단해야 합니다. 기본 브랜치의 권한이 필요한 작업과 외부 코드를 빌드하는 작업을 한 환경에 섞지 마세요. 설정을 검증하기 전에는 외부 기여 코드가 상주 Runner에 도달하지 않도록 제한하는 편이 안전합니다.
Runner 그룹의 저장소 접근 설정을 확인해 어떤 저장소가 어떤 Runner를 사용할 수 있는지 살펴보세요. Runner 그룹을 만들었다는 사실만으로 모든 작업이 자동으로 분리되지는 않습니다. 실제 접근 권한은 그룹과 저장소의 설정에 달려 있습니다.
03상주형과 임시형은 코드 신뢰도에 따라 고릅니다
아래 표는 성능이나 비용 비교가 아니라, 어떤 코드가 실행되고 어떤 상태가 남을 수 있는지를 기준으로 정리한 선택 도구입니다. 격리 환경도 구현 방식과 권한 설정을 검증해야 하며, 이름에 ‘임시’가 들어간다고 해서 모든 위험이 사라지는 것은 아닙니다.
| 실행 상황 | 우선 검토할 환경 | 선택 조건 | 확인할 위험 |
|---|---|---|---|
| 신뢰된 비공개 저장소의 일반 빌드 | 통제된 상주형 Mac | 저장소 접근이 제한되고 작업 후 상태를 점검할 수 있음 | 작업 디렉터리, 캐시, 로그, 자격 증명 잔류 |
| 외부 기여자의 코드 검사 | 격리된 실행 환경 또는 실행 제한 | 상주 호스트와 비밀 정보에 닿지 않도록 설계함 | 작업 코드의 호스트 접근과 권한 노출 |
| 인증서 서명과 앱 업로드 | 별도로 제한한 배포 작업 | 승인된 코드와 배포 권한을 가진 작업만 실행함 | 키체인, 인증서 개인 키, API 비밀 정보 |
| 장애 분석이 필요한 빌드 | 로그를 별도로 보존하는 환경 | 호스트 초기화와 진단 자료 보존을 함께 설계함 | 임시 호스트 종료 뒤 로그가 남지 않을 가능성 |
GitHub는 자체 호스팅 Runner를 신뢰할 수 없는 워크플로에서 사용할 때의 위험을 안내하고, 자동 확장 환경에는 일회성 Runner 사용을 권장합니다. 일회성 Runner는 작업을 마친 뒤 등록이 해제되는 방식이지만, 그 사실만으로 실행 호스트의 완전한 격리나 진단 로그의 보존까지 보장되지는 않습니다. 적용 전에 자체 호스팅 Runner 보안 지침을 확인하세요.
GitHub Actions 자체 호스팅 Runner는 여러 작업에서 다시 사용할 수 있나요?
상주형 Runner는 작업이 끝난 뒤에도 등록 상태를 유지하도록 운영할 수 있습니다. 다만 GitHub 문서에 따르면 Runner 하나는 한 번에 하나의 작업을 처리합니다. 재사용 여부를 결정할 때는 다음 작업을 받을 수 있는 상태인지뿐 아니라, 이전 작업의 파일과 인증 정보가 어떻게 처리되는지도 확인해야 합니다.
작업 정리와 호스트 격리는 서로 다른 통제입니다
Job 뒤에 프로젝트 산출물과 임시 파일을 정리하는 것은 필요하지만, 이를 macOS Runner 격리와 같은 의미로 취급하면 안 됩니다. 코드가 작업 중 접근한 범위, 사용자 계정의 파일, 키체인, 캐시, 로그는 작업 디렉터리 정리만으로 모두 초기화된다고 볼 수 없습니다. 자체 호스팅 Runner의 안전한 사용 안내에 맞춰 호스트와 워크플로 양쪽의 경계를 점검하세요.
| 점검 항목 | Job 종료 뒤 확인할 내용 | 확인 근거 |
|---|---|---|
| 작업 디렉터리 | 체크아웃한 코드, 중간 산출물, 임시 파일이 남았는지 | 작업 후 상태와 정리 기록 |
| 자격 증명 | 임시 키체인, 인증서, API 토큰이 다음 작업에서 접근 가능한지 | 비밀 정보 주입 경로와 폐기 기록 |
| 캐시와 로그 | 다음 작업이 이전 데이터에 접근할 수 있는지, 진단 자료는 별도 보존되는지 | 캐시 설정과 외부 로그 저장 내역 |
| Runner 등록 | 임시 Runner가 작업 종료 뒤 등록 해제됐는지 | Runner 관리 화면과 해제 기록 |
| 권한 범위 | 해당 저장소와 워크플로만 Runner를 사용할 수 있는지 | Runner 그룹 개념과 접근 경계 |
자체 호스팅 Runner는 매 작업 뒤 무엇을 정리해야 하나요?
작업 디렉터리만 보지 말고 임시 산출물, 인증서와 토큰의 사용 경로, 키체인, 캐시, 로그, Runner 등록 상태를 함께 확인하세요. 무엇을 지울지보다 더 중요한 것은 각 항목이 어디에 만들어졌고 누가 접근할 수 있는지 기록하는 것입니다. 정리 로그는 관리 흔적을 제공하지만, 격리됐다는 증거로 대신할 수는 없습니다.
서명과 배포 권한은 일반 빌드에서 분리합니다
일반 빌드 작업은 코드가 컴파일되는지 검증하면 됩니다. 반면 서명과 업로드 작업은 인증서 개인 키, 키체인, 앱 배포용 API 자격 증명에 접근할 수 있습니다. 두 작업이 같은 상주 호스트를 사용한다면, 작업별로 어떤 비밀 정보가 주입되는지와 실행할 수 있는 워크플로가 무엇인지 구분해야 합니다.
GitHub Actions의 권한 설정은 워크플로와 작업 단위에서 선언할 수 있습니다. 워크플로 권한 문법을 확인하고, 필요한 작업에만 토큰 권한과 비밀 정보를 제공하세요. 조직과 저장소의 기본 정책 및 실제 워크플로 설정도 함께 확인해야 합니다.
iOS 서명 키를 상주형 macOS Runner에 둬도 되나요?
상주 호스트에 서명 키를 두는 것 자체를 일괄적으로 안전하거나 위험하다고 판단할 수는 없습니다. 키에 접근할 수 있는 저장소, 워크플로, 사용자 계정과 폐기 절차를 먼저 확인하세요. 외부 기여 코드가 같은 Runner에서 실행될 수 있거나 빌드 작업이 불필요하게 서명 비밀 정보에 접근한다면, 서명 작업을 분리하고 권한 범위를 다시 설계해야 합니다.
원격 Mac에 서명 자격 증명을 두려면 접속 및 자격 증명 관리 경계도 확인해야 합니다. 이용 방식과 데이터 관리 기준을 검토할 때는 원격 Mac 개인정보 보호 방침을 참고하세요. 방침 확인만으로 워크플로의 비밀 정보 접근이 제한되는 것은 아니므로, 실제 권한 설정과 폐기 절차는 별도로 검증해야 합니다.
06이번 주에 설정과 복구 절차를 검증합니다
다음 순서대로 실제 저장소 설정을 확인하세요. 검토 결과는 비밀 정보가 노출되지 않도록 가린 설정 화면, 작업 결과, 정리 기록으로 남기면 됩니다.
- 워크플로 파일에서
on이벤트를 확인하고, 신뢰된 브랜치와 외부 Pull Request가 어떤 경로로 실행되는지 구분합니다. - Runner 그룹과 라벨의 접근 범위를 확인합니다. 해당 Runner에 접근할 수 있는 저장소와 워크플로가 의도한 범위인지 살펴봅니다.
- 각 Job의
permissions, 비밀 정보 전달 방식, 환경 보호 규칙을 확인합니다. 토큰과 배포 자격 증명이 일반 빌드에 불필요하게 전달되지 않는지 검토합니다. - 대표적인 빌드 뒤 작업 디렉터리, 캐시, 임시 파일, 키체인 사용 흔적을 확인합니다. 정리 명령이 실행됐다는 로그만으로 호스트 상태가 초기화됐다고 결론 내리지 않습니다.
- 실패 시 로그가 어디에 저장되는지와 민감 정보가 가려지는지 확인합니다. 임시 Runner를 쓰더라도 호스트 종료 뒤 진단 기록이 자동 보존된다고 가정하지 마세요.
- Runner가 고장 나거나 교체될 때의 등록 해제, 재등록, 호스트 초기화 절차를 문서화합니다. Runner 모니터링 및 문제 해결 안내와 Runner 제거 절차를 운영 방식에 맞춰 대조하세요.
이 검토에서는 실제 워크플로의 이벤트, Runner 그룹, 권한, 사후 처리 기록을 함께 봐야 합니다. 한 번 빌드가 성공했다는 결과는 환경이 격리됐다는 증거가 아니며, 특정 원격 Mac에서도 같은 결과가 자동으로 보장된다는 뜻이 아닙니다. 원격 Mac을 사용한다면 네가 선택한 접속 방식과 구성에서 실제 프로젝트를 실행하고, 작업 종료 뒤 파일과 자격 증명 처리 경계를 별도로 검증하세요.
07원격 Mac은 실행 환경 선택이지 Runner 격리 기능이 아닙니다
기존 개발 장비에서 빌드만 하려는 방식은 장비를 계속 켜 두고 관리해야 할 수 있고, 로컬 디스크와 개발 환경을 다른 작업과 나눠 써야 할 수 있습니다. 전용 Mac을 직접 마련하는 방식도 하드웨어를 보유하고 업데이트와 장애 대응을 맡아야 합니다. 반대로 원격 Mac을 임대하면 필요한 기간에 macOS 환경을 쓰는 선택지가 되지만, Runner 그룹 설정이나 작업별 권한 분리, 일회성 호스트가 자동으로 제공된다고 가정해서는 안 됩니다.
먼저 원격 Mac 환경 안내를 살펴보고, 네 워크플로에서 접속 방식과 사용 가능한 구성을 확인하세요. 단기간의 iOS 빌드나 배포 환경이 필요하고 직접 Mac을 구매·관리하고 싶지 않다면 VpsMesh의 원격 Mac 임대가 검토할 만한 대안입니다. 다만 외부 코드와 서명 작업을 같은 환경에 무심코 섞는 문제는 임대만으로 해결되지 않습니다. Runner의 수명, 접근 권한, 비밀 정보 분리는 네 GitHub 설정과 운영 절차로 확인해야 합니다.