ConfigMgr 25주년

지난주 후반에는 ConfigMgr의 사반세기라는 중요한 시점에 대해 썼습니다. 오늘은 이 탁월한 제품의 배경 이야기를 더 깊이 다루고, 몇 가지 발표 내용을 공유하고, PC 관리 산업을 창출한 제품의 발생과 성장을 심도 있게 다루는 (선댄스 영화제에 도전할 정도로) 멋진 새 다큐멘터리를 소개하고 싶습니다.

다음으로, ConfigMgr 발표는 다음과 같습니다.

지금의 중요 시점을 기념하여 이전에 접한 적이 없을 수도 있는 이야기를 소개하겠습니다.

최초의 시작

지난주 후반에 저는 Project Hermes의 최초의 비전 문서 또는 “사양”을 다시 읽어 볼 기회가 있었습니다. 이 문서를 몇 년 동안 본 적이 없었던 저는 ConfigMgr이 최초 비전에 얼마나 충실한지를 확인하고 놀랐습니다. 문서에서 제시된 기본 구성 요소가 여전히 지금 사용되고 있으며 ConfigMgr의 토대의 일부로 여전히 남아 있습니다.

Microsoft가 내세운 최초의 미션(즉, 모든 가정 및 모든 책상에 PC 보급)이 1992년에 막 임계값에 도달하고 있었습니다. 조직은 터미널 에뮬레이션에서 x86 분산 컴퓨팅 모델로 적극적으로 이전하고 있었고, 대규모로 PC를 관리하는 솔루션이 없었습니다. 팀은 Project Hermes가 영향력이 강해야 한다고 판단했습니다.

최초의 SMS 팀은 상근직 개발자 2명과 Ken Pan이라는 인턴으로 구성되었습니다.  2003년에 제가 팀에 합류했을 때는 인턴인 Ken이 약 150명의 엔지니어로 구성된 전체 개발 팀을 이끌고 있었습니다. Ken은 이후 지금까지 저를 위해 SCCM 및 Intune의 엔지니어링 작업을 이끌고 있습니다!

흥미로운 사실:  SMS(Systems Management Server) 최초 버전은 245였습니다. 왜 1이 아닐까요? 당시 Windows는 빌드 300 기반이었고, 팀은 크게 뒤떨어진 것처럼 보이고 싶지 않았습니다. 그렇다고 해서 300에 너무 가까운 숫자를 선택하면 의혹이 일 것이라고 판단했습니다. 그래서 245를 선택했습니다!

SMS는 1994년 11월 7일에 공식적으로 출시되었습니다. 이 첫 번째 릴리스에는 2년 조금 넘게 소요되었습니다. 지금은 Microsoft의 새 참가자 빌드가 매월 릴리스됩니다.

이 최초 출시 때의 의미 있는 순간은 Bill Gates가 회사 전체적인 SMS 배포를 설명하는 전자 메일을 모든 Microsoft 직원에게 발송한 일입니다. 늘 엔지니어였던 Bill은 이 전자 메일에서 원하는 경우 컴퓨터에서 SMS 소프트웨어를 제거하는 방법도 언급했습니다.

내용을 확인하고 싶은 분을 위해 저는 이 게시물 맨 아래에 이 전자 메일을 포함했습니다.

아키텍처 추진

SMS 1.0과 1.1 및 1.2는 모두 상당히 빨리 릴리스되었으며, 이에 따라 새로운 시장이 탄생했습니다. 팀은 지체 없이 SMS 2.0을 개발하기 시작했습니다.

이때부터 상황이 복잡해졌습니다.

그리고 솔직히 말해 Microsoft는 현명하지 못한 결정을 내렸습니다. 성장 마인드의 큰 부분은 신속하게 배우는 것이며, 빠른 학습은 처음부터 SMS 팀의 핵심이었습니다.

