오버레이 VPN & 메시 네트워킹 2026 — Tailscale / Headscale / ZeroTier / Nebula / WireGuard / NetBird 심층 비교

프롤로그 — “집 컴퓨터에 ssh 좀 하고 싶어요”에서 시작된 시장

2026년에 가장 조용히, 그러나 가장 광범위하게 일어난 인프라 교체 중 하나는 회사 VPN의 죽음이다.

10년 전이라면 “집에서 회사 내부망에 들어가야 한다”의 답은 정해져 있었다. 사내 VPN 서버에 OpenVPN 또는 IPsec 클라이언트로 접속한다. 사용자는 매번 인증을 다시 하고, 트래픽은 사내 게이트웨이를 거쳐 인터넷으로 다시 나가고, 라우터는 “라떼는” 같은 표정으로 패킷을 처리했다.

지금은 다르다. 노트북을 켜면 자동으로 메시 네트워크에 합류한다. 회사 데이터센터의 서버, 동료의 노트북, 클라우드 VPC, 집에 있는 라즈베리파이 — 모두 같은 사설 IP 대역에 들어와 있다. 누가 누구한테 접근할 수 있는지는 ACL 파일 한 장으로 결정된다. 누구도 “게이트웨이”를 거치지 않는다. 두 호스트 사이의 가장 빠른 경로는 직통 P2P이고, 그게 불가능하면 가장 가까운 릴레이가 자동으로 끼어든다.

이 변화의 진원지는 한 회사다 — Tailscale. 그리고 그 회사를 둘러싸고 셀프호스팅(Headscale·NetBird·Innernet), 엔터프라이즈(Twingate·Cloudflare Zero Trust), 다른 신뢰 모델(Nebula·ZeroTier·Yggdrasil)이 각자 자리를 잡았다.

이 글은 그 지도를 그린다. WireGuard라는 공통 기반, Tailscale이 정의한 UX, 그 주변의 대안들, 그리고 “당신 조직은 무엇을 골라야 하는가”까지.

1장 · 2026년 오버레이 VPN 지도 — 세 진영

먼저 큰 그림. 2026년 오버레이 VPN/메시 시장은 세 진영으로 갈라진다.

진영	대표 제품	누가 컨트롤 플레인을 운영하나	특징
매니지드 SaaS	Tailscale, Twingate, Cloudflare Zero Trust, NetBird Cloud, ZeroTier Central, Defined Networking	벤더	빠른 도입, 무료 티어, 엔터프라이즈는 SSO·SCIM·감사
셀프호스팅 오픈소스	Headscale, NetBird (self-host), Innernet, Nebula	본인	컨트롤 평면도 내가 운영, 데이터 주권, 공급망 리스크 통제
DIY / 기반 기술	WireGuard, IPsec, OpenVPN, Yggdrasil	본인 (라우팅까지)	가장 자유롭고 가장 일이 많다

“진영”이라는 단어를 쓰지만 실제로는 거의 모두 WireGuard 위에 서 있다. 차이는 “키 분배, NAT 트래버설, 정책, 사용자 인증을 누가 책임지느냐”다.

한 줄 요약

개인/홈랩 → Tailscale 무료 티어. 끝.
셀프호스팅 마니아 → Headscale + Tailscale 클라이언트.
SMB / 스타트업 → NetBird 또는 Tailscale Teams.
엔터프라이즈 → Cloudflare Zero Trust, Twingate, Tailscale Enterprise 중 택일.
특수 요구(IPv6 메시, 라우팅 자체가 게임) → Yggdrasil, Nebula.

이게 결론이고, 나머지 14장은 “왜 그런가”를 본다.

2장 · NAT 트래버설 — STUN / TURN / DERP / 홀펀칭 기초

오버레이 VPN의 진짜 마법은 암호화가 아니라 NAT 뒤에 있는 두 컴퓨터를 직접 연결하는 것이다. WireGuard는 “패킷을 어떻게 안전하게 보내느냐”를 풀지만, “어디로 보내느냐, 그 IP가 NAT 뒤에 있을 때 어떻게 도달하느냐”는 별개의 문제다.

NAT의 종류와 친절함

NAT 타입	친절함	홀펀칭 가능?
Full Cone	매우 친절	매우 쉬움
Restricted Cone	친절	쉬움
Port-Restricted Cone	보통	양쪽 협력 필요
Symmetric NAT	비협조적	매우 어려움, 릴레이 필요한 경우 많음
CGNAT (캐리어급)	적대적	거의 항상 릴레이 필요

한국의 LTE/5G 모바일은 거의 CGNAT다. 일본 OCN, 미국 T-Mobile도 마찬가지. 현실 세계 인터넷의 상당 부분은 “P2P가 안 되는 곳”이다. 그래서 모든 오버레이 VPN은 릴레이 폴백을 가진다.

STUN / TURN / DERP

전통적 WebRTC 세계에서:

STUN (Session Traversal Utilities for NAT): “나의 공인 IP·포트는 무엇인가?”를 묻는 서버. 양쪽이 서로의 공인 endpoint를 알게 하면 홀펀칭이 시작된다.
TURN (Traversal Using Relays around NAT): STUN으로 안 되면 TURN 서버가 양쪽 트래픽을 릴레이.

Tailscale은 자체 변형을 만들었다:

DERP (Designated Encrypted Relay for Packets): HTTPS(443) 위에서 동작하는 릴레이. 방화벽이 가장 잘 통과시키는 포트가 443이라는 현실에 적응. 트래픽은 항상 양 끝에서 WireGuard 키로 암호화되어 있으므로 DERP는 암호문만 본다 — 릴레이가 “읽을” 수 없다.

DERP가 천재적인 이유:

