.NET 5 소개

안녕하세요, 공백 기간이 또 길어졌습니다.

이번 글은 .NET 공식 블로그에 소개된 Introducing .NET 5를 번역한 글입니다. .NET Core 3.0을 끝으로 이제는 .NET 코어가 아닌 .NET 5라는 새로운 이름으로 소개되는데요, .NET 4또는 .NET Core 4.0으로 결정되지 않고 .NET 5로 불리게 된 이유는 .NET Framework 4.0과 헷갈릴 수 있기 때문이라고 합니다.

 

기울임꼴로 표시된 부분은 번역을 그대로 옮기면 자연스럽지 않아 제 맘대로 번역해봤습니다.
이 부분은 오역이구만? 이렇게 생각하시면 편할 것 같습니다.

 

 

Introducing .NET 5

오늘 우리는 .NET Core 3.0의 차기 버전인 .NET 5를 소개하려고 합니다.
이는 .NET 제품군에서 상당히 큰 변경을 포함할 것입니다. (next big release)

 

이제는 제품군이 나뉘지 않고 .NET 하나로 통합될 것이고 이를 다양한 플랫폼*에서 사용할 수 있게 됩니다.
(There will be just one .NET going forward / * 윈도우, 리눅스, 맥, iOS, Android, WebAssembly 등)

 

새로운 .NET API와 런타임 호환성/언어 기능들을 소개합니다.

새로운 .NET 소개

.NET Core 프로젝트를 시작할 때 개발팀은 약 5천개의 .NET 프레임워크 API를 추가했습니다. 이로써 .NET Core 3.0은 .NET Framework 4.8과 비교했을 때 기능 측면(Windows Forms, WPF 및 Entity Framework 6)에 있어 상당히 근접하게 되었습니다. 또한, .NET 5의 빌드 작업이 여기에 포함되었고 .NET Core + Mono 조합으로 당신의 멋☆진 .NET 코드를 사용할 수 있습니다! (.NET Core 3.0 closes much of the remaining capability gap with .NET Framework 4.8, enabling Windows Forms, WPF and Entity Framework 6. .NET 5 builds on this work, taking .NET Core and the best of Mono to create a single platform that you can use for all your modern .NET code)

 

.NET 5를 2020년 11월에 출시할 예정이고 첫 번째 Preview(베타 참여와 비슷한 개념입니다)는 2020년 상반기쯤에 사용할 수 있을 것입니다. 이는 추후에 업데이트를 통해 Visual Studio 2019, Visual Studio for Mac 그리고 Visual Studio Code 제품에서 지원될 예정입니다.

 

 

.NET 5 = .NET Core vNext

.NET 5는 .NET Core와 함께 한 걸음 나아간 것입니다. (.NET 5) 프로젝트는 .NET 을 향상시키기 위해 몇 가지 중요한 방법을 중점으로 두고 있습니다.

• 어디서든 사용될 수 있으며 동일한 런타임 환경, 개발자 경험을 제공하는 단일 .NET 런타임 / 프레임워크 생산 (uniform runtime behaviors, 프로그램을 실행했을 때 항상 동일한 동작을 하는 것을 말하는 것 같습니다. 이 부분은 저도 확실하지 않아 알려주시면 적극 반영하겠습니다.)
• .NET의 기능을 확장하기 위해 .NET Core, .NET Framework, Xamarin 그리고 Mono의 장점을 채용
• Build that product out of a single codebase that developers (ms) can work on and expand together and that improves all scenarios.

이 새로운 프로젝트와 방향성은 .NET 그리고 .NET 5에 어마어마한 변화를 가져올 줄 것입니다.

