MCP 다음은 MHS다: AI Agent가 실제 기계를 움직이는 시대

AI Agent가 지금까지 주로 다뤄온 세계는 소프트웨어였다.

Repository
Browser
Database
Slack
GitHub
Cloud
API

Agent는 MCP나 각종 Tool API를 통해 이 소프트웨어 세계를 점점 자유롭게 움직이기 시작했다.

그런데 다음 단계는 화면 안에 있지 않다.

현미경

로봇팔

카메라

액체 처리 장비

센서

레이저

공장 장비

같은 실제 물리 장비다.

2026년 8월 27일 Anthropic은 HHMI Janelia Research Campus와 함께 개발해온 Model Hardware Standard(MHS)의 Research Preview를 공개했다.

Anthropic의 설명을 단순화하면 MHS는:

AI Agent가 서로 다른 물리 장비를 발견하고, 상태를 읽고, 조작하고, 안전 한계를 이해할 수 있도록 만드는 공통 Hardware Interface

에 가깝다.

현재는 일부 과학 연구소와 첨단 제조사에 제공되는 제한된 Research Preview이며, 안전성 평가와 운영 Best Practice를 먼저 만든 뒤 향후 Open Source할 계획이다.

흥미로운 건 이것이 단순한 “로봇용 MCP”가 아니라는 점이다.

MCP와 MHS는 서로 경쟁하는 표준이라기보다 다른 Layer에 있다.

---

1. MCP가 Software Tool을 열었다면 MHS는 Physical Tool을 연다

MCP가 등장하면서 Agent는 다양한 Software Tool을 표준화된 방식으로 사용할 수 있게 됐다.

AI Agent

   ↓ MCP

GitHub
Database
Browser
Filesystem
Slack
Cloud

Hardware에서도 비슷한 문제가 존재한다.

예를 들어 연구실에 다음 장비가 있다고 해보자.

Microscope
Liquid Handler
Robot Arm
Plate Reader
Camera
Temperature Controller

문제는 대부분 서로 다른 제조사 제품이라는 것이다.

각 장비마다:

Vendor SDK

독자 API

전용 프로그램

자체 Protocol

전용 Driver

별도 GUI

가 존재한다.

결국 연구실이나 공장에서 여러 장비를 연결하려면 이런 코드를 만들어야 했다.

Microscope ↔ Custom Integration

Robot Arm ↔ Custom Integration

Camera ↔ Custom Integration

Liquid Handler ↔ Custom Integration

장비가 하나 늘어날 때마다 또 연결해야 한다.

Anthropic은 이런 통합에 일반적으로 몇 주에서 몇 달까지 걸릴 수 있다고 설명한다. MHS의 목표는 장비 하나를 공통 Driver 형태로 한 번 정의하고 여러 Agent와 Workflow가 다시 사용할 수 있게 만드는 것이다. 초기 적용에서는 이런 통합 작업을 시간 또는 분 단위까지 단축한 사례가 소개됐다.

---

2. MHS가 해결하려는 핵심 문제는 Hardware API가 아니다

장비에 API가 있는 것만으로 Agent가 장비를 안전하게 사용할 수 있는 것은 아니다.

예를 들어 로봇팔 API가 있다고 하자.

move(x, y, z)

Agent 입장에서는 호출 방법은 알 수 있다.

하지만 중요한 정보가 빠져 있다.

이 로봇의 최대 Payload는?

Arm 자체 무게는?

현재 Gripper에 무엇이 잡혀 있나?

이 좌표에 사람이 있는가?

어디까지 움직여도 되는가?

최대 속도는?

비상 정지 상태인가?

소프트웨어에서는 호출 실패가:

Exception

정도로 끝날 수 있다.

Physical Agent에서는 잘못된 호출이:

장비 파손

샘플 손실

실험 오염

충돌

사람의 부상

으로 이어질 수 있다.

따라서 Physical AI에는 단순 API보다 훨씬 많은 Context가 필요하다.

---

3. MHS Driver는 장비를 Agent가 이해할 수 있는 형태로 바꾼다

Anthropic이 공개한 MHS 구조의 중심에는 표준 Driver가 있다.

Driver는 장비 고유의 API와 Agent 사이에 위치한다.

                AI Agent
                   │
                   ▼
               MHS Driver
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
        read     write    metadata
          │        │
          ▼        ▼
              Vendor API
                   │
                   ▼
                Hardware

기본 Primitive는 상당히 단순하다.

예를 들어:

read

는:

현재 온도 읽기
현재 위치 읽기
센서 값 읽기
카메라 상태 읽기

같은 동작이다.

write

는:

온도 설정
로봇 위치 변경
레이저 출력 변경
밸브 열기

같은 제어다.

단순한 Primitive를 두는 이유는 여러 장비를 하나의 Agent Workflow 안에서 연결하기 쉽기 때문이다.

---

4. 하지만 read/write보다 더 중요한 것이 Device Description이다

Agent에게:

set_temperature(50)

라는 Tool만 보여주는 것은 위험하다.

