리눅스용 윈도우 서브시스템 사용하기

필자는 어제 커피숍에 앉아서 윈도우 개발용 PC에 리눅스 배포판 2개를 설치했다. 가상 머신도 듀얼 부팅 시스템도 아니었고, 다운로드 페이지를 찾아 설치 파일 압축을 푸는 일반적인 과정도 거치지 않았다. 윈도우 스토어에 가서 리눅스를 검색하고 원하는 배포판을 선택한 다음 각각 설치하기를 클릭했을 뿐이다. 다운로드가 된 다음에는 터미널 창을 열고 사용자 이름과 암호를 추가하는 게 끝이었다.

이렇게 설치할 수 있었던 것은 리눅스용 윈도우 서브시스템(Windows Subsystem)에 새로운 기능이 추가된 윈도우 10 크리에이터스 업데이트의 최신 프리뷰 버전을 사용했기 때문이다. 윈도우 10 1주년 업데이트(버전 1609)에 처음 도입되고 최근 릴리즈된 윈도우 10 크리에이터 업데이트(버전 1703)에서 대폭 업데이트된 WSL은 마이크로소프트가 “개발자들을 다시 윈도우로 끌어오려면 어떻게 해야 하는가?”라는 질문 끝에 내놓은 답이다.



마이크로소프트가 개발자를 윈도우로 끌어오는 방법
 “개발자들을 다시 윈도우로 끌어오려면 어떻게 해야 하는가?”에 대한 답은 간단했다. 개발자들이 모이는 곳으로 가면 된다.

그러나 윈도우로 그 답을 실현하기는 간단치 않았다. 개발자가 모이는 곳은 맥OS와 리눅스다. 이들은 명령줄 툴을 사용해 클라우드의 리눅스 서버에서 작업하며, 이미 도커(Docker), 깃허브(GitHub), 젠킨스(Jenkins), 앤서블(Ansible), 셰프(Chef), 트래비스CI(TravisCI)와 같은 서비스와 연계되는 툴 체인과 애플리케이션, 스크립트를 보유하고 있다. 이 개발자들을 어떻게 윈도우로 다시 데려올 수 있을까?

첫 단계는 익숙한 윈도우 데스크톱으로 유닉스를 매끄럽게 가져오는 것이었다. 맥OS는 맥의 터미널 앱을 통해 접근 가능한 BSD 유닉스의 마이크로커널 구현을 기반으로 하므로 본질적으로 유닉스 사용자에게 유리한 면이 있다.

그러나 윈도우의 NT 커널이 지향하는 방향은 달라서 DEC까지 거슬러 올라가며, 전통적으로 여러 가지 퍼스널리티를 실행할 수 있다. 익숙한 툴의 새 버전을 만들어서 이를 윈도우용으로 재컴파일하는 대신, 윈도우에서 직접 리눅스 바이너리를 실행하면 어떨까? 지금은 중단됐지만 마이크로소프트는 윈도우 폰과 윈도우 10의 피코 프로세스 모델을 위한 안드로이드 호환성 계층을 제공하기 위해 추진된 프로젝트 아스토리아(Project Astoria)의 성과를 사용, 리눅스 시스템 호출을 윈도우로 해석해 아무런 변경 없이 코드 실행이 가능한 새로운 OS 서브시스템을 만들었다.

우분투와의 협력으로 나온 첫 번째 릴리즈는 윈도우 터미널에서 실행되는 배시(Bash) 셸을 제공했다(cmd와 파워셸에서 모두 사용). 윈도우 인사이더용 첫 테스트 빌드는 당연히 제한적이었지만 윈도우 10 1주년 업데이트 출시일이 다가오면서 빠른 속도로 개선됐고, 복잡한 콘솔 애플리케이션도 실행할 수 있게 됐다. 또 툴과 서비스 라이브러리에 대한 신속한 접근을 위해 우분투의 apt-get 설치 프로그램도 지원했다. 크리에이터 업데이트에서 마이크로소프트와 캐노니컬은 우분투의 최신 장기 지원 릴리즈인 버전 16.04로 WSL을 옮기는 데 성공했다.

WSL : 리눅스 콘솔의 리눅스 바이너리
개발자 툴에 대한 셸 지원, 그리고 온프레미스 및 퍼블릭 공용 클라우드에서 실행되는 리눅스 서버 원격 접근 기능을 제공하는 WSL은 기술적으로는 콘솔 전용 애플리케이션이다. 그러나 뚜껑을 열고 보니 그보다 훨씬 더 유연한 것으로 드러났다. 공식적으로 지원되는 것은 아니지만 사용자들은 X 기반 GUI 애플리케이션을 설치해 실행하고 윈도우 X 서버를 사용해서 전체 리눅스 데스크톱 환경을 WSL로 가져왔다.

