제14부 시스템 설계·품질·운영

14.9 다중 로봇·플릿 운영

14.9.1 이 장에서 배우는 것 / 선수 지식

로봇 한 대가 잘 동작하는 것과 스무 대가 잘 동작하는 것은 다른 문제다. 한 대에서는 무시할 수 있던 것들이 규모에서 지배적이 된다 — 디스커버리 부하, 무선 대역, 버전 불일치, 수작업 운영, 그리고 "어느 로봇이 문제인가" 를 아는 일 자체.

동시에 새로운 문제가 생긴다. 로봇끼리 부딪히지 않게 하는 것, 작업을 나누는 것, 좁은 통로에서 순서를 정하는 것.

이 장은 그 두 축 — 기술적 아키텍처와 운영을 다룬다.

배우는 것:

• 분리 전략 — 도메인·네임스페이스·네트워크.
• 디스커버리 확장 — 규모의 병목.
• 통신 아키텍처 — 무엇을 공유하는가.
• 조율 — 충돌 회피·작업 배분.
• 플릿 관리 — 감시·배포·데이터.
• 운영 절차 — 규모에서 필요한 것.
• 점진적 확장 — 몇 대에서 무엇이 바뀌는가.
• 상호운용 표준 — VDA5050·Open-RMF가 우리 설계에 강제하는 것(14.9.6.1).

선수 지식: 3.3(디스커버리), 3.4(Discovery Server), 3.10(zenoh), 3.9(네트워크), 14.4.6(다중 로봇 launch), 14.8(배포), 11.3(기록·업로드), 14.2(오케스트레이션).

정직: 플릿 관리 제품·프레임워크는 다양하며 이 책은 특정 제품을 권장하지 않는다. 도구 세부는 확인이 필요하다(확인 필요). 다중 로봇의 안전(로봇 간 충돌·사람 안전)은 안전 요구와 전문가의 영역이며(8.7.1·14.10), 여기 서술을 근거로 삼아서는 안 된다. 이 환경에서 검증하지 않았다(목차 3).

검증 상태(추가): 이 장의 서술 가운데 1곳은 이후 회차에서 Jazzy 실물과 대조해 확인했다 — 본문의 (실행 확인) 표기가 그것이다. 표기가 없는 서술은 위 고지가 그대로 적용된다(목차 3의 검증 범위 표).

14.9.2 분리 전략

로봇들을 하나의 ROS 그래프에 둘 것인가.

견해: 실무 플릿은 대부분 ②(도메인 분리)가 맞다. 로봇들이 서로의 모든 토픽을 볼 필요가 없고, 무선에서 전체 그래프를 공유하는 것은 대역·안정성 모두에서 불리하다(3.9.3). "로봇은 독립 시스템, 필요한 것만 공유" 가 확장 가능한 구조다.

견해: ①(단일 그래프)은 시뮬레이션과 소규모 연구에 적합하다. 한 컴퓨터에서 여러 로봇을 실행하는 시뮬(14.4.6)에서는 자연스럽고, 서로의 상태를 직접 구독하는 실험도 쉽다. 실기 플릿으로 그대로 옮기지 않는 것이 중요하다.

함정: ①에서 시작해 규모가 커지면 이행이 어렵다. 코드가 다른 로봇의 토픽을 직접 구독하고 있으면, 분리할 때 전부 고쳐야 한다. 처음부터 "로봇 간 통신은 명시적 인터페이스로" 를 규율로 두면 이행이 쉽다.

14.9.3 디스커버리 확장

규모에서 가장 먼저 부딪히는 한계다.

견해: 디스커버리 부하는 예고 없이 벽에 부딪힌다. 다섯 대까지 잘 되다가 열 대에서 갑자기 불안정해지는 식이다. 규모 계획이 있다면 처음부터 분리 전략을 세우는 것이 나중에 급히 고치는 것보다 비용이 낮다.

견해: 무선 환경에서는 특히 심각하다(3.9.3). 유선에서는 여유가 있어도 무선에서는 디스커버리 트래픽만으로 대역이 잠식된다. 로봇이 무선으로 연결되는 순간 분리가 사실상 필수가 된다.

정직: Discovery Server와 대체 미들웨어의 Jazzy 지원 상태·성숙도는 확인이 필요하다(확인 필요). 3.10에서 다뤘듯 이 영역은 변화가 빠르므로, 현재 문서와 자신의 환경에서의 측정이 판단 근거여야 한다.

14.9.4 통신 아키텍처

무엇을 로봇 간·중앙과 공유할 것인가.

견해: "센서 원본을 중앙으로 보내지 말라"가 첫 규칙이다(7.8·11.3.2). 이미지·포인트클라우드를 여러 로봇이 동시에 전송하면 무선이 즉시 포화된다. 로봇에서 처리하고 결과만 보내는 것이 확장 가능한 구조다.

