현대의 분산 시스템은 로보틱스, 사물 인터넷(IoT), 자동차, 항공우주 등 다양한 분야에서 점점 더 복잡해지고 있습니다. 이러한 시스템들은 종종 서로 다른 통신 프로토콜, 데이터 모델, 프로그래밍 언어를 사용하는 이기종 하위 시스템들로 구성됩니다. 이러한 이질성은 시스템 통합을 매우 어려운 과제로 만들며, 확장성, 유지보수성, 개발 비용 측면에서 심각한 문제를 야기합니다. eProsima Integration Service는 이러한 근본적인 문제에 대한 전략적 해결책으로 등장했습니다.
분산 시스템 통합에서 전통적으로 사용되던 방식은 각 시스템 쌍을 직접 연결하는 ‘포인트-투-포인트(Point-to-Point)’ 브리지를 개발하는 것이었습니다. 이 방식은 연결해야 할 시스템의 수가 적을 때는 직관적이고 간단해 보일 수 있습니다. 그러나 시스템의 규모가 커짐에 따라 이 접근법의 근본적인 한계가 드러납니다.
N개의 서로 다른 시스템을 상호 연결해야 할 경우, 이론적으로 최대 N×(N−1)/2개의 개별 브리지가 필요하게 됩니다. 이는 시스템의 수가 증가함에 따라 개발 및 유지보수해야 할 브리지의 수가 기하급수적으로 늘어나는 ‘조합적 폭발(combinatorial explosion)’을 의미합니다.1 예를 들어, 5개의 시스템을 통합하려면 최대 10개의 브리지가 필요하지만, 10개의 시스템을 통합하려면 최대 45개의 브리지가 필요합니다.
이러한 접근법은 여러 가지 심각한 문제를 야기합니다 2:
이러한 N² 문제는 복잡한 시스템의 진화를 가로막는 주요 장애물이며, 보다 효율적이고 확장 가능한 통합 패러다임의 필요성을 명확히 보여줍니다.
eProsima Integration Service는 앞서 언급된 N² 문제에 대한 근본적인 해결책을 제시합니다.1 이 서비스는 개별 시스템들이 서로 직접 통신하는 대신, 중앙의 허브(Hub)를 통해 메시지를 교환하는 ‘허브-앤-스포크(Hub-and-Spoke)’ 모델을 채택합니다. 이 아키텍처에서 Integration Service는 서로 다른 언어를 사용하는 시스템들 사이에서 메시지를 중개하고 전달하는 중앙 집중식 메시지 전달 도구 역할을 합니다.3
이 모델의 핵심적인 장점은 확장성 문제를 해결하는 방식에 있습니다. 모든 시스템은 오직 중앙의 코어(Core)와만 통신하면 됩니다. 따라서 N개의 시스템을 통합하기 위해 필요한 소프트웨어 구성 요소(플러그인)의 수는 N개에 비례하여 선형적으로 증가합니다.1 이는 포인트-투-포인트 방식의 N² 증가와 극명한 대조를 이룹니다.
이러한 구조적 이점은 단순히 기술적 세부사항에 그치지 않고, 대규모 시스템 통합의 핵심적인 난제인 비용, 복잡성, 장기적인 유지보수성을 직접적으로 해결하는 전략적 결정입니다. 새로운 기술을 시스템에 도입할 때, 해당 기술을 위한 플러그인 하나만 개발하면 기존에 연결된 모든 시스템과 즉시 통신할 수 있게 됩니다. 이는 시스템의 민첩성을 극대화하고 기술 부채를 줄이는 효과적인 방법론을 제공합니다.
eProsima Integration Service는 하루아침에 만들어진 것이 아니라, 실제 산업 현장의 요구를 반영하며 점진적으로 발전해 온 역사를 가지고 있습니다.
이 프로젝트의 전신은 ‘SOSS(System-Of-Systems Synthesizer)’로, 현재도 Integration Service의 핵심 개념을 형성하고 있습니다.1 SOSS는 eProsima와 로봇 운영체제(ROS)의 관리 기관인 Open Robotics 간의 공동 노력으로 탄생했습니다.6 이는 프로젝트 초기부터 로보틱스 분야의 복잡한 통합 요구사항을 해결하는 데 중점을 두었음을 시사합니다.
초기 개발은 유럽 연합(EU)의 Horizon 2020 연구 혁신 프로그램의 일환인 ROS-Industrial(ROSIN)로부터 자금을 지원받는 집중 기술 프로젝트(FTP)로 시작되었습니다. 당시 프로젝트명은 “ROS2 Integration Service”였으며, 주요 목표는 ROS 2를 MQTT, ZeroMQ와 같은 다른 프로토콜과 쉽게 연결하고, WAN/인터넷을 통한 ROS 2 메시지 통신을 가능하게 하는 것이었습니다.8
현재는 eProsima가 단독으로 프로젝트의 유지보수 및 개발을 책임지고 있습니다.6 특히 버전 3.0.0은 이 프로젝트의 중요한 전환점이었습니다. 이 버전에서 SOSS라는 이름에서 공식적으로 eProsima Integration Service로 명칭이 변경되었고, C++ 네임스페이스가 soss::core에서 eprosima::is::core로 변경되는 등 전체적인 프로젝트 구조가 재편되었습니다.5
이러한 발전 과정은 Integration Service가 학술적 연구에 머무르지 않고, 로보틱스 및 산업 자동화라는 까다로운 분야의 실제 문제를 해결하기 위해 설계된, 검증된 솔루션임을 보여줍니다. Open Robotics 및 ROS-Industrial과의 협력은 이 도구의 신뢰성을 높이고, 잠재적 사용자들이 그 성숙도와 적합성을 평가하는 데 중요한 근거를 제공합니다.
eProsima Integration Service의 강력함과 유연성은 그 독창적인 아키텍처에 기인합니다. 이 아키텍처는 프로토콜별 상호작용, 일반적인 메시지 라우팅, 데이터 표현이라는 세 가지 핵심 관심사를 능숙하게 분리하여 높은 수준의 모듈성과 확장성을 달성합니다. 이 섹션에서는 Integration Service를 구성하는 핵심 요소인 코어 엔진, 시스템 핸들, xTypes 공통 언어, 그리고 Mix 파일의 역할과 상호작용을 심층적으로 분석합니다.
Integration Service의 심장부에는 코어 엔진(Core Engine)이 자리 잡고 있습니다.3 코어는 임의의 수의 미들웨어를 연결할 수 있는 플러그인 기반 플랫폼을 제공하는 중앙 허브입니다.3 코어의 주된 책임은 서로 다른 시스템 핸들(System Handle) 간의 메시지를 라우팅하는 것입니다. 중요한 점은 코어 자체가 ROS, DDS, WebSocket과 같은 개별 프로토콜의 세부 사항을 이해하지 못한다는 것입니다. 코어는 오직 모든 시스템 핸들과 공유하는 ‘공통 언어’만을 사용합니다.11
메시지 전달 과정은 다음과 같이 이루어집니다. 소스 시스템 핸들로부터 메시지를 수신하면, 코어의 라우팅 로직이 YAML 설정 파일에 정의된 경로(route)에 따라 목적지 시스템 핸들을 결정하고 해당 메시지를 전달합니다. 예를 들어, Middleware_1에서 Middleware_2로의 경로가 정의된 경우, 코어는 내부적으로 Middleware_1을 위한 TopicSubscriber와 Middleware_2를 위한 TopicPublisher를 등록하여 데이터 흐름을 관리합니다.11 이러한 구조 덕분에 코어는 특정 프로토콜에 종속되지 않고 범용적인 메시지 중개자 역할을 수행할 수 있습니다.
시스템 핸들(System Handle, SH)은 특정 미들웨어나 프로토콜과 Integration Service 코어 사이를 연결하는 프로토콜별 플러그인입니다.3 각 시스템 핸들의 핵심 역할은 대상 프로토콜의 고유한 데이터 타입과 통신 방식을 코어가 이해할 수 있는 공통 표현 언어인 xTypes로 변환하고, 그 반대의 변환도 수행하는 것입니다.3
시스템 핸들은 사용자 애플리케이션의 통신 엔티티(발행자, 구독자, 서버, 클라이언트)에 대한 ‘미러(mirror)’ 프록시를 생성하는 방식으로 작동합니다.6 예를 들어, 사용자 애플리케이션에 발행자(publisher)가 있다면, 시스템 핸들은 해당 발행자의 메시지를 수신하기 위한 구독자(subscriber)를 생성합니다. 반대로 사용자 애플리케이션에 구독자가 있다면, 시스템 핸들은 해당 구독자에게 메시지를 전달하기 위한 발행자를 생성합니다. 서비스 클라이언트와 서버에 대해서도 동일한 원리가 적용됩니다.6
이 플러그인 기반 프레임워크는 시스템 확장을 매우 용이하게 만듭니다. 새로운 프로토콜을 통합해야 할 경우, 개발자는 해당 프로토콜에 대한 시스템 핸들만 새로 작성하면 됩니다. 일단 시스템 핸들이 개발되면, 해당 프로토콜은 이미 지원되는 다른 모든 프로토콜과 즉시 상호 운용성을 갖게 됩니다.1 이는 개발자가 특정 프로토콜을 xTypes로 변환하는 방법에만 집중하면 되도록 하여, 새로운 기술을 통합하는 데 필요한 진입 장벽을 극적으로 낮춥니다.
Integration Service 코어와 모든 시스템 핸들 간의 원활한 통신을 가능하게 하는 기반 기술은 eProsima xTypes라는 공통 언어입니다.1 eProsima xTypes는 Object Management Group(OMG)의 DDS-XTypes (Extensible and Dynamic Topic Types for DDS) 표준을 C++17 기반의 헤더 전용 라이브러리로 구현한 것으로, 빠르고 가벼운 것이 특징입니다.6
xTypes의 가장 중요한 특징은 런타임에 동적 타입(Dynamic Type) 표현을 생성할 수 있는 능력입니다.11 이는 사용자가 YAML 설정 파일에 인터페이스 정의 언어(Interface Definition Language, IDL) 형식으로 데이터 타입을 정의하면, xTypes 파서가 이를 런타임에 해석하여 동적인 데이터 구조를 만들어내는 방식으로 이루어집니다.10
이 동적 타입 기능은 Integration Service 유연성의 핵심입니다. 컴파일 시점에 알지 못하는 임의의 사용자 정의 데이터 구조를 처리할 수 있게 해주기 때문입니다. 정적 타입 시스템을 사용했다면 새로운 메시지 타입이 추가될 때마다 전체 서비스를 다시 컴파일해야 했을 것입니다. 하지만 동적 타입을 사용함으로써, 사용자는 단순히 YAML 설정 파일만 수정하여 새로운 데이터 타입을 시스템에 알리고, 재컴파일 없이 즉시 사용할 수 있습니다. 또한, 시스템은 xTypes 라이브러리의 TypeConsistency 정의를 사용하여 서로 다른 시스템 엔드포인트 간의 타입 호환성을 검사할 수 있습니다.14
아키텍처의 또 다른 중요한 구성 요소는 “Mix” 파일입니다. Mix는 MiddlewareInterfaceExtension의 약어로, 특정 시스템 핸들이 필요로 하는 동적 라이브러리(Linux의 .so, Windows의 .dll) 목록을 담고 있는 파일입니다.4
이 동적 라이브러리에는 미들웨어의 고유 타입(예: ROS 2의 .msg 파일)을 공통 언어인 xTypes 표현으로 변환하거나 그 반대의 변환을 수행하는 구체적인 로직이 포함되어 있습니다.4 즉, 타입 변환의 실제 구현은 이 라이브러리 안에 존재합니다.
Mix 파일은 일반적으로 빌드 과정에서 is_mix_generator라는 CMake 함수에 의해 자동으로 생성되며, Integration Service가 시작될 때 런타임에 로드됩니다.4 이 메커니즘을 통해 시스템은 필요한 타입 변환 기능을 동적으로 로드하여 사용할 수 있습니다.
| 표 1: 아키텍처 구성 요소 개요 |
|---|
| 구성 요소 |
| Integration Service 코어 |
| 시스템 핸들 (SH) |
| eProsima xTypes |
| Mix 파일 |
eProsima Integration Service의 가장 큰 장점 중 하나는 코드 수정이나 재컴파일 없이 텍스트 기반 설정 파일 하나로 전체 시스템의 통합 동작을 정의할 수 있다는 점입니다. 이 섹션에서는 Integration Service 인스턴스를 구성, 설치 및 실행하는 방법에 대한 구체적이고 실행 가능한 지침을 제공합니다.
Integration Service 인스턴스의 모든 동작은 런타임에 로드되는 단일 YAML 파일에 의해 제어됩니다.3 이 접근 방식은 설정과 코드를 명확하게 분리하여, 대규모 시스템에서 다양한 통합 시나리오를 재컴파일 없이 유연하게 적용할 수 있게 해주는 강력한 이점을 가집니다.3
YAML 파일은 여러 개의 필수 및 선택적 최상위 섹션으로 구성됩니다.3 각 섹션은 통합 시스템의 특정 측면을 정의하는 역할을 합니다.
YAML 설정의 핵심은 systems, types, routes 섹션을 통해 통합의 기본 골격을 정의하는 것입니다.
types (선택 사항): 이 섹션에서는 사용자가 IDL(Interface Definition Language) 문법을 사용하여 커스텀 메시지 타입을 YAML 파일 내에 직접 정의할 수 있습니다. 여기에 정의된 내용은 런타임에 파싱되어 동적 타입으로 생성됩니다.10
systems (필수 사항): 통신에 참여하는 각 미들웨어를 나열하고 설정하는 필수 섹션입니다. 각 시스템에는 고유한 별칭(예: ros2_system, dds_system)이 부여되며, 해당 시스템의 type(예: ros2, fastdds, websocket_server)을 명시해야 합니다.6 또한,
types-from 옵션을 사용하여 한 시스템의 타입 정의를 다른 시스템에서 상속받아 타입 재정의를 피할 수 있습니다.6
routes (필수 사항): 시스템 간의 통신 다리, 즉 경로를 정의하는 필수 섹션입니다. 각 경로는 발행/구독(publish/subscribe) 패턴의 경우 from과 to 시스템을, 서비스 요청/응답(server/client) 패턴의 경우 server와 clients를 지정하여 데이터 흐름의 방향을 정의합니다.14
기본 골격이 정의되면, topics와 services 섹션을 통해 실제 데이터를 교환할 대상을 구체적으로 명시해야 합니다.
topics: 브리징할 특정 토픽을 정의합니다. 각 토픽 항목은 반드시 데이터의 type과 사용할 route를 지정해야 합니다. 여기서 type은 types 섹션에 정의되었거나 Mix 파일을 통해 로드된 타입이어야 합니다.6services: 브리징할 특정 서비스를 정의합니다. 토픽과 유사하게 type과 route를 지정합니다.14remap (선택 사항이지만 강력함): topics 또는 services 정의 내에서 사용할 수 있는 매우 강력한 기능입니다. remap을 사용하면 경로에 포함된 각 시스템에 대해 서로 다른 토픽/서비스 이름이나 심지어 다른 타입 이름(단, 타입 구조는 호환 가능해야 함)을 지정할 수 있습니다. 이 기능은 애초에 함께 작동하도록 설계되지 않은 이기종 시스템을 통합할 때 매우 중요합니다.6이처럼 YAML 설정 파일은 단순한 설정 모음이 아니라, 복잡한 다중 프로토콜 시스템의 전체 데이터 흐름과 변환 로직을 하나의 인간이 읽을 수 있는 문서로 선언하는 ‘선언적 통합 언어’의 역할을 합니다. 이는 시스템 문서화, 버전 관리(YAML 파일을 Git으로 관리), 런타임 유연성 측면에서 막대한 이점을 제공합니다.
Integration Service를 사용하기 위해서는 먼저 필요한 의존성을 설치하고 소스 코드를 빌드해야 합니다.
yaml-cpp (YAML 파서)와 boost-program-options (설정 파일 옵션 처리) 라이브러리를 필요로 합니다.6 eProsima xTypes 역시 필수 의존성이지만, 일반적으로 Git 서브모듈로 포함되어 있어 별도 설치 없이 함께 클론됩니다.15FastDDS-SH는 eProsima Fast DDS 라이브러리가 필요합니다.6ROS2-SH는 ROS 2 배포판(예: Foxy, Galactic)이 필요합니다.6WebSocket-SH는 OpenSSL과 WebSocket++ 라이브러리가 필요합니다.6colcon입니다.6 전체 프로세스는 다음과 같습니다:
colcon 작업 공간(workspace)을 생성합니다.Integration-Service 리포지토리를 --recursive 플래그와 함께 클론하여 서브모듈(xTypes)까지 다운로드합니다.src 디렉터리에 클론합니다.colcon build 명령을 실행하여 전체 프로젝트를 빌드합니다.17Integration Service가 독립적인 제품임에도 불구하고 colcon을 권장 빌드 도구로 채택한 것은 이 프로젝트가 ROS 및 로보틱스 생태계와 깊이 연계되어 있음을 보여줍니다. 이는 주된 대상 사용자인 로봇 공학자들의 진입 장벽을 낮추는 효과가 있지만, ROS 환경에 익숙하지 않은 개발자에게는 약간의 학습 곡선이 존재할 수 있습니다.
eProsima Integration Service의 실제적인 힘은 다양한 프로토콜을 지원하는 시스템 핸들(System Handle)에서 나옵니다. 각 시스템 핸들은 특정 미들웨어와의 통신을 전담하는 플러그인 역할을 합니다. 이 섹션에서는 공식적으로 지원되는 각 내장 시스템 핸들의 목적, 주요 설정 옵션, 그리고 활용 사례를 상세히 분석합니다. 이 시스템 핸들들의 조합은 로보틱스와 산업용 사물 인터넷(IIoT)의 교차점에서 발생하는 복잡한 통합 요구사항을 해결하기 위한 전략적 선택을 반영합니다.
domain_id에서 실행되는 두 DDS 애플리케이션 연결. 이는 대규모 시스템에서 네트워크를 논리적으로 분리하는 데 사용됩니다.13participant.domain_id를 통해 DDS 도메인을 지정할 수 있으며, participant.file_path와 profile_name을 사용하여 XML 기반의 커스텀 QoS(Quality of Service) 프로파일을 적용할 수 있습니다.13예제: Fast DDS 발행자의 데이터를 ROS 2 구독자로 전송하는 DDS-ROS 2 브리지 예제가 제공됩니다.13
ROS 1-ROS 2 브리지 생성.20domain_id를 사용하는 ROS 2 노드들 간의 토픽 브리징. 이는 복잡한 로봇 시스템에서 흔히 요구되는 기능입니다.5ros2 시스템 타입은 YAML 파일에서 domain_id 매개변수를 받을 수 있습니다.14의존성: 해당 ROS 배포판 환경이 활성화되어 있어야 합니다(예: ROS 1의 경우 Melodic/Noetic, ROS 2의 경우 Foxy/Galactic).6
목적: WebSocket 프로토콜을 사용하는 웹 기반 애플리케이션이나 다른 원격 서비스와의 양방향 통신을 가능하게 합니다.15
주요 사용 사례:
설정: 보안 통신을 위한 TLS와 비보안 통신을 위한 TCP 엔드포인트를 모두 지원합니다. YAML에서 port, security, 인증서 경로 등을 설정할 수 있습니다.22 WebSocket을 통한 통신 프로토콜은 JSON 기반이며, publish, subscribe, call_service와 같은 동작을 위한 특정 op 코드를 사용합니다.22
Asio, cURLpp, cURL 라이브러리가 필요합니다.6| 표 2: 내장 시스템 핸들 및 주요 세부 정보 |
|---|
시스템 핸들 (type 이름) |
fastdds |
ros1 |
ros2 |
websocket_server / websocket_client |
fiware |
eProsima Integration Service의 진정한 가치는 이론적인 아키텍처를 넘어 실제 산업 현장의 복잡한 문제들을 해결하는 능력에 있습니다. 이 도구는 세 가지 대표적인 적용 시나리오를 통해 그 실용성을 입증하며, 이 시나리오들은 상호 배타적이지 않고 조합하여 더욱 정교한 시스템 아키텍처를 구축하는 빌딩 블록 역할을 합니다.
이는 Integration Service의 가장 일반적이고 기본적인 사용 사례로, 서로 다른 프로토콜을 사용하며 호환되지 않는 타입, 토픽, 서비스를 처리하는 시스템 간의 통신을 가능하게 합니다.3 포인트-투-포인트 브리지의 한계를 극복하고 중앙 집중식 허브를 통해 원활한 데이터 교환을 구현합니다.
ROS 1 - ROS 2 브리지: 많은 로보틱스 프로젝트는 기존의 방대한 ROS 1 자산을 활용하면서 최신 ROS 2의 기능(실시간성, 보안 등)을 도입하고자 합니다. Integration Service는 레거시 ROS 1 시스템과 최신 ROS 2 시스템 간의 토픽과 서비스를 변환하는 안정적인 브리지를 구성하여 점진적인 마이그레이션을 지원합니다.20FIWARE - ROS 2 브리지: 스마트 팩토리나 스마트 시티 환경에서는 FIWARE 기반의 IoT 플랫폼이 로봇과 상호작용해야 하는 경우가 많습니다. Integration Service는 로봇의 센서 데이터를 FIWARE 컨텍스트 브로커로 전송하거나, IoT 플랫폼의 명령을 ROS 2 로봇이 수행하도록 연결하는 역할을 할 수 있습니다.2DDS - ROS 2 브리지 (커스텀 QoS 포함): 이 예제는 단순한 데이터 전달을 넘어, 두 미들웨어 간의 QoS(Quality of Service) 정책을 존중하고 매핑하는 고급 기능을 보여줍니다. 예를 들어, DDS의 RELIABLE QoS를 ROS 2의 신뢰성 있는 통신에 매핑하여 데이터 전달의 신뢰성을 보장할 수 있습니다.20이 시나리오는 동일한 프로토콜을 사용하는 시스템들이지만, 해당 프로토콜의 특정 기능(예: 도메인 ID, 파티션)에 의해 논리적으로 격리된 경우, 이들 간의 통신을 중개하는 데 사용됩니다.3 이는 시스템의 모듈성과 보안을 강화하는 데 중요한 역할을 합니다.
ROS 2 도메인 ID 변경: ROS 2는 DDS의 도메인 ID를 사용하여 논리적으로 분리된 네트워크를 생성합니다. 예를 들어, 자율주행 차량에서 인식 시스템(perception system)과 임무 계획 시스템(mission planning system)을 서로 다른 도메인 ID로 분리하여 상호 간섭을 막을 수 있습니다. 이때 Integration Service는 두 도메인 간의 게이트웨이 역할을 하여, 차량 위치와 같은 특정 토픽만 선택적으로 브리징하고 나머지 트래픽은 격리된 상태로 유지할 수 있습니다.21DDS 도메인 ID 변경: 순수 DDS 시스템에서도 동일한 개념이 적용됩니다. Integration Service를 사용하면 서로 다른 도메인에 속한 DDS 애플리케이션 간에 제어된 데이터 교환을 구현할 수 있습니다.13이 시나리오는 지리적으로 다른 지역에 위치하거나 논리적으로 분리된 광역 통신망(WAN)에 호스팅된 시스템 간의 통신을 가능하게 합니다.3 이는 원격 제어, 클라우드 기반 로봇 관리, 분산 데이터 수집 등 현대적인 애플리케이션에 필수적입니다.
DDS를 통한 WAN-TCP 터널링: 일반적으로 DDS에서 사용하는 UDP 프로토콜은 인터넷과 같은 WAN 환경에서 방화벽이나 NAT 문제로 인해 불안정할 수 있습니다. Integration Service는 이러한 문제를 해결하기 위해 WAN의 양단에 각각 인스턴스를 실행하고, 이들 간의 통신을 TCP 기반 전송으로 설정하여 안정적인 터널을 생성할 수 있습니다. 이를 통해 DDS 트래픽을 인터넷을 통해 안정적으로 터널링할 수 있습니다.13 이 기능은 ROSIN 프로젝트 제안서에서도 핵심 기능으로 강조되었습니다.8이러한 시나리오들의 조합을 통해 Integration Service는 로보틱스, IoT, 자동차, 그리고 기타 미션 크리티컬 애플리케이션에 매우 적합한 도구임이 입증되었습니다.12 eProsima가 유럽남방천문대(ESO), 르네사스(Renesas), Husarion, RRAI 등 다양한 산업 분야의 고객 및 파트너와 협력하고 있다는 사실은 Integration Service를 포함한 자사 기술 스택의 산업적 중요성을 뒷받침합니다.24
프로덕션 환경에 시스템을 배포할 때, 기능적 요구사항만큼이나 성능 및 보안과 같은 비기능적 특성이 중요합니다. eProsima Integration Service는 다른 시스템들을 연결하는 중개자 역할을 하므로, 이 서비스가 추가하는 오버헤드와 보안 모델을 이해하는 것은 아키텍트에게 필수적입니다.
Integration Service 자체의 성능은 단일 수치로 정의되기보다는, 연결되는 전체 데이터 경로의 함수로 이해해야 합니다. 메시지가 거치는 전체 과정, 즉 소스 앱 -->> 소스 미들웨어 -->> 소스 SH -->> 코어 -->> 목적지 SH -->> 목적지 미들웨어 -->> 목적지 앱의 각 단계에서 발생하는 지연 시간의 총합이 최종 성능을 결정합니다.
Integration Service 코어 자체는 독립적인 보안 계층을 구현하지 않습니다. 대신, 보안은 개별 시스템 핸들의 기능에 의해 제공되는 ‘상속된 보안 모델’을 따릅니다.30 이는 강력한 유연성을 제공하지만, 전체 시스템의 보안을 보장해야 하는 아키텍트에게 중요한 책임을 부여합니다.
FastDDS-SH는 Fast DDS가 제공하는 포괄적인 OMG 표준 DDS 보안 플러그인을 활용할 수 있습니다. 이는 업계 최고 수준의 보안 기능을 제공합니다.
DDS:Auth:PKI-DH): 신뢰할 수 있는 인증 기관(CA)을 사용하여 DDS 도메인에 참여하는 각 DomainParticipant를 인증합니다.31DDS:Access:Permissions): 서명된 거버넌스 및 권한 파일을 통해 각 참여자가 어떤 토픽을 읽고 쓸 수 있는지에 대한 세분화된 권한을 정의합니다.31DDS:Crypto:AES-GCM-GMAC): 메시지 페이로드에 대한 인증된 암호화를 제공하여 데이터의 기밀성과 무결성을 보장합니다.31WebSocket-SH는 YAML 설정 파일에서 구성할 수 있는 TLS(Transport Layer Security)를 통해 보안 통신을 지원합니다.22이러한 상속된 보안 모델은 강력하지만, 아키텍트가 종단 간 보안을 신중하게 설계해야 함을 의미합니다. 예를 들어, DDS 보안 기능으로 완벽하게 보호되는 시스템의 특정 토픽을 Integration Service를 통해 보안이 설정되지 않은(security: none 옵션 사용 가능 22) WebSocket 서버로 브리징할 수 있습니다. 이 경우, 해당 데이터 경로에 대한 DDS 보안은 사실상 무력화됩니다. Integration Service는 연결성을 제공하는 도구일 뿐, 전역적인 보안 정책을 강제하지 않습니다. 따라서 아키텍트는 허브에 연결된 각 ‘스포크’의 보안을 개별적으로 구성하고, 전체 시스템-오브-시스템즈의 보안을 종합적으로 분석해야 합니다.
eProsima Integration Service의 가치를 명확히 이해하기 위해서는 다른 일반적인 통합 기술과의 비교를 통해 그 고유한 위치를 파악하는 것이 중요합니다. 이 서비스는 특정 프로토콜도, 저수준 라이브러리도 아닌, 이들을 아우르는 상위 계층의 솔루션입니다. 아키텍트는 이 비교를 통해 자신의 문제에 가장 적합한 도구를 정보에 입각하여 선택할 수 있습니다.
결론적으로, eProsima Integration Service는 독특한 생태학적 지위를 차지합니다. 이는 프로토콜도, 저수준 라이브러리도, 단순한 라우터도 아닌, “메타-미들웨어(meta-middleware)” 또는 “시스템-오브-시스템즈 통합 플랫폼(system-of-systems integration platform)”으로 정의할 수 있습니다. 기존 미들웨어들 위에서 동작하며 이들이 서로 상호 운용되도록 만드는 것이 그 목적이기 때문입니다. 아키텍트가 “풍부한 데이터 타입을 가진, 여러 개의 기존 이기종 시스템을 연결해야 하는가?”라는 질문에 ‘예’라고 답한다면, Integration Service는 매우 강력한 후보가 될 것입니다.
| 표 3: 통합 기술 비교 분석 |
|---|
| 특징 |
| 주요 추상화 |
| 아키텍처 |
| 데이터 타이핑 |
| 서비스 탐색 |
| 주요 사용 사례 |
| 사용 용이성 |
eProsima Integration Service는 복잡한 분산 시스템 통합이라는 현대적 과제에 대한 강력하고 성숙한 솔루션입니다. 이 마지막 섹션에서는 프로젝트의 현재 상태, 이상적인 채택 시나리오, 그리고 미래 잠재력을 종합적으로 평가하여 아키텍트와 기술 관리자를 위한 전략적 지침을 제공합니다.
프로젝트의 건전성과 지속 가능성은 산업계에서 기술을 채택할 때 가장 중요한 고려사항 중 하나입니다. Integration Service는 이 측면에서 매우 긍정적인 신호를 보냅니다.
Integration Service는 모든 문제에 대한 만병통치약이 아니며, 그 가치가 가장 빛을 발하는 특정 시나리오가 존재합니다.
Integration Service의 미래는 그 확장 가능한 플러그인 아키텍처에 달려 있습니다.1 프레임워크는 이미 새로운 프로토콜을 지원할 준비가 되어 있습니다.
eProsima Integration Service는 현대 분산 시스템에서 발생하는 복잡한 통합 문제를 해결하기 위해 전략적으로 설계된 성숙하고 강력한 프레임워크입니다. 표준화되고 동적인 xTypes 공통 언어를 기반으로 하는 중앙 집중식 플러그인 아키텍처는, 깨지기 쉬운 포인트-투-포인트 브리지 방식에 대한 확장 가능하고 유지보수가 용이한 대안을 제공합니다.
특히 로보틱스와 산업용 IoT(IIoT) 영역에서 그 가치가 두드러지며, 차세대 복합 시스템을 구축하는 아키텍트에게 신뢰할 수 있는 솔루션을 제공합니다. 이 도구는 단순히 시스템을 연결하는 것을 넘어, 시스템이 진화하고 성장할 수 있는 견고한 기반을 마련해 줍니다.