Skip to main content
Summary

로봇에게 필요한 것은 코드 한 덩어리가 아니다

로봇을 처음 만들 때는 모든 기능을 하나의 프로그램 안에 넣고 싶어진다. 카메라에서 영상을 읽고, LiDAR에서 거리를 받아오고, 바퀴 속도를 계산하고, 장애물을 피하고, 목표 지점까지 가는 경로도 같은 코드 안에서 처리하는 식이다. 작은 장난감 로봇이라면 잠깐은 가능할 수 있다. 하지만 로봇이 조금만 복잡해지면 상황은 금세 달라진다.

이동 로봇을 떠올려 보자. 로봇은 주변 벽까지의 거리를 LiDAR로 측정한다. 바퀴 엔코더로 자신이 얼마나 움직였는지 추정한다. IMU로 기울기와 회전을 감지한다. 카메라가 있다면 사람이나 표지판을 인식할 수도 있다. 그리고 이 모든 정보를 바탕으로 현재 위치를 추정하고, 지도를 만들고, 목적지까지의 경로를 계산하고, 모터에 속도 명령을 내려야 한다.

이 일을 하나의 거대한 프로그램이 모두 처리한다면 어떨까? 센서 하나를 바꾸는 일도 전체 코드를 건드려야 한다. 경로 계획 알고리즘을 바꾸고 싶어도 제어 코드와 얽혀 있어 조심스럽다. 한 부분에서 오류가 나면 로봇 전체가 멈출 수도 있다. 디버깅은 점점 어려워지고, 여러 사람이 함께 개발하기도 힘들어진다.

ROS2는 바로 이런 문제를 해결하기 위해 등장한 로봇 소프트웨어 프레임워크다. 핵심은 단순하다. 로봇의 기능을 작고 독립적인 단위로 나누고, 그 단위들이 서로 데이터를 주고받으며 하나의 로봇 시스템처럼 동작하게 만드는 것이다.

ROS2는 무엇인가

ROS2는 진짜 운영체제가 아니다

ROS는 Robot Operating System의 줄임말이다. 이름만 보면 리눅스나 윈도우 같은 운영체제처럼 들린다. 그래서 처음 ROS2를 접하는 사람은 "ROS2를 설치하면 컴퓨터가 로봇 전용 운영체제로 바뀌는 걸까?" 하고 생각하기 쉽다.

하지만 ROS2는 하드웨어를 직접 관리하는 운영체제가 아니다. 컴퓨터의 메모리를 관리하고, 파일 시스템을 제공하고, 프로세스를 스케줄링하는 역할은 여전히 Ubuntu 같은 실제 운영체제가 담당한다. ROS2는 그 위에서 동작하는 로봇 개발용 프레임워크이자 생태계다.

여기서 생태계라는 표현이 중요하다. ROS2에는 단순한 라이브러리 몇 개만 있는 것이 아니다. 로봇 프로그램을 실행하고 연결하는 방식, 센서 데이터를 표현하는 메시지 형식, 여러 기능을 묶어 실행하는 도구, 좌표계를 관리하는 시스템, 시각화 도구, 시뮬레이션과 연결되는 패키지, 내비게이션과 SLAM을 위한 소프트웨어가 함께 모여 있다.

즉 ROS2를 운영체제라고 부르는 이유는 로봇 소프트웨어가 살아가는 공통 환경을 제공하기 때문이다. 실제 OS는 아니지만, 로봇 개발자가 같은 규칙 안에서 프로그램을 만들고 연결할 수 있게 해 준다.

비유하자면 ROS2는 로봇 안의 도시 계획과도 같다. 센서 노드는 데이터를 생산하는 발전소이고, 제어 노드는 도로 위에서 움직이는 차량이며, 토픽은 정보를 운반하는 도로다. 지도 작성 노드와 내비게이션 노드는 관제센터처럼 전체 상황을 보고 판단한다. ROS2는 이 모든 구성 요소가 충돌하지 않고 협력하도록 공통 언어와 연결 방식을 제공한다.

노드로 나누어 생각하기

