2026 Mac Mini M6 GitHub Actions Runner: 임시 Runner인가 상주인가

풀 리퀘스트가 끝났는데도 Runner에 소스와 인증 정보가 남아 있습니까? 그렇다면 자동 등록 해제만 믿지 말고, 일반 검증은 임시 Runner로 보내며 서명과 외부 기기 작업은 제한된 상주 Runner로 분리해야 합니다.

이 글은 다음 팀을 위한 내용입니다. 풀 리퀘스트와 일반 테스트에 깨끗한 실행 환경이 필요한 플랫폼 팀, 코드 서명과 실제 기기를 관리하는 모바일 개발팀, Mac Mini M6 Runner 수와 확장 방식을 계산하는 기술 책임자가 대상입니다.

먼저 판단할 기준을 정합니다

GitHub Actions의 임시 Runner는 작업이 끝난 뒤 Runner 등록을 해제하는 방식입니다. 반면 상주 Runner는 같은 Mac에 도구, 캐시, 계정 환경을 남겨 다음 작업에서 재사용합니다. GitHub는 자동 확장이 필요한 자체 운영 환경에서 임시 Runner 사용을 권장하지만, 이 권고가 물리 Mac을 자동으로 초기화하거나 다시 설치한다는 뜻은 아닙니다. GitHub의 자체 운영 Runner 문서도 Runner 수명과 장비 관리 문제를 구분해 설명합니다.

판단은 다음 순서로 진행하면 됩니다.

1. 외부 기여 코드가 실행되는지 확인합니다.
2. 작업이 인증서, 키체인, 실제 기기, 고정 네트워크를 필요로 하는지 나눕니다.
3. 작업 종료 뒤 파일과 자격 증명을 자동으로 삭제할 수 있는지 검증합니다.
4. 캐시 적중률보다 격리와 복구가 중요한지 비교합니다.
5. 대기 시간과 실패 재실행 기록을 기준으로 노드 수를 조정합니다.

가장 위험한 오해는 “Runner가 자동으로 사라졌으니 Mac도 깨끗하다”는 판단입니다. 등록 해제는 GitHub 쪽 연결을 끊는 동작일 뿐입니다. 작업 디렉터리, 사용자 계정, 키체인, 캐시, 시스템 로그는 별도로 남을 수 있습니다.

첫 번째 팀 유형: 개인 프로젝트와 신뢰된 비공개 저장소

개인 프로젝트나 기여자 범위가 명확한 비공개 저장소라면 상주 Runner가 관리하기 쉽습니다. Xcode, SDK, 패키지 관리자, 빌드 캐시를 유지할 수 있고, 매번 도구를 다시 준비하는 시간을 줄일 수 있습니다.

다만 비공개 저장소라고 모든 코드가 안전한 것은 아닙니다. 외부 의존성의 설치 스크립트, 자동 생성된 작업 흐름, 권한을 가진 기여자의 변경을 함께 검토해야 합니다. GitHub도 자체 운영 Runner에서 신뢰할 수 없는 코드를 실행할 때의 위험을 별도로 안내합니다. GitHub Actions 보안 사용 안내에 따라 비밀 값과 Runner 범위를 최소화해야 합니다.

상주 방식을 쓸 때는 다음을 기본 정책으로 둡니다.

• 작업마다 작업 디렉터리를 삭제합니다.
• 임시 키체인과 인증 파일을 작업 종료 후 폐기합니다.
• 캐시는 저장소와 브랜치 범위를 분리합니다.
• 실패한 작업을 같은 환경에서 무조건 다시 실행하지 않습니다.
• 일반 테스트 Runner에 배포용 인증서를 넣지 않습니다.

캐시가 중요하더라도 환경 오염 비용이 반복되면 상주 Runner의 이점은 줄어듭니다. 정리 스크립트가 실패했을 때 작업을 중단하고 운영자에게 알리는 단계까지 포함해야 합니다.

두 번째 팀 유형: 외부 기여를 받는 오픈 소스 팀

풀 리퀘스트에서 실행되는 코드는 Runner 권한 안에서 명령을 실행할 수 있습니다. 따라서 오픈 소스 팀은 임시 Runner를 우선 검토해야 합니다. GitHub의 자체 운영 Runner 작업 설정 문서는 작업 흐름에서 Runner를 선택하는 방법을 설명하지만, Mac 장비를 자동으로 재배포해 주지는 않습니다.

여기서 임시라는 말은 물리 장비가 매번 새것이 된다는 뜻이 아닙니다. 한 작업에 하나의 Runner 신원을 할당하고, 작업 후 등록을 해제하며, Mac을 검증된 상태로 되돌리는 운영 모델을 말합니다.

권장 흐름은 다음과 같습니다.

