Windows Forms, WPF, WinUI 중 어느 것으로 할까 - 신규 개발, 기존 자산, 배포, UI 표현의 판단표

Windows 데스크톱 앱을 C# / .NET으로 만들 때, 수수하게 매번 까다로운 것이 WinForms, WPF, WinUI 중 어느 것을 고를까입니다.

여기서 위험한 것은,

가장 새로우니까 WinUI
가장 익숙하니까 WinForms
어쩐지 중간 같으니까 WPF

같은 흐릿한 선택 방식입니다.

실무에서는 봐야 할 축이 좀 더 분명합니다.

신규 개발인가, 기존 자산의 연장인가
화면이 입력 폼 중심인가, 표현력이 필요한가
Windows다운 모던한 UI가 제품 가치 그 자체인가
배포・업데이트・기업 내 운용을 어떻게 할 것인가
팀이 Designer 문화인가, XAML / MVVM 문화인가

이 글에서는 이 부근을 판단표로서 한 장으로 보기 쉽게 정리합니다. 덧붙여, 이 글에서 말하는 WinUI는 주로 WinUI 3 + Windows App SDK를 가리킵니다.¹²

또한, 이 3가지는 전부 Windows 전용입니다. macOS / Linux도 시야에 들어온다면 애초에 문제 설정이 다릅니다.³⁴¹

1. 먼저 결론(한마디로)

먼저 꽤 거칠게, 그러나 실무에서 사용하기 쉬운 말로 하면 이렇습니다.

기존 WinForms 앱이 크다면, 먼저 WinForms 계속을 기본으로 봅니다
기존 WPF 앱이 크다면, 먼저 WPF 계속을 기본으로 봅니다
신규의 소~중규모 사내 도구에서 표준 컨트롤 중심・입력 화면 중심・빨리 만들고 싶다면, WinForms는 아직 상당히 강합니다³⁵
신규의 중~대규모 업무 앱에서 화면 수가 많고, 데이터 바인딩, 스타일, 템플릿, 커맨드, MVVM을 제대로 사용하고 싶다면, WPF가 가장 무난한 경우가 많습니다⁴⁶⁷
신규 Windows 전용 제품에서 모던한 Windows UI, Fluent, 최신의 Windows 체험이 제품 가치에 직결된다면, WinUI가 유력합니다¹²
최신 Windows API를 사용하고 싶을 뿐이라면 WinUI 필수가 아닙니다. WPF / WinForms에서도 Windows App SDK의 기능을 도입할 수 있습니다²⁸⁹¹⁰
「나중에 조금씩 WinUI를 끼워 넣으면 된다」를 전제로 고르는 것은 조금 위험합니다. 단계 이행 이야기는 생각보다 진흙투성이입니다¹⁰¹¹

요컨대 대개 다음과 같습니다.

기존 자산이 크다면 그 계보를 먼저 남긴다
신규로 표준 폼을 빨리 만든다면 WinForms
신규로 길게 자랄 Windows 업무 앱이라면 WPF
신규로 모던 Windows UI 자체가 요건이라면 WinUI
Windows App SDK를 사용하고 싶을 뿐이라면 갑자기 전부 WinUI로 하지 않는다

프레임워크 선정은 UI 기술의 선정임과 동시에 배포・운용・학습 비용・이행 비용의 선정이기도 합니다. 여기를 「새로운 / 낡은」만으로 결정하면, 나중에 조용히 효력을 발휘합니다. 싫은 형태로.

2. 이 글에서 말하는 3가지 기술

처음에 용어를 조금 맞춥니다.

기술	대략적으로 말하면	강한 축
WinForms	Visual Studio의 Designer로 빠르게 폼을 짜기 쉬운, Windows용의 전통적인 .NET 데스크톱 UI	빠른 화면 작성, 표준 컨트롤, 기존 자산의 활용
WPF	XAML, 데이터 바인딩, 스타일, 템플릿, 커맨드를 사용하여 표현력 있는 UI를 만들기 쉬운 Windows 전용 UI	중~대규모 업무 앱, MVVM, 화면의 정리하기 쉬움
WinUI	Windows App SDK 상의 모던한 Windows 네이티브 UI	Fluent, 최신 Windows 체험, 고 DPI, 모던한 제품 UI

