Antigravity SDK 로컬 모델 지원: Gemma 4 26B로 오프라인 에이전트 워크플로우를 돌리는 시대

Google이 Antigravity SDK에 로컬 AI 모델 워크플로우 지원을 추가했다. 초기 지원 조합은 Google AI Edge의 LiteRT와 Gemma 4 26B A4B다. 발표에서 Google은 로컬 GPU와 RAM을 활용해 에이전트 작업을 오프라인으로 실행할 수 있다고 설명했다.

이 소식이 중요한 이유는 “로컬 LLM을 실행할 수 있다”가 아니다. 이미 Ollama, LM Studio, vLLM 같은 선택지는 있었다. 이번 변화의 핵심은 에이전트 오케스트레이션 계층에서 로컬 모델을 정식 실행 경로로 다룬다는 점이다. 클라우드 모델은 설계와 분해를 맡고, 로컬 모델은 코드 감사, 패치 생성, 테스트 반복 같은 작업을 맡는 하이브리드 패턴이 구체화되고 있다.

개발자 검색 의도는 명확하다. “로컬 AI 에이전트”, “Gemma 4 26B LiteRT”, “Antigravity SDK 사용법”, “코드 유출 없는 AI 개발” 같은 키워드가 붙는다. 특히 기업 개발팀은 비용보다 코드 반출 여부와 감사 가능성을 더 크게 본다.

로컬 에이전트가 해결하려는 문제

클라우드 LLM 기반 코딩 도구는 강력하지만 세 가지 부담이 있다. 첫째, 코드와 로그가 외부 API로 나갈 수 있다. 둘째, 대량 작업에서는 토큰 비용과 rate limit이 누적된다. 셋째, 네트워크가 불안정하거나 폐쇄망에 가까운 환경에서는 작업 흐름이 끊긴다.

로컬 모델은 이 부담을 줄인다. Google 발표는 비용 효율, 프라이버시, 오프라인 복원력, 하이브리드 워크플로우를 장점으로 제시했다. 특히 “소스코드를 업로드하지 않는” 패턴이 눈에 띈다. 예시에서는 클라우드 Gemini 3.8 Flash가 파일명과 작업 설명만 보고 전략을 세우고, 실제 취약점 재현·패치 작성·회귀 테스트는 로컬 Gemma 4 26B 인스턴스들이 처리한다.

Google이 공개한 데모 수치도 의미가 있다. 클라우드 모델은 95 cloud tokens만 사용했고, 전체 토큰의 97.2%인 3,322 tokens가 로컬에서 처리됐다고 설명한다. 숫자 자체보다 구조가 중요하다. 민감한 코드는 로컬에 두고, 클라우드는 고수준 계획만 맡기는 방식이다.

하드웨어 요구사항은 현실적으로 봐야 한다

발표에는 권장 환경으로 24GB 초과 VRAM 또는 unified memory가 언급된다. 이 조건은 가볍지 않다. 일반 사무용 노트북이나 CI 러너에서 바로 돌리기 어렵다. 로컬 에이전트가 모든 개발자에게 즉시 보급된다는 뜻은 아니다.

하지만 팀 단위로 보면 이야기가 달라진다. 보안이 중요한 조직은 고사양 워크스테이션, 사내 GPU 서버, M 시리즈 고메모리 맥, 전용 빌드 머신을 이미 운영한다. 이런 환경에서는 로컬 모델이 “개인 생산성 도구”가 아니라 “코드가 외부로 나가지 않는 자동화 노드”가 될 수 있다.

실무 도입 시에는 세 가지 기준을 봐야 한다.

• 개발자 개인 장비에서 돌릴 것인가, 팀 공용 노드에서 돌릴 것인가
• 민감 코드 전체를 로컬 모델에 맡길 것인가, 특정 디렉터리만 허용할 것인가
• 로컬 추론 시간이 개발자 대기 시간을 줄이는가, 늘리는가

로컬이라는 말이 항상 빠르다는 뜻은 아니다. 작은 작업은 클라우드 모델이 더 빠를 수 있다. 로컬 모델은 비용과 보안 때문에 선택하는 경우가 많다.

OpenAI 호환 서버 지원이 주는 의미

Antigravity SDK는 LiteRT뿐 아니라 Ollama, LM Studio, vLLM 같은 OpenAI 호환 서버도 LocalOpenAIAgentConfig로 연결할 수 있다고 안내한다. 이 점은 중요하다. 특정 모델 하나에 묶이는 대신, 오케스트레이션과 추론 백엔드를 분리할 수 있기 때문이다.

팀은 같은 에이전트 워크플로우를 유지하면서 로컬 백엔드를 바꿔 실험할 수 있다. 예를 들어 개발자 노트북에서는 작은 Qwen 계열 모델을 쓰고, 사내 GPU 서버에서는 Gemma 4 26B를 쓰고, 보안성이 낮은 일반 작업은 클라우드 모델로 보내는 식이다.

이런 구조에서는 모델 선택보다 라우팅 정책이 중요하다. 민감 파일, 대형 diff, 테스트 실행, 문서 요약, 이슈 정리 같은 작업을 어느 백엔드로 보낼지 정해야 한다. 정책이 없으면 개발자는 매번 감으로 모델을 고르게 되고, 그 결과 비용과 보안 기준이 흔들린다.

로컬 에이전트에도 권한 정책이 필요하다

로컬에서 돈다고 안전한 것은 아니다. 오히려 로컬 에이전트는 파일 시스템, 쉘, 테스트 환경에 더 가까이 붙는다. 잘못된 권한을 주면 민감 파일을 읽거나, 불필요한 명령을 실행하거나, 작업 디렉터리 밖을 수정할 수 있다. Google 예제에도 workspace와 policy 설정이 등장한다.

실무에서는 다음 경계를 세워야 한다.

1. 작업 디렉터리를 명시한다.
2. 읽기 가능한 경로와 쓰기 가능한 경로를 분리한다.
3. 네트워크 접근을 기본 차단하고 필요한 경우만 허용한다.
4. 테스트 명령은 allowlist로 제한한다.
5. 결과 diff는 사람이 리뷰하기 전 자동 커밋하지 않는다.
6. 로컬 모델 로그에 secrets가 남지 않도록 필터링한다.

로컬 모델은 데이터 반출 위험을 줄이지만, 로컬 권한 남용 위험을 새로 만든다. 두 위험을 바꿔 끼는 것에 가깝다.

개발팀 적용 체크리스트

• 24GB 이상 VRAM 또는 unified memory 장비가 있는지 확인한다.
• 민감 코드 작업을 클라우드 모델에서 로컬 모델로 옮길 후보를 정한다.
• 클라우드 모델은 계획, 로컬 모델은 실행이라는 하이브리드 패턴을 실험한다.
• workspace 경로와 파일 권한을 에이전트 설정에 명시한다.
• 로컬 모델 실행 로그와 diff를 리뷰 가능한 형태로 남긴다.
• OpenAI 호환 로컬 서버를 붙여 백엔드 교체 가능성을 테스트한다.
• 로컬 실행이 비용을 줄이는지, 대기 시간을 늘리는지 실제 작업으로 측정한다.
• “오프라인 가능”과 “운영 가능”을 구분해 파일럿부터 시작한다.

출처: Google Developers Blog, “Introducing Support for Local AI Models in the Antigravity SDK”, 2026년 9월 23일.