Gemini CLI 6월 18일 중단, Antigravity로 옮겨야 하는 사용자

AI 요약

• 무슨 일: Google Gemini CLI 공식 공지가 개인 사용자 채널을 2026년 6월 18일 Antigravity CLI로 전환한다고 밝혔습니다.
  • Google AI Pro, Ultra, 무료 개인 사용자는 Gemini CLI, Gemini Code Assist IDE 확장, Gemini Code Assist on GitHub에서 기존 요청 처리가 중단됩니다.
• 남는 접근: Gemini Code Assist Standard/Enterprise, Google Cloud, paid Gemini/API 키 기반 조직 접근은 유지됩니다.
• 실무 영향: CLI 래퍼, IDE 확장, GitHub 앱, OAuth 기반 스크립트는 agy 전환 전에 인증과 권한, 로그, 자동화를 다시 확인해야 합니다.
  • Gemini CLI 저장소는 Apache 2.0으로 남지만, 개인 사용자용 요청 채널과 오픈소스 코드베이스의 운영 경계가 분리됩니다.

Google은 2026년 5월 19일 Gemini CLI 저장소의 공식 Discussion #27274를 올렸습니다. 내용은 터미널 AI 에이전트 경험을 Antigravity CLI로 옮기는 전환 공지입니다. 날짜가 더 중요합니다. 2026년 6월 18일부터 Google AI Pro, Google AI Ultra, 무료 개인 사용자는 Gemini CLI로 요청을 보낼 수 없습니다. 같은 변경은 Gemini CLI를 경유하는 Gemini Code Assist IDE 확장과 Gemini Code Assist on GitHub에도 적용됩니다.

이 공지는 "Gemini CLI가 삭제된다"는 단순한 종료 공지가 아닙니다. Google은 Gemini Code Assist Standard 또는 Enterprise 라이선스, Google Cloud, paid Gemini와 Gemini Enterprise Agent Platform API 키를 쓰는 조직은 기존 Gemini CLI 접근을 계속 지원한다고 적었습니다. 저장소도 Apache 2.0 라이선스로 남고, enterprise 고객을 위한 최신 모델 릴리스, 버그 수정, 보안 수정이 이어진다고 했습니다. 바뀌는 것은 개인 사용자와 무료·Pro·Ultra 계정이 쓰던 요청 경로입니다.

개발자가 확인해야 할 부분은 제품 이름보다 의존성입니다. Gemini CLI를 직접 실행하는 사용자는 설치 명령을 바꾸면 끝날 수 있습니다. 하지만 회사 내부에서 gemini 명령을 스크립트로 감싸고, IDE 확장에서 같은 인증을 쓰고, GitHub 앱으로 PR 리뷰나 이슈 작업을 넘기던 팀은 6월 18일 이후 실패 모드가 달라집니다. 모델 ID deprecation처럼 경고만 받고 계속 동작하는 방식이 아니라, 요청이 멈추는 경로가 생깁니다.

Google의 설명은 멀티 에이전트 작업이 단일 CLI만으로는 부족해졌다는 쪽에 맞춰져 있습니다. 공지에는 Antigravity CLI가 Go로 작성됐고, 더 빠른 반응성, 비동기 백그라운드 워크플로, Antigravity 2.0 데스크톱 앱과 공유하는 아키텍처를 갖췄다고 적혀 있습니다. 또 Gemini CLI의 핵심 기능으로 여겨졌던 Agent Skills, Hooks, Subagents, Extensions를 유지하되 Extensions는 Antigravity plugins로 옮긴다고 설명했습니다.

Antigravity 제품 페이지의 번들 데이터도 같은 방향입니다. Antigravity CLI 페이지는 CLI를 "terminal-first surface"로 소개하고, 터미널 흐름 안에서 에이전트를 호출·감시·상호작용하는 표면으로 설명합니다. 기능 카드에는 자연어 작업, 병렬 subagents, /agents 패널, ctrl+k 도구 승인, /config, /keybindings, slash commands, MCP, skills, hooks, plugins가 함께 나옵니다. Google은 CLI를 독립 제품보다 Antigravity 에이전트 플랫폼의 터미널 표면으로 재배치했습니다.

