닷넷의 LTS(Long Term Support) 다음 버전의 첫 프리뷰가 공개됐다. 닷넷 10은 이전의 짝수 릴리스와 마찬가지로 현재 단기 릴리스에 도입된 기능을 기반으로 성능과 안정성 개선에 중점을 둔다. 닷넷 10은 3년 동안 지원되므로 현재 프로덕션에 있는 모든 닷넷 8 코드라면 당연히 업데이트하는 것이 합리적이다.

프리뷰 조기 출시는 기존 코드가 새로운 런타임으로 어떻게 변환되는지 확인할 수 있는 시간을 주고 새로운 언어와 SDK 기능을 경험할 수 있는 기회도 된다. 장기 지원 릴리스 간의 2년이라는 간격은 새로운 기술과 툴이 성숙해지고 개발자가 현재 구축하는 애플리케이션에 맞춰 준비하기에 충분한 시간이다.

닷넷 런타임 개선

이번 릴리스 주기에서 닷넷팀이 초점을 둔 영역 중 하나는 기반 닷넷 런타임이다. 런타임은 코드가 해석되고 컴파일되는 방식이므로 애플리케이션 성능에 있어 중요하다. 특히 닷넷이 이제 ARM64를 포함한 여러 프로세서 아키텍처를 지원하는 만큼 런타임의 JIT(Just-In-Time) 엔진 효율성이 높아지면 코드의 속도도 빨라진다. 이와 동시에 런타임에는 x64의 새로운 명령어에 대한 지원이 필요하다. 인텔과 AMD는 새로운 사용례에 필요한 새로운 정수 및 부동소수점 유형과 함께 보안 기능을 추가하면서 이 부분을 계속 발전시키고 있다.

여기서 핵심 요구사항 중 하나는 일반적으로 사용되는 언어 기능이 런타임 기능에 직접 매핑되지 않는 코드와 런타임 간의 추상화를 줄이는 것이다. 닷넷 런타임 개발 프로세스 내에 이를 제공하기 위해 진행 중인 프로젝트가 있다. 큰 작업이며, 팀은 닷넷 10의 특정 하위 집합 작업에 집중하고 있다. 작업의 대부분은 배열에서의 닷넷 작동 방식에 중점을 둔다.

이 부분에는 많은 개선이 필요하다. 배열의 합계를 구하는 코드를 작성할 때, 정적 배열에 대한 직접적인 접근과 인터페이스를 사용해 동일한 작업을 관리하는 방식을 비교하면 인터페이스를 사용하는 것이 더 나은 방법이긴 하지만 속도는 직접 접근이 인터페이스를 사용하는 방식보다 4배 이상 빠르다. 인터페이스의 추상화를 배열에 추가하면 컴파일러가 인터페이스의 가상화를 해제할 수 없고, 따라서 올바른 JIT 코드를 생성하기 위해 여러 작업이 추가되기 때문이다.

앞선 닷넷 릴리스에서는 성능 개선과 함께 추상화에 따르는 오버헤드를 줄이기 위한 구성요소가 추가됐다. 이를 통해 닷넷 10은 마침내 배열 인터페이스의 가상화를 해제해 JIT가 코드를 최적화할 수 있도록 했다. 아직 해야 할 일이 남아 있지만, 중요한 개선이다.

차세대 반도체 지원

곧 출시될 새로운 x64 명령어, 구체적으로 AVX 10.2를 위한 다른 컴파일러 수준 기능도 있다. 이를 통해 AI부터 웹어셈블리와 암호화에 이르기까지 광범위한 작업에 걸쳐 중요한 새로운 프로세서 기능이 추가된다. 현재 벡터 처리에 대한 소프트웨어의 의존도가 계속해서 더 높아지는 가운데 이러한 새로운 기능이 지원되면 닷넷 코드의 작동 효율성이 더 높아질 수 있다. 다만 이와 같은 새로운 기능을 지원하는 반도체는 아직 개발 중인 상태이므로 프로세서 출시에 맞춰 지원할 준비는 돼 있지만 지금은 비활성화된 상태다.

3년의 지원 기간을 감안하면 이와 같은 기능을 조기에 닷넷에 내장하는 것이 여러모로 합리적이다. 마이크로소프트는 하드웨어가 준비되면 닷넷 런타임을 크게 변경하지 않고도 이런 기능을 활성화할 수 있다. 또한 마이크로소프트는 외부 출시에 앞서 자체 연구실의 샘플 하드웨어에서 성능을 평가할 수 있다.

ASP.NET 코어 다시 연결하기

닷넷 플랫폼은 프로그래밍 언어 이상의 훨씬 더 많은 내용을 포괄한다. 닷넷은 온프레미스와 클라우드, 여러 운영체제에 걸쳐 사용되는 플랫폼이다. 대부분의 플랫폼 기능은 닷넷 어스파이어(Aspire), ASP.NET 코어와 같은 툴에서 제공된다. 어스파이어의 닷넷 10 기능 모음은 아직 개발 중이다. 어스파이어 9.1은 닷넷 10의 첫 프리뷰와 같은 시점에 출시됐지만 여전히 닷넷 8과 9를 주 대상으로 한다.