1. 작업을 받을 전용 Mac 계정을 준비합니다.
2. 작업 시작 전에 필요한 Runner 등록 정보만 주입합니다.
3. 풀 리퀘스트 작업에는 배포 비밀과 서명 키를 전달하지 않습니다.
4. 작업 종료 후 소스, 임시 파일, 키체인, 로그를 정리합니다.
5. 정리 결과를 확인한 뒤 Runner 등록을 해제합니다.
6. 초기화에 실패하면 노드를 격리하고 새 작업을 받지 않습니다.

Mac Mini M6가 한 번만 사용하는 macOS Runner가 될 수 있는지는 장비 이름이 아니라 이 복구 절차로 판단해야 합니다. Apple은 Mac mini M6의 제품 정보를 공개했지만, 첫 장비가 실제로 배치되기 전에는 재설정 시간과 캐시 효과를 확정할 수 없습니다. Apple의 Mac mini 공식 사양과 Apple의 M6 발표 자료는 하드웨어 정보를 확인하는 자료이지, Runner 복구 성능을 보장하는 자료가 아닙니다.

세 번째 팀 유형: 빌드가 잦은 소규모 모바일 팀

빌드가 자주 발생하는 팀은 상주 캐시와 작업 간 오염을 함께 계산해야 합니다. 일반 컴파일과 단위 테스트는 상주 Runner에서 빠르게 처리할 수 있지만, 동일한 장비에서 여러 브랜치의 패키지와 빌드 산출물을 섞으면 재현성이 떨어질 수 있습니다.

일반 검증과 릴리스 작업을 같은 경로에 두지 않는 것이 좋습니다.

• 일반 빌드와 테스트: 임시 실행 풀 또는 재설정 가능한 상주 풀
• 스냅샷 테스트와 외부 기기 테스트: 기기 연결을 확인한 전용 풀
• 배포와 서명: 저장소와 브랜치가 제한된 서명 전용 풀
• 실패 재현: 운영 환경과 분리된 진단용 노드

캐시를 유지할 때는 캐시 적중 여부만 보지 말고, 캐시 때문에 잘못된 산출물이 통과하는지도 확인해야 합니다. Mac Mini M6의 실제 동시 실행 수와 초기화 시간은 첫 배치 후 같은 작업 흐름으로 측정해야 하며, 발표 자료의 하드웨어 사양만으로 계산해서는 안 됩니다.

대기열이 길어졌다면 노드를 바로 구매하기보다 다음 자료를 먼저 모읍니다. 시간대별 대기 시간, 작업별 실행 시간, 재시도 횟수, 실패가 장비 문제인지 코드 문제인지, 서명 작업이 차지하는 비율입니다. 자체 운영 Runner REST API 문서를 이용하면 등록 상태와 Runner 그룹을 자동으로 확인할 수 있습니다.

네 번째 팀 유형: 서명과 배포를 통제해야 하는 팀

서명 인증서, 키체인, 배포 계정은 모든 공용 Runner에 넣지 않는 편이 좋습니다. 소수의 상주 배포 노드를 두고 저장소, 브랜치, 작업 흐름의 출처를 제한하는 구조가 관리하기 쉽습니다.

임시 Runner에서 서명을 처리하려면 다음 조건을 모두 입증해야 합니다.

• 자격 증명이 작업 시작 때만 주입됩니다.
• 로그와 오류 출력에 비밀 값이 노출되지 않습니다.
• 작업 종료 후 키체인과 임시 인증서가 삭제됩니다.
• 초기화 실패 시 노드가 자동으로 격리됩니다.
• 누가 어떤 작업에 서명 권한을 사용했는지 추적할 수 있습니다.

이 조건을 증명하지 못한다면 임시라는 이름만 붙인 상주 장비가 됩니다. Apple Silicon용 개발 도구의 호환성을 검토할 때는 Apple의 Apple Silicon 앱 이전 문서도 함께 확인해야 합니다. 도구가 실행된다는 사실과 서명 환경이 재현된다는 사실은 서로 다릅니다.

다섯 번째 팀 유형: 대규모 플랫폼과 여러 프로젝트

여러 프로젝트가 같은 Mac Runner 풀을 사용하면 등록, 라우팅, 로그 보관, 시스템 이미지, 장애 회수를 한꺼번에 설계해야 합니다. Linux 컨테이너에서 가능한 자동 확장 방식을 Mac 물리 장비에 그대로 적용하면 안 됩니다. Mac은 장비 할당, 로그인 상태, 재부팅, 외부 기기 연결, 이미지 복구를 별도로 조정해야 하기 때문입니다.

플랫폼 팀은 다음 운영 상태를 기록해야 합니다.

