4.6 네트워크 토폴로지(Topology) 설계 전략

4.6 네트워크 토폴로지(Topology) 설계 전략

Zenoh(제노) 라우터가 아무리 훌륭한 트랜스포트 계층(4.4절)과 자기 수복형 피어 디스커버리 기능(4.5절)을 갖추었다 하더라도, 이 노드들을 어떠한 아키텍처 형태로 이어붙일 것인지는 전적으로 아키텍트의 “설계 전략“에 달려 있다. 무작정 모든 노드를 서로 연결한다고 성능이 극대화되는 것이 아니며, 오히려 치명적인 브로드캐스트 스톰(Broadcast Storm)이나 대역폭 낭비를 초래할 수 있다.

네트워크 토폴로지 중심축을 잘 잡아야만 데이터의 파편화를 막고 초저지연(Ultra-low Latency) 통신망을 완성할 수 있다. 이 절에서는 실물 인프라에 가장 널리 쓰이는 시그니처 토폴로지 패턴들을 분석하고, 각각의 장단점 및 최적의 적용 시나리오를 설계한다.

  • 클리크(Clique) (4.6.1): 모든 노드가 서로 다이렉트 소켓을 뚫어버리는 완전 연결망. 소규모 고성능 최적화 스웜(Swarm) 환경에서 쓰인다.
  • 스타(Star) (4.6.2): 하나의 거대한 중앙 백본 라우터를 중심으로 클라이언트 노드들이 별 모양으로 모이는 전통적인 중앙 집중형 구조. 관리와 모니터링이 극도로 편해진다.
  • 트리(Tree) (4.6.3): 여러 층위의 라우터를 가지 치듯 수직으로 연결하여, 밑바닥의 방대한 센서 데이터를 단계적으로 병합(Consolidation)해 클라우드로 쏘아 올리는 계층형 구조.
  • 메쉬(Mesh) (4.6.4): 핵심 라우터들을 그물망처럼 다중 경로로 엮어, 포크레인이 통신 케이블 하나를 끊어먹어도 데이터가 우회로를 즉시 찾아내는 하드코어 장애 복원 구조.
  • 유동적 토폴로지 (4.6.5): 로보틱스와 무인기(Drone) 군집 비행처럼 시시각각 라우터의 물리적 위치와 연결 상태가 무너지고 재생성되는 극단적인 동적 환경 대응 전략.

이 설계 패턴들을 레고 블록처럼 조합함으로써 여러분은 공장, 자율주행, 클라우드를 관통하는 세상에서 가장 강력하고 유연한 글로벌 데이터 스페이스(Global Data Space)를 창조해 낼 수 있다.

1. 클리크(Clique) 토폴로지: 노드 간 완전 연결망 구성

클리크(Clique) 토폴로지는 네트워크에 참여하는 모든 Zenoh(제노) 노드가 단 하나의 예외도 없이 서로 간에 1:1 다이렉트 세션(Session)을 수립하는 완전 연결망(Fully-Connected Network) 형태를 의미한다. 수학의 그래프 이론에서 노드 간의 빈틈없는 연결 상태인 완전 그래프(Complete Graph)와 동일한 개념이다.

1.1 구조적 특징과 통신 메커니즘

클리크 구조에서는 A 노드가 B 노드로 데이터를 보낼 때 중간에 어떠한 라우터나 브로커도 거치지 않는다. 데이터를 생산하는 Publisher 노드와 이를 요구하는 Subscriber 노드 사이의 점대점(Point-to-Point) 소켓이 직접 열려 있기 때문에, 물리적인 회선이 허용하는 **극한의 최저 지연 시간(Ultra-low Latency)**을 뽑아낼 수 있다.

graph TD
    Peer1 <--> Peer2
    Peer1 <--> Peer3
    Peer1 <--> Peer4
    Peer2 <--> Peer3
    Peer2 <--> Peer4
    Peer3 <--> Peer4

이 토폴로지를 구성하는 방법은 의외로 간단하다. 노드들을 Client 모드가 아닌 Peer 모드로 구동시킨 뒤, 4.5절에서 배운 멀티캐스트 로컬 디스커버리 기능을 활성화해 두면 된다. 좁은 서브넷 안에서 서로의 스카우트 메시지를 감지한 Peer들은 본능적으로 서로에게 TCP 터널을 뚫어 이 클리크 거미줄망을 완성한다.

