Gemini CLI 30일 전환, Antigravity가 삼킨 터미널

Google I/O 2026에서 가장 시끄러운 발표는 Gemini 3.5 Flash와 Gemini Spark였지만, 개발자 워크플로 관점에서 더 직접적인 변화는 Antigravity 쪽에 있었습니다. Google은 Antigravity 2.0 데스크톱 앱, Antigravity CLI, Antigravity SDK, Gemini API Managed Agents를 함께 공개했습니다. 그리고 같은 날 별도 공지에서 Gemini CLI 개인 사용자를 Antigravity CLI로 옮기겠다고 못 박았습니다.

핵심은 새 CLI가 하나 더 생겼다는 정도가 아닙니다. Google은 Gemini CLI가 터미널에서 Gemini를 쓰게 만든 실험이었다고 설명하면서도, 이제 개발자 요구가 여러 에이전트가 작업을 나누고 서로 상태를 공유하는 방향으로 옮겨갔다고 말합니다. 그래서 터미널도 독립된 명령줄 도구가 아니라 Antigravity라는 하나의 에이전트 플랫폼에 붙은 표면이 되어야 한다는 논리입니다.

그 논리는 제품 발표보다 전환 일정에서 더 선명합니다. Google Developers Blog의 공식 공지에 따르면 2026년 6월 18일부터 Gemini CLI와 Gemini Code Assist IDE 확장은 Google AI Pro, AI Ultra, 무료 Gemini Code Assist for individuals 사용자에게 더 이상 요청을 처리하지 않습니다. Gemini Code Assist for GitHub도 같은 날짜 이후 신규 GitHub 조직 설치가 막히고, 이후 요청 처리가 단계적으로 멈춥니다. 반면 Gemini Code Assist Standard, Enterprise, Google Cloud 기반 사용자는 접근이 유지됩니다.

개인 개발자에게는 짧은 전환 창입니다. 기업에게는 예외가 열려 있습니다. 이 분기가 이번 발표의 실제 메시지입니다. Google은 코딩 에이전트를 무료 터미널 실험에서 통합 실행 인프라와 과금, 조직 제어가 붙은 플랫폼으로 끌어올리고 있습니다.

Antigravity가 IDE 밖으로 나온 이유

Google이 I/O 개발자 하이라이트에서 제시한 문장은 "prompt에서 action으로의 전환"입니다. 공식 하이라이트 글은 Gemini 3.5 Flash가 Gemini 3.1 Pro보다 대부분의 벤치마크에서 앞서고 다른 frontier 모델보다 4배 빠르다고 주장합니다. 그리고 이 속도를 Antigravity harness와 연결합니다. 더 빠른 모델은 단발 답변보다 도구 호출, 파일 조작, 테스트 실행, 서브에이전트 분기처럼 반복 루프가 많은 코딩 에이전트에서 체감 차이를 만듭니다.

Antigravity 2.0은 이 루프를 IDE 내부 기능으로만 두지 않습니다. Google은 새 데스크톱 앱을 "agent-first" 표면으로 설명합니다. 동적 서브에이전트는 메인 에이전트가 작은 하위 작업을 따로 정의해 병렬로 실행하게 하고, 비동기 작업 관리는 긴 작업이 메인 흐름을 막지 않게 합니다. JSON hooks는 도구 호출 전후에 정책과 제어를 걸 수 있게 하고, scheduled tasks는 사람이 매번 호출하지 않아도 정해진 시간에 에이전트를 실행하게 합니다.

이 변화는 Cursor나 Claude Code와의 단순 IDE 경쟁보다 넓습니다. IDE는 여전히 중요하지만, 장기 실행 에이전트는 IDE 화면 안에서만 살기 어렵습니다. 리팩터링은 터미널과 CI를 지나고, 문서화는 저장소와 이슈 트래커를 지나며, 배포 검증은 클라우드 권한과 샌드박스를 만납니다. Google은 Antigravity를 이 흐름을 묶는 공통 harness로 만들려 합니다.

Gemini CLI의 종료가 말하는 것

