달리는 사람은 ‘생각’해서 달리지 않는다. 걸음마다 땅을 확인하고, 소리를 듣고, 자세를 고치는 건 몸의 반사다. 그런데 우리가 만드는 에이전트는 대부분 ‘생각’만 할 줄 안다. 그리고 그게 바로, 에이전트가 ‘달릴 수 없게’ 만드는 이유다.

시각장애인 러너에게 달리기는 왜 늘 ‘줄’이 필요했나

시각·저시력(BLV) 러너가 달리려면 전통적으로 물리적 테더(tether)가 필요했다. 곁에서 함께 달리는 인간 가이드, 또는 트랙에 칠해진 가이드 라인. 둘 다 ‘다른 누군가’ 또는 ‘영구 인프라’에 기댄다. 가이드가 없다면, 라인이 없는 야외 코스라면, 그 사람은 달리기를 포기해야 했다.

이 문제를 구글 딥마인드가 5월에 한 발짝 걷어찼다. Running Guide agent — 가슴에 착용한 Pixel 10 Pro가 앞길을 보고, 뼈전도 헤드폰으로 방향과 위험을 실시간 안내하는 접근성 에이전트다. 러너는 인터넷 연결 없이, 인간 가이드 없이, 칠해진 라인 없이 혼자 달릴 수 있게 된다. 구글은 이를 ‘러닝 언바운디드(무한한 달리기)로 가는 한 걸음’이라고 불렀다.

그런데 이 뉴스를 ‘감동적인 접근성 스토리’로만 읽으면 반은 놓친다. 나는 매일 에이전트를 설계하고 운영하는 입장에서 이 시스템의 아키텍처를 봤고, 여기서 에이전트를 만드는 모든 사람에게 적용되는 원칙을 발견했다. 이 글은 그 원칙을 공유하려는 글이다. 아래에서 다루는 제품에 대한 사실(구조, 모델, 파트너십)은 딥마인드 발표에서 온 외부 정보이고, 그것을 내 워크플로에 대입해 본 해석과 경험은 내 것임을 미리 밝혀둔다.

“STOP은 생각해서 말할 수 없다” — 듀얼패스 구조

딥마인드 발표에 따르면 Running Guide agent는 하이브리드 듀얼패스 아키텍처를 쓴다. 두 개의 추론 경로가 동시에, 서로를 막지 않게 돈다.

경로 1 — 안전 경로. Pixel 10 Pro의 커스텀 실리콘에서 완전 오프라인으로 도는 분할(segmentation) 모델. 즉각적인 STOP 알림과 방향을 인코딩한 ‘틱(ticking)’ 사운드 같은 안전 크리티컬 출력을 담당한다. 셀룰러 연결이 죽어도 멈추지 않는다.

경로 2 — 추론 경로. Gemma 4 E4B가 AICore NPU에서 멀티모달(이미지+텍스트) 입력을 받아 고수준 장면을 이해한다. 트랙이 어떻게 휘는지, 노면이 언제 바뀌는지, 근처 주자가 있는지 같은 맥락을 판단한다.

여기서 핵심은 격리(isolation)다. 안전 경로는 추론 경로가 끝나기를 절대 기다리지 않는다. 만약 두 작업이 하나의 추론 큐에 들어갔다면, NPU 지연 변동(latency variance)이 그대로 안전 경로에 전파됐을 것이다. 배터리와 열이 공유되는 스마트폰에서는 특히 치명적이다. 그래서 컴퓨팅 자원을 하드웨어 레벨에서 나눠버렸다.

이 원칙은 한 문장으로 요약된다. 응답의 지연 요구가 경로를 결정하지, 입력의 복잡도가 경로를 결정하지 않는다. 한 번의 추론 사이클 안에 와야 하는 STOP은 어떤 장면이든 빠른 경로로 간다. 수백 ms의 여유가 있는 “40m 앞에서 트랙이 왼쪽으로 꺾인다” 같은 조언은 느려도 되고, 대신 풍부한 추론을 탄다.

모든 프레임을 큰 모델에 넣지 않는 이유 — Smarter Frame Selection

두 번째 패턴은 계산 효율에 대한 것이다. Gemma 4 E4B를 모든 비디오 프레임에 돌리면 배터리는 세션을 끝내지 못한다. 온디바이스 추론은 열·전력 모두 비싸다. 그래서 딥마인드는 Smarter Frame Selection을 만들었다.

이름은 단순해 보이지만 요점이 있다. 추론 경로에 들어가는 프레임을 ‘고엔트로피(high-entropy) 프레임’으로 한정한다. 갑작스러운 지형 변화, 새 장애물의 등장, 트랙 분기점 — 직전 프레임 대비 장면이 크게 달라진 순간만 골라서 큰 모델에 넘긴다. 똑같은 직선 주로를 일정한 페이스로 달리는 동안의 프레임은 스킵된다.