ROS2를 이해하는 가장 중요한 출발점은 노드다. 노드는 ROS2에서 하나의 기능을 담당하는 실행 단위다. 일반적인 프로그램 하나라고 생각해도 좋지만, 더 정확히는 로봇 시스템 안에서 특정 역할을 맡은 작은 구성원이다.

예를 들어 자율주행 이동 로봇을 만든다고 하자. 이 로봇에는 다음과 같은 기능이 필요하다.

  • LiDAR 데이터를 읽어 주변 장애물 거리를 측정하는 기능

  • 바퀴 엔코더 값을 읽어 이동량을 계산하는 기능

  • 센서 정보를 이용해 현재 위치를 추정하는 기능

  • 지도를 만들거나 저장된 지도와 비교하는 기능

  • 목표 지점까지의 경로를 계획하는 기능

  • 계산된 경로를 따라가도록 바퀴 속도를 제어하는 기능

ROS2에서는 이런 기능을 하나의 거대한 프로그램으로 만들기보다 여러 노드로 나눈다. LiDAR 노드는 거리 데이터를 발행하고, 위치 추정 노드는 그 데이터를 구독해 로봇의 위치를 계산한다. 경로 계획 노드는 현재 위치와 목표 위치를 보고 이동 경로를 만든다. 제어 노드는 그 경로를 따라가기 위해 속도 명령을 만든다.

이렇게 나누면 한 가지 큰 장점이 생긴다. 각 노드는 자신의 일에 집중할 수 있다. LiDAR 노드는 경로 계획을 몰라도 된다. 경로 계획 노드는 LiDAR 장치가 어떤 회사 제품인지 몰라도 된다. 제어 노드는 지도가 어떻게 만들어졌는지 자세히 몰라도 된다. 필요한 데이터가 정해진 형식으로 들어오고, 자신이 만든 결과를 정해진 형식으로 내보내면 된다.

이 구조는 레고 블록과 비슷하다. 바퀴 블록, 센서 블록, 몸체 블록을 따로 만들고 조립하듯이, 로봇 소프트웨어도 센서 노드, 인식 노드, 계획 노드, 제어 노드를 조합해 만든다. 어떤 블록이 마음에 들지 않으면 같은 연결 규칙을 지키는 다른 블록으로 바꿀 수 있다.

토픽은 로봇 안의 대화 통로다

노드가 각각 독립적으로 동작한다면, 이제 필요한 것은 노드 사이의 대화 방법이다. ROS2에서 가장 자주 사용하는 통신 방식이 토픽이다. 토픽은 어떤 종류의 데이터가 흘러가는 이름 붙은 통로다.

LiDAR 노드는 주변 거리 정보를 /scan 같은 토픽으로 발행할 수 있다. 위치 추정 노드는 로봇의 위치 정보를 /odom이나 관련 토픽으로 내보낼 수 있다. 제어 노드는 로봇을 움직이기 위한 속도 명령을 /cmd_vel 같은 토픽으로 보낼 수 있다.

여기서 발행한다는 말은 데이터를 내보낸다는 뜻이고, 구독한다는 말은 그 데이터를 받아본다는 뜻이다. 영어로는 Publish와 Subscribe라고 한다. 신문 구독을 떠올리면 이해하기 쉽다. 신문사는 신문을 발행하고, 독자는 관심 있는 신문을 구독한다. 신문사는 독자가 정확히 누구인지 몰라도 신문을 만들 수 있고, 독자는 신문사가 내부에서 어떤 방식으로 기사를 작성하는지 몰라도 신문을 받을 수 있다.

ROS2의 토픽도 비슷하다. LiDAR 노드는 자신이 만든 거리 데이터를 발행할 뿐이다. 그 데이터를 SLAM 노드가 받을 수도 있고, 장애물 회피 노드가 받을 수도 있고, RViz 같은 시각화 도구가 받을 수도 있다. 발행자와 구독자가 느슨하게 연결되기 때문에 시스템을 확장하기 쉽다.