WinForms는 Microsoft Learn에서도 컨트롤, 그래픽, 데이터 바인딩, 사용자 입력을 갖추고, Visual Studio의 드래그 앤 드롭 Designer로 앱을 만들기 쉬운 프레임워크로 설명되고 있습니다.³

WPF는 해상도 비의존의 벡터 기반 묘화, XAML, 데이터 바인딩, 스타일 / 템플릿, 2D / 3D, 애니메이션까지 포함한 표현력이 높은 UI 프레임워크입니다.⁴

WinUI는 Windows App SDK의 일부로, 고 DPI, 모던한 입력, 매끄러운 애니메이션, Fluent 계열의 체험을 전제로 한 지금의 Windows용 UI 프레임워크입니다.¹² 또한, data binding / MVVM의 도선도 평범하게 가지고 있습니다.¹²

여기서 중요한 것은 Windows App SDK와 WinUI는 같지 않다는 점입니다. WinUI는 Windows App SDK의 UI 프레임워크 부분이지만, Windows App SDK 자체는 WPF / WinForms / Win32의 기존 앱에도 추가할 수 있습니다.²¹⁰

그러므로,

WinUI를 사용한다
Windows App SDK의 기능을 사용한다

는 비슷해 보이지만 다른 판단입니다. 여기가 섞이면 회의실에서 이야기가 조금 안개가 짙어집니다.

3. 한 장으로 보는 판단표

먼저 가장 실무에서 사용하기 쉬운 표를 둡니다.

상황	먼저 고르는 것	이유
기존 WinForms 앱의 개수・연명・.NET으로의 업데이트	WinForms 계속	기존 화면, Designer 자산, 컨트롤 자산을 살리기 쉬움
기존 WPF 앱의 개수・연명・.NET으로의 업데이트	WPF 계속	XAML, Binding, MVVM, 화면 구조를 그대로 살리기 쉬움
신규, 사내 도구, 설정 화면, 관리 화면, 입력 폼 중심	WinForms	표준 컨트롤 중심이라면 기동이 빠름
신규, 화면 수가 많고, 상태가 복잡, 스타일 / 템플릿 / MVVM을 사용하고 싶다	WPF	화면의 책무 분리와 UI의 정리가 쉬움
신규, Windows다운 모던 UI 자체가 요건	WinUI	Fluent나 최신의 Windows 체험에 기울이기 쉬움
기존 WPF / WinForms 그대로, Toast / Windowing / App Lifecycle 등을 사용하고 싶다	현행 프레임워크 + Windows App SDK	최신 Windows 기능을 위해 UI 전면 이행까지는 불필요한 경우가 많음
COM / ActiveX / 오래된 서드파티 컨트롤 의존이 진하다	기존 프레임워크 쪽	UI 이전에 의존 관계의 이행 비용이 큼
배포・업데이트・기업 내 운용의 사정을 강하게 받는다	WPF / WinForms를 우선 검토, WinUI는 배포 설계를 일찍 확인	WinUI는 Windows App SDK / packaging 전제의 논점을 일찍 볼 필요가 있음
장래에 크로스 플랫폼화하고 싶다	이 3가지 외를 포함해 재검토	이 3가지는 전부 Windows 전용

이 표만으로도 상당히 충분하지만, 고민하기 쉬운 것은 다음 2가지입니다.

신규 Windows 업무 앱에서 WinForms와 WPF 중 어느 쪽에 기울일까
기존 WPF / WinForms가 있는데 WinUI로 가야 할까

이 2가지는 다음 비교표를 보면 정리하기 쉽습니다.

4. 관점별 비교표

여기는 공식적 우열표가 아니라 상당히 실무 쪽 비교입니다.

관점	WinForms	WPF	WinUI
작은 입력 폼을 빠르게 만든다	◎	○	○
표준 컨트롤 중심의 사내 도구	◎	○	△~○
데이터 바인딩 / MVVM과의 상성	△	◎	○~◎
스타일 / 템플릿 / 화면의 표현력	△	◎	◎
기존 Windows 데스크톱 자산과의 친화성	◎	○	△
모던한 Windows다움	△	○	◎
기존 화면의 연명・단계 개수	◎	◎	△
Windows App SDK 기능의 추가만 하고 싶다	○	○	◎
배포 / 업데이트 / 운용의 설계의 가벼움	○	○	△~○
「새롭게 길게 자랄 Windows 전용 제품 UI」를 만든다	△	○	◎

