처음부터 여러 대를 구매하면 실제 병목을 알기 어렵습니다. 프로젝트 수보다 다음 조건을 먼저 기록해야 합니다.

• 사용할 Xcode 버전
• 하루와 주간 배포 빈도
• 피크 시간의 동시 작업 수
• 외부 기여가 있는 저장소의 비율
• 테스트 서명과 배포 서명의 분리 여부
• 원격 복구가 필요한 시간대
• 빌드 산출물과 캐시의 보존 정책

첫 노드는 모든 작업을 처리하는 만능 서버가 아닙니다. 신뢰된 저장소의 빌드와 테스트만 받는 작은 실험 노드로 정의해야 합니다. 배포 서명까지 같은 노드에서 처리하려면 보호된 브랜치, 보호된 태그, 별도 네트워크와 승인 절차가 추가되어야 합니다.

GitLab은 Runner를 인스턴스, 그룹, 프로젝트 범위로 등록할 수 있습니다. 등록 범위가 넓을수록 편리하지만, macOS 호스트에 접근할 수 있는 프로젝트도 늘어납니다. 기업 환경에서는 프로젝트 Runner 또는 제한된 그룹 Runner부터 시작하는 편이 최소 권한 원칙에 가깝습니다. Runner 등록 범위에 관한 공식 안내에서 세 범위를 구분해 설명합니다.

주의: Shell executor는 작업을 호스트 운영 체제에서 직접 실행합니다. 격리 능력이 제한적이므로 신뢰할 수 있는 코드에만 사용해야 합니다. 공용 저장소와 서명 노드를 같은 태그로 묶지 마십시오.

macOS용 GitLab Runner는 일반적인 리눅스 데몬처럼 시스템 전체에서 실행되지 않습니다. 공식 지원 방식은 로그인한 사용자의 LaunchAgent입니다. macOS 실행 방식과 설치 순서를 먼저 확인한 뒤 조직의 표준 이미지에 반영하십시오.

이 구조에는 세 가지 중요한 결과가 있습니다.

• Runner는 현재 로그인한 사용자 권한으로 실행됩니다.
• 사용자가 로그아웃하면 Runner도 중지될 수 있습니다.
• 사용자의 키체인과 화면 세션에 접근할 수 있어 iOS 시뮬레이터와 코드 서명에 활용됩니다.

설정 파일의 기본 위치도 시스템 경로가 아니라 ~/.gitlab-runner/config.toml입니다. 재부팅 뒤 다시 온라인 상태가 되려면 자동 로그인과 사용자 세션 복구를 검토해야 합니다. 단순히 SSH 접속이 된다는 사실만으로는 충분하지 않습니다.

준비 순서는 다음과 같이 고정하는 것이 좋습니다.

1. 빌드 전용 macOS 사용자 계정을 만듭니다.
2. 원격 관리용 SSH와 화면 접속 경로를 각각 준비합니다.
3. 관리자 계정과 빌드 계정의 사용 범위를 분리합니다.
4. 내부 저장소, 패키지 저장소, GitLab 연결에 필요한 네트워크만 허용합니다.
5. 디스크 암호화를 켜고 복구 키 보관 책임자를 정합니다.
6. Xcode와 명령줄 도구를 설치합니다.
7. 시스템 버전, Xcode 버전, SDK, Ruby, 패키지 관리자와 의존성 버전을 기록합니다.

Apple Silicon을 선택하더라도 Intel 전용 도구나 오래된 플러그인이 남아 있을 수 있습니다. 처음부터 호환된다고 가정하지 말고 대표 프로젝트를 실제로 빌드해야 합니다. 반대로 오래된 의존성이 없다면 Apple Silicon 노드를 별도 태그로 분리해 향후 교체와 확장을 쉽게 만들 수 있습니다.

FileVault를 사용하는 환경에서는 부팅 후 인증과 무인 복구 사이의 관계도 확인해야 합니다. Apple은 FileVault가 저장 장치의 데이터를 암호화하며, 부팅 과정에서 사용자 인증이 필요할 수 있다고 설명합니다. FileVault 보안 문서를 기준으로 복구 절차를 작성하십시오.

등록 단계에서는 먼저 실행 범위를 정한 뒤 태그를 설계해야 합니다. 태그는 단순한 이름이 아니라 작업이 어느 호스트로 갈지 결정하는 라우팅 기준입니다. Runner 구성과 태그 공식 문서를 기준으로 프로젝트 표준을 만드십시오.

예시는 다음처럼 단순하게 시작할 수 있습니다.

ios_build:
  stage: build
  tags:
    - macos
    - xcode-test
  script:
    - xcodebuild -scheme 앱이름 -sdk iphoneos build

실제 태그는 다음 기준으로 나누는 편이 낫습니다.

