WPF 로 개발을 하여 프로그램을 만드는 이유가 궁금합니다!!
쉬운 winform 으로 하면 되는데, 왜 굳이 wpf 를 사용하는 것 일까요!?
1개의 좋아요
화려한(?) UI/UX 와 데이터 조건에 따라 움직이고 동적인 효과 등 처리를 구현하려면
윈폼 보단 wpf가 쉬울거에요!
또한 wpf는 기본적으로 mvvm 아키텍처 설계 구조에 아주-아주 최적화가 잘 되어 있거든요! (강력한 바인딩 처리, 관련 여러 패키지 지원(커뮤니티 툴킷 등))
5개의 좋아요
근데 어렵잖아요!!!
1개의 좋아요
답변 드렸는데.,ㅠㅠ
뭐든지 ‘굳이’ 라는건 없습니다.
간단한 요구사항의 프로젝트라면 말씀하신대로 윈폼으로 개발하셔도 되고,
어렵다는건 주간적이기 때문에
어떤 사람에겐 윈폼보단 MFC가 더 친숙할 수 도 있다면
윈폼은 어려우니깐 MFC로 할거야! 라고 할 수 도 있죠…
3개의 좋아요
그…그렇군요…
1개의 좋아요
디자이너 입장에선 반대일 수도 있을 것 같네요.
“벡터 기반으로 구성되며 복합 컨트롤을 만드는데 용이한 WPF를 놔두고, 버튼에 아이콘 하나 넣는 것조차 라이브러리의 도움을 빌리는 게 나은 Winforms을 써야 할 이유가 있나요?” 라고 물어본다면 프로그래머가 대답하기 난감하지 않을까요?
혼자서 개발할 때야 프레임워크 선택의 이유가 순전히 난이도뿐이어도 상관없지만, 여럿이 개발할 땐 당연히 학습 난이도 외에도 고려해야 할 게 많겠죠? 그게 누군가에게는 UI 커스터마이징의 용이성이 될 수도 있고, 누군가에게는 중대규모 앱 개발 환경에서의 유연성이 될 거에요. 심지어 'conflict 났을 때 머리가 덜 아프다’는 이유 때문일 수도 있고요.
2개의 좋아요
전적으로 요구 사항이 어떤가에 따라 Windows Forms가 쉬울 수도, 어려울 수도 있습니다. 구체적인 예를 들어보면…
- Windows Forms가 유리해서 일이 쉽게 처리되는 경우: Windows 탐색기, MS Office와의 상호 작용, COM 및 ActiveX 컨트롤 활용
- 식탁보의 경우, Windows Forms로 시작했다가 High DPI 문제 때문에 나중에 WPF로 옮겼는데, 이 과정에서 Windows 탐색기 스타일의 리스트 뷰를 구현하는데 엄청난 품이 들어 고생한 경험이 있습니다.
- WPF가 유리해서 일이 쉽게 처리되는 경우: 애니메이션, 키프레임 설정, High DPI 상황에서도 깨지지 않는 레이아웃 유지
- 식탁보의 경우, High DPI 문제를 Windows Forms에서 풀기 어려워 WPF로 옮긴 덕에 많은 부분이 개선되었습니다. (리스트 뷰 문제를 제외하고)
그래서 어느쪽이든 모두 사용할 수 있도록 익히는 것이 필요하고, 여기에 더해 최근에는 양쪽 스택 모두 MVVM을 지원할 수 있도록 .NET 8 이후부터 기능이 크게 보강되고 있기 때문에 상황과 요구 사항에 맞는 UI 스택을 고르는 것도 중요해졌습니다.
3개의 좋아요
WinForm vs WPF: 유지보수 관점에서의 차이
WinForm이 초기 개발 속도 면에서 빠른 경우가 많은 것은 사실입니다.
하지만 자사 솔루션을 기반으로 고객 맞춤형 개발이 많은 경우에는 유지보수가 중요한 요소가 됩니다.
예시: 숫자 포맷 변경 요청
고객이 금액을 표시할 때 , 구분자를 넣어달라는 요청을 했다고 가정해 봅시다.
-
AS-IS
비용($):1000000 -
TO-BE
비용($):1,000,000
WPF의 경우
- 비용 표시 컨트롤이 ViewModel이나 Custom Control 등으로 분리되어 있다면,
- 해당 포맷만 수정해도 전역적으로 자동 반영됩니다.
- 즉, 예외 없이 일관된 적용이 가능합니다.
WinForm의 경우
- 비용 표시 컨트롤을 사용하는 모든 폼을 직접 찾아야 하며,
- 각 컨트롤의 속성값을 수작업으로 수정해야 합니다.
- 이 과정에서 일부 누락이나 실수 가능성이 존재합니다.
결론
UI 구조를 제외하더라도,
지속적인 유지보수와 고객 요청 반영이 잦은 솔루션을 운영하는 환경이라면
WPF가 구조적 유연성과 확장성 측면에서 더 유리합니다.
3개의 좋아요
어디까지나 개인적인 의견입니다만, 쉽고 어려움은 익숙함의 차이가 아닐까 생각합니다. 
저의 경우, 오래 전에는 Windows Forms를 주력으로 애용하여 사용했었지만, WPF를 사용하기 시작한 이후로는 그것만 쭉 사용하게 되고 Windows Forms는 꺼리게 되었네요.
Windows Forms보다 편리한 점이 꽤 많았습니다. 물론 이것도 어디까지나 제 개인적인 생각입니다.
4개의 좋아요
먼저 WPF로 개발하는 이유를 말씀드리자면…
운영체제도 발전하고 .NET도, C#도, Visual Studio도 발전하고 있습니다.
WinForms는 2000년대 초반, Windows XP 운영체제를 타겟으로 설계된 GDI 기반 프레임워크로, 당시에는 간편하고 빠른 UI 개발을 가능하게 하는 장점이 있었습니다.
하지만 핸들 기반 컨트롤을 계층적으로 쌓는 구조적 방식 때문에 레이아웃 유연성, 고해상도(DPI) 대응, 커스터마이징 같은 부분에서 명확한 제약사항이 존재합니다.
이러한 제약은 고객 요청 등에 따른 현대적인 UI 요구사항에 대응하기 어려운 근본적 한계로 이어집니다.
더불어 WinForms는 코드 기반 UI 정의 방식을 사용하기 때문에, 오늘날 널리 채택되고 있는 선언적 UI 정의 방식과 거리가 있다는 것도 고려해볼 부분이 아닐까 생각합니다.
물론 WPF도 2006년에 처음 등장한 만큼 오래된 기술이긴 합니다.
하지만 WPF는 WinForms와는 달리 DirectX 그래픽스 기반의 프레임워크로, Windows Vista 이후 현재까지도 운영체제 레벨에서 지속적으로 지원되고 있는 방식입니다.
WPF는 단순히 오래된 기술이라기보다는, 운영체제, .NET 플랫폼과 언어(C#), 도구(Visual Studio)의 발전 흐름 속에 계속 포함되어 있는 기술입니다.
Visual Studio에서 XAML Hot Reload 기능이 추가된 것이나, UWP를 거쳐 WinUI로 이어지는 최신 UI 프레임워크들이 XAML을 기반으로 하고 있다는 점, C#의 신규 기능에 MVVM 구현 관점에서 유용한 요소들이 꾸준히 포함되고 있다는 점 등이죠.
개인적으로는 특정 도메인 목적을 가지는 어느정도 복잡도를 가지는 데스크탑 응용프로그램 개발이라면 아직까지는 WPF라고 생각합니다.
요약하자면, WinForms는 과거의 운영체제 기술에 맞춰 설계된 오래된 프레임워크로, 현대적인 UI 개발 패러다임과 거리가 있기 때문에 한계가 존재하는 반면, WPF는 기술 발전의 흐름과 함께 했기 때문에, 적어도 윈도우즈 데스크탑 응용프로그램 개발에서 있어서는 WinForms 보다는 WPF를 사용한다라는 의견입니다.
다음은 사족으로,
라는 식의 접근은 기술적 변화에 끊임없이 적응하는 우리 개발자들이 지양해야하는 자세가 아닌가 합니다.
익숙한 것에만 머무르는 자세는 결국 본인의 성장을 가로막게 됩니다.
WPF 역시 반드시 MVVM으로 시작할 필요는 없습니다. 처음에는 WinForms처럼 이벤트 기반으로 개발해놓고, 점진적으로 데이터 바인딩과 커맨드 등의 MVVM 구조를 적용해 나가는 방식으로 접근해 보시기 바랍니다.
그렇게 경험을 쌓다 보면, 어느 순간 자연스럽게 “내가 지금까지 어떻게 WinForms으로 개발을 했을까?”라는 생각이 들게 될 것입니다.
저도 2000년대 후반까지는 @Vagabond-K 님 처럼 WinForms를 주력으로 개발했었지만 WPF를 사용한 이후로는 다시 돌아가지 못합니다
아무리 간단한 프로그램이라도 말이죠ㅎ
16개의 좋아요
와!!! 정말 이해 쏙쏙 되는 답변이네요 감사합니다
1개의 좋아요
mvvm 이 어려워서 wpf 안하고 있었는데, 말씀해주신대로, winform 처럼 이벤트로 만들다가 점진적으로 mvvm 으로 만들어가야겠네요!! 감사합니다
1개의 좋아요
Winform / WPF / WinUI 전부 목적에 따라 최적의 솔루션이 될 수 있기때문에
MS Learn에서 상황에 따라 적절히 고르는 예제를 위 링크에서 알려줍니다.
3개의 좋아요
와,이런 것도 있군요 감사합니다!
몇가지 이유가 있는데 개인적으로 wpf 를 사용할 수 밖에 없는 구체적인 이유 딱 한가지만 언급하겠습니다.
윈폼으로 탭컨트롤을 만들어서 각 탭에 여러가지 울긋불긋한 ui 들을 넣습니다.
각 탭을 전환해보시면 탭 전환 시 각 탭의 ui 가 그려지는 과정이 눈에 보일겁니다.
그런데 이것을 wpf 구현하면 깔끔하게 확확 전환이 됩니다.
저는 개인적으로 이게 너무 큰 차이로 보이더군요.
1개의 좋아요
mvvm으로 개발하면 편합니다.
1개의 좋아요
오랜된 질문글이고 보고만 있었는데, 저는 뚝심있게 윈폼만 씁니다. 이유는 없습니다. 처음 배운게 윈폼이고 다른 것을 배울 시간이 있으면, 해야할 일이 따로 있어서요.
MVVM을 알고 나면 편하다고는 하는데, 사실 젊은 나이도 아니고 제가 교수도 아닌데 평생 공부만 할 수 있는 상황은 아니라서 윈폼을 계속 쓰고 있습니다. 이런 경우도 있다고 생각하시면 됩니다. 질문 내용과는 조금은 동떨어져 있는 댓글입니다.
4개의 좋아요
저도 조금씩 적응해 가는 중인데 mvvm 패턴이 유지보수 차원에선 편하긴 한거같습니다. 코드는 그대로 두고 UI만 2차례 갈아 엎었는데 화면 재구성하고 바인딩만 해주면 알아서 작동이 되는데 세상 편할 수 없네요ㅎㅎ 그런데 mvvm 패턴을 100% 고수는 못 할것 같습니다 ㅎㅎ