이 느슨한 연결은 로봇 소프트웨어에서 매우 중요하다. 실제 로봇 개발은 한 번에 완성되지 않는다. 처음에는 키보드로 조종하고, 다음에는 SLAM으로 지도를 만들고, 그다음에는 Nav2로 자율주행을 붙인다. 개발 단계마다 필요한 노드를 추가하거나 교체할 수 있어야 한다. ROS2의 통신 구조는 이런 점진적인 확장을 가능하게 한다.

로봇 시스템을 모듈화해야 하는 이유

모듈화란 복잡한 시스템을 독립적인 부분으로 나누는 것이다. ROS2는 모듈화를 아주 중요하게 생각한다. 그 이유는 단지 코드가 깔끔해지기 때문만은 아니다. 로봇은 현실 세계와 맞닿아 있기 때문에 예측하지 못한 일이 자주 생긴다. 센서 값이 튀고, 바퀴가 미끄러지고, 장애물이 갑자기 나타나고, 네트워크가 불안정해질 수 있다.

모든 기능이 하나로 뭉쳐 있으면 작은 변경도 위험해진다. 반면 기능이 모듈로 나뉘어 있으면 문제를 좁혀서 볼 수 있다. 로봇이 벽을 향해 이상하게 움직인다면 먼저 LiDAR 데이터가 정상인지 확인한다. LiDAR가 정상이라면 위치 추정이 틀렸는지 본다. 위치 추정이 괜찮다면 경로 계획이나 제어 쪽을 살펴본다. 문제를 단계별로 추적할 수 있는 것이다.

예를 들어 로봇이 목표 지점으로 가지 못하고 제자리에서 빙글빙글 돈다고 해 보자. 모듈화된 ROS2 시스템에서는 다음과 같이 생각할 수 있다.

  • 센서 노드가 정상적으로 거리 데이터를 내보내고 있는가

  • 위치 추정 노드가 로봇의 현재 자세를 올바르게 계산하고 있는가

  • 경로 계획 노드가 목표까지의 경로를 만들고 있는가

  • 제어 노드가 속도 명령을 적절히 생성하고 있는가

  • 모터 드라이버 노드가 명령을 실제 바퀴 움직임으로 바꾸고 있는가

이렇게 나누어 보면 막연한 "로봇이 이상하다"가 구체적인 질문으로 바뀐다. ROS2를 배운다는 것은 단순히 명령어를 외우는 일이 아니다. 복잡한 로봇 문제를 잘게 나누고, 각 부분의 입력과 출력을 확인하며, 전체 시스템을 조립하는 사고방식을 배우는 일이다.

ROS1에서 ROS2로 넘어온 이유

ROS1은 오랫동안 로봇 연구와 교육, 프로토타입 개발에서 널리 사용되었다. 많은 패키지와 예제가 축적되었고, 로봇 개발자들이 공통으로 사용할 수 있는 언어를 제공했다. 하지만 시간이 지나면서 새로운 요구가 커졌다. 로봇은 연구실 안에서만 움직이지 않게 되었고, 공장, 물류창고, 병원, 도로, 가정처럼 더 복잡한 환경으로 나가기 시작했다.

이런 환경에서는 더 안정적인 통신, 여러 로봇의 협업, 실시간 제어, 보안, 상태 관리가 중요해진다. ROS2는 이런 요구를 반영해 새롭게 설계되었다.

관점ROS1ROS2
통신 구조ROS Master 중심 구조DDS 기반의 분산 통신
시스템 발견Master가 노드 연결을 중개노드들이 네트워크에서 서로 발견
멀티로봇추가 설정과 우회 방법이 필요한 경우가 많음여러 로봇과 분산 시스템을 더 자연스럽게 고려
실시간성실시간 제어에 한계가 있음실시간 시스템과의 연계를 더 고려한 구조
보안기본 보안 기능이 제한적DDS-Security 기반 보안 기능 활용 가능
라이프사이클노드 상태 관리가 표준화되어 있지 않음노드의 설정, 활성화, 비활성화, 종료 상태를 관리 가능

