1.6 데이터 추상화와 다중 통신 의미론(Semantics)

1.6 데이터 추상화와 다중 통신 의미론(Semantics)

분산 시스템의 구조가 복잡해질수록 개발자는 데이터 전송이라는 단일 목표를 달성하기 위해 이질적인 여러 통신 패턴들을 억지로 엮어내는(Stitching) 작업에 시달리게 된다. 예를 들어, 실시간 센서 데이터를 원격지에 배포하기 위해서는 퍼블리시/서브스크라이브(Publish/Subscribe) 패턴인 MQTT나 DDS를 도입하고, 과거의 센서 기록이나 데이터베이스 상태를 조회하기 위해서는 HTTP REST나 gRPC 기반의 쿼리/응답(Query/Reply) 패턴 시스템을 아키텍처에 별도로 추가해야만 했다. 이처럼 데이터 형상과 통신 의미론(Semantics)이 특정 미들웨어 프로토콜에 강하게 결합(Coupled)되어 파편화되는 현상은 오늘날 거대한 에지 투 클라우드(Edge-to-Cloud) 인프라 구축에 있어 가장 큰 걸림돌이 되고 있다.

**Zenoh(제노)**는 이러한 ’통신 패턴의 파편화’를 근본적으로 종식하기 위해 통신 모델을 데이터 관점에서 고도로 추상화(Abstraction)하였다. Zenoh의 네트워크 공간에서 데이터는 단순히 덤 파이프(Dumb Pipe)를 타고 일회성으로 전달된 후 소멸하는 메시지(Message)가 아니라, 네트워크의 위상 어딘가에 온전히 존재하는 **‘리소스(Resource)’**로서 대우받는다.

이러한 논리적 리소스를 유연하게 다루기 위한 언어로써, Zenoh는 단일 프로토콜 스택 내에 데이터 변화를 즉시 밀어내는 푸시(Push) 기반의 퍼블리시/서브스크라이브(Pub/Sub) 의미론과, 데이터의 현재 상태를 능동적으로 당겨오는 풀(Pull) 기반의 쿼리/응답(Query/Reply) 의미론을 동시에, 그리고 완벽하게 통합 지원하는 다중 통신 의미론(Multi-Semantics)을 확립했다.

본 장에서는 Zenoh가 네트워크 상의 원시 데이터를 어떻게 논리적 리소스로 추상화하여 명명(Naming)하는지, 그리고 이 강력한 추상화 위에서 이질적으로 보이던 푸시 모델과 풀 모델이 어떻게 하나의 일관된 철학 아래 융합되어 분산 애플리케이션의 복잡도를 획기적으로 낮추는지 그 혁신적 교리를 상세히 살펴본다.

1. 리소스 표현과 계층적 키 경로(Key Path) 기반 라우팅

네트워크 상의 데이터를 단순한 패킷 단위의 메시지가 아닌 영속적인 의미를 갖는 ’리소스(Resource)’로 취급하려면, 생성된 데이터가 광활한 공간 내에서 유일하게 식별될 수 있는 고유한 주소 체계가 선결되어야 한다. 웹 기술의 기반인 URI(Uniform Resource Identifier)가 인터넷상의 문서(HTML)나 미디어의 위상을 보편적으로 정의하듯, Zenoh(제노) 생태계 내에 존재하는 모든 데이터 리소스는 **‘키 표현식(Key Expression)’**이라 불리는 논리적이고 계층적인 경로(Path) 이름을 부여받게 된다.

1.1 계층적 키 경로(Key Path)의 구조적 이점

계층적 구조를 띠는 키 경로는 사람이 직관적으로 이해하기 쉬울 뿐만 아니라, 분산 지능(Distributed Intelligence)을 갖춘 라우터들이 데이터를 효율적으로 라우팅하고 필터링할 수 있는 가장 이상적인 도구이다. 예를 들어, 거대한 스마트 팩토리에서 특정 로봇 팔 관절의 온도 정보를 나타내는 키 경로는 마치 리눅스 파일 시스템의 디렉터리 경로처럼 factory/section_a/robot_1/sensor/temperature와 같이 논리적으로 설계될 수 있다.