견해: 로봇은 서버 없이도 안전하게 동작해야 한다(3.9.3·13.1.7). 통신이 끊겼을 때 정지하거나 안전하게 복귀할 수 있어야 하며, 서버가 필수인 설계는 통신 장애가 곧 전체 정지를 뜻한다.

견해: 로봇 간 직접 통신은 필요할 때만. 근접 회피처럼 지연이 중요한 경우에만 직접 통신을 두고, 나머지는 서버 경유가 관리하기 쉽다. 직접 통신이 늘면 ②(도메인 분리)의 이점이 줄어든다.

프로토콜 선택:

견해: 로봇-서버 경계에서 ROS를 고집할 필요는 없다. 그 경계는 저빈도·이벤트성 통신이므로, 일반적인 IT 프로토콜이 운영·보안·인프라 면에서 유리한 경우가 많다. ROS 브리지를 쓸지는 팀 역량과 기존 인프라에 달렸다.

14.9.5 조율

로봇들이 서로 방해하지 않게 한다.

견해: ③(규칙 기반)이 실무에서 과소평가된다. "일방통행 경로", "우측 우선", "구역별 한 대만" 같은 단순 규칙이 복잡한 협상 알고리즘보다 예측 가능하고 디버깅이 쉽다. 환경을 설계할 수 있다면(창고·공장) 특히 효과적이다.

견해: 어떤 조율 방식이든 "로봇 자체의 회피"가 최종 보루여야 한다(8.7). 조율이 실패하거나 통신이 끊겨도 로봇은 자기 센서로 장애물(다른 로봇 포함)을 보고 멈춰야 한다. 조율은 효율을 위한 것이지 안전의 근거가 아니다.

정직: 다중 로봇 환경의 안전 설계는 이 책의 범위를 넘는다. 로봇 간 충돌, 사람과 여러 로봇이 공존하는 공간의 위험 평가는 안전 표준과 전문가의 영역이다(14.10).

함정: 교착(deadlock)이 다중 로봇의 고유 문제다. 두 로봇이 좁은 통로에서 서로를 기다리면 영원히 멈춘다. 탐지(진행 없음이 지속)와 해소(후진·우선순위)를 설계해야 하며, 없으면 사람이 매번 개입한다.

14.9.6 플릿 관리

여러 대를 운영하는 데 필요한 것들.

견해: "로봇별 진단을 플릿 수준으로 집계"하는 것이 관리의 핵심이다(6.9.8). 각 로봇이 이미 /diagnostics를 발행하고 있다면, 그것을 모아 대시보드로 만드는 것은 비교적 쉽다. 로봇 측 진단이 잘 되어 있으면 플릿 관리가 쉬워진다 — 투자 순서가 그렇다.

견해: "이 로봇만 이상하다"를 판정할 수 있어야 한다. 같은 지표를 로봇 간 비교하면 개별 하드웨어 문제(센서 열화·기계 마모)를 조기에 발견할 수 있다. 플릿의 이점 중 하나가 이 비교 가능성이다.

견해: 유지보수 이력을 소프트웨어와 함께 관리하라. "이 로봇은 지난주에 라이다를 교체했다"는 정보가 없으면, 그 이후의 이상 동작을 소프트웨어 문제로 오진한다. 하드웨어 이력이 진단의 맥락이다.

14.9.6.1 남의 시스템과 연동돼야 할 때 — 상호운용 표준

여기까지는 우리 로봇들끼리의 이야기였다. 현장에서는 다른 조건이 자주 붙는다 — 창고에 이미 다른 회사의 AMR이 운용되고 있고, 고객사에 이미 관제 시스템(WMS·MES)이 있으며, 우리 로봇이 그 안으로 들어가야 한다.

이때 "우리 관제 서버를 쓰세요"는 답이 아니다. 이 영역에는 공개된 상호운용 규약이 있다.

실행 확인(2026-08-16): Jazzy apt 인덱스에 ros-jazzy-rmf-fleet-msgs(3.3.1)·ros-jazzy-rmf-traffic-editor(1.9.2) 등 RMF 패키지가 실재한다. 확인한 것은 패키지 존재까지이며, 기능·성숙도·VDA5050 구현체의 상태는 실행해 보지 않았다(확인 필요).

이것이 설계에 주는 실제 제약은 통신 규약 자체보다 그 앞 단계에 있다.

