ROS2 노드/토픽 구조, 결국 백엔드 마이크로서비스랑 같은 그림이었음
ROS2 + C++로 자율 모바일 로봇 만드는 영문 튜토리얼을 보다가, 노드/토픽/서비스/액션 구조가 백엔드 마이크로서비스 pub/sub 패턴이랑 완전 같은 그림이라는 걸 발견. 분산 시스템에서 좋은 설계는 도메인 안 가리고 수렴한다는 관찰과, 입문 튜토리얼치곤 욕심이 과해 보이는 글 구성에 대한 한국 풀스택 개발자 관점의 후기.
어디서 봤더라, 영문 블로그에서 ROS2 + C++로 자율 모바일 로봇(AMR) 만드는 튜토리얼이 길게 올라와 있길래 끝까지 읽어봤어요. 평소에 로봇틱스랑은 거리가 먼 풀스택 웹개발만 하고 있긴 한데, 본인 도메인 밖이라 오히려 호기심에 들여다본 거.
읽으면서 가장 와닿았던 건 Bug2 알고리즘이나 bicycle model 같은 로봇 이론이 아니라 ROS2 자체의 통신 구조였어요. 결론부터 말하면, 이게 백엔드 개발자가 평소 만지는 메시지 큐 패턴이랑 완전 같은 그림이더라고요.
ROS2의 노드/토픽이 결국 pub/sub 시스템이라는 것
원문에서 정리한 ROS2 핵심 컨셉을 옮기면 대충 이런 구조입니다:
- Node — 하나의 기능을 담당하는 실행 단위
- Topic — pub/sub 채널 (한 publisher → 여러 subscriber)
- Service — request/response (client/server 패턴)
- Action — 시간이 오래 걸리는 작업 + 진행 상태 추적
이거 어디서 많이 본 그림 아닌가. 마이크로서비스 + 메시지 브로커 패턴 그 자체거든요. Topic이 Kafka/Redis Pub/Sub, Service가 일반 REST·gRPC, Action이 long-running job 처리 큐. 로봇틱스 진영이 다듬어온 추상화가 백엔드 분산 시스템이랑 같은 결론에 도달한 셈임.
흥미로운 건 ROS 진영은 이걸 90년대 후반부터 정리해왔다는 점. 현대 마이크로서비스 트렌드가 한참 뒤에 비슷한 구조로 정착한 걸 보면, 분산 시스템에서 좋은 설계는 도메인 가리지 않고 비슷하게 수렴하는 듯해요. 같은 문제는 같은 답으로 가는 거.
글의 강점 - Bug2 알고리즘 부분은 깔끔함
원문 본 주제인 Bug2 path planning은 짧지만 잘 정리됨. 핵심만 옮기면 이런 흐름이에요:
- 목표 방향 벡터 계산
- 장애물 만나면 한 방향(왼쪽이든 오른쪽이든)으로만 우회
- 다시 방향 벡터 따라 진행
C++ 코드도 30줄 정도로 짧게 보여주는데, 학습용으로는 적당한 분량. 직접 돌려본 건 아니라 정확한 동작은 모르는데, 코드 저장소에 결과 GIF가 같이 공개되어 있어서 동작 자체는 검증 가능해 보였어요.
Bug 알고리즘 자체가 80년대에 나온 클래식이라 요즘 산업계 표준은 아님. 실제 자율주행이나 창고 로봇은 A* 변형이나 SLAM 기반 planner가 주류라고 하는데, 직접 안 만져봐서 정확한 비중까진 모르겠습니다. 다만 입문용으로 Bug2 가져온 선택 자체는 OK라고 봄.
근데 입문 튜토리얼치곤 욕심이 과함
여기서부터가 본인이 좀 의문 들었던 부분. 글 한 편에 다음을 다 욱여넣으려 함:
- ROS2 설치 및 핵심 개념
- C++ 노드 작성법
- pub/sub 인터페이스 설계
- 자전거 모델(bicycle model) 운동학
- Bug2 알고리즘 구현
- colcon 빌드 시스템
- launch 파일 작성
각각이 한 챕터씩 가져갈 만한 주제거든요. 한 글에 압축하니 어느 것도 깊이 있게 못 다뤄짐. 특히 ROS2 처음 만지는 사람한테 자전거 모델 운동학까지 같이 던지면 어디서 막히는지 본인도 모르게 됩니다.
ROS2 공식 docs는 의도적으로 단계별로 쪼개놨는데, 이 글은 그걸 한 번에 압축한 셈. 결과적으로 "공식 docs로 충분하지 않나"라는 의문이 남음.
2D OpenCV 시뮬레이션 선택은 좀 의아함
또 하나 걸리는 점은 시뮬레이터로 OpenCV를 직접 썼다는 거예요. ROS2 생태계에는 Gazebo라는 사실상 표준 시뮬레이터가 있고, 요즘은 NVIDIA의 Isaac Sim도 자주 언급됩니다. 둘 다 ROS2랑 native하게 통합돼요.
근데 글에서는 OpenCV로 직접 2D 시뮬을 그리는데, "그래픽이 popular하다"라는 이유 외에는 설득력이 약함. 입문자가 이 글 따라 만들고 나면 막상 실전 ROS2 프로젝트(Gazebo 기반) 보면 또 다 새로 배워야 해요. 교육적 ROI가 떨어진다는 의미임.
직접 만져본 게 아니라 단언은 못 하는데, 후기들 보면 보통 ROS2 입문은 turtlesim → Gazebo 단순 환경 → 실제 로봇 순서를 추천하더라고요. 이 글은 turtlesim 단계는 잠깐 언급하고, 그다음을 자체 시뮬레이터로 가버린 셈.
잠깐 곁가지로 - 풀스택과 로봇틱스가 너무 멀어진 이유
읽으면서 든 잡생각인데, 백엔드 개발자랑 로봇틱스 엔지니어가 사실 같은 분산 시스템 문제를 풀고 있는데도 서로의 도구를 거의 모르고 사는 게 좀 이상하다는 느낌이었어요.
추측해보면 이런 원인들:
- ROS는 C++ + Linux + 하드웨어 드라이버 진입장벽
- 웹은 JS/Python + 컨테이너 + 클라우드 진입장벽
- 둘 다 진입장벽이 큰 데다 채용 시장이 거의 안 겹침
근데 ROS2의 DDS 미들웨어 한 번 이해하면 Kafka 클러스터 운영도 더 직관적으로 보일 거고, 반대로 마이크로서비스 만져본 사람이 ROS 노드 그래프 보면 익숙해지는 속도가 빠를 거예요. cross-pollination이 좀 더 일어나야 한다는 생각이 듭니다.
한국 환경에서 ROS는 어떤가
이 부분은 본인이 직접 ROS 커뮤니티 활동을 안 해서 정확한 건 모르는데, 주변 머신러닝 하는 사람들 얘기 들어보면 한국에서 ROS는 자율주행/로봇 회사 위주로 굴러가지 일반 개발자 풀에는 거의 안 닿아요. 학부 로봇틱스 강의에서 한 번 만지고 끝나는 케이스가 대부분인 듯. 일본이나 독일에 비해 ROS 한국어 자료가 빈약한 것도 그 영향이 아닐까 싶고.
그래서 결론
ROS2의 통신 구조는 백엔드 개발자가 보면 익숙한 분산 시스템 패턴이고, 진입장벽은 결국 C++과 Linux 생태계 종속성이 만든다는 게 이 글 읽고 남은 핵심임. 글 자체는 입문 가이드로는 욕심이 과한 편이라, 공식 docs 먼저 본 다음에 이 글을 보조 자료로 보는 게 맞을 듯.
다음 글에서는 ROS2의 DDS 미들웨어가 실제로 어떻게 동작하는지, 그리고 백엔드에서 쓰는 Kafka/NATS와 어떤 구체적 차이가 있는지 정리해보려고 합니다. 풀스택 입장에서 ROS 진영을 들여다보는 작업이 생각보다 재밌어서.

댓글
NEXT_PUBLIC_GISCUS_*환경변수 구성 필요)