중요한 것은 이 필터가 안전 경로에는 영향을 주지 않는다는 점이다. 분할 경로는 모든 프레임을 계속 받는다. 안전 커버리지는 그대로 유지하면서, NPU 부하와 전력 소모만 줄이는 것이다.

프레임 디퍼런싱이나 광학 플로우 크기, 혹은 작은 이진 분류기 하나만으로도 이 ‘엔트로피 게이트’는 구현 가능하다. 그리고 장면이 안정적일수록 절약이 커진다. 연속 온디바이스 추론이 얼마나 비싼지 고민하는 사람이라면, 이 패턴은 ‘언제 모델을 호출할지’도 설계 대상이라는 사실을 보여준다.

하나의 거대한 에이전트가 아니라, 세 개의 무상태 서브에이전트

딥마인드 발표에서 가장 인상 깊은 부분은 멀티에이전트 프레임워크다. Running Guide는 하나의 모놀리식 루프가 아니라, 상태를 공유하지 않는 세 개의 서브에이전트가 이벤트로 핸드오프하는 구조다.

  • Planner(플래너) — 런 전 담당. Gemma 4의 function calling으로 날씨와 Google Maps 데이터를 가져오고, 러너와 대화로 운동 목표를 정하며 ‘디지털 출발선’을 보정한다. 세 에이전트 중 유일하게 인터넷이 필요하다.
  • Coach(코치) — 런 중 담당. 듀얼패스 출력을 DANGER(즉시 회피) / WARNING(근접 위험) / NOTICE(안내) 3단계로 등급화해 전보체(telegraphic)처럼 짧게 말한다. 레이스 페이스의 인지 부하에 맞춘 설계다.
  • Break(브레이크) — 휴식 구간 담당. 휴식 시간을 관리하고 세션 상태를 보존해서, 재개 시 코치가 처음부터 다시 초기화하지 않도록 한다.

이 분해의 진짜 가치는 실패의 폭발 반경(blast radius)에 있다. 각 서브에이전트는 좁은 책임을 갖고, 겹치지 않는다. 플래너는 실시간 코칭을 시도하지 않고, 코치는 휴식 관리를 시도하지 않는다. Break의 상태 직렬화가 실패해도 안전 크리티컬인 방향 큐는 영향을 받지 않는다. 팀은 코치의 알림 등급만 손대면서, 플래너의 function calling 스키마를 건드리지 않을 수 있다.

현재는 가슴 착용 Pixel 10 Pro가 유일한 계산 호스트지만, 2세대 프로토타입은 지능형 안경(eye-wear)으로 전환 중이다. 안경은 더 넓고 안정적인 시야를 제공하되, 영상을 Pixel로 스트리밍한다. 계산 호스트는 그대로 두고 입력 파이프라인만 바꾸는 증분 설계다.

이 원칙들이 내 워크플로에 꽂힌 방식

여기부터는 외부 사실이 아니라, 내가 실제로 멀티에이전트 시스템을 운영하면서 부딪혀서 배운 것들이다. 딥마인드 발표를 읽으면서 그동안 겪었던 실패들이 하나씩 명명되기 시작했다.

첫째, ‘반사 경로’와 ‘사고 경로’를 섞으면 지연 변동이 퍼진다. 내 파이프라인에서도 예외는 아니었다. 도구 호출처럼 즉시 실패해야 하는 작업과, 천천히 정리해도 되는 작업을 같은 큐에 넣었더니, 느린 작업 하나가 빠른 작업의 대기 시간을 늘리는 일이 반복됐다. 듀얼패스가 하드웨어 레벨에서 경로를 분리한 것처럼, 내 경우엔 서로 다른 latency class를 같은 대기열에 넣지 않는 것부터 시작했다.

둘째, 서브에이전트의 책임을 좁게 유지하면 고장이 격리된다. ‘한 에이전트가 뭔가 하다가 망가졌는데, 그 옆에 있던 안전한 작업까지 덩달아 실패’하는 경험은 누구나 있다. Break 에이전트처럼 ‘상태 보존’만 담당하는 조각이 있다면, 그 조각의 실패는 그 조각에서 끝난다. 에이전트를 쪼갤수록 안정성이 올라가는 게 아니라, 실패의 반경이 줄어드는 것이다.

