Windows 가상화의 심층(제3회) ── 몇 초 만에 시작되는 가상 머신: WSL2·Windows Sandbox·컨테이너가 가벼운 이유

풀 VM은 무거운데 WSL2와 Windows Sandbox는 왜 가벼울까요. 연재 마지막 회는 「무엇을 격리하는가」뿐 아니라 「무엇을 복제하지 않아도 되는가」에서 그 차이를 설명합니다.

Hyper-V 관리자로 Windows VM을 만들면 부팅에 수십 초가 걸리고 수 GB의 메모리를 점유합니다. 반면 같은 PC에서 wsl이라고 치면 Linux 셸이 몇 초 안에 돌아오고, Windows Sandbox도 몇 초 만에 일회용 데스크톱을 엽니다.¹

토대는 어느 쪽이든 제1회에서 본 Windows 하이퍼바이저입니다. 제2회에서는 그 토대를 써서 커널보다 강한 격리를 만들 수 있다는 점을 확인했습니다. 이 글에서는 WSL2의 용도 특화, Sandbox의 공유, 컨테이너의 격리 모드를 나누어 살펴봅니다.

「Windows 가상화의 심층」 전 3회

같은 Windows 하이퍼바이저를 토대 → 보안 격리 → 경량 VM으로의 응용 순서로 살펴봅니다.

이 글의 전제

이 글을 읽는 법

1. 먼저 결론

경량 VM은 격리의 선(전용 커널과 하이퍼바이저 경계)은 그대로 두면서 「게스트 OS 한 벌의 복제」를 덜어냈습니다. Sandbox는 호스트의 Windows 자체를 공유하고, WSL2는 게스트를 용도에 특화된 작은 Linux로 바꾸었으며, 메모리는 둘 다 고정 예약이 아니라 호스트와 동적으로 주고받습니다.

풀 VM이 무거운 근원은 격리 자체가 아니라 복제입니다. 디스크 위에 또 하나의 OS 이미지, RAM 위에 또 한 벌의 OS 페이지, 부팅할 때마다 또 한 번의 풀 부트. 경량 VM들은 이 복제를 「공유해도 안전한 것은 공유한다」(Sandbox)와 「공유할 수 없다면 작게 다시 만든다」(WSL2)라는 두 가지 방침으로 깎아냅니다.

flowchart TB
    accTitle: 경량 VM을 떠받치는 세 가지 공유
    accDescr: 풀 VM이 복제하던 OS 이미지는 Sandbox에서는 공유로, WSL2에서는 소형화로 깎고, 고정 할당이 기본인(동적 메모리 구성은 예외) 메모리는 호스트와의 동적인 융통으로, 부팅은 경량 커널과 최소 구성으로 바꾸어 격리의 경계만 남깁니다
    heavy["풀 VM이 무거운 근원은 복제"] --> d1["디스크: OS 이미지의 복제"]
    heavy --> d2["메모리: 고정 할당이 기본"]
    heavy --> d3["부팅: 풀 부트를 다시 한 번"]
    d1 -->|대체| s1["공유(Sandbox)나 소형화(WSL2)"]
    d2 -->|대체| s2["호스트와 동적으로 주고받기"]
    d3 -->|대체| s3["경량 커널과 최소 구성으로 단축"]

그림 1: 격리를 그만둔 것이 아니라 복제를 그만두었다는 점이 「같은 하이퍼바이저인데 가볍다」의 답을 이루는 뼈대입니다.

이제 WSL2, Windows Sandbox, 컨테이너 순서로 각각 어떤 복제를 깎아냈는지 살펴봅니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 19건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 풀 VM은 무엇을 떠안고 있는가

비교의 기준으로, 기존형 VM이 떠안고 있는 것을 정리해 둡니다.

• 독립된 OS 이미지. 가상 디스크 안에 게스트 OS의 모든 파일을 담습니다. 호스트에 같은 Windows가 있어도 공유하지 않습니다.
• 거친 메모리 할당. 기존형 VM은 호스트 메모리를 정적인 크기로 할당하는 것이 기본입니다. Hyper-V의 동적 메모리처럼 설정 범위 안에서 할당을 늘리고 줄이는 구조도 있지만, 수요 변화에 맞춘 조정 수단은 제한적입니다.²
• 범용적인 풀 부트. 펌웨어, 부트로더, 각종 서비스를 물리 머신과 같은 절차로 시작합니다.

flowchart TB
    accTitle: 풀 VM이 지고 있는 세 가지 짐
    accDescr: 풀 VM은 독립된 OS 이미지, 정적인 것이 기본인 메모리 할당, 범용적인 풀 부트를 지고 있으며, 그것이 디스크와 RAM과 부팅 시간의 비용으로 나타납니다
    fullvm["풀 VM"] --> b1["독립된 OS 이미지"]
    fullvm --> b2["정적인 것이 기본인 메모리 할당"]
    fullvm --> b3["범용적인 풀 부트"]
    b1 -.-> c1["복제한 만큼 디스크를 소비"]
    b2 -.-> c2["쓰지 않는 몫까지 RAM을 안고 있기 쉬움"]
    b3 -.-> c3["부팅에 수십 초가 걸림"]

