안전 경고는 클라우드를 기다리지 않는다, 달리는 에이전트의 조건
Google DeepMind Running Guide agent는 물리 세계 에이전트의 핵심이 모델 성능보다 지연 시간, 온디바이스 안전, 검증에 있음을 보여줍니다.
- 무슨 일: Google DeepMind가 시각장애 및 저시력 러너를 위한 Running Guide agent를 공개했습니다.
- chest-mounted
Pixel 10 Pro, 온디바이스 segmentation,Gemma 4 E4B, Planner/Coach/Break 에이전트를 결합합니다.
- chest-mounted
- 의미: 에이전트가 채팅창 밖 물리 세계로 나오면 핵심 경쟁력은 답변 품질보다 지연 시간과 안전 경계가 됩니다.
- 주의점: Google은 SG Enable과 실사용자 테스트를 말하지만, 넓은 환경의 장기 독립 검증은 아직 공개되지 않았습니다.
- 비, 야간, 소음, 카메라 흔들림, 경로 복잡도는 접근성 에이전트가 반드시 통과해야 할 현실 조건입니다.
Google DeepMind가 2026년 5월 20일 공개한 Running Guide agent는 겉으로 보면 따뜻한 접근성 프로젝트입니다. 시각장애 또는 저시력 러너가 사람 가이드, 물리적 tether, 트랙에 그어진 선 없이 달릴 수 있도록 돕는 AI 러닝 보조 시스템입니다. 하지만 AI 개발자 관점에서 보면 이 발표는 더 까다로운 질문을 던집니다. 에이전트가 화면 안에서 텍스트를 생성하는 수준을 넘어, 사람이 빠르게 움직이는 물리 환경에서 안전 결정을 보조하려면 어떤 구조가 필요합니까.
이 질문이 중요한 이유는 단순합니다. 코딩 에이전트가 잘못된 파일을 고치면 되돌릴 수 있습니다. 고객지원 에이전트가 답을 잘못하면 상담원에게 넘기거나 사후 정정할 수 있습니다. 그러나 달리는 사람 앞에 장애물이 나타났을 때 STOP 경고가 늦으면, 에이전트의 실패는 로그 한 줄이 아니라 몸의 위험으로 바뀝니다. Running Guide agent는 그래서 모델 성능 발표라기보다, 물리 세계 에이전트의 운영 조건을 드러낸 뉴스에 가깝습니다.
Google의 설명에 따르면 이 시스템은 chest-mounted Pixel 10 Pro가 앞쪽 경로를 보고, 러너에게 auditory feedback을 제공합니다. 즉 사용자는 스마트폰을 몸에 장착하고, 헤드폰이나 이어폰을 통해 방향성 ticking sound, 짧은 음성 경고, 휴식과 재개 안내를 듣습니다. Google은 이 기술이 과거 Project Guideline 위에 세워졌다고 설명합니다. Project Guideline은 시각장애 러너가 스마트폰과 헤드폰만으로 표시된 선을 따라 달릴 수 있게 하려던 연구였습니다. 이번 발표의 변화는 "선을 따라가기"에서 "환경을 이해하기"로 이동했다는 점입니다.