보는 요령은 무엇이 최강인가가 아니라 무엇이 가장 마찰이 적은가입니다.

예를 들어,

사내의 설정 도구
장치 설정 화면
일람, 명세, 검색, 설정, 버튼
외관보다 운용의 안정과 개수 속도가 중요

라면, WinForms는 아직 상당히 합리적입니다.

반대로,

화면 수가 많다
표시 상태의 전환이 많다
View와 로직을 분리하고 싶다
데이터의 변화를 UI에 자연스럽게 연결하고 싶다
스타일 / 템플릿으로 UI를 통제하고 싶다

라면, WPF가 상당히 효과적입니다.⁶⁷

그리고,

Windows 11다운 외관을 전제로 하고 싶다
Fluent를 제대로 살리고 싶다
고 DPI, 터치, 모던한 윈도우 API를 전제로 하고 싶다
신규로, Windows 전용 제품으로서 UI의 인상도 중요

라면, WinUI가 자연스럽습니다.¹²

5. 각각, 어떤 안건에 어울리는가

5.1 WinForms

WinForms는 이상하게 가볍게 여겨지기 쉽지만, 표준 컨트롤 중심의 업무 화면을 빠르게 만든다는 한 점에서는 지금도 상당히 강합니다.³⁵

특히 어울리는 것은 예를 들어 다음과 같은 것입니다.

사내용 설정 도구
장치・계측기・감시 도구의 설정 화면
관리 화면, 검색 화면, 일람 + 명세
기존 WinForms 자산이 큰 안건
Designer로 화면을 짜는 문화가 강한 팀

WinForms의 강점은 어려운 사상을 가지고 들어오지 않아도 어느 정도 빠르게 완성품에 가까운 화면이 나오는 것입니다. 폼, 버튼, 레이블, 텍스트 박스, 데이터 그리드. 이 세계가 주전장이라면 상당히 싸울 수 있습니다.

다만, 약한 곳도 분명합니다.

화면 전체의 외관을 크게 통일하고 싶다
스타일과 템플릿으로 UI를 제어하고 싶다
복잡한 상태 변화를 데이터 바인딩 주체로 처리하고 싶다
화면 로직을 깔끔하게 분리하고 싶다

이 부근은 WPF나 WinUI 쪽이 자연스럽습니다.

WinForms로 큰 앱을 만들면 방심하면 이벤트 핸들러의 밀림이 되기 쉽습니다. 그래서 WinForms를 고른다면,

화면 책무를 작게 유지한다
UserControl 단위로 분리한다
Presenter / ViewModel 상당의 경계를 의식한다
화면 이벤트에 업무 로직을 달라붙여서 쓰지 않는다

정도는 처음부터 정해두는 편이 평화롭습니다.

또한, 실무에서 상당히 중요한 것은 Windows App SDK를 사용하고 싶으니까 WinForms를 버릴 필요는 없다는 점입니다. 공식적으로도 기존 WinForms 앱에 Windows App SDK 기능을 추가하는 도선이 있습니다.⁹¹⁰

즉, WinForms는

UI는 그대로
필요한 Windows 기능만 근대화

라는 선택 방식을 할 수 있습니다. 여기는 상당히 현실적입니다.

5.2 WPF

WPF는 Windows 데스크톱의 .NET UI로 보면 가장 밸런스가 좋은 중핵입니다.⁴

강점은 상당히 명확합니다.

XAML로 화면을 선언적으로 쓸 수 있다
Data Binding이 강하다
Style / Template를 쓸 수 있다
Command를 쓸 수 있다
View와 로직을 분리하기 쉽다
중~대규모의 화면을 정리하기 쉽다

WPF의 공식 문서에서도 데이터 바인딩은 WPF의 중심 기능으로 설명되고 있으며, 커맨드도 입력과 실행 로직을 분리하는 구조로 정리되어 있습니다.⁶⁷

그래서 예를 들어 다음과 같은 안건에 상당히 어울립니다.

화면 수가 많은 업무 앱
일람, 상세, 편집, 검색, 상태 표시가 많다
복수 인원으로 길게 보수하는 Windows 앱
View와 로직을 분리하고 싶다
장래의 개수에서 외관과 거동의 책무를 분리해 두고 싶다
WinForms라면 화면이 금방 무거워질 것 같다