그림 2: 풀 VM의 비용 내역은 어느 것도 격리를 위한 것이 아니라 범용성과 복제를 위해 치르는 값입니다.

이것들은 결점이 아니라 「게스트에 무엇이든 넣을 수 있다」는 범용성의 대가입니다. Windows Server 옆에서 오래된 Linux를 돌리는 용도라면 이 범용성 자체가 가치입니다. 그러나 「호스트와 같은(또는 정해진) OS를 개발과 검증을 위해 지금 당장 돌리고 싶다」는 용도에서는 대부분이 쓸데없는 짐이 됩니다. 경량 VM은 용도를 좁힘으로써 이 짐을 내려놓습니다.

3. WSL2 ── 용도 특화 커널을 실은 유틸리티 VM

WSL2는 구조 → 파일을 두는 곳 → 메모리의 반환 순서로 읽으면 정리가 됩니다. 진짜 Linux 커널을 쓴다는 것과 Windows 쪽 파일을 빠르게 다룰 수 있다는 것은 별개의 이야기입니다.

3.1. 구조: 관리되는 VM과 그 안의 배포판

WSL2는 경량 유틸리티 VM 안에서 진짜 Linux 커널을 실행하는 구조입니다.³ 요점은 세 가지입니다.

커널은 진짜, 다만 특화품

Microsoft가 Stable 브랜치에서 빌드한 Linux 커널이며, 크기와 성능이 WSL2에 맞게 조정되어 있습니다. 현재 표준인 Microsoft Store 배포판 WSL에서는 커널이 WSL 본체 패키지와 함께 갱신되고 wsl --update로 적용할 수 있습니다(Windows에 내장되던 예전 배포에서는 Windows Update를 거쳤습니다).⁴

진짜 커널이므로 시스템 호출 호환성이 완전하고, Docker 같은 도구도 그대로 동작합니다.

VM은 뒷무대

VM의 생성·시작·정지는 WSL이 관리하고, 사용자는 셸을 열기만 하면 됩니다. VM 설정 화면도, 부팅을 기다리는 체감도 없습니다.⁴

배포판은 VM 안의 컨테이너

Ubuntu나 Debian 같은 각 배포판은 하나의 관리되는 VM 안에서 격리된 컨테이너로 동작합니다. 네트워크 네임스페이스와 커널은 공유하면서 PID·마운트·사용자 등의 네임스페이스는 분리되어 있습니다.³

flowchart TB
    accTitle: WSL2의 아키텍처
    accDescr: 하이퍼바이저 위에 호스트 Windows와 경량 유틸리티 VM이 나란히 있고, VM 안에서 Microsoft가 빌드한 Linux 커널이 동작하며, 각 배포판은 그 안의 격리된 컨테이너로 동작합니다
    hv["하이퍼바이저"] --> host["호스트 Windows"]
    hv --> uvm["경량 유틸리티 VM"]
    uvm --> lk["Linux 커널(Microsoft 빌드, wsl --update로 갱신)"]
    lk --> u1["Ubuntu(컨테이너)"]
    lk --> u2["Debian(컨테이너)"]
    host <-->|"상호 운용(명령, 파일, 네트워크)"| uvm

그림 3: 「WSL2는 VM인가」의 답은 「그렇습니다, 다만 관리되는 뒷무대의 VM입니다」이며, 배포판을 여러 개 넣어도 VM은 하나입니다.

wsl이라고 친 순간의 뒷면은 이렇게 되어 있습니다.

flowchart TB
    accTitle: wsl 명령 실행에서 몇 초 만에 셸이 돌아오기까지
    accDescr: wsl을 실행할 때 유틸리티 VM이 아직 시작되지 않았다면 경량 VM과 Linux 커널을 시작하고, 이미 시작되어 있다면 그대로 쓰며, 배포판의 컨테이너에서 셸이 돌아옵니다
    cmd["wsl을 실행"] --> vmq{"유틸리티 VM은 이미 시작되었는가?"}
    vmq -->|아니오| bootvm["경량 VM과 Linux 커널을 시작(몇 초)"]
    vmq -->|예| reuse["이미 시작된 VM을 그대로 사용"]
    bootvm --> shell["컨테이너 안에서 셸이 돌아옴"]
    reuse --> shell

그림 4: 기다리는 시간의 정체는 최소한의 VM 시작뿐이며, 풀 부트라는 짐을 내려놓은 효과가 여기에서 드러납니다.

3.2. 파일 I/O: 어느 쪽에 두느냐로 전혀 다른 것이 된다

WSL2의 성능 이야기에서 반드시 등장하는 것이 파일을 두는 위치입니다.

• Linux 쪽(ext4 가상 디스크)의 파일에 대한 작업은 빠릅니다. Linux 커널이 자기 파일 시스템을 직접 다루기 때문이며, tarball 전개에서 WSL1 대비 최대 20배, git clone이나 npm install에서 2~5배 빨라졌다는 보고가 있습니다.⁴
• Windows 쪽(/mnt/c 등)의 파일에 대한 작업은 OS 경계를 넘는 파일 공유를 거치므로 느려집니다. OS 간 파일 시스템 성능은 WSL2가 WSL1에 뒤지는 유일한 주요 항목입니다.⁴

