ASCII.jp 에 기고된 스즈키 준야씨의 기고를 번역한 글 입니다.

2000년대에 들어 마이크로소프트가 「Next Generation Windows Services」(NGWS)의 명칭으로 응용 프로그램의 새로운 개발 · 실행 프레임워크의 개발을 발표한 이후로,  벌써 16년의 세월이 흘렀다. 그리고 지금도 .NET Framework은 계속해서 발전하고 있다.

다만, 그 과정에서 다양한 파생 기술과 키워드가 등장하였고 최신의 트렌드에서 조금 떨어진 사람들에게는 상호 관계와 역할을 이해하기가 조금 어려워져 버린 감이있다. 이번 기회에 .NET의 최신 동향을 정리하고 앞으로의 마이크로소프트가 그려나갈 전략을 정리하고 싶다.

BUILD 2016에서 그려진 .NET의 미래

마이크로소프트의 .NET 전략을 말하는데 있어서 중요한 항목 중 하나에 Xamarin 인수를 꼽을 수 있다. Xamarin 인수를 통해 .NET 응용 프로그램 배포 모델에 변화가 나타나고 있기 때문이다. 예를 들어, 작년 2015년 4월에 열린 개발자 컨퍼런스 BUILD 2015에서 .NET은 핵심 컴퍼넌트인 .NET Framework 과 .NET Core에 촛점을 두었지만, 2016년 2월에 마이크로소프가 Xamarin을 인수 한 것을 계기로, 올해 2016년 3월 BUILD 2016에서는 .NET Framework 과 .NET Core 그리고 Xamarin의 3가지 요소를 고려한 전략을 설명할 필요가 있게 됐다. 이 세 가지 요소가 존재하는 의미와 차이를 정리해 보자.

2015년 당시 .NET 전략을 담당하는 핵심 구성 요소

2016년. 마이크로소프트는 Xamarin 인수를 통해 .NET 제품군을 확대했다.

Xamarin과 Mono Project

지금에 와서는 알 방법이 없지만 적어도 .NET Framework의 최초 버전이 등장한 2001년에 마이크로소프트는 Windows 이외의 플랫폼에서 .NET 응용 프로그램의 실행을 의식한 크로스 플랫폼 개발은고려하지 않았던 것으로 보인다.

.NET에서 사용되는 C# 언어와 그것을 컴파일 중간 언어로 표현하는 CLI(Common Language Infrastructure) 및 CLI를 실행하기위한 CLR(Common Language Runtime)이라는 런타임의 존재는 종래까지의 Windows에서만 작동 Win32 API 기반의 네이티브 코드와 달리 Windows 이외의 환경에서 작동 가능하다는 의미로 생각될수 있지만 .NET Framework 자체는 Windows에서만 제공되고 있었다. 따라서 Windows에서 기동되는 새로운 세대의 응용 프로그램 실행 환경의 범위를 벗어나지는 못했다고 생각한다.

이런 가운데 .NET의 미래에 기대를 품고 도구 및 실행 환경을 외부 플랫폼으로 이식한 것이 바로 Miguel de Icaza를 중심으로 한 Mono Project이다.  .NET의 기반이되는 CLI의 사양 자체는 공개(Ecma / ISO / JIS 등으로 표준화 되어있는) 되어 있었기  때문에 .NET Framework와 호환성을 가진 Linux 용 도구세트를 탑재한 최초의 버전이 2004년에 등장했다.

Xamarin을 이끄는 Miguel de Icaza. BUILD 2016의 기조 연설중에서

Miguel de Icaza는 당시 Ximian이라는 기업에서 Mono Project를 진행하고 있었지만, 이 회사는 2003년에 Novell에 인수 되었기 때문에 실질적으로 Mono 를 후원하고 있던 것은 Novell이라는 얘기가 된다. Novell에 인수 된 이후에도 Mono는 계속해서 발전했고,  Linux 이외의 플랫폼(MonoTouch for iOS, Mono for Android)을 지원하면서, Mono Project는 크로스 플랫폼 개발 환경으로서의 성격을 강화해 나가게 된다.