신규의 Windows 전용 업무 앱에서 망설였을 때, WPF는 지금도 상당히 안전한 제1후보입니다. 여기를 「WPF는 오래됐으니 안 됨」으로 자르는 것은 조금 난폭합니다.

오히려,

기존 WPF 자산이 있다
기존 XAML / MVVM의 지견이 있다
그 정도로 Fluent 최우선은 아니다
그래도 WinForms보다 UI를 깔끔하게 설계하고 싶다

라면, WPF가 가장 길이 좋은 경우는 평범하게 있습니다.

물론 WPF에도 버릇은 있습니다.

XAML을 너무 공들이면 읽기 어려워진다
독자 컨트롤이나 템플릿 지옥에 들어가면 보수가 무겁다
「무엇이든 Binding으로 한다」 종교로 기울면 오히려 쫓기 어렵다

이 부근은 있습니다. 다만, 그것은 WPF가 나쁘다기보다 표현력 있는 도구는 거칠게 휘두르면 반동도 크다는 이야기입니다.

WPF에서도 Windows App SDK의 일부 기능을 추가할 수 있습니다. 즉, WPF 그대로 Windows 기능을 근대화한다는 길이 있습니다.⁸¹⁰

이 때문에,

WPF를 전부 버리고 WinUI로 전면 이행

보다,

WPF를 현행 .NET에 기울인다
필요한 Windows 기능만 Windows App SDK로 추가한다
신규의 큰 기능부터 구성을 정리한다

쪽이, 실무에서는 이기기 쉬운 경우가 꽤 있습니다.

5.3 WinUI

WinUI는 신규 Windows 전용 앱을 만들 때의 모던한 본명입니다.¹²

공식적으로는,

최신의 하드웨어와 입력용으로 최적화
고 DPI
매끄러운 애니메이션
Windows App SDK의 일부

라는 위치입니다.¹

그래서 이런 안건에 어울립니다.

Windows 전용의 신규 제품
UI의 인상이나 체험 그 자체가 중요
Fluent를 자연스럽게 사용하고 싶다
Windows 11의 현재 위치에 기울이고 싶다
새로운 윈도우 API나 최신 Windows 체험을 전제로 하고 싶다

WinUI를 고르는 이유가 제대로 있는 안건, 이라는 것은 대개 「외관이 새롭다」가 아니라 「Windows의 지금 체험을 제품에 도입하고 싶다」 안건입니다.

한편, 주의점도 있습니다.

5.3.1 WinUI는 「그저 새로운 WPF」가 아니다

XAML을 사용하므로 가까워 보이지만,

베이스의 API
컨트롤 주변
프로젝트 구성
디플로이 / packaging의 사고 방식
Windows App SDK와의 교제 방식

이 다릅니다.

즉, WPF로부터의 편리한 교체 대상으로 생각하면 조금 위험합니다.

5.3.2 WinUI를 고르면 배포 이야기가 앞으로 나온다

WinUI 3 앱은 packaged가 기본입니다. 한편, Windows App SDK 자체는 packaged / unpackaged의 양쪽을 다룹니다.¹³¹⁴²

여기서 중요한 것은,

어떻게 배포할 것인가
런타임을 어떻게 넣을 것인가
package identity가 필요한가
사내 배포인가, Store인가, MSIX인가, 기존 EXE / MSI 노선인가

를 일찍 결정하는 편이 좋다는 것입니다.

WinForms / WPF에서도 배포는 중요하지만, WinUI는 여기가 전경으로 나오기 쉽습니다. UI를 정한 줄 알았는데, 실은 배포 전략을 정하고 있었다, 가 이 세계의 조금 까다로운 부분입니다.

5.3.3 「기존 WPF / WinForms에 조금씩 WinUI를 섞는다」는 먼저 실험한다

여기는 기대가 부풀어 오르기 쉬운 곳입니다. 다만, Microsoft의 FAQ에서도 UI 프레임워크를 완전히 이행할 준비가 되어 있지 않는 한 WinUI는 사용할 수 없는 경우가 많다라는 취지가 쓰여 있습니다. 게다가 XAML Islands 주변도 공식 문서에서는 기존 데스크톱 앱으로의 임베드 도선이 제시되는 한편, Windows App SDK 1.4의 릴리스 노트에서는 현시점에서는 C++ 앱에서의 이용이 주로 테스트되고 있으며, WPF / WinForms용의 편리한 래퍼 요소는 들어 있지 않다라고 되어 있습니다.¹⁰¹¹

