WSL2 on kenji.blog

Hyper-V vs WSL2: Windows의 가상화 기술 비교

Sun, 13 Sep 2026 07:00:00 +0900

1. 소개: Windows에서의 가상화 진화

Windows 플랫폼에서의 가상화 기술은 최근 수십 년 동안 극적인 진화를 이루었습니다. 과거에는 서드파티 Type 2 하이퍼바이저(VMware Workstation이나 VirtualBox 등)가 주류였으나, Microsoft가 Windows Server 2008에서 ‘Hyper-V’를 도입한 이후 Type 1 하이퍼바이저가 데스크톱 OS인 Windows 10/11에도 내장되기 시작했습니다.

그리고 최근 개발자들 사이에서 가장 주목받고 있는 것이 ‘WSL2 (Windows Subsystem for Linux 2)‘입니다. WSL1이 시스템 호출 변환(Translation)에 의존했던 반면, WSL2는 Hyper-V 기술을 응용한 ‘경량 유틸리티 VM (Lightweight Utility VM)‘을 채택하여 완벽한 Linux 호환성과 비약적인 성능 향상을 실현했습니다.

본 기사에서는 이 두 가지 강력한 가상화 기술, 즉 모든 기능을 갖춘 ‘Hyper-V’와 개발자 경험에 특화된 ‘WSL2’의 아키텍처, 성능(CPU, 메모리, 디스크 I/O), 네트워크 구성, 그리고 최적의 사용 사례에 대해 깊이 있는 기술적 세부 사항과 함께 철저하게 비교 및 해설합니다.

2. 하이퍼바이저의 기초 이론과 아키텍처 비교

가상화 기술을 이해하는 데 있어 필수적인 것이 하이퍼바이저(가상 머신 모니터: VMM)의 유형 분류입니다.

2.1. Type 1과 Type 2 하이퍼바이저의 차이

하이퍼바이저는 하드웨어에 대한 접근을 추상화하여 여러 OS(게스트 OS)를 단일 물리적 머신 위에서 동시에 실행하게 해주는 소프트웨어 계층입니다.

Type 1(베어메탈형): 하드웨어 위에서 직접 실행됩니다. 호스트 OS라는 개념이 존재하지 않으며(엄밀히 말해 특권을 가진 관리 OS가 존재할 수 있습니다), 오버헤드가 매우 낮고 높은 성능과 보안을 제공합니다. 예: Hyper-V, VMware ESXi, Xen.
Type 2(호스트형): 호스트 OS(Windows나 macOS 등) 위에서 애플리케이션으로 실행됩니다. 모든 하드웨어 접근은 호스트 OS를 거치기 때문에 오버헤드가 큽니다. 예: VMware Workstation, Oracle VirtualBox.

Windows의 Hyper-V는 순수한 Type 1 하이퍼바이저입니다. Hyper-V를 활성화하면, 사실 평소 사용자가 조작하는 Windows OS 자체도 ‘루트 파티션(Root Partition)‘이라 불리는 특수한 가상 머신 안에서 동작하게 됩니다.

2.2. Hyper-V 아키텍처 상세

Hyper-V 아키텍처는 마이크로커널 설계를 채택하고 있으며, 파티션(Partition)이라는 논리적 분리 단위를 기반으로 합니다.

graph TD
A["하드웨어 (CPU, RAM, Disk, NIC)"] --> B["Windows 하이퍼바이저 (Ring -1)"]
B --> C["루트 파티션 (Windows OS)"]
B --> D["자식 파티션 1 (Windows VM)"]
B --> E["자식 파티션 2 (Linux VM)"]
C --> F["VMBus (가상 머신 버스)"]
D --> F
E --> F
C --> G["VID (가상화 인프라 드라이버)"]
C --> H["VMWP.exe (워커 프로세스)"]

Windows 하이퍼바이저: CPU의 가장 높은 특권 수준(Ring -1 또는 VMX Root Mode)에서 동작하며, 메모리 할당과 CPU 스케줄링만을 담당합니다. 디바이스 드라이버는 포함되어 있지 않습니다.
루트 파티션: 호스트 Windows OS가 동작하는 파티션입니다. 모든 디바이스 드라이버를 가지며, 하드웨어를 직접 제어합니다. 또한, 자식 파티션의 관리 기능(WMI 프로바이더나 VMWP.exe 등)을 제공합니다.
자식 파티션: 게스트 OS가 동작하는 파티션입니다. 하드웨어에 대한 직접 접근은 허용되지 않으며, ‘VMBus’라는 논리적 메모리 공유 버스를 통해 루트 파티션으로 I/O 요청을 전송(Synthetic I/O)합니다.

2.3. WSL2와 Lightweight Utility VM의 작동 원리

WSL2는 Hyper-V와 동일한 Type 1 하이퍼바이저 기반 기술을 사용하지만, 모든 기능을 갖춘 Hyper-V 가상 머신과는 다른 ‘가상 머신 플랫폼(Virtual Machine Platform: VMP)‘이라는 서브셋 기능을 이용합니다.

