Anthropic Model Hardware Standard 공개: 로봇·장비 제어 AI 에이전트가 필요한 안전 계약

Anthropic이 2026년 8월 27일 Model Hardware Standard, 줄여서 MHS의 연구 프리뷰를 공개했다. MHS는 AI 에이전트가 물리 장비를 안전하게 다루기 위한 공유 규격을 목표로 한다. 초기 대상은 과학 연구소와 첨단 제조 현장이다. 개발자에게 이 소식이 중요한 이유는 분명하다. AI 에이전트가 더 이상 화면 안의 텍스트만 다루지 않고, 실험 장비·로봇·제조 설비처럼 실패 비용이 큰 환경으로 이동하고 있기 때문이다.

소프트웨어 자동화의 실패는 대개 롤백, 재시도, 로그 분석으로 수습할 수 있다. 물론 결제나 개인정보처럼 위험한 영역도 있지만, 많은 경우 피해가 데이터 상태에 머문다. 물리 장비 자동화는 다르다. 잘못된 온도 설정, 잘못된 모터 이동, 잘못된 시약 투입, 잘못된 전압 인가는 장비 파손이나 안전사고로 이어질 수 있다. 그래서 MHS의 핵심은 “AI가 로봇을 잘 움직인다”가 아니라 “AI가 움직일 수 있는 범위를 기계가 이해할 수 있게 제한한다”에 있다.

왜 하드웨어용 표준이 따로 필요한가

AI 에이전트 보안 논의는 그동안 주로 프롬프트 인젝션, 데이터 유출, 도구 호출 권한에 집중됐다. 웹 브라우저나 사내 SaaS를 다루는 에이전트라면 이 정도로도 많은 문제를 설명할 수 있다. 하지만 물리 장비는 상태 공간이 훨씬 복잡하다. 같은 명령이라도 현재 장비 온도, 잠금 상태, 사람의 접근 여부, 재료 투입 상태에 따라 위험도가 달라진다.

예를 들어 “샘플을 90도로 가열해”라는 명령은 실험 프로토콜 안에서는 정상일 수 있다. 하지만 용기가 밀봉돼 있거나, 압력 센서가 비정상이거나, 사람이 챔버를 열어둔 상태라면 즉시 금지돼야 한다. 텍스트 모델이 이런 상태를 추론하도록 맡기는 것은 위험하다. 장비 쪽에서 허용 범위, 선행 조건, 금지 상태, 비상 정지 조건을 명확히 노출해야 한다.

MHS 같은 규격은 이 지점을 표준화하려는 시도다. 에이전트가 장비에 “무엇을 할 수 있는지”를 묻고, 장비가 “어떤 조건에서 어떤 명령만 허용되는지”를 구조화된 형태로 알려줘야 한다. 이것은 API 문서가 아니라 안전 계약에 가깝다.

개발자가 배워야 할 설계 원칙

물리 에이전트의 첫 번째 원칙은 capability discovery다. 에이전트가 장비별 기능을 임의로 추측하면 안 된다. 장비는 자신이 지원하는 명령, 파라미터 범위, 단위, 필요한 선행 상태를 기계가 읽을 수 있는 방식으로 제공해야 한다. 예를 들어 이동 가능한 축, 최대 속도, 금지 구역, 허용 좌표계를 명시해야 한다.

두 번째는 precondition check다. 명령을 실행하기 전에 현재 상태가 조건을 만족하는지 확인해야 한다. 소프트웨어에서도 유효성 검사가 중요하지만, 하드웨어에서는 검사가 생명선이다. 온도, 압력, 전원, 잠금 장치, 사람 감지 센서, 재료 상태 같은 값을 명령 전후로 확인해야 한다.

세 번째는 bounded execution이다. 에이전트가 장기 계획을 세우더라도 장비 명령은 짧고 제한된 단위로 실행돼야 한다. “전체 실험을 알아서 수행”이 아니라 “다음 30초 동안 2mm 이동”, “설정값을 5도 올림”, “센서 값을 읽고 멈춤”처럼 경계가 있어야 한다. 그래야 사람이 중간에 개입할 수 있고, 장애 지점을 좁힐 수 있다.

