WSL2

WSL2는 Microsoft에서 직접 제작하고 유지 관리하는 완전한 Linux 커널을 사용합니다. 이 커널은 Windows 10 및 Windows 11에 통합되어 있으며, 정기적인 Windows 업데이트를 통해 업스트림 Linux 커널 변경 사항과 보안 패치를 받습니다. 이는 WSL1이 NT 커널을 번역 레이어로 사용했던 방식과 근본적으로 다른 아키텍처입니다.

실제 커널의 사용으로 인해 WSL2는 시스템 호출 호환성이 극적으로 향상되었습니다. Docker 컨테이너, FUSE(Filesystem in Userspace) 기반 파일 시스템, 그리고 다양한 저수준 시스템 프로그래밍 도구와 같은 Linux 전용 기능들을 네이티브에 가깝게 실행할 수 있습니다. 커널 모듈을 직접 로드하는 것은 제한적이지만, 사용자는 Microsoft가 제공하는 커널 소스 코드를 기반으로 자신만의 커널을 빌드하고 사용할 수도 있습니다[2].

이 커널은 경량화된 가상 머신 환경 내에서 실행되지만, 사용자에게는 완전히 통합된 경험을 제공합니다. 사용자는 여전히 Windows 터미널이나 명령 프롬프트에서 wsl 명령을 입력해 Linux 배포판에 접속하며, 별도의 가상 머신 관리 소프트웨어를 실행하거나 부팅을 기다릴 필요가 없습니다.

WSL2는 가상 머신 기반의 아키텍처를 채택하여, 특히 파일 시스템 성능에서 WSL1에 비해 획기적인 향상을 보여준다. WSL1이 NTFS 파일 시스템에 대한 번역 계층을 통해 파일 접근을 처리했던 것과 달리, WSL2는 가상화된 리눅스 커널이 자체 ext4 파일 시스템을 직접 관리한다. 이는 리눅스 애플리케이션이 네이티브 ext4 파일 시스템에서 작동함을 의미하며, 파일 I/O 작업의 오버헤드가 크게 줄어든다.

성능 차이는 특히 리눅스 파일 시스템 내에서의 작업에서 두드러진다. 소스 코드 컴파일, 패키지 관리자 작업, git 연산 등 대량의 파일을 읽고 쓰는 작업에서 WSL2는 WSL1보다 수 배에서 수십 배 빠른 속도를 보여준다. 벤치마크에 따르면, gcc를 사용한 프로젝트 컴파일 시간이 WSL1 대비 최대 5배 이상 단축되는 경우도 있다[3].

반면, Windows 파일 시스템(/mnt/c/ 등)에 접근할 때의 성능은 주의가 필요하다. WSL2는 9P 프로토콜을 통해 호스트의 NTFS 드라이브에 접근하는데, 이 경로를 통한 파일 작업은 리눅스 내부의 ext4 볼륨에 비해 상대적으로 느릴 수 있다. 따라서 성능이 중요한 프로젝트는 WSL2의 리눅스 파일 시스템 내에 두고 작업하는 것이 권장된다.

다음은 주요 작업에 대한 WSL1과 WSL2의 상대적 성능 차이를 요약한 것이다.

이러한 성능 특성으로 인해, WSL2는 파일 I/O가 빈번한 현대적인 개발 및 데이터 과학 워크플로우에 더 적합한 환경을 제공한다.

WSL2는 실제 Linux 커널을 가상 머신 내에서 실행함으로써, Linux 애플리케이션이 의존하는 모든 시스템 호출을 완벽하게 지원합니다. 이는 WSL1의 아키텍처적 한계를 극복한 핵심적인 특징입니다. WSL1은 시스템 호출을 Windows NT 커널로 변환하는 호환성 레이어를 사용했기 때문에, 일부 저수준 호출이나 실시간으로 변경되는 새로운 시스템 호출을 지원하지 못하는 문제가 있었습니다.

WSL2의 완전한 시스템 호출 호환성은 다음과 같은 이점을 제공합니다.

* 컨테이너 기술의 완벽한 실행: Docker와 같은 컨테이너 런타임은 네임스페이스, cgroups와 같은 특정 Linux 커널 기능에 깊이 의존합니다. WSL2는 이를 완전히 지원하여 Linux용 Docker 엔진을 네이티브에 가깝게 실행할 수 있습니다.

* 파일 시스템 성능 향상: FUSE(Filesystem in Userspace)와 같은 기술을 활용하는 파일 시스템 드라이버가 정상적으로 작동합니다.

* 최신 애플리케이션 및 도구 호환성: 커널 모듈을 로드하거나 특정 디바이스 드라이버와 상호작용하는 애플리케이션도 실행 가능성이 높아집니다.

이러한 호환성 덕분에 WSL2는 시스템 프로그래밍 학습, 컨테이너 오케스트레이션 개발, 또는 특정 Linux 배포판에 최적화된 소프트웨어를 사용하는 데 매우 적합한 환경이 되었습니다.

WSL1과 WSL2의 근본적인 차이는 아키텍처에 있다. WSL1은 리눅스 시스템 호출을 실시간으로 윈도우 NT 커널이 이해할 수 있는 형태로 변환하는 호환 계층 방식을 사용했다. 이는 별도의 가상 머신을 구동하지 않으므로 가볍고 빠른 시작 시간을 제공했지만, 모든 시스템 호출을 완벽하게 에뮬레이션하는 데 한계가 있었다.

