가볍게 쓰려했던 WSL2가 무겁게 다가온 순간

국내 유명 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업들의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?

이번 글은 ‘전 세계 사람들에게 즐거움을 선사하자’는 비전을 바탕으로 게임을 만들고 있는 ‘넷마블’ 테크니컬 라이터의 이야기입니다. WSL2 환경을 세팅하며 겪은 고충에 대해 공유합니다.

안녕하세요, 저는 넷마블에서 테크니컬 라이터로 일하는 조병승입니다.

테크니컬 라이터는 보통 기술 문서를 다루는 직군이라고 간단히 정의할 수 있습니다. 단순히 기술 문서 작성 이외에도 할 수 있는 많은 일이 있습니다만, 이건 다음 기회에 전해드리겠습니다. 이번 글에서는 WSL2를 쓰면서 마주했던 몇 가지 이슈와 팁을 소개합니다.

기존에 쓰던 리눅스 환경은 주로 로컬 PC가 아닌, 퍼블릭 클라우드 VM이었습니다. 퍼블릭 클라우드에서는 큰 고민을 하지 않아도, 클릭 몇 번으로 리눅스 환경을 올릴 수 있었습니다. 당시에는 워드프레스 같은 패키지 설치는 주로 비트나미(Bitnami) 스택으로 세팅을 했습니다. 돌이켜보면 비트나미 스택이라는 것을 알고 설치한 것이 아니라, 콘솔 화면에서 가이드하는 안내에 맞춰 설치한 후에 보면 비트나미 스택이었습니다. (가끔은 인프라 담당자가 비트나미 스택에 설치한 채로 접속 권한만 넘겨주기도 했습니다.)

비트나미 스택이라 설치가 간편했던 반면, 서버 설정 관련해서 비트나미에 의존적인 부분이 많았었기에 범용성을 가지지 못했었던 운영 환경은 늘 가슴 한편에 짐이 되기도 했습니다. 마침 CentOS 사용 여건에 변화가 생기기도 했던 만큼, 우분투(Ubuntu)로 기본 OS를 지정하고 하나씩 다시 환경을 구축해 보기로 했습니다.

우선 퍼블릭 클라우드 VM에서 우분투를 사용하는 감을 잡기 위해, AWS 라이트 세일에 간단히 초소형 VM을 생성했습니다. LAMP 기본 환경 세팅과 동작 여부를 확인한 후, 로컬 PC에서 동일한 LAMP 환경을 올리기 위해 WSL을 이용하기로 했습니다.

최초 저의 로컬 PC 환경은,

• LG 그램14 – i5 10세대
• 16GB 램
• 윈도우 10 Enterprise 1909 – OS 빌드 18363.418

WSL

WSL(Windows Subsystem for Linux)에 대한 자세한 설명은 MS 공식 문서 링크로 대체하겠습니다. 저는 매우 라이트(Light)한 사용자입니다. 개발 관련 업무를 직접적으로 하지 않기 때문에, 간단한 웹 페이지 수정을 확인하는 정도 또는 매뉴얼에 작성된 코드를 그대로 재현하면서 따라 해보는 정도가 대부분입니다.

그래서 WSL에 우분투를 올려서 쓸 때 개인적으로 생각한 장점은 크게 2가지가 있습니다. 하나는 이미지 파일 등을 웹 서버로 업로드하기 위해 따로 파일질라 등을 쓰지 않고 윈도우 탐색기만으로 해소할 수 있다는 점(윈도우 탐색기 주소창에서 ‘\\WSL$’를 입력), 나머지 하나는 코드 수정이 필요할 때 간단한 명령어로 비주얼 스튜디오 코드(VSCode)를 바로 실행할 수 있다는 점(해당 디렉터리에서 ‘code <파일명>’을 입력)입니다.

위에서 쓰는 기능은 WSL1에서도 쓸 수 있습니다. 하지만 향후 발생할 수 있는 도커 활용이나 네트워크 설정 등 WSL1에서는 손쉽게 쓸 수 없지만 WSL2에서는 간편하게 쓸 수 있는 기능에 대비하기 위해 WSL2 환경을 세팅하고 싶었습니다.

WSL2를 가로막은 장벽

윈도우10 기준으로 WSL2는 WSL1과 달리 사용을 위해 몇 가지 장벽을 넘어서야 했습니다.

WSL2를 쓸 수 있는 윈도우 빌드 버전