1992년 이후로 클라이언트-서버 애플리케이션을 빌드하는 아키텍처가 많이 바뀌었으며, 팀은 SMS의 규모와 성능의 발전을 위해 기본적으로 1997년과 1998년에 SMS 서버 인프라를 재작성했습니다. 또한 이후 Windows Server 2000의 기능과 통합하기도 했습니다. 당시의 최첨단 기능을 보장하기 위해 처음으로 SMS 아키텍처를 재작성한 것입니다.

SMS 2.0이 1999년 1월에 릴리스되었고, 빠르게 SMS 2.0이 채택 및 사용되었습니다. 당시 저는 SMS의 최대 경쟁업체이던 Novell에서 Novell ZENworks 팀을 이끌고 있었습니다. SMS 고객을 만나서 심층적인 디렉터리 통합을 통한 사용자(ID) 위주의 지원에 기반한 ZENworks가 가진 차별화 요소를 어필하느라 수많은 시간을 보냈습니다!

SMS 2.0에 이스터 에그가 있었다는 사실이 이 글을 쓰는 동안 기억났습니다. 이 이스터 에그는 제품을 개발한 사람들의 이름과 사진이 담긴 비디오였습니다. 저는 이번 주에 이 비디오를 다시 한 번 보다가 눈에 띄는 이름을 발견했습니다.

바로, 제 상사이자 Microsoft 부사장인 Terry Myerson입니다. 모든 인재가 자신의 경력 중에 한 번은 SMS를 거쳐 가는 것 같습니다.

저는 SMS 2003 개발 노력을 증대하는 상황에서 SMS 팀에 합류했습니다.

SMS 2003에도 재작성된 부분이 상당히 많았습니다. 이때 큰 진전은 패치 관리를 위해 WSUS가 가능하도록 SMS를 조정한 것입니다. 따라서 클라우드(Windows 업데이트)에서 고객 및 엔터프라이즈로 Microsoft 패치가 가능해졌습니다. 기본적으로, WSUS는 데이터 센터에서 실행되는 점을 제외하고는 Windows 업데이트에 사용되는 것과 동일합니다.

Windows 업데이트는 세계 최대의 클라우드 서비스 중 하나로서 매월 10억 대 이상의 디바이스를 업데이트합니다. 잠시 생각해 보세요.  공용 클라우드에서 Microsoft의 주요 차별화 요소 중 하나는 Microsoft의 하이브리드 기능 및 고객이 기본적으로 데이터 센터 내에서 Microsoft의 공용 클라우드를 실행할 수 있는 기능입니다. 고객의 데이터 센터에서 Windows 업데이트를 실행(WSUS)하는 것은 정말 선구적이었고 아마 클라우드 연결 및 하이브리드의 최초 사례였을 것입니다. 노트북 사용이 크게 가속화되던 때이기도 했으므로, Microsoft는 연결되지 않은 모델이나 느슨하게 연결된 모델에서 작동하는 새 클라이언트를 빌드해야 했습니다.

SMS 2003 릴리스가 가까워지면서, Microsoft는 회사 전체에서 선별된 직원으로 구성된 그룹과 매주 금요일 오전에 만나 프로젝트의 상태를 평가했습니다. 이 회의에 초대된 주요 그룹 중 하나는 Microsoft IT 부서(MSIT)였습니다. 회사에서 선례가 없던 이 프로젝트에서 저는 제대로 준비되지 않았다고 느끼면 SMS 2003 출시 결정을 거부할 수 있도록 IT 팀에게 권한을 부여했습니다. 그 이후로, MSIT는 팀의 첫 번째이자 가장 좋은 고객인 동시에 초기 빌드에 대한 최고의 피드백 출처 중 하나입니다.

팀은 현재, 단일 ConfigMgr 배포를 통해 Microsoft의 50만 대 이상의 PC 및 모바일 디바이스를 관리(이 수치는 MAD 1억 대에 포함되지 않음)하고 있습니다. 각 월별 릴리스를 빌드할 때마다 지속적으로 Microsoft 전체에 새 ConfigMgr을 배포하고 있습니다. 매번 회사 내에서 시험 사용하는 거죠. 다른 흥미로운 사실:  저의 팀은 ConfigMgr의 내부 배포를 실질적으로 감독합니다. 배우는 데 있어서 실제 행동보다 더 나은 방법은 없습니다!

