▲

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

 (jsnover.com)
2P by GN⁺ 22시간전 | ★ favorite | 댓글 1개
  • 1980년대 후반까지는 Win16/Win32 API 중심의 단일 모델로 Windows 앱 개발이 명확했으나, 이후 수십 년간 일관성 없는 플랫폼 전환이 반복됨
  • Windows GUI 전략의 붕괴는 특정 기술의 실패가 아니라 팀 간 정치, 개발자 컨퍼런스 중심의 발표 문화, 사전 예고 없는 전략 전환이라는 세 가지 조직적 원인에서 비롯됨
  • 1988년 Charles Petzold의 Programming Windows 는 Win32라는 단일 API, 단일 멘탈 모델로 "Windows 앱을 어떻게 만드는가"에 명확한 답을 제시했으나, 그 이후 30년간 Microsoft는 이 명확성을 회복하지 못함
  • MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3, MAUI에 이르기까지 수십 년간의 GUI 프레임워크 난립이 이어졌으며, 실패한 이니셔티브마다 기술적 결함보다 조직 내 의사결정 실패가 핵심 원인으로 작용
  • 현재 Windows에서 실제로 사용되는 GUI 기술은 17가지 이상이며, 그 중 가장 널리 배포된 데스크톱 GUI 기술인 Electron은 Microsoft가 아닌 외부에서 만든 것
  • "플랫폼이 'UI를 어떻게 만들어야 하나'라는 질문에 10초 내 답하지 못한다면, 그 플랫폼은 개발자를 실패시킨 것" 이라는 핵심 진단은 2026년 현재도 Microsoft에 그대로 적용됨

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

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

Petzold 시대: 마지막으로 명확했던 시기

  • 1988년 Charles Petzold의 Programming Windows (852페이지)는 Win16 API를 C로 다루는 단 하나의 권위 있는 답으로, 이것이 곧 Windows 개발의 전략이었음
  • Win32도 더 규모가 커졌지만 메시지 루프, 윈도우 프로시저, GDI라는 하나의 멘탈 모델을 유지했으며, Petzold가 이를 설명했고 개발자들은 배워서 바로 활용 가능했음
  • "OS 하나, API 하나, 언어 하나, 책 하나" — 이 명확성이 플랫폼의 신뢰 신호였음

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

  • 1992년 MFC가 Win32를 C++로 감쌌으나, 이후 OLE, COM, ActiveX가 등장하며 GUI 프레임워크가 아닌 컴포넌트 아키텍처들이 Windows 개발 전반을 잠식
  • Microsoft는 일관된 스토리 대신 기술 원형(primitive)만 제공하고 개발자 스스로 조합하게 했으며, 이는 컨퍼런스 키노트 중심의 발표 문화가 개발자 성공보다 임원의 인상 관리를 우선했기 때문

PDC 2003 Longhorn: 비전이 스스로를 삼키다

  • 2003년 PDC에서 공개된 Longhorn은 WinFS(관계형 파일 시스템), Indigo(통합 통신), Avalon(GPU 가속 XAML 기반 UI) 세 기둥으로 구성된 설득력 있는 비전이었음
  • 2004년 1월 Jim Allchin의 내부 메모는 이를 "돼지(a pig)"라 표현했고, 같은 해 8월 완전한 개발 리셋을 선언 — Server 2003 코드베이스로 원점 복귀
  • 리셋 후 리더십은 "Windows 내 managed code 금지, 모든 신규 코드는 C++"라는 지침을 내렸고, WPF는 Vista와 함께 출시됐지만 셸(shell) 자체는 WPF를 사용하지 않음
  • 이 결정으로 인해 Windows 팀과 .NET 팀 사이에 13년에 걸친 조직 내 내전이 시작됐으며, 결국 WPF 고아화, Silverlight 폐기, UWP 실패로 이어짐

Silverlight: 반복될 패턴의 확립 (2007–2010)

  • WPF는 2006년 말 출시됐으나, 2007년 Silverlight가 Flash 대응 브라우저 플러그인으로 등장하며 개발 투자가 분산됨
  • 2010년 MIX 컨퍼런스에서 Microsoft 임원이 Q&A 중 "Silverlight는 크로스플랫폼 전략이 아니라 Windows Phone 전략"이라 발언 — Silverlight 팀은 사전 통보를 받지 못했으며, LOB 앱을 Silverlight에 투자한 개발자들도 컨퍼런스 Q&A를 통해 처음 알게 됨
  • Silverlight의 종말은 기술적 실패가 아닌 비즈니스 전략 전환의 결과였으며, 개발자들은 항상 마지막에 통보받는 구조가 이때 확립됨

