Tailscale 가격 분석: 홈랩·소규모 비즈니스 비용 전략

Tailscale 가격을 볼 때 가장 많이 헷갈리는 지점은 하나더라고요. 핵심은 “기기 수가 많으면 비싸지는가”가 아니라, “누가 seat를 점유하고 어떤 인프라를 tagged resource로 운영하느냐”입니다. 홈랩에선 거의 무료처럼 느껴지지만, 팀 계정·서브넷 라우터·exit node·CI 러너가 붙는 순간 계산 기준이 확 달라집니다. 이 글은 2026년 8월 28일 기준 Tailscale 공식 가격 페이지와 공식 문서를 바탕으로, 실제 설계할 때 먼저 보는 비용 포인트만 골라 다시 정리한 내용입니다.

제 기준은 단순합니다. 사람 비용은 seat, 인프라 비용은 tagged resource, 변동성 비용은 ephemeral minutes로 나눠서 보는 거예요. 이렇게 분리하면 플랜 선택이 꽤 선명해집니다. 반대로 한데 섞어 보면 “무료로 되겠지” 하고 시작했다가 월말에 권한 설계와 청구 기준이 같이 꼬이기 쉽습니다. 특히 소규모 비즈니스 VPN은 구독료보다 권한 설계 실수와 seat 정리 실패가 더 비싸게 돌아오는 경우가 많습니다.

홈랩 장비, 사용자 좌석(seat), tagged resources, exit node 구성을 한 장으로 요약한 개요 이미지입니다.

Tailscale 가격 구조, 실제 청구 기준으로 보면 이렇게 읽힙니다

현재 공식 요금제 기준으로 신규 가입 tailnet은 seat-based pricing을 따릅니다. 사용자 노트북이나 폰이 여러 대여도, 그 사람은 보통 seat 하나를 점유합니다. 반대로 서버, 서브넷 라우터, app connector, exit node처럼 사람이 아니라 tag가 소유하는 장비는 tagged resource로 계산합니다. 다만 여기서 한 가지는 꼭 짚고 가야 합니다. 일부 기존 legacy tailnet은 예전 월간 활성 사용자 방식이 남아 있을 수 있어서, 이미 오래 운영 중인 계정이라면 현재 플랜 체계를 먼저 확인하는 편이 안전합니다.

실무에서 특히 중요한 건 seat가 실제로 tailnet에 참여한 사용자 기준으로 소비된다는 점입니다. 초대만 해둔 사용자는 seat를 점유하지 않고, 처음 로그인하거나 처음 장비를 붙일 때 seat를 차지합니다. 공식 FAQ 기준으로 seat는 재사용 가능하지만, 월중에 seat를 줄여도 그달 비용이 바로 내려가지는 않습니다. 반대로 seat를 추가하면 일할 계산이 붙습니다. 이 부분, 월말 정산 때 꽤 체감되더라고요.

• User device: 사람 계정에 귀속된 노트북, 폰, 워크스테이션 같은 일반 단말입니다. 수량 자체는 과금 기준이 아닙니다.
• Seat: tailnet에 참여한 사용자가 차지하는 청구 단위입니다. 비용 최적화의 첫 번째 축입니다.
• Tagged resource: tag가 소유하는 서버, subnet router, exit node, app connector 같은 공유 인프라입니다. 기본 50개가 포함되고, 추가분은 개당 월 1달러입니다.
• Ephemeral resource: 짧게 뜨고 사라지는 CI/CD 러너, 쿠버네티스 워크로드 같은 장비입니다. 분 단위 풀을 쓰고, tailnet에 4시간 이상 남아 있으면 일반 tagged resource로 계산됩니다.

Tailscale 가격 비교: 플랜표만 보면 놓치기 쉬운 판단 포인트

플랜표에서 진짜 중요한 건 가격표 숫자보다 무료 한계가 어디서 실무 한계로 바뀌느냐입니다. Personal은 최대 6명까지 무료이고 tagged resource 50개도 포함이라 홈랩 기준으로 꽤 넉넉합니다. 그런데 작은 회사 프로젝트에 그대로 가져가면 얘기가 달라집니다. 공식 문서 기준으로 Personal은 commercial use를 전제로 한 플랜이 아니기 때문입니다. 성능보다 소유권과 운영 정책에서 먼저 막히는 셈이죠.

