다른 통신 모델과의 비교 (MQTT, AMQP, REST vs DDS)

현대의 분산 시스템 아키텍처, 특히 사물인터넷(IoT), 산업 자동화(IIoT), 국방 및 항공우주 분야의 미션 크리티컬 시스템을 설계함에 있어 통신 미들웨어의 선택은 시스템의 성패를 가르는 가장 기초적이면서도 결정적인 요소이다. 개발자와 시스템 아키텍트는 종종 MQTT(Message Queuing Telemetry Transport), AMQP(Advanced Message Queuing Protocol), REST(Representational State Transfer)와 같은 기술들 사이에서 선택의 기로에 놓인다. 이 기술들은 모두 데이터를 한 지점에서 다른 지점으로 이동시킨다는 표면적인 목적을 공유하지만, 그 탄생 배경, 설계 철학, 데이터 처리 방식, 그리고 제공하는 품질 보증(Quality of Service) 수준에서 근원적인 차이를 보인다.

본 장에서는 DDS의 위치를 명확히 하고 여타 통신 프로토콜과의 차별점을 규명하기 위해, 현재 산업계에서 널리 사용되는 주요 통신 모델들과 DDS를 다각도로 비교 분석한다. 이는 단순한 스펙 비교를 넘어, 각 프로토콜이 데이터를 바라보는 철학(Philosophy), 아키텍처(Architecture), 그리고 시스템의 복잡성을 제어하는 방식에 대한 심층적인 고찰을 포함한다. 이를 통해 독자는 단순한 기능 목록의 나열이 아닌, 구축하고자 하는 시스템의 본질적 요구사항에 부합하는 최적의 통신 모델을 선정할 수 있는 통찰력을 얻게 될 것이다.

1. 통신 패러다임의 철학적 차이: 데이터 중심 대 메시지 중심

통신 미들웨어를 이해하는 첫 번째 열쇠는 각 기술이 ’데이터’를 어떻게 정의하고 관리하는지에 대한 관점, 즉 패러다임의 차이를 파악하는 것이다. 이 차이는 시스템 내에서 상태(State)를 관리하는 주체가 누구인지, 데이터의 흐름을 제어하는 책임이 누구에게 있는지에 대한 아키텍처의 근본적인 방향성을 결정짓는다.

1.1 ) 메시지 중심(Message-Centric) 모델: MQTT와 AMQP

MQTT와 AMQP는 대표적인 메시지 중심(Message-Centric) 미들웨어이다.1 이 패러다임에서 미들웨어의 핵심 역할은 ’메시지’라는 컨테이너를 배달하는 운송 수단(Transport)으로 정의된다. 시스템의 관점에서 메시지 안에 담긴 내용(Payload)은 불투명한(Opaque) 바이너리 데이터 덩어리일 뿐이며, 미들웨어는 그 내용에 대해 관여하지 않는다.2

운송 수단으로서의 역할: 미들웨어는 우체부와 유사한 역할을 수행한다. 메시지 헤더에 명시된 주소(토픽 또는 큐 이름)를 기반으로 목적지까지 정확하게 배달하는 것에 집중한다. 그 내용이 텍스트인지, 이미지인지, 혹은 시스템을 중단시키는 긴급 명령인지는 미들웨어의 관심사가 아니다. 이는 유연성을 제공하는 듯 보이지만, 데이터의 해석과 검증 책임을 전적으로 애플리케이션에 전가하는 결과를 낳는다.3
애플리케이션의 책임 가중: 데이터의 구조를 파싱(Parsing)하고, 데이터 타입의 정합성을 검증하며, 데이터 간의 논리적 관계를 관리하는 모든 로직이 송신자와 수신자 애플리케이션 내에 구현되어야 한다. 예를 들어, MQTT를 사용하는 시스템에서 온도 데이터를 보낼 때, 이것이 섭씨인지 화씨인지, 정수형인지 부동소수점형인지는 프로토콜 레벨에서 정의되지 않으므로 개발자가 별도의 문서를 통해 약속하고 애플리케이션 코드 레벨에서 이를 처리해야 한다.5
상태 관리의 부재: 메시지 브로커는 기본적으로 메시지를 전달하고 나면 그 임무를 완료한 것으로 간주한다. 물론 MQTT의 Retain 메시지나 AMQP의 영속성 큐(Persistent Queue)가 존재하지만, 이는 데이터의 ’상태’를 관리한다기보다는 메시지의 ’보관’에 가깝다. 시스템 전체의 현재 상태(예: 모든 밸브의 개폐 여부)를 파악하기 위해서는 애플리케이션이 스스로 상태를 추적하고 데이터베이스 등을 통해 관리해야 한다.5

