Mac 관리자를 위한 macOS 27: MDM 업데이트 명령어 폐지, 더 엄격해진 TLS

Mac을 관리하고 있다면, macOS 27 Golden Gate는 사용자 화면에는 전혀 드러나지 않지만 하루 만에 패치 프로세스나 등록(enrollment) 플로우 전체를 무너뜨릴 수 있는 두 가지 변화를 가져옵니다. 첫째, 대부분의 플릿(fleet)이 10년 가까이 사용해 온 MDM 소프트웨어 업데이트 명령어, 조회(query), 제한(restriction) 항목들이 27.0을 실행하는 기기에서 더 이상 작동하지 않습니다. 둘째, MDM, Declarative Device Management, Automated Device Enrollment, 프로파일 설치, 앱 설치, 소프트웨어 업데이트를 포함한 관리 경로상의 모든 연결이 이제 App Transport Security 규칙을 충족하지 못하는 서버를 거부합니다. 이전 버전에서는 경고 로그만 남겼던 부분입니다.

두 변화 모두 새로운 소식은 아닙니다. Apple은 WWDC 2026 이전과 당시에 두 가지를 모두 발표했습니다. 하지만 27.0이 9월 14일 빌드 26A428로 정식 출시된 지금, 업그레이드하는 모든 Mac에서 이 변화가 실제로 적용됩니다. 이 가이드는 Apple의 스키마와 지원 문서를 근거로 무엇이 멈추는지, 첫 Mac이 문제를 겪기 전에 서버를 어떻게 점검하는지, 그리고 각 레거시 메커니즘을 무엇이 대체하는지를 다룹니다.

핵심 요약

• 27.0에서는 레거시 소프트웨어 업데이트 관리가 사라집니다. Apple: "레거시 소프트웨어 업데이트 관리는 모든 27.0 운영체제에서 더 이상 작동하지 않습니다." 여기에는 ScheduleOSUpdate, ScheduleOSUpdateScan, AvailableOSUpdates, OSUpdateStatus 명령어, com.apple.SoftwareUpdate 페이로드, 그리고 유예(deferral) 제한 항목들이 포함됩니다.
• 대체 수단은 선언형(declarative)입니다. softwareupdate.enforcement.specific은 마감일까지 특정 버전을 강제합니다. softwareupdate.settings는 유예, 자동 동작, Background Security Improvements, 베타 등록을 다룹니다. 상태 항목(status item)이 기존 조회를 대체합니다.
• 권장 주기(recommended cadence)에는 macOS 대응 항목이 없습니다. Apple의 스키마는 선언형 RecommendedCadence 키를 macOS에서 사용할 수 없다고 표시합니다.
• TLS 규칙이 이제 관리 경로 전체에 강제 적용됩니다. TLS 1.2 이상, 순방향 비밀성(forward secrecy)을 갖춘 암호 스위트, SHA-2로 서명된 RSA 2048비트 이상 또는 ECDSA 256비트 이상 인증서, 그리고 extended master secret 확장이 요구됩니다. 예외는 SCEP 서버와 콘텐츠 캐싱 서버뿐입니다.
• 기기가 업그레이드되기 전에 미리 점검할 수 있습니다. 이전 버전에서는 동일한 검사가 경고를 로그로 남기며, Apple은 이를 찾는 로그 프레디케이트(predicate)를 문서화해 두었습니다.

변화 1: 레거시 소프트웨어 업데이트 관리가 더 이상 작동하지 않음

Apple의 WWDC 2026 기기 관리 업데이트는 이를 한 문장으로 정리했습니다. "레거시 소프트웨어 업데이트 관리는 모든 27.0 운영체제에서 더 이상 작동하지 않습니다." 이어서 여기에 해당하는 항목을 나열합니다. 소프트웨어 업데이트 명령어, 소프트웨어 업데이트 조회, 권장 주기 설정, 그리고 유예와 Background Security Improvements를 포함한 소프트웨어 업데이트 제한 항목입니다.

Apple이 공개한 기기 관리 스키마 — MDM 벤더들이 참고해 구현하는 apple/device-management 저장소의 YAML 파일 — 는 각 항목의 정확한 상태를 알려줍니다. macOS 기준으로 보면 다음과 같습니다.