ASP.NET 코어는 단순히 웹 애플리케이션 개발을 넘어 닷넷에서 API와 마이크로서비스를 구축하고 제공하기 위한 가장 적합한 플랫폼으로 부상했다. 시그널R(SignalR)과 같은 기술은 실시간 데이터를 지원하고, 마이크로서비스를 위한 최소 API를 명확한 지침에 따라 제공할 수 있는 방법을 제시한다. 마이크로서비스 역시 풀스택 블레이저(Blazor) 프레임워크의 일환으로 많은 닷넷 기반 웹어셈블리 작업을 ASP.NET 코어에서 진행하고 있다.

블레이저는 닷넷 10에서 대대적인 업데이트를 받아 최신 콘텐츠 전송 네트워크에서 사용할 준비가 됐으며 웹 애플리케이션의 부하를 줄여준다. 정적 자산 전달 기능은 꽤 오래전부터 ASP.NET 코어에 포함된 기능인데, 이제 블레이저 스크립트도 정적 자산으로 취급된다. 시그널R과 최소 API에 대한 업데이트는 이후 프리뷰 릴리스에서 제공될 예정이며 아직 문서화되지 않은 상태다.

API 자동 문서화

클라이언트 애플리케이션 개발에서 오픈API의 중요성이 커지면서 ASP.NET 코어 기반 API 버전이 오픈API 3.1.1로 상향됐다. 이를 통해 ASP.NET 코어에서 오픈API 문서를 생성하는 방식이 변경되고 JSON 스키마 사양의 업데이트된 버전이 지원된다. 이 버전 업그레이드는 의무 사항은 아니다. 기본 라이브러리에 중대한 변경 사항이 있으므로 이전 버전을 선택할 수 있다.

예를 들어 API 정의에서 문서를 생성할 때 오픈API 콘텐츠를 다루기 위해 자체 변환기를 사용하고 있다면 오픈API 클래스에서 JsonNode로 전환해야 한다. 이렇게 하면 작업이 간단해진다. 이전에는 OpenApiInteger 또는 OpenApiString을 사용해야 했던 부분에서 이제는 간단한 정수와 문자열을 사용할 수 있기 때문이다.

이제 JSON이 아닌 YAML 형식으로 오픈API 문서를 전달할 수 있다. 이 기능은 아직 완성되지 않았지만(지금은 동적 콘텐츠에 대한 오픈API 엔드포인트만 지원) 향후 프리뷰에서는 빌드 시점에 YAML 문서를 만들 수 있게 될 것이다. YAML 문서는 사람이 읽기 쉽고 JSON 문서보다 크기도 작으므로 가능하면 YAML 문서를 사용하는 것이 좋다.

개발자 생산성 개선

닷넷 플랫폼의 라이브러리 및 기타 구성요소는 아직 개발 주기의 초기 단계에 있으며 각 프리뷰 릴리스마다 새로운 기능이 적용될 것으로 예상된다. 설명서를 보면 눈에 띄는 몇 가지 기능이 있다.

필자가 오래전부터 원했던 기능은 알파벳 순서뿐만 아니라 숫자 기준으로도 문자열을 정렬하는 방법이다. 새로운 numericStringComparer 연산자를 사용하면 코드에서 “Airbus A320”, “Airbus A319”, “Airbus A321”을 구별해 올바른 순서로 배치할 수 있다. 이전에는 여러 문자열 비교와 변환이 필요한 복잡한 작업이었지만, 이제는 코드 한 줄로 가능하다.

이와 같은 작은 업그레이드와 닷넷의 개선된 zip 아카이브 지원에는 많은 이점이 있다. 개발자의 작업이 조금 더 편해지면 모든 사람이 버그가 적고 더 좋은 코드를 받게 된다. 애초에 간단했어야 할 작업을 더 이상 코드로 우회할 필요가 없기 때문이다.

닷넷 컨프(.NET Conf)에서 최종 릴리스가 나오기까지는 아직 반년 이상 남았지만 닷넷 10이 제공하는 새로운 기능을 미리 살펴보는 것은 언제나 좋은 일이다. 이와 같이 공개적으로 플랫폼을 개발하면 개발팀들이 변경을 제안하거나 적용하기 전에 더 쉽게 실험해 볼 수 있다.

이번 첫 번째 프리뷰는 마이크로소프트가 계획한 전체의 일부만 보여줄 뿐이며, 앞으로 두 개 이상의 프리뷰 릴리스가 더 나올 예정이다. 예상대로 대부분의 기능은 닷넷 9의 더 안정적인 버전을 제공하는 데 초점을 두지만, 새로운 기능도 중요하다. 새로운 기능은 개발자가 요구하는 부분과 현대적 클라우드 네이티브 애플리케이션 및 데스크톱의 요구사항을 닷넷이 충족하도록 보장한다. 어려운 균형 잡기지만 닷넷 10은 해낼 준비가 된 것으로 보인다.
dl-itworldkorea@foundryco.com