1.2 ) 리소스 중심(Resource-Centric) 모델: REST

웹 기술의 표준인 HTTP를 기반으로 하는 REST는 리소스 중심(Resource-Centric) 패러다임을 따른다.6 여기서 데이터는 URI(Uniform Resource Identifier)로 식별되는 ’자원(Resource)’으로 추상화된다.

상태 전이(State Transfer): 클라이언트는 서버에 존재하는 리소스의 현재 상태를 요청(GET)하거나, 새로운 상태로 전이(POST, PUT, DELETE)시키기 위해 명시적인 행위를 수행한다.
요청/응답(Request/Response) 구조: 기본적으로 동기식(Synchronous) 구조를 가지며, 이는 데이터가 필요할 때마다 클라이언트가 능동적으로 서버에 질의해야 함을 의미한다. 폴링(Polling) 방식의 데이터 조회는 실시간성이 중요한 시스템에서 불필요한 네트워크 트래픽과 지연을 유발하는 주요 원인이 된다.7
문서 지향적 교환: 주로 JSON이나 XML과 같은 사람이 읽기 쉬운 텍스트 포맷을 사용한다. 이는 상호운용성과 디버깅 용이성을 높여주지만, 기계 간(M2M) 고속 통신에서는 파싱 오버헤드와 대역폭 낭비를 초래한다.8

1.3 ) 데이터 중심(Data-Centric) 모델: DDS

DDS는 이들과 완전히 궤를 달리하는 데이터 중심(Data-Centric) 미들웨어이다.1 DDS에서 미들웨어는 단순한 메시지 배달부가 아니라, 분산된 환경에서 데이터의 저장소 역할을 수행하는 분산 관계형 데이터베이스와 유사하게 동작한다.

데이터 인식과 타입 시스템: DDS는 교환되는 데이터의 구조(Schema)와 타입(Type)을 명확히 인지한다. IDL(Interface Definition Language)을 통해 정의된 데이터 모델은 컴파일 타임에 타입 안전성(Type Safety)을 보장하며, 미들웨어는 전송되는 데이터가 구조체인지, 배열인지, 그리고 어떤 필드가 식별자(Key) 역할을 하는지 이해한다.10 이는 시스템이 커지고 복잡해질수록 데이터 통합의 비용을 획기적으로 낮춘다.
글로벌 데이터 공간(Global Data Space): DDS의 가장 강력한 개념적 특징은 ’글로벌 데이터 공간’이다. 물리적으로 네트워크에 분산된 노드들은 마치 하나의 거대한 공유 메모리(Shared Memory)에 접근하는 것처럼 데이터를 읽고 쓴다.9 애플리케이션 개발자는 “메시지를 보낸다“는 행위 대신, “데이터 객체의 값을 갱신한다(Write)“는 관점으로 접근한다. 수신 측 역시 “메시지를 받는다“가 아니라 “데이터의 변경 사항을 통지받는다“는 개념으로 동작한다.
인프라에 의한 상태 관리: 이것이 DDS와 타 프로토콜의 가장 결정적인 차이이다. DDS 미들웨어는 데이터의 라이프사이클(생성, 갱신, 삭제)과 최신 상태(Last Value)를 직접 관리한다. 새로운 참여자(Late Joiner)가 네트워크에 들어오면, 애플리케이션의 개입 없이 미들웨어가 자동으로 과거의 이력 데이터나 현재의 최신 상태 값을 동기화해준다.4

핵심 통찰 (Key Insight):

메시지 중심 모델이 “A가 B에게 무엇을 보냈다“라는 **이벤트(Event)와 행위(Action)**에 초점을 맞춘다면, 데이터 중심 모델인 DDS는 “시스템 내 데이터 X의 현재 상태는 Y이다“라는 **사실(Fact)과 상태(State)**에 초점을 맞춘다. 시스템의 규모가 커질수록, 개별 메시지의 전달 경로를 관리하는 것보다 데이터의 상태를 일관성 있게 유지하는 것이 훨씬 더 복잡한 문제이다. DDS는 이 복잡성을 미들웨어 계층으로 흡수하여 애플리케이션 코드를 단순화하고 시스템의 결합도(Coupling)를 낮춘다.

2. 아키텍처 및 토폴로지 비교: 중앙 집중 vs 분산

통신 모델이 채택한 물리적, 논리적 연결 구조(Topology)는 시스템의 성능(Performance), 확장성(Scalability), 그리고 생존성(Survivability)을 결정짓는 핵심적인 아키텍처 요소이다.