또 하나, tagged resource 50개 포함은 넉넉해 보여도 소규모 비즈니스에선 금방 닿을 수 있습니다. 사무실 subnet router, 재택 근무용 exit node, NAS, 백업 서버, staging VM, 모니터링 박스, app connector, 고정 러너 노드를 분리해 두면 생각보다 빨리 늘어납니다. 사람 수보다 인프라 역할 수가 더 빨리 커지는 팀이라면 seat보다 tag 구조를 먼저 계산하는 편이 맞습니다. 이 차이를 놓치면 Tailscale 비용이 예상보다 빨리 불어나더라고요.

홈랩 VPN에서 Tailscale 비용 줄이는 방법

홈랩은 대체로 Personal 플랜에서 오래 버틸 수 있습니다. 그렇다고 아무렇게나 써도 된다는 뜻은 아니에요. 오히려 무료를 오래 유지하려면 사람 계정은 최소화하고, 공유 인프라는 역할이 겹치지 않게 묶고, 태그는 접근 제어 때문에 꼭 필요할 때만 늘리는 편이 좋습니다. 이거 생각보다 차이가 큽니다.

홈랩에서 먼저 줄여야 할 건 tagged resource의 과도한 분해입니다. NAS, Proxmox 호스트, 리버스 프록시, 미디어 서버, 백업 서버를 전부 다른 태그와 정책으로 잘게 나누면 처음엔 있어 보입니다. 그런데 운영이 길어질수록 관리 포인트만 늘어나더라고요. 홈랩에선 복잡한 보안 모델보다, 나중에 내가 이해할 수 있는 구조가 더 중요할 때가 많습니다.

• 개인 사용자 1~3명 중심이면 Personal 유지가 보통 맞습니다.
• 공유 인프라는 tag 하나로 시작하고, ACL 분리가 실제로 필요할 때만 세분화하는 편이 낫습니다.
• 서브넷 라우터는 대역 전체를 무심코 광고하지 말고, 필요한 세그먼트만 내보내는 편이 안전합니다.
• exit node는 1대 대표 노드로 먼저 검증하고, 가용성이나 지역 분산 요구가 생길 때 늘리는 편이 비용과 운영 모두 안정적입니다.

예를 들어 사용자 2명, 노트북 3대, 모바일 2대, NAS 1대, 미니 PC 1대, subnet router 1대, exit node 1대 정도라면 Personal 안에서 충분히 정리되는 경우가 많습니다. 여기서 비용이 새기 시작하는 건 디바이스 수 자체가 아닙니다. 가족이나 지인을 정식 사용자로 계속 추가하거나, 서버 역할마다 태그를 쪼개서 공유 인프라 수를 불리는 순간부터 계산이 달라집니다.

무료 또는 저비용으로 유지하기 좋은 홈랩 구성 예시입니다. 사용자 수는 적게, 공유 인프라는 단순하게 가져가는 그림입니다.

소규모 비즈니스 VPN에서 Tailscale 가격, 언제 Standard가 맞을까요?

팀 운영은 기준이 다릅니다. 여기서는 무료냐 유료냐보다 누가 계정을 만들고, 누가 회수하고, 누가 승인하는가가 먼저예요. 구성원 수가 6명을 넘기기 시작하거나, 업무용 계정과 개인 계정을 섞어 쓰기 싫거나, 입사·퇴사 흐름을 IdP나 SCIM으로 묶고 싶다면 Personal을 오래 붙잡을 이유가 거의 없습니다. 이때부터 Standard는 단순한 비용 증가라기보다 운영 통제 비용을 선제적으로 지불하는 선택에 가깝습니다.

