플랫폼의 핵심 엔진은 Gemini 3.5 Flash다. 이 모델은 에이전트 실행, 코딩 작업, 장기적 워크플로 수행을 위해 설계됐으며, 하위 에이전트(sub‑agent) 생성과 반복적 문제 해결 루프를 지원한다.

구글이 제시한 비전은 명확했다. 개발이 단순한 프롬프트 입력을 넘어 AI가 여러 단계의 소프트웨어 작업을 실제로 수행하는 구조로 이동한다는 것이다.

IDE에서 ‘에이전트 오케스트레이터’로의 변화

이전 Antigravity는 VS Code나 Cursor처럼 AI 기능이 강화된 코드 에디터와 비교되곤 했다.

하지만 Antigravity 2.0은 완전히 다른 방향을 택했다.

구글은 업데이트 과정에서 기존 IDE 중심 인터페이스를 제거하고, 제품을 에이전트 오케스트레이션 플랫폼으로 재정의했다.

새 환경의 핵심 기능은 다음과 같다.

• 여러 AI 에이전트 생성 및 협업 관리
• 작업을 하위 에이전트에게 위임
• 긴 비동기 작업 실행
• 에이전트가 만든 프로젝트와 아티팩트 관리

즉, 인간 개발자가 직접 코드를 다루기보다 AI 에이전트가 개발을 수행하고 인간은 감독하는 구조에 초점이 맞춰졌다.

개발자 반발이 커진 이유

문제는 개념 자체가 아니라 전환 방식이었다.

일부 사용자들은 업데이트가 강제 또는 사실상 자동으로 적용되었다고 주장했다. 이후 인터페이스가 크게 바뀌면서 기존 기능들이 사라졌다는 불만이 이어졌다.

대표적인 불만은 다음과 같다.

• 코드 에디터 제거
• 파일 트리(파일 탐색기) 삭제
• 터미널 접근 제한
• Agent View 중심의 채팅형 인터페이스 강제

일상적으로 코드 수정, 디버깅, Git 관리, 로컬 명령 실행 등을 수행하던 개발자들에게는 업그레이드가 아니라 기능 축소처럼 느껴졌다.

일부 사용자는 업데이트 후 WSL이나 원격 개발 환경이 정상 작동하지 않는다고 보고하기도 했다.

문제의 핵심은 ‘기능’이 아니라 ‘워크플로’

흥미로운 점은 많은 개발자들이 AI 코딩 도구 자체에는 긍정적이라는 사실이다.

하지만 실제 개발 과정은 여전히 다음과 같은 직접적인 작업 흐름에 크게 의존한다.

• 파일 직접 수정
• 터미널 명령 실행
• 버전 관리
• 인터랙티브 디버깅
• 컨테이너·WSL 같은 원격 환경 사용

이런 기본 도구 대신 에이전트 관리자 중심 인터페이스가 등장하면서 일부 개발자들은 오히려 속도가 느려지고 통제력이 줄었다고 느꼈다.

결국 일부 사용자는 이전 Antigravity 버전을 다시 설치하거나 VS Code 같은 기존 IDE로 돌아갔다는 보고도 나왔다.

더 큰 논쟁: 에이전트 개발 vs IDE 개발

Antigravity 2.0 논란은 단순한 제품 실패 논쟁이 아니다. 사실은 AI 개발 도구의 방향성에 대한 업계 전체의 갈등을 보여준다.

현재 두 가지 모델이 경쟁하고 있다.

1. AI 보조형 IDE
기존 IDE에 Copilot 같은 AI 기능을 추가해 코드 작성과 리팩토링을 돕는 방식.

2. 에이전트 중심 개발 플랫폼
개발자가 목표만 정의하면 AI 에이전트들이 실제 구현을 수행하는 방식.

Antigravity 2.0은 명확히 두 번째 모델에 베팅했다. 플랫폼 전체가 멀티 에이전트 협업과 자동화된 작업 실행을 중심으로 설계됐기 때문이다.

하지만 현재 많은 개발자들은 여전히 기존 IDE 내부에서 AI 도움을 받는 방식을 더 선호한다.

이번 사건이 보여준 것

Antigravity 2.0은 단순한 업데이트가 아니라 소프트웨어 개발의 미래에 대한 구글의 가설을 보여주는 실험이었다.

그 가설은 이렇다.

미래의 개발 환경에서 인간은 코드를 직접 작성하기보다 AI 에이전트를 관리하게 될 것이다.

하지만 이번 반발은 또 다른 현실을 보여준다.

개발자들은 자동화를 원하지만, 검증된 워크플로를 갑자기 포기하길 원하지는 않는다.

결국 많은 전문가들은 에이전트 기반 개발 도구가 성공하려면 **기존 IDE 경험과 에이전트 자동화를 함께 제공하는 ‘하이브리드 접근’**이 필요할 것이라고 보고 있다.

