Google Antigravity 2.0의 Go CLI와 AX 분산 에이전트 런타임

CLI 교체가 아니라 실행 계층의 재설계다

Google I/O 2026에서 발표된 Antigravity 2.0은 기존 Gemini CLI를 공식 deprecated하고, Go로 전면 재작성한 CLI를 Google Cloud의 AX(Agent eXecution) 분산 에이전트 런타임과 결합했다. 에이전트 오케스트레이션을 별도 부가 기능이 아닌 개발 워크플로우의 기본 계층으로 끌어올린 변화다.

플랫폼의 역할도 분명하게 나뉜다. 분산 실행과 격리, 장애 대응은 AX가 런타임 수준에서 맡는다. CLI는 15ms 이하의 콜드스타트를 목표로 로컬 요청과 원격 에이전트 실행을 조율한다. 단순한 버전 갱신보다 플랫폼 아키텍처를 다시 설계한 결과에 가깝다.

Antigravity 1.x는 Gemini CLI를 중심으로 개발자 도구 생태계를 만드는 데 초점을 두었다. Node.js는 초기 프로토타입을 빠르게 만드는 데 유리했지만, 프로덕션 규모에서는 구조적인 병목을 드러냈다.

가장 직접적인 문제는 첫 실행 시간이었다. V8 엔진의 JIT 워밍업 때문에 CLI 콜드스타트에 400~800ms가 걸렸다. 터미널에서 반복 실행하거나 CI/CD 파이프라인이 자주 호출할수록 이 지연은 누적된다.

에이전트 실행 구조도 단일 프로세스에 묶여 있었다. 복잡한 멀티스텝 태스크가 순차 처리되므로 독립 작업을 병렬화하기 어려웠고, 한 에이전트의 크래시가 전체 세션 종료로 이어졌다. 별도의 격리 경계가 없어 보안 사고의 영향 범위도 넓었다.

배포 측면에서는 node_modules 의존성 트리가 150MB 이상이었으며, 크로스플랫폼 바이너리를 만들려면 pkg나 nexe 같은 도구가 추가로 필요했다. Windows 지원에서는 지속적인 품질 문제도 발생했다.

2.0은 이 한계를 AX 런타임, Go CLI, AI Studio 멀티플레이어로 나누어 해결한다. AX는 Google Cloud 위에서 에이전트 등록·라우팅·격리·내결함성을 전담한다. Go CLI는 단일 바이너리와 goroutine 기반 동시성을 활용해 에이전트 실행의 로컬 오케스트레이터가 된다. AI Studio 멀티플레이어는 워크플로우 공유, 역할 기반 접근 제어, 감사 로그를 제공해 개인용 도구를 엔터프라이즈 협업 플랫폼으로 확장한다.

에이전트 능력을 등록하고 실행 대상을 찾는 방식

AX의 에이전트 디스커버리는 Capability Manifest를 기준으로 작동한다. 에이전트가 등록될 때 OpenAPI 스타일의 JSON 매니페스트를 제출하면, 런타임이 내용을 파싱해 라우팅 인덱스에 저장한다.

AgentManifest {
  id:           string              // 글로벌 고유 식별자 (UUID v7)
  version:      semver              // 능력 집합의 버전 (호환성 관리용)
  capabilities: []CapabilitySpec    // 처리 가능 태스크 유형 목록
  resources: {
    cpu_milli:  int                 // 최소 요구 CPU (밀리코어 단위)
    memory_mb:  int                 // 최소 요구 메모리
    max_runtime_sec: int            // 하드 타임아웃
  }
  endpoints: {
    health:   string                // 헬스체크 URL
    execute:  string                // 동기 실행 엔드포인트
    stream:   string                // SSE 스트리밍 엔드포인트
  }
  region_affinity: []string         // 선호 실행 리전 (지연 최적화)
}

CapabilitySpec에는 자연어 태스크의 의도 패턴을 담는 intent, JSON Schema 형식의 input_schema와 output_schema가 들어간다. 태스크 라우터는 사용자 요청의 의미론적 임베딩과 에이전트별 intent 패턴 임베딩 사이의 코사인 유사도를 계산해 후보를 먼저 좁힌다.

레지스트리는 etcd 클러스터 위에서 강한 일관성과 분산 잠금을 지원한다. 각 에이전트 인스턴스의 헬스 상태는 30초 TTL 리스로 관리하며, 갱신이 멈춘 인스턴스는 자동으로 비활성 상태가 된다.

라우터가 태스크를 DAG 실행 계획으로 바꾸는 과정

AX의 태스크 라우터는 요청을 전달하는 디스패처에 머물지 않는다. 복잡한 입력을 받으면 먼저 의미를 분석하고 서브태스크로 나눌 수 있는지 판단한다. 분해 기준은 DDG(Data Dependency Graph)로 표현한다.

