[펌, 저장용] 2020년에 주목해야 할 5가지 마이크로소프트 개발자 툴과 기술

2020년이 막 시작된 지금이라도 애플리케이션 개발 계획과 기술 로드맵을 구상하기 위해 앞을 내다봐야 한다. 지난 몇 년 동안 마이크로소프트의 여러 플랫폼에서 애플리케이션을 구축하는 모든 사람에게 많은 변화가 일어났는데, 앞으로도 변화는 계속된다.
 

ⓒ Getty Images Bank 

2020년에는 무엇을 주목해야 하고 그 이유는 무엇인가? 윈도우와 애저를 비롯한 여러 분야의 5가지 옵션을 살펴보자. 이 5개가 전부는 아니지만 더 현대적인 개발 플랫폼과 툴 모음을 향한 길의 시작 지점이다.

 

닷넷 5로 전환 시작

닷넷 코드를 작성하는 모든 사람들이 직면하는 가장 큰 과제는 2020년 말에 닷넷 5 출시와 함께 시작될 오래된 닷넷 프레임워크에서 닷넷 코어로의 전환이다. 두 개의 닷넷 가지를 하나로 묶는 것은 일부 오래된 API를 잃는다 해도 타당한 조치다. 마이크로소프트는 닷넷 깃허브 리포지토리에 전환되는 요소와 전환되지 않는 요소의 목록을 작성해 올렸다. 빠진 API 중 일부는 커뮤니티 구현으로 전환되고 일부는 현대적인 대안으로 대체된다.

닷넷 프레임워크 코드를 지원하고 개발하는 이들에게 2020년은 미래에 코드가 전달되는 방법을 탐색할 좋은 기회가 된다. 현재의 닷넷 코어 3.1 릴리스는 장기 지원 버전이며, 닷넷 스탠다드 라이브러리와 함께 닷넷 5에 포함될 많은 API를 지원한다. 닷넷 코어 3.1로 코드를 이식하면 코드에서 무엇을 변경해야 하는지 탐색할 수 있을 뿐만 아니라 새로운 툴체인을 구축할 기회도 얻을 수 있다.

닷넷 코어의 미래는 ASP.NET과 레이저(Razor)를 통한 웹어셈블리(WebAseembly)와 서버 측 블레이저(Blazor), 윈도우, 맥OS, 리눅스의 닷넷 코어, 모바일 디바이스의 자마린(Xamarin)으로 구성되는 크로스 플랫폼이다. 코드를 닷넷 5로 전환하면 미래의 윈도우 릴리스를 지원할 수 있을 뿐만 아니라 훨씬 더 많은 플랫폼과 사용자에게 코드를 제공할 기회도 얻을 수 있다.

 

WinUI 3.0 탐색 시작

2020년에는 윈도우 플랫폼에 변화가 일어난다. 마이크로소프트가 마침내 윈도우 SDK를 두 개로 나눠 OS 수준 기능은 그대로 두고 UI 구성요소를 WinUI로 분리한다. 향후 WinUI 3.0이 출시되면 OS와 다른 박자로 UI 구성요소를 제공할 수 있고 새로운 컨트롤이 나오는 대로 추가할 수 있게 된다. Win32와 WinForms 앱, 범용 윈도우 플랫폼(UWP) 애플리케이션에 사용할 수 있도록 윈도우 10 전반에서 지원된다.

또한 WinUI는 우노 플랫폼(Uno Platform)과의 파트너십을 통해 새로운 크로미엄 기반 엣지와 같은 현대 브라우저에서도 지원된다. 우노 플랫폼은 웹어셈블리로 컨트롤을 이식해 WinUI가 훨씬 더 넓은 사용자층에 도달할 수 있게 해준다. 기존 UWP 애플리케이션은 최소한의 변경으로 WinUI 3.0을 사용할 수 있으며 C++ 코드는 새로운 컨트롤을 사용해서 마이크로소프트의 플루언트(Fluent) 디자인 언어 지원을 추가한다.

 

클라우드 네이티브 애플리케이션에 AKS 사용

현대식 클라우드 애플리케이션을 구축한다는 것은 분산 마이크로서비스 기반 애플리케이션을 구축하고 필요할 때 필요한 곳에 컨테이너화된 코드를 배포하고 수요에 대응해 리소스를 관리하는 것을 의미한다. 이를 위해서는 확장과 배포를 관리할 오케스트레이터가 필요하다. 직접 쿠버네티스를 구현해서 요체인 kubectl과 YAML 구성 파일을 다룰 수도 있다. 그러나 애저에 대안이 있다. 리눅스와 윈도우 컨테이너용 애저 쿠버네티스 서비스를 사용한 관리형 옵션이다.

이는 익숙한 애저 포털을 사용해서 컨테이너화된 애플리케이션과 서비스의 배포를 간소화해주고, 애저의 자체 네트워킹 기능, 해시코프(HashiCorp)의 테라폼(Terraform)과 같은 툴과 연계 작동하는 기능을 이용할 수 있게 해준다. 그 외의 옵션으로는 리소스 액세스를 잠가 보안 노출을 줄이기 위한 역할 기반 액세스 제어 등이 있다.

