2026년 9월 23일, Google은 공식 개발자 블로그를 통해 Antigravity SDK가 로컬 모델 워크플로를 지원한다고 발표했다. 첫 지원은 Google AI Edge의 LiteRT를 통한 Gemma 4 26B A4B다. 이제 개발자는 완전히 오프라인인 환경에서도 에이전트 기능을 갖춘 어시스턴트를 실행할 수 있다. 코드와 요청이 기기를 벗어나지 않는다.
도입 조건은 구체적으로 명시됐다. Google은 24GB 이상의 VRAM 또는 통합 메모리를 권장한다. 설치는 두 단계면 된다. pip로 google-antigravity와 litert-lm을 설치하고, Hugging Face의 litert-community 조직에서 Gemma 4 26B A4B의 LiteRT 버전을 다운로드하면 몇 줄의 코드로 로컬 Agent가 실행된다. 공식 예제에서 이 로컬 에이전트는 "현재 디렉토리에 어떤 파일이 있나요?"라는 질문에 답한다. 가장 소박하면서도 가장 많은 것을 말해주는 작업이다.
주목할 이유: 클라우드의 두뇌와 로컬의 일꾼
Google이 내세우는 것은 '로컬이 클라우드를 대체한다'가 아니라 하이브리드 오케스트레이션이다. 공식 데모에서는 Architect-Builder 패턴이 소개된다. 클라우드의 Gemini 3.8 Flash가 계획과 스케줄링을 맡는 '설계자', 로컬 머신의 Gemma 4 26B 무리가 실제 작업을 맡는 '시공팀'이라는 역할 분담이다. 데모에서는 취약점이 있는 세 모듈 auth.py, billing.py, database.py의 감사와 패치가 전부 로컬에서 이뤄지고, 데이터는 내부망을 벗어나지 않는다.
이 분업의 계산은 분명하다. 계획과 스케줄링에는 최강 모델의 판단력이 필요하므로 클라우드에 두고, 토큰을 많이 먹는 실행 단계는 로컬로 옮긴다. API 비용과 속도 제한을 아끼면서 엄격한 데이터 컴플라이언스도 만족시킨다. Google이 든 네 가지 이유 — 비용, 프라이버시, 오프라인 복원력, 하이브리드 편성 — 은 본질적으로 같은 질문에 답한다. 어느 단계에 클라우드 대형 모델의 대가를 치를 가치가 있고, 어느 단계가 로컬에서 해결 가능한가라는 질문이다. 이는 transformers의 GGUF 네이티브 지원과 같은 흐름이며(로컬에서 양자화 모델을 돌리는 문턱은 계속 낮아지고 있다 (/article/2045-transformers-yuan-sheng-zhi-chi-gguf-ben-di-pao-liang-hua-mo-xing-bu-yong-zai-zh)), 온디바이스 연산 자원은 '모델이 돌아간다'에서 '에이전트가 돌아간다'로 진화하고 있다.
경계선
24GB VRAM 요구사항은 대부분의 얇고 가벼운 노트북을 제외시킨다. 26B급 모델을 로컬에서 돌리기 위한 피할 수 없는 하드웨어 셈법이다. 현재 권장 실행 백엔드는 LiteRT이며, 다른 로컬 모델과 실행 옵션에 대해 Google은 '지원 범위를 확대하겠다'고만 밝히고 시점은 제시하지 않았다. 또한 오프라인 동작이 유지보수 불필요를 뜻하지는 않는다. 모델 파일, SDK 버전, 로컬 환경 업데이트는 직접 챙겨야 한다.
