Google Antigravity SDK 로컬 모델, 에이전트를 오프라인으로 전환하지만 하드웨어가 한계를 정한다

Google이 Antigravity SDK 로컬 모델을 추가하면서, 개발자는 처음으로 API 키나 인터넷 연결 없이 에이전트 워크플로를 실행할 수 있게 됐다.

초기 최적화 경로는 Gemma 4 26B A4B와 Google AI Edge의 LiteRT 런타임을 결합한다. Google은 최소 24GB의 VRAM 또는 통합 메모리를 권장한다. 로컬 실행이라는 약속에도 불구하고, 이 요구 사항은 완전한 경험을 많은 일반 노트북의 범위 밖에 둔다.

이번 출시는 중요한 경계를 옮긴다. 개발자는 더 이상 모든 프롬프트, 소스 파일 또는 도구 결과를 호스팅 모델로 전송할 필요가 없다. 다만 클라우드 에이전트는 여전히 더 쉬운 배포, 더 큰 모델 용량, 더 적은 하드웨어 제약을 제공한다.

따라서 Google은 이를 포기하지 않으면서 클라우드 전용 에이전트 모델에 도전하고 있다. 자체 데모에서는 Gemini 클라우드 플래너와 여러 로컬 Gemma 워커를 함께 사용한다. 더 중요한 이야기는 클라우드를 완전히 대체하는 것이 아니라, 에이전트의 각 부분을 어디에서 실행할지 제어하는 데 있다.

Antigravity SDK 로컬 모델, 에이전트 루프를 기기로 옮기다

Google은 에이전트의 모델 호출, 도구 루프 및 작업 컨텍스트를 개발자가 제어하는 하드웨어로 옮겼다.

Google은 2026년 9월 23일 로컬 모델 지원을 발표했다. 회사는 Antigravity SDK가 이제 여러 모델과 실행 옵션에 걸친 로컬 워크플로를 지원한다고 밝혔다.

이 SDK는 Python을 통해 Google Antigravity의 에이전트 기능을 제공한다. 여기에는 모델 상호작용, 도구, 정책, 워크스페이스, 훅 및 서브에이전트가 포함된다.

개발자들은 이전까지 이러한 워크플로를 원격 추론과 연관 지었다. 새 구성에서는 동일한 머신에 저장되고 실행되는 모델 체크포인트를 대상으로 에이전트를 운영할 수 있다.

Google의 로컬 모델 출시 발표는 Gemma 4 26B A4B를 첫 번째 최적화 모델로 소개한다. LiteRT는 기기에서 사용할 수 있는 가속 하드웨어를 통해 추론을 처리한다.

지원 경로는 에이전트를 .litertlm 체크포인트로 연결하는 LiteRTAgentConfig를 사용한다. SDK는 로컬 머신의 네트워크 인터페이스에서만 사용할 수 있는 서비스인 루프백 서버를 시작한다.

이 로컬 서비스는 Antigravity 에이전트와 모델 런타임 사이에 위치한다. 이를 통해 더 넓은 에이전트 프레임워크는 공개 모델 엔드포인트를 호출하지 않고 체크포인트와 통신할 수 있다.

Google에 따르면, 결과 워크플로는 API 키나 인터넷 연결 없이 실행할 수 있다. 이는 단지 선택된 파일을 로컬에 저장하는 제품과는 의미 있는 차이다.

완전한 오프라인 실행은 모델 입력, 생성된 토큰 및 도구 상호작용이 기기에 남을 수 있음을 뜻한다. 정확한 개인정보 보호 결과는 여전히 개발자가 활성화한 도구와 통합에 따라 달라진다.

웹 검색 서비스를 호출하는 에이전트는 완전히 오프라인인 것이 아니다. 원격 데이터베이스, 분석 시스템 또는 호스팅된 Model Context Protocol 서버에 연결된 에이전트도 마찬가지다.