특히 Standard의 가치는 seat 가격 8달러 자체보다, 권한 구조를 사람 손으로 덜 만지게 해주는 점에 있습니다. 홈랩에서는 seat 하나가 사용자 1명으로 끝나지만, 팀 환경에서는 seat 하나가 곧 라이프사이클 관리 단위가 됩니다. 이게 정리되지 않으면 퇴사자 계정, 외주 계정, 테스트 계정이 tailnet 안에 남습니다. 청구서보다 보안 쪽이 먼저 문제 되기 쉽습니다.

실무에서 자주 던지는 질문은 딱 두 개입니다. “퇴사자 seat를 그날 바로 비울 수 있는가?”, “사고가 나면 누가 언제 어디에 붙었는지 남겨야 하는가?” 첫 번째에 예라고 답해야 하면 Standard, 두 번째에 예라고 답해야 하면 Premium 검토가 빨라집니다.

Tailscale 비용 최적화 구현: 최소 구성부터 확인해보겠습니다

비용 최적화는 대개 노드를 덜 사는 것보다 역할을 덜 쪼개는 것에서 시작합니다. 홈랩이든 작은 팀이든 먼저 대표 노드 1대로 subnet router와 exit node를 함께 맡길 수 있는지 확인해보세요. 되면 tagged resource 수, 승인 포인트, 장애 추적 포인트가 같이 줄어듭니다. 단순한 구성이 진짜 오래 갑니다.

여기서 중요한 건 정책 파일과 CLI를 같이 설계하는 겁니다. 태그를 붙이려면 tagOwners가 있어야 하고, subnet route나 exit node를 수동 승인 없이 운영하려면 autoApprovers가 필요합니다. 이걸 안 잡아두면 노드는 살아 있는데 승인 대기 상태로 남는 경우가 생깁니다. 처음엔 멀쩡해 보여도 나중에 꼭 한 번 발목을 잡더라고요.

{
  "tagOwners": {
    "tag:infra": ["group:netops"]
  },
  "groups": {
    "group:netops": ["[email protected]", "[email protected]"]
  },
  "autoApprovers": {
    "routes": {
      "192.168.10.0/24": ["tag:infra"]
    },
    "exitNode": ["tag:infra"]
  }
}

이 구성의 장점은 분명합니다. 사람 계정이 바뀌어도 tag가 승인 주체로 남기 때문에, 담당자 교체나 사용자 비활성화 때문에 route 광고가 갑자기 끊길 가능성을 줄일 수 있습니다. 공식 정책 문서도 이 시나리오에선 tag 기반 auto-approver를 고려하라고 안내합니다. 소규모 팀에서 특히 편하더라고요.

sudo tailscale up \
  --advertise-tags=tag:infra \
  --advertise-routes=192.168.10.0/24 \
  --advertise-exit-node \
  --accept-dns=false

명령 자체는 간단하지만, 해석 포인트는 세 가지입니다.

1. 태그를 먼저 설계하고 노드에 붙이세요. 태그는 단순 라벨이 아니라 그 노드의 정체성입니다.
2. 광고할 대역을 최소화하세요. 192.168.10.0/24처럼 필요한 CIDR만 지정하는 편이 낫습니다.
3. tailscale up은 이전 플래그를 기억하지 않는다고 보고 항상 전체 플래그를 다시 적는 습관이 안전합니다. 공식 CLI 문서도 실행할 때마다 필요한 플래그를 모두 지정하라고 안내합니다.

현장에서 많이 보는 실패 모드는 이겁니다. 처음엔 --advertise-tags만 넣고, 며칠 뒤엔 --advertise-routes만 넣는 식이죠. 운영자는 설정을 추가했다고 생각하지만, 실제로는 이전 의도를 빠뜨린 상태로 다시 올린 셈이 됩니다. 요즘 CLI가 경고를 주긴 하지만, 자동화 스크립트에선 여전히 전체 플래그를 명시하는 편이 더 안전합니다.

서브넷 라우터 설정이나 Tailscale SSH 운영이 궁금하시면 관련 글도 같이 보시면 흐름이 더 잘 잡힙니다.

tagged resource, advertised routes, exit node 승인 흐름을 이해하기 쉽게 보여주는 구성 이미지입니다.

