WireGuard vs Tailscale vs Headscale 비교 및 선택 가이드

WireGuard와 Tailscale: 요약

WireGuard와 Tailscale은 두 프로토콜 사이의 선택 문제가 아닙니다. Tailscale은 곧 WireGuard이기 때문입니다. Tailscale은 동일한 암호화 방식과 터널을 사용하며, 여기에 제어 평면(control plane)을 추가합니다. 이 제어 평면은 공개 키를 교환하고, 주소를 할당하며, NAT(network address translation)를 통과하고, 접근 정책을 적용하는 조정 서버 역할을 합니다. 즉, 사용자는 이러한 조정 기능을 얼마나 직접 운영할 것인지 선택하는 것입니다.

이에 대한 명확한 답변은 세 가지입니다. 서버 한 대와 소수의 클라이언트가 접속하는 환경이라면 일반 WireGuard를 사용하십시오. 설정 파일을 관리할 필요 없이 모든 기기가 서로 통신해야 한다면 Tailscale을 사용하십시오. 메시 네트워크는 필요하지만 제3자가 노드 목록을 보유하는 것을 원치 않는다면 Headscale을 사용하십시오.

컨트롤 플레인이 제공하는 실제 이점

순수 WireGuard에는 탐색 기능이 없습니다. 모든 피어는 공개 키, AllowedIPs 행, 그리고 해당 피어에 도달할 수 있는 경우의 Endpoint 등 사용자가 직접 작성해야 하는 텍스트 블록입니다. 10대의 기기로 구성된 네트워크에 기기 하나를 추가하려면 10개의 설정 파일을 모두 수정해야 합니다. 양쪽 모두 상대방의 키가 필요하기 때문입니다. 이것이 거의 모든 자가 호스팅 WireGuard 설정이 허브 앤 스포크(hub and spoke) 방식을 취하는 이유입니다. 즉, 공인 IP를 가진 서버 하나와 그 서버하고만 통신하는 클라이언트들로 구성됩니다.

컨트롤 플레인은 이러한 편집 과정을 제거합니다. 각 노드는 한 번만 등록하면 100.64.0.0/10 CGNAT(carrier grade NAT) 대역에서 주소를 할당받고, 통신이 허용된 노드들의 공개 키를 전달받습니다. 터널링은 여전히 두 피어 간의 직접적인 WireGuard 연결로 유지되며, 트래픽은 조정 서버를 거치지 않습니다. 서버가 처리하는 것은 누가 존재하는지, 각자의 키는 무엇인지, 누가 누구와 통신할 수 있는지에 대한 메타데이터뿐입니다.

이로 인해 세 가지 구체적인 이점이 발생합니다.

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

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

라우팅 대신 정책 사용. 순수한 WireGuard에서는 AllowedIPs가 라우팅 테이블이자 동시에 접근 제어 목록(ACL) 역할을 합니다. 따라서 "alice가 데이터베이스에 접근할 수 있다"는 규칙을 IP 대역으로 표현해야 합니다. Tailscale은 사용자, 그룹, 태그를 이름으로 지정하는 별도의 정책 파일을 유지합니다. 예를 들어 tag:laptop이 tag:db의 5432 포트에만 접근할 수 있고 다른 곳은 접근할 수 없다는 규칙을 설정할 수 있으며, 이 규칙은 기기가 새로운 주소를 할당받더라도 그대로 유지됩니다.

컨트롤 플레인이 요구하는 비용

코디네이션 서버는 사용자의 네트워크를 파악하고 있습니다. 이 서버는 모든 노드의 공개 키, 노드 이름, 할당된 주소, 그리고 정책을 보유합니다. Tailscale 호스팅 서비스를 이용하면 사용자가 통제할 수 없는 외부 기업이 이 정보를 관리하게 됩니다. WireGuard 개인 키는 사용자의 머신에만 저장되므로 패킷 내용을 그들이 읽을 수는 없지만, 네트워크의 구성 형태는 그들이 볼 수 있습니다. 또한 연결 가능 여부는 해당 서비스의 가동 상태와 계정의 정상 유지 여부에 달려 있습니다. 이 점을 얼마나 중요하게 고려할지는 코디네이션 서버가 침해당하거나 계정 정보가 탈취되었을 때 발생할 수 있는 실제 위험 수준에 따라 달라지며, Tailscale의 신뢰 모델 전문을 읽어보는 것이 좋습니다.

