Google VERID 분석: AI 실험실에 코드보다 더 필요한 상태 기록

새 발표에서 읽어야 할 범위

Google Research는 2026년 10월 16일 VERID와 두 분자 설계 연구를 함께 소개했다. VERID는 VERified Infrastructure for Discovery Laboratories의 약자다. 이 글은 10월 18일 확인한 자료를 바탕으로, 그중 에이전트와 실험 장비를 연결하는 기반 구조에 집중한다. 발표는 이 연구들을 앞으로 결합할 방향도 설명한다. 서로 다른 연구의 성과를 합쳐 “이미 완성된 무인 신약 개발 서비스”로 읽어서는 안 된다. 공식 발표

관심을 가질 이유는 모델이 실험 절차를 길게 써 주기 때문이 아니다. 실험 도중 멈췄을 때, 다음 작업자가 현재 장비와 시료에 실제로 무엇이 일어났는지 알아야 하기 때문이다. 이 문제는 로봇을 쓰는 연구팀뿐 아니라 AI를 물리 작업에 연결하려는 개발팀에도 중요하다. 계산을 다시 하는 비용과 이미 옮긴 물질을 다시 옮기는 비용은 다르다.

디지털 트윈은 실험실의 어떤 부분을 대신 표현하나

논문의 VERID는 장비 위치·용기·내용물·팁 상태를 담는 지속적 상태 모델이다. 에이전트는 상태를 조회하고, 복제한 상태에서 명령 블록을 검사한다. 실제 전달 직전에도 현재 상태로 재검증하며, 상태·영상·실행 기록을 시간축에 맞춰 남긴다. 시뮬레이터는 이산적인 상태 회계 모델이다. 논문 §2·§6.2

이를 이해할 때는 디지털 트윈을 “실험실을 똑같이 복제한 영상”으로만 상상하지 않는 편이 좋다. 개발 관점에서 중요한 질문은 무엇을 모델에 넣었고, 어떤 변화가 그 기록을 갱신하는가다. 가령 용기 위치를 잘 표현해도 내용물이 고르게 섞였다는 사실까지 자동으로 알 수 있는 것은 아니다. 모델에 없는 현상은 검사 통과 뒤에도 남는다.

기반 라이브러리인 PyLabRobot은 여러 실험 장비를 Python으로 제어하는 공개 프로젝트다. 공개 코드를 읽으면 “상태 추적”의 의미를 더 구체적으로 볼 수 있다. 확인한 VolumeTracker는 부피 변경 예정값과 확정값을 나누고, 용량·잔량 검사와 commit·rollback을 제공한다. 여기서 rollback은 예정값을 확정값으로 되돌린다. 물리 장비를 역으로 움직이는 메서드가 아니다. 이 코드는 VERID 전체 구현이나 논문 실험 버전으로 확인한 것이 아니다. 고정 커밋의 상태 추적 코드

이 구분에서 실무 설계 원칙이 나온다. 화면에 “잔량”을 표시한다면 센서가 읽은 값인지, 시작량에서 명령량을 뺀 값인지도 드러나야 한다. 두 값이 평소에는 같아 보여도, 누출이나 수동 개입 뒤에는 다른 판단이 필요하다. 계산된 상태를 관측된 상태로 착각하지 않게 만드는 일이 에이전트 연결의 출발점이다.

연구가 보여 준 실패는 서로 다른 종류다

논문은 물·색소를 사용한 사례를 보고한다. 좁은 용기에 맞지 않는 다중 채널 동작은 실행 전에 거절됐다. 혼합 문제는 실행 후 자료와 영상을 대조했고, 첫 사례의 원인 확인에는 사람이 참여했다. 측정기 오류 뒤 준비를 반복하지 않고 이어 간 사례도 있다. 내부 Gemini 4 Argon 프리뷰를 사용했으며, 아래 해석은 자체 재현 결과가 아니다. 논문 §3.1·§3.2·§6.2

이 사례들을 제품 도입 질문으로 바꿔 보면 세 가지 검사가 필요하다. 다음 표는 연구의 성능표가 아니라 이 글의 분석 기준이다.

물어볼 질문	필요한 증거	그것만으로 답할 수 없는 것
이 동작을 지금 수행해도 되는가?	현재 상태와 모델에 표현된 제약	실제 동작이 끝났는가
장비는 어디까지 수행했는가?	작업 식별자·수행 기록·현재 물리 상태	얻은 측정값을 믿어도 되는가
이 결과를 비교·해석해도 되는가?	측정 조건·원본 자료·이상 원인 검토	다른 장비·시료에서도 같은가