따라서 원칙은 「프로젝트 파일은 그것을 다루는 도구와 같은 OS 쪽에 둔다」입니다.⁴ Linux 빌드 도구로 다루는 리포지터리는 Linux 쪽에, Visual Studio로 빌드하는 솔루션은 Windows 쪽에 둡니다.

flowchart TB
    accTitle: WSL2 파일 I/O 경로의 분기
    accDescr: Linux 쪽 ext4 가상 디스크에는 Linux 커널이 직접 접근하므로 빠르고, Windows 쪽 파일에는 OS 경계를 넘는 파일 공유를 거치므로 느리다는 분기입니다
    io["WSL2 안의 파일 작업"] --> place{"파일은 어느 쪽에 있는가?"}
    place -->|"Linux 쪽(홈 등)"| ext4["ext4 가상 디스크로 직접 I/O"]
    place -->|"Windows 쪽(/mnt/c 등)"| p9["OS 경계를 넘는 공유 경유"]
    ext4 --> fast["빠름(WSL1 대비 최대 20배의 예)"]
    p9 --> slow["느려지기 쉬움"]
    slow -.-> fix["대책: 파일을 쓰는 쪽 OS에 둔다"]

그림 5: 느린 것은 WSL2가 아니라 경로이므로, 두는 위치만 바꿔도 성능 문제가 사라지는 경우가 많습니다.

3.3. 메모리: 늘고, 줄고, 그래도 다 돌려주지는 않는다

WSL2의 메모리 사용량(작업 관리자에서는 vmmem 프로세스로 보입니다)은 고정 예약이 아니라 사용량에 따라 늘고 줄어듭니다.

프로세스가 해제한 메모리의 반환

프로세스가 해제한 메모리는 기본으로 켜져 있는 pageReporting 설정 아래에서 Windows로 자동 반환됩니다.⁵

파일 캐시의 회수

파일 캐시로 유지된 페이지는 예전에는 VM을 종료할 때까지 Windows로 돌아가지 않았습니다.⁴ 현행 WSL에서는 .wslconfig의 실험적 설정 autoMemoryReclaim(기본값은 dropCache)이 캐시도 자동으로 회수합니다.⁵

이 설정을 disabled로 한 환경이나 오래된 WSL에서는 장시간 세션의 캐시가 VM 종료까지 남아 호스트 쪽 메모리를 압박할 수 있습니다.

flowchart TB
    accTitle: WSL2 메모리의 증감과 반환 흐름
    accDescr: WSL2 안에서 수요가 늘면 VM의 메모리 사용량이 늘고, 프로세스가 해제한 몫은 기본으로 켜져 있는 pageReporting 아래에서 Windows로 반환되며, 파일 캐시는 기본적으로 autoMemoryReclaim이 자동 회수하지만, 이를 끈 설정이나 오래된 WSL에서는 VM 종료까지 남고 wsl의 shutdown으로 전부 반환됩니다
    grow["WSL2 안에서 메모리 수요가 늘어남"] --> vm["vmmem의 사용량이 늘어남"]
    vm --> freed{"그 페이지는 해제되었는가?"}
    freed -->|"프로세스가 해제(pageReporting 유효 시)"| ret["Windows로 자동 반환"]
    freed -->|파일 캐시로 유지| amr["autoMemoryReclaim이 자동 회수(기본)"]
    amr -.-> old2["끈 설정이나 오래된 WSL에서는 VM 종료까지 남음"]
    old2 --> sd["wsl --shutdown으로 전부 반환"]

그림 6: 「늘어난 채 그대로」로 보이는 것은 주로 캐시분이므로(pageReporting을 끄면 프로세스 해제분도 남습니다), 누수라고 단정하기 전에 반환 경로를 알아 두십시오.

메모리 상한을 설정한다

상한을 명시하고 싶다면 %UserProfile%\.wslconfig로 VM 전체의 메모리, CPU 수, 스왑을 제어할 수 있습니다.⁵

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

설정을 바꾼 뒤 wsl --shutdown으로 VM을 다시 시작하면 반영됩니다. 이 「상한을 정하는 것은 설정, 실제 사용량은 수요에 달렸다」라는 동적 배분은 다음에 볼 Windows Sandbox에서 더욱 철저해집니다.

4. Windows Sandbox ── 호스트의 Windows를 「한 번 더 쓴다」

Sandbox의 가벼움은 디스크 위 OS 파일의 공유, RAM 위 OS 페이지의 공유, 호스트와의 메모리 배분 협조라는 세 가지로 나누어 봅니다.

4.1. 동적 베이스 이미지: 500MB로 완전한 Windows

Windows Sandbox는 하이퍼바이저로 격리된 일회용 Windows 데스크톱입니다. 닫으면 모두 사라지고, 다음번에는 깨끗한 상태로 몇 초 만에 시작됩니다.¹

먼저 신기한 것은 디스크입니다. 완전한 Windows를 부팅할 수 있는데도 Sandbox의 베이스 이미지는 설치 후 약 500MB, 배포 시에는 압축 30MB밖에 되지 않습니다.² 비밀은 동적 베이스 이미지에 있습니다.

