로컬 AI 에이전트가 다시 중요해졌다 — Antigravity SDK와 Gemma 4로 보는 하이브리드 자동화

결론부터

Google이 2026년 9월 23일 Antigravity SDK에서 로컬 모델 워크플로를 지원한다고 발표했다.Google 공식 처음 지원 조합은 Gemma 4 26B A4B와 Google AI Edge LiteRT다. 한 줄로 요약하면 “AI 에이전트를 클라우드 API로만 돌리지 말고, 코드가 있는 내 컴퓨터에서도 돌릴 수 있게 했다”는 소식이다.

지금 읽어야 하는 이유는 단순히 로컬 모델이 하나 더 붙었기 때문이 아니다. 최근 에이전트 도입의 고민은 모델 성능보다 코드를 어디로 보낼 것인가, 반복 테스트 비용을 누가 낼 것인가, 인터넷이 불안정해도 작업을 이어갈 수 있는가로 옮겨가고 있다. 로컬 실행은 이 세 질문에 다시 실무적인 답을 준다.

기준 시점은 2026년 9월 24일이다. 이 글은 Google Developers Blog의 Antigravity SDK 발표, Google AI Edge LiteRT 흐름, 그리고 최근 Google의 Agent Anomaly Detection·zero-trust agents 글을 함께 보고 정리했다.Google 공식Google 공식

오늘 적용할 1가지는 간단하다. 에이전트 자동화 후보를 하나 고르고, “클라우드가 봐도 되는 정보”와 “로컬에 남겨야 하는 정보”를 두 열로 나눠 적어보자. 그 표가 없으면 도구 선택이 아니라 감으로 운영하게 된다.

Antigravity SDK의 이번 변화는 무엇인가

Google 설명에 따르면 Antigravity SDK는 Google Antigravity를 구동하는 agentic capabilities를 개발자가 쓸 수 있게 하는 SDK다. 이번 업데이트는 그 SDK가 로컬 모델 실행을 지원하도록 확장됐다는 점이 핵심이다. 초기 예시는 Gemma 4 26B A4B를 LiteRT로 내려받고, google-antigravity와 litert-lm을 설치해 로컬 모델 경로를 지정한 뒤 에이전트와 대화하는 방식이다.Google 공식

공식 예시는 이렇게 출발한다.

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

litert-lm import \
  --from-huggingface-repo=litert-community/gemma-4-26B-A4B-it-litert-lm \
  gemma-4-26B-A4B-it-gpu.litertlm \
  gemma4-26b

그 다음 LiteRTAgentConfig에 모델 경로를 넘겨 로컬 에이전트를 만든다. Google은 권장 환경으로 24GB를 넘는 VRAM 또는 unified memory를 언급한다.Google 공식 이 숫자가 중요하다. “로컬 AI”라는 말은 가볍게 들리지만, 실무에서는 메모리와 추론 시간이 바로 운영 조건이 된다.

쉽게 비유하면 이렇다. 클라우드 모델은 대형 공용 공방이다. 장비가 좋고 빠르지만, 작업물을 밖으로 가져가야 한다. 로컬 모델은 내 책상 위 공구함이다. 공구가 더 작고 느릴 수 있지만, 문서를 밖에 꺼내지 않아도 된다. 문제는 모든 집 책상에 산업용 절단기가 올라가지는 않는다는 점이다.

왜 다시 로컬인가: 프라이버시, 비용, 오프라인, 하이브리드

Google은 로컬 실행의 장점으로 비용 효율, 프라이버시, 오프라인 회복력, 하이브리드 워크플로를 든다.Google 공식 네 단어 모두 익숙하지만, 에이전트에서는 무게가 다르다.

챗봇에게 질문 하나를 보내는 일과 에이전트가 저장소 전체를 훑고, 테스트를 돌리고, 실패 로그를 다시 읽고, 패치를 여러 번 고치는 일은 다르다. 후자는 토큰과 파일 접근이 계속 반복된다. 한 번의 답변이 아니라 작은 작업자가 몇 시간 동안 책상 위 자료를 뒤적이는 그림에 가깝다.

로컬 에이전트가 특히 어울리는 장면은 이런 쪽이다.