WSL2 환경 세팅 중 만났던 첫 번째 허들은 윈도우 빌드 버전입니다. WSL 공식 문서에 잘 나와있지만, 2021년 8월 기준으로 단순화된 설치는 윈도우 인사이더 프로그램 참가자이면서 윈도우10 OS 빌드가 20262 이상인 사용자만 사용할 수 있습니다. 이 글을 쓰는 2021년 9월 기준으로 가장 최신 윈도우10 OS 빌드는 19043.1165입니다. 단순화된 설치 방법은 저를 위한 방법이 아니었습니다.

다만, WSL 공식 문서 자체에 매우 상세히 잘 나와있어서 설치 과정이 어렵지는 않습니다. 그저 제 노트북에 설치된 윈도우 빌드 버전이 한참 모자란 것이 문제였습니다.

MS 공식 문서에 빌드 버전 관련 조건이 복잡하게 분기돼 있습니다. x64 시스템이라면 버전은 1903 이상이며 빌드는 18362이 이상이면 된다고 첫 줄에 나와있습니다. 하지만 이 상태로 끝까지 진행해도 WSL2가 활성화되지 않았습니다. 다른 조건이 있음을 놓치고 있었습니다.

부연 설명에서는 18362 뒷자리가 1049 이상이어야 한다고 명시돼 있습니다. 처음부터 18363.1049 이상이어야 한다고 해줬더라면 좋았을 텐데 말이죠. 그래서 사내 윈도우 버전 정책 문의를 하고, 윈도우 업데이트를 할 수 있는 한 최대로 끌어올린 후에야 WSL2를 만날 수 있었습니다.

WSL2 Disable 명령어

두 번째 허들은 WSL 공식 문서에 없는 WSL2 Disable 명령어입니다. 바로 위에서 윈도우 빌드 버전을 해결하지 못하던 도중, 중간에 엉켜버린 단계를 깨끗이 되돌리기 위해 Enable 했던 부분을 Disable하고 싶었습니다. (향후에 생기는 제약 요소를 해소할 때에도 Disable 기능이 필요할 수도 있습니다.) 하지만, 공식 문서에는 아무리 찾아도 Disable 관련 명령어가 없었습니다.

커뮤니티 문서를 검색해 찾은 명령어는 아래에 공유합니다. 명령어 패턴이 서로 비슷한듯하면서도 살짝 다른 부분으로 인해 ‘enable’을 ‘disable’로 바꾸는 것만으로는 Disable이 실행되지 않습니다.

Enable 명령어

$ dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-
Linux /all /norestart
$ dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all 
/norestart

Disable 명령어

$ dism.exe /online /disable-feature /featurename:Microsoft-Windows-Subsystem-
Linux /norestart
$ dism.exe /online /disable-feature /featurename:VirtualMachinePlatform 
/norestart

윈도우 로컬 드라이브 소유권 바꾸기

윈도우 탐색기에서 WSL 안에 있는 폴더에 바로 접속하는 것과 동일하게, WSL에서도 윈도우 마운트 드라이브를 작업 디렉터리로 설정할 수 있습니다. 다만, 이때 우분투 셸(Shell)에서 편하게 작업하기 위해서 소유권 같은 권한 설정을 바꿔줄 필요가 있습니다.

하지만 최초 설치한 WSL2 안 우분투로 로컬 PC 드라이브로 연결된 mnt 디렉터리의 권한을 바꾸기 위해 chmod, chown을 실행해도 권한이 바뀌지 않습니다. mnt 디렉터리의 권한을 바꾸려면 마운트(mount) 설정을 변경해야 합니다.

$ sudo umount /mnt/d
$ sudo mount -t drvfs D: /mnt/d -o metadata

마운트를 새로 설정한 이후에는 mnt 디렉터리의 권한을 변경할 수 있습니다.

잦은 재설치 이후 에러 나는 우분투 설치

퍼블릭 클라우드에서 VM을 수시로 생성하고 제거하던 버릇이 남아있던 탓에, 우분투를 수차례 설치하고 삭제하기를 반복하며 작업을 이어갔습니다. WSL에 설치하는 우분투는 윈도우에서 MS 스토어를 통해 쉽게 접근할 수 있습니다. 몇 차례 반복하다 보니, MS 스토어에서 새로 설치되지 않는 현상이 나오기 시작했습니다.

최초에 오류가 발생한 시점에는 로컬 PC를 재부팅하는 정도로 오류를 해소할 수 있었습니다만, 이조차도 수차례 쌓인 후에는 오류가 계속 나오기 시작했습니다. 만약 이 글을 읽으시는 분께서도 이 상황에 직면하셨다면, 우분투가 아니라 MS 스토어를 초기화하시면 해결하실 수 있습니다.

