Windows 데스크톱 앱을 만들 때 무엇을 써야 하는지 10초 안에 답하지 못하는 플랫폼은 개발자에게 실패한 것이다. Win32에서 WPF, Silverlight, WinRT/UWP, WinUI 3까지 이어진 Microsoft GUI 전략의 붕괴를 되짚는다.
검색
게시일: March 13, 2026 작성자: jsnover
몇 년 전 개발자들과 회의 중에 누군가 아주 단순한 질문을 했다. “새 Windows 데스크톱 앱을 만들 때 올바른 프레임워크는 뭔가요?”
완전한 침묵.
누군가는 WPF를 제안했다. 다른 누군가는 WinUI 3라고 했다. 세 번째 사람은 그냥 Electron을 써야 하는지 물었다. 회의는 산으로 갔고 우리는 결국 그 질문에 답하지 못했다.
그 침묵이 이야기다. 그리고 그 이야기는 30년도 더 전으로 거슬러 올라간다.
플랫폼이 “UI를 어떻게 만들어야 하나요?”라는 질문에 10초 안에 답하지 못한다면, 그 플랫폼은 개발자에게 실패한 것이다. 그게 전부다.
1988년, Charles Petzold가 _Programming Windows_를 출간했다. 852쪽. C로 된 Win16 API. 그 방대한 분량에도 불구하고, 그것은 놀라운 무언가를 상징했다. Windows 애플리케이션을 어떻게 작성하는지에 대해 단 하나의, 일관되고, 권위 있는 답이 존재했다는 것. 업계에서는 이런 걸 ‘전략’이라고 부른다.
뒤이어 나온 Win32는 더 거대했지만 여전히 일관적이었다. 메시지 루프. 윈도우 프로시저. GDI. 멘탈 모델이 좀 괴상하긴 했지만, 멘탈 모델은 _하나_였다. Petzold가 그것을 설명했다. 그것은 Windows의 F=MA였다. 단순하다. 강력하다. 배운다. 쓴다. 성공한다.
명확성은 친구다! OS 하나, API 하나, 언어 하나, 책 하나. 관리 코드 대안을 놓고 위원회가 토론하는 일 따위는 없었다. Win32와 Petzold가 있었고, 그건 통했다. 이것은 화학이 아니라 물리였다(이건 되긴 하는데 주기율표의 이 조각에서만. 그리고 이 압력에서만. 그리고 이 온도에서만. 그리고 달이 목성의 7번째 궁에 있을 때만).
그 다음에 벌어진 일은, 뛰어난 인재와 막대한 자원을 가진 회사가 잘못된 것들을 최적화함으로써 30년에 걸친 boof-a-rama를 만들어내는 방식에 대한 마스터클래스다. AKA 똑똑한 사람들이 멍청한 짓을 하는 것.
Win32에는 실제 한계가 있었고, 그래서 Microsoft는 Microsoft답게 행동했다. 개발자 컨퍼런스를 위해 새로운 것을 출시했다. 여러 개의 ‘새로운 것’을.
MFC(1992)는 Win32를 C++로 감쌌다. Win32가 우아하지 않았다면, MFC는 다른 턱시도들로 만들어진 턱시도를 입은 Win32였다. 그 다음엔 OLE. COM. ActiveX. 이 중 어느 것도 진짜 GUI 프레임워크는 아니었다—컴포넌트 아키텍처였다—하지만 Windows 개발의 구석구석을 감염시켰고, Kierkegaard를 Hemingway처럼 읽히게 만들 정도의 인지적 복잡성을 도입했다.
나는 90년대 후반에 한 컨퍼런스 세션에서 OLE 문서, COM 오브젝트, ActiveX 컨트롤의 차이를 이해하려고 앉아 있었다. 나는 그 발표자를 한 시간 내내, 마치 입에서 쥐 꼬리가 삐져나온 사람처럼 쳐다봤다.
Microsoft는 일관된 이야기를 팔고 있지 않았다. 기술 프리미티브를 팔고는 개발자들에게 스스로 이야기를 만들라고 했다. 그게 바로 Conference Keynote Cluster***k이다—Microsoft는 사용자나 개발자의 성공이 아니라, 임원이 키노트로 사람들을 감탄시키는 것을 최적화했다.
PDC 2003에서 Microsoft는 Longhorn을 공개했다—진정으로 회사가 개발자들 앞에 내놓은 기술적 비전 중 가장 매력적인 것들 중 하나였다. 세 가지 기둥: WinFS(관계형 파일 시스템), Indigo(통합 커뮤니케이션), 그리고 Avalon—나중에 WPF—즉 XAML이라는 선언적 XML 언어로 구동되는 GPU 가속 벡터 기반 UI 서브시스템. 개발자들은 Avalon 데모를 보고 완전히 _열광_했다. 그건 올바른 비전이었다.
하지만 Jim Allchin의 2004년 1월 내부 메모 표현을 빌리자면, 그것은 “돼지”였다.
2004년 8월까지 Microsoft는 완전한 개발 리셋을 발표했다. 폐기. 다시 시작. Server 2003 코드베이스에서 재출발. 그리고 리셋 이후, 리더십은 조용한 지시를 내렸다: Windows에는 f***ing 관리 코드는 없다. 모든 신규 코드는 C++로. WPF는 Vista와 함께 출시되지만, 셸 자체는 WPF를 사용하지 않는다.
Windows 팀의 .NET에 대한 앙금은 끝내 치유되지 않았다. 그들의 관점에서, 새로운 관리 코드 프레임워크에 베팅한 것은 회사 역사상 가장 창피한 실패를 낳았다. 그 앙금은 Windows 팀과 .NET 팀 사이에 13년에 걸친 제도적 내전을 만들었고, 결국 WPF를 고아로 만들고, Silverlight를 죽이고, UWP를 망치고, 오늘날의 GUI 생태계 boof-a-rama를 낳았다.
WPF는 2006년 말에 출시됐다. 놀라운 제품이었다—XAML, 하드웨어 가속 렌더링, 진짜 데이터 바인딩. Microsoft가 그것을 결정적 해답으로 만들고 집요하게 투자했다면 이야기는 달라졌을지도 모른다. 그러나 2007년, 그들은 Silverlight를 출시했다. Flash에 맞서기 위한, 간소화된 브라우저 플러그인. 크로스 플랫폼. 우아함. 그리고 Windows Phone의 기반. 2010년 무렵에는 리치 클라이언트의 미래처럼 보였다.
그러다가 MIX 2010에서, Microsoft 임원이 Q&A에서 Silverlight는 크로스 플랫폼 전략이 아니라—Windows Phone을 위한 것이라고 말했다. 이제 HTML5가 정책이었다. Silverlight 팀은 이런 변화가 올 줄 알지 못했다. Silverlight에 LOB 애플리케이션을 걸었던 개발자들은 컨퍼런스 Q&A에서 그 사실을 알게 됐다.
Silverlight는 기술적 실패로 죽은 게 아니다. 기술은 괜찮았다. 그것은 비즈니스 전략 결정으로 죽었고, 개발자들은 가장 마지막에 알았다.
그 패턴을 기억하라. 다시 보게 될 것이다.
Apple은 iPhone을 2억 대 팔았다. iPad는 PC 판매를 잠식하고 있었다. Microsoft의 답은 Windows 8과 Metro—.NET 위에 의도적으로 구축되지 않은 터치 우선 런타임 WinRT였다. Windows 팀의 앙금을 기억하는가? 여기서 드러난다. WinRT는 네이티브 C++ 런타임이었다. WPF, WinForms, 그리고 .NET에 대한 10년치 개발자 투자를 끊어내는 깔끔한 단절.
실제로 Microsoft 내부에서는 동시에 두 가지 이야기가 흘러나오고 있었다. Windows 팀은 WinRT를 만들고 있었고, .NET 팀은 여전히 WPF를 전도하고 있었다. 서로 다른 건물, 서로 다른 VP, 서로 다른 로드맵.
개발자들이 //Build 2012에서 들은 말: 미래는 WinRT다, 그리고 HTML+JS도 1급 시민이다, 그리고 .NET도 여전히 된다, 그리고 C++도 돌아왔다, 그리고 Metro 앱을 작성해야 한다, 그리고 WPF 코드는 여전히 잘 돈다. 그건 전략이 아니다. 그건 여섯 팀이 당신의 관심을 두고 싸우는 Hunger Games 무대다.
엔터프라이즈 개발자들은 UWP의 샌드박싱, Store 배포 요구, 그리고 빠진 Win32 API를 한 번 보고는 등을 돌렸다. 그들을 모던 시대로 끌어들이기 위해 설계된 프레임워크가, 존재하지도 않게 된 태블릿 앱 스토어를 위해 최적화돼 있었던 것이다.
Windows 10은 Universal Windows Platform을 가져왔다—한 번 작성하면 PC, 폰, Xbox, HoloLens에서 실행. 문서로는 매력적이었다. 문제는 Windows Phone이 죽어가고 있었고, Microsoft의 대표 앱들—Office, Visual Studio, 셸 자체—이 UWP를 쓰지 않고 있었다는 점이다. 아무도 소리 내어 말하지 않았지만 메시지는 분명했다.
UWP가 주춤하자 공식 답은 _상황에 따라 다르다_가 됐다. 새 앱은 UWP를 쓰고, 기존 앱은 WPF를 유지하고, XAML Islands로 모던 API를 더하고, WinUI 3를 기다리되, UWP 전용인 WinUI 2도 있고, Project Reunion이 모든 걸 고칠 거지만, 사실 이름을 Windows App SDK로 바꿨고, 그런데도 UWP를 완전히 대체하진 못했고…
똑똑한 사람들이 멍청한 짓을 하는 것. 기술적 브라운 운동.
Project Reunion / WinUI 3는 진짜 진보다. 하지만 왜 애초에 그 문제가 존재했는지 자문해 보라. UWP의 컨트롤은 OS에 묶여 있었는데, Windows 팀이 그것을 소유했기 때문이다. .NET 팀은 아니었다. 개발자 도구 팀도 아니었다. Project Reunion은 조직적 우회로를 기술적 해결책처럼 포장한 것이었다.
한 개발자의 요약(2024년 작성): “Microsoft의 끊임없는 변화를 따라왔습니다: UAP, UWP, 도구 지원 없이 C++/CX가 C++/WinRT로 대체, XAML Islands, XAML Direct, Project Reunion, WinAppSDK의 재시작, WinUI 2.0과 3.0 사이의 혼란스러운 전환…” 14년. 14번의 피벗. 그 사람은 그 순서대로, 훈장과 사과를 받을 자격이 있다.
오늘날 Windows에서 실제로 출시되어 있는 GUI 기술은 다음과 같다:
Microsoft 네이티브 프레임워크:
Microsoft 웹-하이브리드:
서드파티:
17가지 접근법. 5개 프로그래밍 언어. 3가지 렌더링 철학. 그건 플랫폼이 아니다. boof-a-rama라는 용어에 대한 사전적 정의가 내게 없을지 모르지만, 나는 하나를 보면 안다.
실패한 GUI 이니셔티브는 모두 세 가지 원인 중 하나로 귀결된다: 내부 팀 정치(Windows vs. .NET), 개발자 컨퍼런스 발표가 이끄는 성급한 플랫폼 베팅(Metro, UWP), 혹은 개발자들을 경고 없이 고아로 만드는 비즈니스 전략 피벗(Silverlight). 이 중 어느 것도 기술적 실패가 아니다. 기술은 종종 진짜로 좋았다—WPF는 좋았고, Silverlight도 좋았고, XAML도 좋다. 조직적 실패가 곧 제품이었다.
채택, 투자, 유지보수, 마이그레이션을 포함하는 전체 라이프사이클을 덮는 그럴듯한 성공 이론(Plausible Theory of Success)이 있든가, 아니면 개발자 컨퍼런스 키노트가 있을 뿐이다.
하나는 전략이다. 다른 하나는 30년에 걸친 boof-a-rama다.
Charles Petzold는 Microsoft가 매번 새로 발표하는 것을 따라잡기 위해 _Programming Windows_를 6판까지 썼다. 그는 Windows 8의 WinRT를 다룬 6판 이후로 멈췄다. 그게 2012년이다.
그를 탓할 수는 없다.
이 항목은 Uncategorized에 jsnover가 게시했습니다. 퍼머링크를 북마크하세요.
Matthew Adams on March 13, 2026 at 4:20 amsaid: 이 모든 것의 근본 원인이, 우리가 X-Plat 세계에 살고 있다는 것을 믿기 어려울 정도로 늦게 깨달았고, Windows가 모든 것의 중심이라는 개념을 놓기를 거부했다는 점이라고 주장할 수도 있겠습니다.WPF는 그 때문에 목이 졸렸고(그림자 속에 숨어 있던 x-plat MIL 구현들이 있었음에도), Silverlight는 결국 그 때문에 폐기되었습니다. 다양한 Windows 전용 후계 기술들도 그 관념에서 태어났고요. 항상 중요한 위치를 유지할 가능성이 큰 사업부를 위한 후방 방어전이었지만, ‘왕권신수설’은 내려놓아야 했습니다. 답글 ↓
* 
우리는 Silverlight를 위해 WPF 자금도 굶겼습니다. 실수는 많았지만, Silverlight에 ‘사형 선고’가 표시된 진짜 순간은 “Out of Browser” 기능을 출시했을 때였습니다. 그때 Steve Sinofsky 추종자들이 우리에게 내려오기 시작했죠.
또 이 무렵 Windows 팀이 XAML을 흡수하고 Windows 8 이후의 길은 C#이 아니라 C++ 또는 JS라고 선언했습니다. 그리고 Steve Jobs가 그 편지를 올렸고, 그게 ActiveX에게는 거의 1000번째 칼질이었습니다. 답글 ↓
Pingback: 微软自Petzold以来一直没有一个统一的GUI战略。 - 偏执的码农
Pingback: Windows UI History | Fruity Dev Log
2026년, 이제 아무도 Windows 앱을 개발하지 않습니다. 모든 레거시 앱은 업데이트됐고, 새로 만들어지는 건 큰 앱들뿐입니다. 저는 수년 동안 흥미로운 UI를 가진 새 Windows 앱을 단 한 번도 못 봤습니다.
고치는 방법
Windows UI 및 디자인 팀 전체를 해고하라—어차피 다들 macs 쓰는 거 우리도 알잖아요
기존 WinAPI UI를 확장하고, 새 함수와 새 메트릭을 추가하라
새롭고 네이티브인 멋진 컴포넌트를 도입하라
Visual Studio에 시각적 스타일링을 추가해 XAML 헛소리 없이 폼을 대화형으로 설계할 수 있게 하라(Delphi가 어떻게 했는지 보라)
컨트롤을 위한 다양한 그래픽 포맷 지원을 도입하라(icons, JPG, WEBP, SVG, AVIF)
컨트롤에서 mp4 포맷 애니메이션 지원을 도입하라. 예: 버튼에 애니메이션 아이콘 추가
폼에 손쉬운 테마 생성(및 DPI 지원)과 동적 스키닝을 추가하고, Visual Studio에서 C++ 및 .NET 앱을 위해 동적으로 폼을 만들고 대화형으로 설계하는 기능을 도입하라(Delphi는 1998년에 했다!) 답글 ↓
Ron Perrella on March 13, 2026 at 7:01 pmsaid: 네, MacBooks는 윈도우 개발자와 사용자에게 모욕입니다. Mac을 원했다면 Mac을 샀을 겁니다. Windows를 Mac처럼 보이게 만드는 걸 멈추세요. Mac을 부러워하는 팀을 고용하지 마세요. 훨씬 더 잘할 수 있습니다. 답글 ↓
이메일 주소는 공개되지 않습니다.필수 입력란은 표시되어 있습니다 *
댓글 *
이름 *
이메일 *
웹사이트
Δ