레거시 메커니즘	스키마 상태 (macOS)	선언형 대체 항목
ScheduleOSUpdate 명령어	26.0에서 폐기 예고(deprecated), 27.0에서 제거	com.apple.configuration.softwareupdate.enforcement.specific
ScheduleOSUpdateScan 명령어	26.0에서 폐기 예고, 27.0에서 제거	불필요 — 기기가 스스로 스캔하고 상태를 보고함
AvailableOSUpdates 조회	26.0에서 폐기 예고, 27.0에서 제거	상태 항목 softwareupdate.pending-version
OSUpdateStatus 조회	26.0에서 폐기 예고, 27.0에서 제거	상태 항목 softwareupdate.install-state, softwareupdate.failure-reason, softwareupdate.install-reason
com.apple.SoftwareUpdate 프로파일 페이로드	26.0에서 폐기 예고, 27.0에서 제거	com.apple.configuration.softwareupdate.settings
제한 항목 forceDelayedSoftwareUpdates, forceDelayedMajorSoftwareUpdates, forceDelayedAppSoftwareUpdates, enforcedSoftwareUpdateDelay	26.0에서 폐기 예고, 27.0에서 제거	softwareupdate.settings → Deferrals

여기서 사용한 스키마는 2026년 9월 18일 기준 저장소의 release 브랜치를 스냅샷으로 찍은 것입니다. 사용 중인 MDM 벤더의 콘솔에 여전히 레거시 옵션이 표시된다면, 그것은 26.x 이하 버전 기기를 위한 항목입니다. 27.0을 실행하는 Mac에서는 아무 효과가 없습니다.

선언형 설정이 다루는 범위

softwareupdate.settings 구성은 대부분의 레거시 제한 항목이 이동한 곳입니다. Apple 스키마 기준 최상위 키는 다음과 같습니다.

키	제어 내용
Notifications	사용자에게 업데이트 알림을 표시할지 여부
Deferrals	CombinedPeriodInDays, MajorPeriodInDays, MinorPeriodInDays, SystemPeriodInDays
AutomaticActions	Download, InstallOSUpdates, InstallSecurityUpdate
RapidSecurityResponse	Enable, EnableRollback — 스키마에서는 "Background Security Improvements settings"라는 제목이 붙어 있음
AllowStandardUserOSUpdates	관리자가 아닌 사용자가 OS 업데이트를 설치할 수 있는지 여부
Beta	AppleSeed 및 개발자 베타를 위한 ProgramEnrollment, OfferPrograms, RequireProgram
RecommendedCadence	스키마에서 macOS는 "해당 없음(n/a)"으로 표시됨

스키마는 또한 Background Security Improvements가 "Major, Minor, System 유예 메커니즘에서 고려되지 않는다"고 명시합니다. 즉 메이저 업데이트 유예를 걸어도 백그라운드 보안 수정은 미뤄지지 않습니다. 이 부분을 통제하고 싶다면 RapidSecurityResponse 키를 사용하세요. Background Security Improvements 가이드에서 이 업데이트가 무엇인지 설명하고 있습니다.

권장 주기의 공백

레거시 MDM에서는 마이너 업데이트와 새 메이저 버전이 동시에 존재할 때 사용자에게 어느 쪽을 보여줄지 결정하는 "권장 주기"를 설정할 수 있었습니다. Apple은 권장 주기를 더 이상 작동하지 않는 레거시 설정 목록에 포함시켰고, 현재 스키마의 선언형 RecommendedCadence 키는 macOS에 대해 introduced: n/a로 표시되어 있습니다. 즉 오늘날 Mac에는 동등한 대체 수단이 존재하지 않습니다.

실무에서는 정해진 일수만큼 릴리스를 숨기는 **유예(deferrals)**와, 마감일까지 원하는 버전을 고정하는 **강제(enforcement)**를 조합해 사용자에게 보여줄 내용을 결정하게 됩니다. 단일 주기 스위치보다 손이 더 많이 가는 작업이므로, 사용자가 왜 갑자기 메이저 업그레이드가 나타났는지 묻기 전에 서비스 데스크에 이 변화를 미리 알려두는 것이 좋습니다.

