"화이트보드에 손글씨로 적어둔 to-do 리스트를 Spot이 읽고 그대로 일했다."

4족 보행 로봇 Spot이 거실에서 신발을 신발장에 넣고, 빈 음료수 캔을 치우는 영상이 3월에 공개됐다. 시연 자체보다 더 흥미로운 건 그 뒤 구조다. 엔지니어가 작성한 코드는 "자연어 프롬프트" 한 묶음이 전부였고, 작업 순서·실패 처리·재시도는 전부 Gemini Robotics가 결정했다.

이게 뭔데?

Boston Dynamics가 Google DeepMind와 묶여서 만든 두 개의 결과물이 한 달 사이에 같이 나왔다.

(1) "To Do List with Spot" — 가정 환경에서 자연어 명령으로 청소를 수행하는 실험적 데모. Gemini Robotics-ER 1.5가 Spot의 SDK를 호출해 작업을 오케스트레이션. (2) AIVI-Learning(상용 제품) — Spot의 산업 시각 검사 기능에 Gemini Robotics-ER 1.6가 통합된 정식 출시. 2026년 4월 8일 모든 AIVI 고객에게 자동 활성화.

한 줄로 정리하면, 로봇이 일하는 방식이 "코드 짜기"에서 "자연어 지시"로 옮겨가고 있다. 그것도 데모가 아니라 산업 현장에서.

  • 계기판 인식 23% → 98%
    Gemini Robotics-ER 1.5에서 1.6 + agentic vision으로 가면 이렇게 점프한다. 비교: Gemini 3.0 Flash 단독은 67%.
  • "State machine 코드" 작성 시간 → 자연어 프롬프트 작성 시간
    각 단계를 코드로 정의하던 방식에서, 자연어로 도구의 용도를 설명하면 LLM이 알아서 시퀀스를 만들어내는 방식으로.
  • 현장 사용자가 "왜 그렇게 판단했는지" 볼 수 있게 됨 (Transparent Reasoning)
    AIVI가 검사 결과만 던지는 게 아니라 추론 과정을 노출. 안전·규제 산업에서 필수적인 변화.
  • Zero-Downtime Upgrades
    모델은 클라우드에서 자동 갱신. 펌웨어 업데이트·다운타임 없이 검사 정확도가 알아서 올라간다.

코드를 안 짜면 어떻게 일을 시킨다는 건데?

전통적인 로봇 프로그래밍은 "state machine"이다. 이동 → 카메라 켜기 → 객체 인식 → 그립 → 이동 → 내려놓기, 각 단계를 분기 처리·실패 처리·재시도까지 포함해 코드로 짠다. 환경이 바뀌면 코드를 다시 짠다.

Boston Dynamics 팀이 한 일은 다르다. SDK 위에 "도구(tool) 레이어"를 만들고, 각 도구가 무엇을 하는지를 자연어 프롬프트로 설명했다. 예를 들어 "TakePicture" 도구의 프롬프트는 이렇게 적혀 있다.

"이 명령은 지정된 카메라로 사진을 찍는다. 카메라 선택에 미묘한 차이가 있다. GoTo로 도착한 직후에는 항상 그리퍼 카메라부터 찍어라 — 가장 정보가 풍부하다. 만약 로봇이 이미 무엇을 들고 있다면, (1) PutDown을 즉시 호출하거나 (2) 전면 카메라로 영역을 탐색한다. 단, 전면 카메라는 낮은 위치에 있어 높은 곳의 물건을 찍기에는 부적합하다."

이게 코드 한 줄이 아니다. 로봇 하드웨어의 물리적 한계를 자연어로 설명한 것이다. 그리고 이게 작동한다. 데모 당일 화이트보드에 손으로 적어둔 to-do 리스트를 그대로 Spot이 카메라로 읽고, 항목별로 도구를 호출해 끝까지 처리했다.

현장에서 보고된 변화는 다음과 같다.

지표 기존 (코드형 자동화) Spot × Gemini Robotics
새 작업 추가 state machine 코드 작성·테스트·배포 자연어 프롬프트 추가·즉시 시연
계기판 인식 정확도 전통 비전 모델 / Gemini Robotics-ER 1.5: 23% Gemini Robotics-ER 1.6 + agentic vision: 98%
모델 업데이트 로봇 펌웨어 업데이트 + 다운타임 필수 Zero-Downtime, 클라우드 자동 반영
판단 근거 확인 블랙박스 Transparent Reasoning(추론 단계 노출)
실패 시 처리 예외 처리 코드를 사람이 모두 작성 도구가 자연어로 응답("손이 가득 차서 못 잡음") → LLM이 재계획

마지막 행이 핵심이다. 도구가 결과를 자연어 문장으로 돌려주면 — "물건을 집었습니다", "손이 가득 차서 못 집습니다" — Gemini Robotics가 그걸 보고 다음 단계를 다시 생각한다. 예외 케이스를 사람이 미리 다 코딩하지 않아도 되는 것이 진짜 변화다.

그래서 산업 현장에선 뭐가 달라졌는데?

가정 청소 데모가 흥미로운 건 "신기해서"가 아니다. 같은 구조가 산업 현장(AIVI-Learning)에 그대로 적용됐기 때문이다.

