Microsoft는 Petzold 이후 일관된 GUI 전략을 갖지 못했다

• 1980년대 후반까지는 Win16/Win32 API 중심의 단일 모델로 Windows 앱 개발이 명확했으나, 이후 수십 년간 일관성 없는 플랫폼 전환이 반복됨
• MFC, COM, WPF, Silverlight, UWP, MAUI 등 17종의 GUI 기술이 공존하며, 개발자들은 어떤 프레임워크를 선택해야 할지 혼란을 겪음
• 이러한 혼란의 근본 원인은 기술적 한계가 아니라 내부 정치와 비즈니스 급선회로 인한 조직적 실패로 지적됨
• Windows 팀과 .NET 팀의 장기적 갈등이 WPF·Silverlight·UWP 등 주요 기술의 고립을 초래했고, Microsoft조차 자사 앱에 통일된 전략을 적용하지 못함
• Petzold 이후 30년간 이어진 이 상황은 명확한 성공 이론 없이 발표 중심으로 움직인 플랫폼 전략의 한계를 보여줌

일관된 GUI 전략이 사라진 이후의 Microsoft

• 30년 넘게 Windows GUI 전략의 혼란이 지속되며, “새로운 Windows 데스크톱 앱을 만들 때 어떤 프레임워크를 써야 하는가”라는 질문에 명확한 답이 부재
• 1988년 Charles Petzold의 Programming Windows 시절에는 Win16/Win32 API라는 단일 모델이 존재해, 개발자들이 하나의 방식으로 앱을 작성할 수 있었음
• 이후 수십 년간 Microsoft는 내부 정치, 시연 중심 의사결정, 비즈니스 전략 전환으로 일관된 플랫폼을 유지하지 못함
• 결과적으로 Win32부터 MAUI까지 17개의 GUI 기술이 공존하며, 개발자들은 전략 부재의 플랫폼 속에서 혼란을 겪음
• 기술적 실패가 아닌 조직적 실패가 근본 원인으로 지적됨

명확한 전략이 존재하던 마지막 시기

• 1988년 Programming Windows는 Win16 API 기반의 852쪽짜리 책으로, Windows 앱 개발의 단일 지침서 역할을 함
• Win32는 메시지 루프, 윈도우 프로시저, GDI 등으로 구성된 일관된 정신 모델을 제공
• “하나의 OS, 하나의 API, 하나의 언어, 하나의 책”이라는 단순함이 개발자 성공의 핵심이었음
• 이후 Microsoft는 잘못된 최적화로 인해 장기적 혼란을 초래

객체지향 열풍과 복잡성의 시작 (1992–2000)

• Win32의 한계를 보완하기 위해 MFC, OLE, COM, ActiveX 등이 연속적으로 등장
• 이들은 GUI 프레임워크가 아닌 컴포넌트 아키텍처로, Windows 개발 전반에 복잡성을 도입
• Microsoft는 일관된 개발 스토리 대신 기술 단편을 나열하며 해석을 개발자에게 맡김
• 경영진의 컨퍼런스 중심 문화가 개발자 성공보다 우선시됨

PDC 2003과 Longhorn의 붕괴

• 2003년 PDC에서 Longhorn이 발표됨: WinFS, Indigo, Avalon(WPF의 전신)으로 구성된 비전
• Avalon은 GPU 가속과 XAML 기반 선언적 UI로 주목받았으나, 내부적으로 “pig” 라 불릴 정도로 비효율적이었음
• 2004년 개발이 Server 2003 코드베이스로 리셋되며 “Windows에는 관리 코드 금지” 지침이 내려짐
• 이로 인해 Windows 팀과 .NET 팀 간 13년 내전이 발생, WPF·Silverlight·UWP가 차례로 고립됨

Silverlight와 반복된 패턴 (2007–2010)

• WPF가 2006년 출시된 후, 2007년 Microsoft는 Silverlight를 새로 도입
• Silverlight는 Flash 경쟁을 목표로 한 브라우저 플러그인 기반 플랫폼이었으며, Windows Phone의 기반이 됨
• 2010년 MIX에서 Microsoft는 HTML5 중심 정책 전환을 발표, Silverlight 팀조차 사전 통보받지 못함
• 기술적 실패가 아닌 비즈니스 결정으로 인해 개발자 피해가 발생

Metro와 내부 전쟁 (2012)

• iPhone과 iPad의 성공에 대응해 Microsoft는 Windows 8과 Metro(WinRT) 를 발표
• WinRT는 .NET을 배제한 C++ 기반 런타임으로, WPF·WinForms와 단절됨
• Windows 팀과 .NET 팀이 서로 다른 비전을 추진하며 개발자 혼란이 심화
• UWP의 샌드박스, 스토어 배포 제한, Win32 API 부재로 기업 개발자 이탈이 발생

UWP와 WinUI의 확산 (2015–현재)

• Windows 10의 UWP는 “한 번 작성해 모든 기기에서 실행”을 목표로 했으나, Microsoft의 핵심 앱조차 이를 사용하지 않음
• 이후 WinUI 2, WinUI 3, Project Reunion, Windows App SDK 등으로 명칭과 구조가 반복 변경
• UWP의 컨트롤이 OS에 종속되어 팀 간 협업이 어려웠고, Project Reunion은 조직 구조의 임시 해결책에 불과
• 개발자들은 14년간 14번의 전환을 겪으며 지속적 피로감을 호소

관리되지 않는 기술의 동물원

• 현재 Windows에는 17종의 GUI 기술이 병존
  • Microsoft 네이티브: Win32, MFC, WinForms, WPF, WinUI 3/Windows App SDK, MAUI
  • 웹 하이브리드: Blazor Hybrid, WebView2
  • 서드파티: Electron, Flutter, Tauri, Qt, React Native for Windows, Avalonia, Uno Platform, Delphi/RAD Studio, Java Swing/JavaFX
• 다섯 가지 언어와 세 가지 렌더링 철학이 혼재하며, 일관된 플랫폼 부재가 명확

핵심 교훈

• 모든 실패는 내부 정치, 컨퍼런스 중심 의사결정, 비즈니스 급선회로 귀결
• 기술은 우수했으나 조직적 실패가 제품으로 드러남
• 성공적인 플랫폼은 도입–투자–유지–이전의 전 과정을 포괄하는 명확한 성공 이론을 필요로 함
• 그렇지 않으면 “개발자 컨퍼런스 발표용 전략”만 남게 됨
• Petzold는 여섯 번째 Programming Windows (WinRT, 2012) 이후 집필을 중단했으며, 이는 30년 혼란의 상징적 종결로 언급됨