WSL2에 채택된 ‘경량 유틸리티 VM (Lightweight Utility VM)‘은 기존 VM이 갖는 레거시 하드웨어 에뮬레이션(가상 BIOS나 가상 마더보드 등)을 완전히 배제했습니다.

graph TD
A["Windows 호스트 OS (유저 스페이스)"]
B["NTFS 파일 시스템"]
C["9P 프로토콜 서버 (Plan 9)"]
D["경량 유틸리티 VM (Linux 커널)"]
E["ext4.vhdx (가상 디스크)"]
F["Linux 유저 스페이스 (WSL2 배포판)"]
A --> C
C -->| 크로스 OS 파일 공유 | D
D --> E
D --> F

WSL2의 가장 큰 특징은 빠른 시작 속도와 호스트 OS와의 매끄러운 통합입니다. 수 초 내에 Linux 커널이 부팅되며, Windows 측의 파일 시스템(NTFS)에는 Plan 9의 9P 네트워크 파일 시스템 프로토콜을 통해 접근합니다.

3. 성능 철저 분석: 컴퓨팅 리소스와 I/O

가상 머신의 성능은 CPU, 메모리, 그리고 디스크 I/O의 각 구성 요소에서 발생하는 오버헤드의 총합으로 나타납니다.

3.1. CPU와 컨텍스트 스위치 오버헤드

Hyper-V와 WSL2는 모두 하드웨어 지원 가상화(Intel VT-x / AMD-V)를 사용합니다. CPU 명령어는 기본적으로 네이티브 속도로 실행되지만, 특권 명령어를 실행하거나 I/O를 처리할 때는 ‘VM Exit’라 불리는 인터럽트가 발생하여 하이퍼바이저로 컨텍스트 스위치가 일어납니다.

이때의 CPU 오버헤드 $T_{overhead}$는 다음과 같은 수학적 모델로 표현할 수 있습니다.

$$ T_{overhead} = \sum_{i=1}^{N} (t_{vm\_exit} + t_{hypercall\_process} + t_{vm\_entry}) $$

여기서:

$N$: 단위 시간당 VM Exit 발생 횟수
$t_{vm\_exit}$: 게스트에서 하이퍼바이저로의 전환 시간
$t_{hypercall\_process}$: VMBus를 통한 I/O 처리 및 인터럽트 처리 시간
$t_{vm\_entry}$: 하이퍼바이저에서 게스트로의 복귀 시간

WSL2는 레거시 에뮬레이션이 없기 때문에 $t_{hypercall\_process}$가 극히 작게 최적화되어 있습니다. 따라서 순수한 CPU 연산(예: 커널 컴파일이나 머신 러닝 모델 추론)에서는 베어메탈 환경과 비교해도 수 퍼센트 이내의 성능 저하에 그칩니다.

3.2. 메모리 할당 메커니즘

메모리 관리 기법에 있어서 두 기술은 명확한 설계 철학의 차이를 보입니다.

Hyper-V (동적 메모리): 게스트 VM의 메모리 수요에 따라 루트 파티션이 동적으로 메모리를 할당하고 회수합니다. 하지만 게스트 OS 내에서 페이지 캐시로 확보된 메모리는 시스템에 여유가 없는 이상 쉽게 해제되지 않는 경향이 있습니다.
WSL2 (동적 메모리 회수): WSL2는 독자적인 방식을 가지고 있어, Linux VM 내에서 불필요해진 메모리(캐시 포함)를 정기적으로 Windows 호스트에 반환(Reclaim)합니다. 초기 WSL2에서는 Linux의 페이지 캐시가 Windows의 메모리를 모두 소진하는 문제(Vmmem 프로세스 비대화)가 있었으나, 현재는 커널 패치를 통해 개선되었습니다.

3.3. 디스크 I/O 특성 (VHDX vs ext4.vhdx)

가상 머신 성능에서 가장 병목 현상이 발생하기 쉬운 곳이 디스크 I/O입니다.

I/O 레이턴시 $L_{total}$은 다음과 같이 계산됩니다.

$$ L_{total} = L_{guest\_fs} + L_{vmbus} + L_{host\_fs} + L_{physical\_disk} $$

Hyper-V의 경우: 일반적인 Hyper-V 게스트는 VHDX 포맷의 가상 디스크를 사용합니다. 게스트 OS 내의 파일 시스템(ext4 또는 NTFS)에서 발생한 I/O 요청은 VMBus의 블록 디바이스 스토리지 드라이버(storvsc)를 통과하여 Windows 측 NTFS 상의 VHDX 파일에 대한 접근으로 처리됩니다.

WSL2의 경우: WSL2의 Linux 배포판은 전용 ext4.vhdx 파일 내에 구축된 네이티브 ext4 파일 시스템 위에서 동작합니다. Linux 내에서의 파일 조작(~ 디렉터리 등)은 위에서 언급한 Hyper-V와 동등한 네이티브 성능을 발휘합니다. 하지만, WSL2의 Linux에서 Windows 측의 파일(/mnt/c/ 등)에 접근할 경우, 혹은 그 반대의 경우, 처리 방식이 크게 달라집니다. 이러한 크로스 OS 접근에는 9P (Plan 9 File System Protocol)가 사용됩니다.

