Antigravity SDK 로컬 AI 모델 운영법: 코드 유출 없이 에이전트 워크플로우 돌리기

요약: Google Antigravity SDK가 로컬 모델 실행을 지원한다. 초기 지원 조합은 Gemma 4 26B A4B와 LiteRT이며, Ollama, LM Studio, vLLM 같은 OpenAI-compatible 서버도 연결할 수 있다. 발표에서 중요한 숫자는 24GB 이상 VRAM 또는 unified memory 권장, 그리고 예시 워크플로우에서 97.2% 토큰을 로컬에서 처리했다는 점이다. 민감한 코드 감사와 패치 작업을 클라우드에 모두 올리지 않는 설계가 현실적인 선택지가 되고 있다.

로컬 에이전트가 다시 중요해진 이유

AI 개발 도구는 대부분 클라우드 모델을 전제로 발전했다. 성능이 좋고 설정이 쉽기 때문이다. 하지만 회사 코드, 고객 데이터, 보안 취약점 재현 코드, 내부 운영 문서를 다루기 시작하면 문제가 달라진다. “클라우드 모델이 더 똑똑하다”와 “이 데이터를 밖으로 보내도 된다”는 같은 말이 아니다.

Antigravity SDK의 로컬 모델 지원은 이 지점을 겨냥한다. Google은 Gemma 4 26B A4B를 LiteRT로 로컬 실행하는 예시를 제시했고, 비용, 개인정보 보호, 오프라인 복원력, 하이브리드 워크플로우를 장점으로 들었다. 권장 사양은 24GB를 넘는 VRAM 또는 unified memory다.

중요한 변화는 로컬 모델을 단순 챗봇이 아니라 agentic workflow의 실행자(worker)로 쓴다는 점이다. 클라우드 모델은 계획을 짜고, 로컬 모델은 민감한 파일을 읽고 테스트를 돌리고 패치를 만든다. 이렇게 역할을 나누면 성능과 보안을 동시에 관리할 수 있다.

Cloud Architect + On-device Workforce 패턴

Google이 설명한 하이브리드 예시는 Architect-Builder 패턴이다. 클라우드 모델인 Gemini 3.8 Flash가 planner이자 conductor 역할을 맡고, 로컬 Gemma 4 26B 인스턴스들이 실제 코드 감사와 패치 작업을 처리한다.

예시 작업은 auth.py, billing.py, database.py 세 모듈의 취약점을 감사하고 수정하는 흐름이다. 여기서 핵심은 클라우드 모델이 소스 코드를 직접 보지 않는다는 점이다. 파일명과 작업 설명만 보고 전략을 세우며, 발표 예시에서는 클라우드 사용량이 95 tokens에 그쳤다고 설명했다. 전체 토큰의 97.2%, 즉 3,322 tokens는 로컬에서 오프라인으로 처리됐다.

이 숫자는 “로컬 모델이 항상 더 싸다”는 단순 주장보다 더 실용적인 메시지를 준다. 민감한 코드는 로컬에 두고, 클라우드는 고수준 계획에만 쓰는 식으로 토큰 흐름을 설계할 수 있다는 뜻이다.

어떤 업무에 잘 맞는가

로컬 AI 에이전트는 모든 작업에 맞지는 않는다. 특히 대형 모델의 추론력이 필요한 복잡한 제품 전략, 미묘한 요구사항 해석, 긴 문서 기반 의사결정은 클라우드 모델이 나을 수 있다. 반대로 다음 업무는 로컬 실행의 장점이 크다.

첫째, 보안 코드 감사다. 취약점 재현 코드와 내부 인증 로직을 외부 API로 보내기 어려운 팀이라면 로컬 모델이 유리하다. 모델이 완벽하지 않더라도 테스트 실행, 의심 지점 탐색, 패치 후보 생성은 로컬에서 충분히 자동화할 수 있다.

둘째, 반복적인 코드 생성이다. CLI 도구, 모니터링 스크립트, 사내 자동화 스크립트처럼 요구사항이 명확하고 테스트로 검증 가능한 작업은 로컬 모델에 잘 맞는다.

셋째, 오프라인 또는 제한망 환경이다. 금융, 제조, 공공, 국방처럼 외부 네트워크가 제한된 환경에서는 클라우드 API 기반 에이전트 자체가 막힐 수 있다. 로컬 실행은 이런 조직에서 도입 장벽을 낮춘다.