27.0에서 버전 강제하기

가장 많이 쓰게 될 선언은 강제(enforcement) 선언입니다. 대상 버전과 마감 시각을 지정합니다.

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Identifier": "com.example.su.macos-27-0-1",
  "Payload": {
    "TargetOSVersion": "27.0.1",
    "TargetLocalDateTime": "2026-10-15T18:00:00",
    "DetailsURL": "https://intranet.example.com/updates"
  }
}

핵심 키는 TargetOSVersion과 TargetLocalDateTime입니다. 정확한 빌드를 고정하는 TargetBuildVersion도 있으며, 두 값이 함께 설정되면 이쪽이 우선합니다. 예시의 버전 번호는 어디까지나 설명용입니다 — 이 글을 쓰는 시점에는 27.0.1이 아직 출시되지 않았습니다. 대부분의 MDM 벤더는 원시 JSON이 아니라 폼(form) 형태로 이를 제공하지만, 키를 알아두면 기기의 상태에서 왜 설치되지 않았는지 확인할 때 도움이 됩니다.

하나의 정책, 두 가지 방식으로 작성하기

구체적인 예시를 보면 마이그레이션을 훨씬 쉽게 그려볼 수 있습니다. 흔한 정책 하나를 예로 들어보겠습니다. 메이저 업그레이드를 30일간 보류하고, 자동 다운로드와 보안 업데이트는 계속 켜둔다는 정책입니다.

레거시 버전은 com.apple.applicationaccess 페이로드 안의 제한 키 모음입니다.

<key>forceDelayedMajorSoftwareUpdates</key>
<true/>
<key>enforcedSoftwareUpdateMajorOSDeferredInstallDelay</key>
<integer>30</integer>

Tahoe Mac은 이 설정을 따릅니다. Golden Gate Mac은 이를 무시합니다.

선언형 버전은 동일한 의도를 하나의 구성으로 담습니다.

{
  "Type": "com.apple.configuration.softwareupdate.settings",
  "Identifier": "com.example.su.settings",
  "Payload": {
    "Deferrals": { "MajorPeriodInDays": 30 },
    "AutomaticActions": {
      "Download": "AlwaysOn",
      "InstallSecurityUpdate": "AlwaysOn"
    }
  }
}

직접 작성하기 전에 Apple 스키마에서 알아둘 만한 세부 사항이 세 가지 있습니다.

• 유예 값은 1일부터 90일까지이며, 레거시 지연 키와 동일한 범위입니다.
• 여러 선언이 같은 키를 설정하면, 기기는 규칙에 따라 값을 결합합니다. 유예는 number-max(가장 긴 유예가 우선), 자동 동작은 enum-last, Notifications는 boolean-and를 사용합니다 — 즉 어느 선언이든 알림을 끄면 알림은 꺼집니다. 남아 있는 테스트 선언 하나가 90일 유예를 설정해 두면, 30일 정책을 조용히 덮어써 버릴 수 있으므로 다른 문제를 파고들기 전에 어떤 선언이 할당되어 있는지부터 확인하세요.
• 자동 동작은 Allowed, AlwaysOn, AlwaysOff 값을 받으며, 기본값은 Allowed입니다. Apple 스키마는 AlwaysOn을 "항상 활성화", AlwaysOff를 "항상 비활성화"로 설명합니다. 선택을 사용자에게 맡기고 싶다면 Allowed를 고르면 됩니다.

결과 다시 읽기

선언형 관리는 조회 대신 상태 항목을 통해 상태를 보고합니다. softwareupdate.install-state 항목은 none, downloading, prepared, installing, failed 중 하나의 값을 가집니다. 기기가 설치하려는 대상을 알려주는 softwareupdate.pending-version, 그리고 문제가 생겼을 때의 softwareupdate.failure-reason과 짝을 이루면, 예전 OSUpdateStatus 조회가 알려주던 정보가 모두 갖춰집니다. 게다가 이 정보는 관리자가 물어볼 때가 아니라 상태가 바뀔 때 기기가 먼저 보내옵니다.

