GitHub Actions macOS-26 또는 자체 호스팅 Mac? 2026 CI 선택 가이드

빌드 대기열이 길어지고 캐시가 매번 비워지며 서명 단계에서 작업이 멈춘다면, 실행기 종류보다 작업 분리가 먼저 필요합니다.

빠른 해법은 간단합니다. 표준 검사와 빈도가 낮은 빌드는 GitHub Actions macOS-26으로 보내고, 고정된 Xcode, 지속 캐시, 사내망, 장시간 빌드와 서명은 자체 호스팅 Mac으로 분리합니다. 성장 중인 팀에는 두 방식을 섞는 구성이 가장 안전합니다. 모든 팀에 더 나은 단일 실행기는 없습니다.

이 글은 macOS-26 실행기로 이전 중인 GitHub Actions 사용자에게 맞습니다. 빌드 대기, 의존성 다운로드, 서명 작업 때문에 배포가 늦어진 DevOps 팀과 전용 Mac 노드를 검토하는 기술 책임자도 대상입니다.

작업 유형별 선택 기준

GitHub Actions macOS-26이 맞는 작업

코드 검사, 일반 단위 테스트, 짧은 풀 리퀘스트 검증처럼 환경을 오래 유지할 필요가 없는 작업은 호스팅 실행기가 유리합니다. 실행기 준비와 운영체제 패치는 직접 관리하지 않아도 되고, 작업량이 줄면 노드 용량을 미리 확보하지 않아도 됩니다.

macOS-26 라벨은 GitHub가 제공하는 실행기 선택값입니다. 다만 라벨이 영구적인 하드웨어나 Xcode 버전을 뜻하지는 않습니다. 실제 이미지에 포함된 운영체제, 프로세서 구조, 개발 도구는 macOS-26 이미지 목록과 갱신 공지를 작업 시점마다 확인해야 합니다.

자체 호스팅 Mac이 맞는 작업

다음 조건이 하나라도 있으면 전용 노드를 우선 검토합니다.

특정 Xcode 버전을 장기간 유지해야 합니다.
Derived Data와 의존성 캐시를 반복해서 사용합니다.
사내 저장소, 테스트 장비, 사설 패키지 저장소에 접근해야 합니다.
코드 서명과 배포 인증서를 통제된 공간에서 사용해야 합니다.
무거운 빌드가 자주 실행되어 호스팅 실행기의 대기열과 초기 준비 시간이 문제가 됩니다.
동일한 하드웨어와 동일한 도구 조합으로 장애를 재현해야 합니다.

자체 호스팅이라고 해서 자동으로 더 안정적이거나 안전해지는 것은 아닙니다. 운영체제 업데이트, 디스크 정리, 실행기 프로세스, 전원과 네트워크, 대체 노드까지 팀이 책임져야 합니다.

작업별 점수

아래 평가는 일반적인 구조를 결정하기 위한 기준입니다. 특정 프로젝트의 실제 성능을 뜻하지 않으며, 성능 수치는 같은 저장소와 같은 커밋으로 측정해야 합니다.

표준화된 검사: 호스팅 실행기 5점, 자체 호스팅 Mac 3점
Xcode 버전 고정: 호스팅 실행기 2점, 자체 호스팅 Mac 5점
지속 캐시: 호스팅 실행기 2점, 자체 호스팅 Mac 5점
사내망과 장비 접근: 호스팅 실행기 1점, 자체 호스팅 Mac 5점
운영 부담: 호스팅 실행기 5점, 자체 호스팅 Mac 2점
노드 용량 통제: 호스팅 실행기 4점, 자체 호스팅 Mac 3점

한 작업에서 높은 점수를 받은 실행기를 전체 파이프라인의 기본값으로 삼을 필요는 없습니다. 검사와 서명은 서로 다른 위험과 지연을 가지므로 같은 노드에 억지로 묶지 않는 편이 낫습니다.

버전과 도구 체인

GitHub Actions에서 Xcode 버전을 고정하는 방법

macOS-26 runner를 선택했다고 해서 필요한 Xcode가 항상 기본으로 선택된다고 가정하면 안 됩니다. 이미지 목록에서 설치된 도구를 확인하고, 워크플로에서 명시적으로 선택하거나 사전 검증 단계에서 실패시키는 방식이 필요합니다. Apple의 Xcode 시스템 요구 사항도 함께 확인해야 합니다.

예시는 다음과 같은 검증 흐름입니다.

runs-on: macos-26

steps:
  - uses: actions/checkout@v4

  - name: Select Xcode
    run: sudo xcode-select -s /Applications/Xcode.app

  - name: Verify toolchain
    run: |
      sw_vers
      xcodebuild -version
      xcodebuild -showsdks

