현대의 분산 시스템은 단순한 데이터 교환을 넘어 실시간성, 신뢰성, 확장성이라는 복잡한 요구사항을 충족해야 합니다. 이러한 배경 속에서 데이터 분산 서비스(Data Distribution Service, DDS)는 단순한 메시징 프로토콜을 넘어 데이터 중심(Data-Centric) 패러다임을 제시하며 미션 크리티컬 시스템의 핵심 통신 프레임워크로 자리 잡았습니다. 그러나 시스템이 더욱 복잡해지고 이기종 프로토콜과의 연동이 필수적이 되면서, DDS의 강력한 내부 통신 능력을 외부 세계와 연결하는 ‘통합 서비스’의 필요성이 대두되었습니다. 본 보고서의 첫 번째 파트에서는 DDS의 근본적인 철학과 핵심 메커니즘을 분석하고, 이를 통해 왜 전문화된 통합 서비스가 필수불가결한 아키텍처 구성 요소가 되었는지 그 필연성을 탐구합니다.
DDS를 이해하는 첫걸음은 이를 전통적인 메시지 지향 미들웨어(Message-Oriented Middleware, MOM)와 구별하는 것입니다. DDS는 메시지 전송이 아닌 데이터 자체의 상태 공유에 초점을 맞춤으로써 분산 시스템 설계의 근본적인 관점을 전환합니다.
DDS의 통신 모델은 발행-구독(Publish-Subscribe) 패턴에 기반합니다.1 이 모델에서 정보를 생성하는 노드(발행자, Publisher)는 특정 주제(Topic)에 대한 데이터를 발행하고, 해당 정보에 관심 있는 노드(구독자, Subscriber)는 이를 구독하여 데이터를 수신합니다. 이 방식의 가장 큰 장점은 시간과 공간에 대한 느슨한 결합(Loose Coupling)입니다. 발행자와 구독자는 서로의 존재나 위치를 미리 알 필요 없이 동적으로 서로를 발견하고 통신할 수 있습니다.3
여기서 DDS의 핵심적인 차별성이 드러납니다. DDS는 메시지 중심(Message-Centric)이 아닌 데이터 중심(Data-Centric)입니다.4 개발자는 더 이상 저수준의 네트워크 프로그래밍, 즉 소켓 관리, 데이터 마샬링/언마샬링, 재전송 로직 등에 대해 고민할 필요가 없습니다.2 대신, 애플리케이션은 OMG(Object Management Group) 표준에 의해 정의된 고수준의 추상적 객체들을 통해 데이터와 상호작용합니다. 이 객체들은
DomainParticipant, Topic, DataWriter, DataReader 등으로 구성되며, 분산 시스템의 모든 통신은 이들을 통해 이루어집니다.4
DataWriter는 데이터를 발행하는 역할을, DataReader는 데이터를 수신하는 역할을 담당하며, 이들은 특정 Topic과 연관됩니다.3 이러한 추상화는 개발자가 애플리케이션 로직 자체에 집중할 수 있도록 해줍니다.
DDS의 데이터 중심 철학은 ‘글로벌 데이터 공간(Global Data Space)’이라는 개념으로 구체화됩니다.4 이는 물리적으로 분산된 노드들이 마치 하나의 거대한 공유 메모리나 가상 데이터베이스에 접근하는 것처럼 데이터를 읽고 쓸 수 있도록 하는 강력한 추상화입니다. 시스템의 가장 최신 상태(most-current value)가 이 논리적 공간에 존재하며, 미들웨어는 각 참여자에게 필요한 데이터의 부분을 복제하고 일관성을 유지하는 복잡한 작업을 투명하게 처리합니다.4
애플리케이션이 정보를 이 공간에 기여하고자 할 때는 ‘발행자(Publisher)’가 되고, 공간의 일부에 접근하고자 할 때는 ‘구독자(Subscriber)’가 됩니다.8 발행자가 새로운 데이터를 게시할 때마다 미들웨어는 모든 관심 있는 구독자에게 정보를 전파합니다. 이 과정에서 개발자는 메시지를 누가 받을지, 구독자가 어디에 있는지, 메시지 전달 실패 시 어떻게 처리할지와 같은 문제들을 신경 쓸 필요가 없습니다.2
이 글로벌 데이터 공간 내에서 데이터 스트림을 식별하는 기본 단위는 ‘토픽(Topic)’입니다. 토픽은 특정 데이터 항목을 고유하게 식별하는 이름과 데이터 구조를 정의하는 타입(Type)으로 구성됩니다.8 예를 들어, 항공 관제 시스템에서 ‘AircraftTrack’이라는 토픽이 있다면, 각 항공기의 개별 항적 데이터는 ‘키(Key)’라는 고유 식별자를 통해 구분될 수 있습니다.4 키는 데이터 객체 내의 단일 필드(예: 일련번호)일 수도 있고, 여러 필드의 조합(예: 항공사명과 항공편 번호)일 수도 있습니다. 이 키 메커니즘은 DDS가 복잡하고 구조화된 데이터를 효율적으로 관리하고 확장성을 확보하는 핵심적인 방법입니다.4
이러한 아키텍처는 DDS 시스템 설계가 네트워크 토폴로지 설계보다는 데이터베이스 스키마 설계와 더 유사하다는 중요한 관점을 제시합니다. 설계의 기본 단위는 애플리케이션 간의 통신 그래프가 아니라, 인터페이스 정의 언어(IDL)를 통해 정의되는 시스템의 ‘데이터 모델’입니다. 이는 시스템의 진화 가능성에 지대한 영향을 미칩니다. 새로운 애플리케이션은 기존 발행자를 수정하지 않고도 데이터버스에 참여하여 기존 데이터를 활용할 수 있기 때문입니다.
DDS 표준 초기에는 API와 동작 방식은 정의했지만, 네트워크 상에서 메시지를 교환하기 위한 전송 프로토콜, 즉 와이어 프로토콜(Wire Protocol)을 명시하지 않았습니다.1 이로 인해 여러 벤더가 각자의 방식으로 DDS를 구현했고, 서로 다른 벤더의 DDS 제품 간에는 통신이 불가능한 문제가 발생했습니다. 이는 벤더 종속성을 야기하고 개방형 시스템 구축에 큰 걸림돌이 되었습니다.
이러한 상호운용성 문제를 해결하기 위해 OMG는 DDS의 표준 와이어 프로토콜로 RTPS(Real-Time Publish-Subscribe)를 채택했습니다.1 RTPS는 본래 산업 자동화 분야에서 사용되던 검증된 프로토콜로, DDS가 목표로 하는 데이터 분산 시스템의 요구사항을 잘 만족시켰습니다.1 RTPS의 도입은 DDS 생태계에 전환점을 가져왔습니다. 2009년부터 여러 DDS 벤더들이 RTPS 프로토콜을 구현한 제품들 간의 상호운용성을 시연하기 시작했으며, 이는 DDS가 진정한 개방형 국제 표준으로 자리매김하는 데 결정적인 역할을 했습니다.2
API와 동작을 정의하는 DDS 표준과 와이어 프로토콜을 정의하는 RTPS 표준을 분리한 것은 매우 전략적인 결정이었습니다. 이는 ‘관심사 분리(Separation of Concerns)’ 원칙의 훌륭한 예시로, 두 개의 다른 계층에서 독립적인 혁신을 가능하게 했습니다. DDS 표준은 애플리케이션이 필요로 하는 풍부한 데이터 중심의 의미론과 QoS 계약에 집중할 수 있었고, RTPS는 서로 다른 벤더 구현체 간에 안정적이고 효율적으로 비트를 전송하는 저수준의 문제를 해결하는 데 집중할 수 있었습니다. 이러한 분리 덕분에 오늘날과 같이 다양한 벤더 제품이 공존하며 상호운용되는 개방형 DDS 생태계가 구축될 수 있었습니다.1
DDS를 단순한 데이터 전송 파이프라인에서 예측 가능하고 미션 크리티컬한 시스템을 구축하기 위한 프레임워크로 격상시키는 가장 중요하고 강력한 기능은 바로 서비스 품질(Quality of Service, QoS)입니다. QoS는 개발자가 분산 애플리케이션 간의 데이터 분산 방식과 시점을 매우 세밀하게 구성할 수 있도록 하는 표준화된 메커니즘입니다.9
DDS는 20가지가 넘는 다양한 QoS 정책을 제공하며, 각 엔티티(Topic, DataWriter, DataReader 등)는 지원하는 정책의 하위 집합을 가집니다.7 이 정책들을 통해 시스템의 비기능적 요구사항을 충족시킬 수 있습니다. 다음은 가장 핵심적인 QoS 정책들입니다.
RELIABLE은 모든 데이터 샘플이 구독자에게 전달되도록 보장하며, 손실된 패킷은 재전송합니다. 반면 BEST_EFFORT는 최대한 노력하지만 데이터 전달을 보장하지는 않으며, 이로 인해 지연 시간이 짧고 오버헤드가 적습니다. 이는 빠른 속도가 신뢰성보다 중요한 경우에 사용됩니다.1VOLATILE은 발행 시점에 활성화된 구독자에게만 데이터를 전송합니다. TRANSIENT_LOCAL은 발행자가 데이터를 로컬에 저장하여, 발행자가 살아있는 동안 늦게 참여한 구독자에게 최신 값을 제공합니다. TRANSIENT와 PERSISTENT는 데이터를 발행자 외부의 영속적인 서비스에 저장하여 시스템 전체가 재시작된 후에도 데이터를 사용할 수 있게 합니다.11KEEP_LAST는 지정된 ‘깊이(depth)’만큼의 최신 샘플만 유지합니다. KEEP_ALL은 리소스 한계에 도달할 때까지 모든 샘플을 보관합니다. 이는 신규 구독자가 과거 데이터를 수신해야 할 때 유용합니다.10lease_duration으로 지정된 시간 동안 데이터 발행이나 활성도 신호가 없으면 해당 참여자는 비활성 상태로 간주되어, 시스템이 노드의 장애를 감지하고 대처할 수 있게 합니다.10OWNERSHIP_STRENGTH 정책과 함께 사용되어, 가장 높은 강도를 가진 DataWriter가 해당 인스턴스의 유일한 소유자가 됩니다.9DDS의 예측 가능성은 요청-제공(Request-versus-Offered, RxO)이라는 핵심적인 매칭 메커니즘에서 비롯됩니다.7 이는 DataReader와 DataWriter 간의 연결이 형성되기 전에 일어나는 일종의 ‘계약 협상’ 과정입니다.
DataReader는 자신이 통신을 위해 ‘요청(request)’하는 최소한의 QoS 수준을 명시합니다. 반대로 DataWriter는 자신이 ‘제공(offer)’할 수 있는 QoS 수준을 명시합니다. DDS 미들웨어는 이 둘을 매칭시킬 때, 제공된 QoS가 요청된 QoS와 호환되는지, 즉 요청을 만족시킬 수 있는지를 확인합니다. 만약 호환되지 않으면, 두 엔티티 간의 통신은 설정되지 않으며, 애플리케이션은 비호환성 상태에 대한 알림을 받을 수 있습니다.7
예를 들어, 한 DataReader가 RELIABILITY QoS를 RELIABLE로 ‘요청’했다면, 이 DataReader는 BEST_EFFORT로 ‘제공’하는 DataWriter와는 절대로 연결되지 않습니다. 마찬가지로, DataReader가 10ms의 DEADLINE을 ‘요청’했는데 DataWriter가 5초의 DEADLINE을 ‘제공’한다면(즉, 5초에 한 번씩만 데이터를 보내겠다고 약속한다면), 이 또한 호환되지 않으므로 연결이 성립되지 않습니다.9
이 RxO 모델은 시스템 통합에서 매우 중요한 역할을 합니다. 이는 신뢰성이나 적시성과 같은 비기능적 요구사항을 코드 내의 암묵적인 가정으로 남겨두는 대신, 미들웨어에 의해 강제되고 검증되는 명시적인 ‘서비스 수준 협약(Service Level Agreement, SLA)’으로 전환시킵니다. 이로써 개발자는 “데이터가 도착하지 않거나 너무 늦게 도착하면 어떡하지?”와 같은 문제를 고민하며 방어적인 코드를 작성하는 대신, 시스템의 동작 보증을 선언적으로 정의할 수 있습니다. 이는 “조용한 실패(silent failure)”, 즉 애플리케이션이 모르는 사이에 데이터가 유실되거나 지연되는 상황을 원천적으로 방지합니다.
DDS의 QoS 정책은 주로 외부 XML 파일을 통해 선언적으로 구성됩니다.13 이 방식은 애플리케이션 코드를 재컴파일하지 않고도 시스템의 동작을 튜닝할 수 있게 해주는 큰 장점이 있습니다. 시스템 관리자는 배포 환경이나 요구사항의 변화에 따라 XML 파일만 수정하여 데이터 흐름의 신뢰성, 실시간성, 리소스 사용량 등을 조절할 수 있습니다.
물론, 프로그래밍 방식을 통해 동적으로 QoS를 설정하는 것도 가능합니다. 애플리케이션 코드는 엔티티 팩토리(예: DomainParticipant)로부터 기본 QoS 값을 가져와 필요한 정책을 수정한 후, 이를 엔티티 생성 시 인자로 전달할 수 있습니다.10 일부 QoS 정책은 엔티티가 생성된 후에도 변경할 수 있지만(mutable), 다른 정책들은 변경이 불가능(immutable)하며, 이는 통신 호환성에 영향을 미칩니다.10
다양한 QoS 정책들은 독립적이지 않으며, 서로 간에 복잡한 트레이드오프 관계를 형성합니다. 예를 들어, RELIABILITY.RELIABLE과 HISTORY.KEEP_ALL 정책은 강력한 데이터 보존 및 전달을 보장하지만, 더 많은 메모리와 네트워크 대역폭을 소모합니다.10 이는 엄격한
LATENCY_BUDGET이나 DEADLINE 요구사항과 상충될 수 있습니다.11 이것은 DDS의 약점이 아니라, 분산 시스템의 근본적인 트레이드오프를 설계자에게 명시적으로 노출시키는 기능입니다. 따라서 ‘최고의’ QoS 프로파일이란 존재하지 않으며, 각 데이터 스트림(예: 제어 명령, 상태 보고, 비디오 스트림)의 고유한 요구사항에 따라 신중하게 균형을 맞춘 최적의 구성이 존재할 뿐입니다. QoS 설계는 단순한 튜닝이 아니라, 시스템 아키텍처 설계의 핵심적인 초기 활동이어야 합니다.
DDS가 제공하는 강력한 데이터 중심 통신은 그 자체로 완결된 생태계를 이룹니다. 그러나 현대의 복잡한 시스템은 단일 기술만으로 구축되지 않습니다. 다양한 프로토콜과 기술 스택으로 구성된 이기종(heterogeneous) 환경에서 DDS 기반 시스템을 외부 세계와 연결하는 것은 피할 수 없는 과제입니다. 이 파트에서는 이러한 이종 시스템 간의 간극을 메우는 ‘브릿지’, 즉 통합 서비스의 아키텍처적 필연성과 구체적인 구현 방안을 심층적으로 분석합니다.
단일 시스템이 아닌 여러 시스템이 결합된 ‘시스템의 시스템(System of Systems)’ 환경에서, 전용 통합 솔루션이 왜 필요한지에 대한 기술적, 사업적 동인을 파악하는 것은 매우 중요합니다.
현대의 시스템은 본질적으로 이기종 환경으로 구성됩니다. 예를 들어, 자율주행 차량 시스템은 차량 내부 통신을 위해 DDS를 사용하고, 로보틱스 프레임워크와 연동하기 위해 ROS2를, 클라우드 서버와 통신하기 위해 MQTT나 WebSockets를, 공장 자동화 장비와 연결하기 위해 OPC UA를 사용할 수 있습니다.15 이처럼 서로 다른 통신 프로토콜을 사용하는 구성 요소들을 통합하는 것은 중대한 과제입니다.
DDS 자체도 이러한 이질성을 내포하고 있습니다. DDS는 ‘도메인(Domain)’이라는 개념을 통해 통신 평면을 논리적으로 격리합니다.7 서로 다른 도메인 ID를 가진 참여자들은 원칙적으로 직접 통신할 수 없습니다. 이는 보안이나 자원 관리를 위해 의도된 기능이지만, 서로 다른 부서나 기능 단위로 개발된 DDS 시스템들을 통합해야 할 때는 오히려 장애물이 됩니다.18
또한, DDS는 근거리 통신망(LAN) 환경에서의 고성능, 저지연 통신(소위 ‘엣지’ 컴퓨팅)에 최적화되어 있습니다. 그러나 인터넷과 같은 광역 통신망(WAN)을 넘나드는 통신이나 리소스가 제한된 클라이언트와의 통신에서는 경량 프로토콜인 MQTT 등에 비해 비효율적일 수 있습니다.15 이러한 ‘엣지 대 클라우드’ 간의 프로토콜 불일치 역시 통합 솔루션의 필요성을 증대시킵니다.
이기종 시스템을 통합하는 접근 방식은 크게 두 가지로 나눌 수 있습니다.
이러한 통합 허브 아키텍처는 잘 알려진 소프트웨어 디자인 패턴인 ‘중재자 패턴(Mediator Pattern)’과 ‘어댑터 패턴(Adapter Pattern)’의 실제 구현 사례로 볼 수 있습니다. 중앙 코어는 각 시스템이 서로를 직접 알 필요 없이 통신을 중재하는 중재자 역할을 수행합니다. 그리고 각 프로토콜을 지원하는 플러그인(eProsima에서는 ‘시스템 핸들’이라 부름)은 특정 시스템(예: ROS2)의 인터페이스와 프로토콜을 중재자가 이해할 수 있는 공통 인터페이스(예: xTypes)로 변환하는 어댑터 역할을 합니다. 이러한 관점은 솔루션의 구조와 장점을 이해하는 데 강력한 프레임워크를 제공합니다.
통합 허브 모델이 효과적으로 작동하기 위한 전제 조건은 모든 프로토콜이 변환될 수 있는 ‘공통 중간 언어’의 존재입니다. eProsima Integration Service는 이 공통 언어로 OMG의 DDS-XTypes(Extensible and Dynamic Topic Types) 표준을 채택했습니다.18
DDS-XTypes는 컴파일 시점에 시스템의 모든 데이터 타입을 미리 알 필요 없이, 런타임에 동적으로 타입을 정의하고 해석할 수 있는 기능을 제공합니다.18 예를 들어, IDL(Interface Definition Language) 파일로부터 런타임에 타입 정보를 읽어와 해당 구조에 맞는 데이터를 생성하고 변환할 수 있습니다. 이러한 동적 타입 처리 능력은 시스템이 진화함에 따라 새로운 데이터 타입이 추가되더라도 통합 서비스 자체를 재컴파일할 필요 없이 YAML 설정 파일 수정만으로 대응할 수 있게 해주는 강력한 장점입니다. 이는 시스템의 유연성과 진화 가능성을 극대화하는 핵심 기술입니다.
eProsima Fast DDS Integration Service는 오픈 소스 기반의 유연하고 설정 중심적인 접근 방식으로 주목받는 솔루션입니다. 이 섹션에서는 eProsima Integration Service의 아키텍처를 분석하고, YAML 파일을 이용한 실제 사용법을 단계별로 살펴봅니다.
eProsima Integration Service의 아키텍처는 매우 명료합니다. 중앙에는 xTypes를 공통 언어로 사용하는 경량의 ‘통합 서비스 코어’가 자리 잡고 있으며, 특정 프로토콜과의 통신은 동적으로 로드되는 플러그인인 ‘시스템 핸들(System Handle)’이 담당합니다.16 이 구조는 새로운 프로토콜을 지원해야 할 때, 해당 프로토콜을 위한 시스템 핸들만 추가하면 되므로 확장성이 매우 뛰어납니다.
현재 공식적으로 지원되는 시스템 핸들은 다음과 같습니다 16:
이 중 Fast DDS 시스템 핸들은 세 가지 주요 사용 사례를 위해 설계되었습니다 18:
eProsima Integration Service의 가장 큰 특징은 모든 통합 로직이 하나의 YAML 설정 파일을 통해 선언적으로 정의된다는 점입니다.18 이는 ‘코드로써의 설정(Configuration-as-Code)’ 철학을 반영하며, 통합 구성을 버전 관리하고 자동화된 배포 파이프라인에 포함시키기 용이하게 합니다.
YAML 파일의 주요 구성 요소는 다음과 같습니다 21:
systems 블록: 통신에 참여하는 미들웨어 시스템을 정의합니다. 각 시스템에는 고유한 이름을 부여하고, type 필드에 미들웨어 종류(예: fastdds, ros2)를 명시합니다. fastdds 타입의 경우, domain_id와 같은 DDS 관련 특정 파라미터를 추가로 설정할 수 있습니다.routes 블록: 데이터가 어떤 시스템에서 어떤 시스템으로 흘러갈지를 정의하는 ‘경로’를 설정합니다. from과 to 필드에 systems 블록에서 정의한 시스템 이름을 지정합니다.topics 블록: 통합의 핵심 로직이 담긴 부분입니다. 여기서 특정 토픽을 다른 이름으로 매핑(토픽 리매핑 또는 에일리어싱)하거나, 서로 다른 데이터 타입을 변환하는 규칙을 정의합니다.예를 들어, ROS2의 std_msgs::msg::String 타입의 데이터를 DDS의 HelloWorld 구조체(문자열 필드 message와 정수 필드 index를 가짐)로 변환하는 시나리오를 생각해 볼 수 있습니다. YAML 설정에서는 ROS2 토픽의 data 필드를 DDS 토픽의 message 필드로 매핑하도록 명시할 수 있습니다.
다음은 eProsima의 공식 예제를 기반으로 한 DDS와 ROS2 간의 브릿지를 구축하는 단계별 튜토리얼입니다.26
전제 조건:
먼저 시스템에 Integration Service, Fast DDS, ROS2 및 관련 시스템 핸들이 올바르게 설치되어 있어야 합니다.26
1단계: 독립 애플리케이션 실행
세 개의 터미널을 엽니다.
터미널 1: ROS2 환경을 소싱하고 ROS2 talker 예제를 실행합니다. 이 talker는 chatter라는 토픽에 문자열 메시지를 주기적으로 발행합니다.
Bash
source /opt/ros/<ROS2_DISTRO>/setup.bash
ros2 run demo_nodes_cpp talker
터미널 2: Fast DDS HelloWorld 예제의 구독자(subscriber)를 실행합니다.
./build/is-examples/dds/DDSHelloWorld/DDSHelloWorld -m subscriber
```
이 단계에서는 두 애플리케이션이 서로 다른 미들웨어와 토픽 이름, 데이터 타입을 사용하기 때문에 통신이 이루어지지 않는 것을 확인할 수 있습니다.26
2단계: YAML 구성 파일 작성
다음 내용으로 fastdds_ros2_helloworld.yaml 파일을 작성합니다. 이 파일은 Integration Service에게 두 시스템을 어떻게 연결할지 알려줍니다.
YAML
systems:
ros2:
type: ros2
dds:
type: fastdds
routes:
ros2_to_dds:
from: ros2
to: dds
topics:
HelloWorldTopic:
type: HelloWorld
route: ros2_to_dds
remap:
ros2:
topic: chatter
type: std_msgs::msg::String
dds:
topic: HelloWorldTopic
이 설정은 ros2 시스템과 dds 시스템을 정의하고, ros2_to_dds라는 이름의 경로를 설정합니다. topics 섹션에서는 ROS2의 chatter 토픽(타입 std_msgs::msg::String)을 DDS의 HelloWorldTopic 토픽(타입 HelloWorld)으로 매핑하도록 지정합니다. Integration Service는 이 정보를 바탕으로 데이터 타입 변환을 자동으로 처리합니다.
3단계: 통합 서비스 실행
터미널 3: ROS2 및 로컬 작업 공간 환경을 소싱한 후, integration-service 명령어를 사용하여 방금 작성한 YAML 파일과 함께 서비스를 실행합니다.
Bash
source /opt/ros/<ROS2_DISTRO>/setup.bash
source install/setup.bash
integration-service fastdds_ros2_helloworld.yaml
서비스가 실행되면, 터미널 1의 ROS2 talker가 발행하는 메시지가 Integration Service를 통해 변환되어 터미널 2의 Fast DDS 구독자에게 성공적으로 수신되는 것을 확인할 수 있습니다. 반대 방향(Fast DDS에서 ROS2로)의 통신도 유사한 YAML 설정을 통해 쉽게 구현할 수 있습니다.26
eProsima Integration Service는 단순한 토픽 브릿징을 넘어 더 복잡한 시나리오도 지원합니다. 예를 들어, 인터넷으로 분리된 두 개의 LAN에 각각 Integration Service 인스턴스를 실행하고 TCP를 사용하도록 설정하면, 두 DDS 도메인 간에 안전한 WAN 터널을 생성할 수 있습니다.18 또한, 발행-구독 모델뿐만 아니라 요청-응답(RPC) 모델인 서비스 호출도 브릿징할 수 있습니다. 이를 통해 ROS2 클라이언트가 Fast DDS 서버가 제공하는 서비스를 호출하는 것과 같은 이기종 서비스 통합이 가능합니다.18
RTI(Real-Time Innovations)는 DDS 시장의 주요 상용 벤더로서, 단일 통합 도구가 아닌 포괄적인 통합 솔루션 에코시스템을 제공하는 전략을 취합니다. 이 섹션에서는 RTI의 접근 방식을 분석하며, 특히 상용 환경에서 요구되는 강력한 도구와 특정 산업 분야에 특화된 솔루션에 초점을 맞춥니다.
RTI의 전략은 단일 바이너리 형태의 통합 서비스를 제공하기보다, 개발, 설정, 모니터링, 배포에 이르는 전체 라이프사이클을 지원하는 통합된 도구와 서비스 제품군을 제공하는 것입니다.28 이는 특정 산업 분야의 고객들이 겪는 통합의 어려움을 줄이고, 강력한 상업적 지원을 통해 안정적인 시스템을 구축할 수 있도록 돕는 ‘전체 제품(Whole Product)’ 전략으로 볼 수 있습니다.
주요 구성 요소는 다음과 같습니다:
RTI Web Integration Service는 DDS 데이터버스와 웹 기술 간의 간극을 메우기 위해 특별히 설계된 상용 제품입니다.30 이 서비스는 수정되지 않은 기존 DDS 애플리케이션과 웹 기반 서비스가 투명하게 통신할 수 있는 표준 기반의 브릿지를 제공합니다.
DataWriter)를 동적으로 생성하거나, 특정 토픽에 단일 데이터 샘플을 JSON 또는 XML 형식으로 발행(write)하고 읽을(read) 수 있습니다.30 이는 상태를 유지할 필요가 없는 간헐적인 데이터 교환에 유용합니다.RTI의 수직적 통합 전략을 가장 잘 보여주는 사례는 자동차 산업을 겨냥한 RTI Connext Drive입니다.35 이는 단순한 브릿지를 넘어, 소프트웨어 정의 차량(Software-Defined Vehicle, SDV) 개발을 위한 완전한 커넥티비티 프레임워크입니다.
Connext Drive는 AUTOSAR Classic, ROS2와 같은 자동차 산업의 핵심 표준을 위한 사전 구축된 통합 툴킷을 제공합니다.36 이를 통해 개발자들은 ADAS, 차세대 E/E 아키텍처와 같은 일반적인 자동차 사용 사례를 개발할 때, 익숙한 에코시스템 아키텍처 내에서 데이터 중심 커넥티비티의 이점을 누릴 수 있습니다. 이는 맞춤형 프로그래밍의 필요성을 없애고, 전체 시스템의 복잡성과 비용을 최소화하며, 성능 저하 없이 미래 지향적인 시스템을 구축할 수 있도록 지원합니다. 특히, Connext Drive는 TUV SUD로부터 ASIL D 수준의 기능 안전 인증을 받은 구성 요소를 포함하고 있어, 양산 차량에 적용 가능한 신뢰성과 안전성을 제공합니다.36
이러한 접근 방식은 RTI가 특정 고부가가치 수직 시장(Vertical Market)에 대해 단순한 기술 제공자를 넘어, 완전한 엔드투엔드 솔루션 파트너가 되려는 전략을 가지고 있음을 명확히 보여줍니다. 이는 고객의 통합 부담을 근본적으로 줄여주고, 강력한 에코시스템을 구축하여 시장에서의 입지를 공고히 하는 효과적인 방법입니다.
지금까지 DDS의 기본 원리와 통합 서비스의 아키텍처 및 구현을 살펴보았습니다. 마지막 파트에서는 기술적 세부 사항을 넘어, 아키텍트가 실제 프로젝트에서 올바른 기술을 선택하고 효과적으로 관리하기 위해 필요한 전략적 의사결정 프레임워크를 제시합니다. 성능, 디버깅, 배포 전략과 같은 실질적인 문제들을 다루며, 다양한 미들웨어 환경 속에서 DDS 통합 서비스의 위상을 명확히 합니다.
DDS 통합 서비스가 모든 문제에 대한 만병통치약은 아닙니다. 아키텍트는 프로젝트의 요구사항에 가장 적합한 도구를 선택하기 위해 다른 미들웨어 기술과의 장단점을 명확히 이해해야 합니다.
결론: 비즈니스 프로세스 및 워크플로우 오케스트레이션에는 ESB를, 실시간 시스템의 시스템(System-of-Systems) 통합에는 DDS 기반 서비스를 사용하는 것이 바람직합니다.
핵심 차이: 글로벌 데이터 공간(DDS) 대 영구적 이벤트 로그(Kafka).
분석: DDS는 데이터의 현재 상태를 분산시키는 데 중점을 둡니다. DDS의 글로벌 데이터 공간은 각 데이터 인스턴스의 최신 값을 담고 있는 분산 캐시와 같습니다.4 이와 대조적으로, Kafka는 이벤트의 분산된 불변 로그(immutable log)입니다. Kafka는 대규모 데이터 파이프라인 처리, 이벤트 소싱(Event Sourcing), 그리고 방대한 양의 이력 데이터를 순차적으로 처리하고 분석하는 데 최적화되어 있습니다.44 두 기술 모두 발행-구독 모델을 사용하지만, 그 근본적인 데이터 모델과 목적은 완전히 다릅니다.
결론: 대규모 데이터 수집, 스트림 처리, 이벤트 이력 분석이 필요할 때는 Kafka를 사용해야 합니다. 실시간 상태 동기화, 분산 제어, 그리고 최신 데이터 값에 기반한 상호작용이 중요할 때는 DDS 기반 서비스를 선택해야 합니다.
이러한 비교 분석을 통해 현대의 복잡한 시스템은 본질적으로 ‘폴리글랏 미들웨어(Polyglot Middleware)’ 환경을 가질 수밖에 없다는 점이 명확해집니다. 즉, 하나의 미들웨어가 모든 요구사항을 충족시킬 수 없으며, 엣지에서는 DDS를, IoT 기기 통신에는 MQTT를, 백엔드 데이터 처리에는 Kafka를 함께 사용하는 것이 일반적입니다. 따라서, 이러한 전문화된 도메인들을 중재하는 ‘통합 서비스’는 선택적 추가 기능이 아니라, 아키텍처의 필수적인 구성 요소가 됩니다.
| 특성 | DDS 통합 서비스 | 엔터프라이즈 서비스 버스 (ESB) | Apache Kafka | MQTT 브릿지 |
|---|---|---|---|---|
| 주요 패러다임 | 데이터 중심 상태 공유 | 서비스 중심 오케스트레이션 | 이벤트 중심 로그 스트리밍 | 메시지 중심 텔레메트리 |
| 아키텍처 | 분산/P2P (내부) + 허브 (외부) | 중앙 집중식 허브/버스 | 분산 클러스터/브로커 | 중앙 집중식 브로커 |
| 일반적 지연 시간 | 마이크로초 ~ 밀리초 | 밀리초 ~ 초 | 밀리초 | 밀리초 ~ 초 |
| 처리량 | 높음 | 중간 | 매우 높음 | 낮음 ~ 중간 |
| 데이터 모델 | IDL 기반 강력한 타입 | 스키마 기반 (XML/JSON) | 스키마 기반 (Avro, Protobuf) | 불투명 페이로드 (Opaque) |
| 핵심 강점 | 실시간 제어, 상태 동기화 | 비즈니스 프로세스 통합 | 대규모 이벤트 이력, 스트림 처리 | 저전력/불안정 네트워크 |
| 주요 사용 사례 | 로보틱스, 자율주행, 국방 | 기업 애플리케이션 통합(EAI) | 빅데이터 파이프라인, 로그 집계 | IoT 센서 네트워크, 모바일 |
다양한 미들웨어 브릿지와 통합 서비스의 존재는 ‘브릿지’ 자체가 성숙하고 필수적인 아키텍처 패턴임을 증명합니다.17 따라서 아키텍트의 고민은 브릿지가 필요한지 여부가 아니라, 어떤 종류의 브릿지가 가장 적합한지를 결정하는 것입니다. 선택지는 상용 서비스, 오픈 소스 도구, 또는 맞춤형 구현으로 나뉘며, 이는 개발 리소스, 기술 지원 요구사항, 성능 목표 등 다양한 요인에 따라 결정되어야 합니다.
아키텍트가 통합 전략을 최종 결정하기 전에 반드시 고려해야 할 실질적인 운영상의 문제들을 다룹니다.
통합 서비스를 도입하는 것은 명백한 트레이드오프를 수반합니다. 메시지는 소스 애플리케이션에서 통합 서비스를 거쳐 목적지 애플리케이션으로 전달되므로, 추가적인 네트워크 홉(hop)과 처리 계층이 생깁니다. 이는 본질적으로 네이티브 통신에 비해 지연 시간을 증가시키고 CPU 및 메모리 리소스를 더 소모하게 만듭니다.15
이 오버헤드의 크기는 사용 사례, 데이터 크기, 통신 빈도에 따라 크게 달라집니다. 하지만 여러 연구에 따르면, 컨테이너화로 인한 오버헤드는 미미할 수 있으며 49, Fast DDS와 같은 최신 DDS 구현체의 성능이 매우 뛰어나기 때문에 브릿지로 인한 추가 지연이 많은 애플리케이션에서 수용 가능한 범위 내에 있을 수 있습니다.52 핵심은 시스템의 가장 중요한 데이터 경로(critical path)에 대해 실제 환경과 유사한 조건에서 벤치마킹을 수행하여 성능 영향을 정량적으로 평가하는 것입니다.
이기종 미들웨어가 연결된 시스템에서 메시지 유실이나 지연이 발생했을 때, 문제의 원인을 찾는 것은 매우 복잡합니다. 장애 지점은 소스 애플리케이션, 소스 미들웨어, 통합 서비스, 목적지 미들웨어, 목적지 애플리케이션, 또는 네트워크 인프라 등 통신 경로의 어느 곳에나 있을 수 있습니다.54
따라서 체계적이고 다층적인 디버깅 접근 방식이 필수적입니다.
네트워크 계층: ping, ipconfig (Windows) 또는 ifconfig (Linux)와 같은 기본 도구를 사용하여 노드 간의 기본적인 IP 연결성을 확인합니다. 멀티캐스트가 필요한 경우, 멀티캐스트 그룹으로의 ping을 통해 라우터 및 스위치 설정을 검증합니다.57
미들웨어 계층: 각 미들웨어 벤더가 제공하는 전문 모니터링 및 디버깅 도구를 적극적으로 활용합니다. RTI Admin Console 3, eProsima Fast DDS Monitor 58, 또는 표준
rtiddsping 유틸리티 57 등을 사용하여 참여자 발견, 토픽 매칭, QoS 호환성 문제를 진단할 수 있습니다. 이러한 도구들은 통신이 실패하는 근본적인 원인(예: QoS 불일치)을 밝혀내는 데 매우 효과적입니다.
애플리케이션/서비스 계층: 통합 서비스와 양 끝단의 애플리케이션에서 상세 로깅(verbose logging)을 활성화하여 메시지의 흐름을 추적합니다.54 로그 메시지에 타임스탬프와 고유 트랜잭션 ID를 포함시키면 여러 시스템에 걸친 메시지의 여정을 추적하는 데 도움이 됩니다.
체계적 격리: ‘분할 정복(Divide and Conquer)’ 기법을 사용하여 장애 지점을 체계적으로 좁혀 나갑니다.59 예를 들어, 먼저 소스 애플리케이션에서 통합 서비스까지의 통신이 정상적인지 확인합니다. 그 다음, 통합 서비스에서 목적지 애플리케이션까지의 통신을 테스트합니다. 이를 통해 문제의 범위를 절반으로 줄여나갈 수 있습니다.
이러한 디버깅의 복잡성은 시스템 설계 단계부터 ‘디버깅 가능성(Debuggability)’을 고려해야 함을 시사합니다. 장애가 발생한 후에 디버깅 방법을 고민하는 것은 너무 늦습니다. 모든 구성 요소에 걸쳐 상관관계가 있는 포괄적인 로깅을 구현하고, 상태 및 헬스 체크 엔드포인트를 노출하며, 개발 및 배포 프로세스에 모니터링 도구 체인을 통합하는 등, 디버깅은 사후 활동이 아닌 시스템의 내재적 아키텍처 속성이 되어야 합니다.
통합 문제를 해결하기 위해 기성 제품(Off-the-Shelf)을 구매할 것인가, 아니면 직접 개발(Build)할 것인가의 결정은 기술적 선택을 넘어선 전략적 판단입니다.
아키텍트는 프로젝트의 예산, 일정, 그리고 통합 구성 요소의 장기적인 전략적 가치를 종합적으로 고려하여 이 ‘Buy vs. Build’ 결정을 내려야 합니다.
본 보고서는 DDS의 데이터 중심 패러다임에서 시작하여, 이기종 시스템 통합의 필요성과 이를 해결하기 위한 통합 서비스의 아키텍처, 구현, 그리고 전략적 고려사항까지 심층적으로 분석했습니다.
기술이 발전함에 따라 시스템은 더욱 자율적이고 상호 연결될 것입니다. 자율주행차가 스마트 인프라와 통신(V2I)하고 15, 로봇 군집이 협력하며, 산업 현장의 디지털 트윈이 실시간으로 동기화되는 미래에는 이기종 시스템 간의 원활한 데이터 통합이 그 어느 때보다 중요해질 것입니다. 이러한 환경에서 DDS 통합 서비스는 실시간 제어 시스템(DDS), 인공지능/머신러닝 프레임워크, 그리고 클라우드 기반 분석 플랫폼 간의 핵심적인 가교 역할을 수행하며 그 중요성이 더욱 커질 것으로 전망됩니다.
복잡한 분산 시스템을 성공적으로 설계하고 구축하기 위해 다음의 원칙을 고려할 것을 권고합니다.
포괄적인 모니터링 및 디버깅 도구 체인에 투자하십시오. 복잡성은 피할 수 없습니다. 시스템의 투명성을 높이고 문제 해결 시간을 단축하기 위한 도구와 프로세스에 대한 투자를 아끼지 마십시오.
| DDS and MQTT: Basics, Challenges and Integration Benefits | EMQ - EMQX, accessed July 6, 2025, https://www.emqx.com/en/blog/navigating-dds-basics-limitations-and-integration-with-mqtt |
| Ways to Integrate DDS & UPC UA for Future Industrial Systems | RTI, accessed July 6, 2025, https://www.rti.com/blog/two-approaches-to-integrate-dds-and-opc-ua-for-future-industrial-systems |
| Integration Service: Integrating Communication Protocols | PPT - SlideShare, accessed July 6, 2025, https://www.slideshare.net/slideshow/integration-service-integrating-communication-protocols/248308508 |
| Middleware Integration of DDS and ESB for Interconnection between Real-Time Embedded and Enterprise Systems | Request PDF - ResearchGate, accessed July 6, 2025, https://www.researchgate.net/publication/221416383_Middleware_Integration_of_DDS_and_ESB_for_Interconnection_between_Real-Time_Embedded_and_Enterprise_Systems |
| Apache Kafka vs. Integration Middleware (MQ, ETL, ESB) | PPT - SlideShare, accessed July 6, 2025, https://www.slideshare.net/slideshow/apache-kafka-vs-integration-middleware-mq-etl-esb/135064421 |
| DDS Performance Study - DDS-Demonstrators | TechPush - Read the Docs, accessed July 6, 2025, https://dds-demonstrators.readthedocs.io/en/latest/Teams/1.Hurricane/performance_measurements_C.html |
| Useful tools to debug DDS issues | Data Distribution Service (DDS) Community RTI Connext Users, accessed July 6, 2025, https://community.rti.com/howto/useful-tools-debug-dds-issues |
| Debugging Tips and Tricks: A Comprehensive Guide | by Shai Almog | Javarevisited, accessed July 6, 2025, https://medium.com/javarevisited/debugging-tips-and-tricks-a-comprehensive-guide-8d84a58ca9f2 |
| Custom Integration vs. Data Integration Platform | Aspirity, accessed July 6, 2025, https://aspirity.com/blog/custom-platform-integration |