Windows WSL2 환경에서 Docker Desktop 없이 가볍게 개발 환경 구축하기

Winsdows PC를 하나 장만하고, 가장 먼저 개발환경 세팅을 하였다. 예전부터 느낀거지만, Mac에 비해 순수 Windows에서 VSCode로 작업하면 처리 속도가 느려서 답답함을 느끼곤 했다(이러한 탓에 개인적으로 개발은 Mac에서 하는 것을 더 선호한다).

마찬가지로 Docker Desktop은 편리하지만 무겁다. 메모리를 상당히 점유하고, 유료 라이선스 정책 변경 이후 상업적 사용에 제약이 생겼다. WSL2(Windows Subsystem for Linux 2)를 주 개발 환경으로 쓴다면 Docker Desktop 없이도 충분히 쾌적한 컨테이너 환경을 만들 수 있다.

이 글은 WSL2에 Docker Engine을 직접 설치하고, VS Code와 연동해 실제로 쓸 수 있는 수준의 개발 환경을 구성하는 과정을 정리한 것이다.

왜 Docker Desktop 대신 Docker Engine인가

Docker Desktop은 내부적으로 별도의 리눅스 VM을 띄워 그 위에서 Docker를 실행한다. WSL2를 사용한다면 이미 리눅스 커널이 동작하고 있으므로 Docker Desktop이 관리하는 VM 레이어가 사실상 중복이다.

Docker Engine을 WSL2 배포판에 직접 설치하면 이 중간 레이어를 제거할 수 있다. 그 결과 메모리 사용량이 줄고, 부팅 속도가 빨라진다. Windows 호스트에서 별도의 백그라운드 서비스가 돌지 않으니 시스템 전반이 가벼워지는 체감이 분명하다.

라이선스 측면에서도 Docker Engine 자체는 Apache 2.0 라이선스로 상업적 사용에 제약이 없다.

WSL2 환경 사전 확인

Docker Engine 설치 전에 WSL2가 제대로 설정되어 있어야 한다.

WSL2 버전 확인

PowerShell 또는 Windows Terminal에서 다음 명령어로 현재 설치된 배포판과 버전을 확인한다.

wsl --list --verbose

VERSION 열이 2로 표시되어야 한다. 1로 표시된다면 해당 배포판을 WSL2로 전환해야 한다.

wsl --set-version <배포판이름> 2

WSL2 메모리 설정 조정

WSL2는 기본적으로 호스트 메모리의 상당 부분을 자동으로 할당한다. 개발 환경 용도로 쓴다면 .wslconfig 파일로 상한을 지정해두는 것이 좋다.

Windows 사용자 홈 디렉터리(C:\Users\<사용자명>)에 .wslconfig 파일을 만들고 아래 내용을 작성한다.

[wsl2]
memory=4GB
processors=4
swap=2GB

수치는 본인 시스템 사양에 맞게 조정하면 된다. 변경 후에는 wsl --shutdown 명령으로 WSL2를 재시작해야 적용된다.

WSL2에 Docker Engine 설치

Ubuntu 기준으로 설명한다. Debian 계열 배포판이라면 동일한 방법이 적용된다.

기존 Docker 패키지 제거

이전에 시도했던 설치 잔재가 있다면 먼저 제거한다.

sudo apt remove docker docker-engine docker.io containerd runc

Docker 공식 저장소 추가

sudo apt update
sudo apt install ca-certificates curl gnupg lsb-release

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Docker Engine 설치

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

docker-compose-plugin을 함께 설치하면 별도로 docker-compose 바이너리를 관리할 필요 없이 docker compose 명령어로 Compose를 사용할 수 있다.

sudo 없이 Docker 사용 설정

매번 sudo를 붙이는 것은 번거롭다. 현재 사용자를 docker 그룹에 추가하면 된다.

sudo usermod -aG docker $USER

그룹 변경을 반영하려면 WSL2 세션을 종료했다가 다시 시작해야 한다.

WSL2에서 Docker 데몬 시작 방법

WSL2 환경에는 systemd가 기본 활성화되지 않은 배포판이 많다. Docker 데몬을 어떻게 시작할지 방법을 나눠서 알아둘 필요가 있다.

systemd가 활성화된 경우

Ubuntu 22.04 이상이고 WSL2 설정에서 systemd를 활성화했다면 일반적인 리눅스와 동일하게 사용한다.

/etc/wsl.conf 파일에 아래 내용이 있어야 한다.

[boot]
systemd=true

설정 후 WSL2를 재시작하면 systemd가 활성화된다. 이후에는 다음 명령으로 Docker 데몬을 관리한다.

sudo systemctl enable docker
sudo systemctl start docker

enable을 해두면 WSL2 세션이 시작될 때 Docker 데몬이 자동으로 함께 올라온다.

systemd 없이 데몬 시작하는 방법

