개발 환경 선택: WSL과 VPS의 차이점 비교

개발 환경으로 WSL을 사용해야 할까요, 아니면 VPS를 사용해야 할까요?

개발 환경으로서 WSL과 VPS의 차이는 '가용성'이라는 단 하나의 특성으로 귀결됩니다. WSL(Windows Subsystem for Linux)은 Windows 세션의 생사와 운명을 같이하는 가상 머신 내부에서 Ubuntu를 실행합니다. 반면 VPS(Virtual Private Server)는 노트북을 닫아도 계속 켜져 있는 공인 IP 주소 위에서 동일한 Ubuntu를 실행합니다. 대부분의 개발자는 결국 두 환경을 모두 사용하게 되며, 서버는 외부에서 항상 접근 가능한 머신으로 활용합니다.

운영체제는 둘 다 Ubuntu이므로 흥미로운 차이점이 아닙니다. 실제로 차이가 나는 부분은 가동 시간(uptime), 인터넷을 통한 접근성, systemd가 보장할 수 있는 범위, 파일 입출력 속도, 네트워크 동작 방식, 그리고 백업 주체입니다. 아래의 각 섹션은 여러분의 머신에서 직접 확인할 수 있는 차이점들을 다룹니다.

노트북을 닫으면 왜 WSL이 중단됩니까?

WSL 2는 Windows가 필요할 때 시작하는 경량 가상 머신에서 실제 Linux 커널을 실행합니다. 해당 가상 머신은 배포판이 실행되는 동안에만 존재하며, 배포판은 무언가가 그것을 사용하고 있을 때만 실행됩니다. PowerShell에서 상태를 확인하십시오:

wsl --version
wsl --list --running

모든 WSL 터미널을 닫고 1분을 기다린 다음, wsl --list --running를 다시 실행하십시오. 실행 중인 배포판이 없다고 보고되면, 시작했던 셸과 그 안에서 실행 중이던 모든 것이 종료된 것입니다. wsl --shutdown은 즉시 동일한 작업을 수행하며, 이는 재시작 후 설정이 어떻게 동작하는지 테스트하는 유용한 방법입니다.

절전 모드와 최대 절전 모드 역시 가상 머신을 중단시킵니다. 03:00에 데이터베이스를 덤프하도록 설정된 타이머는 노트북 덮개가 닫혀 있는 동안에는 작동하지 않습니다. 이를 실행해야 할 커널이 실행되고 있지 않기 때문입니다. 오류를 기록하는 프로세스가 없으므로, 작업은 마치 예약된 적이 없는 것처럼 보입니다. 이러한 단일 동작 때문에 사용자들이 두 번째 머신을 찾게 됩니다. 빌드 큐, 챗봇, 야간 백업 또는 웹훅 수신기 등은 모두 항상 켜져 있는 컴퓨터가 필요하기 때문입니다.

WSL에서 systemd가 작동합니까?

네, 작동합니다. WSL 0.67.6 버전부터 지원이 추가되었으며, 이전 설치 환경에서는 기본적으로 꺼져 있습니다. 이 기능이 없으면 systemctl status ssh는 다음과 같이 출력합니다.

System has not been booted with systemd as init system (PID 1). Can't operate.

이미 설정 파일이 있을 수 있으므로 먼저 파일을 읽어 보십시오. 파일에 [boot] 섹션이 없다면 새로 추가하고, 이미 있다면 해당 섹션 안에 한 줄을 추가하십시오.

cat /etc/wsl.conf
sudo tee -a /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

PowerShell에서 wsl --shutdown을 실행한 뒤, 새로운 Ubuntu 셸을 열고 systemctl list-units --type=service --state=running로 확인하십시오. 유닛 목록이 나타나면 systemd가 PID 1로 동작 중인 것이며, 그 시점부터 journalctl -b을 사용할 수 있습니다.

문제는 각 머신에서 enable가 보장하는 바가 다르다는 점입니다. VPS 환경에서 sudo systemctl enable --now caddy은 서비스가 부팅 시점에 시작됨을 의미하므로, 재부팅이나 커널 업그레이드 후 아무도 로그인하지 않은 상태에서도 서비스가 복구됩니다. 반면 WSL에서 이는 배포판이 시작될 때 서비스가 시작됨을 의미하며, 배포판은 터미널을 열 때 시작됩니다. 따라서 서비스는 작업 중일 때만 실행되는데, 이는 서비스가 존재하는 목적과는 반대되는 상황입니다. 컨테이너도 동일한 한계를 가지며, 이것이 바로 Docker Compose 서비스를 부팅 시 시작하도록 설정하는 것이 사용자가 직접 요청할 때만 수행되는 WSL의 부팅 과정에 의존하게 되는 이유입니다.

