개인적으로 닷넷(코어)의 LTS는 그 수명이 비교적 짧다고 생각하는데 여러분은 어떻게 생각하시는 편인가요?
우분투는 운영체제기 때문에 직접 비교하는건 힘들지만, 그래도 LTS는 기본 5년 지원에 보안 업데이트에 한해 5년의 연장 지원이 제공됩니다.
[출처]
자바의 경우엔 버전 11부터였나요, 닷넷이랑 같은 3년주기로 LTS를 지원했지만 여기도 최근에는 5년의 기본 지원이 있고 +3년의 연장 지원이 있어 실질적인 수명은 8년으로 볼 수 있습니다.
그런데 닷넷은 연장 지원이 없이 쌩으로 3년의 지원주기를 제공하고 있어 프로덕션 환경에 도입할 때 고민거리가 생기지 않을까 걱정되는데, 실제론 어떤가요?
예를 들어 프로그램 개발을 2020년에 시작했던 회사는 6.0이 정식 공개되지 않았기 때문에 그 전 LTS인 3.1로 개발을 했을 수 있습니다. 그럼 개발기간 및 실제 서비스를 시작한 시점이 1년 후라고 쳐도 2021년인데 1년만 더 있으면 2022년이 되어서 3.1의 지원은 끊기기 직전이고 6.0 LTS로 넘어가야 하는 상황이 찾아옵니다.
프로그램의 규모가 그렇게 크지 않거나 의외로 업그레이드에 크게 문제가 없는 프로젝트라면 운 좋게 6.0으로 매끄럽게 업그레이드 할 수도 있겠지만 만약 그렇지 않다면 문제가 되는 부분을 해결하는데에 추가적인 리소스가 드니 회사 입장에선 망설여질 수 있을 것 같습니다.
만약 백엔드 서버처럼 딱히 업그레이드를 안해도 지금처럼 잘 돌아갈 수 있는 솔루션이라면 업그레이드를 최대한 미룰 수 있겠지만, WPF, WinForm 처럼 일반 데스크톱 환경의 사용자를 위한 프로그램을 제공하는 경우이고, 정직하고 성실하게 LTS 주기에 맞춰서 업그레이드를 한다고 치면 3년에 한번씩 사용자에게 새로운 닷넷을 설치하도록 유도해야하고, 그건 사용자를 꽤나 귀찮게 할 수 있습니다.
실제로 저는 19년부터 온라인 게임 관련하여 유저들의 소통을 돕는 프로그램을 만들고 오픈소스로 배포하고 있지만, 핵심적인 기능은 거의 변하지 않는데 지원주기 때문에 프레임워크를 3.1에서 6으로 옮긴 적이 있고, 불과 내년만 지나면 또 닷넷 8.0으로 전환을 해야합니다.
MS의 입장이 어느정도는 이해가 되는게, 자바의 경우엔 버전이 바뀔 때 거의 언어 측면에서의 변동사항만 있지만 (혹시 아니라면 지적 부탁드립니다), 닷넷의 경우엔 C#, F# 같은 언어 뿐만 아니라 .NET Desktop, ASP.NET Core 등 꽤 다양한 프레임웤을 내포하고 있고, 특히 MAUI 등 새롭게 선보이는 프레임워크도 있기 때문에 (사실 자마린에서 넘어온거긴 하지만) 비교적 짧은 호흡으로 빠르게 기능 추가와 안정화가 필요하다는 점에서 이해가 됩니다.
하지만 개인적으론 닷넷 프레임워크 안에 너무 많은 하위 프레임워크를 포함하고 있어 프레임워크 개별로 보면 그렇게 지원 기간을 짧게 잡을 필요가 없거나 오히려 늘리는게 좋을 수 있는 프레임워크들도 일률적으로 지원 기간이 책정되고 있는건 아닌가 하는 생각이 듭니다.
그런 측면에선 닷넷 Core 초창기의 방향처럼 C#, F# 포함하여 필수적인 사양들과 그외 프레임워크들을 별개의 프레임워크로 묶어 버전 관리를 따로 하면 이런 문제가 덜하지 않을까 싶은데, 여러분은 어떻게 생각하세요?
시장의 소리보다 이윤 추구 기업 집단이라 어쩔수 없어 보여요
그나마 NT환경 독립이라도 한것이 다행일지도
뭐 특별히 바란다고 MS의 대전략은 달라지긴 힘들것 같은데
아마 저희만 이런 불만이 있는것 같지 않고 외국도 마찬가지라
자마린 UNO 같은것 자발적으로 나온것 같기도 하고요
아마 xbox ,xp 레거시 지원 사례만 봐도 ms 내부에서도
필요성은 느꼈을것 같은데 안하는것 보면 돈이 되는 방향이 이쪽인가보네요
아마도 제 짐작에는 나중에는 윈도우 11같이 신규 버전 출시보다
필요 요소만 모듈화 해서 세분화해서 업데이트 설치 형식으로 가지 않을까 싶습니다.
괜찮으시다면 대신 공유해주시면 감사하겠습니다. 사실 보안 업데이트만 제공되는 연장 지원 정도라도 +2년 정도로 제공되어서 총 5년의 LTS 형태로 나온다고 해도 만족할 수 있을 것 같습니다. 그러면 일반 프로덕션 환경에선 연장 지원 기간 동안에 다음 LTS로 넘어가는 작업을 진행할 수도 있을 수 있구요.
피드백을 번역하고 공유해 주셔서 감사합니다. 감사합니다!
제품의 이러한 측면이 공유해주신 것처럼 같은 일부 고객에게 약간의 부담을 준다는 것을 알고 있습니다. 반면에 하나의 주 버전에서 다음 주 버전으로의 업그레이드가 어렵고 시간 소모적이며 사소한 노력이 필요한 레거시 닷넷 프레임워크와 달리 모던 닷넷에서는 하나의 주 버전에서 다음 버전으로 업그레이드하는 과정은 쉽고 간편할 수 있도록 만들기 위해 노력을 기울이고 있습니다.
이를 위해 우리는 그 목표를 향해 엔지니어링 노력을 기울였습니다. 예를 들어, VS Upgrade Assistant를 사용하는 것을 적극 권해드리고 있습니다.
따라서 모던 닷넷의 짧은 수명 주기로 인해 더 빨리 업데이트해야 한다는 것은 전적으로 옳지만, 각 업그레이드에 들어가는 노력은 몇 달 단위가 아닌 몇 주 단위로 해결이 가능한 수준에서 해소될 수 있다고 생각합니다.
그렇지만 업그레이드 과정에서 어려움을 겪고 계신 경우, 좀 더 구체적인 상황과 피드백을 듣고 싶습니다. 피드백 주시는 내용을 토대로, 어떻게 하면 더 나은 제품을 만들 수 있을지 결정할 수 있을 것 같습니다. 피드백을 주실 때에는 적절한 GitHub 리포지터리에 이슈를 만드는 형태로 제공해주시면 되겠습니다.
보내주신 피드백과 관련하여 당장 공유할 수 있는 액션 아이템은 없지만, 제품의 여러 측면에 대한 고객의 의견을 지속적으로 듣고 있으며, 이는 우리가 내리는 모든 선택에 영향을 미치는 요소 중 하나입니다.
계속해서 피드백을 보내주시면 감사하겠습니다.
고맙습니다.
아래는 원문입니다.
Thanks for taking the effort to translate the feedback and post it on this list, I appreciate it!
I acknowledge this aspect of the product creates a bit of a burden for some customers like the example you shared. On the other hand, unlike the legacy .NET Framework where upgrades from one major version to the next were a challenge, time consuming, and a non-trivial effort, with modern .NET our aspiration is that upgrades from one major to the next are fast, easy and painless. We’ve put in engineering effort towards that goal (like the VS Upgrade Assistant extension). So while you’re totally right that the shorter lifecycle for .NET results in having to update more quickly, we expect the effort going into each upgrade should be much smaller and should on average take weeks, not months. If in a particular situation it is not the case then we would love to hear from anyone having that experience so we can figure out how we can do better on that front (feel free to file an issue in the appropriate GitHub repos).
While I don’t have anything immediate to share here in terms of adapting to this feedback, we’re continuously listening to customers’ about this and other aspects of the product and it is one of the factors that influences all choices we make. So keep the feedback coming.
Thanks,
-Jamshed
피드백을 받았을 때 제품을 "즉각적으로 개선"하는 액션을 이끌어내는 것은 명백한 기능 상의 오류나 버그가 있을 경우가 주로 해당이 되고, 이와 같은 정책적인 측면은 아쉽게도 빠른 결정을 이끌어내기는 어렵습니다. 다만, LTS 지원 주기가 조금은 더 늘어나야 한다는 의견은 계속 회자되고 있는 것으로 보입니다.
@사포192 님, 혹시 원하신다면 본사 담당자와 온라인으로 미팅을 진행할 수 있을지도 알아볼까 하는데요, 지금 겪고 계시는 문제점에 대한 스토리를 전해주실 수 있을지도 여쭙습니다.!
온라인 미팅까지는 진행하지 않아도 괜찮습니다 ^^;; 그저 넋두리를 하고 싶어 작성했던 글이라 해당 팀에서 문제를 인지하고 있는 상황이라면 그걸로 충분합니다.
담당자분께서 VS Upgrade Assistant를 언급하셨었는데요, 저도 해당 툴을 이용해 .NET Framework 4.7.2 기반이었던 WPF 앱을 .NET 6으로 업그레이드하였기 때문에 해당 툴이 꽤 용이하다는 점을 잘 이해하고 있습니다.
다만 제 논점은 "업그레이드 과정이 어렵다"가 아니라 업그레이드 후에도 최소한 그 전과 동일한 수준의 안정성과 성능을 보장하기 힘든 경우에 업그레이드 그 자체에 보수적인 관점을 가지게 된다는 것이었습니다.
비교적 최근에 본 포럼에서도 .NET을 업그레이드 한 후에 메모리 사용량이 증가하였지만 그 원인을 찾는데 어려움을 겪으신 분의 사례가 있었구요, 닷넷 리포에서도 비슷한 사례(링크 1, 링크 2)가 보였습니다.
물론 어느 언어든, 어느 프레임워크든 완전 무결한 환경은 없고 버전업을 하면서 새로운 문제가 생길 수도 있습니다. 그런 점에서 제가 위에서 든 사례들은 지엽적인 예시가 될 수도 있다고 생각하지만, 논지는 그게 아니라 최근의 닷넷에서 느껴지는 인상은 확장과 통합에 중점적인 정책으로 인해 안정화와 지원은 상대적으로 약하다는 인상이 있다는 것이었습니다.
제가 처음에 닷넷의 비LTS와 LTS 버전에 대해 가졌던 인상은 틱-톡 정책처럼 기능 추가 단계와 안정화 단계가 번갈아 출시되는 형태인 줄 알았는데 LTS 기간이 3년이면 기업 레벨에서 운용하는 관점에서 봤을 땐 Long-term하지 않을 수 있지 않을까 하는 생각이 들었던 것입니다.
요약하자면
닷넷 업그레이드 과정 자체엔 상대적으로 적은 공수가 드는 것을 알고 있다
(닷넷은 오픈소스 환경이고 기업레벨의 지원 같은걸 제공하고 있지 않기 때문에) 업그레이드 이후에 동일한 성능 혹은 안정성을 최소한 보장받을 수 있을지 보장받기 힘든 환경이다
상용 환경에서 닷넷을 도입하려면 LTS 기간을 늘리는 쪽으로 정책을 펴는 것이 좋을 것 같다고 생각한다
가 되겠습니다.
추후에 제가 직접 닷넷 리포의 Discussion이나 Issue를 통해 의견을 제시해보도록 하겠습니다. @rkttu 여러모로 도와주셔서 감사합니다 ^^
