Apple은 macOS 27.0에서 기존 소프트웨어 업데이트 명령과 업데이트 조회, 권장 버전 주기 설정 및 관련 제한이 더 이상 동작하지 않는다고 확인했습니다. Apple의 기기 관리 업데이트 문서에 명시된 변경입니다.

증상 → MDM 콘솔에는 명령이 전송됐지만 macOS 27 노드가 기존 업데이트 절차를 실행하지 않습니다.
가장 빠른 해결 → 기기 업그레이드보다 먼저 선언형 소프트웨어 업데이트로 제어면을 옮기고, 정책 적용·강제 설치·상태 회신·원격 복구를 각각 통과시켜야 합니다.

이 글은 원격 맥 기기를 관리하고 macOS 27 도입 범위를 정해야 하는 IT 책임자를 위한 런북입니다. MDM과 기기 규정을 운영하는 플랫폼 엔지니어, iOS CI/CD 배포 SLA를 지켜야 하는 기술 책임자에게 특히 유용합니다.

변경 범위부터 측정하기

이번 마이그레이션의 핵심은 운영체제 업그레이드 자체가 아닙니다. 업데이트를 지시하고 결과를 증명하는 macOS 27 MDM 업데이트 명령 마이그레이션입니다.

기존 환경을 다음처럼 쪼개어 기록하십시오.

  • 업데이트 명령을 기기에 직접 보내는 단계
  • 사용 가능한 업데이트와 권장 버전을 조회하는 단계
  • 업데이트 연기와 알림을 설정하는 단계
  • 특정 버전 설치를 강제하는 단계
  • 설치 완료 여부를 감사 자료로 수집하는 단계
  • 재시작 뒤 MDM과 CI 서비스가 복구됐는지 확인하는 단계

Apple 문서는 기존 명령의 중단과 선언형 소프트웨어 업데이트 사용을 함께 안내합니다. 소프트웨어 업데이트 설정 문서를 기준으로 현재 MDM 작업을 하나씩 대응시키십시오.

현재 작업 macOS 27에서 예상되는 결과 확인할 선언형 대체 수단 놓쳤을 때의 영향
업데이트 명령 전송 기존 흐름이 동작하지 않음 소프트웨어 업데이트 설정 선언 패치 배포 지연
업데이트 상태 조회 기존 조회 결과에 의존할 수 없음 상태 항목과 상태 채널 감사 증거 단절
권장 버전 주기 설정 기존 제한 기능에 의존할 수 없음 선언형 업데이트 정책 승인된 버전 통제 실패
특정 버전 설치 강제 명령 성공만으로 실행을 증명할 수 없음 강제 설치 단계와 기기 상태 CI 노드 버전 불일치
콘솔의 전송 성공 표시 기기 완료를 의미하지 않음 기기 실제 상태와 최종 버전 잘못된 준수 판정

여기서 중요한 것은 “명령을 보냈다”와 “기기가 업데이트를 완료했다”를 분리하는 것입니다. 두 상태를 같은 성공으로 처리하면 macOS 27 전환 뒤 준수 보고서가 실제 상태를 반영하지 못합니다.

관리 플랫폼 능력 점검하기

MDM 공급자가 “macOS 27 지원”이라고 표시해도 충분하지 않습니다. 다음 기능을 독립적으로 확인해야 합니다.

  • 선언형 기기 관리 활성화
  • 선언형 소프트웨어 업데이트 설정 동기화
  • 정책 범위와 기기 그룹 지정
  • 상태 채널 수신 및 내보내기
  • 설치 진행 상태와 실패 원인 확인
  • 재시작 뒤 정책 재활성화
  • 표준 사용자 환경에서의 설치 동작

Apple의 선언형 관리 통합 문서는 기존 MDM 흐름과 선언형 관리를 함께 사용할 수 있는 구조를 설명합니다. 다만 이 점이 기존 업데이트 명령의 회귀 수단이 된다는 뜻은 아닙니다. macOS 27 대상 기기에서는 업데이트 제어를 선언형 방식으로 전환해야 합니다.