• macos: macOS 작업 여부
• apple-silicon: 칩 구조
• xcode-현재버전: Xcode 호환성
• test-signing: 테스트 서명 전용
• release-signing: 배포 서명 전용

배포 서명을 사용하는 Runner는 보호된 브랜치와 보호된 태그만 처리하도록 설정해야 합니다. 일반 개발 브랜치가 배포용 인증서에 접근할 수 있으면, 프로젝트 권한을 세밀하게 나눈 의미가 약해집니다. 보호된 브랜치와 태그 설정은 민감한 배포 작업 제한 안내를 함께 확인하십시오.

현재 등록 방식에서는 오래된 등록 토큰 사용 여부도 점검해야 합니다. 새 Runner 인증 토큰 흐름을 기준으로 관리 화면과 자동화 문서를 정리하면, 담당자 변경이나 노드 교체 때 토큰의 출처를 추적하기 쉽습니다. 새 Runner 등록 흐름을 배포 절차에 포함하십시오.

첫 파이프라인은 복잡한 배포 자동화보다 실패 원인을 좁히는 데 집중해야 합니다. 다음 순서로 진행하십시오.

1. 저장소를 가져옵니다.
2. Xcode 명령줄 도구가 선택한 경로를 확인합니다.
3. 의존성을 설치합니다.
4. 단위 테스트를 실행합니다.
5. xcodebuild로 빌드합니다.
6. 테스트 결과와 산출물을 보관합니다.
7. 실패 로그에 운영 체제, Xcode, SDK 정보를 남깁니다.

GitLab의 macOS Runner 설정 문서에는 Bash 선택, Xcode 설치, xcodebuild -runFirstLaunch, xcode-select 설정과 Shell executor 등록 흐름이 정리되어 있습니다. 조직에서는 이 절차에 의존성 고정과 로그 보존 규칙을 추가해야 합니다.

서명 자료는 빌드 자료와 분리합니다

테스트 빌드와 앱스토어 배포 빌드는 같은 신뢰 경계를 사용하면 안 됩니다. 테스트 노드는 제한된 인증서만 사용하고, 배포 노드는 보호된 태그와 승인된 파이프라인만 받도록 구성합니다.

권장 흐름은 다음과 같습니다.

• 보호된 CI/CD 변수에서 인증서와 프로비저닝 프로파일을 가져옵니다.
• 작업 중 임시 키체인을 생성합니다.
• 필요한 인증서와 개인 키를 가져옵니다.
• 빌드와 서명을 수행합니다.
• 작업 완료 뒤 키체인과 임시 파일을 삭제합니다.
• 실패 로그에 인증서 본문이나 개인 키가 남지 않았는지 확인합니다.

Apple은 코드 서명에 인증서뿐 아니라 완전한 디지털 신원과 개인 키가 필요하다고 설명합니다. 인증서 파일만 복사하면 서명이 되지 않는 이유입니다. Apple 코드 서명 자료를 보안 검토 자료로 사용하십시오.

캐시는 빌드 시간을 줄일 수 있지만 프로젝트 간 잔여 파일을 만들 수 있습니다. 의존성 캐시는 범위를 좁게 잡고, 서명 자료와 작업 디렉터리는 캐시에 넣지 않는 것이 안전합니다. 작업이 끝난 뒤 임시 키체인, 프로파일, 빌드 디렉터리가 남아 있지 않은지 검사하십시오.

macOS Runner가 계속 온라인이어야 하는 이유

Runner가 로그인한 사용자의 세션에서 실행되므로 로그아웃, 재부팅, 비밀번호 변경, 자동 로그인 해제에 따라 상태가 달라질 수 있습니다. 다음을 직접 시험해야 합니다.

• 정상 재부팅 뒤 Runner가 다시 등록되는가
• 화면 세션이 복구되는가
• 키체인이 잠긴 상태에서 서명이 실패하는가
• SSH와 화면 접속이 각각 가능한가
• GitLab 화면의 온라인 표시와 실제 작업 수신이 일치하는가

여러 프로젝트 공유의 조건

여러 프로젝트가 한 Runner를 써도 되는지는 프로젝트 수가 아니라 신뢰 경계로 결정합니다. 같은 조직의 내부 저장소라도 외부 병합 요청을 허용하거나 사용자 제공 스크립트를 실행한다면 위험도가 달라집니다.

다음 조건을 모두 만족할 때만 공유를 고려하십시오.

• 모든 프로젝트가 신뢰된 저장소입니다.
• 배포 서명 노드와 테스트 노드가 분리되어 있습니다.
• 작업 후 디렉터리와 캐시를 정리합니다.
• 네트워크 접근 범위가 문서화되어 있습니다.
• 로그와 인증서 사용 기록을 감사할 수 있습니다.