50이:

섭씨 50도인가?

화씨 50도인가?

이 장비가 허용하는 범위인가?

샘플이 견딜 수 있는 값인가?

알 수 없기 때문이다.

그래서 MHS Driver에는 장비의 물리적 특성을 설명하는 Tag가 들어간다.

Anthropic 설명에 따르면 사용자는 자연어로 장비 정보를 작성할 수도 있고, Agent가 사용자에게 장비에 대해 질문하면서 필요한 정보를 수집할 수도 있다.

그 결과 Reference File이 만들어진다.

여기에는 대략:

무엇을 측정할 수 있는가

무엇을 조절할 수 있는가

장비의 일반 특성

어떤 Safety Limit이 적용되는가

같은 정보가 들어간다.

개념적으로 표현하면 이런 모습이다.

device:
  type: temperature_controller

capabilities:
  read:
    - temperature

  write:
    - target_temperature

limits:
  target_temperature:
    min: 4
    max: 40

safety:
  emergency_stop: true

이건 MHS 공식 공개 Schema가 아니라 구조를 설명하기 위한 예시다. 현재 핵심 Specification은 아직 제한된 Research Preview 단계다.

---

5. Agent에게 Hardware Manual을 읽히는 것과는 다르다

그렇다면 그냥 PDF Manual을 Agent에게 읽히면 되지 않을까?

문제는 Manual이:

비정형

장비마다 다름

버전이 다름

현재 상태를 알 수 없음

이라는 것이다.

MHS가 하려는 것은 Manual을 AI에게 검색시키는 게 아니다.

장비의:

Capabilities

State

Control

Physical Properties

Safety Limits

를 Machine-readable Interface로 만드는 것이다.

즉:

Manual
→ 사람 중심 설명

에서:

MHS Driver
→ Agent가 동작할 수 있는 Hardware Contract

로 바뀐다.

---

6. MHS에서 상당히 재미있는 부분이 Shared State다

여러 장비가 같이 일하려면 Agent만 장비 상태를 알아서는 부족하다.

장비끼리 상태를 공유해야 한다.

Anthropic이 소개한 구현에서는 각 장비의:

Variables

Controls

Sensor Values

를 하나의 공유 Dictionary에 기록한다.

이 Dictionary가 Shared Memory에 존재하고 여러 프로그램이나 장비가 접근할 수 있다.

구조를 단순화하면:

Microscope ───┐
Camera ───────┤
Robot Arm ────┤
Laser ────────┼─→ Shared State
Sensor ───────┤
              │
              ▼
           AI Agent

이게 중요한 이유가 있다.

---

7. Agent가 모든 상태를 직접 Polling할 필요가 없어진다

예를 들어 Camera가 Laser 위치를 측정한다.

Camera
→ beam_x = 128
→ beam_y = 245

Mirror Controller는 이 값을 보고 거울을 움직인다.

기존에는:

Camera API
↓
Custom Adapter
↓
Controller Program
↓
Mirror API

를 별도로 만들어야 했다.

공유 상태를 이용하면:

Camera
     ↓
Shared State
     ↓
Agent / Controller
     ↓
Mirror

형태가 된다.

새 장비가 들어와도 다른 장비와 Point-to-point Integration을 계속 만들 필요가 줄어든다.

---

8. Hardware Integration 비용의 구조 자체를 바꾸려는 것이다

장비가 세 개라면 연결 수가 적다.

하지만 장비가 계속 늘어나면 문제가 커진다.

A ↔ B
A ↔ C
A ↔ D
B ↔ C
B ↔ D
C ↔ D
...

MHS의 방향은:

Device A ─┐
Device B ─┤
Device C ─┼─→ Standard Interface
Device D ─┤
Device E ─┘

다.

즉 장비 하나를 추가할 때 전체 시스템을 다시 연결하는 대신 그 장비를 한 번 MHS에 연결하는 것에 집중한다.

Anthropic이 Hardware Integration 시간이 몇 주에서 시간·분 단위로 줄 수 있다고 강조하는 이유도 이 구조 때문이다.

---

9. 그렇다면 MCP와 MHS는 정확히 어떻게 연결될까

가장 헷갈리기 쉬운 부분이다.

MCP
vs
MHS

가 아니다.

MHS가 Physical Hardware를 표준화하고,

MCP는 Agent가 그것을 사용하는 접근 방식 중 하나가 될 수 있다.

Anthropic이 현재 공개한 MHS Control Mechanism은 세 가지다.

MCP

CLI

Code Files / API

즉:

Claude / GPT / 다른 Agent
             │
             ▼
            MCP
             │
             ▼
         MHS Driver
             │
             ▼
        Physical Device

도 가능하고,

Agent
  │
  ▼
CLI
  │
  ▼
MHS Driver

도 가능하다.

---

10. 그래서 MHS는 Model-agnostic이다

이름 때문에:

Claude 전용 Hardware Protocol

처럼 느껴질 수 있지만 그렇지 않다.