2003년과 2007년 사이에 팀은 “기능 팩”을 두 번 릴리스했습니다. 완전히 새로운 제품이 새 기능을 제공할 때까지 기다리고 싶지 않았으며 이 새로운 방식으로 기능을 릴리스하는 방법을 혁신했습니다. 첫 번째 기능 팩은 패치를 위한 WSUS 조정 작업을 완료했습니다. 두 번째 기능 팩은 OS 배포를 릴리스했을 때 포함되었습니다.

이 시기의 기억 중 가장 마음에 드는 것은 2003년 11월 유럽에서 열린 한 이벤트에서 데모를 준비해 새로운 OS 배포 기능을 선보였던 일입니다. Bill Gates가 키노트 연설에서 “SMS의 새로운 기능”을 설명할 때, 팀은 그의 뒤에 있는 벽에서 100대의 PC를 실시간으로 업그레이드했습니다. 우리는 이 데모를 “Wall of Fire”라고 불렀습니다.

다음은 Bill이 데모 실행을 보기 위해 돌아볼 때 촬영한 사진입니다.

다음 사진은 데모를 시연한 용감한 SMS 팀원입니다.

영향력 만들기

2004년 가을, Bill과 Steve는 회사의 고위 경영진 몇 명과 함께 외부 모임을 주최했고, 모임의 최종 세션은 Bill과 Steve와 함께하는 공개 Q&A였습니다.  누군가가 Bill에게 “작년에 Microsoft에 일어난 일 중 가장 중요한 것”은 무엇이라고 생각하는지 물었습니다. Bill은 “SMS와 Active Directory가 제대로 자리잡았고 앞으로 Microsoft에게 엄청난 자산이 될 것”이라고 대답했습니다.

이 일은 지금까지 저의 직업적인 경력에서 가장 좋은 날 중 하나입니다!

2007년 Microsoft는 System Center 브랜드와 맞추기 위해 “SMS”라는 이름을 “ConfigMgr”로 변경했습니다. DSC(Desired State Configuration)는 당시 고객이 요청하던 최신의 혁신적인 시나리오였으며, Microsoft는 DSC가 필요한 방식대로 작동하도록 만들기 위해 다시 한 번 아키텍처를 발전시켰습니다. 또한 관리 환경도 완전히 재작성했습니다.

SCCM 2012를 위한 엔지니어링이 중반에 달한 2011년 2월에 STB(Server and Tools Business)의 지휘를 맡은 Satya가 사업부의 이름을 C+E(Cloud and Enterprise)로 바꿨으며 저의 상사가 되었습니다. 첫 일대일 면담을 위해 Satya는 제 사무실로 와서는 저를 한 사람으로서 더 잘 알기 위해 상당한 시간을 보냈습니다. Satya를 직속 상사로 모시고 몇 년 동안 일한 것은 멋진 경험이었으며, 저는 그의 훌륭하고 탐구심 많은 성격, 성장 마인드, 그리고 겸손한 심부름꾼 같은 리더십 자세 등을 배울 수 있었습니다. Satya는 이 릴리스 동안 ConfigMgr의 미래와 아키텍처에 굉장한 영향을 미쳤습니다.

ConfigMgr 2012에서는 아키텍처 및 환경의 초점을 디바이스뿐만 아니라 사용자에게도 맞춰 기본적으로 아키텍처를 완전히 뒤집었습니다.

고객은 이동성이 미래의 핵심이 될 것이라고 말했고, Microsoft는 이동성이 디바이스에 그치지 않고 인력의 이동성이 중요해질 것이라고 파악했습니다.  이 정보에 응하여 Microsoft는 더 적은 하드웨어를 요구하도록 아키텍처를 극적으로 평면화했고 규모 한도를 크게 늘렸습니다. 바로 여기서 Microsoft의 클라우드 여정이 진정으로 본격화되었습니다. ConfigMgr을 Microsoft Intune에 연결했으며, Intune은 기본적으로 ConfigMgr의 강점이 되었습니다.