예를 들어 모든 명령이 성공했다고 해도 측정값의 이상이 사라지는 것은 아니다. 반대로 측정 파일을 받지 못했다고 해서 앞선 준비가 실패한 것도 아니다. 이 두 상황을 같은 “작업 실패”로 묶으면, 원인을 찾는 대신 전체를 반복하게 된다.

따라서 AI가 다음 실험을 고르게 하려면 결과표뿐 아니라 그 결과가 만들어진 조건도 넘겨야 한다. 같은 경향이 여러 번 나왔다는 사실만으로 원인이 입증되지는 않는다. 반복할 때 같은 장비 배치나 처리 순서도 반복됐다면, 그것이 결과에 미친 영향을 따로 물어야 한다. 추가 실험이 항상 유용한 것이 아니라, 서로 다른 원인 가설을 가를 수 있을 때 유용하다.

가상 사례: 준비가 끝난 P17을 다시 만들 것인가

다음은 직접 만든 복구 판단 사례다. VERID의 실제 로그·지원 API·제품 화면이 아니며 장비 운전 절차도 아니다. 연구팀이 비생물학적 색소 측정 작업을 관리한다고 가정한다. P17은 측정 대상 판의 식별자, R42는 작업 식별자다. 준비 과정은 이미 완료됐다고 기록되어 있고, 측정 결과를 불러오던 화면이 멈췄다.

담당자가 보고 싶은 것은 하나의 빨간 실패 표시보다 다음 세 질문이다.

1. 준비가 실제로 끝났는가? 어떤 대상에 어떤 단계까지 수행했는지, 이후 사람이 건드렸는지 확인한다.
2. 측정이 실제로 끝났는가? 화면 응답과 장비 자체의 수행 기록을 나눠 본다.
3. 결과를 올바른 작업에 연결했는가? 파일이 있다는 사실과 그 파일이 P17·R42의 결과라는 사실을 구분한다.

같은 오류 메시지가 나타나도 다음 행동은 달라진다. 아래의 “검토”에는 담당자의 장비 상태 확인과 해당 실험의 유효 조건 확인이 포함된다.

대조한 상황	다음 행동	자동으로 반복하지 않을 것
장비는 측정 완료, 원본 파일도 있고 P17·R42와 일치. 화면에만 미표시	기존 결과의 연결·표시 복구	준비와 측정 전체
준비 완료와 현 상태 일치, 측정은 시작되지 않았다고 확인됨	준비된 대상이 여전히 유효한지 확인한 뒤 측정 재개 검토	이미 완료된 준비
측정 시작 기록은 있지만 종료·결과 여부가 불명확	장비 기록과 저장소를 추가 대조. 미확인 상태 유지	응답이 없다는 이유만으로 재측정
저장된 상태 뒤 사람이 판을 교체했거나 대상이 불명확	상태 모델과 현장 대조부터 다시 수행	오래된 상태를 근거로 한 재개

첫 행에서는 파일의 내용만 읽는 것으로 충분하지 않다. 이전 작업의 파일이 같은 폴더에 남아 있을 수 있으므로 대상·작업·측정 조건을 확인해야 한다. 두 번째 행에서도 시간이 지났다는 사실을 놓치면 안 된다. 실험의 유효 시간이나 보관 조건을 벗어났다면 “준비 완료” 기록만으로 같은 대상을 계속 사용할 수 없다. 허용 시간은 이 글에서 임의로 정할 수 없으며 해당 업무 담당자가 정해야 한다.

세 번째 행은 자동화가 불편해 보이는 지점이다. 시스템이 “알 수 없음”을 남기고 멈추기 때문이다. 하지만 여기서 완료나 실패를 추측해 채우면, 나중에는 어떤 단계가 중복됐는지 복원하기 더 어려워진다. 네 번째 행은 지속되는 기억에도 갱신 책임이 필요하다는 반례다. 기록을 오래 보존하는 것과 기록이 현재 사실인 것은 별개다.

이 예의 가치는 물리 작업을 데이터베이스 트랜잭션처럼 되돌릴 수 있다고 가정하지 않는 데 있다. 실패 처리에는 재시도 횟수뿐 아니라 이미 남긴 물리적 변화와 아직 확인하지 못한 변화를 구별할 기록이 필요하다.

