선언적 기기 관리 도입

♪ 부드러운 힙합 반주 ♪ ♪ 올해의 선언적 기기 관리 세션에 오신 것을 환영합니다 저는 Cyrus Daboo이고 기기 관리팀의 엔지니어입니다 오늘 강의에서는 선언적 기기 관리를 위한 새로운 기능을 소개하겠습니다 2021년에 열린 Apple WWDC에서 제 동료인 Melissa가 선언적 기기 관리와 MDM 프로토콜을 다시 사용하여 애플 기기를 관리하는 새로운 방법을 소개했습니다 그 세션에서 이미 배운 것처럼 선언적 기기 관리 덕분에 Apple의 기기는 자율적이고 시대를 앞서가게 되었습니다 자율적이라는 건 상태가 전환될 때 Server와 통신하지 않아도 알아서 관리할 로직을 적용한다는 것입니다 시대를 앞서가는 기기라 상태 채널에 중요한 변화가 감지될 때마다 비동기적으로 Server에 보고해서 기기에 대한 정보를 수집할 필요 없게 해줍니다 선언적 기기 관리 모델에서 중요한 두 가지 특징은 ‘선언’과 ‘상태’입니다 선언은 활성화, 술어 환경 설정, Asset 관리 유형까지 포함하고 상태에서는 Status Item과 Status reporting을 포함합니다 이것이 왜 중요하고 어떤 의미가 있길래 제품에 사용하는지 한번 알아볼까요 이 두 가지 기능은 새롭고 복잡한 관리 전략으로 모든 사용자가 잘 관리된 기기를 사용할 수 있게 해줍니다 그리고 IT 관리자가 지겹게 반복하던 일을 줄여주고 기기가 알아서 관리하도록 권한을 주었습니다 기기 관리 솔루션의 개발자인 여러분을 위해 선언적 접근은 Server의 업무량을 줄여 즉각 반응할 수 있게 합니다 선언적 데이터 모델은 조직이 얼마나 구조적인지 더 자세히 보여주고 이것은 기기가 더 직관적으로 변화했다는 것을 의미합니다 Status Report는 많은 피드백 채널을 보유하여 Server에서 기기를 더 자세히 살펴볼 수 있게 합니다 지금 꼭 필요한 정보를 시의적절하면서도 신뢰할 수 있게 보여주어 별도의 복잡한 조사를 시행할 필요가 없습니다 이러한 특징들은 개발에 쏟는 노력을 줄여주고 기기 관리에 더 집중하여 정말 중요한 것에 가치를 더하고 문제를 해결할 수 있게 하여 고객 만족도를 높여줍니다 선언적 접근은 IT 관리자들이 기기의 상태를 예측하여 확신을 갖고 일하게 해줍니다 이런 상황에서는 Server와의 연결이 끊어졌다고 해도 회사의 중요한 자료를 보호하는 안전한 상태를 유지해 줍니다 기기가 보내는 Status Report는 중요한 피드백이 되어 네트워크 대역폭과 같은 자원을 덜 활용하더라도 관리자의 업무 효율을 높여줍니다 회사의 사용자들에게 있어서 기기 관리는 빠르고 신뢰성 있는 작업으로 신입직원 교육을 빠르게 해주고 복구 시간도 더 빨라서 회사의 업무 효율을 한층 높여줍니다 이러한 장점으로 볼 때 미래 프로토콜의 주안점은 선언적 기기 관리가 될 것이며 당장 당신의 제품에 선언적 기기 관리를 적용해야 한다는 것을 알 수 있습니다 선언적 기기 관리에 대한 상세 소개와 적용하는데 필요한 단계를 배우려면 WWDC 21 세션 동영상을 꼭 시청하십시오 이번에는 세 가지 영역에 중점을 두었습니다 선언적 기기 관리의 영역 확장과 Status Report 개선 그리고 술부 기능 강화입니다 선언적 기기 관리의 영역 확장부터 알아보죠 선언적 기기 관리가 소개되었을 때 사용자 등록이 된 iOS만 지원받았습니다 이제 선언적 기기 관리는 등록 유형에 상관없이 MDM 지원을 받을 수 있습니다 관리되는 기기를 포함한 자동 기기 등록 프로파일 기반 등록 프로파일과 계정에 기반한 사용자 등록입니다 선언적 기기 관리는 이제 공유 iPad에서도 사용할 수 있습니다 iOS 16에서 사용자들은 MDM 프로파일에 대한 상세 사항을 설정 앱에서 환경 설정할 수 있습니다 환경 설정을 탭 하여 상세 사항이 나오면 활성화된 환경 설정이 보입니다 한 가지 기쁜 소식은 선언적 기기 관리가 모든 MDM 플랫폼에 지원된다는 점입니다 이제 macOS Ventura에서도 선언적 기기 관리가 지원되어 MDM 등록 유형과 관계없이 macOS를 지원합니다 tvOS 16에도 MDM 서비스가 지원되니 선언적 기기 관리 또한 지원되는 것입니다 OS 지원을 받는 기기라면 iOS를 사용할 수 있는 같은 선언과 상태를 설정하여 macOS와 tvOS에서도 사용할 수 있습니다 macOS에서는 환경 설정에서 MDM 프로파일 상세 사항을 확인할 수 있고 활성화된 설정을 볼 수 있습니다 tvOS도 마찬가지로 환경 설정에서 MDM 프로파일 상세 사항을 확인할 수 있습니다 하나 더 중요한 사실은 macOS와 공유 iPad는 각각 두 개의 MDM 채널을 갖는다는 겁니다 기기 채널과 사용자 채널이죠 기기 채널은 기기의 레벨을 관리하게 해줍니다 반면에 사용자 채널은 특정 사용자들을 위해 관리 상황을 설정하게 해줍니다 어떤 채널에서든 선언적 기기 관리를 사용하려면 그 채널을 분리할 수 있어야 합니다 이 말은 해당 채널에 선언적 관리 명령어를 보내야 한다는 것을 의미합니다 또한 선언적 기기 관리의 Status Report는 각 채널에서 개별적으로 발생하여 개별적으로 관찰하게 됩니다 두 번째는 Status Report입니다 Status Report에 대해 잠깐 복습해보죠 기기는 Server에 상태를 계속 리포트하여 Status Item을 구독할 것입니다 기기에서 Server에 성공적으로 응답을 보내주면 업데이트된 상태가 믿을 만한지 네트워크나 다른 문제로 인해 빠진 건 없는지 확인합니다 Status Report는 기기가 상황을 주도하게 합니다 Server가 계속 기기의 상태 변화를 알아보도록 조사할 필요가 없습니다 iOS 15에서는 모델 타입과 운영 중인 시스템 버전 같은 기기 속성에 대한 아이템의 상태를 소개했습니다 이번에 출시된 버전에서는 세 영역의 상태를 추가했습니다 암호 상태 환경 설정에서 설치한 계정 앱에 설치한 MDM이 바로 그것입니다 암호 상태를 살펴봅시다 iOS 15에서 암호 설정 규칙을 소개했습니다 사용자가 변경해서 MDM 암호 프로파일 규칙을 적용하여 암호를 설정하는 시간과 이 규칙이 적용되는 시간까지는 시차가 발생합니다 그래서 MDM Server는 암호가 설정되기 전에 먼저 확인해 봐야 합니다 하지만 새로운 선언적 기기 관리에서는 암호 설정에 있어 그럴 필요가 없습니다 그래서 우리는 두 가지 Status Item을 추가했습니다 바로 암호 승인과 암호 실재입니다 MDM 프로파일이나 환경 설정을 통해 암호 규칙에 따라 변경한 암호가 승인되면 승인이라고 나타납니다 이 Status Item은 불린 값을 갖습니다 이는 MDM 쿼리를 통해 되찾아 올 수 있는 상응하는 속성을 반영하는 것입니다 Server가 일반적으로 어떻게 가동되는지 살펴보죠 회사에서는 보통 자신들이 보유한 기기의 보안을 철저하게 유지합니다 예를 들면 VPN이나 Wi-Fi의 프로파일에는 허가된 네트워크만 접근을 허용합니다 그 상태에서 기기에 접속하려면 강력한 비밀번호를 설정해야 하고 규칙에 따라 암호를 승인받아야 합니다 기존의 MDM에서는 사용자가 암호를 변경하면 Server가 암호 규칙 프로파일을 전송해서 기기를 확인하고 암호가 승인될 때까지 기다려야 했습니다 초기에 암호가 승인이 안 되면 Wi-Fi 프로파일이 전송되지 않습니다 결국은 사용자가 암호를 변경하여 승인을 얻어냅니다 이후 Server에서 조사해보면 승인 상태가 변경된 것이 감지되고 Wi-Fi 프로파일을 전송할 수 있게 돼 기기에 설치하면 됩니다 선언적 기기 관리는 암호 승인 상태가 변경되었는지 술부를 활성화해 Server에서 직접 확인할 필요가 없습니다 Server는 암호 규칙과 Wi-Fi 프로파일을 둘 다 환경 설정으로 보냅니다 Wi-Fi 설정은 암호 승인에 필요한 술부를 활성화하는 데 필요합니다 암호 설정은 즉시 활성화되어 강한 암호를 생성하는 규칙을 적용합니다 초기에 암호가 승인이 안 날 듯하면 잘못됐는지 파악하기 위해 술부를 활성화하고 Wi-Fi 설정은 비활성화합니다 어느 순간 사용자가 암호를 승인되도록 변경합니다 이것은 Wi-Fi 설정이 활성화되었던 술부의 내용이 참이었는지 활성화를 재평가하게 해줍니다 이 모든 일은 Server의 개입 없이 일어나며 사실상 Server와 연결되어 있지 않아도 일어날 수 있습니다 설정을 활성화해두면 Server는 기기에서 자동으로 Status Report를 받습니다 그래야 변화가 생기면 알 수 있죠 이 작업은 Server가 기기와 어떻게 통신하는지 잘 보여줍니다 직접 조사하지 않아도 기기가 어떻게 가동되는지 믿을 만한 정보를 얻어내고 있죠 이제 계정 상태를 알아볼까요 iOS 15에서는 기기에 다양한 계정을 설치하기 위해 계정에 대한 환경 설정을 한다는 것을 소개했습니다 이것은 일반 회사에서 사용하는 계정 방식으로 사용자에게 회사가 자료의 접근 권한을 주는 방식입니다 계정이 설치되면 누가 어떤 상태로 접속했는지 문제가 있는 사용자는 어떻게 도와줄지 관리자가 알기 쉽게 합니다 이번에는 메일과 캘린더 그 외 다른 계정에 대해 Status Item 8개가 추가되었습니다 환경 설정에서 설치된 계정에만 Status Report를 보내는 것을 알아두세요 자동으로 설치된 계정이나 MDM 프로파일로 설치된 계정에는 보내지 않습니다 새로운 Status Item은 각각 메일 계정의 수신과 발신 현황을 개별적으로 보고하는 계정 환경 유형에 해당합니다 새로 추가된 Status Item은 JSON object의 다른 유형을 사용해 계정 유형에 따른 상태를 보여줍니다 여기 메일이 수신되는 Status Item과 캘린더를 구독하는 Status Item의 예를 보시죠 식별자 키의 값은 Status Item의 배열 내의 Object에 대한 고유의 식별자가 됩니다 이러한 예는 더 있습니다 선언적 식별자 키의 값은 계정을 설치한 환경 설정의 식별자 속성값과 일치하여 Status Item Object와 관련된 설정 교차 참조에 용이합니다 이 두 가지 요소는 모든 계정 유형의 Status Item Object에 항상 존재합니다 다른 키는 계정 유형이 구체적입니다 예를 들어 호스트 이름과 메일 Server의 포트 캘린더 구독을 위한 URL이 있습니다 이번에는 같은 유형의 하나 혹은 여러 개의 계정을 리포트하는데 Status Item의 값이 한 배열에 속해 있는지 알아보도록 하죠 이 배열의 값은 특정한 양식을 갖습니다 배열 안에 있는 아이템은 모든 Object에 사용된 한 배열에서 같은 스키마를 가진 JSON Object입니다 각 Object 유형은 항상 식별자 키를 가지며 하나의 배열 내에서 Object의 위치를 정하는 주요 키가 됩니다 다른 키도 리포트 될 때 함축된 유형으로 제공됩니다 앞으로 출시될 OS에서도 어떤 키와도 호환되게 하려면 Server가 배열 Object 내의 미상의 키도 받아들여야 합니다 배열 값이 변하면 각 Object마다 성능에 대한 내용이 언제든 Server로 전송됩니다 새로운 기능이 어떻게 적용되는지 예시를 통해 알아보죠 이번 예시에서는 Server가 두 개의 메일 계정 설정을 기기로 보냅니다 두 메일 계정은 현재 기기에서 활성화된 상태입니다 Server는 메일 계정의 Status Item으로 현재 상태를 구독해줍니다 구독이 활성화되면 계정 상태가 수집되고 기기는 Status Report를 Server로 전송합니다 Status Report는 두 계정의 Status Object를 상태 배열 내에서 제공하고 기기가 현재 어떤 상태인지 완전한 정보를 전달합니다 각 배열의 Object는 다른 식별자를 가집니다 리포트가 처리된 후 Server는 두 개의 계정을 갖게 되고 기기와도 일치시킵니다 Server가 새로운 환경 설정을 통해 기기에 메일 계정을 추가하면 기기의 Status Item은 배열 값에서 추가된 새로운 Object를 갖게 되고 새로운 Status Report가 Server에 전송됩니다 새 Item만 리포트 되죠 식별자 키값은 기존 Server와는 일치하지 않아 새 계정과 일치시키려고 Server가 추론할 수 있습니다 이 리포트를 처리하고 나면 Server에는 세 개의 메일 계정이 생깁니다 처음 두 개에 하나가 추가되었죠 기기도 똑같은 상태가 됩니다 사용자는 메일과 메모 중에서 선택을 하듯이 계정에 변화가 생기면 기기의 Status Item은 배열 값에 따라 업데이트된 Object를 갖게 됩니다 그리고 다시 Server에 Status Report가 전송됩니다 변경 사항이 있는 Item만 리포트 되죠 이 경우엔 사용자가 자신의 계정에 있는 메모 기능을 꺼버렸습니다 식별자 키값은 이미 Server에 있는 값과 매칭됩니다 그래서 Server는 기존 계정에 변동사항이 있다는 것을 추론할 수 있게 됩니다 결과적으로 기존 Status Item의 배열 객체가 새로운 것으로 교체되는 것입니다 이번 리포트가 처리되고 나면 Server에 있는 세 개의 메일 계정 중 하나가 변경됩니다 계정 환경 설정이 기기에서 제거되면 기기의 Status Item에서도 제거하라는 Object가 생성되고 또 다른 Status Report가 Server에 전송되며 이때는 제거된 아이템만 보고됩니다 제거되었다고 표시하려면 아이템 객체의 배열에 두 키를 포함합니다 하나는 식별자 키로 Server가 이미 가지고 있는 값이고 다른 하나는 제거된 키로 값을 참으로 설정하게 됩니다 기존 아이템을 제거한 기기 상태로 보고 Server가 표시 상태를 업데이트합니다 이 리포트가 전송되고 나면 Server는 두 개의 메일 계정을 가진 상태로 기기와 정확하게 매칭됩니다 Status Report에 대한 마지막 특징입니다 성능 문제를 피하고자 Status Report가 전송될 때 기기에 속도 제한이 생길 것입니다 Status Report가 Server에 전송되기 전 최소 1분 이상의 시간이 걸려 기기마다 Status Item에 차이가 생길 수 있습니다 리포트가 빠르게 전송되긴 하지만 즉각 전송은 아니라는 것을 의미합니다 이제 다음 주제를 살펴볼까요 다년간 발생하는 MDM 병목현상 문제입니다 앱 설치 시에 보이는 현상이죠 MDM Server는 직장이나 학교에서 사용자에게 필요한 도구의 접근 권한을 주려고 기기에 앱을 설치합니다 앱이 성공적으로 설치되었는지 여부에 따라 Server 쪽 논리가 좌우됩니다 그래서 MDM Server는 앱 설치 과정을 추적 관찰하고 사용자가 관리 중인 앱을 기기에서 삭제할 수도 있는지 지켜봐야 합니다 현재 MDM Server는 앱이 설치되는 과정을 살펴보기 위해 '설치된 앱 리스트' 혹은 '관리된 앱 리스트' 명령어를 사용합니다 Server에 앱 설치 진행 상황을 사전 전송한 기기를 소유하면 조사를 피할 수 있습니다 이것이 바로 선언적 기기 관리의 Status Report입니다 이번에 출시된 mdm.app Status Item입니다 이 값은 MDM Server가 설치한 앱이 나타내는 객체의 배열입니다 이 값은 배열이기 때문에 앞서 설명한 순서대로 지속해서 리포트됩니다 MDM으로 설치된 앱만이 리포트 된다는 걸 알아두세요 관리되는 기기도 마찬가지입니다 이 Status Report는 설치를 마친 앱에 대한 Status Item을 제공합니다 식별자 키는 배열 아이템에 대한 고유한 식별자를 가지며 이런 경우에 앱의 번들 식별자가 됩니다 네임 키는 앱의 이름을 말합니다 세 가지 버전의 키 보통, 짧음 외부용 버전의 식별자를 제공합니다 상태 키는 현재 설치 단계에 있는 앱의 리스트입니다 이 키의 값은 MDM의 '관리된 앱 리스트' 명령어에 상응하는 아이템에 해당합니다 이 모든 정보를 갖고 Server가 어떤 앱을 리포트 할지 상태는 어떤지 즉각 구별해 낼 수 있습니다 앱이 설치될 때 데이터가 어떻게 흘러가는지 살펴볼까요 오른쪽의 기기는 iOS 16기기입니다 MDM Server로 관리하고 있죠 Server는 이미 선언적 기기 관리가 가능하고 MDM으로 설치한 앱의 Status Item에 대해 리포트를 보내고 있습니다 다음으로 Server가 할 일은 MDM 앱 설치 명령어를 사용해 앱을 설치하는 것입니다 사용자 등록이 필요한 작업으로 앱을 설치하려면 사용자 승인이 필요합니다 기기에서 앱 설치가 필요하다는 팝업이 뜹니다 이때 설치를 잠시 멈추고 사용자의 입력을 기다립니다 기기는 Server로 입력 신호를 기다리는 수많은 앱 중 MDM으로 설치할 하나의 앱이 있다는 Status Report를 보낼 것입니다 사용자가 설치 버튼을 누르면 기기에 앱이 설치됩니다 설치가 진행되면서 앱을 다운받아 설치한다는 내용이 포함된 또 다른 리포트가 전달될 것입니다 마침내 앱 설치가 완료되었고 이제 사용할 수 있습니다 앱이 잘 설치되어 관리되고 있다는 내용이 담긴 또 다른 리포트가 전달됩니다 이번에는 사용자가 수동으로 기기에서 삭제한 경우를 보죠 다시 한번 Status Report가 전달되고 '삭제했지만 관리됨'으로 보고됩니다 앱은 삭제되었지만 기기에서는 여전히 관리하고 있다는 의미입니다 앱을 Server에서 삭제하고 싶을 때는 어떻게 할까요? 앱 삭제 명령을 기기로 보내 시행합니다 내부적으로 유지되고 있는 관리 상태를 삭제합니다 앱이 여전히 남아있다면 그 역시 삭제됩니다 앱 상태에 대한 배열에서 삭제되었다고 기록된 앱 개체에 대한 새로운 리포트가 전달됩니다 이것은 새로운 MDM Status Item이 앱 설치의 신뢰성과 속도를 개선한다는 것을 보여주고 진행 단계도 줄여줍니다 이번엔 세 번째 주제 술어에 대해 알아볼까요 활성 술부에 대해 잠깐 알아보죠 활성화가 되면 선택적으로 술부를 제공할 수 있습니다 이것으로 활성화에서 참조한 환경 설정을 기기에 적용할지 여부를 결정하게 되죠 술부는 Status Item의 값을 시험할 수 있는 기준이 됩니다 Status Item이 술부의 변화를 참고하면 기기는 술부를 재평가하면서 모든 활성화 단계를 재처리합니다 술부는 문자열로 명시되며 Apple Developer 사이트에 문서화 된 NSPredicate 구문을 사용합니다 좀 더 다양한 술부의 표현을 지원하기 위해 Status Item에 대해 표현하기 쉽도록 술부 구문을 확장했습니다 새로운 구문은 술부 문자열에 @status라는 용어를 삽입해 이름을 만듭니다 예를 들어, 일련번호에 대한 Status Item이 술부 표현에 나오면 새로운 구문을 사용합니다 백워드와의 호환성을 위해 이전 구문은 계속 사용하겠지만 점점 사라질 것입니다 그러니 새로운 구문으로 바꾸세요 Status Item의 배열 값이 어떻게 술부에 적용되는지 살펴봅시다 이미 설명한 것과 같이 우리는 계정에 대한 배열과 MDM으로 설치한 앱의 Status Item 값을 갖고 있습니다 배열 내에 있는 아이템의 활성화에 대해서 알아보는 데 유용합니다 예를 들어 특정 번들 식별자를 가진 앱이 기기에 설치되어 관리될 때 활성화가 되기를 바랄 수 있습니다 NSPredicate는 SUBQUERY라는 용어로 배열을 운영할 수 있습니다 NSPredicate 표현은 MDM으로 설치한 앱의 Status Item을 대상으로 SUBQUERY로 기록합니다 Status Item은 SUBQUERY의 첫 번째 전달 인자로 사용됩니다 두 번째 전달 인자는 배열의 각 요소를 의미하는 변수로 정의됩니다 세 번째 전달 인자는 술부의 표현으로 변수에 의해 정의된 각 요소를 테스트합니다 SUBQUERY 표현은 세 번째 전달 인자에서 술부와 일치된 요소의 배열로 돌아옵니다 그러고 나서 @count 연산자는 그 배열의 길이를 반환하고 그 길이로 일치하는 결과가 있는지 확인합니다 특정 앱이 설치되어 관리될 때 SUBQUERY의 표현은 한 개의 요소로 배열을 돌려놓고 술부는 참으로 평가될 것입니다 앱이 설치되지 않았을 때 SUBQUERY의 표현은 빈 배열로 돌아올 것이고 술부는 거짓으로 평가될 것입니다 Status Item 배열에서 키를 참조하기 위해서는 @key 확장 용어에서 키 경로가 적절히 처리된 걸 확인하는 데 사용해야 한다는 걸 알아두세요 새로운 속성 구문은 더 늘릴 수 있어서 새로운 데이터 유형을 위해 속성 용어를 어떻게 하면 추가할 수 있을지 논의하고 있습니다 Server는 속성에 대한 평가를 좀 더 직접적으로 제어할 필요가 있습니다 그러면 복잡한 Server 쪽 로직은 설정 변경을 동기화할 필요 없이 기기에서 간단히 변환할 수 있습니다 장비를 빠르게 교체하여 나눠줘야 하거나 회사의 데이터를 보호하면서 안전하고 빠르게 기기를 나눠주고 싶은 사용자나 회사에서 여러 사람이 효율적으로 시간을 할당해 사용하는 좋은 예가 될 것입니다 이를 지원하기 위해 기기에 임의의 속성을 설정할 수 있는 새로운 선언형 서비스를 Server에 추가했다는 소식을 전하게 되어 기쁩니다 이젠 활성화 술부를 바로 사용할 수 있습니다 이것이 새로운 관리 속성 선언문입니다 선언문은 키의 이름을 Server가 정의 내려주는 JSON Object로 구성되어 있습니다 JSON Object의 값은 배열이나 객체에서 제공하는 JSON 값의 어떤 유형도 될 수 있습니다 관리 속성 선언문입니다 세 개의 속성 중 이름과 나이 속성은 문자와 정숫값을 갖고 롤 속성은 문자 배열입니다 관리 속성이 참조된 술부가 활성화된 것입니다 첫 번째로 나이 속성 테스트입니다 정숫값이 18 이상인지 여부를 결정합니다 다음은 역할 속성 테스트로 배열 값 내에서 문자열이 12학년인지 결정하는 테스트입니다 각 속성은 @property 확장 용어를 사용해 참조되었고 용어의 내부에 속성 키의 이름이 있습니다 다양한 관리 속성 선언문을 기기로 전송할 수 있습니다 하지만 키는 하나뿐이어야 합니다 중복되는 키가 있다면 그중 한 값은 술부에서 속성을 참조할 때 임의로 선택될 것이고 예측할 수 없는 결과가 나타날 겁니다 그러니 키의 이름이 중복되지 않게 하세요 실제로 어떻게 사용하는지 알아봅시다 학교에서 어떻게 사용할까요? 학교에는 선생님이 많습니다 학교를 두 그룹으로 나눕니다 위층과 아래층이죠 각 그룹에 자신만의 Wi-Fi 네트워크가 있습니다 IT 관리를 맡은 선생님들은 메일 계정을 공유하며 접근을 요청합니다 운동부 선생님들은 모든 팀의 운동 스케줄을 보기 위해 캘린더를 구독해야 합니다 이처럼 네 개의 다른 역할의 선생님이 있습니다 가끔은 여러 역할을 맡기도 하죠 선생님은 역할에 맞게 기기를 받고 기기는 그에 맞게 환경 설정을 다르게 해야 합니다 두 선생님을 예로 들어보죠 1번 선생님은 아래층에 있고 운동부 담당입니다 2번 선생님은 위층에 있고 IT 관리 역할입니다 기존의 MDM Server라면 어떻게 처리했을까요? 원래 Server는 기기를 환경 설정하기 전에 선생님이 기기를 받을 때까지 기다립니다 Server는 선생님의 역할을 먼저 알아야 합니다 그리고 나서야 어떤 프로파일을 연결할지 알 수 있죠 한 번에 한 기기에 각 프로파일을 설치해야 합니다 선생님이 역할을 바꾸면 Server는 프로파일을 추가하거나 지워서 새 역할과 맞춰줘야 합니다 이 방식은 시간을 낭비하게 되고 학교 첫날 숙제를 다 마쳤을 때와 같이 특히 바쁜 시간대라면 기기 관리 시스템에 심각한 병목현상이 나타납니다 새로운 관리 속성 선언문이 있으면 이보다 훨씬 효과적인 대안이 됩니다 선언문을 사전에 기기에 로딩해 둘 수 있습니다 환경 설정에서 관리 속성을 통해 각자의 역할에 맞도록 설정된 술부를 활성화합니다 기기를 선생님에게 줄 때 Server는 선생님의 역할이 환경 설정의 활성화로 작동하는 관리 속성 선언문만 보냅니다 이 방법은 전체적인 Server와 네트워크 트래픽을 줄여주고 기기 상태를 빠르게 변화시켜 복잡하지 않게 해줍니다 학교 예시로 돌아가 봅시다 Server는 다음의 선언문을 사전에 로딩합니다 활성화와 환경 설정이 한 쌍이 되어 각 그룹의 Wi-Fi 네트워크를 설정합니다 그리고 우리에게는 메일 계정이 설치된 IT 관리자를 위한 활성화와 환경 설정이 한 쌍 있습니다 마지막으로 캘린더 구독을 설치하는 활성화와 환경 설정이 있습니다 각 활성화는 역할 관리 속성을 사용하여 각 팀과 기능의 이름을 테스트하는 술부를 갖습니다 지정되지 않은 기기에 처음에 로드하면 모든 술부가 거짓으로 나와 아무것도 적용되지 않습니다 이제 적용되고 나면 어떻게 되는지 볼까요 Server가 해야 할 일은 각 선생님에게 맞춰 관리 속성 선언문을 만드는 겁니다 1번 선생님은 운동을 담당하며 아래층에 있는 역할입니다 2번 선생님은 IT 관리자로 위층에 있는 역할입니다 이 선언문이 각 기기에 개별적으로 전송되어 사전 로드된 활성화는 재평가받게 됩니다 1번 선생님의 기기는 아래층에서 운동을 담당하는 역할에 대한 환경 설정을 갖습니다 2번 선생님의 기기는 위층에서 IT 관리자의 역할이 활성화된 환경 설정을 갖습니다 오직 하나의 선언문이 여러 환경 설정에 있는 앱을 구동하게 됩니다 마지막으로 선생님의 역할이 바뀌었을 때 어떻게 되는지 알아봅시다 이런 경우 2번 선생님은 기존의 역할에 운동 담당 역할이 추가됩니다 선생님에게 할당된 기기에 적용할 관리 속성 선언문으로 이제 추가된 역할 이름이 업데이트되었습니다 선언문이 기기에 업데이트되었으니 모든 활성화는 재평가받습니다 이 경우 새롭게 운동을 담당하는 역할에게 캘린더 구독 설정이 적용됩니다 다시 말하지만 오직 하나의 선언문만 변경하면 됩니다 이번엔 관리 속성 선언문이 기기의 설정 간에 어떻게 빠르고 쉽게 전환되는지 보여주어 복잡한 Server 쪽 로직을 기기에서 간단하게 변환하게 해줍니다 이제 마무리하겠습니다 선언적 기기 관리는 iOS 16, tvOS 16 macOS Ventura까지 사용범위가 확대되었고 공유 iPad를 포함해서 MDM 등록을 사용하는 모든 서비스에도 적용할 수 있습니다 MDM을 지원하는 모든 Apple 기기에서도 선언적 기기 관리를 지원할 수 있습니다 암호나 계정 MDM 설치 앱에 대한 Status Item도 추가했습니다 MDM 설치 앱에 병목현상이 생기는 것을 상당히 개선해 주었습니다 마지막으로 사용하기 쉬운 다양한 표현으로 술부 구문을 확대해 새로운 관리 속성 선언문을 추가했습니다 Server는 기기와 복잡한 사업 로직으로 소통할 수 있는 기회를 얻은 것입니다 이제 여러분의 제품에 선언적 기기 관리를 추가할 시간입니다 선언적 기기 관리를 이용해 기기 관리를 어떻게 재해석해낼지 벌써 기대가 됩니다 피드백은 언제나 환영합니다 감사합니다, WWDC의 다른 강의도 함께 해주세요 ♪