반면, WSL2는 경량화된 마이크로소프트 관리 하이퍼바이저 위에 실제 리눅스 커널을 실행하는 완전한 가상 머신 아키텍처를 채택한다. 이 리눅스 커널은 마이크로소프트가 직접 빌드하여 제공하며, 윈도우 업데이트를 통해 배포된다. 따라서 WSL2는 네이티브 리눅스와 동일한 시스템 호출을 완전히 지원한다.

두 아키텍처의 핵심 차이점을 표로 정리하면 다음과 같다.

이러한 아키텍처 차이는 파일 시스템 접근 방식에도 영향을 미친다. WSL1은 윈도우 드라이브의 파일을 직접 접근했지만, WSL2는 가상 머신 내부의 ext4 파일 시스템을 사용하며, 윈도우 파일 시스템은 네트워크 드라이브(\\wsl$\)를 통해 접근한다. 결과적으로 리눅스 내부 파일 작업은 WSL2가 훨씬 빠르지만, 윈도우 파일과의 교차 작업에서는 상황에 따라 성능 차이가 발생할 수 있다.

WSL1과 WSL2의 성능 차이는 아키텍처의 근본적인 차이에서 비롯된다. WSL1은 시스템 호출을 변환하는 방식으로 동작하여 파일 시스템 성능에 제약이 있었지만, WSL2는 경량화된 가상 머신 내에서 네이티브 Linux 커널을 실행하므로 대부분의 작업에서 더 우수한 성능을 보인다.

파일 시스템 작업의 성능은 사용 패턴에 따라 상반된 결과를 보인다. WSL2 내부의 Linux 파일 시스템(예: ext4)에서의 작업은 네이티브에 가까운 속도를 낸다. 반면, Windows 파일 시스템(/mnt/c/ 등)에 접근할 때는 네트워크 드라이브를 통한 접근과 유사한 방식으로 작동하여 WSL1보다 상대적으로 느릴 수 있다. 따라서 프로젝트 파일을 WSL2 내부에 두고 작업하는 것이 일반적으로 권장된다.

다음 표는 주요 작업 영역별 대략적인 성능 특성을 비교한 것이다.

CPU 및 메모리 집중적 작업, 특히 컴파일이나 데이터베이스 연산, 머신러닝과 같은 자연어 처리 작업에서는 WSL2의 성능이 월등히 앞선다. 반면, Windows 호스트와의 파일 교환 빈도가 매우 높은 워크플로우나, localhost를 통한 네트워크 통신이 중요한 경우에는 WSL1의 아키텍처가 더 나은 성능을 보일 수 있다.

WSL1과 WSL2의 호환성 차이는 근본적인 아키텍처 차이에서 비롯된다. WSL1은 Linux 시스템 호출을 Windows NT 커널이 직접 변환하여 실행하는 방식이었다. 이 방식은 파일 시스템 성능에는 유리했지만, 모든 시스템 호출을 완벽하게 변환하기 어려워 커널 모듈이나 특정 저수준 시스템 호출을 사용하는 애플리케이션(예: Docker 데몬)의 실행에 제약이 있었다.

반면, WSL2는 경량화된 가상 머신 내에서 실제 Linux 커널을 실행한다. 이로 인해 시스템 호출 호환성 측면에서 거의 완벽에 가까운 수준을 달성했다. Linux 커널이 직접 하드웨어를 제어하는 것은 아니지만, 가상화된 환경 내에서 네이티브 시스템 호출을 처리할 수 있어, FUSE(Filesystem in Userspace)나 iptables와 같은 커널 수준의 기능을 완전히 지원한다. 따라서 컨테이너 런타임이나 특정 디바이스 드라이버를 필요로 하는 소프트웨어를 WSL2 내에서 원활하게 실행할 수 있다.

다만, 파일 시스템 호환성에서는 상반된 특징을 보인다. WSL1은 Windows 파일 시스템(/mnt/c/ 등)에 대한 접근 성능이 매우 뛰어났고, 양방향 파일 작업이 자연스러웠다. WSL2는 자체 ext4 파일 시스템을 사용하여 Linux 내부 작업 성능은 우수하지만, Windows 파일 시스템(/mnt/c/)을 접근할 때는 네트워크 드라이브를 거치는 방식으로 성능 저하가 발생할 수 있다. 따라서 Windows 파일을 자주 읽고 쓰는 작업에는 WSL1이 더 유리한 호환성을 보일 수 있다.

결론적으로, 순수 Linux 애플리케이션 호환성과 최신 기능 지원은 WSL2가 압도적으로 우수하다. 반면, Windows 파일 시스템과의 긴밀한 상호작용이 가장 중요한 경우에는 WSL1의 아키텍처가 더 나은 호환성을 제공할 수 있다.

WSL2를 설치하고 실행하기 위해서는 특정 최소 Windows 버전을 만족해야 한다. WSL2는 Windows 10의 2020년 5월 업데이트(버전 2004, 빌드 19041 이상) 또는 Windows 11에서 공식적으로 지원된다. 이전 버전의 Windows 10에서는 WSL2 기능을 사용할 수 없다.

아래 표는 WSL2를 위한 주요 Windows 버전 요구사항을 정리한 것이다.

사용 중인 Windows 버전은 '설정' > '시스템' > '정보' 메뉴에서 확인할 수 있다. 요구사항을 충족하지 않는 경우, Windows Update를 통해 최신 버전으로 업그레이드해야 한다. 또한, WSL2는 Windows 10 Home 에디션에서도 정상적으로 설치 및 실행이 가능하다.