2011년 4월 Mono Project에 일대 전환기가 찾아오게 되는데, 지금까지 이 프로젝트를 지원하고 있던 Novell이 Attachmate라는 기업에 인수된 것이다. Attachmate사가 Mono Project를 진행하던 핵심 멤버들의 해고를 발표하면서 프로젝트의 존속 자체가 불투명해졌다.

Miguel de Icaza는 이듬해 5월에 새로운 회사인 Xamarin의 설립을 발표하고 Mono Project를 이어 간다고 발표했다. 이후 Mono의 라이센스 문제(Novell 소유)를 해소하고 하나의 개발소스로 모바일 크로스 플랫폼 개발이 가능한 Xamarin을 알려가고 있던 즈음 모바일 디바이스용 도구 제공에 뒤쳐져 있던 마이크로소프트가 Xamarin을 지원하면서 Xamarin은 많은 모바일 개발자들에게 어필되었다. 이후 올해 2월 마이크로소프트는 아예 Xamarin을 인수하는 행보를 보이게 된다.

흥미롭게도, 마이크로소프트는 스스로 커버 할 수 없던 공백을 수많은 오픈 소스 프로젝트를 후원하는 것(최근 사티아 나델라의 마이크로소프트는 리눅스 파운데이션의 플래티넘 멤버로 가입함)으로 차곡차곡 채워 나갔고 Mono Project는 현재까지도 마이크로소프트의 후원을 받으며 계속되고 있다.

Xamarin은 유용한 도구이지만, 실질적으로 무상으로 제공되고있는Visual Studio(Express)와 달리 유료 라이센스가 필요하다는 장애물이 존재하고 있었다. 하지만, 마이크로소프트는 BUILD 2016에서 Xamarin for Visual Studio을 무료로 제공하겠다고 발표했다.

Xamarin은 Visual Studio와 통합되어 개발 한 코드를 그대로 iOS 에뮬레이터를 사용하여 동작을 확인 할 수 있다.

Xamarin for Visual Studio의 무료 제공을 발표했다. Professional 과 Enterprise 버전외에 무료 버전인 Community Edition도 포함되어있는 것으로 발표되자 회장은 매우 들끓었다

왜 .NET Core가 필요한 걸까?

.NET 아키텍처 관점에서는 매우 쉽고 편리하지만, 작성된 응용 프로그램 배포에 큰 문제를 안고 있었다. 핵심 IL(Intermediate Language)로 작성된 응용 프로그램의 실행에 있어서는 런타임과 라이브러리를 필요로 한다. .NET Framework는 각각의 버전별로 계층화 된 라이브러리 스택으로 구성되어 있으며 . NET Framework에서 작성된 응용 프로그램은 실행에 필요한 라이브러리가 시스템에 종속되어야 한다.

응용 프로그램이 반드시 모든 라이브러리를 필요로 하고있는 것은 아니지만, 런타임 + 라이브러리의 재활용 문제가 Windows 이외의 플랫폼에서의 응용 프로그램 실행에서는 큰 문제가 된다. 예를 들어 모바일 장치에 응용 프로그램을 배포하기 위해서 장대한 라이브러리를 붙인 재배포 패키지를 통째로 준비해 둔다는 것은 넌센스이기 때문이다.

이와 같은 문제를 해결하기 위해 등장한 것이 .NET Core이다. 앞서 말한바와 같이 Windows PC 이외의 모바일 장치에 응용 프로그램 배포에서 IL뿐만 아니라 런타임이나 라이브러리를 포함한 완전한 실행 패키지로 제공하는 것이 일반적이다.

그러나 전체를 포함한 .NET Framework은 사이즈도 크고 실행 환경에서도 너무 무겁기 때문에 필요한 부분만을 패키징 할 필요가 있다. 이를 위해 .NET Framework에서도 코어가되는 부분만을 추출하여 런타임이나 라이브러리 재배포없이 패키지로 컴팩트하게 전달이 가능한 구조를 제공하는 것이 .NET Core이다. (자세한 사항은 여기를 참고)

