WPF를 주력으로 쓰다가 인력문제로 교체를 생각하고 있습니다

안녕하세요, 웹과 WPF 소프트웨어를 작업하고 있는 개발자입니다.

저희 회사에서는 웹, 윈도우 소프트웨어(맥은 없습니다)를 다루고 있고
모바일 앱은 올해 겨울이나 내년초에 개발되기로 결정된 상태입니다.
모바일의 경우 할거라는 얘기만 있고 아직 어떻게 할건지 진행된건 없습니다.

문제되는건 WPF를 이용해서 만든 소프트웨어입니다.

네트워크가 안되는 환경이나, 사용성 때문에 브라우저에서 동작하는것보단 소프트웨어로서 제공하는게 이점이 많은 환경입니다…만
C#을 다룰 수 있는 인력이 극소수입니다.

그런데다가 신규 프로젝트가 진행중이기 때문에, 안그래도 소수인 C# 개발자가 더 줄어들었는데, 저처럼 다른 업무와 같이 하는 경우도 있어서 구인을 하고 있습니다.

겸업이 된 이유는, 초기엔 소프트웨어의 필요성이 그다지 강조되지 않았고 전부 웹으로 하려다가 실제 사용자들이 소프트웨어를 선호해서 이렇게 되었습니다ㅠ

어쨋거나 구인을 하다보니 지원자부터가 너무 적고 지원해도 여러가지로 회사와 안맞다보니 면접은 보더라도 채용은 안되고 있는 상황인데요

이럴거면 차라리 다른 언어/프레임워크로 만들자는게 언급되어서 고민중에 있습니다.

제일 중요한건 사람을 쉽게 구할 수 있어야한다…인데
대충 루팡하는 사람들끼리 머리를 맞대고 생각한건

  1. 일렉트론
  2. 플러터
  3. 큐티

입니다.

리액트 하는 사람이 많으니 구해서, 웹 및 일렉트론을 시킬 수 있을것 같고
리액트를 안써도 그냥 js/ts만 있어도 가능할테니 웹과 소프트웨어 모두를 챙길 수 있을거 같습니다. 뭔가 가성비 직원 고려하는 사장같은 느낌이-_-;

플러터는 지금 저 말고 존재조차 모르는 사람이 대부분이지만
모바일 앱도 예정되어있기 때문에 겸사겸사한다는 느낌

큐티는 제가 전혀 모르는거지만, 파이썬으로 작업할 수 있다고 합니다
다만 현재 만들어진 소프트웨어를 큐티로 만들려면 좀 오래걸릴거라 합니다.

일단 말꺼낸 사람들끼리 사이트 프로젝트로
최소한의 조건에 충족되는 기능이 있는 소프트웨어를 만들어서 보자, 까지 얘기한 상태입니다만…

혹시나 추천이나 조언받을 수 있는지 궁금해서 글 남겨봅니다.

3개의 좋아요

일단 도구나 프로그래밍 언어보다도, 현재 만든 소프트웨어가 일렉트론, 플러터, QT로 winback (전체 교체)가 가능한 대상인지 기술 검토부터 하셔야하지 않을까 조언드려봅니다. 예를 들어, WPF를 UI로 사용하는 것과 별개로 장치 제어나 P/Invoke, Unsafe 코드 같은 부분에 의존하는 영역이 있다면 여기에 대응되는 stub을 만들고 관리할 수 있는지부터 확인해보셔야 할 수도 있겠고요.

그리고 WPF로 만든 사용자 경험들, 특히 그리드나 컴포넌트류로 구축한 기능들은 다른 플랫폼에서도 사용할 수 있는 카운터파트가 있는지도 꼼꼼히 살펴보신 후에 정말로 옮겨도 괜찮은지를 따져보셔야 하지 않을지 의견드려봅니다.

4개의 좋아요

개인적인 생각입니다면, WPF 의 맹점은 C#이 아니라, XAML 이지 싶습니다.

XAML 은 닷넷 말고는 거의 사용되지 않기 때문에, 이를 기반한 앱을 개발하려면, UI 기술과 로직 코드 기술이 한 세트가 됩니다.
그 결과로 개발 인력도 이 세트를 기준으로 수급 해야 하고요.