2.1 ) 브로커 기반(Broker-Based) 아키텍처: MQTT와 AMQP

MQTT와 AMQP는 일반적으로 중앙 집중형 브로커(Centralized Broker) 아키텍처를 기반으로 동작한다.1

허브 앤 스포크(Hub-and-Spoke) 구조: 모든 메시지는 반드시 브로커를 거쳐야 한다. 게시자(Publisher)가 보낸 메시지는 브로커에 도달한 뒤, 브로커의 라우팅 로직에 따라 적절한 구독자(Subscriber)나 큐(Queue)로 전달된다.
장점:
네트워크 토폴로지의 단순화: 클라이언트는 오직 브로커의 주소만 알면 된다. 복잡한 네트워크 환경, 특히 NAT(Network Address Translation)나 방화벽 뒤에 있는 장치들을 연결할 때, 중앙 브로커에 대한 아웃바운드 연결 하나만으로 양방향 통신이 가능해진다.9
클라이언트 부하 감소: 메시지 필터링, 큐잉, 재전송 관리 등의 복잡한 작업을 브로커가 전담하므로, 엣지 디바이스(Edge Device)의 리소스 사용량을 최소화할 수 있다. 이는 MQTT가 저사양 센서에 적합한 이유이기도 하다.
단점 (구조적 취약성):
단일 실패 지점(SPOF): 브로커가 중단되면 전체 네트워크 통신이 마비된다.10 클러스터링이나 이중화(HA)를 통해 이를 완화할 수 있으나, 이는 인프라 구축 비용과 운영 복잡도를 증가시킨다.
지연 시간(Latency) 및 병목: 모든 통신이 ’게시자 → 브로커 → 구독자’의 2단계 홉(Hop)을 거쳐야 하므로, 물리적으로 직접 연결하는 것보다 지연 시간이 필연적으로 증가한다. 또한, 네트워크 트래픽이 급증할 경우 중앙 브로커가 병목 구간(Bottleneck)이 되어 전체 시스템의 성능을 저하시킬 수 있다.11

2.2 ) 클라이언트-서버(Client-Server) 아키텍처: REST

REST는 웹의 기본 원리인 클라이언트-서버 모델을 따른다.

요청 주도형 통신: 클라이언트가 서버에 연결하여 자원을 요청하는 구조이다.
아키텍처적 한계: IoT와 같은 다대다(N:N) 통신 환경에서는 비효율적이다. N개의 센서가 데이터를 공유하려면 각 센서가 서버 역할을 하거나 중앙 서버에 데이터를 모아야 하는데, 이는 실시간 데이터 분배보다는 데이터 수집 및 조회 서비스에 더 적합하다. 서버가 클라이언트에게 비동기적으로 이벤트를 푸시(Push)하기 위해서는 롱 폴링(Long Polling)이나 웹소켓(WebSocket)과 같은 별도의 메커니즘이 필요하다.3

2.3 ) 버스(Bus) 및 피어-투-피어(P2P) 아키텍처: DDS

DDS는 브로커가 없는(Broker-less) 피어-투-피어(Peer-to-Peer) 아키텍처를 채택한다.1 DDS 미들웨어는 별도의 서버 프로세스가 아니라, 애플리케이션에 링크되는 라이브러리 형태로 존재한다.

직접 통신(Direct Communication): 통신에 참여하는 노드들은 자동 검색(Discovery) 과정을 통해 서로의 존재와 엔드포인트 정보를 교환한 뒤, 실제 데이터 전송 단계에서는 중개자 없이 소켓을 통해 직접 데이터를 주고받는다.
장점:
초저지연(Ultra-Low Latency): 중간 경유지가 없으므로 물리적 네트워크 속도에 근접한 최소한의 지연 시간을 달성할 수 있다. 이는 실시간 제어 루프나 고빈도 트레이딩과 같은 시스템에서 필수적이다.13
단일 실패 지점 제거와 생존성: 특정 노드나 네트워크 세그먼트에 장애가 발생하더라도, 나머지 노드 간의 통신에는 전혀 영향을 주지 않는다. 중앙 서버가 존재하지 않으므로, 전장(Battlefield)이나 재난 현장과 같이 인프라가 파괴될 수 있는 환경에서도 시스템의 기능을 유지할 수 있다.14
무한한 수평적 확장성: 중앙 처리 장치가 없으므로 노드가 추가되어도 성능 병목이 발생하지 않는다. 네트워크 대역폭이 허용하는 한 시스템을 무제한으로 확장할 수 있다.
단점:
검색 트래픽의 복잡성: 초기 연결 설정을 위해 멀티캐스트(Multicast)를 주로 사용하는데(SPDP), 이는 클라우드 환경이나 일부 관리형 네트워크에서 지원되지 않거나 과도한 트래픽을 유발할 수 있다.15 (최신 DDS 구현체들은 이를 해결하기 위해 Discovery Server, Unicast Discovery 등 다양한 옵션을 제공한다.)

