로컬 AI 코딩 에이전트, Antigravity SDK + Gemma 4로 오프라인에서 돌려봤습니다

왜 로컬 에이전트인가 — 코드 유출 없이 돌리는 코딩 어시스턴트

AI 코딩 에이전트를 실무에 붙이다 보면 결국 같은 벽에 부딪혀요. "이 코드, 외부 API로 다 보내도 되나?" 하는 문제죠. 사내 레포지토리, 고객사 소스, 아직 공개 안 된 프로토타입… 이걸 클라우드 모델에 그대로 던지는 건 보안팀 입장에서 눈이 뒤집히는 일입니다.

그래서 최근 흐름은 명확해요. 추론(inference)은 로컬에서, 오케스트레이션은 그대로 — 이 구조가 실무에서 가장 현실적인 타협점입니다.

Antigravity SDK가 이번에 로컬 모델 실행을 정식 지원하면서, Gemma 4 26B A4B 모델을 Google AI Edge의 LiteRT 런타임으로 완전 오프라인에서 돌릴 수 있게 됐어요. 로컬 GPU와 RAM을 활용해서 에이전트 어시스턴스를 그대로 쓸 수 있다는 뜻입니다.

로컬 실행의 장점은 크게 세 가지로 정리됩니다.

• 데이터 프라이버시: 코드와 프롬프트가 외부로 나가지 않아요.
• 토큰 비용 0: 반복적인 파일 탐색, 테스트 실행 루프에서 비용이 안 나갑니다.
• 오프라인 동작: 비행기 안, 폐쇄망 환경에서도 에이전트가 살아있어요.

이 글은 설치 → 첫 에이전트 실행 → 샌드박스 워크스페이스 구성 → 하이브리드 아키텍처까지 순서대로 다룹니다. 클라우드 모델을 완전히 버리라는 얘기가 아니라, 어디까지 로컬로 내려야 안전한지에 대한 실무 가이드라고 보시면 됩니다.

설치부터 첫 실행까지 — 5분이면 됩니다

1단계: 가상환경 + 패키지 설치

권장 사양은 VRAM 24GB 이상 또는 통합 메모리 24GB 이상이에요. 이 이하에서는 모델 로딩이 실패하거나 극단적으로 느려질 수 있습니다.

python3 -m venv .venv
source .venv/bin/activate
pip install google-antigravity litert-lm

# HuggingFace에서 Gemma 4 26B A4B (GPU용) 모델을 로컬로 가져옵니다
litert-lm import \
  --from-huggingface-repo=litert-community/gemma-4-26B-A4B-it-litert-lm \
  gemma-4-26B-A4B-it-gpu.litertlm \
  gemma4-26b

2단계: 첫 에이전트 스크립트

같은 디렉터리에 agy_sample.py 파일을 만들어 주세요.

import asyncio
import os
from google.antigravity import Agent, LiteRTAgentConfig
from google.antigravity.hooks import policy

# 위에서 litert-lm import 로 받아둔 로컬 모델 경로를 지정합니다
MODEL_PATH = os.path.expanduser("~/.litert-lm/models/gemma4-26b/model.litertlm")

async def main():
    print(f"로컬 LiteRT 모델 사용 중: {MODEL_PATH}. 첫 추론은 몇 분 걸릴 수 있어요.")
    config = LiteRTAgentConfig(model_path=MODEL_PATH).lightweight()

    async with Agent(config) as agent:
        response = await agent.chat("현재 디렉터리에 어떤 파일이 있어?")
        async for token in response:
            print(token, end="", flush=True)

if __name__ == "__main__":
    asyncio.run(main())

여기서 주의할 점 하나. .lightweight()는 도구(tool) 세트를 최소한으로 줄인 모드예요. 처음엔 이걸로 감을 잡고, 파일 쓰기나 셸 실행이 필요해지면 다음 단계로 넘어가면 됩니다.

3단계: 워크스페이스 + 정책(policy) 붙이기

에이전트가 파일을 쓰거나 명령을 실행하게 하려면 워크스페이스와 정책을 반드시 명시해야 해요. 이게 이 SDK의 안전장치 핵심입니다.

import asyncio
import os
from google.antigravity import Agent, LiteRTAgentConfig
from google.antigravity.hooks import policy

PROMPT = (
    "psutil과 rich 라이브러리로 실시간 갱신되는 터미널 대시보드를 만들어줘. "
    "CPU 사용량, 메모리 소비량, 메모리 상위 5개 프로세스 테이블을 보여줘야 해. "
    "스크립트는 'monitor.py'로 저장하고 'requirements.txt'도 생성해줘. 동작 테스트까지 해줘."
)

MODEL_PATH = os.path.expanduser("~/.litert-lm/models/gemma4-26b/model.litertlm")

# 에이전트가 파일을 쓸 수 있는 워크스페이스를 명시적으로 지정
WORKING_DIR = os.path.expanduser("~/agy-test")
os.makedirs(WORKING_DIR, exist_ok=True)
os.chdir(WORKING_DIR)

async def main():
    print(f"로컬 LiteRT 모델 사용 중: {MODEL_PATH}. 첫 추론은 몇 분 걸릴 수 있어요.")
    config = LiteRTAgentConfig(
        model_path=MODEL_PATH,
        workspaces=[WORKING_DIR],       # 이 디렉터리 밖으로는 못 나갑니다
        policies=[policy.allow_all()],  # 실무에선 allow_all() 대신 화이트리스트로 좁히세요
    ).lightweight()

    async with Agent(config) as agent:
        response = await agent.chat(PROMPT)
        async for token in response:
            print(token, end="", flush=True)