혼합 플릿(Mixed Fleet)의 함정

앞으로 1년 동안 여러분의 플릿에는 폐기 예고된 레거시 메커니즘을 여전히 따르는 Tahoe 26.x Mac과, 이를 무시하는 Golden Gate 27.0 Mac이 함께 존재하게 됩니다. 여기서 세 가지 위험이 생깁니다.

1. 절반만 작동하는 유예. 레거시 forceDelayedMajorSoftwareUpdates 제한은 Tahoe Mac에는 여전히 적용됩니다. 하지만 Mac이 27로 업그레이드되면 선언형 Deferrals 설정만이 영향을 미칩니다. 두 그룹 모두에 동일한 정책을 적용하고 싶다면, 두 방식 모두에 정의해 두어야 합니다.
2. 텅 비어버리는 리포트. OSUpdateStatus와 AvailableOSUpdates 응답을 기반으로 만든 대시보드는 27.0 기기에 대해 아무것도 보여주지 않습니다. 그런 기기가 "알 수 없음"으로 보이기 전에 리포트를 선언형 상태 항목으로 전환하세요.
3. 명령어가 도달했다고 가정하는 스크립트. ScheduleOSUpdate를 보내고 결과를 기다리는 자동화는 27.0 Mac에서 영원히 기다리게 됩니다. 런북과 API 스크립트를 점검해 MDM에 레거시 명령어 호출이 남아 있지 않은지 확인하세요.

가장 단순한 접근은 아직 Tahoe에 있는 Mac을 포함해 모든 Mac을 지금 바로 선언형 소프트웨어 업데이트 관리로 옮기는 것입니다. Tahoe에서도 DDM 소프트웨어 업데이트 선언은 이미 작동합니다. 레거시 설정은 아직 옮길 수 없는 기기를 위한 안전망 정도로만 남겨두세요. macOS 27이 소프트웨어 업데이트에 나타나지 않는 이유 가이드에서는 유예가 애초에 업그레이드 제공 여부를 어떻게 결정하는지 다루고 있습니다.

변화 2: 관리 경로에 대한 더 엄격한 TLS

Apple은 2026년 6월 9일자 지원 문서 Prepare your network environment for stricter security requirements에서 이 요구 사항을 공개했으며, macOS 27 릴리스 노트에서도 동일하게 반복하고 있습니다. 관리 경로상의 서버는 다음 조건을 충족해야 합니다.

요구 사항	세부 내용
프로토콜	TLS 1.2 이상, "가능한 경우" TLS 1.3
암호 스위트	순방향 비밀성 — TLS 1.3 스위트 전체, 또는 ECDHE를 사용하는 TLS 1.2 스위트
인증서 키	RSA 최소 2048비트, ECDSA 최소 256비트
서명 해시	다이제스트 최소 256비트의 SHA-2
TLS 1.2 확장	Extended master secret(EMS), RFC 7627

영향을 받는 워크플로는 Apple이 나열한 대로 다음과 같습니다. mobile device management, Declarative Device Management, Automated Device Enrollment, 구성 프로파일 설치, (엔터프라이즈 앱 배포를 포함한) 앱 설치, 그리고 소프트웨어 업데이트입니다.

명시된 예외는 두 가지입니다. 프로파일을 설치하거나 DDM 애셋을 해석하는 과정에서 이루어지는 SCEP 서버 연결은 영향을 받지 않습니다. 콘텐츠 캐싱 서버도 앱이나 소프트웨어 업데이트 애셋을 제공하는 경우라 해도 마찬가지로 영향을 받지 않습니다.

27.0에서 달라지는 것은 결과입니다. Apple의 문서: "규정을 준수하지 않는 연결은 차단되며, 로그 메시지는 경고가 아닌 오류로 표시됩니다." 검사 자체는 새로운 것이 아닙니다. 이전 버전들도 이미 이런 위반 사항을 경고로 로그에 남겨왔으며, 바로 그 덕분에 지금 미리 점검하는 것이 가능합니다.

예전 TLS가 여전히 숨어 있을 만한 곳

