# Tailscale Peer Relays: 자체 장치를 고속 릴레이로 활용 > Clean Markdown view of GeekNews topic #26814. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26814](https://news.hada.io/topic?id=26814) - GeekNews Markdown: [https://news.hada.io/topic/26814.md](https://news.hada.io/topic/26814.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-19T21:33:17+09:00 - Updated: 2026-02-19T21:33:17+09:00 - Original source: [tailscale.com](https://tailscale.com/blog/peer-relays-ga) - Points: 2 - Comments: 1 ## Topic Body - **Tailscale Peer Relays**가 정식 출시되어, 사용자가 자신의 장치를 **고성능 릴레이 노드**로 활용할 수 있게 됨 - 방화벽, NAT, 클라우드 네트워크 제약 등으로 직접 연결이 어려운 환경에서도 **안정적이고 빠른 트래픽 중계**를 지원 - **스루풋 향상**과 **락 경합 개선**, **UDP 소켓 분산 처리**로 다수 클라이언트 연결 시 성능이 크게 개선됨 - **정적 엔드포인트 통합**을 통해 자동 탐색이 불가능한 클라우드 환경에서도 **AWS NLB 등 뒤에서 릴레이 운영 가능** - **가시성·모니터링 통합**으로 트래픽 경로, 지연, 릴레이 상태를 명확히 파악할 수 있어 대규모 네트워크 운영에 중요함 --- ### Tailscale Peer Relays 개요 - Peer Relays는 **고성능 릴레이 기능을 자체 장치에서 실행**할 수 있게 하는 기능 - 기존 DERP 릴레이에 더해, 사용자가 직접 배포한 노드를 릴레이로 활용 가능 - 베타 이후 **성능, 안정성, 가시성**이 크게 개선되어 프로덕션 수준으로 발전 - **복잡한 NAT 환경**을 우회하기 위한 기능에서 출발해, **대규모 네트워크 연결 옵션**으로 확장됨 - 팀 단위로 **성능·제어·유연성**을 확보할 수 있는 구조 제공 ### 성능 및 신뢰성 개선 - 다수의 클라이언트가 릴레이를 통해 연결될 때 **스루풋이 크게 향상**됨 - 클라이언트는 릴레이 내에서 **가장 적합한 인터페이스와 주소 패밀리**를 자동 선택 - 릴레이는 **락 경합 감소**와 **멀티 UDP 소켓 분산 처리**로 패킷 처리 효율 향상 - 이러한 개선으로 **일상적인 트래픽에서도 성능과 안정성**이 향상되며, 직접 연결이 불가능한 경우에도 **메시 네트워크에 가까운 성능**을 제공 ### 정적 엔드포인트 지원 - **공용 클라우드 환경**에서는 자동 엔드포인트 탐색이 어려운 경우가 많음 - 방화벽 규칙, 포트 포워딩, 로드 밸런서 등으로 인해 임의 포트 개방이 불가능한 경우 존재 - Peer Relays는 `--relay-server-static-endpoints` 플래그를 통해 **고정 IP:포트 쌍을 광고**할 수 있음 - AWS Network Load Balancer 등 인프라 뒤에서도 외부 클라이언트가 릴레이를 통해 트래픽을 전달 가능 - 이 기능으로 **제한된 클라우드 환경에서도 고속 연결**을 확보할 수 있으며, **서브넷 라우터를 대체**해 **풀 메시 구성**이 가능 ### 가시성 및 모니터링 통합 - Peer Relays는 **Tailscale의 관찰 도구와 직접 통합**되어 릴레이 동작을 명확히 파악 가능 - `tailscale ping` 명령으로 릴레이 사용 여부, 도달 가능성, 지연 및 신뢰성 영향 확인 가능 - 문제 발생 시 트래픽이 릴레이를 거치는지, 릴레이 상태가 정상인지 즉시 판단 가능 - **모니터링 지표**로 `tailscaled_peer_relay_forwarded_packets_total`, `tailscaled_peer_relay_forwarded_bytes_total`을 제공 - Prometheus, Grafana 등과 연동해 **트래픽 패턴 분석, 이상 탐지, 네트워크 상태 모니터링** 가능 ### 일반 제공 및 배포 방식 - 정식 출시된 Peer Relays는 **Tailscale 확장성의 핵심 구성요소**로 자리함 - 직접 경로가 불가능할 때 **고속·저지연 연결** 제공 - **정적 엔드포인트 기반 배포**로 제한된 클라우드 환경에서도 동작 - **사설 서브넷 내 풀 메시 구성**과 **입출구 제어 경로 설정** 지원 - **엔드 투 엔드 암호화**, **최소 권한 접근**, **예측 가능한 동작** 등 Tailscale의 기본 보안 원칙 유지 - CLI를 통해 모든 지원 노드에서 활성화 가능하며, **ACL 기반 제어 및 점진적 배포** 지원 - Peer Relays는 **모든 요금제(무료 Personal 플랜 포함)** 에서 사용 가능 ## Comments ### Comment 51421 - Author: neo - Created: 2026-02-19T21:33:18+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47063005) - Tailscale이 “열려 있다(open)”는 이유로 신뢰받는다면, 동시에 일부 **클라이언트가 폐쇄형**이라는 점도 알아야 함 공식 배포 채널(예: Apple App Store)을 통해서만 배포되고, 완전히 그들의 통제 아래 있음 이런 입장을 정당화하는 논리가 황당한데, “사용자가 비공개 OS를 쓰는 게 괜찮다면 Tailscale도 비공개여도 괜찮다”는 식임 이런 구조는 **연결성 제한 환경**에서는 신뢰하기 어려움 기술적으로 경쟁사보다 낫더라도 결국 **비즈니스**일 뿐임. 가능하다면 자유 소프트웨어 대안을 지원해야 함 [관련 GitHub 이슈](https://github.com/tailscale/tailscale/issues/13717) - 일부 플랫폼에서 **GUI만 비공개**임을 명확히 하고 싶음 (Tailscalar) - 나는 성능보다 **통제권(control)** 을 더 중요하게 여김 사용자가 소스에서 직접 빌드할 수 있다면 성능 개선도 가능하지만, 통제권이 없으면 불만족스러운 부분을 고칠 방법이 없음 상용 소프트웨어는 종종 품질이 낮고, 업데이트 의존적이며, 완성도보다 출시 속도를 우선시함 - macOS용 CLI 클라이언트는 소스에서 직접 빌드 가능함 `go install tailscale.com/cmd/tailscale{,d}@latest` 명령으로 설치할 수 있고, [공식 위키](https://github.com/tailscale/tailscale/wiki/Tailscaled-on-macOS)에 설명되어 있음 GUI는 폐쇄형이지만 CLI는 완전 개방되어 있어 제한된 네트워크 환경에서도 사용 가능함 - 대부분의 Mac 앱이 폐쇄형이라, Tailscale 메뉴바 아이콘 하나쯤은 신경 쓰이지 않음 정말 불편하다면 **brew**나 CLI로 제어하면 됨 - 오픈소스와 상용의 **하이브리드 모델**이 현실적인 절충안이라 생각함 나도 비슷한 구조의 앱을 개발 중인데, CLI는 완전 오픈소스로 제공하고 GUI는 유료로 판매할 예정임 이렇게 해서 개발을 지속하고 생계를 유지할 수 있음 [validate 라이브러리](https://github.com/pmarreck/validate)를 기반으로 GUI와 CLI를 함께 개발 중임 - 최근 Tailscale을 설정했는데, **핑이 16ms에서 10ms로 감소**하고 대역폭이 세 배로 늘어남 Moonlight/Sunshine과 함께 사용하니 MacBook에서 Linux 데스크톱으로 Windows 게임을 50Mbps/10ms로 스트리밍 가능함 포트 포워딩 없이 라우터를 피어 노드로만 설정했음 - Sunshine 관련해서는 [Apollo](https://github.com/ClassicOldSong/Apollo)를 시도해볼 만함 - 흥미로운 사용 사례지만, 사실상 NAT 트래버설과 포트 포워딩을 자동화된 프로토콜에 **위임**한 것임 - 게임 스트리밍을 일반 사용자에게 공개하려면 상대방도 Tailscale을 설치해야 하는지 궁금함 Tailscale은 기본적으로 **신뢰할 수 있는 사용자 간 공유**에 초점이 맞춰져 있는지 알고 싶음 - OpenWRT 라우터로 비슷한 구성을 시도했는데, 여전히 포트를 열어야 하는 줄 알았음 그렇다면 여전히 인터넷에 노출되는 것 아닌가 혼란스러움 - Tailscale의 **수익 모델**이 궁금함. 서비스는 마음에 들지만 장기 지속 가능성이 걱정됨 가끔 **속도 제한(rate limit)** 이 걸리는 느낌도 있음 - 우리 회사는 월 18달러/사용자 요금의 **비즈니스 플랜**을 사용 중임 팀 규모가 커지면 유료 플랜이 필수이고, serve/funnel, SSH 같은 기능이 유용함 예전에는 Zerotier를 썼는데, 몇 년간 무료로 사용하다가 사용자 수가 늘면서 월 5달러 정도만 냈음 - 원래 Tailscale은 초기 연결 후 **P2P WireGuard 연결**을 맺기 때문에 속도 제한이 없어야 함 다만 네트워크 환경에 따라 중계(relay)가 필요할 수 있음 오픈소스 대안으로는 [Headscale](https://github.com/juanfont/headscale)과 [Netbird](https://netbird.io/)가 있음 - [공식 블로그의 무료 플랜 설명](https://tailscale.com/blog/free-plan)을 참고할 만함 - 개발자 무료 플랜으로 인기를 얻고, 이후 기업이 유료 플랜으로 전환하는 **프리미엄 모델**의 전형적인 사례임 - P2P 연결은 비용이 거의 들지 않기 때문에, **무료 티어로 개발자 충성도**를 높이는 전략이 효과적임 - **Peer Relay**로 전환된 것은 NAT 환경의 셀프호스터에게 큰 승리임 직접 DERP 서버를 설정할 필요가 없어 UX가 개선됨 - (Tailscale 직원 Alex) 우리도 같은 문제를 겪었음 Peer Relay는 기존 **subnet router와 exit node 인프라**를 재활용해 구현 부담이 크지 않았음 AWS 같은 제한적 NAT 환경에서도 안정적인 연결을 위해 필수적임 결과적으로 **지연 시간과 사용자 경험** 모두 개선됨 - 중앙 DERP가 트래픽을 블랙홀처럼 삼키는 문제가 있었는데, 최근에는 안정적임 Peer Relay 도입으로 이런 문제 가능성이 더 줄어들 것 같음 - Peer Relay가 **UDP를 지원**하는 점이 핵심임 DERP는 TCP 기반이라 게임 스트리밍이나 음성 통신에서 **지연(latency)** 문제가 있었음 Peer Relay는 UDP를 사용하므로 실시간 트래픽에 훨씬 적합함 별도의 DERP 인스턴스를 설정하지 않아도 기존 서브넷 라우터에서 바로 활성화 가능함 - 하지만 새 계정에서 긍정적인 댓글이 연속으로 달리고, 일부는 Tailscale 직원이 응답한 걸 보면 **AI 기반 홍보(PR)** 같아 보임 이런 식의 AI 댓글은 커뮤니티 신뢰를 해치므로 자제해야 함 - 여러 개의 Relay가 있을 때, Tailscale이 자동으로 **가장 낮은 지연의 노드**를 선택하는지 궁금함 - 실제 **CGNAT 환경**에서 Tailscale이 큰 도움이 되었음 Google Cloud Run에서 AI 비전 시스템을 돌리는데, ISP가 포트 포워딩을 막고 있었음 Tailscale을 통해 Cloud Run 컨테이너와 카메라가 같은 LAN처럼 통신 가능해짐 Peer Relay 덕분에 컨테이너가 자주 재시작될 때 생기던 **지연 문제**도 줄어들 것으로 기대됨 다만, **에페메럴(임시) 노드** 환경에서 Relay 선택이 어떻게 동작하는지 궁금함 - 나는 기존에 직접 구성한 WireGuard 네트워크를 쓰고 있는데, Tailscale이 내부적으로 뭘 하는지 궁금함 DNS, 라우팅, 방화벽 등을 자동으로 조정하는 “**매직**” 기능이 많아 불안함 [공식 문서](https://tailscale.com/docs/concepts)를 봤지만 세부 내용이 부족함 복잡한 네트워크 설정에서도 잘 작동하는지 알고 싶음 - (Tailscale 직원) 완벽한 문서를 유지하기 어렵지만, 가능한 한 **환경 적응형 휴리스틱**을 문서화하려고 함 Linux에서는 다양한 설정 패턴이 존재해 복잡함 [관련 블로그 글](https://tailscale.com/blog/sisyphean-dns-client-linux)에서도 설명함 주요 동작은 다음과 같음 - **규칙 기반 라우팅**으로 충돌 방지 - systemd-resolved를 우선 통합, 없으면 `/etc/resolv.conf` 수정 - iptables와 nftables 모두 지원하며, ufw/firewalld와 호환되도록 구성 - SSH 로그인은 배포판별 차이를 고려해 최대한 호환성 있게 구현 - 안정적 통신을 위해 1360바이트 MTU 경로 필요 매우 커스텀한 환경에서는 문제가 생길 수도 있지만, 지원을 통해 해결 가능함 - 클라이언트는 오픈소스이며, 일부 직원이 **Headscale** 같은 리버스엔지니어링 서버에도 기여함 - [Headscale](https://github.com/juanfont/headscale)은 오픈소스 대안으로 참고할 만함 - 모바일에서 페이지를 열었는데 닫기 버튼이 보이지 않아 **모달을 닫을 수 없었음** [스크린샷](https://i.postimg.cc/14h3Q9mD/Screenshot-20260219-001356-Chrome-Canary.jpg) 참고 나중에 찾긴 했지만 위치가 이상했음 - 모달 오른쪽 아래 파란 상자 안의 흰색 X 버튼이 닫기 버튼임