요약: Google은 Gemini CLI와 일부 Gemini Code Assist 개인용 흐름을 Antigravity CLI로 통합하겠다고 발표했다. 2026년 6월 18일부터 무료·개인용 경로의 요청 중단이 시작되고, 기업 라이선스와 Google Cloud 기반 고객은 별도 지원을 유지한다. Gemini CLI를 개발 워크플로우에 넣어둔 팀이라면 지금 해야 할 일은 새 CLI를 설치하는 것보다 의존 지점을 찾고, 권한·자동화·문서·교육을 전환하는 것이다.
검색 의도: Antigravity CLI 전환, Gemini CLI 종료, Gemini Code Assist 변경, AI 코딩 CLI 마이그레이션
Google은 2026년 5월 19일 개발자 블로그를 통해 Gemini CLI를 Antigravity CLI와 Antigravity 2.0 중심으로 통합한다고 밝혔다. Gemini CLI는 지난 1년 동안 터미널에서 에이전트 작업을 수행하는 대표적인 인터페이스였고, 100,000개 이상의 GitHub star, 6,000개 이상의 merged pull request, 수백 명의 contributor를 모은 프로젝트였다. 그러나 Google은 사용자의 요구가 단일 터미널 도구에서 multi-agent backend를 공유하는 플랫폼으로 이동했다고 설명했다.
가장 중요한 날짜는 2026년 6월 18일이다. 발표에 따르면 이 날짜부터 Google AI Pro·Ultra 사용자와 무료 개인용 Gemini Code Assist 흐름에서는 Gemini CLI와 Gemini Code Assist IDE extension 요청 제공이 중단된다. Gemini Code Assist for GitHub도 신규 설치와 요청 제공이 단계적으로 제한된다. 반면 Gemini Code Assist Standard, Enterprise, Google Cloud 기반 기업 고객은 기존 접근이 유지된다.
즉 개인 개발자와 소규모 팀은 6월 18일 전 전환 계획이 필요하고, 기업 고객도 “우리는 예외니까 괜찮다”로 끝내면 안 된다. 새 기능과 투자 방향은 Antigravity 쪽으로 집중될 가능성이 높기 때문이다.
이 변화는 gemini 명령을 antigravity 명령으로 바꾸는 수준이 아니다. Google은 Antigravity CLI가 Antigravity 2.0과 같은 server-side agent harness를 공유한다고 설명한다. 이것은 로컬 터미널 도구가 독립적으로 작업하는 모델에서, 데스크톱 앱·CLI·서버 측 harness가 같은 백엔드를 공유하는 모델로 바뀐다는 뜻이다.
발표에서 강조된 변화는 세 가지다.
개발팀 입장에서는 장점도 있지만 운영 변화도 생긴다. 기존 Gemini CLI를 shell script, CI helper, 문서 생성, repo 분석, cloud provisioning 보조에 넣어두었다면, 해당 흐름이 새 CLI에서도 같은 입력과 출력, exit code, 인증 방식, 로그 형식을 유지하는지 확인해야 한다.
전환 작업의 첫 단계는 설치가 아니라 인벤토리다. 팀 안에서 Gemini CLI가 어디 쓰이는지 모르면 전환 후 장애를 예측할 수 없다.
찾아볼 위치는 다음과 같다.
단순 검색어는 gemini, Gemini CLI, gemini-code-assist, gcli, ai assist 정도로 시작하면 된다. 찾은 항목은 세 종류로 나눈다.
위험도는 3번이 가장 높다. 사람은 오류를 보고 우회할 수 있지만 자동화는 조용히 실패하거나 잘못된 결과를 배포 흐름에 넣을 수 있다.
Antigravity CLI가 Agent Skills, Hooks, Subagents, Extensions를 유지한다고 해도 1:1 feature parity가 바로 제공되는 것은 아니라고 Google은 밝혔다. 따라서 팀은 “우리 워크플로우 기준”으로 검증해야 한다.
추천하는 테스트 세트는 다음과 같다.
각 테스트는 성공/실패만 보지 말고 결과 형식을 기록해야 한다. 로그 위치, 승인 요청 방식, 에러 메시지, retry 가능 여부, 네트워크 접근 정책이 모두 중요하다.
전환기에 가장 많이 터지는 문제는 도구 자체보다 문서다. 누군가는 오래된 README를 보고 Gemini CLI를 설치하고, 누군가는 새 Antigravity CLI를 쓰고, 누군가는 기업 계정으로 기존 IDE extension을 계속 쓴다. 이 상태가 몇 주만 지속돼도 팀 내 재현 환경이 갈라진다.
문서에는 다음 내용을 명확히 써야 한다.
개발자 교육은 길 필요가 없다. 30분짜리 세션이면 충분하다. 핵심은 새 명령어 사용법보다 “무엇을 에이전트에게 맡기고, 무엇은 사람 리뷰로 남길지”다. Antigravity가 multi-agent 흐름을 강조할수록 작업을 더 크게 맡기고 싶어지지만, 운영 안정성은 작은 작업 단위에서 나온다.
Gemini CLI에서 Antigravity CLI로 넘어가면 에이전트의 실행 표면이 넓어진다. 비동기 작업, subagent, plugin, 공유 harness가 들어오면 편하지만 권한 경계도 더 중요해진다. 특히 여러 에이전트가 동시에 작업하는 구조에서는 “누가 어떤 파일을 바꿨는지”, “어떤 hook이 어떤 명령을 실행했는지”가 명확해야 한다.
전환 시점에 권한 정책을 같이 정리하는 것이 좋다.
이 기준을 문서에만 두지 말고 CLI 설정, plugin 설정, repo 정책에 최대한 반영해야 한다. 사람이 매번 기억해서 통제하는 구조는 오래가지 않는다.
자동화는 전환 작업에서 가장 보수적으로 다뤄야 한다. Gemini CLI가 CI 안에서 문서 생성, 코드 리뷰 요약, 이슈 triage, 테스트 보조에 쓰이고 있다면 Antigravity CLI 전환 전에 다음을 확인한다.
CI는 사람보다 관대하면 안 된다. 로컬에서 편하게 쓰는 권한을 CI에 그대로 넣으면 supply chain, secret leak, 잘못된 PR 자동 생성 위험이 커진다.
Antigravity CLI 전환은 불편한 종료 공지가 아니라 AI 개발 도구가 multi-agent 플랫폼으로 이동하는 신호다. 지금 할 일은 새 도구를 무작정 믿는 것이 아니라, 팀의 자동화와 권한 경계를 새 실행 모델에 맞게 정리하는 것이다.