공급자 검토 때는 구두 답변을 피하십시오. 다음 자료를 문서로 요청하십시오.

  1. 지원하는 macOS 버전과 선언형 관리 기능 목록
  2. 소프트웨어 업데이트 설정 예시
  3. 상태 채널에서 수집 가능한 항목
  4. 강제 설치와 재시작의 알려진 제한
  5. 실패한 선언과 충돌하는 정책의 처리 방식
  6. 상태 데이터의 원본 내보내기 형식

기존 MDM이 일부 선언만 지원한다면 전체 기기 이전을 서두르지 마십시오. 제어면의 기능 공백이 남은 상태에서 운영체제만 먼저 올리면, 원격 맥이 온라인으로 표시되더라도 업데이트 관리가 멈출 수 있습니다.

정책 완전성 기록하기

선언형 업데이트는 한 가지 설정만으로 끝나지 않습니다. 자동 동작, 연기, 알림, 사용자 권한, 특정 버전 강제 설치가 서로 다른 선언으로 구성될 수 있습니다. Apple은 선언형 데이터 모델을 여러 기기로 확장하는 방식을 별도로 설명합니다. 선언형 관리 데이터 모델 문서를 정책 설계 기준으로 사용하십시오.

먼저 정책 매핑표를 만드십시오. 각 행에는 다음 항목을 넣습니다.

  • 기존 규칙의 목적
  • 기존 MDM 작업
  • 선언형 대체 항목
  • 적용할 기기 그룹
  • 사용자 알림과 연기 조건
  • 충돌 시 우선순위
  • 기기에서 확인할 실제 상태
  • 실패 시 담당자와 처분 절차

특히 CI 빌드 노드는 일반 개발 기기와 분리해야 합니다. 자동 업데이트가 허용된 개발 그룹과, 배포 기간 중 재시작을 제한해야 하는 빌드 그룹은 같은 정책을 공유하면 안 됩니다.

선언이 여러 개 적용될 때는 관리 콘솔의 설정값만 보지 마십시오. 기기에서 최종적으로 유효한 정책을 읽어야 합니다. 콘솔은 정책이 저장됐다는 사실을 보여줄 수 있지만, 기기가 해당 선언을 활성화했거나 충돌을 해결했다는 사실까지 보장하지는 않습니다.

최소 구성 예시

아래 형태는 선언의 목적과 범위를 설명하기 위한 최소 구조입니다. 실제 키와 허용 값은 사용 중인 MDM의 구현 문서와 Apple의 공식 스키마를 대조해야 합니다.

{
  "type": "software_update_settings",
  "scope": "isolated-ci-pilot",
  "enforcement": "specified-version",
  "status_validation": [
    "policy-active",
    "installation-progress",
    "final-os-version"
  ]
}

이 예시를 그대로 배포 설정으로 사용하지 마십시오. Apple 공식 기기 관리 스키마 저장소를 기준으로 지원되는 선언 유형과 필드를 확인해야 합니다. 스키마에 없는 기능을 MDM 화면의 사용자 정의 이름만 보고 지원된다고 판단하면 안 됩니다.

상태 회신을 감사 증거로 바꾸기

소프트웨어 업데이트 관리는 정책을 보내는 기능이 아니라 결과를 증명하는 운영 체계입니다. 다음 세 상태를 분리해 저장하십시오.

  • 설정 전송됨: 서버가 정책을 기기에 전달한 상태
  • 정책 활성화됨: 기기가 선언을 받아 실제 관리 상태로 적용한 상태
  • 업데이트 완료됨: 최종 운영체제 버전과 빌드 작업까지 검증한 상태

Apple의 상태 항목 문서는 기기 상태를 활용하는 기준을 제공합니다. 업데이트 단계별로 어떤 상태를 수집할 수 있는지는 MDM의 실제 내보내기 결과로 확인해야 합니다.

