Tailscale 성능 개선, 내 네트워크에서는 무엇이 빨라질까
Tailscale이 예고한 버퍼 개선, 멀티 큐, netmap 캐시는 서로 다른 병목에 작용한다. 출시 상태와 적용 조건을 구분하고, 전송 처리량·동시 연결·접속 시작 시간을 따로 측정할 기준을 살펴본다.
VPN이 느리다는 말에는 서로 다른 문제가 섞여 있다. 큰 파일의 전송이 느릴 수도 있고, 여러 사람이 접속하면 응답이 밀릴 수도 있으며, 노트북을 켠 뒤 첫 연결만 오래 걸릴 수도 있다. Tailscale의 성능 개선 예고는 이 세 가지를 나눠 볼 좋은 사례다. 자신의 병목을 구분해야 업데이트에서 기대할 효과도 정할 수 있다.
공식 발표는 2026년 9월 22일에 나왔고, GeekNews에는 9월 24일 19시 33분에 등록됐다. 피드 등록 시각은 한국 기준이다.
출시 계획과 설치 가능한 버전을 먼저 나눈다
9월 25일 확인한 최신 안정 클라이언트는 v1.102.4다. 공식 릴리스와 변경 기록이 일치한다. 발표에 나온 개선을 이 버전에서 모두 쓸 수 있다는 뜻은 아니다.
발표는 Linux·Android의 버퍼 개선과 netmap 캐시의 기본 활성화를 v1.104로 예고한다. 멀티 큐와 추가 처리량 개선, 모바일의 캐시 적용은 이후 계획이다. 캐시는 현재 기능 플래그로 제공된다. 적용 일정
운영자가 지금 할 일은 예정된 버전 번호를 배포 조건으로 확정하는 것이 아니라, 사용할 플랫폼의 실제 릴리스 노트에서 기능이 들어왔는지 확인하는 것이다. 특히 Linux 게이트웨이의 개선을 Windows 노트북이나 모바일 클라이언트에 그대로 기대하면 비교의 출발점부터 어긋난다.
동시 연결 수에 따라 개선의 의미가 달라진다
기존 경로는 작은 패킷도 별도 64 KiB 버퍼로 복사했다. 개선안은 큰 수신 버퍼를 공유해 복사를 줄인다. 멀티 큐는 여러 흐름이 공유하던 처리 경로를 나누되, 같은 흐름은 같은 큐에 남겨 순서를 유지한다. 구현 설명
이 구조에서 내가 주목한 부분은 병렬화의 단위다. 하나의 연결을 무작정 여러 코어에 흩어 놓는 설계가 아니다. 따라서 큰 파일 하나를 보내는 시험과 여러 사용자의 짧은 요청을 동시에 전달하는 시험은 별도로 해야 한다고 본다. 전자는 한 흐름의 한계를, 후자는 여러 흐름을 합친 처리 능력을 묻는다.
가령 사내 서비스에 접속하는 사용자가 늘 때 게이트웨이의 특정 코어가 바빠진다고 가정해 보자. 이때는 동시 연결 수를 늘리며 요청 지연과 코어별 사용률을 함께 보는 실험이 의미 있다. 반면 회선이 이미 가득 차거나 목적지 서버가 응답을 늦게 만든다면, 중간 장치의 처리 개선만으로 전체 시간이 크게 줄 것이라고 기대하기 어렵다.
기존 성능 가이드는 일반적으로 코어 수보다 높은 CPU 클럭을 더 중요하게 본다. 이를 멀티 큐 예고와 함께 읽으면 하드웨어 선정도 다시 측정할 문제라는 점이 드러난다. 단일 흐름과 동시 흐름의 결과를 구분한 뒤, 같은 비용에서 어떤 구성이 유리한지 비교해야 한다. 아직 배포되지 않은 기능을 근거로 장비부터 늘릴 이유는 없다.
접속을 기다리는 시간에는 캐시가 작용한다
netmap은 접근 가능한 장치와 연결 방법을 담은 지도다. 캐시는 이를 디스크에 보관해 제어 평면의 최신 응답이 오기 전에도 연결을 시작하게 한다. 한 번 이상 연결한 이력과 영구 디스크가 필요하며, 큰 네트워크의 쓰기 부하와 SD 카드 마모는 제약이다. 캐시의 전제
공식 발표의 10~100배 개선은 제어 평면에 도달하기 어려운 환경에서 캐시를 사용한 시작과 사용하지 않은 시작을 비교한 관측이다. 파일 전송 대역폭이 그만큼 늘어난다는 수치가 아니다. 측정 범위 이 글에서는 해당 성능을 재측정하지 않았다.
이 조건이라면 처음 등록하는 일회성 CI 실행기와, 상태를 보존하며 재시작하는 개발 머신을 같은 집단으로 평가하면 안 된다. 새 실행기에는 재사용할 지도가 없을 수 있다. 캐시를 쓰기 위해 상태를 보관한다면 그 저장소의 수명과 관리 비용도 함께 정해야 한다.
또한 캐시가 있다는 사실만으로 모든 단절 상황에서 접속이 된다고 가정해서는 안 된다. 연결 방식 문서는 UDP 차단이나 NAT 조건에 따라 직접 연결이 불가능하고 릴레이가 필요할 수 있다고 설명한다. 저장된 정보로 시작할 수 있는지와, 상대 장치까지 실제 경로가 열리는지는 따로 확인할 조건이다.
비교 전에 경로와 관측 대상을 기록한다
나는 업데이트 전후를 비교할 때 먼저 연결 경로를 기록하겠다. 공식 문서는 직접 연결이 대체로 지연과 처리량에 유리하며, 직접 연결이 어렵다면 자체 인프라의 Peer Relay를 검토할 수 있다고 설명한다. 성능 가이드 코드 변경과 함께 경로까지 달라지면 어느 쪽의 효과인지 구분하기 어렵다.
아래는 CLI 문서에 따른 진단 예다. Tailscale v1.102.4 클라이언트가 설치·로그인돼 있고 상대 장치에 접근할 수 있다는 전제다. peer-name은 실제 장치 이름으로 바꾼다. 여기서는 명령을 실행하지 않았다.
tailscale version
tailscale status
tailscale ping --c 5 peer-name
status의 활성 연결에는 direct, relay, peer-relay 같은 경로가 표시된다. ping은 연결을 살피는 도구이며 애플리케이션의 처리량 시험을 대신하지 않는다. 첫 탐색과 연결이 자리 잡은 뒤의 결과도 나눠 남기는 편이 좋다.
| 확인하려는 증상 | 비교할 항목 |
|---|---|
| 큰 파일 하나가 늦게 도착한다 | 같은 경로에서 전송 시간, CPU 사용률, 회선 사용량 |
| 동시 사용자가 늘면 응답이 밀린다 | 연결 수에 따른 전체 처리량, 요청 지연의 분포, 코어별 부하 |
| 재시작 직후에만 접속이 늦다 | 첫 응답까지의 시간, 기존 등록 여부, 캐시와 제어 평면의 상태 |
업데이트 검증에는 정상 결과뿐 아니라 실패율과 원래 버전으로 되돌릴 절차도 필요하다. 작은 장치에서는 메모리뿐 아니라 디스크 쓰기까지 관찰해야 한다. 나는 대표 경로 하나에서 이 비용과 효과를 확인한 다음 적용 범위를 넓히겠다. 이번 발표에서 가져갈 기준은 최고 속도 숫자보다, 사용자가 기다리는 시간이 어느 구간에서 생기는지 설명할 수 있는가에 있다.
참고 자료
이 이야기가 도움이 되었나요?