Antigravity 2.0, IDE 밖으로 나온 에이전트 지휘소

Google I/O 2026에서 가장 시끄러운 이름은 Gemini 3.5 Flash와 Gemini Omni였지만, 개발자 워크플로 관점에서 더 오래 남을 수 있는 발표는 Antigravity 2.0입니다. Google은 2026년 5월 19일 공식 개발자 하이라이트 글에서 Antigravity 2.0 데스크톱 앱, Antigravity CLI, Antigravity SDK, Gemini API의 Managed Agents, AI Studio의 Android 앱 생성 흐름을 한꺼번에 묶어 소개했습니다. 발표 문장만 보면 "새 코딩 도구"처럼 들리지만, 실제 방향은 더 큽니다. Google은 IDE 플러그인 하나를 개선하는 대신, 에이전트가 작업을 시작하고, 나누고, 실행하고, 저장하고, 다시 이어받는 표면 전체를 자사 하네스 위로 모으려 합니다.

이 차이가 중요합니다. 코딩 에이전트 시장은 이미 자동완성 경쟁을 지나갔습니다. 사용자는 모델이 한 함수의 다음 줄을 맞히는지보다, 긴 작업을 얼마나 잘 쪼개는지, 로컬 파일과 터미널을 어디까지 만지게 할 수 있는지, 샌드박스와 권한은 어떻게 관리되는지, 비용이 어느 시점에 터지는지, 그리고 에이전트가 남긴 산출물을 사람이 어떻게 검토하는지를 묻고 있습니다. Cursor Cloud Agent, OpenAI Codex, Claude Code, GitHub Copilot, Anthropic Managed Agents가 모두 같은 전선을 보고 있습니다. Antigravity 2.0은 Google이 이 전선에서 "IDE"가 아니라 "운영판"을 들고 나온 사건에 가깝습니다.

Google 공식 블로그는 Antigravity 2.0을 "standalone desktop application"으로 설명합니다. 역할은 중앙 홈입니다. 여러 에이전트를 동시에 띄우고, 각각이 독립 작업을 수행하는 동안 사용자가 감시하고 개입할 수 있는 장소입니다. 여기에 동적 서브에이전트, 예약 작업, AI Studio, Android, Firebase 통합이 붙습니다. 이 구성을 보면 Google이 단순히 VS Code류 편집기 안에 더 똑똑한 챗봇을 넣으려는 것이 아니라는 점이 보입니다. 개발자의 화면은 편집기, 터미널, 브라우저, 클라우드 콘솔, 모바일 앱 테스트, 배포 콘솔로 나뉘어 있습니다. Google은 그 경계를 에이전트가 넘나들 수 있게 만들고, 사람은 여러 작업의 진행 상태와 결과물을 보는 쪽으로 이동시키려 합니다.

Antigravity CLI는 이 전략의 두 번째 축입니다. Google은 터미널을 선호하는 사용자를 위해 경량 표면을 제공한다고 설명하면서, Gemini CLI 사용자의 Antigravity CLI 이전을 권장했습니다. 이 문장은 작지만, 제품 전략으로는 무겁습니다. Google이 별도 CLI 브랜드를 계속 병렬 운영하기보다 Antigravity라는 이름 아래 CLI 경험까지 통합하려 한다는 뜻이기 때문입니다. 개발자에게 CLI는 단순 보조 도구가 아닙니다. CI 스크립트, 로컬 자동화, 원격 서버 작업, 코드 리뷰 루틴이 섞이는 작업 표면입니다. CLI를 Antigravity 하네스 안으로 넣는다는 것은 에이전트 실행 단위와 권한, 로그, 설정, 쿼터 감각을 같은 체계로 묶겠다는 신호입니다.

세 번째 축은 SDK입니다. Antigravity SDK는 Google 제품을 구동하는 동일한 에이전트 하네스에 프로그래밍 방식으로 접근하게 한다고 소개됐습니다. 공식 제품 데이터에는 Python으로 설치하는 흐름이 보이며, 파일 읽기, 명령 실행, 코드 편집 같은 에이전트 루프와 컨텍스트 관리를 추상화한다고 설명됩니다. 여기서 Google이 노리는 대상은 일반 사용자만이 아닙니다. 에이전트를 제품 안에 넣으려는 개발팀, 사내 개발 플랫폼을 만드는 조직, 특정 업무용 에이전트를 자체 인프라에 올리고 싶은 팀까지 포함됩니다. SDK가 있다는 것은 Antigravity가 앱 하나로 끝나지 않고, 외부 개발자가 자기 도메인 에이전트를 만드는 런타임 계층으로 확장될 수 있다는 뜻입니다.

