마이크로소프트 GUI, 왜 늘 흔들렸나

Key Points

• Win16/Win32 시기에는 불편해도 중심축이 있었지만, 이후 GUI 기술이 17종 수준으로 늘며 선택 비용이 커졌다.
• 문제의 핵심은 개별 기술의 품질보다 Microsoft가 무엇을 장기 표준으로 볼지 일관되게 신호를 주지 못했다는 데 있다.
• 개발자가 원하는 것은 가장 새로운 프레임워크보다, 몇 년 뒤에도 후회하지 않을 안정적인 선택지다.

---

Microsoft는 Petzold 이후 일관된 GUI 전략을 갖지 못했다는 말은 조금 과격하게 들리지만, Windows 개발을 오래 본 사람에게는 낯설지 않은 진단입니다. 한때 Windows 앱 개발은 비교적 단순했습니다. Win16, 그리고 Win32 API라는 중심축이 있었고, 개발자는 적어도 어디에 서 있는지는 알 수 있었습니다. 문제는 그다음입니다. 플랫폼은 계속 생겼고, 메시지는 자주 바뀌었고, 개발자는 매번 “이번엔 진짜인가”를 다시 판단해야 했습니다. 좋은 플랫폼 전략은 기술을 늘리는 것이 아니라, 선택 비용을 줄이는 것입니다. Microsoft의 GUI 역사는 그 반대 방향으로 읽히는 순간이 많았습니다.

처음에는 왜 명확했나

1980년대 후반까지 Windows 앱 개발은 상대적으로 단순한 그림을 가졌습니다. 핵심은 Win16/Win32 API였습니다. 물론 사용하기 쉬운 모델은 아니었지만, 적어도 기준은 분명했습니다. 운영체제가 있고, 그 위에 올릴 공식적인 UI 모델이 있으며, 개발자는 그 규칙을 배우면 됐습니다. 복잡함은 있었지만 혼란은 덜했습니다.

좋은 플랫폼이란 늘 가장 쉬운 플랫폼을 뜻하지는 않습니다. 대신 방향이 분명한 플랫폼을 뜻하는 경우가 많습니다. 이 시기의 Microsoft는 바로 그 점에서 강했습니다. 불편해도 기준이 있었고, 기준이 있으면 생태계는 적응할 수 있습니다.

문제는 기술이 많아진 것이 아니라 기준이 흐려진 것이다

제공된 요약에 따르면 이후 수십 년 동안 MFC, COM, WPF, Silverlight, UWP, MAUI 등 17종의 GUI 기술이 공존했다고 합니다. 숫자 17은 여기서 꽤 중요합니다. 개발자가 선택할 수 있는 도구가 많다는 뜻처럼 보이지만, 플랫폼 관점에서는 정반대로 읽힐 수 있습니다. 공식 경로가 많다는 것은 사실상 공식 경로가 없다는 뜻이 되기 쉽기 때문입니다.

예를 들어 프레임워크가 2개면 비교가 가능합니다. 3개면 전략적 선택이 가능합니다. 그런데 17개쯤 되면 비교보다 피로가 먼저 옵니다. 어떤 기술이 현재형인지, 어떤 기술이 유지보수 모드인지, 어떤 기술이 5년 뒤에도 살아남을지 판단하는 비용이 너무 커집니다. 좋은 플랫폼은 코드 작성 비용을 낮춰야 하는데, 이 경우에는 의사결정 비용이 오히려 커졌습니다.

간단히 계산해보면 왜 피로한지 보인다

플랫폼 선택의 어려움은 코드량보다 조합 수에서 체감됩니다. 아래는 17개의 GUI 기술 중 2개만 비교한다고 가정했을 때 가능한 비교 쌍의 수를 계산한 단순 예시입니다.

frameworks = 17
pairs = frameworks * (frameworks - 1) // 2

print(f"프레임워크 수: {frameworks}")
print(f"가능한 비교 쌍: {pairs}")