감사 기록에는 최소한 다음 정보를 남기십시오.

  • 기기 식별자
  • 대상 기기 그룹
  • 정책 버전
  • 선언 활성화 시각
  • 설치 시작과 종료 시각
  • 최종 운영체제 버전
  • 실패 상태와 원인
  • 재시도 횟수
  • 담당자의 수동 처분
  • CI 작업 재개 여부

소프트웨어 업데이트 강제 설치 단계 문서는 강제 설치를 단계별로 다루는 기준점입니다. 단, 문서에 있는 관리 모델의 가능성과 사용 중인 MDM이 실제로 수집하는 필드는 구분해야 합니다.

원격 복구 경로 검증하기

데이터센터의 원격 맥은 현장 작업자가 전원 버튼을 누를 수 없습니다. 업데이트 테스트에는 설치 성공뿐 아니라 다음 복구 경로가 포함되어야 합니다.

  1. 격리된 원격 맥을 생산 정책과 같은 그룹에 배치합니다.
  2. 선언형 소프트웨어 업데이트 정책을 적용합니다.
  3. 업데이트 발견, 다운로드, 설치 진행 상태를 기록합니다.
  4. 재시작 뒤 화면 접속과 네트워크 연결을 확인합니다.
  5. 디스크 암호화 해제 절차가 필요한지 확인합니다.
  6. MDM이 다시 온라인 상태가 되고 선언이 활성화되는지 확인합니다.
  7. CI 에이전트가 자동 시작하고 실제 빌드가 완료되는지 검증합니다.
  8. 실패 시 대체 노드로 작업을 넘기고 원인과 복구 시간을 기록합니다.

다음 실패 유형은 별도 처분 경로로 분리하십시오.

  • 업데이트 뒤 MDM이 다시 연결되지 않음
  • 저장 공간 부족으로 설치가 멈춤
  • 재시작 후 CI 에이전트가 실행되지 않음
  • 암호화 해제 대기 때문에 노드가 장시간 오프라인 상태가 됨

원격 맥에 대역 외 재시작 수단이 없고, 대체 빌드 노드도 없다면 핵심 생산 노드를 첫 번째 업그레이드 그룹에 넣지 마십시오. 이 경우에는 MACCOME의 원격 맥 이용 환경처럼 별도 시험 기기를 먼저 확보하는 편이 운영 중단 위험을 줄이는 방법입니다.

준수 기준과 배포 범위 정하기

시험 결과는 감상이 아니라 통과 조건으로 남겨야 합니다. 다음 항목을 모두 확인하십시오.

  • [ ] MDM에서 선언형 소프트웨어 업데이트 설정을 활성화했습니다.
  • [ ] 기존 업데이트 명령에 의존하는 작업을 목록화했습니다.
  • [ ] 자동 동작, 연기, 알림, 사용자 권한 규칙을 매핑했습니다.
  • [ ] 특정 버전 강제 설치 정책을 격리 그룹에서 실행했습니다.
  • [ ] 기기에서 선언 활성화 상태를 직접 확인했습니다.
  • [ ] 설치 진행 상태와 실패 원인을 원본 데이터로 저장했습니다.
  • [ ] 재시작 뒤 MDM 재연결을 확인했습니다.
  • [ ] 디스크 암호화 해제 절차를 시험했습니다.
  • [ ] CI 에이전트 자동 시작과 대표 빌드를 확인했습니다.
  • [ ] 실패 시 대체 노드로 전환했습니다.
  • [ ] 미업그레이드 노드를 회귀 및 출시용으로 보존했습니다.
  • [ ] 담당자, 시간 기록, 실패 원인과 수동 처분을 감사 자료에 남겼습니다.

판정은 세 단계로 나누면 됩니다.

방량 가능은 모든 통제 항목과 복구 항목이 통과하고, CI 작업이 정상적으로 이어지는 경우입니다.
제한 시험은 정책 적용은 되지만 상태 회신 또는 복구 증거가 일부 부족한 경우입니다. 중요하지 않은 기기 그룹으로 범위를 제한해야 합니다.
업그레이드 보류는 기존 명령만 사용할 수 있거나, 재시작 뒤 MDM·CI 복구를 증명하지 못하는 경우입니다.