검증과 결과 해석: Tailscale 비용 오판을 막는 체크 포인트

비용 최적화에서 검증이 중요한 이유는 단순합니다. 느리다고 해서 플랜 업그레이드가 답은 아니고, 노드를 더 만든다고 해서 경로가 좋아지는 것도 아니기 때문입니다. 먼저 direct 연결이 되는지, DERP relay에 오래 머무는지, NAT가 까다로운지부터 읽어야 합니다. 그래야 불필요한 exit node 추가나 tagged resource 증설을 막을 수 있습니다.

tailscale status

tailscale status --json

tailscale netcheck

tailscale ping nas

tailscale ping --tsmp nas

읽는 기준은 보통 이렇게 잡습니다.

• tailscale status: 공유 노드가 계속 비슷한 상태로만 남는다면, 실제로 쓰지 않는 tagged resource인지 먼저 확인합니다.
• status –json: 월말 점검은 사람 눈보다 자동화가 낫습니다. 온라인 여부나 피어 상태를 정리해 보면 안 쓰는 인프라가 드러납니다.
• netcheck: UDP: false면 direct 연결 기대치를 낮추고, 방화벽이나 사내망 정책부터 의심하는 편이 맞습니다.
• MappingVariesByDestIP: true면 hard NAT 가능성이 높습니다. 이 경우 플랜 문제가 아니라 네트워크 환경 문제일 가능성이 큽니다.
• PortMapping이 비어 있거나 false면 라우터가 포트 매핑을 못 도와주는 상태일 수 있습니다. 홈랩에선 이게 은근한 병목입니다.
• tailscale ping: 처음엔 DERP를 타다가 direct로 붙는 건 자연스러운 흐름입니다. 계속 DERP만 유지되면 NAT나 UDP 경로를 다시 봐야 합니다.
• tailscale ping –tsmp: OS의 ICMP 제약을 우회해서 Tailscale 경로 자체를 보기 좋습니다. 원인 분리에 꽤 유용합니다.

비용 관점에서 꼭 덧붙이고 싶은 해석이 하나 있습니다. DERP relay를 쓴다고 바로 Premium이 필요한 건 아닙니다. Premium은 로그와 통제 요구에 대한 답이지, NAT 문제를 요금제로 해결하는 플랜은 아닙니다. 연결이 느린데 곧장 플랜을 올리는 판단은 의외로 헛돈이 되기 쉽습니다.

direct 연결과 DERP relay 상태 차이를 한눈에 볼 수 있는 검증 결과 시각화입니다.

자주 겪는 함정과 트러블슈팅

여러 번 본 패턴을 압축하면, 문제는 기능 부족보다 정체성 관리가 섞일 때 생깁니다. 사람 장비에 태그를 붙여 사용자처럼 쓰려 하거나, 오래 살아 있는 서버를 ephemeral처럼 취급하거나, 상업용 tailnet을 무료 플랜 감각으로 운영하면 나중에 정리가 정말 어려워집니다. 초반엔 편해 보여도 뒤로 갈수록 비용과 운영이 같이 무거워집니다.

• 함정 1: 무료 플랜으로 업무용 운영을 길게 끌기. 근본 원인은 비용 절감이 아니라 계정 소유권과 상업적 사용 정책 정리를 미루는 데 있습니다.
• 함정 2: tagged resource를 서버 수만큼 잘게 쪼개기. 근본 원인은 보안 모델 과설계입니다. 태그 수가 늘면 ACL, autoApprovers, 운영 인수인계가 같이 복잡해집니다.
• 함정 3: ephemeral resource를 일반 서버처럼 오래 띄우기. 공식 문서 기준으로 4시간 이상 존재하면 일반 tagged resource로 계산됩니다.
• 함정 4: seat를 비우지 않고 사람만 교체하기. 근본 원인은 IdP deprovision 미흡입니다. seat 재사용은 가능하지만 계정 비활성화가 실제로 돌아가야 의미가 있습니다.
• 함정 5: route auto-approval 없이 subnet router를 여러 대 늘리기. 승인 절차를 콘솔 수작업에 의존하면 운영자 부재 시 라우팅 장애가 납니다.
• 함정 6: 사람 장비에 태그를 붙여 권한을 흉내 내기. 공식 문서 기준으로 태그를 적용하면 사용자 기반 인증이 제거됩니다. 태그는 사람용 메타데이터가 아니라 머신 정체성입니다.