대부분의 최신 컴퓨터에서 WSL2를 실행하려면 가상화 기술을 활성화해야 합니다. 이는 하이퍼바이저가 물리적 하드웨어 위에서 가상 머신을 효율적으로 실행할 수 있도록 하는 하드웨어 기능입니다. 이 기능은 기본적으로 비활성화되어 있는 경우가 많습니다.

활성화 절차는 컴퓨터의 메인보드 제조사와 BIOS 또는 UEFI 펌웨어 인터페이스에 따라 다릅니다. 일반적인 단계는 다음과 같습니다.

1. 컴퓨터를 재시작하고 부팅 과정 초반에 특정 키(F2, F10, Del, Esc 등)를 눌러 BIOS/UEFI 설정 화면으로 진입합니다.

2. 설정 메뉴에서 'Advanced', 'CPU Configuration', 'Security' 또는 'Virtualization'과 같은 섹션을 찾습니다.

3. 'Intel Virtualization Technology (VT-x)', 'AMD-V', 'SVM Mode' 또는 'Virtualization Technology'와 같은 옵션을 찾아 'Enabled'로 설정합니다.

4. 변경 사항을 저장하고(일반적으로 F10 키) 컴퓨터를 재시작합니다.

활성화를 확인하려면 Windows에서 작업 관리자(Ctrl+Shift+Esc)를 열고 '성능' 탭의 'CPU' 항목을 보면 '가상화: 사용'으로 표시됩니다. 이 기능이 활성화되지 않으면 WSL2 설치 또는 배포판 실행 시 오류가 발생할 수 있습니다.

일부 노트북이나 미리 구성된 OEM 시스템에서는 이 설정 메뉴가 숨겨져 있거나 제한될 수 있습니다. 또한, Microsoft Hyper-V 플랫폼이 WSL2의 기반이므로, Windows 기능에서 'Hyper-V' 또는 'Windows 하이퍼바이저 플랫폼'을 활성화해야 할 수도 있습니다.

WSL2를 설치하는 방법은 주로 Windows PowerShell 또는 명령 프롬프트를 통한 명령어 방식과 Microsoft Store를 통한 그래픽 방식으로 나뉜다. 두 방법 모두 사전에 BIOS/UEFI 설정에서 가상화 기술(Intel VT-x 또는 AMD-V)을 활성화하고, Windows 기능에서 'Linux용 Windows 하위 시스템'과 '가상 머신 플랫폼'을 켜야 한다.

가장 일반적인 방법은 관리자 권한으로 실행한 PowerShell에서 명령어를 사용하는 것이다. 먼저 wsl --install 명령을 실행하면 기본적으로 Ubuntu 배포판이 설치된다. 특정 배포판을 설치하려면 wsl --install -d <배포판 이름> 명령을 사용한다. 예를 들어, wsl --install -d Debian은 Debian을 설치한다. 설치 가능한 배포판 목록은 wsl --list --online 명령으로 확인할 수 있다. 이 명령어 방식은 설치 과정을 자동화하며, 최신 WSL2 커널 업데이트와 기본 배포판 설치를 한 번에 처리한다.

Microsoft Store를 통해서도 설치할 수 있다. Store 앱을 열고 'Linux' 또는 'WSL'로 검색하면 Ubuntu, Debian, openSUSE Leap, Kali Linux 등 다양한 배포판을 찾을 수 있다. 원하는 배포판을 선택하여 '받기' 버튼을 클릭하면 설치가 시작된다. Store를 통한 설치 후 첫 실행 시, 배포판은 자동으로 WSL2를 사용하도록 구성되며, 사용자 계정과 암호를 설정하는 단계를 거친다. Store 버전은 그래픽 인터페이스를 선호하는 사용자에게 편리하며, 배포판의 업데이트도 Store를 통해 관리된다.

설치 방법을 비교하면 다음과 같다.

설치가 완료되면 wsl --set-default-version 2 명령으로 새로 설치되는 모든 배포판의 기본 버전을 WSL2로 설정할 수 있다. 기존 WSL1 배포판이 있다면 wsl --set-version <배포판 이름> 2 명령으로 WSL2로 변환할 수 있다.

WSL2에서는 Microsoft Store를 통해 또는 명령줄을 사용하여 다양한 Linux 배포판을 설치할 수 있다. Windows 10 버전 2004 이상 및 Windows 11에서는 기본적으로 wsl 명령을 사용한 설치가 지원된다. 사용자는 wsl --install 명령으로 기본 배포판(일반적으로 Ubuntu)을 설치하거나, wsl --install -d <배포판 이름> 명령으로 특정 배포판을 선택하여 설치할 수 있다. Microsoft Store에서는 Ubuntu, Debian, Fedora, openSUSE 등 다양한 배포판을 직접 검색하고 설치할 수 있다.

설치된 배포판은 wsl -l -v 명령으로 목록을 확인하고 관리한다. 이 명령은 배포판 이름, 실행 상태(WSL 1 또는 WSL 2), 그리고 버전 정보를 보여준다. 사용자는 wsl --set-version <배포판 이름> <버전> 명령을 통해 기존 배포판을 WSL1과 WSL2 사이에서 전환할 수 있으며, wsl --set-default-version 2 명령으로 새로 설치되는 배포판의 기본 버전을 WSL2로 설정할 수 있다.