Gemini CLI는 Google 내부에서도 꽤 성공한 실험으로 보입니다. 공식 전환 공지는 수백만 사용자, 10만 개 이상 GitHub stars, 6,000개 이상 merged pull requests, 수백 명 contributors를 언급합니다. 보통 이런 숫자는 제품을 접을 때보다 키울 때 쓰는 숫자입니다. 그런데 Google은 그 성공을 Gemini CLI 자체의 계속이 아니라 Antigravity CLI로의 흡수 근거로 사용했습니다.

이 지점이 흥미롭습니다. 개발자가 좋아한 것은 터미널 UI, 빠른 릴리스, 커뮤니티 확장성이었습니다. Google이 강조한 새 요구는 multi-agent reality입니다. 여러 에이전트가 배경에서 리팩터링을 나눠 맡고, 다른 에이전트가 조사를 돌리고, 또 다른 에이전트가 테스트와 검토를 맡는다면 터미널만으로는 상태 관리가 부족해집니다. 대화 기록, 권한, hooks, skills, MCP 서버, 플러그인, 샌드박스 정책을 여러 표면이 공유해야 합니다.

그래서 Antigravity CLI는 Gemini CLI의 후속이지만, Google이 보는 핵심 제품은 CLI가 아닙니다. 핵심은 server-side harness입니다. CLI는 그 harness에 붙은 빠른 조작 표면이고, 데스크톱 앱은 시각적 조율 표면이며, SDK는 프로그래밍 가능한 표면이고, Managed Agents는 API 상품입니다.

Google은 Antigravity CLI가 Gemini CLI의 중요한 기능을 유지한다고 설명합니다. Agent Skills, Hooks, Subagents, Extensions가 Antigravity plugins로 이어집니다. 하지만 같은 문단에서 1:1 기능 패리티가 바로 제공되지는 않는다고 말합니다. 즉, 기존 Gemini CLI를 도구라기보다 개발 환경 일부로 깊게 써온 팀은 단순 설치 변경 이상을 해야 합니다.

SDK는 에이전트 앱을 위한 내부 API에 가깝다

Antigravity SDK 발표는 더 기술적인 신호입니다. 공식 SDK 글은 Python preview 라이브러리인 google-antigravity를 소개합니다. 개발자는 Agent와 LocalAgentConfig로 에이전트 lifecycle을 열고, 파일 I/O, 코드 편집, shell 실행, 디렉터리 검색, 이미지 생성, sub-agent delegation 같은 built-in tools를 쓸 수 있습니다. 여기에 custom Python functions, MCP servers, agent skills를 같은 파이프라인에 얹을 수 있습니다.

중요한 것은 Google이 SDK를 "agent-friendly"하게 설계했다고 강조한 점입니다. Pydantic V2 모델, native Python collections, structured outputs, 명확한 naming conventions를 택해 사람뿐 아니라 코딩 에이전트가 SDK 코드를 읽고 수정하기 쉽게 만들었다는 설명입니다. 이 관점은 일반 SDK 문서와 조금 다릅니다. SDK의 1차 소비자가 인간 개발자만이 아니라, Antigravity 안에서 SDK 코드를 생성하고 고치는 에이전트라는 뜻입니다.

안전 정책도 제품화의 핵심입니다. SDK 문서는 기본 LocalAgentConfig가 built-in tools를 켜지만 shell 접근에는 confirm_run_command() 정책을 적용한다고 설명합니다. 완전히 자율적인 실행을 원하면 policy.allow_all() 같은 명시적 설정이 필요합니다. 이것은 작아 보이지만 에이전트 플랫폼 경쟁에서 중요한 기본값입니다. 에이전트가 파일을 읽고 명령을 실행하는 순간, 모델 품질보다 권한 경계와 감사 가능성이 실무 병목이 됩니다.

Google은 roadmap으로 remote harness, TypeScript와 Go 지원, Gemma integration, plugins, 더 깊은 observability를 제시했습니다. 특히 remote harness는 로컬 agent loop와 클라우드 배포를 같은 추상화로 바꾸려는 방향입니다. 로컬에서 만든 agent를 Interactions API로 접근 가능한 원격 실행 환경에 올리는 그림입니다. 이 로드맵이 실현되면 Antigravity SDK는 단순 로컬 자동화 라이브러리가 아니라 Google Cloud와 Gemini API로 이어지는 agent deployment SDK가 됩니다.

