WireGuard, Tailscale, Headscale 차이와 VPS 선택

WireGuard와 Tailscale: 간단한 답변

WireGuard와 Tailscale의 비교는 두 프로토콜 중 하나를 선택하는 문제가 아닙니다. Tailscale 자체가 WireGuard이기 때문입니다. Tailscale은 동일한 암호화와 동일한 터널을 사용한 다음, 제어 플레인을 추가합니다. 제어 플레인은 공개 키를 교환하고, 주소를 할당하며, NAT(network address translation)를 통한 홀 펀칭을 수행하고, 액세스 정책을 적용하는 조정 서버입니다. 사용자가 직접 운영할 조정 기능의 범위를 선택하는 것입니다.

정확한 답변은 3가지입니다. 서버 1대와 해당 서버에 연결하는 소수의 클라이언트가 있다면 일반 WireGuard를 사용합니다. 유지 관리할 설정 파일 없이 모든 장치가 서로 연결되기를 원한다면 Tailscale을 사용합니다. 이러한 메시 네트워크를 원하지만 제3자가 노드 목록을 보유하는 것을 원하지 않는다면 Headscale을 사용합니다.

제어 플레인이 실제로 제공하는 기능

일반적인 WireGuard에는 검색 기능이 없습니다. 각 피어는 직접 작성하는 텍스트 블록입니다. 여기에는 공개 키, AllowedIPs 줄, 그리고 해당 피어에 연결할 수 있는 경우 Endpoint가 포함됩니다. 10대의 네트워크에 장비 1대를 추가하려면 10개의 설정 파일을 수정해야 합니다. 각 측에서 상대방의 키가 필요하기 때문입니다. 따라서 거의 모든 자체 호스팅 WireGuard 구성은 허브 앤 스포크 방식입니다. 공인 IP가 있는 서버 1대와 해당 서버에만 연결하는 클라이언트로 구성됩니다.

제어 플레인을 사용하면 이러한 편집 작업이 사라집니다. 각 노드는 한 번만 등록하고, 100.64.0.0/10 CGNAT (carrier grade NAT) 범위에서 주소를 받으며, 연결이 허용된 노드의 공개 키를 전달받습니다. 터널은 여전히 두 피어 사이의 직접적인 WireGuard 연결입니다. 트래픽은 조정 서버를 통과하지 않습니다. 서버가 전달하는 것은 메타데이터입니다. 어떤 노드가 존재하는지, 각 노드의 키가 무엇인지, 어떤 노드끼리 통신할 수 있는지를 관리합니다.

이 방식으로 얻는 구체적인 이점은 3가지입니다.

NAT 통과. 두 대의 노트북이 각각 가정용 라우터 뒤에 있으면 두 장비 사이에 공인 IP가 없습니다. Tailscale은 STUN (session traversal utilities for NAT)을 사용해 양쪽의 외부 주소와 포트를 확인합니다. 그런 다음 양쪽이 동시에 패킷을 전송합니다. 각 라우터는 먼저 나가는 흐름을 확인하고 응답을 허용합니다. 이 방식이 실패하면 트래픽은 Tailscale이 운영하는 암호화 릴레이인 DERP 릴레이로 전환됩니다. 릴레이에는 키가 없으므로 릴레이를 통과하는 동안에도 데이터는 종단 간 암호화 상태로 유지됩니다. tailscale status을 실행하면 각 피어 줄에 direct 또는 relay이 표시됩니다. tailscale netcheck을 실행하면 가장 가까운 릴레이와 네트워크에서 UDP를 전혀 허용하는지 확인할 수 있습니다.

만료 기능이 있는 키 순환. WireGuard 키는 만료되지 않습니다. 3년 전에 발급한 키도 피어 블록을 직접 삭제하지 않는 한 계속 작동합니다. 반면 Tailscale은 노드 키를 만료시킵니다. 2026년 7월 기준으로 새 tailnet의 기본 만료 기간은 180일입니다. 다시 인증하지 않은 장비는 연결을 중지합니다. 서버나 서브넷 라우터처럼 로그인할 사람이 없는 장비에서는 장치별로 만료 기능을 끌 수 있습니다.