안전 경로와 추론 경로를 나눈 이유
Google은 Running Guide agent를 hybrid, dual-path architecture라고 부릅니다. 첫 번째 경로는 온디바이스 segmentation입니다. Pixel 10의 custom silicon 위에서 offline으로 실행되며, 즉각적인 안전 판단을 맡습니다. 경로 이탈, 급박한 장애물, 멈춤이 필요한 상황에서는 네트워크 호출이나 대형 모델 추론을 기다리지 않고 바로 STOP alert와 steering cue를 내보냅니다. 러너가 방향 감각을 유지할 수 있도록 directional ticking sound도 이 계층에서 나옵니다.
두 번째 경로는 Gemma 4 E4B 기반의 고수준 장면 이해입니다. Google은 이 경로가 이미지와 텍스트 multimodal input을 처리하며, 복잡한 지형 변화나 새로운 장애물을 이해한다고 설명합니다. 여기서 핵심은 모든 프레임을 분석하지 않는다는 점입니다. Smarter Frame Selection은 갑작스러운 지형 변화나 새로운 물체처럼 정보량이 큰 frame만 골라 처리합니다. 모델을 더 크게 만드는 대신, 어떤 순간에 모델을 깨울지 고르는 스케줄링이 안전과 지연 시간의 일부가 됩니다.
이 구조는 많은 AI 에이전트 제품이 놓치기 쉬운 현실을 보여줍니다. 위험한 행동을 모델 하나에 모두 맡기지 않습니다. 빠르고 단순한 안전 경로는 로컬에서, 느리지만 맥락이 필요한 해석은 별도 reasoning 경로에서 처리합니다. 자율주행이나 로봇 공학에서 익숙한 layered safety 구조가, 이제 소비자용 접근성 에이전트 발표에도 등장한 셈입니다. "최고 성능 모델을 붙였다"가 아니라 "늦으면 안 되는 판단과 깊게 봐야 하는 판단을 분리했다"가 이 발표의 핵심입니다.
| 계층 | 주요 역할 | 왜 분리하나 |
|---|---|---|
| 온디바이스 segmentation | 즉각적인 STOP, steering cue, 경로 이탈 감지 | 네트워크와 대형 추론 지연을 기다릴 수 없는 안전 판단입니다. |
| Gemma 4 E4B | 장애물, 지형 변화, 장면 맥락 이해 | 복잡한 해석이 필요하지만 모든 프레임을 처리하면 느려집니다. |
| 멀티 에이전트 계층 | 계획, 주행 중 코칭, 휴식 상태 관리 | 운동 경험을 하나의 prompt가 아니라 역할별 상태 기계로 나눕니다. |
세 에이전트가 러닝 경험을 나눈다
Google은 Running Guide agent를 collaborative multi-agent framework라고 설명합니다. 이름만 보면 최근 유행하는 멀티 에이전트 마케팅처럼 들릴 수 있습니다. 하지만 여기서는 역할 분리가 비교적 명확합니다. Planner agent, Coach agent, Break agent가 각기 다른 시간대와 위험 수준을 맡습니다.
Planner agent는 달리기 전의 준비를 담당합니다. Google의 설명에 따르면 이 에이전트는 Gemma 4의 function calling을 사용해 weather와 Google Maps data를 가져오고, 러너와 대화하며 workout goal을 정하고, digital starting line을 calibrate합니다. 이것은 일반적인 운동 앱의 설정 화면처럼 보일 수 있지만, 시각장애 또는 저시력 러너에게는 출발점과 경로 이해가 안전의 일부입니다. 계획 단계가 틀리면 주행 중 에이전트가 아무리 똑똑해도 위험이 커집니다.
Coach agent는 달리는 중간에 작동합니다. Google은 이 에이전트가 concise, telegraphic verbal alerts를 제공한다고 설명합니다. 중요한 표현은 triage hierarchy입니다. DANGER는 즉각 회피해야 하는 상황, WARNING은 주변 러너나 장애물, NOTICE는 곧 다가올 트랙 커브처럼 덜 급하지만 알아야 하는 정보를 뜻합니다. 주행 중 음성 인터페이스는 길게 설명할 수 없습니다. 러너는 숨이 차고, 주변은 시끄럽고, 반응 시간은 짧습니다. 따라서 에이전트의 출력 품질은 문장 자연스러움보다 우선순위와 압축률에 달려 있습니다.
Break agent는 휴식 구간을 관리합니다. 달리기는 계속 움직이는 한 가지 상태가 아닙니다. 사용자는 멈추고, 물을 마시고, 호흡을 고르고, 다시 시작합니다. 보조 시스템이 이 상태 전환을 놓치면 잘못된 시점에 경고를 내거나, 재개 후 경로 상태를 잘못 이해할 수 있습니다. Break agent는 이런 pause/resume 상태를 명시적으로 관리합니다. 작아 보이지만, 실제 사용자 경험에서는 "에이전트가 지금 내가 쉬고 있다는 사실을 아는가"가 신뢰의 중요한 일부입니다.
이 설계는 AI 에이전트가 점점 더 좁은 도메인으로 들어갈수록 범용 추론보다 workflow state가 중요해진다는 흐름과 맞닿아 있습니다. 코딩 에이전트도 planning, editing, testing, reviewing을 나눕니다. 금융 에이전트도 alert triage, case investigation, human review를 나눕니다. Running Guide agent는 같은 원칙을 물리적 활동에 적용합니다. 차이는 실패 비용입니다. 여기서는 상태 관리 실패가 곧 안전 문제입니다.
Project Guideline에서 달라진 점
Running Guide agent를 이해하려면 2021년 Google Research가 공개한 Project Guideline을 함께 봐야 합니다. 당시 프로젝트는 Google Research, Google Creative Lab, Accessibility Team, Guiding Eyes for the Blind가 협력한 초기 연구였습니다. 스마트폰 카메라가 지면의 guideline을 보고, 러너가 경로 중심에서 벗어나면 오디오 신호로 방향을 알려주는 방식이었습니다. Google은 Guiding Eyes for the Blind CEO Thomas Panek이 Central Park에서 독립 5K를 완주한 사례를 소개했습니다.
2023년 Google은 Project Guideline을 오픈소스 접근성 컴퓨터 비전 플랫폼으로 공개했습니다. 이때도 핵심은 온디바이스 기술이었습니다. 러너의 velocity vector를 사용해 카메라 흔들림의 노이즈를 줄이고, 러닝 중 irregular camera movement를 고려하는 식입니다. 즉 Running Guide agent는 갑자기 등장한 agent demo가 아니라, 몇 년 동안 이어진 접근성 컴퓨터 비전 연구 위에 agentic layer를 얹은 형태입니다.
차이는 경로의 성격입니다. Project Guideline은 표시된 선을 따라가는 문제에 가까웠습니다. Running Guide agent는 "실시간 환경 이해"를 전면에 둡니다. Google은 단순 path-following에서 advanced, real-time spatial reasoning으로 넘어간다고 표현합니다. 이 표현을 과장 없이 읽으면, 모델이 세상 전체를 완벽히 이해한다는 뜻은 아닙니다. 대신 라인 검출 중심의 폐쇄적 task에서, 장애물과 지형 변화가 있는 더 열린 task로 이동한다는 뜻입니다.
여기서 개발자에게 중요한 교훈은 두 가지입니다. 첫째, 물리 세계 에이전트는 한 번에 end-to-end로 만들기 어렵습니다. 먼저 좁은 경로 추적 문제를 풀고, 그다음 장면 이해와 계획을 붙이는 식으로 확장됩니다. 둘째, agent라는 이름이 붙어도 기반은 여전히 센서, segmentation, latency, 하드웨어, 사용자 테스트입니다. 모델이 주인공처럼 보이지만, 실제 제품의 신뢰는 주변 시스템에서 나옵니다.
온디바이스 AI의 가치가 선명해지는 순간
온디바이스 AI는 종종 프라이버시나 비용 절감의 언어로 설명됩니다. Running Guide agent에서는 더 직접적입니다. 안전 경고는 클라우드를 기다릴 수 없습니다. 러너가 빠르게 움직이는 동안 네트워크 품질은 일정하지 않고, 지연 시간은 작은 숫자 차이처럼 보이다가 실제 환경에서는 큰 위험 차이로 바뀝니다. Google이 offline segmentation을 별도 안전 경로로 둔 이유가 여기에 있습니다.
Gemma 4 E4B를 기기에 올리는 선택도 같은 맥락입니다. Google은 이 모델이 high-level scene understanding을 온디바이스로 수행한다고 설명합니다. 즉 "카메라 영상을 서버로 보내 큰 모델이 판단한다"는 구조가 아닙니다. 물론 모델 크기와 성능, 배터리, 발열, 프레임 선택 정책은 모두 trade-off입니다. 하지만 접근성 보조에서 로컬 추론은 단순한 제품 차별점이 아니라, 사용 가능성의 전제에 가깝습니다.
이 지점은 AI 인프라 팀에도 시사점이 있습니다. 앞으로 에이전트 아키텍처는 클라우드 LLM 호출 하나로 설명되지 않을 가능성이 큽니다. 빠른 local model, 작은 vision model, event filter, function calling, cloud service, device sensor, policy layer가 역할을 나눕니다. Running Guide agent는 이를 소비자 접근성 시나리오로 보여줍니다. 같은 구조는 공장 안전 보조, 물류 현장 agent, 의료 보조 기기, 차량 안 개인 assistant에서도 반복될 수 있습니다.
특히 Smarter Frame Selection은 주목할 만합니다. 모든 sensor input을 대형 모델에 넣는 방식은 비용과 지연 시간에서 곧 막힙니다. 대신 시스템은 어떤 frame이 고위험 또는 고정보량인지 판단하고, 그때만 reasoning path를 호출합니다. 이것은 단순한 optimization이 아니라 agent runtime의 핵심 기능입니다. 무엇을 무시해도 되는지, 무엇을 절대 놓치면 안 되는지 결정하는 계층이 생기는 것입니다.
접근성 AI에서 검증은 기능보다 앞선다
Google은 Singapore의 disability and inclusion focal agency인 SG Enable과 협력해 BLV runners와 실제 테스트를 진행한다고 밝혔습니다. 이 점은 중요합니다. 접근성 기술은 연구실 demo만으로 평가할 수 없습니다. 사용자의 신체 조건, 운동 경험, 선호하는 오디오 cue, 주변 소음, 노면 상태, 날씨, 문화적 맥락이 모두 다릅니다. "잘 보이는 데모 영상"보다 "다양한 사용자가 장기간 어떻게 실패를 경험하는가"가 더 중요합니다.
동시에 공개된 정보에는 한계가 있습니다. Google 발표는 기술 방향과 architecture를 설명하지만, 독립적인 장기 안전 평가, 실제 사용자 수, 실패율, weather/lighting 조건별 성능, 경고 false positive와 false negative 비율은 공개하지 않았습니다. 이것은 비판이라기보다 현재 상태를 정확히 보는 데 필요한 조건입니다. 물리 세계 접근성 에이전트는 일반 앱 기능보다 높은 검증 기준을 요구합니다.
예를 들어 안전 경고가 너무 자주 울리면 사용자는 경고 피로를 느낄 수 있습니다. 반대로 경고가 너무 보수적이지 않으면 위험한 상황을 놓칠 수 있습니다. 방향 cue가 너무 복잡하면 러너가 즉시 반응하지 못할 수 있고, 너무 단순하면 상황을 구분하기 어렵습니다. 음성 안내는 이어폰, 주변 차량 소리, 바람, 호흡 소리와 경쟁합니다. 카메라는 비, 역광, 야간, 흔들림, 다른 사람의 갑작스러운 움직임에 영향을 받습니다. 이런 문제는 모델 benchmark만으로 닫히지 않습니다.
그래서 이 뉴스의 핵심은 "AI가 사람 가이드를 대체한다"가 아닙니다. 더 정확한 표현은 "AI가 특정 조건에서 독립성을 넓히는 보조 계층으로 시험되고 있다"입니다. 사람 가이드, 안전한 인프라, 접근성 커뮤니티, 스포츠 단체, 도시 환경은 여전히 중요합니다. Running Guide agent가 의미 있는 이유는 그 모든 것을 지우기 때문이 아니라, 기술이 맡을 수 있는 좁지만 중요한 영역을 더 넓히려 하기 때문입니다.
개발자가 읽어야 할 구조적 신호
AI 업계에서 agent라는 단어는 너무 넓게 쓰입니다. 어떤 경우에는 챗봇에 tool call을 붙인 수준이고, 어떤 경우에는 장시간 작업을 수행하는 소프트웨어 노동자이며, 어떤 경우에는 물리 환경에서 센서와 actuator를 다룹니다. Running Guide agent는 이 단어의 범위를 다시 좁혀 보게 만듭니다. 여기서 에이전트는 "목표를 이해하고, 상태를 유지하고, 도구와 센서를 사용하며, 위험 우선순위에 따라 행동을 조절하는 시스템"입니다.
개발자에게 첫 번째 신호는 runtime 분리입니다. 안전에 가까운 판단은 deterministic하거나 작은 모델에 가까운 fast path로 두고, 풍부한 해석은 느린 path로 보냅니다. 두 번째 신호는 role separation입니다. Planner, Coach, Break처럼 서로 다른 상태와 책임을 명시적으로 나눕니다. 세 번째 신호는 user-in-the-loop가 아니라 user-in-motion입니다. 사용자가 화면을 보고 확인 버튼을 누르는 상황이 아니라, 달리는 동안 즉각 반응해야 하는 상황입니다. UI와 UX의 기준이 완전히 달라집니다.
이 관점에서 보면 Running Guide agent는 Google의 접근성 프로젝트이면서 동시에 ambient AI의 시험대입니다. Google은 intelligent eyewear prototype도 언급했습니다. 안경은 더 넓고 안정적인 field of view를 제공하고, Pixel device로 stream을 보내 multimodal model에 더 나은 입력을 줄 수 있다고 설명합니다. 이것은 스마트폰 중심 에이전트에서 wearable sensor 중심 에이전트로 넘어가는 경로를 암시합니다.
다만 안경이 들어오면 개인정보와 사회적 수용성 문제도 커집니다. 러너 주변의 사람과 공간이 카메라에 잡히고, 모델이 주변 환경을 해석합니다. 데이터가 온디바이스에서 처리된다고 해도, 사용자와 주변인의 신뢰를 얻으려면 무엇이 저장되고, 무엇이 전송되고, 어떤 상황에서 기록이 남는지 명확해야 합니다. 접근성의 이점이 크다고 해서 privacy와 safety 검토가 작아지는 것은 아닙니다.
에이전트 안전의 다음 단위는 밀리초
최근 AI 뉴스는 모델 점수, context window, tool use, benchmark 순위에 집중하는 경우가 많습니다. Running Guide agent는 다른 축을 보여줍니다. 물리 세계에서 에이전트의 핵심 단위는 token만이 아닙니다. frame, sensor latency, audio cue, battery, heat, network fallback, user reaction time이 함께 들어옵니다. AI 인프라가 실제 세계로 나올수록 "몇 token을 생성했는가"보다 "몇 밀리초 안에 무엇을 막았는가"가 더 중요한 지표가 됩니다.
이 변화는 코딩 에이전트에도 간접적으로 영향을 줍니다. 안전 임계값이 높은 도메인에서는 모델이 잘 설명하는 것보다, 위험한 행동을 fast path에서 멈추는 구조가 중요합니다. 파일 삭제, 결제 실행, 의료 조언, 차량 제어, 산업 설비 조작은 모두 같은 질문을 받습니다. 무엇은 로컬 policy로 즉시 차단하고, 무엇은 느린 reasoning으로 검토하며, 무엇은 사람에게 넘길 것입니까. Running Guide agent는 이 질문을 러닝이라는 구체적 장면에 놓습니다.
결국 이번 발표의 가치는 "Google이 멋진 접근성 demo를 만들었다"에만 있지 않습니다. AI 에이전트가 실제 세계에 붙을 때 필요한 최소 조건을 보여줍니다. 온디바이스 safety path, multimodal reasoning path, 역할별 agent state, 사용자 커뮤니티와의 테스트, 보수적인 한계 인식이 그것입니다. 이 조건이 없으면 agent는 똑똑해 보여도 신뢰하기 어렵습니다.
Running Guide agent는 아직 넓은 배포와 독립 검증을 거친 완성품으로 읽어서는 안 됩니다. 하지만 방향은 분명합니다. 에이전트 시대의 안전은 prompt 문구나 모델 점수에서 끝나지 않습니다. 어떤 판단을 클라우드 밖으로 빼야 하는지, 어떤 경고를 몇 밀리초 안에 내야 하는지, 사용자가 움직이는 동안 어떤 상태를 잃지 않아야 하는지까지 내려갑니다. 달리는 사람 앞에서 AI는 더 짧게 말하고, 더 빨리 멈추고, 더 조심스럽게 행동해야 합니다.