macOS 26.6 업그레이드가 Mac CI를 중단시킬까? 2026년 기업 유지 관리 방안

Xcode 27을 사용해야 하는 노드는 먼저 macOS 요구 사항을 확인해야 합니다. 요구 사항을 충족하지 못하는 기존 노드에서 Xcode만 교체하면 설치 단계 또는 실제 빌드 단계에서 막힐 수 있습니다. Xcode 27의 공식 시스템 요구 사항을 기준으로 프로젝트별 최소 조합을 기록하십시오.

모든 업데이트를 같은 위험으로 취급하면 안 됩니다.

• 백그라운드 보안 업데이트: 업무 중단과 재시작 여부를 별도로 확인합니다.
• 같은 계열의 시스템 업데이트: Runner, Xcode 경로, 의존성 해석을 검증합니다.
• 큰 버전 전환: 도구 체인과 프로젝트 호환성을 별도 시험합니다.
• 관리형 강제 설치: 재시작 시점과 실행 중 작업의 처리 방식을 확인합니다.

Apple은 관리 기기의 소프트웨어 업데이트에 대해 선언형 설정과 설치 동작을 문서화하고 있습니다. 그러나 관리 플랫폼이 실제로 어떤 설정과 상태 회신을 지원하는지는 별도 확인이 필요합니다. 관리형 소프트웨어 업데이트 개요만으로 특정 관리 도구의 구현 상태를 추정해서는 안 됩니다.

이 표에서 온라인 상태는 승인 기준이 아닙니다. 호스트가 온라인이어도 Runner가 작업을 받지 못할 수 있습니다. Runner가 온라인이어도 Xcode를 호출하지 못하거나 서명 키를 읽지 못할 수 있습니다. 기업 승인 기록에는 상태를 나누어 남겨야 합니다.

PR 빌드 노드는 가장 먼저 배수 절차를 적용하기 좋습니다. 다음 순서로 실행하십시오.

1. 노드 라벨 또는 큐 라우팅에서 대상 노드를 제외합니다.
2. 현재 실행 중인 Job 목록과 상태를 저장합니다.
3. 새 Job이 들어오지 않는지 확인합니다.
4. 실행 중인 Job이 성공 또는 실패로 끝날 때까지 기다립니다.
5. Runner 상태, macOS 버전, Xcode 경로를 기록합니다.
6. 대상 노드에 시스템 업데이트를 적용하고 재시작합니다.
7. Runner 자동 시작과 작업 수신 상태를 확인합니다.
8. 깨끗한 의존성 해석과 실제 프로젝트 빌드를 실행합니다.
9. 첫 승인 파이프라인의 로그와 결과물을 보관합니다.

실행 중인 작업을 기다리지 않고 업데이트를 시작하면 시스템이 빌드 프로세스를 종료할 수 있습니다. Apple의 관리형 업데이트 문서에는 설치 예약, 재시작과 강제 실행에 관한 조건이 설명되어 있으므로 소프트웨어 업데이트 적용 방식을 유지 관리 정책과 대조해야 합니다.

한 번에 전체 풀을 올리지 마십시오. 첫 배수에서 Runner 복구, Xcode 호출, 의존성 다운로드, 깨끗한 빌드가 모두 통과한 뒤 다음 일부 노드로 확장합니다. 기업 기록에는 업그레이드 전 버전, 업그레이드 후 버전, 첫 승인 파이프라인, 실패한 단계와 재라우팅 결과를 함께 남겨야 합니다.

생산 서명 노드는 일반 PR 풀과 같은 속도로 관리하면 안 됩니다. 아카이브, 코드 서명, 업로드는 결과물의 진위와 출시 일정에 직접 연결됩니다. 호스트와 Runner가 정상이어도 Keychain 접근이나 인증 정보가 깨지면 배포는 실패합니다.

유지 관리 전에 다음 항목을 확인하십시오.