Spot은 자동차 공장·발전소·물류센터에서 정기 점검 임무를 맡는다. 한 번 순회마다 점검할 자산은 수백 개 — 게이지(아날로그 압력계·온도계), 사이트 글래스(탱크 안 액체 수위), 컨베이어 벨트 손상, 누유 흔적, 5S 정리 상태 등. 이걸 정확하게 읽으려면 단순 객체 인식이 아니라 "복잡한 시각 추론"이 필요하다.

점검 항목 기존 Gemini Robotics-ER 1.6 통합 후
아날로그 게이지 / 사이트 글래스 0~100% 측정 객체 인식만 가능, 수치 못 읽음 정확한 수치 추출 가능
5S 컴플라이언스 감사 사람이 직접 점검 자동화 (multi-shift 인력 대체)
팔레트 카운팅 수기 / 별도 비전 시스템 AIVI가 직접 처리
웅덩이·미인가 인원 감지 주기적 인력 순찰 Site View 알림 (다음 릴리즈)
모델 업데이트 현장 다운타임 필요 클라우드 자동 갱신, 다운타임 0

특히 계기판 인식 점프 — 23% → 98% — 가 의미하는 건 단순한 수치 개선이 아니다. 이 정도까지 와야 "사람이 매번 검증하지 않아도 되는" 자동 점검이 실제로 가능해진다. 23%면 사람이 따라다녀야 한다. 98%는 사람이 예외만 본다.

주목할 차이 하나 더: "agentic vision"이라는 새 개념이다. 모델이 이미지를 한 번 보고 답하는 게 아니라, 이미지에 점을 찍거나 영역을 자르거나 다시 들여다보는 "scratchpad" 동작을 통해 단계적으로 추론한다. 인간이 시계 바늘을 정확히 읽으려고 가까이 가서 다시 보는 행동을 모델이 흉내 내는 것에 가깝다.

한국 회사 입장에서 무엇을 봐야 하는데?

Spot은 한국에서도 이미 한화·현대·SK 등에 깔려 있다(현대차그룹이 Boston Dynamics 모회사). 그러니까 멀리 있는 이야기가 아니다. 로봇 도입 의사결정 자체가 "코드 외주 비용"에서 "프롬프트 운영 역량"으로 옮겨갈 수 있다.

  1. 1단계: 로봇 워크플로우 설계자의 역할이 바뀐다
    "각 단계를 어떻게 코드화할까"가 아니라 "어떤 도구를 만들어 LLM이 자유롭게 조합하게 할까"로. 도구의 입력·출력·에러 메시지를 자연어로 잘 설계하는 능력이 곧 로봇 운영 역량이 된다.
  2. 2단계: 점검 결과의 "추론 로그"를 남긴다
    Transparent Reasoning이 켜지면 매 점검마다 LLM의 판단 근거가 기록된다. 한국 산업 안전 규제(중대재해처벌법 등)에서 "왜 그렇게 판단했는가"의 근거가 필수가 되는 시점, 이 로그가 핵심 증빙이 된다.
  3. 3단계: 클라우드 모델 의존성을 명시적으로 평가한다
    Zero-Downtime Upgrade는 편하지만, 모델이 자동으로 바뀐다는 뜻이기도 하다. 발전소·반도체 fab처럼 변경관리(MoC)가 엄격한 산업에서는 "오늘 검사한 모델"과 "내일 검사한 모델"이 다를 수 있다는 점을 운영 절차에 반영해야 한다.
  4. 4단계: 데이터 공유 약관을 검토한다
    AIVI-Learning은 사용 시 facility 데이터를 Boston Dynamics와 공유해야 한다(BD 내부 사용에 한정). 한국 산업기밀(반도체 공정·발전소 도면 등)이 학습 데이터로 들어가도 되는지 법무·보안 검토 필수.

핵심만 정리: 시작하는 법

  1. 1단계: "코드형 자동화"를 자연어 프롬프트 + 도구 레이어로 재해석한다
    로봇/RPA 워크플로우를 가진 회사는, 기존 state machine 로직을 "도구 단위"로 쪼개고 각 도구의 용도·제약·실패 모드를 자연어로 적어본다. 이 과정 자체가 LLM 기반 자동화 도입의 첫걸음.
  2. 2단계: 정확도 기준선을 "사람 동행 가능" 수준으로 잡는다
    Gemini Robotics-ER 1.6의 98% 같은 수치가 의사결정 임계값이다. 80% 이하는 사람이 매번 검증해야 하고, ROI가 안 나온다. 95%+가 나오는 영역부터 적용 후보로 본다.
  3. 3단계: Transparent Reasoning을 운영 로그로 활용한다
    점검 자동화 도입 시 "결과만" 받지 말고 추론 과정을 함께 저장. 사고 발생 시 원인 분석·규제 대응 근거가 된다.
  4. 4단계: 모델 자동 업데이트 정책을 운영 절차에 반영한다
    Zero-Downtime은 편의지만, 안전 임계 산업에선 "어떤 모델 버전이 검사를 수행했는가"가 추적되어야 한다. 운영 절차에 모델 버전 기록을 추가.
  5. 5단계: 데이터 공유 가능 영역과 격리 영역을 분리한다
    모든 검사 데이터를 외부 학습에 보내지 않는다. 일반 안전 점검(범용)과 고유 기밀(공정·도면)은 별도 워크플로우로 운영.