4.5 피어 디스커버리(Peer Discovery) 메커니즘

수천 대의 로봇과 센서가 수시로 네트워크에 진입(Join)하고 이탈(Leave)하는 동적인 엣지(Edge) 환경에서, 중앙 서버의 고정 IP를 하드코딩하여 통신망을 유지하려는 시도는 필연적으로 아키텍처의 취약점을 노출한다. 브로커가 죽으면 전체 망이 마비되는 이러한 중앙 집중형 설계의 한계를 극복하기 위해, **Zenoh(제노)**는 네트워크 노드들이 스스로 주변 동료를 찾아내고 자생적으로 메쉬(Mesh)를 엮어내는 피어 디스커버리(Peer Discovery) 메커니즘을 핵심 기능으로 내장하고 있다.

이 장에서는 Zenoh 노드들이 어떻게 서로의 존재를 감지하고 동적으로 라우팅 경로를 개척하는지, 그 은밀한 수색 과정을 해부한다.

탐색의 본질 (4.5.1 & 4.5.2): 노드가 기동될 때 주변에 자신의 존재를 알리는 ‘스카우트(Scout)’ 메시지의 작동 원리와, 로컬 네트워크(Subnet) 내에서 가장 빠르고 효율적으로 동료를 찾는 멀티캐스트(Multicast) 기반 디스커버리를 알아본다.
대규모 확장 (4.5.3): 로컬 네트워크를 넘어 대륙 단위로 퍼진 수만 개의 노드가 중앙 서버 없이 서로의 존재를 전파하는 탈중앙화된 가십(Gossip) 프로토콜의 핵심을 파헤친다.
제한 환경 돌파 (4.5.4): 멀티캐스트 패킷을 원천 차단하는 클라우드(AWS, GCP 등) VPC 환경이나 폐쇄망에서 억지로 디스커버리를 성사시키기 위한 정적(Static) 피어링 기법을 다룬다.
생태계 연동 (4.5.5): 애플의 Bonjour나 범용 IoT 기기들이 사용하는 표준 네트워크 탐색 기술인 mDNS/DNS-SD를 Zenoh와 융합하여 이기종 생태계와의 접점을 넓히는 방법을 소개한다.

이 디스커버리 메커니즘을 완벽히 통제해야만 비로소 특정 노드의 물리적 장애에 흔들리지 않는 진정한 “자기 치유형(Self-healing)” 데이터 네트워크를 건설할 수 있다.

1. 스카우트(Scout) 메시지와 자동 디스커버리 프로토콜

Zenoh(제노) 네트워크에 갓 진입한 노드(Peer, Router, Client)는 자신이 속한 거대한 데이터 우주에서 철저한 고립 상태로 시작한다. 이 고독한 노드가 가장 먼저 수행하는 생존 본능적 행위가 바로 스카우트(Scout) 메시지의 발송이다.

1.1 스카우트 메시지의 해부

스카우팅(Scouting)은 말 그대로 정찰병을 사방으로 파견하는 행위다. Zenoh 데몬이 부팅되면 설정 파일 내부의 scouting 파라미터 세팅에 따라 네트워크 상에 비콘(Beacon) 패킷을 주기적으로 흩뿌린다.

이 스카우트 패킷의 페이로드(Payload) 내부에는 해당 노드를 특정 지을 수 있는 필수 데이터가 응축되어 있다.

What I am: 자신의 노드 역할(Peer인지 Router인지).
Who I am: 자신을 식별하는 고유한 암호학적 식별자(Zenoh ID).
Where I am: 다른 노드가 나에게 접속하기 위해 찔러야 할 1개 이상의 바인딩 엔드포인트(Locator 주소 리스트, 예: tcp/192.168.1.100:7447).

1.2 Hello-Welcome 프로토콜 교환

허공에 뿌려진 스카우트 메시지를 주변에 이미 자리를 잡고 있던 다른 Zenoh 라우터나 피어가 낚아채면, 즉흥적인 세션 협상(Negotiation) 절차가 점화된다.

Hello 발송 (Scouting): A 노드가 멀티캐스트 주소로 “나 여기 7447 포트로 IP 192.168.1.100에 살아있소!“라는 Hello 성격의 스카우트 패킷을 쏜다.
스니핑(Sniffing)과 검증: B 라우터가 이 패킷을 수신(Listen)한다. B 라우터는 A 노드의 Zenoh ID가 자신의 라우팅 테이블에 있는지 대조하고, 기존에 없던 새로운 노드임이 확인되면 연결을 결심한다.
세션(Session) 수립: B 라우터는 스카우트 메시지 안에 적혀 있던 A 노드의 TCP 로케이터를 향해 유니캐스트(Unicast)로 직접 소켓 연결을 때리며 세션을 맺는다.
Welcome 및 라우팅 정보 동기화: 논리적 세션이 맺어지는 순간 양측은 각자가 가진 라우팅 테이블(누가 어떤 토픽을 구독하고 있는지)을 빛의 속도로 쏟아내며 서로를 동기화(Sync)시킨다.