실제 경로가 이미지에 존재하지 않으면 작업을 계속하지 말고 실패시키는 편이 좋습니다. 여러 Xcode를 설치한 자체 호스팅 Mac에서는 xcode-select 변경이 다음 작업에 남지 않도록 작업 전후 상태를 확인해야 합니다. 추가 구성 요소가 필요한 경우에는 Xcode 구성 요소 설치 안내를 기준으로 이미지와 노드를 따로 관리합니다.

호스팅 이미지는 자동으로 바뀔 수 있습니다. 따라서 이미지 변경을 발견하면 같은 커밋으로 빌드, 테스트, 아카이브를 다시 실행하는 검증 작업을 예약해야 합니다. 반대로 자체 호스팅 Mac은 버전을 고정하기 쉽지만, 고정이 방치로 바뀌면 보안 패치와 SDK가 뒤처집니다.

주의: macos-26은 운영체제 계열을 선택하는 라벨이지, 특정 Mac 모델과 영구히 연결된 약속이 아닙니다. 프로세서 구조와 Xcode 기본값은 이미지 문서와 실제 실행 로그로 확인해야 합니다.

빌드 시간과 캐시 구조

CI 속도는 코어 수 하나로 계산할 수 없습니다. 초기 실행기 준비, 저장소 내려받기, 패키지 다운로드, 컴파일, 테스트, 아카이브 업로드가 모두 총 시간에 포함됩니다. 따라서 “더 강한 Mac”이라는 설명만으로 교체 효과를 예측하면 안 됩니다.

호스팅 실행기에서는 캐시 복원과 저장이 작업 흐름에 포함됩니다. GitHub의 의존성 캐시 동작 문서는 키와 복원 키를 기준으로 캐시를 관리하는 방식을 설명합니다. 브랜치, 운영체제, 패키지 관리자, 잠금 파일을 키에 반영하지 않으면 오래된 의존성이 복원되거나 캐시 적중률이 낮아질 수 있습니다.

자체 호스팅 Mac은 캐시가 디스크에 남아 다음 작업에 재사용될 수 있습니다. 그러나 여러 프로젝트가 같은 캐시를 공유하면 오염과 권한 문제가 생깁니다. 프로젝트별 경로를 나누고, 잠금 파일 변경 시 캐시 키를 바꾸며, 디스크 사용량이 임계 상태가 되기 전에 정리해야 합니다.

성능 비교는 다음 조건으로 측정해야 합니다.

같은 커밋과 같은 의존성 잠금 파일을 사용합니다.
캐시가 없는 첫 실행과 캐시가 있는 반복 실행을 분리합니다.
대기 시간, 준비 시간, 빌드 시간, 업로드 시간을 따로 기록합니다.
동일한 테스트 집합과 아카이브 설정을 사용합니다.
여러 번 반복한 중앙값과 실패율을 함께 비교합니다.

이런 기록 없이 호스팅 실행기와 자체 호스팅 Mac의 우열을 단정할 수 없습니다. 특히 캐시가 큰 iOS 프로젝트에서는 컴파일보다 다운로드와 압축 해제가 병목일 수 있습니다.

서명과 네트워크 경계

코드 서명은 실행기 선택보다 권한 설계가 중요합니다. 임시 호스팅 실행기는 작업이 끝난 뒤 환경이 폐기되는 장점이 있지만, 사내망이나 물리 장비에 접근하기 어렵습니다. 자체 호스팅 Mac은 인증서와 프로비저닝 프로필을 보관할 수 있지만, 장기간 남는 비밀 정보가 공격 표면이 됩니다.

GitHub의 안전한 사용 지침은 외부 풀 리퀘스트와 비밀 정보 사용을 분리해서 검토하도록 안내합니다. 서명 노드에는 다음 정책을 적용해야 합니다.

신뢰할 수 없는 풀 리퀘스트가 서명 노드에 도달하지 않게 합니다.
배포용 비밀 정보와 일반 테스트용 비밀 정보를 분리합니다.
작업 종료 뒤 임시 키체인과 인증서를 삭제합니다.
실행기 계정의 파일 접근 범위를 최소화합니다.
실행기 로그와 네트워크 접근 기록을 남깁니다.
노드가 오프라인일 때 대체 경로와 배포 중단 조건을 정합니다.

자체 호스팅 실행기의 접근 제어는 공식 관리 문서처럼 저장소와 조직 단위로 나누어야 합니다. 전용 라벨만 붙이는 것으로 격리가 완성되지는 않습니다. 풀 리퀘스트 트리거, 환경 승인, 저장소 권한을 함께 점검해야 합니다.

유지 관리와 장애 복구

호스팅 방식은 운영체제 패치와 기본 이미지 관리를 줄여 줍니다. 대신 이미지 갱신으로 도구 버전이나 라벨의 실제 환경이 변할 수 있습니다. 자체 호스팅 방식은 환경을 얼려 재현성을 높이지만, 패치 누락과 디스크 부족, 실행기 중단이 곧 CI 장애로 이어집니다.