• 노드가 등록된 시각과 작업을 받은 시각
• 작업 종료와 정리 완료 시각
• 정리 실패 및 재등록 실패
• 로그 외부 저장 성공 여부
• 장애 노드의 격리와 교체 결과

GitHub의 자체 운영 Runner 보안 안내는 로그를 외부에 보관하는 운영 요구와 자동 확장 환경의 고려 사항을 제공합니다. 다만 Mac의 전원, 저장 장치, 시스템 이미지까지 대신 관리하지는 않습니다.

끝에서 두 번째 단계: 팀별 선택을 표로 고정합니다

아래 표에서 가장 가까운 팀 유형을 고르면 됩니다.

현재 Runner 구성을 점검할 때는 kvmsync의 도움말 페이지에서 원격 장비 운영과 계정 관리 항목도 함께 확인할 수 있습니다. 장비를 추가하기 전에는 kvmsync의 Mac 환경 안내와 실제 팀의 접근 권한 정책을 맞춰 보는 편이 좋습니다.

마지막 단계: 이중 구조로 확장 기준을 정합니다

대부분의 운영팀에는 하나의 방식보다 이중 구조가 현실적입니다. 일반 검증은 임시 또는 재설정 가능한 실행 풀에 보내고, 서명과 외부 기기, 고정 도구 환경은 권한을 제한한 상주 풀에 보냅니다.

현재 자동 초기화가 안정적으로 되지 않는다면 임시 Runner라고 부르지 말고, 먼저 상주 노드의 권한과 접근 범위를 줄여야 합니다. 그 뒤 작업 공간 정리, 키체인 회수, 시스템 복구를 자동화하고 실제 실패 기록을 쌓아야 합니다.

자주 묻는 내용

임시 Runner와 상주 Runner를 고르는 가장 큰 기준은 무엇입니까?

작업의 출처와 비밀 정보의 범위가 가장 큰 기준입니다. 외부 코드가 실행되거나 작업마다 강한 격리가 필요하면 임시 방식을 우선합니다. 반대로 서명, 외부 기기, 고정된 도구 체인이 필요하고 접근 주체를 좁힐 수 있다면 제한된 상주 방식이 적합합니다.

Mac Mini M6를 일회성 macOS Runner로 운영할 수 있습니까?

운영할 수 있지만 자동 등록 해제만으로는 부족합니다. 장비가 작업 전 상태로 돌아왔다는 증거가 필요합니다. 파일 삭제, 키체인 초기화, 사용자 상태 확인, 시스템 복구, 새 Runner 등록을 하나의 흐름으로 만들고, 각 단계의 성공 여부를 기록해야 합니다.

iOS 서명을 임시 Runner에 맡겨도 안전합니까?

자격 증명 주입과 폐기 과정을 감사할 수 있을 때만 검토해야 합니다. 서명 키가 일반 테스트 환경에 남거나 로그에 노출되면 임시 Runner의 장점이 사라집니다. 검증이 부족한 팀은 저장소와 브랜치를 제한한 서명 전용 상주 노드부터 운영하는 편이 안전합니다.

작업 사이의 오염을 어떻게 줄입니까?

작업 디렉터리만 지우지 말고 캐시, 임시 파일, 키체인, 계정 토큰, 생성된 설정 파일을 함께 처리해야 합니다. 정리 실패 시 노드를 즉시 라우팅 대상에서 제외하고, 새 작업을 받기 전에 재부팅이나 검증된 이미지 복구를 수행해야 합니다.

Runner를 늘릴 시점은 어떻게 판단합니까?

대기 작업 수 하나만으로 판단하지 않습니다. 대기 시간, 실행 시간, 재시도, 실패 원인, 시간대별 동시 실행량을 함께 기록합니다. 일반 테스트와 서명 작업을 분리한 뒤 특정 작업군의 대기 시간이 지속적으로 늘어날 때 같은 권한 경계를 가진 노드를 추가해야 합니다.

현재 사용하는 방식이 일반 Mac 한 대에 모든 작업을 몰아넣는 구조라면 캐시를 얻는 대신 작업 간 오염, 서명 키 노출, 장애 시 전체 파이프라인 중단이라는 대가를 치르게 됩니다. 반대로 장비를 모두 임시로만 만들면 초기화 자동화와 외부 기기 연결 관리가 복잡해집니다. 먼저 일반 테스트 작업 하나를 분리해 임시 실행 노드로 검증하고, 배포 시기에만 추가 Mac 용량이 필요하다면 동일한 이미지와 권한 경계를 가진 단기 노드를 늘리는 방식이 합리적입니다. 이런 시험용 Mac 환경이 필요할 때는 kvmsync의 이용 안내에서 임대 조건을 확인한 뒤, 실제 작업 흐름과 복구 절차를 기준으로 검토하시기 바랍니다.