Google Antigravity 2.0: IDE는 죽었다, 에이전트 오케스트라의 시대가 온다

이 글은 Google I/O Writing Challenge를 위한 제출물입니다.

내 IDE가 박물관 유물이 되었다고 깨달은 순간

저는 8년 동안 전문적으로 코딩을 해왔습니다. 저의 개발 환경은 신성합니다. 세심하게 설정된 Neovim 키 바인딩(keybindings), 없어서는 안 될 수십 개의 VS Code 확장 프로그램(extensions), 그리고 완성하는 데 몇 달이 걸린 터미널 설정까지 말이죠. 그래서 Google이 I/O 2026에서 Antigravity 2.0을 발표하며 이를 "에이전트 우선 개발 플랫폼(agent-first development platform)"이라고 불렀을 때, 저의 첫 본능은 이것을 내 삶을 자동 완성으로 없애버리려는 또 다른 AI 코딩 어시스턴트(AI coding assistant)로 치부하며 무시하는 것이었습니다.

그러다 데모를 보게 되었습니다. 소프트웨어 엔지니어링 디렉터인 Varun Mohan이 무대에 올라 AI 에이전트(AI agents) 군단을 지휘하여 작동 가능한 OS 커널(OS kernel)을 처음부터 구축하는 모습을 보여주었습니다. 단순한 장난감 예제가 아니었습니다. "Hello World"의 파생물도 아니었습니다. 메모리 관리(memory management), 프로세스 스케줄링(process scheduling), 파일 시스템 작업(filesystem operations)을 갖춘 실제 운영체제였습니다. 압권은 무엇이었을까요? 그는 그 완전히 새로운 OS 위에서 Doom 클론을 실시간으로 실행했습니다. 토큰 비용(Token cost): 1,000달러 미만. 경과 시간: 12분. 그때 깨달았습니다. Google은 내 IDE를 더 똑똑하게 만들려는 것이 아닙니다. 그들은 IDE를 쓸모없게 만들려 하고 있습니다.

Antigravity 2.0의 실체 (그리고 이것이 중요한 이유)

과장된 광고를 걷어내고 봅시다. Antigravity 2.0은 소프트웨어 개발에서 일어나고 있는 근본적인 변화에 대한 Google의 해답입니다. 작업의 단위(unit of work)는 더 이상 파일이나 코드베이스(codebase)조차 아니며, 바로 '태스크(task, 작업)'입니다.

이 플랫폼은 서로 연결된 다섯 가지 인터페이스(surfaces)로 제공됩니다:

• Desktop App: (VS Code 포크가 아닌) 완전히 멀티 에이전트 오케스트레이션 (multi-agent orchestration)을 중심으로 구축된 독립형 애플리케이션
• CLI (agy): 동일한 에이전트 하네스 (agent harness)를 사용하는 터미널 우선 워크플로우로, 속도를 위해 Go 언어로 작성됨
• SDK: 커스텀 에이전트를 구축하고 자신만의 도구를 통합할 수 있는 소프트웨어 개발 키트
• Managed Agents API: 에이전트를 실행하는 지속적인 서버 측 Linux 샌드박스 (sandboxes)
• Enterprise Platform: 거버넌스 (governance), 세션 메모리 (session memory), 컴플라이언스 (compliance) 제어 기능을 갖춘 Gemini Enterprise Agent Platform

이것이 GitHub Copilot, Cursor 또는 다른 어떤 AI 코딩 도구와 다른 점은 다음과 같습니다: Antigravity는 에이전트를 보조 도구가 아닌 '1급 시민 (first-class citizens)'으로 취급합니다.

병렬 실행의 게임 체인저 (The Parallel Execution Game-Changer)

I/O에서 발표된 기능 중 가장 과소평가된 기능은 무엇일까요? 바로 멀티 에이전트 병렬 오케스트레이션 (multi-agent parallel orchestration)입니다. 전통적인 개발 방식에서는 AI의 도움을 받더라도 근본적으로 직렬적 (serial)입니다. 함수를 작성하고, AI가 개선 사항을 제안하면, 이를 수락하거나 거절한 뒤 다음 함수로 넘어갑니다. 이 과정을 반복합니다. 순수하게 수동으로 코딩하는 것보다는 빠르지만, 여전히 한 번에 하나의 작업만 수행합니다.

Antigravity 2.0은 이 모델을 뒤집습니다.