AKS(Azure Kubernetes Service)는 자동으로 쿠버네티스 클러스터를 확장하고 축소하며, 서비스 운영을 면밀히 관찰할 수 있도록 애저의 모니터링 툴과 통합된다. 그 결과는 세부적인 제어를 위해 쿠버네티스 툴로 관리할 수 있는 순수 쿠버네티스 플랫폼과 다른 애저 서비스에 대한 관리되는 액세스 권한이 있는 익숙한 애저 포털의 결합이다. 이 서비스 통합으로 예를 들어 영구 데이터를 위한 애저 스토리지 직접 액세스, 애저의 자체 컨테이너 레지스트리 지원 등으로 쿠버네티스 작업을 간소화할 수 있다.

애저에서 쿠버네티스 애플리케이션을 구축하는 경우, 특히 애저 데브 스페이스(Dev Spaces)와 같은 서비스를 고려한다면 사실상 대안이 없다. AKS, 데브 스페이스를 기반으로 구축하면 프로덕션 서비스에 영향을 미치지 않으면서 클라우드 네이티브 코드를 구축, 테스트, 디버깅하기 위한 안전한 비공개 환경을 이용할 수 있다.

 

WSL 2와 도커로 노트북에서 클라우드 개발

얼마 전만 해도 개발자 이벤트라고 하면 어디서든 애플 로고밖에 보이지 않았다. 그러나 마이크로소프트가 개발자들을 다시 윈도우로 되돌리기 위해 노력하면서 파이썬과 같은 인기있는 언어에 대한 빠른 접근, 비주얼 스튜디오 코드의 맞춤설정하기 쉬운 프로그래머 편집기, 새로운 윈도우 터미널, 그리고 무엇보다 중요한 리눅스용 윈도우 서브시스템(WSL)을 제공한 결과 지금은 훨씬 더 다양해졌다.

WSL은 처음에는 리눅스 커널을 에뮬레이션했지만 곧 윈도우와 나란히 실행되는 자체 리눅스 커널로 업그레이드됐다. WSL 2에는 PC에서 손쉽게 클라우드 애플리케이션을 구축하고 테스트할 수 있도록 윈도우에서 액세스할 수 있는 리눅스 파일 시스템, 비주얼 스튜디오 코드를 사용한 원격 편집 지원도 포함된다. 도커는 WSL 2용 도커 데스크톱 버전 테스트를 시작했다. 윈도우에 네이티브 리눅스 컨테이너 지원을 추가해 익숙한 도커파일을 사용해 로컬 컨테이너 인스턴스를 구축, 배포하고 코드(Code)를 사용해 내용물을 직접 다룰 수 있게 된다.

윈도우, 리눅스, 도커의 결합은 강력한 엔드 투 엔드 개발 툴 모음을 구성하기 위한 유연한 기반을 제공하므로 각 플랫폼을 온전히 활용하고 일반적인 리포지토리에 계속 코드를 제공하면서 자신이 원하는 방식대로 유연하게 작업할 수 있다.

 

애저 스피어로 IoT 보호

애저 스피어(Azure Sphere)를 마지막으로 살펴본 후 시간이 꽤 지났다. 애저 스피어는 안전한 IoT를 위한 마이크로소프트 플랫폼이다. 하드웨어 기반 보안과 맞춤형 리눅스 커널, 클라우드에 호스팅되는 관리 플랫폼을 혼합해 하드웨어에서 실행 중인 운영체제와 애플리케이션의 변조를 차단하고 악의적 서드파티가 코드를 변경 또는 삽입할 수 없도록 한다.

보안 ARM 마이크로컨트롤러를 사용하는 마이크로소프트의 개발 보드는 오래 전부터 있었는데, 최근에는 더 값싼 여러 대안이 등장했다. 프로덕션급 모듈과 SOC의 등장으로 직접 하드웨어를 만들 수 있으므로 이제 애저 스피어를 제품에 사용할 준비가 됐다. 새로운 개발 툴은 필요 없다. 모든 애저 스피어 개발은 익숙한 비주얼 스튜디오에서 이뤄진다.

한 가지 흥미로운 개발 분야는 기존 산업용 컨트롤러와 함께 작동해서 PLS 및 기타 기존 산업 시스템과 애플리케이션을 통합할 때 보호 계층을 추가하고 과거에는 IoT에 추가하기에 너무 위험하다고 간주된 디바이스를 연결할 수 있게 해주는 스피어 기반의 가디언 유닛이다. editor@itworld.co.kr 

원문보기:
http://www.ciokorea.com/news/140676#csidx65016a3bdd78d4a8494ec740447fee8 

 

닷넷 프레임워크와 닷넷 코어가 드디어 융합이 되는구나.