[표 1-1] 주요 통신 아키텍처 비교 요약

특성	MQTT / AMQP	REST	DDS
기본 아키텍처	중앙 집중형 (Broker)	클라이언트-서버	분산형 (Peer-to-Peer)
통신 패턴	Pub/Sub (Broker 경유)	Request/Response	Pub/Sub (직접 통신)
단일 실패 지점 (SPOF)	브로커 (치명적 취약점)	서버	없음 (높은 생존성)
지연 시간 (Latency)	중간 (2 Hops + 처리시간)	높음 (TCP Handshake 등)	매우 낮음 (1 Hop)
주요 용도	텔레메트리, IT 통합, 클라우드 수집	웹 서비스, 모바일 앱 연동	국방, 항공, 로봇, 제어 시스템

3. 상세 프로토콜별 기술적 심층 분석

각 프로토콜의 내부 메커니즘과 DDS와의 구체적인 차이점을 기술적 관점에서 심층 분석한다.

3.1 ) MQTT vs DDS: IoT의 두 거인, 서로 다른 지향점

MQTT와 DDS는 종종 IoT 프로토콜의 양대 산맥으로 비교되지만, 그 기술적 지향점은 명확히 구분된다.

토픽 구조와 데이터 타이핑 (Topic & Typing):
MQTT: 계층적 문자열(Hierarchical String) 기반의 토픽(예: factory/line1/temp)을 사용하며, 와일드카드(+, #)를 통한 유연한 구독을 지원한다.6 그러나 페이로드는 단순한 바이트 배열(Byte Array)이다. 이는 송수신자가 데이터의 내부 포맷(JSON, XML 등)을 사전에 약속하고 애플리케이션 레벨에서 파싱해야 함을 의미한다. 이는 **’느슨한 결합(Loose Coupling)’처럼 보이지만, 실제로는 데이터 포맷에 대한 ‘강한 의미적 결합(Semantic Coupling)’**을 유발하며, 시스템 변경 시 양쪽 코드를 모두 수정해야 하는 부담을 준다.5
DDS: 토픽은 이름뿐만 아니라 **데이터 타입(Data Type)**과 결합된다. IDL로 정의된 구조체가 토픽의 스키마가 되며, 이는 컴파일 타임에 검증된다. XTypes 표준을 통해 데이터 타입이 변경되더라도(예: 필드 추가), 기존 애플리케이션과의 하위 호환성을 유지할 수 있는 체계적인 진화 메커니즘을 제공한다.16
상태 보존 전략: Retain vs Durability:
MQTT Retain: MQTT는 Retain=True 플래그를 통해 브로커가 해당 토픽의 마지막 메시지 단 하나를 저장하게 한다. 새로운 구독자가 접속하면 이 마지막 값을 즉시 수신한다.17 이는 센서의 현재 값 공유 등에는 유용하지만, 과거의 이력을 분석하거나 복잡한 초기화 데이터를 전달하기에는 부족하다.
DDS Durability & History: DDS는 훨씬 정교한 지속성 모델을 제공한다. Durability QoS는 데이터가 휘발성인지(Volatile), 메모리에 남을지(Transient-Local), 디스크에 저장될지(Persistent)를 제어한다. 이를 History QoS와 결합하여, 단순히 마지막 1개가 아니라 최근 N개의 데이터(Keep-Last) 또는 **모든 데이터(Keep-All)**를 늦게 합류한(Late Joiner) 노드에게 전달할 수 있다.19 이는 블랙박스 기록장치나 트렌드 분석 시스템 구현에 필수적이다.
생존 확인 메커니즘: LWT vs Liveliness:
MQTT LWT (Last Will and Testament): 클라이언트가 비정상적으로 연결이 끊겼을 때, 브로커가 미리 지정된 ‘유언’ 메시지를 대신 발행하여 다른 클라이언트들에게 장애 사실을 알린다.21 이는 사후 대응적인 알림 방식이다.
DDS Liveliness: DDS는 능동적이다. 주기적인 하트비트(Heartbeat) 패킷을 통해 참여자의 생존을 감시하며, Liveliness QoS를 통해 생존 확인의 주체(자동 또는 수동)와 민감도를 설정한다. 연결이 끊기면 on_liveliness_changed 이벤트가 즉시 발생하며, 더 나아가 Deadline QoS를 통해 데이터가 정해진 주기 안에 갱신되지 않으면 경고를 발생시키는 등 **시스템의 건전성(Health)**을 실시간으로 모니터링한다.9

3.2 ) AMQP vs DDS: 엔터프라이즈 트랜잭션과 실시간 제어의 경계