네 번째 축은 Gemini API의 Managed Agents입니다. Google은 단일 API 호출로 추론하고, 도구를 쓰고, 코드를 실행하는 에이전트를 띄울 수 있으며, 격리된 Linux 환경과 지속 상태를 제공한다고 설명했습니다. 이 부분은 OpenAI Agents SDK의 샌드박스, Anthropic Managed Agents와 직접 비교되는 지점입니다. 개발팀 입장에서는 "모델 API를 호출한다"에서 "작업 환경을 가진 에이전트 인스턴스를 운영한다"로 사고방식이 바뀝니다. 단발성 텍스트 응답이 아니라 파일과 상태를 가진 장기 세션을 관리해야 하고, 실패한 작업을 재개하거나 검사할 수 있어야 하며, 보안팀은 해당 환경이 어떤 네트워크와 파일 권한을 갖는지 확인하려 합니다.

Google이 이 흐름을 AI Studio와 Android까지 연결한 것도 눈여겨볼 대목입니다. Android Developers Blog는 AI Studio가 프롬프트만으로 Kotlin 기반 네이티브 Android 앱을 만들고, 브라우저 안의 Android Emulator에서 미리 보며, ADB로 실제 기기에 설치하고, Google Play 내부 테스트 트랙에 올릴 수 있다고 설명했습니다. 또한 고급 도구가 필요하면 Android Studio, GitHub, Antigravity로 넘길 수 있다고 했습니다. 이 흐름은 "아이디어를 앱으로"라는 소비자형 문구처럼 보이지만, 개발자 도구 시장에서는 더 구체적인 의미가 있습니다. Google은 에이전트가 생성한 코드가 로컬 IDE에서만 끝나지 않고 테스트, 기기 설치, Play Console, Firebase, Cloud까지 이어지는 파이프라인을 만들고 있습니다.

이렇게 보면 Antigravity 2.0의 진짜 경쟁자는 특정 IDE 하나가 아닙니다. Cursor가 장기 실행 에이전트를 클라우드 VM으로 올리고, OpenAI가 Codex와 Agents SDK에서 샌드박스와 파일 작업을 밀고, Anthropic이 Claude Code와 Managed Agents를 엔터프라이즈 워크플로에 붙이는 흐름 전체가 경쟁 구도입니다. Google은 여기에 Android, Firebase, AI Studio, Gemini API, Google Cloud라는 자체 배포면을 얹을 수 있습니다. 개발자에게는 매력적이지만 동시에 잠금 효과도 커집니다. 에이전트가 코드를 쓰고 테스트하고 배포 콘솔까지 이어질수록, 그 하네스 안에서 생긴 컨텍스트와 설정, 스킬, 히스토리를 다른 도구로 옮기기 어려워집니다.

동적 서브에이전트는 이 전략을 잘 보여주는 기능입니다. 공식 제품 페이지의 번들 데이터는 복잡한 문제를 병렬 부분으로 나누기 위해 서브에이전트를 동적으로 정의하고 생성한다고 설명합니다. 개발자는 예전에는 한 챗봇에게 순서대로 "테스트 고쳐", "문서 업데이트해", "리팩터링해"라고 말했습니다. 이제 플랫폼은 작업을 하위 에이전트에게 나누고, 각 에이전트가 별도 세션에서 진행 상황을 만들며, 사용자는 승인과 피드백을 통해 방향을 잡는 방식을 제안합니다. 이것이 잘 작동하면 대규모 변경의 처리량은 올라갑니다. 그러나 잘못 작동하면 충돌 난 브랜치, 중복된 수정, 서로 다른 에이전트가 가정한 요구사항 불일치, 어디서 비용이 발생했는지 알기 어려운 실행 로그가 생깁니다.

그래서 이번 발표의 초기 커뮤니티 반응이 중요합니다. r/google_antigravity에는 5월 22일 "Antigravity IDE Feedback"이라는 글이 올라왔고, Google 관계자로 보이는 계정은 지난 며칠간 IDE 관련 피드백을 받았으며 IDE 지원을 제거하려던 의도가 아니었다고 설명했습니다. 또한 2.0에서 IDE 연결 방법을 더 명확히 하고, Windows에서 IDE 열기 문제를 고치고, IDE 설정과 확장 복원 안내를 제공했으며, 모두의 Gemini 주간 사용량을 다시 리셋하겠다고 했습니다. 이 공지는 기능 설명보다 더 많은 것을 말합니다. 에이전트 개발 플랫폼에서 "새 앱으로 옮기세요"는 단순 다운로드 안내가 아닙니다. 사용자가 쌓아둔 설정, 키바인딩, 확장, 워크스페이스, 대화 히스토리, 비용 감각을 모두 건드리는 이전 작업입니다.

