허브 앤 스포크
더 많은 작업
허브 앤 스포크(Hub-and-Spoke)는 하나의 중앙 네트워크 또는 연결 지점인 허브(Hub)에 여러 개의 독립된 네트워크·지점인 스포크(Spoke)를 연결하여 통신, 라우팅 및 공통 서비스를 중앙 집중화하는 네트워크 토폴로지이자 아키텍처 패턴으로, 기업 WAN, 데이터센터, 클라우드 VPC/VNet 및 하이브리드·멀티클라우드 네트워크에서 널리 사용된다.[1][2]
허브 앤 스포크는 바퀴의 중심부와 바큇살에서 이름을 따온 구조이다. 중앙에 위치한 허브가 여러 스포크의 연결점 역할을 하며, 각각의 스포크는 일반적으로 다른 스포크와 직접 연결되는 대신 허브를 통해 공통 서비스나 다른 네트워크에 접근한다.
기본 구조는 다음과 같다.
Spoke A
│
│
Spoke B ────────── Hub ────────── Spoke C
│
│
Spoke D
네트워크에서 허브에는 라우팅, 방화벽, VPN 게이트웨이, DNS와 같은 여러 네트워크가 공통으로 사용하는 기능을 배치할 수 있다. 스포크에는 각 애플리케이션, 부서, 지사 또는 독립된 워크로드를 배치한다.
Microsoft는 클라우드 허브 앤 스포크 구조에서 허브를 여러 스포크 네트워크와 온프레미스 네트워크의 중앙 연결 지점으로 설명하며, 방화벽·게이트웨이 등의 공유 네트워크 서비스를 허브에 배치할 수 있다고 설명한다.[2]
허브 앤 스포크는 특정 제품이나 프로토콜의 명칭이 아니므로 실제 구성 방식은 환경에 따라 달라진다. 일반적으로 다음 두 요소로 구성된다.
| 구성 요소 | 역할 |
|---|---|
| 허브(Hub) | 여러 스포크가 연결되는 중앙 네트워크 또는 라우팅 지점으로, 공통 네트워크·보안 서비스를 제공할 수 있다. |
| 스포크(Spoke) | 허브에 연결되는 개별 네트워크, VPC/VNet, 지사, 데이터센터 또는 워크로드 영역이다. |
허브에는 일반적으로 다음과 같은 기능을 배치할 수 있다.
- 라우터
- 차세대 방화벽
- VPN 게이트웨이
- SD-WAN 게이트웨이
- 인터넷 출구(Egress)
- DNS
- NAT
- 침입 방지 시스템
- 네트워크 가상 어플라이언스(Network Virtual Appliance, NVA)
스포크는 다음과 같은 단위로 분리할 수 있다.
- 업무별 네트워크
- 개발·테스트·운영 환경
- 기업의 각 지사
- 클라우드 VPC 또는 VNet
- 계열사·부서별 네트워크
- 독립적인 애플리케이션 및 워크로드
허브 앤 스포크의 중요한 특징은 여러 네트워크의 연결을 중앙 허브로 집중한다는 것이다.
예를 들어 세 개의 지사를 연결한다고 가정하면 각 지점이 서로 직접 연결되는 구조를 다음과 같이 만들 수 있다.
지사 A ───── 지사 B │ │ └──── 지사 C
지점 수가 증가하면 각 지점 사이의 직접 연결도 빠르게 증가한다.
허브 앤 스포크에서는 각 지점이 허브에만 연결된다.
지사 A
│
│
지사 B ─────── 허브 ─────── 지사 C
│
│
지사 D
지사 A에서 지사 B로 통신해야 한다면 구성에 따라 다음과 같이 중앙 허브를 거쳐 전달할 수 있다.
지사 A ↓ 허브 ↓ 지사 B
AWS는 여러 VPC 및 온프레미스 네트워크를 연결할 때 각 네트워크 사이를 직접 연결하는 메시 구조보다 허브 앤 스포크 구조를 사용하면 연결 구조와 관리 복잡성을 줄이고 라우팅 및 네트워크 제어를 중앙화할 수 있다고 설명한다.[1]
허브 앤 스포크와 자주 비교되는 구조는 풀 메시(Full Mesh) 토폴로지이다.
풀 메시에서는 모든 네트워크가 다른 모든 네트워크와 직접 연결될 수 있다.
A ───────── B │ ╲ ╱ │ │ ╲ ╱ │ │ ╳ │ │ ╱ ╲ │ │ ╱ ╲ │ C ───────── D
반면 허브 앤 스포크는 중앙 허브를 통해 연결한다.
A
│
│
B ─── Hub ─── C
│
│
D
네트워크가 총 N개이고 이들이 모두 서로 직접 연결되는 풀 메시라면 필요한 연결 수는 이론적으로 다음과 같다.
N × (N - 1)
───────────
2
예를 들어 네트워크가 10개라면 풀 메시에는 최대 45개의 개별 연결 관계가 필요하다.
반면 단일 허브 앤 스포크 구조에서는 10개의 스포크를 연결하기 위한 기본적인 허브 연결은 10개이면 된다.
| 스포크 수 | 풀 메시의 최대 연결 수 | 단일 허브 연결 수 |
|---|---|---|
| 3 | 3 | 3 |
| 5 | 10 | 5 |
| 10 | 45 | 10 |
| 20 | 190 | 20 |
| 100 | 4,950 | 100 |
따라서 네트워크 수가 많아질수록 허브 앤 스포크 방식은 연결 관계를 단순화하는 효과가 커진다. AWS도 다수의 프라이빗 네트워크를 연결할 때 메시 구조보다 허브 앤 스포크가 운영성·확장성·제어 측면에서 유리하다고 권고한다.[1]
다만 허브를 거치면서 추가적인 네트워크 홉이 발생할 수 있으므로 모든 환경에서 메시보다 성능이 우수하다는 의미는 아니다.
허브 앤 스포크의 주요 활용 목적 가운데 하나는 보안 기능을 중앙 집중화하는 것이다.
각 스포크에 별도의 방화벽을 설치하는 대신 허브에 공통 방화벽을 배치할 수 있다.
Spoke A
│
↓
┌───────────┐
Spoke B → │ Firewall │ ← Spoke C
│ + Hub │
└───────────┘
│
↓
인터넷
스포크에서 인터넷으로 나가는 트래픽이나 스포크 사이의 통신을 허브 방화벽으로 강제하면 하나의 위치에서 보안 정책을 적용할 수 있다.
Microsoft의 Azure 허브 앤 스포크 참조 아키텍처에서도 중앙 허브에 Azure Firewall을 두고 스포크의 인터넷 트래픽이나 스포크 간 트래픽을 검사하는 구성이 사용된다.[2]
이 구조는 다음과 같은 기능을 중앙에서 관리하는 데 이용할 수 있다.
- 방화벽 정책
- 인터넷 접근 제어
- NAT
- 침입 탐지·방지
- 네트워크 로깅
- DNS
- VPN 연결
- 온프레미스 연결
허브 앤 스포크는 클라우드가 등장하기 전부터 기업의 지사 WAN에서 사용되어 온 대표적인 네트워크 구성 방식이다.
본사 또는 중앙 데이터센터를 허브로 두고 각 지사를 스포크로 연결할 수 있다.
부산 지사
│
│
대전 지사 ── 본사/DC ── 광주 지사
│
│
대구 지사
이 구조에서는 지사가 다른 지사나 중앙 시스템에 접근할 때 본사 또는 데이터센터의 허브를 거치도록 만들 수 있다.
기업이 여러 지역에 지점을 가지고 있을 때 각각의 지사를 모두 직접 연결하는 것보다 중앙 허브로 연결을 집중하면 WAN 구조와 라우팅 정책을 단순화할 수 있다.
다만 인터넷 및 SaaS 사용량이 증가하면서 모든 트래픽을 중앙 데이터센터로 우회시키는 기존 허브 앤 스포크 WAN 구조는 불필요한 지연이나 회선 사용량 증가를 발생시킬 수 있다. 이러한 문제를 완화하기 위해 SD-WAN이나 SASE에서는 지사가 인터넷 또는 클라우드 서비스에 직접 연결하면서 필요한 보안 정책을 적용하는 구조도 사용된다.
허브 앤 스포크는 현대 클라우드 네트워크에서 매우 흔하게 사용된다.
기업이 여러 애플리케이션을 하나의 거대한 VPC나 가상 네트워크에 배치하는 대신 각각을 독립적인 네트워크로 분리하고, 중앙 허브 네트워크에 연결하는 방식이다.
온프레미스
│
VPN / 전용회선
│
↓
┌─────────────────┐
│ Hub VPC │
│ │
│ Firewall │
│ VPN Gateway │
│ DNS │
│ Shared Service │
└─────────────────┘
│ │ │
┌─────────┘ │ └─────────┐
↓ ↓ ↓
Spoke VPC A Spoke VPC B Spoke VPC C
개발환경 운영환경 데이터
이 구조는 다음과 같은 장점을 제공한다.
- 애플리케이션과 환경별 네트워크 격리
- 중앙 집중식 인터넷 출구
- 중앙 방화벽 적용
- 온프레미스 연결 공유
- VPN 및 전용회선 게이트웨이 공유
- 공용 DNS 및 관리 서비스 공유
- 각 워크로드 팀의 독립적인 네트워크 운영
Google Cloud 역시 기업이 서로 다른 워크로드를 별도의 VPC 네트워크로 분리하고, 공통 서비스 및 온프레미스 연결을 중앙 허브 네트워크에 배치하는 허브 앤 스포크 아키텍처를 공식적인 클라우드 네트워크 구성 방식으로 제공한다.[3]
Amazon Web Services에서는 AWS Transit Gateway를 허브로 사용해 여러 VPC와 온프레미스 네트워크를 연결하는 방식이 대표적인 허브 앤 스포크 구현이다.
VPC A
│
│
VPC B ── Transit Gateway ── VPC C
│
│
온프레미스
각 VPC를 다른 모든 VPC와 직접 피어링하는 대신 Transit Gateway에 연결하면 중앙 라우팅 지점을 통해 네트워크 연결을 관리할 수 있다.
AWS는 Transit Gateway를 네트워크 세분화, 중앙 집중식 라우팅 및 클라우드·온프레미스 연결을 제공하는 관리형 허브로 설명한다.[4]
Microsoft Azure에서는 일반적으로 중앙 Hub VNet과 여러 Spoke VNet을 구성한다.
Spoke VNet
│
│ Peering
↓
┌─────────────┐
│ Hub VNet │
│ │
│ Firewall │
│ VPN Gateway │
│ Bastion │
└─────────────┘
│ │
Spoke Spoke
VNet VNet
허브에는 Azure Firewall, VPN Gateway, ExpressRoute Gateway 및 기타 공유 서비스를 배치하고, 실제 애플리케이션 워크로드는 스포크 VNet에 배치할 수 있다.[2]
Azure Virtual WAN을 이용하면 Microsoft가 관리하는 가상 허브를 이용해 비슷한 구조를 구현할 수도 있다.[5]
Google Cloud에서는 Network Connectivity Center(NCC)를 이용하여 허브 앤 스포크 네트워크를 구성할 수 있다.
NCC의 허브에는 여러 VPC, 온프레미스 및 다른 네트워크 연결을 스포크로 연결할 수 있다. Google은 이를 VPC 간 연결, 사이트 간 연결 및 사이트-클라우드 연결을 중앙 관리하기 위한 네트워크 연결 프레임워크로 제공한다.[6]
VPC A
│
│
VPC B ───── NCC Hub ───── VPC C
│
│
온프레미스
허브 앤 스포크라는 구조를 사용한다고 해서 반드시 모든 스포크가 서로 통신할 수 있는 것은 아니다.
스포크 간 연결 방법은 구현 기술에 따라 달라진다.
예를 들어 Azure VNet Peering은 기본적으로 비전이적(non-transitive)이므로,
Spoke A ↔ Hub Hub ↔ Spoke B
라는 피어링이 존재하더라도 이것만으로 다음 통신이 자동으로 성립하는 것은 아니다.
Spoke A ↔ Spoke B
스포크 간 통신이 필요한 경우 허브의 라우터·방화벽 같은 NVA를 경유시키거나 별도의 직접 피어링 및 관리형 라우팅 기능 등을 사용해야 한다. Microsoft는 허브를 통한 스포크 간 트래픽이 필요한 경우 방화벽 또는 다른 NVA와 라우팅 구성을 사용할 수 있다고 설명한다.[2]
반대로 AWS Transit Gateway나 Google Cloud Network Connectivity Center처럼 중앙 허브 자체가 여러 스포크 사이의 경로 교환과 전이적 연결을 제공하도록 설계된 서비스도 있다.[4][6]
따라서 허브 앤 스포크는 논리적인 토폴로지를 의미하며 스포크 간 전이적 라우팅의 지원 여부까지 규정하는 것은 아니다.
허브 앤 스포크의 주요 장점은 네트워크가 커질수록 연결 및 정책 관리를 단순화할 수 있다는 것이다.[1]
| 장점 | 설명 |
|---|---|
| 연결 단순화 | 각 스포크가 다른 모든 스포크와 직접 연결될 필요 없이 허브에 연결할 수 있다. |
| 중앙 집중식 라우팅 | 네트워크 경로와 연결 정책을 허브에서 관리할 수 있다. |
| 중앙 집중식 보안 | 공통 방화벽, IPS, 로깅 및 인터넷 접근 정책을 허브에 배치할 수 있다. |
| 공통 서비스 공유 | VPN 게이트웨이, DNS, 관리 서버 등 여러 스포크가 사용하는 서비스를 허브에서 공유할 수 있다. |
| 네트워크 격리 | 서로 다른 업무·환경을 독립된 스포크로 분리할 수 있다. |
| 확장성 | 새로운 네트워크를 추가할 때 기존 모든 스포크와 연결하지 않고 허브 연결을 추가하는 방식으로 확장할 수 있다. |
중앙 집중화에는 단점도 존재한다.
허브 의존성이 가장 중요한 고려사항이다. 모든 통신이 하나의 허브에 의존하는 구조에서 허브에 장애가 발생하면 다수의 스포크가 동시에 영향을 받을 수 있다.
따라서 실제 환경에서는 허브 구성 요소를 고가용성으로 구성하거나 여러 지역에 별도의 허브를 배치하기도 한다.
Region A Region B Spoke ─┐ ┌─ Spoke Spoke ─┼─ Hub A ═══════ Hub B ┼─ Spoke Spoke ─┘ └─ Spoke
또한 트래픽을 중앙 허브로 우회시키면 스포크끼리 직접 통신하는 것보다 추가 지연과 대역폭 비용이 발생할 수 있다.
주요 고려사항은 다음과 같다.
- 허브 장애의 영향 범위
- 허브의 처리 용량
- 스포크 간 트래픽으로 인한 추가 홉
- 중앙 방화벽의 처리 성능
- 클라우드 데이터 전송 비용
- 라우팅 테이블 관리
- 여러 지역을 사용하는 경우 허브 간 연결
- 허브의 관리 권한 집중
- 스포크 간 통신 허용 정책
대규모 환경에서는 하나의 허브에 모든 네트워크를 집중시키기보다 지역이나 보안 영역별로 여러 허브를 구성하는 멀티 허브 앤 스포크 구조를 사용할 수 있다. Microsoft도 여러 지역이나 처리 용량 확대가 필요한 환경에서 다중 허브 구조를 고려할 수 있다고 설명한다.[2]
허브 앤 스포크의 물리적인 형태는 스타 토폴로지와 매우 유사하다.
둘 모두 중앙 노드를 기준으로 여러 노드가 방사형으로 연결된다.
A
│
│
B ── 중앙 ── C
│
│
D
그러나 일반적인 스타 토폴로지는 LAN의 물리적·논리적 연결 형상을 포함하는 광범위한 네트워크 토폴로지 개념이다.
반면 허브 앤 스포크는 기업 WAN, 클라우드 및 복수 네트워크 사이에서 중앙 연결·라우팅·공유 서비스 구조를 설명하는 아키텍처 패턴이라는 의미로 많이 사용된다.
따라서 두 용어가 형태적으로는 유사하지만 사용되는 문맥과 추상화 수준에는 차이가 있다.
전통적인 기업 WAN에서 허브 앤 스포크는 중앙 데이터센터를 통해 인터넷 및 애플리케이션 트래픽을 처리하는 구조로 많이 사용되었다.
지사 ↓ 본사 허브 ↓ 방화벽 ↓ 인터넷
클라우드와 SaaS 사용이 증가하면 지사의 인터넷 트래픽이 중앙 데이터센터까지 갔다가 다시 인터넷으로 나가야 하는 백홀링(Backhauling)이 발생할 수 있다.
서울 지사 ↓ 본사 데이터센터 ↓ 인터넷 ↓ SaaS
사용자가 실제로 접근하려는 SaaS 서비스와 가까운 인터넷 연결이 있어도 중앙 허브를 거쳐야 하기 때문에 불필요한 경로가 발생할 수 있다.
이러한 문제 때문에 현대 SD-WAN에서는 애플리케이션과 정책에 따라 지사가 인터넷으로 직접 나가는 로컬 브레이크아웃(Local Breakout)을 사용할 수 있으며, SASE에서는 중앙 데이터센터 대신 분산된 클라우드 보안 거점을 이용하는 구조가 사용된다.
따라서 SD-WAN이나 SASE가 허브 앤 스포크를 완전히 대체하는 개념은 아니다. 실제 네트워크에서는 클라우드·데이터센터 연결에는 허브 앤 스포크를 사용하면서 사용자 인터넷 접근에는 SASE를 사용하는 등 여러 구조를 함께 사용할 수 있다.
- ↑ 1.0 1.1 1.2 1.3 Amazon Web Services, 「REL02-BP04 Prefer hub-and-spoke topologies over many-to-many mesh」, https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_network_topology_prefer_hub_and_spoke.html, 확인일: 2026년 9월 7일.
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 Microsoft, 「Hub-and-spoke network topology」, https://learn.microsoft.com/en-us/azure/networking/design-guide/hub-spoke, 확인일: 2026년 9월 7일.
- ↑ Google Cloud, 「Hub-and-spoke network architecture」, https://docs.cloud.google.com/architecture/deploy-hub-spoke-vpc-network-topology, 확인일: 2026년 9월 7일.
- ↑ 4.0 4.1 Amazon Web Services, 「AWS Transit Gateway」, https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html, 확인일: 2026년 9월 7일.
- ↑ Microsoft, 「Hub-Spoke Network Topology That Uses Azure Virtual WAN」, https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke-virtual-wan-architecture, 확인일: 2026년 9월 7일.
- ↑ 6.0 6.1 Google Cloud, 「Network Connectivity Center overview」, https://docs.cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/overview, 확인일: 2026년 9월 7일.