"배포 설정(deployment configs)과 마이그레이션 계획(migration plan)을 생성해줘." 23분 후, 저는 다음과 같은 결과물을 얻었습니다: 명확한 경계를 가진 7개의 마이크로서비스(microservices), 각 서비스에 대한 OpenAPI 명세(specs), Docker Compose 및 Kubernetes 매니페스트(manifests), 롤백 단계가 포함된 단계별 마이그레이션 계획, 그리고 847개의 유닛 테스트(unit tests). 완벽했냐고요? 아니요. 인증 서비스(authentication service)는 재작업이 필요했고, 데이터베이스 마이그레이션 스크립트 중 하나에는 미묘한 레이스 컨디션(race condition)이 있었습니다. 하지만 제가 두려워하던 프로젝트에서 70%의 선행 진도를 뽑아주었습니다. 더 중요한 것은, 제가 며칠 동안 조사하고 계획해야 했을 올바른 아키텍처 선택(architectural choices)을 수행했다는 점입니다.

컨텍스트를 실제로 이해하는 CLI

이제 agy에 대해 이야기해 보겠습니다. 새로운 Antigravity CLI인 agy는 Google이 과감한 베팅을 한 지점입니다. 대부분의 AI 코딩 도구는 기존 워크플로우(workflows)에 덧붙여지는 방식입니다. IDE와 통합되거나 터미널에 자리 잡고 있지만, 근본적으로는 반응형(reactive)입니다. 사용자가 프롬프트(prompt)를 입력하면 응답합니다. 이들의 멘탈 모델(mental model)은 "보조자(assistant)"입니다. 하지만 agy는 다릅니다. 이는 처음부터 Go 언어로 구축되었으며(단순히 API를 감싼 래퍼(wrapper)가 아닙), 전체 개발 세션(development session) 동안 지속적인 컨텍스트(persistent context)를 유지합니다. 제가 테스트한 실제 워크플로우는 다음과 같습니다:

# 오전: 새로운 기능 시작
$ agy task create "Add rate limiting to all API endpoints"
# 에이전트(Agents)가 미들웨어(middleware), 테스트, 설정 스키마(config schema)를 생성합니다.
# 제가 검토하고 일부 변경 사항을 적용합니다.

# 오후: CI에서 무언가 깨짐
$ agy diagnose "why is the rate limiting test failing in CI?"
# 제가 어떤 컨텍스트도 제공하지 않았음에도, agy는 다음과 같이 동작합니다:
# - CI 로그를 가져옵니다.
# - 타임존(timezone) 가정 때문에 테스트가 실패하고 있음을 식별합니다.
# - 수정 사항을 제안합니다.
# - 적절한 커밋 메시지(commit message)와 함께 자동 커밋(auto-commits)합니다.

# 나중에: 제품 팀에서 변경 요청
$ agy modify "make rate limiting configurable per endpoint, not global"
# 에이전트들이 미들웨어를 리팩터링(refactor)하고, 테스트를 업데이트하며, 문서를 재생성합니다.

여기서 일어나지 않은 일들에 주목하십시오. 저는 에러 로그를 복사해서 붙여넣지 않았습니다. "rate limiting"이 무엇을 의미하는지 설명하지 않았습니다. 어떤 파일을 변경해야 하는지 지정하지도 않았습니다.

CLI는 나의 오전 세션으로부터 작업 컨텍스트 (task context)를 이해했으며, 하루 종일 그 이해를 유지했습니다. 이것이 바로 "에이전트 우선 (agent-first)"이 실제로 의미하는 바입니다. 에이전트는 당신이 호출하는 도구가 아니라, 작업 기억 (working memory)을 유지하는 협업자입니다.

경제학적 관점은 진정으로 놀랍습니다
가장 논란이 되는 부분인 가격 문제를 짚고 넘어갑시다. Antigravity 2.0은 월 100달러의 새로운 "AI Ultra" 티어를 도입했습니다. 저렴한 가격은 아닙니다. 참고를 위해 비교하자면 다음과 같습니다: GitHub Copilot: 월 10달러, Cursor: 월 20달러, Supermaven: 월 10달러. 하지만 여기서 계산이 흥미로워집니다. 아까 본 OS 커널 데모 말인가요? 11분 만에, 토큰 비용은 1,000달러 미만이었습니다. 보수적으로 잡아서, 시니어 개발자(시간당 150달러 기준)가 이를 수동으로 구축하는 데 2주(80시간)가 걸린다고 가정해 봅시다. 이는 12,000달러의 인건비입니다. 에이전트는 점심값도 안 되는 비용으로 이를 해냈습니다.

