통신 미들웨어의 진화와 OMG 표준화

현대 컴퓨팅 환경, 특히 국방, 항공우주, 산업 자동화, 자율 주행과 같은 미션 크리티컬(Mission-Critical) 도메인에서 분산 시스템(Distributed System)의 복잡성은 기하급수적으로 증가해 왔다. 수천 개의 센서, 제어 장치, 연산 노드가 실시간으로 데이터를 교환해야 하는 환경에서, 단순한 ’연결’을 넘어선 ’지능적인 데이터 분배’는 시스템의 생존을 결정짓는 핵심 요소다. 데이터 분산 서비스(DDS, Data Distribution Service)는 이러한 진화의 정점에 있는 표준 기술이다. 본 장에서는 DDS가 등장하기까지 통신 미들웨어가 겪어온 기술적 진화의 역사와 실패의 교훈들, 그리고 객체 관리 그룹(OMG, Object Management Group)을 통해 데이터 중심(Data-Centric) 통신 패러다임이 어떻게 표준화되었는지를 심도 있게 분석한다.

1. 미들웨어의 부재와 혼돈: 소켓(Socket) 프로그래밍의 시대

분산 컴퓨팅의 태동기에는 ’미들웨어’라는 개념조차 희미했다. 1980년대 초반, 네트워크 통신의 주류는 운영체제가 제공하는 가장 기초적인 네트워크 API인 **소켓(Socket)**을 이용한 직접 프로그래밍이었다. 소켓은 TCP/IP 또는 UDP/IP 스택에 대한 직접적인 제어권을 제공하며, 개발자로 하여금 네트워크 통신의 모든 세부 사항을 수동으로 관리하게 만들었다.1

1.1 (1) 개발자의 부담과 스파게티 코드의 양산

소켓 프로그래밍 환경에서 애플리케이션 개발자는 비즈니스 로직보다 통신 로직을 구현하는 데 더 많은 시간을 할애해야 했다. 데이터를 전송하기 위해서는 메모리 상의 객체를 바이트 스트림(Byte Stream)으로 변환하는 직렬화(Serialization) 과정을 직접 코딩해야 했고, 수신 측에서는 이를 다시 원래의 구조로 복원하는 역직렬화(Deserialization) 코드를 작성해야 했다. 이 과정에서 발생하는 엔디안(Endian) 불일치 문제, 데이터 구조의 정렬(Alignment) 문제, 부동 소수점 표현 방식의 차이 등 하드웨어 아키텍처 간의 이기종성(Heterogeneity)을 해결하는 것은 오롯이 개발자의 몫이었다.

더욱 치명적인 문제는 오류 처리와 흐름 제어였다. 네트워크 패킷의 손실, 순서 뒤바뀜(Out-of-Order), 중복 수신과 같은 네트워크 레벨의 오류를 애플리케이션단에서 처리하기 위해 복잡한 상태 머신(State Machine)을 구현해야 했다. 이는 결과적으로 비즈니스 로직과 통신 로직이 강하게 결합된(Tightly Coupled) ’스파게티 코드’를 양산하는 결과를 초래했다.

1.2 (2) 스토브파이프(Stovepipe) 시스템의 고립

이러한 방식은 소규모 시스템에서는 유효했으나, 시스템의 규모가 커질수록 치명적인 아키텍처적 결함을 드러냈다. 각 서브시스템이 독자적인 통신 프로토콜과 데이터 포맷을 정의하여 사용함에 따라, 시스템 간의 상호 운용성(Interoperability)이 전무한 ‘스토브파이프(Stovepipe)’ 구조가 고착화되었다.2

예를 들어, 미 해군의 초기 전투 시스템에서는 레이더 시스템과 무기 제어 시스템이 서로 다른 사설(Proprietary) 프로토콜을 사용하여, 이들을 통합하기 위해서는 고비용의 변환 게이트웨이를 별도로 개발해야 했다. 이는 유지보수 비용을 급격히 증가시키고, 시스템의 업그레이드와 확장을 가로막는 주요 원인이 되었다. 유지보수의 악몽과 확장성의 한계는 개발자들로 하여금 하위 레벨의 네트워크 복잡성을 추상화해 줄 새로운 계층, 즉 **통신 미들웨어(Communication Middleware)**의 필요성을 절감하게 했다.1

2. 절차적 추상화의 시도: RPC(Remote Procedure Call)