Anthropic은 MHS가 model-agnostic이고 일반적인 Agent Harness가 MCP 같은 표준 Protocol을 통해 접근할 수 있다고 설명한다.

즉 구조적으로는:

Claude
GPT
Gemini
Local Model
Other Agent
       │
       ▼
     MHS
       │
       ▼
   Hardware

를 목표로 한다.

이 점에서는 MCP가 가져온 방향과 꽤 비슷하다.

---

11. 그런데 Physical Agent에서는 MCP 호출만 반복하면 느릴 수도 있다

여기서 재미있는 문제가 하나 생긴다.

예를 들어 Laser를 미세 조정해야 한다.

값 읽기
↓
생각
↓
조금 이동
↓
값 읽기
↓
생각
↓
조금 이동
↓
값 읽기

이 작업을 LLM이 매번 추론하면서 수행하면 느리다.

Hardware는 밀리초 단위의 제어가 필요할 수도 있다.

그래서 MHS에는 Code File이라는 방식이 중요해진다.

---

12. Agent는 ‘생각’을 Code로 압축할 수 있다

Anthropic이 공개한 Laser Alignment 사례가 아주 재미있다.

처음 Claude는 사람처럼 탐색했다.

Laser 조절
↓
Camera 확인
↓
Beam 위치 관찰
↓
다시 조절
↓
다시 관찰

여러 번 반복하면서 관계를 파악했다.

그런데 충분히 이해한 뒤에는 그 행동을 Deterministic Script로 만들었다.

즉:

Agent Reasoning
        ↓
패턴 학습
        ↓
Code 생성
        ↓
Deterministic Controller

로 바뀐다.

이게 상당히 중요한 패턴이다.

---

13. AI는 모든 순간 생각할 필요가 없다

예를 들어 로봇팔의 반복 작업을 생각해보자.

나쁜 구조:

LLM
↓
Move 1
↓
LLM
↓
Move 2
↓
LLM
↓
Move 3

좋은 구조는:

LLM

Goal 이해
↓
작업 계획
↓
Controller Script 생성

          ↓

Deterministic Runtime

Move
Move
Move
Sensor
Adjust

일 수 있다.

Agent는 고수준의 판단을 하고 빠르고 반복적인 Physical Control은 코드가 수행한다.

---

14. 이것은 Software Agent에서도 이미 보던 패턴이다

Coding Agent에서도 비슷하다.

처음에는 Agent가:

파일 찾기
grep
검색
Test
Log

를 하나씩 호출한다.

같은 작업이 반복되면:

Script
Skill
Tool

로 만든다.

Physical Agent에서도:

Exploration
↓
Understanding
↓
Automation

이 반복된다.

AI Agent가 새로운 Hardware를 사용하면서 자신의 Tool을 스스로 만들어내는 구조다.

---

15. QuEra 사례가 이 구조를 잘 보여준다

Anthropic이 공개한 MHS 적용 사례 중 하나가 QuEra Computing의 Quantum Computer Laser System이다.

중성 원자를 이용하는 Quantum Computer에서는 Laser Frequency를 극도로 정밀하게 유지해야 한다.

문제가 생기면 숙련된 Engineer가 여러 계측 장비를 보면서 Laser Lock을 복구해야 한다.

기존에는 사람의 복구에 약 5~10분이 걸릴 수 있었다.

QuEra는 과거에도 이 작업을 자동화하려고 했고, Laser Engineer·Software Engineer·Algorithm Specialist·Tester가 몇 달 동안 만든 Bespoke Script가 있었다.

그 Script의 성공률은 약 58퍼센트였다고 Anthropic은 설명한다.

---

16. MHS를 통해 Claude에게 같은 문제를 맡겼다

QuEra는 Agent에게:

Goal:
Laser를 다시 Lock한다.

Success:
첫 시도에 Lock하고
30초 동안 유지한다.

라는 목표를 줬다.

그리고 의도적으로:

Beam Block

Instrument Power Cut

Frequency Disturbance

같은 장애를 만들었다.

MHS가 Claude에게 장비를 읽고 조절할 수 있는 Interface를 제공했다.

Anthropic이 공개한 결과에서는 Agent가 만든 Controller가 Laser Lock을 99.3퍼센트의 경우 사람 개입 없이 복구했다.

상당히 인상적인 숫자다.

다만 이 결과는 Anthropic이 발표한 특정 QuEra 환경의 사례이지, MHS를 적용하면 어떤 Hardware에서든 99퍼센트 자동복구가 된다는 의미는 아니다.

---

17. 중요한 것은 58 → 99.3이라는 숫자보다 Recovery 방식이다

기존 Script는 Linear Workflow에 가까웠다.

Step A
↓
Step B
↓
Step C
↓
Step D

그런데 중간에 온도나 압력 같은 환경 변화가 발생하면 이전 Step이 무효가 될 수 있었다.

그러면 처음부터 다시 해야 했다.

Agent는 조금 다르게 움직일 수 있다.