SDK는 LocalOpenAIAgentConfig를 통해 외부 로컬 서버도 지원한다. 이 경로는 개발자의 머신 또는 사설 네트워크에서 OpenAI 호환 API를 제공하는 소프트웨어에 연결한다.

Google은 Ollama, LM Studio 및 vLLM을 예로 든다. 로컬 AI 사용자는 이미 이러한 서버를 중심으로 모델과 자동화를 구성하고 있기 때문에 이 호환성은 중요하다.

두 경로는 서로 다른 요구를 충족한다. LiteRT는 자체 런타임에 최적화된 Google 관리형 경로를 제공하는 반면, 호환 서버는 팀에 모델 호스팅에 대한 더 많은 제어권을 제공한다.

Google의 로컬 실행 가이드는 두 구성을 모두 문서화한다. 또한 Apple Silicon Metal, Nvidia CUDA 및 자동 감지되는 가속기 백엔드를 지원한다고 확인한다.

이는 에디터 안의 또 다른 모델 선택기 그 이상이다. SDK를 사용하면 개발자는 자체 스크립트, 서비스, 평가 시스템 및 특화된 에이전트 워크플로에 로컬 추론을 배치할 수 있다.

이 프로그래밍 가능성은 이 글의 핵심 긴장을 만든다. 추론을 기기로 옮기면 제어권은 향상되지만, 인프라 책임도 Google에서 사용자에게 이전된다.

오프라인 에이전트, 클라우드 전용 워크플로에 압박을 가하다

이번 출시는 데이터 지역성을 제품 제약이 아닌 아키텍처 선택으로 만들며 클라우드 전용 에이전트 플랫폼에 압박을 가한다.

클라우드 추론은 대부분의 코딩 에이전트에서 여전히 기본값이다. 워크스테이션급 GPU나 긴 모델 다운로드 없이 대규모 모델에 즉시 접근할 수 있게 해준다.

이러한 편리함에는 사용료 외의 비용도 따른다. 소스 코드, 프롬프트, 검색된 문서 및 도구 출력은 원격 처리 환경으로 들어가야 한다.

제공업체 정책은 보관과 학습 사용을 제한할 수 있다. 엔터프라이즈 계약은 더 강력한 통제를 추가할 수 있다. 그럼에도 일부 조직은 민감한 자료를 승인된 머신이나 네트워크 밖으로 보낼 수 없다.

에어갭 개발 환경은 가장 명확한 사례다. 이러한 시스템은 규제 대상, 기밀 또는 상업적으로 민감한 정보를 포함하기 때문에 의도적으로 직접적인 인터넷 접속이 없다.

클라우드 전용 에이전트는 이런 환경에서 정상적으로 작동할 수 없다. 오프라인 Antigravity 에이전트는 모델과 소프트웨어 의존성이 승인된 전송 절차를 통해 전달된다면 작동할 수 있다.

동일한 이점은 출시되지 않은 제품, 보안 보고서, 법률 문서 및 독점 알고리즘을 다루는 개발자에게도 적용된다. 로컬 실행은 이들의 컨텍스트를 받는 시스템 수를 줄인다.

서비스 가용성도 달라진다. 로컬 워크플로는 모델 제공업체에 장애가 발생하거나, 할당량을 변경하거나, 엔드포인트를 철회한다고 해서 멈추지 않는다.

이러한 독립성은 장시간 실행되는 작업에서 중요할 수 있다. 리포지토리를 감사하는 에이전트는 파일을 읽고, 변경을 계획하고, 테스트를 실행하며, 오류를 검토하는 동안 여러 차례 모델 턴을 수행할 수 있다.

지연 시간도 다르게 작동한다. 로컬 추론은 광역 네트워크 지연을 피하지만, 토큰 생성은 전적으로 사용 가능한 하드웨어와 런타임 최적화에 의존한다.