라우팅 대신 정책 사용. 일반적인 WireGuard에서는 AllowedIPs가 라우팅 테이블과 액세스 제어 목록을 동시에 담당합니다. 따라서 "alice가 데이터베이스에 연결할 수 있다"는 규칙을 IP 범위로 표현해야 합니다. Tailscale은 사용자, 그룹 및 태그를 규칙에 지정할 수 있는 별도의 정책 파일을 사용합니다. 규칙에서 tag:laptop이 포트 5432의 tag:db에만 연결할 수 있고 다른 대상에는 연결할 수 없도록 지정할 수 있습니다. 장비에 새 주소가 할당되어도 이 규칙은 유지됩니다.

제어 플레인이 부과하는 비용

조정 서버는 네트워크 정보를 파악합니다. 모든 노드의 공개 키, 모든 노드 이름, 할당된 주소, 정책을 보관합니다. 호스팅된 Tailscale을 사용하면 이 서버는 사용자가 제어할 수 없는 외부 회사가 운영합니다. WireGuard 개인 키가 사용자의 시스템에 남아 있으므로 해당 회사가 패킷 내용을 읽을 수는 없습니다. 그러나 네트워크 구조는 해당 회사가 확인할 수 있습니다. 또한 연결하려면 해당 회사의 서비스가 실행 중이어야 하고 계정 상태가 양호해야 합니다.

놓치기 쉬운 두 번째 비용도 있습니다. Tailscale은 모든 시스템에서 데몬으로 실행됩니다. 따라서 모든 시스템에서 이 소프트웨어에 패치를 적용하고 최신 상태로 유지해야 합니다. Ubuntu 24.04의 일반 WireGuard는 배포판에 포함되어 함께 제공되는 커널 모듈이며, 커널과 함께 업데이트됩니다.

세 번째 비용은 요금입니다. 2026년 7월 기준으로 Personal 요금제는 최대 6명의 사용자에게 기기 수 제한 없이 무료입니다. Standard는 사용자당 월 $8이고, Premium은 사용자당 월 $18입니다. 한 가정은 계속 무료로 사용할 수 있습니다. 10명으로 구성된 팀은 무료가 아닙니다.

일반 WireGuard가 적합한 경우

네트워크 토폴로지가 실제로 허브 앤 스포크 구조일 때 일반 WireGuard를 선택합니다. 공인 IP를 사용하는 VPS 1대와 여기에 연결되는 장치 3~4대가 있고, 장치끼리 서로 연결할 필요가 없는 경우입니다. 설정은 한 화면에 들어갑니다. 업데이트할 데몬이 없고, 잃어버릴 계정도 없으며, 서버와 사용자 사이에 외부 서비스가 개입하지 않습니다.

또한 다른 모든 구성 요소의 기반이 되는 계층을 이해하려는 경우에도 적합합니다. VPS에서 WireGuard VPN 자체 호스팅하기에서는 키 생성, wg0.conf, IP forwarding, NAT 및 handshake 실패를 단계별로 설명합니다. 이러한 메커니즘은 tailnet 아래에서도 계속 실행됩니다. 이전 옵션을 아직 검토 중이라면 WireGuard와 OpenVPN 비교에서 OpenVPN이 여전히 우위를 유지하는 4가지 경우를 설명합니다.

설치는 짧습니다.

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

모든 장치가 다른 모든 장치에 연결되어야 하는 순간부터 일반 WireGuard는 관리하기 어려워집니다. N개 노드로 full mesh를 구성하려면 N 곱하기 N 빼기 1개의 peer 블록이 필요합니다. 장치가 6대이면 30개의 블록을 수동으로 동기화해야 합니다. AllowedIPs 항목이 중복되면 오류가 어디에도 출력되지 않은 채 해당 항목을 먼저 가진 peer의 트래픽을 조용히 가로챕니다.

Tailscale이 적합한 경우

머신의 위치가 바뀐다면 Tailscale을 선택합니다. 호텔 네트워크에 연결하는 노트북, 모바일 데이터를 사용하는 휴대폰, 직접 제어할 수 없는 라우터 뒤에 있는 홈 서버가 이에 해당합니다. 이러한 경우에는 양쪽 모두 Endpoint에 지정할 안정적인 공용 엔드포인트가 없으므로 일반 WireGuard가 제대로 작동하지 않습니다.

공식 설치 프로그램을 사용하면 다음 한 명령으로 클라이언트를 설치할 수 있습니다.

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

tailscale up은 URL을 출력합니다. 해당 URL을 열고 로그인하면 머신이 네트워크에 연결됩니다. 복사할 키가 없고 인바운드 포트를 열 필요도 없습니다. 데몬이 coordination server에 아웃바운드 연결을 설정하고 이를 유지하기 때문입니다. 따라서 방화벽을 전혀 제어할 수 없는 네트워크에서도 Tailscale 노드가 작동합니다.