1.3 주기적 발송과 스플릿 브레인(Split-Brain) 복구

스카우트 메시지는 부팅 시점에 딱 한 번만 쏘는 것이 아니다. 네트워크 단절로 메쉬가 두 동강(Split-Brain) 나거나, 와이파이 재접속으로 IP 주소가 변동되었을 때를 대비해, 노드는 설정된 주기(기본 수백 밀리초 ~ 수 초)마다 끊임없이 비콘을 내보낸다.

이를 통해 끊어졌던 노드들이 다시 무선망 커버리지 안으로 들어오는 즉시 서로를 귀신같이 알아채고 다시 하나의 거대한 메쉬망으로 병합(Merge)되는 기적 같은 **자동 복구력(Self-healing)**을 갖추게 된다.

2. 멀티캐스트(Multicast) 기반의 로컬 네트워크 디스커버리

앞선 4.5.1절에서 다룬 “스카우트(Scout) 메시지“를 전송하는 가장 지배적이고 효율적인 물리적 수단이 바로 **멀티캐스트(Multicast)**다. TCP나 Unicast UDP가 편지 봉투에 특정 수신자의 주소를 정확히 적어서 보내는 방식이라면, 멀티캐스트는 동네 마을 회관의 앰프에 대고 방송을 때리는 것과 같다.

동일 서브넷(Subnet, 예: 공유기에 물려있는 집안망이나 특정 공장의 로컬 이더넷 망) 환경에서, 수십 대의 로봇이 IP 스캐닝이나 고정 IP 설정 없이도 전원을 켜자마자 서로를 즉시 식별할 수 있는 비결이 여기에 있다.

2.1 멀티캐스트 그룹의 이해

Zenoh(제노) 코어는 기본적으로 224.0.0.225라는 IPv4 멀티캐스트 특수 그룹 주소(UDP 포트 7447)를 타겟으로 맞춘 채 출하된다.

네트워크 내의 모든 Zenoh 라우터와 피어는 자신의 일상적인 TCP 통신을 수행함과 동시에, OS 커널 스택에게 “224.0.0.225로 떨어지는 패킷은 나에게도 사본을 던져달라“고 멀티캐스트 그룹 가입(Join)을 신청해 둔다.

2.2 로컬 디스커버리 설정과 튜닝

라우터 설정 파일(zenoh.json5) 내의 scouting 영역에서 멀티캐스트의 동작 양상을 세밀하게 통제할 수 있다.

// zenoh.json5
{
  "scouting": {
    "multicast": {
      // 로컬 디스커버리 기능 켜기 (기본값: true)
      "enabled": true,
      
      // 사용할 멀티캐스트 주소 및 포트 변경 (충돌 회피 시)
      "address": "224.0.0.225:7447",
      
      // 여러 네트워크 카드(NIC) 중, 멀티캐스트를 발송할 특정 인터페이스 지정
      "interface": "eth0",
      
      // 스카우트 비콘을 쏘는 주기 지정 (밀리초) - 로봇 이동 속도에 맞춰 조절
      "interval": 200
    }
  }
}

다중 NIC 환경 주의: 서버에 랜카드가 2개 이상 꽂혀 있을 때(예: 내부망용, 외부망용), interface를 명시하지 않으면 OS가 엉뚱한 망으로 앰프 방송을 쏘아서 로봇들이 영영 라우터를 찾지 못하는 고전적인 이슈가 자주 발생한다.

2.3 한계와 주의점 (TTL)

멀티캐스트의 전파 범위는 무조건 L3 라우터 홉(Hop) 수, 즉 **패킷 생명주기(TTL, Time-To-Live)**의 제약을 받는다. 보통 보안상의 이유로 기업용 백본 라우터(공유기가 아닌 통신망 라우터)들은 멀티캐스트 패킷을 씹어 삼키고(Drop) 옆 동네 서브넷으로 넘겨주지 않는다. 즉, 서울 서버실의 라우터가 쏜 멀티캐스트는 포트 포워딩을 아무리 열심히 해도 부산에 있는 로봇에게 결코 닿지 않는다.

망이 분리된 원거리나 클라우드 환경에서는 멀티캐스트에 의존할 수 없으므로, 이어질 4.5.3의 가십 프로토콜이나 4.5.4의 정적 라우팅 기법으로 구조적 한계를 우회해야 한다.

3. 가십(Gossip) 프로토콜을 활용한 대규모 네트워크 구성

