본문으로 건너뛰기
피드

윈도우 네이티브 앱 개발이 이렇게 개판인 줄 몰랐음 (현직 개발자 회고)

frontend 약 6분
vote
0
댓글
북마크

윈도우 개발 추억 있는 개발자가 소소한 유틸리티 앱 하나 만들려다 현실에 박살난 썰. Win32부터 WinUI 3까지 수십 년간 쌓인 레거시와 미완성 API들 때문에 결국 '그냥 Electron 쓰는 게 맞다'는 결론에 도달함. 마이크로소프트가 자기 플랫폼을 방치하는 수준이 ㄹㅇ 심각함.

  • 1

    WinUI 3까지 7세대 UI 프레임워크를 갈아치웠지만 기능 공백은 여전히 존재

  • 2

    최신 Windows 11에도 .NET 4.8.1만 내장 → 배포 경험이 최악

  • 3

    트레이 아이콘, 글로벌 단축키 등 기본 기능도 Win32 P/Invoke 직접 호출 필요

  • WinUI 3까지 이어지는 UI 프레임워크 역사: Win32 → MFC → WinForms → WPF → WinRT → UWP → WinUI 3, 매번 갈아엎는 거 반복
  • 최신 Windows 11에도 기본 탑재 .NET은 4.8.1인데 현재 버전은 10임 ㄷㄷ
  • 트레이 아이콘, 글로벌 단축키 등 기본 기능도 P/Invoke로 Win32 직접 호출해야 함
  • MSIX 코드 서명 인증서가 비거주자 기준 연 $200~300 ㅋㅋ 그냥 Apple보다 비쌈
  • 결론: "그냥 Electron/Tauri 써라, 웹스택이 훨씬 낫다"

개발자가 만든 앱: Display Blackout

저자는 3모니터 세팅에서 게임할 때 양쪽 모니터를 블랙아웃하는 유틸리티를 만들려 했음. OLED 모니터에 검은 오버레이를 씌우면 픽셀이 꺼져서 전원 차단이랑 사실상 동일한 효과. 간단해 보이는 기능인데 요구사항이:

  • 디스플레이 목록 및 영역 감지
  • 테두리/타이틀바 없는 투명 창 생성
  • 글로벌 키보드 단축키 인터셉트
  • 시작프로그램 등록
  • 설정 저장
  • 트레이 아이콘 + 메뉴

윈도우 앱 개발 역사 요약 (개판의 역사)

시대 프레임워크 특징
1990s Win32 C API 원조, 아직도 안 죽음
1990s MFC C++ 객체지향 래퍼
2002 WinForms (.NET 1.0) Win32 또 래핑
2006 WPF (.NET 3.0) XAML 도입, GPU 렌더링
2012 WinRT (Windows 8) 샌드박스 앱 시도, 새 API 세트
2015 UWP (Windows 10) 제한 일부 완화, 크로스디바이스
2021 WinUI 3 (Windows 11) 또 XAML 기반 새 컨트롤 라이브러리

매번 다시 짜는데 이전 것보다 기능이 빠져있음. 레전드 비효율.

실제로 뭐가 안 되냐

Windows App SDK / WinUI 3으로 할 수 있는 것과 없는 것:

  • ✅ 디스플레이 열거: 되는데 foreach가 아니라 for 루프 써야 함 ㅋㅋ. 변경 감지는 P/Invoke 필요
  • ⚠️ 테두리 없는 창: 대부분 가능하지만 non-activating(창 활성화 방지)은 P/Invoke 필요
  • ❌ 글로벌 키보드 단축키: 완전 불가, P/Invoke만 가능
  • ✅ 시작프로그램 등록: 됨
  • ✅ 설정 저장: 됨
  • 트레이 아이콘: 불가. P/Invoke 필요하고 메뉴 스타일도 패키지마다 달라서 통일 안 됨

배포도 개판

  • 프레임워크 의존 배포: 시스템 .NET이 4.8.1에 묶여 있어서 최신 앱 설치 시 사용자가 .NET 따로 다운로드해야 함 → UX 끔찍
  • .NET AOT: 런타임을 통째로 바이너리에 박아넣음 → 모니터 블랙아웃 앱이 9MB짜리가 됨 ㄷㄷ
  • MSIX 서명: 비미국 거주자 코드 서명 인증서 연 $200~300. Apple은 $99인데?
  • Microsoft Store 거절: "고유하고 지속적인 가치를 제공하지 않음"이라고 반려 ㅋㅋㅋ
  • Rust 바인딩도 시도했다가 포기함