이후에는 두 가지 설정으로 대부분의 유용한 기능을 사용할 수 있습니다. subnet router는 전체 LAN을 네트워크에 알리므로 모든 디바이스에 클라이언트를 설치할 필요가 없습니다.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

관리 콘솔에서 승인하기 전까지는 해당 경로가 비활성 상태로 유지됩니다. 이는 의도된 동작입니다. 노드가 자체적으로 네트워크에 경로를 주입할 수 없기 때문입니다. Linux 클라이언트에는 sudo tailscale set --accept-routes도 필요합니다. Linux는 기본적으로 advertised route를 수락하지 않으므로, 서버 측에서 승인된 것으로 표시되는 경로도 이를 설정하기 전까지는 Linux 노트북에서 아무 동작도 하지 않습니다.

exit node는 클라이언트의 모든 트래픽을 하나의 머신을 통해 전송합니다. 이는 일반적으로 "VPN"이라고 할 때 의미하는 full tunnel 동작입니다.

sudo tailscale set --advertise-exit-node

Headscale이 적합한 경우

Headscale은 coordination server의 오픈 소스 구현이며, 사용자가 소유한 VPS에서 실행됩니다. 공식 Tailscale 클라이언트는 호스팅 서비스 대신 이 서버를 사용하도록 지정할 수 있습니다.

sudo tailscale up --login-server https://headscale.example.com

데이터 경로와 관련된 사항은 모두 동일합니다. 여전히 WireGuard를 사용하며, 네트워크에서 허용하는 경우 피어 간에 직접 연결됩니다. 달라지는 점은 노드 목록, 키 및 정책이 사용자가 소유한 디스크의 SQLite 파일에 저장된다는 것입니다. 외부에서는 사용자의 네트워크 구성을 확인하거나, 계정을 비활성화하거나, 사용자별로 요금을 청구할 수 없습니다.

대신 실제 운영 작업이 필요합니다. 이제 공개 HTTPS 서비스를 운영해야 하므로 DNS 이름, 인증서 및 WebSocket 업그레이드를 올바르게 전달하는 reverse proxy가 필요합니다. 서비스 가동 시간도 직접 관리해야 합니다. coordination server가 중단되면 새 노드를 등록할 수 없고, 기존 노드가 변경 사항을 가져올 수도 없습니다. 또한 Headscale은 아직 version 1.0 미만이며, minor release에 호환성을 깨는 변경 사항이 포함된 적이 있습니다. 따라서 업그레이드하기 전에 항상 changelog를 확인해야 합니다. 자체 Tailscale control server로 Headscale 실행에서는 설치, config.yaml, preauth key 및 열어야 할 port를 설명합니다.

한 가지 주의할 점은 나중에 문제로 드러나는 경우가 많습니다. Headscale에는 Tailscale의 global relay network가 포함되어 있지 않습니다. 두 피어가 직접 연결할 수 없는 경우 자체 서버에서 내장 relay를 활성화하거나 다른 relay를 사용하도록 설정해야 합니다. 이 relay는 전 세계에 분산된 fleet이 아니라 단일 region의 단일 서버입니다. 지구 반대편에 있는 피어는 이 차이를 체감할 수 있습니다.

한 번에 결정하는 방법

서로 통신해야 하는 머신이 몇 대인지 확인합니다. 모든 머신이 서버와만 통신하면 된다면, 일반 WireGuard가 같은 결과를 더 적은 소프트웨어로 제공합니다.

머신에 안정적인 공용 주소가 있는지 확인합니다. 대부분의 머신이 직접 제어할 수 없는 NAT 뒤에 있다면 control plane이 필요합니다. 홀 펀칭이 어려운 부분이며, 이를 직접 다시 구현할 필요는 없습니다.

누가 네트워크 구성을 알 수 있어야 하는지 확인합니다. 외부 회사가 알 수 없어야 하거나 사용자 수 때문에 사용자별 과금이 부담스럽다면 Headscale을 실행합니다. 대신 이제 control server를 직접 운영해야 합니다.

결정을 나중에 바꾸는 비용은 낮습니다. 세 가지 방식 모두 data plane에 동일한 프로토콜을 사용하기 때문입니다. 일반 WireGuard에서 조정된 mesh로 전환할 때는 설계를 다시 하는 대신 client를 설치하면 됩니다. Tailscale에서 Headscale로 전환할 때는 각 node를 다른 login server에 다시 등록하면 됩니다.