이 하이브리드 구성은 Microsoft의 클라우드 혁신을 가능하게 한 모델이 되었으며 이 하이브리드 배포를 통해 온-프레미스 ConfigMgr에 새로운 가치를 제공했습니다. Microsoft는 클라우드가 과거에 불가능했던 시나리오를 가능하게 만든다고 믿었고, Satya는 디바이스 관리를 위한 클라우드의 잠재적 영향력을 포착하고 이 부분에서 실제로 혁신과 실험을 추진했습니다.

ConfigMgr을 클라우드로 이동

다음의 아키텍처 발전은 단연 가장 어려웠습니다.

Windows 10을 매년 여러 번의 업데이트와 함께 Windows as a Service로 제공하는 것처럼 ConfigMgr도 클라우드로 이전해야 한다고 생각했습니다.

그러려면 문제가 쉽지 않았습니다.

역사적으로 ConfigMgr은 2~3년 주기로 릴리스되었습니다. SCCM 2007의 첫 번째 종합 계획을 세워야 하고, 안정화하는 데 16개월 정도 걸리며, 코드 완료를 선언하는 시점과 릴리스 시점 사이의 차이 등 다양한 과제가 있었던 것으로 기억됩니다. 16개월입니다!   연간 여러 번의 릴리스 주기를 유지 관리할 수 있으려면 ConfigMgr의 “SaaS화”가 필요하다는 것이 명백했습니다.

이렇게 쉽지 않은 과제를 눈앞에 두고 Microsoft는 ConfigMgr에 대해 심도 있게 알고 있고, 성장 마인드를 가졌으며, 이 고객 기반을 향한 열정을 공유하는 엔지니어와 프로그램 관리자를 엄선하여 소규모 팀을 꾸렸습니다.  이 과제를 완수할 수 있는 유일한 방법은 과제에 초점을 둔 소규모 팀이 전체 아키텍처를 정비하고 클라우드에서 제공되는 서비스를 처음부터 만드는 것이라고 생각했습니다.

이 정비 작업의 일정을 확인했을 때 저는 낙관주의가 넘치던 평소의 제 마음에 약간의 회의가 섞였다는 것을 인정할 수밖에 없습니다. 그렇게 짧은 일정 안에 완료하는 것은 믿을 수 없는 일이었습니다.

결과는 명백합니다.  극도로 집중적인 이 엔지니어링 팀은 모든 벤치마크를 초과 달성했고 PC 관리에 있어서 월간 릴리스 주기로 이전할 수 있게 만드는 새로운 클라우드 기반 접근 방식을 제공했습니다. 이 업데이트를 기록하기 위해 Microsoft는 기존의 버전 번호(예: 2003, 2007, 2012)를 폐지하고 대신 연도/월 규칙을 사용해 명명하기 시작했습니다. 따라서, 첫 번째 릴리스는 2015년 11월에 릴리스했으므로 버전 번호가 1511이 되었습니다.

그 후로 Microsoft는 매월 새로운 참가자 버전 ConfigMgr을 릴리스하고 주 현재 분기 릴리스는 최대 4개월에 한 번씩 제공했습니다.

의심할 여지없이, 이 작업은 지금까지 제가 참여한 가장 훌륭한 엔지니어링 프로젝트 중 하나였습니다.

새로운 이 클라우드 제공 모델에 대한 고객의 반응은 굉장했습니다.

그래픽으로 확인

ConfigMgr 기반의 절반 정도가 이미 업그레이드하여 새 현재 분기 모델을 사용하며, 현재 1억 대 이상의 디바이스가 관리되고 있고 원격 분석을 전송하고 있습니다.

무려 1억 대에 달합니다!!!!

제가 아는 바로는 관리 대상이며 원격 분석을 전송하는 활성 사용자 또는 디바이스의 수가 1억이 넘는 엔터프라이즈 서비스는 세계적으로 3개뿐입니다.  Office 365, Azure Active Directory, 그리고 ConfigMgr이죠. 이 세 서비스의 공통점은 무엇일까요?  모두가 통합 Microsoft 365 제공 사항의 일부라는 점입니다.

