원격 분석 서버 구축기 (WSL2, Tailscale, Docker)

msgo·2026년 3월 15일

친구와 프로젝트를 진행하기로 했고, 초기 개발에는 보유한 로컬 PC(GPU)를 활용하기로 결정했습니다.

맥북을 메인 개발 기기로 사용하면서, 집에 있는 윈도우 PC(GPU 탑재)를 딥러닝 및 데이터 분석용 원격 서버로 활용하기 위한 환경 구축기입니다.

처음 구축 시 여러 시행착오를 겪으며 대략 4시간이 소요되었으나, 이 글의 순서대로 진행한다면 시간을 크게 단축할 수 있을 것입니다. 추후 재구축을 위한 기록이자, 비슷한 환경을 구성하려는 분들을 위한 참고용으로 작성했습니다.

목표 아키텍처

단순히 윈도우에 원격 접속하는 것을 넘어, 협업자를 고려하여 윈도우 개인 파일과 완벽히 격리된 독립적인 Ubuntu 서버를 구축하는 것이 핵심입니다.

네트워크: Tailscale을 이용한 외부 원격 접속

OS: Windows 11 + WSL2 (Ubuntu)

격리: 우분투 내부에 독립적인 Tailscale 및 SSH 서버 구축 (윈도우 파일 접근 차단)

인프라: 순정 Docker Engine + NVIDIA Container Toolkit + 디스크 용량 확장

1단계: 기본 네트워크 및 WSL2 환경 준비

1. Tailscale 기반 네트워크 구성
개인 홈 네트워크 환경에서 복잡한 공유기 포트포워딩 설정 없이, 안전하고 고정된 IP로 외부 접속을 하기 위해 가상 VPN 서비스인 Tailscale을 사용합니다. 윈도우 PC(서버)와 맥북(클라이언트) 양쪽에 Tailscale을 설치하고 동일한 계정으로 로그인하여 서로를 하나의 사설망으로 묶어줍니다. 추후, 해당 네트워크 스페이스에 협업자를 초대하여 사설망으로 묶을 수 있을 것을 기대한다.

간단한 방식이었으나 실제 가장 큰 병목이 발생함.

[Troubleshooting: 맥북 Tailscale 연결 지연 및 통신 실패]

증상: 윈도우 PC에서는 Tailscale이 즉시 연결되고 고정 IP가 할당되었으나, 맥북에서는 Tailscale 네트워크가 제대로 잡히지 않거나 윈도우 PC로의 ping 테스트 및 SSH 접속이 먹통이 되는 현상이 발생했습니다.

원인 분석: 당시 맥북 백그라운드에 FortiClient(기업용 VPN/방화벽)와 TeamViewer(원격 제어 프로그램)가 켜져 있었습니다.

가장 큰 원인은 FortiClient입니다. 기업용 VPN은 보안을 위해 PC의 전체 네트워크 트래픽 경로(라우팅 테이블)를 강제로 통제하고 암호화 터널을 만듭니다. Tailscale 역시 가상의 네트워크 인터페이스를 생성하여 통신하는 구조이기 때문에, 두 개의 VPN 프로그램이 서로 네트워크 주도권을 쥐려고 충돌(Routing Conflict)을 일으킨 것입니다.

TeamViewer 역시 지속해서 백그라운드 네트워크 패킷을 주고받으며 포트를 점유하므로, 통신 간섭의 원인이 될 수 있습니다.

ps aux | grep -i tailscale

위 명령어 실행 결과
/Applications/Tailscale.app/Contents/MacOS/Tailscale      ← GUI 실행됨
io.tailscale.ipn.macsys.network-extension.systemextension ← Network Extension 실행됨

에러 핵심:

failed to connect to local Tailscale service

이건 macOS에서 System Extension은 떠 있지만 control service가 시작되지 않는 버그일 때 나타납니다.
GUI ✔ 실행
NetworkExt ✔ 실행
Daemon socket ✖ 없음

sudo launchctl bootout system /Library/LaunchDaemons/com.tailscale.tailscaled.plist
sudo rm -rf /Library/Tailscale
sudo rm -rf ~/Library/Containers/io.tailscale.ipn.macos

이후 재부팅 및 재설치 -> 해결