WSL에서 실행 중인 서버에 웹훅으로 접근할 수 있습니까?

도움 없이는 불가능하며, 그 이유는 네트워크 구성 때문입니다. 기본 모드에서 WSL 2는 가상 머신을 자체 가상 어댑터의 NAT(네트워크 주소 변환) 뒤에 배치합니다. 주소를 확인해 보십시오:

ip -4 addr show eth0
ip route show default

해당 주소는 사설 IP이며 가상 머신이 시작될 때마다 다시 할당되므로 계속 변경됩니다. WSL은 localhost 연결을 배포판으로 전달하므로 Windows 자체는 localhost:3000에 접근할 수 있습니다. 하지만 관리자 권한의 PowerShell에서 프록시 규칙을 추가하지 않는 한, 네트워크상의 다른 컴퓨터는 접근할 수 없습니다:

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.24.108.3

이 규칙은 특정 주소를 지정하므로 주소가 변경될 때마다 규칙이 깨집니다. 미러링된 네트워킹(mirrored networking)을 사용하는 것이 더 나은 선택입니다. 이 모드를 사용하면 배포판이 Windows와 동일한 인터페이스와 주소를 갖게 됩니다. 2026년 8월 기준으로 Windows 11 22H2 이상이 필요합니다. %UserProfile%\.wslconfig에 다음 내용을 넣고 wsl --shutdown을 실행하십시오:

[wsl2]
networkingMode=mirrored

미러링 모드는 로컬 네트워크 문제를 해결하지만, 공인 IP 주소를 제공하지는 않습니다. 라우터가 다시 NAT를 수행하고, 대부분의 가정용 연결은 제어 가능한 인바운드 포트가 없으며, 많은 ISP가 그 위에 NAT 계층을 하나 더 추가합니다. 따라서 GitHub는 노트북에 이벤트를 POST할 수 없고, 동료는 데모 링크를 열 수 없습니다. 터널링 서비스를 사용하면 이를 우회할 수 있지만, 터널 클라이언트가 노트북에서 실행되어야 하므로 노트북을 계속 켜두어야 합니다.

VPS는 이 문제의 반대편에서 시작합니다. VPS는 공인 IPv4 주소와 일반적으로 공인 IPv6 주소를 가지며, 사용자가 개방한 포트만 노출됩니다. A 레코드를 해당 주소로 지정하고 80번과 443번 포트를 허용하면 어디서든 응답을 받을 수 있습니다. 이는 공인 인증서를 위한 조건이기도 합니다. HTTP-01 챌린지는 Let's Encrypt가 공인 도메인의 80번 포트를 통해 파일을 가져오도록 요구하기 때문입니다. Certbot과 nginx로 Let's Encrypt 인증서 발급받기는 서버에서 5분이면 끝나는 작업이지만 WSL에서는 불가능합니다. 로컬 작업의 경우 Ubuntu 신뢰 저장소에 자체 CA 추가하기를 통해 WSL 내부에서도 브라우저가 신뢰하는 HTTPS를 사용할 수 있습니다.

왜 /mnt/c에서 git이 느린가요?

파일이 Linux 파일 시스템에 위치하지 않기 때문입니다. WSL은 비용이 크게 다른 두 가지 저장 영역을 제공합니다. 홈 디렉터리는 가상 디스크 내부의 ext4 파일 시스템에 위치하며 일반적인 Linux 디스크처럼 동작합니다. /mnt/c는 Windows 드라이브이며, Windows 측 구성 요소가 9P 프로토콜(Plan 9 파일 시스템 프로토콜)을 통해 제공하므로 모든 open 및 stat 호출이 해당 경계를 넘나들어야 합니다.

파일 하나를 다루는 것은 괜찮습니다. 대규모 저장소에서 git status를 실행하면 수천 번의 stat 호출이 발생하며, 호출마다 경계를 넘는 비용이 발생합니다. 이 페이지를 포함하여 타인의 수치를 맹신하지 말고 직접 측정하십시오.

cd /mnt/c/Users/you/code/myrepo && time git status
cp -r /mnt/c/Users/you/code/myrepo ~/myrepo
cd ~/myrepo && time git status

