마이크로소프트는 왜 30년째 GUI 프레임워크를 통일하지 못할까

Petzold 이후로 길을 잃다

Windows 개발을 해보신 분이라면 "찰스 펫졸드(Charles Petzold)"라는 이름을 한 번쯤 들어보셨을 거예요. 이 분이 쓴 Programming Windows라는 책은 Win32 API 시대의 바이블이었거든요. 그 시절에는 답이 명확했어요. Windows에서 GUI를 만들려면 Win32 API를 쓰면 됐어요. 선택지가 하나였으니 혼란도 없었죠.

그런데 문제는 그 이후예요. 마이크로소프트가 내놓은 GUI 프레임워크를 한번 나열해볼게요. MFC, Windows Forms, WPF, Silverlight, UWP, WinUI 2, WinUI 3, MAUI, Blazor Hybrid... 이걸 보면 "도대체 뭘 써야 하지?"라는 생각이 드는 게 당연해요. 이 글의 저자 Jeffrey Snover는 바로 이 점을 지적하고 있어요. 마이크로소프트가 펫졸드 시대 이후로 일관된 GUI 전략을 한 번도 가진 적이 없다는 거예요.

프레임워크 무덤의 역사

조금 더 구체적으로 이 역사를 풀어볼게요. 2000년대 초반, .NET과 함께 Windows Forms(WinForms)가 나왔어요. Win32 API를 C#으로 쉽게 쓸 수 있게 감싼 거였는데, 꽤 잘 됐어요. 간단하고 직관적이어서 빠르게 데스크톱 앱을 만들 수 있었거든요.

그런데 마이크로소프트가 가만히 있지 않았어요. 2006년에 WPF(Windows Presentation Foundation)를 내놨는데, 이건 완전히 다른 접근이었어요. XAML이라는 마크업 언어로 UI를 선언적으로 구성하고, 벡터 기반 렌더링으로 더 화려한 UI를 만들 수 있게 한 거예요. 문제는 WinForms를 대체하겠다고 했으면서 WinForms를 공식적으로 폐기하지도 않았다는 거예요. 두 개가 공존하면서 개발자들이 갈라졌죠.

다음은 Silverlight인데요. 이건 웹 브라우저에서 WPF 비슷한 걸 돌리겠다는 야심찬 프로젝트였어요. 한때 잘 나갔지만 모바일 시대가 오면서 Flash와 함께 사라졌죠. 그다음에는 Windows 8과 함께 UWP(Universal Windows Platform)가 등장했어요. "하나의 앱으로 PC, 태블릿, Xbox, 폰 전부 지원한다"는 비전이었는데, 현실은 달랐어요. 기존 Win32 앱과의 호환성 문제, 스토어 전용 배포 제한 등으로 개발자들이 외면했거든요.

그러고 나서 WinUI 3, MAUI(.NET Multi-platform App UI), Blazor Hybrid가 나왔는데... 이쯤 되면 패턴이 보이시죠? 새 프레임워크 발표 → 이전 프레임워크 방치 → 개발자 혼란 → 또 새 프레임워크. 이게 반복되는 거예요.

왜 이런 일이 반복되나요?

저자는 이게 단순히 기술적 판단 실수가 아니라 조직 구조의 문제라고 봐요. 마이크로소프트 같은 거대 기업에서는 각 팀이 자기만의 프레임워크를 만들고 싶어 하거든요. Windows 팀, Office 팀, .NET 팀, 개발자 도구 팀이 각각 다른 방향을 보면서 "우리 프레임워크가 표준이 되어야 한다"고 주장하는 거예요. 그 결과 회사 차원의 통일된 전략이 만들어지지 않는 거죠.

반면 Apple은 어떤가요? UIKit에서 SwiftUI로의 전환은 물론 완벽하진 않지만, 적어도 "앞으로는 SwiftUI를 쓰세요"라는 방향이 명확해요. 구글도 Android에서 Jetpack Compose를 밀면서 비교적 일관된 메시지를 주고 있고요. 웹 프론트엔드 세계에서도 React, Vue, Svelte 같은 선택지가 있지만, 적어도 각각이 독립적인 커뮤니티에서 발전하는 거잖아요. 한 회사가 매번 새 프레임워크를 내면서 이전 걸 버리는 것과는 다르죠.

한국 개발자에게 주는 시사점

"나는 Windows 데스크톱 개발 안 하는데?"라고 생각하실 수 있어요. 하지만 이 이야기에서 얻을 수 있는 교훈은 꽤 보편적이에요.

첫째, 기술 선택의 중요성이에요. 프레임워크를 고를 때 단순히 "최신이냐"가 아니라 "이 기업이 이걸 얼마나 오래 지원할 의지가 있느냐"를 봐야 해요. 마이크로소프트의 사례는 대기업이 만든 프레임워크라고 해서 무조건 안전한 게 아니라는 걸 보여주거든요.

둘째, 한국 기업 중에서도 레거시 Windows 데스크톱 앱을 운영하는 곳이 꽤 많아요. 금융권, 공공기관, 제조업 MES 시스템 같은 데서요. 이런 곳에서 "WinForms 앱을 뭘로 마이그레이션할까?"는 현실적인 고민인데, 마이크로소프트가 방향을 계속 바꾸니까 결정을 내리기가 어려운 거예요. 당장 마이그레이션 계획이 있는 팀이라면, 특정 프레임워크에 올인하기보다 웹 기반(Electron, Tauri 등)으로 가는 것도 진지하게 고려해볼 만해요.

셋째, 이 문제는 프론트엔드 생태계 전반의 교훈이기도 해요. 프레임워크 피로(framework fatigue)라는 말이 괜히 나온 게 아니거든요. 핵심 원리(HTML, CSS, JavaScript 기본기, UI 설계 패턴)를 탄탄히 익혀두면 프레임워크가 바뀌어도 적응이 빠르다는 건 변하지 않는 진리예요.