1.2 클리크의 치명적 장점: 단일 장애점(SPOF)의 소멸

중앙 브로커가 존재하는 레거시 미들웨어(MQTT 등)와 달리, 클리크 토폴로지에는 시스템을 총괄하는 우두머리가 없다.
따라서 10대의 로봇으로 구성된 스웜(Swarm) 비행체 무리 중 9대가 폭파되더라도, 남은 1대는 여전히 자신의 데이터를 뿜어내고 동작할 수 있다. 중앙 서버가 죽어 전체 시스템이 마비되는 **단일 장애점(SPOF, Single Point of Failure)**이 원천적으로 존재하지 않는 진정한 탈중앙화(Decentralization)의 끝판왕이다.

1.3 한계점: O(N^2) 스케일링의 저주

클리크 토폴로지는 소규모 네트워크(보통 10~50대 미만 노드)에서는 타의 추종을 불허하는 성능을 내지만, 노드 수가 늘어날수록 시스템은 비명을 지르기 시작한다.

노드의 개수가 N개일 때, 네트워크 전체에 유지되어야 하는 커넥션의 개수는 \frac{N(N-1)}{2} 개가 된다. 즉 O(N^2)의 궤적을 그리며 기하급수적으로 폭증한다.
1,000대의 노드가 완전 연결을 시도하면 무려 약 50만 개의 상시 TCP 소켓이 열려야 하므로, 각 단말의 OS 포트 고갈과 Context Switching 오버헤드로 인해 시스템이 자멸한다. 따라서 클리크 토폴로지는 반드시 닫힌(Closed) 폐쇄망이나 좁은 구역의 자율주행 차량 내부망 구축과 같은 특수 시나리오로 범위를 엄격히 제한해야 한다.

2. 스타(Star) 토폴로지: 중앙 집중형 라우터 구성

스타(Star) 토폴로지는 네트워크의 한가운데에 강력한 처리 능력을 가진 Zenoh 라우터(Router) 하나를 배치하고, 모든 피어(Peer)나 클라이언트(Client) 노드들이 오직 이 라우터 하나만을 바라보고 직접 연결을 맺는 방사형 구조다. 초기 IT 인프라에서 가장 직관적으로 떠올릴 수 있는 고전적인 서버-클라이언트(Server-Client) 아키텍처와 형태적으로 매우 유사하다.

2.1 구조적 특징과 통신 메커니즘

스타 토폴로지 환경 하에서 A 노드가 B 노드로 데이터를 퍼블리시(Publish)하려 할 때, 데이터는 반드시 중앙의 라우터를 한 번 거쳐야만 한다.

graph TD
    Router((Central Router))
    NodeA[Node A] -->|Connect| Router
    NodeB[Node B] -->|Connect| Router
    NodeC[Node C] -->|Connect| Router
    NodeD[Node D] -->|Connect| Router
    
    style Router fill:#f9f,stroke:#333,stroke-width:2px

이 방식을 구현하려면 중앙 라우터는 대기(Listen) 모드로 열어두고, 나머지 모든 노드들은 4.5.4절에서 다룬 정적 연결(Static Connect) 방식을 사용하여 라우터의 IP로 연결을 강제하거나, 라우터가 발송하는 멀티캐스트 스카우트 비콘을 수신하도록 설정해야 한다.

2.2 스타 토폴로지의 강력한 이점: 통제와 가시성

클리크(Clique)의 복잡한 그물망과 비교할 때, 스타 토폴로지가 엔터프라이즈 환경에서 여전히 사랑받는 이유는 명확하다.

  • 단순성과 연결성(Connectivity) 보장: 수백 대의 노드들이 서로의 IP를 알 필요가 없다. 오직 중앙 라우터의 IP 단 하나만 알고 있으면 전체 네트워크에 접속된다. 특히 NAT(Network Address Translation)나 엄격한 방화벽 뒤에 숨어있는 디바이스들을 하나로 모으는 데 매우 탁월하다.
  • 중앙 집중식 관리와 로깅: 모든 데이터 트래픽이 중앙 라우터라는 단일 병목점(Choke Point)을 통과하므로, 이곳에만 와이어샤크(Wireshark)나 모니터링 플러그인을 붙여두면 전체 네트워크의 트래픽 흐름, 페이로드 분석, 접근 제어(ACL) 통제가 완벽하게 가능해진다.