HTTPS는 어디서나 열려 있다. 5G CGNAT, 호텔 WiFi, 회사 방화벽 모두 통과.
컨트롤 플레인과 분리. DERP는 순수 릴레이일 뿐, “누구한테 보낼지”는 모른다.
자동 폴백. P2P가 가능해지면 즉시 P2P로 전환. 사용자는 모른다.

홀펀칭의 동작

A (집, NAT 뒤)                B (사무실, NAT 뒤)
   │                              │
   │  ─── STUN ─→  "내 공인 EP"   │  ─── STUN ─→
   │       Coordinator              │
   │  ←─── B의 공인 EP ───          │  ←─── A의 공인 EP ───
   │                              │
   │  ─── UDP 패킷 (A→B) ─→ ❌(B의 NAT에서 떨어짐)
   │  ←─── UDP 패킷 (B→A) ─── ❌(A의 NAT에서 떨어짐)
   │
   │  → 동시에 양방향으로 보내면 양쪽 NAT의 매핑이 만들어진다 ←
   │
   │  ─── UDP 패킷 ─→ ✅ 직통 P2P

핵심 트릭: 양쪽이 동시에 패킷을 보내면, 양쪽 NAT은 “나가는 트래픽이 있으니 응답을 들여보내자”는 매핑을 만든다. 한 번 매핑이 생기면 그 후로는 직통.

Tailscale의 DERP는 “이 트릭이 실패할 때를 위한 안전망”이다.

3장 · WireGuard — 모든 것의 기반

2020년 Linux 커널 5.6에 머지된 WireGuard는 VPN 세계를 바꿨다. 너무 깔끔하고 너무 작아서, 이전 세대 VPN (OpenVPN, IPsec) 의 위치를 빠르게 뺏어갔다.

WireGuard가 단순한 이유

# /etc/wireguard/wg0.conf
[Interface]
PrivateKey = ...
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
PublicKey = ...
Endpoint = 203.0.113.42:51820
AllowedIPs = 10.0.0.2/32

이게 전부다. 키, IP, 엔드포인트. 협상 프로토콜은 단 한 라운드트립(1-RTT). 암호 스위트는 고정 — Curve25519, ChaCha20-Poly1305, BLAKE2s, HKDF. 선택의 여지가 없다 = 잘못 구성할 여지가 없다.

OpenVPN과 비교:

OpenVPN: 코드 약 10만 줄, 수백 개 설정 옵션, TLS, 다양한 cipher suite, 복잡한 라우팅 모드
WireGuard: 코드 약 4천 줄(커널 모듈), 고정된 한 가지 cipher suite

WireGuard가 해결하지 않는 것

이게 더 중요하다. WireGuard는 데이터 평면이지 컨트롤 평면이 아니다.

WireGuard가 제공하지 않는 것:

키 분배. 새 노드가 들어오면 모든 노드의 [Peer] 섹션을 업데이트해야 한다. 수동.
NAT 트래버설. Endpoint가 NAT 뒤면 그냥 안 된다.
DNS / 이름 해석. IP만 안다.
ACL / 권한 정책. 모든 peer는 AllowedIPs에 적힌 IP에 자유롭게 접근.
사용자 인증. 키 = 신원이고, 사용자 ↔ 키 매핑은 외부 시스템의 몫.
로테이션, 폐기, 멤버십 관리.

오버레이 VPN 시장의 모든 제품은 **“WireGuard 위에 컨트롤 플레인을 얹어 위의 6가지를 자동으로 푸는 것”**이다. Tailscale, Headscale, NetBird, Innernet, Cloudflare WARP 전부 그렇다.

WireGuard는 “VPN 프로토콜”이 아니라 “안전한 터널 프리미티브”다. 그 위에 무엇을 쌓느냐가 진짜 제품이다.

`wg-quick`만으로 충분한 경우

노드 수 ≤ 5
한쪽이 공인 IP를 가진 서버
멤버십이 거의 변하지 않음

이 조건이면 wg-quick은 완벽하다. 한 줄짜리 conf 파일, kernel 데이터 패스, 거의 0 오버헤드. 작은 홈 서버와 노트북 둘이면 이게 최선일 수 있다.

조건이 깨지는 순간 — 5명을 넘어서고, 둘 다 NAT 뒤고, 매주 새 노드가 들어오고 — 컨트롤 플레인이 필요해진다. 그게 다음 장의 주제다.

4장 · Tailscale — 사실상 표준

2019년 창업한 Tailscale은 “WireGuard 위에 사용자가 원했던 모든 것”을 얹어 시장을 정의했다. 2026년에는 사실상 표준이다.

Tailscale = WireGuard + 코디네이션 서비스

                  ┌──────────────────────────┐
                  │   Tailscale Control      │
                  │   (Coordination Server)  │
                  │   - 노드 등록             │
                  │   - 공개 키 배포          │
                  │   - ACL 평가              │
                  │   - 어떤 DERP를 쓸지       │
                  └──────────────────────────┘
                          ▲             ▲
                          │ 컨트롤       │ 컨트롤
                          │             │
                  ┌───────┴───┐   ┌─────┴─────┐
                  │   노드 A   │   │   노드 B   │
                  └─────┬─────┘   └─────┬─────┘
                        │                │
                        │  WireGuard P2P │
                        │ ◀───────────▶  │
                        │                │
                        │      또는       │
                        │ ┌────────────┐ │
                        └▶│ DERP 릴레이  │◀┘
                          └────────────┘

컨트롤 평면은 메타데이터만 본다. 실제 트래픽은 노드들 사이에서 직접 (또는 DERP를 거쳐) 흐르고, 양 끝에서 WireGuard로 암호화돼 있다. Tailscale 회사조차 사용자 트래픽 내용을 못 본다.

핵심 기능 (2026년)