배포판을 더 이상 사용하지 않을 경우, wsl --unregister <배포판 이름> 명령으로 해당 배포판을 완전히 제거하고 시스템에서 등록을 해제할 수 있다. 이 작업은 가상 하드 디스크 파일을 포함한 모든 관련 데이터를 삭제한다. 여러 배포판을 동시에 설치하여 병렬로 실행하는 것도 가능하며, 각 배포판은 독립적인 환경과 파일 시스템을 유지한다.

wsl 명령은 WSL을 관리하고 조작하는 주요 명령줄 도구이다. Windows 터미널(명령 프롬프트, PowerShell 등)에서 실행하며, 설치된 배포판을 시작하거나 목록을 확인하는 기본 작업부터 고급 설정에 이르기까지 다양한 기능을 제공한다.

가장 일반적으로 사용되는 명령어는 다음과 같다.

또한, wsl --help 명령을 실행하면 사용 가능한 모든 명령어와 옵션에 대한 도움말을 확인할 수 있다. 이러한 명령어들을 조합하여 WSL 배포판의 생명주기를 관리하고, Windows 호스트 시스템과의 통합 작업을 효율적으로 수행할 수 있다.

WSL2 환경에서는 Linux 배포판과 Windows 호스트 간에 파일 시스템을 상호 접근할 수 있다. 이는 개발 워크플로우에서 두 시스템의 자원을 통합적으로 사용할 수 있게 해주는 핵심 기능이다.

Linux 배포판 내에서는 /mnt/c/, /mnt/d/와 같은 경로를 통해 Windows의 드라이브(C:, D: 등)에 직접 접근할 수 있다. 예를 들어, Windows 사용자 폴더의 문서는 /mnt/c/Users/[사용자명]/Documents/ 경로에서 액세스할 수 있다. 반대로, Windows 파일 탐색기에서는 \\wsl$ 네트워크 경로를 입력하거나, WSL 배포판 아이콘을 통해 Linux 파일 시스템에 접근할 수 있다. 배포판의 루트 파일 시스템은 일반적으로 \\wsl$\[배포판 이름]\home\[사용자명]과 같은 형태로 나타난다.

파일 시스템 간 작업 시 몇 가지 주의사항이 존재한다. Linux와 Windows는 서로 다른 라인 엔딩(Line Ending, LF vs CRLF)과 파일 권한 모델을 사용하기 때문에, 특히 소스 코드나 스크립트 파일을 양쪽에서 편집할 경우 호환성 문제가 발생할 수 있다. 또한, Linux 파일 시스템 내부 파일(예: /etc, /var 등)을 Windows 쪽에서 직접 수정하는 것은 시스템 손상을 초래할 수 있으므로 권장되지 않는다. 성능 측면에서는 프로젝트 파일을 Linux 파일 시스템(/home 아래)에 두고 Linux 도구로 작업하는 것이 일반적으로 더 빠르며, Windows 드라이브(/mnt/c/ 아래)에서 Linux 바이너리를 실행하는 것은 성능 저하를 일으킬 수 있다.

WSL2는 가상 머신 기반 아키텍처를 채택하여 네트워킹을 구현한다. WSL2 배포판은 경량화된 가상 머신 내에서 실행되며, 이 가상 머신은 가상 네트워크 스위치를 통해 호스트 Windows와 연결된다. 이로 인해 WSL2 인스턴스는 호스트와는 별개의 가상 IP 주소를 가지게 되며, 자체적인 가상 네트워크 인터페이스 카드(NIC)를 갖춘 독립된 네트워크 스택을 운영한다.

네트워크 구성 측면에서 주요 특징은 다음과 같다.

이 아키텍처는 완전한 시스템 호출 호환성을 제공하는 대신, 네트워크 대역폭과 지연 시간 측면에서 WSL1에 비해 개선된 성능을 보인다. 그러나 네트워크 주소가 분리되므로, 호스트에서 실행 중인 서비스(예: 데이터베이스 서버 또는 웹 API)를 WSL2에서 접근하려면 추가적인 주소 설정이 필요할 수 있다. 반대로, WSL2 내부에서 실행 중인 서비스(예: 웹 서버)를 호스트의 브라우저에서 접근하려면 localhost를 사용하면 되는데, 이는 Windows가 WSL2 가상 머신의 localhost 트래픽을 자동으로 포워딩하기 때문이다.

WSL2 환경에서 실행 중인 서비스에 접근하기 위해 localhost 주소를 사용할 수 있습니다. 이는 WSL2가 가상 머신으로 격리되어 실행되지만, Windows 호스트 측에서 자동으로 포트 포워딩을 설정해주기 때문입니다. 예를 들어, WSL2 내부의 우분투 배포판에서 8080 포트로 웹 서버를 실행했다면, Windows의 웹 브라우저에서 http://localhost:8080을 입력하여 해당 서비스에 접속할 수 있습니다.

반대로, Windows 호스트에서 실행 중인 서비스(예: 데이터베이스 서버나 개발 서버)에도 WSL2 내부에서 localhost 주소로 접근이 가능합니다. 이는 WSL2가 호스트의 루프백 주소를 자동으로 변환하여 연결하기 때문입니다. 따라서 네트워크 설정을 크게 변경하지 않고도 양방향 통신이 자연스럽게 이루어집니다.

단, 일부 특정 포트나 매우 복잡한 네트워크 구성에서는 추가 설정이 필요할 수 있습니다. 또한, WSL2 인스턴스가 완전히 종료된 상태에서는 포트 포워딩이 작동하지 않을 수 있습니다. 기본적으로 대부분의 일반적인 개발 시나리오(웹 서버, API 서버, 데이터베이스 연결 등)에서는 localhost를 사용한 접근 방식이 잘 동작합니다.

