WSL containers 정식 출시: Docker 없이 윈도우에서 리눅스 컨테이너 돌리기

들어가며: 컨테이너 하나 돌리려고 엔진을 따로 깔던 시절

윈도우에서 리눅스 컨테이너를 돌리려면 지금까지 선택지가 좁았습니다. Docker Desktop을 설치하거나, WSL 안에 다시 컨테이너 엔진을 세우거나, Podman 같은 대안을 붙이는 식이었습니다. 개발자 입장에서는 도구가 하나 더 늘고, 기업 입장에서는 관리 사각지대가 하나 더 생겼습니다.

마이크로소프트가 2026년 9월 29일 WSL containers를 정식 출시(GA)했습니다. 핵심은 간단합니다. WSL을 업데이트하면 컨테이너를 다루는 명령이 함께 들어옵니다. 별도 엔진을 설치하지 않습니다. WSL 릴리스 3.0.1에 포함되어 나왔고, 문서상 최소 요구 버전은 2.9.3입니다.

핵심 개념: wslc.exe와 WSL containers API

용어를 먼저 정리하겠습니다.

• WSL은 윈도우에서 리눅스 환경을 돌리는 하위 시스템입니다. WSL 2부터는 실제 리눅스 커널이 관리형 가상 머신 안에서 돕니다.
• WSL containers는 그 WSL 환경에 컨테이너 계층을 얹은 기능입니다. 이름은 WSLC로 줄여 씁니다.
• wslc.exe는 컨테이너를 빌드하고 실행하는 명령줄 도구입니다. 별칭으로 container.exe를 함께 제공합니다.

즉 기존에 "윈도우에서 컨테이너를 쓰려면 무엇을 설치해야 하나"라는 질문이 "WSL을 최신으로 올리면 되나"로 바뀌었습니다.

준비물

• WSL이 설치된 윈도우 (문서 기준 WSL 2.9.3 이상)
• 최신 WSL로 올리기 위한 관리자 권한 (업데이트 시점)
• 선택 사항으로 VS Code와 윈도우 터미널 (개발 편의)

1단계: WSL 업데이트와 wslc 확인

파워셸에서 WSL을 최신으로 올립니다.

wsl --update
wsl --version

이어서 명령줄 도구가 살아 있는지 확인합니다.

wslc version

여기까지 오류 없이 버전이 출력되면 설치가 끝난 것입니다. 별도 엔진 설치 단계가 없다는 점이 이전 방식과 가장 크게 다른 부분입니다.

2단계: 내장 이미지로 동작 확인

가장 빠른 확인은 내장 이미지를 돌려 보는 것입니다. 이미지가 없으면 자동으로 내려받습니다.

wslc run --rm hello-world

인사 메시지가 보이면 동작합니다. 자주 쓰는 명령 몇 가지를 함께 익혀 두면 편합니다.

wslc image list              # 내려받은 이미지
wslc container list          # 실행 중 컨테이너
wslc container list --all    # 중지된 것까지
wslc stats                   # 자원 사용량

3단계: 포트를 열어 웹 서버 돌리기

컨테이너를 백그라운드로 띄우고 포트를 연결해 보겠습니다.

wslc run -d --rm -p 8080:80 --name web nginx
curl localhost:8080
wslc exec web cat /etc/os-release
wslc container stop web

--rm을 주었으므로 컨테이너는 중지와 동시에 자동으로 제거됩니다. 컨테이너 안에서 uname을 실행하면 Linux가 나옵니다. 이것이 컨테이너가 WSL 2 리눅스 커널 위에서 돌고 있다는 증거입니다.

4단계: 직접 만든 앱을 이미지로 빌드하기

프로젝트 루트에 Containerfile을 두고 빌드합니다. 도커 파일과 같은 형식입니다.

FROM python:3
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

wslc build -t helloworld-django .
wslc run -d --rm -p 8000:8000 --name django helloworld-django

브라우저에서 http://localhost:8000/을 열면 컨테이너 안의 앱이 보입니다.

참고로 코드는 윈도우 파일 시스템이 아니라 리눅스 쪽에 두는 편이 빠릅니다. 리눅스 도구가 윈도우 파일을 건드릴 때의 성능 손실이 오래된 병목이었기 때문입니다. 이번 릴리스에서 그 경로가 최대 2배 개선되었다고 발표되었습니다.