• 정식 배포 작업을 동결했는지 확인합니다.
• Keychain 잠금 해제와 인증서 개인 키 접근을 검증합니다.
• App Store Connect 인증 정보의 보관 위치와 만료 상태를 확인합니다.
• 업그레이드하지 않은 회귀 노드의 경계를 기록합니다.
• 실패 시 작업을 어느 노드로 되돌릴지 정합니다.

복귀 검증은 실제 아카이브 생성으로 시작해야 합니다. 이어서 코드 서명, 업로드, 감사 로그 보관까지 실행하십시오. 단순히 호스트가 온라인인지, Runner가 연결되었는지만으로 통과 처리하지 마십시오.

생산 서명 풀이 하나뿐이라면 macOS 26.6 CI 업그레이드의 위험은 시스템 호환성보다 복구 경로 부재에서 커집니다. 이 경우 업그레이드하지 않은 노드를 유지하거나, 먼저 원격 Mac 임대 PoC와 복구 시험을 실행해 동일 프로젝트의 검증 경로를 만들어야 합니다.

Apple Silicon 기반 Mac은 업데이트 파일을 내려받는 것과 무인 재시작 후 다시 작업을 받는 것이 같은 문제가 아닙니다. bootstrap token, secure token, 볼륨 소유권, 소프트웨어 업데이트 권한의 관계를 확인해야 합니다. Apple의 bootstrap token 배포 문서를 기준으로 관리 도구의 실제 지원 범위를 검증하십시오.

다음 항목은 문서 확인만으로 끝내지 말고 통제된 재시작 시험으로 확인해야 합니다.

• FileVault 시동 해제가 현장 입력 없이 가능한지 확인합니다.
• 필요한 사용자 세션이 자동으로 준비되는지 확인합니다.
• CI Agent가 재부팅 후 자동 시작되는지 확인합니다.
• 원격 관리 채널이 다시 연결되는지 확인합니다.
• Runner가 새 작업을 받는지 확인합니다.
• 실제 빌드가 끝까지 완료되는지 확인합니다.

특히 “재부팅 후 온라인”과 “생산 작업 완료”는 다른 상태입니다. 복구 시험에서는 두 상태 사이의 실패 지점을 기록하십시오. 관리 플랫폼이 선언형 업데이트를 제공하더라도, 해당 기능이 무인 빌드 노드의 FileVault와 Runner 시작까지 보장한다고 가정해서는 안 됩니다. 선언형 소프트웨어 업데이트 설정 문서를 플랫폼 설정과 함께 검토하십시오.

단일 기계실의 노드만 유지 관리하는 경우에도 모든 노드의 설치 시점을 같은 시간으로 예약하지 마십시오. 여러 지역을 운영한다면 단일 지역 풀, 다른 지역 풀, 공유 서명 노드를 나누어 순서를 정해야 합니다.

미유지 노드로 작업을 보내려면 라벨이나 큐 라우팅을 사용하십시오. 다만 예비 용량을 고정된 노드 수로 정하는 방식은 위험합니다. 다음 두 값을 기업 기록으로 비교해야 합니다.

• 유지 관리 중 빠지는 노드가 처리하던 최대 동시 작업량
• 같은 시간대에 실제로 들어오는 최대 작업량

이 기록 없이 “노드 몇 대를 남기면 충분하다”고 결정할 수 없습니다. 큐 대기 상한도 함께 정하십시오. 상한을 넘으면 새 작업을 계속 받는 대신 유지 관리를 멈추거나 깨끗한 예비 원격 Mac으로 제한된 작업만 전환해야 합니다.

CALMVPS의 기업용 원격 Mac 운영 환경은 이런 유지 관리 창의 임시 빌드 용량이나 복구 시험 대상으로 검토할 수 있습니다. 다만 검증되지 않은 원격 Mac을 생산 서명 노드로 즉시 승격하지 마십시오. 프로젝트 빌드, 인증 정보, 업로드 권한을 먼저 분리해 확인해야 합니다.