WSL 퍼스널리티를 사용한 작업은 네이티브 리눅스를 사용한 작업과 비슷하다. 셸에 접근할 수 있고 셸을 통해 명령줄에 접근할 수 있다. 애플리케이션 설치는 간단히 우분투에서 apt-get을 사용하거나 수세(Suse)에서 yast 및 zypper를 사용하면 된다. 나중에 페도라가 윈도우로 오면 yum을 사용하면 된다.

초기 WSL 빌드에는 일부 애플리케이션 실행에 문제가 있었다. 핵심 종속성이 지원되지 않았기 때문이다. 그러나 윈도우 10 1주년 업데이트 릴리즈 이후에는 과정이 훨씬 더 쉬워졌고, 이제는 도커와 같은 복잡한 패키지도 설치하고 실행할 수 있다.

물론 이것, 즉 PC에서 크로스 플랫폼 개발과 관리를 하기 위해 필요한 툴을 가져오는 것이 바로 WSL의 핵심이다.

올 하반기 윈도우 서버에 네이티브 리눅스 컨테이너가 구현되면 WSL은 엔터프라이즈 시스템 툴셋에서 더욱 중요한 핵심 구성 요소가 될 것이다. 사실 개발 및 운영 윈도우 PC에 이미 일상적으로 설치가 가능하다. (윈도우 서버의 WSL은 대규모 리눅스 워크로드 또는 서버를 지원하지 않지만 호스팅되는 리눅스 컨테이너에 대한 직접 관리 연결을 제공하고 기존 관리 스크립트와 툴을 지원한다.)

리눅스와 윈도우 툴 체인을 통합하는 방법
마이크로소프트는 WSL에서 윈도우로, 윈도우에서 WSL로 이동하기 쉽게 했다. 윈도우 명령줄에서 WSL 기본 사용자를 사용해 리눅스 바이너리를 호출할 수 있고 배시에서 윈도우 바이너리를 호출할 수 있다. (또한 비주얼 스튜디오 코드 내의 터미널에서 배시에 접근할 수 있으므로 개발 툴을 나오거나 윈도우를 나오지 않고도 유닉스 코드를 테스트할 수 있다.)

팁을 하나 이야기하자면, WSL은 윈도우 디렉터리를 마운팅된 파일 시스템으로 취급하므로 일반적으로 사용되는 파일에 symlink를 설정하거나, 배시 경로에 윈도우 프로그램 파일 디렉터리를 추가하면 좋다.

비주얼 스튜디오 코드와 같은 툴이 WSL을 지원하는 것은 반가운 흐름이다. 개발자가 모이는 곳에 윈도우 플랫폼을 정착시키는 데 성공하려면 툴이 윈도우의 리눅스 퍼스널리티와 직접 호환되어 윈도우와 리눅스의 장점을 모두 누릴 수 있는, 일종의 하이브리드 작업 방식을 제공해야 한다. 추후에 발표될 비주얼 스튜디오 풀 버전에서 리눅스 터미널을 호스팅하고, WSL 내에서 실행되는 서비스에 대해 webhook 및 기타 API를 호출하는 모습도 충분히 상상할 수 있다.

윈도우가 실행되는 리눅스 배포판 확대
리눅스용 윈도우 서브시스템은 최근 기존 우분투 릴리즈와 함께 실행되는 두 개의 새로운 리눅스 배포판, 오픈수세(OpenSuse)와 수세 엔터프라이즈 서버(Suse Enterprise Server)가 릴리즈되면서 그 범위를 한 단계 더 넓혔다. 두 수세 릴리즈 모두 윈도우 스토어에 있으며 인사이더 프로그램 사용자라면 이용할 수 있다.

리눅스 변형이 추가되는 것은 좋은 일이다. 우분투 방식을 좋아하지 않는 사람도 있다. 수세, 그리고 곧 페도라까지 WSL에 참여하는 만큼 좀더 유연하게 자신에게 익숙한 작업 방식으로 리눅스 툴과 서비스를 사용하고 기존 툴 체인에서 윈도우 PC로 스크립트와 바이너리를 가져올 수 있게 된다. WSL은 동시에 여러 개의 리눅스 퍼스널리티를 각기 별도의 터미널에 호스팅할 수도 있다.

여러 리눅스 배포판을 지원하는 것은 합리적인 전략이다. 지난 몇 년 동안 여러 업체와 팀이 여러 사용례에 집중하면서 동일한 가상 파트 킷으로 서로 다른 플랫폼을 구축했다. 페도라, 우분투와 같은 오래된 배포판은 범용 운영체제에 가깝고 개발자 관점에서는 이러한 운영체제를 사용하는 편이 합리적이다. 흥미로운 부분은 미래의 WSL이 컨테이너에 집중하는 코어OS(CoreOS)와 같이 전문화된 릴리즈에 대한 지원 폭을 넓힐지 여부다.  editor@itworld.co.kr