1.2.3 DDS(Data Distribution Service)의 뛰어난 성능과 그에 반하는 복잡성

로보틱스 운영체제(ROS 2) 및 고신뢰성 국방·항공우주 망의 사실상 표준(De facto standard) 미들웨어로 자리매김한 데이터 분산 서비스(DDS, Data Distribution Service)는 당초 ‘결코 통신이 실패해선 안 되는’ 크리티컬 도메인(Mission-critical Domain)을 구원하기 위한 목적 하에 탄생했다. 브로커(Broker)라는 단일 장애점(SPoF)을 아키텍처에서 완전히 배제하고, 지능형 노드(Node) 간의 직접적인 순수 P2P(Peer-to-Peer) 오버레이 망을 구축함으로써 극한의 로컬 지연 시간(Latency) 단축과 무결점 타이밍 제어를 성취한 위대한 공학적 결과물이다.

그러나 이 압도적인 로컬 네트워크 통제력과 하드 리얼타임(Hard Real-time)의 무결함을 달성한 대가로, DDS는 현대의 유연한 클라우드 네이티브(Cloud-native) 환경과 거대한 광역망(WAN) 위에서는 도저히 스케일링(Scaling)할 수 없는 무겁고 경직된 통신 인프라 스트럭처의 복잡성(Complexity)이라는 짙은 그림자를 드리우게 되었다. 본 절에서는 DDS 아키텍처가 지닌 모순적인 성능과 한계를 네트워크 및 소프트웨어 공학적 관점에서 해부한다.

1. 자동 디스커버리(Auto-Discovery) 멀티캐스트 폭풍(Storm)이 유발하는 대역폭 포화 억제

DDS가 중앙 서버 없이도 노드들이 자율적으로 통신망을 수립할 수 있는 근간에는 바로 실시간 전송 프로토콜(RTPS, Real-Time Publish Subscribe) 기반의 동적 피어(Peer) 자동 탐색 주기인 디스커버리(Auto-Discovery) 메커니즘이 존재한다. 새로운 로봇이 네트워크에 진입하면, 이들은 수초 단위로 자신과 자신이 퍼블리시(Publish)하거나 구독(Subscribe)하려는 토픽(Topic)들의 정보를 담은 무거운 메타데이터(Metadata) 패킷을 서브넷 전역에 멀티캐스트(Multicast)로 브로드캐스팅(Broadcasting)한다.

네트워크 내 노드가 10대 미만일 때는 이 탐색 패킷의 규모가 시스템에 미치는 영향이 미미하다. 그러나 물류 창고에 투입된 AMR(Autonomous Mobile Robot) 무리가 수십 대에서 수백 대 규모로 스케일 아웃(Scale-out)되는 순간, 상황은 급변한다. 모든 노드가 각자의 디스커버리 패킷을 동시에 멀티캐스트로 난사하면서 전체 네트워크 망에는 거대한 제어 트래픽 해일, 즉 멀티캐스트 폭풍(Multicast Storm)이 발생하게 된다. 이는 실제 제어 명령이나 센서 페이로드(Payload)가 지나가야 할 귀중한 무선 대역폭(Bandwidth)을 헛된 자기소개 패킷만으로 포화(Saturation) 시켜버리는 짐벌락(Gimbal Lock) 사태를 야기하며, 대규모 무선 군집 로보틱스 상용화의 가장 거대한 기술적 족쇄로 작용하고 있다.

2. 정적 인터페이스 정의 언어(IDL) 컴파일 타임 락인(Lock-in)과 개발자 경험의 훼손

네트워크 자원 포화 이외에도, 소프트웨어 엔지니어링 생태계가 DDS를 기피하게 만드는 가장 치명적인 주범은 바로 지독하게 경직된 컴파일 타임(Compile-time) 종속성이다. JSON과 같이 동적(Dynamic)이고 유연한 웹 기반 구조화 포맷을 허용하는 MQTT 등과 달리, 고성능 바이트(Byte) 패킹을 추구하는 DDS는 통신에 참여하는 모든 노드가 사전에 약속된 데이터 구조체만을 사용하도록 강제한다.

// 경직된 DDS IDL(Interface Definition Language) 구조 예시
struct RobotOdometry {
    long robot_id;
    double pos_x;
    double pos_y;
    // 향후 센서 필드가 추가되면 시스템 전체를 가동 중단한 뒤 모든 소스코드를 깨부수고 재생성해야 한다.
};

시스템 설계자는 반드시 무거운 인터페이스 정의 언어(IDL, Interface Definition Language) 파일을 규격에 맞게 작성한 뒤, 특정 벤더(Vendor)에 종속된 코드 제너레이터(Code Generator)를 통해 C++ 혹은 자바(Java) 보일러플레이트(Boilerplate) 코드를 쏟아내야만 한다. 만약 개발 도중에 로봇 오도메트리(Odometry) 데이터에 센서 배터리 규격 필드를 하나 추가하려는 일이 발생하면, DDS 컴포넌트 전체를 멈추고 거대한 파이프라인의 종속성 트리를 완전히 다시 컴파일하여 재배포(Redeployment)하는 고비용의 락인(Lock-in) 지옥을 경험하게 된다.

3. NAT 및 방화벽(Firewall) 통과 불가 현상의 아키텍처적 한계 노출

마지막으로, 인터넷 스케일(Internet Schema) 확장에서 DDS가 직면하는 가장 파괴적인 장벽은 바로 NAT(Network Address Translation) 및 사내 방화벽(Firewall)의 통과 불가라는 벽이다. DDS의 핵심 통신 기작인 UDP(User Datagram Protocol) 멀티캐스트 트래픽은 라우팅의 보안과 캡슐화를 위해 설계된 L3 라우터와 회사 보안 방화벽 밖을 선천적으로 넘어갈 권한이 없다.

따라서 한국의 관제 클라우드 센터에서 독일에 위치한 지능형 로봇의 DDS 로컬 망으로 터널을 뚫어 텔레메트리 데이터를 수집하려면, 보안 부서와 다투며 무작위 인바운드(Inbound) 포트 매핑 범위를 억지로 뚫어내거나, 수천만 원의 가상 사설망(VPN) 인프라를 강제적으로 설치해야만 하는 비효율의 극치를 낳는다. 즉 DDS는 공장 혹은 서브넷(Subnet)이라는 한정된 어항 속에서만 최고의 성능을 발휘할 뿐, 물리적 한계를 허무는 ‘에지-투-클라우드(Edge-to-Cloud)’ 패러다임으로의 직결(Direct Link) 시대에는 전혀 맞지 않는 무거운 공룡의 아키텍처로 전락하고 만 것이다.

이러한 공룡과도 같은 복잡성과 경직성의 구속복(Straitjacket)을 완전히 벗어던진 채, DDS의 무결점 하드 리얼타임 성능은 보존하면서도 동적인 토폴로지 확장과 투명한 네임 기반 라우팅의 가벼움을 하나로 융합한 차세대 미들웨어의 등장은 더 이상 유예할 수 없는 시대적 필연이었다.