GitHub Actions macOS Runner vs 자체 호스팅 Mac: 2026 iOS 빌드 어떻게 선택할까?

빌드가 끝날 때마다 의존성을 다시 받고, Archive 단계에서 서명 오류까지 반복됩니까? 가장 빠른 해법은 낮은 빈도의 검사에는 GitHub 호스팅 macOS Runner를 쓰고, 잦은 Archive와 정식 배포에는 격리된 자체 호스팅 Mac을 붙이는 것입니다. 대부분의 독립 개발자는 두 환경을 나누는 구성이 안전합니다.

매주 Pull Request 검사를 몇 번만 실행하는 개인 개발자라면 이 글의 앞부분만 확인해도 됩니다. 캐시 복원과 서명 초기화 때문에 시간이 흔들리는 앱 유지 담당자, 원격 Mac을 GitHub Actions에 연결하려는 작은 팀이라면 뒤의 보안과 복구 조건까지 읽어야 합니다.

마지막 업데이트: 2026년 8월 28일. Runner 라벨과 과금, 보안 기준은 GitHub 공식 Runner 문서, Actions 과금 안내, Apple 개발자 문서를 기준으로 다시 확인해야 합니다.

먼저 작업을 세 갈래로 나누십시오

GitHub Actions macOS Runner와 자체 호스팅 Mac의 선택은 칩이나 메모리부터 비교할 문제가 아닙니다. 다음 네 가지를 먼저 기록하십시오.

• 빌드 빈도: Pull Request 검사인지, 하루에 반복하는 Release Archive인지 구분합니다.
• 작업 지속 시간: 컴파일만 하는지, 테스트·Archive·내보내기·업로드까지 이어지는지 봅니다.
• 환경 지속성: 매번 새 환경이 필요한지, Xcode 구성과 의존성 캐시를 보존해야 하는지 확인합니다.
• 권한 수준: 일반 테스트인지, 인증서·Provisioning Profile·App Store Connect API 키를 사용하는 배포인지 나눕니다.

일반 컴파일과 단위 테스트는 깨끗한 호스팅 환경의 장점을 얻기 쉽습니다. 반대로 Archive와 서명 내보내기는 Apple이 안내하는 배포 절차처럼 인증서, 프로파일, 키체인 상태가 함께 맞아야 하므로 단순한 컴파일 시간만으로 판단하면 안 됩니다. Apple의 Archive 및 배포 안내도 이 작업을 별도 단계로 다룹니다.

세 가지 상황별 선택 점수

아래 점수는 특정 장비의 성능 점수가 아니라, 운영 부담과 재현성까지 포함한 의사결정용 점수입니다. 점수가 높을수록 해당 상황에 더 잘 맞는다는 뜻입니다.

GitHub 호스팅 Runner는 사용 가능한 macOS 이미지와 아키텍처를 라벨로 선택하지만, macos-latest를 영구적인 특정 버전으로 간주해서는 안 됩니다. 공식 문서에 표시된 현재 라벨과 아키텍처를 확인하고, 실제 저장소에서 최소 빌드를 실행해 검증해야 합니다. 호스팅 Runner의 사용량 과금 방식은 공식 Actions Runner 과금 페이지에서 확인할 수 있습니다.

자체 호스팅 Runner는 GitHub가 실제 Mac을 관리해 주는 서비스가 아닙니다. Mac의 전원과 네트워크, 디스크 여유 공간, Runner 서비스, Xcode 설치, 키체인 정리, 재부팅 뒤 자동 복구를 모두 직접 책임져야 합니다. Mac이 온라인이어도 Runner 서비스가 멈추면 작업은 실행되지 않습니다.

첫 번째 판단: 낮은 빈도 검사는 깨끗한 환경으로 처리합니다

표준 프로젝트의 Pull Request 검사, 단위 테스트, 가끔 실행하는 빌드라면 호스팅 Runner가 대체로 간단합니다. 작업이 끝난 뒤 다음 작업에 잔여 파일이 남지 않으므로, 이전 빌드가 다음 빌드에 영향을 주는 문제를 줄일 수 있습니다.

특히 팀원이 같은 Xcode와 스크립트를 사용해야 하는 초기 단계에서는 환경을 매번 새로 만드는 방식이 재현성에 유리합니다. Runner 이미지에 포함된 도구와 사용 가능한 라벨은 변경될 수 있으므로, 워크플로 파일에 latest만 남기지 말고 정기적으로 실제 이미지 상태를 확인하십시오.