여기서 DDS는 Data Distribution Service의 줄임말이다. 쉽게 말해 여러 프로그램이 네트워크를 통해 데이터를 주고받기 위한 통신 표준이다. ROS2는 DDS를 바탕으로 노드들이 서로를 찾고 데이터를 주고받도록 설계되었다. ROS1에서는 ROS Master라는 중앙 중개자가 중요한 역할을 했지만, ROS2에서는 이런 중앙 의존성을 줄이고 분산 시스템에 더 어울리는 구조를 선택했다.

이 차이는 실제 로봇을 여러 대 운용할 때 더 크게 느껴진다. 예를 들어 물류창고에서 여러 대의 이동 로봇이 동시에 움직인다고 생각해 보자. 각 로봇은 자신의 센서 데이터를 처리하면서도, 필요하면 다른 로봇이나 관제 시스템과 정보를 주고받아야 한다. ROS2의 통신 구조는 이런 분산 환경을 염두에 두고 만들어졌다.

실시간성도 중요하다. 실시간이라는 말은 단순히 빠르다는 뜻이 아니다. 정해진 시간 안에 반드시 반응해야 한다는 뜻이다. 모터 제어나 안전 정지처럼 시간이 중요한 기능에서는 "언젠가 처리된다"가 아니라 "정해진 시간 안에 처리된다"가 필요하다. ROS2는 운영체제, DDS 구현, 실행기 설정 등에 따라 실시간 시스템과 더 잘 결합할 수 있도록 설계되었다.

보안 역시 현실적인 문제다. 로봇이 네트워크에 연결되고, 여러 장비와 데이터를 주고받는다면 아무나 명령을 보내 로봇을 움직이게 해서는 안 된다. ROS2는 통신 보안, 인증, 암호화 같은 기능을 고려할 수 있는 기반을 제공한다.

라이프사이클은 노드의 생애를 상태로 관리하는 개념이다. 로봇 노드가 실행되자마자 바로 움직이는 것이 항상 좋은 것은 아니다. 먼저 설정을 읽고, 센서 연결을 확인하고, 준비가 끝난 뒤 활성화되는 절차가 필요할 수 있다. 라이프사이클 노드는 이런 상태 전환을 명확하게 다룰 수 있게 해 준다.

ROS2가 연결하는 자율주행 이동 로봇의 흐름

이제 ROS2가 자율주행 이동 로봇에서 어떤 흐름을 연결하는지 큰 그림으로 살펴보자. 이 책의 뒤쪽에서는 SLAM, 지도, Nav2, Costmap, Behavior Tree 같은 개념을 차례로 배우게 된다. 지금은 세부 알고리즘보다 데이터가 어떻게 흘러가는지 보는 것이 중요하다.

자율주행 이동 로봇의 출발점은 센서다. 로봇은 자기 몸만 보고 움직일 수 없다. 주변을 알아야 한다. LiDAR는 벽과 장애물까지의 거리를 측정한다. 카메라는 영상 정보를 제공한다. IMU는 회전과 가속도를 알려 준다. 바퀴 엔코더는 바퀴가 얼마나 돌았는지 알려 준다.

이 센서 데이터는 각각의 센서 노드에서 ROS2 메시지로 바뀌어 토픽으로 발행된다. 그러면 다른 노드들이 이 데이터를 구독해 사용한다. SLAM 노드는 LiDAR와 오도메트리 정보를 이용해 지도를 만들고, 동시에 로봇이 지도 안에서 어디에 있는지 추정한다. 오도메트리는 바퀴 회전량 등을 이용해 이동량을 추정하는 방법이다. 다만 바퀴가 미끄러지면 오차가 누적되기 때문에 다른 센서와 함께 보정해야 한다.

지도가 준비되면 로봇은 목표 지점을 향해 이동할 수 있다. 이때 Nav2 같은 내비게이션 시스템이 등장한다. Nav2는 ROS2에서 자율주행 이동 로봇을 만들 때 자주 사용하는 내비게이션 프레임워크다. 현재 위치, 목표 위치, 지도, 장애물 정보를 바탕으로 경로를 만들고, 로봇이 그 경로를 따라가도록 속도 명령을 생성한다.

