박스를 뜯고 전원만 켰을 뿐인데, 회사 정책과 업무용 앱이 자동으로 설치되는
광경을 처음 본 건 제가 처음 테크 기업에 입사했던 날이었습니다. 100명이 같은 날
입사해 같은 경험을 했는데, 그때 받은 충격이 결국 저를 이 시스템을 직접
구축하는 자리까지 이끌었습니다. Apple Business Manager(ABM)는 그 마법 같은
경험의 출발점이었습니다.
제로터치 배포, 실제로 어떻게 작동하는가
제로터치 배포(Zero-Touch Deployment)란, IT 담당자가 기기를 직접 손대지 않아도
사용자가 전원을 켜는 순간 회사 환경이 자동으로 구성되는 방식을 말합니다. 이
개념이 실제로 어떻게 구현되는지는 ABM의 핵심 구조를 보면 이해가 됩니다.
Apple 기기는 처음 Wi-Fi에 연결될 때 Apple의 활성화 서버를 통해 조직에 등록된
기기인지 확인되고, 지정된 MDM 서버로 연결됩니다. 이 순간, 해당 기기가 ABM에
등록되어 있다면 "이 기기는 특정 조직의 소유이며, 지정된 MDM으로
연결하겠습니다"라는 응답이 돌아옵니다. MDM(Mobile Device Management)이란
기업이 스마트폰, 태블릿, 노트북 등 모바일 기기를 원격으로 관리하는 솔루션을
말합니다. Jamf, Microsoft Intune, VMware Workspace ONE 같은 제품들이 여기에
해당합니다.
이 과정을 가능하게 하는 기반이 바로 ADE(Automated Device Enrollment), 즉 기기
등록 프로그램입니다. ADE란 리셀러가 기기를 판매 단계에서 ABM에 등록해두면,
이후 기기 소유자가 따로 등록 절차를 밟지 않아도 자동으로 조직 환경에 편입되는
구조입니다. 제가 처음 테크 기업에서 맥북을 받았을 때 초기 비밀번호 하나 외에
아무것도 하지 않았는데 업무 프로그램이 줄줄이 설치되던 것도 바로 이 ADE
덕분이었습니다.
나중에 작은 회사에서 이 구조를 직접 설계해보니, 실제 동작 원리는 단순하지만 그
앞 단계, 즉 MDM 정책을 어떻게 짜느냐가 훨씬 더 중요하다는 걸 깨달았습니다.
처음엔 시스템이 요구하는 대로 정보만 채워 넣었는데, 막상 테스트해보니 기기를
여러 번 초기화하고 재설정하는 시행착오가 반복됐습니다. ABM 자체의 문제가
아니라, 설계 없이 시작한 제 문제였습니다. 예를 들어, 저희 팀에서는 입사 직후
Slack, Notion, VPN, 보안 프로파일이 자동으로 설치되도록 구성했는데, 초기에는
권한 설정이 꼬여 일부 앱이 실행되지 않는 문제가 발생했습니다. 이 문제를
해결하면서 ‘MDM 정책은 기능 설정이 아니라 사용자 경험 설계’라는 걸 체감하게
됐습니다.
앱 라이선스 관리, 소모 비용을 자산으로 바꾸는 구조
ABM에서 앱을 관리하는 영역은 과거에 VPP(Volume Purchase Program), 즉 볼륨 구매
프로그램이라고 불렸고, 지금은 '앱 및 도서' 섹션으로 통합되어 있습니다. VPP란
조직이 앱을 개인 단위가 아닌 라이선스 단위로 대량 구매하고 필요에 따라
재배포할 수 있도록 한 제도입니다.
이 구조의 핵심은 앱 라이선스를 소모품이 아닌 회수 가능한 자산으로 다룬다는
점입니다. 예를 들어 특정 유료 앱을 10개 구매했다면, 팀원 A가 퇴사하면 그
라이선스를 회수해 신규 입사자에게 재할당할 수 있습니다. 개인 Apple ID로 구매한
앱은 퇴사자와 함께 사라지지만, ABM을 통해 구매한 앱은 조직의 자산으로
남습니다.
또 하나 실용적인 부분이 있습니다. MDM을 통해 앱을 배포할 때, 기기에 개인
iCloud 계정이 없으면 앱 설치 과정에서 iCloud 로그인을 요구하는 팝업이 뜨는
문제가 생깁니다. ABM을 통해 앱을 구매하고 MDM에 연동하면, 해당 앱에 회사
라이선스 정보가 포함되기 때문에 이 문제가 원천 차단됩니다. 제가 직접 써봤는데,
이 차이는 실제 운영 환경에서는 반복되는 로그인 이슈를 줄여준다는 점에서 체감이
큽니다.
ABM에서 앱 배포 흐름을 정리하면 다음과 같습니다.
-
ABM의 '앱 및 도서' 섹션에서 원하는 앱을 검색하고 위치(Location)와 수량을
지정해 구매합니다.
-
위치 토큰(Location Token)을 다운로드해 MDM에 업로드하여 ABM과 MDM을
연동합니다.
-
MDM에서 해당 앱을 특정 기기 그룹 또는 사용자에게 배포 정책으로 설정합니다.
-
기기가 정책을 수신하면 디바이스 기반 할당(Device-based assignment)
방식에서는 iCloud 로그인 없이 앱이 자동 설치됩니다.
- 라이선스가 필요 없어지면 회수 후 다른 기기에 재할당합니다.
ABM의 '위치' 개념도 여기서 중요해집니다. 위치(Location)란 MDM 서버와 앱
라이선스를 연결하는 논리적 단위입니다. 여러 MDM을 운영 중이라면 MDM별로 위치를
분리해서 앱을 배포해야 관리가 뒤엉키지 않습니다. 처음엔 이 위치 개념이 왜
필요한지 몰라서 단일 위치로 다 넣었다가 나중에 구조를 다시 짜야 했습니다. 미리
알았더라면 좋았을 부분입니다.
Managed Apple ID, 보안 거버넌스의 실질적 기반
Managed Apple ID(관리형 Apple ID)란 개인이 생성하는 일반 Apple ID와 달리,
조직이 직접 생성하고 소유권을 갖는 계정입니다. 이 계정은 조직의 ABM 도메인
아래에서 만들어지기 때문에 퇴사자가 계정을 들고 나가거나, 개인 기기에서 그대로
사용하는 일이 구조적으로 차단됩니다.
보안 측면에서 이 구조의 가치는 분명합니다. 직원이 퇴사하면 Managed Apple ID를
즉시 비활성화할 수 있고, 조직 리소스에 대한 접근 권한이 즉시 차단됩니다.
기존처럼 개인 Apple ID로 회사 시스템에 로그인하던 구조에서는 퇴사 후 접근
차단이 사실상 불가능했는데, Managed Apple ID는 이 리스크를 제거합니다.
다만 이 계정에는 몇 가지 제한이 있습니다. '나의 찾기', 'Apple Pay', 'iCloud
사진 공유' 같은 소비자 지향 기능은 보안 정책상 사용이 제한됩니다. 저희
조직에서도 이 부분을 두고 팀원들과 꽤 긴 대화를 나눴습니다. "왜 업무용
맥북에서 개인 계정을 못 쓰나요?"라는 질문이 생각보다 자주 나왔고, 이를
설명하는 내부 커뮤니케이션과 업무적 약속을 만드는 데 별도의 시간을 써야
했습니다. 기술적 도입보다 사람을 설득하는 일이 더 어려울 때가 있다는 걸 그때
실감했습니다.
Managed Apple ID 생성은 수동으로도 가능하지만, 규모가 있는 조직이라면 Azure
Active Directory나 Google Workspace와 같은 ID 공급자(Identity Provider)와
연동하는 페더레이션(Federation)을 권장합니다. 페더레이션이란 기존 사내
디렉터리 시스템과 ABM을 연결해 사용자 계정을 자동으로 동기화하는 방식입니다.
이렇게 하면 신규 입사자가 사내 시스템에 등록되는 순간 Managed Apple ID도 자동
생성되고, 퇴사 처리와 동시에 계정도 비활성화됩니다. (Apple Business Manager 공식 가이드: Apple Support)
ABM 도입, 설계 없이 시작하면 운영 비용으로 되돌아온다
ABM은 그 자체만으로는 거의 아무것도 하지 않는 시스템입니다. MDM과 연결되어야
비로소 가치가 생깁니다. ABM이 기기 소유권을 등록하고, ADE로 자동 등록을
가능하게 하고, VPP로 앱 라이선스를 관리한다면, 실제 정책 집행과 원격 관리는
전부 MDM의 몫입니다. 이 둘의 역할 분리를 처음부터 명확히 이해하지 못하면
어디서 무엇을 설정해야 하는지 혼란이 생깁니다. 정리하면, ABM은 ‘소유권과
등록’, MDM은 ‘정책과 실행’을 담당한다고 이해하면 가장 정확합니다.
MDM을 선택할 때도 규모와 요구사항을 따져야 합니다. Apple Business Essentials는
월 몇 달러 수준의 요금제(플랜 및 지역에 따라 다름)로 소규모 BYOD 환경에
적합하지만, SSO(Single Sign-On, 하나의 계정으로 여러 시스템에 로그인하는
방식)나 단일 앱 모드(기기를 특정 앱 하나만 실행하도록 고정하는 기능) 같은 고급
정책이 필요하다면 Jamf나 Workspace ONE 같은 전문 MDM이 필요합니다. 저희처럼
30명 안팎의 조직이라도 업무 특성에 따라 요구 사항은 전혀 달라질 수 있습니다.
ABM이 애플 생태계에 강하게 종속된다는 단점은 분명히 존재합니다. 팀 전체가
맥북을 쓰는 조직이라면 이 종속성이 오히려 일관된 관리의 장점이 되지만,
Windows나 Android 기기가 혼재한다면 ABM만으로는 해결이 안 됩니다. 그 경우엔
크로스 플랫폼 MDM을 선택하거나, 플랫폼별로 관리 체계를 따로 설계해야 합니다.
이건 기술적 선택이 아니라 비즈니스적 판단의 영역입니다.
감독(Supervision)이라는 개념도 짚고 넘어갈 필요가 있습니다. 감독이란 기기를
소비자 모드에서 기업 전용 모드로 전환하는 가장 높은 수준의 관리 권한입니다.
항상 켜진 VPN, 단일 앱 모드, 화면 캡처 제한 등은 감독 상태의 기기에서만
적용됩니다. ABM을 통해 ADE로 등록된 기기는 설정 단계에서 자동으로 감독 상태가
되기 때문에, BYOD처럼 개인 기기를 후등록하는 경우와 처음부터 다른 관리 수준을
갖게 됩니다. 이 차이를 감안해 기기 정책을 설계해야 합니다. 특히 20명 내외의
규모에서는 수작업으로도 운영이 가능하지만, 입사/퇴사가 반복되는 순간부터는
자동화 구조 없이는 관리 비용이 기하급수적으로 증가합니다.
ABM과 MDM을 온전히 활용하게 된 뒤, 신규 입사자에게 기기를 택배로 보내고 전원을
켜는 순간 설정이 완료되는 구조를 만들었습니다. 그렇게 아낀 시간을 입사자
온보딩에 집중할 수 있게 되었고, 실제로 온보딩 품질이 눈에 띄게 달라졌습니다.
도입을 고려 중이라면, 먼저 기기 관리 거버넌스를 종이에 한 번 그려보는 것부터
시작하시길 권합니다.
참고: https://www.youtube.com/watch?v=k0cchC6mE88&t=31s
https://support.apple.com/ko-kr/guide/apple-business-manager/welcome/web
https://www.iru.com/definitions/what-is-zero-touch-deployment-for-mac