플랫폼의 핵심 엔진은 Gemini 3.5 Flash다. 이 모델은 에이전트 실행, 코딩 작업, 장기적 워크플로 수행을 위해 설계됐으며, 하위 에이전트(sub‑agent) 생성과 반복적 문제 해결 루프를 지원한다.

구글이 제시한 비전은 명확했다. 개발이 단순한 프롬프트 입력을 넘어 AI가 여러 단계의 소프트웨어 작업을 실제로 수행하는 구조로 이동한다는 것이다.

IDE에서 ‘에이전트 오케스트레이터’로의 변화

이전 Antigravity는 VS Code나 Cursor처럼 AI 기능이 강화된 코드 에디터와 비교되곤 했다.

하지만 Antigravity 2.0은 완전히 다른 방향을 택했다.

구글은 업데이트 과정에서 기존 IDE 중심 인터페이스를 제거하고, 제품을 에이전트 오케스트레이션 플랫폼으로 재정의했다.

새 환경의 핵심 기능은 다음과 같다.

• 여러 AI 에이전트 생성 및 협업 관리
• 작업을 하위 에이전트에게 위임
• 긴 비동기 작업 실행
• 에이전트가 만든 프로젝트와 아티팩트 관리

즉, 인간 개발자가 직접 코드를 다루기보다 AI 에이전트가 개발을 수행하고 인간은 감독하는 구조에 초점이 맞춰졌다.

개발자 반발이 커진 이유

문제는 개념 자체가 아니라 전환 방식이었다.

일부 사용자들은 업데이트가 강제 또는 사실상 자동으로 적용되었다고 주장했다. 이후 인터페이스가 크게 바뀌면서 기존 기능들이 사라졌다는 불만이 이어졌다.

대표적인 불만은 다음과 같다.

• 코드 에디터 제거
• 파일 트리(파일 탐색기) 삭제
• 터미널 접근 제한
• Agent View 중심의 채팅형 인터페이스 강제

일상적으로 코드 수정, 디버깅, Git 관리, 로컬 명령 실행 등을 수행하던 개발자들에게는 업그레이드가 아니라 기능 축소처럼 느껴졌다.

일부 사용자는 업데이트 후 WSL이나 원격 개발 환경이 정상 작동하지 않는다고 보고하기도 했다.

문제의 핵심은 ‘기능’이 아니라 ‘워크플로’

흥미로운 점은 많은 개발자들이 AI 코딩 도구 자체에는 긍정적이라는 사실이다.

하지만 실제 개발 과정은 여전히 다음과 같은 직접적인 작업 흐름에 크게 의존한다.

• 파일 직접 수정
• 터미널 명령 실행
• 버전 관리
• 인터랙티브 디버깅
• 컨테이너·WSL 같은 원격 환경 사용

이런 기본 도구 대신 에이전트 관리자 중심 인터페이스가 등장하면서 일부 개발자들은 오히려 속도가 느려지고 통제력이 줄었다고 느꼈다.

결국 일부 사용자는 이전 Antigravity 버전을 다시 설치하거나 VS Code 같은 기존 IDE로 돌아갔다는 보고도 나왔다.

더 큰 논쟁: 에이전트 개발 vs IDE 개발

Antigravity 2.0 논란은 단순한 제품 실패 논쟁이 아니다. 사실은 AI 개발 도구의 방향성에 대한 업계 전체의 갈등을 보여준다.

현재 두 가지 모델이 경쟁하고 있다.

1. AI 보조형 IDE
기존 IDE에 Copilot 같은 AI 기능을 추가해 코드 작성과 리팩토링을 돕는 방식.

2. 에이전트 중심 개발 플랫폼
개발자가 목표만 정의하면 AI 에이전트들이 실제 구현을 수행하는 방식.

Antigravity 2.0은 명확히 두 번째 모델에 베팅했다. 플랫폼 전체가 멀티 에이전트 협업과 자동화된 작업 실행을 중심으로 설계됐기 때문이다.

하지만 현재 많은 개발자들은 여전히 기존 IDE 내부에서 AI 도움을 받는 방식을 더 선호한다.

이번 사건이 보여준 것

Antigravity 2.0은 단순한 업데이트가 아니라 소프트웨어 개발의 미래에 대한 구글의 가설을 보여주는 실험이었다.

그 가설은 이렇다.

미래의 개발 환경에서 인간은 코드를 직접 작성하기보다 AI 에이전트를 관리하게 될 것이다.

하지만 이번 반발은 또 다른 현실을 보여준다.

개발자들은 자동화를 원하지만, 검증된 워크플로를 갑자기 포기하길 원하지는 않는다.

결국 많은 전문가들은 에이전트 기반 개발 도구가 성공하려면 **기존 IDE 경험과 에이전트 자동화를 함께 제공하는 ‘하이브리드 접근’**이 필요할 것이라고 보고 있다.