WSL 쓰는데 Docker 빌드 속도 5배 올리는 방법

분명 컴퓨터는 최신 사양인데, WSL2에서 docker build만 돌리면 세월아 네월아 느려터져서 답답하셨나요? npm install이나 yarn 실행할 때마다 한참을 기다려야 하고, vmmem 프로세스가 메모리를 미친 듯이 잡아먹어서 짜증이 치밀어 오르셨다고요? 이거, 여러분의 코딩 실력이나 컴퓨터 사양 탓이 아닐 가능성이 높습니다. 오히려 아주 사소한 차이, 즉 파일을 어디에 두느냐가 빌드 속도를 5배 이상 좌우할 수 있다는 사실, 알고 계셨나요? 마이크로소프트 공식 문서에서도 이 문제를 콕 집어 언급하고 있다고 하네요.

배경 설명: 왜 내 WSL만 유독 느릴까?

WSL2는 이름 그대로 Windows Subsystem for Linux 2입니다. 이건 단순히 리눅스 명령어만 실행하는 에뮬레이터가 아니라, 실제 리눅스 커널이 가상 머신(VM) 위에서 돌아가는 방식이죠. 덕분에 WSL1보다 훨씬 강력하고 진정한 리눅스 환경을 제공합니다. 마치 윈도우 안에 작은 리눅스 컴퓨터를 하나 더 들여놓은 셈입니다.

문제는 여기서 발생합니다. Windows의 파일 시스템은 NTFS이고, 리눅스의 주류 파일 시스템은 ext4입니다. 이 둘은 완전히 다른 방식으로 파일을 관리하는데요. WSL2가 /mnt/c와 같이 Windows 파티션에 있는 파일에 접근하려고 하면, 이 두 다른 파일 시스템 간의 '통역' 과정이 필요하게 됩니다. 이때 사용되는 것이 9P 프로토콜인데, 이 통역 과정에서 발생하는 오버헤드가 어마어마합니다. 특히 파일 입출력(I/O) 작업이 많은 docker build나 패키지 설치 명령어에서 이 오버헤드가 극심한 병목 현상을 일으키는 것이죠. Docker 공식 문서에서도 최상의 파일 시스템 성능을 위해서는 소스 코드를 Windows 파일 시스템 대신 리눅스 파일 시스템에 저장할 것을 강력히 권장하고 있습니다.

핵심 내용: 빌드 속도 5배 올리는 '파일 이사'

모든 문제의 근원: C 드라이브에 사는 내 코드

아마 대부분의 개발자분들이 평소에 윈도우에서 하던 대로 cd /mnt/c/Users/내이름/projects 같은 경로에서 개발 프로젝트를 시작하셨을 겁니다. 그리고 이 경로에서 docker build나 npm install을 실행하셨겠죠. 이게 바로 문제입니다! 당신의 코드가 NTFS 파티션에 있기 때문에, 빌드 과정에서 발생하는 수많은 파일 읽기/쓰기 작업이 매번 저 '느린 통역' 과정을 거쳐야 하는 겁니다.

한 Velog 유저의 "WSL2 Docker 속도 저하 해결 삽질기"에 따르면, 윈도우 파티션에 있던 프로젝트를 WSL 안의 ext4 파티션으로 옮겼더니 npm install 속도가 무려 몇 분에서 몇 초로 드라마틱하게 줄었다고 해요. "신세계를 경험했다"는 반응이 괜히 나오는 게 아니겠죠? 마이크로소프트 벤치마크에 따르면 특정 파일 작업에서 WSL2 네이티브 파일 시스템이 /mnt/c를 통해 접근하는 것보다 최대 20배까지 빠를 수 있다고 하니, 이 속도 차이는 과장이 아닙니다.

WSL의 고향으로 프로젝트를 옮기자

해결책은 의외로 간단합니다. 프로젝트 파일을 WSL의 네이티브 파일 시스템, 즉 ext4 파티션으로 옮기기만 하면 됩니다.

파일을 옮기는 방법도 어렵지 않습니다. 가장 쉬운 방법은 윈도우 파일 탐색기 주소창에 \\\\wsl$를 입력하고 엔터를 치는 겁니다. 그러면 현재 설치된 WSL 리눅스 배포판들이 보이는데, 여기서 사용하시는 배포판 (예: Ubuntu)을 선택하고, home/내이름 경로로 들어가 projects 같은 폴더를 하나 만들어 주세요. 그리고 기존 윈도우 C 드라이브에 있던 프로젝트 폴더를 이 projects 폴더 안으로 복사해 넣으면 끝입니다!

물론 터미널을 이용해 직접 복사할 수도 있습니다. WSL 터미널을 열고 다음 명령어를 사용하면 되죠.

mkdir -p ~/projects
cp -r /mnt/c/Users/내이름/기존프로젝트폴더 ~/projects/

이제 기존 프로젝트 폴더는 윈도우의 구렁텅이에서 벗어나 WSL의 빠릿빠릿한 고향으로 이사를 마쳤습니다.

"아니, 그럼 VS Code는 어떻게 쓰지?" 걱정하실 필요 없습니다. VS Code의 Remote - WSL 확장을 설치하셨다면, 아주 간단하게 WSL 안의 프로젝트를 열 수 있습니다. VS Code에서 Ctrl+Shift+P를 누르고 Remote-WSL: New Window 또는 Remote-WSL: Open Folder in WSL을 선택한 후, 아까 옮긴 ~/projects/내프로젝트 경로를 열어주면 됩니다. 이전과 똑같이 윈도우용 VS Code에서 리눅스 터미널과 파일을 편집할 수 있으니 전혀 불편함이 없을 겁니다.

자, 이제부터는 모든 새로운 프로젝트는 ~/projects 폴더에서 시작하세요. 이 작은 습관 하나가 당신의 개발 생산성을 확 바꿔줄 겁니다.

 

이 '파일 이사' 팁을 적용한 수많은 개발자들이 "진작 이렇게 할 걸!", "속이 다 시원하다" 같은 후련한 반응을 보이고 있습니다. 빌드 시간이 눈에 띄게 줄어들고 vmmem의 메모리 점유율도 안정화되는 경험을 하고 있다고 하네요.

파일 시스템 문제 외에도, vmmem 프로세스가 메모리를 과도하게 점유하는 문제로 고민이라면 .wslconfig 파일을 활용하는 것도 좋은 방법입니다. Tistory의 "WSL2 vmmem 메모리 누수 잡고 Docker 속도 올리기" 같은 블로그에서는 이 파일을 수정하여 WSL2에 할당되는 메모리나 CPU 코어 수를 제한하는 팁을 공유하고 있습니다. 이를 통해 리소스를 효율적으로 관리하고 쾌적한 개발 환경을 유지할 수 있습니다.

티스토리툴바