넷째, 토큰이 많이 드는 탐색 작업이다. 대량 로그 읽기, 여러 파일 반복 분석, 테스트 실패 원인 후보 나열처럼 입력이 많고 반복이 많은 작업은 클라우드 비용이 빠르게 커진다.

로컬 모델 도입 전 확인할 현실 조건

로컬 실행에는 비용이 사라지는 대신 다른 비용이 생긴다. 하드웨어, 설치, 모델 파일 관리, 성능 편차, 보안 정책이 필요하다.

먼저 하드웨어를 봐야 한다. 발표 예시는 24GB 이상 VRAM 또는 unified memory를 권장한다. 팀원 노트북이 모두 이 조건을 만족하지 않는다면 개인 로컬 실행보다 사내 GPU workstation 또는 self-hosted runner가 현실적이다.

둘째, 모델 버전과 실행 환경을 고정해야 한다. 같은 프롬프트라도 모델 파일, LiteRT 버전, inference backend가 다르면 결과가 달라질 수 있다. 재현 가능한 워크플로우를 원한다면 requirements.txt, 모델 해시, 실행 옵션을 기록해야 한다.

셋째, 권한 정책을 로컬에서도 적용해야 한다. 로컬이라고 안전한 것은 아니다. 에이전트가 파일을 읽고 쓰고 명령을 실행한다면 allowlist, sandbox, workspace 제한이 필요하다. “내 컴퓨터에서 도는 모델”이 “아무 파일이나 읽어도 되는 모델”은 아니다.

넷째, 결과 품질을 테스트로 닫아야 한다. 로컬 모델은 비용 절감과 privacy에는 좋지만, 복잡한 추론에서 클라우드 frontier model보다 약할 수 있다. 따라서 코드 생성은 lint, unit test, typecheck, integration test와 연결해야 한다.

도입 아키텍처 예시

실무적으로는 다음 구조가 안정적이다.

• Cloud planner: 민감한 내용 없이 파일 목록, 작업 목표, 제한 조건만 보고 계획을 만든다.
• Local worker: 실제 파일을 읽고 수정하며 테스트를 실행한다.
• Policy layer: worker가 접근 가능한 디렉터리와 실행 가능한 명령을 제한한다.
• Test runner: 변경 결과를 자동 검증한다.
• Human approval: 보안, 결제, 권한 관련 변경은 사람이 승인한다.
• Audit log: 어떤 모델이 어떤 파일을 읽고 어떤 명령을 실행했는지 남긴다.

이 구조에서는 클라우드 모델이 소스 코드를 몰라도 된다. 대신 “auth 모듈에서 인증 우회 가능성을 점검하고, 테스트가 실패하면 원인을 로컬 worker에게 다시 넘겨라”처럼 계획만 담당한다. 로컬 worker는 실제 코드를 보고 패치를 만든다.

실행 체크리스트

• 로컬 실행 후보 업무를 보안 감사, 반복 코드 생성, 제한망 작업, 대량 로그 분석 중에서 고른다.
• 팀 하드웨어가 24GB 이상 VRAM 또는 unified memory 조건을 만족하는지 확인한다.
• 모델 파일, LiteRT 또는 backend 버전, requirements를 기록한다.
• 에이전트 workspace를 별도 디렉터리로 제한한다.
• 파일 읽기, 파일 쓰기, shell 실행 권한을 allowlist로 관리한다.
• 클라우드 모델에는 소스 코드 대신 파일명, 목표, 제약 조건만 보낸다.
• 로컬 worker의 결과는 lint, test, typecheck로 검증한다.
• 보안/결제/권한 관련 변경은 자동 merge하지 않는다.
• 토큰 사용량을 cloud/local로 나눠 측정한다.

Antigravity SDK의 로컬 모델 지원은 “클라우드 모델을 대체하자”가 아니다. 더 현실적인 방향은 역할 분리다. 클라우드는 계획과 조율, 로컬은 민감한 파일 처리와 반복 실행을 맡는다. 개발팀이 이 구조를 제대로 잡으면 AI 에이전트를 쓰면서도 코드 유출, 비용 폭증, 네트워크 의존도를 동시에 줄일 수 있다.