Microsoft가 Windows Update를 모든 서드파티 앱에 개방하기 시작함

• 마이크로소프트가 제3자 앱까지 Windows Update에서 업데이트 가능하도록 개방하는 새 플랫폼을 프리뷰로 공개함
• 새로운 Windows Update 오케스트레이션 플랫폼은 드라이버 및 비즈니스 앱 포함 모든 업데이트를 통합 관리할 수 있도록 설계됨
• 사용자 활동, 배터리 상태, 친환경 에너지 타이밍 등에 따라 업데이트 일정을 최적화 가능함
• Win32, MSIX, APPX 앱까지 지원되며, Windows Update 기록에도 앱 업데이트 이력이 포함됨
• 기존 Microsoft Store나 Winget 방식의 한계를 넘어, 비즈니스용 커스텀 앱도 포함 가능성이 있음

---

Windows Update, 모든 앱 업데이트의 허브가 되려는 움직임

• 마이크로소프트는 최근 Windows Update를 OS 및 드라이버 업데이트 외에도 모든 앱의 통합 업데이트 플랫폼으로 확장하겠다는 계획을 발표함
• 이 변화는 특히 기업 환경에서 내부 앱까지 업데이트를 통합 관리하려는 수요를 반영한 것으로 보임

새로운 오케스트레이션 플랫폼 개요

• Windows Update Orchestration Platform이라는 이름으로 현재 프라이빗 프리뷰 제공 중
• 기존 Windows Update의 기능을 확장해, 앱 업데이트도 함께 일정 조정 및 사용자 경험 최적화 대상에 포함

“우리는 앱, 드라이버 등 어떤 업데이트도 Windows Update와 함께 오케스트레이션할 수 있는 통합 지능형 플랫폼을 구축하고 있습니다.” — Microsoft 제품 관리자 Angie Chen

기존 앱 업데이트 방식의 문제

• 대부분의 윈도우 앱은 각 개발사마다 개별 업데이트 시스템을 운영
• 결과적으로 업데이트 타이밍이나 품질이 일관되지 않음
• MS Store를 통해 일부 앱은 통합 업데이트 가능하지만, 많은 앱은 Store에 등록되지 않거나 기업용 자체 앱임

주요 기능 및 장점

• 사용자 활동, 배터리 상태, 지속 가능한 에너지 시점 기반 스케줄링 기능
• Windows Update의 기본 알림 및 이력 UI에 통합
• MSIX / APPX 앱은 물론 일부 Win32 앱까지 지원
• 플랫폼의 향후 업데이트를 자동으로 상속받음
• 기존 installer 대체 가능성 제시 (예: Adobe처럼 자체 백그라운드 설치기를 운영하는 대형 앱들도 대상이 될 수 있음)

기존 해결책들과 비교

방식	설명	주요 단점
Microsoft Store	앱 설치 및 업데이트를 Store에서 관리	등록된 앱이 제한적, 기업용 앱 적용 어려움
Windows Package Manager (winget)	커맨드라인 기반 패키지 설치/업데이트 도구	주로 파워유저 및 개발자 중심, 일반 사용자 비주류
Windows Update 오케스트레이션	OS/드라이버 외에 일반 앱까지 업데이트 통합 가능	현재는 프라이빗 프리뷰 단계

향후 전망

• 우선 기업용 앱 업데이트 통합 수요가 클 것으로 예상
• 이후 Adobe, Zoom, 기타 상용 소프트웨어 등으로 확대 가능성 존재
• 장기적으로는 macOS처럼 시스템 전반의 업데이트 일원화를 추구하는 방향성

마이크로소프트는 분산된 앱 업데이트 경험을 통합하려는 시도를 다시금 강화하고 있으며, 개발자와 기업의 협업 참여 여부가 이 생태계 전환의 핵심이 될 것으로 보임.

[GN⁺]

Hacker News 의견

