1.17 이클립스 모스퀴토 및 기존 프로토콜의 한계

1. 중앙 집중형 브로커 아키텍처의 한계

사물인터넷(IoT) 생태계에서 사실상 표준으로 자리 잡은 MQTT 프로토콜과 그 대표적인 오픈 소스 구현체인 이클립스 모스퀴토(Eclipse Mosquitto)는 경량 메시징 분야에서 큰 성과를 거두었다. 하지만 모스퀴토는 본질적으로 ‘중앙 집중형 브로커(Centralized Broker)’ 토폴로지에 의존한다.

모든 데이터 생산자(Publisher)와 소비자(Subscriber)는 통신을 위해 반드시 동일한 브로커 인스턴스(IP 주소)에 접속해야만 한다. 이러한 구조는 데이터의 궤적이 항상 코어 네트워크를 거치게 만들어 종단 간 지연 시간(End-to-End Latency)을 증가시킨다. 엣지 컴퓨팅(Edge Computing) 환경에서 센서와 제어기가 물리적으로 불과 몇 미터 거리에 있음에도 불구하고 수백 킬로미터 밖의 클라우드 브로커를 경유해야 하는 비효율성이 발생하며, 브로커 노드가 다운될 경우 전체 시스템 통신이 마비되는 치명적인 단일 장애점(Single Point of Failure) 문제가 내재되어 있다.

2. 엄격한 발행/구독(Pub/Sub) 모델의 기능적 제약

모스퀴토를 비롯한 기존 메시지 지향 미들웨어(Message-Oriented Middleware)는 철저하게 발행/구독 패턴(Pub/Sub)에 묶여 있다. 만약 엣지 노드가 분산 저장소(Geo-distributed Storages)나 다른 노드가 지닌 특정 상태 값을 실시간으로 조회하고 싶다면, 질의/응답(Query/Reply) 패턴이 필수적이다.

그러나 MQTT 환경에서 RPC(Remote Procedure Call)나 상태 조회를 구현하려면 임시 토픽(Topic)을 생성하고 응답을 기다리는 복잡하고 불안정한 애플리케이션 레벨의 우회 로직(Workaround)을 작성해야만 한다. 이는 시스템 아키텍처를 불필요하게 복잡하게 만들고 개발 오버헤드를 가중시킨다. 데이터의 이동(Data in Motion)과 데이터의 조회(Data at Rest)를 유기적으로 통합하지 못하는 것은 기존 미들웨어의 가장 뼈아픈 한계이다.

3. 위치 투명성의 부재와 라우팅의 경직성

기존 프로토콜은 데이터의 내용보다 데이터가 도달해야 할 목적지(브로커의 위치)를 먼저 정의해야 한다. 클라이언트는 특정 네트워크 인프라에 결속되어야 하므로 차량 간 통신(V2X)이나 군집 로봇(Swarm Robotics)과 같이 동적 발견(Dynamic Discovery) 메커니즘을 통해 지속적으로 토폴로지가 변하는 엣지 환경에 민첩하게 대응할 수 없다.

Zenoh는 이러한 한계를 극복하기 위해 제안되었다. Zenoh 런타임(Runtime)은 클라이언트(Client), 피어(Peer), 라우터(Router) 모드를 모두 지원하여 브로커가 없는 완벽한 분산형 메쉬(Mesh) 토폴로지를 구성할 수 있다. 또한 하나의 통합된 프로토콜 내에서 발행/구독 모델과 질의/응답(Query/Reply)을 동시에 제공하며, 위치 투명성(Location Transparency)을 보장하는 키 표현식(Key Expression) 라우팅을 수행한다. 결론적으로 기존 모스퀴토 중심의 프로토콜 생태계가 가진 구조적 한계는 제로 오버헤드(Zero Overhead) 원칙을 실현한 Zenoh와 같은 차세대 데이터 중심 네트워킹 인프라로의 진화를 가속화하는 결정적 계기가 되었다.