간과하기 쉬운 두 번째 비용이 있습니다. Tailscale은 모든 머신에서 데몬으로 실행되므로, 이제 모든 머신에서 소프트웨어 패치를 직접 관리해야 합니다. 반면 Ubuntu 24.04의 기본 WireGuard는 배포판에 포함된 커널 모듈이며 커널 업데이트와 함께 자동으로 갱신됩니다.

세 번째 비용은 요금입니다. 2026년 7월 기준으로 Personal 플랜은 최대 6명의 사용자까지 기기 제한 없이 무료로 제공되며, Standard는 사용자당 월 8달러, Premium은 사용자당 월 18달러입니다. 가구 단위 사용은 무료로 유지되지만, 10명 규모의 팀은 그렇지 않습니다. 무료 범위를 넘어서는지는 기기 수가 아닌 사용자 수(seat)에 따라 결정되므로, 7번째 사용자를 초대하기 전에 무료 플랜의 실제 적용 범위를 확인하는 것이 좋습니다.

순수 WireGuard가 적합한 경우

토폴로지가 진정한 허브 앤 스포크(hub and spoke) 형태라면 순수 WireGuard를 선택하십시오. 공인 IP를 가진 VPS 한 대에 3~4대의 장치가 연결되고, 장치 간 직접 통신이 필요 없는 경우입니다. 설정은 한 화면에 들어올 정도로 간결하며, 업데이트해야 할 데몬이나 분실할 계정이 없고, 서버와 사용자 사이에 외부 서비스가 개입하지 않습니다.

다른 모든 기술이 구축되는 기반 계층을 이해하고 싶을 때도 순수 WireGuard가 정답입니다. VPS에서 WireGuard VPN 직접 호스팅하기에서는 키 생성, wg0.conf, IP 포워딩, NAT, 핸드셰이크 실패 문제를 다루며, 이러한 모든 메커니즘은 tailnet 하위에서도 동일하게 작동합니다. 여전히 구형 옵션을 고려 중이라면 WireGuard와 OpenVPN 비교를 통해 OpenVPN이 여전히 강점을 가지는 네 가지 사례를 확인하십시오.

설치 과정은 간단합니다.

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

순수 WireGuard가 불편해지는 시점은 모든 장치가 서로 통신해야 하는 경우입니다. N개의 노드로 구성된 풀 메시(full mesh) 네트워크는 N 곱하기 (N-1)개의 피어 블록이 필요합니다. 장치가 6대라면 30개의 블록을 수동으로 동기화해야 하며, 중복된 AllowedIPs 항목이 발생하면 아무런 오류 메시지 없이 먼저 등록된 피어의 트래픽을 가로채게 됩니다.

Tailscale이 적합한 경우

기기가 이동하는 환경이라면 Tailscale을 선택하십시오. 호텔 네트워크를 사용하는 노트북, 모바일 데이터를 사용하는 휴대폰, 제어할 수 없는 라우터 뒤에 있는 홈 서버가 이에 해당합니다. 이러한 환경에서는 일반적인 WireGuard가 제대로 작동하지 않습니다. 양쪽 모두 Endpoint에 입력할 수 있는 안정적인 공인 엔드포인트가 없기 때문입니다.

공식 설치 프로그램을 통해 한 줄의 명령어로 클라이언트를 설치할 수 있습니다.

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

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

설치 후에는 두 가지 설정이 대부분의 유용한 작업을 수행합니다. 서브넷 라우터는 전체 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는 기본적으로 광고된 경로를 수락하지 않기 때문입니다. 따라서 서버 측에서 승인된 경로라도 이 설정을 적용하지 않으면 Linux 노트북에서는 아무런 동작도 하지 않습니다. 이러한 구성이 필요하다면 VPS에서 서브넷 라우터 실행하기를 참조하여 승인 단계와 포워딩 설정을 순서대로 진행해 경로가 불완전하게 작동하는 상황을 방지하십시오.

출구 노드(exit node)는 클라이언트의 모든 트래픽을 특정 기기를 통해 전송합니다. 이는 흔히 "VPN"이라고 부르는 전체 터널링 방식입니다.

sudo tailscale set --advertise-exit-node

해당 플래그를 설정하는 것은 간단합니다. VPS를 출구 노드로 전환하기에서는 그 이후의 과정, 즉 관리 콘솔에서 경로를 승인하고 트래픽이 잘못된 경로로 나가는 것을 방지하기 위해 DNS 및 IPv6 동작을 수정하는 방법을 다룹니다. 전체 네트워크가 아니라 특정 웹 서비스에만 접근하려는 경우, serve 및 funnel을 사용하여 단일 로컬 포트 앞에 HTTPS를 적용할 수 있습니다. 이는 tailnet 내부 전용으로 설정하거나 공용 인터넷에 공개할 수 있습니다.