공개된 MDM 서비스들은 이미 오래전부터 요구 사항을 충족해 왔습니다. 위험은 여러분이 직접 호스팅하거나 경로에 배치한 것들에 남아 있습니다.

• 한 번 설정한 뒤 다시 들여다본 적 없는 오래된 리버스 프록시나 로드 밸런서 뒤에 있는 자체 호스팅 MDM
• 엔터프라이즈 앱 매니페스트와 .ipa 또는 .pkg 파일을 호스팅하는 서버인 사내 앱 배포
• DDM 애셋 선언이나 커스텀 설치 워크플로가 가리키는 패키지 및 애셋 호스트
• 트래픽을 자체 인증서로 다시 서명하는 TLS 검사 방화벽 및 프록시 — 이 인증서 역시 동일한 키 크기와 해시 요구 사항을 충족해야 함
• 내부 CA의 RSA 1024비트 키나 SHA-1 서명 같은 오래된 인증서 체인
• TLS 1.2는 협상하지만 extended master secret 확장은 지원하지 않는 오래된 TLS 스택

Mac이 업그레이드되기 전에 점검하는 방법

1단계: nscurl로 각 서버 테스트하기

macOS에는 ATS 테스트 도구가 내장되어 있습니다. 관리 경로상의 각 서버를 대상으로 실행합니다.

nscurl --ats-diagnostics https://mdm.example.com

이 도구는 일련의 ATS 구성으로 연결을 시도하며 각 항목에 대해 Result : PASS 또는 Result : FAIL을 출력합니다. 첫 번째 블록인 Default ATS Secure Connection이 여기서 가장 중요한 항목입니다. 검증 삼아 Tahoe Mac에서 공개 서버 두 곳을 대상으로 실행해 보았습니다. www.apple.com은 61개 검사 항목을 모두 통과했습니다. TLS 1.0만 제공하는 어느 공개 테스트 서버는 기본 보안 연결 단계부터 시작해 단 하나도 통과하지 못했습니다.

2단계: extended master secret 확인하기

nscurl은 EMS를 별도로 구분해서 보여주지 않는데, 오래된 TLS 스택이 가장 놓치기 쉬운 요구 사항이 바로 이것입니다. OpenSSL 3.x는 이를 직접 보고해 줍니다. macOS의 시스템 openssl은 사실 LibreSSL이므로, Homebrew로 설치한 버전을 사용하세요.

echo | openssl s_client -connect mdm.example.com:443 -tls1_2 -servername mdm.example.com 2>/dev/null \
  | grep -E "Protocol|Cipher|Server public key|Extended master secret"

www.apple.com을 대상으로 실행하면 Protocol: TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384 암호, 2048비트 서버 키, 그리고 Extended master secret: yes가 출력됩니다. 경로상의 모든 서버가 이와 같거나 그 이상이어야 합니다.

3단계: 기기가 직접 알려주게 하기

서버별 테스트는 여러분이 알고 있는 서버만 커버합니다. Apple이 권장하는 감사(audit) 방식은 기기가 실제로 어디에 연결하는지를 기록해서 나머지를 잡아냅니다.

1. 테스트용 Mac에 Apple의 Network Diagnostics Logging 프로파일을 설치합니다.
2. 관심 있는 워크플로를 실행합니다. 등록, 프로파일 설치, 앱 설치, 소프트웨어 업데이트 등입니다.
3. 해당 Mac에서 sysdiagnose를 수집합니다.
4. Apple의 프레디케이트로 로그 아카이브를 검색합니다.

log show --archive system_logs.logarchive --info -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

26.x를 실행하는 Mac에서는 이 결과가 모두 경고로 나타납니다. 즉 해당 Mac이 업그레이드되면 이 연결들은 차단됩니다. 27.0 Mac에서는 동일한 항목이 오류로 나타나며, 이 연결들은 이미 실패하고 있는 상태입니다.

Tahoe Mac에서 이 테스트를 실행해 두면, 실제로 무언가 망가지기 전에 무엇이 망가질지 목록으로 미리 확인할 수 있습니다.

롤아웃 체크리스트

