Antigravity SDK 로컬 모델 지원: 코드 에이전트가 오프라인으로 가는 이유

구글이 Antigravity SDK에서 로컬 AI 모델 워크플로를 지원한다고 발표했다. 초기 지원 조합은 Google AI Edge의 LiteRT와 Gemma 4 26B A4B다. 발표문에서 권장하는 장비 기준은 24GB 이상의 VRAM 또는 unified memory다.

이 소식은 “로컬에서도 챗봇을 돌릴 수 있다” 수준이 아니다. 코드 에이전트의 일부 작업을 오프라인으로 빼고, 클라우드 모델은 설계와 조율에만 쓰는 구조가 공식 예제로 등장했다는 점이 중요하다. 비용, 프라이버시, 네트워크 안정성 때문에 클라우드 LLM만으로 에이전트를 운영하기 어려웠던 팀에게는 꽤 실용적인 선택지가 생긴 셈이다.

구글 예시는 클라우드 모델 Gemini 3.8 Flash가 설계자 역할을 하고, 로컬 Gemma 4 26B 인스턴스들이 실제 취약점 재현, 패치 작성, 검토, 테스트를 수행하는 구조다. 기록된 데모에서는 클라우드에 95 tokens만 쓰고, 전체 token의 97.2%인 3,322 tokens를 로컬에서 처리했다고 설명한다. 숫자가 크지는 않지만 방향은 분명하다. 민감한 소스코드를 클라우드에 올리지 않고도 에이전트 작업을 구성할 수 있다는 메시지다.

발표의 핵심 요약

Antigravity SDK는 Google Antigravity의 agentic capability를 개발자가 쓸 수 있게 만든 SDK다. 이번 업데이트로 LiteRT 기반 로컬 모델 실행을 지원한다. 설치 흐름은 Python 가상환경 생성, google-antigravity와 litert-lm 설치, Hugging Face repo에서 Gemma 4 26B A4B LiteRT 모델 import, 그리고 LiteRTAgentConfig로 Agent를 실행하는 방식이다.

SDK는 OpenAI-compatible local server도 지원한다. Ollama, LM Studio, vLLM 같은 백엔드를 LocalOpenAIAgentConfig로 붙일 수 있다는 의미다. 모델 실행 환경을 바꿔도 에이전트 orchestration, tools, workflow를 유지하는 방향으로 설계돼 있다.

구글이 강조한 장점은 네 가지다. API 비용과 rate limit 없이 실행할 수 있는 비용 효율성. 코드와 요청을 로컬에 남기는 프라이버시. 인터넷이 불안정해도 실행 가능한 오프라인 회복력. 그리고 로컬 모델과 클라우드 모델을 섞는 hybrid workflow다.

왜 코드 에이전트에서 로컬 실행이 중요해졌나

코드 에이전트는 일반 챗봇보다 데이터 민감도가 높다. 프롬프트에는 파일 경로, 내부 API 이름, 테스트 실패 로그, 고객 데이터가 섞일 수 있다. 전체 레포를 읽는 순간 지식재산과 보안 정보가 함께 움직인다. 클라우드 모델이 성능은 좋지만, 모든 작업을 클라우드로 보내는 설계는 보안팀과 법무팀을 설득하기 어렵다.

로컬 모델은 이 문제의 일부를 줄인다. 예를 들어 코드 검색, 테스트 실패 요약, 간단한 리팩터링, 취약점 재현, 후보 패치 작성은 로컬에서 처리한다. 클라우드 모델은 파일 내용을 보지 않고 task decomposition, 전략 수립, 리뷰 기준 생성만 담당한다. 이렇게 나누면 클라우드 token과 데이터 노출 범위를 동시에 줄일 수 있다.

물론 로컬 모델이 항상 더 안전하다는 뜻은 아니다. 로컬 에이전트가 파일을 수정하고 명령을 실행한다면, 권한 문제는 여전히 남는다. 오히려 사용자가 “로컬이니까 안전하다”고 착각하면 더 위험하다. sandbox, workspace 제한, allowlist, 테스트 게이트는 그대로 필요하다.

24GB 장비 기준이 의미하는 현실

권장 사양이 24GB 이상이라는 점은 중요하다. 개인 노트북 전체 시장을 대상으로 한 기능이라기보다는, 고성능 개발 장비나 Apple Silicon 상위 모델, 워크스테이션, 사내 AI 박스에 가까운 타깃이다. 모든 개발자가 당장 로컬 26B 모델을 돌릴 수 있다는 말은 아니다.

그래도 실무 적용 가능성은 있다. 팀 전체가 같은 고사양 장비를 가질 필요는 없다. CI 옆에 로컬 inference 서버를 두거나, 보안 구역 내부에 shared workstation을 두고 에이전트 job을 돌릴 수 있다. 특히 금융, 헬스케어, 엔터프라이즈 SaaS처럼 소스코드 반출 정책이 강한 조직에서는 “클라우드 LLM 금지”와 “AI 도입 필요” 사이의 절충안이 된다.

