서로 다른 회사의 로봇을 함께 쓰려면 모든 기계를 하나의 중앙 AI가 직접 조종하게 만들 필요가 없다. 상위 시스템은 임무·경로·문·엘리베이터·충전기 같은 공유 자원을 조정하고, 각 제조사의 제어기는 주행과 충돌 방지, 비상정지를 맡는 구조가 현실적이다. 공통 API만 연결해서는 부족하며 좌표·상태·오류의 뜻, 최소 권한 보안, 데이터 사용 규칙과 장애 격리까지 맞아야 한다.
한 화면에 보인다고 통합된 플릿은 아니다
관제 화면에 A사 AMR과 B사 서비스 로봇의 아이콘이 함께 떠도 임무를 서로 넘기거나 같은 엘리베이터를 안전하게 예약하지 못하면 모니터링 통합에 가깝다. 멀티벤더 운영은 로봇이 어떤 일을 할 수 있는지 설명하고, 상위 조정자가 임무를 배정하며, 실행 상태와 실패를 같은 의미로 돌려받는 단계까지 이어져야 한다.
Open-RMF 공식 홈페이지는 Open Robotics Middleware Framework를 여러 로봇 플릿과 문·엘리베이터·빌딩 관리 시스템의 공유·상호운용을 돕는 무료 오픈소스 모듈형 시스템으로 설명한다. 병원용으로 시작했지만 사무실, 공항, 항만, 쇼핑몰, 공장, 물류센터에도 적용할 수 있다고 안내한다. 프레임워크가 연결 지점을 제공한다는 사실과 특정 현장의 플러그앤플레이 호환을 보장한다는 것은 다르다.
| 계층 | 공통으로 맞출 것 | 제조사·현장에 남길 것 |
|---|---|---|
| 업무 | 임무 유형, 우선순위, 완료·취소 의미 | 로봇별 수행 가능 작업과 제한 |
| 이동·자원 | 지도 기준, 경로 충돌, 문·엘리베이터·충전 예약 | 로컬 장애물 회피와 실시간 안전 제어 |
| 상태·오류 | 대기·실행·중단·복구 상태와 오류 등급 | 제조사 고유 진단·정비 절차 |
| 통제 | 인증, 권한, 감사, 데이터 정책 | 장비 키, 안전 인증, 현장 비상정지 |
상위 임무와 실시간 안전 제어를 분리한다
중앙 조정자는 “3층 약품 보관소에서 검사실로 운반” 같은 임무를 적합한 플릿에 배정하고, 이동 경로와 공유 자원 사용 순서를 정한다. 반면 바퀴가 몇 rpm으로 돌아야 하는지, 사람을 발견했을 때 몇 ms 안에 멈출지는 로봇 내부 제어기와 독립 안전장치가 맡는다.
이 경계를 지키면 네트워크가 잠시 끊겨도 로봇이 사람을 피하고 안전하게 정지할 수 있다. 반대로 중앙 서버가 관절이나 바퀴를 실시간으로 직접 제어하면 지연과 서버 장애가 현장 위험으로 곧바로 번진다. 제조사별 안전 기능을 상위 소프트웨어가 우회하지 못하도록 권한을 제한해야 한다.
상위 명령에도 유효시간이 필요하다. 10초 전에 받은 “통로 진입” 명령을 통신 복구 후 그대로 실행하면 이미 다른 장비가 들어온 통로에서 충돌할 수 있다. 로봇은 상태를 다시 보고하고 새 승인을 받은 뒤 움직여야 한다.
좌표·상태·오류의 뜻을 어댑터에서 맞춘다
두 로봇이 같은 지도를 쓴다고 해도 원점과 층 높이, 문 통과 가능 폭이 다를 수 있다. A사는 ‘도착’을 목표점 반경 20cm로, B사는 1m로 판단할 수도 있다. 좌표 변환과 허용 오차, 로봇 외곽선, 속도 제한을 공통 스키마로 정하지 않으면 화면에서는 도착했지만 작업대에 손이 닿지 않는 일이 생긴다.
상태 이름도 번역이 필요하다. ‘paused’가 안전정지인지 운영자 대기인지, ‘failed’가 자동 재시도 가능한 오류인지 현장 회수가 필요한 고장인지 제조사마다 다르다. 플릿 어댑터는 메시지 형식만 바꾸지 말고 상태 전이와 복구 가능성을 공통 의미로 매핑해야 한다. 알 수 없는 새 오류 코드는 ‘정상’으로 처리하지 않고 격리 상태로 보낸다.
버전 관리는 어댑터의 일부다. 로봇 펌웨어나 API가 바뀌면 이전 상태 코드와 경로 응답이 달라질 수 있다. 지원 버전, 호환성 시험, 롤백 가능한 어댑터 패키지를 로봇별로 보관해야 야간 업데이트 뒤 플릿 전체가 멈추는 상황을 막을 수 있다.
임무를 보내기 전에는 기능 협상도 필요하다. 같은 ‘운반’ 로봇이라도 최대 적재, 통과 폭, 사용 가능한 층, 도킹 장치와 냉장함 지원이 다르다. 상위 시스템은 고정된 모델명보다 현재 로봇이 보고한 기능과 상태를 보고 배정하고, 정보가 오래됐거나 필수 기능이 빠졌으면 임무를 보내지 않는다. 기능 설명이 바뀌었을 때 어댑터와 배차 규칙을 함께 시험해야 한다.
문·엘리베이터·충전기의 교착을 풀어야 한다
멀티벤더 현장에서 가장 어려운 것은 로봇끼리의 대화보다 한 대뿐인 설비를 나누는 일이다. 두 플릿이 서로 다른 층에서 같은 엘리베이터를 예약하거나, 배터리가 낮은 로봇 여러 대가 충전기로 몰리면 자원 교착과 긴 대기가 생긴다. 통로·문·리프트·작업대를 예약 가능한 자원으로 모델링해야 한다.
예약에는 시작·만료 시간과 소유자, 실패 시 해제 규칙을 둔다. 로봇이 엘리베이터 안에서 통신을 잃었는데 예약이 영구히 남으면 다른 플릿도 멈춘다. 반대로 만료가 너무 짧으면 이동 중 권한을 잃을 수 있다. 실제 이동시간의 분포와 최악 조건을 기준으로 설계한다.
우선순위 정책도 현장 업무와 맞춰야 한다. 병원에서 긴급 검체 운송과 폐기물 운반이 같은 순서로 대기해서는 안 된다. 다만 높은 우선순위가 계속 들어와 일반 작업이 영원히 밀리지 않도록 최대 대기시간과 수동 조정 절차를 둔다.
교착 시험은 두 로봇이 좁은 통로 양쪽에서 서로의 양보를 기다리는 장면부터 시작한다. 누가 후퇴할지 결정할 수 없으면 중앙 조정자가 안전한 대기 지점과 재경로를 지정해야 한다. 엘리베이터 예약과 충전 예약을 동시에 가진 로봇처럼 여러 자원을 묶는 경우에는 취득 순서를 고정하거나 일부 예약을 풀어 주는 규칙이 필요하다. 처리량이 낮아지는 것보다 현장 전체가 멈추지 않는 것이 먼저다.
개방형 API에는 최소 권한과 서명이 필요하다
개방형은 누구나 아무 명령이나 보낼 수 있다는 뜻이 아니다. 주문 시스템은 임무 생성 권한만, 빌딩 시스템은 문·엘리베이터 상태 권한만, 정비 계정은 특정 로봇의 진단 권한만 가져야 한다. 운전 명령과 비상정지 해제는 더 강한 인증과 승인 절차를 요구한다.
장비와 서비스마다 고유 신원을 발급하고 상호 인증된 통신을 사용한다. 명령에는 발신자, 대상, 시각, 만료, 서명을 붙여 재전송이나 변조를 식별한다. 키가 유출되거나 공급사 계정이 침해됐을 때 해당 플릿만 차단하고 다른 로봇은 계속 운영할 수 있어야 한다.
어댑터와 플러그인 자체도 공급망 공격 경로가 될 수 있다. 배포 패키지의 출처와 서명을 검증하고, 필요한 네트워크·파일 권한을 목록으로 관리하며, 새 버전은 격리된 시험 플릿에서 먼저 실행한다. 취약점이 발견됐을 때 어느 로봇과 서버에 해당 버전이 설치됐는지 즉시 찾을 수 있도록 소프트웨어 자산과 배포 계보를 유지한다.
Fujitsu 일본 Physical AI 협력 공식 발표는 2026년 7월 16일 FANUC·Yaskawa Electric·Kawasaki Heavy Industries와 NVIDIA 기술을 통합하는 협력 제어 플랫폼의 사업 기회를 검토하기 시작했다고 밝혔다. 발표는 적용 범위 확대와 함께 사이버공격, 시스템 전체 중단·오작동, 기밀정보 유출 위험이 커진다고 명시한다. 이는 개발·표준화 방향을 밝힌 단계이며 완성된 범용 플랫폼의 상용 성능 발표는 아니다.
소버린 데이터는 서버 위치만의 문제가 아니다
소버린 데이터는 데이터를 어느 나라에 저장하는지만 정하는 개념보다 넓다. 누가 센서 원본을 볼 수 있는지, 공급사가 장애 분석이나 모델 학습에 쓸 수 있는지, 파생 특징과 모델을 국외로 보낼 수 있는지, 계약 종료 후 어떻게 삭제하는지까지 통제하는 능력이다.
Fujitsu는 디지털과 물리 세계를 연결하면서 주권을 보장하는 협력 제어 기반을 개방형 플랫폼으로 발전시키겠다고 밝혔다. 제조·물류·의료에는 각각 공정 비밀, 판매·재고, 환자 이동 같은 민감정보가 들어간다. 로봇 좌표만 공유해도 생산량과 시설 구조를 추정할 수 있으므로 영상 파일만 보호해서는 충분하지 않다.
| 데이터 항목 | 계약·기술 통제에서 정할 내용 | 확인할 증거 |
|---|---|---|
| 실시간 위치·상태 | 접근자, 보존 기간, 외부 전송 범위 | 권한표와 접속 감사 로그 |
| 영상·센서 원본 | 최소 수집, 마스킹, 학습 사용 동의 | 데이터 계보와 삭제 시험 |
| 오류·정비 로그 | 공급사별 조회 범위와 사고 공유 | 사건별 열람·반출 기록 |
| 파생 데이터·모델 | 소유권, 재사용, 국외 이전, 계약 종료 | 버전별 출처와 폐기 확인서 |
SEER Robotics WRC 2026 전략 발표도 로봇 모델과 제어·플릿 계층, 데이터 네트워크를 연결하는 방향을 제시한다. 공급사의 통합 비전은 참고할 수 있지만 데이터 권리와 내보내기 가능성은 고객 계약과 실제 API에서 별도로 확인해야 한다.
한 대의 장애가 다른 플릿으로 번지지 않게 한다
통합의 실패는 모든 로봇이 동시에 멈추는 형태로 나타날 수 있다. 중앙 스케줄러가 죽었을 때 진행 중 임무를 안전하게 끝낼지 정지할지, 문 서버 장애 시 어느 구역을 닫을지, 특정 공급사 API가 느려졌을 때 전체 큐를 막지 않을지 사전에 정한다.
회로 차단과 타임아웃을 플릿별로 둔다. 응답이 없는 로봇은 격리하되 다른 플릿의 작업은 계속 배정한다. 중앙 시스템이 복구되면 로봇의 실제 위치와 임무 상태를 다시 조회하고, 서버에 남은 오래된 상태를 덮어쓰지 않는다. 마지막 정상 데이터보다 현장 관측을 우선한다.
오프라인 운용 범위도 제한한다. 통신 없이 로컬로 피할 수 있는 장애물과, 상위 예약 없이는 들어가면 안 되는 엘리베이터·좁은 통로를 나눈다. 비상정지는 네트워크와 무관하게 작동하고, 해제는 현장을 확인한 사람만 수행하도록 한다.
두 대로 시작해 의미와 복구를 먼저 검증한다
첫 파일럿에는 서로 다른 제조사의 로봇 한 대씩과 공유 설비 하나만 넣는다. 동일한 픽업·드롭오프 임무를 50회 이상 반복하며 좌표 오차, 상태 전환, 자원 대기, 원격 개입을 기록한다. 성공 장면이 나온 뒤 통신 단절, 문 미응답, 배터리 부족, 알 수 없는 오류 코드를 의도적으로 넣어 격리와 복구를 확인한다.
Open-RMF 다중 로봇 연동, VDA 5050 3.0 표준 해설, VIO와 SLAM 비교를 함께 보면 설비 연동과 메시지 표준, 위치 추정 차이를 구체적으로 점검할 수 있다.
확장 전에는 신규 로봇 한 대를 연결하는 데 필요한 어댑터 개발시간, 호환성 시험, 보안 검토, 장애 복구 훈련을 비용으로 계산한다. ‘표준 지원’이라는 체크박스보다 실제 메시지 버전과 선택 기능, 제조사 오류 매핑을 본다. 여러 공급사의 가격·지원·데이터 조건이 계약서에서 서로 충돌하지 않는지도 확인한다.
확장 뒤에는 처리량과 격리 능력을 함께 본다. 플릿 전체 처리량만 높으면 특정 로봇의 장시간 대기나 우선순위 굶주림이 가려질 수 있다. 제조사별 임무 성공률과 대기시간, 어댑터 오류, 설비 예약 충돌, 수동 복구를 따로 보고 전체 지표와 나란히 둔다. 업데이트 후에는 이전 버전 대비 퇴행을 플릿별로 확인한다.
보안 지표에는 차단한 명령, 만료된 인증서, 과도한 권한, 비정상 데이터 반출을 포함한다. 소버린 데이터 정책은 문서가 아니라 삭제와 반출 차단을 실제로 실행해 확인한다. 장애 훈련에서는 중앙 서버, 한 공급사의 클라우드, 빌딩 시스템을 차례로 끊어 안전 상태와 서비스 지속 범위를 측정한다.
멀티벤더 운영의 완성도는 얼마나 많은 로고를 한 화면에 붙였는지가 아니다. 새 공급사를 추가해도 공통 의미가 유지되고, 한 곳의 실패를 격리하며, 현장 소유자가 명령과 데이터의 통제권을 계속 갖는지가 판단 기준이다.
자주 묻는 질문
같은 관제 화면에 나오면 멀티벤더 통합인가요?
모니터링 통합일 수는 있지만 충분하지 않다. 임무 배정과 상태·오류 의미, 문·엘리베이터·충전기 예약, 실패 후 복구까지 공급사 사이에서 이어져야 실제 운영 통합에 가깝다.
Open-RMF나 VDA 5050을 지원하면 바로 호환되나요?
아니다. 표준 버전과 선택 기능, 좌표계, 상태 전이, 제조사 오류 코드, 안전 책임을 실제 메시지로 시험해야 한다. 같은 표준 이름 아래에서도 구현 범위가 다를 수 있다.
개방형 API는 보안에 약한가요?
개방 여부보다 인증과 권한 설계가 좌우한다. 장비별 신원, 최소 권한, 서명·만료 명령, 감사 로그와 플릿별 차단을 적용하면 통제 가능한 연결을 만들 수 있다.
확인한 공식 자료
최종 확인: 2026년 8월 23일