비용도 월 이용료 하나로 비교하면 안 됩니다. 호스팅 방식은 실행 시간, 동시 작업 수, 캐시와 저장 공간 정책을 변수로 둔 추정식이 필요합니다. 자체 호스팅 방식은 Mac 임대 또는 구매 비용에 전력, 네트워크, 관리 시간, 예비 노드, 장애 복구 비용을 더해야 합니다. 실제 금액은 계약 조건과 사용량에 따라 달라지므로 출처 없는 가격을 선택 근거로 사용하면 안 됩니다.

Mac 노드가 필요하지만 직접 장비를 확보하기 어려운 팀은 클라우드 Mac 임대 방식을 운영 부담과 함께 비교할 수 있습니다. Mac 환경의 연결과 지원 범위를 먼저 확인하려면 Mac 지원 안내도 함께 검토하는 편이 좋습니다. 다만 물리적인 장비 연결이나 장기간 고정 부하가 핵심이면 자체 구매가 더 적합할 수 있습니다.

혼합 CI 설계

대부분의 성장 팀은 다음처럼 파이프라인을 분리합니다.

풀 리퀘스트의 정적 검사와 일반 단위 테스트는 macos-26에 배치합니다.
장시간 빌드와 큰 아카이브는 self-hosted runner 라벨을 가진 전용 Mac으로 보냅니다.
코드 서명과 배포는 승인된 환경에서만 실행합니다.
장비 연결이 필요한 테스트는 별도 노드와 별도 큐로 분리합니다.
노드가 중단되면 서명 작업을 자동으로 다른 경로에 보내지 않고, 승인된 대체 절차를 실행합니다.

작업 분리는 단순히 runs-on 값만 바꾸는 일이 아닙니다. 캐시 경로, 비밀 정보, 아티팩트 보관, 실패 시 재실행 정책까지 함께 나눠야 합니다. 일반 테스트를 자체 호스팅 노드로 보내면 서명 키가 불필요하게 노출될 수 있고, 서명 작업을 호스팅 실행기로 보내면 네트워크와 키 관리 요구를 충족하지 못할 수 있습니다.

마이그레이션 전 검증 목록

운영 워크플로를 한 번에 옮기기보다, 동일한 커밋을 두 실행기에서 검증한 뒤 범위를 넓혀야 합니다.

[ ] macOS-26 이미지 목록과 실제 sw_vers 결과가 일치하는지 기록합니다.
[ ] 실제 xcodebuild -version과 필요한 SDK가 승인된 범위인지 확인합니다.
[ ] 캐시 없음과 캐시 있음의 시간을 별도로 측정합니다.
[ ] 빌드 산출물의 해시와 테스트 결과가 두 실행기에서 일치하는지 비교합니다.
[ ] 서명 노드에 접근할 수 있는 저장소와 트리거를 검토합니다.
[ ] 작업 종료 후 키체인, 임시 파일, 인증서가 삭제되는지 확인합니다.
[ ] 자체 호스팅 Mac이 오프라인일 때의 대체 큐와 담당자를 정합니다.
[ ] 이미지 갱신 뒤 다시 실행할 검증 워크플로를 등록합니다.
[ ] 대기 시간과 실패율을 포함해 용량을 재평가합니다.

이 절차를 통과하지 못한 작업은 생산 배포에서 자체 호스팅으로 전환하지 않는 편이 안전합니다. 특히 캐시가 좋아졌다는 이유만으로 서명과 일반 테스트를 같은 노드에 합치면 권한 경계가 약해집니다.

결론과 다음 선택

현재 호스팅 실행기만 사용하는 구조는 환경 변경을 통제하기 어렵고, 지속 캐시와 사내망 접근에 제약이 있으며, 무거운 작업이 몰릴 때 대기열의 영향을 받습니다. 반대로 자체 호스팅 Mac만 사용하는 구조는 패치, 모니터링, 예비 노드와 보안 정리를 팀이 계속 책임져야 합니다.

따라서 먼저 기존 파이프라인을 일반 검사, 중량 빌드, 서명과 배포로 나누는 것이 맞습니다. 고정 환경이 필요한 일부 작업만 통제 가능한 Mac 노드로 옮기면 전체 CI를 한 번에 마이그레이션하는 위험을 피할 수 있습니다. 임시 테스트 환경이나 특정 기간의 빌드 용량이 필요하다면 Zilmac의 Mac 임대 구성을 검토할 수 있지만, 장기간 일정한 고부하와 직접 장비 연결이 필요한 팀에는 구매 또는 전용 운영이 더 알맞습니다.

마지막 업데이트: 2026년 8월 24일. 실행기 라벨과 이미지 정보는 GitHub 호스팅 실행기 문서와 macOS-26 이미지 문서를 기준으로 다시 확인해야 하며, Xcode 요구 사항은 Apple 문서와 실제 샘플 워크플로 로그로 검증해야 합니다.