셋째, 온디바이스 function calling은 프라이버시가 디폴트다. 위치·건강 같은 민감 데이터는 구조적으로 클라우드 라운드트립을 피해야 한다. 러너의 신체 상태 데이터가 런 중에 외부 서버를 거치지 않는다는 것은, 설계 원칙 이상의 의미다. 클라우드로 돌리던 도구 오케스트레이션을 로컬로 옮길 수 있다면, 라운드트립 지연과 데이터 노출을 동시에 줄일 수 있다.

배달물은 ‘제품’이 아니라 ‘패턴’이다

여기서 한 가지 솔직한 경계를 그어야 한다. 이 시스템은 5월 기준 리서치 프로토타입이다. 공개 SDK, API, 가격, 출시 일정은 없다. 싱가포르의 장애인·포용 기관인 SG Enable과 파트너십을 맺고 실제 BLV 러너와 함께 필드 트라이얼을 진행하는 단계다. 심지어 두 추론 경로의 ms 단위 지연 수치조차 공개되지 않았다. 구글의 공식 표현은 ‘러닝 언바운디드로 가는 한 걸음’ — 즉 ‘도착’이 아니라 ‘과정’이다.

그래서 이 뉴스에서 실제로 가져갈 배달물은 제품이 아니라 패턴이다. 그리고 그 패턴은 지금, 공개된 도구로 조립 가능하다.

  • 듀얼패스 분할 — 전용 저지연 파이프라인 + (AICore / Core ML / ONNX Runtime 중 하나)의 조합으로 오늘 구현 가능하다. “한 번의 추론 사이클 안에 와야 하는 응답”은 전용 경로를 줘라.
  • 엔트로피 게이트 — 고비용 모델 호출 앞에 작은 프레임 디퍼런싱 또는 이진 분류기를 달아라. 비디오 입력 에이전트라면 비용이 바로 절감된다.
  • 온디바이스 function calling — Gemma 4 E4B는 Android AICore로 바로 접근 가능하고, 온디바이스 툴 사용은 Google Developers Blog에 문서화돼 있다.
  • 좁은 서브에이전트 — 거대한 에이전트 하나를 무상태·이벤트 기반의 좁은 책임으로 쪼개라.

이 패턴은 접근성 밖으로도 그대로 일반화된다. 창고 로봇(충돌 회피 = 빠른 경로, 경로 최적화 = 추론 경로), 자율주행 보조(긴급 제동 vs 차선 변경 조언), AR 오버레이, 웨어러블 헬스 모니터링(임계 경보 vs 트렌드 분석). ‘실시간 센서 입력 + 혼합 지연 요구’가 있는 모든 에이전트에 적용되는 골격이다.

이번 주, 당신의 에이전트에서 ‘반사’를 분리해 보라

Running Guide agent가 보여준 것은 결국 하나다. 에이전트가 안전하려면, 반사는 반사대로, 사고는 사고대로 돌아야 한다. 그리고 그 반사가 있어야, 에이전트는 ‘생각만 하는 프로그램’을 넘어 ‘실제로 달릴 수 있는 존재’가 된다.

시작은 거창하지 않다. 당신의 워크플로에서 “반드시 즉시 와야 하는 응답” 하나를 찾아라. 그 응답에 전용 경로를 줘라. 고비용 모델 콜 앞에는 엔트로피 게이트를 달아라. 하나의 거대한 에이전트를, 좁고 무상태인 서브에이전트들로 쪼개라.

나는 그 첫 줄 하나로 파이프라인 안정성이 눈에 띄게 달라지는 걸 직접 경험했다. 당신의 워크플로에서 ‘STOP’에 해당하는 것은 무엇인가? 댓글로 공유해 준다면, 에이전트의 반사 신경을 설계한 실제 사례들을 모아 다음 글을 쓰겠다. 그리고 이 시리즈가 유용했다면 구독해 두는 것을 추천한다 — 에이전트를 ‘안전하게’ 만드는 이야기를 계속 다룰 예정이다.

근거 출처

외부 정보 (하베스터 수집): 본문의 제품·구조·모델·파트너십 관련 사실은 다음 출처에서 가져왔다.

  • Google DeepMind 공식 발표 — “Running Guide agent: A step towards running unbounded” (2026-05-20, blog.google)
  • Google Developers Blog — Gemma 4 엣지 배포·온디바이스 function calling 문서
  • Creeta 기술 분석 — “DeepMind Guides Blind Runners On-Device — No Cloud, No Tether” (2026-05-30)

상호작용 (에이전트-드루 대화·작업): ‘이 원칙들이 내 워크플로에 꽂힌 방식’ 섹션은 필자가 운영 중인 멀티에이전트 시스템(Drewgent)에서 실제로 겪은 운영 경험을 바탕으로 한 1인칭 서술이다. 외부 통계나 인용된 수치가 아니다.