이 차트는 1511 릴리스 이후의 ConfigMgr 현재 분기 주 릴리스의 채택 현황을 보여줍니다. 이 데이터를 실시간으로 보여주는 대시보드가 있으며, Microsoft는 매주 일요일 아침 8시 30분에 이 차트를 전체 팀에게 보냅니다.

일요일 아침 8시 30분은 매주 제가 가장 좋아하는 순간입니다.

ConfigMgr의 사상 최고 속도 업그레이드였습니다. 각 릴리스와 함께 채택 비율(왼쪽에서 오른쪽으로 이어진 선의 경사)이 더 빨라지고 더 가파르게 되었음을 확인할 수 있습니다. 처음에는 이렇게 빠른 릴리스에 대한 ConfigMgr 커뮤니티의 반응이 어떨지 약간 불안했지만 고객이 Microsoft에게 보여준 신뢰와 확신에 대해 놀라는 동시에 고맙게 생각하고 있습니다.

지금은 어느 때보다 더 많은 관심과 열정이 Project Hermes에 쏟아지고 있습니다.

향후 계획

Microsoft는 2015년 11월에 ConfigMgr 현재 분기 1511을 릴리스하면서 클라우드 여정을 시작했으며 이때 이 릴리스가 목표를 향한 중요한 진전이었음을 명확히 알았습니다. 해야 할 훨씬 더 많은 일이 있다는 것도 잘 알고 있었습니다.

1511 이후의 혁신 속도는 높아지기만 했습니다. 조직은 모바일 디바이스에 연결된 클라우드 서비스의 세상으로 빠르게 이전하고 있고, 이렇게 빨리 변화하는 환경에서 고객이 요구하는 바를 Microsoft가 제공하기 위해 ConfigMgr 인프라는 진정한 클라우드 서비스가 되기 위해 크게 일보 전진했습니다. ConfigMgr은 이제 지속적으로 새 기능이 업데이트되는 서비스입니다. 클라우드의 AI 기능을 활용하여 고객의 요구 사항을 충족하고 고객이 요구하는 보호를 제공하며, 전 세계적으로 수억 대의 디바이스까지 확장 가능한 클라우드 기반 서비스로 고객에게 제공됩니다.

이러한 모든 특성을 생각하면 저는 전 세계 IT 리더에게 가장 흔히 듣는 이야기가 떠오릅니다.  IT 리더들은 자신 및 팀이 작업을 완수하기 위해 해결해야 하는 복잡성 때문에 지친다고 합니다. 조직은 배포한 제품 및 서비스를 단순화할 방법을 찾고 있으며 모든 디바이스에서 사용자를 지원하는 동시에 사용자가 요구하는 관리와 보안도 제공할 통합된 방식을 원합니다. 바로 이런 이유로 Microsoft 365를 빌드했습니다.  M365는 사용자의 더 큰 성과를 지원하는 최신 보안 작업 영역 및 통합된 클라우드 서비스를 제공합니다. IT가 사용자의 역량을 강화하는 풍부한 작업 환경, 그리고 사용자의 사랑과 IT의 신뢰를 받는 작업 환경을 제공할 수 있도록 설계되었습니다.

이로써 고객이 수년 동안 사용해 온 모든 Microsoft 제품(Windows, Office, Active Directory, ConfigMgr)이 또 한 번 발전했으며, Microsoft는 Microsoft 365를 통해 이 제품 모두를 클라우드로 이전했습니다.  전 세계의 엔터프라이즈 고객은 클라우드로 마이그레이션하고 있으며(Windows 10 as-a-Service, Office 365 및 EMS 서비스 사용), 이런 추세는 ConfigMgr 아키텍처의 자연스러운 발전 단계입니다.

