ROS의 역사와 배경
Willow Garage 시절
ROS(Robot Operating System)의 기원은 2007년 무렵, 미국 캘리포니아에 위치한 로보틱스 연구소인 Willow Garage에서부터 비롯되었다. Willow Garage는 당시 로봇 소프트웨어 생태계가 각 로봇 연구 그룹마다 독립적으로 개발되고 유지보수되는 점에 주목했다. 연구자가 달라질 때마다 코드를 재사용하기 어려워지고, 표준화된 방식 없이 하드웨어와 소프트웨어가 뒤섞여 개발되어 혼선이 커지는 문제가 있었다. 이 문제를 해결하기 위해 하나의 통합된 로봇 소프트웨어 프레임워크가 필요하다고 판단하였고, 그 결과가 바로 ROS였다.
오픈 소스 로보틱스 발전 배경
오픈 소스 로보틱스에 대한 관심은 학계와 산업계에서 점차 늘어나고 있었다. 로보틱스를 연구하는 많은 기관과 기업들은 하드웨어는 어느 정도 표준화와 상호운용성(interoperability)을 고민해 왔지만, 소프트웨어 측면에서 이러한 흐름이 부족했다. Willow Garage를 비롯한 다양한 기관은 오픈 소스 철학이 로봇 소프트웨어에도 적용되어야 한다고 보았으며, 이를 통해 기술 발전의 가속과 효율적인 협업이 가능하다고 믿었다.
ROS는 당시 Willow Garage 내부의 연구 프로젝트 및 지원 프로젝트에 폭넓게 적용되었으며, 외부 로봇 연구 기관과 협력하며 빠르게 발전해 나갔다. 로보틱스 연구자들은 ROS를 통해 센서 퓨전, 경로 계획, SLAM, 컴퓨터 비전 등 다양한 로보틱스 알고리즘을 공유하고 통합하기 시작했다.
ROS의 인프라 철학
ROS(특히 ROS 1)는 커뮤니티가 개발한 다양한 소프트웨어 패키지를 쉽게 가져다 쓸 수 있도록 설계되어 있다. 예컨대 센서 데이터나 로봇의 상태 데이터를 주고받는 방식을 표준화하여, 각기 다른 하드웨어에서도 동일한 통신 프로토콜을 통해 연구 개발이 이뤄지도록 했다. 이를 위해 ROS는 노드(Node)와 메시지(Message), 그리고 토픽(Topic)이라는 핵심 개념을 도입했다. 이러한 추상화(Abstraction)를 통해 연구자들은 하드웨어 제어나 드라이버 개발보다 고차원적인 로봇 학습, 자율 주행 등의 알고리즘 구현에 집중할 수 있었다.
좌표 변환의 수학적 중요성
ROS의 핵심 기능 중 하나는 좌표계 변환을 쉽게 처리하는 TF(transform) 라이브러리이다. 예컨대 로봇의 여러 부품(베이스, 조인트, 그리퍼 등)과 외부 센서(LiDAR, 카메라 등)가 서로 다른 좌표계를 사용할 때, 모든 데이터와 동작이 일관성 있게 해석되려면 통일된 참조 좌표계를 통해 변환이 이뤄져야 한다.
일반적인 로봇 조인트 각도를 $\mathbf{q}$ 라고 할 때, 전방운동학(Forward Kinematics)을 통해 얻어지는 각 조인트 말단(End-Effector)의 위치와 자세는 다음처럼 표현할 수 있다.
여기서 $\mathbf{R}(\mathbf{q})$는 회전 행렬이고, $\mathbf{d}(\mathbf{q})$는 변위 벡터이다. ROS는 이러한 좌표 변환 과정을 “노드 간 통신” 또는 “토픽” 방식으로 모듈화하여, 로봇 시스템 전체가 동일한 시공간적 기준을 공유할 수 있도록 한다.
OSRF(오픈 소스 로보틱스 재단)의 탄생
Willow Garage에서 시작된 ROS가 학계와 산업계 모두에서 주목받게 되자, 이를 더욱 체계적으로 관리하고 발전시킬 수 있는 기관이 필요해졌다. 그래서 2012년 경에 오픈 소스 로보틱스 재단(Open Source Robotics Foundation, OSRF)이 출범하여, ROS 및 Gazebo 시뮬레이터 등 핵심 오픈 소스 로보틱스 프로젝트의 관리와 커뮤니티 지원을 담당하게 되었다. 이로써 Willow Garage에서 벗어나 ROS는 더욱 폭넓은 영역에서 연구개발이 가능해졌고, 여러 버전이 지속적으로 발표되며 기능과 성능이 향상되어 왔다.
ROS Distro의 등장
ROS(ROS 1)가 점차 성숙해짐에 따라, 개발자들은 특정 시점에서의 ROS 기능과 API를 공식적으로 묶어 배포할 필요성을 느꼈다. 그 결과, 일정 주기마다 “ROS Distro(Distribution)”가 발표되었다. 초기에는 Box Turtle, C Turtle, Diamondback, Electric, Fuerte 등과 같이 이름이 독특한 버전들이 순차적으로 출시되었으며, 각 버전마다 호환되는 패키지 및 기능이 정해져 있었다. 이 방식을 통해 서로 다른 시점에서 개발된 로보틱스 프로젝트라도 동일한 ROS Distro에서 통합 운용이 가능하게 되었다.
ROS Distro의 관리 체계
ROS Distro는 발표 주기가 정해져 있으며, 오픈 소스 커뮤니티 참여자(개발자, 연구자, 기업 등)들이 협력하여 안정성, 새로운 기능의 추가, 결함 수정 등을 관리한다. 예컨대 “LTS(Long Term Support)”가 부여된 Distro는 일정 기간 동안 보안 업데이트와 버그 수정을 우선적으로 지원받는다. 이는 장기간 운용이 필요한 산업용 로봇 시스템에 특히 유용하다.
이 과정을 통해 ROS는 “빠르게 변화하는 최첨단 기능”과 “안정적이고 성숙한 기능”을 동시에 제공하려는 전략을 취하게 되었다. 일반 사용자나 연구기관은 필요에 따라 LTS 버전을 선택하거나, 최신 버전을 추적하며 혁신적인 기능을 빠르게 받아들일지 결정할 수 있었다.
로보틱스 커뮤니티의 확장
ROS가 공개되면서 전 세계 로보틱스 커뮤니티의 규모가 빠르게 확장되었다. 대학 연구실, 정부 연구소, 민간 기업, 로봇 애호가 등 다양한 주체가 ROS를 사용하여 로봇 제어, 센서 데이터 처리, 인공지능 알고리즘 통합 등을 진행하였다. 커뮤니티 내에서는 다음과 같은 활동이 활발히 이뤄졌다.
사용자 그룹(Users Group), ROSCon(ROS 컨퍼런스) 등 정기·비정기 모임
GitHub, ROS Answers 포럼 등을 통한 문제 해결 및 노하우 공유
개별 하드웨어용 드라이버, SLAM·네비게이션·매니퓰레이션 알고리즘 패키지 개발
심지어 비로보틱스 분야(드론, 자율주행 차량, 물류 자동화 등)에서도 ROS 적용
이러한 커뮤니티 활동으로 인해 로보틱스 오픈 소스 생태계는 유례없이 빠르게 커졌고, ROS는 사실상 “표준(de facto standard)”이 되었다.
산업계에서 ROS
처음에는 연구 및 교육 용도로만 사용되었던 ROS가, 점차 산업계에서도 주목받기 시작했다. 특히 다음과 같은 특징들이 산업계의 관심을 끌었다.
개발 비용 절감: 기초적인 로봇 소프트웨어 구성요소를 오픈 소스로 이용함으로써 초기 개발 비용이 낮아진다.
유연한 확장성: 하드웨어 의존도를 최소화한 ROS 구조 덕분에 새로운 센서나 액추에이터가 도입되어도 큰 구조 변환 없이 추가 가능하다.
커뮤니티의 기술력: 연구 최전선에서 개발되는 SLAM, 경로 계획, 컴퓨터 비전 알고리즘 등이 ROS 패키지로 공개돼 있으므로, 이를 손쉽게 도입할 수 있다.
이후 산업용 로봇에 ROS를 적용하려는 시도들이 증가하자, ROS 2로의 개발 방향성도 “실제 산업 현장에서의 요구 사항(실시간성, 보안, 분산성 등)을 충족시키기 위해 시스템 아키텍처를 개선한다”는 전략으로 자리잡게 되었다.
ROS 기반 하드웨어의 진화
대학 연구실에서 만들어진 시제품 로봇은 ROS를 활용해 빠르게 프로토타이핑이 가능해졌다. 수많은 스타트업과 기업들은 ROS 호환성을 강조하며 자사 제품(로봇 팔, AGV, 자율주행 플랫폼 등)을 내놓았다. 예컨대 이동 로봇 업체들은 LiDAR, Depth 카메라 등을 포함한 전체 시스템을 ROS 패키지 형태로 제공하여, 연구자나 엔지니어가 쉽게 실험할 수 있도록 했다.
더 나아가, ROS에서 자주 활용되는 대표적인 하드웨어 플랫폼(예: TurtleBot 시리즈)은 오픈 하드웨어+소프트웨어 형태로 설계되어 학습 및 개발에 큰 기여를 했다.
로봇 시뮬레이션과 Gazebo
Gazebo 시뮬레이터는 Willow Garage 및 OSRF 시절부터 ROS와 밀접하게 통합되어 발전해 왔다. Gazebo는 물리 엔진(동역학 시뮬레이션), 3D 렌더링, 가상 센서 시뮬레이션 등을 제공함으로써, 실제 로봇이 없어도 가상 환경에서 로봇 알고리즘을 시험할 수 있게 한다.
이를 통해 로보틱스 연구자들은 하드웨어 결함, 안전사고, 비용 부담 없이 대규모 실험을 수행할 수 있었다. ROS 패키지를 통해 실제 로봇 제어 코드를 시뮬레이터와 쉽게 연결할 수 있으므로, 물리 실험과 가상 실험 간 스위칭이 용이하다.
ROS 2의 등장 배경
ROS 1이 연구와 교육 분야에서 성공적으로 자리 잡았지만, 산업 환경의 요구 사항을 충족하기에는 여러 가지 한계가 드러났다. 예컨대, 높은 확장성과 신뢰성, 보안, 실시간성, 멀티 로봇 운영에 대한 요구가 증가하면서 ROS 아키텍처 전반을 재설계할 필요성이 제기되었다. 이를 계기로 ROS 2 프로젝트가 시작되었으며, 다음과 같은 점들이 주요 개발 동기가 되었다.
분산 처리와 통신 프로토콜의 진화 ROS 1에서는 토픽 기반 메시지 통신을 자체 개발한 ROS Master(노드 발견, 토픽 관리) 방식에 크게 의존하였다. 그러나 멀티 로봇 환경이나 대규모 분산 시스템에서 확장성을 높이기 위해, DDS(Data Distribution Service)와 같은 표준화된 미들웨어를 도입해야 한다는 요구가 커졌다. 이는 노드 간 통신 구조를 바탕부터 교체해야 하는 작업이었으며, 기존 ROS 1 아키텍처로는 구현하기 어려웠다.
실시간(Real-time) 요구 협동 로봇이나 자율 주행 차량처럼 안전과 직결되는 로봇 시스템에서는 일부 노드의 응답 지연을 엄격하게 제한해야 한다. ROS 1은 주로 일반적인 사용자 환경에서 동작하도록 설계되었기에, 실시간 스케줄링이나 QoS(Quality of Service) 보장 기능이 미흡했다. 따라서 ROS 2에서는 DDS를 활용한 다양한 QoS 정책(이중 버퍼링, 이중화, 신뢰 전송 등)이 적용될 수 있도록 설계 방향을 잡았다.
보안(Security) 강화 로봇 시스템이 네트워크를 통해 연결되고, 클라우드 기반 서비스를 점점 더 많이 활용함에 따라, 각종 사이버 공격이나 데이터 유출에 대비할 필요성이 높아졌다. ROS 1의 기본 구조에서는 메시지 암호화, 인증, 접근 제어 등을 체계적으로 지원하기가 어려웠다. 반면 DDS는 산업용 시스템에서 이미 검증된 보안 확장 기능(DDS Security)을 지원하므로, 이를 ROS 2에 도입함으로써 보안 취약점을 보완하고자 했다.
멀티 로봇 및 대형 시스템 확장성 ROS 1은 여러 대의 로봇을 동시에 운용하거나, 기업 수준의 대규모 로봇 플릿(fleet)을 구성하는 시나리오에 대한 경험이 상대적으로 적었다. ROS 2에서는 노드 자동 발견, 동적 네트워크 구성, ROS Master 종속성 제거 등을 통해 멀티 로봇 간 데이터 교환과 협업을 보다 수월하게 할 수 있는 구조로 변경하였다.
ROS 1에서 ROS 2로의 이행
ROS 2의 등장은 단순히 기존 ROS 1을 “업그레이드”하는 수준이 아니라, 내부의 통신 미들웨어와 아키텍처를 완전히 재설계하는 과정을 의미했다. 때문에 ROS 1 패키지들을 그대로 ROS 2에서 사용하는 것은 쉽지 않았으며, 새로운 API와 빌드 시스템, 노드 실행 방법 등이 제시되었다. 이를 위해 개발자 커뮤니티는 “ROS 1 브리지(bridge)”나 “mentoring” 프로젝트를 운영하여, ROS 2 생태계가 빠르게 구축될 수 있도록 노력했다.
아직도 많은 로봇 연구기관과 기업들은 ROS 1에 남아 있으나, 차츰 ROS 2로 전환하는 추세가 이어지고 있다. ROS 1의 일부 기능(예: MoveIt, Navigation 등)은 ROS 2용으로 재작성되어 제공되었으며, 특히 산업계와 협력하여 실용화에 집중하는 패키지들이 늘고 있다.
ROS 2와 수학적 시스템 구성
ROS 2는 로봇 제어 시스템의 구조적 설계를 수학적으로 접근하는 것이 한층 수월해진다는 특징이 있다. 예컨대, 여러 로봇의 동작을 통합 제어하기 위해서는 “멀티 로봇 동역학(Multi-robot dynamics)” 문제를 풀어야 한다. 간단히 두 로봇 A, B가 서로 다른 국소 좌표계에서 주행할 때, 각 로봇의 상태 벡터를 $\mathbf{x}_A(t)$, $\mathbf{x}_B(t)$라 하자.
이때 상호 충돌을 회피하고 최적 경로를 찾기 위해서는, 두 로봇의 상태를 하나의 확장 상태 벡터 $\mathbf{x}_{\mathrm{combined}}(t)$로 묶어 경로 계획 알고리즘을 적용하기도 한다.
ROS 2는 이러한 확장 상태 벡터 기반 알고리즘을 분산 환경에서 동시에 처리할 수 있는 통신 프레임워크를 제공한다. 예컨대 DDS 기반 QoS 정책을 통해 각 로봇 노드가 서로의 위치/속도 정보를 실시간으로 교환하며, 충돌 방지와 협업을 빠르게 수행할 수 있다.
오픈 소스 로보틱스의 미래
ROS 2로의 전환은 오픈 소스 로보틱스가 연구실 중심에서 산업 응용, 자율 주행, 클라우드 로보틱스 등으로 영역을 확장하는 중요한 전환점이 되었다. 각 국가 및 지역별로 ROS 2에 특화된 컨소시엄과 교육 프로그램이 등장하고 있으며, 기업들도 ROS 2 호환성을 갖춘 제품을 잇따라 출시하고 있다.
ROS 자체가 단일 소프트웨어가 아닌 “로봇 소프트웨어 생태계”에 가깝다는 점에서, 이 생태계가 어떻게 성장하고 유지되는지는 로봇 공학 전반에 큰 파급력을 미친다. OSRF 및 ROS 커뮤니티는 이러한 생태계가 중단 없이 이어질 수 있도록 다양한 활동(ROS 2 TSC(Technical Steering Committee), ROSCon, 워킹 그룹 등)을 통해 표준화와 협업을 진행 중이다.
ROS 2 배포판(Distro) 명명과 역사
ROS 1 시절부터 이어진 Distro(배포판) 문화는 ROS 2에서도 고유의 이름을 사용해 주기적으로 버전을 발표하는 형태를 유지하고 있다. ROS 2 초기에는 “Ardent Apalone(2017)”이라는 이름으로 첫 배포판이 공개되었으며, 이후 알파벳 순으로 버전 이름의 첫 글자를 정하여 다음과 같은 배포판이 잇달아 등장했다.
Ardent Apalone (12/2017) ROS 2의 첫 정식 버전으로, DDS 기반 아키텍처의 기본 프레임워크가 구축되어 있었다. 기능은 아직 제한적이었으나, 기존 ROS 1에서 사용하던 핵심 요소들(예: Nodes, Topics, Packages)을 ROS 2용으로 변환하기 위한 초석을 마련했다.
Bouncy Bolson (06/2018) Ardent에서의 피드백을 반영하여 API를 안정화하고, 멀티 플랫폼 윈도우(Windows), 리눅스(Linux), macOS 간 호환성을 높였다. 일부 실험적 기능도 도입되어, 커뮤니티가 ROS 2에 적응할 수 있도록 유도했다.
Crystal Clemmys (12/2018) ROS 1과의 브리지(bridge) 기능이 개선되어, 기존 ROS 1 패키지를 ROS 2 환경과 혼합해 사용할 수 있는 가능성을 열었다. 또한, 여러 DDS 구현체(Fast RTPS, Cyclone DDS 등)와의 호환성이 실무에서 조금씩 안정화되었다.
Dashing Diademata (05/2019) ROS 2의 첫 LTS 버전 중 하나로 꼽힌다. 장기 지원을 통해 산업 현장에 ROS 2를 도입하려는 기업들이 이 버전을 채택하기도 했다. 멀티 로봇 및 네트워크에 특화된 QoS 정책 설정, 라이프사이클 노드(Lifecycle Node) 기능 등이 정식으로 추가되어 시스템 안정성을 높였다.
Eloquent Elusor (11/2019) 성능 최적화와 개발 편의성을 개선하였다. 노드 간 메시지 교환 속도가 향상되었고, ros2cli 등 명령줄 인터페이스 도구의 사용성이 다듬어졌다. 이는 개발자들이 ROS 2의 복잡한 통신 설정을 보다 쉽게 다룰 수 있게 해주었다.
Foxy Fitzroy (06/2020) 산업계 수용을 염두에 두고, 다시 한번 LTS(Long-Term Support) 딱지가 붙었다. Foxy 버전부터는 점진적으로 ROS 2 패키지 에코시스템이 확대되며, ROS 1에서 널리 쓰이던 MoveIt, Navigation 등의 핵심 패키지들이 ROS 2 버전으로 이전되기 시작했다.
Galactic Geochelone (05/2021) DDS를 이용한 노드 간 통신이 보다 유연해졌고, rclcpp/rclpy 등 ROS 2용 라이브러리들의 API가 어느 정도 정착 단계에 접어들었다. 실시간 시스템에서의 적용 사례가 늘면서, ROS 2에 대한 연구 개발이 다양한 기관과 프로젝트로 확산되었다.
Humble Hawksbill (05/2022) 본서에서 다루는 주요 버전으로, 고도화된 실시간성 지원, 네트워크 품질(QoS) 상세 설정, 보안 기능 강화를 통해 “산업용 ROS”로서의 기틀을 닦았다는 평가를 받는다. 특히 멀티 스레드, 멀티 노드 실행 환경에서 성능이 개선되어 많은 로봇 전문기업이 Humble 버전을 사용하기 시작했다.
Iron Irwini (05/2023) Humble의 개선 사항을 이어받았으며, 다양한 하드웨어 가속(AI, GPU 병렬 처리 등)을 지원하는 플러그인들이 발표되었다. 또한, ROS 2 생태계에서 이미 표준으로 자리 잡아가던 DDS 구현체 간 호환성 테스트가 활발히 진행되어, 실무 적용 시 발생하는 문제들이 빠르게 해결되기 시작했다.
위와 같은 ROS 2 배포판 역사 속에서, 로보틱스 분야의 요구 사항(실시간성, 안정성, 확장성, 보안 등)이 버전마다 점차 구체적으로 반영되고 있다. 이는 기존 ROS 1에서 경험했던 연구와 개발의 성과를 산업계가 효과적으로 활용하도록 돕는 핵심 동력이 되고 있다.
Last updated