AMQP는 금융 거래와 같은 비즈니스 트랜잭션의 신뢰성을 위해, DDS는 물리적 장비의 실시간 제어를 위해 탄생했다. 이 태생적 차이는 기능 구현에서 극명하게 드러난다.

신뢰성과 트랜잭션 (Reliability & Transaction):
AMQP: 메시지의 **유실 없는 전달(Reliability)**과 순서 보장에 최우선 순위를 둔다. 트랜잭션(Transaction)을 지원하여, 여러 메시지가 모두 처리되거나 아니면 모두 취소되는 원자성(Atomicity)을 보장한다.24 큐(Queue)를 사용하여 소비자가 메시지를 처리할 때까지 데이터를 안전하게 영속화한다.
DDS: **실시간성(Real-time)**과 **적시성(Timeliness)**이 최우선이다. DDS의 Reliability QoS는 RELIABLE뿐만 아니라 BEST_EFFORT를 핵심적으로 지원한다. 제어 시스템(예: 미사일 추적)에서는 “오래된 데이터를 재전송받아 100% 신뢰성을 맞추는 것“보다 “일부 패킷이 유실되더라도 가장 최신의 데이터를 지연 없이 받는 것“이 더 중요하기 때문이다.6 DDS는 데이터가 유효한 시간을 지정하는 Lifespan QoS를 통해 오래된 데이터가 자동으로 폐기되도록 한다.12
흐름 제어 (Flow Control):
AMQP: 소비자(Consumer)가 처리할 수 있는 만큼만 메시지를 보내는 크레딧 기반(Credit-based) 흐름 제어를 강력하게 지원한다. 소비자가 “준비됨” 신호를 보내야 브로커가 메시지를 전송한다.26
DDS: 송신 측의 FlowController를 통해 네트워크 대역폭을 점유하는 속도를 조절하거나(Traffic Shaping), 수신 측의 TimeBasedFilter를 통해 필요한 데이터의 최소 간격을 설정하여 스스로 부하를 조절한다. 이는 시스템 전체의 실시간성을 해치지 않으면서 네트워크 폭주를 막는 방식이다.27

3.3 ) REST vs DDS: 정적 자원과 동적 스트림

REST와 DDS는 시스템 아키텍처 관점에서 상호 보완적일 수 있으나, 데이터 전송 효율성 면에서는 비교가 불가피하다.

통신 오버헤드 (Overhead):
REST: 매 요청마다 HTTP 헤더를 전송하고, 텍스트 기반(JSON/XML) 인코딩을 수행하며, TCP 연결 설정/해제(Keep-alive를 쓰더라도) 비용이 발생한다. 이는 수 밀리초(ms) 단위의 고속 데이터 교환에는 지나치게 무겁다.8
DDS: RTPS(Real-Time Publish Subscribe) 와이어 프로토콜은 바이너리 직렬화(CDR: Common Data Representation)를 사용하고, UDP 위에서 동작하며, 필요시 제로 카피(Zero Copy) 전송을 지원하여 오버헤드를 극한으로 줄였다. 벤치마크 결과에 따르면 동일한 데이터 전송 시 DDS는 REST 대비 수십 배 이상의 처리량과 낮은 지연 시간을 보인다.13
결합도 (Coupling):
REST: 클라이언트는 서버의 주소(IP/Port/URL)를 정확히 알아야 한다(공간적 결합). 또한 서버가 응답할 때까지 기다려야 한다(시간적 결합).
DDS: 게시자와 구독자는 서로의 존재를 모른다. 시간적으로도 분리되어 있다(Durability 사용 시). 이러한 완전한 **비동기적 분리(Decoupling)**는 시스템의 구성요소를 독립적으로 개발, 배포, 업그레이드할 수 있게 하여 대규모 시스템의 복잡도를 낮추는 핵심 요인이다.27

4. 서비스 품질(QoS) 정책의 비교: 제어의 깊이와 넓이

DDS가 다른 통신 모델과 가장 차별화되는, 그리고 DDS를 ‘DDS답게’ 만드는 핵심은 바로 방대하고 세밀한 QoS(Quality of Service) 정책이다.