이러한 특징때문에 UI 인력과 로직 인력을 따로 운용하는 것이 현실적으로 어려운 것이죠.

즉, C# 기술자가 부족하다기 보다는 XAML 기술자, 혹은 UI 기술자 풀이 매우 적은 어려움을 겪고 계신 것이라 생각됩니다.

이러한 어려움은 블레이저 도입으로 완화될 수 있을 것 같습니다.

블레이저는 웹 환경 뿐만 아니라, XAML 을 기반하는 닷넷 프레임워크들 대부분에서도 쓸 수 있는데, 이를 블레이저 하이브리앱(Blazor Hybrid App) 이라고 합니다.

ASP.NET Core Blazor Hybrid | Microsoft Learn

블레이저를 사용하는 웹앱과 블레이저 하이브리드 앱은 UI를 공유할 수 있습니다.

Build a .NET MAUI Blazor Hybrid app with a Blazor Web App | Microsoft Learn

블레이저를 채택한다면, UI에 필요한 기술은 웹 프론트 엔드 기술로 한정되는데, 이 부분의 인력 수급은 매우 쉬운 편입니다.

UI의 상당 부분을 다른 기술자에게 맡기면, 뼈대 코드를 담당하는 C# 기술자의 부담은 줄게 됩니다.

또한, 웹부터 모바일까지 뼈대 코드를 하나의 언어로 통일하기 때문에 유지 보수 면에서도 매우 효율적이게 됩니다.

참고로, 웹 기술로 UI를 구성하는 또 다른 닷넷 기반 프레임워크로 Phortino 도 있습니다. (MS 기반 아닙니다)

Photino: Native, Cross-Platform Web UI Desktop Apps (tryphotino.io)

참고로, 포티노도 블레이저를 지원하는데, 이 경우에는 블레이저가 기반하는 웹어셈블리나 웹소켓을 이용하지는 않고, 자체 렌더링을 한다고 하네요.

블레이저를 사용하든 포티노를 사용하든 닷넷 기반이라, 운용체제, 특히 윈도우와 협업을 하는 코드는 다른 어떤 언어보다 유리한 측면이 있습니다.

마지막으로 웹 서비스 포함, 기반 기술이 C# 이 아니라면, 다른 언어로 옮기는 게 현실적으로 옳은 결정일 것 같습니다.

4개의 좋아요

플러터는 모바일 빼고 윈도나 웹용으로 쓰기는 아직 문제가 있다고 생각하는지라… 물론 윈도용 api를 깊게 쓰는게 아니라 모바일앱, 웹앱 정도의 기능을 윈도우앱으로 만드신거라면 별 문제는 없을 것 같긴한데 저도 윗분 말씀처럼 Blazor 하이브리드 써서 웹프론트 쪽을 구하시는게 어떨까 싶습니다.

2개의 좋아요

댓글 남겨주셔서 감사합니다.

dll 읽기를 지원가능하다면 무엇이든 가능하고
안될 경우 dll을 다른방식으로 처리해서 만들어 사용할 수 있어서 그렇습니다.

다만 dll을 다른 방식으로 만드는데에 좀 시간이 걸리고 충돌이 생기거나 할것으로 예상이 되긴합니다.

가장 이상적인건 바꾸지 않고 그대로 사용하는것인데, 사람을 구하기 어려운게 가장 큰 걸림돌이네요

2개의 좋아요

댓글 남겨주셔서 감사합니다.

블레이저는 그냥 asp와 붙여서 쓰는건줄 알고 있었는데, 제가 잘못 알고 있거나 많이 업데이트가 된것 같네요.

내일…이 아니라 오늘 한번 블레이저 하이브리드앱을 만들어보고 기능을 테스트해보겠습니다.

그리고 xaml보다는… C#을 다루는 사람을 구할 수가 없어서가 고민의 시작입니다.
전체 인구로 보면 괜찮을지 몰라도, 저희 회사 기준으로 다른 분야 개발자는 3자리 숫자로 지원이 들어오는데… 씨샵만 유독 1자리, 많아도 20명 미만으로만 잡히는데
외부 인력을 데려다 쓰자니 장기로 계약하고하는 문제가 있습니다

