# Microsoft는 Petzold 이후 일관된 GUI 전략을 갖지 못했다 > Clean Markdown view of GeekNews topic #28258. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28258](https://news.hada.io/topic?id=28258) - GeekNews Markdown: [https://news.hada.io/topic/28258.md](https://news.hada.io/topic/28258.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-06T17:32:54+09:00 - Updated: 2026-04-06T17:32:54+09:00 - Original source: [jsnover.com](https://www.jsnover.com/blog/2026/03/13/microsoft-hasnt-had-a-coherent-gui-strategy-since-petzold/) - Points: 8 - Comments: 2 ## Topic Body - 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판 이후 집필을 중단** ## Comments ### Comment 54861 - Author: iolothebard - Created: 2026-04-07T19:42:44+09:00 - Points: 2 기승전 Win32?!! ### Comment 54770 - Author: neo - Created: 2026-04-06T17:32:54+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47651703) - 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 기반이었고, [포럼 글](https://community.logos.com/discussion/6200)에서도 같은 불만이 많았음 - 2010~2011년경 복잡한 WPF 앱을 만들었는데, 성능이 HTML/JS/Blink보다 훨씬 나빴음 결국 대부분의 코드를 Direct3D/Direct2D로 다시 구현했음 **WPF 아키텍처** 자체가 문제였음 - 2010년쯤 **Evernote가 WPF를 버린 사례**가 있었음 이유는 흐릿한 텍스트와 성능 문제였다고 함 관련 글: [edandersen.com](https://www.edandersen.com/p/evernote-has-no-patience-drops-...) / [Reddit](https://www.reddit.com/r/csharp/comments/x0nu7h/comment/im9k...) - 문제는 WPF가 아니라 Microsoft가 **Intel의 저성능 하드웨어**를 ‘충분하다’고 인정한 게 더 큰 원인임 관련 기사: [Ars Technica](https://arstechnica.com/gadgets/2008/03/the-vista-capable-de...) - 이건 마치 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](https://pwabuilder.com)로 앱스토어 배포도 가능함 나는 이 프로젝트에 참여 중이며, **Electron 없이도 빠르고 가벼운 앱**을 만들 수 있음 - Windows는 24H2 이전까지 **HTML 앱**을 지원했음 [Active Desktop 문서](https://learn.microsoft.com/en-us/previous-versions/ms536495...)를 보면 당시엔 꽤 실험적이었음 - 하지만 웹 앱의 UX는 여전히 **네이티브 앱보다 열악**함 웹은 임시방편일 뿐, 진짜 좋은 경험은 네이티브에서 나옴 - 2007년쯤 Delphi에서 WPF로 넘어갔지만, 2010년엔 완전히 **Windows를 떠남** Microsoft 내부 정치와 잦은 기술 폐기가 너무 심했음 Rails가 뜨던 시기라 갈아타기 쉬웠음 - 지금도 Windows GUI를 쓴다면 **WPF를 고수**함 Stockholm 증후군일지도 모르지만, Visual Studio도 여전히 WPF 기반이라 걱정 없음 - Microsoft는 훌륭한 인재가 많았지만 **리더십과 비전 부재**로 망가졌음 오늘날 빅테크의 문제를 미리 보여준 셈임 - 그래도 **VB는 아직도 동작**하니, 완전히 버리진 않았음 - Steven Sinofsky가 최근 같은 주제로 글을 올렸음 [x.com 링크](https://x.com/stevesi/status/2036921223150440542) - 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는 이게 **핵심 비즈니스**라 방향을 자주 바꾸지 않음