소켓의 복잡성을 해결하기 위해 등장한 첫 번째 혁신은 **RPC(Remote Procedure Call, 원격 프로시저 호출)**였다. 1980년대 중반, 썬 마이크로시스템즈(Sun Microsystems) 등의 주도로 확산된 RPC의 핵심 철학은 “네트워크 통신을 마치 로컬 함수 호출처럼 보이게 만들자“는 투명성(Transparency)에 있었다.4

2.1 (1) 기능 중심(Functional) 통신의 한계

RPC는 클라이언트-서버(Client-Server) 모델을 기반으로 한다. 개발자는 IDL(Interface Definition Language)을 통해 서버가 제공하는 함수의 인터페이스를 정의하고, 컴파일러가 생성해 주는 스텁(Stub)과 스켈레톤(Skeleton) 코드를 통해 네트워크 통신의 세부 사항을 숨길 수 있었다. 이는 분산 프로그래밍의 진입 장벽을 획기적으로 낮추었으나, 본질적인 아키텍처의 한계를 내포하고 있었다.

RPC는 기능(Function) 중심의 통신 모델이다. 클라이언트는 서버가 제공하는 특정 기능(함수)을 호출하고 결과를 기다린다. 이는 클라이언트와 서버 간의 **강한 결합(Tight Coupling)**을 유발한다. 서버의 함수 시그니처가 변경되면 클라이언트 코드도 함께 수정되어야 하며, 이는 대규모 분산 시스템에서 변경 관리를 어렵게 만든다.4

2.2 (2) 동기식 차단(Synchronous Blocking)과 성능 저하

RPC의 가장 큰 기술적 제약은 기본적으로 **동기식(Synchronous)**이며 블로킹(Blocking) 방식으로 동작한다는 점이다. 클라이언트가 요청을 보내면 서버로부터 응답이 올 때까지 클라이언트의 실행 흐름은 멈춘다(Block).

특성	소켓 (Socket)	RPC (Remote Procedure Call)
추상화 레벨	저수준 (Low-level)	프로시저 수준 (Procedure-level)
통신 방식	명시적 패킷 전송	함수 호출 은유 (Metaphor)
결합도	프로토콜 종속적	인터페이스 종속적 (Tight Coupling)
동기화	개발자 구현에 따름	기본적으로 동기식 (Synchronous)
주요 한계	생산성 저하, 오류 취약	지연 시간(Latency) 민감, 연쇄 장애 위험

분산 시스템의 8가지 오류(Fallacies of Distributed Computing) 중 하나인 “지연 시간은 0이다(Latency is zero)“라는 잘못된 가정에 기반한 RPC 모델은, 네트워크 지연이나 서버 장애 시 클라이언트 전체가 멈추는 연쇄 장애(Cascading Failure)를 유발하기 쉬웠다. 또한, 1:1 통신에 최적화된 구조는 하나의 데이터를 다수의 수신자에게 보내야 하는 1:N 통신 환경에서 막대한 대역폭 낭비와 성능 저하를 초래했다. 실시간 데이터 스트리밍이 필수적인 레이더 추적 시스템이나 주식 거래 시스템에서 RPC는 적합한 대안이 될 수 없었다.4

3. 객체 지향의 이상과 현실: CORBA의 흥망성쇠

1990년대, 객체 지향 프로그래밍(OOP)의 부상과 함께 분산 시스템에서도 객체(Object) 단위의 통신을 표준화하려는 거대한 움직임이 일어났다. 그 중심에는 OMG(Object Management Group)가 제정한 **CORBA(Common Object Request Broker Architecture)**가 있었다.

3.1 (1) ORB(Object Request Broker)와 상호 운용성의 꿈

CORBA는 이기종 분산 환경에서 서로 다른 언어(C++, Java, Ada 등)와 운영체제로 작성된 객체들이 투명하게 메서드를 호출할 수 있도록 하는 야심 찬 표준이었다. 그 핵심에는 **ORB(Object Request Broker)**라는 소프트웨어 버스가 있었다. 모든 객체는 ORB에 등록되며, 클라이언트는 객체의 물리적 위치를 몰라도 ORB를 통해 메서드를 호출할 수 있었다. IIOP(Internet Inter-ORB Protocol)라는 표준 프로토콜 덕분에 벤더가 다른 ORB 간의 통신도 가능해졌다.6

3.2 (2) 복잡성의 늪과 실시간성의 부재

그러나 CORBA는 ’분산 객체’라는 이상을 실현하기 위해 지나친 **복잡성(Complexity)**을 지불해야 했다. CORBA 사양은 수천 페이지에 달할 정도로 방대했고, 이를 구현한 ORB 제품들은 무겁고 비대했다.