이 전환은 최근 Antigravity 2.0의 대규모 subagent 데모와 결이 다릅니다. 데모가 93개 subagent나 26억 token 같은 실행 규모를 보여줬다면, 이번 공지는 사용자 권한과 제품 채널을 바꿉니다. 개인 개발자에게는 모델 성능보다 인증 방식, 계정 종류, IDE 확장 경로, GitHub 앱 연동이 더 직접적인 리스크입니다. 6월 18일 이후 같은 프롬프트가 실패한다면 원인은 모델 품질이 아니라 접근 채널일 수 있습니다.

커뮤니티 반응은 그 지점에서 갈렸습니다. GitHub Discussion 댓글에는 Antigravity CLI가 Gemini CLI처럼 오픈소스가 될 계획이 있는지 묻는 질문이 빠르게 올라왔습니다. 다른 사용자는 Antigravity CLI를 시험해 보니 diff 확인이나 문서 프로젝트 기억 같은 사용성이 기존 Gemini CLI보다 낮게 느껴진다고 적었습니다. 또 Gemini CLI에 27개 커밋 PR을 병합했다는 기여자는 커뮤니티가 만든 코드가 enterprise 고객용 유지보수에만 남는지 우려했습니다.

Google은 저장소를 닫는다고 말하지 않았습니다. 공식 공지의 문장은 반대입니다. Gemini CLI 프로젝트는 Apache 2.0으로 계속 공개되고, Google은 최신 모델 릴리스, 버그 수정, 보안 수정을 유지하겠다고 했습니다. 다만 개인 사용자 관점에서는 오픈소스 코드가 남는다는 사실과 무료·Pro·Ultra 계정으로 요청을 보낼 수 있느냐가 다른 문제입니다. 소스 코드를 설치할 수 있어도 백엔드 인증과 quota가 바뀌면 실제 작업 루틴은 끊길 수 있습니다.

이 차이는 AI 코딩 도구가 라이브러리보다 SaaS에 가깝다는 사실을 다시 드러냅니다. 전통적인 CLI 도구는 바이너리와 설정 파일이 남아 있으면 어느 정도 계속 실행됩니다. AI 에이전트 CLI는 모델, 인증, rate limit, 계정 정책, remote backend가 함께 묶입니다. Gemini CLI의 Apache 2.0 저장소는 유지될 수 있지만, 개인 사용자의 gemini 명령이 어떤 계정으로 어떤 endpoint에 요청하는지는 별도 운영 정책입니다.

팀이 마이그레이션 전에 확인할 항목은 네 가지입니다. 첫째, 로컬 스크립트와 CI에서 gemini 명령을 직접 호출하는지 확인해야 합니다. 둘째, IDE 확장과 GitHub 앱이 개인 계정 인증을 쓰는지 조직 라이선스를 쓰는지 나눠야 합니다. 셋째, hooks와 skills가 Antigravity plugins 또는 새 skills 위치로 옮겨질 때 파일 경로와 권한 모델이 같은지 봐야 합니다. 넷째, 기존 로그와 감사 기록이 Antigravity 2.0의 artifact 또는 agent management 방식으로 대체되는지 확인해야 합니다.

특히 hooks는 보안팀이 먼저 봐야 합니다. Antigravity hooks 문서는 특정 실행 이벤트에서 스크립트나 shell command를 실행하는 구성을 설명합니다. 이는 Gemini CLI에서 custom workflow를 붙였던 팀에는 익숙한 기능이지만, 동시에 agent loop 중간에 로컬 명령이 실행되는 지점입니다. 마이그레이션은 단순 설치 교체가 아니라 어떤 이벤트에서 어떤 command가 실행되는지 다시 승인하는 작업이어야 합니다.

plugins도 같은 이유로 중요합니다. Antigravity CLI plugins 문서는 skills, background subagents, linting rules를 묶는 방식을 설명합니다. 같은 bundle에는 MCP definitions와 event hooks도 들어갈 수 있습니다. Gemini CLI에서 .gemini 설정, MCP 서버, 사내 prompt pack, shell hook을 따로 관리했다면 Antigravity에서는 이들을 plugin 단위로 포장할 수 있습니다. 운영 관점에서는 배포가 쉬워지는 대신, 한 bundle이 가져오는 권한과 실행 지점을 더 명확히 검토해야 합니다.