기능	무엇
MagicDNS	노드 이름을 DNS처럼 — `ssh laptop`이 그냥 된다. `*.ts.net` 서브도메인 자동.
Subnet Router	한 노드가 “내 뒤의 서브넷도 라우팅한다”고 광고. 사내 192.168.x를 메시에 노출.
Exit Node	노드를 인터넷 게이트웨이로 지정. 모든 트래픽이 그 노드를 통해 나간다.
ACL (Tailnet Policy)	HuJSON 파일 한 장으로 `user:alice@example.com → tag:server` 같은 규칙.
Tailscale SSH	SSH 키 자체를 Tailnet에 위임. 키 배포 불필요.
Tailscale Funnel	메시 안의 노드를 공개 인터넷에 노출. HTTPS 자동.
Tailscale Serve	노드 위의 서비스를 메시 내부에만 노출 (TLS 자동).
Mullvad 통합	exit node를 Mullvad VPN의 출구로 → 진짜 “인터넷 VPN” 모드.
App Connector	SaaS(Slack, Notion)로의 트래픽을 특정 노드가 대리. SaaS의 IP allowlist에 그 한 노드만 등록.
ACME / TLS	메시 노드에 진짜 LetsEncrypt 인증서 자동 발급.
Auto-update	클라이언트 자동 업데이트. 보안 패치 누락 방지.

Tailscale Funnel — “localhost를 인터넷에 띄우기”

홈서버에서 데모를 한 시간만 외부에 보여주고 싶다. 옛날엔 ngrok이었고, 지금도 ngrok는 좋지만 Tailscale 가입자라면 그냥:

tailscale funnel 8080
# https://my-laptop.tail1234.ts.net 가 만들어진다
# LetsEncrypt 인증서 자동

Cloudflare Tunnel과 정확히 같은 카테고리, 다만 “이미 Tailnet 안에 있는 노드를 그대로 노출”하는 식.

Mullvad 파트너십 — 두 가지 VPN의 결혼

2023년부터 Tailscale 유료 사용자는 추가 비용 없이 (또는 약간) Mullvad의 38개국 출구를 exit node로 쓸 수 있다.

“업무용 메시 네트워크” → Tailscale
“스타벅스 WiFi에서 안전하게 인터넷 쓰기” → Mullvad
“하나의 클라이언트로 둘 다” → 2026년 표준 셋업

가격과 무료 티어

Free (Personal): 3명, 100 기기, 모든 기능. 사실상 개인·소규모 홈랩에는 무한.
Starter / Premium / Enterprise: 사용자당 월 단위. SSO/SCIM/감사/SLA는 상위 티어.

2026년 현재 무료 티어는 세계에서 가장 관대한 SaaS 무료 티어 중 하나다. 그게 “Tailscale을 안 써본 개발자가 없는” 이유다.

약점

컨트롤 평면 의존. Tailscale의 컨트롤이 죽으면 신규 연결·키 로테이션이 막힌다(이미 연결된 세션은 한동안 유지).
벤더 락인. 핵심 기능은 클라이언트와 컨트롤 평면이 함께 만든다. → 다음 장 Headscale.
데이터 주권. 메타데이터는 Tailscale의 서버에 남는다. 규제 산업에는 부담.

5장 · Headscale — Tailscale 셀프호스팅

Headscale은 Tailscale의 컨트롤 평면을 오픈소스로 다시 구현한 프로젝트다. 클라이언트는 Tailscale의 공식 오픈소스 클라이언트를 그대로 쓰고, 서버 사이드만 본인이 운영한다.

만든 사람: Juan Font (Tailscale 직원은 아니지만 Tailscale 측이 “건강한 외부 구현”으로 환영해 왔다).

무엇이 같고 무엇이 다른가

기능	Tailscale (SaaS)	Headscale
WireGuard 데이터 평면	동일	동일
MagicDNS	있음	있음
ACL	있음 (HuJSON)	있음 (호환 형식)
DERP	Tailscale 운영	본인이 운영하거나 Tailscale의 공개 DERP 사용 가능
Funnel / Serve	있음	부분 (버전에 따라)
Mullvad	있음	없음 (Mullvad 계약)
SSO/SAML/SCIM	있음	부분 (OIDC 가능)
운영 부담	0	본인

구축

docker run -d --name headscale \
  -v ./config:/etc/headscale \
  -v ./data:/var/lib/headscale \
  -p 8080:8080 \
  -p 9090:9090 \
  headscale/headscale:0.25.0 \
  serve

# 클라이언트는 그냥
tailscale up --login-server=https://headscale.example.com

그 외엔 사용 경험이 거의 똑같다. tailscale status, tailscale ssh, tailscale ping 전부 그대로 동작.

누가 Headscale을 골라야 하나

데이터 주권 요구가 강한 조직 (유럽 규제, 금융, 정부)
벤더 락인을 견딜 수 없는 사람 (인프라 철학)
인터넷 단절된 환경 (Tailscale의 컨트롤로 갈 수 없음)
재미 — 사실 개인 홈랩에서 Headscale을 돌리는 사람들이 많다. UI/UX는 비공식 웹UI들이 채워주고 있다 (예: headscale-ui).

약점

Tailscale이 새 기능을 내면 Headscale은 따라잡는 데 몇 달이 걸린다.
운영은 본인 책임 — DERP 운영, DB 백업, 업그레이드.
엔터프라이즈 기능(고급 ACL UI, 감사 로그 UI, 자동 디바이스 posture check)은 부족.

6장 · ZeroTier — WireGuard 이전 시대의 챔피언

ZeroTier는 2011년 시작됐다. WireGuard가 존재하기 한참 전이다. 자체 프로토콜, 자체 cipher suite, 자체 데이터 평면. “전 세계 가상 이더넷 스위치”라는 비유를 가장 처음 만든 회사 중 하나다.