특히 실시간 시스템(Real-Time System) 관점에서 CORBA는 치명적인 약점을 가지고 있었다:

예측 불가능한 지연(Unpredictable Latency): ORB 내부의 마샬링/언마샬링 과정, 동적 메모리 할당, 문자열 처리 등은 실행 시간의 예측 불가능성을 증대시켰다. 이는 결정론적(Deterministic) 반응 속도가 생명인 무기 제어 시스템이나 항공 전자 시스템에서는 용납될 수 없는 특성이었다.8
중앙 집중식 병목: 논리적으로 ORB를 거쳐야 하는 구조는 통신의 병목 구간이 될 가능성이 높았으며, 단일 실패 지점(Single Point of Failure)의 위험을 내포했다.
QoS(Quality of Service)의 미비: 초기 CORBA는 데이터 전송의 신뢰성이나 우선순위를 세밀하게 제어할 수 있는 표준화된 QoS 정책이 부족했다. RT-CORBA(Real-Time CORBA)가 뒤늦게 제안되었지만, 이미 시장은 CORBA의 복잡성에 등을 돌린 상태였다.5

결국 CORBA는 엔터프라이즈 환경에서는 EJB(Enterprise Java Beans)와 웹 서비스(SOAP, REST)에 밀리고, 임베디드 실시간 환경에서는 성능 문제로 인해 퇴출당하는 수순을 밟게 되었다. 그러나 CORBA가 남긴 IDL(Interface Definition Language)과 데이터 타입 시스템은 이후 DDS 설계의 중요한 밑거름이 되었다.

4. 비동기 메시징의 대두: MOM(Message Oriented Middleware)

CORBA와 RPC의 강한 결합(Tight Coupling) 문제를 해결하기 위해 **MOM(Message Oriented Middleware)**이 등장했다. IBM MQSeries(현재 IBM MQ), TIBCO Rendezvous, JMS(Java Message Service) 등이 대표적인 예다.

4.1 (1) 시간적, 공간적 결합의 해소

MOM의 핵심 혁신은 **메시지 큐(Message Queue)**를 도입하여 송신자와 수신자를 분리한 것이다. 송신자는 수신자가 현재 실행 중인지 신경 쓰지 않고 큐에 메시지를 넣으면 되고(Fire and Forget), 수신자는 자신이 준비되었을 때 큐에서 메시지를 꺼내 처리한다. 이를 통해 비동기(Asynchronous) 통신이 가능해졌고, 시스템 간의 시간적 의존성이 제거되었다.4

또한 MOM은 게시-구독(Publish-Subscribe) 모델을 널리 확산시켰다. 데이터를 생성하는 게시자(Publisher)와 데이터를 소비하는 구독자(Subscriber)는 서로를 몰라도 ’토픽(Topic)’이나 ’주제’를 통해 느슨하게 연결된다. 이는 1:N 또는 N:M 통신을 효율적으로 지원하며 시스템의 확장성을 크게 향상시켰다.1

4.2 (2) 중앙 브로커의 한계와 데이터 불투명성

하지만 MOM 역시 국방 및 초고속 산업 제어 시스템의 요구사항을 완벽히 충족시키지는 못했다.

중앙 브로커 병목(Centralized Broker Bottleneck): 대부분의 MOM 아키텍처는 모든 메시지가 중앙 서버(브로커)를 거쳐 가도록 설계되었다. 이는 브로커의 처리 용량이 전체 시스템의 성능 상한선이 됨을 의미하며, 브로커 장애 시 전체 통신이 마비되는 위험이 있었다.
데이터 내용의 불투명성(Opaque Data): MOM은 메시지 내부의 데이터를 단순히 ’이진 블록(Binary Blob)’이나 텍스트로 취급한다. 미들웨어는 데이터의 내용을 이해하지 못하므로, 데이터 값에 따른 필터링(Content-Based Filtering)이나 데이터의 생명주기 관리, 상태(State) 관리를 수행할 수 없었다.
실시간성 부족: 저장-전달(Store-and-Forward) 방식은 필연적으로 지연 시간을 발생시키며, 마이크로초 단위의 초저지연 통신에는 부적합했다.

5. 위기 속의 탄생: 미 해군과 데이터 중심(Data-Centric) 패러다임