분리된 서브태스크 사이의 의존 관계는 DAG로 모델링한다. 선행 결과를 기다릴 필요가 없는 작업은 같은 레이어에 배치해 병렬로 실행한다.

실행 에이전트를 고를 때는 능력 매칭 점수, 현재 부하를 바탕으로 한 queueing delay 예측, 리전 핑으로 본 지리적 지연, 실행 단가를 가중 합산한다. 완성된 계획은 JSON으로 직렬화해 감사 로그에 남긴다. 실행이 끝난 뒤에는 계획과 실제 결과를 대조해 계획 정확도 메트릭을 갱신한다.

라우팅 판단에는 피드백 루프도 연결된다. 실제 실행 지연이 예측치를 넘으면 해당 에이전트의 부하 예측 모델을 업데이트하고 다음 라우팅에 반영한다.

gVisor 샌드박스가 만드는 실행 경계

각 에이전트 호출은 gVisor 기반 컨테이너 샌드박스 안에서 실행된다. gVisor는 Linux 커널 시스템 콜을 사용자 공간에서 인터셉트한다. 전통적인 runc 컨테이너보다 높은 보안 격리를 제공하면서 VM보다 빠르게 시작하는 방식이다.

Tier 1에서는 파일시스템 접근을 에이전트 작업 디렉토리인 /workspace로 제한한다. 외부 네트워크는 allowlist에 등록된 도메인만 허용하고, 시스템 콜에는 seccomp 화이트리스트를 적용한다.

Tier 2는 쓰기를 차단한 읽기 전용 파일시스템을 사용한다. 네트워크는 AX 런타임 API 엔드포인트로 한정하며 외부 자격증명 접근도 완전히 막는다.

Tier 3에서는 네트워크 인터페이스 자체를 제공하지 않는다. 에이전트 입력과 출력은 stdin/stdout 파이프로만 오가며, 고객 데이터를 다루는 엔터프라이즈 에이전트에 적용된다.

실제 격리 수준은 매니페스트의 security_tier와 Workspace 관리자 정책을 함께 평가해 결정한다. 두 조건 가운데 더 강한 제약이 우선한다.

배치 집계와 SSE 스트리밍을 함께 다루는 Result Collector

Result Collector는 분산된 서브태스크의 결과를 배치 또는 스트리밍 방식으로 수집한다.

배치 모드에서는 모든 서브태스크가 끝난 뒤 결과를 한꺼번에 집계한다. 반환 순서는 원본 DAG의 위상 정렬을 따른다. 일부 작업이 실패했다면 실패한 서브태스크의 fallback과 함께 부분 결과를 반환하도록 선택할 수 있다.

스트리밍 모드는 완료된 결과를 즉시 SSE(Server-Sent Events)로 클라이언트에 보낸다. 이벤트는 task_id, agent_id, chunk_type의 progress/result/error 구분, payload, timestamp로 구성된다. CLI는 이 스트림을 Go 채널로 변환해 터미널에 실시간으로 표시한다.

순서 의존성이 있는 결과는 선행 결과가 도착할 때까지 내부 버퍼에 머문다. 태스크별로 설정한 최대 버퍼 크기를 넘으면 백프레셔가 작동해 상류 에이전트의 실행 속도를 조절한다.

장애를 에이전트·태스크·클러스터에서 막는다

⤢✕

에이전트 계층에서는 30초 간격으로 상태를 확인하고 연속 3회 실패한 인스턴스를 격리한 뒤 트래픽을 전환한다.

태스크 계층은 멱등성 토큰을 사용해 exactly-once 실행을 보장한다. 오래 실행되는 태스크는 30초마다 체크포인트를 저장하므로 재시작할 때 처음부터 다시 수행하지 않는다.

클러스터 계층에서는 인스턴스를 여러 가용 영역에 분산한다. 글로벌 로드밸런서는 지연 기반 라우팅으로 단일 리전 장애를 자동 우회한다.

전체 요청은 Go CLI에서 AX를 거쳐 에이전트 풀로 전달되고, 수집된 결과가 다시 CLI의 SSE 수신부로 돌아온다.

⤢✕

Go CLI가 시작 시간과 배포 부담을 줄이는 방법

Go 재작성은 “CLI는 함수처럼 빨리 실행되어야 한다”는 원칙에서 출발했다. Gemini CLI와 Antigravity CLI의 비교 결과는 다음과 같다.

측정 지표	Gemini CLI (Node.js)	Antigravity CLI (Go)	개선율
콜드스타트	400~800ms	15~40ms	약 95% 단축
배포 크기	~150MB (node_modules)	~18MB (단일 바이너리)	약 88% 감소
유휴 메모리	~80MB	~12MB	약 85% 감소
크로스컴파일	pkg/nexe 필요	네이티브 지원	도구 의존성 제거
설치 시간	npm install ~45초	바이너리 복사	사실상 0초