각 명령을 두 번씩 실행하고 두 번째 실행 결과를 비교하여 캐시가 준비된 상태에서 측정하십시오. Windows 실시간 백신 검사는 /mnt/c 측에 추가적인 비용을 발생시키며, 이것이 동일한 저장소라도 개인용 노트북보다 회사용 노트북에서 더 느리게 느껴지는 이유입니다.

WSL 내부에서의 해결책은 작업 복사본을 ~ 아래에 유지하고, 편집기의 WSL 원격 모드로 여는 것입니다. 이렇게 하면 편집기 서버가 경계를 넘어 접근하는 대신 배포판 내부에서 실행됩니다. Windows 탐색기는 여전히 \\wsl.localhost\Ubuntu\home\you 경로를 통해 해당 파일을 탐색할 수 있습니다. VPS는 단일 Linux 파일 시스템을 사용하므로 이러한 문제가 없습니다. VPS 사용 시 발생하는 비용은 편집 중의 네트워크 지연 시간이며, 이를 위해 사용자는 터미널 멀티플렉서나 원격 편집기 세션을 사용합니다. 공유 CPU는 소형 서버에서 주의해야 할 사항이며, 이웃 프로세스로 인한 steal time은 top의 st 열에 표시됩니다.

WSL이 확실하게 우위를 점하는 부분

• 무료이며 이미 기기에 설치되어 있습니다. 기능을 켜고 Ubuntu를 설치하면 1분 안에 작업을 시작할 수 있으며, 비용이 들지 않고 방어해야 할 외부 공개 표면도 없습니다.
• 서버와 달리 일회성으로 사용하기 좋습니다. wsl --export Ubuntu D:\wsl-backups\ubuntu.tar은 전체 배포판을 하나의 파일로 기록하며, wsl --import는 이를 복원하거나 다른 이름으로 복제합니다. 새로운 Ubuntu 릴리스를 테스트할 때, VPS를 24.04에서 26.04로 업그레이드하는 것은 실행 중인 서비스 때문에 일정을 조정해야 하는 일방향 작업인 반면, WSL에서는 복제와 롤백으로 간단히 해결됩니다.
• GPU 작업이 직접적입니다. 최신 Windows GPU 드라이버를 사용하면 배포판 내부에서 그래픽 카드를 사용할 수 있으므로, CUDA 및 ROCm 워크로드를 이미 보유한 하드웨어에서 실행할 수 있습니다. 동일한 등급의 GPU를 시간 단위로 대여하는 것은 상당한 비용이 듭니다.
• 편집 루프가 더 짧습니다. 파일과 브라우저가 모두 로컬에 있으므로, localhost:5173에서 실행 중인 개발 서버를 이미 로그인된 브라우저에서 바로 열 수 있습니다.

이러한 점들은 실질적인 장점이며, 보통 한 대의 기기보다는 두 대의 기기를 모두 사용하는 것이 권장되는 이유입니다.

백업의 소유권은 누구에게 있습니까?

두 환경 모두 귀하에게 있으며, WSL의 경우 이 사실이 사용자들을 놀라게 하곤 합니다. 배포판은 Windows 사용자 프로필 내의 가상 디스크 파일(ext4.vhdx) 형태로 존재합니다. 어떤 공급자도 이를 대신 스냅샷으로 저장해주지 않습니다. wsl --unregister Ubuntu는 실행 시 되돌릴 방법 없이 파일을 삭제하며, Windows를 재설치하면 해당 파일도 다른 모든 데이터와 함께 사라집니다. 실제로 지킬 수 있는 일정에 맞춰 내보내기를 수행하십시오.

wsl --export Ubuntu D:\wsl-backups\ubuntu-2026-08-18.tar

VPS의 경우, 공급자가 제공하는 스냅샷은 호스트 장애로부터 귀하를 보호합니다. 하지만 잘못된 디렉터리에서 rm -rf을 실행하는 실수로부터는 보호해주지 않으며, 서버와 동일한 계정에 보관된 스냅샷은 로그인 정보가 탈취되는 순간 서버와 함께 사라집니다. 파일 단위 백업을 서버 외부로 전송하고, 실제 복구가 필요하기 전에 미리 복원 테스트를 수행하십시오. 두 경우 모두 책임은 귀하에게 있습니다. 실질적인 차이점은 서버는 노트북을 켜둘 필요 없이 오전 03:00에 스스로 백업을 수행할 수 있다는 점입니다.

브리지: WSL에서 VPS로 SSH 연결하기

두 번째 머신을 사용하는 것은 연결 설정이 제대로 완료되기 전까지는 번거롭게 느껴질 수 있습니다. WSL 내부에서 다음 과정을 한 번만 수행하십시오.