멀티캐스트(Multicast)는 하나의 서브넷 안에서는 무적의 효율을 자랑하지만, 라우터를 하나 건너뛰어야 하는 거리가 되거나 노드의 개수가 수만 개 단위로 넘어가면 대역폭을 갉아먹는 브로드캐스트 스톰(Broadcast Storm)의 주범이 될 수 있다.

이러한 지역적 한계를 극복하고, 전 세계에 흩어진 Zenoh(제노) 노드들이 중앙 서버 없이도 스스로 전체 네트워크 지도를 그리게 만드는 마법의 핵심이 바로 가십(Gossip) 프로토콜이다.

3.1 가십(Gossip) 확산의 원리

가십 프로토콜은 문자 그대로 “소문(Gossip) 퍼뜨리기“와 똑같은 방식으로 동작한다. 인간 사회에서 발 없는 말이 천 리를 가듯 네트워크의 소문 전파 알고리즘도 무시무시한 속도로 전체 망을 감염시킨다.

A 라우터가 B 라우터와 세션을 맺는다.
B 라우터가 C 라우터의 존재를 새롭게 알게 된다.
B 라우터는 자기가 알고 있는 주변 노드(A 라우터 포함 한정된 이웃들)에게 “나 C 라우터랑 연결됐어! C 라우터 위치는 여기야!“라고 속삭인다(소문내기).
이 소문을 들은 A 라우터는 또다시 자신이 아는 D, E 라우터에게 이 소문을 전달한다.
결과적으로 불과 몇 홉(Hop) 만에 전체 네트워크의 수만 개 라우터가 C 라우터의 존재와 라우팅 경로를 알게 된다.

이 방식은 각 노드가 전체 네트워크의 상태를 알고 있을 필요 없이, 오직 자신의 **직접 연결된 이웃(Neighbors)**하고만 통신하면 되므로 대규모 확장에 있어 병목이 제로(Zero)에 가깝다.

3.2 라우팅 테이블 트리와 혼잡 제어

물론 무작정 소문만 퍼뜨리면 패킷이 무한 루프를 도는 재앙이 발생한다. Zenoh는 이 가십 알고리즘 내부에 스패닝 트리 알고리즘(Spanning Tree Algorithm)과 유사한 고유의 토폴로지 관리 로직을 내장하고 있다.

