Fujitsu Kozuchi Physical OS는 로봇 한 대에 설치하는 범용 운영체제가 아니다. Fujitsu가 로봇·센서·업무 시스템·물리 공간을 묶어 여러 장비가 하나의 운영 지시 아래 협업하도록 개발 중인 피지컬 AI 플랫폼이다. 사람 시범과 과거 경험에서 작업 적응력을 얻는 ‘브레인 인텔리전스’와, 로봇이 일하는 현실 환경을 표현하는 ‘공간 인텔리전스’를 결합한다는 구상이며 2026년 8월 현재 완성 제품의 공개 배포보다 연구·협력과 단계적 통합이 진행되는 상태다.
이름은 OS지만 Windows나 ROS를 대체하는 제품은 아니다
‘Physical OS’라는 명칭은 공장 전체의 로봇과 공간 정보를 조율하는 공통 기반을 뜻한다. 모터 드라이버, 실시간 제어기, ROS 2 노드처럼 개별 로봇 안에서 관절을 움직이는 소프트웨어와 역할이 다르다. Fujitsu는 클라우드부터 엣지까지 하나의 인프라로 연결해 실시간성·신뢰성·안전, 데이터 주권과 거버넌스를 다루겠다고 설명한다.
따라서 Kozuchi Physical OS를 도입한다고 각 제조사의 로봇 제어기가 사라지는 것은 아니다. 현장에는 여전히 FANUC·Yaskawa·Kawasaki 같은 업체의 안전 제어와 동작 명령, PLC, 설비 인터록이 남는다. 그 위에서 업무 계획, 공간 상태, 여러 로봇의 역할 배분과 데이터 정책을 연결하는 상위 협업 계층으로 이해하는 편이 정확하다.
| 계층 | 맡는 역할 | Physical OS와의 관계 |
|---|---|---|
| 업무 시스템 | 생산계획, 재고, 병원 운송 요청, 우선순위 | 로봇이 수행할 목적과 제약을 전달 |
| Physical OS | 공간 상태, 작업 분배, 다중 로봇 협업, 거버넌스 | 서로 다른 시스템 사이의 공통 조율 계층 |
| 플릿·로봇 제어 | 경로 계획, 장비별 명령, 충돌 회피 | 상위 지시를 각 장비가 실행 가능한 명령으로 변환 |
| 안전 제어 | 비상정지, 속도·구역 제한, 설비 인터록 | AI 판단과 분리된 결정론적 보호가 필요 |
| 물리 장비 | 로봇 팔, AMR, 센서, 문·엘리베이터 | 상태를 보내고 승인된 동작을 수행 |
브레인 인텔리전스는 ‘무엇을 할지’를 작업 경험과 연결한다
Fujitsu의 Kozuchi Physical OS 공식 발표는 브레인 인텔리전스를 과거 경험과 사람의 모방을 바탕으로 로봇의 과업 적응력을 높이는 축으로 설명한다. 고정된 좌표와 순서만 실행하는 자동화에서 벗어나, 물체 위치나 공정 상태가 달라졌을 때 대안을 고르는 능력을 겨냥한다.
이 계층이 자연어 업무 지시를 받더라도, 실제 동작은 승인된 능력 목록 안에서만 실행해야 한다. ‘이 약품을 병동으로 보내라’는 지시가 들어오면 운반 가능한 로봇, 보안이 허용된 경로, 온도 조건, 인계할 사람을 확인해야 한다. 언어모델이 만든 계획을 관절 명령으로 바로 보내면 업무 규칙과 안전 제어를 건너뛸 수 있다. 계획의 출처와 승인자, 사용한 모델 버전, 예외 처리 과정을 감사 로그로 남겨야 하는 이유다.
공간 인텔리전스는 지도보다 ‘지금 무엇이 가능한가’를 표현한다
공간 정보는 벽과 통로의 고정 지도만으로 충분하지 않다. 사람이 서 있는 위치, 이동 중인 카트, 열린 문, 엘리베이터 상태, 작업대 점유, 위험 구역과 로봇이 들고 있는 물체가 시간에 따라 바뀐다. 공간 인텔리전스는 이런 현실 상태를 공유해 서로 다른 로봇과 AI 에이전트가 같은 장면을 해석하도록 만드는 축이다.
정적인 디지털 트윈과도 차이가 있다. 설비의 3D 모델이 정교해도 센서 업데이트가 늦으면 로봇은 이미 막힌 통로를 계획에 사용할 수 있다. 객체의 좌표뿐 아니라 관측 시각, 신뢰도, 소유자, 만료시간을 함께 가져야 한다. 카메라와 라이다 위치 추정이 어긋나는 문제는 VIO와 SLAM의 차이처럼 로컬 인지 단계에서 시작하지만, Physical OS에서는 그 오차가 여러 로봇의 공유 판단으로 번질 수 있다.
다중 로봇 협업은 공통 지도보다 권한과 책임이 어렵다
서로 다른 회사의 AMR, 로봇 팔, 휴머노이드가 한 공간에서 움직이면 메시지 형식만 맞춘다고 협업이 끝나지 않는다. 누가 우선권을 갖는지, 문과 엘리베이터를 누가 예약하는지, 하나가 멈췄을 때 어느 작업을 다른 장비로 넘기는지 정해야 한다. Fujitsu는 2026년 7월 FANUC·Yaskawa Electric·Kawasaki Heavy Industries와 사업 기회를 검토하면서 표준화·개방형 협업 제어 기반을 추진하겠다고 발표했다.
Fujitsu의 2026년 7월 공식 발표는 제조, 물류·소매, 의료를 첫 적용 분야로 제시한다. 생산 변동과 현장 상태를 반영한 공장 계획, 판매·재고에 맞춘 물류, 병원 시스템 지시에 따른 약품·검체 운송과 안내가 예시다. 이는 공동 검토가 시작됐다는 발표이며, 모든 참여사 로봇이 이미 하나의 상용 Physical OS에서 연동된다는 완료 보고는 아니다.
시설 자원 연동의 실무 기준은 Open-RMF로 문·엘리베이터·플릿을 연결하는 방법, AMR 메시지 표준의 범위는 VDA 5050 버전 3 가이드에서 더 구체적으로 볼 수 있다. Kozuchi Physical OS는 이런 기존 인터페이스를 없애기보다 상위 업무·공간·AI 계층과 엮는 방향에 가깝다.
NVIDIA 기술은 시뮬레이션과 학습의 부품으로 들어간다
Fujitsu는 NVIDIA Cosmos를 사회·물리 시뮬레이션에 활용해 현실 사건의 이해와 예측을 강화하고, Omniverse·Isaac·Newton 물리엔진으로 Sim-to-Real과 로봇 학습·검증·최적화를 효율화하겠다고 밝혔다. NVIDIA 로보틱스 공식 플랫폼도 학습, 물리 시뮬레이션, 엣지 추론을 서로 다른 컴퓨팅 단계로 설명한다.
월드모델이 만든 미래 장면은 실제 현장의 사실 기록이 아니다. 물리엔진의 마찰, 센서 노이즈, 사람 행동 가정이 틀리면 시뮬레이션에서 안전한 계획이 현실에서 실패할 수 있다. 합성 데이터에는 생성 설정과 원천을 표시하고, 실제 로그와 분리해 평가해야 한다. 시뮬레이션 통과는 현장 안전 승인이 아니라 위험한 조건을 싸게 찾는 전 단계다.
소버린 데이터는 저장 위치만 정하는 문제가 아니다
공장 공정, 병원 동선, 재고와 작업자 행동은 기업과 기관의 민감한 운영 데이터다. 여러 회사의 로봇이 이를 공유하면 사이버공격, 전체 시스템 정지, 오작동, 기밀 유출의 영향 범위도 넓어진다. Fujitsu가 ‘소버린 협업 제어 기반’을 강조하는 배경이다.
주권 요건에는 데이터가 저장되는 국가와 클라우드뿐 아니라, 누가 원본 영상을 볼 수 있는지, 모델 학습에 재사용되는지, 파생된 공간 표현의 소유자가 누구인지가 포함된다. 한 업체의 유지보수 계정이 모든 로봇에 접근하지 않도록 권한을 나누고, 명령 승인과 모델 업데이트를 서명·감사해야 한다. 중앙 플랫폼이 끊겨도 각 로봇이 안전하게 멈추거나 제한 운용을 계속할 수 있어야 한다.
| 실패 장면 | Physical OS가 준비해야 할 대응 | 검증할 기록 |
|---|---|---|
| 공간 상태 지연 | 오래된 객체·통로 정보 만료, 보수적 재계획 | 관측 시각, 신뢰도, 폐기 사유 |
| 로봇 한 대 정지 | 작업 인계와 통로 격리, 플릿 연쇄 대기 방지 | 장애 시작·인계·복구 시간 |
| 제조사 API 변경 | 어댑터 버전 고정과 단계적 롤백 | 호환표, 테스트 결과, 배포 승인자 |
| 중앙 네트워크 단절 | 로컬 안전 상태와 제한 임무 유지 | 마지막 승인 명령, 오프라인 동작 |
| 계정 탈취 | 최소권한·명령 서명·구역별 차단 | 사용자·장비 ID, 변경 이력, 경보 |
| 월드모델 오판 | 결정론적 안전 제약으로 행동 거부 | 예측값, 실제 결과, 정책 버전 |
도입 판단은 작은 구역의 이기종 작업으로 시작한다
Physical OS를 검증하려고 공장이나 병원 전체를 한 번에 연결하면 원인을 찾기 어렵다. 로봇 두 종류, 문이나 엘리베이터 한 개, 업무 시스템 한 개가 만나는 작은 구역을 고르는 편이 낫다. 예를 들어 AMR이 약품을 운반하고, 휴머노이드가 보안문 앞에서 인계하며, 병원 시스템이 목적지를 바꾸는 시나리오다.
평가값은 단일 로봇 성공률이 아니라 업무 완료시간, 교착 횟수, 오래된 공간정보 사용률, 사람 승인 횟수, 장애 뒤 전체 복구시간이어야 한다. 플랫폼을 껐을 때도 안전이 유지되는지, 한 제조사 어댑터를 제거해도 다른 장비가 멈추지 않는지 시험한다. 공급사 종속을 피하려면 공간·작업 데이터의 내보내기 형식과 API 종료 정책도 계약에 포함해야 한다.
Fujitsu는 연구센터 기술을 2026 회계연도부터 Physical OS에 단계적으로 통합할 계획이라고 밝혔다. ‘단계적으로’라는 표현은 제품 버전, 제공 기능, 참여사, 지역과 가격이 아직 후속 발표를 필요로 한다는 뜻이다. 도입 검토자는 로드맵과 실제 제공 기능을 같은 칸에 쓰지 말고, 다운로드 가능한 소프트웨어·현장 실증·유상 배치로 증거 수준을 나눠 추적해야 한다.
개방성은 참여 회사 수보다 인터페이스의 탈출 가능성으로 검증한다
여러 대기업이 참여한다고 플랫폼이 자동으로 개방형이 되는 것은 아니다. 새 로봇을 추가할 때 공개된 어댑터 규격을 쓸 수 있는지, 공간 상태와 작업 이력을 표준 형식으로 내보낼 수 있는지, 특정 클라우드를 중단해도 로컬 운용이 가능한지를 확인해야 한다. API 문서가 있어도 인증 서버나 데이터 모델이 한 공급사에 묶여 있으면 교체 비용은 커진다.
검증 환경에서는 제조사 A의 로봇을 모의 장치로 바꾸고도 같은 작업 요청이 흐르는지 시험한다. 어댑터가 오류 값을 보낼 때 전체 계획기가 멈추지 않는지, 구버전 API를 일정 기간 병행할 수 있는지, 데이터 스키마 변경을 사전에 통지하는지도 본다. 계약서에는 내보내기 가능한 원본 범위, 종료 뒤 보존 기간, 어댑터 소스나 에스크로 제공 조건, 지원이 끝난 버전의 안전 조치를 적는다. 플랫폼의 가치는 연결 가능한 장비 수뿐 아니라 한 구성요소를 제거해도 운영 자산과 기록을 잃지 않는 데서 드러난다.
자주 묻는 질문
Kozuchi Physical OS는 ROS를 대체하나요?
공식 발표는 ROS 대체 제품으로 설명하지 않는다. 개별 로봇 제어보다 로봇·센서·업무 시스템·공간을 묶는 상위 협업 플랫폼에 가깝다.
지금 바로 다운로드해 설치할 수 있나요?
공개 자료는 개발과 단계적 통합, 기업 간 협력을 설명한다. 범용 패키지의 공개 다운로드·가격·지원 환경은 별도 제품 공지가 필요하다.
공간 월드모델이 있으면 충돌이 사라지나요?
아니다. 센서 지연과 가림, 모델 오판이 남는다. 비상정지와 속도·구역 제한 같은 결정론적 안전 제어를 AI 예측과 분리해야 한다.
확인한 공식 자료
최종 확인: 2026년 8월 23일