CsWin32도 답없음

P/Invoke 고통을 줄여주려는 CsWin32 프로젝트도 문제 많음:

  • 구조체 안 문자열도 제대로 못 감쌈
  • 버전 1.0도 못 찍은 언더펀딩 프로젝트
  • C# 언어 자체가 Win32의 [optional, out] 파라미터 개념을 표현 못함 → 메서드를 두 버전씩 생성하는 웃긴 상황

C# 언어팀도 방치

WPF 출시(2006) 이후 20년이 지났는데 데이터 바인딩 보일러플레이트가 거의 그대로임. 프로퍼티마다 getter/setter 쌍 + 동일값 가드 + 이벤트 발화... JavaScript는 데코레이터/프록시로 해결했는데 C# 언어팀은 뭐 했냐는 소리.

결론: 그냥 Electron 써라

저자 최종 판단:

  • 마이크로소프트 자체가 VS Code, Outlook, 시작 메뉴까지 웹 기술로 만들고 있음
  • Tauri 쓰면 Chromium 번들 없이 시스템 웹뷰 사용 가능
  • 시스템 웹뷰는 4주마다 업데이트되는데 시스템 .NET은 4.8.1에 멈춰 있음 ㅋㅋㅋ
  • Avalonia, Uno Platform 같은 서드파티 프레임워크가 오히려 더 잘 관리됨
  • TypeScript/React/CSS가 C#/XAML보다 솔직히 나음

마이크로소프트가 자기 OS의 앱 플랫폼을 이렇게 방치하고 있으면 개발자들이 Electron으로 가는 거 당연한 수순임. 네이티브 앱 복고풍 감성은 이해하지만 현실은 그냥 웹스택이 맞다는 게 슬프면서도 공감 100%.

댓글

댓글

댓글을 불러오는 중...

frontend

개인 웹사이트에 JSON-LD 넣는 법, 검색엔진과 크롤러가 내 사이트를 제대로 읽게 만들기

개인 웹사이트에 JSON-LD 구조화 데이터를 추가해 검색엔진과 크롤러가 사이트, 사람, 글, 프로젝트를 더 정확히 이해하게 만드는 실전 가이드야. WebSite, Person, ProfilePage, BlogPosting 같은 노드를 어떻게 연결하고 어느 페이지에 넣어야 하는지 예시 중심으로 설명해.

frontend

Deno, 웹 프로젝트를 데스크톱 앱으로 묶는 `deno desktop` 공개

Deno가 TypeScript 파일 하나부터 Next.js 앱까지 데스크톱 앱으로 패키징하는 `deno desktop`을 공개했다. 아직 안정 릴리스는 아니고 Deno v2.9.0 canary에서만 쓸 수 있지만, 운영체제 WebView 기반의 작은 바이너리, 프레임워크 자동 감지, 내장 자동 업데이트까지 한 번에 노린다.

frontend

파비콘 안에 웹사이트를 숨겨 넣은 개발자, 진짜 됨

한 개발자가 웹사이트의 파비콘 이미지를 작은 저장소처럼 사용해 HTML을 픽셀 RGB 값 안에 넣고, 브라우저에서 다시 읽어 렌더링하는 실험을 했다. 208바이트짜리 HTML payload에 4바이트 길이 헤더를 붙여 총 212바이트를 만들었고, 이를 9x9 픽셀 PNG 안에 87% 사용률로 저장했다.

frontend

스크린이 절대 못 보여주는 색은 어디에 있을까

이 글은 우리가 화면에서 보는 색이 인간이 볼 수 있는 색 전체가 아니라, sRGB와 Display-P3 같은 색역 안에 갇힌 일부라는 점을 파고든다. 특히 숲, 바닷속, 새와 나비의 구조색, 생물발광, 교통신호 LED 같은 실제 세계에는 모니터와 카메라가 제대로 담지 못하는 청록색과 녹색 계열이 꽤 많다는 얘기다. 디스플레이, 카메라, 조명, 렌더링을 다루는 개발자라면 “색상값 하나”가 생각보다 물리와 표준의 타협이라는 걸 체감하게 된다.

frontend

크롬, 매니페스트 버전 2 우회로까지 닫는다

구글 크롬이 매니페스트 버전 2 확장 지원을 사실상 최종 종료 단계로 밀어넣고 있다. 기존에는 플래그나 레지스트리 설정으로 유블록 오리진 같은 확장을 살리는 우회가 있었지만, 크로미움 150과 151을 거치며 그 우회 코드까지 제거되는 흐름이다.