무료 Gemini CLI 마감일, 터미널 에이전트 흡수전

AI 요약

• 무슨 일: Google이 Gemini CLI 개인/무료 사용자 경로를 Antigravity CLI로 전환합니다.
  • 2026년 6월 18일부터 Pro/Ultra와 무료 개인 경로의 Gemini CLI, Code Assist IDE, GitHub 신규 설치와 요청 제공이 단계적으로 멈춥니다.
• 의미: 터미널 AI 도구가 단일 명령 보조 기능에서 멀티 에이전트 하네스의 입구로 흡수되고 있습니다.
• 주의점: 엔터프라이즈와 paid API key 경로는 예외지만, 개인 개발자는 마이그레이션과 워크플로 재검토가 필요합니다.
  • Agent Skills, Hooks, Subagents, Extensions는 이어지지만 Extensions는 Antigravity plugins로 이동합니다.

2026년 5월 19일, Google Developers Blog에 올라온 전환 공지는 겉으로 보면 제품 이름 변경처럼 보입니다. Gemini CLI를 Antigravity CLI로 옮긴다는 이야기입니다. 하지만 날짜와 대상, 예외 조항을 자세히 읽으면 더 큰 변화가 보입니다. Google은 개인 개발자가 터미널에서 쓰던 Gemini CLI 경로를 Antigravity라는 에이전트 개발 플랫폼으로 흡수하고 있습니다.

핵심 날짜는 2026년 6월 18일입니다. 그날부터 Gemini CLI와 Gemini Code Assist IDE 확장은 Google AI Pro/Ultra 사용자, 무료 Gemini Code Assist for individuals 사용자에게 요청을 제공하지 않습니다. Gemini Code Assist for GitHub도 같은 날 GitHub 조직의 신규 설치가 막히고, 이어서 요청 제공이 중단됩니다. 반면 Gemini Code Assist Standard/Enterprise 라이선스, Google Cloud를 통한 Gemini Code Assist for GitHub, paid Gemini 또는 Gemini Enterprise Agent Platform API key를 쓰는 조직은 Gemini CLI와 IDE 확장을 계속 쓸 수 있습니다.

이 차이가 이번 발표의 본질입니다. Gemini CLI가 사라진다기보다, 무료와 개인 구독 기반의 터미널 경로가 Antigravity 쪽으로 재배치됩니다. 기업 경로는 유지됩니다. Google은 커뮤니티형 CLI를 완전히 버리는 대신, 에이전트 개발의 기본 표면을 Antigravity 2.0과 Antigravity CLI로 옮기고 있습니다. 개발자 입장에서는 “새 CLI를 설치하면 끝”이 아니라, 내가 어떤 계정과 어떤 백엔드, 어떤 권한 모델로 코딩 에이전트를 운영할지 다시 확인해야 하는 사건입니다.

10만 스타 CLI가 플랫폼 입구로 바뀌는 순간

Google은 공지에서 Gemini CLI가 수백만 사용자, 10만 개 이상의 GitHub 스타, 6천 개 이상의 병합 PR, 수백 명의 기여자를 얻었다고 설명합니다. 이 숫자는 Gemini CLI가 실험적 데모가 아니라 실제 개발자 워크플로에 들어갔다는 증거입니다. 터미널에서 파일을 읽고, 셸 명령을 실행하고, 빠르게 코드를 고치는 인터페이스는 AI 코딩 도구의 가장 자연스러운 입구 중 하나였습니다.

그런데 바로 그 성공이 전환의 이유가 됐습니다. Google은 개발자의 요구가 2025년 초의 “터미널에 Gemini를 넣는다”에서 벗어났다고 말합니다. 이제 사용자는 여러 에이전트가 서로 소통하며 일을 나누고, 복잡한 작업을 백그라운드에서 수행하고, IDE와 터미널과 브라우저가 같은 하네스를 공유하기를 원한다는 설명입니다. 다시 말해 Gemini CLI의 문제는 인기가 없어서가 아니라, 단일 터미널 도구로는 Google이 그리고 있는 멀티 에이전트 개발 환경의 중심이 되기 어렵다는 데 있습니다.