2000년대 초반, 미 해군(US Navy)은 차세대 함정 전투 시스템(LPD-17, 이지스함 현대화 등)을 구축하며 심각한 딜레마에 봉착했다. 수천 개의 센서와 무기 체계가 복잡하게 얽힌 환경에서 기존의 RPC, CORBA, MOM 그 어떤 것도 “적절한 데이터를, 적절한 장소에, 적절한 시간 내에(Right Data, Right Place, Right Time)” 전달해야 하는 요구사항을 만족시키지 못했기 때문이다.2

미 해군은 시스템 통합의 복잡성을 줄이고, 벤더 종속성을 탈피하며, 실시간 성능을 보장할 수 있는 **개방형 아키텍처(Open Architecture)**를 갈망했다. 그들이 원한 것은 중앙 서버 없이(Serverless), 피어-투-피어(Peer-to-Peer)로 통신하며, 데이터의 품질(QoS)을 엄격하게 제어할 수 있는 새로운 표준이었다.

이러한 배경에서 등장한 개념이 바로 데이터 중심(Data-Centric) 통신이다. 데이터 중심 통신은 “명령(Instruction)“을 보내는 것이 아니라 “상태(State)“를 공유하는 것에 초점을 둔다. 미들웨어는 단순한 파이프가 아니라, 데이터의 구조와 내용을 이해하고 관리하는 **글로벌 데이터 공간(Global Data Space)**의 관리자가 된다.12

6. OMG 표준화 과정과 DDS의 탄생

미 해군의 강력한 요구와 방위 산업체들의 필요성이 맞물려, 객체 기술 표준화 기구인 OMG(Object Management Group)에 새로운 데이터 분산 표준 제안 요청서(RFP, Request for Proposal)가 발의되었다. 아이러니하게도 객체 중심의 CORBA를 만든 OMG가 데이터 중심의 새로운 표준을 주도하게 된 것이다.

6.1 (1) DDS 사양의 제정 (DDS 1.0 ~ 1.4)

RTI(Real-Time Innovations), Thales, OIS 등 주요 벤더들이 연합하여 공동 제출한 사양은 2003년 6월 OMG에 의해 채택되었고, 2004년 6월 DDS 1.0 공식 표준으로 확정되었다.13

DDS 표준은 크게 두 가지 계층으로 정의되었다:

DCPS (Data-Centric Publish-Subscribe): 데이터 분산의 핵심 계층으로, 토픽(Topic), 게시자(Publisher), 구독자(Subscriber) 등의 엔티티와 QoS 정책을 정의한다. 효율적인 데이터 전달에 초점을 맞춘다.
DLRL (Data Local Reconstruction Layer): DCPS 위에서 데이터를 객체 모델로 재구성해 주는 선택적 계층이다. (이후 버전 1.4에서 별도 사양으로 분리되었다).14

DDS 사양은 지속적으로 개정되어, 데이터 타입 확장성을 위한 DDS-XTypes, 보안을 위한 DDS-Security, RPC 지원을 위한 DDS-RPC 등의 부가 표준들이 추가되며 거대한 생태계를 형성하게 되었다.15

6.2 (2) 상호 운용성의 완성: RTPS 와이어 프로토콜

초기 DDS 1.0 표준은 API(Application Programming Interface)만을 정의하고 있었다. 즉, 애플리케이션 코드는 표준화되었지만, 서로 다른 벤더(예: RTI와 PrismTech)의 DDS 제품끼리는 통신할 수 없었다. 각 벤더가 독자적인 네트워크 프로토콜을 사용했기 때문이다. 이는 진정한 개방형 아키텍처를 저해하는 요인이었다.

이를 해결하기 위해 OMG는 DDSI-RTPS (DDS Interoperability Wire Protocol) 표준을 제정했다. 2006년경부터 논의가 시작되어 2008년 RTPS 2.0이 공식 채택됨으로써, 서로 다른 벤더의 DDS 구현체 간에도 완벽한 상호 운용성이 보장되게 되었다.16 RTPS는 UDP/IP 멀티캐스트를 적극 활용하여 확장성을 극대화하고, 신뢰성 있는 데이터 전송을 위한 긍정/부정 응답(ACK/NACK) 메커니즘을 내장하고 있다. 또한 **SPDP(Simple Participant Discovery Protocol)**와 **SEDP(Simple Endpoint Discovery Protocol)**를 통해 별도의 설정 서버 없이도 네트워크상의 참여자를 자동으로 발견(Discovery)하는 기능을 제공한다.18

7. 요약: 통신 패러다임의 완성형, DDS