.NET Core에 대해서 또 하나 주목할 만한 것이 바로 .NET Native구조다. 이는 일반적으로 중간 언어(IL)로 기술되어있다. .NET 응용 프로그램을 라이브러리내의 필요한 파일과 런타임을 병합하는 형태로 컴파일하고, 그 플랫폼에서 직접 실행 가능한 네이티브 애플리케이션으로 변환해 버린다. 기존의 .NET은 JIT (Just In Time) 방식의 컴파일러를 채용하고 있으며, 실행 단계에서 네이티브 코드로 변환되어 메모리로 떨어트린다. 반면 .NET Native는 AOT (Ahead Of Time) 방식의 컴파일러를 사용하고 JIT에서 발생하는 네이티브 코드 변환 페널티를 줄이면서 더 작고 빠르게 실행 가능한 코드를 생성 할 수있다.

.NET Core의 메리트

.NET Core의 장점은 크게 두 가지이다. 하나는 Windows PC 이외의 장치와 플랫폼에 애플리케이션 배포 지향적으로 이것은 크로스 플랫폼 개발에 적합하다고 할 수있다. 이것은 Windows 10의 공통 실행 환경인 Universal Windows Platform(UWP)에서도 마찬가지로 배포 패키지로써 .NET Core의 이용을 염두에 두고 있던 것 같다. 두 번째는 네이티브 코드를 AOT 방식으로 변환하므로써 기존의 .NET의 실행 환경과 비교해도 빠른 실행이 가능한 점으로, 특히 마이크로 서버등 특정 용도에 특화된 서버에서도 다수의 응용 프로그램을 실행하거나 대량의 요청을 처리하는 것에 적합하다. 이를 통해 .NET의 활용범위를 넓힐 수 있다.

.NET Core의 3가지 특징

.NET Core와 Xamarin의 공존

이미 눈치챘을 수도 있겠지만 .NET Core을 사용하는 이점은 용도적으로 Xamarin에 있다고 본다. .NET Core를 처음 발표 한 시점에 Xamarin은 마이크로소프트 산하에 없었기 때문에 추구하는 방향성이 중복되어도 큰 문제가 없었다. 하지만, Xamarin 인수를 통해 양자의 방향성 차이는 명확해졌다.

구체적으로는 서로 다른 장치(플랫폼)에 대한 대응을 전제로 한 응용 프로그램 개발의 경우, 개발 수단으로는 Xamarin을 사용하고, 이미 개발되어 있는 .NET 응용 프로그램을 특정 용도로 더 빠르게 수행 할 경우, 또는 ASP. NET과 같이 서버 측 응용 프로그램으로 빠른 실행을 기대하고 싶은 경우에는 .NET Core를 사용하므로써 수평 전개와 빠른 실행을 목적에 맞게 구분 할 수 있게 된다.

.NET Core와 Xamarin의 공존

다음 그림을 보면 이해할 수 있겠지만, UWP를 제외한 Windows 10은 .NET Framework과 UWP 또는 ASP. NET의 환경에는 .NET Core를 모바일 디바이스를 중심으로 한 크로스 플랫폼 개발은 Xamarin으로 구분되고 있다.

시나리오에 따른 구분 .NET의 개발 · 실행 환경이 구분되어 있다.

다만, 태생적으로 .NET Framework과 .Net Core 그리고 Xamarin은 서로간 응용 프로그램 개발 · 실행 환경에서 API를 포함하는 라이브러리의 완전한 호환은 실현되지 않고 있으며, 마이크로소프트는 이 같은 호환성 문제를 추후 .NET 표준 라이브러리로 공통화/체계화를 통해 해결하겠다고 한다. Xamarin을 인수하고 .NET Core도 정식버전을 발표한 가운데 마이크로소프트에서 제공하는 개발 · 실행 환경은 앞으로 이런 식으로 용도에 따라 구분되어 가고 있는 것으로 예측된다.

.NET Innovation 라이브러리가 완전히 일반화된다