Antigravity CLI 전환 대응: Gemini CLI 사용 팀이 6월 18일 전에 해야 할 일

요약: 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 쪽으로 집중될 가능성이 높기 때문이다.

왜 단순 CLI 교체가 아닌가

이 변화는 gemini 명령을 antigravity 명령으로 바꾸는 수준이 아니다. Google은 Antigravity CLI가 Antigravity 2.0과 같은 server-side agent harness를 공유한다고 설명한다. 이것은 로컬 터미널 도구가 독립적으로 작업하는 모델에서, 데스크톱 앱·CLI·서버 측 harness가 같은 백엔드를 공유하는 모델로 바뀐다는 뜻이다.

발표에서 강조된 변화는 세 가지다.

• Go 기반으로 더 빠른 실행과 반응성 제공.
• 여러 에이전트가 백그라운드에서 비동기 작업을 수행.
• Antigravity 2.0과 같은 agent harness를 공유해 향후 개선을 공통 적용.

개발팀 입장에서는 장점도 있지만 운영 변화도 생긴다. 기존 Gemini CLI를 shell script, CI helper, 문서 생성, repo 분석, cloud provisioning 보조에 넣어두었다면, 해당 흐름이 새 CLI에서도 같은 입력과 출력, exit code, 인증 방식, 로그 형식을 유지하는지 확인해야 한다.

먼저 찾아야 할 의존 지점

전환 작업의 첫 단계는 설치가 아니라 인벤토리다. 팀 안에서 Gemini CLI가 어디 쓰이는지 모르면 전환 후 장애를 예측할 수 없다.

찾아볼 위치는 다음과 같다.

• 개발자 온보딩 문서.
• README, AGENTS.md, CONTRIBUTING.md.
• package.json scripts, Makefile, justfile.
• GitHub Actions, GitLab CI, CircleCI 같은 CI 설정.
• 내부 bootstrap script.
• tmux, devcontainer, Codespaces 설정.
• 팀 위키의 “AI로 작업하기” 문서.
• 개인 dotfiles와 shell alias.

단순 검색어는 gemini, Gemini CLI, gemini-code-assist, gcli, ai assist 정도로 시작하면 된다. 찾은 항목은 세 종류로 나눈다.

1. 사람에게 안내하는 문서.
2. 로컬에서 실행되는 개발 보조 명령.
3. CI나 자동화에서 실행되는 명령.

위험도는 3번이 가장 높다. 사람은 오류를 보고 우회할 수 있지만 자동화는 조용히 실패하거나 잘못된 결과를 배포 흐름에 넣을 수 있다.

마이그레이션 테스트는 작은 작업으로 한다

Antigravity CLI가 Agent Skills, Hooks, Subagents, Extensions를 유지한다고 해도 1:1 feature parity가 바로 제공되는 것은 아니라고 Google은 밝혔다. 따라서 팀은 “우리 워크플로우 기준”으로 검증해야 한다.

추천하는 테스트 세트는 다음과 같다.

• repo 구조 요약: 읽기 전용 분석이 정상 동작하는지 확인.
• 작은 버그 수정: 파일 1~2개 수정과 테스트 실행까지 가능한지 확인.
• 문서 업데이트: changelog나 README 수정 품질 확인.
• 테스트 생성: 실패 케이스를 이해하고 regression test를 만들 수 있는지 확인.
• 긴 작업 백그라운드 실행: terminal session을 막지 않고 상태를 확인할 수 있는지 확인.
• hook 실행: 기존에 쓰던 pre/post 작업이 새 plugin 구조에서 유지되는지 확인.

각 테스트는 성공/실패만 보지 말고 결과 형식을 기록해야 한다. 로그 위치, 승인 요청 방식, 에러 메시지, retry 가능 여부, 네트워크 접근 정책이 모두 중요하다.

문서와 교육에서 바꿔야 할 부분

전환기에 가장 많이 터지는 문제는 도구 자체보다 문서다. 누군가는 오래된 README를 보고 Gemini CLI를 설치하고, 누군가는 새 Antigravity CLI를 쓰고, 누군가는 기업 계정으로 기존 IDE extension을 계속 쓴다. 이 상태가 몇 주만 지속돼도 팀 내 재현 환경이 갈라진다.