아니면 저처럼 잡식하는 사람이 있거나, 그렇게 만들어버리면-_- 되기도 하지만…
아무래도 개발자들의 의견을 수용하는쪽으로 가다보니 저같은 잡식파는 여기저기 낑겨서 비명을 지르네요ㅠ

2개의 좋아요

댓글 남겨주셔서 감사합니다.

플러터는 자세히 파보질 않고, dll사용여부만 판단한지라 세부적인 사항은 잘 모르겠네요.

다만 윈API를 쓰기 위해서…보다는 고객들의 pc가 윈도우라서 그렇게 갔기 때문에, 최소한 현재까지는 문제 없으리라 판단했습니다…만

플러터 웹을 보고 경악한적이 있어서, 아마 비슷한 경우일거같으니 플러터는 모바일에만 쓰는걸로 가야겠습니다…

1개의 좋아요

플러터는 일단 제외하시는게 나을것으로 보입니다.
dll불러오는건 쉬운데요. 데스크탑용 앱 개발 시 api및 여러가지가 부족합니다.
구글이 데스크탑 특히 윈도우즈 지원을 약간 고의적으로 느리게 하는 경향이 보입니다.

2개의 좋아요

WPF 인력이 그렇게 구하기 어려운가요??
아무리 그래도 WPF 인력은 좀 있을것 같았는데

QT는 임베디드나 장비 다룰때나 고려하지
WPF보다 더 인력이 처참한것으로 압니다.

리액트 네이티브 같은것이 있긴 하지만
그래도 롱텀은 WPF일것 같긴 하지만 구하기 힘드시다니
참 고민이 많으시겠어요

아그리고 닷넷 인력 지원 몇십명은 그냥 그게 맞습니다.
원래 이쪽은 공급이 이정도구나 생각하시면 되요

3개의 좋아요

?? 20명 지원이 적어서 안된다… 몇백명은 되야 한다 ???
잘 이해가 안가는 군요…

3개의 좋아요

솔찍히 한국에서 눈높이를 높이면 .net 개발자 구하기 힘들긴 합니다.
회사가 이름도 좀 있고 상장도 되 있고 복지도 좋고 하면 어떨지 모르겠는데
저희 회사같은 중소는 진짜 구하기 힘들더라구요.

20명이면… 부럽습니다.

WPF를 쓰는 이유는 Windows 환경에서 GUI 어플을 개발 할때 지금까지는 가장 무난하고
무료에 가까운(VS 비용은 캐바캐라…) 환경이라 쓰는거겠죠.

QT를 말씀 하셨는데 QT는 유료입니다. 꽤 비싼걸로 알고 있습니다.
언어는 CPP 입니다. 닷넷보다 구인이 힘들수 있습니다. 개발 효율도 안나오고요.

어떤 솔루션인지는 모르겠으나
웹이 베이스고 PC가 편의성을 위해 나온거고 모바일 지원까지 고려 하고 있다면
웹앱으로 가는거도 방법일듯 싶습니다.

2개의 좋아요

저희는 장비제어 회사인데

C# winform 가능 인력 수급이 안되서 저 입사 전에 먼저 온 2명은 웹 하시던 분 이네요.

신규로 간단한 연동 하는데 웹이랑 개념이 달라서 그런가 옆에서 하는 거 보니 좀 …(저걸 왜 저렇게??? )

이런 상황이라 PM은 신규 프로젝트는 가급적 웹 기반 으로 할려고 하네요

다른 2명 활용을 해야 하니 이해는 갑니다만
저는 반대로 웹을 몰라서…나중에 어떻게 될려나 고민되네요

1개의 좋아요

답변 감사합니다.

개발과 별개로 그런 비밀스러운(?)게 있나보군요

1개의 좋아요

답변 감사합니다.

가급적이면 wpf로 가는게 현재 얼마 없는 가용인력으로도 뭔거 할 수 있개 때문에 좋긴한데
뒤에 이어서 작업하거나, 기존 wpf개발자들이 다른 업무 때문에 붙잡지 못하게 될때가 있어서 그렇습니다. 코어한거만 다루고 범용적인건 다른걸 사용하거나 해야겠습니다

1개의 좋아요

답변 감사합니다.

본문 내용대로 지원자가 20명이고 실제로 채용이 된 인원은 없습니다
지원자가 몇백명이 되어야 씨샵을 쓴다는 얘기가 아니라, 씨샵 인력의 수급되는 수이 적다는 얘기입니다