systemd를 사용하지 않는 환경이라면 ~/.bashrc 또는 ~/.zshrc에 다음을 추가해 셸이 시작될 때 자동으로 데몬을 띄우도록 설정할 수 있다.

if [ $(ps -e | grep -c dockerd) -eq 0 ]; then
  sudo service docker start > /dev/null 2>&1
fi

그리고 sudo 패스워드 없이 docker 서비스를 시작할 수 있도록 /etc/sudoers에 예외를 추가한다.

sudo visudo

파일 마지막에 다음 줄을 추가한다.

<사용자명> ALL=(ALL) NOPASSWD: /usr/sbin/service docker start

VS Code와 연동하기

WSL2 기반 개발 환경의 가장 큰 장점 중 하나는 VS Code와의 연동이 매끄럽다는 점이다.

VS Code Remote – WSL 확장 설치

Windows에 설치된 VS Code에서 Remote – WSL 확장을 설치한다. 이후 WSL2 터미널에서 작업 디렉터리로 이동해 code . 명령을 실행하면 VS Code가 해당 WSL2 환경에 직접 연결된 상태로 열린다.

파일 시스템 접근, 터미널, 확장 기능 실행 모두 WSL2 리눅스 환경 기준으로 동작한다. Windows 호스트에서 마운트된 경로(/mnt/c/...)가 아닌 WSL2 파일 시스템(~/) 안에 프로젝트를 두는 것이 I/O 성능 면에서 훨씬 유리하다.

Dev Containers 활용

VS Code의 Dev Containers 확장을 함께 사용하면 프로젝트별로 격리된 컨테이너 환경에서 개발할 수 있다. .devcontainer/devcontainer.json 파일을 프로젝트에 추가해두면 팀원 간에 동일한 개발 환경을 공유하기도 쉽다.

Docker Desktop 없이 WSL2에 직접 설치한 Docker Engine 위에서도 Dev Containers는 정상적으로 동작한다.

실제 사용 시 알아두면 좋은 것들

포트 포워딩

WSL2에서 실행 중인 컨테이너의 포트는 Windows 브라우저에서 localhost로 접근할 수 있다. WSL2가 자동으로 포트 포워딩을 처리한다. 예를 들어 컨테이너에서 8080 포트를 열었다면 Windows의 브라우저에서 http://localhost:8080으로 바로 접속된다.

파일 시스템 경로 주의사항

Docker 볼륨을 마운트할 때 Windows 경로(C:\...)가 아닌 WSL2 내부 경로(/home/...)를 사용해야 한다. Windows 경로를 그대로 쓰면 마운트가 제대로 되지 않거나 성능이 크게 저하된다.

Docker Compose 사용

앞서 설치한 docker-compose-plugin 덕분에 docker compose up -d, docker compose down 같은 명령이 바로 사용 가능하다. 기존에 docker-compose(하이픈 포함) 명령어에 익숙하다면 docker compose(공백 구분)로 바꿔서 사용하면 된다. 동작은 동일하다.

WSL2 종료 시 컨테이너 상태

wsl --shutdown으로 WSL2를 종료하면 실행 중이던 컨테이너도 함께 멈춘다. 다음에 WSL2를 다시 시작하면 systemd를 쓰는 경우 Docker 데몬이 자동으로 올라오고, docker start <컨테이너명> 으로 필요한 컨테이너를 다시 띄우면 된다. restart: always 정책을 사용하는 컨테이너는 Docker 데몬이 시작될 때 자동으로 재시작된다.

Docker Desktop과 비교했을 때 실질적인 차이

항목	Docker Desktop	WSL2 + Docker Engine
메모리 사용량	상대적으로 높음	가벼움
라이선스	상업적 사용 시 유료 가능	무료(Apache 2.0)
GUI 관리 도구	내장	별도 설정 필요
설치 복잡도	낮음(인스톨러)	다소 높음
Windows 통합	자동	일부 수동 설정 필요

Docker Desktop의 GUI 대시보드가 반드시 필요하거나, 팀 전체가 동일한 설정을 간편하게 공유해야 하는 상황이라면 Docker Desktop이 나을 수 있다. 개인 개발 환경이나 리소스 절약이 우선이라면 이 방식이 훨씬 실용적이다.

마무리하며

WSL2에 Docker Engine을 직접 설치하는 방식은 처음 설정이 조금 번거롭지만, 한 번 구성해두면 Docker Desktop보다 훨씬 가볍고 빠르게 동작한다. 특히 메모리가 16GB 이하인 환경에서는 그 차이가 더 크게 느껴진다.

VS Code, Dev Containers와 함께 구성하면 로컬 개발 환경으로서 부족함이 없다. Windows 환경에서 리눅스 기반 개발 워크플로우를 유지하고 싶다면 이 조합이 현실적인 선택지가 된다.