생산 기기가 파괴적인 테스트를 감당할 수 없다면, 생산 정책과 동일한 격리 원격 맥을 먼저 준비하십시오. 맥 미니 렌탈 구성 확인을 통해 시험 노드와 대체 노드를 분리할 수 있는지 확인한 뒤, 실제 정책과 빌드 작업으로 증거를 확보해야 합니다.

현재 보유한 맥만으로 시험하면 장비를 테스트에 묶어 두는 동안 생산 용량이 줄어들고, 실패한 노드를 현장에서 복구하기 어렵습니다. 장비를 일괄 구매하면 초기 지출, 감가상각, 예비 장비 보관, 교체와 유지보수까지 직접 부담해야 합니다. 반면 MACCOME의 맥 렌탈은 필요한 기간에 격리 시험 노드나 대체 원격 맥을 준비하는 선택지가 될 수 있습니다. 장기적으로 고정된 고부하를 계속 처리하거나 물리 포트와 현장 접근이 필요한 조직에는 직접 구매가 더 적합하지만, macOS 27 마이그레이션처럼 기간이 정해진 검증과 임시 CI 용량에는 렌탈 방식이 더 현실적입니다.

자주 확인하는 운영 판단

macOS 27에서 기존 명령이 실패하는 이유

Apple이 27.0에서 기존 소프트웨어 업데이트 명령과 조회 기능, 권장 버전 주기 설정 및 관련 제한의 동작 중단을 확인했기 때문입니다. MDM 콘솔의 전송 성공은 서버 작업의 완료일 뿐, 기기의 업데이트 실행을 의미하지 않습니다. 따라서 선언형 소프트웨어 업데이트와 상태 채널을 함께 검증해야 합니다.

MDM을 바로 교체해야 하는지

반드시 즉시 교체해야 하는 것은 아닙니다. 먼저 현재 MDM이 선언형 관리 활성화, 소프트웨어 업데이트 정책 동기화, 상태 회신, 강제 설치와 실패 추적을 모두 제공하는지 확인하십시오. 한 항목이라도 문서와 실제 내보내기로 증명하지 못하면 macOS 27 생산 전환을 보류하고 공급자의 공식 지원 범위를 다시 확인해야 합니다.

선언형 관리를 단계적으로 적용하는 방법

기존 기기 관리 흐름과 선언형 관리는 일정 범위에서 함께 운영할 수 있습니다. 먼저 격리된 시험 그룹에 업데이트 선언을 적용하고, 일반 개발 기기와 CI 빌드 노드의 정책을 분리하십시오. 정책 활성화, 설치 진행, 재시작 복구와 최종 버전을 확인한 뒤에만 그룹을 넓혀야 합니다. 기존 업데이트 명령을 회귀 경로로 남겨 두지는 마십시오.

오프라인 원격 맥의 처분 기준

오프라인 상태를 곧 업데이트 실패로 단정하지 말고 마지막 상태 시각, 네트워크 연결, 재시작 여부, 저장 공간과 암호화 해제 대기 여부를 확인하십시오. 대역 외 재시작이나 대체 노드가 없다면 담당자의 현장 처분 없이는 복구가 지연될 수 있습니다. 핵심 CI 노드는 이런 증거와 대체 경로가 준비된 뒤에만 배포 대상에 포함해야 합니다.

테스트 노드를 늘려야 하는 조건

일반 개발 환경만 시험했다면 CI 빌드 노드를 추가하십시오. 서명, 캐시, 장시간 빌드, 재시작 뒤 자동 실행처럼 생산 작업과 다른 조건이 있기 때문입니다. 운영체제 버전이 다른 노드나 디스크 암호화 정책이 다른 노드가 있다면 별도 그룹으로 시험해야 합니다. 대표 조건을 재현하지 못하면 고정된 노드 수보다 더 많은 격리 환경이 필요합니다.