2.3 한계점: 단일 장애점(SPOF)과 대역폭 병목

모든 장점은 곧 치명적인 약점으로 뒤바뀐다.

중앙 라우터 프로세스가 메모리 누수나 하드웨어 장애로 멈추는 순간, 로봇 A와 B가 1미터 옆에 나란히 서 있더라도 서로 통신할 수 없는 완벽한 단일 장애점(SPOF, Single Point of Failure) 상태에 빠진다.

아울러 수천 대의 카메라 센서가 4K 영상 스트림을 뿜어낼 경우, 이를 중앙에서 모두 받아내어 다시 재분배(Fan-out)해야 하는 라우터의 네트워크 카드 밴드위스(Bandwidth) 한계가 전체 시스템의 최대 성능 상한선이 되어버린다. 따라서 데이터 트래픽이 특정 척추 라우터의 처리 용량을 초과할 것으로 예상된다면, 다음 장에서 다룰 트리(Tree)나 메쉬(Mesh) 구조로 즉각 전환해야 한다.

3. 트리(Tree) 토폴로지: 계층적 데이터 병합 및 확산

스타(Star) 토폴로지 한가운데 놓인 단일 라우터 하나만으로는 전 세계에 흩어진 수십만 개의 엣지(Edge) 디바이스에서 폭포수처럼 쏟아지는 데이터를 결코 감당할 수 없다. 이를 극복하기 위해 라우터들을 마치 나뭇가지가 뻗어 나가듯 수직 계층형으로 층층이 연결하는 아키텍처가 바로 트리(Tree) 또는 계층형(Hierarchical) 토폴로지다.

3.1 아키텍처의 구조와 데이터 펌핑(Pumping)

트리 토폴로지는 보통 공장 바닥(Shop Floor)의 리프(Leaf) 노드부터 최상단 스토리지 클라우드까지 3~4개의 논리적 티어(Tier)로 구성된다.

  • L1 (Edge Clients): 개별 센서나 초소형 마이크로컨트롤러들.
  • L2 (Edge Routers/Brokers): 공장 건물의 랙(Rack)이나 자율주행 차량 내부에 설치된 로컬 라우터. L1 클라이언트의 데이터를 1차적으로 취합한다.
  • L3 (Cloud/Backbone Router): 전 세계 L2 라우터들이 모두 모여드는 중앙 관제 센터의 대형 라우터.
graph TD
    CloudR[L3 Cloud Router]
    FactoryR1[L2 Local Router : Factory A]
    FactoryR2[L2 Local Router : Factory B]
    
    CloudR --- FactoryR1
    CloudR --- FactoryR2
    
    FactoryR1 --- n1[Robot 1]
    FactoryR1 --- n2[Robot 2]
    FactoryR2 --- n3[Robot 3]
    FactoryR2 --- n4[Sensor 1]

이 구조에서 에지 라우터(L2)는 단순히 하위 데이터를 위로 퍼 올리는 파이프 역할만 하는 것이 아니다. 하위 노드 100대가 초당 10번씩 서버에 “현재 온도를 알려줘“라고 쿼리(Query)를 날릴 때, L2 라우터가 이를 중간에서 캐싱(Caching)하여 클라우드로 넘어가는 트래픽을 단 1건으로 압축 병합(Consolidation)하는 기염을 토한다.

3.2 브로드캐스트 도메인의 분리

트리 구조의 가장 큰 아키텍처적 이점은 브로드캐스트 도메인을 강제로 절단할 수 있다는 점이다.

만약 로컬 공장 A의 수백 대 로봇이 자기들끼리 스카우팅 멀티캐스트를 날리며 초당 기가바이트 단위의 고해상도 영상을 주고받더라도, 이 폭발적인 트래픽은 하위에 국한될 뿐 상위 클라우드망(WAN)으로 결코 넘어오지 않는다.

L2 에지 라우터가 허브 역할을 하며 외부로 나가는 트래픽과 내부에 머무는 트래픽을 토픽(Topic) 기반 라우팅 룰셋에 따라 지능적으로 걸러내 주기 때문이다. 망의 대역폭(Bandwidth)을 하위 노드끼리 로컬로 온전히 소진할 수 있도록 보호벽을 세우는 셈이다.