• OS 파일의 대부분은 변하지 않으며(immutable) 호스트의 것을 그대로 공유할 수 있습니다.
• 변할 수 있는(mutable) 소수의 파일만은 공유할 수 없으므로 깨끗한 사본을 베이스 이미지 안에 보관합니다.
• 시작할 때는 호스트의 불변 파일과 손안의 가변 파일 사본을 조합해 완전한 Windows 이미지를 구성합니다.²

즉 Sandbox는 Windows의 사본을 내려받지도 저장하지도 않고, 호스트에 이미 설치된 Windows를 재사용해 시작하는 것입니다.

flowchart TB
    accTitle: 동적 베이스 이미지의 구성
    accDescr: 호스트 Windows 중 변하지 않는 OS 파일은 공유하고, 변할 수 있는 파일만 깨끗한 사본을 베이스 이미지에 두며, 둘을 조합해 Sandbox의 완전한 Windows 이미지를 구성합니다
    hostw["호스트의 Windows 한 벌"] --> imm["변하지 않는 OS 파일(대다수)"]
    hostw --> mut["변할 수 있는 OS 파일(소수)"]
    imm -->|그대로 공유| img["Sandbox의 부팅 이미지"]
    mut -->|깨끗한 사본을 보관| img
    img --> boot["완전한 Windows로 시작"]
    img -.-> size["저장이 필요한 것은 약 500MB뿐"]

그림 7: 「Windows를 하나 더 갖는다」가 아니라 「호스트의 Windows에서 조립한다」는 것이, 디스크 복제를 그만둔 모습입니다.

이런 구성이기에 다음과 같은 수명 주기가 성립합니다.

다만 폐기되는 것은 Sandbox 안의 로컬 상태입니다.

.wsb 구성 파일로 쓰기 가능한 폴더를 호스트에서 매핑하고 있다면, 그곳에 대한 변경은 호스트 쪽에 남습니다.⁶

flowchart TB
    accTitle: Windows Sandbox의 수명 주기
    accDescr: 시작하면 깨끗한 Windows가 몇 초 만에 준비되고, 앱 검증이나 실험을 한 뒤 닫으면 Sandbox 안의 상태는 모두 폐기되어 다음번에도 깨끗한 상태에서 시작하지만, 쓰기 가능하게 매핑한 호스트 쪽 폴더의 변경은 남습니다
    launch["시작(몇 초)"] --> clean["깨끗한 Windows"]
    clean --> work["앱 검증이나 실험"]
    work --> close2["닫기"]
    close2 --> discard["Sandbox 안의 상태를 모두 폐기"]
    discard -.-> mapped["매핑한 쓰기 가능 폴더의 변경은 호스트에 남음"]
    discard -->|다음 시작| launch

그림 8: 매번 깨끗한 상태로 돌아갈 수 있는 것은 가변 부분이 일회용 사본이기 때문이며, 지우는 일 자체가 설계의 일부입니다.

4.2. 다이렉트 맵: 같은 ntdll.dll은 같은 물리 페이지

공유되는 것은 디스크만이 아니라 RAM도 마찬가지입니다. Sandbox는 호스트와 같은 OS 이미지를 실행하므로, OS 바이너리에 대해서는 호스트와 같은 물리 메모리 페이지를 쓰는 「다이렉트 맵」이라는 기술을 사용합니다. Sandbox 안에서 ntdll.dll이 메모리로 읽힐 때, 그것은 호스트에서 읽힌 같은 바이너리와 같은 물리 페이지를 가리킵니다.

호스트의 비밀을 위험에 빠뜨리지 않으면서 기존형 VM보다 훨씬 작은 메모리 풋프린트를 실현하고 있습니다.²

「같은 물리 페이지를 여러 이용자가 공유한다」──이것은 메모리 연재 제3회에서 다룬 섹션 객체를 통한 DLL 공유(「섹션 객체와 Copy-on-Write」)와 같은 발상입니다. 그 구조는 프로세스 사이의 공유였지만, Sandbox는 VM 경계를 넘어 그것을 해냅니다.

flowchart TB
    accTitle: 다이렉트 맵에 의한 물리 페이지 공유
    accDescr: 호스트 위의 앱과 Sandbox 안의 앱이 ntdll 같은 OS 바이너리에 대해 동일한 물리 메모리 페이지를 공유해 메모리 사용량을 줄입니다
    happ["호스트의 앱"] --> hva["호스트 쪽 가상 주소"]
    sapp["Sandbox 안의 앱"] --> sva["Sandbox 쪽 가상 주소"]
    hva --> phys["동일한 물리 페이지(ntdll.dll 등의 OS 바이너리)"]
    sva --> phys
    phys -.-> save["OS 몫의 RAM 복제가 필요 없어짐"]

그림 9: 프로세스 사이에서 써 오던 페이지 공유의 발상을 VM 경계를 넘어 적용한 것이 다이렉트 맵입니다.

4.3. 메모리의 대차: VM이라기보다 프로세스처럼

기존형 VM의 정적인 메모리 할당과 달리, Sandbox의 토대인 컨테이너 기술은 호스트와 협조해 리소스 배분을 동적으로 정합니다. 호스트가 메모리 부족에 빠지면 일반 프로세스에서 회수하는 것과 마찬가지로 컨테이너에서도 메모리를 회수할 수 있습니다.² Hyper-V의 동적 메모리도 설정 범위 안에서 VM에 대한 할당을 늘리고 줄이지만, Sandbox는 한 걸음 더 나아가 호스트의 메모리 관리와 같은 무대에서 서로 융통한다는 점이 다릅니다.