Metro와 두 팀의 전쟁 (2012)

  • Apple의 iPhone 2억 대 판매, iPad의 PC 잠식에 대응해 Windows 8과 Metro를 출시했으나, WinRT는 의도적으로 .NET 기반이 아닌 네이티브 C++ 런타임으로 설계 — Windows 팀의 .NET에 대한 반감이 직접 반영된 결과
  • //Build 2012에서 개발자들은 "미래는 WinRT, HTML+JS는 일급 시민, .NET도 여전히 동작, C++도 귀환, Metro 앱도 작성 가능, WPF 코드도 여전히 실행"이라는 모순된 메시지를 동시에 수신
  • 엔터프라이즈 개발자들은 UWP의 샌드박싱, Store 배포 요건, 누락된 Win32 API를 확인하고 즉시 이탈 — "태블릿 앱스토어는 끝내 실현되지 않았음"

UWP와 WinUI의 혼란 (2015–현재)

  • Windows 10의 UWP(Universal Windows Platform) 는 PC, 폰, Xbox, HoloLens를 아우르는 "한 번 작성, 모두 실행" 비전이었으나, Windows Phone 쇠퇴와 함께 Microsoft 자체 주력 앱(Office, Visual Studio, 셸)이 UWP를 사용하지 않으면서 신호는 명확해짐
  • 공식 답변은 "상황에 따라 다름(it depends)"으로 전락 — UWP, WPF 유지, XAML Islands, WinUI 3 대기, WinUI 2 병존, Project Reunion 출시, Windows App SDK로 이름 변경이 이어지며 혼란 가중
  • Project Reunion / WinUI 3는 기술적 진전이지만, 그 존재 자체가 UWP 컨트롤이 OS에 종속되고 .NET 팀·개발 도구 팀이 이를 소유하지 못했던 조직적 문제의 산물
  • 2024년 한 개발자의 회고: "UAP, UWP, C++/CX의 C++/WinRT 교체(도구 지원 없이), XAML Islands, XAML Direct, Project Reunion, WinAppSDK 재시작, WinUI 2.0과 3.0 사이의 혼란스러운 전환… 14년, 14번의 피벗"

관리인 없는 동물원: 현재 Windows의 GUI 기술 목록

Microsoft 네이티브 프레임워크:

  • Win32 (1985) — 여전히 사용 중, Petzold 책 여전히 유효
  • MFC (1992) — 유지보수 모드, 엔터프라이즈·CAD 분야 잔존
  • WinForms (2002) — "사용 가능하나 권장하지 않음", 데이터 입력 폼에는 여전히 최고 속도
  • WPF (2006) — XAML, DirectX 렌더링, 오픈소스, Microsoft 신규 투자 없음
  • WinUI 3 / Windows App SDK (2021) — 공식 "현대적" 답변, 로드맵 불확실
  • MAUI (2022) — Xamarin.Forms의 크로스플랫폼 후계자, .NET 팀의 현재 베팅

Microsoft 웹 하이브리드:

  • Blazor Hybrid — 네이티브 WebView 내 .NET Razor 컴포넌트
  • WebView2 — Win32/WinForms/WPF 앱에 Chromium 내장

서드파티:

  • Electron — Chromium + Node.js, VS Code·Slack·Discord 채택, 현재 Windows에서 가장 널리 배포된 데스크톱 GUI 기술이지만 Microsoft와 무관
  • Flutter (Google), Tauri (Rust 기반), Qt (C++/Python/JS), React Native for Windows (Microsoft 후원이나 Facebook 기술 기반)
  • Avalonia — WPF의 오픈소스 정신적 후계자, JetBrains·GitHub·Unity 등 Microsoft를 기다리지 않은 개발자들이 채택
  • Uno Platform — Microsoft보다 WinUI에 더 헌신적
  • Delphi/RAD Studio, Java Swing/JavaFX — 버티컬 마켓·엔터프라이즈에서 여전히 생존

→ 17가지 접근법, 5개 프로그래밍 언어, 3가지 렌더링 철학 — "플랫폼"이 아님

핵심 진단

  • 모든 실패한 GUI 이니셔티브는 세 원인 중 하나로 귀결됨: 팀 간 정치(Windows vs. .NET), 컨퍼런스 발표 중심의 조기 플랫폼 베팅(Metro, UWP), 개발자 사전 통보 없는 비즈니스 전략 전환(Silverlight)
  • 기술 자체는 종종 우수했음 — WPF 우수, Silverlight 우수, XAML 우수 — 조직적 실패가 곧 제품의 실패였음
  • "채택-투자-유지보수-마이그레이션" 전 생애주기를 아우르는 Plausible Theory of Success 없이는 전략이 아닌 컨퍼런스 키노트에 불과
  • Charles Petzold는 Microsoft가 발표하는 새로운 것들을 따라잡기 위해 Programming Windows 를 6판까지 개정했으나, WinRT(Windows 8)를 다룬 6판 이후 집필을 중단