Headscale이 적합한 경우

Headscale은 코디네이션 서버의 오픈 소스 구현체이며, 사용자가 소유한 VPS에서 실행됩니다. 공식 Tailscale 클라이언트는 호스팅 서비스 대신 이 서버를 가리키도록 설정합니다.

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

데이터 경로와 관련된 모든 사항은 변경되지 않습니다. 여전히 WireGuard를 사용하며, 네트워크가 허용하는 경우 피어 간 직접 통신이 이루어집니다. 변경되는 점은 노드 목록, 키, 정책이 사용자가 소유한 디스크의 SQLite 파일에 저장된다는 것입니다. 외부의 누구도 사용자의 네트워크 구성을 볼 수 없으며, 계정을 비활성화하거나 사용자별로 요금을 청구할 수 없습니다.

그 대가로 실제 운영 작업이 필요합니다. 이제 공개 HTTPS 서비스를 직접 운영해야 하므로 DNS 이름, 인증서, 그리고 WebSocket 업그레이드를 올바르게 전달하는 리버스 프록시가 필요합니다. 서버의 가동 시간은 사용자가 책임져야 하며, 코디네이션 서버가 중단되면 새로운 노드를 등록할 수 없고 기존 노드는 변경 사항을 업데이트할 수 없습니다. Headscale은 아직 버전 1.0 미만이며 마이너 릴리스에서 호환성을 깨뜨리는 변경 사항이 포함될 수 있으므로, 업그레이드 전마다 변경 로그를 확인하십시오. Headscale을 직접 Tailscale 제어 서버로 운영하기에서는 설치, config.yaml, 사전 인증 키 및 개방해야 할 포트를 다룹니다.

사용자들이 뒤늦게 깨닫는 주의 사항이 하나 있습니다. Headscale에는 Tailscale의 글로벌 릴레이 네트워크가 포함되어 있지 않습니다. 두 피어가 직접 연결할 수 없는 경우, 자체 서버에서 내장 릴레이를 활성화하거나 다른 서버의 설정을 가리키도록 해야 합니다. 이 릴레이는 전 세계적인 인프라가 아닌 단일 지역의 단일 서버로 작동합니다. 지구 반대편에 있는 피어들은 이 차이를 체감하게 됩니다. 이러한 구성 요소를 직접 조립하고 싶지 않다면, NetBird 자체 호스팅이 제어 평면을 내부적으로 유지하는 또 다른 방법입니다. NetBird의 퀵스타트는 관리, 신호, 릴레이 서비스를 하나의 VPS에서 함께 실행하기 때문입니다.

한 번에 결정하는 방법

각 장비가 서로 통신해야 하는지 확인합니다. 모든 장비가 서버와만 통신하면 된다면, WireGuard를 직접 사용하는 것이 소프트웨어 복잡도를 줄이면서 동일한 결과를 얻는 방법입니다.

장비들이 고정된 공인 IP 주소를 가지고 있는지 확인합니다. 대부분의 장비가 제어할 수 없는 NAT 뒤에 있다면 제어 평면(control plane)이 필요합니다. NAT 홀 펀칭(hole punching)은 구현하기 까다로우며 직접 다시 만들 가치가 없기 때문입니다.

누가 네트워크 구조를 알 수 있어야 하는지 확인합니다. 외부 업체가 포함되지 않아야 하거나 사용자 수에 따른 종량제 비용이 부담된다면, Headscale을 직접 운영하는 방안을 고려하십시오. 비용 문제로 전환을 고민 중이라면, 팀 규모에 따른 실제 지불 비용을 먼저 계산해 보아야 합니다. 비용은 운영하는 장비 수가 아니라 계정을 가진 사용자 수에 따라 결정되며, 이 두 수치는 일치하는 경우가 드뭅니다.

결정은 언제든 저렴한 비용으로 번복할 수 있습니다. 세 방식 모두 데이터 평면에서 동일한 프로토콜을 사용하므로, 일반 WireGuard에서 조정된 메시(coordinated mesh) 네트워크로 전환하는 것은 설계를 다시 하는 것이 아니라 클라이언트를 설치하는 수준의 작업입니다. Tailscale에서 Headscale로 이동하는 것 역시 각 노드를 다른 로그인 서버에 다시 등록하는 것만으로 충분합니다.