자동 복구 검증

콘솔에서 Runner가 온라인이라고 표시되어도 실제 빌드가 성공한다는 뜻은 아닙니다. 재부팅 후 작은 테스트 작업을 자동으로 실행하고, 작업 수신부터 산출물 업로드까지 확인해야 합니다.

비밀번호 변경, 운영 체제 업데이트, Xcode 교체 뒤에도 같은 점검을 반복하십시오. 특히 키체인 잠금 상태와 화면 세션이 달라지면 명령줄 빌드는 성공해도 서명 단계에서 실패할 수 있습니다.

다음 조건에 따라 선택하면 됩니다.

• 피크 부하가 낮고 장기간 같은 Xcode만 사용한다면 상시 보유 노드를 검토합니다.
• 배포 빈도가 특정 기간에 집중된다면 기간형 원격 Mac을 먼저 사용합니다.
• 현장 운영 인력이 부족하다면 원격 복구와 교체 절차가 있는 원격 Mac을 우선 검토합니다.
• 물리 장비, 사내망 직접 연결, 특수 보안 장치가 필요하다면 자체 보유 노드가 더 적합할 수 있습니다.
• Xcode 버전이 여러 개이고 프로젝트별 신뢰 수준이 다르다면 한 대의 대형 호스트보다 역할별 노드 구성이 낫습니다.
• 대기 시간이 반복적으로 길어지지만 부하가 일시적이라면 상시 증설보다 기간형 확장을 먼저 비교합니다.

기업용 Mac 인프라의 TCO는 장비 가격만으로 계산하면 안 됩니다. 아래 변수를 입력해야 합니다.

비교식은 다음처럼 단순하게 시작하십시오.

연간 TCO = 장비 감가 + 운영 인력 + 네트워크 + 예비 장비 + 장애 비용 + 보안 관리 비용

원격 Mac 비용 = 사용 기간 요금 + 데이터 전송 비용 + 내부 운영 비용 + 추가 보안 통제 비용

가격과 구성은 계약 시점과 지역에 따라 달라지므로 고정된 절감률을 가정하면 안 됩니다. KVMNODE의 Mac 원격 이용 요금 안내에서 실제 조건을 확인한 뒤, 위 표에 조직의 내부 비용을 더해 비교하십시오.

다음 항목 중 하나라도 실패하면 생산 투입을 미루는 것이 좋습니다.

• 대표 프로젝트가 깨끗한 작업 공간에서 반복 빌드되는가
• 테스트 서명과 배포 서명이 분리되는가
• 보호된 브랜치와 태그만 배포 Runner에 도달하는가
• 재부팅 뒤 사용자 세션과 Runner가 복구되는가
• 디스크 암호화와 복구 키 관리 책임자가 정해졌는가
• 작업 로그에 비밀 값이 노출되지 않는가
• Xcode 버전 변경 시 영향 범위가 기록되는가
• 피크 대기 시간과 동시 작업 수를 측정했는가
• 장애 시 SSH와 화면 접속으로 복구할 수 있는가

용량이 늘어난 뒤에도 노드 하나에 모든 역할을 모으면 단일 장애 지점이 남습니다. 테스트, 릴리스, 오래된 Xcode, 높은 보안 등급을 각각 태그와 노드 그룹으로 나누십시오. 팀의 운영 기준을 정리할 때는 KVMNODE 원격 Mac 안내도 함께 참고할 수 있습니다.

모든 조건을 통과한 뒤에도 첫 운영 기간에는 작업 대기 시간, 성공률, 빌드 시간, 디스크 증가량, 재부팅 복구 기록을 계속 남겨야 합니다. 팀 인원만 보고 Mac 대수를 정하면 과잉 구매나 지속적인 대기열을 피하기 어렵습니다.

현재 장비를 직접 구매하는 방식은 장기 고정 부하에는 유리할 수 있지만, 초기 자본 지출과 교체 책임이 따릅니다. 사내 Mac을 공유하면 Xcode 버전 충돌, 서명 자료 잔류, 담당자 부재 시 복구 지연도 생깁니다. 반면 KVMNODE의 원격 Mac은 단일 노드 시험과 피크 기간 확장을 먼저 진행한 뒤 실제 대기 시간과 복구 기록을 기준으로 계약 기간을 정할 수 있습니다.

따라서 단일 노드 파이프라인을 통과시킨 다음, 피크 동시성·Xcode 버전·배포 빈도·보안 경계를 정리해 원격 Mac 시범 환경을 구성하는 순서가 안전합니다. 실제 기록으로 장기 구매, 기간형 렌탈, 혼합 구성을 비교하면 불필요한 장비 확보를 피하면서도 iOS 배포 흐름을 안정적으로 운영할 수 있습니다.