같은 글의 5%와 100배는 다른 종류의 개선이다

Tailscale이 성능 개선을 정리한 글에 두 숫자가 같이 있다. 하나는 약 5%, 하나는 1~2 자릿수(10~100배).

같은 제목 아래 있지만 같은 종류의 개선이 아니다. 5%는 코드가 하던 일을 덜 하게 만들어 나왔고, 100배는 하던 일을 기다리지 않게 만들어 나왔다.

소규모 팀이 자기 시스템에서 찾을 수 있는 100배는 거의 항상 뒤쪽이다. 그리고 그건 프로파일러로는 안 보인다.

출처: Making Tailscale faster

확인된 것

데이터 경로 쪽 (Linux/Android)

작은 패킷(보통 1 KiB)을 64 KiB 버퍼로 복사하던 것을 없앴다. 결과는 "roughly 5% speed-up in many network configurations". v1.104에 들어간다.
패킷 큐 깊이를 줄였다. 수치는 없다. 역시 v1.104.
writev로 여러 패킷을 한 번에 커널에 넘긴다. 수치 없음. 2026년 봄에 일부 적용됐고 전면 적용은 v1.104 이후.
멀티 큐 — 단일 스레드 파이프라인을 머신 자원에 맞춰 병렬 레인으로 바꾼다. 서브넷 라우터·앱 커넥터·엑싯 노드 대상. 수치 없이 "higher aggregate capacity and lower delay". v1.104 다음 릴리스.

netmap 캐싱

장치가 네트워크 맵을 로컬 디스크에 캐시한다.

When a device starts up, it can use that cached copy to establish connections with other devices on the tailnet, until it's able to contact the control plane.

속도 주장은 "one to two orders of magnitude faster than from a 'cold' start" 인데, 조건이 붙어 있다 — 제어 평면 도달성이 나쁜 tailnet에서 웜 캐시로 시작할 때다.

명시된 제약: 이전에 성공한 연결이 있어야 하고, 영구 디스크가 있어야 하며, 아주 큰 tailnet이나 마모에 민감한 저장소(SD카드)에는 권장하지 않는다. 현재 기능 플래그로 제공되고 v1.104에서 기본값이 될 예정, 모바일은 그 이후.

판단

1. 두 숫자를 찾는 도구가 다르다

5%는 패킷 복사를 없애서 나왔다. 프로파일러로 찾는 종류다. 뜨거운 경로에서 낭비를 발견하고 깎는다.

100배는 제어 서버 응답을 기다리지 않게 해서 나왔다. 이건 프로파일에 CPU 시간으로 잡히지 않는다. 의존성 그래프로 찾는 종류다.

→ 내 시스템에서 뒤쪽을 찾는 방법은 단순하다. 부팅 경로와 첫 요청 경로에 원격 호출이 몇 개 있는지 세고, 그중 '직전에 성공한 값으로 일단 시작해도 되는 것'이 몇 개인지 본다. 대개 하나 이상 나온다.

2. 100배에 붙은 조건이 사실상 전부다

Tailscale은 이 수치를 "제어 평면 도달성이 나쁜" 경우로 한정했다. 제어 평면이 가까우면 이득은 거의 없다.

정직하게 쓴 문장이니 정직하게 읽어야 한다. 해외 리전, 모바일 네트워크, 방화벽 뒤 IoT라면 해당한다. 같은 AZ 안에서 도는 것들이라면 무관하다.

오늘 아침 하네스 글에서 절감률이 39%·28%·16%로 갈린 것과 같은 읽기다. 개선율은 상수가 아니라 내 환경의 함수다. 숫자를 보면 조건을 먼저 찾는 습관이 든다.

3. 이 캐시의 목적은 속도가 아니라 가용성이다

netmap 캐시는 재계산을 피하는 보통의 캐시가 아니다. 제어 서버 없이도 일단 동작하게 만드는 축퇴 모드다. 사용자가 느끼는 증상이 '느림'이라서 "빠르게 만들기"라는 제목 아래 들어갔을 뿐이다.

이 구분이 실무에서 쓸모 있는 이유는, 같은 질문을 내 서비스에 던질 수 있어서다. 설정 서버가 죽으면 내 앱은 뜨는가? 마지막으로 성공한 설정을 디스크에 두고 그걸로 기동하게 하면 장애 하나가 통째로 사라진다. 이건 성능 작업이 아니라 가용성 작업인데, 대개 성능 티켓으로 위장해 들어온다.

4. 부작용 목록이 곧 채택 조건이다

이전 성공 연결 필요, 영구 디스크 필요, 아주 큰 tailnet과 SD카드 같은 마모 민감 저장소에는 비권장. 마지막 항목이 구체적이다 — 라즈베리파이에 SD카드로 돌리는 홈 서버가 정확히 그 경계에 있다.

→ 캐시를 넣을 때 같이 정해야 하는 것이 항상 셋이다. 어디에 쓰는가, 얼마나 자주 쓰는가, 틀렸을 때 어떻게 버리는가. 세 번째를 안 정하고 넣은 캐시가 나중에 제일 오래 디버깅하게 만든다.

모르는 것

재보지 않았다. 5%도 1~2 자릿수도 Tailscale 자기측정이고, 측정 구성과 방법이 공개되지 않았다.
"many network configurations"가 어떤 구성인지 모른다. 내 구성에서 5%가 나올지 알 수 없다.
멀티 큐와 writev에는 수치가 아예 없다. v1.104 다음이라 지금은 확인할 방법도 없다.
캐시가 오래됐을 때 어떻게 되는지 글에서 찾지 못했다. 캐시로 피어에 붙은 뒤 제어 평면이 "그 피어는 이제 없다"고 알려주면 얼마나 빨리 정리되는지, 그 사이 트래픽은 어디로 가는지. 캐시 설계에서 가장 궁금한 부분인데 비어 있다.
"아주 큰 tailnet"의 기준 숫자가 없다. 몇 노드부터 해당하는지 판단할 근거가 없다.