견해: 상호운용을 나중에 추가하려 하면 비용이 크다. 로봇의 상태·작업 모델이 우리 내부 개념으로만 짜여 있으면, 표준 스키마로 옮길 때 의미가 어긋나는 곳이 많이 나온다("우리의 '대기'는 저쪽의 무엇인가"). 고객사 통합 가능성이 있다면 작업·상태 모델을 설계할 때 한 번 대조해 보는 것만으로도 나중 비용이 크게 준다. 반대로 단일 벤더·단일 현장이 확실하다면 표준 도입은 순수한 부담이다 — 판단은 사업 맥락에서 나온다.

정직: 이 책은 VDA5050의 메시지 필드나 Open-RMF의 API를 다루지 않는다. 버전 의존이 크고 이 환경에서 검증할 수 없기 때문이다(확인 필요). 여기서 다루는 것은 그런 요구가 시스템 설계에 무엇을 강제하는가까지이며, 세부는 각 프로젝트 문서가 정본이다.

14.9.7 운영 절차

규모에서 필요해지는 것들.

견해: "한 대일 때 사람이 하던 일"이 규모에서 병목이 된다. 로봇 한 대의 캘리브레이션을 수동으로 하는 것은 되지만 스무 대는 안 된다. 자동화 우선순위는 "로봇 수에 비례해 늘어나는 작업" 에 두어야 한다.

견해: 로봇별 차이를 최소화하라. 하드웨어 구성·소프트웨어 버전·설정이 로봇마다 다르면 조합이 기하급수적으로 늘고 진단이 불가능해진다. "모든 로봇이 같다"에 가까울수록 운영이 쉽다 — 다만 하드웨어 세대 차이는 불가피하므로, 세대를 명시적으로 관리한다(14.4.5의 변형).

함정: 한 대에서 검증한 것이 플릿에서 다르게 동작할 수 있다. 무선 대역·서버 부하·상호 간섭은 대수에 따라 달라진다. 단계적 확대(카나리 → 소수 → 전체) 가 이 위험의 대비다.

14.9.8 점진적 확장

규모마다 무엇이 문제가 되는가.

견해: "다음 단계를 미리 준비하되 그 다음까지는 하지 말라"가 실용적이다. 3대를 운영하면서 100대용 인프라를 만드는 것은 낭비이고, 아무 준비 없이 20대로 가는 것은 위기다. 한 단계 앞을 보는 것이 적절하다.

견해: 가장 중요한 준비는 "자동화 가능한 구조"다. 배포·점검·데이터 수집이 스크립트로 가능한 형태면 규모가 커져도 확장된다. 사람의 손이 필수인 절차가 병목이 되므로, 그것을 먼저 없앤다.

견해: 초기부터 지켜야 할 규율 셋 — ① 로봇 간 통신은 명시적 인터페이스로(14.9.2), ② 로봇은 서버 없이 안전하게 동작(14.9.4), ③ 버전·설정을 코드로 관리(14.8). 이 셋은 나중에 도입하기 어렵고, 초기 비용은 작다.

14.9.9 함정 카탈로그

14.9.10 체크포인트

• 다중 로봇 아키텍처 세 전략과 각각의 적합 상황은?
• 단일 그래프와 도메인 분리의 여섯 축 비교를 말할 수 있는가.
• 실무 플릿에 도메인 분리를 권하는 근거는?
• 단일 그래프에서 시작할 때 지켜야 할 규율은?
• 디스커버리 확장 수단 다섯 가지와, 무선에서 특히 심각한 이유는?
• 공유 대상 일곱 가지와 "센서 원본을 보내지 말라"의 근거는?
• 로봇이 서버 없이 동작해야 하는 이유는?
• 로봇-서버 경계에서 ROS를 고집하지 않아도 되는 이유는?
• 조율 방식 세 가지와 각각의 장단점은?
• 규칙 기반 조율이 과소평가되는 이유와 그 강점은?
• "조율은 안전의 근거가 아니다"의 의미는?
• 교착이 다중 로봇의 고유 문제인 이유와 대처는?
• 플릿 관리의 일곱 기능과, 로봇 측 진단 투자가 왜 선행되어야 하는가.
• "이 로봇만 이상하다"를 판정할 수 있는 것의 가치는?
• 유지보수 이력을 함께 관리해야 하는 이유는?
• 자동화 우선순위를 어디에 두어야 하는가.
• 규모별로 새로 생기는 문제를 말할 수 있는가.
• 초기부터 지켜야 할 규율 셋은?
• 고객사의 기존 관제와 연동돼야 할 때, 통신 규약보다 먼저 다시 그어야 하는 것은 무엇인가.
• 상호운용 표준을 나중에 추가하는 것이 비용이 큰 이유를 작업·상태 모델 관점에서 설명할 수 있는가.

다음 장 14.10는 제14부의 마지막이자 이 책이 여러 번 미뤄 온 주제 — 안전 표준과 ROS 2의 위치를 정면으로 다룬다.