윈도우 설정에서 ‘앱 및 기능’ 항목으로 들어가, MS 스토어에서 ‘고급 옵션’을 누르시면 위 그림과 같은 화면을 볼 수 있습니다. 여기서 초기화를 실행해 앱 데이터를 삭제하면, 우분투 재설치 시 겪는 오류 화면을 벗어나실 수 있습니다.

로컬 PC를 재부팅하면 service XXX restart

WSL에 올려둔 우분투는 윈도우 부팅 시 자동 실행하는 프로세스가 아닙니다. 그래서 사용하던 LAMP 스택 기준에서는 윈도우 부팅 시 LAMP를 꼭 새로 실행해 줘야 했습니다. 물론 재부팅으로 인해 우분투를 새로 실행하면, 우분투가 할당받는 IP 주소도 바뀐다는 점도 잊지 말아야 합니다.

꼭 WSL 우분투를 실행하지 않더라도, 윈도우 셸 커맨드로 간편히 실행할 수 있으므로 미리 배치 파일로 만들어 시작 프로그램에 등록해둔다면 이 과정을 생략할 수 있습니다.

그럼에도 불구하고 간단히 해결하지 못했던 이슈들

고정 IP 주소 할당받기

위에서 언급했던 것처럼, 로컬 PC를 재부팅하면 우분투 VM에 할당된 IP 주소가 바뀝니다. 로컬 PC에 설치한 VM이 WSL 우분투 하나일 땐 로컬 호스트(127.0.0.1)로 접속하면 됩니다만, 우분투 내부 웹 서버 설정에서 IP 주소를 고정 값으로 입력한 경우라면 재부팅할 때마다 설정값을 바꿔줘야 하는 불편함을 겪습니다.

검색해 보면 이를 해소할 수 있는 여러 방법이 있습니다만, WSL 설치 이외에 부차적으로 해야 하는 설정을 위한 학습 난이도가 존재해 별도의 글로 작성해 보려 합니다.

같은 OS 버전으로 WSL VM을 여러 개 설치하기

WSL에 설치하는 리눅스는 기본적으로 MS 스토어를 통해 설치합니다. 우분투, 우분투 20.04, 우분투 18.04, 데비안, 칼리 리눅스, 수세 리눅스 등 여러 리눅스를 MS 스토어에서 볼 수 있습니다.

하지만 같은 OS 버전으로 VM을 두 개 이상 설치하는 것은 MS 스토어를 통해서는 불가능합니다. WSL 공식 문서에 나와있는 WSL DistroLauncher를 활용해 커맨드 라인으로 실행해야만 같은 OS 버전을 두 개 이상 설치할 수 있습니다.

Hyper-v와 공존성

WSL2는 Hyper-v 기반으로 동작하고 있으므로, Hyper-v와 동시에 동작할 수 없는 애플리케이션이나 가상 머신 플랫폼은 로컬 PC에서 사용할 수 없습니다. 그나마 버츄어박스(VirtualBox)는 6.1 버전 이후로 Hyper-v를 지원하고 있습니다만, VMware는 상용 라이선스인 워크스테이션 16버전 이상을 사용해야 함께 쓸 수 있습니다. 이외에도 블루스택이나 LD 플레이어 같은 에뮬레이터도 Hyper-v 공존성을 꼭 확인해야 합니다.

간단한 리눅스 활용은 셀프로

비개발자로서 업무를 하면서 리눅스 환경에서 할 일이 얼마나 있을까 싶기도 했지만, 어느덧 WSL2와 우분투 기본 환경 구축에 대해서는 겁을 내지 않아도 옆자리 동료에게 가르쳐줄 수 있는 만큼 익혔다는 점은 참 뿌듯합니다.

간단하고 간편하게 LAMP 환경을 활용하려고 WSL2를 보기 시작했었는데, 정작 제대로 써보려는 과정에서 이런저런 장벽을 마주하고 나니 야크 털깎기를 한 게 아닐까 싶은 생각도 여러 번 들었습니다. 실제로 이 작업을 진행하면서 도커(Docker)나 베이그란트(Vagrant)에서 시작하라는 유혹도 주변에서 수차례 받았습니다.

이번 기회에 WSL2와 우분투 환경 구성은 마쳤으니, 이제 저를 유혹했던 이들의 기대에 부응할 수 있도록 틈나는 대로 도커를 만나러 가봐야겠습니다.

<원문>

가볍게 쓰려했던 WSL2가 무겁게 다가온 순간.