이 계산에서 비교 쌍은 136개입니다. 실제 개발자가 136개를 모두 비교하는 것은 아니지만, 플랫폼 메시지가 자주 바뀌고 세대가 겹쳐 있으면 체감은 비슷해집니다. “무엇을 배울까”보다 “무엇을 피해야 할까”를 먼저 고민하게 되기 때문입니다. 이 숫자가 말하는 진짜 이야기는 기술의 풍성함이 아니라, 전략의 불명확함입니다.

왜 개발자는 기술보다 신호를 본다

개발자는 프레임워크의 기능만 보고 움직이지 않습니다. Microsoft가 무엇을 밀고 있는지, 무엇을 버릴 가능성이 있는지, 어떤 기술이 공식 행사와 문서에서 전면에 서는지를 함께 봅니다. 이건 단순한 정치 읽기가 아닙니다. GUI 기술은 배운 비용이 크고, 제품 코드에 깊게 박히기 때문입니다.

예를 들어 WPF, Silverlight, UWP, MAUI 같은 이름은 각각 기술 그 자체보다도 “이번이 새로운 기본 경로인가”라는 질문과 함께 기억됩니다. 문제는 그 질문에 대한 답이 자주 바뀌었다는 점입니다. 기술 전환이 반복되면 개발자는 혁신보다 회의감을 먼저 학습합니다.

커뮤니티 반응이 냉소적으로 변한 이유

커뮤니티가 이런 주제에 자주 반응하는 이유는 단순합니다. 많은 개발자가 실제로 그 전환 비용을 몸으로 겪었기 때문입니다. 새 프레임워크를 배우고, 코드를 일부 옮기고, 앱 전략을 바꾸고, 몇 년 뒤 다시 다른 이름이 등장하는 경험이 반복되면 기대보다 방어가 먼저 생깁니다. “이번엔 진짜인가?”라는 반응은 우연히 나온 것이 아닙니다.

이런 냉소는 기술에 대한 적대감이라기보다, 플랫폼 운영 방식에 대한 피로에 가깝습니다. 커뮤니티는 새로운 GUI 기술을 싫어해서가 아니라, 새로운 GUI 기술이 또 버려질 가능성을 계산해야 하는 상황을 싫어합니다.

그렇다고 아무 가치가 없었던 것은 아니다

여기서 균형은 필요합니다. MFC, WPF, UWP, MAUI가 모두 실패작이었다고 보는 것은 과합니다. 각각은 당시의 제약과 목표 속에서 의미가 있었고, 실제로 특정 환경에서는 꽤 유용했습니다. 문제는 개별 기술의 품질보다 전체 포트폴리오의 방향성입니다. 하나하나는 쓸 만해도, 전체 전략이 흔들리면 플랫폼 신뢰는 약해집니다.

좋은 도구 몇 개가 있다고 해서 좋은 플랫폼 전략이 되는 것은 아닙니다. 좋은 플랫폼 전략은 결국 “지금 무엇을 선택해야 하는가”를 분명하게 말해줘야 합니다.

왜 이런 플랫폼은 오래 흔들리는가

폴 그레이엄 식으로 정리하면, 살아남는 플랫폼은 개발자에게 자유를 많이 주는 플랫폼이 아니라, 불필요한 선택을 줄여주는 플랫폼인 경우가 많습니다. Microsoft의 GUI 전략이 반복해서 비판받는 이유는 기술이 부족해서가 아니라, 기술이 너무 자주 “새 중심”처럼 등장했기 때문입니다. 중심이 자주 바뀌면 생태계는 확장보다 방어적으로 변합니다.

Microsoft는 Petzold 이후 일관된 GUI 전략을 갖지 못했다는 문장은 그래서 단지 과거 회고가 아닙니다. 이 말은 플랫폼이 신뢰를 잃는 방식에 대한 설명이기도 합니다. 개발자는 가장 화려한 GUI 기술을 원하는 것이 아닙니다. 5년 뒤에도 후회하지 않을 선택지를 원합니다. 결국 살아남는 플랫폼은 가장 많은 기술을 가진 플랫폼이 아니라, 가장 적은 불확실성을 남기는 플랫폼입니다.