이런 판단은 최근 AI 코딩 도구 경쟁과도 맞물립니다. Claude Code, OpenAI Codex, Cursor, GitHub Copilot app, Windsurf 같은 제품은 모두 단순 자동완성이나 채팅을 넘어 “작업을 맡기고 검증하는 표면”을 만들고 있습니다. diff, 테스트 로그, 브라우저 스크린샷, 작업 계획, 권한 승인, 비용 계기판이 제품의 일부가 됩니다. CLI는 여전히 강력하지만, 장시간 작업과 여러 에이전트의 상태를 보여주는 데에는 별도의 운영 표면이 필요합니다.

Google의 답은 Antigravity입니다.

Antigravity CLI는 새 이름이 아니라 새 하네스입니다

Google은 Antigravity 공개 글에서 이 제품을 agent-first 개발 플랫폼이라고 불렀습니다. 익숙한 IDE 안에서 코드를 직접 만지는 Editor View가 있고, 여러 에이전트를 배치하고 관찰하는 Manager Surface가 따로 있습니다. 에이전트는 editor, terminal, browser를 오가며 계획하고, 실행하고, 검증합니다. 결과는 raw tool call 로그가 아니라 task list, implementation plan, screenshot, browser recording 같은 Artifacts로 전달됩니다.

이번에 나온 Antigravity CLI는 그 플랫폼의 터미널 표면입니다. Google은 Gemini CLI의 핵심 기능으로 Agent Skills, Hooks, Subagents, Extensions를 꼽고, Antigravity CLI가 이 기능을 유지한다고 말합니다. 다만 Extensions는 Antigravity plugins라는 이름과 형식으로 이동합니다. 이것은 호환성을 최대한 살리려는 신호이면서 동시에, 앞으로 확장 생태계의 중심이 Gemini CLI가 아니라 Antigravity가 된다는 신호입니다.

기술적 차이도 있습니다. Google은 Antigravity CLI가 Go 기반이라 더 빠르고 반응성이 좋다고 설명합니다. 또 비동기 워크플로를 지원해 대규모 리팩터링이나 여러 조사 작업을 백그라운드에서 돌리면서 터미널 세션을 막지 않는다고 합니다. 가장 중요한 표현은 unified architecture입니다. Antigravity CLI는 Antigravity 2.0 데스크톱 앱과 같은 agent harness를 공유하므로, core agent 개선이 어디에서 쓰든 같이 적용된다는 설명입니다.

이 문장은 제품 전략을 거의 그대로 드러냅니다. Google은 모델을 CLI에 붙이는 회사가 아니라, IDE와 CLI와 브라우저 검증을 하나의 에이전트 실행 계층으로 묶는 회사를 지향합니다. Gemini CLI가 “터미널에서 Gemini에게 묻는 도구”였다면, Antigravity CLI는 “Antigravity 하네스를 터미널에서 호출하는 도구”에 가깝습니다. 사용자가 보는 화면은 비슷할 수 있지만, 제품의 중심은 바뀝니다.

6월 18일의 진짜 의미

전환 공지에서 가장 실무적인 문장은 “Starting today, Antigravity CLI is available to everyone” 다음에 나옵니다. Antigravity CLI는 오늘부터 쓸 수 있지만, Gemini CLI와 관련 개인 경로는 6월 18일에 멈춥니다. 마이그레이션 기간은 약 한 달입니다. AI 도구 전환치고는 길지 않습니다.

개인 개발자에게는 세 가지 확인 지점이 있습니다. 첫째, 자신이 무료 Gemini Code Assist for individuals나 Google AI Pro/Ultra 경로로 Gemini CLI를 쓰고 있는지 확인해야 합니다. 둘째, 자동화 스크립트, 로컬 alias, CI 보조 작업, MCP 연결, extension 설정이 Antigravity CLI에서 어떻게 옮겨지는지 점검해야 합니다. 셋째, 기존 Gemini CLI를 빠른 one-shot 작업에 쓰던 습관이 Antigravity CLI의 세션/하네스 모델과 충돌하지 않는지 봐야 합니다.