오늘날 세계적으로 거의 모든 엔터프라이즈와 영리 조직이 Active Directory, 그룹 정책 및 ConfigMgr을 관리 도구로 사용하는 온-프레미스 모델에서 시작하고 있습니다. 더 단순한 최신 모델로 이전하려는 의욕이 높지만, 이런 최신 모델에 도달하기는 쉽지 않았습니다. 조직은 손가락을 튕겨 AD/GP/ConfigMgr에서 AAD/Intune으로 사용자/디바이스를 간단히 이전할 수 없습니다. 고객은 이전 과정을 더 단순하고 더 빠르게 만들고 위험을 제거하는 다리를 Microsoft에 요구해 왔습니다. 이 영역에서 Microsoft는 온-프레미스 Exchange에서 Exchange Online으로 이전하는 조직을 지켜보며 많은 것을 배웠습니다.

Microsoft는 최신 클라우드 관리로 이전하는 속도를 높여 주는 다리이자 일련의 새 기능인 공동 관리를 발표하게 되어 기쁘게 생각합니다. Fall Creators Update를 통해 Windows 10 디바이스를 온-프레미스 AD(Active Directory) 및 Azure AD에 동시에 참가시킬 수 있습니다.

공동 관리는 이 개선 사항을 활용하며 디바이스를 ConfigMgr 에이전트와 Intune MDM에서 모두 관리할 수 있게 만듭니다. 최신 관리로 이전하는 것이 더 이상 절벽을 뛰어내리는 일이 아닙니다. 공동 관리 덕분에 고객은 클라우드로 이전하는 고유한 단계별 여정을 조직에 맞는 방식과 속도로 진행할 수 있습니다.

Microsoft는 디바이스를 관리하고 Intune을 사용한 관리 대상으로 등록하기 위한 ConfigMgr 콘솔 내 작업을 단순화했습니다. 고객은 클라우드로 이전할 첫 번째 작업을 선택할 수 있고(말 그대로 슬라이더 막대를 ConfigMgr에서 Intune으로 이동), 선택한 작업은 클라우드로 이전됩니다.

이 공동 관리 시나리오에서 Microsoft 365의 고유한 기능 중 하나는 ConfigMgr 및 Intune의 지속적인 통신입니다. 작업이 이전될 때 사용자 및 디바이스의 모든 특성과 관련하여 권한 있는 소스가 Intune과 ConfigMgr 중 어느 쪽인지 파악함으로써 충돌하는 정책이 적용되는 것을 방지합니다.

이 기능은 Windows 10 및 최신 클라우드 관리로의 이전을 가속화합니다.

* * * * *

이 글을 쓰면서 저는 추억을 되짚어 보는 좋은 경험을 했습니다. SMS/ConfigMgr/Intune은 제 생활과 제 가족의 생활 및 프로젝트를 위해 일한 수천 명의 엔지니어의 생활뿐 아니라 제품을 사용해 왔고 지금도 계속 사용하고 있는 수백만 IT 전문가의 생활에 깊은 영향을 미쳤습니다. 저는 이 제품을 사랑하고 이 커뮤니티를 사랑합니다.

또한 ConfigMgr의 역사에 대한 오늘의 다큐멘터리가 엮여 나온 과정을 즐겁게 살펴봤습니다. 하지만 이 다큐멘터리는 1부일 뿐입니다. 2는 훨씬 더 중요합니다. 2부는 바로 여러분이 만들 예정이기 때문입니다.

Ignite에 참가하신다면 Microsoft 부스의 관리 및 보안 섹션을 들러 여러분의 사례를 말해 주세요. 간단한 안내는 여기에서 확인하세요.

Ignite에 없더라도 참가하기가 아주 쉽습니다. ConfigMgr에 대한 기억과 사례를 여기(aka.ms/ConfigMgr25) 업로드하여 공유해 주세요. 몇 가지 기본 지침을 확인할 수 있습니다.

제출해 주신 내용을 사용하여 2부를 만들 예정이며 이 비디오의 제목은 다음과 같습니다.

“개인의 ConfigMgr 역사”

빨리 보고 싶네요.

_______________________________________________