월 100달러 Ultra가 끼어든 이유

이번 발표에는 가격 신호도 있습니다. Google은 AI Ultra 구독을 월 100달러부터 시작한다고 밝혔고, Antigravity에서 AI Pro보다 5배 높은 사용 한도를 제공한다고 설명했습니다. 2026년 5월 25일까지는 한도에 도달할 경우 적용되는 100달러 보너스 크레딧도 제시했습니다.

이 숫자는 기사 제목으로만 보면 소비자 구독 뉴스처럼 보입니다. 하지만 코딩 에이전트 관점에서는 사용량 한도가 곧 제품 경험입니다. 에이전트는 사람이 채팅창에 한 번씩 질문하는 방식보다 훨씬 빠르게 토큰과 도구 호출을 소모합니다. 서브에이전트를 병렬로 띄우고, 테스트를 반복하고, 브라우저와 파일시스템을 오가며, 실패한 패치를 되돌리고 다시 시도하면 quota가 제품의 보이지 않는 벽이 됩니다.

따라서 Antigravity의 경쟁력은 "Gemini 3.5 Flash가 얼마나 똑똑한가"만으로 결정되지 않습니다. 같은 가격에서 몇 개의 agent loop를 돌릴 수 있는지, 실패한 실행을 얼마나 싸게 흡수할 수 있는지, 조직이 비용 폭주를 얼마나 빨리 감지할 수 있는지가 중요해집니다. Google이 Ultra 한도를 Antigravity와 함께 언급한 것은 우연이 아닙니다. 에이전트 플랫폼은 모델 판매보다 실행량 판매에 가깝습니다.

커뮤니티의 불편함은 제품 리스크다

출시 직후 Reddit의 GeminiCLI와 google_antigravity 관련 스레드에서는 불만이 적지 않았습니다. 일부 사용자는 Gemini CLI가 오픈소스이고 활발했으며, 그 위에 자신만의 커스텀 레이어를 쌓았는데 Antigravity CLI가 같은 식으로 유지될지 불확실하다고 말했습니다. 또 다른 사용자는 6월 18일이라는 날짜가 핵심 개발 도구 전환치고 빠르다고 봤습니다. Antigravity 2.0, Antigravity IDE, Antigravity CLI, 기존 Gemini CLI가 어떻게 다른지 묻는 글도 이어졌습니다.

이 반응을 단순 저항으로만 보면 놓치는 것이 있습니다. 개발자 도구의 신뢰는 기능 수보다 경로의 안정성에서 나옵니다. 어제까지 쓰던 CLI가 오늘부터 다른 플랫폼의 일부가 되고, 기존 IDE 확장의 요청 처리 일정이 달라지며, 무료/개인/기업 티어가 다르게 움직이면 개발자는 "이 도구 위에 내부 자동화를 더 쌓아도 되는가"를 다시 묻습니다.

반대로 Google의 논리도 이해할 수 있습니다. Gemini CLI가 커진 만큼, 터미널 도구 하나가 감당해야 할 기대도 커졌습니다. 다중 에이전트, 배경 작업, hooks, MCP, skills, 플러그인, 조직 권한, 원격 샌드박스, API 배포를 모두 한 프로젝트가 독립적으로 처리하기는 어렵습니다. 플랫폼 통합은 기술적으로 자연스러운 선택입니다. 문제는 그 전환을 사용자가 충분히 예측 가능하게 느끼느냐입니다.

OpenAI, Anthropic과 다른 Google식 답

OpenAI는 Codex와 Agents SDK, managed execution을 통해 모델과 작업 공간을 붙이고 있습니다. Anthropic은 Claude Code와 Agent SDK, MCP 생태계를 앞세워 개발자 워크플로에 깊게 들어갑니다. Cursor는 IDE 경험과 자체 모델/훈련 루프를 결합합니다. Google의 Antigravity 전략은 이 세 흐름을 한 번에 묶으려는 쪽에 가깝습니다. 데스크톱 앱, CLI, SDK, API, AI Studio, Android, Firebase, Google Cloud가 모두 같은 이름 아래 정렬됩니다.