이러한 명명(Naming) 규약은 단순히 데이터를 분류하는 꼬리표 역할을 넘어, 네트워크 내부(In-network)의 지능적인 정보 분배 스케일링을 극대화한다. 만약 클라우드 관제 애플리케이션이 factory/section_a/*/sensor/temperature라는 와일드카드(Wildcard, * 또는 **)를 포함한 정규 키 표현식으로 데이터를 집단 구독(Subscribe)하거나 쿼리(Query)를 발송한다면, Zenoh 네트워크 망에 위치한 라우팅 트리(Routing Tree)는 해당 표현식을 수식으로 해석한다. 그 결과 section_a 하위에 존재하는 수백 대 로봇들의 온도 데이터 프레임만을 즉시 필터링 및 병합(Aggregation)하여 정확히 타깃 노드에게만 전달한다. 애플리케이션 개발자는 각 이종 센서별로 지루한 필터링 제어문 로직을 별도로 작성할 필요가 완전히 소거된다.

1.2 이름 기반 라우팅(Name-based Routing)과 압축 매핑의 마법

더욱 중요한 사실은, Zenoh에서 이 계층적 키 경로가 단순한 응용 계층의 ’식별표’가 아니라 패킷 그 자체를 목적지로 이끌고 나가는 통신망 기저의 물리적 이정표 역할을 수행한다는 점이다. 고전적인 IP와 포트(Port) 번호에 의존하여 핑퐁을 치는 것이 아니라, 패킷의 앞단에 붙어 있는 이 리소스의 ’이름(Name)’만을 판별하여 십자로의 스위칭 방향을 결정하는 네임드 데이터 네트워킹(NDN) 철학이 바로 이 지점에서 발현된다.

다만, 초당 수만 번 진동하며 전송되는 10 바이트 센서 페이로드 패킷마다 factory/section_a/robot_1/sensor/temperature라는 40바이트 이상의 긴 문자열 헤더를 짐처럼 온전히 싣고 다니는 것은 1.5.1장에서 천명한 ‘최소한의 오버헤드(Minimal Overhead)’ 설계 원칙에 치명적으로 위배된다.

이 모순을 타파하기 위해 Zenoh는 통신 당사자인 노드들이나 중간 라우터들 간에 긴 문자열(String) 형태의 키 경로를 단 몇 바이트(Byte) 수준의 짧은 정수형 식별자인 **숫자 ID(Numeric ID)**로 선제적으로 압축 매핑(Mapping)하는 고도의 동적 인코딩 스키마를 영리하게 내장하고 있다.
초기 세션 수립 시 상호 협의(Negotiation)된 키-ID 매핑 테이블을 통해, 실제 대량의 실시간 데이터 프레임이 오고 갈 때는 긴 계층 경로 문자열은 거둬지고 할당된 숫자 식별자(예: ID 1004) 1~2바이트와 순수 페이로드(Payload) 값만이 유선(Wire) 상으로 극한의 레이턴시(Latency)로 날아다니게 된다. 가장 풍부하고 서술적인 계층형 데이터 추상화(Abstraction)를 개발자에게 선사하면서도, 네트워크 와이어 상의 기계적 오버헤드는 나노미터 단위로 면도해버리는 Zenoh 라우팅 엔진의 마법이다.

2. 고성능 퍼블리시/서브스크라이브(Publish/Subscribe) 모델

거대한 사물인터넷(IoT) 군집망과 실시간 로보틱스 제어 도메인에서, 말단 센서의 상태 변화를 가장 빠르고 유연하게 퍼뜨리는 대규모 분산 통신의 표준 패턴은 여전히 발송자가 데이터를 밀어내는 푸시(Push) 형태의 퍼블리시/서브스크라이브(이하 Pub/Sub) 모델이다.
온도 센서나 자이로스코프가 단 1밀리초 전에 새로운 상태 값(데이터)을 뱉어내었을 때(Publish), 이 데이터의 최신 프레임을 0초에 가깝게 즉각 인지해야 하는 수백 개의 관제 모니터링 노드와 백엔드 트리거들에게 이를 동시 전파(Subscribe)하는 브로드캐스팅(Broadcasting) 관점에서는 이 모델의 효율성을 수직으로 뛰어넘을 수 있는 마땅한 대안이 존재하지 않는다.

2.1 기존 Pub/Sub 프레임워크와의 차별성과 토폴로지 해방

과거의 미들웨어들은 이 Pub/Sub 패턴을 구현함에 있어 극명한 아키텍처적 족쇄를 시스템에 채웠다.
널리 쓰이는 MQTT 프레임워크는 프로토콜 자체가 가볍다는 장점이 있으나, 중앙의 브로커(Broker) 서버가 모든 데이터 패킷을 무조건 모았다가 튕겨내야만 하는 강력한 중앙 집중형 ’스타 토폴로지(Star Topology)’를 강요한다. 이로 인해 수만 대의 단말 트래픽이 병목 지점인 브로커 트리로 몰릴 경우 서버가 여지없이 붕괴되어 전체 네트워크가 마비되는 치명적 한계를 갖는다. 반면 국방 및 항공용 분산 표준인 DDS(Data Distribution Service)는 브로커 없는 완벽한 P2P 멀티캐스트(Multicast)로 막강한 분산 라우팅 성능을 뿜어내지만, 이를 뒷받침하기 위한 극도로 복잡한 QoS(Quality of Service) 설정 정책과 방대한 코어 바이너리 덩치 때문에 메모리가 결핍된 마이크로컨트롤러(MCU)에는 진입조차 허용하지 않는 양극단의 부작용을 낳아왔다.

Zenoh(제노) 산하의 Pub/Sub 모델은 이러한 기존 미들웨어 생태계의 오랜 딜레마를 단칼에 해체해버렸다.
Zenoh망 안에서의 Pub/Sub 데이터 흐름은 특정 망 구성(중앙 브로커가 존재하든 존재하지 않든)의 여부에 전혀 구애받지 않는다. 단말 노드들은 주변에 존재하는 동료(Peer) 노드나 지역 에지 라우터들과 백그라운드 가십(Gossip) 프로토콜을 통하여 자신들의 조용한 관심사(구독하고자 하는 키 표현식)를 동적으로 교환하고 기록한다.

퍼블리셔(Publisher)가 robot/1/telemetry라는 논리적 키로 센서 데이터를 망에 툭 하니 푸시(Push)하는 순간, 백그라운드에 포진한 네트워크의 라우팅 트리가 구독자를 향하여 막힘없는 최단 경로(Shortest Path)를 눈 깜짝할 새 산출해내어 데이터를 복제·분산한다. 폭풍우 상황이나 통신 간섭으로 인해 중간에 특정 라우터 노드가 물리적으로 다운되거나 유선 라인이 단절되더라도, Zenoh 네트워크는 밀리초(msec) 단위로 새로운 우회로(Detour)를 탐색하여 데이터 페이로드를 목적지까지 라우팅해내는 진정한 자가 치유(Self-healing) 기반의 고가용성 매시 통신을 성취해 냈다. 단일 실패 지점(SPoF)이라는 개념 자체가 이 추상화된 모델 앞에서는 완전히 소멸된다.

2.2 푸시(Push) 철학의 정점: 초고성능 스루풋(Throughput) 최적화

Zenoh가 구현한 Pub/Sub 모델의 파괴적인 철학은 수십만 건의 메시지가 우박처럼 초당 쏟아지는 고대역폭 스트리밍 환경에서 그 진가가 정점으로 폭발한다.
현대의 로봇 운영체제(ROS 2)가 수십 메가바이트 크기의 3D 라이다(LiDAR) 포인트 클라우드 배열이나 4K 해상도의 다중 카메라 비디오 프레임을 쉴 새 없이 송출할 때, Zenoh 데몬은 운영체제의 사용자(User) 공간과 커널(Kernel) 간에 빈번하게 데이터를 옮겨 나르며 CPU 사이클을 허비하던 메모리 복사를 원천 차단하는 제로 복사(Zero-copy) 엔진을 가동한다.

나아가 네트워크 소켓(Socket) 버퍼 위로 패킷을 뱉어내기 직전, 작은 크기의 파편화된 다중 퍼블리시 데이터 블록들을 단일한 TCP/UDP 프레임 내로 영리하게 우겨넣어 한 번에 쏘아 올리는 통합 메시지 배치(Message Batching) 최적화 기술을 통해 운영체제의 잦은 컨텍스트 스위칭(Context Switching) 오버헤드를 극단적으로 질식시킨다.
결과적으로 Zenoh는 기존 이더넷(Ethernet) 백본 환경 장비에서 구리선 하드웨어가 낼 수 있는 물리적 대역폭의 99%에 달하는 라인 캡(Line-rate)에 육박하는 초당 수십 기가비트(Gbps) 급 초고성능 스루풋(Throughput)을 달성한다. 그리고 이토록 거친 속도의 마법을 개발자의 응용 단 코드 수정이나 아키텍처 재설계 여부와 무관하게 완전히 투명하게(Transparently) 보장해준다.

3. 분산 컴퓨팅을 위한 쿼리/응답(Query/Reply) 모델

실시간 데이터 스트림을 전송하는 퍼블리시/서브스크라이브(Publish/Subscribe) 패턴만으로는 현대의 복잡한 분산 애플리케이션이 요구하는 모든 비즈니스 로직을 충족시킬 수 없다. 로봇의 현재 배터리 상태를 일회성으로 묻거나, 센서의 과거 이력(History) 데이터를 데이터베이스로부터 추출(Pull)해야 하는 경우, 시스템은 필연적으로 쿼리(Query)를 능동적으로 발송하고 그에 대한 응답(Reply)을 수신하는 패턴을 필요로 한다. 고전적으로 이러한 통신 모델은 RESTful API, gRPC, 혹은 원격 프로시저 호출(RPC) 기반의 클라이언트-서버(Client-Server) 아키텍처를 통해 해결되어 왔다.

그러나 이러한 종래의 쿼리/응답 모델은 대규모 에지 컴퓨팅(Edge Computing) 위상학(Topology) 환경에서는 심각한 한계에 봉착한다. 클라이언트는 데이터를 보유하고 있는 서버의 정확한 물리적 위치(IP 및 포트)를 사전에 알고 연결을 수립(Connection Setup)해야 하며, 만약 여러 대의 서버(예: 분산 데이터베이스 클러스터)가 동일한 데이터를 파편화하여 지니고 있다면 클라이언트가 일일이 쿼리를 날려 수합(Aggregation)하는 극심한 오버헤드를 떠안아야 한다.

3.1 지능적 위치 투명성(Location Transparency)이 가미된 분산 쿼리

**Zenoh(제노)**의 쿼리/응답(Query/Reply) 모델은 네임드 데이터 네트워킹(NDN) 철학을 바탕으로 이 구시대적인 점대점(Point-to-Point) 쿼리 방식의 한계를 완전히 박살 냈다.

Zenoh 네트워크 환경에서 애플리케이션은 대상 서버의 IP 주소에 쿼리를 전송하지 않는다. 대신, 네트워크라는 거대한 추상 공간을 향해 robot/+/battery (모든 로봇의 배터리 상태)와 같은 ‘키 표현식(Key Expression)’ 자체를 쿼리로 발송한다.
쿼리를 수신한 Zenoh 라우팅 인프라는 해당 키 표현식과 일치하는 데이터를 제공할 수 있는 퍼블리셔(Publisher), 캐시 노드, 혹은 데이터베이스 연결 백엔드(Backend)가 네트워크 어디에 위치해 있는지 자체적으로 분석한다. 그리고 가장 가깝거나, 혹은 해당 데이터를 분할 소유하고 있는 모든 대상에게 쿼리를 투명하게 분배(Fan-out)한다.

3.2 분산 응답의 통합: 맵리듀스(MapReduce) 철학의 온프레미스 구현

가장 경이로운 지점은 흩어져 있는 다수의 노드로부터 반환되는 다발적인 응답(Reply) 데이터를 처리하는 방식이다.

클라우드 관제 서버가 factory/sensor/*/temp를 쿼리했을 때, 공장 내 100대의 로봇이 각각 자신의 온도를 응답할 것이다. Zenoh망의 지역 에지 라우터들은 이 100개의 파편화된 응답 패킷을 단순히 클라우드로 무차별 포워딩(Forwarding)하지 않는다. 에지 라우터는 지능적으로 수집된 응답 데이터를 통합(Aggregation) 및 병합하여, 최소화된 트래픽 스트림으로 압축한 뒤 클라이언트에게 돌려준다.