문서에는 다음 내용을 명확히 써야 한다.

• 개인용·무료 사용자는 Antigravity CLI를 기본으로 사용.
• 기업 라이선스 사용자는 기존 Gemini CLI 접근 가능 여부를 별도 확인.
• 신규 설치 문서는 Antigravity CLI 기준으로 갱신.
• 기존 Gemini CLI 명령은 deprecated로 표시.
• 자동화에 남아 있는 Gemini CLI 사용처는 owner와 전환 예정일을 표시.

개발자 교육은 길 필요가 없다. 30분짜리 세션이면 충분하다. 핵심은 새 명령어 사용법보다 “무엇을 에이전트에게 맡기고, 무엇은 사람 리뷰로 남길지”다. Antigravity가 multi-agent 흐름을 강조할수록 작업을 더 크게 맡기고 싶어지지만, 운영 안정성은 작은 작업 단위에서 나온다.

권한 정책을 다시 보는 이유

Gemini CLI에서 Antigravity CLI로 넘어가면 에이전트의 실행 표면이 넓어진다. 비동기 작업, subagent, plugin, 공유 harness가 들어오면 편하지만 권한 경계도 더 중요해진다. 특히 여러 에이전트가 동시에 작업하는 구조에서는 “누가 어떤 파일을 바꿨는지”, “어떤 hook이 어떤 명령을 실행했는지”가 명확해야 한다.

전환 시점에 권한 정책을 같이 정리하는 것이 좋다.

• 읽기 전용 분석은 자동 허용.
• 테스트·린트·타입체크는 자동 허용.
• 워크스페이스 내부 수정은 제한 허용.
• 패키지 설치와 외부 네트워크 접근은 승인 필요.
• DB 변경, 배포, secret 접근은 기본 금지.
• subagent가 만든 결과도 동일한 PR·CI 규칙을 통과.

이 기준을 문서에만 두지 말고 CLI 설정, plugin 설정, repo 정책에 최대한 반영해야 한다. 사람이 매번 기억해서 통제하는 구조는 오래가지 않는다.

CI와 자동화에서 확인할 것

자동화는 전환 작업에서 가장 보수적으로 다뤄야 한다. Gemini CLI가 CI 안에서 문서 생성, 코드 리뷰 요약, 이슈 triage, 테스트 보조에 쓰이고 있다면 Antigravity CLI 전환 전에 다음을 확인한다.

• headless 실행이 가능한가?
• 인증 토큰을 안전하게 주입할 수 있는가?
• exit code가 실패를 정확히 표현하는가?
• 출력 JSON 또는 Markdown 형식이 기존 parser와 호환되는가?
• rate limit와 timeout 정책이 다른가?
• 로그에 민감 정보가 남지 않는가?
• 실패 시 재시도해도 중복 PR이나 중복 댓글이 생기지 않는가?

CI는 사람보다 관대하면 안 된다. 로컬에서 편하게 쓰는 권한을 CI에 그대로 넣으면 supply chain, secret leak, 잘못된 PR 자동 생성 위험이 커진다.

실행 체크리스트

• 6월 18일 영향을 받는 사용자군을 구분했는가?
• repo와 CI에서 Gemini CLI 의존 지점을 모두 검색했는가?
• 문서용, 로컬 명령용, 자동화용 사용처를 분리했는가?
• Antigravity CLI로 읽기 분석, 작은 수정, 테스트 생성, hook 실행을 검증했는가?
• 기존 Gemini CLI 명령을 deprecated로 표시하고 owner를 지정했는가?
• 권한 정책을 읽기, 테스트, 수정, 네트워크, 배포 기준으로 다시 나눴는가?
• CI에서 exit code, 출력 형식, 토큰 주입, timeout을 확인했는가?
• 팀에 30분 전환 가이드를 공유했는가?

Antigravity CLI 전환은 불편한 종료 공지가 아니라 AI 개발 도구가 multi-agent 플랫폼으로 이동하는 신호다. 지금 할 일은 새 도구를 무작정 믿는 것이 아니라, 팀의 자동화와 권한 경계를 새 실행 모델에 맞게 정리하는 것이다.