월말 점검은 저는 꽤 기계적으로 합니다.

1. seat: 실제 로그인한 사용자 수와 현재 구매 seat 수가 맞는지 확인합니다.
2. tagged resource: 더 이상 쓰지 않는 subnet router, exit node, app connector, 고정 서버가 남아 있지 않은지 봅니다.
3. ephemeral usage: CI/CD나 쿠버네티스 워크로드가 4시간 이상 tailnet에 잔류하지 않는지 확인합니다.
4. relay 상태: direct로 바꿀 수 있는 연결인데 DERP에만 머무는 장비가 없는지 봅니다. 이건 비용보다 체감 품질 문제를 줄이는 데 효과적입니다.

FAQ: Tailscale 가격에서 많이 헷갈리는 포인트

Tailscale 비용은 기기 수가 많으면 바로 올라가나요?

보통은 아닙니다. 현재 공식 요금제 기준으로 핵심은 seat 수입니다. 다만 서버·subnet router·exit node처럼 tag가 붙은 공유 인프라는 tagged resource로 따로 관리해야 합니다.

홈랩 VPN 용도라면 무료 플랜으로 충분한가요?

대부분은 충분합니다. 사용자 6명 이내, 비상업용, tagged resource 50개 안쪽이면 Personal이 꽤 넉넉합니다. 다만 태그와 라우팅을 과하게 쪼개면 무료라도 운영 난도는 확 올라갑니다.

소규모 비즈니스 VPN은 언제 Premium까지 가야 하나요?

보안 감사, 접속 흐름 추적, 외부 로그 적재, 고급 SSH 통제, JIT access가 필요할 때입니다. 단순 원격 접속과 내부 웹 접근 위주라면 Standard에서 끝나는 팀도 많습니다.

ephemeral minutes가 부족하면 무조건 Premium으로 올려야 하나요?

그 전에 먼저 워크로드 수명을 보셔야 합니다. 짧게 떠야 할 러너가 오래 남아 있다면 플랜 문제보다 설계 문제일 가능성이 큽니다. 4시간 이상 존재한 장비는 일반 tagged resource로 계산된다는 점도 같이 보셔야 합니다.

마무리: 저는 이렇게 고르라고 말씀드립니다

개인 홈랩이라면 Personal부터 시작하시면 됩니다. 사용자 6명 이내, 비상업용, 공유 인프라 수가 많지 않다면 구조를 단순하게 유지하는 쪽이 이득입니다. 새 노드를 추가하기 전에 대표 subnet router 1대와 exit node 1대로 충분한지 먼저 검증해보세요. 무료 유지의 핵심은 기기 수보다 역할 수를 늘리지 않는 것입니다.

작은 팀이라면 Standard를 출발점으로 보는 게 맞습니다. 업무용 계정 수명주기, 역할 분리, SCIM/MDM이 필요하면 여기서부터가 운영적으로 안정적입니다. 그리고 누가 언제 어디에 접근했는지 남겨야 하는 조직이면 Premium 검토를 미루지 않는 편이 낫습니다. 그 구간에선 요금보다 사고 대응 비용이 더 크게 돌아오거든요.

한 줄로 정리하면 이렇습니다. 사람이 적고 구조가 단순하면 Personal, 계정 운영이 시작되면 Standard, 감사와 추적이 필수면 Premium. Tailscale 가격은 복잡해 보여도 seat·tagged resource·ephemeral minutes를 따로 보면 의외로 답이 선명합니다.

Personal, Standard, Premium 중 어떤 상황에서 무엇을 고르면 되는지 빠르게 판단할 수 있는 요약 이미지입니다.