이는 마치 하둡(Hadoop) 생태계의 맵리듀스(MapReduce) 알고리즘이 네트워크 통신 미들웨어 계층의 피와 살이 되어 녹아든 것과 같다. 클라이언트 애플리케이션은 100번의 HTTP 요청 상태를 관리하는 지옥에서 벗어나, 단 1번의 Zenoh 쿼리 함수 호출만으로 분산된 네트워크 전체의 상태를 논리적으로 완벽하게 병합(Merge)된 하나의 컬렉션(Collection)으로 돌려받게 된다.

결과적으로 Zenoh의 다중 통신 의미론(Semantics) 하에서 개발자는 푸시(Push)를 위한 Pub/Sub 프레임워크와 풀(Pull)을 위한 RPC 프레임워크를 분리해서 구축할 필요 없이, 단일 스택 위에서 완벽히 추상화된 두 가지 통신 메커니즘을 상황에 맞게 우아무결하게 혼용할 수 있다.

4. 데이터 저장과 캐싱을 통합하는 분산 스토리지 개념

통신 미들웨어(Middleware)와 데이터베이스(Database)는 소프트웨어 아키텍처 역사상 철저하게 분리된 계층으로 다루어져 왔다. 미들웨어는 현재 발생하는 이동 중인 데이터(Data-in-Motion)를 퍼나르는 역할에 치중했고, 데이터베이스는 정지된 데이터(Data-at-Rest)를 영속적으로 보관하고 검색하는 역할에 국한되었다. 이로 인해 센서 데이터가 발생하여 최종 스토리지에 저장되고 다시 조회되기까지, 시스템은 거추장스러운 데이터 스위칭(Switching)과 파이프라인 연계 작업을 의무적으로 거쳐야만 했다.