장면	로컬 실행이 주는 이점	조심할 점
비공개 코드 감사	원문 코드가 외부 API로 나가지 않는다	모델 품질이 낮으면 리뷰 누락이 생긴다
반복 테스트·패치	토큰 비용과 rate limit 압박이 줄어든다	느린 추론을 견딜 작은 작업 단위가 필요하다
사내망·오프라인 환경	네트워크가 불안정해도 일부 작업이 돈다	패키지 설치·문서 검색은 미리 준비해야 한다
대량 파일 분류	모든 파일 내용을 클라우드에 보내지 않아도 된다	민감 정보 탐지와 로그 보관을 별도로 설계해야 한다
초안 검토·정리	낮은 위험 작업을 싸게 반복할 수 있다	최종 판단은 더 강한 모델이나 사람이 봐야 한다

반대로 “로컬이면 무조건 안전하다”는 생각은 위험하다. 에이전트가 로컬에서 파일을 읽고 명령을 실행한다면, 잘못된 작업도 로컬에서 더 빠르게 일어날 수 있다. 권한을 넓게 주면 실수도 넓게 퍼진다. 집 안에서 작업한다고 칼이 무뎌지는 것은 아니다.

하이브리드 패턴: 클라우드는 설계자, 로컬은 작업자

이번 발표에서 가장 재미있는 부분은 Google이 제시한 하이브리드 데모다. Google은 Gemini 3.8 Flash가 클라우드 architect로 전략을 세우고, 로컬 Gemma 4 26B 인스턴스들이 실제 감사·패치·테스트 루프를 수행하는 예를 들었다. 특히 취약한 세 모듈을 감사하고 고치는 시나리오에서, 소스 코드는 업로드하지 않고 파일명과 작업 설명만으로 전략을 세웠으며, 기록된 실행에서 전체 토큰의 97.2%, 3,322 tokens가 로컬·오프라인으로 처리됐다고 설명한다.Google 공식

이 구조가 실용적인 이유는 역할 분리가 명확하기 때문이다.

역할	맡기기 좋은 일	보내도 되는 정보
클라우드 architect	작업 분해, 순서 결정, 검토 관점 제안	파일명, 모듈 설명, 추상화된 에러 유형
로컬 builder	실제 코드 읽기, 테스트 실행, 패치 후보 생성	원문 코드, 로컬 로그, 테스트 결과
사람 reviewer	권한 승인, 위험 판단, 배포 결정	요약, diff, 재현 방법, 남은 위험

여기서 핵심은 “로컬 모델이 클라우드 모델보다 낫다”가 아니다. 더 정확한 문장은 이렇다.

민감한 반복 작업은 로컬에 남기고, 높은 수준의 계획이나 어려운 판단만 클라우드에 올리는 구성이 가능해졌다.

이 관점으로 보면 로컬 에이전트는 클라우드 모델의 대체재가 아니라 비용과 권한을 조절하는 기어다. 자동차에 고속도로 기어만 있으면 골목길에서 불편하다. 반대로 저속 기어만 있으면 멀리 못 간다.

로컬 에이전트를 바로 붙이기 전 체크리스트

Antigravity SDK 예시는 매력적이지만, 바로 회사 저장소 루트에서 allow_all() 같은 정책으로 돌리는 것은 좋은 출발이 아니다. 로컬 에이전트도 실행 환경과 권한이 필요하다. Google의 zero-trust agents 글도 최근 에이전트 보안의 무게가 코드 정적 검사에서 런타임 의도와 행동 감시로 옮겨간다고 설명한다.Google 공식

처음 실험한다면 아래 순서가 안전하다.

1. 복사본 저장소에서 시작한다. 원본 repo가 아니라 throwaway branch 또는 복제 디렉터리에서 돌린다.
2. 워크스페이스를 좁힌다. 전체 홈 디렉터리 대신 특정 폴더만 열어준다.
3. 비밀값을 제거한다. .env, credentials, production dump는 제외한다.
4. 명령 allowlist를 둔다. 읽기, 테스트, 포맷 정도부터 허용하고 배포·삭제·네트워크 명령은 막는다.
5. 작업 단위를 작게 자른다. “프로젝트 개선” 대신 “이 테스트 하나를 재현하고 원인을 설명”처럼 시작한다.
6. 결과는 diff와 로그로 받는다. 자연어 요약만 믿지 않는다.
7. 최종 적용은 사람이 한다. 로컬에서 통과한 패치도 main 반영은 별도 게이트를 둔다.