즉,

「단계 이행 가능할 것 같다」
「조금씩 메우면 될 것 같다」

는 구상으로서는 매력적이어도 안건의 주전략으로 하기 전에 작게 검증하는 편이 좋습니다.

WinUI는,

신규로 시작한다
Windows 전용 제품으로서 체험을 만든다

때 가장 길이 좋다. 반대로 기존 WPF / WinForms의 전면 치환의 받침 접시로서는 이유와 검증이 필요합니다.

6. 자주 있는 판단 실수

6.1 「최신이니까 WinUI」

이것은 알기 쉽지만 꽤 위험합니다.

새로운 기술을 고르는 이유는 그 기술이 아니면 얻을 수 없는 가치가 있는가로 보는 편이 좋습니다.

모던한 Windows 체험이 제품 가치인가
Fluent를 자연스럽게 사용하고 싶은가
신규 제품인가
배포 / 운용의 전제를 받아들일 수 있는가

여기가 yes라면 WinUI는 상당히 유력합니다. 반대로, 단지 「장래성이 있을 것 같다」만으로는 비용의 설명이 약합니다.

6.2 「Windows App SDK를 사용하고 싶으니까 WinUI로 하지 않으면 안 된다」

이것은 오해되기 쉽지만 다릅니다.

Windows App SDK는 기존의 WPF / WinForms에도 추가할 수 있습니다. 공식 FAQ에서도 WPF / MFC / WinForms 앱은 WinUI와 무관한 Windows App SDK API를 사용할 수 있다고 정리되어 있습니다.¹⁰⁸⁹

예를 들어,

App Lifecycle
Windowing
Toast Notifications

과 같은 기능은 지금의 UI를 유지하면서 도입할 수 있는 경우가 있습니다.¹⁰

6.3 「WPF / WinForms는 이제 끝났다」

여기도 거칠게 자르지 않는 편이 좋습니다.

WinForms도 WPF도 현행 .NET 상에서 문서와 이행 도선이 계속되고 있으며, 공식적으로도 현역의 Windows 데스크톱 UI로 다루어지고 있습니다.³⁴

특히 업무 앱에서는,

기존 자산
서드파티 컨트롤
화면 수
장표나 인쇄
장치 연계
배포 순서

쪽이 UI 프레임워크의 새로움보다 무거운 경우는 평범하게 있습니다.

6.4 「어차피라면 전면 리라이트」

전면 리라이트는 기술 선정이 아니라 사업 판단에 가깝습니다.

기존 앱이 있다면 처음에 봐야 할 것은 다음입니다.

무엇이 정말로 곤란한가
UI의 문제인가, 아키텍처의 문제인가
의존 DLL / COM / OCX / 장표 / 배포가 진짜 짐이 아닌가
UI를 전부 바꾸지 않아도 곤란한 점은 풀리는가

UI 리라이트는 화려하지만 비용도 화려합니다. 게다가 외관은 새로워져도 주변의 까다로움은 대개 남습니다.

6.5 「나중에 XAML Islands로 어떻게든 된다」

이 기대는 이해할 수 있습니다. 다만, 처음부터 구명 보트 취급하지 않는 편이 안전합니다.¹⁰¹¹

단계 이행은,

임베드하고 싶은 컨트롤은 무엇인가
포커스, 입력, DPI, 테마는 어떻게 되는가
실제로 그 호스트 구성이 안정되는가

를 먼저 작게 시도하는 편이 좋습니다.

7. 기존 앱을 전제로 할 때의 보는 법

여기는 신규보다 기존 쪽이 중요합니다.

7.1 기존 WinForms가 있다면

먼저 갑자기 WinUI로 뛰어가기 전에 다음을 봅니다.

현행 .NET으로 기울일 수 있는가
64bit화가 필요한가
async / await, 예외 처리, 설정, 로그를 정리할 수 있는가
화면 분할이나 UserControl화로 보수성을 올릴 수 있는가
필요한 Windows 기능만 Windows App SDK로 추가할 수 있는가

WinForms의 문제로 보여서 실제로는

화면과 로직이 섞여 있다
스레드 경계가 거칠다
설정 / 파일 / COM / DB의 책무가 막혀 있다

