2026년 기업 iOS/macOS CI 선정: GitLab Runner(macOS)와 GitHub Actions 자체 호스팅 Runner 비교 — 독점 원격 Mac 노드 동시성, SSH 계정 격리, 캐시 마운트·운영 FAQ 의사결정 매트릭스
소스가 GitLab이든 GitHub이든, Apple 빌드는 결국 macOS 호스트 한 대(또는 소수 노드)에서 돌아갑니다. 독점 원격 Mac를 CI 노드로 쓸 때 운영자가 가장 많이 맞닥뜨리는 축은 동시 실행, SSH·로그인 계정과 키체인 격리, 캐시·Derived Data 마운트입니다. 이 글은 GitLab Runner와 GitHub Actions self-hosted runner를 같은 전제(단일 물리 Mac, 팀 전용) 아래 놓고 의사결정 매트릭스와 FAQ로 정리합니다.
1. 실행 모델부터 정리: “한 노드에 job이 몇 개까지?”
GitLab Runner는 macOS에서 보통 shell 또는 ssh executor를 씁니다. 동일 러너 프로세스가 concurrent 설정만큼 job을 겹쳐 받을 수 있어, 한 호스트에서 병렬 job 수를 명시적으로 늘리기 쉽습니다. 대신 같은 사용자 홈·같은 키체인·같은 Derived Data 경로를 공유하면 경합이 납니다.
GitHub Actions self-hosted runner는 기본적으로 한 러너 인스턴스가 한 번에 하나의 job을 처리하는 모델에 가깝습니다. 같은 Mac에서 병렬을 원하면 러너를 여러 개 등록(서로 다른 작업 디렉터리·환경)하거나, 워크플로에서 의도적으로 직렬화하는 패턴이 흔합니다. 조직에서 GitHub/GitLab과 메신저까지 한 번에 엮는 원격 Mac 운영을 참고하려면 OpenClaw 기업급 통합: 원격 Mac mini SSH·GitHub/GitLab 연결 가이드의 접근을 CI 계정 경계 설계에 맞춰 응용할 수 있습니다.
2. 독점 원격 Mac에서의 동시성 설계
독점 노드라도 CPU·디스크 I/O·시뮬레이터는 유한합니다. 실무 규칙은 다음과 같이 단순화할 수 있습니다.
- GitLab:
concurrent를 “코어 수 − 여유”로 두고, SPM·xcodebuild가 동시에 두 개 이상 뜨면 RAM·디스크 경합을 모니터링합니다. - GitHub: 러너 수 = 논리적 병렬도. 라벨(
runs-on)을mac-ci-1,mac-ci-2처럼 쪼개 두면 큐잉과 실제 병렬을 분리해 설명하기 쉽습니다. - 둘 다 GUI·시뮬레이터 UI 테스트는 헤드리스 정책과 충돌할 수 있으므로, “스크립트 전용 큐”와 “GUI 허용 큐”를 나누는 편이 안전합니다.
원격 셸·자동화 스크립트를 장기 운용할 때 백그라운드 실행·보안 실수를 줄이려면 OpenClaw & SSH 자동화 심층 실전에서 다루는 세션·launchd 패턴을 참고해 CI 전용 계정의 서비스 경계를 맞추면 좋습니다.
3. SSH·OS 계정 격리: 서명·키체인·홈 디렉터리
macOS CI에서 “격리”는 컨테이너 한 겹으로 끝나지 않는 경우가 많습니다. 핵심은 코드 서명 자격 증명이 어느 사용자 키체인에 묶이는지와, 개발자가 SSH로 같은 호스트에 들어와 디버깅할 때 환경이 러너 job과 섞이지 않는지입니다.
- 전용 계정:
gitlab-runner또는github-runner등 CI 전용 사용자를 두고, 인간용 SSH 계정과 홈을 분리합니다. - 키체인 잠금 해제: 빌드 서명용 인증서는 로그인 키체인 + 접근 제어 또는 CI용 별도 키체인 파일로 관리하고, 재부팅 후에도 동작하도록 문서화합니다.
- SSH executor: GitLab에서 SSH로 원격 Mac에 붙는 경우, 베어메탈에 직접 접속하는 팀 키와 러너가 쓰는 키를 분리하지 않으면 감사 추적이 어렵습니다.
4. 캐시·Derived Data·아티팩트 마운트
GitLab은 프로젝트·job 단위 cache와 artifacts로 원격 저장소(S3 호환, 자체 GitLab 등)에 캐시 계층을 두기 쉽습니다. 로컬 Mac에는 SPM 전역 캐시, DerivedData를 APFS 볼륨이나 심볼릭 링크로 고정해 job 간 재사용을 설계합니다.
GitHub Actions는 actions/cache와 아티팩트 업로드로 유사한 효과를 냅니다. self-hosted에서는 러너 작업 폴더가 job마다 새로 생기는지, 아니면 커스텀 경로를 유지하는지에 따라 캐시 적중률이 크게 달라집니다. Xcode·Derived Data 전략은 팀 런북에 경로 규칙·정리 주기·동시 job 상한을 함께 적어 두면 GitLab·GitHub 양쪽 모두에서 재사용하기 쉽습니다.
5. 의사결정 매트릭스(요약)
아래 표는 “이미 GitLab을 쓰는가 / GitHub가 단일 진실인가” 외에, 운영 성격으로 고를 때 쓰는 요약입니다.
| 기준 | GitLab Runner (macOS) | GHA self-hosted (macOS) |
|---|---|---|
| VCS·이슈 일체화 | GitLab 단일 제품선과 파이프라인·MR 흐름이 자연스럽게 맞물림 | GitHub PR·브랜치 보호·Actions 마켓플레이스와 직접 연결 |
| 단일 Mac 병렬도 조절 | concurrent로 한 러너에서 조절하기 쉬움 |
러너 다중 등록·라벨로 병렬도를 “인스턴스 수”로 표현 |
| 캐시·아티팩트 | 내장 cache/artifacts + 외부 오브젝트 스토어 연동이 일반적 | cache 액션·아티팩트; 호스트 경로 설계가 적중률을 좌우 |
| 거버넌스·감사 | Self-Managed일 때 내부망·RBAC 일원화 용이 | GitHub Enterprise 규칙·OIDC·조직 정책과 정합 |
| 학습 곡선 | .gitlab-ci.yml + Runner 설정 |
워크플로 YAML + 러너 앱·서비스화 |
6. 운영 FAQ
Q. 한 Mac에 GitLab Runner와 GHA Runner를 같이 올려도 되나요?
가능은 하지만, 동시성·키체인·포트·작업 디렉터리 충돌을 피하려면 계정 분리와 총 concurrent/러너 수 상한을 합산해 설계해야 합니다. 프로덕션에서는 한 스택으로 통일하거나, 하드웨어를 논리적으로 나누는 편이 안전합니다.
Q. SSH로 빌드 서버에 붙어 디버깅하면 job이 깨질 수 있나요?
같은 사용자·같은 Xcode 파생 경로를 건드리면 그렇습니다. 인간용 SSH는 별도 계정으로 두고, 필요 시 CI 사용자로만 sudo -u 전환하는 운영 규칙을 권장합니다.
Q. “캐시가 있는데도 Xcode가 매번 풀 빌드처럼 느리다”면?
Indexing·모듈 캐시·시뮬레이터 프리플라이트, 동시 job의 디스크 경합을 의심하세요. 노드당 병렬 수를 줄이는 것만으로도 체감이 좋아지는 경우가 많습니다.
고정 비용 대비 빌드 빈도를 따질 때 Mac mini 렌탈 비용 우위 분석에서 정리한 TCO 관점과 맞춰 보면, self-hosted를 유지할지 호스티드 분 단위로 일부 넘길지 결정이 쉬워집니다.
독점 원격 Mac CI를 macOS·Mac mini에 두는 이유
iOS/macOS 파이프라인은 Xcode·시뮬레이터·코드 서명이 한 OS에 강하게 묶입니다. Apple Silicon Mac mini는 통합 메모리 대역폭으로 동시 xcodebuild에 유리하고, 실사용 환경에 따라 대기 전력이 매우 낮은 편이라 24시간 러너로 두기 부담이 적습니다. macOS는 서버형 Linux보다 UI·서명 스택이 정석에 가깝고, Gatekeeper·SIP·FileVault는 러너에 자격 증명이 있을 때도 방어 깊이를 더합니다.
팀이 독점 노드에서 GitLab과 GitHub 중 하나(또는 둘)를 운영하든, 총소유비용과 설치 공간·소음 측면에서 Mac mini M4는 균형이 잘 맞는 경우가 많습니다. 위 매트릭스로 스택을 고른 뒤 실제 하드웨어에서 검증하고 싶다면, Mac mini M4가 비용 대비 성능 면에서 좋은 출발점입니다. 지금 독점 원격 CI 환경을 점검하고 싶다면 SSHMac 홈에서 구성을 확인해 보세요.