충분한 사양의 워크스테이션은 예측 가능한 응답 시간을 제공할 수 있다. 최소 메모리 권장 사양에 가까운 머신은 특히 동시 워크로드에서 훨씬 느린 경험을 제공할 수 있다.

클라우드 플랫폼에는 분명한 장점이 남아 있다. 로컬 메모리를 소모하지 않고 더 큰 모델, 탄력적 용량, 중앙 집중식 모니터링 및 관리형 업데이트를 제공할 수 있다.

또한 서로 다른 컴퓨터를 사용하는 직원들 사이에서 성능을 표준화할 수 있다. 로컬 우선 접근 방식에서는 기기 사양이 배포 계획의 일부가 된다.

따라서 이번 출시는 로컬 AI와 클라우드 AI 간의 단순한 경쟁을 의미하지 않는다. 두 실행 환경 사이에 의미 있는 선택지를 제공하지 않는 플랫폼에 압박을 가한다.

전략적 이점은 민감도, 복잡성 및 사용 가능한 컴퓨팅 자원에 따라 작업을 라우팅할 수 있는 프레임워크에 있다. Google의 SDK는 이제 이 더 넓은 패턴을 지원한다.

엔터프라이즈에서는 의사결정이 더 세분화된다. 팀은 까다로운 계획 작업에는 호스팅 모델을 사용하면서, 반복적인 파일 분석은 통제된 하드웨어에서 처리할 수 있다.

개인 개발자는 또 다른 형태의 선택권을 얻는다. 모든 작업을 원격 인증이나 사용량 제한에 묶고 싶지 않을 때도 에이전트 워크플로를 계속 사용할 수 있다.

제약은 적합한 하드웨어에 대한 접근성이다. Google은 대표 Gemma 체크포인트에 최소 24GB의 VRAM 또는 통합 메모리를 권장한다.

많은 주류 컴퓨터는 이 기준에 못 미친다. 일부 머신은 기술적으로 충족하더라도 운영 체제, 에디터, 브라우저 및 빌드 도구와 그 메모리를 공유해야 한다.

클라우드 전용 제공업체는 관리형 추론이 여전히 더 접근하기 쉬운 경로라고 합리적으로 주장할 수 있다. 로컬 에이전트는 자율성을 높이지만 컴퓨팅 비용을 없애지는 않는다.

따라서 이 압박은 보안에 민감하고 기술적으로 성숙한 팀에서 가장 강하다. 이러한 구매자는 설정 작업과 하드웨어 요구 사항을 감수할 만큼 로컬 제어를 가치 있게 여길 수 있다.

LiteRT와 Gemma 4가 오프라인 워크플로의 작동 방식을 설명한다

이 메커니즘은 희소 Gemma 모델, 로컬 추론 런타임, 그리고 제어 루프를 가까이에 둘 수 있는 에이전트 프레임워크에 의존한다.

Gemma 4 26B A4B는 전문가 혼합 아키텍처를 사용한다. 이 설계는 모든 파라미터를 활성화하는 대신 각 토큰을 모델의 일부만 거치도록 라우팅한다.

Google은 이 모델의 전체 파라미터 수를 252억 개, 활성 파라미터 수를 38억 개로 제시한다. A4B 표기는 추론 중 약 40억 개의 파라미터가 활성화된다는 의미다.

이 구분은 로컬 실행에서 중요하다. 이 모델은 모든 토큰에 대해 252억 개 파라미터 전체에 걸친 밀집 연산을 요구하지 않고도 더 큰 파라미터 풀을 활용할 수 있다.

그렇다고 체크포인트가 저장 공간이나 메모리에서 40억 개 파라미터만 차지한다는 뜻은 아니다. 라우팅을 위해 전문가 전체 집합이 계속 사용 가능해야 한다.

Google은 LiteRT 형식의 체크포인트 다운로드 용량이 약 16.8GB라고 설명한다. 권장 메모리 24GB는 추론 상태와 다른 프로세스를 위한 추가 여유를 남긴다.

