13. ROS 2는 왜 로봇 개발의 표준 도구가 되었나

한 파일로 시작한 로봇이 왜 갑자기 버거워질까

처음 로봇을 만들 때는 코드가 단순합니다. 센서를 읽고, 조건문으로 판단하고, 모터를 움직이면 됩니다. 작은 장애물 회피 로봇은 실제로 한 파일 안에서도 꽤 잘 돌아갑니다. 이전 장들에서 만든 프로젝트도 처음에는 이런 방식으로 충분했습니다.

문제는 기능이 늘어날 때 시작됩니다. 카메라를 붙이면 이미지 처리 코드가 들어오고, 음성 명령을 붙이면 마이크와 STT가 들어오고, AI 판단을 넣으면 네트워크 호출이나 추론 코드가 들어옵니다. 여기에 바퀴 제어, 배터리 상태 확인, 로그 저장, 원격 조종까지 얹으면 코드가 점점 한 덩어리로 뭉칩니다.

그 순간부터 이상한 일이 벌어집니다. 카메라 처리가 느려지면 모터 반응도 늦어지고, 음성 인식이 막히면 주행 루프도 같이 버벅입니다. 어떤 버그가 생겼는데 센서 문제인지, 판단 로직 문제인지, 모터 제어 문제인지 찾기도 어려워집니다. 로봇이 커진 것이 아니라, 코드가 서로 발목을 잡기 시작한 것입니다.

바로 이 지점에서 ROS 2가 등장합니다. ROS는 운영체제처럼 이름이 붙어 있지만, 실제로는 로봇 애플리케이션을 만들기 위한 오픈소스 라이브러리와 도구 모음에 가깝습니다.¹ 그리고 ROS 2는 현대 로봇이 요구하는 모듈성, 확장성, 신뢰성을 더 잘 다루도록 다시 설계된 세대입니다.²

이 장의 핵심은 간단합니다. 작을 때는 한 덩어리 코드로도 되지만, 커질수록 로봇은 모듈식 시스템으로 생각해야 한다는 것입니다. ROS 2는 바로 그 생각을 실제 코드 구조로 옮겨 주는 도구입니다.

ROS 2는 로봇용 공용 배선 규격에 가깝다

ROS 2를 처음 접하면 거대한 프레임워크처럼 느껴집니다. 설치도 해야 하고, 워크스페이스도 만들고, 패키지라는 개념도 나오고, 낯선 명령어도 많습니다. 그래서 초보자는 종종 이렇게 묻습니다.

"그냥 파이썬으로 직접 짜면 안 되나요?"

물론 됩니다. 문제는 직접 짜는 통신과 구조를 얼마나 오래 버틸 수 있느냐입니다.

ROS 2를 쉽게 비유하면, 로봇 부품과 소프트웨어가 서로 대화하는 공용 규칙입니다. 카메라 노드가 영상을 보내는 방식, 모터 제어 노드가 속도 명령을 받는 방식, 내비게이션 노드가 목표를 받아 실행하는 방식이 제각각이면 시스템이 금방 복잡해집니다. 반면 공통된 규칙이 있으면, 서로 다른 부품과 코드가 비교적 쉽게 연결됩니다.

즉 ROS 2의 진짜 가치는 "멋진 함수 몇 개"가 아니라 여러 프로그램을 하나의 로봇 시스템처럼 묶는 구조에 있습니다. 이 구조 덕분에 센서 처리, 판단, 제어, UI, 원격 명령을 따로 떼어 생각할 수 있습니다. 그리고 필요하면 같은 PC 안에서 돌릴 수도 있고, 여러 컴퓨터에 나눠 돌릴 수도 있습니다.²

노드: 기능을 작게 쪼개는 기본 단위

ROS 2에서 가장 먼저 이해해야 할 개념은 노드입니다. 노드는 로봇 시스템 안에서 하나의 역할을 맡는 작은 실행 단위입니다. 쉽게 말해 "한 가지 일을 주로 담당하는 프로그램"이라고 생각하면 됩니다.

예를 들어 이동 로봇 하나에도 이런 노드들을 둘 수 있습니다.

• 카메라에서 영상을 읽는 노드

• 물체를 인식하는 노드

• 바퀴 모터를 제어하는 노드

• 배터리 상태를 감시하는 노드

• 사용자 명령을 해석하는 노드

이렇게 나누는 이유는 단순히 예뻐 보이기 위해서가 아닙니다. 역할이 분리되면 머릿속 모델이 훨씬 선명해집니다. "카메라가 이상한가?", "인식 결과가 이상한가?", "명령은 맞는데 바퀴가 안 도는가?"처럼 문제를 구획해서 볼 수 있습니다.

