안녕하세요.
저는 .NET 기반으로 애플리케이션을 개발하는 회사에 재직 중입니다. 이번에 팀에서 .NET 버전을 업그레이드 해보면 어떨까 하는 이야기가 나와서 알아보다가 여기 계신 C# 및 .NET 전문가 분들의 조언과 도움을 받고자 글을 쓰게 되었습니다.
현재 저희 팀은 .NET Framework 4.7.2 버전을 기반으로 애플리케이션을 개발하고 있으며 팀에서 내년부터는 .NET8로 개발을 시작해보면 어떨까 고민 중에 있습니다. 제가 알아본 바로는 .NET Framework는 Windows 기반이고, .NET (Core)는 크로스 플랫폼을 지원하는 것으로 알고 있는데 이 밖에 유의해야 할만한 다른 차이점이나 기존의 .NET Framework에서 .NET으로 버전을 업그레이드 할 시에 고려해야 할 만한 점 등이 있을까요? (ex. Visual Studio버전에 따른 호환성, 참조하는 라이브러리들과의 호환성 등)
또한, .NET 및 .NET Core 공식 지원 정책 해당 MS의 사이트에 보시면 .NET의 경우에는 지원 종료 주기가 굉장히 짧은데 그 이유도 궁금합니다… 이렇게 주기가 짧다보면 보다 자주 버전 업을 진행해야 하는 것일까요? 그래서 .NET Framework를 유지해야 되나라는 생각도 듭니다. 긴 글 읽어주셔서 감사드리며 사소한 의견이라도 감사하게 받겠습니다. 감사합니다.
2개의 좋아요
회사에서 닷넷을 비주얼스튜디오에서 이용하려면 최신 2022를 구독해서 이용하셔야하는 비용이 발생할 수 있습니다. 베스트는 특정 IDE에 의존하지 않는것 입니다. 닷넷프레임워크와 다르게 닷넷은 비주얼스튜디오와 독립적으로 사용해도 괜찮습니다. 그외 의식하지 않고 윈도우종속적으로 쓰던 몇몇가지가 발목을 잡을수는 있습니다만, 대부분 호환됩니다.
닷넷프레임워크가 오랫동안 지원을 했다고 저희가 지금껏 어떤 지원을 받았는지 모르겠습니다. 원래 IT산업은 빠르게 변화합니다. 어차피 유지할 제품이라면 최신 환경을 기준으로 계속 보수하는게 맞습니다. 최신기술에 물릴것을 걱정하여 레거시에 잔류하는것은 당뇨약 한번먹으면 평생먹어야 한다며 투약을 꺼리는 당뇨병 환자와 비슷한 오착이 될 수 있습니다. 앞으로 계속 유지해야할 제품이라면, 닷넷8 이후로도 정기적으로 마이그레이션을 진행하는것을 권장드립니다. 스케일링도 자주하면 하나도 안아픕니다. 안아플때 합시다.
3개의 좋아요
.NET Framework에서 .NET 8 이상으로 업그레이드할 때, 큰 줄기로 보면 다음의 기술은 불가피하게 재 개발이 필요한 부분들이라, 혹시 해당되는 내용이 없는지 우선 보시면 좋을 것 같습니다.
- ASP .NET Web Form과 ASP .NET AJAX: ASP .NET Web Form 자체가 .NET Framework 전용 기술입니다. 러닝 커브가 상대적으로 적고, Web Form과 마찬가지로 상용 컴포넌트 업체들이 포트폴리오를 충분히 구축하고 있는 Blazor로 다시 개발하거나, 좀 더 미래 지향적인 대비를 위하여 MVC로 리모델링하는 방안을 검토해보셔야 합니다.
- Windows Forms, WPF는 .NET 8 이후로도 계속 지원될 뿐 아니라 계속해서 업그레이드되고 있는 기술이라 이들 기술은 큰 무리 없이 현대화가 가능합니다.
- .NET Remoting, WCF, CAS, AppDomain 등 .NET Framework 전용 기술을 쓰는 경우에는 충분한 기간을 가지고 gRPC, JSON/YAML, Open API 등으로 전환을 검토하시는 것이 좋습니다.
그리고 이제 .NET 8 이후부터는 Java/Spring과 마찬가지로 DI/IoC가 매우 강조됩니다. 기술적 호환성과는 별개로, DI/IoC 개념을 익히시는 것이 매우 권장됩니다.
또한 개별 .NET 버전의 지원 주기가 짧은 것은 의도된 정책입니다. 그러나 .NET 버전 간의 전환은 코너 케이스가 아니라면 큰 어려움이 없는 경우가 많을 것입니다. 제일 이상적인 것은 STS/LTS 구분을 두지 않고 매년 새 버전으로 업그레이드하는 것이나, 혹 매년 업데이트하는 것이 부담인 경우 2년 간격으로 출시되는 LTS 버전 중심의 버전 변경도 나쁘진 않습니다.
그리고 닷넷 개발팀의 입장에서 보면, Java와 달리 개별 .NET 버전의 지원 주기를 길게 가지고가면서 기술적인 부채를 안고 가는 것보다, 빠르고 적극적인 피드백 수용을 통해서 더 많은 발전을 이루는데 큰 가치를 두고 있는 것 같습니다. 이 점 때문에 Java의 초 장기 지원 패턴보다는 Node 개발 팀의 정책을 벤치마킹하여 현재까지 운영하고 있는 것으로 보입니다.
만약 펌웨어나 개별 구성 요소 변경이 쉽지 않은 특수 도메인/산업군 (예: 항공/우주/군수 등)에 납품하는 소프트웨어를 개발하는 것이 목적이라면, .NET은 이 도메인이 요구하는 fit에 맞지 않을 가능성이 높다고 생각합니다.
6개의 좋아요
만약 Java와 같은 수준의 초 장기 지원이 꼭 필요하지만, 그러면서도 .NET 에코시스템의 이점을 누려야 한다면, 지금으로서는 .NET Framework와 Windows Server (클라이언트 OS 기준으로는 Windows 11 및 Windows 11 IoT/Enterprise)를 택하는 것이 가장 합리적인 선택지라고 생각합니다.
다행히, 최근에 Windows Server의 경우 2025가 출시되면서 HTTP/2나 HTTP/3에 대한 지원도 보강되었을 뿐 아니라, 클라우드 컴퓨팅 도메인에서 합리적으로 가격을 관리할 수 있는 종량제형 라이선스, Windows Container와 WSL 2 지원이 이미 포함되어있습니다.
그리고 머지 않은 시일 내에 ARM64 기반 Windows Server 빌드까지 출시도 예상되므로 클라우드 기반 기술 채택에 있어서도 격차를 많이 줄일 수 있으니 꽤 괜찮을 수 있는 선택지라고 생각합니다.
(덧붙임) .NET Framework 스택 자체를 리눅스나 크로스 플랫폼으로 옮기는 시도로 과거에 Mono Project가 존재했습니다. 그러나 여러 과정을 거치며, Mono Project는 Microsoft가 아닌 WineHQ 재단의 프로젝트로 이적하였고, Mono Project의 코어는 .NET 8 이상의 코드 베이스에 거의 통합되어 Mono Project로 .NET Framework 애플리케이션을 옮기는 것은 추천할 만한 선택지가 아닌 상태입니다. (Microsoft가 Mono 기반의 런타임에 대한 책임을 지지 않는다는 뜻이기도 합니다.)
3개의 좋아요
최근에 .NET Framework 4.8(WPF앱)에서 .NET Core 8로 변경했었는데, 좀 킹받았던 부분이…
- 더 이상 지원하지 않는 클래스 및 기능(System.Deployment.Application 네임스페이스의 ApplicationDeployment, BinaryFormatter 클래스 등등…)
- 특정 프로젝트(A)와 이에 종속된 프로젝트(B)가 있을때, (A)가 윈도우 및 WPF, Winforms 사용이 설정되어 있으면, (B) 이하의 종속 프로젝트들도 일일이 다 설정
이 있었네요.
.Net standard 2.0으로 구현 할 수 있는 로직들은 미리 스탠다드로 구현해두면 이사가기 좀 더 쉽지 않을까 싶습니다 ㅎㅎㅎ
2개의 좋아요
4.8에서 8로 가는건 먼길이긴 하죠. 그래서 수정할 부분이 있을것이라고 충분히 예상이 되어 집니다.
6에서 8로 가는건 딸깍이지만요 ㅎ
2개의 좋아요
우선 답변 감사합니다. naratteu님 말씀처럼 최신 기술을 적용시켜 계속 보수하는게 맞다는 생각을 갖고 있습니다. 단, 최신 기술을 도입하기 전에 확실한 장단점과 호환성, 이에 따른 갱신에 필요한 여러 측면의 비용 및 한계점에 대해 파악하고자 질문을 드렸습니다. 소중한 답변 감사드립니다:)
1개의 좋아요
답변 감사합니다. 좀 더 추가 정보를 말씀드리자면, 저희는 Windows OS를 기반으로 하는 애플리케이션을 주로 개발하고 있으며, WPF를 사용하고 있습니다. Web이나 Windows Server를 다루고 있지는 않고 앞으로도 크게 계획을 가지고 있지는 않습니다. 그렇다면 위에서 말씀하신 것처럼 큰 무리 없는 현대화가 가능하다고 볼 수 있을까요?
추가로 알아보니 MS사이트에 .NET(.NET Core)이 성능적으로 좋다는 식으로 나와있었는데 .NET Framework와 비교하여 어떤 부분에 있어서 그런지 간략하게라도 궁금하네요… 소중한 답변 너무 감사드립니다.
2개의 좋아요
말씀하신대로 많은 로직들이 .NET standard 2.0으로 구현되어있어 그 부분은 다행이라고 생각합니다.ㅎㅎ 답변 감사합니다.
1개의 좋아요
수정할 부분과 호환성 체크 등 다양한 측면에서 여부를 알아보고 있습니다ㅎㅎ 답변 감사드립니다.
1개의 좋아요
WPF를 .NET Core로 전환하는 부분이라면, .NET Remoting이나 Serialization, AppDomain, CAS 같은 .NET Framework 전용 API에 의존하는 부분만 정리하면 큰 무리 없이 .NET Core 기반으로 현대화하실 수 있을 것입니다.
성능의 경우, 실질적으로 벤치마킹은 해보셔야 하겠으나 일반적으로 .NET Core 기반으로 이동했을 때 좀 더 나은 성능을 기대할 여지가 많이 있습니다.
실제로 참고할만한 벤치마킹 자료로 아래 두 개 아티클을 참고하시면 좋을 것 같습니다.
1개의 좋아요
다른 분들께서 현대화가 필요하(고 성공했)다는 입장을 취하셔서, 저는 필요하지 않은 관점으로 말씀드리려 합니다. (제 개인적 입장과 상관 없이요)
WPF는 윈도우 전용 앱
모던 닷넷이 크로스 플랫폼이기는 하지만, WPF 자체가 윈도우 전용이라, 현대화를 해도 (크로스 플랫폼 앱이 아닌) 원도우 전용 앱이라는 사실에는 변화가 없어 실익이 없을 수도 있습니다.
물론, 모던 닷넷이 성능이 나아졌다고는 하지만, 앱의 성능이라는 게 런타임 성능도 중요하지만, I/O 등 외부 성능에 종속되는 경우가 많기에 피부로 느끼기에는 한계가 있을 수도 있습니다.
그리고, 다른 분이 말씀하신 것처럼, 레거시 닷넷의 라이브러리에 심각하게 의존하는 경우, 대체제가 없을 수도 있습니다.
불리한 설치 편의성
레거시 닷넷은 윈도우와 함께 배포되지만, 모던 닷넷은 사용자가 별도로 설치해야 합니다.(컴퓨터가 윈도우라 할지라도)
물론, 이런 방식은 자바가 동작하는 원리와 같고, 닷넷을 포함해서 빌드하는 옵션도 있기는 하지만(앱 용량이 엄청 커짐), 레거시 닷넷과 비교하면 분명 사용자가 불편을 느낄 부분입니다.
마이크로소프트는 사실, 모던 닷넷이 윈도우에 얼마나 설치되어 있는 지에 대한 통계도 발표하지 않고, 설치를 유도하는 어떤 노력도 크게 하지 않고 있는 듯 보입니다.
.Net Standard
닷넷을 현대화하고 레거시 닷넷을 쓰지 않겠다고 하면 .Net Standard 를 쓸 이유가 없습니다.
특히, 오픈 소스도 아니고, 레거시 닷넷 클라이언트를 위한 라이브러리 작성이 목적이 아니라면 말이죠.
현대화할 때, .Net Standard 2.0 코드도 현대화해야 할 수도 있습니다.
새로운 문법
현대화를 하면 닷넷 버전이 올라가는데, 그에 따라 C#언어 버전도 많이 올라갑니다. 프레임워크는 현대화하면서 언어는 C#7.3 이하(현재는 C#13)를 쓰는 것이 좀 어색하죠.
새로운 문법에 적응하는 것도 일정 시간이 소요될 것입니다.
물론, 새로운 문법을 알고 모르고는 개발자 개인의 역량 평가 지표가 수 있습니다.
아래 문서는 버전 별 중대 변화를 간략히 설명합니다.
3개의 좋아요
말씀하신 내용으로만 판단하자면 저도 BigSquare님과 비슷한 이유로 업그레이드하는 것을 그렇게까지 추천하고 싶지 않습니다.
확실히 편리한 문법이나 성능의 개선 같은 장점도 있지만, 대부분은 전통적인 문법으로도 충분히 구현할 수 있고 (.NET 4.7~ 4.8 시점의 문법과 기능도 충분히 좋습니다) 지원이 종료되는 시점에 맞춰 매번 버전을 업그레이드하고 사용자 혹은 고객사 쪽에 새로운 .NET 런타임을 설치해달라고 요청하는 것은 경우에 따라 껄끄러운 상황이 될 수 있습니다.
혹시 팀에서 어떤 이유로 .NET 버전을 업그레이드 하고 싶어했는지 알려주실 수 있으세요?
2개의 좋아요
답변 정말 감사드립니다. 덕분에 유용한 정보 많이 알게되었습니다ㅎㅎ
답변 감사합니다. BigSquare 님 말씀대로 필요하지 않은 과점으로도 봤을 때 충분히 유의할 만한 고려사항들도 있네요…감사합니다
1개의 좋아요
우선 성능적인 부분이 제일 크다고 보여지고(실제로 체감할 수 있는 정도는 아직 모르지만요) 앞으로 나올, 또는 쓰일지도 모를 라이브러리들의 종속성 호환때문도 있습니다. BigSquare님 말씀대로 좀 더 시간을 두고 알아봐야 할 것 같다는 생각이 듭니다… 답변 감사드립니다:)
1개의 좋아요