엔터프라이즈 팀은 다른 질문을 해야 합니다. 공식 공지상 Gemini Code Assist Standard 또는 Enterprise 라이선스, Google Cloud를 통한 Gemini Code Assist for GitHub, paid Gemini와 Gemini Enterprise Agent Platform API key 경로는 유지됩니다. 그러면 조직은 “기존 Gemini CLI를 계속 둘 것인가, Antigravity CLI를 표준으로 옮길 것인가”를 선택해야 합니다. 엔터프라이즈 예외가 있다는 사실은 단기 리스크를 낮추지만, 장기 제품 투자가 Antigravity 쪽으로 흐른다는 신호는 여전히 남습니다.

이 표에서 중요한 것은 “중단”이라는 단어보다 “경로”입니다. 같은 Gemini CLI라도 어떤 인증과 어떤 상품 경로로 쓰는지에 따라 결과가 달라집니다. AI 개발 도구가 개인 신용카드와 무료 quota로 확산된 뒤, 기업 운영 표준과 플랫폼 하네스로 재편되는 전형적인 장면입니다.

CLI의 장점은 사라지지 않지만 성격은 바뀝니다

Gemini CLI 같은 터미널 도구의 장점은 명확합니다. 빠르게 실행되고, 파이프라인에 넣기 쉽고, 파일과 표준 입출력을 다루기 편합니다. 로그 요약, 코드 검색, 작은 패치, 문서 초안, 일회성 변환 작업에는 IDE 전체를 열 필요가 없습니다. 그래서 개발자 커뮤니티에서는 CLI와 Antigravity 같은 IDE/세션형 도구를 보완적으로 쓰는 흐름이 있었습니다.

이번 전환은 그 구분을 없애지는 않습니다. Antigravity CLI도 터미널 표면을 제공합니다. 하지만 CLI가 독립 제품으로 남는지, 아니면 더 큰 에이전트 플랫폼의 얇은 입구가 되는지는 큰 차이입니다. 독립 CLI는 shell script, Makefile, cron, CI 보조 작업에 자연스럽게 들어갑니다. 플랫폼형 CLI는 같은 하네스와 계정, 권한, 플러그인, 상태 모델을 공유하는 대신, 제품 플랫폼의 정책 변화에 더 직접적으로 묶입니다.

이 변화는 장점과 비용을 동시에 만듭니다. 장점은 장시간 작업과 멀티 에이전트 작업이 더 일관된 실행 계층을 갖는다는 점입니다. 예를 들어 Antigravity의 Manager Surface에서 시작한 작업과 CLI에서 시작한 작업이 같은 agent harness를 공유하면, 권한 정책, 결과물, 검증 방식, 모델 라우팅을 한 곳에서 개선할 수 있습니다. Google이 말한 “core agent 개선이 어디에서든 자동 적용된다”는 메시지는 이 장점을 겨냥합니다.

비용은 단순성과 독립성입니다. 터미널 도구는 적을수록 좋습니다. 개발자가 원하는 것은 종종 “현재 디렉터리에서 이 로그를 읽고 한 줄로 요약해줘”입니다. 그 작업까지 세션형 에이전트 플랫폼의 세계관 안으로 들어가야 한다면, 일부 사용자는 무겁게 느낄 수 있습니다. 특히 quota, authentication, permissions, no capacity, stuck thinking 같은 운영 이슈가 생기면 CLI의 장점이 빠르게 사라집니다.

GitHub google-gemini/gemini-cli Discussions를 보면 이런 긴장이 이미 보입니다. Discussions에는 MCP 설정, 권한 자동 허용, capacity 문제, Antigravity bans 복구, 요청 제한 확인 같은 주제가 쌓여 있습니다. 이는 Gemini CLI 사용자가 단순한 챗봇 사용자가 아니라, 도구를 실제 개발 환경에 연결한 운영자라는 뜻입니다. 이번 전환은 그 운영자들에게 “앞으로 Google이 고치는 곳은 Antigravity 하네스”라고 말하는 셈입니다.