현재 Sensor State 확인
↓
어디가 틀어졌는지 판단
↓
필요한 Step만 다시 실행
↓
결과 관찰
↓
다시 조정

즉 State-aware Recovery다.

Software Agent에서 최근 중요해지고 있는:

실패
→ 동일 Retry

가 아니라:

실패
→ Re-observe
→ Re-plan
→ Recovery

구조가 Physical World에서도 똑같이 등장한다.

---

18. MHS가 진짜 흥미로운 이유는 ‘Hardware Agentic Loop’ 때문이다

소프트웨어 Agent Loop:

Observe

↓

Reason

↓

Act

↓

Observe

↓

Recover

Hardware에서도 그대로 적용된다.

Sensor

↓

AI

↓

Actuator

↓

Physical World 변화

↓

Sensor

↓

AI

이제 Agent가 다루는 State가 파일이나 Browser DOM이 아니라 현실 세계의 상태다.

이 차이는 엄청나게 크다.

---

19. Software에서는 Retry 비용이 비교적 낮다

예:

Build 실패

↓

다시 Build

큰 문제가 아닐 수 있다.

Hardware에서는:

액체 50ml 투입

↓

잘못됨

↓

다시 해볼게

가 불가능할 수도 있다.

샘플은 이미 오염됐다.

또:

Robot Arm 이동

↓

충돌

↓

Retry

도 말이 안 된다.

따라서 Physical Agent에서는 Irreversible Action이라는 개념이 훨씬 중요하다.

---

20. 그래서 Physical Agent의 권한은 단계적으로 나누는 게 좋다

개발환경에서 Agent Permission을:

AUTO
CONFIRM
DENY

로 나누듯 Hardware도 비슷하게 설계할 수 있다.

예를 들어:

AUTO

Sensor 읽기

Camera 촬영

장비 상태 확인

낮은 위험도의 미세 조정

CONFIRM

Sample 이동

고출력 Laser 변경

Robot Arm 큰 이동

실험 조건 변경

DENY

Safety Limit 해제

Emergency Stop 비활성화

위험 구역 진입

허가되지 않은 장비 제어

이다.

이것은 MHS 공식 권한 Schema를 의미하는 것이 아니라, Physical Agent 시스템을 설계할 때 필요한 현실적인 Control Layer의 예다.

---

21. Safety Limit은 Prompt에만 넣으면 안 된다

가장 위험한 구조:

System Prompt:

"로봇팔을 너무 빠르게 움직이지 마."

이다.

Agent가 잘못 판단하면 끝이다.

더 좋은 구조:

Agent

↓

move(speed = 200)

↓

Hardware Safety Layer

max_speed = 80

↓

DENY

즉 안전 규칙은 Agent 바깥에서 강제되어야 한다.

Anthropic도 MHS Reference 정보에 장비의 Safety Limit이 포함되고 Driver가 Agent가 장비를 안전하게 사용할 수 있도록 물리적 Context를 제공하는 구조를 설명한다.

---

22. Physical AI에서는 Defense in Depth가 더 중요하다

추천 구조:

                    AI Agent
                       │
                       ▼
                   MHS Layer
                       │
                       ▼
                  Policy Layer
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
          Limits   Permissions  Interlock
             │         │         │
             └─────────┼─────────┘
                       ▼
                  Device Driver
                       │
                       ▼
                  Safety PLC
                       │
                       ▼
                    Hardware

Agent가 마지막 안전장치가 되어서는 안 된다.

---

23. Emergency Stop은 AI가 판단하면 안 된다

예를 들어 로봇이 사람에게 접근한다.

이때:

Camera
↓
LLM
↓
사람인지 판단
↓
멈출까?

같은 구조는 위험하다.

E-Stop이나 Collision Safety는:

Hardware

PLC

Safety Controller

같은 결정적 시스템이 담당해야 한다.

AI는 그보다 위 Layer에 있는 것이 좋다.

---

24. Physical Agent에는 Digital Twin이 거의 필수에 가까워질 수 있다

새로운 행동을 실제 기계에서 바로 실행할 필요는 없다.

추천 Workflow:

Goal

↓

Agent Plan

↓

Simulation / Digital Twin

↓

Safety Check

↓

Shadow Mode

↓

Human Approval

↓

Physical Execution

이다.

예를 들어 Agent가 로봇팔 경로를 만든다.

먼저 Simulation에서:

충돌

Joint Limit

작업 시간

위험 Zone

을 검증한다.

문제가 없을 때 실제 Hardware에서 실행한다.

---

25. Shadow Mode도 굉장히 유용하다

Agent에게 실제 Control 권한을 주지 않는다.

대신:

현재 상태라면
무엇을 할 것인가?

만 기록한다.

Physical Hardware
      │
      ▼
   Sensor Data
      │
      ▼
     Agent
      │
      ▼
Proposed Actions

실제 작업자는 기존 Controller가 한다.

그리고:

Agent 선택

vs

Human 선택

을 비교한다.

충분히 안정적이면 권한을 단계적으로 올린다.

---

26. 처음부터 Autonomous Factory를 만들 필요는 없다