flowchart TB
    accTitle: 호스트와 Sandbox의 메모리 협조
    accDescr: 기존형 VM은 정적인 크기의 점유가 기본이고 조정 수단이 제한적인 데 비해, Sandbox는 호스트의 메모리 압력에 따라 회수 대상이 되며 일반 프로세스와 같은 무대에서 메모리를 서로 융통합니다
    pressure["호스트의 메모리 압력이 높아짐"] --> from{"어디에서 회수하는가?"}
    from --> proc["일반 프로세스의 Working Set"]
    from --> sbx["Sandbox(컨테이너)의 사용분"]
    proc --> relief["여유 메모리를 확보"]
    sbx --> relief
    relief -.-> contrast["기존형 VM은 조정 수단이 제한적"]

그림 10: 메모리를 융통하는 일에서 Sandbox는 VM이 아니라 프로세스 쪽에 서며, 호스트가 힘들 때는 내어 줍니다.

제1회에서 「VM의 성능은 호스트 쪽에도 의존한다」라고 말했지만, 경량 VM에서는 한 걸음 더 나아가 메모리 배분 자체가 호스트와의 공동 작업이 되어 있습니다. Sandbox를 「무거운 가상화 소프트웨어」가 아니라 「또 하나의 앱」 정도의 감각으로 쓸 수 있는 것은 이 협조 덕분입니다.

덧붙여 Sandbox를 업무 앱 검증에 쓰는 구체적인 절차는 이미 나온 「Windows Sandbox로 업무 앱 검증 환경 만들기」에서 다루고 있습니다. 이 글은 그 발밑의 구조 쪽입니다.

5. 컨테이너 ── 격리의 선을 어디에 긋는가

여기에서는 「컨테이너」라는 이름만으로 안전성을 판단하지 말고, 호스트와 커널을 공유하는지, 커널째 나누는지를 확인합니다.

5.1. 프로세스 격리와 Hyper-V 격리

Windows 컨테이너에는 실행 시 격리 모드가 두 가지 있습니다. 이미지는 공통이며 시작할 때 플래그로 고를 수 있습니다.⁷

• 프로세스 격리: 여러 컨테이너가 호스트와 커널을 공유하고, 파일 시스템·레지스트리·네트워크 포트·프로세스 ID 공간·개체 관리자 네임스페이스 등 네임스페이스별 가상화로 분리합니다. Linux 컨테이너와 거의 같은 방식입니다.
• Hyper-V 격리: 각 컨테이너가 고도로 최적화된 VM 안에서 동작하며 사실상 전용 커널을 가집니다. VM이 있기에 컨테이너끼리, 그리고 호스트와의 사이에 하드웨어 수준의 분리가 들어갑니다.⁷

네임스페이스에 의한 분리는 레지스트리 가상화 글(「Windows의 레지스트리 리디렉션과 가상화」)에서 본 「같은 API 아래에서 다른 실체를 보여 준다」는 기법의 철저한 판이라고 할 수 있습니다.

flowchart TB
    accTitle: 프로세스 격리와 Hyper-V 격리의 대비
    accDescr: 프로세스 격리에서는 컨테이너가 호스트와 커널을 공유하고 네임스페이스로 분리하는 데 비해, Hyper-V 격리에서는 각 컨테이너가 최적화된 VM 안에서 전용 커널을 가집니다
    subgraph pi ["프로세스 격리"]
        c1["컨테이너 A"] --> sk1["호스트와 공유하는 커널"]
        c2["컨테이너 B"] --> sk1
    end
    subgraph hi ["Hyper-V 격리"]
        c3["컨테이너 C"] --> k3["전용 커널(최적화 VM 안)"]
        c4["컨테이너 D"] --> k4["전용 커널(최적화 VM 안)"]
    end
    sk1 ~~~ c3

그림 11: 같은 컨테이너 이미지라도 격리의 선을 커널 위에 그을지 커널째 나눌지는 시작할 때 고를 수 있습니다.

5.2. 「보안 경계」라고 부를 수 있는 쪽은 어디인가

이 두 모드의 차이는 성능 이야기에 그치지 않습니다. Microsoft는 프로세스 격리 컨테이너를 견고한 보안 경계로 보지 않습니다. 보안 경계로서 유지 보수(취약점 대응)되는 것은 하이퍼바이저 격리 컨테이너이며, 적대적인 멀티테넌트 시나리오에서는 Hyper-V 격리를 선택해야 한다고 안내합니다.⁸

제2회에서 본 VBS도 「커널은 뚫릴 수 있다」를 전제로 하이퍼바이저 경계로 대피시키는 설계였습니다. 컨테이너의 세계에서도 같은 판단 기준이 통합니다. 신뢰할 수 없는 코드를 가두는 선은 커널 공유의 안쪽이 아니라 하이퍼바이저의 경계에 긋습니다.