왜 Google은 흡수 전략을 택했나

Google이 Gemini CLI를 별도 제품으로 계속 키울 수도 있었습니다. 실제로 2025년 말에는 Gemini 3 Flash를 Gemini CLI에 넣으며 terminal-based work의 속도와 비용을 강조했습니다. 당시 Google은 Gemini 3 Flash가 agentic coding에서 SWE-bench Verified 78%를 기록했고, Gemini 3 Pro보다 낮은 비용으로 고빈도 개발 작업에 적합하다고 설명했습니다. Gemini CLI는 빠른 모델과 잘 어울리는 표면이었습니다.

그런데 코딩 에이전트 경쟁은 빠른 모델만으로 끝나지 않습니다. 개발자는 모델에게 “이 함수 고쳐줘”라고 말하는 수준을 넘어, 이슈를 재현하고, 테스트를 만들고, 브라우저에서 확인하고, PR 설명을 쓰고, 리뷰 반영까지 처리하는 흐름을 원합니다. 이때 핵심은 모델 응답 속도보다 실행 상태와 검증 증거입니다. 어떤 파일을 읽었는지, 어떤 명령을 실행했는지, 어떤 브라우저 화면을 확인했는지, 사용자가 어디에 피드백을 달 수 있는지가 중요합니다.

Antigravity의 Artifacts 개념은 바로 이 지점을 겨냥합니다. Google은 raw tool call 로그를 뒤지는 대신, task list, implementation plan, screenshot, browser recording 같은 결과물로 에이전트의 논리를 검증하게 하겠다고 설명했습니다. 이것은 OpenAI Codex의 clean diff와 작업 증거, Claude Code의 plan과 tool trace, GitHub Copilot app의 PR 기반 검증과 같은 경쟁 축에 놓입니다.

결국 Gemini CLI가 강한 영역은 “명령형 터미널 보조”였고, Google이 크게 베팅하는 영역은 “에이전트 운영 표면”입니다. 둘을 따로 키우면 모델, 권한, 플러그인, 메모리, 하네스, 검증 UI가 갈라집니다. Google은 이 분리를 줄이기 위해 Antigravity CLI라는 흡수 경로를 택했습니다. 개발자에게는 불편한 전환이지만, 제품 전략으로는 일관된 선택입니다.

경쟁사 입장에서 보이는 신호

이번 발표는 Google 내부 정리만이 아닙니다. AI 코딩 시장 전체에 보내는 신호입니다. 2026년의 코딩 에이전트 경쟁은 “누가 더 똑똑한 모델을 붙였나”에서 “누가 더 오래, 더 안전하게, 더 검증 가능하게 작업을 맡길 수 있나”로 이동하고 있습니다. 터미널은 여전히 중요하지만, 터미널만으로는 이 경쟁을 설명하기 어렵습니다.

Claude Code는 개발자에게 매우 강한 CLI/agent 경험을 제공했고, Anthropic은 Claude Platform, MCP, Skills, enterprise 연결을 계속 확장하고 있습니다. OpenAI Codex는 데스크톱 앱, 모바일 승인, 기업 배포, Goals 같은 작업 완료 계약으로 넓어지고 있습니다. GitHub Copilot은 PR과 이슈, CI, 조직 정책으로 들어갑니다. Cursor와 Windsurf는 IDE 자체를 에이전트 작업대로 바꾸고 있습니다.

Google은 Antigravity로 이 경쟁에 답합니다. Antigravity CLI 전환은 “우리도 CLI가 있다”가 아니라 “우리의 CLI는 Antigravity라는 agent-first 플랫폼의 일부다”라는 선언입니다. Gemini 모델, Gemini Code Assist, Google Cloud, browser verification, Android/Chrome/Firebase 개발자 생태계를 한 하네스에 묶을 수 있다면 Google에는 분명한 강점이 있습니다. 반대로 사용자가 원하던 가벼운 CLI 감각을 잃으면, Claude Code나 Codex CLI 같은 대안으로 이동할 이유도 생깁니다.

개발자가 지금 할 일

