토큰의 97.2%를 로컬에서: Google Antigravity SDK가 Gemma 4 로컬 실행과 클라우드 설계를 한 팀으로 묶는다

에이전트가 쓰는 토큰의 97.2%를 자기 컴퓨터에서 처리하면 API 청구서는 어떻게 되나. Google이 9월 23일 Antigravity SDK의 로컬 모델 지원을 발표하면서 내놓은 시연 수치다. 클라우드의 Gemini 3.8 Flash가 계획을 세우고 로컬의 Gemma 4 26B A4B가 실제 작업을 한 보안 점검 시연에서 나왔다.

한 줄 정리

계획은 비싼 클라우드 모델에 맡기고 반복 실행은 로컬 모델이 하는 분업이 SDK 기능으로 들어와, 에이전트 비용의 대부분을 API 밖으로 빼는 길이 열렸다.

한눈에 보기

발표	2026년 9월 23일
로컬 모델	Gemma 4 26B A4B (LiteRT로 실행)
연결 가능한 서버	Ollama, LM Studio, vLLM 등 OpenAI 호환 서버
권장 사양	VRAM 또는 통합 메모리 24GB 초과
시연 결과	보안 점검에서 전체 토큰의 97.2%를 로컬 처리
설치	pip으로 google-antigravity와 litert-lm

설계자와 시공자

시연은 건설 현장처럼 짠다. 클라우드 모델이 설계자로서 큰 그림과 작업 목록을 만들고, 로컬 모델이 시공자로서 파일 하나하나를 읽고 점검한다. 토큰이 많이 드는 쪽은 시공이다. 설계는 한 번이면 되지만 시공은 파일 수만큼 반복된다. 그 반복을 로컬로 돌리니 클라우드로 나가는 토큰이 3% 안쪽으로 줄었다.

같은 에이전트 구성과 도구를 로컬 백엔드를 바꿔 가며 그대로 쓸 수 있다는 점도 짚을 만하다. Ollama나 LM Studio로 돌리던 팀이 오케스트레이션 코드를 새로 짤 필요가 없다.

데이터도 밖으로 안 나간다. 고객 목록, 계약서, 미공개 원고처럼 클라우드에 올리기 꺼려지는 문서를 대량으로 훑는 작업에 어울린다. 완전한 오프라인 동작도 된다.

도입 전에 따져 볼 것

사양 문턱이 있다. 메모리 24GB 초과는 최근 맥북 프로나 게이밍 데스크톱 수준이다. 직원 전원의 노트북이 이를 넘는다고 가정할 수 없다. 팀에 그런 장비가 한두 대뿐이라면 공용 작업 머신 한 대를 두는 편이 낫다.

시연 수치는 보안 점검이라는 한 작업에서 나온 값이다. 카피 작성이나 영상 기획처럼 판단의 질이 결과를 좌우하는 일에서 로컬 모델이 같은 비율을 감당한다는 보장은 없다. 반복적이고 규칙이 분명한 일에 먼저 대 본다.

위시클레이 관점

97.2%라는 숫자는 모델 성능이 아니라 일의 모양을 말해 준다. 에이전트가 쓰는 토큰은 생각하는 데보다 읽고 훑는 데 대부분 쓰인다. 그리고 훑는 일은 똑똑한 모델이 아니어도 된다.

그래서 팀이 던질 질문이 바뀐다. 어떤 모델이 제일 좋은가가 아니라, 우리 업무 흐름에서 "한 번 판단하는 구간"과 "천 번 반복하는 구간"이 어디서 갈리는가다. 월 구독 하나로 전 직원이 같은 모델을 쓰는 방식에서는 이 구분이 필요 없었다. 에이전트가 일하는 순간부터 청구서가 이 구분을 요구한다.

콘텐츠 에이전시라면 후보 100개 헤드라인 중 상위 5개를 고르는 일은 클라우드에, 100개 전부를 브랜드 가이드와 대조하는 일은 로컬에 두는 식으로 가를 수 있다. 구분선을 어디에 긋는지가 곧 그 팀의 운영 노하우가 된다.