$$ L_{cross\_os} = L_{9p\_client} + L_{socket\_transfer} + L_{9p\_server} + L_{ntfs} $$

이 9P 프로토콜을 경유한 접근은 직렬화(Serialize) 처리의 오버헤드가 커서, 작은 파일을 대량으로 읽고 쓰는 용도(예: Windows 측 디렉터리에 위치한 Node.js 프로젝트에서의 npm install이나 Git 조작)에서는 성능이 현저히 떨어집니다(때로는 10배 이상의 지연 발생). 그러므로, WSL2를 사용할 때는 반드시 프로젝트 파일을 Linux의 네이티브 파일 시스템(~/ 산하)에 배치하는 것이 철칙입니다.

4. 네트워크 구조: NAT, Default Switch, Bridged

네트워크 기능의 유연성은 Hyper-V와 WSL2의 큰 차이 중 하나입니다.

4.1. WSL2의 네트워크 (NAT 기반)

WSL2의 네트워크는 기본적으로 Hyper-V의 가상 스위치 기술을 사용한 ‘NAT (Network Address Translation)’ 구성으로 되어 있습니다. Linux VM에는 Windows 호스트와는 다른 사설 IP 주소(예: 172.20.x.x)가 자동으로 할당됩니다. Windows 호스트에서는 localhost를 통해 WSL2 내에서 실행된 서비스(포트)로 포워딩되는 구조가 내장되어 있어, 개발자는 네트워크를 의식하지 않고도 웹 서버 등을 테스트할 수 있습니다.

최근 WSL2에는 ‘Mirrored 모드’라는 새로운 네트워크 모드가 프리뷰 버전으로 도입되었습니다. 이를 통해 IPv6 지원 및 VPN 연결 호환성이 향상되었습니다(.wslconfig에서 설정 가능).

4.2. Hyper-V의 가상 스위치 (Virtual Switch)

Hyper-V는 엔터프라이즈 수준의 고도화된 네트워크 구축이 가능합니다. ‘가상 스위치 관리자’를 통해 주로 세 가지 모드를 제공합니다.

외부 (External): 호스트 머신의 물리적 NIC를 가상 스위치에 바인딩하여, 게스트 VM을 물리적 네트워크에 직접 참여시킵니다(브리지 연결). VM은 DHCP 서버로부터 물리 네트워크와 동일한 서브넷의 IP를 얻습니다.
내부 (Internal): 호스트 OS와 VM 간, 그리고 VM 간의 통신만을 허용합니다. 외부 네트워크로 직접 나갈 수는 없습니다.
프라이빗 (Private): VM 간의 통신만을 허용하며, 호스트 OS와의 통신도 차단합니다. 격리된 검증 환경을 구축할 때 사용됩니다.

4.3. PowerShell을 이용한 고급 Hyper-V 네트워크 구축

개발이나 테스트 환경에서 VM용으로 사용자 정의된 NAT 네트워크를 구축하고 싶을 경우, PowerShell을 사용하면 세밀한 제어가 가능합니다. 다음은 내부 가상 스위치를 생성하고, 여기에 NAT를 구성하여 VM에 인터넷 액세스를 제공하는 스크립트 예시입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. 내부 가상 스위치 생성
$SwitchName = "HyperV-NatSwitch"
New-VMSwitch -SwitchName $SwitchName -SwitchType Internal

# 2. 호스트 측 가상 NIC에 IP 주소 설정 (게이트웨이가 될 IP)
$GatewayIP = "192.168.100.1"
$NetPrefix = 24
$InterfaceAlias = "vEthernet ($SwitchName)"
New-NetIPAddress -IPAddress $GatewayIP -PrefixLength $NetPrefix -InterfaceAlias $InterfaceAlias

# 3. NAT 네트워크 구성
$NatName = "HyperV-NatNetwork"
$NatSubnet = "192.168.100.0/24"
New-NetNat -Name $NatName -InternalIPInterfaceAddressPrefix $NatSubnet

# 확인용 명령어
Get-NetNat

이 구성을 통해 지정한 Hyper-V 게스트에 수동으로 192.168.100.x의 IP와 게이트웨이 192.168.100.1을 설정함으로써, 호스트를 경유해 외부와 통신 가능한 독자적인 NAT 세그먼트를 구축할 수 있습니다.

5. 사용 사례와 실전 선택 가이드

지금까지의 아키텍처와 성능 차이를 바탕으로, 어떤 상황에서 어떤 기술을 채택해야 할지 정의합니다.

5.1. WSL2를 선택해야 하는 시나리오

WSL2는 ‘개발자의 생산성 향상’에 특화되어 설계되었습니다. 다음과 같은 용도에 최적입니다.

웹 개발 및 클라우드 네이티브 개발: Docker Desktop(WSL2 백엔드)이나 Podman을 사용한 컨테이너 개발.
Linux 전용 도구 사용: bash, grep, awk, sed 또는 Linux용 GCC나 Clang 컴파일러를 일상적으로 사용하는 경우.
GUI 애플리케이션 (WSLg): Linux의 X11/Wayland 애플리케이션을 Windows 데스크톱 위에서 매끄럽게 실행하고 싶은 경우.
머신 러닝 및 AI 개발: GPU 패스스루 기능(NVIDIA CUDA on WSL)을 이용한 TensorFlow나 PyTorch의 고속 학습.

