2016 빌드 컨퍼런스는 뜨거운 이슈가 없어 보였는데, 소리없이 커다란 관심을 끈 이슈가 하나 등장했다. MS가 캐노니컬과 협력하여 윈도우에 우분투(Ubuntoo) 서브시스템을 탑재한다는 것이 바로 그것이다.
사실, 윈도우는 유닉스 호환 운영체제다. 더 정확하게 말한다면 POSIX 표준을 준수하는 유닉스 호환 운영체제지만, POSIX 자체가 매우 낡은 표준이기 때문에 현대적인 유닉스와의 호환을 제공하는 것은 아니다. 특히, 유닉스 그 자체를 의미할 정도로 유닉스 시장을 장악한 리눅스의 성격을 생각한다면 더욱 그렇다. 여튼, 지금까지 윈도우는 생색 내기 수준의 유닉스 호환 기능을 제공해 왔다. 사용자 편의가 중요한 일반 데스크탑 시장에서는 여기에 신경 쓸 이유가 없지만, 서버 시장이나 개발자 관점에서 본다면 이것은 매우 중요한 부분이다. 당신이 인정하든 그렇지 않든, 유용한 소프트웨어 대부분은 유닉스의 '모든 것은 파일 스트림이다'라는 메타포를 중심으로 작성되었으며, 이것의 반증을 찾기 위한 대부분의 여정은 이 명제의 정당성만 공고히 했을 뿐이다. 이 메타포 위에서 발전하고 검증된 소프트웨어를 윈도우에서 사용하는 것은 제약이 많았다. 그러나, 우분투 서브시스템 탑재로 이 상황은 혁명적으로 바뀌었다.
유닉스 소프트웨어를 윈도우에서 구동하자고 한다면, 3가지 방법이 있다. 첫번째, 소스 차원에서 윈도우용으로 재작성한 빌드를 사용한다. 소스 차원의 수정이 필요하므로 많은 시간이 필요하고, 완전히 동일한 기능을 제공하지 않을 수도 있다. 두번째, CygWin을 사용한다. CygWin은 자체적으로 유닉스 시스템콜 호환 레이어를 제공하며, CygWin 환경에서 소스를 재컴파일하기만 하면 왠만한 소프트웨어는 그럭저럭 윈도우 위에서 구동할 수 있다. 그러나, CygWin의 호환 레이어는 윈도우의 생색내기 POSIX 호환에 기반하고 있기 때문에 해당 소프트웨어의 동일한 동작을 보장하지 못한다. 마지막으로 MSYS가 있는데, MSYS는 Minimal GNU for Windows 프로젝트에서 파생한 것으로, 유닉스와의 호환성보다는 윈도우에서의 성능을 고려한 환경이다. 즉, 유닉스 인터페이스는 동일하지만, 특정 인터페이스는 윈도우 네이티브 API를 사용하여 다르게 구현된다.
불행한 것은, 이 방법 중 하나만으로는 모든 경우에 대응하기 불가능하기 때문에 거의 필연적으로 이 3가지 방법을 모두 준비하고 있어야 한다는 점이다. 특정 소프트웨어들의 윈도우용 빌드, CygWin 빌드, MSYS 빌드의 상호 운용성이 좋지 못하다는 것은 덤이다. 이 문제 때문에, 요즘 오픈 소스 위에서 개발되는 소프트웨어 프로젝트들은 처음부터 윈도우 지원을 크게 신경 쓰지 않거나, 지원하더라도 그 방법이 복잡하고 까다롭다.
새로 추가될 윈도우의 우분투 서브시스템은 CygWin처럼 시스템콜을 에뮬레이션하는 것이 아니라, 서브시스템 차원에서 시스템콜을 구현한다. 따라서, 유닉스 소프트웨어를 윈도우 환경에서 실행할 때 필연적으로 발생할 수 밖에 없는 한계가 훨씬 줄어든다. 문제는 우분투 서브시스템이 얼마나 유닉스 시스템콜을 잘 구현하여 윈도우와 연결해주느냐에 달려 있다. 성능에 중점을 둔다면 윈도우 전용 설계를 해야겠지만, 그럴 필요가 없는 소프트웨어들은 단순히 우분투 서브시스템을 사용하면 된다. 즉, 가급적 하나의 인터페이스로 소프트웨어를 개발하기 때문에 관리가 엄청나게 단순해진다. 다른 환경 때문에 수없이 중복 패키지를 설치해왔다면, 이제 이런 낭비를 할 필요가 사라졌다.
우분투 서브시스템은 다음 윈도우 업데이트인 레드스톤에서 릴리즈 될 예정이다. 구시대의 유물인 DOS 커맨드 프롬프트 대신 bash를 사용하는 것은, 하나의 시대가 완전히 바뀌었다는 것을 상징적으로 보여주는, 매우 매력적인 부분이다.