Physical AI 이야기가 나오면 금방:

무인 공장

으로 가기 쉽다.

현실적인 도입 순서는 오히려:

Level 0
관찰

↓

Level 1
추천

↓

Level 2
사람 승인 후 실행

↓

Level 3
저위험 작업 자동 실행

↓

Level 4
고수준 Goal 기반 Workflow

처럼 가는 편이 안전하다.

---

27. MHS가 제조업에서 흥미로운 이유도 여기에 있다

공장에는 이미 수많은 자동화 Protocol이 있다.

PLC

OPC UA

ROS

Vendor SDK

Industrial Ethernet

MHS가 이 모든 것을 없애는 것은 아니다.

오히려 위에 Agent Layer를 만들려는 접근에 가깝다.

                  AI Agent
                     │
                    MHS
                     │
        ┌────────────┼─────────────┐
        ▼            ▼             ▼
      ROS 2        OPC UA       Vendor SDK
        │            │             │
        ▼            ▼             ▼
      Robot       Machine        Sensor

기존 산업제어 Protocol을 대체하기보다 Agent가 그것들을 일관된 방식으로 사용할 수 있게 하는 쪽이다.

---

28. 즉 MHS는 Hardware OS가 아니다

MHS가:

Robot Operating System 대체

도 아니고:

PLC 대체

도 아니다.

정확히는:

Agent가 여러 종류의 Programmable Hardware를 발견하고 이해하고 안전하게 사용하는 데 필요한 공통 Interface Layer

에 가깝다.

현재 Anthropic도 MHS가 programmable interface를 가진 장비를 대상으로 한다고 설명한다.

---

29. 그럼 일반 개발자가 지금 MHS를 사용할 수 있을까?

현재는 제한적이다.

2026년 9월 기준 MHS는:

Research Preview

단계다.

공식 사이트에서 신청을 받고 있으며 초기 파트너와 과학·로봇·전자·제조 분야 조직을 대상으로 테스트가 진행되고 있다.

핵심 Specification도 아직 일반 Open Source 상태는 아니다.

Anthropic은 Safety Evaluation과 Best Practice를 더 만든 뒤 Open Source할 계획이라고 밝혔다.

따라서 지금 GitHub에서:

npm install mhs

하고 시작하는 일반 개발자용 표준이라고 생각하면 아직 이르다.

---

30. 하지만 지금 준비할 수 있는 것은 많다

MHS 자체를 사용하지 않더라도 Physical Agent Architecture를 비슷하게 설계해볼 수 있다.

예를 들어 Raspberry Pi + Camera + Motor가 있다고 하자.

기존:

Python Script
→ GPIO

대신:

Device Adapter

read_state()
read_camera()
move_motor()
stop_motor()

처럼 Capability를 분리한다.

그리고 별도로:

limits

permissions

device_state

safety

를 정의한다.

---

31. 작은 Physical Agent를 만든다면 이런 구조가 좋다

physical-agent/

├── devices/
│   ├── camera/
│   ├── motor/
│   └── temperature/
│
├── manifests/
│   ├── camera.yaml
│   ├── motor.yaml
│   └── temperature.yaml
│
├── policies/
│   └── safety.yaml
│
├── simulation/
│
├── logs/
│
└── agent/

Device Manifest:

device: motor

capabilities:
  - read_position
  - move
  - stop

limits:
  position:
    min: 0
    max: 100

  speed:
    max: 20

다시 말하지만 이것은 MHS 공식 Schema가 아니라 MHS의 설계 방향을 이해하기 위한 예시다.

---

32. 중요한 것은 Tool 이름보다 Capability다

Agent에게:

motor_move_x_140()

같은 저수준 Tool을 무수히 노출하기보다:

readPosition
move
stop

같은 안정된 Primitive를 제공한다.

그리고 Hardware별 차이는 Adapter가 처리한다.

                  Agent
                    │
            ┌───────┼───────┐
            ▼       ▼       ▼
           read    move    stop
                    │
                    ▼
                 Adapter
                    │
        ┌───────────┼────────────┐
        ▼           ▼            ▼
      Brand A     Brand B      Brand C

장비가 바뀌어도 Agent Workflow는 크게 바뀌지 않는다.

---

33. Physical Agent에서도 Skill 개념이 중요해질 수 있다

예를 들어:

laser-alignment

이라는 Skill이 있다고 하자.

처음에는 Agent가 여러 번 탐색해 알아낸다.

그리고:

1. Camera 상태 확인
2. Laser Power 확인
3. Beam 위치 측정
4. Mirror 조정
5. 다시 측정
6. 오차 이하까지 반복

같은 Workflow로 정리한다.

다음부터 Agent는 처음부터 다시 추론하지 않는다.

Agent
↓
Skill
↓
Deterministic Controller

형태가 된다.

Software Agent에서 발전한 Skill 개념과 매우 비슷하다.

---

34. Physical Agent의 로그는 더 중요하다

Coding Agent가 잘못된 코드를 만들었다면 Git Diff를 보면 된다.