주의점: 커널을 세밀하게 커스터마이즈하고 싶거나, systemd에 강하게 의존하는 복잡한 서비스(현재 systemd는 지원되지만, 기본적으로 비활성화되어 있거나 제한이 있음)를 구축할 경우에는 제약이 따를 수 있습니다.

5.2. Hyper-V를 선택해야 하는 시나리오

Hyper-V는 ‘인프라스트럭처의 가상화와 완전한 격리’를 목적으로 합니다. 다음과 같은 용도에서는 필수가 됩니다.

Windows VM 실행: 다른 버전의 Windows(Windows Server나 오래된 Windows 10 등)를 테스트 환경으로 실행하는 경우.
중첩 가상화 (Nested Virtualization): 가상 머신 안에서 또 다른 가상 머신(Hyper-V나 KVM)을 실행하고 싶은 경우. 인프라 엔지니어의 검증 환경에 필수적입니다.
고급 네트워크 요구사항: 외부 브리지 연결(동일 LAN 참여), VLAN 태깅, 다중 NIC 할당 등 네트워크 구성을 엄격하게 제어해야 하는 경우.
스냅샷 (체크포인트): VM의 특정 시점 상태를 저장하고 언제든 즉시 롤백할 수 있는 기능. 소프트웨어의 파괴적인 테스트나 악성코드 분석 등에 매우 유용합니다.
고정 리소스 할당: CPU 코어 수나 메모리 양을 엄격하게 고정하여 호스트 OS에 미치는 영향을 최소화하고 싶은 경우.

6. 수학적 모델을 통한 I/O 처리량 고찰 (부록)

시스템 엔지니어로서 두 기술의 I/O 성능 한계를 파악할 때, 처리량(Throughput) $S$와 블록 크기 $B$의 관계를 이론적으로 이해하는 것은 중요합니다.

데이터 전송의 처리량 $S$는 단위 시간당 데이터 전송량이며, 다음과 같이 모델링됩니다.

$$ S(B) = \frac{B}{L_{setup} + \frac{B}{R_{max}}} $$

$B$: 블록 크기 (Bytes)
$L_{setup}$: I/O 요청 설정 및 컨텍스트 스위치에 수반되는 고정 레이턴시
$R_{max}$: 복사나 디바이스 전송 시 하드웨어의 최대 대역폭

WSL2의 9P 프로토콜을 통한 파일 접근에서는 이 $L_{setup}$이 매우 큽니다(소켓 통신과 프로토콜의 직렬화/역직렬화 때문). 따라서 블록 크기 $B$가 작을 경우(수 KB 정도의 작은 파일에 대한 대량의 읽기/쓰기), 분모에서 $L_{setup}$의 영향이 지배적이게 되어 처리량 $S$는 극적으로 떨어집니다. 반대로 Hyper-V의 VMBus를 경유하는 VHDX 접근에서는 $L_{setup}$이 하드웨어 인터럽트에 가까운 수준까지 최적화되어 있으므로, 작은 크기의 블록에서도 높은 IOPS를 유지할 수 있습니다.

이러한 수학적 현실이 “WSL2에서는 프로젝트 파일을 Windows 측에 두면 안 된다"는 모범 사례의 논리적 근거가 됩니다.

7. 결론: 공존하는 두 가지 가상화 기술

Hyper-V와 WSL2는 어느 한쪽이 우수하다는 것이 아니라, **‘목적이 다른 두 가지 솔루션’**입니다.

WSL2는 Windows라는 OS의 틀을 깨고, Linux 생태계를 매끄럽고 빠르게 Windows 사용자에게 전달하기 위한 ‘최고의 통합 도구’입니다. 개발자를 위한 궁극의 CLI 환경이라 해도 과언이 아닙니다.
Hyper-V는 엔터프라이즈 데이터 센터에서 축적된 강력한 격리성과 관리 기능을 데스크톱으로 가져온 ‘본격적인 하이퍼바이저’입니다. 네트워크 구축, Windows OS 테스트, 인프라 환경 시뮬레이션에 있어서 타의 추종을 불허합니다.

현대의 Windows 환경에서 이 두 기술은 대등하게 경쟁하는 것이 아니라, 동일한 VM 플랫폼 위에서 아름답게 공존합니다. 목적에 맞게 적재적소에 활용함으로써, Windows는 세계에서 가장 강력하고 유연한 엔지니어링 워크스테이션이 될 것입니다.

WSL2(Windows Subsystem for Linux) 궁극의 개발 환경 설정 가이드

Sat, 12 Sep 2026 23:00:00 +0900

Windows 상에서 Linux 네이티브 개발 환경을 제공하는 ‘WSL2(Windows Subsystem for Linux 2)‘는 현대 소프트웨어 개발에서 필수 불가결한 도구가 되었습니다. 하지만 기본 상태로 계속 사용하는 것과 아키텍처를 이해하고 적절하게 튜닝을 적용하는 것은 성능과 개발 경험에 엄청난 차이를 가져옵니다.

