# WSL2는 단순한 VM이 아닌가요?

> Clean Markdown view of GeekNews topic #24765. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24765](https://news.hada.io/topic?id=24765)
- GeekNews Markdown: [https://news.hada.io/topic/24765.md](https://news.hada.io/topic/24765.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-12-02T10:23:04+09:00
- Updated: 2025-12-02T10:23:04+09:00
- Original source: [ssg.dev](https://ssg.dev/isnt-wsl2-just-a-vm/)
- Points: 9
- Comments: 2

## Summary

WSL2는 단순한 **가상머신(VM)** 이 아니라, Windows NT의 **서브시스템 철학**을 현대적으로 재해석한 결과물입니다. 초기의 **WSL1**이 리눅스 호출을 윈도우 커널로 번역하는 얇은 계층이었다면, **WSL2**는 실제 **리눅스 커널을 Hyper-V 위에서 실행**하면서도 **동적 메모리 관리·드라이브 마운트·GUI 통합(WSLg)** 등으로 일반 VM보다 훨씬 긴밀한 통합성을 보여줍니다. 파일 관리나 디스크 이미지 의존성 같은 제약은 남아 있지만, **WSL1과 WSL2를 상황에 맞게 선택할 수 있는 유연성**이 개발자에게 큰 장점으로 작용합니다. 윈도우와 리눅스의 경계가 점점 흐려지는 지금, 이 구조적 진화는 “개발 환경”의 정의를 다시 생각하게 만듭니다.

## Topic Body

- Windows NT의 **서브시스템 구조**는 다른 운영체제용 프로그램을 실행하기 위한 **API 호출 변환 계층**으로 구성되어 왔음  
- **WSL1**은 이러한 전통을 잇는 형태로, 리눅스 호출을 윈도우 커널 호출로 변환하는 **가벼운 번역 계층**으로 동작  
- **WSL2**는 성능 문제를 해결하기 위해 **Hyper-V 기반의 완전한 리눅스 VM**으로 전환되었으며, 실제 **리눅스 커널**을 실행  
- WSL2는 **동적 메모리 관리**, **Windows 드라이브 마운트**, **WSLg를 통한 GUI 통합** 등으로 일반 VM보다 **높은 통합성**을 제공  
- 파일 관리의 불편함과 디스크 이미지 의존성 등 한계가 있지만, **WSL1과 WSL2의 장단점을 선택적으로 활용할 수 있는 유연성**이 중요  

---

### Windows NT의 서브시스템 개념
- Windows NT의 **서브시스템(subsystem)** 은 다른 운영체제용 프로그램을 실행하기 위한 **API 세트와 호출 변환 계층**을 의미  
  - 과거 NT에는 **OS/2 서브시스템(OS2SS.EXE)** , **POSIX 서브시스템(PSXSS.EXE)** 등이 존재  
  - **CSRSS.EXE**는 Win32 API 변환 계층으로, 일부 기능은 커널 모드(`WIN32K.SYS`)로 이동  
- POSIX 서브시스템은 정부 인증을 위한 최소 구현 수준이었으며, 이후 **Interix 기반 Windows Services for Unix**로 대체됨  

### WSL1: 번역 기반 리눅스 계층
- **WSL1(Windows Subsystem for Linux)** 은 리눅스 시스템 호출을 윈도우 호출로 변환하는 **얇은 번역 계층**  
  - 실행 시 `bash` 프로세스만 몇 MB 메모리를 사용하며, **Task Manager에서 일반 프로세스로 표시**  
  - 루트 파일시스템은 **NTFS 상의 개별 파일 구조**로 존재해 저장 공간 오버헤드가 거의 없음  
- **제한사항**
  - **I/O 성능 저하**: 리눅스와 Win32 파일시스템 API 차이로 인한 변환 비용  
  - **GUI 실행 시 외부 X 서버 필요** (예: X410)  
  - **Raw 소켓 미지원**으로 `traceroute`, `nmap`, `tcpdump` 등 실행 불가  

### WSL2: Hyper-V 기반 리눅스 VM
- 사용자 요구에 따라 Microsoft는 **Hyper-V 위에서 동작하는 완전한 리눅스 VM**을 도입  
  - 루트 파일시스템은 **단일 VHDX 파일**로 관리  
  - 명령어 `wsl --set-version "Ubuntu" 2` 로 WSL1↔WSL2 간 변환 가능  
- **성능 특성**
  - 초기 부팅은 느리지만, **네이티브 리눅스 커널**을 실행  
  - 메모리 사용은 동적이며, **최대 물리 메모리의 절반까지 확장 가능**  
  - `stress` 테스트 결과, 메모리 사용량은 부하에 따라 증가 후 자동 축소  
  - 필요 시 `wsl --shutdown` 명령으로 VM 종료 가능  

### WSL2의 통합 기능과 한계
- WSL2는 전통적 VM과 달리 **Windows와의 통합성**을 강화  
  - **Windows 드라이브 자동 마운트**, **리눅스 드라이브를 `\\wsl$\` 경로로 접근**, **WSLg를 통한 GUI 앱 실행**  
  - GUI 앱은 **Remote Desktop 프로토콜을 통해 스트리밍**되며, DPI나 텍스트 스케일링은 별도 설정 필요  
- **파일 관리 문제**
  - 리눅스 작업 데이터는 `ext4.vhdx` 이미지 내부에 저장되어 **이식성 및 복구 위험** 존재  
  - `wsl --unregister Distro` 실행 시 **모든 데이터 즉시 삭제**  
  - Windows 드라이브(`/mnt/c`) 사용 시 **NTFS + VM 오버헤드로 성능 저하**  
- **파일시스템 프로토콜**
  - WSL1은 `drvfs`, WSL2는 **Plan9의 `9p` 프로토콜** 사용  
  - 변환 과정에서 `drvfs`가 남는 버그 발생 사례 언급  
- **대안**
  - 별도의 **VHDX 이미지 생성 후 `wsl --mount --vhd`로 마운트**하여 작업 데이터 분리 권장  
  - `.wslconfig`에서 자동 설정 불가, 스크립트로 처리 필요  

### 결론
- Windows NT의 **모듈형 설계와 안정적 커널 ABI**는 오래된 드라이버 호환성을 유지  
- **WSL1**은 가벼운 메모리 사용이 장점이며, **WSL2**는 실제 리눅스 커널로 더 높은 호환성과 성능 제공  
- WSL2는 **VM의 단점을 최소화하고 호스트 OS와의 통합을 강화**한 구조  
- 전통적 정의로는 VM에 가깝지만, **가벼운 통합형 환경**으로서 “서브시스템”이라 부를 만한 가치가 있음

## Comments



### Comment 47069

- Author: crawler
- Created: 2025-12-02T13:10:29+09:00
- Points: 1

와 개발자 쓱이 있네

### Comment 47063

- Author: neo
- Created: 2025-12-02T10:23:05+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=46039140) 
- WSL2는 Hyper-V의 **하위 집합** 위에서 동작하며, 기본적으로 하이퍼바이저 위의 VM임  
  하지만 일반 Hyper-V VM과는 다른 점이 있음. 예를 들어, WSL2의 Linux 배포판은 GPU 파티셔닝(즉, PCI/GPU 패스스루)과 DirectX의 특수 구현을 통해 X나 Wayland 환경에서도 GPU 가속을 사용할 수 있음  
  이런 기능은 PowerShell 등을 통한 해킹으로 일반 Hyper-V에서도 가능하지만, 공식적으로는 **Windows Server**에서만 지원됨
  - GPU 패스스루가 기본 Windows 11에서도 되는 줄 알았는데, 자세히 보지 않았음. 그래도 꽤 인상적인 기능임. 그래픽 관련 기능에 대해 새 글을 써볼까 생각 중임
  - 결국 그건 그냥 일반 VM이지만, 자동화된 점이 좋음  
    다만 “X나 Wayland가 렌더링을 담당한다”는 건 오해임. 실제로 GPU를 사용하는 건 애플리케이션 자체이고, X/Wayland는 렌더링이 끝난 후 **윈도우 합성** 정도만 담당함  
    색상 변환 같은 복잡한 작업도 있지만 계산량은 적음
  - WSL2와 WinNT 커널이 둘 다 Hyper-V 위에서 거의 같은 수준으로 동작하는 것 아님? 물론 NT 커널은 하드웨어 접근 권한이 더 많음
  - Linux 실행을 위해 **Windows Server 라이선스**를 사서 설치해야 한다고 상상해보면 웃김
  - WSL2의 그래픽 통합은 기대보다 실망스러웠음. 예전 X-server 설정이 더 나았음. 하지만 X는 현대 API를 지원하지 않아 개발자들이 점점 관심을 잃고 있음. WSL2 지원이 늘어나면 개선되길 바람

- WSL1은 **pico process** 기반으로, Drawbridge 연구에서 파생된 기술임  
  관련 영상 [The Linux Kernel Hidden Inside Windows 10](https://youtu.be/_p3RtkwstNk?si=V9vhvrdDOLu2Durr)과 [WSL Pico Process Overview](https://learn.microsoft.com/de-de/archive/blogs/wsl/pico-process-overview) 참고  
  같은 Drawbridge 기술이 SQL Server를 Linux에서 실행할 때도 사용됨  
  [Ars Technica 기사](https://arstechnica.com/information-technology/2016/12/how-an-old-drawbridge-helped-microsoft-bring-sql-server-to-linux/)에 자세히 나와 있음

- WSL2로 전환한 이유는 이해하지만, WSL1 개발을 완전히 중단한 건 아쉬움  
  우리 CI 환경은 대부분 Linux 기반이지만, 일부 툴체인은 Wine에서 잘 안 돌아감(MSVC 같은 경우)  
  그래서 Windows에서 Linux 빌드를 원활히 실행할 수 있는 환경이 필요했음. WSL1은 이게 가능했지만, WSL2는 **프로세스 네임스페이스**나 파일 디스크립터를 공유하지 않아 여러 **우회 방법**이 필요함  
  IO 속도는 빨라졌지만, 파일 공유가 느려서 실사용에는 부적합함
  - WSL2에서도 `/mnt/c`를 통해 Windows 파일 접근은 가능함
  - MSVC 대신 [clang-cl](https://clang.llvm.org/docs/MSVCCompatibility.html)과 [xwin](https://github.com/Jake-Shadle/xwin)을 조합해보는 것도 방법임.  
    예전에 Python C 확장 모듈을 이 방식으로 빌드해본 적 있음

- WSL2는 Windows 환경과 **매우 긴밀히 통합된 VM**임  
  회사 정책상 Windows를 써야 해서 개발용으로 매일 사용 중인데, 대부분의 경우 꽤 쾌적함
  - 회사에서 제공한 VM으로 작업 중인데 성능이 점점 답답해짐. WSL2로 바꿔볼까 고민 중임.  
    다만 RHEL8 기반이라 Debian 계열만 지원하는 게 불편함. 그래픽 앱 지원은 요즘 어떤지 궁금함
  - “긴밀한 통합”이라는데, 실제로는 `ps`나 `top`에서 VM 프로세스만 보임.  
    `docker run -it ubuntu`로도 비슷한 기능이 가능한데, 어떤 점이 다른지 궁금함.  
    개인적으로는 **분리된 작업공간**이 너무 불편했음

- WSL2는 결국 **가벼운 VM**임. Firecracker와 비슷한 개념으로, 빠른 부팅과 낮은 메모리 사용을 목표로 함  
  하지만 Docker를 여러 개 돌리면 메모리 요구량이 커짐. 최소 20GB 이상은 있어야 쾌적함
  - 다행히 요즘은 32GB 램 노트북도 예전처럼 비싸지 않음
  - WSL2 부팅이 1~2초로 매우 빠른데, 어떻게 구현했는지 궁금함. BIOS 화면을 생략하는 건 알겠지만, 그 외에도 뭔가 최적화가 있는 듯함

- 개인적으로 WSL1이 훨씬 유용함. C++과 .NET 툴체인, ssh/scp 등 대부분의 **CLI 도구**가 잘 작동함  
  반면 WSL2는 쓸모가 거의 없음. Linux VM이 필요하면 VMware를 씀  
  VMware는 **스냅샷 트리**, **3D 가속**, **USB 장치 연결**, **가상 네트워크 구성** 등 기능이 풍부하고 GUI도 편리함

- WSL 내부 VM 디스크는 `\\wsl$` 경로로 접근 가능함  
  오래된 소프트웨어가 UNC 경로를 지원하지 않으면 드라이브 문자로 매핑해서 해결 가능함

- VHDX 파일이 계속 커지는 문제가 있음. 수동으로 **압축(compact)** 해야 함
  - **sparse VHD**를 활성화하면 도움이 됨. 완벽하진 않지만 `systemd-trim` 서비스로 일부 해결 가능함  
    관련 이슈는 [GitHub WSL #12103](https://github.com/microsoft/WSL/issues/12103) 참고  
    그래도 안 되면 [수동 최적화 방법](https://superuser.com/questions/1827953/reclaim-wsl2-disk-space-after-setting-it-to-sparse#1834374)을 사용할 수 있음
  - 자동 축소 기능이 있긴 하지만, 오히려 문제를 일으킬 때도 있음

- 참고로 WSL은 기본적으로 **Windows 방화벽 규칙을 우회**함. 왜 Microsoft가 이렇게 설계했는지 의문임
  - 정말 그런가? WSL에서 ssh 연결이 잘 안 돼서 항상 고생했음

- 실제 ext4 파티션을 마운트해서, 이미지 파일 기반 블록 디바이스 시뮬레이션으로 인한 **성능 손실**을 줄일 수 있을지 궁금함