보안 위험이 높다는 이유만으로 전체 생산 풀을 동시에 재시작하면 출시 장애가 발생할 수 있습니다. 반대로 빌드 호환성만 걱정해 긴급 패치를 무기한 미루는 것도 적절하지 않습니다. 다음 네 가지를 함께 판단하십시오.

• 보안 위험의 긴급성
• 생산 작업에 미치는 영향
• Xcode와 의존성의 호환성
• 실패 시 되돌릴 수 있는 경로

조건식 결정 목록

• 보안 위험이 높고, 시험 노드의 실제 빌드와 복구가 통과하면 순차 적용을 가속합니다.
• 보안 위험이 높지만 시험 노드에서 서명 또는 업로드가 실패하면 생산 서명 노드는 보류하고 깨끗한 예비 노드를 검증합니다.
• 보안 위험이 낮고, 업데이트 후 도구 체인 결과가 확인되지 않았다면 정기 유지 관리 창까지 기다립니다.
• FileVault 해제나 Runner 자동 시작이 확인되지 않으면 무인 노드의 강제 설치를 중단합니다.
• 큐가 예비 용량을 초과하면 새 배치를 열지 말고 작업 라우팅 또는 임시 원격 Mac으로 복구 경로를 확보합니다.
• 회귀 노드가 없고 실제 아카이브 검증도 완료되지 않았다면 생산 서명 노드의 업그레이드를 승인하지 않습니다.

긴급 패치라도 검증 증거가 없는 전체 풀 자동 설치는 피해야 합니다. Apple의 소프트웨어 업데이트 강제 실행과 재시작 조건은 관리형 업데이트 명령 문서에서 확인하고, 실제 관리 플랫폼의 상태 회신과 비교하십시오.

다음 체크리스트를 티켓이나 변경 기록에 붙여 사용하십시오.

• [ ] Xcode 27을 요구하는 프로젝트와 기존 도구 체인을 분리했습니다.
• [ ] 대상 노드의 macOS와 Xcode 경로를 업그레이드 전에 기록했습니다.
• [ ] 새 Job 차단과 실행 중 Job 배수를 확인했습니다.
• [ ] 첫 노드에서 Runner, Xcode 호출, 깨끗한 빌드를 확인했습니다.
• [ ] 서명 노드의 Keychain과 인증서 개인 키를 확인했습니다.
• [ ] 아카이브, 서명, 업로드, 감사 기록을 모두 검증했습니다.
• [ ] Apple Silicon 노드의 FileVault와 무인 재시작을 시험했습니다.
• [ ] 지역별 큐 라우팅과 대기 상한을 설정했습니다.
• [ ] 미유지 회귀 노드 또는 임시 복구 노드를 지정했습니다.
• [ ] 실패 시 중단 조건과 책임자를 기록했습니다.

현재 Mac CI 환경에 여유 노드가 없으면, 기존 풀에서 일부를 억지로 빼는 방식보다 먼저 단기 원격 Mac에서 동일 프로젝트의 실제 빌드와 복구 시험을 실행하는 편이 안전합니다. 직접 보유한 Mac mini는 물리적 통제와 장기 고정 부하에는 유리하지만, 유지 관리 창의 임시 용량을 빠르게 늘리기 어렵고 하드웨어 장애와 교체 책임도 직접 부담해야 합니다. CALMVPS의 원격 Mac은 이런 단기 검증, 유지 관리 피크, 회귀 노드 확보에 맞는 선택지입니다. 다만 지속적인 고정 부하, 특수 물리 장치, 현장 전용 연결이 필요한 환경이라면 직접 보유 방식이 더 적합할 수 있습니다.

먼저 CALMVPS의 한국어 원격 Mac 신청 경로에서 사용 가능한 환경을 확인하고, 정식 전환 전에는 실제 프로젝트의 빌드·서명·업로드 결과를 승인 증거로 남기십시오.