개인 키가 Unix 권한을 유지하며 ssh에서 정상적으로 인식되도록, Windows 측이 아닌 배포판 내부에서 키를 생성하십시오.

ssh-keygen -t ed25519 -C "dev@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Ed25519 키는 짧고 빠릅니다. ssh-copy-id은 서버의 ~/.ssh/authorized_keys에 올바른 권한으로 공개 키를 추가합니다. SSH 키 관리 기초에서 나중에 키를 교체하거나 폐기하는 방법을 다룹니다.

~/.ssh/config에 서버 이름을 지정하십시오.

Host dev
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ForwardAgent yes
  ServerAliveInterval 30

이제 ssh dev로 연결할 수 있습니다. IdentitiesOnly yes는 클라이언트가 보유한 모든 키를 제공하지 않도록 하여, 에이전트에 여러 키가 로드되었을 때 발생하는 Too many authentication failures 오류를 방지합니다. ServerAliveInterval 30는 가정용 네트워크 연결에서 세션이 메시지 없이 끊기는 현상을 방지합니다.

ForwardAgent yes는 워크플로우를 원활하게 만드는 핵심 설정입니다. 노트북의 에이전트에 키가 로드되어 있으면, 개인 키를 서버에 복사하지 않고도 git clone git@github.com:you/app.git을 사용할 수 있습니다. VPS에서 ssh -T git@github.com을 실행하여 테스트하십시오. Hi you! You've successfully authenticated이라는 응답이 돌아와야 합니다. 에이전트 포워딩은 신뢰할 수 있는 서버에만 사용하십시오. 해당 머신의 root 사용자는 사용자가 연결되어 있는 동안 에이전트 소켓을 사용할 수 있기 때문입니다. 다른 사람과 공유하는 서버라면 저장소별 배포 키(deploy key)를 사용하는 것이 더 안전합니다.

WSL은 셸 간에 에이전트를 유지하지 않으므로, 새 터미널을 열 때마다 키를 다시 요구합니다. keychain로 이 문제를 해결할 수 있습니다.

sudo apt update && sudo apt install -y keychain
echo 'eval "$(keychain --eval --quiet id_ed25519)"' >> ~/.bashrc

새 셸을 열고 ssh-add -l을 실행하십시오. 키 지문(fingerprint)이 출력되어야 합니다. Error connecting to agent이 출력된다면 해당 설정 파일이 읽히지 않는 것이므로, 셸이 실제로 ~/.bashrc를 소스(source)하는지 확인하십시오.

연결이 끊겨도 작업이 종료되지 않도록 터미널 멀티플렉서 내부에서 서버 작업을 실행하십시오.

tmux new -s dev
# Ctrl-b then d to detach
tmux attach -t dev

노트북을 닫아도 빌드는 계속 진행됩니다. 이것이 바로 두 번째 머신을 사용하는 주된 이유입니다. 이와 같은 패턴으로 많은 사용자가 tmux를 사용하여 VPS에서 Claude Code를 실행하고, 다른 장치에서 세션을 다시 불러와 작업을 이어갑니다.

서버에 무엇인가를 설치하기 전에 보안을 강화하십시오. 새 VPS에서의 첫 10분 가이드에서는 root가 아닌 사용자 생성, 키 기반 SSH 인증, 방화벽 설정, 자동 보안 업데이트를 차례대로 다룹니다. 이 순서를 따라야 서버 접속이 차단되는 상황을 방지할 수 있습니다.

어떤 작업에 어떤 머신을 사용해야 할까요?

작업이 사용자의 화면에서 이루어지는 경우에는 WSL을 사용하십시오. 편집, 테스트 스위트 실행, localhost에서의 개발 서버 구동, 노트북, GPU 실험 등 시작한 뒤 계속 지켜봐야 하는 모든 작업이 이에 해당합니다.

작업을 외부에서 접근할 수 있어야 하거나 사용자의 세션이 종료된 뒤에도 계속 유지되어야 한다면 VPS를 사용하십시오. 클라이언트가 열어볼 수 있는 스테이징 URL, 웹훅 엔드포인트, 실제 시간을 기준으로 동작하는 cron job, 봇, 다른 서비스가 통신하는 소규모 데이터베이스, 금요일 오후에 시작해 두어야 하는 데이터 가져오기 작업 등이 이에 해당합니다.

