세상에 없던 아이디어는 아니었다 — 나는 이미 너무 늦은 걸까?
내 기발한 아이디어가, 알고 보니 로보틱스 세계 절반쯤에서는 이미 이야기되고 있었다.
작은 개발용 로봇 M3 Pro가 기대와 다르게 움직일 때면 소프트웨어 시스템을 만들던 시절의 본능이 고개를 든다. 센서 데이터가 끊겼다면 센서 자체가 멈춘 걸까? ROS가 메시지를 전달하지 못한 걸까? 필요한 transform이 사라졌을까? 아니면 애플리케이션이 더 이상 데이터를 읽지 않을까?
누군가 재부팅하기 전에 로봇이 증거를 남겨 주면 좋겠다. 같은 입력을 워크스테이션에서 다시 재생하고, 소프트웨어를 수정한 뒤, 실패가 재발하는지 확인할 수 있을 테니까.
그러다 생각이 진단에서 observability, 자동 테스트, 원격 배포를 거쳐 RobotOps 플랫폼까지 뛰어갔다. 멋진 아키텍처 그림도 곧 그릴 기세였다.
그때 ROSCon 영상을 보기 시작했다.
아, 다들 이미 와 있었다
replay testing, 로봇 진단, observability, fleet 도구, 산업용 ROS 통합까지 다른 사람들은 이미 하고 있었다. 어떤 사람들은 운영 환경에서 수년을 일했고, 나보다 훨씬 많은 로봇을 다루고 있었다.
나는 20년 넘게 소프트웨어 시스템을 만들었지만 로보틱스에서는 여전히 새롭다. 잠깐은 예상 가능한 질문이 떠올랐다. 이미 너무 늦은 걸까?
조금 더 생각하니 오히려 쓸모 있는 신호로 보였다. 여러 사람이 같은 문제에 도구를 만들고 있다는 건 로봇 실패의 재현, 운영 중에 벌어진 일의 이해, 기존 인프라와 로봇 소프트웨어의 연결이 실제로 어렵다는 뜻이다.
만약 로봇 dashboard에 움직이는 날씨 위젯이 필요하다고 생각한 사람이 나뿐이었다면 독창성은 별 위안이 되지 않았을 것이다. 반면 서로 다른 팀이 replay test와 상태 진단 도구를 만드는 일은 더 강한 신호다. 물론 그것만으로 모든 실패가 해결됐다는 뜻은 아니고, 내 M3 Pro에서 무엇이 가장 아픈지도 알려 주지 않는다.
이제 질문은 이것이다. 아직 어떤 부분이 어려우며, 내가 그 문제를 해결했다는 걸 보여 줄 수 있을까?
또 플랫폼을 만들려는 본능
이 순서는 익숙하다. 반복되는 운영 문제를 찾고, 추상화하고, telemetry와 자동화를 붙인 뒤, 플랫폼에 이름을 짓는다. 유용한 본능이지만 문제 하나를 검증해 해결하기 전에 훌륭한 dashboard부터 만들 수도 있다.
M3 Pro의 CPU, camera, LiDAR, 배터리 상태를 표시할 수 있다. AI에게 화면 설계와 첫 구현을 도와달라고 할 수도 있다. 그렇다고 센서 데이터가 왜 멈췄는지, 수정 후에도 문제가 사라질지는 알 수 없다.
세상이 내게서 또 하나의 범용 로봇 dashboard를 기다리고 있을 것 같지는 않다. 기존 도구와 내 경험을 활용해 실제 실패 하나를 처음부터 끝까지 해결하는 편이 더 흥미롭다.
AI 덕분에 시연 화면이나 아키텍처를 구상하는 일도 빨라질 수 있다. 하지만 센서와 모터가 달린 기계에서, 때로는 네트워크 연결까지 불안정한 상태에서 실제로 무슨 일이 있었는지 설명하는 일은 여전히 어렵다.
하나의 실패, AI와 함께
센서 데이터가 오래된 값에 머무는데 시스템은 로봇이 정상이라고 보고하는 상황을 가정해 보자. 우선 질문할 수 있을 만큼의 증거를 남겨야 한다. 필요한 범위만 담은 ROS bag 또는 MCAP 녹화, timestamp, 관련 로그, ROS graph와 transform, 설정, 소프트웨어 버전이다. 지난 Wi-Fi 디버깅에서 재부팅 뒤 로그가 사라졌을 때 이 교훈을 배웠다.
그다음에는 내 로봇에서 아직 시험해 보지 않은 방법을 써보고 싶다. 검토하고 범위를 좁힌 자료를 AI assistant에게 보여 주고, 서로 경쟁하는 원인 가설을 요청하는 것이다. publisher가 멈췄을까? 메시지가 도착하지 않았을까? transform이 없었을까? 애플리케이션이 오래된 timestamp를 거부했을까?
처음에는 몇 시간 분량의 camera 원본을 넘기는 대신 짧은 시간 구간, 선택한 topic 통계와 그래프, 관련 로그 몇 줄만 다룰 것이다. AI가 어떤 관찰을 근거로 삼았고 무엇을 더 측정해야 하는지도 밝혀 주길 바란다. 제안한 테스트는 먼저 녹화된 데이터에서 실행한다.
도움이 되는 결과물은 작은 검증 계획이다. 어떤 관찰이 가설들을 구분하는지, 녹화의 어느 구간을 replay할지, 어떤 결과가 각 가설을 반박하는지 말이다. 언어 모델로 ROS bag을 분석하는 연구도 이런 방향을 탐색하고 있다. 그렇다고 AI가 내 M3 Pro의 문제를 제대로 진단할 것이라는 뜻은 아니다.
AI가 재현 가능한 테스트에 도달하는 시간을 줄여 줄까? 아니면 그럴듯하지만 틀린 원인으로 나를 이끌까? 어느 쪽이든 기록할 가치가 있다.
테스트는 반복 가능해야 한다. 같은 입력을 replay해 소프트웨어 실패를 재현하고, 수정한 뒤 다시 replay한다. 마지막으로 실제 로봇에서도 해당 동작을 확인한다. 녹화는 소프트웨어 환경의 일부를 재현할 수 있지만, 새로운 모터 명령에 물리 세계가 어떻게 반응할지 모두 재현하지는 못한다.
replay에서 통과했다고 끝은 아니다. 실제 로봇에서는 타이밍, 전원, 움직임, 주변 환경이 영향을 줄 수 있다. 실패가 replay에서만 사라진다면 그 차이부터 설명해야 한다.
다음 목표의 범위는 의도적으로 작다.
실제 실패 하나. 녹화 하나. AI의 도움으로 세운 가설들. 수정 전에는 실패하고 수정 후에는 통과하는 테스트 하나. 실제 로봇에서의 마지막 확인 하나.
다른 엔지니어가 내 로봇을 갖고 있지 않아도 소프트웨어 쪽 실패를 재현할 수 있다면 더 좋다. 녹화, 소프트웨어 버전, 설정, 테스트를 함께 남겨 내 결론과 AI의 제안을 같은 증거로 검토할 수 있게 하고 싶다.
내 경험이 보탤 수 있는 것
내 경력은 제어 알고리즘이나 manipulator 연구보다 분산 소프트웨어, 데이터, API, 테스트, 배포, 운영 장애에 가깝다.
그 경험은 증거를 남기고, 설정을 버전 관리하고, 장애를 재현하고, 한 번만 성공한 수정은 의심하는 습관을 줬다. 로보틱스에는 타이밍, calibration, 불완전한 센서, 불안정한 네트워크, 물리적 결과, 안전 제약이 더해진다. 익숙한 방법이 어디까지 유효하고 물리 세계에서는 무엇을 새로 배워야 하는지 알아가야 한다.
AI는 증거를 살펴보고 다음 실험을 제안하는 데 도움을 줄 수 있다. 실제로 무슨 일이 있었는지는 녹화와 반복 가능한 테스트, 그리고 로봇에서의 확인이 보여 줄 것이다.
그래서, 나는 너무 늦은 걸까?
로봇을 모니터링하자는 생각을 처음 한 사람이 되기에는? 확실히 늦었다.
구체적인 실제 실패를 찾아 신중하게 해결하기에는? 그렇게 생각하지 않는다.
이제 필요한 것은 새로운 분야의 이름보다 깊이다. 문제 하나를 관찰에서 녹화된 실패, 검증된 수정, 다른 엔지니어도 사용할 수 있는 문서까지 가져가고 싶다. AI가 그 조사에 실제로 도움이 되는지, 틀린 제안을 할 때까지 포함해 확인하고 싶다.
누군가는 분명 이것도 이미 생각했을 것이다.
괜찮다.
이제 내가 해내야 한다.