MQTT/AMQP의 한계: MQTT는 QoS 레벨을 3단계(0, 1, 2)로 단순화하여 네트워크 전송의 신뢰성만을 제어한다. AMQP는 트랜잭션과 큐의 영속성 등을 제어하지만, 이는 주로 ’데이터 유실 방지’에 초점이 맞춰져 있다.5
DDS의 포괄적 제어: DDS는 20가지 이상의 QoS 정책을 제공한다. 이는 데이터 전송의 신뢰성뿐만 아니라, 데이터의 수명, 시스템 리소스 사용량, 네트워크 우선순위, 소유권 분쟁 해결 등을 포괄적으로 제어한다.

[표 1-2] 주요 프로토콜별 QoS 기능 상세 매핑

QoS 범주	정책 (Policy)	MQTT	AMQP	DDS	비고
전송 신뢰성	Reliability	3단계 (0, 1, 2)	Ack 기반 보장 (At-least-once 등)	Reliable, Best-Effort	DDS는 시간 제약 내의 신뢰성 보장 가능
데이터 지속성	Durability	Retain (Last 1)	Queue (영구 보관)	Volatile, Transient, Persistent	DDS는 History와 결합하여 정교한 제어
데이터 수명	Lifespan	(일부 버전 지원)	TTL (Time To Live)	데이터별 자동 만료 시간 지정	DDS는 만료된 데이터를 수신측에 전달하지 않음
실시간성	Deadline	없음	없음	주기적 갱신 강제 및 위반 알림	제어 시스템의 안전장치 역할
리소스 관리	Resource Limits	브로커 설정 의존	큐 크기 설정	샘플/인스턴스 개수 제한 설정	메모리 사용량의 결정론적 제어 가능
필터링	TimeBasedFilter	없음	없음	최소 수신 간격 설정 (부하 조절)	수신자가 송신 속도를 제어하는 효과
소유권	Ownership	없음 (Last write wins)	없음	Exclusive (강도 기반), Shared	이중화된 센서/시스템의 Active-Standby 구현

분석: DDS의 Deadline, LatencyBudget, TimeBasedFilter, Ownership 같은 QoS는 실시간 시스템의 물리적 제약 조건과 비즈니스 로직을 소프트웨어 레벨의 **계약(Contract)**으로 정의할 수 있게 해준다. 이는 MQTT나 AMQP가 흉내 낼 수 없는 DDS만의 독보적인 영역이며, 복잡한 시스템 통합 시 발생할 수 있는 문제를 사전에 예방하는 강력한 도구이다.5

5. 성능(Performance) 및 확장성(Scalability) 벤치마크 분석

성능은 단순히 “누가 더 빠른가“의 문제가 아니라, “어떤 부하 상황에서 시스템이 안정적으로 동작하는가“의 문제이다.

지연 시간 (Latency):

DDS의 우위: 브로커를 거치지 않는 P2P 통신과 가벼운 UDP 기반의 전송 덕분에 DDS는 경쟁 프로토콜 대비 압도적인 저지연 성능을 보인다. 100Gb 이더넷 환경에서의 벤치마크 결과, DDS는 마이크로초(µs) 단위의 지연 시간을 기록한 반면, 브로커를 경유하는 MQTT와 Kafka는 수십에서 수백 배 높은 지연 시간을 보였다.29 특히 1:N 멀티캐스트 통신에서 그 차이는 더욱 벌어진다.
결정론적(Deterministic) 성능: DDS는 실시간 OS(RTOS) 위에서 동작할 때 지터(Jitter)가 매우 적은 결정론적 성능을 제공하여, 예측 가능한 제어 시스템 구축을 가능하게 한다.

처리량 (Throughput):

확장성: 1명의 게시자가 다수의 구독자에게 데이터를 보낼 때, MQTT/AMQP 브로커는 구독자 수만큼 메시지를 복제해서 보내야 하므로 부하가 선형적으로 증가한다. 반면, DDS는 IP 멀티캐스트를 활용하여 패킷 하나만 네트워크에 던지면 하드웨어 레벨에서 복제가 일어나므로, 구독자가 수천 명으로 늘어나도 송신자의 부하가 거의 증가하지 않는다.30 이는 대규모 분산 시스템에서 DDS가 탁월한 확장성을 갖는 이유이다.
데이터 크기에 따른 효율: 작은 크기의 텔레메트리 데이터뿐만 아니라, LiDAR나 영상과 같은 대용량 데이터 전송에서도 DDS는 제로 카피(Zero Copy) 기술 등을 통해 높은 처리량을 유지한다.13

네트워크 대역폭 효율:

MQTT는 헤더가 매우 작아(최소 2바이트) 대역폭이 극도로 제한된 네트워크(위성, 저전력 무선)에서 유리할 수 있다.25 그러나 데이터 갱신 빈도가 높거나 다수의 수신자가 존재하는 경우, 멀티캐스트를 사용하는 DDS가 전체 네트워크 대역폭 사용량 측면에서 훨씬 효율적일 수 있다.

6. 보안(Security) 아키텍처 비교

IoT 시대에 보안은 선택이 아닌 필수이다. 각 프로토콜은 서로 다른 계층에서 보안을 해결한다.

MQTT/AMQP/REST: 주로 전송 계층 보안(TLS/SSL)에 의존한다.24 이는 파이프(Pipe) 자체를 암호화하는 방식이다. 클라이언트 인증은 가능하지만, “누가 어떤 토픽에 읽기/쓰기 권한이 있는지“에 대한 세밀한 제어(Authorization)는 브로커의 구현체마다 다르거나 애플리케이션 로직에 의존해야 한다. 또한 중앙 브로커가 공격당하면 전체 보안이 뚫릴 위험이 있다.
DDS Security: OMG DDS Security 표준은 데이터 중심 보안을 제공한다.
세분화된 접근 제어: 도메인 참여자별로, 그리고 토픽별로 읽기/쓰기 권한을 아주 세밀하게 제어할 수 있다.
플러그인 아키텍처: 인증(Authentication), 접근 제어(Access Control), 암호화(Cryptography), 로깅(Logging) 등을 플러그인 형태로 제공하여, 시스템 요구사항에 맞춰 커스터마이징이 가능하다.2
데이터 페이로드 암호화: 전체 패킷을 암호화할 수도 있고, 성능을 위해 헤더는 두고 데이터 페이로드만 암호화하거나, 특정 서브메시지만 암호화하는 유연성을 제공한다.

7. 결론 및 제언: 적재적소의 미들웨어 선정 전략

지금까지 살펴본 바와 같이, 모든 상황에 완벽한 단 하나의 만능 프로토콜은 존재하지 않는다. 각 기술은 해결하고자 하는 문제 영역에 최적화되어 진화해왔다.

[표 1-3] 상황별 프로토콜 선정 가이드

고려 사항	추천 프로토콜	이유
미션 크리티컬 / 실시간 제어	DDS	초저지연, SPOF 없음, QoS를 통한 실시간성 보장 (국방, 로봇, 자율주행)
대규모 데이터 분산 (1:N)	DDS	멀티캐스트 지원으로 트래픽 효율 및 확장성 우수
불안정한 네트워크 / 저전력	MQTT	가벼운 헤더, Keep-Alive, 저전력 운용에 최적화 (원격 센서)
단순 텔레메트리 수집	MQTT	구현이 쉽고, 브로커를 통한 중앙 수집이 용이함
엔터프라이즈 통합 / 트랜잭션	AMQP	큐잉, 트랜잭션 보장, 이종 시스템 간의 안정적 메시지 교환 (금융, 서버 백엔드)
웹/모바일 연동 / 공공 API	REST	웹 표준 준수, 방화벽 친화적, 범용적인 클라이언트 지원

결론적으로, **DDS는 단순한 메시징 프로토콜이 아니라 ‘데이터 중심의 실시간 분산 소프트웨어 버스’**로 정의할 수 있다. MQTT나 AMQP가 IT 시스템의 데이터를 나르는 ‘배관(Plumbing)’ 역할을 한다면, DDS는 시스템 전체의 상태를 실시간으로 공유하고 제어하는 ‘신경망(Nervous System)’ 역할을 수행한다.

복잡한 분산 시스템을 설계하는 아키텍트는 이러한 차이를 명확히 이해하고, 시스템의 요구사항—지연 시간, 신뢰성, 확장성, 네트워크 환경—을 면밀히 분석하여 최적의 도구를 선택하거나, 필요하다면 여러 프로토콜을 적절히 혼용(Gateway 사용 등)하는 지혜를 발휘해야 한다.9 이어지는 제2장에서는 이러한 DDS의 강력한 기능들이 어떤 아키텍처 모델(DCPS) 위에서 구현되는지 구체적으로 살펴볼 것이다.

8. 참고 자료

