회사에 SW팀이 생긴 지 얼마 되지 않아 전체적인 개발 프로세스나 구조가 제대로 확립되어 있지 않은 상황입니다. WinForms를 기반으로 장비 제어용 프로그램을 개발하고 있고, 저 혼자 UI/로직을 설계해가며 만들고 있습니다. 제가 C# 언어에 대해 잘 모르고, 정형화된 자료를 찾기 힘들어 이렇게 글을 올립니다.
제가 고민하고 있는 부분
Java에서는 MVC 패턴을 자연스럽게 적용해왔는데, WinForms에서는 MVP/MVVM 등 다양한 방식이 있고, 확립된 표준이 없어 보입니다. 현업에서는 그냥 한 파일에 몇천 줄짜리로 몰아서 짜는 경우도 많다고 들었는데… 개인적으로 SOLID 원칙을 최대한 지키는 구조적인 설계를 하고 싶습니다. 실무에서 많이 쓰이거나 추천되는 WinForms 설계 패턴/방식이 있을까요?
기본 WinForms UI가 너무 못생겼습니다. 버튼 하나 둥글게 만들려 해도 GDI 코드로 커스터마이징해야 해서 비효율적입니다. 혹시 WinForms에서 손쉽게 사용할 수 있는 모던 UI 라이브러리 또는 프레임워크가 있을까요?
나중에 회사 자체에서는 WPF로 넘어가려고 하는데, 현업에서는 WPF로 넘어가는 추세인가요??
Java MVC에서 닷넷 클라이언트 앱 개발로 넘어오면 말씀하신것처럼 구현 프레임워크의 수나 기법이 매우 다양하다보니 적응이 어려우실 수 있습니다. 닷넷데브를 통해서 많은 인사이트를 얻어가실 수 있기를 바랍니다.
일단 Windows Forms는 데이터 바인딩 기반의 동작이 주된 동작이고, .NET 8 이후부터 제한적으로 MVVM의 Command 패턴을 지원하고 있긴 합니다. 하지만 MVVM 엔진이 뒷받침된 것은 아니기 때문에 WPF, Avalonia 수준의 강력한 MVVM은 기대할 수 없습니다. 그리고 .NET 데스크톱 앱의 경우에는 Windows Forms를 제외하면 WPF, WinUI, Avalonia, MAUI 등 거의 모든 영역에 걸쳐서 MVVM이 사실상의 표준이라고 보시면 대체로 맞습니다. 웹에서 MVC가 표준으로 여겨지는 것과 비슷합니다.
말씀하신대로 그런 UI 커스터마이징을 로우 레벨부터 적용해놓은 것이 흔히 볼 수 있는 상용 컴포넌트 (Infragistics, GrapeCity, DevExpress 등) 들입니다. 뿐만 아니라, 상용 컴포넌트들의 경우 디자인 언어 적용이나 테마 적용까지 고려해서 테마 엔진까지 제공하는 완결성을 갖추고 있습니다. 만약 이런 상용 컴포넌트의 도움을 받기 어려운 상황이라면, WPF, Avalonia처럼 XAML을 사용하는 UI 시스템이 찾으시는 답에 가까울 것입니다.
WPF로 넘어가는 추세라기 보다는, XAML, MVVM 기반의 프레임워크가 더 널리 쓰인다고 표현하는게 정확한 표현이라고 생각합니다. Windows 전용 기술인 점까지 고려하면 개인적으로는 WPF보다는 Avalonia를 사용하기를 더 추천드립니다. 여기에 더해 하이브리드 앱을 지향하는 경우 Blazor WASM 처럼 웹 뷰 기반의 데스크톱 앱도 많이 다루게 되는 영역입니다.
ps. Avalonia 관련 예제가 많이 있겠지만, 최근 제가 리뉴얼 중인 오픈 소스 프로젝트가 마침 WPF에서 Avalonia로 전환 중이고, Avalonia의 상용 스택인 XPF의 우수 사례로 최근 출시된 LINQPad 8 및 9이 꼽힙니다. Avalonia를 사용하면, Windows 뿐 아니라 macOS, 리눅스까지 커버가 되고, AOT 컴파일을 지원해서 바이너리 크기, 초기 실행 속도, 종속성 간소화까지 모두 달성할 수 있습니다.
반갑습니다.
저는 공장업계를 떠난 지 8년이 되었지만, 주변 공장 업계 종사자분들의 경험을 수소문하여 개인적인 의견을 담아 답글 남깁니다.
어떤 회사에 다니시는지 모르겠지만 장비 제어 업계는 전통적으로 폐쇄적인 분위기이고 오픈 커뮤니티 같은 것도 없는 실정인지라 일반적인 대세를 따르는 웹개발이라는 괴리가 있습니다.
장비 통신만 잘되면 아무래도 좋다는 현업 고연차 개발자들의 마인드가 많다고 느껴지기 때문입니다. 당연히 일반화할 수 없는 부분이고, 노력하고 계시는 개발자가 많다는 것은 동의할 수 있지만, 보수적인 업계라는 특징이 그런 분들의 성장마저도 발목을 잡고 있지 않을까 하는 점이 우려되는 점입니다.
소프트웨어 서비스 업계는 최대한 패턴화하여, 원빌드 또는 글로벌이래봐야 몇개의 국가에 배포합니다. 그리고 그것도 국가마다 대응하면서 보통은 트래픽에 관련된 이슈를 통해 현재의 비즈니스의 구조에 맞게 적절하게 분할합니다. 제품 또한 소프트웨어가 전부이기에 소프트웨어의 변경이 자유로운 구조로 만들어서 유지보수도 구조적으로 합니다. 또 각자의 지식수준이 다른 많은 사람이 협업해야하는 입장이기 때문에 최대한 디자인패턴이나 알려진 일반적인 지식을 통한 개발을 하는 것이 주된 문화라고 할 수 있습니다. 그래서 커뮤니티도 있을 수 있는 거겠죠.
하지만 공장은 상황이 다릅니다. 공장에 들어가는 기계는 통상적으로 하드웨어와 소프트웨어가 함께 제품 구성되어 있고, 보통은 하드웨어 중심으로 돌아갑니다. 눈에 보이는게 하드웨어라서 그렇다고 생각합니다. 가격도 제품 구성 비율중에 하드웨어가 압도적으로 비쌉니다. 그래서 기계가 노후화되지 않는 이상 소프트웨어는 업데이트를 거의 안 하게 됩니다. 그리고 기계를 여러 공장에 납품해야하기 때문에 공장마다 커스터마이징이 들어가며 개인이 여러 개의 공장을 담당하는 경우가 일반적이라고 할 수 있습니다. 소프트웨어 업계라고 하면 국가마다 배포한다고 쳐도 10개가 안될텐데, 개인이 관리하는 공장은 30개가 넘을 수 있으니까요. 연차가 쌓여갈 수록 관리하는 공장이 줄지 않고 늘기만 할 것입니다.
그렇기 때문에 코드의 스타일이 하드웨어를 따라가게 되며, 어차피 변하지 않을 제품, 코드이기 때문에 코드 변경에 유리한 디자인패턴들은 사실상 큰 의미가 없게 됩니다. 납품하면 끝이니까요. 치명적인 알고리즘 이슈가 아니라면 소프트웨어를 업데이트하지 않습니다. 공장업계는 패턴보단, 알고리즘과 순서, 통신을 중요하게 생각하는 것 같습니다.
그렇기 때문에 일반화된 코딩패턴보다는 회사 자체에서 오랫동안 선임개발자들에 의해서 구조화된 회사 자체의 패턴을 따르게 됩니다. 이것이 학교에서 배운 일반적인 패턴들이라면 문제가 없겠지만, 그렇지 못한 경우도 꽤 있을 것입니다. 경험은 다양하고 공장은 많으니까요. 따라서 앞에 인용한 SOLID 원칙을 지켜서 코딩하시는 것을 원하신다면, 반드시 선임/사수개발자와 상담 후에 진행하시는 것이 맞으며, 독단적으로 진행하시면 회사 내의 입지가 좋지 않아질 우려가 있습니다. 한국은 나이와 연차로 기업문화가 형성되기 때문이죠.
Windows Forms를 사용하는 많은 분들이 어려워하는 부분입니다. 웹처럼 HTML, CSS 같은 디자인 전용 언어가 있는 게 아니고 C# 코드로 디자인을 하기 때문에 진입장벽 자체가 높습니다. 그래서 디자인 전용 언어인 XAML 이 있는 WPF를 선호하는 것입니다. 그래서 Windows Forms를 쓴다면 보통은 DevExpress, ComponentOne, Infragistics, Telerik 같은 상용 컴포넌트를 구매하여 쓰게 됩니다.
앞서 말씀드린대로 공장업계는 일반적인 추세를 따르기 보다는 회사 자체의 특성을 따라가게 되는 경우가 많습니다. 따라서 WPF로 넘어가는 추세가 있다고 보여지기 힘들고, MFC를 쓰는 공장은 꾸준히 쓸 것이고, Windows Forms를 쓰는 공장은 꾸준히 쓸 것이고, WPF를 쓰는 공장은 역시 꾸준히 WPF를 쓸 것으로 생각합니다.
부정적으로 남기긴 했지만, 사실 이건 비판 받을 요소는 아니고 기계를 제어하는 업계의 소프트웨어적 특성이라고 생각합니다. 사람은 필요에 의해서 움직이고 비즈니스를 만들어가는 존재인데, 필요가 없는 것을 굳이 도입하는 비용으로 산출했을 때 낭비이기 때문입니다.
우선 답변 감사합니다.
저희 회사는 장비 자체를 만드는 회사보다는 유통 과정에서 장비 내의 제어 로직과 통신, 그리고 클라이언트의 편의성을 위한 상위 어플리케이션으로 연동하는 것을 담당하고 있습니다.
말씀하신대로, 장비 업계가 폐쇄적인 분위기를 가져 참고자료하고 오픈 커뮤니티가 아예 없어 어떤 개발의 방향성을 지향해야 하는지 찾고 있습니다.
이 회사는 최근에 SW 개발에 힘을 주기 시작했기 때문에 아직 회사 내의 개발 문화가 이루어져있지 않고, 또한 프로젝트는 웬만하면 한명이 담당해서 진행하다 보니 더더욱 저만의 개발 방향성을 정하고 싶다는 생각입니다. 물론 그 과정에서 팀장 혹은 대표와의 컨펌이 이루어진다는 가정이 있어야겠지만요.
저는 단순하게 돌아가기만 하면 되는 소프트웨어가 아닌, C# 언어만의 특성인 유지보수 측면과 객체지향적인 개발을 하고싶어 이렇게 질문을 하게 되었습니다. 더더욱 뒤쳐지지 않게 트렌드를 조금이나마 따라가고 싶은 욕심도 있구요.
두서없이 말한 것 같은데, 진심어린 답변 감사합니다. 앞으로 많이 배워나가도록 하겠습니다.
오히려 소프트웨어 서비스에 가깝다고 판단이 드신다면, Windows Forms 는 통상 MVP 패턴을 많이 따른다고 하지만 저도 Windows Forms는 손에서 놓은 지 좀 오래 되었습니다. 알고 계신 추상화 지식으로 하셔도 충분하실 것입니다.
아시겠지만 추상화란 기준을 정하고 끝나지 추상화하는 게 아니라 분할할 부분을 상황에 맞춰가면서 하는 것입니다.
인터페이스는 무조건 써야하니까, 서비스 한 개만 있어도 난 지금까지 인터페이스를 무조건 썼고 그게 패턴상 맞으니까 그렇게 해야지! 라기보단 난 저급 추상화와 고급 추상화 지식을 많이 알고 있기 때문에, 항상 최 고급의 추상화가 아니라 현재의 비즈니스에 맞는 적합한 추상화를 적용한 뒤, 이후 필요에 따라 추상화 레이어를 발전시켜 나가는 것입니다.
특히나 C#은…저는 다른 언어는 안해보고 C#만 11년했지만 개인적인 C#에 대한 감상은 진정한 잡탕밥이라는 것입니다.
C# 고유의 개발 방법론이나 문법이 있다기 보단, 내가 하고 싶은 오늘은 이렇게, 내일은 저렇게 하고 싶을 때마다 그런 도구들이 이미 다 준비되어 있는 폭 넓은 언어라는 느낌으로 다가왔습니다. .NET 생태계 자체도 특정 비즈니스나 업계에 종속되게 특화한다기보단 그저 한국이 공장과 병원과 게임 분야에서 많이 쓰일 뿐, 모든 비즈니스를 흡수하는 방향으로 굉장히 제너럴하게 발전하고 있습니다. 이런 부분이 제 느낌을 뒷받침 할 수 있는 것 같습니다.
그래서 아마도 질문자님의 지식이 발전하실 수록 C#을 더 잘 쓰게 되실 것이고 현재 알고 계신 JAVA MVC의 방법론도 그대로 C#으로 적용하실 수 있으며 Windows Forms에도 Endpoint가 없는 Controller가 필요 없는 구조이기 때문에 MVC가 애매한 것이지 비슷한 형태의 추상화는 얼마든지 가능할 것입니다.
안녕하세요
신입 개발자라고 하셨는데 책임이 막중하신 것 같습니다.
저도 비슷한 업계에서 제어, 컴퓨터비전 직무로 근무한 적이 있어서 몇가지 의견 남겨봅니다. 도움이 되셨으면 좋겠네요.
Winforms는 MVP가 확실히 어울리는 것 같습니다. 데이터 및 커맨드 바인딩이 강력하지 않고, 이벤트 연결 기반이라 그렇게 느꼈던 것 같습니다. 제 경험으로는 프로젝트가 일정이 빠듯했던 경우가 많아서 마스터플랜에 따라서 필수적인 유닛테스트와 추상화 외에 요구사항 구현에 집중하고 이후 리팩토링을 하는게 시간 효율이 더 좋았습니다.
개인적으로는 MVP에 시간을 쏟기보다 Layered Architecture에 더 힘을 많이 주었었습니다. 설비가 다품종이었고 커스터마이징 요청이 많은 만큼 재사용이 중요해서 VisualStudio 기준으로 한 솔루션에 *.App, *.CommonApp, *.Infrastructure, *.Framework등으로 프로젝트들을 나누고 하위 프로젝트 단위(*Infrastructure.Database, *Framework.Logging)로 모듈화하여 관리하는게 나중에 생산성에 도움이 되었습니다. 계층을 나누고 구조를 계획하다보면 다른 아키텍처나 디자인 패턴도 필요해져서 지금도 개발할 때 중요도를 높게 가져가고 있습니다. 다만, 처음부터 이런 구조를 완성하고 가져가려면 시간이 많이 들고 너무너무 힘들어서 프로젝트가 비는 유휴 시간에 구조화, 리팩토링 작업을 하시는 것을 추천드립니다.
UI는 Telerik을 회사에서 사줘서 썼었고 그 외 MetroFramework이나 SiticoneUI도 괜찮았습니다. 뭘 쓰던 UI는 만들기 나름인 것 같아요. 저는 디자인 감각이 없어서 힘들었습니다…
주도적으로 검토중이라고 하시니 MVVM 기반 프레임워크로 바로 넘어가셔도 괜찮지 않을까 생각합니다. 정말 보수적인 회사들은 Winforms은 고사하고 VB, MFC에서 벗어나지 못하고 있는 것도 많이 봤었습니다.
