VPN인데 빠르다고요?
Tailscale 팀이 블로그에 'Making Tailscale Faster'라는 글을 올렸어요. 제목 그대로 Tailscale을 더 빠르게 만들기 위해 어떤 작업을 해왔는지 다루는 글인데요. 이 글을 계기로, Tailscale이 어떤 구조로 속도를 끌어올리는지 그 밑바탕부터 한번 정리해 보려고 해요.
먼저 Tailscale이 뭐냐면, WireGuard라는 암호화 터널 프로토콜 위에 만들어진 '메시 VPN'이에요. 보통 회사에서 쓰는 VPN은 모든 트래픽이 중앙 서버를 한 번 거쳐서 목적지로 가는 구조거든요. 서울에 있는 내 노트북에서 같은 사무실의 개발 서버에 붙는데도, 트래픽이 VPN 게이트웨이까지 갔다가 돌아오는 식이죠. 반면 Tailscale은 각 기기끼리 직접 암호화 터널을 만들어요. 가운데를 거치지 않으니 당연히 빠를 수밖에 없죠. 그런데 '직접 연결'이라는 게 말처럼 쉽지 않아서, 여기서부터 속도 이야기가 시작돼요.
첫 번째 관문: 직접 연결이 되느냐
Tailscale의 속도를 결정하는 가장 큰 요소는 두 기기가 '직접' 붙었느냐, 아니면 '릴레이'를 거치느냐예요. 집 공유기나 회사 방화벽 뒤에 있는 기기들은 공인 IP가 없기 때문에 서로를 바로 찾을 수 없거든요. 이걸 뚫는 기술이 NAT 트래버설이에요. 이게 뭐냐면, 양쪽 기기가 동시에 바깥으로 패킷을 쏴서 공유기에 구멍을 내고, 그 구멍으로 서로 연결하는 기법이에요. 흔히 '홀 펀칭'이라고 부르죠.
이게 실패하면 Tailscale은 DERP라는 자체 릴레이 서버를 경유해요. 릴레이를 타면 연결은 되지만 지연 시간이 늘고 대역폭도 제한되니까, 체감 속도가 확 떨어져요. 그래서 Tailscale의 성능 작업 중 상당 부분은 '어떻게든 직접 연결을 성공시키는 것'에 쏠려 있어요. UPnP나 NAT-PMP 같은 포트 매핑 프로토콜을 활용하기도 하고, 까다로운 NAT에서는 여러 포트를 동시에 시도하는 확률적인 기법까지 동원하거든요. 2025년에 베타로 나온 '피어 릴레이' 기능도 같은 맥락이에요. 직접 연결이 안 될 때 Tailscale 회사 서버 대신 내 네트워크 안의 다른 기기를 릴레이로 쓰게 해서, 대역폭 제한 없이 훨씬 빠른 경로를 만들어 주는 거예요.
두 번째 관문: 유저스페이스 WireGuard의 한계
직접 연결이 됐다고 끝이 아니에요. Tailscale은 리눅스 커널에 내장된 WireGuard가 아니라, Go 언어로 작성된 wireguard-go를 써요. 모든 운영체제에서 똑같이 동작하게 만들려면 커널 의존을 줄여야 하거든요. 대신 대가가 있어요. 커널 안에서 처리되는 게 아니라 일반 프로그램처럼 돌기 때문에, 패킷 하나가 오갈 때마다 커널과 프로그램 사이를 왔다 갔다 해야 해요. 이 왕복이 시스템 콜인데, 패킷이 초당 수십만 개가 되면 이 오버헤드가 병목이 돼요.
Tailscale 팀이 여기서 한 일이 꽤 유명해요. 패킷을 하나씩 처리하는 대신 여러 개를 묶어서 한 번의 시스템 콜로 처리하는 거예요. UDP GSO와 GRO라는 커널 기능을 활용했는데, 이게 뭐냐면 보낼 때는 큰 덩어리 하나를 넘기면 커널이 알아서 잘라서 보내고, 받을 때는 커널이 여러 패킷을 모아서 한 번에 넘겨주는 기능이에요. 택배를 한 상자씩 들고 나르는 대신 카트에 잔뜩 실어 한 번에 나르는 셈이죠. 가상 네트워크 장치인 TUN 쪽에도 같은 방식의 묶음 처리를 적용했어요. 이 작업 덕분에 리눅스에서 Tailscale 터널로 10Gb/s를 넘기는 결과를 2023년에 공개했고, 이 개선 사항은 wireguard-go 본가에도 반영됐어요.
경쟁 프로젝트와 비교하면
같은 WireGuard 기반 메시 VPN으로는 오픈소스인 NetBird가 있어요. NetBird는 리눅스에서 커널 WireGuard를 쓸 수 있어서 그 부분은 유리하지만, 플랫폼 간 동작 일관성이나 NAT 트래버설 완성도는 Tailscale이 앞선다는 평가가 많아요. ZeroTier는 자체 프로토콜을 쓰는 오래된 경쟁자고, Slack이 만든 Nebula는 인증서 기반의 다른 접근을 택했어요. 그리고 Tailscale의 컨트롤 서버만 오픈소스로 대체한 Headscale도 있는데, 클라이언트는 Tailscale 것을 그대로 쓰니까 여기서 다룬 성능 개선은 Headscale 사용자도 똑같이 누려요.
흐름으로 보면 이 업계는 '연결되느냐'에서 '얼마나 빠르고 안정적이냐'로 경쟁 축이 옮겨 갔어요. 이제 VPN을 원격 접속용으로만 쓰는 게 아니라, 쿠버네티스 노드 간 통신이나 GPU 서버 간 데이터 이동처럼 대역폭이 중요한 곳에도 깔기 때문이에요.
한국 개발자라면 이렇게 써먹어 보세요
Tailscale은 개인이나 소규모 팀이면 무료로 쓸 수 있어서, 집 NAS나 홈랩 서버에 밖에서 붙는 용도로 이미 많이 쓰고 계실 거예요. 속도가 답답하다면 먼저 tailscale status로 상대 기기 옆에 direct가 찍히는지 relay가 찍히는지 확인해 보세요. relay라면 tailscale netcheck로 어떤 NAT 종류인지, 어느 DERP 서버가 가까운지 볼 수 있고요. 공유기에서 UPnP를 켜 주는 것만으로 직접 연결 성공률이 확 올라가는 경우가 많아요.
서버 간 대용량 전송을 Tailscale로 하고 있다면 리눅스 커널 버전이 최신인지도 중요해요. 위에서 말한 GSO/GRO 최적화는 커널이 지원해야 효과가 나거든요. 그리고 대역폭이 중요한 사내 환경이라면 피어 릴레이를 설정해서 DERP 의존도를 줄이는 것도 방법이에요.
정리하면
Tailscale의 속도는 '직접 연결 성공률'과 '유저스페이스 오버헤드 줄이기' 두 축으로 만들어지고, 이번 글은 그 노력이 지금도 이어지고 있다는 이야기예요.
여러분은 Tailscale을 어떤 용도로 쓰고 계세요? 릴레이 때문에 속도가 안 나와서 고생한 경험이나, 직접 연결을 뚫기 위해 시도해 본 설정이 있다면 댓글로 공유해 주세요.
🔗 출처: Hacker News