2. WSL2 (Ubuntu) 설치
윈도우 환경에 리눅스 서브시스템을 설치합니다.
관리자 권한으로 PowerShell을 실행하고 아래 명령어를 입력한 뒤 재부팅합니다.

**PowerShell**
wsl --install

2단계: 협업자를 위한 완벽한 독립 서버(Ubuntu) 구성

가장 중요한 단계입니다. 윈도우를 거쳐 접속하면 윈도우의 개인 파일(C드라이브)이 노출되는 문제가 있습니다. 이를 방지하고 우분투를 완전히 독립된 서버로 만들기 위해 C드라이브 마운트를 해제하고 우분투 내부에 별도의 네트워크 통로를 뚫습니다.

1. 윈도우 C드라이브 자동 마운트 해제
우분투 터미널에 접속하여 wsl.conf 파일을 수정합니다

sudo nano /etc/wsl.conf

아래 내용을 추가하여 systemd를 활성화하고 윈도우 드라이브 연결을 끊습니다.


[boot]
systemd=true

[automount]
enabled=false

수정 후 윈도우 PowerShell에서 wsl --shutdown을 입력해 재시작합니다.

2. 우분투 내부 OpenSSH 및 Tailscale 설치
우분투 자체가 독립적인 IP를 갖도록 내부에 Tailscale을 설치합니다.

sudo apt update
sudo apt install openssh-server -y
sudo systemctl enable --now ssh

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

인증을 마치면 우분투 전용 IP(100.x.x.x)가 새로 발급됩니다. 이제 협업자는 윈도우를 거치지 않고 이 IP를 통해 우분투 홈 디렉토리로 다이렉트 접속하게 됩니다.

3. 협업자 전용 리눅스 계정(User) 생성
윈도우 본 계정의 권한을 협업자에게 직접 공유하는 것은 보안상 위험합니다. 따라서 우분투 내부에 협업자가 사용할 전용 계정을 별도로 생성하여 환경을 격리합니다.

sudo adduser 협업자계정명

비밀번호 및 기본 정보를 입력하여 계정 생성을 완료합니다.
이제 협업자는 맥북 터미널에서 ssh 협업자계정명@우분투TailscaleIP 형식으로 접속하게 되며, 윈도우 C드라이브를 거치지 않고 본인의 리눅스 홈 디렉토리(/home/협업자계정명)로 직행하여 안전하게 작업할 수 있습니다.

[Troubleshooting: 최고 관리자 계정의 타 사용자 디렉토리 접근 불가]

증상: 서버를 세팅하던 메인 관리자 계정으로 접속한 상태에서, 방금 생성한 협업자의 홈 디렉토리(cd /home/협업자계정명)로 이동하려 하면 Permission denied 에러가 발생합니다.

원인: 리눅스의 철저한 권한 분리 원칙 때문입니다. sudo 그룹에 속한 관리자라 하더라도, 평소의 일반 사용자 상태에서는 시스템 보호를 위해 타인의 홈 디렉토리에 함부로 접근할 수 없도록 차단됩니다.

해결책: 해당 디렉토리에 접근하여 파일 권한 등을 추가로 세팅해 주려면, 터미널에 sudo su 명령어를 입력하여 일시적으로 완벽한 Root(최고 관리자) 모드로 변신한 뒤 이동해야 합니다. 정상적으로 세팅이 끝났다면 협업자는 반드시 본인의 계정으로 접속하여 작업을 진행하도록 안내합니다.

3단계: SSH Key 로그인 및 에디터 연결

맥북의 Cursor나 VS Code를 통해 원격 서버에 접속할 때, 비밀번호 입력 팝업이 누락되어 타임아웃이 발생하는 버그가 잦습니다. 이를 원천 차단하기 위해 SSH Key 기반 로그인을 세팅합니다.

1. 맥북에서 SSH Key 생성
맥북 터미널에서 아래 명령어를 치고 엔터를 3번 칩니다.

ssh-keygen -t ed25519
cat ~/.ssh/id_ed25519.pub

출력된 공개키 텍스트를 복사합니다.

2. 우분투에 공개키 등록
우분투 서버로 접속하여 복사한 키를 등록합니다.

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys

복사한 텍스트를 붙여넣고 저장합니다. 이제 비밀번호 없이 에디터에서 즉시 접속이 가능합니다.

4단계: GPU 인식 및 Docker 환경 세팅

1. 다이렉트 접속 시 GPU 인식 오류 해결
[Troubleshooting]
윈도우를 거치지 않고 우분투 IP로 직접 접속한 사용자(협업자 등)가 nvidia-smi를 치면 명령어를 찾을 수 없다는 오류가 발생합니다. 이는 윈도우가 넘겨주던 GPU 경로 환경변수(PATH)를 받지 못했기 때문입니다.

[해결책]
해당 사용자의 쉘 설정 파일에 GPU 라이브러리 경로를 직접 추가합니다.

echo 'export PATH=$PATH:/usr/lib/wsl/lib' >> ~/.zshrc
echo 'export PATH=$PATH:/usr/lib/wsl/lib' >> ~/.bashrc
source ~/.zshrc

[Troubleshooting]
도커 그룹에 사용자를 추가한 직후 docker ps를 치면 permission denied 에러가 발생합니다. 리눅스 세션 새로고침 문제이므로 터미널을 나갔다가 다시 SSH로 재접속하거나, newgrp docker 명령어를 입력하면 해결됩니다.

이후 도커 컨테이너에서 GPU를 사용하기 위해 NVIDIA Container Toolkit을 설치합니다.

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
  && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

GPU 도커 연동 테스트:

docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu22.04 nvidia-smi

5단계: WSL2 우분투 가상 디스크 용량 확장

[Troubleshooting]
윈도우 C드라이브 용량이 수백 기가바이트가 남아있어도, WSL2 우분투 내에서 df -h를 쳐보면 디스크가 꽉 차가는 경우가 많습니다. 이는 마이크로소프트가 우분투 가상 디스크(ext4.vhdx)의 최대 크기를 256GB로 제한해 두었기 때문입니다. 무거운 딥러닝 도커 이미지를 다루기 위해 이를 512GB로 확장해야 합니다.

[해결책]

윈도우 PowerShell(관리자)에서 우분투 종료 및 vhdx 파일 경로 찾기

wsl --shutdown
Get-ChildItem -Path "C:\Users\본인계정명\AppData\Local\Packages" -Filter "ext4.vhdx" -Recurse -ErrorAction SilentlyContinue | Select-Object FullName

출력된 전체 경로를 복사해 둡니다.

윈도우 diskpart로 가상 디스크 상한선 확장 (512GB)

diskpart
Select vdisk file="복사한_vhdx_전체경로"
expand vdisk maximum=524288
exit

3.우분투에 접속하여 내부 파티션 넓히기

sudo resize2fs /dev/sdc

다시 df -h를 입력하면 전체 용량이 500GB 이상으로 성공적으로 늘어난 것을 확인할 수 있습니다.

마무리

이로써 맥북의 편리한 개발 경험과 윈도우 PC의 강력한 GPU 성능, 그리고 협업자를 위한 완벽히 독립된 안전한 도커 환경까지 모두 갖춘 분석 서버 구축이 완료되었습니다.

개발/AI 공부를 하기 위해 3090을 구매해놨으나 귀찮아서...window pc를 직접 쓰기가 싫어서 활용을 잘하지 못했었는데 이번 서버 구축 계기로 협업 뿐만 아니라 여러 활용을 쉽게 할 수 있을 것 같다.

대부분의 서버 구축은 Gemini Pro와 함께 진행했으며 해당 블로그 글도 Gemini Pro가 대부분 작성을 진행했다. 서버 구축의 가장 큰 병목은 Tailscale로 네트워크를 연결하는데 가장 오래걸림. 해당 병목이 없었더라면 2시간 이내로 구축을 다 했을 것으로 생각된다. Geimin Pro와 진행하면서 병목이 생기면(잘 해결이 되지 않으면) 세션이 엉뚱한 길로 빠지지 않게 하기 위해 새로운 세션을 열거나 ChatGPT를 활용함.

해당 서버 구축 프로세스가 나중에 필요할 경우 다시 보면서 생각해보고 보안 또한 적절한지 고려해볼 필요는 있음.

전달까지 완료!

msgo

이전 포스트