또한 노드는 재사용하기 좋습니다. 데스크 어시스턴트 로봇에서 쓰던 음성 입력 노드를 나중에 이동 로봇에 붙일 수도 있습니다. 모터 제어 노드를 바꾸지 않고, 그 위에 있는 계획 노드만 새로 바꿀 수도 있습니다. 한 부분을 바꿀 때 전체를 갈아엎지 않아도 되는 것입니다.

혼자 개발할 때도 이 장점은 큽니다. 코드를 팀원과 나누지 않더라도, 오늘의 나와 한 달 뒤의 내가 협업해야 하기 때문입니다. ROS 2의 노드 구조는 미래의 나를 덜 고생시키는 장치이기도 합니다.

토픽: 계속 흘러가는 데이터를 위한 통로

노드가 나뉘면, 이제 서로 데이터를 주고받아야 합니다. 이때 가장 많이 쓰는 방식이 토픽입니다.

토픽은 한쪽이 데이터를 계속 발행하고, 다른 쪽이 그 데이터를 구독해서 받는 통신 방식입니다. ROS 2 공식 가이드에서도 토픽은 센서 데이터나 로봇 상태처럼 계속 흐르는 데이터 스트림에 쓰라고 설명합니다.³

예를 들어 이런 데이터는 토픽과 잘 맞습니다.

• 카메라 이미지

• 라이다 스캔

• IMU 값

• 엔코더 기반 주행 정보

• 바퀴 속도 명령

토픽의 좋은 점은 보내는 쪽과 받는 쪽이 서로를 몰라도 된다는 점입니다. 카메라 노드는 "누가 보든 말든" /camera/image_raw 같은 토픽으로 영상을 내보냅니다. 물체 인식 노드, 녹화 노드, 화면 표시 노드는 각자 필요하면 그 토픽을 구독하면 됩니다. 한 번 보내서 여러 곳이 동시에 받을 수 있는 구조입니다.⁴

이게 왜 중요할까요? 만약 카메라 코드 안에 "인식도 하고, 저장도 하고, 화면 표시도 하고, 네트워크 업로드도 하고"가 전부 들어 있다면, 기능 하나를 바꿀 때마다 카메라 코드 자체를 건드려야 합니다. 하지만 토픽 구조에서는 카메라 노드는 그냥 영상을 보내기만 하면 됩니다. 누가 그 영상을 어떻게 쓰는지는 뒤쪽 노드가 알아서 정합니다.

이 구조는 로봇을 훨씬 유연하게 만듭니다. 그리고 디버깅도 쉬워집니다. ROS 2에서는 rqt_graph나 ros2 topic list, ros2 topic echo 같은 도구로 어떤 노드가 어떤 토픽을 주고받는지 확인할 수 있습니다.⁴ 즉, 시스템 안에서 데이터가 어디를 흐르는지 눈으로 볼 수 있습니다. 로봇 개발에서 이건 생각보다 엄청난 장점입니다.

메시지: 데이터가 오가는 약속된 형식

토픽을 이해했다면 메시지도 함께 알아야 합니다. 메시지는 토픽을 통해 오가는 데이터의 형식입니다. 쉽게 말해 "이 통로로는 어떤 모양의 데이터를 보낼 것인가?"에 대한 약속입니다.

예를 들어 속도 명령을 보낼 때는 단순히 go fast 같은 문자열을 보내지 않습니다. 보통은 선속도와 각속도를 담는 정해진 구조를 사용합니다. ROS 2 공식 튜토리얼에서도 geometry_msgs/msg/Twist 같은 메시지 형식을 통해 선형 속도와 회전 속도를 주고받는 예시를 보여 줍니다.⁴

이 약속이 중요한 이유는, 로봇 시스템이 커질수록 "이 데이터가 무슨 뜻인지"를 말로 추측하면 안 되기 때문입니다. 메시지 형식이 정해져 있으면 퍼블리셔와 서브스크라이버는 같은 문법으로 대화할 수 있습니다.

쉽게 비유해 보겠습니다. 토픽이 택배 도로라면, 메시지는 상자의 규격입니다. 상자 크기와 내용 표기가 정해져 있으면 물류가 빨라집니다. 반대로 누군가는 숫자 두 개를 보내고, 누군가는 문자열로 보내고, 누군가는 순서를 바꿔 보내면 사고가 납니다.