**Zenoh(제노)**가 분산 시스템 분야에 던진 가장 충격적이고 혁신적인 개념 중 하나는, 바로 이 통신(Communication)과 저장(Storage)의 경계를 허물고 단일한 데이터 공간(Global Data Space)으로 통합해버렸다는 점이다. 데이터 중심(Data-centric) 패러다임을 극대화한 Zenoh 아키텍처에서는, 네트워크 코어 로직과 스토리지 로직이 하나의 프로토콜 의미론(Semantics) 안에서 완벽하게 파동을 같이 한다.

4.1 네트워크 내 캐싱(In-network Caching)의 무한한 가능성

Zenoh 네트워크망에 연결된 에지 라우터나 피어(Peer) 노드들은 단순한 패킷의 중계기(Relay) 역할에 머물지 않는다. 이들은 각자의 메모리나 로컬 디스크를 활용하여 자신을 통과하는 데이터를 지능적으로 캐싱(Caching)할 수 역량을 지닌다.

예를 들어 차량 간 통신(V2V) 환경에서 선행 차량이 road/obstacle/front라는 긴급 위험 데이터를 퍼블리시(Publish)했을 때, 이 데이터는 후행 차량들에게 전달되는 동시에 주변의 지역 에지 기지국(Zenoh Router) 메모리에 캐시(Cache)로 남는다. 3분 뒤 새롭게 해당 도로에 진입한 차량이 이전의 장애물 정보 이력을 쿼리(Query)하면, 데이터를 발생시켰던 선행 차량은 이미 수 킬로미터(Km) 밖으로 멀리 사라져 연결이 끊겼음에도 불구하고, 에지 기지국이 스스로 캐싱된 스토리지 값을 꺼내어 밀리초(msec) 이내에 즉각 응답(Reply)하게 된다.
이 기능은 지연성 한계에 다다른 고가의 인메모리(In-memory) 솔루션(예: Redis나 Memcached)을 네트워크 인프라단에 별도로 덕지덕지 구축할 필요성을 원천적으로 소멸시킨다.