함께 보면 좋은 글 β

▲
GN⁺ 22시간전  [-]
Hacker News 의견들

  • Microsoft가 GUI 일관성을 프레임워크 레이어에서 해결하려고만 하는 게 근본 문제임
    WinForms, WPF, UWP, WinUI 등 계속 새 프레임워크를 내놓고 결국 버림
    Apple은 디자인 시스템 자체를 제품으로 보고, 프레임워크는 보이지 않게 만든 반면 Microsoft는 매번 반대로 접근함

    • 70년대생으로 80년대부터 컴퓨터를 해온 입장에서 이 말에 커피를 쏟을 뻔했음
      Apple 쪽 사례도 들어볼래?
    • 40년 된 Win32 앱에 Metro 디자인, 터치스크린, 다크 모드를 한 번에 입히는 건 불가능함
      요즘 WPF는 WinUI 스킨을 흉내내고 있어서, 그래도 Microsoft가 노력은 하고 있음
    • 동의함. 다만 WinForms는 아직도 지원 중임
      최신 .NET 스택에서도 여전히 공식 경로 중 하나로 남아 있음
    • “Apple이 해결했다”는 말은 Tahoe 이전에 쓰인 댓글 같음
    • 통찰력 있는 코멘트였음

  • 여전히 WinForms가 매력적임
    WebView2 덕분에 하이브리드 앱 개발이 쉬워졌고, 순수 웹으로 갈 수도 있지만 네이티브 크롬이 주는 감각이 더 좋음
    모든 고객이 Windows를 쓰기 때문에 굳이 싸우지 않음
    최근엔 .NET10 + WinForms + WebView2 조합으로 AI 어시스턴트를 만들고 있음
    순수 WinForms로 대화 히스토리 UI를 반복 수정하는 건 상상도 하기 싫음

  • “WPF가 좋았다”는 말에 동의하지 않음
    2000년대 후반 일반 하드웨어에서 WPF 앱은 느렸음
    예를 들어 Logos Bible Software가 단순 텍스트 앱인데도 그래픽 성능을 요구해서 구형 노트북에서 버벅였음
    나중에 보니 Logos 4가 WPF 기반이었고, 포럼 글에서도 같은 불만이 많았음

    • 2010~2011년경 복잡한 WPF 앱을 만들었는데, 성능이 HTML/JS/Blink보다 훨씬 나빴음
      결국 대부분의 코드를 Direct3D/Direct2D로 다시 구현했음
      WPF 아키텍처 자체가 문제였음
    • 2010년쯤 Evernote가 WPF를 버린 사례가 있었음
      이유는 흐릿한 텍스트와 성능 문제였다고 함
      관련 글: edandersen.com / Reddit
    • 문제는 WPF가 아니라 Microsoft가 Intel의 저성능 하드웨어를 ‘충분하다’고 인정한 게 더 큰 원인임
      관련 기사: Ars Technica
    • 이건 마치 Apple의 Tahoe/iOS 26처럼 효과를 덧붙이다가 과한 결과를 낳은 사례 같음
    • 예전엔 WinForms가 느리다고 했지만, 지금은 Electron이 그 자리를 차지함
      결국 성능 논쟁은 시대마다 반복됨
      Apple도 AppKit/UIKit에서 SwiftUI로 넘어가며 비슷한 문제를 겪고 있음

  • ChatGPT가 처음 폭발했을 때 Bing이 웹 접근 가능한 버전을 통합한 건 천재적인 아이디어였음
    하지만 Microsoft는 컨텍스트 압축 같은 세부 구현을 하지 않아 금방 대화가 차단됨
    반면 OpenAI, Perplexity 등은 이를 잘 구현해서 지금은 표준이 되었음
    Microsoft가 그때 제대로 했더라면 Google을 대체할 수도 있었을 것임
    결국 UI/UX의 완성도 부족이 문제였고, 이는 조직 문화의 일관성 부재 때문이라 생각함
    Apple이 UI 라이브러리 번들링을 막는 게 답답했지만, 그 덕에 UI 일관성이 유지된 것도 사실임

    • Apple이 UI 라이브러리를 막는다고 해도, Flutter나 KMP처럼 캔버스 렌더링하면 됨
      대부분의 사용자는 신경 쓰지 않음

  • 어떤 사용자가 Microsoft 임원과의 저녁 이야기를 계속 복붙한다는데, 그 내용이 “Microsoft는 엔터프라이즈 올인”이라는 것임
    하지만 실제로는 Windows와 Azure 품질 저하로 기업들도 떠나고 있음
    우리 회사도 Azure SLA 문제로 피해를 봤고, 보상도 없었음
    그래서 Active Directory, Windows 의존도를 줄이고 있음

    • Microsoft가 기업만 보고 개별 사용자 경험을 잊은 게 문제임
      결국 사용자 없는 기업 시장은 존재하지 않음

  • Win32 이후 Microsoft는 2년 이상 한 방향으로 밀고 나간 적이 없음
    WinRT는 괜찮았는데, Nadella가 와서 Azure 중심으로 전환하며 Windows 플랫폼을 버림

    • 이제는 Microsoft가 여전히 플랫폼 회사인지조차 의문임
      Windows → Office → Azure로 변하면서 정체성이 흐려졌음
      Office는 웹과 데스크톱 양쪽에 있고, 하드웨어와 스토어도 있음
      Satya Nadella의 비전이 명확히 전달되지 않음
    • WinRT는 기술적으로도 별로였고, Microsoft Store 강제 정책이 더 큰 실패 요인이었음
      스토어는 형편없었고, 내부 승진용 프로젝트에 불과했음

  • Microsoft가 계속 새로운 GUI 프레임워크를 내놓는 게 문제지만, 그래도 Win32 앱은 여전히 작성 가능함
    Microsoft는 오래전부터 웹 중심으로 방향을 잡았고, AJAX·Flexbox·Grid 같은 기술 발전에도 기여했음
    나는 주로 웹·Java·Python 기반의 크로스플랫폼 시스템을 개발함
    굳이 Windows 전용 GUI를 만들 이유가 없음
    웹 앱이 더 유연하고 접근성 높음

    • 왜 Windows 전용 앱을 만들어야 하는지 의문임
      웹은 어디서나 동작하고, PWABuilder로 앱스토어 배포도 가능함
      나는 이 프로젝트에 참여 중이며, Electron 없이도 빠르고 가벼운 앱을 만들 수 있음
    • Windows는 24H2 이전까지 HTML 앱을 지원했음
      Active Desktop 문서를 보면 당시엔 꽤 실험적이었음
    • 하지만 웹 앱의 UX는 여전히 네이티브 앱보다 열악함
      웹은 임시방편일 뿐, 진짜 좋은 경험은 네이티브에서 나옴

  • 2007년쯤 Delphi에서 WPF로 넘어갔지만, 2010년엔 완전히 Windows를 떠남
    Microsoft 내부 정치와 잦은 기술 폐기가 너무 심했음
    Rails가 뜨던 시기라 갈아타기 쉬웠음

    • 지금도 Windows GUI를 쓴다면 WPF를 고수함
      Stockholm 증후군일지도 모르지만, Visual Studio도 여전히 WPF 기반이라 걱정 없음
    • Microsoft는 훌륭한 인재가 많았지만 리더십과 비전 부재로 망가졌음
      오늘날 빅테크의 문제를 미리 보여준 셈임
    • 그래도 VB는 아직도 동작하니, 완전히 버리진 않았음

  • Steven Sinofsky가 최근 같은 주제로 글을 올렸음
    x.com 링크

    • Sinofsky가 .NET을 비판하는 게 웃김
      WinRT 시절 DevDiv에 있었는데, Windows 팀은 개발자 니즈를 몰랐음
      Python/WinRT 프로토타입도 있었지만 “개발자는 JS만 원한다”는 이유로 폐기됨
      Metro 스타일을 강요해 Visual Studio 메뉴를 전부 대문자로 바꾸기도 했음
      Windows RT는 호환성도 끊어버려 앱이 거의 없었고, 결국 실패함
      심지어 Sinofsky의 기술적 주장 중 일부는 틀림 (.NET 3.0은 Vista에 포함되어 있었음)
    • 그 글이 이 기사에 대한 응답글이라 상단에 링크를 추가할 예정임
    • x.com을 거치지 않고 읽는 방법이 있는지 묻는 사람도 있었음
      xcancel.com은 아직 해당 기능을 지원하지 않음

  • 답은 명확함 — Qt임
    농담이 아니라, Electron을 쓰지 않는다면 Qt가 진짜 대안임
    Qt는 이게 핵심 비즈니스라 방향을 자주 바꾸지 않음

답변달기