로봇이 고장 났을 때 '그때 그 순간'을 똑같이 되감아 볼 수 있다면? MIT 박사들이 만든 차세대 로봇 운영 체제 '세릴리온'

AI Summary

MIT 로보틱스 박사 출신들이 개발한 오픈소스 로봇 런타임 '세릴리온'은 제로카피 공유 메모리와 결정론적 리플레이를 통해 로봇 개발 시간을 최대 10배 단축합니다.

로봇 공학자들에게 가장 악몽 같은 순간은 언제일까요? 공장이나 실험실 한가운데서 고가의 자율주행 로봇이 갑자기 멈춰 섰거나 엉뚱한 방향으로 돌진했을 때입니다. 현장에서 로봇을 멈추고 로그를 뒤져보지만, 똑같은 상황을 다시 재현하기란 하늘의 별 따기입니다. 마치 영화 속 한 장면처럼, 원인을 찾지 못한 채 ‘어쩌다 한 번 발생한 버그(Heisenbug, 관찰하려고 하면 사라지거나 재현되지 않는 기괴한 버그)’로 치부하고 넘어가기 일쑤였습니다 [Source 1].

로봇 소프트웨어 개발의 이러한 오랜 고통을 정면으로 겨냥한 오픈소스 프로젝트가 등장했습니다 [Source 4, Source 9]. MIT 로보틱스 박사 출신 엔지니어들이 개발한 세릴리온(Cerulion, 로봇의 소프트웨어 실행을 관리하고 조율하는 런타임)이 바로 그 주인공입니다 [Source 1, Source 4, Source 9]. 기존 로봇 표준 미들웨어인 ROS 2(Robot Operating System 2, 로봇 소프트웨어 개발을 위해 널리 쓰이는 표준 미들웨어)의 장점을 고스란히 살리면서도, 통신 속도를 획기적으로 높이고 실패한 순간을 완벽하게 되감아 분석할 수 있는 기능을 갖추고 있어 글로벌 개발자 커뮤니티의 뜨거운 관심을 받고 있습니다 [Source 1, Source 2, Source 11].

이게 왜 중요한가요?

상상해보세요. 여러분이 수십억 원짜리 물류 로봇이나 오프로드 자율주행 차량을 개발하는 엔지니어입니다. 로봇에는 수많은 센서—예컨대 2개의 라이다(Lidar, 레이저를 이용해 주변 지형과 물체를 감지하는 센서)와 6개의 카메라—가 장착되어 매 순간 엄청난 양의 데이터를 쏟아냅니다 [Source 1].

이 데이터들을 로봇 안의 여러 프로그램(프로세스)들이 서로 주고받아야 하는데, 기존 시스템에서는 이 과정에서 지연(Delay)이 발생하거나 표준화된 데이터 형식 제약 때문에 발목을 잡히곤 했습니다 [Source 1]. 결국 개발자들은 어쩔 수 없이 모든 프로그램을 하나의 거대한 프로세스 안에 억지로 우겨넣는 불안정한 방식을 택해왔고, 이는 곧 디버깅(Debugging, 소프트웨어 오류를 찾아 수정하는 과정)을 지옥으로 만드는 원인이 되었습니다 [Source 1].

세릴리온은 이러한 물리 AI(Physical AI, 디지털 지능이 실제 물리적 로봇 몸체와 결합하여 작동하는 기술) 시대의 근본적인 인프라 문제를 해결합니다 [Source 4, Source 9]. 로봇 개발의 복잡성을 낮추어 전반적인 개발 시간을 최대 10배까지 단축할 수 있게 돕는 것입니다 [Source 4]. 이는 단순히 개발자들의 야근을 줄여주는 것을 넘어, 자율주행차나 물류 로봇의 안전성과 상용화 속도를 획기적으로 앞당기는 중요한 전환점입니다.

쉽게 이해하기: 대형 화이트보드와 비행기 블랙박스

기술의 원리를 조금 더 쉽게 살펴볼까요? 세릴리온의 핵심 장점인 ‘빠른 통신’과 ‘완벽한 되감기’는 일상적인 비유로 쉽게 이해할 수 있습니다.

1. 복사기 대신 대형 화이트보드 쓰기 (제로카피 공유 메모리)

기존 로봇 시스템에서 여러 부서(프로세스)가 데이터를 주고받는 과정은 마치 중요한 서류를 복사해서 각 부서에 일일이 전달하는 방식과 같습니다. 부서가 늘어나고 서류(예: 고화질 이미지나 포인트 클라우드 데이터)가 거대해지면 복사하고 전달하는 데만 엄청난 시간이 걸립니다 [Source 1]. 특히 표준화된 규격(POD, Plain Old Data)만을 강제하다 보니 범용적인 이미지나 센서 데이터를 처리할 때 시스템이 꽉 막히곤 했습니다 [Source 1].