세 가지 모두 제공하지 않는 것

세 가지 모두 방화벽은 아닙니다. 터널은 어떤 패킷을 전달할지 결정하지만, 어떤 서비스가 수신 대기할지는 결정하지 않습니다. 터널을 통해 접근할 수 있는 서버는 열어 둔 모든 포트에서 인터넷을 통해 여전히 접근할 수 있습니다. 따라서 VPS의 UFW 방화벽 규칙이 계속 작동하도록 유지해야 합니다. Tailscale의 정책 파일은 다른 노드가 접근할 수 있는 대상을 제한하지만, 공용 인터페이스에는 아무런 영향을 주지 않습니다.

세 가지 모두 서비스별 인증을 제공하지 않습니다. 연결한 후 사용자가 수행한 작업을 기록하는 감사 추적도 제공하지 않습니다. 세 가지를 모두 전송 수단으로 간주하고, 로그인 검사는 애플리케이션에서 처리해야 합니다.

FAQ

Tailscale은 추가 단계가 있는 WireGuard에 불과합니까?

Tailscale은 데이터 경로에 WireGuard 프로토콜을 사용하므로 암호화와 터널은 동일합니다. Tailscale이 추가하는 기능은 조정입니다. 여기에는 키 교환, 주소 할당, STUN 및 DERP 릴레이를 사용한 NAT 통과, 키 만료, IP 범위 대신 사용자를 지정하는 정책 파일이 포함됩니다. 일반 WireGuard에서는 이러한 작업을 직접 처리해야 합니다. 시스템이 서로 다른 네트워크로 이동하기 시작하면 이러한 작업이 복잡해집니다.

트래픽이 Tailscale 서버를 거칩니까?

일반적으로 그렇지 않습니다. 조정 서버가 피어를 서로 알린 후에는 피어가 직접 연결되며, tailscale status은 해당 피어 행에서 direct을 표시합니다. 직접 경로를 설정할 수 없으면 트래픽은 DERP 릴레이로 전환되고 행에는 relay이 표시됩니다. 이 경우에도 릴레이는 암호화된 패킷만 전달하며 WireGuard 개인 키를 보유하지 않습니다. 따라서 릴레이는 콘텐츠를 읽을 수 없습니다. tailscale netcheck를 실행하면 네트워크가 직접 연결에 필요한 UDP를 차단하는지 확인할 수 있습니다.

공식 Tailscale 앱에서 Headscale을 사용할 수 있습니까?

그렇습니다. Headscale은 동일한 제어 프로토콜을 사용하므로 공식 클라이언트가 sudo tailscale up --login-server https://headscale.example.com로 연결됩니다. 데스크톱 및 모바일 앱에서도 사용자 지정 로그인 서버를 지정할 수 있습니다. 다만 플랫폼마다 설정 위치가 다르고, 특정 버전이 필요할 가능성이 가장 높은 것은 모바일 앱입니다. 전체 네트워크를 마이그레이션하기 전에 휴대폰 1대에서 테스트하십시오.

Tailscale 또는 Headscale을 사용하려면 포트를 계속 열어야 합니까?

Tailscale 클라이언트는 조정 서버로 외부 연결을 시작하고 연결을 유지하므로 인바운드 포트가 필요하지 않습니다. 자체 호스팅 Headscale 서버에는 인바운드 포트가 필요합니다. 제어 프로토콜에는 443, HTTP-01 인증서 챌린지를 사용하는 경우에는 80, 내장 릴레이를 활성화한 경우에만 3478/udp가 필요합니다. 일반 WireGuard는 서버와 공급자가 운영하는 별도의 네트워크 방화벽에서 UDP 수신 포트(일반적으로 51820)를 열어야 합니다.

세 가지 중 어느 것이 가장 빠릅니까?

세 가지 모두 WireGuard로 패킷을 전송하므로 처리량은 동일합니다. 차이는 연결 설정과 경로 품질에서 나타납니다. 올바른 Endpoint이 설정된 일반 WireGuard는 항상 직접 연결됩니다. Tailscale과 Headscale은 대부분 직접 연결되지만 네트워크가 홀 펀칭을 차단하면 릴레이로 전환되며, 릴레이 경로에서는 지연 시간이 증가합니다. tailscale ping <node>로 직접 경로인지 릴레이 경로인지 확인하거나, 터널을 통해 iperf3을 실행하여 실제 경로를 측정하십시오.