15ms 콜드스타트는 컴파일 시점의 정적 링킹을 활용해 달성했다. 실행할 때 동적 라이브러리를 불러오지 않으며, 가비지 컬렉터 초기화와 스케줄러 부트스트랩은 수 밀리초 안에 끝난다. CGO 의존성을 없애 C 라이브러리 로딩 오버헤드도 배제했다.

동시성에서는 goroutine이 여러 에이전트 호출을 적은 메모리로 관리하는 기반이 된다. OS 스레드가 기본 2MB 스택을 할당하는 데 비해 goroutine은 2KB에서 시작하고 필요에 따라 크기가 늘어난다. 이 구조는 수천 개의 동시 에이전트 연결을 수백 MB 메모리로 처리할 수 있게 한다.

CLI는 워커 풀로 병렬 호출 수를 runtime.NumCPU() * 2로 제한해 goroutine이 무제한 증가하지 않도록 한다. 각 워커는 채널에서 태스크를 가져와 에이전트 API를 호출하고 결과 채널로 응답을 보낸다.

모든 원격 호출은 context.Context를 받는다. CLI를 시작할 때 만든 루트 컨텍스트는 사용자의 Ctrl+C 입력을 감지하면 취소 신호를 전체 컨텍스트 트리에 전파한다. 진행 중인 에이전트 호출을 함께 정리해 리소스 누수를 막는 구조다.

AX에서 받은 SSE 응답은 chan Chunk 형태의 Go 채널로 변환한다. 별도의 렌더링 goroutine이 채널을 읽어 터미널에 출력하므로 네트워크 I/O와 화면 렌더링이 분리된다.

단일 바이너리와 격리된 플러그인 프로세스

최종 배포 바이너리의 크기는 18MB다. 빌드 시 -ldflags="-s -w"를 적용해 디버그 심볼과 DWARF 정보를 제거하며, 이 과정에서 바이너리 크기를 30~40% 줄인다.

릴리스 빌드에는 UPX 압축도 적용한다. 최종 바이너리를 추가로 40~60% 압축하며, 실행 시 압축 해제는 수 밀리초 안에 끝나 사용자가 체감할 지연이 없다. 의존성은 표준 라이브러리를 우선하는 방식으로 억제하고, go mod tidy와 govulncheck를 함께 사용해 미사용 의존성과 취약한 의존성을 정기적으로 정리한다.

플러그인은 hashicorp/go-plugin을 통해 메인 CLI와 다른 프로세스에서 실행된다. 플러그인이 크래시하더라도 CLI 프로세스로 장애가 전파되지 않는 격리 방식이다.

프로세스 간 통신에는 gRPC와 Protocol Buffers를 사용한다. 플러그인 구현 언어가 Go로 제한되지 않으므로 Python, Rust, Java에서도 같은 gRPC 인터페이스를 구현할 수 있다. Protocol Buffers 스키마는 API 버전과 하위 호환성을 관리하는 타입 계약으로 쓰인다.

최초 로드 시에는 플러그인 바이너리의 SHA-256 서명을 검증한다. Antigravity 공식 키나 Workspace 관리자가 등록한 신뢰 키로 확인할 수 없는 플러그인은 로드를 거부하고 감사 로그에 기록한다.

크로스플랫폼 릴리스가 만들어지는 경로

⤢✕

CGO를 사용하지 않는 순수 Go 코드와 표준 크로스컴파일 도구체인으로 linux/amd64, linux/arm64, darwin/amd64, darwin/arm64, windows/amd64 바이너리를 한 파이프라인에서 생성한다. Windows 빌드에는 UPX 대신 Authenticode 코드 서명을 적용한다.

Gemini CLI에서 넘어갈 때 확인할 일정과 호환성

Gemini CLI의 deprecated 선언은 도구 이름만 바꾸는 일이 아니다. 수십만 명의 개발자가 사용하던 워크플로우가 새로운 실행 모델로 이동하는 생태계 전환이다.

2026년 4월 1일: Antigravity CLI 퍼블릭 베타 공개, 양 CLI 병행 운영
2026년 6월 18일: Antigravity CLI GA 출시, Gemini CLI 공식 deprecated 선언, 기능 업데이트 중단
2026년 12월 31일: Gemini CLI 보안 패치 종료, 완전 EOL

antigravity migrate --from gemini는 ~/.gemini/ 아래의 설정을 ~/.config/antigravity/로 변환한다. API 키 설정, 커스텀 시스템 프롬프트, 단축키 매핑, 히스토리 파일이 자동 변환 범위에 포함된다.

다만 Gemini CLI용 커스텀 플러그인은 그대로 옮길 수 없다. gRPC 기반 Antigravity 플러그인 인터페이스에 맞춰 다시 작성해야 하므로, 자체 플러그인을 운영하는 팀은 별도의 마이그레이션 비용과 일정을 잡아야 한다.