에이전트가 개발자를 대체할 것이라고 말하는 것은 아닙니다 (대체하지 못할 것입니다. 코드는 인간의 검토가 필요하고, 아키텍처 결정에는 판단력이 필요하며, 예외 케이스 (edge cases)에는 창의성이 요구되기 때문입니다). 하지만 에이전트는 특정 유형의 작업에 대한 경제학을 근본적으로 변화시킵니다:

• 레거시 코드베이스 (legacy codebases) 리팩토링
• 포괄적인 테스트 스위트 (test suites) 작성
• 프레임워크 또는 언어 마이그레이션
• 새로운 서비스의 스캐폴딩 (Scaffolding)
• 문서 생성

이것들은 모두 개발자들이 하기 싫어하지만 필수적인, 높은 노력과 낮은 창의성이 요구되는 작업들입니다. 바로 이 지점에서 에이전트가 빛을 발합니다.

Google이 놓친 부분 (그리고 이것은 중요합니다)
Antigravity 2.0은 인상적이지만 완벽하지는 않습니다. 세 가지 사항이 우려됩니다:

1. 락인 (Lock-In) 위험은 실재합니다
   기본적으로 모든 것이 Gemini 3.5 Flash에서 실행됩니다. 플랫폼 전체가 Google의 모델 스택 (model stack)에 깊게 결합되어 있습니다. 만약 Antigravity에서 복잡한 멀티 에이전트 워크플로우 (multi-agent workflow)를 구축한다면, 당신은 Google의 인프라, 가격 정책, 그리고 모델 로드맵에 종속되는 것입니다. Claude, GPT-4, 그리고 로컬 모델 사이를 전환할 수 있게 해주는 Cursor와 비교해 보십시오. 또는 설계 단계부터 모델 불가지론적 (model-agnostic)인 LangChain과 비교해 보십시오. Google의 폐쇄적인 정원 (walled garden) 접근 방식은 더 나은 최적화를 제공할 수 있지만, 개발자의 유연성을 감소시킵니다.

기업용 기능은 유료 결제 장벽(Paywall) 뒤에 있습니다. 세션 메모리(Session memory), 중앙 집중식 거버넌스(Centralized governance), 컴플라이언스 제어(Compliance controls) — 이것들은 기업 도입을 위한 '있으면 좋은 기능(nice-to-haves)'이 아닙니다. 이것들은 필수 요구 사항입니다. 그리고 이 모든 기능은 Gemini Enterprise Agent Platform 티어 뒤에 잠겨 있습니다. 이는 개별 개발자는 데스크톱 앱으로 실험할 수 있지만, 기업은 대규모 계약 협상 없이는 이를 도입할 수 없는 기묘한 역학 관계를 만듭니다. Google이 개발자 마케팅을 통한 바이럴 채택(Viral adoption)과 라이선싱을 통한 기업 수익이라는 두 마리 토끼를 모두 잡으려 하는 것처럼 느껴집니다.

3. "마법" 문제
   에이전트(Agent)가 제대로 작동할 때는 마법 같습니다. 하지만 실패할 때는 도저히 이해할 수 없는 방식으로 실패합니다. 저는 Antigravity 2.0에 데이터베이스 쿼리(Database query) 최적화를 요청했습니다. 에이전트는 쿼리를 다시 작성하고, 인덱스(Indexes)를 업데이트하며, 캐싱 전략(Caching strategy)을 변경했습니다. 성능은 40% 향상되었습니다. 훌륭합니다! 하지만 왜일까요? 어떤 변경 사항이 차이를 만든 것일까요? 만약 새벽 3시에 운영 환경(Production)에서 이를 디버깅(Debug)해야 한다면, 저는 에이전트가 무엇을 했는지 이해할 수 있을까요? Google에는 더 나은 설명 가능성(Explainability) 도구가 필요합니다. 단순히 "무엇이 바뀌었는지" 보여주는 차이점(Diffs)이 아니라, "왜 이러한 선택을 했는지"에 대한 추론 로그(Reasoning logs)가 필요합니다.

더 큰 그림: 이 모든 것이 향하는 곳
Antigravity 2.0은 단순히 더 빠르게 코딩하는 것에 관한 것이 아닙니다. 이는 소프트웨어 개발이 나아갈 방향에 대한 예고편입니다. 5년 뒤, 저는 다음과 같이 예측합니다:

• 주니어 개발자는 보일러플레이트(Boilerplate) 코드를 작성하는 대신 에이전트를 오케스트레이션(Orchestrate)할 것입니다.
• 시니어 개발자는 아키텍처(Architecture)와 에지 케이스(Edge cases)에 집중할 것입니다.
• "에이전트를 위한 프롬프트 엔지니어링(Prompt engineering for agents)"은 오늘날의 Git처럼 핵심 기술이 될 것입니다.
• 병목 현상(Bottleneck)은 코드를 작성하는 것이 아니라, 요구 사항을 이해하고 트레이드오프(Tradeoffs)를 결정하는 것이 될 것입니다.

이러한 변화는 이미 일어나고 있습니다. Devin, Claude Code, 그리고 이제 Antigravity 2.0과 같은 도구들은 에이전트가 단순히 다음 줄을 자동 완성(Autocomplete)하는 것이 아니라, 전체 워크플로(Workflows)를 처리할 수 있다는 개념을 일반화하고 있습니다. 번창할 개발자는 가장 빠르게 코딩할 수 있는 사람이 아닐 것입니다. 시스템 수준에서 사고하고, 문제를 에이전트 작업(Agentic tasks)으로 분해하며, 기계가 생성한 코드를 비판적인 시각으로 검토할 수 있는 사람이 될 것입니다.

실제로 이것을 사용해야 할까요? 일주일간의 테스트를 거친 후 저의 솔직한 권장 사항은 다음과 같습니다.

Antigravity 2.0을 사용해야 하는 경우:

• 주로 Google 생태계(Firebase, Android, Google Cloud)에서 작업하는 경우
• 대규모 리팩토링 (Refactoring) 또는 마이그레이션 (Migration) 프로젝트를 진행하는 경우
• 생성된 코드를 검토하고 디버깅 (Debugging)하는 데 능숙한 경우
• 모델의 유연성보다 병렬 에이전트 오케스트레이션 (Parallel agent orchestration)을 더 가치 있게 여기는 경우

Antigravity 2.0을 건너뛰어야 하는 경우:

• 모델 불가지론적 (Model-agnostic) 도구가 필요한 경우
• 회사가 자체 호스팅 (Self-hosted) 솔루션을 요구하는 경우
• AI 코딩 도구를 이제 막 시작하는 단계인 경우 (Copilot이나 Cursor로 시작하세요)
• 학습 데이터가 제한적인 언어/프레임워크에서 작업하는 경우

저에게 Antigravity 2.0은 제 도구 모음(Toolkit)에서 영구적인 자리를 차지했지만, 모든 것을 대체하지는 않았습니다. 빠른 편집을 위해서는 여전히 Neovim을 사용합니다. 복잡한 코드베이스 (Codebase)를 설명할 때는 여전히 Claude를 사용합니다. 하지만 지속적인 노력과 여러 파일에 걸친 조정이 필요한, 그동안 미뤄왔던 프로젝트를 해결해야 할 때는 가장 먼저 agy를 찾습니다.

I/O 2026의 진짜 핵심 요약
Google의 베팅은 명확합니다. 개발의 미래는 에이전트 중심 (Agentic)입니다. AI 보조 (AI-assisted)도 아니고, AI 증강 (AI-augmented)도 아닙니다. 에이전트 중심 (Agentic)입니다. 에이전트가 당신의 다음 명령을 기다리는 도구가 아니라, 주체성 (Agency)을 가진 독립적인 행위자가 되는 시대입니다.

Antigravity 2.0이 표준이 될지, 아니면 Google의 실험실 유물 중 하나로 남을지는 지켜봐야 합니다. 하지만 이 도구가 도입한 개념들 — 멀티 에이전트 오케스트레이션 (Multi-agent orchestration), 작업 수준의 추상화 (Task-level abstractions), 지속 가능한 샌드박스 (Persistent sandboxes) — 은 앞으로도 계속 유지될 것입니다. 우리가 알고 있는 형태의 IDE는 이제 박물관에나 갈 유물이 되었습니다.

여러분은 Antigravity 2.0을 이미 사용해 보셨나요? 경험이 어떠셨나요? 댓글을 남겨주세요. 제 경험이 다른 분들과 일치하는지, 아니면 저 혼자만 이 열기에 취해 있는 것인지 궁금합니다.