• Windows에서 여전히 Chrome이 권한 상승 문제를 우회하기 위해 특수 서비스를 사용해 업데이트를 처리하는 상황이 남아 있고, Spotify 등 많은 앱들이 같은 이유로 AppData에 설치되는 현상 유지 중인 상황 공유, 많은 프로그램의 제거 프로그램이 제대로 작동하지 않아서 파일이나 기타 흔적을 남기는 경우도 여전함, MSI는 “체인 서명”이라는 오래된 키로 새로운 키를 서명하도록 영원히 요구하는데, 10년 넘는 긴 기간 동안 업데이트를 관리해야 할 때 굉장히 어렵게 느껴지는 문제, 언젠가 이 모든 상황이 깔끔히 정리되었으면 하는 바람
  • Chrome이 사용하는 설치/업데이트 프로그램은 오픈소스 Omaha이고, 다른 언급된 앱들은 Squirrel을 사용하고 있음, 둘 다 AppData에 위치하는 것이 가능(특히 Squirrel은 오로지 사용자 디렉터리에만 설치됨), Squirrel의 철학이 관리자 권한 없이도 사용자 설치 가능하게 하는 것임
  • AppData에 설치하는 이유는 권한 상승 우회를 목적으로 숨기려는 게 아님, Microsoft가 거의 10년 이상 AppData에 설치하는 방식을 권장한 결과이고, 요즘은 권한 상승 없이 동작 가능한 프로그램이라면 AppData 설치가 ‘올바른’ 방식이라고 생각함
  • 비컨테이너화되고 루트/관리자 접근 권한이 있는 앱의 경우 설치 프로그램 입장에서는 잔여 파일을 완전히 처리하는 것이 거의 불가능한 문제라고 생각함, 이들 앱은 아무 디렉터리에나 파일을 만들고 쓸 수 있으며, Microsoft 혹은 앱 제공자가 제공하는 제거 프로그램조차 모든 파일을 찾아내지 못하고, 프로그램의 전체 동작 흐름을 그대로 재현하지 않는 한 완전한 삭제가 어렵다고 봄
  • GNU/Linux 환경의 패키지들도 잔여 파일을 남기는 현상이 많음
• UniGetUI를 발견하게 되어 WinGet, Scoop 등 다양한 패키지 매니저를 잘 호출해주며, 무시 목록 등 커스터마이즈 기능도 제공, Windows에서는 그 정도 수준의 커스터마이즈 기능을 기대하기 어렵다고 생각함
• 항상 Windows에 왜 macOS처럼 통합된 설치, 업데이트, 삭제 프레임워크가 처음부터 존재하지 않았는지 의문을 가짐, 분명히 해결되지 않은 명백한 누락이라고 생각, 현재도 기업 고객은 애플리케이션을 관리하기 위해 개별적으로 직접 패키징해야만 하는 상황, 초기부터 Microsoft가 DLL 공유를 장려했고, 하위 호환성을 제공해야 했기에 .MSI나 고도화된 소프트웨어 관리 프레임워크 도입을 강제하지 않았던 게 원인이라 추측
  • MacOS도 처음부터 그런 통합 프레임워크를 제공하지 않았음, 많은 앱은 드래그 앤 드롭 방식으로 Applications 폴더에 넣는 간편함이 있지만, 상당수 앱은 설치 프로그램을 실행해야 하고, 시스템 전체에 지원 파일을 설치하기 위해 관리자 인증을 요청하는 경우 많음, 앱마다 자체 업데이트 프로그램이 시작 시 자동 실행되기도 하고, 과거에는 확장 기능이나 제어판 요소가 System Folder에 설치되어 재부팅이 필요했던 기억, 그리고 이러한 앱 중 상당수는 자체 제거 기능도 없어서, 설정 파일과 캐시 파일 등도 사용자가 직접 찾아서 지워야 문제 없이 재설치 가능
  • Microsoft의 첫 유명 운영체제였던 MS-DOS 영향으로, 초기 Windows는 타사 소프트웨어 설치 관점에서 사실상 DOS처럼 동작, 별도 설치 개념 없이 공급업체가 제공한 INSTALL.COM/INSTALL.EXE를 실행하는 방식, 주로 루트 디렉터리에 새 폴더를 만들고 파일을 복사했으며, 어떤 경우에는 사용자가 직접 폴더 만들어 수동 복사, 모든 앱 데이터 작업이 특정 디렉터리(예: C:\Program Files)에 집중된 구조, UNIX처럼 /bin, /etc, /var로 분리하지 않았음, MS-DOS는 IO.SYS, MS-DOS.SYS, CONFIG.SYS, AUTOEXEC.BAT 외 각종 파일 위치에 전혀 신경 쓰지 않았던 구조, Windows 3.x가 대중적으로 보급됐을 때도 이러한 DOS 스타일 작업 방식이 그대로 이어졌고, ‘통합 설치 시스템’이 매우 늦게 도입됨, .MSI도 상당히 후기에 도입되어 기존 프로그램들이 적용하지 않은 역사적 배경 설명
  • macOS로 전향했을 때 전형적인 설치 경험이 Windows보다 훨씬 좋다는 점에 정말 놀람, 다운로드 파일을 그냥 폴더에 복사만 하면 설치 끝나는 방식의 간편함이 인상적, 별도 설치 프로그램이 필요해도 거의 항상 시스템에서 제공되는 익숙한 플로우라 부담없이 느껴짐
  • 드라이버, 시스템 확장, 라이브러리 버전 관리 등 복잡한 문제들이 통합 설치/삭제 시스템을 만드는 걸 어렵게 함, 인터넷 연결조차 보장하지 못한다면 더 까다로움, 이런 기능을 만든다고 해도 소프트웨어 벤더들이 이를 이용하도록 설득해야 하고, 경영진이 이를 새로운 이윤 수단으로 여기지는 않을지 우려
  • 주요 소프트웨어 벤더들은 GPO 배포용 msi 패키지를 일반적으로 제공하는 편, 지난 10년간 직접 패키징해야 했던 적이 거의 기억나지 않음, 설치 매개변수 튜닝 정도의 간단한 작업만 하는 경우가 대부분, 다만 개선 여지는 여전히 충분히 남아 있다고 느낌