if __name__ == "__main__":
    asyncio.run(main())

workspaces와 policies가 이 SDK의 샌드박싱 축이에요. 워크스페이스는 파일 시스템 경계를, 정책은 도구 실행 권한을 제어합니다. policy.allow_all()은 데모용입니다. 실무에서는 반드시 허용할 명령/경로만 화이트리스트로 지정하세요. 이 부분은 AI 코딩 에이전트 샌드박싱과 실행 위험 관리 실무 가이드에서 더 깊게 다뤘습니다.

4단계: 다른 로컬 백엔드로 갈아타기

Ollama, LM Studio, vLLM처럼 OpenAI 호환 서버라면 LocalOpenAIAgentConfig로 그대로 붙일 수 있어요. 에이전트 오케스트레이션, 도구, 워크플로우 코드는 손댈 필요 없이 백엔드만 교체됩니다. 로컬 추론 환경을 벤치마킹할 때 특히 편하죠.

하이브리드 패턴 — 클라우드 플래너 + 로컬 워커

로컬 모델만으로 전부 처리하려고 하면 금방 한계에 부딪혀요. 26B급 모델이라도 복잡한 계획 수립(planning)에서는 클라우드 대형 모델에 밀립니다. 그래서 실무에서 가장 효율이 좋은 건 Architect-Builder 패턴이에요.

• Architect (클라우드): Gemini 3.8 Flash 같은 모델이 플래너 겸 지휘자 역할. 작업을 분해하고 우선순위를 정합니다.
• Builder (로컬): Gemma 4 26B 인스턴스 여러 개가 실제 코드 생성, 패치, 테스트를 온디바이스에서 처리합니다.

예를 들어 취약한 모듈 3개(auth.py, billing.py, database.py)를 감사(audit)하고 패치하는 작업을 이 패턴으로 돌리면, 민감한 소스는 로컬을 벗어나지 않고 계획 수립에만 클라우드 토큰을 씁니다. 토큰 효율이 극적으로 좋아지는 이유가 여기 있어요.

이 기술의 한계와 주의사항

솔직히 말하면, 만능은 아닙니다.

1. VRAM 24GB 벽: 이 이하 환경에서는 실사용이 어렵습니다. 맥 스튜디오나 RTX 4090급이 사실상 최소선이에요.
2. 첫 추론 지연: 모델 로딩 + 첫 토큰까지 수 분이 걸릴 수 있습니다. CI에 넣기엔 부적합해요.
3. 정책 설정 실수 = 사고: allow_all()을 그대로 프로덕션에 두면 에이전트가 워크스페이스 밖 파일을 건드릴 수 있습니다. 반드시 화이트리스트로 좁히세요.
4. 모델 성능 편차: 26B는 코드 생성은 잘하지만, 복잡한 리팩터링이나 대규모 컨텍스트 유지에서는 여전히 클라우드 대형 모델이 우세합니다.

네트워크 계층의 유사한 실시간 진단 이슈는 PMTUD 블랙홀, 이제 Cloudflare One이 실시간으로 해결합니다에서 다룬 적이 있는데, 로컬 에이전트도 결국 "경로(path)를 얼마나 정확히 아느냐"의 문제라는 점에서 결이 비슷합니다.

한국 개발 생태계에서의 적용 맥락

국내 SI/금융권 환경에서는 이 패턴이 특히 유효해요. 외부 API 호출이 망분리 정책에 걸리는 곳이 많아서, 로컬 추론 + 클라우드 플래너 하이브리드는 "보안팀 설득용 카드"로 쓰기 좋습니다. 다만 사내 GPU 인프라가 없다면 결국 개인 워크스테이션에 의존해야 하니, 팀 단위 도입 전에 GPU 자원 실태 조사부터 하시길 권합니다.

정리 — 지금 당장 해볼 것

1. 로컬 환경 체크: VRAM 24GB 이상인지 확인. 안 되면 Ollama + 소형 모델로 먼저 감을 잡으세요.
2. lightweight() 모드로 시작: 도구 권한을 최소로 두고 에이전트 루프가 어떻게 동작하는지 관찰.
3. 워크스페이스 + 정책 명시: 파일 쓰기가 필요해지는 순간부터 반드시 경계를 그으세요.
4. 하이브리드로 확장: 계획은 클라우드, 실행은 로컬. 토큰 비용과 프라이버시를 동시에 잡는 실무 패턴입니다.

다음 단계 학습 방향

• LiteRT 최적화: 양자화(quantization), KV 캐시 튜닝으로 추론 속도 개선.
• 정책 훅 설계: policy 모듈을 커스터마이징해서 명령 단위 화이트리스트 구현.
• 멀티 에이전트 오케스트레이션: 로컬 Gemma 인스턴스 여러 개를 병렬로 돌려 빌더 스웜 구성.

에이전트 코딩은 이미 "써볼까 말까"의 단계를 지났어요. 이제는 어디까지 로컬로 내리고, 어디서 클라우드를 부를지를 설계하는 단계입니다. 이 글이 그 첫 삽이 되면 좋겠네요.

함께 보면 좋은 글

• AI 코딩 에이전트 샌드박싱과 실행 위험 관리 실무 가이드
• PMTUD 블랙홀, 이제 Cloudflare One이 실시간으로 해결합니다

근거자료: Introducing support for local AI models in the Antigravity SDK