본 문서에서는 WSL2의 근간을 이루는 아키텍처 해설을 시작으로, 성능을 최대한으로 끌어올리기 위한 설정, 쾌적한 터미널 환경 구축, Docker 및 VS Code와의 원활한 연동, 그리고 고급 네트워크 설정까지 전문 엔지니어가 요구하는 ‘궁극의 개발 환경’을 구축하기 위한 모든 절차를 1만 자 이상의 분량으로 철저하게 해설합니다.

1. WSL2의 아키텍처와 WSL1으로부터의 진화

WSL2의 잠재력을 완전히 이끌어내기 위해서는 먼저 그 내부 구조를 이해하는 것이 중요합니다. 1세대 WSL(WSL1)과 WSL2는 Linux 바이너리를 Windows 상에서 실행하기 위한 접근 방식이 근본적으로 다릅니다.

WSL1: 시스템 콜 변환 레이어

WSL1은 Linux의 시스템 콜을 실시간으로 Windows의 NT API로 변환(트랜슬레이션)하는 구조를 채택했습니다. 이는 가상 머신(VM)을 사용하지 않기 때문에 리소스 오버헤드가 매우 적다는 장점이 있었습니다. 하지만 파일 시스템의 I/O 작업 등 복잡한 시스템 콜을 완벽하게 에뮬레이션하기는 어려웠고, 특히 Node.js의 npm install이나 Git의 리포지토리 조작 등 다량의 작은 파일을 다루는 처리에서 절망적인 성능 저하를 초래했습니다.

WSL2: 경량 유틸리티 VM과 완전한 Linux 커널

WSL2에서는 아키텍처가 쇄신되어 Hyper-V 아키텍처의 서브셋을 이용한 ‘경량 유틸리티 VM’ 위에서 Microsoft가 빌드한 실제 Linux 커널이 직접 가동되게 되었습니다. 이로써 시스템 콜의 100% 호환성이 보장되었고, Linux 네이티브의 ext4 파일 시스템을 이용한 가상 디스크(VHDX)를 사용함으로써 파일 I/O 성능이 WSL1과 비교하여 극적으로 향상되었습니다.

아래의 Mermaid 다이어그램은 WSL1과 WSL2의 구조적인 차이를 보여줍니다.

flowchart TD
subgraph "Windows OS Environment"
A["Windows NT 커널"]
A --> F["NTFS 파일 시스템 (C: 드라이브)"]
end
subgraph "WSL2 Architecture"
B["Hyper-V 하이퍼바이저"]
B --> C["경량 유틸리티 VM"]
C --> D["Linux 커널 (Microsoft)"]
D --> E["Ubuntu 사용자 공간 (glibc, bash 등)"]
D --> G["ext4 가상 디스크 (.vhdx)"]
end
A -.->|"Plan 9 (9P) 프로토콜 네트워크 파일 공유"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

이 구조에서 얻을 수 있는 중요한 교훈은 **“Linux 측의 파일(VHDX 내)에 대한 접근은 매우 빠르지만, Windows 측의 파일(/mnt/c/)에 대한 접근은 9P 프로토콜을 거치기 때문에 매우 느리다”**는 것입니다. 프로젝트의 소스 코드는 반드시 WSL 측의 홈 디렉토리(~) 아래에 배치해야 합니다.

2. 성능의 수학적 분석: 왜 WSL2는 빠른가?

WSL2의 성능 향상을 수학적인 모델을 사용하여 정량적으로 평가해 보겠습니다. 소프트웨어 개발에서 가장 시간이 많이 걸리는 작업 중 하나가 다량의 파일 I/O를 수반하는 처리(예: 라이브러리 설치나 빌드)입니다.

어떤 처리 전체의 실행 시간 $T_{total}$ 은 CPU에 의한 연산 시간 $T_{compute}$ 와 디스크 I/O에 걸리는 시간 $T_{io}$ 의 합으로 표현됩니다.

$$ T_{total} = T_{compute} + T_{io} $$

WSL1의 경우, Linux 측의 조작을 NTFS의 조작으로 변환하는 오버헤드가 발생하기 때문에, I/O 시간은 다음과 같이 모델링됩니다. 여기서 $n$ 은 파일 조작 횟수, $t_{ntfs\_syscall}$ 은 Windows 측의 시스템 콜 실행 시간, $t_{trans}$ 는 변환 레이어의 오버헤드입니다.

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

반면, WSL2의 경우 ext4 파일 시스템에 대해 커널이 직접 I/O를 발행하기 때문에, 오버헤드는 가상화로 인한 아주 약간의 지연 $t_{virt}$ 뿐입니다.

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

일반적인 파일 시스템에서 $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$ 이므로, $n$ 이 매우 큰(수만~수십만 개의 파일 조작을 수행하는) 경우 WSL1과 WSL2의 I/O 시간 차이는 지수함수적으로 벌어집니다.

