본문 바로가기
IT/AI , 로봇

AI-로봇-멀티모달 시스템 네트워크 복잡성 증가와 설계 전략

오호라마 2025. 6. 15. 14:30

 


AI 기술과 로봇 공학, 그리고 음성·영상·센서·LLM과 같은 멀티모달 인터페이스가 융합된 시스템이 등장하면서, 이러한 시스템의 네트워크 아키텍처는 복잡성이 급격히 증가했습니다.

 

2025년 현재, 원격 로봇 제어, 엣지(edge) AI 추론, 멀티모달 인터페이스 통합 등 실제 사례에서 서로 다른 통신 방식(예: WebRTC, RTSP, ROS 2/DDS, gRPC, MQTT, Kafka, REST/FastAPI 등)이 혼재되며 설계자들에게 새로운 도전과제를 안겨주고 있습니다.

 

본 글에서는 복잡성 증가의 원인을 분석하고, 각 통신 기술의 특성과 트레이드오프를 상세 비교하며, 지연, 신뢰성, 확장성, 비용 측면의 설계 기준을 제시하겠습니다.

 

또한 주요 시나리오별 추천 아키텍처 조합을 도식화하여, 실무 설계자가 현실적인 판단을 내릴 수 있도록 구조적 인사이트와 판단 기준을 제공합니다.

 

 

 

네트워크 구조 복잡성 증대의 주요 원인

1. 이기종 통신 요구사항:

로봇 및 AI 통합 시스템은 여러 종류의 데이터 스트림을 다룹니다. 예를 들어 실시간 영상 스트리밍, 제어 명령, 음성/텍스트 데이터, 센서 피드백 등이 각각 서로 다른 특성(대역폭, 지연 허용치, 전송 빈도)을 가지므로, 각 흐름에 최적화된 통신 프로토콜을 따로 선택하는 경향이 있습니다. 그 결과 WebRTC, RTSP, ROS2/DDS, MQTT 등 여러 프로토콜이 한 시스템에 공존하며 구조가 복잡해집니다.

 

2. 계층화된 분산 아키텍처 (엣지-클라우드 연계):

AI 로봇 시스템은

**장치(device) - 엣지(edge) - 클라우드(cloud)**

의 다계층 구조를 취하는 경우가 많습니다.

 

로봇 현장 장치와 인근 엣지 서버 간에는 실시간성 높은 로컬 네트워크 통신(ROS 2, DDS 등)이 쓰이는 반면,

엣지에서 클라우드로는 인터넷 망을 통한 MQTT, REST API, Kafka 스트림 등이 활용됩니다.

