---
title: "윈도우 네이티브 앱 개발이 이렇게 개판인 줄 몰랐음 (현직 개발자 회고)"
published: 2026-03-24T09:04:00.000Z
canonical: https://jeff.news/article/133
---
# 윈도우 네이티브 앱 개발이 이렇게 개판인 줄 몰랐음 (현직 개발자 회고)

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

- **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보다 솔직히 나음

## 핵심 포인트

- WinUI 3까지 7세대 UI 프레임워크를 갈아치웠지만 기능 공백은 여전히 존재
- 최신 Windows 11에도 .NET 4.8.1만 내장 → 배포 경험이 최악
- 트레이 아이콘, 글로벌 단축키 등 기본 기능도 Win32 P/Invoke 직접 호출 필요

## 인사이트

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