또한, 가상화 환경에서의 CPU 연산 오버헤드 비율을 $\rho$ 라고 하면, 최신 하드웨어 지원 가상화(Intel VT-x / AMD-V)에서는 $\rho \approx 0.01 \sim 0.03$ (1~3%) 정도에 머뭅니다. 따라서 순수한 계산 작업에서도 네이티브 Linux 환경과 손색없는 $97\% \sim 99\%$ 의 성능이 발휘됩니다.

3. 설치와 기반 구축

Windows 10/11에서는 WSL2의 설치가 매우 간단해졌습니다. 관리자 권한으로 PowerShell을 열고 다음 명령어를 실행하기만 하면 됩니다.

1
2
3
4
5
6


# 기본적으로 WSL2와 Ubuntu가 설치됩니다
wsl --install

# 특정 배포판을 지정할 경우
# wsl --list --online 으로 확인 가능
wsl --install -d Ubuntu-24.04

설치 후 재부팅을 거쳐 첫 실행 시 UNIX 사용자 이름과 비밀번호 설정을 요구받게 됩니다. 이 사용자는 Windows 사용자와 독립적이며, WSL 내에서만 유효합니다.

이미 WSL1을 사용하고 있는 경우에는 다음 명령어로 WSL2로 변환합니다.

1
2
3
4
5


# 기존 배포판을 WSL2로 변환
wsl --set-version Ubuntu 2

# 향후 추가할 배포판의 기본값을 WSL2로 설정
wsl --set-default-version 2

4. 리소스 제어의 비결: .wslconfig 와 wsl.conf

WSL2의 가장 큰 함정 중 하나가 ‘메모리의 무제한 소비(Vmmem 프로세스의 비대화)‘입니다. WSL2는 Linux 커널의 페이지 캐시를 이용하기 때문에, I/O를 수행할 때마다 호스트(Windows)의 메모리를 끝없이 잠식해 들어갑니다. 이를 방지하기 위해 설정 파일을 통한 리소스 제한이 필수적입니다.

WSL2의 설정 파일은 Windows 전체에 영향을 미치는 .wslconfig 와 각 배포판의 내부에 영향을 미치는 wsl.conf 의 두 가지로 나뉩니다.

4.1. .wslconfig (Windows 측)

Windows의 사용자 프로필 디렉토리(C:\Users\<사용자명>\.wslconfig)에 파일을 생성하여 VM에 대한 리소스 할당을 제어합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<사용자명>\.wslconfig
[wsl2]
# VM에 할당할 최대 메모리 양. 호스트 총 메모리의 50%~75% 정도를 권장
memory=16GB

# 사용할 CPU 코어 수(생략 시 모든 코어 사용)
processors=8

# 스왑 파일의 크기
swap=8GB

# 스왑 파일의 저장 위치(C 드라이브의 용량을 절약하고 싶은 경우)
# swapfile=D:\\wsl\\swap.vhdx

# localhost 포워딩 활성화(Windows 측에서 localhost로 WSL에 접근하기 위해)
localhostForwarding=true

# 메모리를 자동으로 확보(Windows 11 전용)
# 페이지 캐시를 동적으로 해제하여 Vmmem의 비대화를 방지
autoMemoryReclaim=dropcache

[experimental]
# Windows 11 22H2 이후에서 이용 가능한 고급 네트워크 기능
# 이를 통해 IPv6 지원이나, WSL과 Windows 간의 동일한 IP 주소 공유가 가능해짐
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (Linux 측)

WSL 내의 /etc/wsl.conf 를 편집하여, 배포판 고유의 동작을 제어합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (WSL 내부에서 편집)
[network]
# WSL 시작 시 자동 생성되는 /etc/resolv.conf 의 생성을 비활성화
# 자체 DNS(예: 8.8.8.8)를 설정하고 싶은 경우에 유용
generateResolvConf=false

# 자체 호스트 이름 설정
hostname=WSL-DevNode

[automount]
# Windows 드라이브를 마운트할 때의 설정
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# C 드라이브의 마운트 포인트를 /mnt/c 에서 /c 로 변경(경로를 짧게 하기 위해)
root=/

[boot]
# systemd 활성화(WSL 0.67.6 이후)
# 이를 통해 snap이나 각종 데몬(Docker 등)이 네이티브하게 작동하게 됨
systemd=true

[user]
# 기본으로 로그인할 사용자
default=kenji

이러한 설정을 반영하기 위해서는 PowerShell에서 wsl --shutdown 을 실행하여, WSL VM을 완전히 정지시킨 후 재시작해야 합니다.

5. 궁극의 터미널 환경: Zsh + Powerlevel10k

기본 bash 상태로는 생산성이 오르지 않습니다. 강력한 자동 완성 기능과 시인성을 자랑하는 Zsh에, 초고속 테마 ‘Powerlevel10k’를 결합하여 최강의 프롬프트를 구축합니다.

5.1. Windows Terminal 도입과 설정

Microsoft Store에서 ‘Windows Terminal’을 설치합니다. JSON 설정(settings.json)을 열고 기본 프로필을 WSL(Ubuntu)로 설정한 후, 폰트를 개발용 Nerd Font(예: HackGen Console NF 나 MesloLGS NF)로 변경합니다.

5.2. Zsh 및 Oh My Zsh 설치

WSL 터미널에서 다음 명령어를 실행합니다.