3.3 취약점: 계층 단절 현상

트리 구조 역시 상위 라우터와 하위 라우터를 잇는 “목줄” 형태의 단일 링크에 지나치게 의존한다. 만약 L2와 L3 구간의 인터넷 망이 공사 중 굴착기로 인해 절단되면, 해당 팩토리 전체 노드가 클라우드 통제권을 잃는 고립 상태에 빠지게 된다. 이를 막으려면 이어지는 4.6.4절에서 다룰 그물망 구조(Mesh)를 섞어 혼종 토폴로지를 구성해야만 한다.

4. 메쉬(Mesh) 토폴로지: 장애 복원력을 갖춘 다중 경로 설계

스타(Star) 구조의 단일 장애점(SPOF) 위험과 트리(Tree) 구조의 단일 링크 이탈 위험을 동시에 해결하는 궁극의 네트워크 아키텍처가 바로 메쉬(Mesh) 토폴로지다.

인프라의 핵심을 담당하는 Zenoh(제노) 백본 라우터들을 마치 그물망처럼 다중(Redundant) 경로로 서로 엮어, 한 대의 라우터가 전소되거나 통신 케이블이 끊어지더라도 데이터가 멈추지 않고 우회로를 찾아 흐르게 만드는 강력한 장애 복원력(Fault Tolerance)을 제공한다.

4.1 다중 경로 연동과 라우팅 루프의 회피

메쉬 네트워크를 구성하는 방법 자체는 놀라울 정도로 단순하다. zenoh.json5 설정 파일의 connect 지시어에 이웃 라우터들의 IP를 2개 이상 복수로 적어주기만 하면 된다.

// 라우터 A의 설정
{
  "mode": "router",
  "connect": {
    "endpoints": [
      "tcp/router-B.local:7447",
      "tcp/router-C.local:7447" // 두 군데로 동시에 다리를 걸친다
    ]
  }
}

이처럼 라우터들이 서로 꼬리에 꼬리를 무는 다중 연결 망을 형성할 경우, 가장 우려되는 점은 데이터 패킷이 목적지를 찾지 못하고 라우터들 사이를 영원히 핑퐁 치며 맴도는 라우팅 루프(Routing Loop) 현상이다.

하지만 개발자는 이를 걱정할 필요가 없다. 2.3절에서 다루었듯, Zenoh 라우터는 내장된 링크 상태(Link State) 라우팅 프로토콜을 통해 전체 메쉬 망의 지도를 스스로 그리고, 노드 간의 최단 경로를 수학적으로 계산하여 루프를 원천 차단하는 스패닝 트리(Spanning Tree)를 백그라운드에서 자동 구성해 낸다.

4.2 장애 발생 시의 복원(Self-Healing) 시나리오

메쉬 토폴로지의 진가는 장애 상황에서 드러난다.

  1. 라우터 A에서 라우터 C로 가는 핵심 우회로(Link)가 물리적으로 절단된다.
  2. 케이블 절단(Socket Close 또는 Heartbeat Timeout)을 감지한 라우터 A와 C의 Zenoh 코어는 밀리초(ms) 단위로 주변 라우터들에게 링크 단절 사실을 전파(Gossip)한다.
  3. 네트워크 지도를 갱신한 라우터들은 즉시 라우터 B를 거쳐 가는 새로운 우회 경로를 계산하여 라우팅 테이블을 업데이트한다.
  4. 잠시 멈칫했던 센서 데이터 스트림은 즉각 B 라우터라는 지름길을 타고 다시 흐르기 시작한다.

4.3 메쉬 설계의 실무적 적용점

진정한 의미의 ’완전 메쉬(Full Mesh)’는 4.6.1절의 클리크(Clique)와 다름없어 막대한 연결 오버헤드를 발생시킨다.
따라서 현대의 초대형 IoT 시스템 아키텍트들은 수만 대의 말단 디바이스(Client)는 지역별 에지 라우터에 트리(Tree) 형태로 가볍게 붙이고, 거점 관리를 담당하는 핵심 뼈대 라우터(Backbone Router)들 10~20여 대만 부분 메쉬(Partial Mesh)로 굵직하게 엮어내는 혼합형(Hybrid) 토폴로지를 표준 설계안으로 채택한다.