개인 프로젝트에서도 메시지는 중요합니다. 처음에는 내 코드니까 대충 맞춰도 될 것 같지만, 프로젝트가 길어질수록 과거의 내가 보낸 데이터를 현재의 내가 해석 못 하는 순간이 옵니다. 메시지는 그 혼란을 줄여 줍니다.

서비스: 짧고 분명한 요청에 적합하다

토픽이 "계속 흘러가는 데이터"라면, 서비스는 "한 번 묻고 한 번 답받는 요청"에 가깝습니다. ROS 2에서는 서비스를 빠르게 끝나는 요청-응답 작업에 쓰는 것을 권장합니다.³

예를 들어 이런 경우입니다.

• 현재 배터리 상태를 물어보기

• 카메라 노출 값을 바꾸기

• 특정 센서를 리셋하기

• 로봇팔 목표 자세가 도달 가능한지 검사하기

서비스는 전화 통화와 비슷합니다. 클라이언트가 서버에게 "이거 가능해?" 하고 묻고, 서버가 "된다" 또는 "안 된다"라고 답합니다. 중요한 점은 서비스는 오래 끄는 작업에 쓰지 않는 편이 좋다는 것입니다.³

예를 들어 "주방까지 이동해" 같은 명령은 몇 초, 몇 분이 걸릴 수도 있습니다. 이런 작업을 서비스로 처리하면, 요청은 했는데 중간 진행 상황도 모르고 취소도 어렵습니다. 그래서 서비스는 짧고 명확한 일에 쓰는 것이 자연스럽습니다.

초보자 입장에서는 이것만 기억해도 좋습니다. 계속 흐르면 토픽, 한 번 묻고 끝나면 서비스입니다.

액션: 오래 걸리는 작업에는 중간 보고가 필요하다

로봇에는 시간이 걸리는 일이 많습니다. 목표 지점까지 이동하기, 물체를 집기, 도킹하기, 방 한 바퀴 순찰하기 같은 작업이 그렇습니다. 이런 일은 시작도 있고 끝도 있지만, 중간 과정도 중요합니다.

바로 이런 상황을 위해 ROS 2에는 액션이 있습니다. 액션은 목표, 피드백, 결과라는 세 가지 요소로 이루어진 통신 방식이며, 오래 걸리는 작업에 적합합니다.³⁵

예를 들어 "책상 오른쪽 끝까지 이동해"라는 목표를 보냈다고 해봅시다. 그동안 로봇은 이런 정보를 줄 수 있습니다.

• 지금 20% 진행됨

• 장애물을 피하는 중

• 목적지까지 0.5m 남음

• 작업 완료 또는 실패

게다가 액션은 취소도 할 수 있습니다.⁵ 로봇이 이동 중인데 갑자기 "멈춰"라고 해야 할 때, 액션 구조가 특히 빛납니다.

이 차이는 실제 로봇에서 아주 중요합니다. 서비스는 "요청하고 응답받는다"에 가깝고, 액션은 "작업을 맡기고 진행 상황을 보며 필요하면 중단한다"에 가깝습니다. 로봇의 행동은 대부분 현실 세계에서 시간이 걸리므로, 액션은 생각보다 자주 등장합니다.

간단히 정리하면 이렇습니다.

• 토픽: 계속 흐르는 데이터

• 서비스: 짧은 요청과 응답

• 액션: 오래 걸리는 목표 지향 작업

이 세 가지를 구분할 수 있으면, ROS 2 통신 구조의 절반은 이해한 셈입니다.

왜 굳이 이렇게 나눠야 할까

여기서 이런 질문이 자연스럽게 나옵니다.

"그냥 전부 토픽으로 보내면 안 되나요?"

기술적으로는 억지로 할 수 있습니다. 하지만 그러면 의미가 흐려집니다. 예를 들어 "현재 카메라 이미지"와 "도킹 작업 요청"과 "도킹 진행률"은 전혀 다른 종류의 데이터입니다. 전부 같은 방식으로 다루면 코드가 편해지는 것이 아니라, 오히려 의도가 사라집니다.

좋은 시스템 설계는 단순히 데이터가 오가게 만드는 것이 아니라, 그 데이터의 성격을 드러내는 것입니다. ROS 2가 토픽, 서비스, 액션을 따로 둔 이유가 여기에 있습니다. 각 통신 방식이 "이건 스트림이다", "이건 짧은 질의다", "이건 시간이 걸리는 행동이다"라는 뜻을 품고 있기 때문입니다.³