모델

   네트워크 ID (16자리 16진수)에 가입
       ↓
   글로벌 컨트롤러(루트 노드)가 ID·키 분배
       ↓
   모든 노드가 Layer 2 가상 NIC를 가진다
       ↓
   L2 프레임이 P2P로 흐른다 (P2P 실패 시 root로 릴레이)

WireGuard와의 차이:

Layer 2 (이더넷). WireGuard/Tailscale은 Layer 3 (IP) 위만 본다. ZeroTier는 브로드캐스트, 멀티캐스트, 비-IP 프로토콜도 흘릴 수 있다. “그냥 한 LAN처럼” 작동.
자체 프로토콜. WireGuard처럼 커널 모듈은 아니고 사용자공간 데몬.
컨트롤러 자체호스팅 가능. ZeroTier Central(SaaS)을 쓸 수도, ZTNCUI 등으로 셀프호스트할 수도.

2026년에 ZeroTier가 여전히 의미 있는 경우

레거시 비-IP 트래픽 (오래된 산업용 프로토콜, NetBIOS, 일부 게임)
이미 ZeroTier로 깔린 환경 — 마이그레이션 비용
Layer 2 시맨틱이 필요한 시나리오 (예: 가상 머신 클러스터의 vMotion, 일부 클러스터링 솔루션)
단일 무료 네트워크에 25명 이하의 소규모 (무료 티어 한도)

약점 (Tailscale 시대 기준)

UX가 Tailscale보다 한 세대 떨어진다. MagicDNS·SSH·Funnel 같은 게 없다.
WireGuard 대비 성능이 떨어진다 (사용자공간 = 컨텍스트 스위치).
L2를 메시에 흘리는 건 보안적으로 위험할 때가 많다 (브로드캐스트 폭주).

대다수의 사용 사례에서 “2026년에 새로 도입할 이유”는 적다. 다만 ‘L2 시맨틱이 필요한가?’를 진지하게 묻는 사용자에게는 거의 유일한 답이다.

7장 · Nebula (Slack 오픈소스) — 다른 신뢰 모델

Slack이 자사 서비스 메시(수백만 호스트 규모)를 운영하면서 만든 게 Nebula다. 2019년 오픈소스화. Tailscale과 같은 “WireGuard 기반 메시”처럼 보이지만 모델 자체가 다르다.

핵심 아이디어 — PKI

Nebula는 자체 PKI를 갖는다. 운영자가 CA를 만들고, 각 노드에 인증서를 발급한다. 인증서에는:

노드 이름
그룹 멤버십 (예: web, db, staging)
허용된 IP
만료일

인증서 자체에 권한이 박혀 있다. 컨트롤 서버에 매번 “이 노드가 누구냐”를 물을 필요가 없다 — 인증서가 곧 신원이고, 노드끼리 직접 검증한다.

Tailscale vs Nebula 비교

차원	Tailscale	Nebula
키 분배	컨트롤 평면이 동적으로	PKI, 정적으로 인증서 발급
신원	사용자 ↔ 키 매핑 (SSO 가능)	인증서의 그룹/이름
정책 평가	컨트롤 평면 (중앙)	노드에서 (분산)
확장성	수만 노드 OK, 컨트롤 평면 의존	수십만 노드 운영 사례 (Slack)
운영 모델	SaaS 또는 Headscale	본인 (lighthouse 노드 운영)
NAT 트래버설	DERP 등	UDP 홀펀칭 + lighthouse 릴레이

lighthouse — 디스커버리

Nebula에서 “어떤 노드의 공인 endpoint가 뭐인지”는 lighthouse라는 특수 노드가 안다. 노드들은 lighthouse에 자기 정보를 등록하고, 다른 노드를 찾을 때 lighthouse에 묻는다. Lighthouse는 작은 서버 한두 대면 충분.

어디서 빛나는가

대규모 인프라 메시 (수천~수만 노드의 서버투서버 연결)
이미 PKI를 사내에서 운영하고 있는 조직 — Vault, Step-CA 등과 자연스럽게 결합
컨트롤 평면이 죽어도 메시는 살아 있어야 하는 환경 — 인증서가 유효한 한 노드들끼리 통신 계속
사용자 노트북이 아니라 서버 인프라 중심의 사용

약점

사람 친화적인 도구가 아니다. CLI/설정 파일이 다수. Tailscale의 “설치하면 끝나는” UX와 거리가 멀다.
MagicDNS 같은 편의 기능 부재.
SSO 통합이 약하다. 사용자 워크스테이션을 메시에 넣는 시나리오엔 어울리지 않는다.

8장 · Defined Networking — 상용 Nebula

Nebula를 만든 핵심 개발자들이 만든 회사가 Defined Networking이다. Nebula 오픈소스의 “관리형 컨트롤 평면 + UI + 인증서 발급 자동화”를 제공.

“Nebula의 Tailscale”이라고 부를 수 있는 포지션.
다만 사용자 노트북보다는 서버 인프라 시장에 더 집중.
SSO, 정책 UI, 감사 로그 등을 컨트롤 평면에서 제공.
가격은 기기당 월 단위.

선택의 결정 기준:

우리는 “사람 < 서버” 비중인가 → Defined Networking이 자연스럽다.
우리는 “서버 < 사람” 비중인가 → Tailscale이 자연스럽다.

9장 · NetBird (오픈소스) — Tailscale + SSO

NetBird는 2022년경 등장한 “오픈소스 + SSO-퍼스트” 메시 VPN이다. WireGuard 기반, MagicDNS 비슷한 기능, ACL, 그리고 처음부터 OIDC/SAML 통합이 중심.

핵심 차이

