Windows 10으로 넘어가면서, MS는 하나의 큰 숙제를 해결하고자 하였습니다. 기존 업데이트 방식에서 오는 OS의 파편화 문제였죠.
이전에는 이것을 일정 주기마다 서비스 팩을 배포하여 버젼을 단일화하는 것으로 해결하였으나, Windows 10을 출시하면서 Windows를 플랫폼화 하려고 생각한 MS는 메이저 버전 업그레이드 -기존의 버전 업그레이드-를 보다 자주 할 필요가 있다고 생각하였습니다.

그 결과물이 윈도우 10에 적용된 Red Stone 시리즈입니다. 메이저 업그레이드가 없는 대신 6개월에 하나씩 기능 업그레이드를 배포하겠다는 소리였습니다. 이 정책을 발표하면서 MS는 새로운 업그레이드 모델을 제시합니다. 바로 CB, CBB, LTSB로 구분되는 업그레이드 채널입니다.

각각 Current Branch, Current Branch for Business, Long-Term Service Branch로 불리는 이 업그레이드 채널은 간단히 말해 '기능 업그레이드를 언제 적용할래?' 라는 뜻을 담고 있습니다. (CB/CBB/LTSB 모델은 SAC(Targeted) / SAC / LTSC 모델로 변경되었습니다. 세부 사항은 동일합니다)

SAC(Semi-Annual Channel)은 일반적인 사용자와 기업 사용자가 적용받는 업데이트 방식입니다. 매년 봄, 가을에 제공되는 기능 업데이트를 적용받으며, 각 버전은 18개월간 지원을 받을 수 있습니다. 그렇다면 SAC(Targeted)와 SAC의 차이점은 무엇일까요?

이것은 아래 그림에서 확인할 수 있습니다.

(TechNet Blog - Windows as a Service : simplified and aligned 에서 발췌)

Plan and Prepare 단계에서는 Preview 버전을 배포하고 인사이더 빌드 사용자들에게 피드백을 받습니다. 기능 업데이트가 안정화되면 이제 그 다음인 Targeted Deploy로 넘어갑니다.
이 Targeted Deploy 단계에서 SAC(Targeted) 사용자가 영향을 받습니다. 대부분의 개인 사용자들은 여기에 속합니다.

만약 Windows 10 Pro 에디션을 사용 중이라면 SAC를 사용할 수 있습니다. 물론, 그룹 정책을 이용하여 적용할 수도 있습니다.

SAC를 적용하게 되면 기능 업데이트가 적용되는 시점이 Broadly Deploy로(약 4개월) 미뤄집니다. 하지만 영원히 설치되지 않는 것은 아닙니다.

또한 Windows 10 1703부터 사용자들은 기능 업데이트를 최대 365일까지 미룰 수 있습니다. 이를 통해 계산해보면 Windows 10 Pro 유저가 기능 업데이트를 지연할 수 있는 기한은 최대 'Broadly Deploy 페이즈로 넘어가는데 걸리는 시간 + 1년 + 알파' 입니다. 알파는 업데이트 일시 중지 기능 때문인데, 모든 업데이트를 최대 35일간 중지할 수 있는 기능을 말합니다.
이건 사용해보지 않아서 기간 만료시 어떻게 동작할 지 몰랐기에 제외하였습니다.

결국 Pro 사용자들도 최대 1년 가량을 연기하고 나면 어쩔 수 없이 레드스톤 업데이트를 설치해야 합니다.
이것을 피할 수 있는 유일한 방법은 현재로썬 LTSB(현 LTSC)를 적용하는 것 뿐입니다.

LTSC(Long-Term Service Channel)은 MS에서 업데이트 없이 장시간 동작해야 하는 응용(임베디드, 서버 등등)에 사용하라고 만들어놓은 채널입니다. 가장 큰 특징으로 6개월마다 제공되는 기능 업데이트가 없고, 지원 기간이 18개월에서 기본 5년(추가 5년)으로 늘어났다는 점이 있습니다.
MS는 LTSB를 발표할 때 LTSB는 5년간 지속적인 지원을 받을 것이라고 하였으나, 실리콘 업데이트에 대한 지원은 하지 않겠다고 말을 바꾸었습니다. 즉 최신 하드웨어를 쓰고 싶다면 기능 업데이트를 적용하라는 뜻입니다.

LTSC는 매 2-3년에 한번씩 업데이트 될 것이라고 하며, 현 시점에서 LTSC를 사용하는 방법은 Windows 10 Enterprise LTSB를 사용하거나, Windows Server 2016을 사용하는 것 뿐입니다.

비즈니스 사용자들의 반발을 예상하였는지, MS는 조직에 '업데이트 링 모델'을 적용할 것을 권고하였습니다.

조직의 시스템을 중요도에 따라 구분하고, 부서별로 Preview/Targeted/Broad 업데이트를 적용받을 시스템을 나눠서 적용하라는 것입니다.
물론 손으로 하기는 힘드니 MS에서 제공하는 업데이트 도구를 사용해야 합니다.

이것이 많은 시스템을 운용하는 대규모 조직에서는 합리적일지 몰라도, 윈도우 서버가 없거나, 윈도우 서버/업데이트 시스템을 관리하고 조율할 관리자가 없는 중-소규모 조직에서는 어떻게 대응하라는 것인지 도무지 감이 안 옵니다.

이상으로 Windows as a Service 업데이트에 대해 알아보았습니다.

개인적으로는 MS의 입장도 이해가 되지만, 사용자에 대한 배려가 부족하다는 생각을 지울 수 없는 정책 개편이었습니다.
이게 싫으면 리눅스로 넘어가라는 뜻일까요?