Google은 2026년 5월 19일 Gemini CLI를 Antigravity CLI로 전환한다고 발표했습니다. 개인 사용자와 무료 Gemini Code Assist for individuals, Google AI Pro·Ultra 사용자는 2026년 6월 18일부터 기존 Gemini CLI와 일부 IDE extension 요청이 중단됩니다. 기업 고객은 Standard 또는 Enterprise 라이선스, Google Cloud 기반 Gemini Code Assist, Enterprise Agent Platform API key 경로가 유지됩니다.
이 글은 단순 설치 안내가 아닙니다. 이미 Gemini CLI로 개발 자동화, scaffolding, cloud provisioning, subagent workflow, hook, skill을 쓰고 있는 팀이 무엇을 점검해야 하는지 정리합니다. CLI 이름이 바뀌는 문제처럼 보여도 실제로는 agent-first 개발 플랫폼의 backend와 운영 방식이 바뀌는 문제입니다.
많은 개발팀은 CLI 마이그레이션을 gemini 명령을 antigravity 명령으로 바꾸는 작업으로 생각합니다. 하지만 Google 발표의 핵심은 더 큽니다. Gemini CLI는 terminal UI로 agentic task를 수행하는 도구였고, Antigravity CLI는 Antigravity 2.0 desktop app과 같은 server-side harness를 공유하는 구조입니다. 즉 단순 command wrapper가 아니라 multi-agent workflow와 asynchronous execution을 전제로 한 플랫폼으로 이동합니다.
이 차이는 운영에 영향을 줍니다. 기존 스크립트가 동기 실행을 가정했다면 background task 처리 방식이 달라질 수 있습니다. hook이 어떤 시점에 호출되는지, subagent가 어떤 context를 받는지, extension이 plugin으로 어떻게 매핑되는지 확인해야 합니다. CI에서 Gemini CLI를 호출하던 팀은 deadline 전에 검증하지 않으면 6월 18일 이후 자동화가 멈출 수 있습니다.
Google은 Gemini CLI 사용자가 terminal UI, weekly release, community contribution을 좋아했지만, 2025년 초기 워크플로우보다 요구가 커졌다고 설명합니다. 이제 사용자는 여러 agent가 서로 통신하며 대규모 refactor, research, cloud provisioning 같은 복잡한 작업을 나누어 처리하길 원합니다.
그래서 Antigravity CLI는 Go 기반의 더 빠른 실행, asynchronous workflow, Antigravity 2.0과 공유하는 unified architecture를 강조합니다. Agent Skills, Hooks, Subagents, Extensions는 유지되지만 Extensions는 Antigravity plugins로 이동합니다. 발표문도 1:1 feature parity가 당장 있는 것은 아니라고 말합니다.
이 말은 기존 기능명이 남아 있어도 동작 세부가 다를 수 있다는 뜻입니다. migration test가 필요합니다.
먼저 조직 내 사용자를 세 그룹으로 나눠야 합니다.
첫째, 개인 계정이나 무료 Gemini Code Assist for individuals를 쓰는 개발자입니다. 이 그룹은 6월 18일 중단 영향을 직접 받습니다. 로컬 개발 환경의 CLI, IDE extension, GitHub organization 신규 설치 경로를 확인해야 합니다.
둘째, 기업 라이선스 사용 개발자입니다. Google은 Standard 또는 Enterprise license와 Google Cloud 기반 Gemini Code Assist for GitHub는 유지된다고 설명합니다. 다만 Antigravity CLI를 병행 도입할 수 있으므로, 장기적으로는 전환 테스트를 해야 합니다.
셋째, CI/CD나 내부 자동화에서 CLI를 호출하는 시스템 계정입니다. 사람이 쓰는 CLI보다 이쪽이 더 위험합니다. cron, GitHub Actions, Cloud Build, 내부 dev portal, scaffolding bot에서 gemini 명령을 호출하는지 전수 검색해야 합니다.
마이그레이션의 첫 작업은 명령어 검색입니다. 저장소와 dotfiles에서 다음을 찾습니다.
rg "gemini|Gemini CLI|gemini-code|gcli" .
찾은 항목은 단순히 교체하지 말고 용도별로 분류하세요.
이 inventory가 있어야 위험도를 판단할 수 있습니다. 특히 cloud provisioning과 CI automation은 실패 시 비용이나 배포 문제가 생길 수 있으므로 먼저 검증해야 합니다.
Antigravity CLI의 장점 중 하나는 asynchronous workflows입니다. 대규모 refactor나 여러 주제 research를 background로 돌릴 수 있습니다. 하지만 운영 관점에서는 작업 완료 감지, 실패 로그, 승인 단계가 달라질 수 있습니다.
기존 스크립트가 “명령이 끝나면 결과 파일이 있다”고 가정했다면, 비동기 작업에서는 polling, callback, task id, status check가 필요할 수 있습니다. 또한 여러 agent가 동시에 파일을 수정할 수 있다면 lock이나 branch 전략이 필요합니다. local workspace에서 병렬 작업을 허용할지, 작업별 isolated worktree를 쓸지도 정해야 합니다.
마이그레이션 테스트에서는 다음을 확인하세요.
Google은 Agent Skills, Hooks, Subagents가 Antigravity CLI에서도 중요 기능으로 유지된다고 했습니다. 하지만 Extensions는 Antigravity plugins로 이동합니다. 기존 extension이 있는 팀은 바로 전체 이전하지 말고 대표 샘플을 하나 골라 end-to-end로 옮겨야 합니다.
좋은 샘플은 다음 조건을 만족합니다.
이 샘플을 기준으로 plugin packaging, credential injection, logging, retry, timeout을 확인합니다. 성공하면 나머지 extension을 같은 template로 옮깁니다.
마이그레이션은 한 번에 갈아타지 말고 dual-run으로 진행하는 편이 안전합니다. 최소 1주일은 같은 작업을 Gemini CLI와 Antigravity CLI에서 모두 실행해 결과 차이를 봐야 합니다. 특히 코드 수정 작업은 diff 품질, 테스트 통과율, 리뷰어 수정량을 비교해야 합니다.
권장 일정은 다음입니다.
기업 라이선스로 기존 CLI가 유지되는 팀도 이 작업을 미루지 않는 편이 좋습니다. 플랫폼 방향이 Antigravity로 이동한다면 신규 기능은 그쪽에 먼저 붙을 가능성이 큽니다.
gemini 명령 사용처를 검색합니다.Gemini CLI에서 Antigravity CLI로의 이동은 Google의 개발자 AI 도구가 terminal assistant에서 multi-agent platform으로 넘어가는 신호입니다. 마이그레이션을 단순 명령어 교체로 보면 위험합니다. 사용처를 inventory로 만들고, 비동기 실행과 plugin 전환을 검증한 뒤 단계적으로 옮기는 편이 안전합니다.
참고: Google Developers Blog, “An important update: Transitioning Gemini CLI to Antigravity CLI”, 2026-05-19.