이 의미 구분은 코드 읽기와 디버깅에서 큰 차이를 만듭니다. /camera/image_raw를 보면 연속 영상 데이터라는 걸 알 수 있고, /reset_odometry를 보면 짧은 호출이라는 걸 알 수 있으며, /navigate_to_pose를 보면 목표 기반 행동이라는 걸 짐작할 수 있습니다. 이름만 봐도 시스템의 흐름이 읽히는 구조가 되는 것입니다.

ROS 2가 커질수록 강해지는 이유

작은 프로젝트에서는 ROS 2가 오히려 무겁게 느껴질 수 있습니다. 센서 하나, 모터 두 개, 조건문 몇 개면 끝나는 로봇이라면 아두이노 코드 한 파일이 더 빠를 수도 있습니다. 이건 사실입니다.

하지만 기능이 3개에서 8개가 되고, 센서가 1개에서 4개가 되고, 제어 보드와 AI 보드가 나뉘고, 시뮬레이터와 실제 하드웨어를 번갈아 써야 하는 순간 이야기가 달라집니다. 그때부터 ROS 2는 갑자기 "무거운 프레임워크"가 아니라 "질서를 만들어 주는 도구"가 됩니다.

ROS 2가 규모가 커질수록 강한 이유는 크게 네 가지입니다.

• 분리: 센서, 인식, 계획, 제어를 역할별로 나눌 수 있습니다.

• 교체: 카메라나 알고리즘을 바꿔도 전체 구조를 덜 흔듭니다.

• 관찰: 토픽과 노드 상태를 도구로 들여다보며 디버깅할 수 있습니다.

• 확장: 한 컴퓨터에서 돌리던 코드를 여러 장치에 나눠 배치하기 쉽습니다.

이 네 가지는 개인 개발자에게도 매우 실용적입니다. 특히 "교체"와 "관찰"이 큽니다. 로봇 개발은 늘 뭔가를 바꿔 가며 실험하는 과정이기 때문입니다. 센서를 바꾸고, 알고리즘을 바꾸고, 시뮬레이터로 먼저 시험하고, 나중에 실물에 붙입니다. ROS 2는 이 반복 실험을 견디기 좋은 구조를 제공합니다.

개인 개발자 프로젝트에 대입해 보면 더 잘 보인다

지금까지 만든 프로젝트를 떠올려 봅시다.

장애물 회피 이동 로봇은 비교적 단순합니다. 거리 센서 읽기, 충돌 판단, 모터 제어 정도면 됩니다. 이 단계에서는 ROS 2 없이도 충분히 구현할 수 있습니다.

하지만 카메라 인식 로봇부터는 이야기가 달라집니다. 카메라 입력, 이미지 전처리, 객체 인식, 결과 시각화, 주행 반응이 동시에 움직입니다. 여기에 음성 명령 로봇이 되면 마이크, STT, LLM, 명령 해석, 안전 검사, 실제 모터 제어가 얽힙니다. 데스크 어시스턴트 로봇이라면 표정 출력, 카메라 감시, 알림, 간단한 행동, 사용자 상호작용까지 붙습니다.

이쯤 되면 한 파일 구조는 금방 무너집니다. 예를 들어 "사용자가 '컵을 찾아 줘'라고 말했다"는 정보는 음성 처리 쪽에서 나옵니다. "카메라에 컵이 보였다"는 정보는 비전 쪽에서 나옵니다. "지금 모터를 움직여도 안전한가?"는 제어 쪽에서 판단해야 합니다. 이 셋을 한 함수 안에서 뒤엉키게 만드는 것보다, 각각을 노드로 분리하고 정해진 방식으로 연결하는 편이 훨씬 낫습니다.

바로 여기서 ROS 2의 가치가 선명해집니다. ROS 2는 복잡함을 없애 주지 않습니다. 대신 복잡함을 관리 가능한 모양으로 나눠 줍니다.

ROS 2는 표준 도구가 아니라 공용 언어에 가깝다

"표준"이라는 말을 들으면 정답 하나만 떠오르기 쉽습니다. 하지만 ROS 2는 세상의 모든 로봇이 반드시 써야 하는 유일한 답은 아닙니다. 작은 임베디드 장치만으로 끝나는 프로젝트에는 더 단순한 방법이 맞을 수도 있습니다.

그런데도 ROS 2가 사실상 표준 도구로 받아들여지는 이유는, 많은 로봇 개발자가 이미 이 공용 언어를 사용하고 있기 때문입니다. 로봇 세계에는 센서 드라이버, 시각화 도구, 시뮬레이션 연결, 내비게이션, 제어, 로깅 같은 공통 문제가 반복해서 등장합니다. ROS 2는 이런 문제를 풀기 위한 생태계와 공통 인터페이스를 제공합니다.¹²