개인 개발자에게도 확인할 부분이 있습니다. Google 공지에는 Antigravity CLI를 지금 Google Cloud projects와 함께 사용할 수 있다고 적혀 있습니다. 무료 개인 사용자가 기존 Gemini CLI를 "로컬 오픈소스 도구"처럼 생각했다면, 6월 18일 전에 Antigravity CLI 설치, 로그인, quota 표시, 파일 수정 승인, diff 확인, 작업 취소, 로그 저장 위치를 실제 프로젝트에서 시험해야 합니다. 특히 AI 코딩 에이전트는 첫 실행보다 실패 후 복구 경험이 더 중요합니다.

기업 사용자는 공지상 기존 Gemini CLI 접근이 유지되지만, 무시해도 된다는 뜻은 아닙니다. 개인 채널과 enterprise 채널이 분리되면 내부 개발자의 shadow usage가 드러납니다. 회사 계정으로 통제되는 IDE 확장은 계속 동작해도, 일부 개발자가 개인 Google AI Pro 계정으로 로컬 CLI를 쓰던 경우 6월 18일 이후 갑자기 Antigravity 전환 압력을 받습니다. 보안팀은 "조직 라이선스는 유지"라는 문장만 보지 말고 개인 계정 기반 자동화가 있는지 찾아야 합니다.

경쟁 제품과 비교하면 Google의 선택은 명확합니다. Claude Code는 dynamic workflows로 장기 작업과 subagent 운영을 강조하고, OpenAI Codex는 데스크톱·모바일·원격 실행을 한 제품 표면으로 묶고, GitHub Copilot은 IDE·CLI·cloud agent·mobile에 모델 선택과 과금을 붙입니다. Google도 Gemini CLI를 독립적인 오픈소스 터미널 도구로 키우기보다 Antigravity 2.0, Antigravity CLI, Antigravity SDK를 하나의 에이전트 플랫폼으로 정렬하고 있습니다.

다만 이 정렬은 커뮤니티 신뢰 비용을 가집니다. GitHub 저장소의 star 수와 contributor 수는 제품 채널 전환의 완충재가 아닙니다. 사용자는 오픈소스 코드에 기여하면서 동시에 Google 계정과 backend quota에 의존했습니다. 이제 Google은 저장소 유지와 개인 접근 종료를 동시에 말합니다. 기술적으로는 모순이 아니지만, 커뮤니티가 체감하는 가치는 "코드를 볼 수 있는가"보다 "내가 쓰던 방식이 계속 동작하는가"에 더 가깝습니다.

한국 개발팀이 이 뉴스를 보는 실무 포인트는 모델 성능 비교가 아닙니다. 6월 18일이라는 날짜를 dependency deadline으로 등록하는 일입니다. gemini 호출이 들어간 shell alias, VS Code 설정, JetBrains 설정, GitHub app 권한, MCP 서버 구성, 사내 prompt pack, hook 스크립트, 비용 추적 대시보드를 한 번에 점검해야 합니다. 개인 계정으로 테스트하던 agent workflow를 조직 라이선스로 옮길지, Antigravity CLI로 옮길지, 다른 CLI로 대체할지 결정해야 합니다.

현재 확인된 사실만 놓고 보면 Gemini CLI는 사라지지 않습니다. 하지만 개인 사용자의 기존 요청 경로는 2026년 6월 18일에 멈춥니다. Antigravity CLI는 그 빈자리를 받는 새 터미널 표면이고, Google은 멀티 에이전트와 데스크톱 공통 아키텍처를 이유로 제시했습니다. 이 전환을 제품 리브랜딩으로만 보면 놓치는 부분이 있습니다. AI 코딩 에이전트의 의존성은 바이너리 이름이 아니라 계정 정책, backend, 권한, 자동화 경로까지 포함합니다.

마이그레이션의 최소 기준은 간단합니다. 6월 18일 전에 실제 저장소 하나에서 Antigravity CLI를 설치하고, 기존 Gemini CLI로 하던 작업 하나를 끝까지 재현합니다. 그 과정에서 diff 확인, tool 승인, hook 실행, MCP 연결, 실패 로그, 비용 또는 quota 표시가 기대와 맞는지 봅니다. 자동화가 깨지는지 확인하려면 성공 사례보다 실패 사례를 만들어야 합니다. 권한 없는 command, 실패하는 test, 충돌 나는 파일 수정, 긴 작업 중 취소를 시험하면 새 CLI가 팀의 운영 기준을 통과하는지 더 빨리 알 수 있습니다.