마이크로소프트가 최근 빌드(Build) 컨퍼런스에서 리눅스용 윈도우 서브시스템(Windows Subsystems for Linux, WSL)의 두 번째 버전을 소개했다. 초기의 WSL 개념을 대대적으로 수정한 이번 버전은 리눅스 시스템 호출을 윈도우로 번역하는 수준에서 벗어나 윈도우 자체 커널과 함께 실행되는 온전한 리눅스 커널로 발전했다.

변화의 이유는 많지만 가장 큰 이유는 단순하다. 1년에 두 번 출시되는 에뮬레이터로 리눅스 커널의 변화, 리눅스 바이너리가 의존하는 변화를 따라잡기는 불가능하다는 점이다. 윈도우가 클라우드용 리눅스 앱을 구축하는 개발자를 지원하고자 한다면 일관성만으로는 부족하고 호환성을 확보해야 한다.

WSL 2 소개

WSL 2의 성격을 결정지은 중요한 요인은 두 가지다. 첫 번째는 마이크로소프트가 윈도우의 격리 계층으로 하이퍼-V 가상화 툴을 사용하는 데 초점을 두면서 하이퍼-V를 범용 하이퍼바이저 서비스로 만들고 있다는 점이다. 두 번째는 도커, LCOW라고 하는 윈도우 리눅스 컨테이너(Linux Containers on Windows)와의 긴밀하게 연관된 협업이다.

시작은 LCOW다. LCOW는 윈도우 서버에서 리눅스 앱이 포함된 도커 컨테이너를 실행하기 위해 하이퍼-V를 사용해서 씬(thin) 리눅스 커널을 호스팅한다. 마이크로소프트는 LCOW를 윈도우 개발 툴(특히 비주얼 스튜디오 코드의 새로운 원격 개발 기능)에서 액세스가 가능한 환경, 컨테이너가 마치 네이티브 윈도우 코드처럼 작동하는 환경으로 만들기 위해 많은 노력을 기울였다. 

네이티브에 근접한 성능의 근원은 윈도우 10의 핵심 보안 기능이라는 하이퍼-V의 새로운 역할을 지원하기 위해 구현된 하이퍼-V의 변화에 있다. 새로운 격리된 로그인 화면 프로세스를 호스팅하거나 윈도우 디펜더 애플리케이션 가드에서 브라우저에 필요한 기능만 포함한 윈도우 커널을 실행하는 것은 하이퍼-V다. 또한 의심스러운 코드를 디버깅하거나 검사하는 용도로 가볍게 쓰고 버리는 윈도우 인스턴스인 윈도우 샌드박스의 기반 계층이기도 하다.

하이퍼-V 자체, 그리고 하이퍼-V가 새로운 시나리오에서 코드를 호스팅하는 방식 측면에서 대대적인 변화는 윈도우 스케줄러와의 통합이다. 이제 윈도우는 하이퍼바이저와 모든 호스팅되는 코드에 하나의 프로세스를 사용하는 대신 하이퍼바이저 플랫폼에 의해 호스팅되는 모든 프로세스를 관리하면서 표준 윈도우 애플리케이션처럼 자유롭게 실행되도록 할 수 있다.

이를 토대로 보면 LCOW가 어떻게 해서 WSL에 대한 새로운 접근 방식의 기반이 되고 마이크로소프트에 의해 유지되는 전체 리눅스 커널을 호스팅하고 이전 WSL과 동일한 리눅스 배포를 지원하는지 어렵지 않게 이해할 수 있다. 프리뷰 릴리스는 패스트 링(Fast Ring) 채널을 통해 받을 수 있는 윈도우 인사이더 빌드 20H1 시리즈에 포함된다.

이제 WSL 2에는 자체 파일 시스템이 있다. 9P 프로토콜을 사용하는 WSL의 가상 하드 디스크 스토리지(리눅스 네이티브 ext4 파일 시스템을 사용함)는 윈도우와 공유가 가능하다(CIFS를 사용해 리눅스가 포함된 윈도우와도 가능). 덕분에 비주얼 스튜디오 코드의 원격 개발 및 디버깅 기능을 리눅스 툴체인의 일부로 윈도우 UI를 통해, 코드는 리눅스에서 실행되는 형태로 사용할 수 있다.

두 번의 WSL 릴리스 사이에서 많은 부분이 바뀌었다. 개발자에게 가장 눈에 띄는 부분은 WSL 2에는 자체 루트 파일 시스템이 있다는 점이다. 이제 모든 리눅스 파일을 자체 루트에 저장해야 하며 이를 통해 파일 액세스 속도가 훨씬 더 빨라진다. 윈도우의 9P 지원 덕분에 윈도우에서 새로운 리눅스 파일 시스템에 직접 액세스할 수 있다는 점도 유용하다. 윈도우 탐색기 또는 비주얼 스튜디오 코드와 같은 툴을 리눅스 셸에서 실행해서 리눅스 파일에 직접 액세스할 권한을 부여할 수 있다.

WSL 2 시작하기