쉽게 말해, ROS 2를 쓰면 나 혼자 모든 배관을 새로 깔 필요가 줄어듭니다. 카메라 데이터를 어떻게 보여 줄지, 노드끼리 어떻게 연결됐는지 어떻게 볼지, 장기 작업은 어떤 방식으로 요청할지 같은 기본 규칙이 이미 잡혀 있습니다. 그래서 개인 개발자도 더 빨리 "로봇다움"에 도달할 수 있습니다.

혼자 만드는 프로젝트에서 이건 큰 힘입니다. 혼자 하다 보면, 진짜 만들고 싶은 기능보다 주변 인프라를 만드는 데 시간이 더 많이 들 때가 많습니다. ROS 2는 그 주변 인프라의 상당 부분을 이미 제공해 줍니다.

너무 일찍 모든 걸 ROS 2로 바꿀 필요는 없다

여기서 균형 잡힌 시각도 필요합니다. ROS 2가 훌륭하다고 해서, LED 하나 깜빡이는 프로젝트까지 거대한 구조로 시작할 필요는 없습니다.

개인 개발자에게 더 현실적인 접근은 이렇습니다. 처음에는 단순하게 만들고, 다음과 같은 순간이 오면 ROS 2를 도입하는 것입니다.

• 코드가 한 파일에서 감당이 안 될 때

• 센서와 제어를 분리하고 싶을 때

• 카메라, 음성, 주행을 함께 다룰 때

• 시뮬레이션과 실물을 같은 구조로 연결하고 싶을 때

• 나중에 기능을 계속 늘릴 계획이 있을 때

즉 ROS 2는 "처음부터 무조건"이 아니라, 프로젝트의 성장통을 버티게 해 주는 구조적 선택에 가깝습니다. 작은 로봇에는 과할 수 있지만, 조금만 커져도 왜 다들 이 도구를 쓰는지 체감하게 됩니다.

이 장에서 꼭 가져가야 할 그림

이 장의 핵심 그림은 머릿속에 이렇게 남기면 됩니다.

로봇은 하나의 거대한 프로그램이 아니라, 여러 기능이 연결된 시스템입니다. ROS 2에서는 각 기능을 노드로 나누고, 계속 흐르는 데이터는 토픽으로, 짧은 요청은 서비스로, 시간이 걸리는 작업은 액션으로 다룹니다. 그리고 메시지는 그 사이를 오가는 데이터의 약속된 형식입니다.

이 구조의 장점은 멋있어 보인다는 데 있지 않습니다. 고장 난 부분을 찾기 쉽고, 기능을 바꾸기 쉽고, 시스템을 키우기 쉽다는 데 있습니다. 그래서 규모가 커질수록 ROS 2의 필요성이 커집니다.

작은 프로젝트에서는 한 파일이 더 빨라 보일 수 있습니다. 하지만 개인 로봇이 점점 더 똑똑해지고, 더 많은 센서와 AI 모델을 품게 될수록, 우리는 결국 "코드를 어떻게 나눌 것인가"라는 질문과 마주치게 됩니다. ROS 2는 그 질문에 대해 가장 널리 쓰이는 실전 답안 중 하나입니다.

정리

ROS 2는 단순한 라이브러리 묶음이 아니라, 로봇 소프트웨어를 모듈식 시스템으로 설계하게 만드는 도구입니다. 노드는 역할을 나누고, 토픽은 연속 데이터를 흐르게 하고, 메시지는 데이터 형식을 맞추고, 서비스는 짧은 요청을 처리하고, 액션은 오래 걸리는 작업을 관리합니다.

혼자 만드는 작은 로봇에서는 이 구조가 과해 보일 수 있습니다. 하지만 카메라, 음성, AI, 이동, 조작이 하나의 로봇 안에 모이기 시작하면, 오히려 이런 구조가 없어서 더 힘들어집니다.

이제부터 ROS 2를 "배워야 하는 어려운 프레임워크"로 보기보다, 복잡한 로봇을 사람 머리로 관리 가능한 크기로 나누는 방법으로 바라보면 좋습니다. 그 감각이 생기면 다음 장에서 센서와 모터를 ROS 2로 연결하는 과정도 훨씬 자연스럽게 이해될 것입니다.

참고

¹ROS 공식 소개

²Robot Operating System 2: Design, Architecture, and Uses In The Wild

³Topics vs Services vs Actions

⁴Understanding topics — ROS 2 Documentation: Humble documentation

⁵Understanding actions — ROS 2 Documentation: Rolling documentation