Gemma 4 모델 카드는 26B A4B 모델의 컨텍스트 윈도우가 최대 256,000토큰이라고 명시한다. 텍스트와 이미지 입력도 지원한다.

광고된 대규모 컨텍스트 윈도우가 모든 로컬 머신에서 편안하게 사용할 수 있음을 보장하지는 않는다. 실제 워크로드에서 더 긴 컨텍스트는 메모리 요구량과 처리 시간을 늘린다.

Gemma 4에는 네이티브 함수 호출도 포함돼 있다. 함수 호출을 사용하면 모델은 파일 읽기나 개발자가 정의한 도구 호출과 같은 구조화된 작업을 요청할 수 있다.

이 기능은 에이전트에 필수적이다. 일반적인 챗봇은 응답만 생성하는 반면, 에이전트는 추론, 작업, 관찰 및 수정된 결정을 번갈아 수행한다.

Antigravity는 주변 제어 시스템을 제공한다. 워크스페이스, 사용 가능한 도구, 실행 정책 및 로컬 모델과의 통신을 관리한다.

LiteRT는 추론 계층을 제공한다. Google은 지원되는 하드웨어 백엔드 전반에서 온디바이스 머신러닝을 위해 이 런타임을 설계했다.

LiteRT 모델 가이드는 휴대폰부터 소비자용 GPU와 워크스테이션까지 다양한 기기를 겨냥한 Gemma 변형을 설명한다. 하드웨어 대상은 제품군 내에서 상당히 다르다.

Antigravity 통합을 위해 개발자는 SDK와 litert-lm 패키지를 설치한다. 그런 다음 모델을 LiteRT의 체크포인트 형식으로 가져온다.

에이전트는 구성을 통해 모델 경로를 받는다. 프로그램이 시작되면 SDK는 로컬 모델 서비스를 만들고 생성된 토큰을 애플리케이션으로 다시 스트리밍한다.

이 아키텍처는 통합 방식을 비교적 익숙하게 유지한다. 개발자는 추론 서버와 도구 루프를 독립적으로 구축하는 대신, 여전히 에이전트를 인스턴스화하고 작업을 전송한다.

대안인 OpenAI 호환 구성은 모델 선택지를 넓힌다. 팀은 Antigravity를 기존 Ollama, LM Studio 또는 vLLM 배포 환경으로 연결할 수 있다.

OpenAI 호환 인터페이스는 일반적인 요청 및 응답 형식을 표준화한다. 이는 기반 모델이 OpenAI에서 제공됐다는 의미는 아니다.

이 구분을 통해 Antigravity는 여러 추론 스택 위에 위치할 수 있다. 선택한 로컬 서버나 모델이 바뀌어도 에이전트 프레임워크는 안정적으로 유지될 수 있다.

호환성은 런타임 계층에서의 종속성도 줄인다. 이미 내부 서버에서 vLLM을 사용하는 팀은 모든 워크플로에 LiteRT를 채택할 필요가 없다.

Google이 초기 Gemma 4 경로를 LiteRT 중심으로 최적화했기 때문에 LiteRT는 여전히 특별한 주목을 받는다. 이 조합은 Google이 모델 형식과 실행 런타임 모두를 제어할 수 있게 한다.

이 아키텍처는 완전한 로컬 운영을 넘어선다. 클라우드 모델이 작업을 계획하고 로컬 에이전트가 범위가 제한된 작업을 수행하는 하이브리드 오케스트레이션도 지원한다.

이 하이브리드 옵션은 Google의 출시 시점을 가장 명확하게 설명한다. 로컬 모델은 가장 강력한 호스팅 플래너를 대체하지 않으면서도 유용한 코딩 작업을 처리할 만큼 충분히 발전했다.

Google의 하이브리드 데모가 드러낸 실제 전략

Google의 자체 사례는 로컬 에이전트가 작업 수행 계층으로 자리 잡는 한편, 클라우드 모델은 계획 역할을 유지하고 있음을 보여준다.