WSL2는 가상 머신 기반 아키텍처를 사용하므로, 고급 네트워킹 시나리오를 위해 몇 가지 추가 설정이 필요할 수 있습니다. 기본적으로 WSL2 인스턴스는 가상화된 NAT(Network Address Translation) 네트워크에 연결되어 자체 IP 주소를 가지며, 호스트 Windows는 이를 통해 외부 네트워크와 통신합니다.

포트 포워딩은 WSL2의 주요 고급 네트워크 설정 중 하나입니다. WSL2 가상 머신 내에서 실행 중인 서비스(예: 웹 서버)를 호스트의 로컬 네트워크나 인터넷에서 접근하려면, 호스트 Windows의 특정 포트로 들어오는 트래픽을 WSL2 인스턴스의 해당 포트로 전달해야 합니다. 이는 PowerShell에서 netsh 명령어를 사용하여 수동으로 설정할 수 있습니다. 예를 들어, 호스트의 8080 포트를 WSL2 인스턴스의 80 포트로 포워딩하는 명령은 다음과 같습니다.

```powershell

netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=80 connectaddress=(WSL2_IP_주소)

```

WSL2 인스턴스의 IP 주소는 ip addr show eth0 명령으로 확인할 수 있으나, 재시작 시 변경될 수 있으므로 스크립트를 통해 동적으로 관리하는 것이 좋습니다.