첫 27.0 업그레이드를 앞둔 플릿이라면, 저희는 다음 순서로 작업할 것을 권장합니다.

1. 관리 경로상의 모든 서버를 나열합니다. MDM 서버 및 체크인 URL, Automated Device Enrollment 구성, 앱 매니페스트와 패키지 호스트, DDM 애셋 URL, 그리고 해당 트래픽을 검사하는 프록시나 방화벽까지 포함합니다.
2. 각 서버에 대해 nscurl --ats-diagnostics를 실행하고, 기본 보안 연결 단계에서 실패하는 항목을 수정합니다.
3. TLS 1.2를 종료(terminate)하는 모든 서버에서 OpenSSL 3.x로 EMS를 확인합니다.
4. 테스트용 Tahoe Mac 한 대에서 등록부터 업데이트까지 전체 주기를 거치며 Apple의 로그 감사를 실행합니다.
5. 업데이트 정책을 선언형으로 다시 작성합니다. 대상 버전을 위한 강제 선언, 유예·자동 동작·Background Security Improvements를 위한 softwareupdate.settings가 포함됩니다.
6. 리포트를 전환합니다. OSUpdateStatus와 AvailableOSUpdates 대신 선언형 상태 항목을 사용하도록 바꿉니다.
7. 자동화 스크립트를 검색해 레거시 명령어 이름이 남아 있는지 확인합니다. ScheduleOSUpdate, ScheduleOSUpdateScan, AvailableOSUpdates, OSUpdateStatus입니다.
8. 서비스 데스크에 알립니다. 27.0에서는 주기 기반 업데이트 숨김 기능이 사라졌으며, 사용자에게 대신 무엇이 보일지 안내합니다.
9. 파일럿 그룹을 먼저 업그레이드하고, 실제 27.0 하드웨어에서 등록·앱 설치·업데이트 강제가 모두 정상 작동하는지 확인한 뒤 범위를 넓힙니다.

자주 발생하는 문제 해결

27.0 Mac이 설정한 업데이트 마감일을 무시함

문제: Golden Gate로 업그레이드한 Mac이 정책에서 요구하는 마이너 업데이트를 설치하지 않습니다.

해결: 정책이 어떤 메커니즘을 사용하는지 확인하세요. 레거시 ScheduleOSUpdate 명령어나 MDM 제한 항목이라면 27.0에서는 더 이상 작동하지 않습니다. 대신 softwareupdate.enforcement.specific 선언을 전달하고, 그래도 설치되지 않는다면 기기의 softwareupdate.failure-reason 상태를 확인하세요.

업데이트 리포트에 새 Mac이 "알 수 없음"으로 표시됨

문제: 패치 대시보드에 27.0 Mac에 대한 업데이트 데이터가 전혀 표시되지 않습니다.

해결: 대시보드가 레거시 조회 응답을 읽고 있는 상태입니다. softwareupdate.install-state와 softwareupdate.pending-version 선언형 상태 항목을 사용하도록 전환하세요.

Tahoe에서는 등록이 되는데 Golden Gate에서는 실패함

문제: 27.0을 실행하는 새 Mac은 Automated Device Enrollment 과정에서 실패하는 반면, 동일한 구성의 Tahoe Mac은 성공합니다.

해결: 다른 원인이 확인되기 전까지는 TLS 변화를 의심하세요. 등록 플로우의 모든 URL을 nscurl --ats-diagnostics로 테스트하고, mdmclient, Setup Assistant, profiles에서 발생하는 ATS 오류가 없는지 기기 로그를 확인하세요.

엔터프라이즈 앱이 27.0에서 설치되지 않음

문제: 자체 서버에서 배포하는 커스텀 앱이 설치에 실패합니다.

해결: 매니페스트나 패키지 호스트가 TLS 요구 사항을 충족하지 못하고 있을 가능성이 높습니다. MDM 강화 작업 대상에 한 번도 포함되지 않았던 오래된 웹 서버인 경우가 많습니다. 콘텐츠 캐싱 서버는 예외이므로, 문제는 원본(origin) 호스트에 있습니다.

TLS 검사 방화벽이 관리 트래픽을 깨뜨림

