Hacker News 의견들

• 나도 다른 사람들처럼 Win32를 고수하는 게 맞다고 생각함
  오랜 기간 Win32로 개발해온 입장에서, 필요한 기능은 8KB 이하의 독립 실행 파일로 충분히 구현 가능함
  디스플레이 열거, 창 생성, 단축키 후킹, 시작 프로그램 등록, 설정 저장, 트레이 아이콘 표시 등 모두 몇백 바이트 수준의 API 호출로 가능함
  하지만 2026년에 새 프로젝트를 메모리 안전하지 않은 언어(C++) 로 작성하는 건 시대착오적임
  다만, 신뢰되지 않은 입력이 거의 없는 앱이라면 굳이 선전(Propaganda)에 휘둘릴 필요는 없음

  • 메모리 안전성과 _UNICODE 문제를 피하고 싶다면 .NET Framework로 절반의 시간에 같은 걸 만들 수 있음
  • 예전에는 Delphi나 MFC 같은 얇은 레이어가 이런 문제를 해결했지만 지금은 유행이 지나고 대체제가 없음
    “NoFramework” 운동이 다시 나와서 RAD 시대로 돌아가야 한다고 생각함
  • Win32는 여전히 풍부한 문서와 도구가 있고, 앞으로도 오래 살아남을 것임
    하지만 새 프로젝트에서 C++을 선택하는 건 신중해야 함
    메모리 안전 언어에서도 Win32를 쓸 수 있음 — 예를 들어 windows-rs
  • 일반 사용자 눈에 Win32 앱을 예쁘게 보이게 하려면 어떻게 해야 하는지 궁금함
  • Winamp 개발자들은 어떻게 그렇게 훌륭한 Win32 앱을 만들었을까 궁금함
    당시엔 Borland Delphi가 가장 인기 있는 도구였음

• 기존 WinRT, UAP, UWP 앱이 아니라면 WinUI 3.0이나 WinAppSDK는 피해야 함
  Win32, MFC, WinForms, WPF 같은 검증된 기술을 계속 쓰는 게 낫고,
  Microsoft 외부 생태계라면 Qt, VCL, Firemonkey, Avalonia, Uno, ImGUI 등을 고려할 만함
  WinUI 3.0은 너무 엉망이라 Microsoft조차 커뮤니티에 오픈소스로 넘기려는 중임

  • 예전에 WinJS로 Windows 8 앱을 만들어 Windows Store에 올렸었음
    이후 WinJS가 오픈소스 웹 프레임워크로 전환되면서 공식 지원이 끊겼음
  • 최근 블로그에서 “Windows 핵심 경험을 WinUI3로 이전한다”는 발표가 있었는데, 품질 개선을 위한 조치라지만 불안함
    관련 블로그 글

• 임베디드 개발자인데, 장치와 통신하는 Win32 GUI 프로그램을 만드는 게 여전히 쉬움
  XP 시절 코드가 Windows 11에서도 그대로 동작했고, VC6 프로젝트를 Visual Studio 2022로 열어도 문제없이 빌드됨
  이런 하위 호환성은 다른 플랫폼에서 보기 힘듦

  • 나는 차라리 투박한 Win32 코드를 계속 쓰는 게 낫다고 느낌
    Apple의 Cocoa는 구조는 “우아”하지만 실제로는 복잡하고 문서도 불친절함
  • 요즘 개발자들은 매주 바뀌는 생태계에 익숙해서, 오래된 게 “유지보수 안 되는 것”이라 생각하는 경향이 있음
  • 다만 고해상도 DPI나 입력 처리 문제 등은 여전히 까다로움
  • 32비트에서 64비트로 완전 이전하는 게 가장 큰 도전이었음
  • 문자열 정의 방식이 너무 많아서 혼란스러움

• 순수 Win32 API는 여전히 실용적인 선택임
  C++로 MFC 비슷한 래퍼를 직접 만들면 2~3주 안에 완성 가능하고, 이후엔 완전한 제어권을 가질 수 있음
  Microsoft의 강력한 하위 호환성 덕분에 Win32 기반 앱은 장기적으로 안정적임
  10년 넘게 업데이트한 예시를 여기에서 볼 수 있음

  • 다크 모드 지원이 가장 큰 문제임
    시스템 색상과 컨트롤이 하드코딩되어 있어서 어두운 테마와 충돌함
    메뉴나 메시지 박스, 파일 대화상자 등 일부 UI만 다크 모드를 지원해 일관성이 깨짐
  • 이 접근법은 Windows 11 스타일 UI를 만들지 못함
    관련 논의는 이 글 참고
  • 예전에 WTL 3.0을 썼는데, MFC보다 훨씬 가볍고 Win32 기능에 모두 접근 가능했음
    현재는 오픈소스로 유지되고 있고 버전 10까지 나와 있음
  • MFC 스타일 래퍼의 API 설계를 잘 하면, AI가 구현을 대신 작성해줄 수도 있음
  • 차라리 C++ Builder나 Delphi를 쓰는 게 낫지 않냐는 의견도 있음