다만 의존성 설치가 무겁거나, 시뮬레이터 런타임과 패키지를 매번 다운로드하거나, 캐시가 자주 무효화되면 장점이 줄어듭니다. 이때는 컴파일 단계가 아니라 준비 단계까지 포함한 전체 작업 시간을 측정해야 합니다. GitHub Actions의 분 단위 사용량과 실패한 재실행까지 비용 항목에 넣으십시오.

두 번째 판단: 반복 Archive와 배포는 지속 환경을 따져야 합니다

하루에 여러 차례 Archive를 만들거나 TestFlight에 반복 업로드한다면 자체 호스팅 Mac의 가치가 커집니다. 같은 Xcode 도구 체인, 패키지 관리자 캐시, 프로젝트 의존성을 유지할 수 있기 때문입니다. 여기서 중요한 것은 컴파일만 빠른지가 아니라 다음 흐름이 안정적으로 끝나는지입니다.

1. 저장소를 깨끗한 작업 디렉터리에 받습니다.
2. 필요한 의존성과 캐시 상태를 확인합니다.
3. 고정한 Xcode로 Release Archive를 실행합니다.
4. 키체인과 Provisioning Profile을 사용해 앱을 내보냅니다.
5. 결과물을 App Store Connect에 업로드합니다.
6. 작업 디렉터리, 임시 키체인, 로그의 민감한 값을 정리합니다.
7. 실패 뒤 Runner 서비스와 Mac을 복구한 뒤 같은 작업을 다시 실행합니다.

자체 호스팅 Mac에서 캐시를 보존한다고 해서 모든 작업이 안전해지는 것은 아닙니다. 이전 빌드의 파일이 남으면 재현성이 깨지고, 만료된 프로파일이 남으면 서명 오류 원인을 찾기 어려워집니다. Apple의 Provisioning Profile 기술 문서를 기준으로 Bundle ID, Team ID, 프로파일의 관계를 확인하고, 저장소와 로그에는 실제 값을 남기지 마십시오.

원격 Mac을 배포용으로 운영하려면 VPSMAC의 한국어 Mac 이용 안내처럼 접속 방식과 사용 가능한 환경을 먼저 확인한 뒤, 현재 프로젝트의 Archive 흐름을 그대로 재현할 수 있는지 검증해야 합니다.

세 번째 판단: Xcode 27은 생산 환경과 호환성 환경을 분리합니다

Xcode 27을 검증해야 한다면 기존 정식 배포 환경의 Xcode를 바로 교체하지 않는 편이 안전합니다. Apple Release Notes에 해당 기능이나 이미지가 미리 보기로 표시되어 있다면, 이를 장기 운영 약속으로 해석해서는 안 됩니다. Xcode 27 Release Notes에서 지원 상태와 알려진 제한을 확인하십시오.

권장 구조는 다음과 같습니다.

• 호스팅 Runner: 공식적으로 제공되는 Xcode 27 관련 환경을 호환성 테스트에 사용합니다.
• 자체 호스팅 Mac: 현재 출시 중인 앱을 빌드하는 정식 Xcode와 서명 환경을 유지합니다.
• 공통 검증: 같은 커밋으로 컴파일, 테스트, Archive 결과를 비교합니다.
• 회귀 경로: Xcode 27 테스트가 실패하면 정식 배포 Runner로 즉시 되돌립니다.

runs-on 라벨은 문서에 실제로 표시되고 테스트 저장소에서 실행되는지 확인해야 합니다. 미래의 라벨 이름이나 유지 기간을 전제로 워크플로를 설계하지 마십시오.

네 번째 판단: 비공개 의존성과 서명 키는 Runner보다 격리가 우선입니다

공개 저장소의 Pull Request는 신뢰할 수 없는 코드가 실행될 가능성을 염두에 둬야 합니다. 서명 인증서, Provisioning Profile, App Store Connect API 키, 사설 패키지 저장소 토큰이 있는 자체 호스팅 Mac에서 이런 작업을 실행하면 Mac의 잔여 파일과 네트워크 권한까지 위험 범위에 들어갑니다.