전체 흐름을 단순화하면 다음과 같다.

  • 센서 노드가 LiDAR, 카메라, IMU, 엔코더 데이터를 읽는다

  • 위치 추정 또는 SLAM 노드가 로봇의 현재 위치와 지도를 계산한다

  • 내비게이션 노드가 목표 지점까지의 경로를 계획한다

  • 제어 노드가 경로를 따라가기 위한 속도 명령을 만든다

  • 모터 드라이버가 속도 명령을 바퀴 움직임으로 바꾼다

여기서 속도 명령은 보통 선속도와 각속도로 표현된다. 선속도는 앞으로 얼마나 빠르게 갈지, 각속도는 얼마나 빠르게 회전할지를 뜻한다. 이동 로봇에게는 "왼쪽 바퀴를 몇 번 돌려라"보다 "앞으로 이만큼 가고, 이만큼 돌아라"가 더 일반적인 명령일 때가 많다. 로봇의 하위 제어기는 이 명령을 실제 모터 제어로 바꾼다.

중요한 점은 ROS2가 이 모든 알고리즘을 마법처럼 대신 만들어 주는 것이 아니라는 사실이다. ROS2는 각 기능이 만나는 공통 무대를 제공한다. 센서 데이터가 어떤 형식으로 흐를지, 노드가 어떻게 서로를 찾을지, 메시지를 어떻게 주고받을지, 여러 노드를 어떻게 함께 실행할지에 대한 기반을 제공한다. 그 위에 SLAM 패키지, Nav2, 로봇 드라이버, 사용자가 만든 노드가 올라간다.

ROS2를 배우는 올바른 순서

ROS2를 처음 배울 때 가장 흔한 실수는 곧바로 복잡한 자율주행 예제를 실행하려는 것이다. 물론 버튼 몇 번으로 시뮬레이션 로봇이 움직이면 재미있다. 하지만 내부 구조를 모르면 문제가 생겼을 때 어디를 봐야 할지 알 수 없다. 지도는 보이는데 로봇이 움직이지 않거나, 목표를 찍었는데 경로가 생기지 않거나, 경로는 있는데 로봇이 벽에 붙어 가는 상황이 생긴다.

그래서 먼저 작은 개념부터 연결해야 한다. 노드가 무엇인지 알고, 토픽으로 메시지가 흐르는 방식을 이해한다. 서비스와 액션으로 요청과 오래 걸리는 작업을 다루는 방법을 배운다. 파라미터와 Launch로 실행 구조를 정리한다. 그다음 좌표계와 TF를 이해해야 한다. 로봇에서 좌표계는 매우 중요하다. LiDAR가 보는 장애물 위치, 로봇 중심의 위치, 지도 안에서의 위치가 서로 다른 기준으로 표현되기 때문이다.

로봇 모델을 URDF와 xacro로 정의하고, RViz에서 눈으로 확인하면 추상적인 구조가 조금씩 구체적인 형태를 갖는다. 시뮬레이션에서는 실제 하드웨어 없이 센서와 주행을 실험할 수 있다. 그 후 SLAM을 통해 지도를 만들고, 저장한 지도를 바탕으로 위치를 추정하고, Nav2를 사용해 목표 지점까지 이동하는 흐름으로 확장한다.

결국 이 책의 여정은 "명령어를 외우는 과정"이 아니라 "로봇 시스템을 조립하는 과정"이다. 처음에는 노드 하나를 실행하는 작은 경험에서 시작하지만, 마지막에는 센서, 지도, 위치 추정, 경로 계획, 장애물 회피, 속도 제어가 연결된 하나의 자율주행 로봇 시스템을 보게 될 것이다.

ROS2를 바라보는 세 가지 관점

ROS2를 잘 이해하려면 세 가지 관점을 함께 가져야 한다.

첫째, ROS2는 통신 도구다. 노드와 노드가 메시지를 주고받고, 요청과 응답을 처리하며, 오래 걸리는 작업의 진행 상황을 공유하게 해 준다. 토픽, 서비스, 액션은 이 통신을 이해하기 위한 핵심 개념이다.