이 회사는 Gemini 3.8 Flash를 클라우드 아키텍트로 사용하는 Architect-Builder 패턴을 시연했다. 로컬 Gemma 4 26B 인스턴스는 빌더 역할을 맡았다.

이 시연에서는 auth.py, billing.py, database.py라는 이름의 취약한 Python 모듈 세 개를 시스템에 할당했다. 로컬 워커는 기기에서 감사와 패치를 처리했다.

클라우드 플래너는 더 폭넓은 프로세스를 조율했다. 이 분업은 더 큰 호스팅 모델에 오케스트레이션을 맡기면서도 리포지토리 작업의 상당 부분을 로컬에 유지했다.

이는 하나의 로컬 체크포인트가 모든 클라우드 모델과 맞먹을 수 있다고 주장하는 것보다 더 신뢰할 만한 설계다. 에이전트 작업의 각 단계는 정확도, 프라이버시, 컴퓨팅 측면에서 서로 다른 요구사항을 지닌다.

계획 수립은 넓은 맥락을 아우르는 더 강력한 추론의 이점을 얻는 경우가 많다. 반복적인 검사, 편집, 검증은 더 작은 워커에 분산할 수 있다.

이 모델은 전통적인 컴퓨팅 아키텍처를 닮았다. 중앙화된 시스템이 작업을 스케줄링하고, 특화된 장비가 관련 데이터 가까이에서 작업을 실행한다.

소프트웨어 팀의 실용적인 하이브리드 워크플로는 호스팅 모델이 마이그레이션을 세부 작업으로 분해하는 것에서 시작할 수 있다. 이후 로컬 에이전트가 개별 모듈을 검사하고 수정안을 제안할 수 있다.

민감한 세부 정보가 최소화된 뒤 최종 검토를 클라우드 플래너로 다시 돌릴 수 있다. 또는 추가 원격 호출 없이 사람이 로컬 출력을 검토할 수도 있다.

프라이버시 이점은 이 경계에 달려 있다. 클라우드 플래너가 완전한 소스 파일을 받는다면 로컬 빌더는 원격 데이터 노출을 막지 못한다.

개발자는 어떤 맥락이 경계를 넘어가는지, 어떤 요약이 공유되는지, 어떤 도구가 외부 서비스에 접근할 수 있는지를 결정해야 한다. SDK가 이러한 정책 결정을 자동으로 내릴 수는 없다.

Google의 정책 시스템은 개발자가 제한을 강제할 수 있는 지점을 제공한다. 그러나 관대한 샘플 구성은 검토 없이 프로덕션 기본값이 되어서는 안 된다.

회사의 기본 예제는 로컬 에이전트가 현재 디렉터리의 파일을 검사하도록 한다. 더 고급 예제에서는 에이전트가 모니터링 도구를 만들고 명령을 실행할 수 있다.

이러한 기능은 에이전트를 유용하게 만들지만 위험도 높인다. 실수하거나 조작된 모델은 파일을 수정하고, 프로세스를 호출하거나, 연결된 도구를 통해 정보를 노출할 수 있다.

로컬 추론이 에이전트를 무해하게 만들지는 않는다. 이는 모델 연산이 수행되는 위치를 바꿀 뿐, 생성된 작업에 감독이 필요한지 여부를 바꾸지는 않는다.

하이브리드 실행은 운영 복잡성도 가져온다. 팀은 경계를 넘는 장애를 이해하면서 원격 호출과 로컬 런타임을 모두 모니터링해야 한다.

클라우드 플래너는 결함 있는 작업 분해를 생성할 수 있다. 그러면 로컬 빌더가 그 계획을 일관되게 실행해 하나의 오류를 여러 파일에 퍼뜨릴 수 있다.

동시성도 또 다른 제약을 만든다. 여러 Gemma 4 인스턴스를 실행하려면 단일 권장 구성보다 더 많은 메모리가 필요할 수 있다.