뿐, 인 경우는 꽤 있습니다.

그 경우 WinUI로 이사해도 문제가 이름을 바꿔 남을 뿐입니다.

7.2 기존 WPF가 있다면

WPF는 기존 자산을 살리기 쉽습니다.

XAML 자산
Binding
Style / Template
Command
MVVM

이 부근을 버리는 이유는 상당히 명확해야 합니다.

예를 들어,

제품 UI를 전면 쇄신하고 싶다
Fluent를 주축으로 하고 싶다
신규 모듈을 별도 제품으로 잘라낸다
Windows 전용 제품으로서 새로운 체험으로 기울이고 싶다

라면, WinUI의 검토 이유가 됩니다. 하지만, 단지 「WPF는 오래됐으니까」라면 약합니다.

7.3 정말로 무거운 것은 UI 이외가 많다

실무에서는 힘든 것은 의외로 이 부근입니다.

ActiveX / OCX
COM interop
독자 장표
인쇄
Excel / Office 연계
네이티브 DLL
32bit / 64bit의 뒤틀림
인스톨러, 권한, 업데이트, 서명

여기를 가볍게 보면 UI만 깔끔하게 해도 안건 전체는 가벼워지지 않습니다.

그래서 기존 앱의 이행에서는 UI 프레임워크만 보는 것이 아니라 의존 경계별로 재고 조사를 하는 편이 먼저입니다.

8. 망설였을 때 마지막에 보는 5개 질문

최종적으로 망설이면 다음 5개 질문을 순서대로 봅니다.

8.1 기존 자산은 큰가

크다 → 기존 계보를 기본 유지
작다 / 없다 → 신규 선정으로

8.2 그 앱에서 「Windows다운 모던한 체험」은 필수인가

필수 → WinUI가 유력
그 정도는 아니다 → WPF / WinForms로 충분한지 확인

8.3 화면은 표준 폼 중심인가, XAML적인 표현력이 필요한가

표준 폼 중심 → WinForms
스타일 / 템플릿 / Binding / MVVM이 중요 → WPF

8.4 원하는 것은 UI의 전면 쇄신인가, Windows 기능의 추가인가

UI의 전면 쇄신 → WinUI 검토
기능 추가만 → 현행 WPF / WinForms + Windows App SDK를 먼저 검토

8.5 배포 / 업데이트 / 운용을 어떻게 할지 먼저 설명할 수 있는가

아직 애매 → WinUI는 일찍 packaging / deployment를 다듬기
기존 운용에 강하게 태우고 싶다 → WPF / WinForms 쪽이 마찰이 적은 경우가 많다

이 5개 질문으로 상당히 좁힐 수 있습니다. 마지막에 거칠게 정리하면 이런 느낌입니다.

빠르게 만드는 사내 폼 → WinForms
길게 자라는 Windows 업무 앱 → WPF
신규의 모던 Windows 제품 UI → WinUI
기존을 살리면서 Windows 기능만 근대화 → 현행 프레임워크 + Windows App SDK

9. 정리

WinForms, WPF, WinUI의 선정은, 새로운 순으로 늘어놓아 맨 오른쪽을 취하는 게임이 아닙니다.

먼저 봐야 할 것은 다음 4가지입니다.

기존 자산이 어디에 있는가
화면이 폼 중심인가, 표현력 중심인가
Windows다운 모던 UI가 제품 요건인가
배포 / 업데이트 / 운용을 어떻게 돌릴 것인가

이 4가지가 보이면 대개 다음과 같이 정리할 수 있습니다.

기존 WinForms를 크게 가지고 있다면 먼저 WinForms 계속
기존 WPF를 크게 가지고 있다면 먼저 WPF 계속
신규로 표준 폼 중심이라면 WinForms
신규로 중~대규모의 Windows 업무 앱이라면 WPF
신규로 모던 Windows 체험 그 자체가 요건이라면 WinUI
Windows App SDK를 사용하고 싶을 뿐이라면 갑자기 전부 WinUI로 하지 않는다

가장 피하고 싶은 것은,

오래됐으니 버린다
새로우니 고른다
도중에 어떻게든 되겠지로 시작한다

의 3가지입니다.

Windows 데스크톱은 외관보다 자산, 배포, 운용, 의존 관계 쪽이 무거운 세계입니다. 그래서 고르는 법도 반짝반짝한 느낌보다 마찰의 적음을 보는 편이 대개 이기기 쉽습니다.