댓글에서도 같은 긴장이 보입니다. 일부 사용자는 Google이 빠르게 반응했고 IDE가 계속 유지된다는 점에 긍정적으로 반응했습니다. 반면 다른 사용자는 워크스페이스와 대화 연결이 깨졌다고 말했고, 주간 한도를 한 작업의 일부에서 다 써버렸다는 불만, 지출 한도를 앱 안에서 보고 싶다는 요구, 이전 Flash 모델을 돌려달라는 요청, 보안 제품이 Antigravity를 서명 문제로 경고한다는 질문도 있었습니다. 이 반응을 과장할 필요는 없습니다. 초기 대형 업데이트에는 늘 이관 문제가 있습니다. 다만 이번에는 문제가 더 구조적입니다. 에이전트가 더 많은 표면을 통제할수록, 사용자는 더 명확한 경계와 더 예측 가능한 비용 신호를 요구합니다.

Google 공식 블로그의 가격 관련 문구도 이 전환을 드러냅니다. 발표 당시 Google은 AI Ultra 구독을 월 100달러부터 시작한다고 소개했고, Antigravity에서 AI Pro보다 5배 높은 사용 한도를 제공한다고 밝혔습니다. 또한 5월 25일까지 Antigravity 앱에서 청구할 수 있는 100달러 보너스 크레딧을 언급했습니다. 코딩 에이전트에서 가격은 부록이 아닙니다. 한 번의 긴 작업이 여러 모델 호출, 파일 읽기, 도구 실행, 서브에이전트 병렬 처리, 검증 루프를 포함하기 때문입니다. 사용자가 "프롬프트 몇 번"이 아니라 "작업 하나"를 기준으로 비용을 느끼는 순간, 플랫폼은 토큰보다 작업 단위의 예측 가능성을 제공해야 합니다.

이 지점에서 Antigravity 2.0은 좋은 질문을 던집니다. 코딩 에이전트의 단위는 앞으로 무엇입니까? 채팅 메시지입니까, IDE 세션입니까, 프로젝트입니까, 작업 티켓입니까, 아니면 API에서 재개 가능한 실행 환경입니까? Google의 답은 점점 "프로젝트와 에이전트 실행" 쪽으로 기웁니다. Antigravity 제품 데이터에는 프로젝트가 여러 폴더를 span하고, 사용자 지정 설정과 scoped permissions를 지원한다는 설명이 있습니다. 또한 스킬, MCP, JSON hooks로 에이전트 행동을 확장할 수 있다고 소개합니다. 이것은 ChatGPT식 대화 인터페이스보다 훨씬 개발 플랫폼에 가깝습니다. 문제는 그만큼 설정 표면도 늘어난다는 점입니다. 조직은 누가 어떤 스킬을 설치할 수 있는지, MCP 서버가 어떤 데이터에 닿는지, hook이 어떤 명령을 실행하는지 관리해야 합니다.

Managed Agents는 이 질문을 API로 끌고 갑니다. 격리 Linux 환경과 지속 상태는 실무적으로 강력합니다. 예를 들어 에이전트가 레포를 체크아웃하고, 테스트를 실행하고, 파일을 만들고, 다음 호출에서 같은 상태를 이어받을 수 있다면 긴 백그라운드 작업을 API 제품에 넣기 쉬워집니다. 그러나 이 기능은 보안, 감사, 재현성 요구도 함께 올립니다. 에이전트가 어느 파일을 읽었는지, 어떤 명령을 실행했는지, 실패한 뒤 어떤 상태가 남았는지, 민감한 토큰을 어떻게 다뤘는지가 운영 이슈가 됩니다. Google이 Antigravity 하네스를 Gemini 모델과 같이 최적화했다고 설명하는 만큼, 개발팀은 편의성과 종속성 사이의 균형을 따져야 합니다.