Physical Agent는 작업이 지나가면 상태가 사라질 수도 있다.

따라서:

Timestamp

Device

Previous State

Command

Requested Value

Applied Value

Sensor Result

Agent Reason

Safety Decision

같은 기록이 중요하다.

예:

{
  "time": "14:21:03",
  "device": "motor-02",
  "action": "move",
  "requested": 18,
  "applied": 18,
  "position_before": 41,
  "position_after": 59,
  "result": "success"
}

이런 Event Log가 있어야 사고가 발생했을 때 무엇이 일어났는지 확인할 수 있다.

---

35. Agent Provenance가 Hardware에서도 중요해진다

앞으로 질문은:

누가 Robot Arm을 움직였는가?

만으로 끝나지 않을 수 있다.

어떤 Agent가

어떤 Goal을 받고

어떤 Sensor Data를 보고

어떤 Policy Version으로

어떤 Command를 실행했고

사람이 승인했는가?

까지 필요할 수 있다.

특히:

Manufacturing

Medical

Laboratory

Warehouse

Energy

같은 환경에서는 더욱 그렇다.

---

36. 그래서 Physical Agent Control Plane이 필요해진다

앞으로 이런 시스템을 상상할 수 있다.

                    Agent Control Plane
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
       Identity         Permission        Tasks
          │                │                │
          └────────────────┼────────────────┘
                           ▼
                          MHS
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
          Robot         Camera        Machine

여기에서:

Agent Identity

Device Permission

Action Budget

Safety Policy

Runtime Monitoring

Human Approval

Audit Log

를 관리한다.

---

37. Agent에게도 ‘작업 예산’이 필요하다

Software Agent에서:

Token Budget

Retry Budget

를 두는 것처럼,

Physical Agent에는:

Motion Budget

Time Budget

Energy Budget

Sample Budget

Retry Budget

같은 것도 필요할 수 있다.

예:

같은 Hardware Action
2회 실패

↓

STOP

↓

현재 상태 다시 읽기

↓

Human Notify

같은 정책이다.

앞서 Software QA Agent에서도 중요한 원칙이었던:

Retry

보다:

Re-observation

이 Hardware에서는 훨씬 더 중요하다.

---

38. Hardware Error Recovery는 AI Agent가 잘할 가능성이 있는 영역이다

전통 Automation은:

Error Code 103
→ Procedure 103 실행

형태가 많다.

하지만 실제 Hardware Failure는 복합적이다.

Sensor 변화

Temperature 변화

Motor 상태

Camera 결과

Power 상태

를 함께 봐야 할 수 있다.

Agent가 여러 상태를 종합해서:

가능성 A

가능성 B

가능성 C

를 판단하고 안전 범위 안에서 실험적으로 확인할 수 있다.

QuEra의 Laser 사례도 이 가능성을 보여준다.

---

39. 하지만 LLM의 Physical Intuition은 아직 제한적이다

이 부분은 반드시 같이 봐야 한다.

Anthropic도 이번 Research Preview를 바로 공개 표준으로 내놓지 않는 이유 중 하나로 AI Model이 실제 물리 세계를 충분히 이해하지 못한다는 점을 언급하고 있다.

텍스트와 이미지로 학습한 모델에게:

물체 질량

마찰

관성

기계 Backlash

Sensor Noise

온도 지연

Material Failure

같은 실제 물리현상은 매우 어렵다.

그래서 먼저 제한된 파트너 환경에서 Safety Evaluation과 Best Practice를 만들겠다는 것이다.

---

40. Physical AI에서는 ‘모델이 똑똑해질 때까지 기다린다’도 답은 아니다

모델이 모든 물리 현상을 이해하게 만드는 것만 기다릴 필요는 없다.

더 좋은 Architecture는:

AI

+

Sensors

+

Deterministic Controller

+

Physical Constraints

+

Safety Interlock

+

Simulation

+

Human

이다.

모델의 약점을 시스템으로 보완한다.

이건 최근 Software Agent Architecture와도 같은 방향이다.

---

41. MCP에서 배운 가장 중요한 교훈도 같다

MCP가 성공적으로 확산된 이유 중 하나는:

모든 Tool을 모델에 직접 구현

하지 않고:

Agent

↕

Standard Interface

↕

Tool

로 분리했기 때문이다.

MHS도 비슷한 질문을 Hardware에 던지고 있다.

Agent마다

Robot Driver를 만들 것인가?

아니면:

Hardware를 한 번 표준화해서

여러 Agent가 사용할 것인가?

이다.

---

42. 그래서 ‘MCP 다음은 MHS’라는 표현은 절반만 맞다

시간 순서상으로는 자연스럽다.

하지만 기술적으로:

MCP → MHS로 교체

되는 것은 아니다.

더 정확하게는:

                    AI Agent
                       │
              ┌────────┴────────┐
              ▼                 ▼
             MCP               CLI
              │                 │
              └────────┬────────┘
                       ▼
                      MHS
                       │
                       ▼
                    Hardware

