▲

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

 (jsnover.com)
1P by GN⁺ 8시간전 | ★ favorite | 댓글 1개
  • 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년 혼란의 상징적 종결로 언급됨

함께 보면 좋은 글 β

▲
GN⁺ 8시간전  [-]
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는 이게 핵심 비즈니스라 방향을 자주 바꾸지 않음

답변달기