• Windows 10에서 모든 업데이트를 비활성화한 채 1년 넘게 아무 문제 없이 사용 중, Microsoft가 ‘업데이트’라는 단어 자체를 부정적으로 만든 것 같고, Nadella가 왜 이렇게까지 Windows에 애정을 안 보이는지 이해가 안 됨
  • 보안 걱정으로 업데이트를 안 하면 난리나는 사용자도 있겠지만, 대부분의 가정용 PC는 NAT 환경에 있기 때문에, 원격 취약점(예: EternalBlue) 악용도 어렵고, 트로이목마에 걸리지 않는 한 큰 문제 없음, 브라우저만 최신 상태라면 실질적으로 안전하다고 생각함, 예외적으로 트로이목마가 걸려도 관리자 권한 필요 없이 문서 암호화, 봇넷 참여가 가능하므로 Windows 업데이트만으로 모든 위협을 막는 건 아니라는 의견
• Windows Update 방식이 모든 리눅스 패키지 매니저에서 사용하는 방법과 매우 유사하다고 생각, 다만 Chocolatey, Scoop, WinGet 등 다른 대안들과 비교하면 Windows Update는 지나치게 단순하며 기능이 부족하게 느껴짐
  • WinGet이 존재한다는 사실을 너무 늦게 알았던 점이 부끄럽게 느껴짐, Ubuntu 등 리눅스 환경에서 지내다가 Windows용 패키지 매니저를 검색해보고 뒤늦게 알게 됨
  • Windows Update는 속도가 굉장히 느리게 느껴짐, 업데이트 컴포넌트 수나 데이터 양이 10배로 늘어난다면 정말 상상도 하기 어려운 일이라고 생각
• 개발자/고급 사용자가 아니라 Winget/커맨드라인으로 앱 업데이트가 어려운 일반 사용자라면 오픈소스 앱인 UniGetUI를 적극 추천, UI가 직관적이고 관리도 잘 되고 매우 쾌적하게 동작함
  • UniGetUI 프로젝트를 처음 알게 됐는데 정말 세련된 느낌, 좋은 정보 공유에 감사
• 이 스레드 덕분에 UniGetUI라는 아주 멋진 툴을 알게 됨, 앞으로 내 모든 Windows 장비에 꼭 설치할 예정, 이 앱의 주요 목표는 WinGet, Scoop, Chocolatey, Pip, Npm, .NET Tool, PowerShell Gallery 등 다양한 Windows 패키지 매니저용 직관적 GUI 제공, 지원하는 패키지 매니저에서 원하는 소프트웨어를 간편하게 설치/업데이트/삭제할 수 있는 매력적인 앱, 링크 참고(16.2k stars 기록)
• 이 변화는 7zip 업데이트에도 20분이 걸리고 재부팅까지 요구되는 사태를 만들 것 같다는 의구심
  • 꼭 그런 일이 벌어지진 않을 것이라고 생각, Windows Update가 강제로 재부팅을 요구하지 않는 업데이트도 많고, 7zip 역시 이와 다르지 않은 방식으로 설정 가능하다고 봄
• 다른 작성자들과 마찬가지로 이번 변화가 이미 한참 뒤처졌다고 느끼는데, 이유는 단순히 누가 먼저 했느냐가 아니라 내 개인적으로는 Win32 API와 데스크톱 앱의 시대가 최소 10년 전에 끝났다고 보기 때문, 이제 데스크톱에 설치된 앱은 소수에 불과하고, 대다수 사용자는 모바일 앱과 웹브라우저에 더 의존, 개인적으로 설치하는 것도 대부분 유틸리티며, 이는 Microsoft의 비즈니스 모델에도 맞지 않음, 결국 목표 사용자가 도대체 누구인지 의문
• 이 정책은 Windows Update 서비스에 문제가 생길 경우 엄청난 단일 실패 지점을 만들 것이라는 우려, 관련 검색 트렌드로도 알 수 있듯 Windows Update는 오랜 기간 불안정 기록이 있음
  • 단일 업데이트 수단이 된다면 그런 우려가 현실이지만, 실제로 Windows Update가 유일한 경로로 작동하게 만들 계획은 아니라서 ‘싱글포인트’ 우려가 크지 않다고 생각