반면 세릴리온이 채택한 제로카피 공유 메모리(Zero-copy Shared Memory, 데이터를 물리적으로 복사하지 않고 여러 프로그램이 메모리 공간을 그대로 공유하여 속도를 극대화하는 기술)는 사무실 한가운데에 거대한 공용 화이트보드를 두는 것과 같습니다 [Source 2]. 데이터를 복사해서 전달할 필요 없이, 누구나 그 자리에 적힌 최신 정보를 즉시 읽고 쓸 수 있기 때문에 통신 지연이 단 4.98마이크로초(µs, 1초의 100만분의 1) 수준으로 뚝 떨어집니다 [Source 2].

2. 한 치의 오차도 없는 비행기 블랙박스 (결정론적 리플레이)

로봇이 주행 중 벽에 부딪히는 사고가 났다고 가정해 봅시다. 기존에는 사고 순간의 상황을 정확히 재구성하기 어려워 감으로 코드를 수정해야 했습니다 [Source 1].

세릴리온은 로봇이 달리는 동안 입력된 모든 센서 데이터와 내부 스케줄러의 작동 순서를 표준 MCAP(ROS 2 등에서 로봇 센서 데이터와 로그를 기록하기 위해 사용하는 표준 파일 포맷) 파일에 꼼꼼히 기록합니다 [Source 1, Source 8]. 나중에 사무실 컴퓨터에서 코드를 수정하고 결정론적 리플레이(Deterministic Replay, 과거 로봇이 실행되었던 정확한 입력과 순서를 컴퓨터 안에서 한 치의 오차도 없이 똑같이 다시 재현하는 기술)를 실행하면, 사고가 났던 그 순간의 상황을 완벽하게 재현할 수 있습니다 [Source 1, Source 10]. 코드가 정상적으로 작동하는지, 어디서 어긋났는지를 바이트 단위로 정확히 비교 검증할 수 있으므로 ‘귀신 잡는 디버깅’이 가능해집니다 [Source 1, Source 10].

현재 상황: 러스트로 무장한 실전형 미들웨어

세릴리온은 탁상공론식 연구실 프로젝트가 아닙니다. MIT에서 오프로드 자율주행 연구를 직접 수행했던 락셰이(Lakshay)와 라빈(Raveen) 두 공동 창업자가 현장에서 겪은 뼈아픈 경험을 바탕으로 바닥부터 직접 설계했습니다 [Source 1, Source 4].

이들은 메모리 안전성과 극한의 성능을 동시에 제공하는 프로그래밍 언어인 러스트(Rust, 시스템 프로그래밍에 특화되어 메모리 오류를 원천 차단하면서도 C++ 급의 속도를 내는 언어)를 선택해 런타임을 구축했습니다 [Source 1].

특히 현장 엔지니어들을 배려한 점이 돋보입니다. 기존에 이미 널리 쓰이고 있는 ROS 2 생태계의 노드(Node, 로봇 안에서 독립적으로 작동하는 프로그램 단위)나 런치 파일(Launch file, 여러 프로그램을 한 번에 실행시키는 설정 파일)을 전면 수정할 필요 없이 그대로 세릴리온 환경과 함께 실행할 수 있습니다 [Source 1]. 여기에 네이티브 러스트 및 파이썬(Python) 코드를 자유롭게 섞어서 쓸 수 있어 기존 시스템과의 호환성 장벽을 낮췄습니다 [Source 1]. 리눅스 환경에서 ROS 2 재즈(Jazzy) 버전 노드들과 손쉽게 연동되며, 상세한 명령어와 퀵스타트 가이드는 공식 문서와 깃허브 저장소를 통해 제공되고 있습니다 [Source 5, Source 8].

앞으로 어떻게 될까?

피지컬 AI와 자율주행 로봇 시장은 이제 장난감이나 시제품 단계를 넘어 실제 산업 현장과 도심 속으로 파고들고 있습니다. 하지만 하드웨어 비용이 비싸고 소프트웨어 디버깅이 까다롭다는 점은 여전히 대중화의 큰 걸림돌입니다 [Source 4].

세릴리온처럼 통신 지연을 극단적으로 줄이고, 과거의 오류를 완벽하게 재현하여 코드 품질을 빠르게 끌어올릴 수 있는 툴링(Tooling, 개발을 보조하는 도구 모음)은 앞으로 로보틱스 업계의 표준 인프라로 자리 잡을 가능성이 높습니다 [Source 1, Source 4, Source 11]. 기존 ROS 2 개발자들이 큰 전환 비용 없이 곧바로 도입할 수 있다는 실용성 덕분에, 앞으로 더 많은 물류 로봇, 드론, 휴머노이드 로봇 개발팀이 세릴리온 기반의 고속 멀티 프로세스 아키텍처를 채택할 것으로 전망됩니다 [Source 1].