1
2
3
4
5
6


# 패키지 업데이트 및 Zsh 설치
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# Oh My Zsh 설치 스크립트 실행
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. Powerlevel10k와 플러그인 도입

Zsh를 더욱 강화하는 플러그인(구문 강조와 입력 자동 완성) 및 Powerlevel10k 테마를 도입합니다.

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

~/.zshrc 를 편집하여, 테마와 플러그인을 활성화합니다.

1
2
3
4
5


# ~/.zshrc의 변경점
ZSH_THEME="powerlevel10k/powerlevel10k"

# 플러그인 배열에 추가
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

저장한 후 source ~/.zshrc 를 실행하면, Powerlevel10k 설정 마법사(p10k configure)가 시작됩니다. 화면의 지시에 따라 자신이 원하는 형태의 프롬프트(프롬프트 스타일, 아이콘 유무, 표시할 정보 등)로 커스터마이즈하십시오. Git의 브랜치명이나 상태, Node.js 버전, 명령어 실행 시간 등이 실시간으로 표시되어 개발 효율이 비약적으로 향상됩니다.

6. VS Code Remote - WSL의 원활한 통합

WSL2 환경에서의 개발에 있어, Windows 측에 설치된 IDE(Visual Studio Code)에서 WSL 내의 파일에 매끄럽게 접근하는 구조가 ‘Remote - WSL’ 확장 기능입니다.

아키텍처 해설

아래의 시퀀스 다이어그램은 VS Code가 WSL2와 어떻게 통신하는지 보여줍니다.

sequenceDiagram
autonumber
participant U as "Developer"
participant V as "VS Code UI (Windows)"
participant S as "VS Code Server (WSL2)"
participant F as "ext4 File System (WSL2)"
U->>V: "WSL 터미널에서 `code .` 입력"
V->>S: "Vsock을 통해 RPC 연결 수립"
Note over V,S: TCP/IP를 사용하지 않고 Hyper-V 소켓으로 통신
S->>F: "소스 파일 읽기 / 린터 실행"
F-->>S: "데이터 및 분석 결과 반환"
S-->>V: "Language Server 결과를 UI로 스트리밍"
V-->>U: "구문 강조 및 오류 표시"

Windows 측의 VS Code는 단순한 ‘얇은 클라이언트(UI)‘로 기능하며, Language Server, 디버거, 터미널 실행 등의 무거운 처리는 모두 WSL 측의 ‘VS Code Server’에서 처리됩니다. 이를 통해 Windows 측에 Node.js나 Python을 설치하지 않고도, WSL 측에서만 환경을 깨끗하게 유지할 수 있습니다.

필수 VS Code 설정

VS Code의 ‘확장 기능’에서 “WSL” (ms-vscode-remote.remote-wsl) 을 설치합니다. 그 후 WSL의 터미널에서 프로젝트 디렉토리로 이동하여 code . 를 실행하기만 하면, 해당 디렉토리가 열린 상태로 Windows 측의 VS Code가 시작됩니다.

중요한 주의점(줄바꿈 코드 문제): Windows와 Linux는 줄바꿈 코드가 다릅니다(Windows는 CRLF, Linux는 LF). WSL 상에서 개발을 진행할 경우, Git의 core.autocrlf 설정이나 VS Code의 파일 기본 설정을 반드시 LF 로 통일해야 합니다. 이를 소홀히 하면 쉘 스크립트나 Docker 컨테이너 실행 시 알 수 없는 오류로 고생하게 됩니다.

1
2


# WSL 측에서의 Git 줄바꿈 코드 설정
git config --global core.autocrlf input

VS Code의 settings.json(원격 설정)에도 다음을 추가합니다.

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Docker Desktop과 WSL2 Integration 최적화

WSL2 환경에서 Docker를 이용하려면 주로 2가지 접근 방식이 있습니다.

Docker Desktop for Windows 를 설치하고, WSL2 통합 기능을 활성화한다.
WSL2 내부(Ubuntu 등)에 네이티브 Docker Engine 을 직접 설치한다.

접근 방식 1: Docker Desktop (권장)

GUI를 통한 관리나 Windows/WSL 간의 투명한 컨테이너 접근이 용이하기 때문에, 많은 경우 이 방식이 권장됩니다. Docker Desktop의 설정(Settings)에서 다음을 확인합니다.

General -> Use the WSL 2 based engine 에 체크합니다.
Resources -> WSL Integration -> Enable integration with my default WSL distro 에 체크하고, 토글 버튼으로 사용할 배포판(Ubuntu)을 켭니다.

이를 통해 WSL2의 터미널에서 직접 docker 명령어를 실행할 수 있게 되며, Docker 데몬과의 통신은 Docker Desktop이 관리하는 전용 경량 VM(docker-desktop 및 docker-desktop-data)을 통해 이루어집니다.

접근 방식 2: 네이티브 Docker Engine 직접 도입

기업 네트워크의 제약(Docker Desktop 유료화 회피 등)이나 성능 오버헤드를 극한까지 줄이고 싶은 경우에는, /etc/wsl.conf 에서 systemd 를 활성화한 뒤, 순수한 Ubuntu 서버로서 Docker를 설치합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# systemd가 활성화된 WSL2 Ubuntu에서의 Docker 공식 설치 절차 발췌
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# 리포지토리 추가
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

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