여러분의 코드와 프로젝트 파일은 여러분들이 어떤 종류의 앱을 개발하던지간에 동일하게 있을거예요! (your code and project files will look and feel the same no matter which type of app you're building. 여기서 말하는 앱이란 모바일 애플리케이션을 말하는 것이 아닌, WPF/Windows Forms/ASP 등 어떤 형태로 빌드를 해도 동일한 환경을제공한다는 의미로 쓰인 것 같습니다)

또한 각 앱마다 동일한 런타임, API 및 언어 기능에 접근할 수 있습니다. 이는 거의 매일 CoreFX에 커밋되는 수정사항으로 인해 새로운 성능 향상을 포함할 것입니다. (This includes new performance improvements that get committed to corefx, practically daily.)

여러분들이 사랑했던 .NET Core의 기능이나 특징들은 계속 이어나갈 것입니다.

• 오픈 소스 및 커뮤니티 중심적 (GitHub)
• 크로스 플랫폼 구현
• 플랫폼 종속적인 기능(대표적인 예로 Windows Forms나 WPF, 자마린을 이용한 네이티브 플랫폼 바인딩) 활용
• 높은 성능
• Side-by-side 설치
• 작은 프로젝트 파일 (SDK 스타일이라는데.. 뭐가 SDK 스타일이라는건지)
• 짱짱좋은 CLI
• Visual Studio, Visual Studio for Mac 그리고 Visual Studio Code 제품간의 통합

 

그리고 새로 추가되는 것들입니다.

• 런타임 경험에 대해 다양한 선택을 할 수 있습니다. (밑에 더 나와있음)
• 자바 Interop 기능은 모든 플랫폼에서 사용할 수 있을 예정입니다.
  (Interop 이란 상호 운용성을 말하는데, 쉽게 말해서 .NET에서 자바 코드를 사용할 수 있게 된다는 얘기입니다)
• Objective-C 그리고 Swift Interop 기능은 다양한 운영체제에서 지원될 예정입니다.
  (맥에 한정되지는 않을 것 같습니다. 원문에서도 on multiple operating systems 라고 나와있습니다)
• CoreFX에서 .NET의 정적 컴파일(AOT)을 지원하도록 확장하고, 더 작은 파일 크기와 다양한 운영체제에서 지원되도록 할 예정입니다.

 

 

.NET Schedule

.NET 개발 및 배포 계획

(글 맨 앞에서 설명드린 내용입니다)
우리는 .NET 프레임워크(4.x 버전을 긴 시간 사용해왔기 때문)를 주로 사용하던 사용자들이 .NET Framework 4.x 버전과 헷갈릴 수 있고 또 .NET 5가 .NET 플랫폼의 새로운 미래라는 것을 확실하게 전하고 싶었기 때문에 버전 4를 건너뛰도록 결정했습니다.

또한 단순한 이름을 사용하기 위한 기회를 잡았습니다. 우리는 "만약, 하나의 .NET만 개발된다면 'Core'를 명확하게 붙일 필요가 없지 않을까?" 라고 생각했습니다. 짧은 이름은 단순화 뿐만 아니라 .NET 5가 동일한 기능과 행동을 가진다는 것을 전달하기 위함입니다. 만약, ".NET Core"라고 부르는 것을 선호하신다면 그렇게 부르시면 됩니다.

 

 

Runtime experiences

Mono는 크로스플랫폼으로 구현된 최초의 .NET입니다. 이 프로젝트는 오픈소스로 시작하였고, .NET Framework의 대체제로 사용되었습니다. 그리고 모바일 기기가 대중화됨에 따라 모바일 기기도 지원하도록 변화하였습니다. Mono는 Xamarin의 런타임으로 사용되고 있습니다.

CoreCLR은 .NET Core의 런타임으로 사용되고 있습니다. .NET Core의 주 대상은 클라우드 애플리케이션(Microsoft에서 운영 중인 거대한 스케일의 서비스도 포함)을 지원하는 것이였지만 이제는 Windows Desktop, IoT 그리고 Machine Learning 애플리케이션에서도 사용되고 있습니다.

종합해보면 .NET Core하고 Mono 런타임은 상당히 많은 공통점(둘 다 .NET 런타임이니까요)을 가지고 있지만, 또 가치있는 고유의 기능들이 있습니다. 이는 사용자가 원하는 런타임 경험을 고를 수 있도록 해줄거예요. CoreCLR과 Mono의 성능을 다른 것보다 향상시키는 작업을 하는 중입니다. 우리는 이것을 간단하게 만들 예정입니다. 예를 들자면 빌드 스위치를 만들어 사용자가 다른 런타임 옵션을 설정할 수 있도록 하는 것 처럼요.

이후에 소개되는 주제에서는 .NET 5 계획에 있어 중요하다고 생각되는 것들을 설명할 것이고, 이는 우리가 어떻게 두 런타임(Mono와 CoreCLR을 말하는 것 같습니다)을 개별적으로 그리고 또한 같이 발전시킬 것인지 확실하게 보여줄 것입니다.

 

 

High throughput and high productivity

처음부터 .NET은 중간 언어(IL)를 머신에 최적화된 코드로 해석하기 위해 Just-in-Time (JIT) 컴파일러를 의지해왔습니다. 이후 우리는 아주 높은 처리량을 갖는 JIT 기반의 관리되는 런타임을 만들었습니다. 그리고 프로그래밍을 빠르고 쉽게 하기 위해 개발자 경험 또한 활성화했습니다. (Since that time, we've built an industry-leading JIT-based managed runtime that is capable of very high throughput and also enabled developer experiences that make programming fast and easy.)

JIT는 오래 지속되는 클라우드 및 클라이언트 시나리오에 적합합니다. JIT는 특정 머신 설정을 대상으로 한 코드를 생성(특정 CPU 명령 포함)할 수 있습니다. 또한, 런타임에 메서드를 재생성하는 것이 가능합니다. JIT를 빠르게 하기 위해 자주 사용되는 메서드일 경우 정밀하게 최적화된 코드를 생성하는 옵션을 추가했습니다. (a technique used to JIT quickly while still having the option to produce a highly-tuned version of the code if this becomes a frequently used method.)

ASP.NET Core를 TechEmpower의 프레임워크 벤치마킹에서 더 빠르게 동작하도록 하기 위한 노력은 JIT의 성능과 CoreCLR에 대한 투자를 보여주는 좋은 예입니다. 컨테이너를 위한 .NET Core를 더 강력하게 하는 우리의 노력은 제약된 환경에서 런타임의 기능을 동적으로 적응하는 것으로 보여주고 있습니다. (Our efforts to harden .NET Core for containers also demonstrates that runtime's ability to dynamically adapt to constrained environments.)

* TechEmpower Framework benchmark: 웹 프레임워크의 성능을 벤치마킹하는 것으로, 이 곳에서 웹 프레임워크의 성능 순위를 보실 수 있습니다.

 

개발자 도구는 JIT 기능의 동작을 보기에 아주 좋은 예제입니다. (another good example where JIT shines) dotnet watch 또는 edit and continue (편집하며 계속하기, 디버깅 중에 코드를 변경하고 변경된 코드를 프로그램의 재시작 없이 그대로 반영하는 것)기능을 예로 들 수 있습니다. 도구는 단일 프로세스에서 재시작을 하지 않고 빠르게 수행해야할 때 컴파일과 코드를 여러 번 불러오는 것을 자주 요구합니다. (Tools often require compiling and loading code multiple times in a single process without restarting and need to be do it very quickly.)

JIT을 주로 사용해오던 .NET Core 또는 .NET Framework 개발자 분들께서는 이 경험이 친숙할 것으로 보입니다.

기본적으로 .NET 5 작업의 경우 JIT 기반의 CoreCLR 런타임을 사용하게 됩니다. 다만, 두 가지 예외가 있는데 하나는 iOS이고 다른 하나는 클라이언트측의 Blazor (WebAssembly) 입니다. 둘 다 ahead-of-time (AOT) 컴파일을 필요로 하기 때문입니다.

 

 

Fast startup, low footprint, and lower memory usage

Mono 프로젝트는 모바일 및 게임 콘솔(Xbox, PlayStation 등)을 중점으로 많은 // 중요한 기능과 결과는 그 프로젝트는 .NET 기반의 AOT 컴파일러와 최신 LLVM 프로젝트입니다. // Mono의 AOT 컴파일러는 C++처럼 .NET 코드가 머신에서 실행될 수 있는 단일 네이티브 코드를 // AOT / 작은 공간에서도 효율적으로 실행될 수 있으며, 시작할 때 필요하다면 처리량을 줄이거나 늘리기도 합니다.

Blazor 프로젝트는 이미 Mono의 AOT를 사용하고 있습니다. 이 프로젝트는 .NET 5으로 변환한 첫 번째 프로젝트입니다. 우리는 우리의 계획을 증명하기 위한 방법으로 Blazor를 사용하고 있습니다. (We are using it as one of the scenarios to prove out this plan.)

두 가지 형태의 AOT가 있습니다. (There are two types of AOT solutions. / solutions를 따로 해석하지 않았습니다)

• 100% AOT 컴파일을 필요로 하는 것
• 대부분의 코드가 AOT로 컴파일 되었으나, JIT 또는 인터프리터가 사용 가능하고 또, 코드 패턴이 AOT와는 어울리지 않는 경우 (제네릭같은 것)

Mono AOT는 두 가지 형태 모두 지원합니다. 첫 번째 형태의 AOT인 경우는 보안상의 문제로 인해 애플의 iOS와 몇 가지 게임 콘솔에서 필요로 합니다. 두 번째는 AOT의 장점을 제공하면서도, 단점은 하나도 없이 사용할 수 있으므로 선호되는 방법입니다.

.NET Native는 우리가 Windows UWP 대상 애플리케이션을 만들 때 사용하는 AOT 컴파일러입니다. 그리고 위에서 나열한 AOT 첫 번째 형태의 예입니다. 특정 구현으로, 우리는 사용할 수 있는 .NET API와 기능을 제한했습니다. 우리는 이 경험을 통해 AOT는 모든 .NET API와 패턴을 커버해야 한다는 것을 배웠습니다. (.NET Native is the AOT compiler we use for Windows UWP applications and is an example of the first type of AOT listed above. With that particular implementation, we limited the .NET APIs and capabilities that you can use. We learned from that experience that AOT solutions need to cover the full spectrum of .NET APIs and patterns.)

AOT 컴파일은 iOS나 WebAssembly 및 몇몇 게임 콘솔의 요구로 없어지진 않을거예요. AOT 컴파일은 빠른 시작과 낮은 크기를 요구하는 애플리케이션을 위한 옵션으로 만들어질 예정입니다. (We will make AOT compilation an option for applications that are more appliance-like, that require fast startup and/or low footprint. appliance-like는 제외했습니다. 네이버 백과사전에서 찾은 의미인데, 도통 이해가 안가네요..)

 

 

Fundamentals and overlapping experiences

시작 시간, 처리량, 메모리 사용량, 안정성과 진단 기능을 갖춘 전체 플랫폼으로 나아가는 것이 중요합니다. 이와 동시에 우리의 노력을 여기에 집중하는 것도 말이 되구요. 우리는 CoreCLR의 처리량과 안정성에 더 많은 투자를 하는 한편, Mono AOT 컴파일러에도 시작 속도와 크기 감소에 더 많은 투자를 할 것입니다. 이러한 것들은 좋은 결합이라고 생각합니다. 그리고, 시작 속도와 크기 감소는 처리량과 안정성과 비례합니다. (It is critical that we continue to move forward as an overall platform with startup, throughput, memory use, reliability, and diagnostics. At the same time, it also makes sense to focus our efforts. We’ll invest more in throughput and reliability in CoreCLR while we invest more in startup and size reduction with the Mono AOT compiler. We think that these are good pairings. Throughput and reliability go together as do startup and size reduction.)

다른 투자를 하는 것이 더 나은 경우도 있지만, 그렇지 않은 경우도 있습니다. (there are some characteristics where it makes sense to make different investments)

진단 기능은 기능과 성능 진단을 위해 .NET 5에서 동일할 필요가 있습니다. 또한, 이는 같은 칩과 운영체제를 지원하기 위해서도 매우 중요합니다. (단, iOS와 Web Assembly는 예외입니다) (Diagnostics capabilities need to be the same across .NET 5, for both functional and performance diagnostics.)

우리는 각 작업과 시나리오에 대한 .NET 5 최적화를 계속 수행할 것입니다. 특히, 여러 작업이 중복되는 경우에는 최적화에 더 중점을 둘 것입니다.

모든 .NET 5 애플리케이션에서는 CoreFX를 사용하게 됩니다. 우리는 CoreFX가 자주 사용되지 않는 곳(주로, Xamarin이나 클라이언트측 Blazor 작업에서)에서도 제대로 동작하도록 보장할 것입니다.

모든 .NET 5 애플리케이션은 공용 명령줄 도구가 있는 경우, .NET CLI를 사용하여 빌드할 수 있을 것입니다. (ensuring that you have common command-line tooling across projects. )

C#은 이제 .NET 5와 함께 발전할 것입니다. .NET 5 앱을 작성하는 개발자는 항상 최신 버전의 C# 그리고 그 기능에 접근할 수 있을 것입니다. (이렇게 되면 C# 언어의 버전을 선택하는 과정이 없어질 것 같네요)

 

The birth of the project

2018년 12월에 보스턴에서 기술 팀을 만나 이 프로젝트를 시작했습니다. .NET 팀(Mono/Xamarin/.NET Core)과 유니티의 디자인 리더는 다양한 기술적 기능과 구조적 방향을 제시해줬습니다. (presented on various technical capabilities and architectural direction. / presented 를 발표하다로 해석했습니다.)

이제 우리는 이 프로젝트를 마치 제품의 묶음처럼 단일 팀으로 진행하고 있습니다. 12월 이후 우리는 몇몇 프로젝트에 많은 진전을 이뤄냈습니다. (moving forward on this project as a single team with one set of deliverables.)

• 런타임 <-> 관리되는 코드 레이어 / 99% 의 CoreFX 코드??? 뭐라는건지..
• MonoVM에서 CoreFX와 그 클래스 라이브러리들을 사용할 수 있음
• MonoVM에서 CoreFX의 구현을 이용하여 CoreFX의 모든 테스트를 실행할 수 있음
• MonoVM을 이용하여 ASP.NET Core 3.0 애플리케이션을 실행할 수 있음
• MonoDevelop/Visual Studio for Mac을 CoreCLR으로 실행할 수 있음

단일 .NET으로 구현하는 것은 중요한 의문을 가지게 합니다. 과연 대상 프레임워크는 어떤 것이 되는지? NuGet 패키지의 호환성 규칙은 이전과 동일할 것인지? 어떤 작업들이 설치 없이 .NET 5 SDK로 지원될 것인지? 특정 아키텍쳐를 대상으로 한 코드는 어떻게 작성할 것인지? .NET Standard가 여전히 필요할 것인지? 우리는 이러한 이슈들을 인지하고 작업하고 있으며, 조만간 디자인 문서를 공유하고 여러분께서 읽으신 후 피드백을 저희에게 주실 수 있도록 할 것입니다. (Which workloads should be supported out-of-the-box by the .NET 5 SDK?)

 

 

Closing

.NET 5 프로젝트는 중요하고 기대되는 .NET의 새 방향입니다. .NET이 더 간단해지지만 넓고 더 확장성있는 기능과 유용성을 갖는 것을 보실 수 있을겁니다. 새로운 C# 버전을 포함하여 새로운 개발 및 기능은 .NET 5의 일부가 될 것입니다. (The .NET 5 project is an important and exciting new direction for .NET. You will see .NET become simpler but also have broader and more expansive capability and utility. All new development and feature capabilities will be part of .NET 5, including new C# versions.)

우리는 대상 애플리케이션 형식이나 운영체제, 칩 아키텍쳐에 상관 없이 동일한 .NET API와 언어를 사용할 수 있는 밝은 미래를 보았습니다. 이는 Visual Studio나 Visual Studio for Mac, Visual Studio Code, Azure DevOps 또는 명령줄 인수를 이용하여 빌드 구성을 바꾸고 다른 애플리케이션을 빌드하는 것을 더 쉽게 만들어 줄 것입니다. (We see bright future ahead in which you can use the same .NET APIs and languages to target a broad range of application types, operating systems, and chip architectures. It will be easy to make changes to your build configuration to build your applications differently, in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or at the command line. / 어떤 IDE나 편집 도구를 사용해도 설정이 쉬워지겠다는 얘기 같습니다.)

 

 

상당히 오랜 시간에 걸쳐 번역 작업을 마무리 했습니다. 모자란 영어 실력을 가지고 번역을 해서 죄송할 따름이지만, 번역하면서 느낀 가장 큰 키워드는 ".NET 플랫폼의 통합" 같습니다. 닷넷 코어나 프레임워크, 자마린 등 나뉘어 있던 플랫폼이 .NET 5 하나로 통합되면서 편리함을 챙기면서도 성능 면에서도 많은 발전이 있다고 하니, 정말로 기대가 되네요.

 

번역이 매끄럽지 않은 부분/틀린 부분은 댓글로 꼭 남겨주시면 감사드리겠습니다.

긴 글 읽어주셔서 감사합니다.

 

출처: .NET Blog - Introducing .NET 5