셀프호스팅이 진짜 가능. Headscale은 “Tailscale 호환 컨트롤 평면”이지만 NetBird는 처음부터 “셀프호스팅을 메인 경로”로 설계됐다. Docker Compose 한 방.
SSO 통합이 기본. Keycloak, Auth0, Authentik, Google Workspace, Okta 다 됨.
정책 UI. 웹에서 그룹·태그·정책을 시각적으로 편집.
SaaS도 있다. NetBird Cloud(매니지드)도 운영. 가격은 Tailscale보다 약간 저렴한 편.

NetBird vs Tailscale vs Headscale

차원	Tailscale	Headscale	NetBird
라이선스	컨트롤 평면 클로즈드	100% 오픈소스	100% 오픈소스
매니지드 옵션	Yes	비공식	Yes (NetBird Cloud)
SSO	엔터프라이즈에서	OIDC만	강력함 (모든 주요 IdP)
MagicDNS	Yes	Yes	Yes
ACL UI	Yes	제한적	강력함
셀프호스트 난이도	불가	보통	쉬움
클라이언트 다양성	최고 (모든 OS)	Tailscale 클라이언트 사용	모든 주요 OS

누가 NetBird를 골라야 하나

셀프호스팅이 요구되고 + 사내 SSO가 이미 있는 SMB / 미드마켓
Tailscale 가격이 부담되고 + 셀프호스팅을 감당할 인력이 있음
오픈소스 원칙이 강한 조직

약점

기능 성숙도는 Tailscale 미만. Funnel 같은 “와우 기능”은 없거나 약하다.
커뮤니티 규모가 Tailscale보다 작다.
DERP 같은 정교한 글로벌 릴레이망은 직접 구축해야 한다.

10장 · Twingate — Zero Trust 엔터프라이즈

Twingate는 “오버레이 VPN이 아니라 Zero Trust Network Access (ZTNA)” 카테고리로 자리를 잡았다. 이게 무슨 차이일까.

모델 차이

전통적 메시 VPN (Tailscale, NetBird):

사용자가 “메시에 합류”한다
합류하면 ACL이 허용하는 모든 노드가 보인다
IP 기반 정책

Twingate(및 Cloudflare Access, Google BeyondCorp 같은 ZTNA 카테고리):

사용자가 “리소스에 접근 요청”을 한다
요청마다 신원/디바이스 posture/시간/조건이 평가된다
리소스 단위 정책 (예: “이 사용자는 이 호스트의 443만”)
보통 TCP 프록시 모델 — 메시 IP가 아니라 “이름 기반”

Twingate의 구성요소

[사용자 디바이스 + Twingate Client]
        │
        ▼ (TLS, 인증 토큰)
[Twingate Controller (SaaS)] ── 정책 평가
        │
        ▼
[Twingate Connector (사내에 설치)]
        │
        ▼
[보호 대상 (DB, 내부 웹앱, SSH)]

핵심: Connector는 outbound로만 Controller에 연결한다. 사내에 inbound 포트를 열 필요가 없다. 이건 Cloudflare Tunnel과 같은 패턴.

강점

포트를 안 연다. 사내 리소스를 인터넷에 노출하지 않고도 접근.
리소스 단위 ACL. “Alice는 staging의 jenkins:8080만” 식.
디바이스 posture. Mac이 디스크 암호화 켜져 있나? OS 최신인가? 안 그러면 차단.
사이트투사이트 VPN 대체. 사용자→리소스 모델이라 “지점간 VPN 라우팅”을 안 짠다.

약점

메시가 아니다. 노드끼리는 못 본다. 사용자→리소스 일방향.
벤더 락인이 강하다. 컨트롤도 connector도 회사 코드.
가격이 SaaS-tier. SMB에는 비쌀 수 있다.

누가 고르는가

이미 사내에 OpenVPN/Cisco AnyConnect로 “사이트투사이트 VPN”을 운영 중인 엔터프라이즈가 그걸 끝내고 싶을 때.
컴플라이언스(SOC 2, ISO 27001)에서 “세션마다 인증, 디바이스 posture, 감사 로그”를 요구할 때.
콜센터/지원조직처럼 “직원이 잠깐 들어와서 한 리소스만 본다”의 패턴.

11장 · Cloudflare WARP / Zero Trust — 소비자 + 엔터프라이즈

Cloudflare는 두 가지 다른 제품을 한 우산 아래 묶었다.

WARP — 무료 소비자 VPN-ish

원래 모바일 앱이었다. “1.1.1.1로 DNS를 보내고 모든 트래픽을 CF의 글로벌 네트워크로 흘려보내는” 무료 서비스. 정통 VPN과 다른 점:

IP를 숨기는 게 주된 목적이 아님 (Mullvad와는 다른 결).
“느린 ISP 라우팅보다 CF의 더 빠른 백본”이 셀링 포인트.
WireGuard 변형 (Cloudflare가 만든 BoringTun) 위에서 동작.

WARP+ (유료)는 우선순위 라우팅과 약간의 추가 기능.

Cloudflare Zero Trust — 엔터프라이즈 ZTNA

같은 클라이언트가 사실은 엔터프라이즈 Zero Trust 플랫폼의 진입점이다.

Cloudflare Access: SaaS·내부 앱에 SSO + 정책 게이트 (BeyondCorp 패턴).
Cloudflare Tunnel (구 Argo Tunnel): connector daemon이 outbound로 CF에 연결, 사내 리소스를 안전하게 노출.
Gateway: 사용자 → 인터넷 트래픽을 DNS/HTTP/네트워크 필터로 검사 (SWG).
Browser Isolation: 위험한 사이트는 클라우드 브라우저에서 렌더 후 픽셀만 보내기.
Cloudflare One: 위의 모든 걸 “SASE” 우산으로 묶음.

강점

글로벌 백본. 320+ 도시 PoP. 어디서 접속해도 가까운 PoP.
DNS·CDN·DDoS·Workers를 같은 회사가 한다. 통합도가 높다.
무료 티어가 진짜 쓸 만하다 (사용자 50명까지 Zero Trust 무료).
DEX(Digital Experience Monitoring) — 사용자 경험 자체를 측정.