이 전략의 장점은 통합입니다. 개발자는 AI Studio에서 만든 프로젝트를 Antigravity로 가져오고, CLI에서 시작한 대화를 데스크톱 앱에서 이어 보고, SDK로 custom agent를 만들고, Managed Agents로 원격 실행 환경을 붙일 수 있습니다. Google 생태계 안에서는 꽤 설득력 있는 이야기입니다.

약점도 같은 곳에 있습니다. 통합이 강할수록 독립 도구의 예측 가능성과 오픈 생태계의 유연성은 줄어들 수 있습니다. Gemini CLI 사용자에게 이번 발표가 반갑지만은 않은 이유입니다. 특히 기존 확장, hooks, MCP 서버, skills를 자동으로 옮길 수 있다 해도 조직 내부 스크립트, 문서, 권한 정책, CI 사용 방식은 사람이 검증해야 합니다.

개발자가 지금 점검할 것

가장 먼저 해야 할 일은 자신이 어느 경로에 있는지 확인하는 것입니다. Gemini CLI를 개인 Google 계정, 무료 Gemini Code Assist, AI Pro, AI Ultra로 쓰고 있다면 2026년 6월 18일이 실질적인 마감입니다. Gemini Code Assist Standard나 Enterprise, Google Cloud 경유 사용이라면 즉시 중단 대상은 아니지만, 팀이 Antigravity CLI와 2.0을 실험할 이유는 여전히 있습니다.

두 번째는 이식 가능한 자산을 분리하는 것입니다. AGENTS.md, SKILL.md, MCP 서버 설정, hooks, slash command, extensions가 어디에 저장되어 있고 어떤 권한을 요구하는지 확인해야 합니다. Google의 migration docs는 Gemini CLI extensions를 Antigravity plugins로 가져오는 경로를 제시하지만, 일부 요소는 1:1로 옮겨지지 않을 수 있습니다. 전환의 성패는 설치 명령보다 이런 작은 설정 파일에서 갈립니다.

세 번째는 비용과 실행 경계를 테스트하는 것입니다. Antigravity CLI가 더 빠르고 같은 harness를 쓴다고 해도, 다중 에이전트와 scheduled tasks를 켜면 사용량 패턴이 달라집니다. 개인 개발자는 quota 소진 지점을 봐야 하고, 팀은 누가 어떤 agent에게 shell 권한을 줄지, hooks로 무엇을 막을지, 로그를 어디까지 남길지 정해야 합니다.

결론: 터미널은 사라지지 않고 흡수된다

이번 발표를 "Google이 Gemini CLI를 종료한다"로만 읽으면 절반만 본 것입니다. 더 큰 변화는 터미널이 사라지는 것이 아니라 에이전트 플랫폼에 흡수되는 것입니다. 개발자는 여전히 CLI를 원합니다. 빠르고, 스크립트화할 수 있고, 원격 서버에서 쓸 수 있고, IDE보다 덜 무겁기 때문입니다. Google도 그것을 알고 있습니다. 그래서 Antigravity CLI를 새로 내놓았습니다.

다만 이제 CLI는 혼자 서 있지 않습니다. 같은 harness를 쓰는 데스크톱 앱, Python SDK, Gemini API Managed Agents, Google Cloud enterprise platform과 연결됩니다. 이것이 Google이 보는 코딩 에이전트의 다음 형태입니다. 개발자가 모델에게 코드를 묻는 단계가 아니라, 여러 agent loop를 운영하고 비용과 권한과 상태를 관리하는 단계입니다.

그래서 6월 18일은 단순한 제품 종료일이 아닙니다. Gemini CLI라는 성공한 커뮤니티 도구가 Antigravity라는 상위 플랫폼으로 편입되는 날짜입니다. 이 전환이 부드럽게 끝나면 Google은 코딩 에이전트 경쟁에서 강한 distribution과 인프라를 함께 얻게 됩니다. 반대로 이식성, quota, 기능 패리티, 초기 혼선이 길어지면 개발자는 더 독립적인 도구로 분산될 수 있습니다. Antigravity의 첫 시험대는 모델 벤치마크가 아니라, Gemini CLI 사용자의 손에 남아 있는 터미널 습관입니다.