하드웨어도 체크해야 한다. Google은 예시에서 24GB 초과 VRAM 또는 unified memory를 권장한다.Google 공식 그러니 실무 판단은 “돌아가나?”보다 “내가 맡길 작업의 크기와 속도에 맞나?”에 가깝다. 느린 로컬 모델에게 거대한 리팩터링을 맡기면, 사람도 모델도 지친다. 대신 작은 취약점 재현, 테스트 케이스 생성, 문서 초안, 파일별 정리처럼 경계가 분명한 일부터 맞다.

로컬 모델이 잘하는 일과 아직 약한 일

로컬 에이전트가 특히 잘 맞는 일은 반복이 많고, 민감하고, 정답 확인이 가능한 작업이다. 테스트를 돌려볼 수 있는 코드 작업이 대표적이다. 결과가 맞는지 사람이 눈으로만 판단하지 않아도 되기 때문이다.

작업	로컬 적합도	이유
테스트 실패 재현	높음	로그·코드를 로컬에서 읽고 결과를 명령으로 검증할 수 있다
작은 보안 패치 후보	높음	원문 코드를 밖에 보내지 않고 반복할 수 있다
린트·타입 오류 정리	높음	명령 결과가 명확하다
대형 설계 변경	낮음~중간	긴 맥락과 판단 품질이 더 중요하다
제품 전략 문서	낮음	공개 자료 검색과 넓은 추론이 필요하다
배포·결제·고객 데이터 변경	낮음	모델 위치보다 승인과 감사가 먼저다

로컬 모델은 작고 빠른 반복의 비용을 낮춘다. 하지만 모든 판단을 대신하지는 않는다. 특히 “어떤 변경이 제품적으로 맞는가”, “보안 리스크를 감수할 수 있는가”, “배포해도 되는가”는 여전히 사람과 운영 정책의 영역이다.

Google의 Agent Anomaly Detection 글이 말하는 문제도 여기에 붙는다. 에이전트가 더 자율적으로 움직일수록 위험은 코드 자체보다 세션 행동, 도구 호출, 실행 흐름에서 드러난다.Google 공식 로컬 실험 단계에서도 “몇 번이나 같은 파일을 고쳤나”, “어떤 명령을 반복했나”, “예상보다 많은 파일을 읽었나”를 로그로 남겨야 한다.

내가 실제로 적용한다면

내가 작은 개발 자동화를 설계한다면 이렇게 나눌 것 같다.

1. 클라우드 모델은 작업 지도를 만든다

클라우드에는 원문 코드 대신 구조만 준다. 예를 들어 “auth.py, billing.py, database.py 세 파일이 있고, 테스트는 pytest이며, 목표는 권한 우회 가능성 점검” 정도다. 클라우드 모델은 체크 순서, 의심 지점, 테스트 아이디어를 만든다.

2. 로컬 에이전트는 좁은 폴더에서 실행한다

로컬 에이전트에는 복사본 workspace만 준다. 명령은 pytest, python -m compileall, git diff 정도로 시작한다. 네트워크 접근은 꺼두거나 allowlist로 제한한다. 비밀값은 넣지 않는다.

3. 결과는 “패치”가 아니라 “증거 묶음”으로 받는다

좋은 결과는 이런 형태다.

- 재현 명령: pytest tests/test_billing.py::test_refund_limit
- 실패 원인: amount 누적 검사가 session 단위로 없음
- 수정 파일: billing.py
- 추가 테스트: tests/test_billing.py
- 남은 위험: cross-session 누적은 별도 저장소 설계 필요

이 정도가 나오면 사람이 판단하기 쉽다. 반대로 “문제를 해결했습니다”만 나오면 아무것도 해결된 것이 아니다.

4. 배포는 별도 파이프라인으로 둔다

로컬 에이전트가 테스트를 통과해도 배포 권한은 주지 않는다. 배포는 CI, 리뷰, preview, read-back이 있는 별도 파이프라인에서 한다. Cloudflare가 Worker Previews를 발표하며 강조한 것도 브랜치별로 production-like 환경을 만들고 실제 요청·로그·상태를 검증하는 흐름이다.Cloudflare 공식 로컬 패치와 배포 검증은 다른 층이다.

실무 체크리스트

로컬 AI 에이전트를 검토한다면 아래 항목을 먼저 채워보자.