같은 구조가 가능하다.

MHS는 MCP를 밀어내는 것이 아니라 Physical Hardware를 MCP가 접근할 수 있는 새로운 Layer로 만드는 쪽에 가깝다.

---

43. MHS가 열리면 개발자의 범위도 넓어질 수 있다

지금 Agent 개발이라고 하면:

Web

Backend

Cloud

Coding Agent

가 중심이다.

앞으로는:

Robotics

Smart Factory

Smart Home

Lab Automation

Warehouse

Agriculture

Energy

Medical Devices

쪽에서도 Agent Application이 크게 늘 수 있다.

특히 Software Developer가 과거에는 접근하기 어려웠던 Hardware System에 들어갈 진입 장벽을 줄일 가능성이 있다.

---

44. 개인 개발자에게 가장 가까운 분야는 Smart Home과 Robotics일 수 있다

예:

Agent

↓

Camera

Temperature Sensor

Robot

Matter Device

Home Assistant

를 연결한다.

다만 소비자 IoT와 MHS가 직접 연결된다고 발표된 것은 아니다.

여기서 중요한 것은 MHS가 제시하는 Architecture Pattern이다.

Hardware Capability Description

Standard Driver

Shared State

Agent

Safety Boundary

이 구조는 다양한 Physical Agent 시스템에서 참고할 만하다.

---

45. 결국 Agent의 세상이 화면 밖으로 나온다

최근 몇 년간 Agent는 빠르게 확장됐다.

Chat

↓

Code

↓

Browser

↓

Computer

↓

Cloud

그리고 이제:

Physical Hardware

까지 들어오기 시작했다.

Anthropic의 MHS Research Preview는 이 변화를 꽤 명확하게 보여준다.

---

46. 앞으로 개발자가 고민해야 할 질문도 달라진다

Software Agent에서는:

이 Agent에게 Git Write를 허용할까?

를 고민했다.

Physical Agent에서는:

이 Agent에게 Robot Arm을 얼마나 빠르게 움직일 권한을 줄까?

Sample을 폐기할 수 있게 할까?

몇 번까지 Retry하게 할까?

어떤 작업은 반드시 사람이 승인해야 할까?

를 고민해야 한다.

Agent Permission이 곧 물리적 권한이 된다.

---

47. Physical Agent에서 가장 중요한 것은 Intelligence보다 Boundaries일 수 있다

엄청나게 똑똑한 Agent보다:

무엇을 할 수 있고

무엇을 할 수 없으며

언제 멈춰야 하는지

가 명확한 Agent가 더 안전할 수 있다.

따라서 MHS 이후의 핵심은:

Agent Intelligence

만이 아니다.

Agent
+
Hardware Contract
+
Safety Boundary
+
Runtime Verification

이다.

---

48. 개발자가 지금 준비할 만한 Architecture

지금부터 Physical AI를 공부한다면 다음 구조를 추천할 수 있다.

                   Goal
                    │
                    ▼
                AI Agent
                    │
                    ▼
               Planner
                    │
                    ▼
                Simulator
                    │
                    ▼
              Safety Policy
                    │
                    ▼
              Device Adapter
                    │
                    ▼
                 Hardware
                    │
                    ▼
                  Sensor
                    │
                    └──────────→ Agent

그리고 모든 Action을 Log한다.

Observe
→ Plan
→ Validate
→ Act
→ Observe
→ Verify

이 Loop가 기본이 된다.

---

49. MHS가 Open Source되면 가장 먼저 보고 싶은 부분

현재 공개 자료만으로는 실제 Specification 전체를 볼 수 없다.

그래서 정식 Open Source 이후 특히 확인할 부분은:

Device Manifest Schema

Discovery

Authentication

Permission Model

Safety Limit 표현

Unit 표현

Failure / Recovery

State Synchronization

Network Protocol

Driver Conformance

Simulation Interface

Audit / Provenance

이다.

특히 Safety가 Prompt 수준인지 Driver 수준에서 얼마나 강하게 강제되는지가 중요하다.

---

50. 지금 단계에서 MHS를 과대평가해서도 안 된다

현재 MHS는:

Research Preview

다.

아직:

업계 표준으로 확정

된 것도 아니고,

모든 Robot 업체가 채택

한 것도 아니다.

또:

AI가 공장을 완전히 자율 운영

한다는 의미도 아니다.

Anthropic과 초기 파트너들이 AI Agent와 Physical Hardware를 연결하기 위한 공통 규격을 실험하기 시작했다고 보는 것이 정확하다.

---

마무리

MCP가 중요한 이유는 AI에게 새로운 지능을 준 것이 아니었다.

AI가 사용할 수 있는 Software Tool의 세계를 표준화된 방식으로 넓혔기 때문이다.

MHS가 흥미로운 이유도 같다.

단순히 Claude가 Robot Arm을 움직였다는 이야기가 아니다.

더 중요한 질문은:

AI Agent가
서로 다른 물리 장비를
어떻게 발견하고,