flowchart TB
    accTitle: 실행할 코드의 신뢰도와 격리 선택
    accDescr: 신뢰할 수 있는 워크로드라면 프로세스 격리로 밀도와 성능을 취하고, 신뢰할 수 없는 코드나 남의 코드라면 Hyper-V 격리 컨테이너나 네트워크 등을 끈 강화 구성의 Windows Sandbox, 격리된 VM 같은 하이퍼바이저 경계를 고릅니다
    trust{"그 코드를 신뢰할 수 있는가?"} -->|있다| dens["프로세스 격리(밀도와 속도를 우선)"]
    trust -->|없다 또는 남의 코드| bound["하이퍼바이저 경계를 고른다"]
    bound --> opt1["Hyper-V 격리 컨테이너"]
    bound --> opt2["강화 구성의 Sandbox나 격리 VM"]

그림 12: 격리 모드는 성능 이야기이기 전에 보안 이야기이며, 신뢰도가 선을 그을 자리를 정합니다.

보충: VM 안에서 쓸 때는 중첩 가상화 요건을 확인한다

Hyper-V 격리 컨테이너를 Hyper-V VM 안에서 돌리면 하이퍼바이저가 두 단이 되는 중첩 가상화가 됩니다.

1단 중첩은 조건을 충족하는 환경(Intel 프로세서는 Windows 10/Windows Server 2016 이후, AMD 프로세서는 Windows 11/Windows Server 2022 이후의 호스트와 각각 대응하는 VM 구성 버전)에서 프로덕션에서도 지원되며, 여기에 더해 바깥쪽 VM에 가상화 지원 기능을 노출하는 설정(Hyper-V라면 Set-VMProcessor의 ExposeVirtualizationExtensions)이 전제입니다.

VM 안에서 WSL2를 돌리는 구성도 마찬가지로 지원됩니다.⁹ 클라우드의 개발 VM에서 WSL2나 Docker를 쓸 수 있는지도 그 VM 크기와 설정이 중첩 가상화를 노출하고 있는지로 결정됩니다.

flowchart TB
    accTitle: 중첩 가상화의 구조
    accDescr: 물리 호스트의 하이퍼바이저 위에 클라우드 VM이 있고, 그 안에서 한 단 더 하이퍼바이저(지원되는 중첩은 1단까지)가 동작해 WSL2와 Hyper-V 격리 컨테이너를 떠받칩니다
    phys3["물리 호스트의 하이퍼바이저"] --> cvm["클라우드 VM(개발 머신)"]
    cvm --> nhv["VM 안의 하이퍼바이저(중첩 1단째)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Hyper-V 격리 컨테이너"]
    nhv -.-> limit["지원되는 중첩은 1단까지"]

그림 13: 클라우드 VM 안에서 wsl이 동작하는 것은 중첩 가상화가 한 단만 공식적으로 지원되기 때문입니다.

5.3. 격리와 가벼움의 스펙트럼

여기까지 등장한 인물들을 하나의 축에 늘어놓으면 다음과 같습니다.

flowchart TB
    accTitle: 격리의 강도와 가벼움의 스펙트럼
    accDescr: 프로세스 격리 컨테이너는 가장 가볍지만 커널을 공유하고, WSL2와 Sandbox와 Hyper-V 격리 컨테이너는 전용 커널을 갖는 경량 VM이며(Sandbox는 호스트 공유, WSL2는 특화 커널로 경량화), 풀 VM은 가장 무겁지만 범용이라는 배열입니다
    ax["가볍다 ← → 무겁다"] ~~~ p1
    p1["프로세스 격리 컨테이너(커널 공유)"] --> p2["WSL2·Sandbox·Hyper-V 격리(전용 커널의 경량 VM)"]
    p2 --> p3["풀 VM(무엇이든 동작, 복제를 전부 보유)"]
    p1 -.-> n1["경계: 네임스페이스"]
    p2 -.-> n2["경계: 하이퍼바이저"]
    p3 -.-> n3["경계: 하이퍼바이저 + 완전한 독립"]

그림 14: 경량 VM 무리는 하이퍼바이저 경계를 지킨 채 복제를 깎은 중간 해법이며, 깎는 방식은 Sandbox가 공유, WSL2가 특화 커널로 갈립니다.

6. 직접 눈으로 확인한다

가벼움과 공유는 손안에서 관측할 수 있습니다.

6.1. WSL2의 시작 시간과 메모리 증감

작업 관리자를 열어 둔 채로 다음을 실행해 보십시오.

# 시작 시간 체감(첫 회는 VM 시작, 2회째 이후는 더 빠름)
Measure-Command { wsl -e true }

# WSL2 VM의 메모리 사용량(vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# VM째 종료해 메모리가 돌아오는 모습을 본다
wsl --shutdown

WSL2 안에서 큰 빌드나 파일 작업을 하면 vmmem이 커지고, wsl --shutdown으로 한꺼번에 반환되는 것을 관측할 수 있습니다.

6.2. WSL2의 파일 배치에 따른 속도 차이

같은 리포지터리를 Linux 쪽(~/repo)과 Windows 쪽(/mnt/c/repo)에 두고 git status나 전개 처리의 시간을 비교하면, 제3.2절의 차이가 숫자로 보입니다.

6.3. Sandbox 시작 시 호스트 쪽 메모리의 증가분

Sandbox를 시작하고 호스트의 작업 관리자에서 메모리 증가분을 보십시오. 「Windows가 하나 더」에서 상상하는 것보다 훨씬 작은 증가분으로 끝난다는 점이 공유의 효과를 말해 줍니다.

