플랫폼 팀 이전 검토 회의에서 경영진이 항상 묻습니다: 「GitHub Actions에서 자체 Mac 노드로 바꾸면 개발 효율이 얼마나 오르나?」——「빌드가 조금 빨라졌어요」 정도로는 회의가 진행되지 않습니다. 2026년 iOS / Flutter / React Native 팀들과 대조 실험을 진행한 결과, 자체 Mac 노드(사무실 Mac mini, 랙 베어메탈, 또는 Cloud Mac에 Runner 연결)로 이전한 뒤 가장 큰 효과는 컴파일 자체가 아니라 대기와 queue의 소멸이었습니다. 아래에서는 재현 가능한 4가지 지표, 3개 팀의 실측 대조표로 「얼마나 오르는지」에 답하고, 2주 안에 실행 가능한 이전 체크리스트와 ROI 개략 계산을 제공합니다.
Quick Answer: 효율이 얼마나 오르나?
| 관심 항목 | 호스팅 macOS runner (이전) | 자체 Mac 노드 (이후) | 전형적 개선 폭 |
|---|---|---|---|
| PR push부터 전체 녹색까지 (E2E) | 42–68분 | 9–16분 | 약 70%–80% 단축 |
| 대기 (queue time) | 15–45분/회 | 0–2분 | 거의 0 |
| Archive 1회 | 11–14분 | 8–11분 | 약 15%–25% (캐시 적중 후) |
| 릴리스 밤 TestFlight 빌드 수 | 1–2개 | 3–5개 | 처리량 약 2–3배 |
| 개발자 주간 수동 대기 | 3–6인시/인 | 0.5–1.2인시/인 | 약 75% 감소 |
한마디로: 개발 효율 향상의 핵심은 「대기」이지 「컴파일러가 빨라진 것」이 아닙니다. 자체 노드가 희소한 macOS 풀을 공유 queue에서 분리하고, DerivedData를 영속화해야 위 표의 규모감이 나옵니다.
먼저 측정할 지표——「얼마나 올랐는지」 말하기 전에
이전 후 「별로 빨라지지 않았다」고 느끼는 팀은 GitHub Actions의 Job duration만 보고 queue time과 Slack에서 기다리는 시간을 무시하는 경우가 많습니다. 이전 전후 각 2주, 최소 4가지를 기록하세요:
- 대기:
job queued부터job started까지 초를 P50 / P95로 보고 - PR 피드백 루프: 마지막 push부터 required checks 전부 녹색까지
- 릴리스 윈도우 처리량: 고정 4시간 내 TestFlight 성공 업로드 횟수
- 수동 대기 인시: 개발자 설문 「오늘 CI를 얼마나 기다렸나」 또는 PR 코멘트 타임스탬프로 추정
추출 방법: GitHub API로 run_started_at과 created_at 차이, 또는 workflow에 queue 초를 artifact에 쓰는 step 추가. 베이스라인 없이 이전하면 나중에 경영진에게 ROI를 증명하기 어렵습니다.
| 지표 | 수집 방법 | 이전 성공 신호 |
|---|---|---|
| Queue P95 | Actions API / 커스텀 step | >20min에서 <3min으로 |
| PR 피드백 P50 | PR 이벤트 타임스탬프 | 50% 이상 감소 |
| 캐시 적중률 | DerivedData 디렉터리 용량 + 빌드 로그 | <20%에서 >60%로 |
| 병렬 실패율 | 동일 머신 다중 Job 실패 비율 | 디렉터리 격리 후 <2% |
3개 팀 대조: 이전 vs 이후
아래 3건은 실제 이전 프로젝트(팀명 익명)에서 동일 저장소·동일 Xcode 메이저·2주 평일 샘플로 조건을 맞춘 데이터입니다.
케이스 A: 12명 iOS 팀, 단일 App + 확장
이전 전 모두 macos-14 호스팅 runner. 이후 M4 16GB Cloud Mac 2대 self-hosted Runner, DerivedData는 로컬 NVMe에 마운트. PR 평균 18회/일.
| 지표 | 이전 | 이후 | 변화 |
|---|---|---|---|
| PR 피드백 P50 | 52분 | 11분 | −79% |
| Queue P95 | 38분 | 0.8분 | −98% |
| Archive 1회 | 12.4분 | 9.1분 | −27% |
| 릴리스 밤 TestFlight 빌드 | 1.5개/밤 | 4개/밤 | +167% |
Tech Lead 코멘트: 「예전엔 오후 5시 push하고 6시 반 넘어야 머지 가능 여부를 알았다. 지금은 물 마시러 갔다 오면 녹색이다.」
케이스 B: 28명 KMP + Android 메인, Mac은 iOS 셸 전용
이전 전 macOS Job과 Android Job이 같은 릴리스 윈도우를 놓고 경쟁. 이후 상주 M4 Pro 1대 + 릴리스 주 burst Cloud Mac 2대 (릴리스 burst 운영 참고).
| 지표 | 이전 | 이후 | 변화 |
|---|---|---|---|
| 듀얼 플랫폼 PR 전체 녹색 P50 | 71분 | 24분 | −66% |
| 릴리스 주 Queue 합계/일 | 6.2시간 | 0.4시간 | −94% |
| 개발자 주간 대기 (설문 평균) | 4.8인시 | 1.1인시 | −77% |
케이스 C: 8명 인디, 월 2회 릴리스
반례: 이전 후 거의 개선 없음——PR이 적고 queue도 원래 거의 0. 자체 기기의 키체인 유지보수만 늘었다. Archive는 10.2분→9.4분(−8%)뿐, Queue는 원래 0에 가까웠음. 「얼마나 오르는지」는 부하 형태에 크게 의존하므로 대기업 숫자를 그대로 적용하면 안 됩니다.
효과의 원천: 대기·캐시·병렬
총 대기 시간을 분해하면 비개발 의사결정자에게도 설명하기 쉬워집니다:
PR 총 시간 ≈ queue 대기 + 환경 준비 + 컴파일·테스트 + 산출물 업로드1. 대기 (최대 요인): GitHub 호스팅 macOS runner는 공유 풀. 릴리스 주나 Xcode 메이저 업그레이드 주에는 P95 queue 30분+도 흔합니다. 자체 노드 = 전용 executor로 queue 항목이 거의 사라집니다.
2. 콜드 스타트와 캐시: 호스팅 Job은 종료와 동시에 폐기되어 DerivedData, Pods, SwiftPM 캐시가 매번 리셋됩니다. 자체 기기에 핫 디렉터리를 영속 볼륨에 두면 2회차 빌드는 보통 약 20% 단축. 자세히는 self-hosted Runner 캐시와 디스크 FAQ.
3. 병렬: Mac 2–3대로 matrix Job을 병렬 처리해 릴리스 밤 「꼬치 큐」를 해소. 동일 머신에서 다중 Job 실행 시 디렉터리 격리 필수——그렇지 않으면 랜덤 실패가 효율을 되돌립니다.
| 단계 | 호스팅 runner 전형 비율 | 자체 노드 이후 |
|---|---|---|
| 대기 | 45%–70% | <5% |
| 의존성 압축 해제 / 인덱싱 | 15%–25% | 5%–10% (영속 캐시 있음) |
| 순수 컴파일·테스트 | 20%–35% | 15%–30% |
2주 이전 경로: 먼저 대조, 나중에 트래픽 전환
금요일 저녁에 한 번에 프로덕션 전환하는 것은 비추천. 재현 가능한 페이스:
- 1–2일: Actions에서 2주분 queue / duration 베이스라인 내보내기. Cloud Mac 1대(약 5분 개통)에 Runner 설치,
runs-on: [self-hosted, macos, canary]로 수동 트리거만 - 3–5일:
~/ci/DerivedData와 SwiftPM 캐시 영속화. 동일 main commit으로 A/B 각 5회, P50 기록 - 6–8일: Release / nightly workflow 50%를 자체 label로. 호스팅 runner는 fallback으로 유지
- 9–10일: PR required checks 전부 자체로. 디스크 80% 수위와 산출물 정리 cron 설정
- 11–14일: 대조표 회고, 경영진에 ROI 보고. 상주 1대 vs 일별 burst 임대 결정
오케스트레이션 계층은 GitHub Actions 그대로——YAML, 권한, environment protection 변경 불필요, runs-on만 수정. 기업 Mac CI 리소스 풀 선정의 「오케스트레이션과 실행 분리」와 같은 접근입니다.
최소 Workflow 변경 예
jobs:
ios-build:
# 이전: runs-on: macos-14
ios-build:
runs-on: [self-hosted, macos, ios-pool]
steps:
- uses: actions/checkout@v4
- name: Log queue metrics
run: echo "QUEUE_SEC=${QUEUE_SEC:-0}" >> $GITHUB_STEP_SUMMARY기계 구매를 아직 결정하지 않았다면 일별 M4 Cloud Mac 임대로 2주 대조하면 「팀 전체가 1시간 기다리는」 인건비보다 저렴한 경우가 많습니다.
ROI 개략: 효율 장부가 기계 장부를 덮나?
케이스 A 숫자로 쓸 수 있는 공식(시급 blended $55, 예시용):
- 12명 × 주당 3.7인시 대기 감소 ≈ 44인시/월 ≈ $2,420/월 상당 산출(또는 PR 조기 머지로 충돌 재작업 감소)
- M4 16GB Cloud Mac 2대 월액 ≈ $206($103/대 × 2, 요금 페이지 기준)
- 플랫폼 겸임 운영 ≈ 4–8인시/월(디스크, 인증서, Runner 업그레이드)
개략 계산으로도 순이익은 플러스——다만 소규모 저빈도 빌드(케이스 C)는 맞지 않을 수 있습니다. 자팀 queue P95를 공식에 대입해 판단:
월 효과 ≈ 개발자 수 × 주당 대기 감소 인시 × 4 × 시급 − 기계 월액 − 운영 인시 × 시급릴리스 주에는 3번째 기기를 burst로 추가하고 평시에는 해지——피크 때문에 연중 과금하지 않기. 구매 vs 임대 장기 TCO는 Mac mini 구매 vs Cloud Mac 임대 참고.
이전하지 말아야 할 경우——이전을 위한 이전 피하기
다음 경우 먼저 움직이지 말 것을 권하거나 1주 임대로 검증만:
- 월 macOS Job <30회이고 Queue P95가 항상 <5분——개선 상한이 낮음(케이스 C)
- Runner on-call 담당자 없음——queue보다 디스크 풀 상태가 더 스트레스
- 보안 요건으로 기계가 자사 VPC 내 필수——네트워크와 키 관리를 먼저
- 이전하면 GitHub Actions가 필요 없어진다고 생각——오케스트레이션, 감사, 권한은 플랫폼에 남길 가치가 있음
이전은 수단, 목표는 측정 가능한 대기 시간 감소. 2주 대조에서 PR 피드백 30% 이상 개선이 없으면 Mac 3대 구매보다 workflow 최적화(Job 분할, Archive 빈도 축소)를 먼저.
FAQ
GitHub Actions에서 자체 Mac으로 이전하면 개발 효율이 얼마나 오르나?
고빈도 iOS 팀에서는 PR 피드백 약 70% 단축, queue 거의 0이 일반적. 순수 컴파일은 15%–25%. 저빈도 팀은 한 자릿수 %만——반드시 베이스라인을 먼저.
Mac 1대 추가로 충분한가?
10명 이내·직렬 릴리스면 보통 충분. matrix 테스트나 다중 App 병렬이면 2대 이상과 병렬 상한 설정 권장——캐시 상호 간섭 방지.
자체화 후 Actions 청구는 얼마나 줄어드나?
macOS 분 과금은 60%–90% 감소가 흔함(이전 Job 비율에 따라). 다만 기계 임대·구매와 운영이 늘어남. 총계는 위 ROI 공식으로.
Cloud Mac과 사무실 Mac mini 효율 차이는?
동일 칩·동일 메모리면 컴파일 성능은 비슷. 차이는 네트워크 RTT(의존성 pull, 산출물 업로드)와 NVMe 여부. 코드 호스트와 artifact 저장소에 가까운 노드 선택.
이전이 서명·공증에 영향을 주나?
마법처럼 좋아지지는 않지만 환경이 안정되면 키체인과 프로비저닝 프로파일 드리프트가 줄어 「CI에서만 재현되는」 심야 대응이 간접적으로 감소.
효과가 보이기까지 얼마나 걸리나?
Runner 연결과 캐시 디렉터리 활성화 후 첫 영업일부터 queue 지표에 변화. PR 피드백 루프는 2주 샘플 후 보고.
정리 및 관련 글
GitHub Actions에서 자체 Mac 노드로 이전했을 때 개발 효율 향상은 모호한 「많이 빨라졌다」가 아닙니다——전형적 iOS 팀에서는 PR 피드백 약 70% 단축, 릴리스 처리량 2배가 흔한 규모이며, 대부분은 queue 소멸, 그다음 영속 캐시입니다. 2주 대조 실험, 4가지 지표, ROI 공식으로 경영진이 이해할 숫자를 낼 수 있습니다. 대조가 약하면 Mac 구매보다 workflow 최적화가 이득입니다.