문제: 사내망을 벗어나면 모든 것이 정상 작동하고, 사내망 안에서는 실패합니다.

해결: 검사 장비가 자체 인증서와 TLS 설정으로 연결을 다시 서명하는데, 이제 이 설정도 ATS 요구 사항을 충족해야 합니다. 해당 장비의 구성을 업그레이드하거나, 관리 대상 호스트와 Apple의 MDM 엔드포인트를 검사 대상에서 제외하세요.

자주 묻는 질문

macOS 26에서는 레거시 소프트웨어 업데이트 명령어가 여전히 작동하나요?

네. Apple의 스키마는 이를 26.0에서 폐기 예고, 27.0에서 제거로 표시하고 있으므로, Tahoe를 실행하는 Mac은 여전히 이를 따릅니다. 27.0을 실행하는 Mac은 따르지 않습니다. 전환 기간 동안에는 정책을 선언형으로 정의해 모든 Mac이 동일한 결과를 얻도록 하세요.

권장 주기 설정은 무엇으로 대체되나요?

macOS에서는 직접적인 대체 항목이 없습니다. Apple의 스키마는 선언형 RecommendedCadence 키를 macOS에서 사용할 수 없다고 표시합니다. 릴리스를 숨기려면 유예를, 원하는 버전을 강제하려면 강제 선언을 사용하세요.

콘텐츠 캐싱 서버도 이번 TLS 변화의 영향을 받나요?

아니요. Apple은 콘텐츠 캐싱 서버를 "앱 설치나 소프트웨어 업데이트와 관련된 애셋을 요청하는 경우라 해도" 예외로 명시하고 있습니다. SCEP 서버도 마찬가지로 예외입니다.

어떤 Mac도 업그레이드하기 전에, 어느 서버가 실패할지 어떻게 알 수 있나요?

Tahoe 테스트용 Mac에 Apple의 Network Diagnostics Logging 프로파일을 설치하고, 워크플로를 실행한 뒤 sysdiagnose를 수집해 Apple 지원 문서의 로그 프레디케이트로 검색하세요. 26.x에서는 위반 사항이 경고로 나타나므로, 실제로 문제를 일으키기 전에 미리 확인할 수 있습니다.

관리되지 않는(unmanaged) Mac에는 아무 영향이 없나요?

소프트웨어 업데이트 변화는 영향이 없습니다. TLS 규칙은 모든 Mac의 소프트웨어 업데이트와 앱 설치에도 적용되지만, 이런 Mac은 보통 이미 요구 사항을 충족하는 Apple 자체 서버에 연결합니다. profiles status -type enrollment 명령으로 Mac이 관리되고 있는지 확인할 수 있습니다. 관리되지 않는 Mac에서는 두 항목 모두 "No"로 표시됩니다.

결론

macOS 27은 선언형 관리가 등장한 이래 Apple이 계속 예고해 온 흐름을 마무리 짓습니다. 업데이트 제어는 이제 27.0에서 선언형 방식만 남았고, 관리 경로는 최신 앱 연결과 동일한 수준의 전송 계층 보안을 강제합니다. 두 변화 모두 사용자 인터페이스에는 손대지 않으므로, 플릿은 마감일을 놓치거나 등록이 실패하기 전까지는 아무런 눈치도 채지 못한 채 두 변화 속으로 들어가게 됩니다.

두 가지 모두 지금 Tahoe 상태에서 미리 준비해 두면 피할 수 있습니다. 서버를 테스트하고, Mac 한 대에서 Apple의 로그 감사를 실행하고, 업데이트 정책을 선언형으로 재구성하고, 리포트의 대상을 다시 지정하세요. 첫 27.0 Mac이 도착하기 전에 이 작업을 마쳐두면, 업그레이드는 그저 일상적인 절차가 됩니다.

관련 글: macOS 27이 소프트웨어 업데이트에 나타나지 않는 이유 · Background Security Improvements 설명 · macOS 27이 다른 앱의 데이터 접근을 차단하는 문제 · macOS 27 Golden Gate 출시 첫날 업데이트 가이드 · macOS Tahoe 엔터프라이즈 배포 가이드