[C#] C#과 .NET6 시작하기 - 2. .NET 이해하기

2. .NET

 

.NET과 연관되는 .NET 6, .NET Core, .NET Framework, Xamarin 등은 서로 밀접하게 연관되어 있으며 어느 부분에서는 서로 간에 중복성을 가지기도 합니다. 이들 연관성이나 각각의 특징에 관해 알아보려면 각각에 대한 개별적인 콘셉트를 이해할 필요가 있습니다.

 

● .NET Framework

 

.NET Framework는 CLR(Common Language Runtime)을 포함하는 하나의 개발 플랫폼으로서 코드의 실행을 관리하고 Application 개발에 필요한 여러 가지 클래스 라이브러리를 제공하기도 합니다.

 

마이크로소프트는 원래 .NET Framework를 Cross-platform으로 설계하기를 시도했으나 결과적으로 윈도 전용이 되었으며 4.5.2버전 부터는 아예 이를 공식화하였습니다. 이미 수많은 컴퓨터에 설치된 .NET Framework는 버그를 수정하는 것조차도 문제를 야기할 수 있다는 우려 때문에 보안에 관한 것만 아주 드물게 업데이트를 지원하고 있습니다.

 

또한 .NET Framework 4.0 이후부터 사용된 모든 App들은 같은 CRL과 GAC(Global Assembly Cache)에 저장된 라이브러리를 공유하고 있는데 호환성을 위해 특정 버전을 필요로 하게 되는 경우 문제를 야기할 수도 있습니다. 현실적으로 몇 가지 문제점과 레거시에 해당하는 플랫폼이므로 신규 프로젝트는 더이상 .NET Framework를 이용하지 말 것을 권장합니다.

 

● Mono, Xamarin, Unity

 

Mono는 .NET Framework를 제삼자에서 구현한 것으로 사실상 Cross-Platform에 해당하는 프로젝트입니다. 하지만 공식적인 프로젝트는 아니며 윈도우에서 .NET Framework를 사용하는 것만큼 충분한 활용성을 제공해 주지는 못했습니다.

 

이후 크로스 게임 개발 플랫폼인 Unity와 함께 마이크로소프트는 모노의 개발을 양도받아 Xamarin 모바일 플랫폼에서 활용할 수 있도록 개발하고 있으며 Xamarin은 2016년 마이크로소프트에서 인수하여 Visual Studio에서 무료로 사용할 수 있도록 공개했습니다. 뒤이어 마이크로소프트는 mobile app을 만들 수 있는 'Xamarin Studio development tool'을 'Visual Studio for Mac'이라는 명칭과 함께 console이나 Web service와 같은 다른 프로젝트도 생성할 수 있도록 변경하였습니다.

 

Visual Studio 2022 for Mac에 와서는 사용경험과 성능을 이유로 Xamarin Studio Editor를 Visual Studio for Windows용과 동일한 편집기로 교체되었으며 또한 네이티브 MacOS의 UI를 적용한 Visual Studio가 배포되어 신뢰도의 향상과 함께 MacOS의 내장된 기술을 활용할 수 있도록 하였습니다.

 

● .NET Core

 

Cross-platform세계에서 운영체제의 중요성은 점점 하락하고 있습니다. 이에 마이크로소프트는 .NET Framework를 Windows에서 분리시키기 위한 노력을 계속해 왔으며 그 결과 .NET Core라는 Cross-platform이 탄생하게 되었습니다.

 

.NET Core는 기존의 CLR을 Cross-platform으로 대체하기 위한 CoreCLR과 BCL을 Cross-platform으로 대체하는 CoreFX를 포함하고 있습니다. .NET Core는 App과 함께 나란히 배포될 수 있으며 같은 기기에서 동작하는 다른 app에는 영향을 주지 않는 구조로 이루어져 있습니다.

 

● NET 변화

 

2020년 개발자 컨퍼런스에서 .NET팀은 .NET을 통합하기 위한 계획이 지연되었음을 알려왔고 모바일을 제외한 .NET통합 버전인 .NET5가 2020년 10월에 발표될 것이라고 밝혔습니다. 그리고 .NET6에 와서야 비로소 모바일까지도 통합한 최초의 통합버전이 되었습니다.

 

.NET Core는 공식적으로 .NET으로 명칭이 바뀌었으며 주요 버전은 현재의 .NET Framework 4.x버전과의 혼동을 방지하기 위해 4에서 5로 곧장 변경되었습니다. 그리고 마이크로소프트는 .NET의 주요버전 업데이트를 매년 10월에 할 것으로 계획했습니다.

 

아래 표는 그간 발표된 .NET 버전과 시기를 정리한 것입니다.

 

버전	릴리즈	배포
.NET Core RC1	2015년 11월	2016년 3월
.NET Core 1.0	2016년 6월
.NET Core 1.1	2016년 11월
,NET Core 1.0.4 / .NET Core 1.1.1	2017년 3월	2017년 3월
.NET Core 2.0	2017년 8월
NET Core for UWP in Windows 10 Fall Creators Update	2017년 10월	2017년 11월
.NET Core 2.1 (LTS)	2018년 5월
.NET Core 2.2	2018년 12월
.NET Core 3.0	2019년 9월	2019년 10월
.NET Core 3.1 (LTS)	2019년 12월
Blazor WebAssembly 3.2	2020년 5월
.NET 5.0	2020년 11월	2020년 11월
.NET 6.0 (LTS)	2021년 11월	2021년 11월
.NET 7.0	2022년 11월 예정	2022년 11월 예정
.NET 8.0 (LTS)	2023년 11월 예정	2023년 11월 예정

 

Blazor Server는 .NET Core 3.1에 포함되었으나 Blazor WebAssembly는 예정과 달리 지연되어 나중에 따로 3.2버전으로 출시하게 되었는데 이로서 Blazor WebAssembly를 .NET Core 3.1의 LTS에서 분리시키게 되었습니다.

 

● .NET 지원정책

 

.NET 버전은 LTS(Long Term Support)와 Current 2가지가 있습니다. LTS는 안정화 버전에 해당하며 생명주기에 걸쳐 업데이트 주기가 적습니다. 지원기간은 초기 릴리즈 이후 3년이며 이 기간은 주기상 다음 LTS릴리즈 이후 1년을 포함합니다. 따라서 오랜 기간 지원받고자 하는 경우 당연히 LTS버전을 선택해야 합니다.

 

Current는 feedback으로 인한 업데이트로 인해 LTS보다 업데이트 주기가 잦을 수 있는 버전이며 초기 릴리즈 이후 18개월 동안 지원됩니다. 이 기간은 새로운 major 또는 minor버전이 출시된 후 6개월의 기간을 포함합니다.(.NET 5 이전에는 3개월) 이것은 만약 .NET 5.0으로 프로젝트를 생성한 경우라면 2021년 11월에 .NET 6.0을 2022년 5월까지 업데이트해야 한다는 의미가 됩니다.

 

위 2개 버전 모두 수명주기 동안에는 보안과 안정성에 관한 업데이트가 반영되며 지속적인 지원을 받기 위해서는 마지막 패치 버전까지 설치를 유지해야 합니다. 예를 들어 1.0에서 동작하는 시스템에서 1.0.1버전이 릴리즈 된다면 1.0.1버전을 설치해야 하는 식입니다.

 

● .NET Runtime과 .NET SDK

 

.NET Runtime의 버저닝 방식은 시멘틱 방식을 따릅니다. 때문에 major버전은 큰 변화에 대한 반영을, minor는 몇몇 새로운 기능에 대한 변화를, 마지막으로 patch는 버그 수정을 표현합니다.

 

반면 .NET SDK는 시멘틱 방식을 따르지 않습니다. major와 minor버전은 Runtime과 동일하게 유지하며 patch는 SDK의 major와 minor를 나타내는 관례를 따릅니다.

 

변경내용	Runtime	SDK
초기 릴리즈	6.0.0	6.0.100
SDK 버그 수정	6.0.0	6.0.101
Runtime과 SDK의 버그 수정	6.0.1	6.0.102
SDK의 새로운 기능 추가	6.0.1	6.0.200

 

● .NET의 구버전 삭제

 

.NET Runtime의 업데이트는 6.x대와 같은 major버전과 호환되며 .NET SDK의 업데이트된 릴리즈는 이전 버전에 맞춰진 Application을 여전히 빌드할 수 있습니다. 때문에 이전 구버전의 .NET을 안전하게 제거할 수 있습니다.

 

현재 시스템에 설치된 SDK와 Runtime은 아래 명령으로 확인할 수 있습니다.

dotnet --list-sdks dotnet --list-runtimes

Windows 운영체제는 '프로그램 추가/삭제'에서 제거할 수 있으며 혹은 '.NET 제거 도구'를 사용할 수도 있습니다. 이 도구는 Windows와 MacOS에서만 지원됩니다.

 

제거 도구 - .NET | Microsoft Docs

제거 도구 - .NET

● .NET Framework와의 차이점

 

.NET은 .NET Framework와 달리 모듈화로 구성되었으며 마이크로소프트의 결정에 따라 오픈소스화 되었습니다. 그리고 성능의 향상을 위해 지속적으로 개선을 진행 중입니다.

 

.NET은 또한 .NET Framework의 레거시와 WPF나 Winform과 같은 Windows에 집중되는 비 Cross-platform 기술을 제거함으로써 훨씬 간소화된 크기를 가질 수 있습니다. 다만 이것은 MacOS나 Linux의 .NET에만 포함되지 않으며 Windows용 .NET에서는 여전히 Winform이나 WPF개발이 가능하게 되었습니다. 바로 Windows Desktop Pack을 포함하는 것으로 비록 MacOS 혹은 Linux보다는 더 큰 크기가 만들어지게 되었지만 Winform/WPF를 사용한 기존의 윈도우 Application에 대한 개발을 지속할 수 있는 데다가 새로운 .NET을 활용할 수 있게 됨으로써 전반적인 성능향상및 .NET에 추가되는 새로운 기능을 활용할 수 있게 되었습니다.

 

웹 개발의 경우 WebForms와 WCF는 제거되었으며 대신 이 기술은 ASP.NET Core에서의 ASP.NET MVC, ASP.NET Web API, SignalR, gRPC기술로 대체될 수 있습니다.

 

Database의 경우 객체-관계 매핑 기술로서 Entity Framework Core가 사용되며 Oracle이나 Microsoft SQL Server와 같은 관계형 데이터베이스상에서 동작하도록 설계되었습니다. Entity Framework Core는 최근 몇 년간 비약적으로 발전하여 훨씬 간소화된 형태를 이루면서도 Microsoft Azure Cosmos DB와 같은 비 관계형 Database까지 지원하기에 이르렀습니다.

 

● .NET Standard

 

2019년 당시 .NET은 크게 다음과 같은 3가지 정도의 .NET Platform으로 나누어지고 있었습니다.

• .NET Core
• .NET Framework
• Xamarin

이 3가지는 예를 들어 .NET Core의 경우 Cross-platform개발에 사용되듯 각각의 상황에 맞게끔 설계되었으므로 그 나름대로의 강점을 가지고 있었지만 반대로 각각의 상황에 맞는 개발을 위해 3가지 platform을 나누어 습득해야 하는 문제를 안고 있었습니다. 그렇다고 해서 각각이 매우 다른 특징만을 가지고 있었던 것은 아니고 부분적으로 공통되는 영역이 존재하기는 했기만 이 자체가 사실 불필요한 습득 시간을 소모하게 만드는 요인이 되기도 하였습니다.

 

이러한 문제 때문에 마이크로소프트는 .NET Standard를 정의함으로써 모든 버전의 .NET에서 구현 가능한 API명세를 제공하게 되었고 .NET Standard 2.0에 이르러 3가지 platform모두에서 공유가능한 코드를 만들 수 있는 최소한의 기준을 마련하게 되었습니다. (.NET Core 2.0에 와서는 기존 .NET Framework에서 작성된 코드를 그대로 Cross-platform으로 이식하기 위한 API들이 대거 추가되었지만 운영체제의 특성으로 작동하는 몇몇이 여전히 존재했기에 완벽하지는 않았습니다.)

 

.NET Standard는 그저 호환 가능한 API 규격을 명시할 뿐, 시스템에 설치되는 platform이 아닙니다. .NET Standard를 이용하기 위해서는 .NET Standard를 준수하는 .NET Platform을 설치해서 사용하는 것이며 마지막 .NET Standard버전인 2.1을 준수하는 platform은 .NET Core 3.0, Mono, 그리고 Xamarin이고 .NET Framework의 마지막 버전인 4.8에서는 .NET Standard가 구현되지 않았습니다.

 

2021년 .NET6에 들어서면서 본격적으로 .NET Standard의 필요성은 현저히 줄어들게 되었습니다. .NET6는 Mobile을 포함하여 단일적인 Platform에 해당하기 때문입니다. .NET6는 단일적인 BCL과 함께 2개의 CLR을 가지고 있는데 CoreCLR은 Web Service와 같은 Server 환경과 Windows desktop App과 같은 desktop환경을 위한 것이며 Mono는 상대적으로 제한된 리소스를 사용하는 Mobile이나 Web Browser app을 위한 것입니다.

 

현재도 여전히 .NET Framework에 의해 만들어진 Application에 대한 지원이 필요하다면 .NET Standard 2.0 Class Library를 통해 개발을 지속할 수 있습니다.

 

● IL (Intermediate language)

 

Roslyn이라 불리는 C# Compiler는 C# 코드를 IL로 변환하기 위해 CLI를 사용하며 IL을 DLL이나 EXE와 같은 Assembly파일에 저장합니다.

 

그리고 .NET의 가상 머신 격인 CoreCLR에 의해 App을 실행하게 되는데 이때 CoreCLR은 IL을 Assembly로부터 읽어와 JIT(Just-in-time) Compiler를 통해 실행하고자 하는 컴퓨터의 CPU에 맞는 Native Code로 변환하고 실행하는 과정을 거치게 됩니다.

 

이렇듯 최초 C# Code는 2단계 걸쳐 Compile을 수행하게 되는데 이로서 마이크로소프트는 Windows뿐만 아니라 Linux나 MacOS에서 실행되는 CLR을 만들어 둠으로서 각각의 운영체제와 CPU환경에 맞는 Code를 생성하여 실행할 수 있게 하였습니다.

 

다만 C#이나 Visual Basic .NET 또는 F#과 같은 .NET언어는 예외 없이 동일한 IL Code로 변환되므로 이러한 특징 때문에 ILSpy와 같은 도구를 통해 IL(Assembly)을 읽어 다시 본래의 코드를 드러냄으로써 소스코드가 노출될 수 있다는 단점이 존재합니다. 따라서 보안상 비밀번호와 같은 내용을 그대로 .NET 언어코드 안에 담아두는 행위는 위험을 초래할 수 있습니다.(난독화 도구를 사용하여 코드를 읽기 어렵게 하는 경우도 있으나 완벽하지 않고 경우에 따라 Assembly가 실행될 때 Runtime Error를 유발하는 경우도 있으므로 이 또한 주의해서 사용해야 합니다.)