Windows 11, WSL 컨테이너 도입: 리눅스 컨테이너 실행의 새로운 방법
Windows 11은 이제 사용자가 Docker Desktop과 같은 백그라운드 런타임 없이도 리눅스 컨테이너를 네이티브로 빌드, 실행 및 관리할 수 있도록 지원합니다. WSL 컨테이너라는 이 새로운 기능은 공개 프리뷰로 도입되었습니다. 실제 작업 부하로 설치 및 테스트한 결과, 그 기능, 한계, 설정 과정을 개략적으로 소개합니다.
Windows 11의 WSL 컨테이너란?
WSL 컨테이너는 Windows Subsystem for Linux (WSL)의 내장 기능입니다. 사용자는 Docker Desktop 또는 Podman Desktop과 같은 타사 런타임 없이도 Windows에서 바로 리눅스 컨테이너를 생성, 실행 및 관리할 수 있습니다. 이는 두 가지 방식으로 작동합니다:
- Windows 애플리케이션이 백그라운드에서 리눅스 전용 코드를 실행하기 위해 리눅스 컨테이너를 조용히 실행할 수 있습니다. 리눅스의 흔적 없이 동작합니다. 예를 들어, Microsoft는 Windows 실행 파일 내부에서 오픈소스 리눅스 렌더링 엔진인 Moonray를 실행하며 이를 시연했습니다.
- API를 사용하는 각 Windows 애플리케이션은 컨테이너 격리를 위해 Hyper-V 기반 가상 머신을 개별적으로 할당받습니다. 이 접근 방식은 자원 효율성보다 보안을 우선시하며, 기업 환경에 적합합니다.
리눅스 VM 내부의 컨테이너 런타임은 Docker를 구동하는 오픈소스 엔진인 Moby입니다. WSL 컨테이너는 컨테이너를 재발명하지 않으며, Windows에 컨테이너 관리용 1차 인터페이스를 제공합니다.
Windows 11에서 WSL 컨테이너 설치 방법
WSL 컨테이너는 현재 프리릴리즈 채널의 WSL에서만 사용할 수 있습니다. 시작하려면 사용자는 이 채널에 가입하고 WSL 설치를 업데이트해야 합니다.
- WSL의 최신 프리릴리즈 버전을 설치합니다.
wslc명령어가 인식되지 않으면 터미널이나 PC를 재시작합니다.- Hyper-V 기반 격리를 위해 BIOS 또는 UEFI에서 가상화가 활성화되었는지 확인합니다.
참고: 일부 개발자는 초기 실행 중 치명적 오류 (오류 코드: E_UNEXPECTED)와 같은 문제를 보고했지만, 테스트 중에는 이러한 문제가 발생하지 않았습니다. WSL 컨테이너는 Copilot+ PC를 요구하지 않지만 최신 CPU 가상화 지원이 필요합니다.
WSL 컨테이너로 컨테이너 빌드 및 실행하기
wslc 설정이 완료된 후 기본 예제를 건너뛰고 커스텀 이미지를 빌드하고 서비스를 노출함으로써 실제 사용 사례를 테스트했습니다. 아래는 단계별 절차입니다:
- 기본 확인:
wslc run -it debian:latest명령을 사용해 Debian 컨테이너를 인터랙티브로 실행했습니다.uname -a명령을 실행해 실제 리눅스 커널 사용을 확인했습니다. - 분리 및 재연결:
Ctrl+P, Ctrl+Q를 사용해 컨테이너를 분리하고,wslc ps -a명령으로 컨테이너를 나열한 후wslc attach [container-name]명령으로 다시 연결했습니다. - 커스텀 이미지:
file,exiftool,binutils와 같은 도구를 패키징하는 리눅스 검사 유틸리티를 위한 Containerfile (Dockerfile과 유사)을 생성했습니다.wslc build -t my-linux-inspector .명령을 사용해 이미지를 빌드했습니다. - 서비스 실행:
wslc run -d -p 5000:5000 --name inspector my-linux-inspector명령을 사용해 포트 매핑된 컨테이너를 시작했습니다. 추가 네트워크 설정 없이 Windows에서127.0.0.1:5000의 Flask 서버에 접근했습니다.
이를 통해 타사 소프트웨어 없이도 리눅스 커널 기반 서비스를 Windows의 localhost에서 접근 가능함을 입증했습니다.
WSL 컨테이너에서 GPU 접근 테스트
AI 및 머신러닝 작업 부하를 위해 GPU 패스스루는 매우 중요합니다. WSL 컨테이너는 Docker의 문법과 동일한 --gpus all 플래그를 지원합니다. 테스트 결과, GPU 접근이 가능한 컨테이너는 CPU 전용 컨테이너에 비해 컴파일된 PyTorch 모델 실행 시 훨씬 높은 성능을 보여주었습니다.
기업 환경을 위한 WSL 컨테이너
Microsoft는 WSL 컨테이너를 프리뷰 단계에서도 기업 환경에 적합한 솔루션으로 포지셔닝하고 있습니다. 주요 기업 기능은 다음과 같습니다:
- 보안 모니터링: Microsoft Defender for Endpoint는 WSL 플러그인을 통해 컨테이너 이벤트를 추적하며, 컨테이너 활동에 대한 가시성을 제공합니다.
- 정책 제어: IT 관리자는 그룹 정책 및 ADMX 정책을 통해 WSL 컨테이너를 관리할 수 있습니다. 전체 Intune 대시보드 지원도 곧 제공될 예정입니다.
- 개발 도구: VS Code의 Dev Containers 확장은
wslc를 지원하며, 최소한의 설정 변경만 필요합니다.
WSL 컨테이너의 현재 한계
유망하지만, 현재 WSL 컨테이너에는 몇 가지 한계가 있습니다:
- Docker Compose 지원이 없어
compose.yaml파일이 필요한 다중 서비스 프로젝트에는 적합하지 않습니다. - 이미지를 스캔하는 Docker Scout와 같은 GUI 대시보드 또는 기능이 없습니다.
- Docker Desktop에 비해 방대한 플러그인 생태계가 부족합니다.
Microsoft는 VPN 및 프록시 문제를 해결하는 Windows 네트워킹 스택을 통해 리눅스 트래픽을 라우팅하는 Consomme와 같은 실험적 네트워킹 기능을 도입했습니다. 이러한 기능과 더불어 virtiofs 파일 시스템은 더 빠른 파일 접근을 제공하며, 현재는 WSL 컨테이너에 독점적으로 제공되지만, 향후 일반 WSL 배포판에도 확장될 가능성이 있습니다.
Docker Desktop에서 전환해야 할까요?
단일 컨테이너 시나리오의 경우, WSL 컨테이너는 Docker Desktop에 대한 실용적인 대안입니다. 특히 별도의 라이선스가 필요하지 않기 때문입니다. 그러나 Compose 파일, 다중 서비스 또는 Docker의 플러그인 생태계를 포함한 복잡한 워크플로우에는 Docker Desktop이 여전히 더 완전한 솔루션입니다.
Microsoft는 WSL 컨테이너의 일반적인 가용성을 2026년 가을까지 목표로 삼고 있습니다. CLI는 Docker와 유사하여, 부족한 기능들이 시간이 지나면서 추가될 가능성이 높습니다. 현재로서는 WSL 컨테이너를 Docker Desktop과 함께 실행하여 이 새로운 기능을 비용 없이 탐색할 수 있습니다.