이러한 이질적인 네트워크 도메인 간 연계를 위해 프로토콜 브릿지(예: ROS2-DDS 메시지를 MQTT로 변환와 게이트웨이가 추가되며 구조가 복잡해집니다.

 

3. 실시간성과 신뢰성 요구 간 상충:

로봇 제어와 센서 피드백은 지연에 민감하고 최신 상태만 전달되면 되지만, 영상/음성 스트리밍이나 LLM 질의응답은 데이터 손실 없이 순서 보장도 중요합니다. 따라서 일부 채널은 UDP 기반 무상태 전송, 다른 채널은 TCP 기반 안정 전송 등 서로 다른 전송 방식을 혼용하게 됩니다. 예를 들어 WebRTC는 낮은 지연을 위해 P2P UDP 전송을 활용하는 반면,

RTSP는 영상 프레임의 신뢰성을 위해 TCP 터널링을 쓰거나 RTP/RTCP로 보완합니다

이렇게 QoS 요구사항 차이가 여러 프로토콜 병행 사용으로 이어집니다.

 

4. 새로운 AI 서비스와 기존 로봇 시스템의 통합:

LLM 같은 최신 AI 모델은 주로 **클라우드 API(예: REST/HTTP)**로 제공되거나,

gRPC 마이크로서비스로 배치되는 반면,

 

로봇 제어 소프트웨어는 ROS2 같은 기존 미들웨어에 기반합니다.

음성 인식/합성 서비스, 비전 AI 등도 각각 전용 API를 갖는 경우가 많습니다.

이질적인 소프트웨어 스택을 오케스트레이션하기 위해, 설계자는 각 구성요소를 메시지 버스, RPC 호출, 웹서비스 등으로 연결하는 추가 계층을 두게 되고 아키텍처가 복잡해집니다.

 

이러한 요인들로 인해 단일 프로토콜/프레임워크로 모든 요구를 충족하기 어려워 여러 기술을 조합하게 되며, 통신 계층의 복잡도가 상승합니다. 그렇다면 각각의 통신 기술은 어떤 맥락에서 선택되고, 어떤 트레이드오프를 갖는지 살펴보겠습니다.

 

 

주요 통신 기술별 선택 맥락과 트레이드오프

WebRTC vs. RTSP – 실시간 미디어 스트리밍

WebRTC(Web Real-Time Communication)는 브라우저 등에서 P2P 실시간 통신을 가능하게 하는 프로토콜로,

낮은 지연과 양방향 통신이 장점입니다.

 

예컨대 원격 화상제어, 원격 협업 등 양방향 스트리밍에 적합하여, 원격 로봇 teleoperation UI에도 활용됩니다.

WebRTC는 오디오/비디오를 실시간 전송하면서도 내장 보안(암호화)과 NAT 트래버설(STUN/TURN) 기능을 제공해 인터넷 상에서도 브라우저끼리 직접 통신하게 합니다

 

지연(latency) 면에서 WebRTC는 수백 밀리초 이내의 interactive latency를 달성하며, 프레임 일부 손실을 감수하고서라도 최신 스트림을 빠르게 전달하는 쪽으로 설계돼 있습니다.

 

다만 다자간 통신 시에는 MCU/SFU 서버가 필요해 구성이 복잡해질 수 있고, 브라우저 이외 플랫폼에서 사용하려면 추가 라이브러리가 요구됩니다.

 

RTSP(Real-Time Streaming Protocol)는 주로 영상 스트리밍 제어용 프로토콜로,

IP 카메라 등에서 한 방향 영상 전송에 많이 쓰입니다. **“실시간”**이라는 이름에도 불구하고 WebRTC와 달리 스트림 제어 (재생, 정지 등) 신호용이며, 실제 미디어 전송은 RTP/RTCP 등에 의해 이뤄집니다

레거시 CCTV/보안 카메라 환경에 널리 깔려 있어, 기존 하드웨어와 통합 시 RTSP 지원이 유용합니다.

RTSP 자체는 P2P보다는 클라이언트-서버 모델에 가깝고, TCP 기반으로 동작하여 방화벽 통과 등을 위해 RTSP-over-TCP 터널링을 사용하기도 합니다

 

따라서 WebRTC 대비 지연은 조금 크고(일반적으로 수백 ms~1초 내외) 양방향 제어에는 덜 유연하지만,

여러 수신자에게 동시 방송(One-to-Many)에 적합하고 구현이 단순합니다.

 

예시: 최신 카메라 SW가 WebRTC 지원하면 WebRTC를 쓰는 편이 낫지만, 구형 IP카메라를 로봇에 달아 쓰는 경우 RTSP/TCP로 영상을 중계하는 식으로 선택될 수 있습니다

 

종합 Trade-off:

WebRTC는 원격 조작, 텔레프레즌스 등 실시간 양방향 상황에 적합하며, 브라우저 지원이 강점입니다.

반면 RTSP는 기존 영상장비 연계나 일대다 모니터링에 적합하고 구현이 가벼우나, WebRTC만큼 저지연/보안이 기본 내장되어 있지는 않습니다

 

두 프로토콜 모두 IoT 영상 스트리밍 분야의 주요 옵션으로 공존하며,

저지연 2-way 통신에는 WebRTC, 고정형 1-way 카메라 스트림에는 RTSP를 고려하는 것이 일반적입니다

 

 

ROS 2와 DDS – 로봇 미들웨어 데이터 버스

ROS 2(Robot Operating System 2)는 로봇 어플리케이션 개발을 위한 미들웨어로,

센서 데이터, 상태 정보, 제어 명령을 토픽(topic) 기반 발행-구독으로 주고받습니다.

 

ROS 2의 핵심 통신 계층은 DDS(Data Distribution Service)로 구현되며, 분산 실시간 데이터 공유에 초점을 맞춥니다.

 

DDS는 프로세스 간 데이터 버스 역할을 하며, QoS 정책(신뢰성, 이력 깊이, 우선순위 등)을 세부 튜닝할 수 있어 고신뢰/저지연 통신을 지원합니다.

 

예컨대 ROS 2에서는 이미지 토픽은 베스트 에포트(best-effort), 제어 명령은 신뢰성 보장(reliable) 식으로 QoS를 조절해 네트워크 부하와 신뢰성을 균형 맞출 수 있습니다.

 

DDS는 브로커 없는 P2P 구조로 로컬 네트워크에서 매우 낮은 지연(수 ms 수준)과 고 처리량을 보여주며, 다수 노드가 있을 때도 multicast 발견 기능으로 자동 연결되는 편의성이 있습니다.

 

하지만 **ROS 2(DDS)**는 동일 LAN 내 통신을 가정한 설계가 많아, 원거리 네트워킹에는 한계가 있습니다. 인터넷을 통한 ROS 2 통신은 NAT, 방화벽 문제로 바로 연결하기 어려워, VPN 구성이나 브릿지 노드가 필요합니다

www2.eecs.berkeley.edu

www2.eecs.berkeley.edu.

 

 

실무에선 rosbridge(ROS <-> WebSocket 브릿지) 같은 방법으로 ROS 메시지를 웹으로 중계하기도 하나,

예를 들어 rosbridge로 이미지 전송 시 초당 1~2프레임에 그쳐 원활하지 않았다는 보고도 있습니다

medium.com.

 

이를 해결하려 Peter Gaston 등의 사례에서는 ROS 2 노드로 WebRTC 서버를 내장하여 카메라 토픽을 WebRTC로 뿌리고, 조작 명령은 WebRTC 데이터 채널로 받아 ROS 2의 cmd_vel 토픽으로 투입하는 방식을 썼습니다medium.commedium.com.

이처럼 ROS 2 환경에 WebRTC 게이트웨이 노드를 추가하면 원격 제어의 영상/데이터 지연을 크게 줄일 수 있었습니다.

 

ROS 2/DDS Trade-off: 로컬 로봇 제어 및 다수 센서 융합에는 ROS 2(DDS)가 사실상 표준으로, 마이크로초~밀리초 수준 지연과 정밀 QoS 제어가 강점입니다. 하나의 DDS 네트워크에 수십~수백 노드도 운용 가능하지만, 규모가 아주 커지면 디스커버리 트래픽과 메모리 오버헤드가 늘어 조정이 필요합니다.

 

WAN 연동 시에는 ROS 2 전용 브릿지나 클라우드 IoT 서비스 활용이 흔합니다. 예를 들어 AWS는 Greengrass로 ROS 2 DDS 데이터를 MQTT 브로커와 동기화해 로컬 ROS 네트워크와 클라우드 IoT 코어를 연결하는 패턴을 제시합니다

d1.awsstatic.comd1.awsstatic.com.

 

요약하면, ROS 2/DDS는 로봇 내부/현장 통신의 중추로 쓰이고, 외부와 연계할 땐 다른 프로토콜로 변환/연결하는 하이브리드 구조를 취하는 것이 일반적입니다.

 

 

gRPC vs. REST(FastAPI) – 마이크로서비스 통신

gRPC는 구글이 개발한 고성능 RPC 프레임워크로, 프로토콜 버퍼(protobuf) 기반의 바이너리 직렬화와 HTTP/2 전송을 사용합니다. REST API(HTTP+JSON)와 비교해 지연 시간이 낮고(동일 TCP 연결로 다중 요청 처리 및 스트리밍 지원) 처리량이 높아 마이크로서비스 간 내부 통신에 적합합니다wallarm.comwallarm.com.

 

실제로 gRPC는 멀티 요청을 하나의 연결로 처리하기에 TCP 핸드셰이크/헤더 오버헤드가 줄고, 서버 푸시 및 스트리밍 응용에도 유리합니다. 한 실험에 따르면 원격 DB 액세스 시 REST는 37초, gRPC는 18초로 2배 이상 빠른 응답을 보이기도 했습니다medium.com.

 

IDL(인터페이스 정의) 기반 코드생성으로 개발 편의성도 있으나, 브라우저 직접 호출이 불가하여 웹 클라이언트와 통신하려면 gRPC-Web 프록시 등이 필요합니다wallarm.comwallarm.com.

 

 

**REST API(FastAPI 등)**는 웹 시대부터 쓰여온 HTTP/1.1+JSON 표준으로, 언어 불문 광범위한 호환성이 강점입니다. 브라우저, cURL 등 어디서나 호출 가능하고, JSON은 사람도 읽을 수 있는 형식이라 디버깅이 쉽습니다. Python 기반 FastAPI 같은 프레임워크를 쓰면 손쉽게 RESTful 서버를 만들어 AI 추론 서비스 등을 배포할 수 있어, 프로토타이핑과 외부 공개 API로 선호됩니다. 그러나 REST/HTTP는 요청당 헤더+핸드셰이크 오버헤드가 매번 발생하고, 실시간 스트림보다는 요청-응답 위주라 대기 시간이 비교적 높습니다wallarm.comwallarm.com.

 

 

HTTP/1.1 환경에서는 동시 요청 시 커넥션 지연도 있고, HTTP/2로 개선되었지만 여전히 텍스트 JSON 파싱 부담이 남습니다. 반면, gRPC는 HTTP/2 기반이지만 브라우저 호환성 제약과 러닝 커브가 단점입니다.

Trade-off: 내부 서비스 간 통신이나 고성능 요구 (예: 영상 분석 서비스 간 데이터 교환)에는 gRPC가 높은 효율과 낮은 지연을 제공합니다wallarm.com.

 

특히 양방향 스트리밍이나 실시간 피드에는 REST로 구현하기 어려운 패턴을 gRPC로 쉽게 구현할 수 있습니다. 반대로, 외부 시스템 연계나 공개 API는 REST/HTTP가 개발 생산성과 범용성 면에서 유리합니다wallarm.comwallarm.com.

 

예를 들어 LLM 모델 API를 사내에 배포한다면, 내부 호출에는 gRPC를 쓰되 외부 개발자용 엔드포인트는 REST(FastAPI)로 래핑하는 식으로 혼용 전략을 취할 수 있습니다. 요약하면, gRPC는 성능, REST는 호환성 쪽에 무게를 둔 선택이라 할 수 있습니다.

 

 

MQTT vs. Kafka – IoT 메시징과 데이터 스트림

MQTT(Message Queuing Telemetry Transport)는 IoT 분야 표준 경량 프로토콜로, 브로커 중개 하에 publish-subscribe 모델로 동작합니다. MQTT는 패킷 헤더가 2바이트 정도로 매우 작고, 장비 자원 소모를 최소화하도록 설계되어 임베디드 센서, 무선 통신에 적합합니다cedalo.comcedalo.com.

 

예를 들어 배터리 구동 센서가 수만 개 있는 환경에서 MQTT broker 하나로도 수백만 개 연결을 유지할 수 있으며cedalo.com,

 

각 센서는 짧은 메시지를 간헐적으로 보내도 MQTT는 연결 세션을 지속해두기에 에너지 효율이 높습니다cedalo.com.

 

MQTT의 QoS 레벨(0,1,2)을 조정하여 “최소 1회 전달”, “정확히 1회 전달” 같은 메시지 전달 보장도 선택 가능합니다cedalo.com.

 

다만 중앙 브로커 의존 구조라 브로커 장애 시 대비해 클러스터링이나 이중화가 필요하고, 표준 MQTT는 메시지 영구 보관을 정의하지 않으므로 데이터를 오래 저장/재처리하기엔 한계가 있습니다cedalo.com.

 

Apache Kafka는 분산 스트리밍 플랫폼으로, 고속 로그 수집/스트림 처리에 특화된 분할 로그 (partitioned log) 구조를 채택합니다. 프로듀서/컨슈머 모델을 통해 토픽 단위로 메시지를 파일시스템에 영구 저장하고, 구독자들이 각자 속도에 맞춰 pull해서 데이터를 소비합니다cedalo.comcedalo.com.

 

결과적으로 Kafka는 대용량 데이터 실시간 처리에 강하고, 메시지 순서와 중복 제어, 내구성을 기본 제공합니다cedalo.comcedalo.com.

 

예컨대 수백 대 기기에서 초당 수십만 건의 이벤트가 쏟아질 때, Kafka는 이를 디스크에 적재하며 클러스터 노드들에 복제하여 내고장성을 보장하고, 소비자는 필요시 과거 데이터까지 재처리할 수 있습니다. 성능 측면에서 Kafka는 배치 최적화와 압축으로 **처리량(throughput)**은 매우 높고, 레이턴시도 일정 수준 부하 이상에서는 낮게 유지됩니다cedalo.comcedalo.com.

 

다만 단건 소량 메시지만 띄엄띄엄 오는 IoT 기기에는 Kafka가 과한 인프라 부담이 될 수 있습니다 – Kafka는 브로커 클러스터, Zookeeper/쿼럼 노드 등을 요구해 운영 복잡도와 비용이 MQTT보다 큽니다cedalo.comcedalo.com.

 

Trade-off:

MQTT는 소형 디바이스 수만~수百万 대 연결, 낮은 지연 통신에 최적으로, 네트워크 품질이 떨어져도 비교적 끈기 있게 전달해 IoT 현장에서 널리 쓰입니다risingwave.comrisingwave.com.

Kafka는 데이터 양이 많고 저장/분석이 중요한 경우 등장하여, 예를 들어 산업 설비 모니터링에서 수많은 센서 데이터 스트림을 실시간 분석해야 하면 Kafka가 유용합니다risingwave.comrisingwave.com.

 

MQTT와 Kafka는 경쟁이라기보다 서로 보완적으로 함께 쓰이기도 하는데, MQTT 브로커가 받은 IoT 데이터를 Kafka로 흘려보내 장기 저장/대용량 분석을 담당시키는 아키텍처가 대표적입니다cedalo.comcedalo.com.

 

한마디로, MQTT는 디바이스<->엣지 간 경량 전송, Kafka는 엣지<->클라우드 간 대규모 스트림처리로 구분지어 활용하며, 둘을 잇는 브리지도 존재합니다.

다음 표는 앞서 언급한 주요 기술들을 지연, 신뢰성, 확장성, 운영비용 측면에서 요약 비교한 것입니다.

 

 

기술  지연 특성  신뢰성 보장  확장성  운영 비용/복잡도  주요 활용 맥락
WebRTC 매우 낮음 (P2P, ms~수백ms) 중간 (UDP 기반, 필요 시 FEC 사용) 1:1 P2P 기본, 다자간은 SFU로 확장 필요 브라우저 내장 지원으로 클라이언트 부담 적음. 서버로는 시그널링/STUN/TURN 필요 원격제어, 양방향 화상/음성 스트림
RTSP 낮음 높음 (대개 TCP 사용, 패킷 재전송) 1:N 스트림에 적합 (서버가 팬아웃) 전용 미디어 서버/리시버 필요, 브라우저 직접지원 없음 (별도 플레이어 필요) CCTV, IP카메라 영상 모니터링
ROS 2 / DDS 매우 낮음 (로컬 P2P, ms 수준) 높음 (QoS로 Reliable 설정 가능) LAN 내 수십~수백 노드WAN 확장은 브릿지 필요 오픈소스 구현 사용 (FastDDS 등). 설정 복잡도 다소 높음. 상용 RTI Connext는 비용 高 로봇 센서/제어 버스, 실시간 제어 루프
gRPC 낮음 (HTTP/2, 바이너리) 높음 (TCP + 애플리케이션 재시도 구현) 서버 수평확장 용이 (LB 통해) API 설계/관리 복잡도 높음 (스키마 관리, stub생성). HTTP/2 LB 필요 내부 마이크로서비스 통신, 실시간 스트림 RPC
REST / FastAPI 중간 (HTTP/1.1 기본, 요청당 핸드셰이크) 높음 (TCP, 무상태 재시도 용이) 매우 높음 (스테이트리스, 캐시 활용 가능) 개발 용이 (인프라/도구 풍부). 성능 튜닝 여지 적음 (JSON 파싱 비용 등) 공개 API, 웹 통합, 간단한 AI 서비스 배포
MQTT 매우 낮음 (persistent 연결, 경량 프로토콜) 선택적 보장 (QoS0~2로 at-most-once ~ exactly-once) 연결 수 수백만까지 확대 사례 있음 (메시지 빈도 높으면 브로커 부하 상승) 브로커 설치/운영 간단 (Mosquitto 등 경량). 클러스터링은 구현 별도 지원 IoT 센서망, 엣지 기기간 통신 (이벤트 트리거 등)
Kafka 중간 (ms~수십ms; 디스크 flush 및 배치 지연) 매우 높음 (다중 복제, 소비자 재시도, 불멸 로그) 매우 높음 (분산클러스터로 수만 TPS 이상) 운영 복잡 (다수 브로커+좌표노드, Zookeeper/RAFT 필요). 전문지식 요구 & 비용 높음 대규모 데이터 파이프라인, 실시간 로그/이벤트 분석

 

 

※ 상기 수치는 일반적인 경향을 요약한 것이며, 구체적인 지연/성능은 구현과 환경에 따라 달라질 수 있습니다. 설계 시에는 각 기술의 최신 구현 상태와 QoS 설정 옵션을 함께 검토해야 합니다. 

다음으로, 앞서 논의된 통신 기술들을 실제 시스템에 어떻게 조합하여 적용할 수 있는지, 대표적인 아키텍처 사례 두 가지를 도식과 함께 살펴보겠습니다 (또한 멀티모달 인터페이스 통합 사례도 추가 언급합니다).

 

사례 1: 원격 로봇 제어 시스템 아키텍처

원격 로봇 teleoperation 아키텍처: 로봇 온보드(좌측) ROS 2/DDS 버스에 카메라 센서와 액추에이터가 연결되어 있고, 원격 운영자 측(우측)은 웹 브라우저 UI를 통해 로봇과 WebRTC로 영상/제어 데이터를 교환한다. (예: ROS 2 노드 내 WebRTC 게이트웨이 구성)

 

위 다이어그램은 원격지에서 로봇을 조작하는 시스템의 통신 구조를 나타낸 것입니다.

로봇 측(좌측 점선 박스)은 ROS 2/DDS 기반으로 카메라 센서가 주는 영상 토픽과 여러 제어 명령 토픽(cmd_vel 등)을 공유합니다. 원격 운영자 측(우측 점선)은 웹 브라우저 UI를 통해 로봇 상황을 모니터링하고 조작 입력을 보냅니다. 주요 설계 요소는 다음과 같습니다:

  • 실시간 영상 전송: 로봇의 카메라 영상은 ROS 2 이미지 토픽으로 게시되며, WebRTC 게이트웨이 노드가 이 토픽을 받아 압축 영상 스트림으로 변환, WebRTC를 통해 원격 브라우저로 전송합니다medium.comtransitiverobotics.com.
  • 이를 통해 낮은 지연으로 운영자 화면에 로봇 시야를 제공할 수 있습니다. WebRTC는 P2P 전송을 시도하므로, 로봇과 사용자가 인터넷에 있을 경우 STUN/TURN 시그널링 서버 한 대를 중계로 사용합니다 (AWS Kinesis Video 등 서비스 활용 가능). P2P 연결 시 영상 지연과 대역폭 효율이 매우 우수하며, 방화벽 환경에서는 TURN을 거쳐도 실시간성을 유지하도록 최적화됩니다d1.awsstatic.comd1.awsstatic.com.
  • 원격 제어 명령 전송: 운영자의 조이스틱/키보드 입력은 브라우저에서 WebRTC 데이터 채널로 로봇에게 전달됩니다. WebRTC 데이터 채널은 SCTP/UDP 기반의 양방향 통신으로, 여기서 수십 Hz~100 Hz로 조작 명령(Twist 메시지 등)을 보낼 수 있습니다medium.com.
  • 로봇 쪽 WebRTC 노드는 받은 명령을 ROS 2 제어 토픽에 퍼블리시하여, 기존 로봇 소프트웨어 스택이 이를 받아 모터 구동 등에 사용합니다. 이렇게 하면 명령 지연이 최소화되고, ROS 2 네이티브 제어와도 호환됩니다.
  • ROS 2 상호운용 및 브릿지: 상기 WebRTC 노드는 ROS 2의 일원으로 동작하여 ROS 네트워크에 통합됩니다. 대안으로는 ROS bridge (rosbridge_server)를 통해 브라우저와 WebSocket으로 통신하는 방식도 있으나, 앞서 언급한 바처럼 성능이 제한적입니다medium.com.
  • WebRTC를 쓸 경우 수십 FPS 영상과 즉각적인 조작 피드백이 가능하여, 사용자 입장에서 딜레이가 거의 없는(remote in-network) 조작 환경을 구현합니다transitiverobotics.comtransitiverobotics.com.
  • 또한 WebRTC는 영상과 제어 신호를 동일 연결로 다루므로, 네트워크 장애 시 영상 손실과 동시에 제어 중지도 감지할 수 있어 안전성 개선에도 도움이 됩니다transitiverobotics.com.
  • 추가 고려 – 신뢰성과 보안: 원격 조작에서는 지연 최소화가 핵심이지만, 신호 신뢰성도 중요합니다. WebRTC 데이터 채널은 필요한 경우 ordered, reliable 모드로 설정 가능하고, 영상 채널은 약간의 손실 허용으로 세팅하는 등 미세 조정이 가능합니다. 또한 WebRTC는 DTLS로 암호화되어 전송되므로 중간 탈취 위험이 낮고, ROS 2 DDS 자체도 옵션에 따라 암호화를 적용할 수 있습니다. 이중 보안 계층이지만 성능에 큰 영향 없이 동작합니다www2.eecs.berkeley.eduwww2.eecs.berkeley.edu.

이 아키텍처의 장점은 **기존 로봇 소프트웨어(ROS 2)**를 그대로 활용하면서도 원격 제어를 위한 **실시간 스트리밍 채널(WebRTC)**을 추가하여, 양 측 요구를 모두 만족시킨다는 점입니다. 실제 산업 창고 로봇의 원격 tele-op, 자율주행 배달로봇의 긴급 수동제어 등에 이 패턴이 응용되고 있습니다. Transitive Robotics 등 상용 솔루션도 WebRTC 기반 ROS 원격제어 기능을 제공하며, 10대까지 동시 영상 스트림과 안전장치(dead-man switch) 등을 덧붙여 실무 활용성을 높이고 있습니다transitiverobotics.comtransitiverobotics.com.

 

 

사례 2: 엣지 기반 추론-센서 피드백 아키텍처



엣지 AI 추론 및 센서-액추에이터 피드백 아키텍처: 현장 Edge 사이트(좌측)에서 다수 센서 디바이스가 MQTT 브로커에 데이터를 게시하면, Edge AI 서비스가 이를 구독하여 처리하고 필요한 경우 MQTT로 액추에이터 명령을 보낸다. 동시에 Edge 서비스는 중요한 데이터를 Kafka 스트림으로 클라우드에 전송하고, 클라우드의 Kafka 소비자가 이를 저장/분석한다.

 

 

위 그림은 제조/산업 현장 등에서 엣지 컴퓨팅을 활용한 센서 데이터 실시간 처리 구조를 나타냅니다. 핵심 아이디어는 MQTT를 사용해 현장 센서와 엣지 AI 서비스 간 데이터 버스를 형성하고, Kafka를 통해 필요한 데이터만 클라우드로 필터링/전송하는 2단계 구성입니다:

  • 엣지 MQTT 센서 허브: 여러 IoT 센서(온도, 압력, 카메라 등)가 MQTT 프로토콜로 엣지 게이트웨이의 MQTT 브로커에 데이터를 게시(publish)합니다. MQTT 브로커는 엣지 서버나 게이트웨이 장비 내에서 동작하며, 센서들은 주기적으로 작은 JSON/이진 메시지를 전송합니다. 예를 들어 온도센서는 sensors/temperature 토픽에 1초마다 온도 값을 게시합니다. MQTT 브로커는 가벼운 경량 프로세스여서 엣지 디바이스에서도 실행 가능하며, 수십~수백개의 센서 연결도 무리 없이 처리합니다. 지연 측면에서, 센서 -> 브로커 -> 구독자 전파가 수 ms 단위로 매우 빨라 엣지 단에서 실시간 수집이 이뤄집니다.
  • Edge AI 추론 서비스: MQTT 브로커에 Edge AI 서비스가 구독자로 연결되어, 센서 데이터 스트림을 실시간으로 받습니다. 이 서비스는 Python 등의 FastAPI 서버나 gRPC 서버 형태로 동작하며, 내부에 AI 추론 엔진(예: 결함 감지 모델, 영상 인식 등)을 포함합니다. 예시: 엣지 서비스가 카메라 센서 영상을 처리하여 이상 여부를 판단하고, 만약 이상 징후가 있으면 액추에이터로 경보 신호를 보내는 로직.
    엣지 서비스는 MQTT 클라이언트로서 센서 토픽들을 비동기로 구독하여, 새 데이터 발생 시마다 AI 모델을 실행합니다. 이때 추론 지연은 모델 복잡도에 따라 수 ms수백 ms 정도이며, 결과를 즉시 MQTT를 통해 액추에이터 명령 토픽에 퍼블리시합니다. 로컬 처리를 하므로 네트워크 왕복 지연이 없고, MQTT 자체 지연도 매우 낮아 엔드투엔드(센서->액추에이터) 반응 시간이 짧게 유지됩니다 (수십 ms수백 ms 이내).
  • 액추에이터 제어 및 피드백: 엣지 MQTT 브로커를 액추에이터 디바이스(모터, 알람 장치 등)도 구독하고 있습니다. Edge AI 서비스가 퍼블리시한 명령을 브로커가 액추에이터에게 전달(deliver)하면, 해당 디바이스가 동작을 수행합니다. 이 과정 역시 MQTT QoS 설정에 따라 한 번 이상 또는 정확히 한 번 전달 보장되어, 명령 신뢰성을 확보합니다cedalo.com.
  • 액추에이터가 ROS 2 로 제어되는 로봇이라면, 엣지 서비스가 ROS 토픽 퍼블리시나 ROS2-브릿지를 통해 명령을 전달할 수도 있지만, 여기서는 단순화하여 MQTT로 직접 제어하는 그림으로 나타냈습니다. 중요한 점은, 센서->처리->액션의 피드백 루프가 모두 엣지 상에서 폐쇄되어, 인터넷이 끊겨도 현장 반응은 지속 가능하다는 것입니다 (안전/실시간성이 중요한 이유).
  • 클라우드 데이터 스트림 연계: 엣지에서 처리된 데이터 중 일부(원본 센서 raw 데이터 전체일 수도, 또는 요약 결과일 수도)를 Edge AI 서비스가 Kafka 프로듀서로서 클라우드에 전송합니다. 즉, Kafka 클러스터에 연결된 서비스가 분석용 토픽에 메시지를 쌓으면, 클라우드의 Kafka 컨슈머(예: 데이터 레이크 적재 모듈, 모니터링 대시보드 등)가 이를 읽어 영구 저장 또는 집계합니다. Kafka는 대용량 데이터의 지속 전송과 저장에 적합하므로, 예컨대 하루치 센서 로그를 모두 저장해두고자 할 때 엣지->Kafka 경로를 활용합니다cedalo.comcedalo.com.
  • 이때 Kafka 전송은 배치 전송 및 압축을 활용해 WAN 대역폭을 효율화하며, 네트워크 일시 불안정 시에도 버퍼링/재전송으로 데이터 유실 없이 넘어갑니다. MQTT 브로커와 Kafka 브로커는 엣지-클라우드 사이의 완충 지대 역할을 하여, 서로 부하를 격리합니다 – MQTT는 디바이스 부하를, Kafka는 클라우드 소비 부하를 담당합니다cedalo.comcedalo.com.
  • 관리 및 API 인터페이스: 다이어그램에는 생략됐지만, Edge AI 서비스는 FastAPI/gRPC로 구현되어 상태 모니터링 또는 설정 API를 제공할 수 있습니다. 현장 운영자가 웹 클라이언트로 엣지 서비스의 REST API에 접속해 AI 모델의 동작 모드나 임계값을 변경하는 식입니다. 또한 클라우드에서도 해당 엣지 서비스와 gRPC로 연결해 원격 모델 업데이트 등을 실시할 수 있습니다. FastAPI의 경우 간단한 대시보드 UI도 내장 가능하므로, 엣지 장비 상태 파악에 쓰입니다. 이처럼 MQTT/Kafka는 백엔드 데이터 경로, REST/gRPC는 제어 및 설정 경로로 병행 운용하여 기능을 분리하는 전략을 사용합니다.

이 아키텍처는 에지 컴퓨팅의 전형적인 패턴으로, 산업용 IoT, 자율공장 등에 활용됩니다. 장점은 현장에서 필요한 응답은 신속히 처리하고, 방대한 데이터는 클라우드에 지속 전달함으로써 실시간성과 빅데이터 처리를 양립한다는 점입니다. 각각에 최적화된 MQTT와 Kafka를 적재적소에 사용한 예시로, MQTT는 저지연 현장 제어, Kafka는 고확장성 데이터 처리를 맡습니다risingwave.comrisingwave.com.

설계자는 이처럼 계층별 프로토콜 분담을 통해 시스템 복잡성을 다소 높이지만 관리 영역을 명확히 구분하고, 각 계층에 최적인 기술을 써서 전체 성능과 신뢰성을 극대화할 수 있습니다.

사례 3: 멀티모달 인터페이스 통합 시스템

끝으로, 음성 + 영상 + 센서 + LLM이 어우러진 차세대 멀티모달 인터페이스의 아키텍처를 간략히 살펴보겠습니다. 이 경우 앞서 언급한 여러 통신 패턴이 동시에 요구되며, 가장 복잡한 시나리오로 꼽을 수 있습니다.

예시 시나리오: 한 사용자가 음성으로 로봇에게 명령을 내리고, 로봇은 카메라로 주변을 인식하여 LLM 기반으로 이해 및 응답하거나 행동하는 시스템을 상상해봅시다. 이를 구현하려면 다음과 같은 모듈과 통신이 필요합니다:

  • 음성 입력 및 ASR: 사용자의 마이크 음성을 스트리밍 인식(ASR) 서비스로 보내 텍스트로 변환해야 합니다. 만약 사용자가 원격에 있고 웹으로 접근한다면, WebRTC나 gRPC 스트리밍을 통해 음성 데이터를 전송할 수 있습니다. 브라우저에서 바로 OpenAI Whisper API 등을 호출해 음성을 텍스트로 바꾸거나, 웹소켓으로 보내는 방법도 있습니다. 저지연 실시간 인식을 위해 gRPC 스트림 API를 사용하는 사례도 있으며, 이 경우 사용자 클라이언트와 ASR 서버 간 바이너리 스트리밍으로 음성이 전달됩니다.
  • 영상 및 센서 데이터 수집: 로봇이 가진 카메라 영상이나 기타 센서(LiDAR 등) 데이터는 Edge에서 1차 처리가 필요할 수 있습니다. 영상의 경우 ROS 2 이미지 토픽을 Edge GPU 노드가 구독하여 객체인식 등을 수행하거나, 로봇 카메라를 RTSP로 Edge 서버에 송출해 프레임 분석을 할 수 있습니다. 어떤 방법이든, 대용량 비디오 스트림을 실시간으로 처리해야 하므로 로컬 네트워크 상 높은 대역폭 저지연 채널이 필요합니다. ROS 2 DDS를 쓸 경우 로봇-Edge 간 gigabit LAN에서 수십 FPS 영상을 공유 가능하며, 또는 GStreamer등으로 RTSP 스트림을 가져올 수도 있습니다. 센서 수치들은 ROS 2 토픽이나 MQTT로 Edge 서비스에 모입니다.
  • LLM 의사결정 모듈: 음성 인식 결과 텍스트 + 중요 영상/센서 정보는 LLM에 제공되어, 사용자의 질문에 답하거나 명령 의도를 파악하는 데 활용됩니다. LLM은 크기가 크므로 대개 클라우드 API 호출(예: REST로 OpenAI API)로 사용하거나, 작은 버전을 Edge에 올려 로컬 gRPC 호출로 사용할 수 있습니다. 어떤 경우든 LLM 모듈은 음성 텍스트와 상황 정보를 입력 받아 자연어 답변 또는 실행 계획을 출력합니다. 예를 들어 “저기 빨간 물체를 집어와 줘” 라는 명령에, 카메라 영상 분석으로 “빨간 물체=사과” 정보를 LLM에게 주면 LLM이 *“로봇 팔로 사과 집기”*라는 액션을 결정할 수 있습니다. 이때 LLM 호출은 수백 ms~수초 지연이 있을 수 있으므로, Edge 서비스는 비동기 처리로 구현하고, 다른 실시간 루프와 분리합니다. REST API 호출은 간단하지만 동기식이므로, gRPC 스트림으로 LLM과 주고받는 최신 연구도 나타나고 있습니다.
  • 응답 및 행동 실행: LLM의 출력이 자연어 응답(“네, 집어오겠습니다”)이라면, TTS(Text-to-Speech) 엔진을 통해 음성으로 합성하여 스피커로 출력합니다. TTS 합성은 Edge에서 라이브러리 사용 또는 클라우드 API 이용 가능하며, 수백 ms 정도 소요됩니다. 한편 LLM 출력이 로봇 행동 명령인 경우, Edge 서비스가 ROS 2 액션/서비스 호출이나 MQTT 제어 메시지를 통해 로봇 제어 계층에 명령을 내립니다. 이때 ROS 2 액션은 피드백/결과까지 받을 수 있어 유용합니다. 명령 실행 중간중간 로봇 상태(센서 피드백)를 다시 LLM에 피드백하여, 사용자의 추가 질문에 답변을 개선하거나, 행동을 동적으로 조정할 수도 있습니다. 이는 지속적인 멀티모달 대화를 위해 필요한 부분입니다.
  • 통합 오케스트레이션: 위의 모든 기능을 조율(orchestrate) 하는 것은 Edge AI 오케스트레이터 서비스가 담당합니다. 이 서비스는 멀티스레드/이벤트 기반으로 음성, 영상, LLM 호출 등을 관리하며, 내부 통신으로 이벤트 버스(예: MQTT, ROS 2, Kafka 중 경량인 ROS 2나 MQTT)와 함수 호출(LLM REST, gRPC) 혼합을 사용합니다. 핵심은, 각 모듈이 느슨하게 결합되도록 하는 것입니다. 예를 들어 음성->텍스트 결과가 나오면 이벤트 버스에 user_intent 메시지를 발행하고 LLM모듈이 이를 구독하는 식으로 설계하면, 모듈 간 강결합 없이 확장 가능합니다. Kafka까지는 과할 수 있지만, ROS 2 intra-process 통신이나 Python 이벤트 큐로도 충분히 구현 가능합니다.

멀티모달 시스템의 복잡성 완화 전략: 이처럼 구성요소가 많을수록, 모듈화와 인터페이스 표준화가 중요합니다. 실무에서는 마이크로서비스 아키텍처로 음성-ASR, 비전-CV, LLM, 로봇제어를 분리하고 **컨테이너 오케스트레이션(Kubernetes)**으로 관리하기도 합니다arxiv.orgdiscourse.ros.org.

각각의 서비스는 gRPC/REST API로 노출하여 교차 호출하고, 공통 메시지 포맷(예: 프로토버퍼)을 사용하면 디버깅이 수월해집니다. 또한 중앙 이벤트 버스(예: Redis PubSub, ROS 2, MQTT)로 주요 이벤트를 흘려보내 상태 공유를 하며, 필요한 서비스만 그 이벤트를 사용하도록 합니다. 이렇게 하면 새로운 모달리티(예: 촉각 센서 등)를 추가해도 기존 시스템에 큰 변경 없이 구독자 하나 추가하는 방식으로 통합이 가능합니다.

사례 예시: 실제 Unitree quadruped 로봇을 OpenAI의 ChatGPT와 연동한 실험에서, 로봇이 음성을 “듣고”, ChatGPT로 답변을 생성해 “말하고”, 음성 명령을 실행하도록 구성한 바 있습니다hackmd.io.

이 시스템에서 Unitree 로봇은 자체 DDS 기반 SDK로 제어되고, 음성 인식과 TTS는 온라인 API, LLM은 ChatGPT API로 처리되었습니다. 결과적으로 로봇이 사용자 질문에 대화형으로 답하고, “이쪽으로 따라와” 같은 명령에 반응하게 되었는데, 이는 멀티모달 인터페이스의 가능성을 보여줍니다hackmd.io.

다만 이러한 통합은 아직 연구단계에 가까워, 지연 누적(음성->텍스트->LLM->텍스트->음성 변환 등)이나 오류 전파 문제 등 해결할 과제가 많습니다. 설계 팁으로, 멀티모달 통합 시에는 사용자 경험에 영향주는 경로(예: 질의->응답)는 최대한 동기식 경로를 단축하고, 부가 기능(기록 저장 등)은 비동기로 떼어내는 것이 좋습니다. 또한 장애 격리를 위해 각 모달 처리 모듈이 실패해도 나머지 핵심 기능은 동작하도록 폴백 시나리오를 마련해야 합니다.

결론 및 설계자 안내

AI, 로봇, 멀티모달 기술이 융합된 시스템에서는 완벽한 은탄환 프로토콜은 존재하지 않으며, 요구에 따라 여러 통신 기술을 조합하는 것이 현실적인 접근입니다. 2025년 현재 동향은, 로봇 현장 영역은 ROS 2/DDS, MQTT 등으로 실시간성과 경량화를 추구하고, 클라우드/AI 영역은 gRPC, Kafka 등으로 확장성과 데이터 처리량을 확보하는 방향으로 수렴되고 있습니다. WebRTC와 RTSP는 각각 양방향 실시간 vs. 일방향 스트림 용도로 공존하고 있어, 화상/원격협업 기능을 고려한다면 함께 도입될 수 있습니다.

설계자는 시스템을 기능적 모듈로 나누고, 모듈 간 인터페이스에 가장 적합한 통신방법을 선택해야 합니다. 이때 키 포인트는 트레이드오프입니다:

  • 지연 vs. 보장성: 몇 ms의 지연이 중요한 경로에는 UDP/로컬 처리를, 약간 지연돼도 확실히 받아야 하는 데이터는 TCP/저장 후 처리를.
  • 즉시성 vs. 확장성: 즉각 반응해야 하는 소수 노드 통신에는 P2P/경량 프로토콜을, 대규모 연결/데이터에는 중앙 브로커/분산 로그를.
  • 개발 민첩성 vs. 성능 최적화: 빠르게 서비스를 노출해야 하거나 다수 이종 플랫폼 연결 시는 REST/HTTP, 고빈도 호출이나 스트리밍에는 gRPC.

또한 시스템 전반의 모니터링과 관리를 위해, 통신 경로를 중앙집중적으로 추적할 수 있는 로그/메트릭 수집 아키텍처를 함께 고려해야 합니다. Kafka 등에 중요한 이벤트를 모두 적재하거나, Prometheus로 각 모듈 상태를 수집해 병목을 찾는 식입니다.

마지막으로, 기술 조합 예시 두 가지를 추천하자면:

  1. “ROS 2 + WebRTC + 클라우드브릿지” 아키텍처: 로봇 내부는 ROS 2로 일관성을 유지하고, 원격 UI와의 인터랙션은 WebRTC로 캡슐화하며, 클라우드 연동(로그 업링크 등)은 ROS 2 - MQTT 브릿지나 REST API로 보완. 이러한 구조는 자율주행 로봇 원격관리에 적합하며, 실제 Foxglove나 AWS RoboMaker 솔루션에서도 유사한 패턴을 채택합니다medium.comd1.awsstatic.com.
  2. “MQTT + Edge Microservice + Kafka” 아키텍처: 현장 장치들은 MQTT로 엣지 서비스와 통신하고, 엣지 서비스는 하나의 AI 마이크로서비스로 동작하며, 중요 데이터는 Kafka로 중앙 수집. 이 구조는 스마트 공장, IIoT 플랫폼에 잘 어울리고, 최근 Unified Namespace 개념(모든 OT/IT 데이터을 MQTT로 수집 후 필요 데이터만 Kafka 등으로 통합)으로도 확장되고 있습니다cedalo.comcedalo.com.

앞으로도 새로운 통신 기술이 나오겠지만, 기본 원리는 위에서 다룬 요구별 최적화와 계층 분담일 것입니다. 복잡성을 줄이기 위해 불필요한 중복 경로는 제거하고, 역할이 겹치는 기술은 하나로 통일하며, 모두 필요한 경우에는 명확한 인터페이스 계약을 정해 관리해야 합니다. 설계 기준표를 참고하여 각 요소의 속성을 비교하고, 우선순위에 따라 아키텍처 결정을 체계화하면 복잡한 시스템도 통제 가능할 것입니다. 실무 설계자는 결국 이러한 판단의 연속선상에 있으며, 본 글이 구체적인 판단 근거와 인사이트를 제공함으로써 복잡한 네트워크 구조 속에서도 균형잡힌 설계를 구현하는 데 도움이 되길 바랍니다.

참조 및 출처:

'IT > AI , 로봇' 카테고리의 다른 글

F1 지표가 이렇게 다양해?  (1) 2025.07.06
핸들 없는 차가 도로에 나온다고?” 자율주행 규제 대폭 풀렸다!  (2) 2025.06.15
로봇이 '지능'을 가지려면 무엇을 배워야 하는가? - Meta V-JEPA 2  (0) 2025.06.15
Mistral Code: 기업 내부 AI 도구는 어떻게 달라야 할까?  (1) 2025.06.15
🤖 로봇이 직접 OO까지?  (2) 2025.05.21

'IT/AI , 로봇' Related Articles

티스토리툴바