통신 미들웨어의 진화 역사는 ’복잡성의 추상화’와 ’결합도의 완화’를 향한 끊임없는 여정이었다. 소켓의 원시적 제어에서 시작하여, RPC의 절차적 추상화, CORBA의 객체 지향적 통합, MOM의 비동기성을 거쳐, 마침내 DDS에 이르러 데이터 중심의 실시간 QoS 통신이라는 완성형에 도달했다.

세대 (Generation)	기술 (Technology)	통신 모델 (Model)	주요 특징 및 한계	DDS로의 진화 요소
제1세대	Sockets	Byte Stream	수동 구현, 높은 복잡성, 스토브파이프화	미들웨어 도입의 필요성 대두
제2세대	RPC	Function Call	동기식 차단, 1:1 강한 결합, 연쇄 장애 위험	비동기 및 1:N 통신 요구
제3세대	CORBA	Distributed Object	중앙집중식 ORB, 무거운 오버헤드, 실시간성 부족	경량화, 탈중앙화, 예측 가능성 요구
제4세대	MOM	Message Queue	비동기 큐, 데이터 내용 불투명, 중앙 브로커 병목	데이터 인지(Data-Aware), 서버리스 구조 요구
제5세대	DDS	Data-Centric Pub/Sub	글로벌 데이터 공간, 풍부한 QoS, 표준 와이어 프로토콜(RTPS)	실시간 데이터 분산의 완성

DDS는 단순한 기술적 대안이 아니라, “네트워크가 곧 데이터베이스다“라는 철학적 전환을 의미한다. 과거의 미들웨어가 애플리케이션 간의 ’행위(Behavior)’를 연결하는 데 집중했다면, DDS는 애플리케이션이 공유해야 할 ‘정보(Information)’ 그 자체에 집중함으로써 시스템의 복잡성을 획기적으로 낮추고 확장성을 극대화했다. 이러한 진화적 배경을 이해하는 것은 DDS의 핵심 아키텍처인 DCPS 모델과 20여 종에 달하는 QoS 정책을 이해하는 데 필수적인 선행 지식이 된다.

8. 참고 자료

Learn About How it Works: Take the CoreDX DDS Data Distribution …, https://www.twinoakscomputing.com/coredx/dds_tour
The Data Distribution Service: Reducing Cost through Agile Integration, https://www.twinoakscomputing.com/wp/DDS_Exec_Brief_v20l-public.pdf
COMP610: Topics in Engineering Enterprise Middleware Platforms, https://cse.hkust.edu.hk/~charlesz/comp610/COMP610.pdf
Message-Oriented Middleware - Edward Curry, https://www.edwardcurry.org/publications/curry_MfC_MOM_04.pdf
CORBA /DDS, COMPETING or COMPLEMENTING …, http://www.dre.vanderbilt.edu/~schmidt/DDS/CORBA-DDS.pdf
(PDF) A case study of Middleware to Middleware: MOM and ORB …, https://www.researchgate.net/publication/229025951_A_case_study_of_Middleware_to_Middleware_MOM_and_ORB_interoperability
Multi-Technology Distributed Objects and their Integration, https://www2.dmst.aueb.gr/dds/pubs/jrnl/2001-CSI-Components/html/imtd.html
The rise and fall of CORBA - ResearchGate, https://www.researchgate.net/publication/220426591_The_rise_and_fall_of_CORBA
comparative evaluation of command distribution via dds and corba …, https://open.metu.edu.tr/bitstream/handle/11511/23531/index.pdf
Message-Oriented Middleware (MOM), https://docs.oracle.com/cd/E19528-01/819-4470/gbpdl/
A Sea-Worthy Standard: 20 Years of DDS for the U.S. Navy - RTI, https://www.rti.com/blog/20-years-of-dds-for-the-u.s.-navy
(PDF) OMG Data-Distribution Service: architectural overview, https://www.researchgate.net/publication/4070720_OMG_Data-Distribution_Service_architectural_overview
OMG Data-Distribution Service (DDS): Architectural Overview - DTIC, https://apps.dtic.mil/sti/tr/pdf/ADA433157.pdf
Data Distribution Service - Wikipedia, https://en.wikipedia.org/wiki/Data_Distribution_Service
The Data Distribution Service | PDF - Slideshare, https://www.slideshare.net/slideshow/the-data-distribution-service-76586756/76586756
What protocol did DDS use before RTPS came about?, https://community.rti.com/forum-topic/what-protocol-did-dds-use-rtps-came-about
About the DDS Interoperability Wire Protocol Specification Version 2.0, https://www.omg.org/spec/DDSI-RTPS/2.0
DDS Standard - HackMD, https://hackmd.io/@st9540808/ry7BLvkKr