GA에서 새로 추가된 기능

정식 출시와 함께 생명주기·네트워킹·관측성 전반에 명령이 늘었습니다.

• 컨테이너 재시작
• tar 아카이브로 파일을 주고받는 복사
• 컨테이너 환경 상태를 한눈에 보는 시스템 정보
• 네트워크 연결과 해제
• 네트워크 생성 시 임의 드라이버 옵션 지원
• 실시간 컨테이너 활동 스트림
• 컨테이너 헬스 체크
• 중지 타임아웃 지정 (무한 대기도 가능)
• 생성과 실행 단계의 마운트 지원
• 기본 세션의 저장 경로를 원하는 드라이브로 지정

아키텍처: 특권 서비스가 가상 머신을 소유하지 않는다

여기가 이번 릴리스에서 가장 눈여겨볼 부분입니다.

기존 WSL에서는 특권 윈도우 서비스인 wslservice.exe가 가상 머신을 직접 소유했습니다. WSL containers는 이 구조를 바꿉니다. wslservice.exe는 가상 머신을 만드는 데까지만 관여하고, 실제 세션 작업은 자식 프로세스인 wslcsession.exe가 맡습니다. 이 프로세스는 호출한 사용자 권한으로 돕니다.

효과는 두 가지입니다. 세션이 서로 다른 프로세스에 살기 때문에 격리가 강해지고, 컨테이너 작업이 특권 서비스보다 낮은 권한에서 실행되므로 권한 경계가 좁아집니다.

스토리지: 세션 VHD와 virtiofs

저장 구조는 세 층으로 나뉩니다.

• 세션 VHD: 세션마다 별도의 가상 디스크를 씁니다. 이미지·컨테이너·네트워크·볼륨 상태가 여기에 들어갑니다.
• 컨테이너 볼륨: 컨테이너가 삭제되면 사라지는 임시 공간과 달리, 밖에 데이터를 남깁니다. 윈도우 경로를 그대로 공유할 수도 있습니다.
• VHD 볼륨: 볼륨 자체를 가상 디스크로 만드는 방식입니다. 리눅스 네이티브 파일 시스템이 필요하거나 크기 상한을 걸고 싶을 때 씁니다.

윈도우 경로 공유는 virtiofs로 구현됩니다. 가상 머신과 하이퍼바이저 사이를 위해 만든 파일 시스템이고, 기존 plan9 방식보다 약 2배 빠르다고 설명됩니다. 볼륨에 크기 상한을 걸고 싶으면 드라이버를 vhd로 지정하고 바이트 수를 넘깁니다.

네트워킹: Consomme 모델

네트워킹은 새 모델을 씁니다. 이름은 Consomme입니다.

가상 머신의 트래픽을 이더넷 프레임으로 virtio 큐에 넘기면, 사용자 권한으로 도는 윈도우 프로세스가 그 프레임을 읽습니다. 이 프로세스가 DNS 응답, TCP·UDP 라우팅, 포트 매핑을 대신 처리합니다.

중요한 결과가 하나 있습니다. 밖으로 나가는 트래픽이 사용자 소유 프로세스에서 나가기 때문에, 평범한 윈도우 프로세스가 낸 트래픽과 같은 취급을 받습니다. VPN과 방화벽 환경에서의 호환성이 크게 좋아지는 이유입니다.

기업 도입: Intune과 Defender for Endpoint

이번 릴리스는 개발자 기능만이 아니라 거버넌스도 함께 넓혔습니다. 기업 환경에서 컨테이너를 표준으로 밀어붙일 근거가 생긴 셈입니다.

• Intune에 WSL containers 전용 설정 두 가지가 추가되었습니다. 하나는 기능 전체에 대한 접근 허용/차단이고, 다른 하나는 이미지 풀 허용 레지스트리 목록입니다.
• 승인된 레지스트리만 허용하도록 정의할 수 있어, 조직의 보안·컴플라이언스 기준을 만족하는 이미지만 들어오게 통제할 수 있습니다.
• Defender for Endpoint의 WSL 플러그인이 컨테이너까지 확장되었습니다. 컨테이너 안에서 일어난 프로세스·파일·네트워크 활동을 윈도우 호스트 활동과 연결해 보여 줍니다.
• 별도의 보안 워크플로를 새로 만들지 않고 기존 조사 흐름에서 컨테이너를 함께 볼 수 있습니다.