약점

메시 VPN이 아니다. 노드 ↔ 노드 모델이 아니라 “모든 게 Cloudflare를 거친다”.
Cloudflare에 모든 trust를 둔다. 메타데이터·DNS·트래픽 패턴이 CF에 보인다.
벤더 락인의 끝판왕. Workers, R2, KV까지 들어가면 빠져나오기 어렵다.

누가 고르는가

이미 Cloudflare를 CDN/WAF로 쓰는 회사 — 자연스러운 확장.
분산된 글로벌 인력 (시차 큰 지점들).
“SASE 한 벤더로 다 끝내고 싶다”는 엔터프라이즈.

12장 · 그 외 옵션 — Innernet, Yggdrasil, 그리고 더

Innernet (Tonari)

일본 도쿄의 회사 Tonari가 만든 단순한 WireGuard 메시 도구. 오픈소스. “Tailscale은 너무 많고, wg-quick은 너무 적다”의 중간을 노렸다.

서버 한 대가 곧 컨트롤러. 노드 추가는 초대 토큰으로.
CIDR 트리 구조의 ACL — 네트워크/CIDR로 권한 표현.
DERP 없음. NAT 트래버설은 기본기만.
소규모 분산 팀에서 “Tailscale을 셀프호스팅하는 가벼운 대안”으로 사용.

Yggdrasil

전 세계 사람들이 자기들끼리 라우팅하는 메시 IPv6 네트워크. 학술/실험 프로젝트 같지만 실제로 동작한다.

각 노드가 ed25519 키 쌍 → 그 키에서 결정적으로 IPv6 주소를 만든다.
노드들은 “피어”로 연결하면 자동으로 글로벌 라우팅 트리에 합류.
회사가 운영하지 않는다. 진짜 P2P 메시.

용도:

“인터넷이 망가져도 우리끼리 라우팅 가능한 백업 네트워크”
학술 실험
IPv6 mesh의 정치적 신념을 가진 사람들

엔터프라이즈에 적합하지 않다. 컨트롤·SLA·감사 같은 개념 자체가 없다.

그 외 흘려 듣지 마라

Tinc — 1998년부터 있는 P2P VPN. WireGuard 이전 세대지만 여전히 일부 사용.
OpenZiti — “애플리케이션 임베디드 zero trust” 컨셉. SDK로 앱 안에 직접 짜 넣음.
Boundary (HashiCorp) — “사용자 → DB/서버”의 세션 브로커. 메시 VPN과는 다른 결.
GoodAccess, Perimeter 81 (지금은 Check Point) — 엔터프라이즈 SaaS VPN, 비미국 마켓 중심.

13장 · ACL / MagicDNS / exit node / subnet router — 운영 패턴

기능 이름은 알겠다. 그래서 실전에서 어떻게 쓰는지 패턴 위주로 짚자. Tailscale ACL 문법으로 예시를 들지만 NetBird·Headscale도 사실상 동일한 개념을 갖는다.

ACL — 진짜 zero-trust의 형태

{
  "groups": {
    "group:eng":   ["alice@example.com", "bob@example.com"],
    "group:ops":   ["carol@example.com"]
  },
  "tagOwners": {
    "tag:prod-db":  ["group:ops"],
    "tag:staging":  ["group:eng"]
  },
  "acls": [
    { "action": "accept", "src": ["group:eng"],
      "dst": ["tag:staging:22,80,443"] },
    { "action": "accept", "src": ["group:ops"],
      "dst": ["tag:prod-db:5432"] }
  ],
  "ssh": [
    { "action": "check", "src": ["group:eng"],
      "dst": ["tag:staging"], "users": ["root", "ubuntu"] }
  ]
}

핵심 원칙:

사용자가 아니라 그룹·태그로 표현. 이직/입사 시 그룹 멤버십만 갱신.
포트 단위까지 좁힌다. “staging의 80/443/22만” 같은 식.
기본 거부. 명시적으로 허용 안 한 건 모두 거부.
머신은 사람이 아니다. 머신에는 tag (예: tag:prod-db), 사람에는 그룹.

MagicDNS — 이름이 곧 IP

tailscale up 후에 ssh laptop이 그냥 된다. 노드가 등록될 때 받은 이름이 100.x.x.x로 자동 해석된다. 짧은 이름은 같은 tailnet 내에서만, 풀 이름은 laptop.tail1234.ts.net.

운영적으로 의미 있는 것:

/etc/hosts나 DNS 분산 관리 불필요.
Headscale·NetBird도 동일 기능을 (다른 도메인으로) 제공.
MagicDNS는 ACL의 가독성을 폭발적으로 끌어올린다. IP가 아니라 이름으로 정책 쓸 수 있음.

Exit Node — 메시 안의 “기본 게이트웨이”

# 특정 노드를 exit node로 선언
sudo tailscale up --advertise-exit-node

# 클라이언트에서 그 노드를 출구로 사용
tailscale set --exit-node=my-exit

용도:

카페 WiFi 차단망 우회 — 회사 메시의 한 노드를 통해 인터넷 접속.
지오펜싱 우회 — 다른 나라에 노드가 있으면 그 나라처럼 보임.
Mullvad exit (Tailscale) — 38개국 출구.
SaaS의 IP 허용 목록 작성 단순화 — exit 노드 한 개의 IP만 등록.

Subnet Router — 메시가 닿지 않는 곳까지

# 사내 192.168.10.0/24를 메시에 노출
sudo tailscale up --advertise-routes=192.168.10.0/24
# 관리자가 어드민 UI에서 라우트를 승인

용도:

레거시 장비 (메시 클라이언트를 깔 수 없는 NAS, 프린터, IPMI)
클라우드 VPC — VPC 안의 EC2 한 대를 subnet router로 만들면 VPC 전체가 메시에서 보임.
사이트투사이트 VPN의 사실상 대체.

High Availability Subnet Router

여러 노드가 같은 서브넷을 광고하면, Tailscale은 자동으로 failover. 라우터 한 대가 죽어도 끊기지 않는다.

14장 · 한국·일본 도입 — 토스, 라인, 메르카리

한·일 시장의 zero-trust / 오버레이 VPN 도입은 빠르게 진행됐다. 몇 가지 공개된 사례.

토스 (Viva Republica)

토스는 “inner network”라는 이름으로 내부 zero-trust 모델을 운영한다. 핵심 요소:

사용자 노트북 → 사내 리소스 접근에 디바이스 인증서 + SSO가 필수.
사이트투사이트 VPN을 줄이고 사용자 단위 ACL 모델로 전환.
사내 발표(2024–2025)에서 “VPN 게이트웨이의 폐기 / 메시 모델로의 이행”을 여러 차례 언급.
자체 빌드와 상용 솔루션의 하이브리드.

핵심 교훈:

“VPN을 자르고 zero-trust로 가자”는 정책 의사결정이 먼저.
그 후 단계적 마이그레이션(특정 리소스 → 특정 부서 → 전사).
보통 1~2년이 걸린다.

라인 (LINE)

LINE의 SRE/네트워크 팀은 글로벌 분산(일본·한국·태국·인도네시아·대만)이라는 특수성 때문에 일찍부터 자체 메시 / zero-trust 모델을 운영해 왔다.

오픈소스 컴포넌트 + 자체 컨트롤 평면 조합.
도쿄 본사 직원이 자카르타 데이터센터에 접근하는 시나리오에서 지리적으로 가장 가까운 PoP를 자동 선택.
사내 발표에서 “OpenVPN 게이트웨이 정리 + zero-trust 우산” 이야기를 정기적으로 한다.

메르카리 (Mercari)

도쿄의 메르카리는 “전사 마이크로서비스 + 글로벌 인력”의 모델 — 이런 회사는 zero-trust 도입 부담이 가장 큰 곳 중 하나다.

Cloudflare Access + 자체 정책 엔진의 조합으로 사내 도구 게이팅.
“VPN을 거치지 않고 사내 도구에 직접” 방향성을 사내 블로그에서 여러 차례 공개.
일본 기업 중에서는 zero-trust 도입의 선구자로 자주 인용된다.

한국·일본 시장의 공통 패턴

개인 노트북의 회사 메시 진입은 보통 SSO + 디바이스 인증서.
사내 사이트투사이트 VPN은 줄어드는 중. Tailscale subnet router나 ZTNA connector로 대체.
금융권은 데이터 주권 우려로 셀프호스팅(Headscale, NetBird, 자체 구축) 선호.
모바일 게임/엔터테인먼트는 Cloudflare Zero Trust 채택률이 높다.
스타트업은 Tailscale 무료/Starter 티어부터 시작.

15장 · 누가 무엇을 골라야 하나 — 시나리오별 결정 트리

마지막으로 카탈로그를 짧은 “결정” 형식으로 압축한다.

개인 / 홈랩

Tailscale Free. 끝. 3명 / 100 기기까지 무료, 모든 기능. Mullvad exit이 필요하면 가장 싼 유료 티어 + Mullvad 추가. 셀프호스팅 욕심이 있으면 Headscale로 옮긴다.

피해야 할 것: 2026년에 “심심해서 OpenVPN을 처음 세팅”하는 것.

1–10명 스타트업

Tailscale Starter 또는 NetBird Cloud. SSO가 필요하면 위쪽. 가격에 민감하면 NetBird.

SMB (10–200명)

세 가지 길:

Tailscale Premium / Enterprise — 가장 빠른 도입.
NetBird (self-host) — 셀프호스팅이 요구되거나 가격을 깎고 싶을 때.
Cloudflare Zero Trust — 이미 CF 고객이거나 SASE 한 우산을 원할 때.

엔터프라이즈 (200명+)

거의 항상 두 개의 제품을 조합하게 된다.

사용자 → 사내 리소스 / SaaS: Cloudflare Zero Trust 또는 Twingate.
서버 ↔ 서버 인프라 메시: Tailscale Enterprise, Headscale, 또는 Nebula/Defined Networking.
노트북에 들어가는 클라이언트가 하나면 좋다 — 그래서 한 벤더로 통일하기도 한다.

규제 산업 (금융·정부·의료)

Headscale 또는 NetBird 셀프호스팅 + 자체 DERP. 데이터·메타데이터 모두 자국 내. 컨트롤 평면 침해 시 영향 범위 통제 가능.

대규모 서버 인프라 메시 (수만 노드)

Nebula 또는 Defined Networking. PKI 기반의 분산 신뢰 모델이 컨트롤 평면 의존을 줄인다.

글로벌 분산 인력 (수십개 PoP)

Cloudflare Zero Trust 또는 Tailscale + 자체 운영 DERP. PoP 근접성이 사용자 경험의 큰 비중.

인터넷 단절 환경 (선박, 광산, 원격지)

Headscale + 자체 DERP 또는 Nebula. 외부 컨트롤 평면 의존 제로.

Layer 2 시맨틱이 정말로 필요

ZeroTier. 거의 유일한 합리적 선택.

정치적·실험적 메시

Yggdrasil. 또는 Hyphanet 같은 동급의 P2P 네트워크.

마무리 — “VPN”이라는 단어는 곧 더 이상 안 쓸지도

2026년에 우리는 “VPN을 도입한다”는 말을 점점 적게 한다. 대신 “zero-trust 네트워크”, “오버레이 메시”, “디바이스 신원” 같은 말을 쓴다.