루프(Loop) 방지: 이미 들은 소문(특정 노드의 식별자와 Sequence Number가 동일한 디스커버리 패킷)은 즉각 폐기하여 통신망을 맴도는 좀비 패킷을 차단한다.
구독(Subscription) 정보의 역전파: 누가 어디에 있는지만 소문내는 것이 아니라, “나는 /sensor/temperature/** 데이터를 원해“라는 구독 정보(Routing Table)도 가십을 타고 역방향으로 전파된다.

결국, 한국에 있는 라우터 단 하나만 미국에 있는 백본 라우터의 IP를 알고 연결해 두면, 가십 프로토콜을 통해 한국의 모든 에지 로봇과 미국의 모든 클라우드 서버가 단 하나의 유기적인 Pub/Sub 네트워크망으로 엮이게 되는 셈이다.

4. 브로드캐스트 제한 환경(클라우드 등)에서의 정적(Static) 피어 연결 설정

자동화된 멀티캐스트 스카우팅(Scouting)은 매우 편리하지만, 현실 세계의 상용 인프라는 이보다 훨씬 척박하다. 대표적으로 **AWS, GCP, Azure와 같은 퍼블릭 클라우드 공간(VPC)**이나, 보안 규정이 촘촘하게 적용된 기업의 DMZ 구간 라우터들은 네트워크 플러딩(Flooding) 공격을 막기 위해 브로드캐스트나 멀티캐스트 패킷을 스위치 단에서 가차 없이 폐기시켜 버린다.

이러한 차단 스택 위에서는 백날 스카우트 비콘을 쏘아 올려도 아무도 응답하지 않는다. 이럴 때 Zenoh(제노) 라우터들을 강제로 이어붙이기 위해 사용하는 최후의 수단이 바로 정적(Static) 커넥트 설정이다.

4.1 정적 커넥션(Static Connection)의 구성

정적 피어링 방식은 라우터가 부팅될 때 수동적인 탐색을 포기하고, 설정 파일이나 실행 파라미터에 명시된 특정 로케이터(IP/포트)를 향해 다이렉트로 TCP 소켓을 뚫어버리는 능동적(Active) 접근법이다.

zenoh.json5 설정 파일의 connect 지시어를 통해 이를 구현한다.

// 로컬 공장의 에지 라우터 (클라우드로 연결 시도)
{
  "mode": "router", // 라우터 모드
  "listen": {
    "endpoints": ["tcp/0.0.0.0:7447"]
  },
  "connect": {
    "endpoints": [
      // 멀티캐스트가 막혀 있으므로, 클라우드 백본 라우터의 공인 IP와 포트에 무조건 붙어라!
      "tcp/203.0.113.50:7447" 
    ]
  }
}

4.2 하프 메쉬(Half-Mesh) 토폴로지 아키텍처 구축

수백 개의 에지 라우터가 모두 클라우드 중심점(Center)을 바라보게 정적 연결을 구성하면 전형적인 허브 앤 스포크(Hub-and-Spoke) 구조가 된다.

여기서 4.5.3절에서 배운 가십(Gossip) 프로토콜의 진가가 드러난다. 에지 라우터 A, B, C가 오직 중앙 클라우드 라우터(Hub) 하나의 IP만 알고 연결을 수립하더라도, 허브 라우터가 가십 프로토콜을 통해 A, B, C 각자의 라우팅 테이블을 모두에게 중계해 준다.

즉, 설정 파일에는 IP 화살표를 단 한 방면으로만 딱딱하게 고정시켰음에도 불구하고, 실제 페이로드 트래픽은 이 연결선들을 타고 유연하게 흐르는 논리적 메쉬(Mesh) 네트워크가 완성되는 것이다.

이 정적 커넥션 기법은 도커(Docker) 컨테이너 간의 통신, 쿠버네티스(Kubernetes) 팟 간의 통신 등 오버레이 네트워크가 복잡하게 꼬여 멀티캐스트를 신뢰할 수 없는 모든 IT 인프라에서 가장 안정적이고 확실한 네트워크 구축의 뼈대가 된다.

5. mDNS/DNS-SD 기반 노드 탐색 기법

Zenoh 자체의 멀티캐스트 스카우팅 메커니즘은 매우 강력하지만, 이는 오직 ’Zenoh 프로토콜을 이해하는 노드들’끼리만 통용되는 내부 은어(Jargon)와 같다. 만약 기업망의 방화벽이 특정 포트의 멀티캐스트를 차단하거나, 애플리케이션 레벨에서 네트워크 서비스들을 범용적으로 중앙 관제해야 하는 상황이라면 범용 표준 탐색 프로토콜과의 융합이 필수적이다.

이를 위해 Zenoh(제노) 생태계는 범용 제로 설정 네트워킹(Zeroconf)의 산업 표준인 **mDNS(Multicast DNS)**와 **DNS-SD(DNS Service Discovery)**를 활용한 노드 탐색을 결합하는 모델을 지원한다.

5.1 mDNS와 DNS-SD의 개념

우리가 프린터를 네트워크망에 꽂기만 하면 맥(Mac)북이 자동으로 프린터를 찾아내고, 아이폰의 애플티비 미러링(AirPlay)이 IP 입력 없이 즉시 연결되는 마법의 핵심 기술이 바로 이 두 가지다.

mDNS: 로컬 네트워크 안에서 중앙 DNS 서버(예: 8.8.8.8) 없이도, 단말기들이 서로 .local 이라는 도메인 이름과 자신의 로컬 IP를 서로 지저귀며 이름풀이(Name Resolution)를 자급자족하는 기술이다.
DNS-SD: 특정 이름을 넘어, “이 네트워크에 ‘프린터’ 기능 가진 놈 있어?” (서비스 타입 쿼리)라고 외치면 서비스 목록들을 리스트로 뱉어주는 메커니즘이다.

5.2 Zenoh 포트와 mDNS의 결합 메커니즘

운영체제 레벨의 mDNS 데몬(리눅스의 Avahi, 애플의 Bonjour)과 협력하여 Zenoh 라우터의 존재를 광고(Advertise)할 수 있다. 예를 들어, 라우터를 띄우면서 라우터의 TCP 엔드포인트를 mDNS의 특정 서비스 타입(예: _zenoh._tcp.local)으로 등록해 두는 것이다.

서비스 퍼블리싱: 클라우드 서버나 헤드리스(Headless) 로봇 노드에서 Zenoh 데몬을 실행하는 동시에, Avahi 데몬을 통해 _zenoh._tcp 서비스가 7447 포트에서 동작 중임을 브로드캐스트한다.
클라이언트 디스커버리: 다른 네트워크 관리용 노트북이나 감시 스크립트는 Zenoh 코어를 실행할 필요 없이, 가장 흔한 표준 dns-sd 커맨드라인 툴만 쳐봐도 현재 건물 안의 로컬 네트워크 지도를 그려내고 살아있는 Zenoh 라우터들의 IP:포트 리스트를 쭉 뽑아낼 수 있다.

이 방식의 가장 큰 강점은 Zenoh에 대한 1바이트의 사전 지식 없는 범용 IT 모니터링 툴 체인(예: Datadog, 오픈소스 에셋 트래커) 서드파티 앱들도 Zenoh 인프라를 손쉽게 감시하고 맵핑할 수 있게끔 네트워크 가시성(Visibility)의 허들을 확 낮춰준다는 점이다.