[.NET] .NET 통합: .NET 5에 대한 Microsoft의 계획

Microsoft가 5월에 Microsoft Build 2019에서 .NET 5를 발표했을 때 데스크톱, 웹, 모바일, 클라우드 및 장치 플랫폼에서 작업하는 개발자에게 중요한 진전을 표시했습니다. .NET 5는 다양한 프레임워크를 통합하고 코드 복잡성을 줄이며 플랫폼 간 도달 범위를 크게 향상시키는 플랫폼 업데이트입니다.

 

Microsoft는 .NET Framework, .NET Core 및 Xamarin/Mono와 같은 여러 주요 프레임워크의 소스 코드 스트림을 병합할 것을 제안합니다. 이러한 노력은 세기의 전환기에 시작될 때 분리되었던 스레드를 통합하고 개발자에게 작업을 위한 하나의 대상 프레임워크를 제공할 것입니다.

 

 

.NET, Mono 및 Shared Source Initiative에서 .NET 5로의 소스 코드 흐름 개념

 

각 프레임워크의 타임라인이 동기화되고 궁극적으로 2020년 11월에 단일 스레드로 .NET 5로 병합되는 방법을 보여줍니다. (이미지에서 .NET Framework는 .NET FW로 단축되었습니다. ) .NET 5는 .NET Framework 4.8, Mono 5.0 및 .NET Core 3.0을 능가합니다.

 

.NET 5 - 통합 플랫폼

이 작업의 결과로 .NET 5 프레임워크가 모든 플랫폼(데스크톱, 웹, 클라우드, 모바일 등)에서 실행되는 통합 플랫폼입니다.

 

Microsoft의 Rotor(Shared Source Common Initiative), SilverLight, Windows Phone, .NET Core 및 .NET Framework(Mono는 아님)와 같은 다양한 .NET 프레임워크가 동일한 소스 코드에서 컴파일된 방식은 놀랍습니다. 모든 소스 코드는 단일 리포지토리에서 유지 관리되고 모든 .NET 프레임워크에서 공유됩니다. 그렇게 함으로써 Microsoft는 다른 프레임워크에 공통된 API가 동일한 소스 코드에서 제공되고 동일한 서명을 갖도록 할 수 있었습니다. 유일한 차이점은 어떤 API가 공유되었는지였습니다.

 

다른 프레임워크를 대상으로 하는 단일 소스를 달성하기 위해 다수의 #ifdef와 같은 다양한 하위 설정 기술이 사용되었습니다. 또한 관심 있는 부분 설정 기술(즉, 다른 #ifdef)의 직교 집합이 .NET 소스 코드에 구워져 Rotor의 플랫폼 간 지원을 구축하여 Silverlight와 .NET Core를 모두 빠르게 개발할 수 있습니다.

 