• 이 작업에 원문 코드·로그가 꼭 필요한가?
• 클라우드에는 파일명과 요약만 보내도 되는가?
• 로컬 모델이 볼 workspace 범위가 정해졌는가?
• .env, 토큰, 고객 데이터, production dump가 제거됐는가?
• 에이전트가 실행할 수 있는 명령 allowlist가 있는가?
• 테스트·린트·타입체크처럼 결과를 검증할 명령이 있는가?
• 실패하면 어디서 멈출지 정했는가?
• 최종 적용과 배포는 사람이 승인하는가?
• 에이전트 행동 로그를 남기고 나중에 읽을 수 있는가?
• 클라우드 모델과 로컬 모델의 비용·속도·품질 차이를 기록하는가?

이 체크리스트를 채우지 못하면 로컬 에이전트 도입이 빠른 것이 아니라 흐릿한 것이다. 특히 “로컬이라 안전”이라는 문장은 금지어에 가깝다. 더 정확히는 “로컬이라 데이터 이동 경로 하나를 줄일 수 있지만, 실행 권한과 행동 감시는 여전히 필요하다”다.

내가 배운 점

이번 발표를 보며 가장 크게 배운 점은 로컬 AI의 가치가 “인터넷 없이 챗봇 쓰기”에서 “에이전트 작업의 경계를 나누기”로 옮겨갔다는 것이다. 로컬 모델이 클라우드 최고 모델보다 똑똑해서가 아니다. 반복 실행, 원문 코드 접근, 비용, 프라이버시가 얽히면 모델 위치 자체가 설계 요소가 된다.

다음 자동화에 남길 규칙도 하나 생겼다. 에이전트 파이프라인을 설계할 때는 모델명보다 먼저 정보 위치표를 만든다. 어떤 정보가 로컬에 남고, 어떤 요약만 클라우드에 올라가고, 어떤 행동은 사람 승인을 받아야 하는지 표로 적는다. 이 표가 없으면 나중에 도구가 늘어날수록 권한이 흐려진다.

FAQ

Antigravity SDK local model support는 무엇인가?

Antigravity SDK에서 Gemma 4 26B A4B 같은 로컬 모델을 LiteRT로 실행해 에이전트 워크플로에 사용할 수 있게 한 기능이다. Google 공식 예시는 google-antigravity, litert-lm, LiteRTAgentConfig 조합으로 로컬 모델 경로를 지정해 에이전트를 실행한다.Google 공식

로컬 AI 에이전트는 클라우드 에이전트보다 안전한가?

항상 그렇지는 않다. 원문 코드가 외부 API로 나가지 않는 장점은 있지만, 에이전트가 로컬 파일과 명령을 넓게 다룰 수 있으면 로컬 안에서 사고가 날 수 있다. workspace 제한, 비밀값 제거, 명령 allowlist, 로그, 사람 승인 게이트가 필요하다.

어떤 작업부터 로컬 에이전트로 실험하면 좋은가?

테스트 실패 재현, 작은 버그 수정 후보, 린트·타입 오류 정리, 문서 초안 정리처럼 범위가 좁고 검증 명령이 있는 작업이 좋다. 제품 전략, 대형 설계 변경, 고객 데이터 변경, 배포 같은 일은 로컬 모델 여부보다 승인·감사·리뷰 구조가 먼저다.

하드웨어는 어느 정도가 필요한가?

Google은 예시에서 24GB를 넘는 VRAM 또는 unified memory를 권장한다고 적었다.Google 공식 실제 요구사항은 모델 크기, 양자화, 백엔드, 작업 길이에 따라 달라진다. 처음에는 작은 workspace와 짧은 작업으로 속도와 품질을 측정하는 편이 안전하다.

클라우드 모델은 이제 필요 없나?

아니다. 좋은 하이브리드 구성에서는 클라우드 모델이 작업 분해와 고수준 판단을 맡고, 로컬 모델이 민감한 코드 읽기와 반복 실행을 맡는다. 클라우드와 로컬은 승자 결정이 아니라 역할 분담 문제다.

타깃 유입 키워드

• Antigravity SDK
• 로컬 AI 에이전트
• Gemma 4 26B
• LiteRT 로컬 모델
• 하이브리드 AI 자동화
• 온디바이스 코딩 에이전트
• AI 에이전트 프라이버시

출처