첫째, 6월 18일 전에 사용 경로를 확인해야 합니다. Gemini CLI를 npm으로 설치해서 쓰고 있더라도, 실제 인증이 Google AI Pro/Ultra인지, 무료 Code Assist 개인 경로인지, paid API key인지, 엔터프라이즈 라이선스인지에 따라 대응이 다릅니다. 특히 로컬 자동화나 팀 문서에 “Gemini CLI 실행”이 박혀 있다면 중단 시점에 조용히 깨질 수 있습니다.

둘째, Extensions를 쓰는 팀은 Antigravity plugins 전환을 별도로 봐야 합니다. Google은 핵심 기능을 유지한다고 했지만 1:1 feature parity는 바로 제공되지 않는다고 명시했습니다. “대부분 된다”와 “우리 워크플로가 그대로 돈다”는 다른 문장입니다. MCP 서버, Hooks, Subagents, Skills, 파일 접근 정책, 권한 승인 모델은 실제 프로젝트에서 테스트해야 합니다.

셋째, CLI를 어떤 용도로 쓰는지 분류해야 합니다. 로그 요약과 빠른 코드 검색, 일회성 변환처럼 단순하고 짧은 작업은 다른 CLI 도구나 paid key 경로가 더 적합할 수 있습니다. 장시간 리팩터링, 브라우저 검증, UI 반복, 여러 작업 병렬 실행처럼 상태와 검증이 필요한 작업은 Antigravity 쪽으로 옮기는 것이 더 자연스러울 수 있습니다.

넷째, 기업 팀은 “예외라서 괜찮다”에서 멈추지 않는 편이 좋습니다. 엔터프라이즈 경로는 유지되지만, Google의 발표 문맥은 Antigravity에 개발 에너지를 모으겠다는 쪽입니다. 기존 Gemini CLI 표준을 계속 둘지, Antigravity CLI를 신규 표준으로 둘지, 두 경로를 역할별로 나눌지 결정해야 합니다. 보안팀은 agent harness가 어떤 권한 경계와 로그를 남기는지도 같이 봐야 합니다.

결론: 터미널이 끝난 것이 아니라 소유권이 바뀝니다

Gemini CLI 전환은 터미널 AI 도구의 종말이 아닙니다. 오히려 터미널은 더 중요해질 가능성이 큽니다. 개발자는 여전히 shell, git, test runner, deployment CLI, log stream 안에서 일합니다. 에이전트가 실제 개발자의 환경에 들어오려면 터미널을 피할 수 없습니다.

다만 터미널 도구의 소유권이 바뀌고 있습니다. 예전의 AI CLI는 모델을 로컬 개발 흐름에 꽂는 비교적 독립적인 어댑터였습니다. 이제 대형 AI 회사들은 CLI를 에이전트 플랫폼의 진입점으로 재정의합니다. 사용자는 빠른 명령줄 경험을 얻는 대신, 플랫폼의 계정 체계, 권한 모델, 플러그인 생태계, 검증 표면, 제품 전환 일정에 묶입니다.

Google의 6월 18일 전환은 그 변화를 아주 직접적으로 보여줍니다. 10만 스타를 넘긴 Gemini CLI는 충분히 큰 개발자 기반을 만들었습니다. 그러나 Google이 앞으로 키우려는 것은 Gemini CLI 단독 제품이 아니라, Antigravity CLI와 Antigravity 2.0이 공유하는 단일 agent harness입니다. 코딩 에이전트 경쟁의 무게중심이 모델 호출에서 작업 운영 계층으로 이동했다는 뜻입니다.

개발자에게 남는 질문은 단순합니다. 나는 AI CLI를 가벼운 도구로 원하는가, 아니면 장시간 작업을 맡기는 에이전트 운영 표면의 일부로 원하는가. Gemini CLI에서 Antigravity CLI로의 전환은 이 질문을 더 이상 미룰 수 없게 만듭니다. 6월 18일은 단지 제품 지원 날짜가 아니라, 터미널 에이전트가 플랫폼 경쟁 안으로 본격적으로 들어가는 마감선입니다.