두 번째 머신을 어떤 용도로 사용할지 아직 결정하지 못했다면, 사양 비교보다는 사람들이 실제로 VPS에서 운영하는 서비스 목록을 참고하는 것이 더 유용하며, VPS란 무엇인가에서 그 기반이 되는 가상화 기술을 설명합니다. 사용하는 도구가 Windows에서만 실행된다면 이는 별개의 결정 사항이며, Linux와 Windows Server 비교 페이지를 확인하십시오.

두 머신이 모두 절반만 설정된 상태가 되지 않게 하려면 한 가지 습관이 필요합니다. 코드는 git에 저장하고, 두 머신 모두 저장소의 클라이언트로 사용하십시오. 중요한 데이터는 어느 한쪽 머신에만 존재해서는 안 됩니다.

FAQ

WSL에서 실제 도메인으로 웹사이트를 호스팅할 수 있습니까?

안정적으로 운영할 수 없습니다. WSL 2는 컴퓨터 내부의 NAT 뒤에 위치하며, 공유기 또한 NAT를 사용하므로 대부분의 가정용 인터넷 환경에서는 외부에서 포트를 포워딩할 수 없습니다. 터널링 서비스를 사용하면 로컬 포트를 외부로 노출할 수 있지만, 터널 클라이언트가 노트북에서 실행되므로 노트북이 절전 모드로 들어가면 사이트도 함께 중단됩니다. Let's Encrypt의 HTTP-01 챌린지는 공개 도메인의 80번 포트로 파일을 가져와야 하므로 인증서 발급도 훨씬 어렵습니다. 공인 IP 주소를 가진 VPS를 사용하고 A 레코드를 설정하는 것이 별도의 우회 방법 없이 두 조건을 모두 충족하는 방법입니다.

WSL에서 systemctl enable이 작동합니까?

systemd가 활성화되어 있으면 작동합니다. 이를 위해서는 /etc/wsl.conf 파일의 [boot] 섹션 아래에 systemd=true를 설정한 뒤 wsl --shutdown를 실행해야 합니다. 그렇지 않으면 systemctl 명령은 System has not been booted with systemd as init system (PID 1). Can't operate.라는 응답을 보냅니다. systemd가 실행 중이라 하더라도, enable은 배포판이 시작될 때 서비스를 시작하며, 배포판은 셸을 열 때 시작됩니다. 서버 환경에서 동일한 명령은 사용자가 로그인하지 않아도 재부팅 후 서비스가 자동으로 다시 시작됨을 의미합니다.

WSL IP 주소가 계속 바뀌는 이유는 무엇입니까?

기본 NAT 모드에서는 가상 머신이 시작될 때마다 WSL 가상 어댑터로부터 새로운 사설 IP 주소를 할당받습니다. 따라서 wsl --shutdown 이후에는 기존의 netsh interface portproxy 규칙이나 하드코딩된 주소가 작동하지 않게 됩니다. 현재 주소는 ip -4 addr show eth0으로 확인할 수 있습니다. Windows 11의 미러링 네트워킹 모드를 사용하면 Windows와 동일한 인터페이스를 공유하므로 별도의 주소 문제가 해결됩니다. %UserProfile%\.wslconfig 파일의 [wsl2] 섹션 아래에 networkingMode=mirrored를 설정하십시오.

/mnt/c가 정말 느린 것입니까, 아니면 근거 없는 이야기입니까?

실제로 느리며, 직접 1분만 테스트해 봐도 알 수 있습니다. ~ 아래의 파일들은 ext4 가상 디스크에 저장됩니다. 반면 /mnt/c 아래의 파일들은 Windows 측 구성 요소가 9P 프로토콜을 통해 제공하므로, 모든 stat 호출이 경계를 넘나들어야 합니다. 대규모 트리에서 git status를 실행하면 수천 번의 호출이 발생합니다. 저장소를 ~으로 복사한 뒤 각 위치에서 time git status을 두 번 실행하여 캐시가 적용된 상태의 속도를 비교해 보십시오. 작업용 복사본은 ~ 아래에 두고 편집기의 WSL 원격 모드를 사용하는 것이 좋습니다.

VPS가 있는데도 WSL이 여전히 필요합니까?

대부분의 사용자는 둘 다 사용합니다. WSL은 무료이며 즉시 시작되므로 코드를 편집하고 테스트하는 용도로 적합하며, GPU 작업에도 유리합니다. 서버는 항상 켜져 있는 기기로서, 공개 도메인을 유지하고 노트북을 닫아도 계속 실행되어야 하는 작업들을 처리합니다. 코드를 git으로 관리하고 두 환경 모두 저장소의 클라이언트로 활용하면 작업 내용을 옮기는 데 드는 비용은 없습니다.