Google은 Antigravity 통합을 위한 독립적이고 워크로드별인 벤치마크를 공개하지 않았다. 따라서 이 발표는 보편적인 성능이 아니라 가용성을 확립한다.

그럼에도 이 데모는 분명한 제품 방향을 시사한다. Google은 로컬 모델을 더 폭넓은 에이전트 시스템 안에서 상호 보완적인 워커로 자리매김하고 있다.

이 전략은 다른 에이전트 프레임워크에도 유사한 라우팅 지원을 압박한다. 고객은 클라우드 전용 답변을 받아들이기 전에 작업을 로컬에 유지할 수 있는지 점점 더 물을 것이다.

이는 Google이 두 시장을 모두 아우를 방법이기도 하다. Gemini 서비스는 까다로운 오케스트레이션에 계속 적합하고, Gemma와 LiteRT는 프라이버시 또는 비용에 민감한 실행을 담당한다.

24 GB 권장은 첫 번째 현실 점검이다

오프라인 운영은 원격 엔드포인트 의존성을 없애지만, 그 대신 하드웨어, 유지보수, 모델 품질 제약이라는 의존성을 가져온다.

Google은 Gemma 4 26B A4B에 최소 24 GB의 VRAM 또는 통합 메모리를 갖춘 장비를 권장한다. 이 표현은 보편적인 보장이 아니라 권장 사항을 뜻한다.

VRAM은 개별 GPU가 사용하는 전용 그래픽 메모리다. 통합 메모리는 Apple Silicon Mac 같은 시스템에서 프로세서와 그래픽 하드웨어가 함께 사용하는 공유 메모리 풀이다.

이 구성은 부하 상황에서 서로 다르게 작동한다. 개별 GPU는 높은 추론 처리량을 제공할 수 있는 반면, 통합 메모리는 CPU와 그래픽 작업 전반에서 유연성을 제공할 수 있다.

표시된 총용량보다 실제 사용 가능한 용량이 더 중요하다. 컨테이너, 브라우저, 빌드, 여러 에이전트를 실행하는 24 GB 장비에는 남는 공간이 거의 없을 수 있다.

16.8 GB 체크포인트 다운로드도 배포 부담을 만든다. 조직은 승인된 장비 전반에 이 아티팩트를 배포, 검증, 업데이트, 저장해야 한다.

모델 출처는 운영상의 관심사가 된다. 팀은 체크포인트의 출처, 변환 방식, 라이선스가 의도한 사용을 허용하는지를 확인해야 한다.

Google 문서에 따르면 Gemma 4는 Apache 2.0 라이선스를 따른다. 외부 파인튜닝 모델과 변환된 체크포인트에는 별도 조건이나 보안 문제가 수반될 수 있다.

모델 품질은 더 큰 불확실성을 제시한다. Google은 코딩 및 에이전트 지향 평가를 포함한 Gemma 4 벤치마크 결과를 공개한다.

이 벤치마크는 정의된 테스트 조건에서 기반 모델의 성능을 설명한다. 개발자의 리포지토리에서 Antigravity가 길고 도구 중심적인 작업을 얼마나 안정적으로 완료하는지는 입증하지 않는다.

에이전트 신뢰성은 단계 전반에 걸쳐 오류를 누적시킨다. 작은 오해가 파일 선택, 명령 실행, 테스트 해석, 최종 패치에 영향을 미칠 수 있다.

로컬 모델은 최신 호스팅 개선 사항을 반영하지 못할 수도 있다. 클라우드 제공업체는 추론 시스템을 중앙에서 업데이트할 수 있지만, 로컬 배포에는 의도적인 업그레이드와 회귀 테스트가 필요하다.

팀은 그 안정성을 선호할 수 있다. 고정된 체크포인트는 더 통제된 환경을 만들고 원격 모델 업데이트 후 예기치 않은 동작 변화를 피할 수 있다.