1개의 좋아요

답변 감사합니다.

아예 웹서비스로 만들어서 특정 기능(설계때 없던 기능들) 이외에는 가능한데
이상하게 브라우저로 열리는걸 싫어하시더라고요ㅠ 이유를 모르겠습니다.
그런데 모바일 웹은 잘 쓰고 있고 있습니다(…)

다른 사이트랑 같이 뜨는데도 모바일은 좋고 pc는 싫다니 저로선 기준을 모르겠네요ㅠㅠ

그나마 다행인건… 웹으로 만들고 껍데기만 씌워서 보내면 잘 쓰고 있다는겁니다
(이것 때문에 일렉트론을 생각한거기도합니다)

2개의 좋아요

답변 감사합니다.

저희랑 반대되는쪽이라 부럽네요…
저흰 아예 웹기반으로만 가려고 했던거라 팀이름도 웹개발팀인데
사용자들 의견으로 소프트웨어랑 병행하고있네요;

2개의 좋아요

브라우저로 열리는것이 싫다면 닷넷 데브도 지원하는
pwa 도 고려해보시는것도 좋을것 같습니다.

바탕화면에 아이콘도 생기고 실행 화면도 form 창이고
알림도 보낼수 있고 물론 기술적 허들이 있을수 있는데
웹으로 만드는것고 아마도 기존에 다른 사이트 만들어놓으신것
조금 고쳐서 만들수도 있을것요 (이건 확실히 알아보셔야 할것 같습니다)

2개의 좋아요

비밀스럽다기보다는… 구글에서 개발한 프레임웍이나 라이브러리를 윈도우즈에서 맛보고 씹고 뜯고 해보면 쌍욕이 나오는 경우가 생깁니다.

최근 구글 기조가 프레임웍이나 라이브러리를 바이너리 배포를 안하고 빌드를 해서 써라는 쪽으로 가고 있는데요.
BAZEL이라는 빌드툴을 씁니다.
이게 윈도우즈에서는 욕나오게 빌드가 잘 안되는것들이 많습니다. 리눅스에서는 아무 문제가 없고요. 맥은 지원한다고 써 있으면 리눅스 수준으로 쉽게 되고요.

플러터는 그정도는 아니긴 한데. 데스크탑에서 검토 해보고 각종 라이브러리 샘플들 써보고 하면 아~ 이건 지원에 의미를 둔거구나~ 하게 됩니다.

1개의 좋아요

WPF는 그나마 수요가 증가한다고 생각했는데 공급이 줄어드는 것에 영향이 더 큰가보네요.

네트워크 안되는 환경이 있다는 것과 고려하시는 기술로 대체 가능한 것은 고려하신 듯하니
고려하신 기술을 사용하는 사람이 과연 구하기 쉬운가 하는 부분에 의문이 듭니다.

리액트는 웹 프론트엔드에, 플러터는 모바일에 각각 높은 사용 영역이 있어 윈도우 클라이언트 앱이 업무에 주가 되면 채용이나 이탈율도 꽤 될 것 같습니다. 커뮤니티가 크고 활동도 많은 편이라 마이너 영역에서 사용하고 있는 경우 영향이 있지 않을까 싶네요.

저같은 경우 C#을 오래 사용했지만 웹 쪽 경력이 많아 WPF는 지원 자격이나 경력이 인정이 안되기 때문에 다른 기술 스택으로 넘어갈 준비를 하고 있습니다.
사용이 많지 않은 기술 쪽에서 경력을 쌓는 것이 쉽지 않았지만 인정받거나 계속 활용하는 것은 더 어렵더라고요. 반대로 닷넷으로 서비스를 운영하는 회사는 자바로 서비스를 개발/운영해본 경력을 닷넷 경력보다 인정해주기도 하고요.

C#을 사용해본 개발자로 채용 범위를 넓혀서 WPF를 시켜보는 것과 다른 주류 기술로 비주류 영역에 개발을 시키는 것은 좀 더 고민해보시는 것이 어떨까 싶습니다.
한국은 용도에 특화된 기술이 아니면 구인이나 구직 한쪽이 기울어지면서 같이 무너지는걸 많이 본 것 같아서요.

3개의 좋아요