무엇을 할 수 있는지 이해하고,

현재 상태를 읽고,

안전한 범위 안에서 조작하고,

여러 장비를 하나의 Workflow로 묶을 것인가?

이다.

Anthropic이 공개한 구조에서는 MHS Driver가 장비별 API 차이를 표준화하고, Device Reference가 측정 가능 값·조절 가능한 값·물리적 특성과 안전 한계를 Agent에게 알려준다. MCP·CLI·Code File을 통해 Agent가 장비를 제어할 수 있고, 반복적이거나 빠른 작업은 Agent가 직접 매 순간 추론하지 않고 Deterministic Code로 내려보낼 수도 있다.

이 구조가 중요한 이유는 결국 Agent가 사용하는 Tool의 정의가 바뀌기 때문이다.

지금까지:

Tool
=
API
Database
Browser
Git

였다면,

앞으로는:

Tool
=
Robot
Microscope
Camera
Laser
Machine
Sensor

도 된다.

하지만 Software와 Physical World 사이에는 결정적인 차이가 있다.

Software는 잘못되면 Rollback할 수 있는 경우가 많다.

Physical World에는:

Undo

가 없는 작업이 많다.

그래서 Physical Agent 시대에는 모델의 Intelligence만큼이나:

Safety Limits

Permissions

Deterministic Controllers

Simulation

Retry Budget

Emergency Stop

Audit Log

Human Approval

이 중요해진다.

한 문장으로 정리하면:

MHS의 진짜 의미는 AI에게 기계를 움직일 권한을 주는 것이 아니라, AI가 실제 기계를 사용할 때 필요한 공통 언어와 안전 경계를 만들기 시작했다는 데 있다.

그리고 이 방향이 자리 잡는다면 Agent 개발의 범위도 크게 달라질 수 있다.

Software Agent

에서:

Physical Agent

로.

Coding Automation

에서:

Experiment Automation
Manufacturing Automation
Robotics Automation

으로.

AI Agent가 화면 밖으로 나오기 시작한 셈이다.

MCP가 Agent에게 Software World의 문을 열었다면,

MHS는 Physical World의 문을 열려는 첫 시도 중 하나다.

---

참고 자료

Anthropic — Previewing the Model Hardware Standard, 2026-08-27
MHS Research Preview의 공식 발표. MHS는 HHMI Janelia Research Campus와의 협력에서 시작됐으며 현미경·Liquid Handler·Robot Arm·Quantum Laser 등 Programmable Hardware를 AI Agent가 공통 Interface를 통해 제어하는 방향을 제시한다. Standardized Driver, read/write Primitive, Device Discovery, Natural-language Hardware Context, Safety Limits, MCP·CLI·Code File 기반 제어 구조를 설명한다.

Model Hardware Standard 공식 사이트
현재 MHS는 Limited Research Preview이며 과학·로봇·전자·제조 분야 파트너를 대상으로 신청을 받고 있다. Safety Evaluation과 Best Practice 개발 이후 Open Source할 계획이다.

Anthropic / QuEra MHS 사례
Quantum Computer Laser System의 Lock Recovery에 MHS 기반 Agent를 적용한 사례에서 기존 수작업·Bespoke Automation과 다른 Adaptive Recovery 접근을 보여준다. 공개 결과에서 MHS 기반 Controller는 실험 환경에서 99.3퍼센트의 Lock Recovery 성공률을 기록했다.

HHMI Janelia Research Campus
MHS는 Janelia의 연구 장비 통합 문제를 해결하려는 작업에서 출발했다. Janelia는 다양한 Custom Microscope와 연구용 Hardware를 개발·운영하는 연구기관으로, Open Science와 Hardware/Software 도구 공개도 지속하고 있다.

핵심 참고 포인트

MHS는 MCP의 대체물이 아니다. MHS가 Hardware를 공통 Driver와 Device Description으로 표준화하고 MCP는 Agent가 그 Hardware에 접근하는 방법 중 하나가 될 수 있다. Anthropic은 MCP 외에도 CLI와 Code File/API를 MHS 제어 방식으로 설명하고 있다.

또한 현재 MHS는 일반 개발자가 바로 설치해서 사용하는 완성형 Open Source 표준이 아니라 제한된 Research Preview다. 따라서 공개된 구조를 기반으로 Physical Agent Architecture를 연구할 수는 있지만, 실제 MHS 공식 Schema나 구현 세부사항을 임의로 가정해서는 안 된다.

가장 흥미로운 기술적 패턴은 Agent가 처음에는 Hardware를 탐색적으로 조작하고, 반복 가능한 관계를 학습한 뒤 그 행동을 Deterministic Code로 변환하는 방식이다. AI가 모든 제어 순간마다 추론하는 것이 아니라 AI Reasoning → Controller 생성 → 빠른 Runtime 실행으로 역할을 분리한다. Physical Agent가 실제 산업 환경으로 확장될수록 이 구조와 함께 Safety Boundary·Simulation·Hardware Interlock·Audit가 핵심이 될 가능성이 높다.