AI 에이전트의 도구 사용은 지금까지 대체로 브라우저, 코드 저장소, 사내 시스템 안에서 이야기됐다. 8월 27일 Anthropic이 연구 미리보기로 공개한 Model Hardware Standard, MHS는 그 도구의 범위를 현미경, 액체 처리기, 로봇 팔 같은 물리 장비까지 넓히려는 규격이다.
여기서 중요한 점은 에이전트가 갑자기 장비를 잘 조종하게 됐다는 발표가 아니다. 서로 다른 제조사의 장비를 연결할 때마다 만들던 전용 통합 코드를 공통 드라이버와 공통 명령으로 줄이려는 접근이라는 점이다. AI를 업무에 붙이는 과정에서 자주 마주치는 문제와도 닮았다. 모델의 답변 능력보다 먼저, 어떤 시스템을 어떤 방식으로 발견하고 읽고 바꿀지 정해져 있어야 한다.
장비 연결의 번역기를 표준으로 만들려는 시도
Anthropic의 설명에 따르면 MHS는 프로그래밍 가능한 인터페이스를 가진 장비를 대상으로 한다. 장비별 드라이버가 운영체제와 장비 사이를 번역하듯, MHS 드라이버는 에이전트와 장비 사이에 공통 층을 둔다. 온도를 읽는 read, 설정값을 바꾸는 write처럼 단순한 명령을 공통 단위로 삼는 방식이다.
이 구조에서는 장비가 무엇을 측정하고 무엇을 조절할 수 있는지, 어느 범위가 안전한지를 표준 형식으로 드러낼 수 있다. 로봇 팔의 무게나 가동 범위처럼 코드만 보고는 알기 어려운 물리적 특성도 태그와 참조 파일에 담는다고 Anthropic은 설명한다. 에이전트가 장비를 처음 만났을 때 매뉴얼을 추측하는 대신, 사전에 작성된 제약과 능력 목록을 읽게 하려는 것이다.
MHS의 제어 경로는 MCP, 명령줄, 코드 파일 API 세 가지다. 따라서 MCP는 전체 장비 자동화 그 자체가 아니라 에이전트가 표준화된 장비 기능을 호출하는 한 경로가 된다. Ars Technica도 이 규격을 서로 다른 실험 장비가 네트워크에서 공통 형식으로 정보를 교환하게 하는 표준 드라이버 인터페이스로 설명했다. 이미 MCP 서버를 실험하는 팀이라면 이 차이가 특히 중요하다. 서버 연결이 된다는 사실만으로 물리 작업이 안전해지는 것은 아니다.
자연어 지시보다 먼저 고정해야 할 것
장비 제어에 LLM을 얹으면 사람이 자연어로 실험 순서를 요청하고, 에이전트가 여러 장비를 조율하는 그림이 가능해진다. Anthropic은 장기 실행 작업에서 매 단계마다 모델이 추론하지 않도록 드라이버 명령을 코드 파일로 묶어 실행할 수 있다고도 설명한다. 반복되는 동작은 결정적인 스크립트로 옮기고, 판단이 필요한 지점만 에이전트가 맡는 구분이다.
이 구분은 현장 자동화에서 꽤 현실적이다. 예를 들어 온도 설정, 샘플 이동, 촬영처럼 검증된 절차는 고정된 명령으로 남기고, 측정 결과를 보고 다음 조건을 제안하는 역할만 모델에 주는 편이 낫다. 그러면 장애가 났을 때도 원인을 모델의 추론, 드라이버, 장비 상태, 사람이 정한 운영 절차로 나누어 볼 수 있다.
CNBC는 MHS가 현재 과학·로봇·제조 분야의 제한된 조직에 제공되는 연구 미리보기이며, 향후 오픈소스화 계획이 있다고 보도했다. 아직 누구나 바로 도입할 수 있는 범용 장비 플랫폼은 아니다. Anthropic도 공간과 물리 세계에 대한 모델의 이해에는 한계가 있어 전문가 감독이 필요하다고 적었다. 단백질 샘플의 거품처럼 물리적 실패를 소프트웨어 오류와 혼동할 수 있다는 사례도 함께 제시했다.
안전 한계는 프롬프트가 아니라 장비 가까이에 둬야 한다
물리 장비에서는 잘못된 한 번의 호출이 데이터 손실, 시료 훼손, 설비 중단으로 이어질 수 있다. 그래서 ‘이 범위를 넘지 마라’는 문장을 프롬프트에만 적어두는 방식은 부족하다. MHS가 장비 특성과 안전 한계를 드라이버의 정보로 표현하려는 이유도 여기에 있다. 모델이 그 규칙을 읽는 것과 별개로, 드라이버와 장비 쪽에서 허용 범위를 실제로 막아야 한다.
실무에서라면 권한을 더 잘게 나누는 편이 좋다. 처음에는 상태 읽기와 로그 수집만 허용한다. 다음 단계에서 시뮬레이터나 비가동 장비로 제한된 쓰기 명령을 시험한다. 실제 장비의 설정을 바꾸거나 동작을 시작하는 명령은 담당자의 승인과 작업 기록을 남기도록 둔다. 이 과정은 속도를 늦추는 절차가 아니라, 자동화가 틀렸을 때 되돌릴 수 있는 범위를 좁히는 설계다.
또 하나는 실패 처리다. 에이전트가 오류를 감지하고 재시도할 수 있다는 설명은 편리하게 들리지만, 재시도가 안전한 오류와 즉시 멈춰야 하는 오류는 다르다. 통신 지연처럼 무해한 문제와 충돌 감지, 온도 이상, 시료 누출 가능성을 같은 재시도 정책으로 다루면 안 된다. 중단 조건, 사람 호출 조건, 재개 권한은 장비별로 문서화해야 한다.
지금 할 수 있는 작은 점검
당장 실험 장비나 로봇이 없더라도 MHS를 읽으며 자신의 AI 자동화를 점검할 수 있다.
- 도구 목록을 능력과 제약으로 나눠 적어본다. 사내 API나 자동화 스크립트마다 읽을 수 있는 값, 바꿀 수 있는 값, 바꾸면 안 되는 범위를 표로 만든다. 설명 문장보다 API 수준의 제한이 있는지 확인한다.
- 반복 절차와 판단 절차를 분리한다. 매번 같은 순서로 실행되는 작업은 테스트 가능한 스크립트로 남기고, 예외 판단이나 다음 행동 제안만 에이전트에 맡긴다. 실행 결과와 입력값을 남기면 나중에 비교하기도 쉬워진다.
- 중단과 재개를 한 작업으로 정의한다. 실패하면 누가 어떤 근거로 멈추고, 어떤 점검 후에 다시 시작하는지 적어둔다. 읽기 전용 자동화에서도 이 규칙을 만들어 두면 쓰기 권한을 추가할 때 기준이 생긴다.
표준이 해결하지 않는 부분
MHS가 널리 쓰이더라도 장비의 품질, 센서 오차, 네트워크 지연, 현장 안전 절차가 사라지는 것은 아니다. 프로그래밍 인터페이스가 없는 장비에는 아직 적용되지 않으며, 규격 자체도 연구 미리보기 단계다. ‘통합 시간이 몇 시간으로 줄어든다’는 Anthropic의 설명과 초기 사례는 방향을 보여 주지만, 각 조직의 장비 구성과 검증 기준에서 같은 효과가 난다고 볼 근거는 아직 부족하다.
이번 발표를 개인이나 팀의 자동화 관점에서 읽으면, 물리 장비라는 낯선 소재보다 인터페이스 설계의 원칙이 남는다. 에이전트에 더 많은 권한을 주기 전에 도구의 이름, 입력과 출력, 안전 한계, 승인 기록을 먼저 정리해야 한다. MHS가 앞으로 열린 표준으로 자리 잡을지는 더 지켜봐야 한다. 다만 AI가 소프트웨어 바깥의 일을 맡기 시작할수록, 좋은 자동화는 자연스러운 대화보다 명확한 경계에서 시작된다는 점은 분명하다.