4.2 스토리지 백엔드(Backend)의 플러그인화: 영속성의 투명화

메모리 캐시를 넘어선 영구적인 시계열 데이터(Time-series Data)나 로그 기록 관리가 필요할 때, Zenoh는 자체적으로 무거운 데이터베이스 엔진을 밑바닥부터 다시 짜는 어리석음을 범하지 않았다. 대신, 현존하는 뛰어난 스토리지 솔루션들을 Zenoh 생태계 안으로 흡수(Plug-in)시키는 스토리지 백엔드(Storage Backend) 아키텍처를 창안했다.

Zenoh 라우터에는 InfluxDB, PostgreSQL, MySQL, RocksDB 등 다양한 데이터베이스 엔진을 연동할 수 있는 백엔드 플러그인이 존재한다. 개발자가 특정 라우터에 InfluxDB 백엔드를 연동하고 sensor/telemetry/** 키 경로를 매핑해 둔다면, 네트워크 어디선가 센서들이 해당 경로로 배포(Publish)하는 모든 데이터는 별도의 추가 삽입(Insert) 쿼리 작성이나 서버 로직 없이 자동으로 투명하게 InfluxDB에 시계열로 축적된다.

역으로, 클라우드 대시보드에서 sensor/telemetry/temp/last_hour 데이터를 쿼리(Query)하면, Zenoh 라우터는 이 질의 패킷을 수신해 내부 플러그인을 거쳐 InfluxDB의 SQL 쿼리로 자동 변환하여 데이터를 추출하고, 그 결과를 다시 Zenoh 패킷으로 감싸 클라우드로 올려보낸다. 애플리케이션 개발자는 하단에 깔린 데이터베이스가 PostgreSQL인지 RocksDB인지 알 필요가 없으며, 오직 일관된 Zenoh의 데이터 추상화 인터페이스 하나만으로 통신과 저장 스키마를 유기적으로 완벽하게 통제하게 된다.