WSL2 프로젝트를 Windows 드라이브에 두면 성능이 떨어지는 이유는 다음과 같습니다

Windows Subsystem for Linux를 처음 사용하기 시작하면 모든 것이 정상적으로 작동하는 것처럼 보입니다. 저장소를 복제하고, 의존성을 설치하고, 앱을 실행할 수 있으며, 이제 자신이 '윈도우에서 리눅스를 실행하고 있다'고 스스로 확신할 수도 있습니다.

그러면 뭔가 이상하다고 느껴지고, 즉시 처리되어야 할 명령어들이 눈에 띄게 시간이 걸리는 것을 알아차리게 됩니다. 패키지 설치가 느려지고, 파일 감시 기능이 이상하게 작동하며, 개발 서버는 어느 한 가지 원인으로는 설명하기 어려운 방식으로 느려집니다. 처음에는 명백한 범인인 WSL2 자체가 원인으로 지목되지만, 보통 이것은 잘못된 판단입니다.

진짜 문제는 당신의 파일이 어디에 있는가입니다

Windows 파일 시스템은 숨겨진 성능 저하를 일으킨다

당신의 프로젝트가 다음과 같은 곳에 위치해 있다면:

/mnt/c/Users/YourName/projects/my-app

당신은 실제로 리눅스 파일 시스템에서 작업하고 있는 것이 아닙니다. 당신은 번역 계층을 통해 접근한 윈도우 파일 시스템에서 작업하고 있는 것입니다.

그 세부 사항은 놓치기 쉽고 놀랄 만큼 비쌉니다. WSL2는 가벼운 가상 머신 안에서 실제 Linux 커널을 실행합니다. 그 환경 안에는 네이티브 Linux 파일 시스템이 있습니다. 그것은 빠르고 일관되며 Linux 도구가 기대하는 방식 그대로 동작합니다.

그러나 /mnt/c, /mnt/d 또는 마운트된 Windows 드라이브에서 파일에 접근할 때, 모든 파일 작업은 Linux와 Windows 사이의 경계를 넘어야 합니다. 바로 이 경계에서 성능이 떨어지게 됩니다(조용히, 오류를 발생시키지 않고, 이 점이 더 문제입니다).

왜 이것이 실제로 속도를 늦추는가

파일 중심 워크플로우는 파일시스템 변환 오버헤드를 증폭시킨다

현대 개발 워크플로우는 파일 사용량이 매우 많습니다. 다음과 같은 작업을 실행할 때 어떤 일이 발생하는지 생각해 보세요:

npm install
pip install
cargo build
npm run dev

이 도구들은 수천 개의 작은 파일을 생성, 읽기, 수정합니다. 이들은 빠른 파일 시스템 접근과 예측 가능한 동작에 의존합니다.

네이티브 리눅스 파일 시스템에서는 이것이 최적화되어 있지만, WSL2를 통해 접근하는 윈도우 파일 시스템에서는 이러한 각 작업이 두 가지 다른 시스템 간의 변환을 수반합니다.

결과적으로, 일은 진행되지만 모든 것이 단지 더 느릴 뿐입니다. 때로는 2배 느리고, 때로는 10배 느리며, 어떤 경우에는 더 심할 수 있습니다. 느려짐이 많은 작은 작업들에 분산되어 있기 때문에 항상 즉시 눈치채는 것은 아니지만, 시간이 지나면서 누적됩니다.

이 문제를 관찰하는 가장 쉬운 방법 중 하나는 Git을 사용하는 것입니다. /mnt/c에 저장된 대형 저장소에서 git status나 git checkout을 실행하고, 동일한 저장소를 Linux 홈 디렉토리 안에서 실행한 것과 비교해 보세요.

차이는 미묘하지 않습니다. Git은 많은 파일 시스템 작업을 수행하기 때문입니다. 디렉토리를 스캔하고, 메타데이터를 확인하며, 파일 상태를 비교합니다. 느린 파일 시스템 브리지를 사용할 경우, 이 점은 매우 명확하게 드러납니다. 사람들은 종종 Git 자체를 탓하거나 자신의 저장소가 '단지 크다'고 생각합니다. 실제로는 파일 시스템 선택이 대부분의 문제를 일으키고 있습니다.

또 다른 일반적인 증상은 신뢰할 수 없는 파일 감시입니다. webpack, Vite, 또는 nodemon과 같은 도구는 변경 사항을 감지하기 위해 파일 시스템 이벤트에 의존합니다. 네이티브 Linux 파일 시스템에서는 이러한 이벤트가 효율적으로 전달됩니다.