둘째, ROS2는 구조화 도구다. 패키지, 워크스페이스, Launch, 파라미터를 통해 프로젝트를 정리한다. 로봇 프로그램은 파일 몇 개로 끝나지 않는다. 여러 노드와 설정 파일, 모델 파일, 실행 파일이 함께 움직인다. ROS2는 이 복잡함을 관리할 수 있는 틀을 제공한다.

셋째, ROS2는 통합 도구다. 센서 드라이버, 시뮬레이터, 시각화 도구, SLAM 패키지, Nav2 같은 내비게이션 시스템을 하나의 흐름으로 묶는다. 직접 모든 기능을 처음부터 만드는 대신, 공통 인터페이스를 통해 검증된 도구들을 연결할 수 있다.

이 세 가지 관점을 기억하면 앞으로 나오는 개념들이 따로 놀지 않는다. 노드는 통신의 주체이고, 토픽은 데이터가 흐르는 길이며, TF는 좌표계를 연결하는 지도이고, URDF는 로봇의 몸을 설명하는 문서이며, Nav2는 목표 지점까지 이동하기 위한 여러 노드의 묶음이다.

작은 로봇에서 큰 시스템으로

ROS2의 매력은 작은 실습에서 시작해 실제 로봇 시스템으로 확장할 수 있다는 점이다. 처음에는 "Hello"를 출력하는 노드를 만들 수 있다. 그다음 숫자를 발행하고 구독하는 토픽 예제를 만든다. 이어서 키보드 입력으로 로봇을 움직이고, LiDAR 데이터를 RViz에서 확인한다. 그러다 어느 순간 로봇이 스스로 지도를 만들고, 지도 위에서 자신의 위치를 찾고, 목표 지점까지 이동하는 장면을 보게 된다.

이 과정에서 가장 중요한 변화는 개발자의 시선이다. 처음에는 "어떤 명령어를 입력해야 하지?"라고 생각하지만, 점점 "이 데이터는 어느 노드에서 나와서 어디로 들어가지?", "이 좌표는 어떤 기준으로 표현되어 있지?", "이 기능은 독립 노드로 나누는 것이 좋을까?"라고 생각하게 된다. 이것이 ROS2식 사고방식이다.

자율주행 로봇은 겉으로 보면 바퀴 달린 기계가 스스로 움직이는 것처럼 보인다. 하지만 그 안에서는 수많은 작은 프로그램이 쉼 없이 대화한다. 어떤 노드는 세상을 보고, 어떤 노드는 위치를 짐작하고, 어떤 노드는 길을 찾고, 어떤 노드는 바퀴를 움직인다. ROS2는 이 대화를 가능하게 하는 공통 언어다.

앞으로의 장에서는 이 언어를 하나씩 배워 나간다. 처음에는 낯선 용어가 많을 수 있다. 하지만 모든 개념은 하나의 질문으로 다시 돌아온다. "로봇의 기능을 어떻게 나누고, 그 기능들이 어떻게 데이터를 주고받게 할 것인가?" 이 질문을 붙잡고 가면 ROS2의 많은 개념이 서로 연결되기 시작한다.

ROS2는 단순한 도구 상자가 아니다. 로봇을 생각하는 방식이며, 복잡한 자율주행 시스템을 작고 이해 가능한 조각으로 나누는 설계 방법이다. 이 관점을 갖고 나면 노드, 토픽, SLAM, Nav2는 각각 따로 떨어진 기술이 아니라 하나의 이동 로봇을 완성하기 위한 이어진 길이 된다.

책 목록

ROS2로 완성하는 자율주행 로봇: 노드·TF·SLAM·Nav2 실전 설계

전체 목차 보기

이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.

틸노트는 사용자가 AI를 활용해 노트를 쉽게 작성하거나 편집할 수 있는 서비스입니다.

AI 스퀘어 단톡방에 함께해요

AI 활용과 틸노트 사용 팁을 나누는 오픈채팅방입니다. 입장 비밀번호는 tilnote입니다.

참여하기