Q1. .NET Framework 4.8 vs .NET
고려할 포인트가 많기 때문에 결정에 참고만 하세요.
.NET 최신 버전이 나올 때마다 매번 재배포할 필요는 없습니다. 최초 배포 시점의 LTS(예: .NET 10) 버전을 적용하고 유지하시면 됩니다.
배포 방식으로는 Self-Contained로 런타임까지 포함할 수도 있지만, 이 경우 업데이트할 때마다 배포본이 커지므로 추천하지 않습니다.
대신 초기 설치 시 .NET Desktop Runtime을 설치하도록 절차화하는 방법이 더 나을듯 합니다.
저라면 운영 환경이 Windows 10 이상으로 특정될 수 있다면 .NET으로 개발하는 것을 권하겠습니다.
이 부분에 대해서는 DevExpress 컴포넌트의 경우 일부 컨트롤이 상위 버전 .NET을 타겟으로 개발 시 문제가 되는 것으로 보고되고 있는데요, 일반적인 개념으로는 상위 .NET 타켓에서 하위 버전으로 빌드 된 라이브러리를 참조하는데 문제는 없습니다.
최신 버전을 구입하실 예정이라면 추후 업그레이드를 하지 않더라도 (적어도 .NET 10 까지는) .NET 하위 호환성은 보장될 것으로 보입니다.
OpenCVSharp와 FFmpeg는 깊게 다뤄보지 않아서 어떤 쪽이 더 적합한지 명확히 말씀드리기는 어렵습니다.
다만, 최근까지 활발히 업데이트되고 있는 라이브러리를 사용한다면 최적화나 런타임 성능 면에서는 최신 .NET이 더 유리할 가능성이 높습니다.
Q2. WPF 개발에 Page 모델을 사용하는가?
UserControl 기반으로 가는게 맞다고 봅니다.
우선 WPF에 Page 기반의 Navigation 모델이 도입된 배경을 살펴봅시다.
2000년대 초중반의 웹 프론트 기술은 HTML의 부족한 부분을 채워주는 Adobe Flash가 리치 클라이언트(Rich Client)의 대명사로 자리 잡고 있었습니다. Microsoft는 이에 대응하기 위해 브라우저에서도 실행 가능한 .NET 애플리케이션(Smart Client)의 개발을 목표로 삼았고, 이 결과물이 바로 Silverlight(WPF/E)와 WPF의 XBAP 호스팅 모델입니다.
HTML의 페이지와 브라우저의 프레임 개념을 차용한 Page와 Frame이 WPF에 도입되었지만, 이러한 설계는 창 기반 데스크탑 애플리케이션의 요구와는 다소 어긋나는 면이 있습니다.
웹 네비게이션과 유사하게 탐색 기록을 관리하기 위해 내부적으로 View의 상태를 따로 저장하는 과정 때문에 MVVM을 적용할 경우 출동이 발생할 수 있고, 또한 Frame 내외부 간 리소스나 바인딩의 참조 모델이 일반적인 WPF와 다르고, 이로 인해 XAML Hot-Reload 기능을 제대로 사용할 수 없어 생산성 측면에서도 큰 걸림돌이 됩니다.
심지어 Page 모델의 기원인 Silverlight나 XBAP는 Chromium 계열 브라우저에서 실행 불가능하며 모던 .NET(.NET Core, .NET 5+)에서도 퇴출 된 상태입니다.
Xamarin이나 MAUI의 Page 모델은 웹보다는 모바일 환경의 실행(단일 뷰, 뒤로가기)을 고려했기 때문에 도입된 것입니다.
따라서 데스크탑에서 구동되는 창 기반, 멀티 뷰 애플리케이션이라면 UserControl 방식으로 가는 것이 바람직하고 DI나 MVVM 적용에도 유리하다고 봅니다.