• Windows 앱을 여러 개 만들어본 경험상,
  (1) Win32 API는 오래됐지만 매우 안정적이고,
  (2) Microsoft 소유 UI 툴킷은 피해야 함 — 결국 Win32 레벨의 제어가 필요해짐

  • 다만 WPF와 WinForms는 예외적으로 안정적임
    지난 20년간 Microsoft가 만든 UI 기술 대부분이 WPF의 변형이었음
    WPF를 계속 발전시켰다면 지금쯤 UI 개발의 표준이 되었을 것임

• 사용자 입장에서는 네이티브 앱이 빠르고 좋지만, 개발은 정말 복잡한 혼돈임
  Outlook과 Teams 같은 앱이 점점 나빠지는 이유도 이 때문임

  • 아이러니하게도 Outlook과 Teams가 웹앱 기반(Electron) 이라서 그런 문제를 겪음
    포커스, 키보드 내비게이션 등에서 네이티브 감각을 흉내내기 어려움
  • 나도 개인 도구를 만들 때 TypeScript + Bun + Electrobun 조합을 씀
    Electrobun 프로젝트 참고
  • Microsoft조차 Electron으로 앱을 만들고 있으니, 다른 개발자들에게 뭘 기대하겠음

• “C++로 새 프로젝트를 만드는 건 범죄”라는 말엔 동의하지 않음
  GUI는 안전성보다 성능과 제어가 중요하고, C++은 여전히 검증된 언어임
  Qt는 2026년에도 최고의 GUI 프레임워크 중 하나로, 메모리 안전 기능을 내장하고 있음

  • 하지만 Qt는 일부 Linux 배포판에서만 진정한 네이티브로 동작함
  • Qt 앱은 런타임이 필요하므로 완전한 네이티브라 보긴 어려움
  • 물론 관리형 환경에 비하면 불편하지만, 임베디드 환경에서는 여전히 유용함

• 왜 최신 .NET 런타임이 Windows 11에 기본 포함되지 않는지 의문임
  이는 Microsoft가 일관된 사용자 경험을 포기한 또 다른 사례로 보임

  • .NET 버전이 너무 많고 완전한 하위 호환이 아니기 때문에,
    Windows Update로 모두 배포하는 건 비현실적임
    대신 AOT 컴파일된 독립 실행 파일로 배포할 수 있음 (약 9MiB)
    Electron보다 훨씬 작고 효율적임
  • 예전엔 Windows Update로 배포했지만, 업데이트가 앱을 깨뜨리거나 너무 커서 비효율적이었음
    지금은 DLL을 함께 패키징하는 게 더 나음
  • .NET 5 이후 보안 모델과 네임스페이스가 크게 바뀌어
    OS에 내장하기 어려워졌음
    빠른 릴리스 주기를 유지하려고 OS 업데이트와 분리한 것임
  • 현재는 레거시 .NET Framework가 OS에 포함되고,
    .NET Core는 별도로 설치해야 하는 구조임

• 오랜만에 Tauri로 Windows와 Mac용 앱을 만들어봤는데,
  개발과 빌드는 쉬웠지만 코드 서명 문제로 동료들이 설치를 못 했음
  Mac에서는 터미널 명령으로 해결했지만, Windows는 Smart App Control을 꺼야 했고
  이 기능은 재설치 없이는 다시 켤 수 없음
  보안 목적은 이해하지만, 설치 과정이 이렇게 어려울 줄은 몰랐음

• “왜 Electron을 쓰지 않느냐”는 질문의 답은 간단함 —
  Electron 앱은 사용자 경험이 나쁨
  개발은 쉽지만, 성능과 품질을 희생함
  좋은 제품을 만들고 싶다면 어렵더라도 네이티브로 가야 함
  개인적으로는 C#이 TypeScript보다 훨씬 낫다고 생각함