호스트 쪽 메모리 내역을 더 파고들려면 RAMMap과 VMMap 사용법을 정리한 Sysinternals 도구 글(「Process Explorer·Handle·VMMap 사용법」)이 참고가 됩니다.

다만 이것들은 호스트 쪽 프로세스나 물리 메모리의 분류를 보는 도구이며, 게스트와의 공유 자체를 직접 관측하는 것은 아닙니다.

6.4. Windows 컨테이너의 격리 모드 차이

Windows 컨테이너 환경이 있다면 docker run --isolation=process와 --isolation=hyperv로 같은 이미지를 시작해, 시작 시간과 작업 관리자에서 보이는 모습(프로세스 격리에서는 컨테이너 안의 프로세스가 호스트의 프로세스 목록에 보입니다)을 비교하면 격리 선의 위치를 체감할 수 있습니다.⁷

다만 프로세스 격리는 호스트와 이미지의 버전 일치가 전제이며, 클라이언트 OS에서는 개발과 테스트 용도로만 쓸 수 있습니다. Hyper-V 격리는 더 넓은 조합을 허용하므로, 비교는 호환되는 조합으로 하십시오.¹⁰

7. 실무에서 피하고 싶은 세 가지 오해

7.1. 「WSL2는 느리다」

느린 것은 WSL2가 아니라 OS 경계를 넘나드는 파일 I/O 경로입니다. 프로젝트를 Linux 쪽으로 옮기는 것만으로 체감이 전혀 달라지는 경우가 많습니다.⁴ 반대로 Windows 도구에서 만지는 파일을 Linux 쪽에 두는 것도 같은 이유로 불리합니다. 「쓰는 쪽과 같은 OS에 둔다」로 판단하십시오.

7.2. 「vmmem이 비대해지는 것은 메모리 누수」

WSL2의 메모리는 수요에 따라 늘고 줄며, 해제분은 반환됩니다. 현행 WSL이라면 파일 캐시도 autoMemoryReclaim(기본값은 dropCache)이 자동으로 회수하므로, 「커진 채 그대로」는 시간이 지나면서 해소되는 경우가 많습니다.⁵

그래도 남는다면 autoMemoryReclaim이 disabled로 되어 있지 않은지, 해제분의 반환을 담당하는 pageReporting이 꺼져 있지 않은지(또는 오래된 WSL이 아닌지)를 확인한 다음, .wslconfig의 memory로 상한을 명시하거나 세션을 마무리할 때 wsl --shutdown으로 전부 반환합니다.

누수인지 아닌지 가려내는 사고방식은 메모리 연재의 도입편 「Windows의 「메모리 사용량」은 무엇을 나타내는가」와 같습니다.

7.3. 「컨테이너에 넣었으니 안전」

프로세스 격리 컨테이너는 커널을 공유하고 있으며, Microsoft의 기준으로는 보안 경계가 아닙니다.⁸ 신뢰할 수 없는 코드나 검체를 실행할 때는 Hyper-V 격리 컨테이너, Windows Sandbox, 또는 전용 VM처럼 하이퍼바이저 경계를 갖는 격리를 고르십시오.

다만 하이퍼바이저 경계는 만능의 면죄부가 아닙니다.

Windows Sandbox의 기본 설정에서는 네트워크 연결이 켜져 있어 신뢰할 수 없는 앱을 내부 네트워크에 노출할 수 있습니다.¹ 검체 실행에 쓴다면 .wsb 구성 파일로 네트워크나 클립보드 리디렉션을 꺼서 격리를 강화하거나, 격리된 네트워크 위의 전용 VM을 쓰십시오.

8. 정리 ── 연재를 마무리하며

제3회의 요점입니다.

• 경량 VM의 가벼움은 「격리를 약화한」 결과가 아니라 「복제를 그만둔」 결과입니다.
• WSL2는 관리되는 경량 유틸리티 VM에서 진짜 Linux 커널을 실행하고, 배포판은 VM 안의 컨테이너로 분리됩니다.³ 파일은 쓰는 쪽 OS에 두는 것이 성능의 원칙이고, 메모리는 동적으로 늘고 줄며 .wslconfig로 상한을 제어할 수 있습니다.⁴⁵
• Windows Sandbox는 동적 베이스 이미지로 호스트의 불변 OS 파일을 공유하고, 다이렉트 맵으로 대상 OS 바이너리의 물리 페이지까지 공유함으로써 Windows 한 벌의 복제를 갖지 않습니다.² 가변 파일의 약 500MB와, 그 안에서 돌리는 앱 자체의 메모리는 별도로 필요합니다.
• 컨테이너의 격리 모드는 시작할 때 고를 수 있고, 보안 경계라고 부를 수 있는 것은 Hyper-V 격리 쪽입니다.⁷⁸

그리고 연재 전체를 한 장으로 정리하면 이렇게 됩니다.