10. 참고 자료

Microsoft Learn, “WinUI 3 - Windows apps” https://learn.microsoft.com/en-us/windows/apps/winui/winui3/ / Microsoft Learn, “Modernize your desktop apps for Windows” https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Microsoft Learn, “Windows App SDK” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, “Windows 폼이란 - Windows Forms” https://learn.microsoft.com/en-us/dotnet/desktop/winforms/overview/ ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, “Windows Presentation Foundation이란 - WPF” https://learn.microsoft.com/en-us/dotnet/desktop/wpf/overview/ ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, “What is Windows Forms Designer?” https://learn.microsoft.com/en-us/visualstudio/designers/windows-forms-designer-overview?view=visualstudio ↩ ↩²
Microsoft Learn, “Data binding overview - WPF” https://learn.microsoft.com/en-us/dotnet/desktop/wpf/data/ ↩ ↩² ↩³
Microsoft Learn, “Commanding Overview - WPF” https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/commanding-overview ↩ ↩² ↩³
Microsoft Learn, “WPF 앱에서 Windows App SDK를 사용한다” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/wpf-plus-winappsdk ↩ ↩² ↩³
Microsoft Learn, “Use the Windows App SDK in a Windows Forms (WinForms) app” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/migrate-to-windows-app-sdk/winforms-plus-winappsdk ↩ ↩² ↩³
Microsoft Learn, “Windows 개발자용 FAQ” https://learn.microsoft.com/en-us/windows/apps/get-started/windows-developer-faq ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
Microsoft Learn, “Windows App SDK 1.4 release notes” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/release-notes/windows-app-sdk-1-4 / Microsoft Learn, “Windows App SDK” https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/ ↩ ↩² ↩³
Microsoft Learn, “Windows data binding and MVVM” https://learn.microsoft.com/en-us/windows/apps/develop/data-binding/data-binding-and-mvvm ↩
Microsoft Learn, “Packaging overview - Windows apps” https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/packaging/ ↩
Microsoft Learn, “Quick start: Set up your environment and create a WinUI 3 project” https://learn.microsoft.com/en-gb/windows/apps/get-started/start-here ↩

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

Windows 앱 개발

상주 처리, 장비 연동, 운영 로그, 유지 보수 가능한 구조가 필요한 Windows 데스크톱 애플리케이션을 지원합니다.

서비스 보기 문의하기

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.

프로필 보기 문의하기

공개 링크

GitHub LinkedIn X COM_BLAS COM_BigDecimal

1. 먼저 결론(한마디로)

2. 이 글에서 말하는 3가지 기술

3. 한 장으로 보는 판단표

4. 관점별 비교표

5. 각각, 어떤 안건에 어울리는가

5.1 WinForms

5.2 WPF

5.3 WinUI

5.3.1 WinUI는 「그저 새로운 WPF」가 아니다

5.3.2 WinUI를 고르면 배포 이야기가 앞으로 나온다

5.3.3 「기존 WPF / WinForms에 조금씩 WinUI를 섞는다」는 먼저 실험한다

6. 자주 있는 판단 실수

6.1 「최신이니까 WinUI」

6.2 「Windows App SDK를 사용하고 싶으니까 WinUI로 하지 않으면 안 된다」

6.3 「WPF / WinForms는 이제 끝났다」

6.4 「어차피라면 전면 리라이트」

6.5 「나중에 XAML Islands로 어떻게든 된다」

7. 기존 앱을 전제로 할 때의 보는 법

7.1 기존 WinForms가 있다면

7.2 기존 WPF가 있다면

7.3 정말로 무거운 것은 UI 이외가 많다

8. 망설였을 때 마지막에 보는 5개 질문

8.1 기존 자산은 큰가

8.2 그 앱에서 「Windows다운 모던한 체험」은 필수인가

8.3 화면은 표준 폼 중심인가, XAML적인 표현력이 필요한가

8.4 원하는 것은 UI의 전면 쇄신인가, Windows 기능의 추가인가

8.5 배포 / 업데이트 / 운용을 어떻게 할지 먼저 설명할 수 있는가

9. 정리

10. 참고 자료

관련 기사

관련 토픽

이 주제와 연결되는 서비스

저자 프로필

Go Komura