성능 기대치는 낮춰야 한다. 로컬 모델은 대형 클라우드 모델보다 추론이 느리고, 어려운 설계 판단에서 약할 수 있다. 따라서 처음부터 전체 기능 구현을 맡기기보다 반복적이고 검증 가능한 작업에 배치하는 것이 낫다. 예를 들어 lint fix, 테스트 보강, migration script 초안, boilerplate 생성, 보안 패턴 점검이 좋은 시작점이다.

하이브리드 에이전트 아키텍처

실무에서 쓸 만한 구조는 세 계층으로 나눌 수 있다. 첫째, 클라우드 planner다. 이 계층은 사용자 요청을 작은 작업으로 쪼개고, 어떤 파일군을 봐야 하는지 정한다. 가능하면 실제 소스 내용 대신 파일명, 테스트명, 오류 유형 같은 최소 정보만 본다.

둘째, 로컬 worker다. 이 계층은 workspace 안에서 파일을 읽고, 수정하고, 테스트를 돌린다. worker는 모델 성능보다 권한 통제가 중요하다. 작업 디렉터리 제한, 네트워크 차단, 명령 allowlist, 변경 diff 검토가 들어가야 한다.

셋째, deterministic gate다. 에이전트가 “성공했다”고 말하는 것은 충분하지 않다. 테스트, 타입체크, 정적분석, 보안 스캔 같은 검증이 결과를 판단해야 한다. 최근 에이전트 실패 사례에서 자주 보이는 문제는 실패했는데도 정상 종료처럼 보이는 것이다. 그래서 최종 판단은 모델 텍스트가 아니라 실행 결과로 해야 한다.

어떤 작업을 로컬 모델에 맡길까

로컬 모델에 적합한 작업은 세 조건을 만족한다. 입력 데이터가 민감하다. 결과를 자동으로 검증할 수 있다. 실패해도 롤백이 쉽다. 이 세 가지가 맞으면 로컬 에이전트의 약점보다 장점이 커진다.

예를 들어 unit test 추가는 적합하다. 모델이 테스트를 작성하고, 실제 테스트 러너가 통과 여부를 검증한다. 문서화도 적합하다. 내부 코드 구조를 읽어 README나 API 문서를 갱신할 수 있다. 단, 외부 공개 문서라면 사람 검토가 필요하다.

반대로 제품 아키텍처 결정, 보안 정책 변경, 결제 로직 수정은 처음부터 맡기면 위험하다. 이런 작업은 클라우드 고성능 모델의 reasoning이 필요할 수 있고, 사람 승인도 필요하다. 로컬 모델은 후보안 작성이나 영향 범위 조사 정도에 쓰는 편이 안전하다.

비용 계산은 token만 보면 안 된다

구글 데모의 97.2% 로컬 token은 매력적이다. 하지만 비용 계산에는 장비 비용, 전력, 운영자 시간, 모델 다운로드와 업데이트, 보안 패치, 장애 대응이 들어간다. API token 비용이 줄어도 전체 비용이 줄지 않을 수 있다.

따라서 의사결정 기준은 “싸냐”가 아니라 “민감한 작업을 충분히 통제하면서 반복 처리할 수 있냐”가 되어야 한다. 로컬 실행은 비용 절감 도구이기도 하지만, 더 본질적으로는 데이터 경계와 운영 통제를 위한 도구다.

작은 팀이라면 먼저 클라우드 모델로 생산성을 확인하고, 민감도가 높은 job만 로컬로 분리하는 편이 낫다. 대기업이라면 반대로 보안 구역 내부 로컬 모델을 먼저 만들고, 외부 클라우드 호출을 예외 처리로 둘 수 있다.

실행 체크리스트

• 로컬 에이전트 적용 대상을 반복적이고 검증 가능한 작업으로 제한한다.
• 24GB 이상 VRAM 또는 unified memory 장비를 기준으로 성능을 테스트한다.
• 클라우드 planner에는 소스코드 본문 대신 최소 메타데이터만 전달한다.
• 로컬 worker의 workspace, 명령, 네트워크 권한을 제한한다.
• 모델 출력이 아니라 테스트, 타입체크, 정적분석 결과로 성공 여부를 판단한다.
• 코드 수정 전후 diff를 저장하고 사람이 확인할 수 있게 한다.
• API token 절감액과 장비 운영 비용을 함께 계산한다.
• 보안팀에는 “로컬이라 안전함”이 아니라 “데이터 경계와 권한 통제 방식”을 설명한다.
• 처음에는 문서화, 테스트 작성, lint fix부터 적용한다.
• 공개 발표 수치와 내부 워크로드 성능을 분리해서 평가한다.