하지만 고정됐다고 해서 결정론적이라는 뜻은 아니다. 샘플링 설정, 도구 결과, 워크스페이스 상태, 동시성은 여전히 결과를 바꿀 수 있다.

보안 팀은 로컬 서버도 검토해야 한다. 루프백 주소는 노출을 제한하지만, 잘못된 구성은 여전히 포트를 열거나 지나치게 광범위한 파일 시스템 접근 권한을 부여할 수 있다.

OpenAI 호환 서버도 비슷한 수준의 검토가 필요하다. vLLM serving documentation는 로컬 또는 프라이빗 엔드포인트가 일반적인 모델 API를 모방하는 방식을 보여준다.

호환성은 이식성을 높이지만 중요한 차이를 감출 수 있다. 모델마다 도구 호출 형식, 맥락 처리, 안전 동작, 구조화된 출력 지원 방식이 다르다.

따라서 개발자는 프롬프트 응답뿐 아니라 전체 에이전트 루프를 테스트해야 한다. 코드를 잘 작성하는 모델도 도구를 안정적으로 선택하는 데는 어려움을 겪을 수 있다.

Google의 하드웨어 권장은 당장의 대상 사용자를 좁힌다. 고용량 메모리 Nvidia GPU를 갖춘 워크스테이션과 사양이 더 높은 Apple Silicon 시스템이 자연스러운 출발점이다.

더 작은 Gemma 모델은 접근성을 넓힐 수 있지만, Google의 발표는 최적화된 워크플로의 중심으로 26B A4B 체크포인트를 제시한다. 이는 출시의 가장 강력한 주장을 뒷받침하는 버전이다.

“로컬에서 실행된다”와 “내 장비에서 잘 실행된다” 사이의 간극은 여전히 해소되지 않았다. 성능은 하드웨어, 맥락 크기, 도구 사용량, 작업 복잡도에 따라 달라진다.

오프라인 Antigravity 에이전트가 전체 소프트웨어 엔지니어링 작업에서 선도적인 호스팅 시스템과 맞먹는다는 증거도 아직 없다. Google은 그러한 더 광범위한 주장을 하지 않았다.

책임 있는 해석은 더 좁다. Antigravity는 이제 문서화된 설정과 상당한 메모리 권장 사항을 갖추고 의미 있는 에이전트 워크플로를 로컬에서 실행할 수 있다.

성능 동등성이 확보되기 전에도 이 역량은 중요하다. 이는 이전에는 원격 추론이 허용되지 않거나 바람직하지 않았던 팀에 배포 가능한 선택지를 제공한다.

로컬 에이전트가 기본값이 되는지 보여줄 세 가지 신호

다음 시험대는 프라이버시에 민감한 실험과 고용량 메모리 개발자 워크스테이션을 넘어 로컬 실행이 일상화되는지 여부다.

첫 번째 신호는 더 폭넓은 모델 및 하드웨어 지원이다. 개발자에게는 24 GB 권장 사항보다 낮은 사양의 장비를 위한 실용적인 선택지가 필요하다.

더 작은 Gemma 변형 모델은 더 많은 노트북에서 오프라인 에이전트를 사용할 수 있게 할 수 있다. 추가 최적화 체크포인트는 팀이 속도와 메모리 사용량을 대가로 성능을 조절할 수 있게 할 수도 있다.

지원만으로는 충분하지 않다. Google은 Apple Silicon, Nvidia GPU 및 기타 지원 가속기 전반에서 명확한 성능 데이터를 공개해야 한다.

유용한 측정 항목에는 생성 속도, 첫 토큰까지 걸리는 시간, 최대 메모리 사용량, 엔드투엔드 작업 완료율이 포함된다. 에이전트 벤치마크는 도구와 다단계 복구도 다뤄야 한다.

그 결과가 일반적인 하드웨어에서 수용 가능한 성능을 보여준다면 로컬 경로는 전문 기능 이상이 된다. 결과가 약하다면 클라우드 추론이 기본값이라는 인식이 강화될 것이다.