WSL 2를 사용하기 위해 새로운 WSL 리눅스 배포판이 필요한 것은 아니다. 먼저 파워셸 또는 윈도우 기능 제어판에서 20H1 윈도우 인사이더 릴리스에 포함된 새로운 가상 머신 플랫폼 기능을 활성화하고, 역시 같은 툴을 사용해 WSL을 활성화하면 된다. 이렇게 하면 WSL 1과 WSL 2 지원이 모두 설정된다.

윈도우 스토어에서 원하는 WSL 리눅스 배포판을 선택한다. 설정하고 배포판의 압축을 풀고 사용자 계정을 추가하면 WSL 2에서 작동하도록 변환할 수 있다. 마이크로소프트는 배포판 관리에 도움이 되도록 윈도우에 새로운 wsl 명령 집합을 추가했다. 먼저 wsl -l -v 명령으로 설치된 배포판 목록과 각각의 WSL 버전을 확인한다. WSL 1에서 WSL 2로 변환하려면 wsl –set-version <distroname> 2 명령을 사용한다. 다시 되돌리려면 같은 명령을 버전 번호만 1로 바꿔서 실행하면 된다.

WSL 2에서 리눅스 배포판을 실행하는 방법은 WSL 1에서 실행하는 방법과 동일하다. 명령줄에 이름을 입력하거나 시작 메뉴에서 실행하면 된다. 현재 윈도우 스토어에서 베타 버전으로 제공되는 새로운 오픈소스 윈도우 터미널과 WSL 2를 마이크로소프트가 향후 어떻게 통합할 지도 흥미롭게 지켜볼 부분이다.

WSL 네트워킹의 변경 사항

윈도우에서 리눅스를 사용하는 방법이 가상화 기반 접근 방식으로 변경되면서 리눅스 기반 네트워킹 앱 액세스 방법도 바뀌었다. WSL 1에서는 모두 같은 네트워크에 속했지만 WSL 2에서는 리눅스 환경에 자체적인 동적 IP 주소가 부여된다. 초기 릴리스에서 이는 VM의 IP 주소를 사용해서 서비스에 연결해야 한다는 것을 의미했다.

마이크로소프트는 이 과정을 간소화하기 위해 작업 중이며 초기 WSL 2 릴리스의 최신 업데이트에서 이 문제를 다루기 시작했다고 밝혔다. 윈도우에서 WSL로의 localhost 기반 네트워킹에 대한 지원이 추가되고 컨테이너에서 호스팅되는 애플리케이션과 기타 리눅스 서비스에 액세스하기가 간편해진다. 그러나 여전히 단방향이므로 DISPLAY 변수를 동적으로 설정하는 스크립트를 사용하지 않는 한 X 기반 애플리케이션은 사용할 수 없다.

자신의 리눅스 커널 사용하기

최신 릴리스에서 가장 큰 변화라고 할 만한 점은 마이크로소프트 커널 대신 사용자 자신의 리눅스 커널을 사용할 수 있는 기능이다. .wslconfig 파일의 커널 옵션을 사용해 시작 시 로드될 커널의 경로를 설정하면 된다. 자기만의 맞춤형 커널을 사용하거나 WSL을 사용해 임베디드 시스템 애플리케이션을 개발하거나 클라우드에서 호스팅되는 코드를 개발할 수 있다. 개발과 테스트를 위한 풍부한 유연성이 제공된다. 예를 들어 코드 개발에는 장기 지원 커널을 사용하고 테스트에는 클라우드 제공업체의 쿠버네티스 환경에 사용되는 커널을 사용할 수 있다.

새로운 접근 방식에는 기존 개발 환경에 영향을 미칠 수 있는 한 가지 중요한 문제가 있다. 하이퍼-V는 상당한 저수준 툴로, 윈도우 아래에 위치한다. 다른 가상화 툴은 새로운 하이퍼-V API를 지원하지 않는 한 WSL 2를 호스팅하는 시스템에서 실행되지 않는다. 마이크로소프트는 최신 버추얼박스 릴리스 또는 구글 안드로이드 에뮬레이터 등 하이퍼-V와 호환되는 하이퍼바이저로 전환할 수 없는 사용자를 위해 기존 WSL을 그대로 둘 것이라고 밝혔다. 

새로운 WSL 명령줄 툴을 사용하면 특정 배포판 릴리스를 실행할 버전을 관리할 수 있게 된다. 예를 들어 펭귄 리눅스는 WSL 2에서 실행하고 우분투 릴리스는 WSL 1에서 실행할 수 있다.

결론 

WSL 2를 테스트한 지난 몇 주는 흥미로운 시간이었다. 여러 리눅스 플랫폼 사이에서 전환하는 과정이 쉬워졌고, 전체 리눅스 커널이 있으므로 호환성에 대해 걱정할 필요도 없어졌다. 또한 추가 하이퍼바이저 계층이 필요없는 완전한 네이티브 리눅스 컨테이너라는 보너스도 있다. 비주얼 스튜디오 코드의 새로운 기능이 WSL 가상 머신까지 개발 환경을 넓혀준다.

딱 한 가지 문제는 WSL 2가 20H1 윈도우 10 릴리스의 일부로 개발되고 있는 만큼 프로덕션에 사용하려면 2020년 5월까지 기다려야 한다는 점이다. 하지만 데스크톱에서 리눅스의 해를 위한 날짜가 정해졌다는 것만 해도 의미있는 일이다.