기술적으로 보면 거의 같은 일이다 — 노드들 사이의 암호화 터널이다. 다른 건 모델이다:

옛날: “경계 안에 들어가면 다 본다”
지금: “신원·디바이스·맥락마다 매번 평가, 리소스 단위 권한”

이 모델 변화의 데이터 평면은 WireGuard가 거의 가져갔다. 컨트롤 평면과 UX는 Tailscale이 정의했다. 그 사이의 빈 칸 — 셀프호스팅, SSO 통합, 엔터프라이즈 정책 — 을 Headscale, NetBird, Twingate, Cloudflare Zero Trust, Nebula, Defined Networking 같은 회사들이 채우고 있다.

당신이 다음에 “집에서 회사 서버에 ssh 한 번 하고 싶다”의 답을 누군가에게 줄 때, 그 답이 OpenVPN이라면 이미 늦은 것이다. 적어도 Tailscale 한 번 설치해 보고 ssh 한 번 쳐 보길. 5분 후 “세상이 이렇게 단순해질 수 있구나”의 순간이 온다.

그게 2026년 오버레이 VPN의 약속이다.

참고 / References

WireGuard: https://www.wireguard.com/
Tailscale: https://tailscale.com/
Tailscale Funnel: https://tailscale.com/kb/1223/funnel
Tailscale Mullvad: https://tailscale.com/kb/1258/mullvad-exit-nodes
DERP (Tailscale): https://tailscale.com/kb/1232/derp-servers
Headscale: https://github.com/juanfont/headscale
ZeroTier: https://www.zerotier.com/
Nebula (Slack): https://github.com/slackhq/nebula
Defined Networking: https://www.defined.net/
NetBird: https://netbird.io/
NetBird (GitHub): https://github.com/netbirdio/netbird
Twingate: https://www.twingate.com/
Cloudflare Zero Trust: https://www.cloudflare.com/zero-trust/
Cloudflare WARP: https://1.1.1.1/
Cloudflare Tunnel: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/
Innernet (Tonari): https://github.com/tonarino/innernet
Yggdrasil Network: https://yggdrasil-network.github.io/
BeyondCorp (Google): https://cloud.google.com/beyondcorp
NIST SP 800-207 Zero Trust Architecture: https://csrc.nist.gov/publications/detail/sp/800-207/final
LINE Engineering: https://engineering.linecorp.com/en
Mercari Engineering: https://engineering.mercari.com/en/
토스 기술 블로그: https://toss.tech/

프롤로그 — “집 컴퓨터에 ssh 좀 하고 싶어요”에서 시작된 시장

1장 · 2026년 오버레이 VPN 지도 — 세 진영

한 줄 요약

2장 · NAT 트래버설 — STUN / TURN / DERP / 홀펀칭 기초

NAT의 종류와 친절함

STUN / TURN / DERP

홀펀칭의 동작

3장 · WireGuard — 모든 것의 기반

WireGuard가 단순한 이유

WireGuard가 해결하지 않는 것

wg-quick만으로 충분한 경우

4장 · Tailscale — 사실상 표준

Tailscale = WireGuard + 코디네이션 서비스

핵심 기능 (2026년)

Tailscale Funnel — “localhost를 인터넷에 띄우기”

Mullvad 파트너십 — 두 가지 VPN의 결혼

가격과 무료 티어

약점

5장 · Headscale — Tailscale 셀프호스팅

무엇이 같고 무엇이 다른가

구축

누가 Headscale을 골라야 하나

약점

6장 · ZeroTier — WireGuard 이전 시대의 챔피언

모델

2026년에 ZeroTier가 여전히 의미 있는 경우

약점 (Tailscale 시대 기준)

7장 · Nebula (Slack 오픈소스) — 다른 신뢰 모델

핵심 아이디어 — PKI

Tailscale vs Nebula 비교

lighthouse — 디스커버리

어디서 빛나는가

약점

8장 · Defined Networking — 상용 Nebula

9장 · NetBird (오픈소스) — Tailscale + SSO

핵심 차이

NetBird vs Tailscale vs Headscale

누가 NetBird를 골라야 하나

약점

10장 · Twingate — Zero Trust 엔터프라이즈

모델 차이

Twingate의 구성요소

강점

약점

누가 고르는가

11장 · Cloudflare WARP / Zero Trust — 소비자 + 엔터프라이즈

WARP — 무료 소비자 VPN-ish

Cloudflare Zero Trust — 엔터프라이즈 ZTNA

강점

약점

누가 고르는가

12장 · 그 외 옵션 — Innernet, Yggdrasil, 그리고 더

Innernet (Tonari)

Yggdrasil

그 외 흘려 듣지 마라

13장 · ACL / MagicDNS / exit node / subnet router — 운영 패턴

ACL — 진짜 zero-trust의 형태

MagicDNS — 이름이 곧 IP

Exit Node — 메시 안의 “기본 게이트웨이”

Subnet Router — 메시가 닿지 않는 곳까지

High Availability Subnet Router

14장 · 한국·일본 도입 — 토스, 라인, 메르카리

토스 (Viva Republica)

라인 (LINE)

메르카리 (Mercari)

한국·일본 시장의 공통 패턴

15장 · 누가 무엇을 골라야 하나 — 시나리오별 결정 트리

개인 / 홈랩

1–10명 스타트업

SMB (10–200명)

엔터프라이즈 (200명+)

규제 산업 (금융·정부·의료)

대규모 서버 인프라 메시 (수만 노드)

글로벌 분산 인력 (수십개 PoP)

인터넷 단절 환경 (선박, 광산, 원격지)

Layer 2 시맨틱이 정말로 필요

정치적·실험적 메시

마무리 — “VPN”이라는 단어는 곧 더 이상 안 쓸지도

참고 / References

`wg-quick`만으로 충분한 경우