생태계: 도구들이 이미 붙었다

정식 출시와 함께 주변 도구 지원도 들어왔습니다.

• VS Code dev container가 wslc를 드라이버로 쓸 수 있습니다.
• Aspire가 WSL Containers를 일급 컨테이너 런타임으로 다룹니다.
• VS Code 컨테이너 확장이 wslc를 지원합니다.
• Lazywslc는 터미널에서 컨테이너를 관리하는 TUI 대시보드입니다.
• WSL Container Desktop은 WinUI 3로 만든 데스크톱 앱이고, 컨테이너와 k3s, 레지스트리까지 함께 다룹니다.
• wslc-remote는 WSL 배포판 안에서 wslc를 부르는 래퍼입니다.

다음 과제: compose

발표문이 명시한 최우선 요청은 compose 지원입니다. 목표는 기존 compose.yaml을 수정하지 않고 그대로 쓰는 것입니다. 착수했다고 밝혔으니 다음 반복에서 나올 것으로 보입니다.

그 밖에 네트워킹과 크로스 OS 파일 성능 개선이 계속 진행 중입니다.

보안·주의 사항

• 레지스트리 허용 목록은 기업 배포에서 먼저 정하는 편이 좋습니다. 개발자별로 임의 이미지를 당겨오면 통제가 무너집니다.
• 컨테이너에서 윈도우 파일에 접근할 때의 권한은 그 컨테이너를 실행한 윈도우 사용자 권한을 따릅니다. 리눅스 안에서 root라도 윈도우 관리자 작업은 되지 않습니다.
• 저장 경로를 바꾸면 기존 세션 VHD 위치와 어긋날 수 있으니 초기에 정하는 편이 안전합니다.
• 기능 전체를 차단하는 Intune 설정이 있으므로, 관리 기기에서는 관리자 정책을 먼저 확인하세요.

자주 걸리는 지점

1. wslc 명령이 없다고 나오는 경우 WSL 버전이 낮습니다. wsl --update를 실행하고 wsl --version으로 확인하세요. 문서상 최소 2.9.3, GA 릴리스는 3.0.1입니다.
2. 이미지를 내려받지 못하는 경우 기업 프록시나 방화벽 환경일 수 있습니다. Intune의 레지스트리 허용 목록에 해당 레지스트리가 들어 있는지 확인하세요.
3. 컨테이너는 도는데 밖에서 접속이 안 되는 경우 포트 매핑이 빠졌을 가능성이 큽니다. 실행할 때 -p 옵션으로 호스트 포트와 컨테이너 포트를 이어 주세요.
4. 파일 접근이 유난히 느린 경우 코드를 윈도우 파일 시스템에 두었을 수 있습니다. 리눅스 쪽 파일 시스템을 쓰면 체감 차이가 큽니다.
5. 디스크가 부족한 경우 중지된 컨테이너와 안 쓰는 이미지가 공간을 차지합니다. 정리 명령으로 회수하세요.

wslc container prune
wslc image prune

마무리: 윈도우가 리눅스 워크로드의 실행 기반이 되는 중

정리하면 이렇습니다. WSL을 최신으로 올리면 컨테이너 명령이 함께 들어옵니다. 세션마다 권한이 낮은 별도 프로세스가 돌아 격리와 보안 경계가 함께 좋아졌습니다. 네트워킹은 사용자 권한으로 나가 VPN과 방화벽 호환성이 개선되었습니다. 기업은 Intune과 Defender for Endpoint로 컨테이너까지 관리 범위에 넣을 수 있게 되었습니다.

특히 눈여겨볼 대목은 WSL containers API입니다. 윈도우 앱에서 코드로 컨테이너를 다룰 수 있게 되었으니, 로컬 AI 워크로드나 클라우드 컨테이너 앱을 네이티브 앱에 붙이는 시나리오가 자연스러워집니다. WinUI 3로 만든 관리 도구가 이미 나와 있다는 점도 같은 방향을 가리킵니다.

윈도우 앱을 만드는 입장에서 이번 변화는 "리눅스 도구를 쓰려면 곁다리 도구를 하나 더 깔아야 한다"는 전제를 지웁니다. 확장 팁을 하나 붙이면, 아래 한 줄로 내 환경이 준비되었는지 바로 확인할 수 있습니다.

wsl --version