재개 판단을 남기는 작은 기록 양식

다음 항목은 이 글이 제안하는 인수인계 양식이다. 공식 VERID 설정이나 실행 코드가 아니다. 사람과 에이전트가 같은 자료를 보고 다음 행동을 정할 때 쓸 수 있다.

대상 / 작업 식별자:
적용한 절차·조건의 버전:
마지막으로 확인한 물리 상태와 확인 시각:
  - 직접 관측:
  - 명령 기록에서 계산:
  - 아직 추정 또는 미확인:
완료가 확인된 단계 / 근거 위치:
완료 여부가 불명확한 단계 / 추가로 볼 기록:
원본 결과 파일 / 대상·작업과의 연결 확인:
중단 뒤 수동 개입·장비 이동·조건 변화:
재사용 가능한 대상인지 판단할 유효 조건:
재개할 단계 / 반복하지 않을 단계 / 판단 담당자:

재개 판단 기록 양식 내려받기. 실제 개인정보나 민감한 연구 자료를 공개 양식에 넣을 필요는 없다. 팀 내부의 기록 위치와 식별자로 연결하면 된다.

화면을 만든다면 요약에는 현재 상태와 미확인 항목을 두고, 상세에는 같은 작업의 시간순 기록과 결과 파일을 붙이는 구성이 적합하다. 오류 알림이 사라져도 미해결 항목은 다시 찾을 수 있어야 한다. 이는 구현하지 않은 화면 설계 제안이다. 이 글은 VERID UI의 모바일 배치·키보드 조작을 확인한 사용기가 아니다.

도입 가치는 모델 교체 비용 밖에서 결정된다

VERID의 시뮬레이션 통과를 모든 물리 현상의 검증으로 읽을 수는 없다. 논문은 실행 자료의 대규모 지식 추출과 그 후속 효과 검증을 향후 과제로 둔다. 공개 자료만으로 임의의 장비에 설치해 바로 사용할 수 있는 배포 패키지나 전체 비용을 확인하지도 못했다. 논문 §4.2·결론

도입하려는 팀은 먼저 자주 중단되는 한 업무를 고르고, 아래 질문에 답해 보는 편이 낫다. 다음은 연구 결과에서 출발한 편집 제안이며 성능 보장 조건이 아니다.

• 기록할 상태를 누가 관리하는가? 장비 배치나 용기가 바뀔 때 정의를 갱신할 담당자가 필요하다.
• 명령과 실제 결과를 무엇으로 대조하는가? 장비 응답만으로 충분한 단계와 별도 관측이 필요한 단계를 나눈다.
• 중단 뒤 되살릴 자료가 남는가? 로그·원본 파일·작업 식별자를 묶어 다시 찾을 수 있어야 한다.
• 틀린 결과를 더 빨리 만들고 있지는 않은가? 완료 시간과 함께 재작업 원인, 해석 불가 결과, 사람 검토 시간을 기록한다.

기존의 고정 절차가 안정적으로 돌아가고 변경이 드물다면, 장비 연결·상태 모델 유지·영상 보관·검토 체계를 추가하는 비용이 클 수 있다. 반대로 실험 조건을 자주 바꾸고, 실패 후 처음부터 다시 준비하는 비용이 크다면 지속되는 상태와 실행 기록을 먼저 갖출 이유가 있다. 이 판단은 구독 가격 한 줄이나 모델 점수만으로 하기 어렵다.

처음 비교할 산출물도 거창할 필요가 없다. 과거 중단 사례 하나를 골라 다른 담당자가 기록만으로 “어디까지 완료됐고 무엇이 미확인인지” 구분할 수 있는지 확인한다. 못 찾은 근거가 무엇인지 남기면, 다음에 추가할 장비 정보나 로그를 정할 수 있다. 실제 시간 절감·재료 절감은 그렇게 범위를 고정한 뒤 측정해야 한다.

형식에 맞는 출력과 실제 업무 조건의 차이는 JSON 출력 검증 글에서 이어 읽을 수 있다. AI가 전문 도구와 자료를 결합할 때 생기는 판단 경계는 Earth AI 분석과 연결된다. 이 글의 판단표를 다시 사용할 예정이라면 저장 기능을, 다음 분석을 받아보려면 RSS를 이용할 수 있다.