• 제1회: Windows 아래에는 하이퍼바이저 계층이 있고, 호스트 OS 자신이 루트 파티션으로 동작합니다. CPU와 메모리(SLAT)의 조정은 이 계층이 직접 하고, 합성 장치의 I/O는 VMBus 너머에서 루트 파티션(VSP)이 중개합니다.
• 제2회: 그 계층은 VM끼리의 분리뿐 아니라 같은 OS 안쪽에 커널보다 강한 경계(VTL)를 긋는 데에도 쓰입니다. Windows 11의 기본 보안은 이 위에 세워져 있습니다.
• 제3회: 같은 계층 위에서 복제를 깎음으로써 「몇 초 만에 시작되는 가상 머신」이 성립합니다. 격리의 선은 그대로 유지된 채 일상의 도구가 되었습니다.

flowchart TB
    accTitle: 연재 전체의 한 장짜리 그림
    accDescr: 하드웨어 바로 위의 하이퍼바이저가 제1회, 호스트 Windows 안 VTL0과 VTL1의 분리가 제2회, 같은 계층에 올라타는 WSL2와 Sandbox와 Hyper-V 격리의 가벼움이 제3회에 대응하며, 프로세스 격리 컨테이너는 호스트의 커널을 공유하고 Sandbox는 공유로, WSL2는 특화 커널로 가벼워집니다
    hw3["하드웨어"] --> hv3["하이퍼바이저(제1회)"]
    hv3 --> rp3["호스트 Windows(VTL 분리는 제2회)"]
    hv3 --> lw3["WSL2·Sandbox·Hyper-V 격리(제3회)"]
    rp3 --> pc3["프로세스 격리 컨테이너(커널 공유)"]
    lw3 -.-> mech3["Sandbox는 공유, WSL2는 특화 커널로 경량화"]

그림 15: 세 회분을 쌓아 올리면 지금 Windows의 발밑 전체 그림이 됩니다.

가상화는 이제 서버실의 기술도, VM을 세우는 사람만의 기술도 아닙니다. 여러분의 Windows 발밑에서 보안과 개발 경험 양쪽을 조용히 떠받치고 있다는 것──그것이 현재 위치입니다.

관련 글

• Windows 가상화의 심층(제1회) ── 지금 쓰는 Windows는 어디에서 실행되는가: 하이퍼바이저와 파티션
• Windows 가상화의 심층(제2회) ── 커널에서도 보이지 않는 메모리: VBS·HVCI·Credential Guard의 구조
• Windows 메모리의 심층(제3회) ── 섹션 객체와 Copy-on-Write
• Windows Sandbox로 업무 앱 검증 환경 만들기
• Windows의 레지스트리 리디렉션과 가상화

관련 상담 영역

합동회사 고무라소프트에서는 WSL2와 컨테이너를 사용한 개발 환경 정비, Windows 앱 검증 환경 설계, 가상화 환경에서의 성능·호환성 조사를 다루고 있습니다.

• Windows 앱 개발
• 결함 조사·원인 분석
• 기존 자산 활용·이전 지원
• 문의하기

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

WSL2는 VM인가요?

그렇습니다. WSL2는 경량 유틸리티 VM 안에서 Microsoft가 빌드한 진짜 Linux 커널을 실행합니다. 다만 VM 관리는 WSL이 뒤에서 처리하므로, 사용자가 VM 설정이나 부팅 대기를 의식하지 않도록 설계되어 있습니다. 각 Linux 배포판은 이 관리되는 VM 안에서 격리된 컨테이너로 동작합니다.

WSL2에서 /mnt/c 아래의 파일 작업이 느린 이유는 무엇인가요?

WSL2의 Linux 커널에서 Windows 쪽 파일 시스템에 접근할 때는 OS 경계를 넘는 파일 공유를 거치기 때문입니다. Linux 파일 시스템(ext4 가상 디스크) 위의 작업은 빠르므로, 프로젝트 파일은 그것을 다루는 도구와 같은 OS 쪽에 두는 것이 원칙입니다.

vmmem 프로세스의 메모리 사용량이 큰 것은 누수인가요?

대부분의 경우 누수가 아닙니다. WSL2의 메모리는 사용량에 따라 늘고 줄며, 프로세스가 해제한 메모리는 기본으로 켜져 있는 pageReporting 설정 아래에서 Windows로 반환됩니다. 파일 캐시분도 현행 WSL에서는 .wslconfig의 autoMemoryReclaim(기본값 dropCache)이 자동으로 회수합니다. 이 설정들을 끈 환경이나 오래된 WSL에서는 VM이 끝날 때까지 남을 수 있으며, 그런 경우에는 memory 설정으로 상한을 정하거나 wsl --shutdown으로 반환합니다.

Windows Sandbox는 어떻게 수백 MB의 디스크로 완전한 Windows를 부팅할 수 있나요?

동적 베이스 이미지라는 구조 덕분입니다. 호스트에 이미 설치된 Windows 중 변하지 않는 OS 파일을 공유하고, 변할 수 있는 소수의 파일만 깨끗한 사본으로 보관합니다. 그래서 Windows 사본을 통째로 저장하지 않고도 부팅 가능한 완전한 이미지를 구성합니다.

컨테이너는 VM보다 안전한가요?

격리 모드에 따라 다릅니다. 프로세스 격리 컨테이너는 호스트와 커널을 공유하며, Microsoft는 이것을 견고한 보안 경계로 보지 않습니다. 적대적인 코드를 다룰 때는 컨테이너마다 전용 커널을 갖는 Hyper-V 격리를 선택해야 합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.