정적 IP 할당과 사용자 정의 가상 네트워크 스위치 생성은 더 복잡한 설정에 해당합니다. WSL2는 기본적으로 [[Hyper-V

WSL2는 Microsoft Windows 10 및 Windows 11에서 Linux용 Windows 하위 시스템의 두 번째 아키텍처이다. WSL2는 가상 머신 기반의 경량 하이퍼바이저를 사용하여 실제 Linux 커널을 실행한다. 이 아키텍처는 파일 시스템 성능과 전체 시스템 호출 호환성에서 WSL1에 비해 상당한 향상을 제공한다.

WSL2는 완전한 Linux 커널을 포함하며, 이 커널은 Microsoft에서 직접 구축하고 유지 관리한다. 이 커널은 Windows 업데이트를 통해 정기적으로 업데이트된다. 사용자는 또한 Microsoft의 GitHub 리포지토리에서 커널 소스 코드에 접근하고 직접 커널을 수정하여 빌드할 수 있다.

WSL2의 네트워킹 아키텍처는 가상 머신 환경을 반영한다. 각 WSL2 배포판 인스턴스는 가상화된 이더넷 어댑터를 통해 호스트 Windows와 통신하는 가상 머신 내에서 실행된다. 이는 WSL1의 네트워크 브리징 방식과는 차이가 있다. 결과적으로, WSL2 인스턴스는 고유한 IP 주소를 가지며, 이 주소는 호스트 네트워크와는 별개의 가상 네트워크에 존재한다.

WSL2는 Windows와 Linux 파일 시스템 간의 통합된 접근을 제공한다. 사용자는 Linux 배포판 내에서 /mnt/c, /mnt/d 등의 경로를 통해 Windows 드라이브(C:, D: 등)의 파일에 직접 접근할 수 있다. 반대로, Windows 파일 탐색기에서는 \\wsl$\<배포판이름> 경로를 통해 Linux 배포판의 파일 시스템을 네트워크 드라이브처럼 탐색할 수 있다.

WSL2 환경 내에서 물리적 USB 장치를 직접 접근하고 사용하는 것은 기본적으로 지원되지 않는다. WSL2는 완전한 가상 머신 아키텍처를 기반으로 하기 때문에, 호스트의 하드웨어에 대한 직접적인 접근이 제한된다. USB 장치는 일반적으로 호스트 Windows 운영 체제에서 관리되며, WSL2 내부의 리눅스 배포판은 이러한 장치를 네이티브로 인식하지 못한다.

USB 장치를 WSL2에서 사용하기 위해서는 일반적으로 호스트 측에 추가 소프트웨어를 설치하고 네트워크 또는 소켓을 통해 연결을 전달(forward)하는 방법을 사용한다. 한 가지 널리 알려진 접근법은 usbipd-win[10]이라는 오픈 소스 도구를 활용하는 것이다. 이 도구는 Windows 호스트에서 USB 장치를 "공유"하고, WSL2 내부의 리눅스 클라이언트가 해당 장치에 TCP/IP 네트워크를 통해 접근할 수 있도록 한다.

설치 및 사용 절차는 대략 다음과 같은 단계를 따른다.

1. Windows 호스트에 usbipd-win을 설치한다.

2. WSL2 배포판 내부에 usbip 리눅스 툴을 설치한다.

3. Windows 관리자 권한으로 터미널을 열어, 연결할 USB 장치의 BUSID를 확인한 후 해당 장치를 공유(attach)한다.

4. WSL2 터미널에서 동일한 BUSID를 사용하여 호스트로부터 장치를 연결한다.

이 과정을 성공적으로 완료하면, WSL2 내부에서 lsusb 명령어를 실행했을 때 해당 USB 장치가 목록에 나타나며, 마치 물리적 리눅스 머신에 연결된 것처럼 장치 파일을 통해 접근할 수 있다. 이 방법은 아두이노, STM32 개발 보드, 특정 USB to Serial 변환 칩, 또는 일부 보안 토큰과 같은 장치를 WSL2 내의 개발 환경에서 사용할 때 유용하다.

이 방식은 네트워크 스택을 경유하므로 순수 네이티브 성능에는 미치지 못할 수 있으며, 모든 종류의 USB 장치가 완벽하게 호환되는 것은 아니다. 또한, WSL2 인스턴스를 재시작할 경우 연결이 끊어지므로 필요시 다시 연결 절차를 수행해야 한다.

.wslconfig 파일은 사용자 홈 디렉터리(예: C:\Users\<사용자명>)에 위치하며, WSL 2에서 실행되는 모든 배포판에 적용되는 전역 설정을 관리하는 데 사용된다. 이 파일은 메모리, 프로세서, 네트워킹 등 WSL 2 가상 머신의 리소스 할당과 동작을 세부적으로 제어할 수 있게 해준다.

파일은 일반 텍스트 형식이며, [wsl2] 섹션 헤더 아래에 다양한 설정을 키-값 쌍으로 지정한다. 주요 설정 항목은 다음과 같다.

설정을 변경한 후에는 변경 사항이 적용되도록 WSL을 재시작해야 한다. 관리자 권한으로 PowerShell 또는 명령 프롬프트를 실행한 후 wsl --shutdown 명령어를 입력하여 WSL을 완전히 종료한다. 이후 WSL 배포판을 다시 실행하면 새로운 설정이 적용된다. 이 파일을 사용하면 호스트 시스템의 리소스 상황에 맞춰 WSL 2의 성능을 최적화하거나, 특수한 커널을 테스트하는 등 고급 사용자 요구를 충족할 수 있다.

WSL2 배포판의 상태를 보존하거나 다른 시스템으로 이동시키기 위해 백업과 복원 작업을 수행할 수 있다. wsl --export와 wsl --import 명령어를 사용하면 배포판 전체를 단일 파일로 패키징하거나, 그 파일로부터 새로운 배포판 인스턴스를 생성할 수 있다. 이 방법은 개발 환경을 그대로 백업하거나, 동일한 환경을 여러 컴퓨터에 구성해야 할 때 유용하다.

백업을 생성하는 기본 명령어는 wsl --export <배포판 이름> <저장할 파일 경로>.tar이다. 이 명령은 지정된 배포판의 전체 파일 시스템과 설정을 하나의 .tar 파일로 압축하여 내보낸다. 예를 들어, Ubuntu 배포판을 백업하려면 wsl --export Ubuntu C:\backup\ubuntu_backup.tar와 같이 실행한다. 작업을 수행하기 전에 해당 배포판을 종료(wsl --terminate <배포판 이름>)하는 것이 안정성을 높인다.

백업 파일로부터 새로운 배포판을 복원(가져오기)할 때는 wsl --import <새 배포판 이름> <설치 경로> <백업 파일 경로> 명령어를 사용한다. 이때 설치 경로는 새로운 배포판의 가상 하드 디스크 파일(ext4.vhdx)과 관련 데이터가 저장될 Windows 측 디렉토리를 지정한다. 가져오기 완료 후 wsl -d <새 배포판 이름> 명령으로 실행하여 정상적으로 복원되었는지 확인할 수 있다. 기존 배포판을 교체하려면 먼저 기존 배포판을 등록 해제(wsl --unregister <기존 이름>)한 후 동일한 이름으로 가져오기 작업을 수행하면 된다.

WSL2는 Docker와의 긴밀한 통합을 통해 Windows에서의 컨테이너 기반 개발 경험을 크게 향상시킨다. WSL2는 완전한 Linux 커널을 포함하므로, Linux용 Docker 엔진을 네이티브로 실행할 수 있다. 이는 기존의 Hyper-V 기반 Docker Desktop for Windows와는 다른 접근 방식이다. 사용자는 WSL2 배포판 내에 Docker 데몬을 설치하고, Windows 측의 Docker 클라이언트가 이를 제어하는 방식으로 작업할 수 있다.

보다 일반적인 방법은 공식 Docker Desktop for Windows 애플리케이션을 사용하는 것이다. 최신 버전의 Docker Desktop은 WSL2 백엔드를 완벽하게 지원한다. 설치 시 'WSL 2 기반 엔진 사용' 옵션을 선택하면, Docker 데몬이 가볍고 빠른 WSL2 가상 머신에서 실행된다. 이 방식의 주요 장점은 다음과 같다.

• 성능: 컨테이너 파일 시스템 접근 속도가 WSL1이나 기존 Hyper-V 가상 머신 방식보다 월등히 빠르다.

• 리소스 효율성: 단일 Linux 커널을 공유하여 메모리 사용량이 줄어든다.

• 통합성: Windows 터미널, Visual Studio Code 등 Windows 도구와의 원활한 연동이 가능해진다.

Docker Desktop의 WSL2 통합 모드를 사용할 때의 구성은 아래 표와 같다.

이 통합을 통해 개발자는 Windows 파일 탐색기에서 프로젝트 코드를 편집하면서, 동일한 파일을 WSL2 및 Docker 컨테이너 내에서 고성능으로 빌드하고 실행할 수 있다. 또한, Kubernetes 클러스터도 Docker Desktop을 통해 WSL2 환경에서 실행할 수 있어, 현대적인 마이크로서비스 개발 및 테스트 환경을 구성하는 데 유용하다.

WSL2 설치 과정에서 사용자는 몇 가지 일반적인 오류를 마주할 수 있습니다. 가장 흔한 문제는 시스템의 가상화 기능이 비활성화되어 있는 경우입니다. 이는 BIOS 또는 UEFI 설정에서 Intel VT-x 또는 AMD-V와 같은 하드웨어 가상화 기술을 활성화해야 해결됩니다. Windows 기능에서 'Linux용 Windows 하위 시스템'과 '가상 머신 플랫폼' 옵션이 체크되어 있지 않아도 설치가 실패합니다.

네트워크 환경에 따라, 특히 회사나 학교의 프록시 서버 뒤에서 WSL2 커널 업데이트나 배포판 다운로드가 실패할 수 있습니다. Windows의 인터넷 옵션에서 프록시 설정을 올바르게 구성하거나, 일시적으로 프록시를 우회하여 설치를 시도해야 합니다. Windows 버전이 오래된 경우에도 호환성 문제가 발생할 수 있으며, Windows 10 버전 2004(빌드 19041) 이상 또는 Windows 11이 필요합니다.

일부 안티바이러스 소프트웨어나 방화벽이 WSL2의 가상화 구성 요소를 차단하여 설치 또는 실행을 방해할 수 있습니다. 이 경우 해당 보안 소프트웨어를 일시적으로 비활성화하거나 예외 규칙을 추가해야 합니다. 또한, 이전에 WSL1이 설치된 상태에서 WSL2로 업데이트할 때 발생하는 문제는 관리자 권한의 PowerShell에서 wsl --set-default-version 2 명령을 실행하여 해결할 수 있습니다.

WSL2의 네트워크 문제는 주로 가상화된 네트워크 어댑터와 호스트 Windows 간의 복잡한 상호작용에서 발생합니다. 가장 흔한 문제는 WSL2 인스턴스 내부에서 인터넷 연결이 되지 않는 경우입니다. 이는 종종 호스트의 방화벽 설정, DNS 서버 구성 문제, 또는 가상 네트워크 스위치의 잘못된 설정 때문입니다. 또한, WSL2는 가상 머신에 고유한 IP 주소를 부여하기 때문에, 호스트의 localhost(127.0.0.1)로 직접 접근하지 못하는 경우가 있습니다.

특정 포트를 사용하는 서버 애플리케이션을 실행할 때 연결 문제가 빈번히 보고됩니다. WSL2 인스턴스에서 실행 중인 웹 서버에 Windows의 브라우저로 접근하려면, WSL2의 IP 주소를 직접 사용하거나, Windows 호스트가 WSL2의 localhost 트래픽을 전달하도록 설정해야 합니다. 네트워크 드라이브나 VPN 소프트웨어가 설치된 환경에서는 WSL2의 네트워크 인터페이스가 비정상적으로 구성되어 연결이 끊길 수 있습니다.

문제를 해결하기 위한 첫 단계는 WSL2 인스턴스 내에서 네트워크 진단 명령어(ping, curl, nslookup)를 실행하여 연결 상태를 확인하는 것입니다. Windows 호스트의 Hyper-V 가상 스위치 관리자에서 WSL 관련 네트워크 어댑터의 상태를 점검하는 것도 도움이 됩니다. 지속적인 문제가 발생한다면, wsl --shutdown 명령으로 WSL2를 완전히 종료한 후 재시작하여 가상 네트워크 스택을 초기화하는 방법이 효과적일 수 있습니다.

WSL2에서 발생할 수 있는 일반적인 성능 문제는 주로 파일 시스템 접근 방식과 메모리 관리에서 기인한다. WSL2는 가상 머신 기반 아키텍처를 사용하므로, Linux 배포판 내부의 파일 작업은 매우 빠르지만, Windows 파일 시스템(/mnt/c/ 등)에서 파일을 접근할 때는 성능 저하가 발생할 수 있다. 특히 Node.js의 node_modules나 Git 저장소처럼 작은 파일이 많은 디렉터리를 Windows 측에서 작업하면 상당한 지연이 관찰된다. 이 문제를 완화하려면 프로젝트 파일을 Linux 배포판의 자체 파일 시스템(예: ~/project 경로) 내에서 관리하는 것이 권장된다.

메모리 관련 문제도 흔하다. WSL2 가상 머신은 시작 시 할당된 메모리 양을 동적으로 조정하지만, 때로는 사용하지 않을 때도 메모리를 과도하게 점유하거나, 반대로 메모리 부족으로 인해 프로세스가 강제 종료될 수 있다. 이러한 문제는 사용자 홈 디렉터리에 .wslconfig 파일을 생성하여 메모리 제한을 명시적으로 설정함으로써 해결할 수 있다. 예를 들어, 다음 설정은 WSL2가 사용할 수 있는 메모리를 4GB로 제한한다.

```

[wsl2]

memory=4GB

```

디스크 공간 사용량이 예상치 않게 증가하는 문제도 발생할 수 있다. WSL2는 가상 하드 디스크 파일(ext4.vhdx)을 사용하며, 이 파일은 자동으로 축소되지 않는다. 시간이 지남에 따라 이 파일이 불필요하게 커져 Windows 호스트의 디스크 공간을 차지할 수 있다. 이를 관리하기 위해서는 주기적으로 디스크 공간을 확보하는 명령어를 실행하거나, 배포판을 내렸다가(wsl --shutdown) Windows 디스크 관리 도구를 통해 수동으로 압축해야 한다.

입출력 성능과 관련하여, 안티바이러스 소프트웨어나 실시간 검사 기능이 WSL2의 가상 디스크 파일(.vhdx)을 스캔할 경우 심각한 성능 저하를 초래할 수 있다. 이 문제를 해결하려면 Windows 보안 설정에서 해당 가상 디스크 파일이나 WSL 프로세스(wsl.exe)를 검사 예외 목록에 추가하는 것이 효과적이다. 또한, WSL2 내에서 데이터베이스 서버를 실행할 때는 쓰기 캐싱 정책을 확인하고, 가능하면 Windows 측이 아닌 Linux 파일 시스템 내에 데이터 파일을 저장해야 최적의 성능을 얻을 수 있다.

WSL2는 Windows에서 Linux 기반 개발 환경을 구축하는 데 널리 활용된다. 특히 웹 개발, 서버 사이드 프로그래밍, 임베디드 시스템 개발 등에서 네이티브에 가까운 Linux 경험을 제공하여 생산성을 높인다.

주요 활용 분야는 다음과 같다.

개발자는 Windows 호스트의 Visual Studio Code와 같은 편집기를 사용하면서, WSL2 내부의 Linux 터미널에서 모든 명령어와 도구를 직접 실행할 수 있다. VS Code의 "Remote - WSL" 확장 기능은 원격 개발 환경처럼 WSL2 인스턴스에 직접 연결하여 코드 편집, 디버깅, 터미널 사용을 가능하게 한다. 이를 통해 Windows 파일 시스템과 Linux 파일 시스템 간의 복잡한 설정 없이 통합된 워크플로를 구성할 수 있다.

또한, Docker Desktop은 WSL2 백엔드를 지원하여 Linux 컨테이너를 네이티브에 가까운 성능으로 실행할 수 있다. 이는 컨테이너 기반 마이크로서비스 개발 및 테스트에 매우 유리한 환경을 제공한다. WSL2는 Kubernetes 개발 환경이나 복잡한 멀티서비스 애플리케이션의 로컬 테스트에도 효과적으로 사용된다.

WSL2는 리눅스 기반의 데이터 과학 및 머신러닝 개발 환경을 Windows에서 구축할 수 있는 강력한 플랫폼을 제공합니다. 이를 통해 연구자와 개발자는 CUDA 및 GPU 가속을 활용한 딥러닝 모델 학습, 대규모 데이터 처리, 그리고 리눅스 생태계의 다양한 데이터 과학 도구들을 윈도우 운영체제를 전환하지 않고도 활용할 수 있습니다.

주요 활용 분야는 다음과 같습니다. Python과 R을 포함한 데이터 분석 언어의 네이티브 리눅스 환경 실행, Jupyter Notebook 또는 JupyterLab을 이용한 대화형 분석 및 시각화, 그리고 TensorFlow, PyTorch, scikit-learn 같은 머신러닝 프레임워크의 설치 및 사용이 포함됩니다. WSL2는 완전한 시스템 호출 호환성을 제공하므로, 이러한 도구들은 네이티브 리눅스와 거의 동일한 성능과 동작을 보입니다.

GPU 가속 지원은 WSL2의 가장 중요한 장점 중 하나입니다. Windows 11 및 Windows 10의 특정 버전부터는 WSL2 내부의 리눅스 배포판이 호스트의 NVIDIA 또는 AMD GPU를 직접 인식하고 활용할 수 있습니다[15]. 이를 통해 다음과 같은 작업이 가능해집니다.

또한, Docker와의 원활한 통합은 재현 가능한 연구 환경 구축에 기여합니다. 데이터 과학자는 리눅스용 Docker 컨테이너 이미지를 WSL2 내에서 직접 실행하여, 프로젝트별로 격리된 의존성 환경을 쉽게 관리할 수 있습니다. 이는 팀 협업과 프로덕션 배포 파이프라인으로의 이행을 용이하게 합니다. 결국 WSL2는 윈도우 사용자가 데이터 과학 워크플로우 전반에 걸쳐 리눅스의 유연성과 강력한 성능을 누릴 수 있는 교량 역할을 합니다.

WSL2는 리눅스 운영 체제와 그 생태계를 학습하는 데 효과적인 도구를 제공합니다. 기존에 가상 머신을 사용할 경우 발생하는 높은 시스템 리소스 점유와 복잡한 설정 과정 없이, 학습자는 Windows 환경을 유지한 채 빠르게 리눅스에 접근할 수 있습니다.

명령줄 인터페이스, 쉘 스크립트, 패키지 관리 시스템(apt나 yum 등)과 같은 리눅스의 기본 개념을 실습하는 데 이상적인 환경입니다. 또한 Python, C++, GCC 컴파일러, Apache 웹 서버 등 다양한 오픈 소스 개발 도구와 서버 소프트웨어를 네이티브에 가까운 성능으로 설치하고 실행해 볼 수 있습니다. 이를 통해 운영 체제 이론, 시스템 프로그래밍, 네트워크 서버 구축 등 실무적인 컴퓨터 과학 교육이 용이해집니다.

다양한 리눅스 배포판을 쉽게 설치하고 전환할 수 있어, Ubuntu, Debian, Fedora 등 각 배포판의 특징과 차이점을 비교 학습하는 데도 유용합니다. Windows 파일 시스템과의 원활한 상호 접근성을 통해, 학습 중 생성된 코드나 문서를熟悉的한 Windows 응용 프로그램으로 편집하고, 리눅스 환경에서 빌드 및 실행하는 워크플로우도 자연스럽게 익힐 수 있습니다.