AI Studio의 Android 흐름도 마찬가지입니다. 프롬프트에서 네이티브 앱을 만들 수 있다는 말은 강력하지만, 실제 앱은 생성 순간보다 유지보수 순간에 평가됩니다. Kotlin과 Jetpack Compose, 하드웨어 API, Firebase Auth, Firestore, Play 내부 테스트 트랙까지 이어질수록, 생성된 앱은 단순 데모를 넘어 진짜 제품의 표면을 갖습니다. 그러면 질문은 "만들 수 있나"에서 "검토 가능한 구조인가", "팀 규칙을 따르나", "테스트와 릴리스 권한이 분리됐나", "개인 계정이 아니라 조직 계정 기준으로 운영되나"로 바뀝니다. Antigravity가 이 흐름의 로컬 개발 종착지로 제시된 점은 Google이 Android 개발 생태계까지 에이전트 워크플로 안에 넣고 싶어 한다는 신호입니다.

흥미로운 점은 Google이 이번 발표에서 에이전트의 추상화를 상위로 끌어올리면서도, 커뮤니티는 매우 구체적인 불편을 말하고 있다는 점입니다. "Open IDE 버튼이 어디 있나", "설정과 확장이 복원되나", "주간 한도가 얼마나 남았나", "Flash 모델이 왜 없어졌나", "Windows에서 IDE가 열리나", "보안 소프트웨어가 왜 경고하나" 같은 질문입니다. 이 간극은 AI 개발 도구가 실제 업무 도구가 될수록 더 자주 나타날 것입니다. 회사의 비전은 에이전트 운영 플랫폼이지만, 사용자의 하루는 키바인딩과 터미널 세션과 빌드 실패로 이루어져 있습니다. 전자가 후자를 매끄럽게 흡수하지 못하면, 아무리 강한 모델도 도구 이탈을 막기 어렵습니다.

개발팀이 지금 Antigravity 2.0을 볼 때 확인해야 할 것은 세 가지입니다. 첫째, 기존 IDE와 CLI 워크플로를 얼마나 보존하는지입니다. 에이전트 지휘소가 편해도 팀의 로컬 개발 규칙을 깨면 도입 비용이 커집니다. 둘째, 사용량과 비용이 작업 단위로 설명되는지입니다. 여러 서브에이전트가 병렬로 움직이는 플랫폼에서는 남은 프롬프트 수보다 작업별 예상 비용과 중단 기준이 더 중요합니다. 셋째, 스킬, MCP, hooks, SDK를 조직 정책으로 관리할 수 있는지입니다. 에이전트가 파일과 명령과 외부 서비스를 다루는 순간, 확장성은 곧 공급망과 권한 문제가 됩니다.

그럼에도 Antigravity 2.0은 Google이 늦게 뛰어든 단순 추격자라고 보기 어렵습니다. Google은 모델, Android, 브라우저, Firebase, Cloud, Play, Workspace를 모두 갖고 있습니다. 이 표면들이 Antigravity 하네스와 Gemini API Managed Agents로 연결되면, 개발자는 프롬프트에서 앱 초안, 로컬 수정, 테스트, 내부 배포, 클라우드 리소스 연결까지 한 흐름에서 처리할 수 있습니다. 경쟁 도구들은 더 날카로운 IDE 경험이나 더 빠른 코딩 루프를 제공할 수 있지만, Google은 플랫폼 표면의 폭으로 승부할 수 있습니다. 그래서 이번 발표의 핵심은 "Google도 코딩 에이전트를 냈다"가 아닙니다. Google이 자사 생태계의 흩어진 개발 표면을 에이전트 실행 하네스 하나로 묶기 시작했다는 점입니다.

결론적으로 Antigravity 2.0의 첫 주는 두 가지를 동시에 보여줍니다. 하나는 코딩 에이전트가 더 이상 편집기 사이드바에 머물지 않는다는 점입니다. 독립 앱, CLI, SDK, API 실행 환경, Android 생성 도구가 모두 같은 지휘소로 모이고 있습니다. 다른 하나는 이 변화가 사용자에게 꽤 거칠게 체감될 수 있다는 점입니다. IDE 지원을 명확히 하고 사용량을 리셋해야 했던 초기 대응은 작은 해프닝이 아니라, 에이전트 플랫폼 전쟁의 다음 병목을 보여줍니다. 앞으로 승자는 가장 똑똑한 모델을 가진 회사가 아니라, 에이전트가 작업하는 동안 개발자가 맥락, 비용, 권한, 검증을 잃지 않게 만드는 회사일 가능성이 큽니다.