•
아래 영상을 보고 너무 감명받아 포스팅을 한다.
"30fps로 쏘는 카메라가 0.5fps로 수신돼요." "CPU 8코어인데 하나만 쓰고 있어요." "멀티 익스큐터 켰는데 왜 싱글스레드로 도는 거죠?" "Depth 이미지 쏘니까 전체 토픽이 마비됐어요."
•
ROS는 장단점이 매우 명확한 프레임워크다. 그래서 실제 제품 개발을 해본 엔지니어라면 누구나 한 번쯤은 “ROS를 계속 가져가야 하는가?”라는 고민을 하게 된다.
•
ROS가 제품 개발에서 자주 비판받는 이유는 단순히 “무겁다”는 인상 때문이 아니다. 구조적으로 연산 자원과 메모리, 네트워크 대역폭을 과도하게 소비할 가능성이 있는 설계 패턴을 기본값으로 채택하고 있기 때문이다. 예를 들어 ROS 1의 TCPROS/UDPROS 기반 pub-sub 구조 serialization/deserialization, context switching, kernel networking stack을 반복적으로 거치면서 latency jitter를 유발한다. ROS 2는 DDS를 채택하면서 deterministic 통신을 목표로 했지만, QoS 설정, discovery traffic, middleware 구현체(Fast DDS, Cyclone DDS 등)에 따라 실제 성능 특성이 크게 달라지는 문제가 있다.
실제 이슈
•
고트래픽 환경에서 이러한 특성은 더욱 두드러진다. LiDAR point cloud, multi-camera raw frame, IMU, GNSS, radar 등이 동시에 발행되는 시스템에서는 초당 수백 MB~수 GB급 데이터가 ROS 토픽을 통해 이동한다. 이때 copy 횟수, serialization 비용, intra-process communication 설정 여부에 따라 CPU utilization과 memory bandwidth가 급격히 증가하며, 예측 불가능한 latency spike가 발생한다. 특히 Linux non-RT kernel 환경에서 scheduler interference까지 겹치면 control loop의 deterministic guarantee는 사실상 무너지게 된다.
•
리소스 관리와 디버깅의 불편함 역시 구조적인 문제다. ROS 노드는 프로세스 단위로 분리되어 있어 fault isolation에는 유리하지만, IPC 경계가 많아질수록 profiling과 tracing이 어려워진다. rosbag, rqt_graph, rqt_plot 등 도구들이 존재하지만, 실제 제품 환경에서 system-level profiling(perf, eBPF, LTTng 등)과 ROS graph-level tracing을 함께 해석하는 것은 상당한 비용을 요구한다.
•
보안 측면에서도 ROS는 기본적으로 research-friendly하게 설계되었기 때문에 production security model을 전제로 하지 않는다. ROS 2의 DDS-Security가 존재하지만, 인증서 관리, secure discovery, enclave 분리 등은 제품 개발 단계에서 상당한 운영 비용과 복잡성을 추가한다.
•
또 하나의 현실적인 문제는 핵심 스택 커스터마이징이다. ROS의 navigation stack, perception pipeline, SLAM framework 등은 빠른 프로토타이핑에는 탁월하지만, 제품 요구사항에 맞게 깊이 커스터마이징하려 하면 결국 middleware 레벨까지 내려가야 하는 경우가 많다. 이 단계에서 ROS abstraction layer가 오히려 개발 속도를 늦추는 역설적인 상황이 발생한다.
•
그럼에도 ROS가 여전히 강력한 이유는 분명하다. 패키지 생태계, 표준화된 메시지 인터페이스, launch 및 lifecycle 관리, 그리고 수천 개의 검증된 오픈소스 스택은 개발 초기 속도를 압도적으로 높여준다.
특히 연구 코드 → 제품 프로토타입 → 파일럿 시스템으로 이어지는 파이프라인에서 ROS는 사실상 industry lingua franca 역할을 하고 있다.
•
문제는 이 장점들이 제품 요구사항의 복잡도와 성능 요구를 그대로 따라와 주지는 못한다는 점이다. 고성능 perception pipeline, 그리고
sensor fusion,
•
real-time control이 요구되는 제품에서는 ROS의 default architecture가 bottleneck이 되는 경우가 많다.
이 지점에서 ROS 도입 여부는 기술적 취향이 아니라 현실적인 시스템 엔지니어링 선택 문제가 된다.
•
상용 제품 개발에서 ROS 사용 여부는 이념이 아니라 TCO(Total Cost of Ownership)에 기반해 결정된다. 개발 일정, 팀의 middleware 역량, 장기 유지보수 비용, 그리고 리스크 관리까지 고려하면, ROS를 전면적으로 배제하는 것이 반드시 비용 효율적이라고 보기도 어렵다.
•
실무적으로는 ROS를 “운영체제처럼 쓰지 않는” 하이브리드 구조가 자주 선택된다. 예를 들어 Visual SLAM 비중이 높은 제품이라면, SLAM 파이프라인 자체를 C++ native pipeline으로 구성하고 shared memory, zero-copy IPC, GPU direct memory access 등을 활용해 성능을 확보한다. ROS는 high-level orchestration, parameter server, telemetry, system management layer 정도로 제한적으로 사용된다. 이는 ROS의 생태계와 개발 생산성은 취하되, 성능 민감 영역에서는 ROS 의존도를 최소화하기 위한 현실적인 타협이다.
•
물론 여기까지 오면
“이 정도로 우회해서까지 ROS를 써야 하나?”
•
라는 의문이 자연스럽게 든다. 하지만 이는 ROS의 기술적 우수성 문제라기보다는, 이미 검증된 생태계를 활용하는 것이 주는 개발 리스크 감소 효과와 팀 생산성 향상이라는 현실적인 이점에 대한 판단에 가깝다.
•
결국 ROS를 완전히 배제하고 새 아키텍처를 설계하더라도 시스템이 마법처럼 가벼워지지는 않는다. 고성능 middleware를 직접 구현하면 copy path, memory layout, scheduler, real-time constraint까지 모두 직접 책임져야 한다. 잘 분배된 ROS 기반 구조와 비교했을 때 성능 차이는 분명 존재하겠지만, 제품 레벨에서 체감될 정도로 드라마틱한 차이가 나는 경우는 생각보다 많지 않다.
결국 다 이거라니깐?
•
그렇다. 절대적인 성능 경쟁이라기보다는, 리스크 관리와 개발 효율, 그리고 시스템 복잡도 관리 사이에서 어디에 무게를 둘 것인가라는 엔지니어링 트레이드오프의 문제로 귀결된다.
안녕하세요
•
관련 기술 문의와 R&D 공동 연구 사업 관련 문의는 “glory@keti.re.kr”로 연락 부탁드립니다.
Hello
•
For technical and business inquiries, please contact me at “glory@keti.re.kr”