# 현재 사용자를 docker 그룹에 추가(sudo 없이 실행하기 위해)
sudo usermod -aG docker $USER

재부팅 후, 네이티브 Linux 환경과 완전히 동일하게 systemctl start docker 가 작동하며, 높은 성능을 발휘합니다.

8. SSH 키 통합: Windows와 WSL에서의 원활한 인증

Git의 SSH 클론이나 원격 서버에 SSH 접속을 수행할 때, Windows 측과 WSL 측에서 별도의 SSH 키를 관리하는 것은 매우 번거롭습니다. 보안과 편의성을 양립시키기 위해 Windows 측에서 가동 중인 SSH 에이전트(또는 1Password와 같은 암호 관리자)를 WSL 측에 브릿지하는 설정을 수행합니다.

여기에서는 가장 안전하고 모던한 접근 방식으로, 1Password의 SSH 에이전트 기능 또는 Windows의 OpenSSH Authentication Agent 를 이용하고, npiperelay 나 socat 을 사용하여 WSL2의 UNIX 도메인 소켓으로 포워딩하는 방법을 설명합니다.

ssh-agent의 소켓 포워딩

일반적으로 Windows의 Named Pipe(명명된 파이프)로 제공되는 SSH 에이전트를 WSL 측의 소켓 파일로 변환할 필요가 있습니다. wsl-ssh-agent 나 1Password가 제공하는 기능을 이용하면 간단합니다.

1Password의 설정 화면에서 ‘Developer’ -> ‘SSH 에이전트 사용’을 활성화합니다. 그 다음, WSL 측의 ~/.zshrc 또는 ~/.bashrc 에 다음 설정을 추가하여 로그인 시 자동으로 소켓을 바인딩하도록 합니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# ~/.zshrc 에 추가(1Password SSH Agent를 이용할 경우의 예)
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# WSL 시작 시 소켓이 존재하지 않거나, 프로세스가 바인딩되지 않은 경우 socat과 npiperelay를 사용하여 포워드
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # 백그라운드에서 socat을 시작하여, Windows 측의 Named Pipe를 WSL 측의 UNIX 소켓에 연결
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

※사전에 Windows 측에 npiperelay.exe 설치 및 환경 변수(Path) 등록 작업이 필요합니다.

이 설정이 완료되면, WSL 터미널에서 ssh-add -l 을 실행했을 때 1Password나 Windows 측에 등록한 SSH 키의 공개키 목록이 표시됩니다. 이를 통해 비밀키 편집을 WSL 내에 복사할 필요 없이 안전하게 인증을 통과할 수 있습니다.

9. 유지 보수: 비대해진 VHDX 최적화(압축)

WSL2의 가장 큰 단점 중 하나가 “Docker 이미지를 삭제하거나 파일을 삭제해도 Windows 측 가상 디스크(.vhdx)의 파일 크기가 자동으로 축소되지 않는다"는 사양입니다. 장기간 개발을 계속하다 보면 ext4.vhdx 파일이 수십 GB에서 수백 GB까지 부풀어 오릅니다.

디스크 용량을 확보하기 위해서는 주기적으로 Windows 측에서 VHDX를 최적화(Compact)해야 합니다.

먼저, WSL을 완전히 종료합니다.
1

wsl --shutdown
관리자 권한의 PowerShell을 열고, 다음의 diskpart 명령어, 또는 Hyper-V 모듈의 Optimize-VHD 명령어를 실행합니다(Hyper-V가 활성화되어 있는 경우에만 후자를 사용할 수 있습니다).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# Hyper-V 모듈을 사용할 수 있는 경우
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# diskpart를 사용하는 경우
diskpart
# 아래의 프롬프트에서 대화형으로 입력
DISKPART> select vdisk file="C:\Users\<사용자명>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

주기적으로 이 작업을 수행함으로써, 낭비되었던 C 드라이브 용량을 되찾을 수 있습니다.

10. 맺음말

WSL2는 단순한 ‘Windows 상에서 구동되는 덤으로 주는 Linux’라는 틀을 완전히 넘어서, macOS나 네이티브 Linux 머신 못지않은, 혹은 그 이상의 강력한 개발 플랫폼으로 진화했습니다.

이번에 해설한 설정(.wslconfig 를 통한 리소스 최적화, Zsh + Powerlevel10k를 통한 터미널 강화, VS Code Remote를 통한 투명한 접근, 그리고 SSH 연동 및 VHDX 유지 보수)을 모두 적용함으로써, 스트레스 없고 빠르며 안전한 ‘궁극의 개발 환경’이 완성됩니다.

환경 구축에는 약간 수고가 들어가지만, 한 번 설정을 확립해두면 향후 엔지니어링의 생산성이 극적으로 향상될 것임에 틀림없습니다. 부디 자신의 프로젝트나 취향에 맞춰 이 가이드를 바탕으로 더 나은 커스터마이징을 탐구해 보시기 바랍니다.