네 번째는 independent interlock이다. 안전 장치는 모델의 판단 밖에 있어야 한다. 에이전트가 아무리 확신해도 문이 열려 있으면 레이저가 켜지지 않아야 하고, 압력이 임계값을 넘으면 가열이 중단돼야 한다. 이 규칙은 프롬프트가 아니라 펌웨어, 컨트롤러, 게이트웨이 레이어에 있어야 한다.

소프트웨어 에이전트에도 그대로 적용된다

MHS는 하드웨어 이야기지만, 일반 SaaS 개발팀도 배울 점이 많다. 하드웨어에서 “모터 최대 속도”와 “금지 좌표”가 중요하듯, 소프트웨어에서는 “수정 가능한 필드”, “삭제 금지 리소스”, “승인 없는 외부 전송 금지”가 중요하다. 에이전트가 사용할 수 있는 API를 넓게 열어두고 프롬프트로만 통제하는 방식은 오래 버티기 어렵다.

예를 들어 사내 운영 에이전트가 고객 계정을 관리한다면 API 레벨에서 권한을 쪼개야 한다. 읽기 전용 토큰, 초안 생성 토큰, 승인 후 실행 토큰을 분리한다. 삭제나 결제처럼 되돌리기 어려운 동작은 별도 승인 키를 요구한다. 모델이 “하면 안 된다”고 학습됐는지보다 시스템이 “할 수 없게 돼 있는지”가 더 중요하다.

또 하나는 감사 로그다. 하드웨어 장비에서는 누가 어떤 명령을 언제 보냈고 센서 상태가 어땠는지 남겨야 한다. 소프트웨어 에이전트도 마찬가지다. 프롬프트, 도구 호출, 응답, 상태 변경 전후, 승인자, 실패 로그를 남기지 않으면 사고 후 원인을 찾을 수 없다.

도입 시나리오별 위험도

연구실 자동화는 비교적 작은 폐쇄 환경에서 시작하기 좋다. 장비 수가 제한돼 있고 프로토콜이 문서화돼 있으며, 전문가가 결과를 검토한다. 그래도 위험 물질이나 고가 장비가 있다면 비상 정지와 접근 제어가 필수다.

제조 현장은 훨씬 어렵다. 장비 간 연쇄 효과가 있고, 생산 라인 중단 비용이 크며, 사람과 기계가 같은 공간을 쓰는 경우가 많다. AI 에이전트가 추천만 하는 단계와 실제 제어하는 단계는 완전히 다르게 관리해야 한다. 추천 단계에서는 설명 가능성과 작업자 UI가 중요하고, 제어 단계에서는 안전 인증과 독립 인터락이 필요하다.

개인용 로봇이나 가정용 기기는 또 다른 문제를 만든다. 사용자가 전문가가 아니고 환경이 예측 불가능하다. 아이, 반려동물, 장애물, 네트워크 지연, 센서 오작동을 고려해야 한다. 이 영역에서는 모델 성능보다 제품 책임과 기본 안전 설계가 먼저다.

개발팀 체크리스트

• 에이전트가 제어할 수 있는 장비 또는 API의 capability 목록을 구조화한다.
• 각 명령에 파라미터 범위, 단위, 선행 조건, 금지 조건을 붙인다.
• 실행 전후 상태 확인을 강제하고, 조건 불일치 시 모델 판단 없이 중단한다.
• 위험 명령은 짧은 시간·작은 변화량으로 쪼개고 사람 승인 지점을 둔다.
• 비상 정지와 하드 리밋은 프롬프트가 아니라 독립 제어 계층에 둔다.
• 모든 명령, 센서 상태, 승인, 실패 결과를 감사 로그로 남긴다.
• 시뮬레이터 또는 디지털 트윈에서 회귀 테스트를 먼저 돌린다.
• 소프트웨어 에이전트에도 같은 원칙을 적용해 삭제·결제·외부 전송 권한을 분리한다.

MHS는 아직 연구 프리뷰 단계다. 하지만 방향은 명확하다. AI 에이전트가 물리 세계로 나갈수록 개발자는 “무엇을 시킬 수 있는가”보다 “무엇을 절대 못 하게 막을 것인가”를 먼저 설계해야 한다.