Messaging Technologies for the Industrial Internet and the Internet …, https://www.omg.org/news/whitepapers/Messaging-Whitepaper-v2.1.pdf
Understanding IoT Protocols and Matching Requirements - Solace, https://solace.com/blog/understanding-iot-protocols-matching-requirements-right-option/
MQTT vs REST: Which Is The Best Communication Protocol For IoT?, https://www.cloud.studio/mqtt-vs-rest-the-best-protocol-for-iot/
Message Protocols: Data-Centric vs. Data-Centric - EEJournal, https://www.eejournal.com/2015/04/20/message-protocols-data-centric-vs-data-centric/
DDS vs. MQTT vs. VSL for IoT, https://www.net.in.tum.de/fileadmin/TUM/NET/NET-2019-10-1/NET-2019-10-1_01.pdf
Navigating IIoT Protocols: Comparing DDS and MQTT - RTI, https://www.rti.com/blog/comparing-dds-and-mqtt
CoAP, MQTT, AMQP, XMPP & DDS: Which Protocol Should You …, https://www.nexpcb.com/blog/different-data-protocols-which-one-to-choose
A Performance Analysis of Internet of Things Networking Protocols, https://www.mdpi.com/2076-3417/11/11/4879
DDS and MQTT: Basics, Challenges and Integration Benefits - EMQX, https://www.emqx.com/en/blog/navigating-dds-basics-limitations-and-integration-with-mqtt
Bridging OpenDDS® and MQTT Messaging - Object Computing, Inc., https://objectcomputing.com/resources/publications/mnb/2022/06/01/bridging-opendds-and-mqtt-messaging
(PDF) DM-MQTT: An Efficient MQTT Based on SDN Multicast for …, https://www.researchgate.net/publication/327610389_DM-MQTT_An_Efficient_MQTT_Based_on_SDN_Multicast_for_Massive_IoT_Communications
How Does DDS Compare to other IoT Technologies?, https://www.dds-foundation.org/features-benefits/
A Survey on Experimental Performance Evaluation of Data … - arXiv, https://arxiv.org/pdf/2310.16630
Connext DDS and the Industrial IoT: The Top 5 Things to Know - RTI, https://www.rti.com/blog/connext-dds-and-the-industrial-iot-the-top-5-things-to-know
Discovery configuration — Eclipse Cyclone DDS, 0.11.0, https://cyclonedds.io/docs/cyclonedds/latest/config/discovery-config.html
Why Choose DDS? - DDS Foundation, https://www.dds-foundation.org/why-choose-dds/
MQTT Last Will Explained + Example - Cedalo, https://cedalo.com/blog/mqtt-last-will-explained-and-example/
Last Will and Testament | MQTT Broker - ThingsBoard, https://thingsboard.io/docs/mqtt-broker/user-guide/last-will/
Durability - OpenDDS 3.27.0, https://opendds.readthedocs.io/en/dds-3.27/devguide/shapes/durability.html
3.1.2.1. Standard QoS Policies - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/v2.14.5/fastdds/dds_layer/core/policy/standardQosPolicies.html
Understanding the MQTT Protocol: A Deep Dive into Topics, QoS …, https://prezi.com/p/v1iam-ickbxr/understanding-the-mqtt-protocol-a-deep-dive-into-topics-qos-levels-and-lwt/
MQTT Will Message (Last Will & Testament) Explained and Example, https://www.emqx.com/en/blog/use-of-mqtt-will-message
Quality of Service - OpenDDS 3.29.1, https://opendds.readthedocs.io/en/dds-3.29.1/devguide/quality_of_service.html
PERFORMANCE ANALYSIS OF DATA PROTOCOLS OF INTERNET …, https://acadpubl.eu/jsi/2017-115-6-7/articles/6/6.pdf
A Comparative Evaluation of AMQP, MQTT and HTTP Protocols …, https://www.researchgate.net/publication/355205575_A_Comparative_Evaluation_of_AMQP_MQTT_and_HTTP_Protocols_Using_Real-Time_Public_Smart_City_Data
Ten Benefits of AMQP 1.0 Flow Control - RabbitMQ, https://www.rabbitmq.com/blog/2024/09/02/amqp-flow-control
AMQP vs Data Distribution Service (DDS) - what is better? - Quora, https://www.quora.com/AMQP-vs-Data-Distribution-Service-DDS-what-is-better
FlowControllerExamplePublisher.cs, https://d2vkrkwbbxbylk.cloudfront.net/sites/default/files/rti-examples/rticonnextdds-examples/examples/connext_dds/custom_flow_controller/cs/FlowControllerExamplePublisher.cs
Comparing the Performance of Zenoh, MQTT, Kafka, and DDS, https://zenoh.io/blog/2023-03-21-zenoh-vs-mqtt-kafka-dds/
Evaluating DDS, MQTT, and ZeroMQ Under Different IoT Traffic …, http://www.dre.vanderbilt.edu/~gokhale/WWW/papers/M4IoT2020.pdf