세 가지 도구가 제공하지 않는 기능

이들 중 어느 것도 방화벽이 아닙니다. 터널은 어떤 패킷을 전송할지만 결정할 뿐, 어떤 서비스가 포트를 열고 대기할지는 결정하지 않습니다. 터널을 통해 접근 가능한 서버라도 외부 인터넷에서 열려 있는 포트를 통해 여전히 접근할 수 있으므로, VPS의 UFW 방화벽 규칙이 제 역할을 하도록 유지해야 합니다. Tailscale의 정책 파일은 다른 노드가 접근할 수 있는 범위를 제한할 뿐, 공용 인터페이스에는 아무런 영향을 주지 않습니다.

이들 중 어느 것도 서비스별 인증 기능을 제공하지 않으며, 사용자가 연결된 후 수행한 작업에 대한 감사 기록(audit trail)도 남기지 않습니다. 세 가지 도구 모두 전송 계층으로만 취급하고, 로그인 확인 절차는 애플리케이션 내부에서 처리해야 합니다.

FAQ

Tailscale은 단순히 WireGuard에 복잡한 단계를 추가한 것인가요?

Tailscale은 데이터 경로에 WireGuard 프로토콜을 사용하므로 암호화 방식과 터널링 원리는 동일합니다. Tailscale은 여기에 키 교환, 주소 할당, STUN 및 DERP 릴레이를 이용한 NAT 통과, 키 만료, IP 대역 대신 사용자를 식별하는 정책 파일 관리와 같은 조정 기능을 추가합니다. 이러한 부분은 일반 WireGuard에서 사용자가 직접 해결해야 하는 영역이며, 장비가 네트워크를 이동할 때마다 관리하기가 매우 까다롭습니다.

제 트래픽이 Tailscale 서버를 거쳐 가나요?

일반적으로 그렇지 않습니다. 조정 서버가 피어 간의 연결을 중재하고 나면 피어들은 서로 직접 연결되며, tailscale status 명령을 실행하면 해당 피어 라인에 direct가 표시됩니다. 직접 경로를 설정할 수 없는 경우 트래픽은 DERP 릴레이를 경유하게 되며, 이때는 relay으로 표시됩니다. 릴레이를 거치더라도 암호화된 패킷만 전달하며 WireGuard 개인 키를 보유하지 않으므로 내용을 읽을 수 없습니다. 직접 연결에 필요한 UDP 통신이 네트워크에서 차단되고 있는지 확인하려면 tailscale netcheck를 실행하십시오.

공식 Tailscale 앱에서 Headscale을 사용할 수 있나요?

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

Tailscale이나 Headscale을 위해 포트를 개방해야 하나요?

Tailscale 클라이언트는 조정 서버로 아웃바운드 연결을 시도하고 이를 유지하므로 인바운드 포트를 열 필요가 없습니다. 직접 호스팅하는 Headscale 서버는 인바운드 포트가 필요합니다. 제어 프로토콜을 위해 443 포트, HTTP-01 인증서 챌린지를 사용하는 경우 80 포트, 그리고 내장 릴레이를 활성화할 때만 3478/udp 포트가 필요합니다. 일반 WireGuard는 서버와 공급자가 운영하는 네트워크 방화벽에서 UDP 수신 포트(보통 51820)를 개방해야 합니다.

셋 중 어느 것이 가장 빠른가요?

세 방식 모두 WireGuard를 통해 패킷을 전송하므로 처리량은 동일합니다. 차이는 연결 설정 속도와 경로 품질에서 나타납니다. 올바른 Endpoint 설정을 갖춘 일반 WireGuard는 항상 직접 연결됩니다. Tailscale과 Headscale은 대부분 직접 연결되지만 네트워크에서 홀 펀칭을 차단할 경우 릴레이로 전환되며, 릴레이 경로는 지연 시간을 증가시킵니다. 경로가 직접 연결인지 릴레이인지 확인하려면 tailscale ping <node>을 사용하거나, 터널을 통해 iperf3을 실행하여 경로 품질을 측정하십시오. 직접 경로임에도 측정값이 회선 속도보다 훨씬 낮게 나온다면, 이는 세 가지 방식 중 무엇을 선택했느냐의 문제가 아니라 일반적인 원인인 경로 MTU 불일치 때문일 가능성이 높으며, 이는 제어 평면 사용 여부와 관계없이 동일하게 발생합니다.