빌드가 Xcode 27을 요구하는데 GitLab 호스티드 맥 실행기 목록에는 Xcode 26까지만 보인다면, 지금 전체 이전을 멈춰야 합니다.
2026년 9월 5일 기준으로 GitLab Hosted macOS Runner는 Xcode 27 생산 이전의 유일한 기반이 될 수 없습니다. 안정된 도구 체인과 비민감 검증은 호스티드 실행기에 두고, Xcode 27 시험·사설망 작업·생산 서명은 전용 자가 관리 맥으로 분리하는 이중 경로가 가장 안전합니다.
SECTION 01 이 글을 읽어야 하는 사람
Xcode 27 적응 계획을 세우면서 GitLab 호스티드 이미지의 지원 범위를 확인하려는 개발 생산성 책임자에게 적합합니다. 코드 서명, 내부 의존성, 네트워크 격리를 심사해야 하는 기업 IT 책임자도 대상입니다.
호스티드 계산 사용량과 자가 관리 맥의 전체 비용을 비교해야 하는 기술 총괄과 구매 담당자라면, 아래 조건 분기부터 적용하면 됩니다.
먼저 할 일: 2026년 9월 5일 기준 이미지 목록, Xcode 버전, 사내 서명 정책을 각각 문서로 분리해 확인하십시오. 세 항목을 하나의 “지원 여부”로 묶으면 잘못된 이전 결정이 나옵니다.
SECTION 02 버전 지원은 왜 즉시 이전의 기준이 되나요?
GitLab 공식 문서에서 Hosted macOS Runner는 아직 베타 상태이며, 공개된 이미지에는 macOS 15와 Xcode 16 조합, macOS 26과 Xcode 26 조합이 표시되어 있습니다. Xcode 27 이미지는 해당 목록에 없습니다. 반면 Apple은 Xcode 27 베타 계열의 릴리스 노트를 공개하고 있습니다. 따라서 “Apple이 Xcode 27을 제공한다”와 “GitLab 호스티드 이미지에서 Xcode 27을 선택할 수 있다”는 서로 다른 사실입니다. GitLab의 호스티드 맥 실행기 목록과 Apple의 Xcode 27 릴리스 노트를 따로 대조해야 합니다.
GitLab Hosted macOS Runner에서 Xcode 27은 언제 쓸 수 있나요?
공식 이미지 목록에 Xcode 27이 추가되고, 해당 이미지의 상태와 수명이 문서에 반영될 때까지 확정된 날짜는 없습니다. 커뮤니티 게시물이나 언론의 예상 시점은 이미지 출시일의 근거로 사용할 수 없습니다. GitLab이 이미지와 서비스 상태를 갱신했는지 직접 확인하는 방식만 허용해야 합니다.
여기서 다음 네 상태를 분리해 기록하십시오.
- Hosted macOS Runner 서비스가 베타인지 정식인지
- macOS 이미지가 현재 선택 가능한지, 종료 예정인지
- Xcode 27이 베타·출시 후보·정식 중 어느 상태인지
- 자가 관리 Runner 애플리케이션이 어떤 맥에서 실행되는지
GitLab Runner를 맥에 설치하는 절차는 공식 macOS 설치 문서를 기준으로 진행하십시오. 다만 설치 성공은 운영 적합성의 증거가 아닙니다. 등록 토큰의 보관, 실행 계정, 자동 업데이트, 로그 보존과 장비 교체 절차까지 별도로 승인해야 합니다.
SECTION 03 환경을 통제할 수 있는 범위
호스티드 이미지는 빠르게 시작할 수 있지만, 사전 설치된 Xcode와 도구 목록에 따라 선택 범위가 정해집니다. 이미지 선택이 가능하더라도 기업이 업데이트 시점을 완전히 통제한다는 뜻은 아닙니다. 이미지가 바뀌면 컴파일러, 시뮬레이터 런타임, 패키지 관리자 동작이 달라질 수 있습니다.
자가 관리 맥은 Xcode 27 베타, 여러 시뮬레이터 런타임, 사내 도구를 자유롭게 설치할 수 있습니다. 그러나 자유로운 설치는 환경 일관성을 자동으로 만들지 않습니다. 다음 기록이 없으면 전용 장비도 재현 가능한 빌드 노드가 아닙니다.
- Xcode와 명령줄 도구의 정확한 버전
- 설치한 시뮬레이터 런타임과 SDK 목록
- 의존성 파일과 패키지 잠금 상태
- 인증서·프로파일의 식별자와 만료 관리 기록
- 이미지 또는 장비 변경 시점과 승인자
- 같은 커밋을 다시 빌드했을 때의 산출물 비교 결과
GitLab macOS Runner의 호스티드 방식과 자가 관리 방식 중 어느 쪽이 낫나요?
버전이 고정된 일반 테스트와 변동이 큰 검증 작업은 호스티드 방식이 운영 부담을 줄입니다. Xcode 27 시험, 특수 런타임, 내부 도구, 생산 서명이 함께 필요하면 자가 관리 맥이 적합합니다. 대부분의 기업은 두 방식을 같은 노드 풀로 섞지 않고, 작업의 민감도와 버전 요구에 따라 분리하는 편이 안전합니다.
SECTION 04 두 번째 기준: 서명과 작업 격리를 어떻게 나눌까요?
일반 컴파일과 테스트는 일회성 작업 환경에서도 수행할 수 있지만, App Store 제출용 서명은 다른 기준으로 다뤄야 합니다. 작업 환경에 관리자 권한이 있거나, 인증서와 프로파일을 작업 변수로 주입하는 경우에는 로그·캐시·임시 파일에 비밀 정보가 남지 않는지 검증해야 합니다.
호스티드 맥에서 App Store 정식 서명을 맡겨도 되나요?
기업 보안 정책과 공급자 계약이 임시 실행 환경, 관리자 권한, 비밀 정보 주입, 로그 보존, 작업 후 삭제를 명시적으로 허용하지 않는다면 생산 서명을 맡기지 않는 편이 맞습니다. 기본 분류는 일반 빌드와 비민감 테스트는 호스티드 풀, 정식 서명은 감사가 끝난 전용 자가 관리 맥입니다.
자가 관리 전용 노드는 통제력이 높지만 책임도 늘어납니다. 다음 항목을 운영 증거로 남겨야 합니다.
- 서명 전용 계정과 일반 빌드 계정의 분리
- Keychain 잠금과 인증서 접근 권한
- 프로비저닝 프로파일의 발급·폐기 기록
- 배포 계정의 최소 권한과 다중 승인
- 작업 공간, 캐시, 임시 파일의 정리 결과
- 노드 장애나 인증서 노출 시 즉시 격리하는 절차
GitLab 공식 호스티드 실행기 설명은 실행 환경의 격리 방식과 사용 조건을 확인하는 출발점입니다. 하지만 그것만으로 사내 감사 통과나 Apple 계정의 운영 책임 이전을 의미하지는 않습니다. 서명 작업은 보안팀이 실제 로그와 삭제 결과를 검토한 뒤 허용해야 합니다.
SECTION 05 세 번째 기준: 사설망 접근은 어떤 증거로 판단하나요?
코드를 가져올 수 있다는 사실만으로 전체 빌드가 가능한 것은 아닙니다. 사설 패키지 저장소, 내부 API, 고정 출구 주소, 프록시, 허용 목록, 사내 인증 서비스 중 하나라도 호스티드 환경에서 접근할 수 없으면 파이프라인은 중간 단계에서 멈춥니다.
자가 관리 맥은 기업 네트워크 안에 두거나 승인된 연결 경로를 사용할 수 있어 사설 의존성에 유리합니다. 대신 네트워크가 넓어질수록 공격 표면과 관리 책임도 커집니다. 다음 자료가 모두 있어야 네트워크 적합성을 승인할 수 있습니다.
- 소스 저장소에서 맥 실행기까지의 네트워크 흐름도
- 패키지 저장소·서명 서비스·알림 서비스의 접속 지점 목록
- 프록시와 방화벽 허용 규칙
- 접근 실패 시각, 주소, 오류가 담긴 실행 로그
- 데이터 보존과 지역 규칙에 대한 보안팀 서명
사설망 의존성이 있으면 언제 자가 관리 맥으로 돌아가야 하나요?
내부 저장소가 고정 출구 주소나 사내 인증을 요구하고 호스티드 실행기에서 이를 보장할 수 없다면 자가 관리 맥으로 분기해야 합니다. 공개 저장소에서 코드를 내려받는 작업이라도, 빌드 중 내부 서비스에 접근한다면 같은 기준을 적용해야 합니다.
SECTION 06 네 번째 기준: 대기열과 처리량은 어떻게 산정하나요?
호스티드 실행기는 수요가 몰릴 때 대기 시간이 발생할 수 있고, 비용은 실행 시간뿐 아니라 GitLab의 계산 사용량 규칙에 따라 집계됩니다. 최신 계산 규칙은 GitLab Compute Minutes 문서에서 확인해야 합니다. 구독 등급이나 정책이 바뀔 수 있으므로 과거의 분당 비용을 고정값처럼 사업계획서에 넣으면 안 됩니다.
자가 관리 맥은 사용료 대신 장비 점유, 유휴 시간, 장애 대응, macOS와 Xcode 유지 관리가 비용으로 나타납니다. 한 대의 빠른 빌드 기록만으로 필요한 노드 수를 정하면 안 됩니다. 실제 업무를 다음 조합으로 재현하십시오.
- 일반 Pull Request 빌드
- 단위 테스트와 UI 테스트
- Xcode 아카이브
- 서명 포함 배포 후보 빌드
- 캐시가 비어 있는 최초 실행
- 캐시가 유지된 반복 실행
계산은 다음처럼 변수로 두는 편이 안전합니다.
- 월간 호스티드 비용 = 실제 계산 사용량 × 계약상 계산 단가
- 자가 관리 월비용 = 맥 임대 또는 구매의 월 환산액 + 유지 관리 시간 비용 + 네트워크·보안 운영 비용
- 유효 처리량 = 관찰 기간 동안 성공한 작업 수 ÷ 실행기 점유 시간
- 필요 여유 용량 = 피크 동시 작업량 − 현재 처리 가능한 동시 작업량
대기, 실행, 실패 후 재시도 시간을 각각 기록하십시오. Runner Fleet Dashboard 문서를 사용하면 실행기 상태와 작업 분포를 관찰할 수 있지만, 기업 프로젝트의 실제 용량 결론은 자체 로그와 청구서로 확정해야 합니다.
SECTION 07 다섯 번째 기준: 기업용 TCO에 포함할 항목
기업용 Mac 인프라 TCO는 호스티드 청구서와 맥 장비 가격만 비교하면 안 됩니다. 다음 항목을 같은 기간으로 환산해야 합니다.
- 호스티드 계산 사용량과 초과 사용 비용
- 자가 관리 맥의 구매 또는 임대 비용
- Xcode와 시뮬레이터 런타임 관리에 드는 인력 시간
- 인증서, Keychain, 계정 분리와 감사 비용
- 사설망 연결과 고정 출구 관리 비용
- 장애 복구, 예비 장비, 재빌드에 따른 중단 비용
- 캐시 손실과 작업 재시도에 따른 생산성 손실
GitLab의 호스티드 실행기 설명은 사용량과 실행기 운영 경계를 확인하는 자료로 사용할 수 있습니다. 반대로 자가 관리 맥 비용은 기업의 장비 가격, 계약 기간, 담당 인력, 복구 목표에 따라 달라지므로 공개 단일 가격으로 일반화할 수 없습니다.
GitLab 자가 관리 맥의 비용은 어떻게 계산해야 하나요?
장비의 월 환산 비용에 운영 인력, 보안 관리, 사설망, 예비 용량과 장애 복구 비용을 더한 뒤, 실제 성공 작업 수로 나누십시오. 호스티드 방식은 계산 사용량과 대기·재시도 비용을 더해 같은 작업 단위로 비교해야 합니다. 장비 단가만 비교하면 자가 관리 방식이 실제보다 저렴하게 보입니다.
팀이 Xcode 27 시험 장비를 직접 구매하기보다 일정 기간 원격 맥을 임대해 GitLab Runner를 연결하면, 초기 장비 확보와 회수 부담을 분리할 수 있습니다. 다만 장기적으로 안정된 고부하가 계속되고 물리 포트, 로컬 주변 장치 또는 직접 보관이 필요하다면 구매가 더 적합할 수 있습니다. 임대 후보를 비교할 때는 VPSNIX 요금 안내에서 계약 조건을 확인한 뒤, 실제 파이프라인 로그와 보안 승인 결과를 함께 검토해야 합니다.
SECTION 08 구매 결정을 위한 조건 확인 목록
아래 항목은 작업별로 체크하십시오. 모든 조건을 한 노드에 억지로 적용하지 말고, 표시 결과에 따라 Runner 태그와 접근 정책을 나누는 방식이 적합합니다.
- [ ] Xcode 27이 필요하고 공식 호스티드 이미지에 없다면 자가 관리 Apple Silicon 맥을 선택합니다.
- [ ] 공개 의존성만 사용하고 서명이 필요 없다면 호스티드 Runner를 우선 검토합니다.
- [ ] 사설 패키지 저장소, 고정 출구 주소 또는 내부 인증이 필요하다면 승인된 네트워크의 자가 관리 맥을 선택합니다.
- [ ] 정식 App Store 서명과 배포 계정이 포함되면 감사된 전용 노드로 분리합니다.
- [ ] 작업량이 짧은 기간에 급증하고 도구 체인이 안정적이면 호스티드 실행기를 탄력 용량으로 사용합니다.
- [ ] 하루 종일 일정한 고부하가 발생하고 장비 운영 인력이 있다면 자가 관리 풀의 TCO를 계산합니다.
- [ ] Xcode 27 시험과 안정 버전 검증이 동시에 필요하면 서로 다른 Runner 태그와 접근 정책을 둔 혼합 구성을 선택합니다.
- [ ] Xcode 27 정식 이미지가 추가되면 동일 커밋, 동일 테스트, 동일 서명 정책으로 재검증한 뒤에만 생산 작업을 이동합니다.
SECTION 09 조건 분기로 최종 노드 구성을 결정하세요
Xcode 27이 정식으로 제공되기 전에 별도 GitLab Runner를 만들어야 하나요?
Xcode 27 시험이 필요하다면 별도 전용 Runner를 먼저 만드는 편이 좋습니다. 이는 호스티드 이미지의 출시를 기다리지 않고 버전 고정, 서명 격리, 사설망 연결을 검증하기 위한 PoC 장치입니다. 단, 시험 Runner를 곧바로 생산 서명 노드로 승격하지 말고 보안 승인과 복구 검증을 거쳐야 합니다.
최소한 다음 일곱 단계를 순서대로 실행하십시오.
- GitLab 프로젝트에서 Xcode 버전, 서명 여부, 내부 의존성, 예상 동시 작업을 목록화합니다.
- 호스티드 이미지와 자가 관리 맥의 도구 체인 목록을 같은 형식으로 기록합니다.
- 실제 Pull Request, 테스트, 아카이브, 서명 작업을 포함한 대표 파이프라인을 정의합니다.
- 대기·실행·재시도·복구 시간을 기록하고, 캐시 유무에 따른 결과를 분리합니다.
- 네트워크 흐름도와 비밀 정보 처리 로그를 보안팀에 제출합니다.
- 계산 사용량과 자가 관리 비용을 같은 작업량 기준으로 환산합니다.
- 결과에 따라 일반 검증, Xcode 27 시험, 사설망 작업, 생산 서명에 Runner 태그를 배정합니다.
현재 호스티드 방식은 이미지 버전 공백, 업데이트 시점 통제 부족, 사설망과 서명 정책의 불확실성이 약점입니다. 반대로 자가 관리 맥은 장비·운영·보안·복구 책임을 직접 부담해야 하고, 유휴 용량까지 기업이 비용으로 떠안습니다. 그래서 지금 필요한 답은 한쪽을 전부 선택하는 것이 아니라, 안정된 작업은 호스티드로 두고 Xcode 27과 민감 작업은 독립 원격 맥으로 분리하는 것입니다.
호스티드 이미지가 Xcode 27을 포함할 때까지는 이 조건 확인 목록으로 작업을 나눈 뒤, 부족한 영역에만 전용 원격 맥을 연결해 GitLab Runner PoC를 진행하십시오. 그 과정에서 실제 빌드, 대기, 복구 기록을 남겨야 하므로 필요하면 VPSNIX 도움말 센터의 운영 조건도 함께 확인할 수 있습니다. 안정적인 장기 고부하나 물리 장치가 필요한 조직은 직접 구매가 더 맞을 수 있지만, Xcode 27 시험이나 일시적인 CI 용량 확장처럼 기간과 수요가 불확실한 경우에는 원격 Mac 임대가 초기 투자와 회수 부담을 줄이는 현실적인 선택이 됩니다.