Claude Code·Cursor와 다른 지점은 통합의 깊이다

⤢✕

Antigravity 2.0이 내세우는 경쟁력은 Google Cloud와의 네이티브 통합 깊이다. BigQuery, Cloud Storage, Cloud Run, GKE, Pub/Sub을 사전 등록된 에이전트로 제공하므로 GCP를 사용하는 팀은 별도 커넥터 없이 자연어로 인프라를 조작할 수 있다. 범용 연결성을 지향하는 Claude Code의 MCP와 달리 특정 클라우드 플랫폼에 깊게 최적화한 선택이다.

실행 위치도 다르다. Claude Code와 Cursor는 기본적으로 로컬 또는 단일 세션 안에서 에이전트를 실행하지만, Antigravity 2.0은 AX를 통해 Google Cloud 데이터센터로 작업을 분산한다. 대규모 코드베이스 분석이나 배치 데이터 처리처럼 큰 컴퓨팅 자원이 필요한 태스크에는 유리한 반면, 클라우드 의존성과 데이터 레지던시 문제를 함께 검토해야 한다.

AI Studio 멀티플레이어는 에이전트 워크플로우를 팀과 공유하고 역할에 따라 접근을 통제한다. Claude Code와 Cursor가 현재 개인 도구 범주에 머물러 있는 것과 비교하면, 팀 단위 에이전트 거버넌스가 필요한 엔터프라이즈 시장에서 Antigravity 2.0이 먼저 자리를 잡을 수 있는 기능이다.

Android와 Firebase 안으로 에이전트를 들여놓는 전략

Android Studio Meerkat(2026.1)에는 Antigravity 에이전트가 IDE 기능으로 들어간다. Android와 Firebase 개발자가 이미 쓰는 환경에 에이전트를 포함해 별도의 도구 학습 없이 접근하도록 만드는 전략이다.

Compose UI 에이전트는 Figma 디자인 파일이나 자연어 설명을 받아 Jetpack Compose 컴포넌트 코드를 만들고 Android Studio 미리보기에 바로 반영한다.

Firebase 연동 에이전트는 Firestore 스키마 정의, Cloud Functions 코드 생성, Authentication 플로우 설정을 자동화한다. Firebase Console과의 양방향 동기화도 지원해 IDE에서 바꾼 내용을 Firebase 프로젝트에 실시간으로 반영한다.

Play Console 분석 에이전트는 ANR, 충돌 보고서, 성능 메트릭을 분석해 코드베이스 안의 원인 위치와 수정안을 제시한다. Maps Platform 에이전트는 프로젝트 구조에 맞는 Google Maps SDK 통합 코드를 생성하고 사용자 위치 표시, 경로 탐색, POI 마커 같은 지도 UX 패턴을 구현한다.

이 접근은 약 300만 명의 활성 Android 개발자를 Antigravity 생태계의 초기 사용자 기반으로 확보하려는 포지셔닝이다.

생태계의 강점과 아직 남은 비용

2026년 에이전트 개발 도구 시장은 로컬 중심 프라이버시 진영과 클라우드 네이티브 통합 진영으로 나뉜다. Claude Code, Cursor, GitHub Copilot이 전자에 속하고 Antigravity 2.0, Amazon Q Developer, Microsoft GitHub Copilot Enterprise는 후자에 놓인다.

Antigravity 2.0은 Google Cloud 의존성을 제약이자 경쟁력으로 사용한다. 대형 엔터프라이즈와 스타트업 크레딧 프로그램을 포함한 GCP 고객 기반이 초기 도입을 이끌고, Android·Firebase 개발자 생태계가 뒤를 잇는 확장 전략이다.

단기적으로는 플러그인 생태계가 약점이다. Claude Code의 MCP 에코시스템과 Cursor Extension 마켓플레이스에는 이미 수백 개의 통합이 있지만, Antigravity의 gRPC 플러그인 생태계는 2026년 6월 GA 시점에 공식 Google 플러그인 약 40개와 초기 서드파티 플러그인으로 출발한다. 생태계가 성숙하려면 최소 12~18개월이 필요할 것으로 예상된다.

AX는 에이전트 격리, 내결함성, 스트리밍 집계를 플랫폼 책임으로 옮겼고 Go CLI는 15ms 이하 응답으로 개발자의 실행 마찰을 낮춘다. 2026년 6월 18일의 전환 시점을 기준으로 Google Cloud 또는 Android·Firebase에 의존하는 팀은 Gemini CLI 마이그레이션과 커스텀 플러그인 재작성 일정을 함께 준비해야 한다. 이후 경쟁력은 Google Cloud 통합의 깊이와 개발자가 플랫폼을 신뢰하게 되는 속도에 달려 있다.