윈도우 경계를 넘으면 상황이 일관되지 않게 된다.

다음을 볼 수 있습니다:

변경 사항이 재빌드를 트리거하지 않음
지연된 재장전
폴링 대체 기능으로 인한 CPU 사용량 증가

이는 당신의 도구의 버그가 아니라 파일 시스템 알림이 Windows와 Linux 간에 번역되는 방식의 결과입니다. 프로젝트를 WSL2의 파일 시스템으로 옮기면 이러한 문제들은 사라지는 경향이 있습니다.

/mnt/c의 오해를 불러일으키는 편리함

편리함은 교차 시스템 접근의 비용을 숨긴다

사람들이 결국 여기로 오게 되는 이유는 완전히 이해할 수 있습니다. 윈도우에서 시작하면 파일과 편집기가 그곳에 있습니다. /mnt/c를 통해 WSL2에서 접근하는 것이 자연스럽게 느껴집니다.

이것은 통합된 환경이라는 착각을 줍니다. 하나의 파일 시스템이 Windows와 Linux 모두에서 접근 가능하지만, 실제로 통합된 것이 아니라 브리지된 것이며, 브리지는 비용이 듭니다.

이 설정은 가끔 파일에 접근할 때는 괜찮지만, 고빈도 파일 시스템 작업에 의존하는 활발한 개발 작업에는 적합하지 않습니다.

WSL2 안에서 Linux 파일 시스템에서 작업할 때, 차이는 즉시 느껴집니다. 경로는 다음과 같이 보입니다:

이제 당신은 완전히 리눅스 환경 내에서 작동하며, 번역 계층이나 교차 OS 오버헤드가 없습니다. 이 디렉터리 내에서 의존성 설치를 시도하면 설치가 더 빠르게 완료되고, 개발 서버도 더 빨리 시작되며 신뢰성 있게 다시 로드됨을 알 수 있습니다.

그런데 Windows에서 접근하는 것은 어떡하죠?

여전히 /mnt/c를 사용할 수 있을 때

일부 작업 부하는 여전히 Windows 파일 시스템의 혜택을 받습니다

공정하게 말하면, 이 문맥에서 Windows 파일 시스템이 쓸모없다고 할 수는 없습니다. 문서나 미디어 파일에 접근하거나, 간단한 스크립트를 여러 환경에서 공유하거나, Windows 전용 도구와의 상호 운용성과 같은 유효한 사용 사례가 있습니다. 하지만 활성 개발, 특히 큰 의존성 트리나 잦은 파일 작업을 포함하는 경우에는 프로젝트를 두기에는 적절하지 않습니다. WSL2를 'Windows 안의 Linux'로 생각하기보다는 Windows와 잘 통합되는 별도의 Linux 시스템으로 생각하는 것이 도움이 됩니다.

그 모델을 채택하면 파일 시스템 결정은 명백해집니다. 일반적으로 지연 시간이 높은 네트워크 장착 파일 시스템에서 Linux 프로젝트를 개발하지는 않습니다. 로컬에 유지할 것입니다. WSL2에서는 Linux 파일 시스템이 로컬 환경이고 Windows 파일 시스템은 Linux의 관점에서 사실상 원격입니다.

고치는 데 몇 분 걸린다

프로젝트를 이동하거나 Linux 파일 시스템 안에 복제하기

해결책은 복잡하지 않습니다. 단지 프로젝트를 이동하기만 하면 됩니다:

mv /mnt/c/Users/YourName/projects/my-app ~/projects/

또는 WSL2 안에서 직접 다시 클론하십시오:

git clone <repo>  ~/projects/my-app

새 위치를 열도록 편집기를 업데이트하세요.

성능은 튜닝보다 위치에 더 의존한다

WSL2는 자체 내부 경계를 존중하는 완전한 리눅스 환경으로 취급될 때 가장 잘 작동합니다. 프로젝트가 그 공간 안에서 실행되는 순간, 하이브리드 워크플로우와 관련된 대부분의 마찰이 사라집니다. Windows는 인터페이스 계층으로서 유용함을 유지하지만, 실행 컨텍스트는 다시 일관성을 가지게 되며, 도구들은 설계된 대로 작동합니다.

흥미로운 점은 그 상태에 도달하는 데 필요한 노력이 거의 없다는 것입니다. 위치의 변화가 대부분의 구성 조정보다 성능에 더 큰 영향을 미칩니다. 일단 그것이 직관적으로 이해되면, 이전의 행동은 신비로워 보이기보다는 지속적인 왕복 접근을 위해 최적화되지 않은 시스템을 넘는 예측 가능한 결과처럼 보이기 시작합니다.