하위 설정 기술의 직교 세트는 남아 있지만 플랫폼 간 컴파일을 가능하게 하는 하위 설정(서로 다른 프레임워크를 생성하는 하위 설정)은 제거됩니다. (예를 들어 bit.ly/2WdSzv2에서 오래된 #ifdef를 제거하는 pull 요청을 참조하세요.) 오늘 제거할 수 있는 이유는 .NET 1.1 릴리스 후 며칠 이내에 .NET Core 및 . NET Framework 소스 코드가 분기되었습니다(복사된 것과 비슷함). 이것은 실제로 두 개의 .NET 소스 코드 웹 사이트가 있는 이유를 설명합니다. referencesource.microsoft.com의 .NET Framework와 source.dot.net의 .NET Core입니다. 이들은 두 개의 별도 코드 기반입니다.

 

배경 이야기

하위 집합을 계속 사용하지 않고 분기하기로 한 결정은 이전 버전과의 호환성 유지(.NET Framework의 높은 우선 순위)와 혁신(.NET Core의 우선 순위) 간의 긴장을 반영합니다. 호환성 유지가 .NET API 수정 또는 개선과 충돌하는 경우가 너무 많아 두 목표를 모두 달성하려면 소스 코드를 분리해야 했습니다. 실제로 API가 다르고 버전이 호환되지 않는 경우 #ifdef를 사용하는 것은 더 이상 프레임워크를 분리하는 기능적인 방법이 아닙니다.

그러나 시간이 지남에 따라 개발자가 두 프레임워크 내에서 성공적으로 실행할 수 있는 라이브러리를 만들 수 있도록 허용하는 또 다른 충돌이 발생했습니다. 이를 달성하기 위해 개발자에게 프레임워크에 표준으로 식별되는 특정 API 세트가 있음을 보증하는 API 표준이 필요했습니다. 그렇게 하면 표준 내에서 API만 활용하면 라이브러리가 프레임워크 간 호환이 됩니다(정확히 동일한 어셈블리가 다시 컴파일하지 않고도 다른 프레임워크에서 실행될 수 있음).

.NET에 새로운 기능이 추가될 때마다(예: Span<T>) 이전 버전의 프레임워크와 이전 버전과의 호환성을 유지하기가 점점 더 어려워졌습니다. 보다 구체적으로 말하면, .NET Framework에서 새로운 .NET Standard 버전의 개념을 지원하는 것이 문제였습니다. 이는 실제로 새로운 .NET Core 혁신이었습니다. 또한 .NET Framework와 .NET Core 간의 .NET Standard 호환성을 유지하기 위한 유지 관리 부담이 될 때까지 .NET Standard의 각 새 버전에는 점점 더 많은 API 집합이 포함되어 있었습니다.

 

두 프레임워크는 표준 때문에 점점 더 비슷하게 보이기 시작했습니다. API의 일관성이 높아짐에 따라 분명한 질문이 제기되기 시작했습니다. 개별 코드 기반을 다시 함께 이동하지 않는 이유는 무엇입니까? 그리고 실제로 .NET Core 3.0 미리 보기부터 .NET Framework WPF 및 Windows API의 많은 부분이 선별되어 .NET Core 3.0 코드 베이스에 병합되었습니다. .NET Core 3.0의 소스 코드는 .NET Framework 4.8의 최신 기능(데스크톱, 클라우드, 모바일 및 IoT)과 동일하게 되었습니다.

 

Mono/Xamarin

이 시점에서 아직 다루지 않은 주요 .NET 프레임워크가 하나 있습니다: Mono/Xamarin. Rotor의 소스 코드는 공개적으로 사용 가능했지만 이를 사용하면 라이센스 계약을 위반하게 됩니다. 대신 Mono는 Linux 호환 버전의 .NET을 만들겠다는 비전으로 별도의 미개발 분야 개발 노력으로 시작했습니다. 

 

Mono 프레임워크는 2003년 Novell에 의해 회사(Ximian)가 인수될 때까지 시간이 지남에 따라 계속 성장했으며 Novell이 Attachmate에 매각된 후 8년 후에 폐쇄되었습니다. Ximian 경영진은 2011년 5월 Xamarin으로 빠르게 개편되었습니다. 그리고 2년도 채 되지 않아 Xamarin은 Android와 iOS 모두에서 실행되는 플랫폼 간 UI 코드 기반을 개발했으며 현재는 비공개 소스인 Mono의 교차 플랫폼 버전을 내부적으로 활용합니다.

 

2016년 Microsoft는 Xamarin을 인수하여 모든 .NET 프레임워크 소스 코드를 단일 회사의 통제 하에 가져왔습니다. 잠시 후 Mono와 Xamarin SDK가 오픈 소스로 출시됩니다.

이로써 우리는 2019년 상반기에 .NET Core 3.0 및 Mono/Xamarain이라는 두 가지 주요 코드 기반이 기본적으로 진행됩니다. 이와 함께 .NET Standard 및 곧 출시될 .NET Standard 2.1로의 API 통합이 있습니다.

(Microsoft는 누구나 예측할 수 있는 한 Windows에서 .NET Framework 4.8을 지원하지만 .NET Core 3.0 이상 .NET 5는 앞으로 새로운 애플리케이션을 위한 전략적 플랫폼으로 이를 능가할 것입니다.)

 

API가 점점 더 가까워지면서 .NET Core 3.0와 Mono의 병합도 이미 시작되고 있습니다. 오늘날 Mono는 이미 1/3의 Mono 소스, 1/3의 CoreFx 및 1/3의 .NET Framework 참조 소스입니다. 이는 Microsoft Build 2019에서 발표될 .NET 5의 무대를 마련했습니다.

 

.NET 5의 장점

이 통합 버전의 .NET 5는 모든 .NET 애플리케이션 유형(Xamarin, ASP.NET, IoT 및 데스크톱)을 지원합니다. 또한 단일 CoreFX/BCL(기본 클래스 라이브러리), 두 개의 개별 런타임 및 런타임 코드 기반(다른 두 개의 런타임을 단일 소스로 만드는 것은 정말 어렵다) 및 단일 도구 체인(예: dotnet CLI)을 활용합니다. 결과는 동작, API 및 개발자 경험 전반에 걸쳐 균일합니다. 예를 들어 System.* API의 세 가지 구현이 아니라 각기 다른 플랫폼에서 실행되는 단일 라이브러리 세트가 있습니다.

 

.NET의 통합에는 많은 이점이 있습니다. 프레임워크, 런타임 및 개발자 도구 집합을 단일 코드 기반으로 통합하면 개발자(Microsoft와 커뮤니티 모두)가 유지 관리하고 확장해야 하는 중복 코드 양이 줄어듭니다. 또한 요즘 Microsoft에서 기대하는 것처럼 모든 .NET 5 소스 코드는 오픈 소스가 될 것입니다.

합병으로 각 개별 프레임워크에 독점적인 많은 기능이 모든 플랫폼에서 사용할 수 있게 됩니다. 예를 들어, 이러한 플랫폼에 대한 csproj 유형은 널리 사용되는 간단한 .NET Core csproj 파일 형식으로 통합됩니다. 따라서 .NET Framework 프로젝트 유형은 .NET Core csproj 파일 형식을 활용할 수 있습니다. .NET Core csproj 파일 형식으로의 변환은 Xamarin 및 .NET Framework(WPF 및 Windows Forms 포함) csproj 파일에 필요하지만 작업은 ASP.NET에서 ASP.NET Core로의 변환과 유사합니다. 다행히 오늘날에는 ConvertProjectToNETCore3(bit.ly/2W5Lk3D 참조)와 같은 도구 덕분에 훨씬 더 쉬워졌습니다.

또 다른 중요한 차이점은 Xamarin 및 .NET Core/.NET Framework의 런타임 동작입니다. 전자는 소스 코드를 플랫폼의 기본 소스 코드로 컴파일하는 AOT(ahead-of-time) 컴파일과 함께 정적 컴파일 모델을 사용합니다. 대조적으로 .NET Core 및 .NET Framework는 JIT(Just-In-Time) 컴파일을 사용합니다. 다행히 .NET 5에서는 프로젝트 유형 대상에 따라 두 모델이 모두 지원됩니다.

 

예를 들어 .NET 5 프로젝트를 런타임에 JIT 컴파일러(지터)를 사용하거나 iOS 또는 Android 플랫폼에서 작동하는 기본 컴파일러를 사용하는 단일 실행 파일로 컴파일하도록 선택할 수 있습니다. 대부분의 프로젝트는 지터를 활용하지만 iOS의 경우 모든 코드는 AOT입니다. 클라이언트 측 Blazor의 경우 런타임은 WASM(웹 어셈블리)이며 Microsoft는 AOT에서 소량의 관리 코드(약 100kb ~ 300kb)를 컴파일하고 나머지는 해석할 예정입니다. (AOT코드가 커서 전신환 비용이 꽤 부담됩니다.)

.NET Core 3.0에서는 단일 실행 파일로 컴파일할 수 있지만 해당 실행 파일은 실제로 런타임에 실행하는 데 필요한 모든 파일의 압축 버전입니다. 파일을 실행하면 먼저 임시 디렉토리로 확장된 다음 모든 파일이 포함된 디렉토리에서 애플리케이션의 진입점을 실행합니다. 대조적으로 .NET 5는 제자리에서 직접 실행할 수 있는 진정한 단일 실행 파일을 생성합니다.

.NET 5의 또 다른 놀라운 기능은 Java 및 Objective-C(Swift 포함)의 소스 코드와의 상호 운용성입니다. 이는 초기 릴리스부터 Xamarin의 기능이었지만 모든 .NET 5 프로젝트로 확장됩니다. 예를 들어 csproj 파일에 jar 파일을 포함할 수 있고 .NET 코드에서 Java 또는 Objective-C 코드로 직접 호출할 수 있습니다. (불행히도 Objective-C에 대한 지원은 Java보다 나중에 제공될 것입니다.) .NET 5와 Java/Objective-C 간의 상호 운용성은 프로세스 내 통신만을 대상으로 한다는 점에 유의해야 합니다. 동일한 시스템의 다른 프로세스 또는 다른 시스템의 프로세스에 대한 분산 통신에는 REST 또는 RPC 기반 분산 호출로 직렬화가 필요할 수 있습니다.

 

.NET 5에 없는 것

.NET 5 프레임워크에서 사용할 수 있는 중요한 API 세트가 있지만 지난 20년 정도 동안 개발되었을 수 있는 모든 것이 포함되어 있지는 않습니다. .NET Standard 2.1에서 식별된 모든 API가 지원될 것으로 예상하는 것이 합리적이지만 Web Forms, WCF(Windows Communication Foundation) 서버 및 Windows Workflow를 비롯한 일부 "레거시" API는 지원하지 않습니다. 이들은 .NET Framework에만 남아 있을 예정입니다. .NET 5 내에서 동일한 기능을 달성하려면 다음과 같이 이러한 API를 이식하는 것을 고려하십시오.

 

• ASP.NET 웹 양식 => ASP.NET Blazor
• WCF 서버 및 원격 => gRPC
• Windows 워크플로(WF) => 코어 WF(github.com/UiPath/corewf)

WCF 서버 지원의 부족은 의심할 여지 없이 일부 사람들에게 실망스럽습니다. 그러나 Microsoft는 최근 MIT 오픈 소스 라이선스에 따라 소프트웨어를 출시하기로 결정했습니다. 이 소프트웨어의 운명은 커뮤니티를 제어하는 ​​것입니다(github.com/CoreWCF/CoreWCF 참조). .NET Framework와 독립적으로 릴리스하기 위해 수행해야 할 작업이 여전히 엄청나게 많지만 그 동안 클라이언트 측 WCF API를 사용할 수 있습니다(github.com/dotnet/wcf 참조).

 

.NET 출시 일정

Microsoft가 .NET 5에서  통합 .NET 릴리스에 대해 정기적인 주기를 채택한다고 발표했습니다.

.NET 출시 일정

앞으로 매년 4분기에 .NET의 일반 공급 버전이 출시될 것으로 예상할 수 있습니다. 이러한 릴리스 중 모든 두 번째 버전은 LTS(장기 지원) 릴리스로, Microsoft는 최소 3년 또는 후속 LTS 릴리스 이후 1년 중 더 긴 기간 동안 지원합니다. 즉, 다음 LTS 릴리스로 애플리케이션을 업그레이드하려면 항상 최소 3년의 시간이 필요합니다. .NET Core 지원 정책 및 .NET 5 이상 지원 정책이 될 것으로 합리적으로 예상할 수 있는 사항에 대한 자세한 내용은 bit.ly/2Kfkkw0을 참조하세요.

 

마무리

.NET Core 개발이 시작되었을 때 .NET Framework의 거의 포괄적인 재작성은 상상조차 할 수 없었습니다. 당시 Microsoft는 Linux, 컨테이너 및 PaaS에서 Azure 호스팅 경험을 크게 향상시키려는 요구에 부응하고 있었습니다. 따라서 회사는 고객과 Azure 제품 팀의 요구 사항을 충족하기 위해 무언가를 내놓는 데 집중했습니다.

.NET Core 2.0에서는 .NET Framework에 있는 기능과 일치하도록 임무가 확장되었습니다. 다시 말하지만, 너무 많은 것을 취하기보다는 실행 가능한 것을 출시하는데 초점을 맞췄습니다. 그러나 .NET Core 3.0과 .NET Standard 2.1의 구현으로 상황이 바뀌기 시작했습니다. 새로운 기능이나 버그가 생겼을 때 세 가지 다른 프레임워크에 들어가서 변경해야 한다는 생각은 짜증과 비용이었습니다. 그리고 곧 가능한 많은 코드를 단일 코드 기반으로 리팩토링하자는 아이디어가 떠올랐습니다.

그래서 .NET 5가 탄생했습니다. 또한 간단한 csproj 형식이든, 오픈 소스 개발 모델을 채택하든, Java 및 Objective-C(Swift 포함)와의 상호 운용성을 가능하게 하거나, JIT 및 AOT 컴파일을 지원하든 상관없이 각 프레임워크의 모든 기능을 통합하는 아이디어가 탄생했습니다. 마찬가지로 단일 통합 프레임워크에 대한 아이디어가 분명한 다음 단계가 되었으며 Microsoft 내부와 외부 모두가 축하할 것입니다.

 

참고

• C# - .NET Reunified: Microsoft’s Plans for .NET 5 | Microsoft Learn