5. 동적 환경(로보틱스, 드론)에서의 유동적 토폴로지 변경 대응

지금껏 다룬 스타, 트리, 메쉬 토폴로지는 모두 지면이나 서버 랙에 단단히 볼트로 고정된 정적(Static) 인프라를 가정한 논의였다. 하지만 무인 드론 편대 비행, 자율주행 차량 간의 V2V(Vehicle-to-Vehicle) 통신, 혹은 로봇 개들의 군집 수색 작전과 같이 노드의 물리적 위치와 통신망이 초 단위로 요동치는 극한의 동적(Dynamic) 환경에서는 기존의 아키텍처 공식이 통째로 붕괴된다.

**Zenoh(제노)**는 이처럼 토폴로지가 유체처럼 끊임없이 변형되는 환경(Fluid Topology)에서조차 데이터망을 끈질기게 유지해 내는 독보적인 설계 사상을 지원한다.

5.1 로케이터(Locator) 파편화와 0-RTT 재연결

고속으로 터널을 통과하는 자율주행 차량은 A 기지국에서 B 기지국으로 핸드오버(Handover)를 반복하며 초당 수차례씩 IP 주소가 바뀐다. 기존의 TCP 소켓 기반 브로커 시스템이라면 IP가 바뀔 때마다 TCP 3-Way Handshake와 TLS 협상을 다시 맺느라 수백 밀리초 단위의 블랙아웃을 겪을 수밖에 없다.

Zenoh는 4.4.3절에서 강조한 QUIC 트랜스포트의 힘을 빌려 이 문제를 돌파한다. QUIC은 연결의 주체를 IP 주소가 아니라 논리적인 ’연결 ID(Connection ID)’로 식별하기 때문에, 로봇의 IP가 4G망에서 와이파이망으로 휙휙 바뀌더라도(Connection Migration) 데이터 스트림은 끊김 없이 파이프라인을 타고 흘러간다.

5.2 브로커리스(Broker-less) 애드혹(Ad-hoc) 네트워킹

사막이나 재난 현장에서는 로봇들을 컨트롤해 줄 중앙 라우터 인프라를 기대할 수 없다. 통신 중계소가 폭파된 상황에서 드론 무리가 임무를 수행해야 한다면, 이들은 클라이언트(Client)나 일반 노드가 아닌 피어(Peer) 모드로 동작해야 한다.

  1. 5대의 드론이 서로의 와이파이 무선 도달 거리(Ad-hoc Wi-Fi) 십자포화 안으로 진입한다.
  2. 멀티캐스트 디스커버리(4.5.2절)가 작동하며 공중에서 즉각적인 임시 클리크(Clique) 네트워크가 형성된다.
  3. 선두 드론이 카메라로 찍은 영상 데이터를 Publish 하면, 나머지 4대의 드론이 즉시 이를 Subscribe 하여 편대 간격 유지 데이터를 나눈다.
  4. 무리가 흩어져 통신 거리가 멀어지면 세션은 미련 없이 끊어지고(Drop), 다른 드론 무리를 만나면 또다시 새로운 위상 공간의 토폴로지를 엮어낸다.

5.3 데이터 중심(Data-Centric) 라우팅의 최종 진화

동적 환경에서 Zenoh 토폴로지가 빛을 발하는 가장 근본적인 이유는 철학적 기조에 있다.
IP 네트워크의 본질은 “패킷을 어느 IP 컴퓨터로 보낼 것인가“에 집착하지만, Zenoh의 핵심 철학은 **“이 데이터(Topic)가 어디에 필요한가?”**에 집중한다.

드론 A가 영상/좌표 토픽을 들고 퍼블리시할 때 상대방 드론의 IP가 192.168.1.10이든 10.0.0.5이든 상관하지 않는다. 공간과 네트워크가 찢어지고 붙기를 1,000번 반복하는 와중에도, Zenoh 라우팅 코어는 현재 맺어져 있는 세션의 나뭇가지를 더듬어 오직 해당 데이터를 요구하는(Subscribe) 노드 곁으로만 페이로드를 조용하게, 그리고 가장 빠른 길로 배달해 낼 뿐이다.