두 번째 신호는 프로덕션 배포의 증거다. 초기 시연은 소프트웨어가 실행된다는 것을 증명하지만, 일상적인 신뢰성을 보여주지는 않는다.

팀은 로컬 에이전트가 대규모 리포지토리, 긴 세션, 동시 워커, 반복 가능한 평가 스위트를 어떻게 처리하는지 보고해야 한다.

보안 중심의 도입은 특히 주목할 만하다. 에어갭 환경의 조직은 워크플로가 내부 통제를 충족한다면 더 느린 성능을 감수할 강한 이유가 있다.

개발자 피드백은 실무적인 마찰도 드러낼 것이다. 설치 실패, 체크포인트 변환 문제, 열 제한, 도구 호출 오류는 아키텍처적 이점을 압도할 수 있다.

세 번째 신호는 경쟁사의 대응이다. 다른 에이전트 프레임워크도 이미 로컬 모델 서버에 연결하지만 통합 수준은 크게 다르다.

중요한 비교는 제품이 Ollama를 옵션으로 나열하는지 여부가 아니다. 로컬 모델이 동일한 도구, 정책, 워크스페이스, 오케스트레이션 기능을 사용할 수 있는지가 핵심이다.

경쟁사는 더 강력한 로컬 라우팅, 엔터프라이즈 호스팅 추론, 또는 원격 및 온디바이스 모델 간 자동 선택으로 대응할 수 있다.

빠른 대응은 실행 위치가 구매 기준이 되고 있다는 Google의 근본적인 판단을 뒷받침할 것이다. 제한적인 대응은 수요가 여전히 애호가층에 집중돼 있음을 시사할 것이다.

Google의 하이브리드 패턴도 면밀한 검토가 필요하다. 이는 실용적인 균형을 제공할 수 있지만, 개발자가 어떤 정보가 클라우드 플래너에 도달하는지 검증할 수 있을 때만 그렇다.

명확한 로그, 정책 제어, 추적 가능한 라우팅은 모델 지원만큼 중요해질 것이다. 기업은 선언된 경계가 모든 에이전트 턴에서 강제된다는 증거를 필요로 한다.

이 출시는 더 절제된 작업 설계도 장려해야 한다. 개발자는 하나의 시스템이 전체 프로젝트를 자율적으로 관리하길 기대하기보다, 범위가 제한된 작업에 로컬 에이전트를 할당할 수 있다.

예로는 프라이빗 문서 분류, 범위가 정해진 모듈 검토, 테스트 생성, 로컬 기술 노트 요약 등이 있다. 각 작업에는 측정 가능한 입력과 출력이 있다.

이 접근법은 민감한 맥락이 사용자 가까이에 유지되는 더 폭넓은 AI 워크플로에 부합한다. 중요한 작업은 여전히 사람의 검토가 통제한다.

Antigravity SDK 로컬 모델은 이제 오프라인 에이전트 실행을 비공식적인 우회책이 아니라 문서화된 Google 워크플로로 만든다. 이번 출시는 품질이나 접근성 문제를 해결하지는 않는다.

하지만 개발자가 에이전트 플랫폼에 요구할 수 있는 것을 바꾼다. 클라우드 접근은 더 이상 자동화의 피할 수 없는 대가일 필요가 없다.

가장 유용한 다음 단계는 구체적인 테스트다. 비공개로 범위가 제한된 작업 하나를 선택해 메모리 사용량과 완료 품질을 기록한 뒤, 로컬 실행과 호스팅 실행을 비교하라.

로컬 에이전트는 하드웨어 투자를 정당화할 만큼 충분한 작업을 수행하면서도 중요한 컨텍스트를 보호하는가? 그 답이 Google이 기본 아키텍처를 만든 것인지, 아니면 가치 있는 예외를 만든 것인지를 결정할 것이다.