GitHub의 Actions 보안 사용 지침은 자체 호스팅 Runner를 신뢰 경계 안에서 운영하고, 공개 저장소의 위험한 작업과 분리하도록 안내합니다. 따라서 다음처럼 나누는 것이 좋습니다.

• 일반 검사: 공개 Pull Request도 접근할 수 있는 호스팅 Runner에서 실행합니다.
• 비공개 빌드: 보호된 브랜치와 환경 승인을 거친 자체 호스팅 Runner에서 실행합니다.
• 정식 배포: 별도 라벨과 별도 저장소 또는 작업 흐름으로 제한합니다.
• 비밀값 처리: 작업이 끝날 때 임시 키체인과 생성 파일을 삭제하고, 로그 마스킹을 확인합니다.

자체 호스팅 Runner라는 이름만으로 보안이 확보되는 것은 아닙니다. Runner를 등록한 계정, 저장소 권한, 라벨 선택, 작업 승인 조건이 함께 설계되어야 합니다.

다섯 번째 판단: 실제 발행 주기로 두 환경을 검증합니다

결정 전에 한 번의 작은 컴파일만 재지 마십시오. 다음 순서로 실제 발행 주기를 기록하면 선택이 선명해집니다.

1. 같은 커밋을 호스팅 Runner와 자체 호스팅 Mac에서 실행합니다.
2. 의존성 복원 시간을 따로 적습니다.
3. 테스트와 일반 빌드 시간을 분리합니다.
4. Release Archive와 앱 내보내기 시간을 기록합니다.
5. 실패를 일부러 재현하고 Runner 서비스 복구 시간을 확인합니다.
6. 테스트용 자격 증명으로 통제된 업로드를 실행합니다.
7. 캐시, 임시 파일, 로그에 비밀값이 남지 않았는지 검사합니다.

낮은 빈도이고 초기화 시간이 감당할 만하면 호스팅 Runner를 유지하십시오. Archive가 자주 반복되고 지속 환경이 준비 시간을 줄이면 자체 호스팅 Mac을 선택하십시오. 검사와 배포의 위험이 다르면 일반 작업은 호스팅 Runner에, 서명과 정식 배포는 격리된 자체 호스팅 Mac에 두는 것이 기본값입니다.

복구 조건으로 최종 결정을 내리는 방법

• 매주 실행하는 검사가 적고 서명 자료가 없다면 호스팅 Runner를 선택합니다.
• 캐시 복원과 Xcode 준비가 반복되어 전체 작업 시간이 흔들리면 자체 호스팅 Mac을 검토합니다.
• 정식 배포와 공개 Pull Request가 같은 Runner를 사용한다면 먼저 작업을 분리하고, 그다음 자체 호스팅 여부를 결정합니다.
• Xcode 27이 미리 보기 상태라면 호환성 검증용 별도 환경으로 제한하고 정식 배포에는 사용하지 않습니다.
• Mac 장애 뒤 자동 복구를 보장할 수 없다면 단일 자체 호스팅에 의존하지 말고 호스팅 Runner를 복구 경로로 남깁니다.

원격 Mac을 실제 배포 서버로 운용할 계획이라면 서울 노드처럼 VPSMAC의 사용 가능한 Mac 환경을 확인할 수 있습니다. 다만 임대 기간이나 비용만 보고 결정하지 말고, 고정 Xcode 설치와 Runner 재시작, 디스크 정리, 접근 권한 회수가 가능한지 먼저 문의해야 합니다.

현재 방식과 Mac 방식의 차이

지금 호스팅 Runner만 사용하면 초기 관리 부담은 작지만, 반복되는 환경 준비와 캐시 복원, 실행 대기와 사용량 과금이 누적될 수 있습니다. 반대로 자체 Mac을 직접 운영하면 캐시와 서명 환경을 통제할 수 있지만, Mac이 꺼지거나 Runner 서비스가 멈겼을 때 복구 책임이 당신에게 남고 보안 정리도 직접 해야 합니다.

실제 발행 주기를 측정한 뒤 고정 Xcode, 지속 캐시, 격리된 서명 환경이 필요하다고 판단했다면 VPSMAC의 원격 Mac을 보조 또는 정식 배포 환경으로 검토할 수 있습니다. 기존 GitHub Actions를 모두 바꾸기보다, 일반 검사에는 호스팅 Runner를 남기고 발행 작업만 연결하는 방식이 비용과 장애 위험을 함께 관리하기 쉽습니다.