맥북 대신 Windows + WSL2를 메인 개발 환경으로 전환한 백엔드 개발자의 1년 경험을 3인칭으로 정리했다. .wslconfig 설정, Docker 성능, 파일시스템 함정, 실제 결론까지.
한 줄 요약: 맥북 대신 Windows + WSL2를 메인 개발 환경으로 전환한 백엔드 개발자가 1년간 겪은 실제 경험 — 뭐가 됐고, 뭐가 안 됐고, 지금은 어떻게 쓰고 있는지.
※ 이 글은 Node.js + PostgreSQL 기반 SaaS를 개발하는 백엔드 개발자 이씨(가명)의 1년간 경험을 3인칭으로 재구성한 케이스 스터디다. 2025년 초 전환 시작, 2026년 2월 기준 작성.
이씨는 5년간 맥북 프로를 메인 개발 머신으로 써왔다. 2024년 말, 맥북 M3 Pro 가격을 보고 멈칫했다. 동등 스펙 기준 윈도우 노트북 대비 약 1.5배 차이. 게다가 이씨의 주된 사이드 프로젝트는 게임이었다. macOS는 게이밍 플랫폼으로 사실상 비어 있다.
결정적인 계기는 회사 정책 변경이었다. 팀 전체가 지급 노트북을 Windows 기기로 통일했고, 이씨는 "집에서도 같은 환경"을 써보기로 했다. 개인 맥북을 팔고, Lenovo ThinkPad X1 Carbon(2024) + WSL2 조합으로 전환했다. 예산 절감 40만 원, 무게 1.12kg, 배터리 22시간이라는 계산이 맞았다.
그가 가장 걱정한 건 두 가지였다. Docker 성능과 Unix 툴체인의 완성도. 맥북에서 brew install 한 줄로 되던 것들이 Windows에서는 얼마나 복잡해질지 알 수 없었다.
이씨는 WSL2 설치에서 첫 번째 장벽을 만났다. Windows 11 Home 에디션에서 기본 설치 명령은 동작했지만, 설치 후 Ubuntu를 실행하면 "WslRegisterDistribution failed" 오류가 났다. 원인은 BIOS에서 Virtualization 옵션이 꺼져 있던 것이었다. BIOS 진입 후 "Intel VT-x" 활성화로 해결했다.
초기 환경 구성에는 약 3일이 걸렸다. Ubuntu 22.04 LTS를 기본 distro로 선택하고, dotfiles 레포를 클론해서 zsh, Neovim, tmux 설정을 옮겼다. Node.js는 nvm으로, Python은 pyenv로 관리했다. VS Code의 "Remote - WSL" 확장을 설치하면 WSL2 파일시스템에서 직접 편집이 가능해졌다.
WSL2 설치 및 Ubuntu 배포판 구성# PowerShell (관리자 모드) wsl --install wsl --install -d Ubuntu-22.04 # 설치 후 Ubuntu 터미널에서 sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential curl git zsh # oh-my-zsh 설치 sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" # Node.js — nvm 방식 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install --lts nvm use --lts # Python — pyenv 방식 curl https://pyenv.run | bash pyenv install 3.12.3 pyenv global 3.12.3
Docker는 Docker Desktop for Windows를 설치하고 "Use the WSL 2 based engine" 옵션을 켰다. WSL2 통합 설정에서 Ubuntu-22.04를 활성화하면 WSL2 터미널에서 docker 명령을 바로 쓸 수 있었다. 이씨는 이 과정에서 "생각보다 macOS랑 비슷하다"는 인상을 받았다고 한다.
3개월간 이씨가 가장 만족한 건 VS Code Remote WSL 경험이었다. WSL2 파일시스템 안에서 직접 코드를 열면 linting, TypeScript 타입 검사, 터미널 명령 모두 Linux 환경 그대로 동작한다. macOS에서 개발할 때와 사실상 동일한 DX였다.
Node.js 기반 프로젝트의 npm install과 빌드 속도는 macOS M2와 비교해 큰 차이를 느끼지 못했다. Docker 컨테이너 기동 시간은 오히려 빨라진 케이스도 있었다. 이씨가 주로 쓰는 PostgreSQL + Redis 컨테이너 스택은 docker compose up 기준 평균 4초 이내로 올라왔다.
또 하나의 장점은 리소스 분리였다. macOS에서는 브라우저, 슬랙, Docker가 모두 같은 커널을 공유했지만, WSL2는 VM 위에 격리되어 있어서 메모리 사용 패턴이 더 예측 가능했다. 이씨는 WSL2에 8GB를 고정 할당하고 Windows 측에 나머지를 배분했다.
6개월 차에 이씨는 WSL2의 파일시스템 경계 문제를 처음으로 심각하게 겪었다. Windows 드라이브(/mnt/c/)에 있는 파일을 WSL2에서 접근하면 I/O 속도가 수십 배 느려진다. 이씨는 초반에 OneDrive 폴더 안에 프로젝트를 넣었다가 npm install에 4분이 걸리는 상황을 겪었다.
해결책은 명확했다. 모든 프로젝트 파일을 WSL2 내부 파일시스템(~/projects/)으로 옮기는 것이다. Windows 측에서 파일을 건드릴 일이 없으면 I/O 병목은 사라진다. 그러나 이 경계선을 처음 셋업 때 명확히 인지하지 못하면 "WSL2 느리다"는 오해를 하게 된다.
두 번째 장벽은 Docker Desktop 메모리 누수였다. 하루 종일 작업하면 Docker Desktop 프로세스가 Windows 측에서 6~8GB를 점유하는 현상이 반복됐다. 이 문제는 2025년 중반 Docker Desktop 업데이트로 개선됐지만, 이씨가 처음 전환했던 당시에는 하루에 한 번 재시작이 필요했다.
/mnt/c/에 두면 I/O가 10~50배 느려진다. 반드시 WSL2 홈 디렉토리(~/) 안에 넣을 것.wslconfig로 상한을 지정할 것localhost 접근이 끊길 수 있다. mirrored 네트워크 모드(Windows 11 22H2+) 적용으로 해결이씨가 6개월 시점에 .wslconfig 파일을 제대로 설정하면서 체감 품질이 크게 달라졌다고 한다. 이 파일은 Windows 사용자 홈 디렉토리(C:\Users\username\.wslconfig)에 위치하며, WSL2 VM 전체의 리소스 상한과 네트워크 모드를 제어한다.
.wslconfig — WSL2 VM 리소스 최적화 설정 (Windows 11 22H2+)# C:\Users\{username}\.wslconfig [wsl2] # 메모리 상한 (권장: 물리 RAM의 40~50%) memory=8GB # CPU 코어 수 (물리 코어 수 이하로 지정) processors=6 # 스왑 파일 크기 swap=4GB # 네트워크 모드: mirrored = Windows와 IP 공유 (22H2+) networkingMode=mirrored # DNS 터널링 활성화 (VPN 환경에서 필수) dnsTunneling=true # 자동 메모리 해제 활성화 (gradualRelease 권장) autoMemoryReclaim=gradualRelease # 파일시스템 캐시 해제 허용 [experimental] sparseVhd=true
특히 networkingMode=mirrored는 Hyper-V와의 충돌로 VPN이나 로컬 포트 바인딩이 불안정했던 문제를 해결했다. 이 설정 하나로 이씨가 경험하던 "갑자기 localhost:3000에 접근이 안 된다"는 현상이 사라졌다.
autoMemoryReclaim=gradualRelease는 Linux 커널의 파일 캐시가 차지하던 메모리를 점진적으로 Windows에 돌려주는 설정이다. 장시간 작업 시 메모리가 계속 점유되던 문제가 눈에 띄게 개선됐다.
1년간 이씨가 WSL2로 처리한 주요 작업은 Node.js + TypeScript 백엔드 서비스 개발, PostgreSQL 마이그레이션 스크립트 작성, Python 기반 데이터 파이프라인 구축이었다. 이 모든 작업에서 WSL2는 "충분히" 작동했다고 한다. macOS에서 불가능했던 것이 가능해진 건 없지만, 불가능해진 것도 없었다.
가장 크게 달라진 건 게임과 개발을 하나의 기기에서 할 수 있게 됐다는 점이다. 이씨는 퇴근 후 같은 노트북에서 Steam을 열고, 작업할 때는 Windows Terminal에서 WSL2를 열었다. 두 환경 전환에 걸리는 시간은 3초였다.
반면 1년간 계속 불편했던 것도 있었다. GUI 앱이 필요한 경우였다. Figma, Postman 같은 앱은 Windows 버전을 쓰면 됐지만, Linux 전용 디버깅 도구나 일부 오픈소스 CLI의 GUI 컴포넌트는 WSLg(WSL2 GUI 지원)를 통해 실행했는데 반응속도가 네이티브 대비 미묘하게 느렸다. 일상 업무에서는 문제없었지만, 빠른 반복이 필요한 UI 프로토타이핑에서는 아쉬움이 남았다.