에디터에서 에이전트 관리로 — Google Antigravity 2.0이 알리는 Agent OS의 등장

이 글은 제 블로그의 내용을 미러링한 것입니다. 원문: https://okikusan-public.pages.dev/antigravity-agent-os.en Antigravity 2.0은 단순한 AI-IDE 업데이트가 아닙니다. 이는 개발자 경험 (Developer Experience)의 중심축이 "에디터 (the editor)"에서 "에이전트 관리 (agent management)"로 이동하는 순간입니다. Desktop / CLI / SDK / 통합 (integration) 퍼널은 이제 Claude Code / Codex / Grok Build와 같은 "전문가용 작업 도구 (specialist worker)"를 넘어, 하나의 Agent OS처럼 보이기 시작했습니다. 기존의 축이었던 "어떤 모델이 더 똑똑한가"는 더 이상 충분하지 않습니다. 하네스 (Harness) 설계, 권한 경계 (permission boundaries), 컨텍스트 (context), 예약된 실행 (scheduled execution), 그리고 인간의 검토 (human review) — 이 다섯 가지가 현재 개발자 생산성을 결정합니다. AI 코딩의 다음 전장이 펼쳐졌습니다.

▍ 출처 (SOURCES)
Google Antigravity — 공식 사이트
@antigravity의 출시 발표
Gemini CLI를 Antigravity CLI로 전환 (Google Developers Blog)
Google, Antigravity 2.0 출시 (TechCrunch)
Antigravity 2.0 = 독립적인 에이전트 우선 플랫폼 (MarkTechPost)
공식 출시 영상: https://www.youtube.com/watch?v=6C0FjHoN3qE

▍ 용어 (TERMS) — 정의 및 전제
에이전트 하네스 (Agent harness) — 모델을 감싸는 런타임 (runtime). Karpathy의 정의에 따르면, 에이전트 (Agent) = 모델 (Model) + 하네스 (Harness) 입니다. 구체적으로 하네스는 다음을 결합합니다:

• 시스템 프롬프트 (System prompts) / 역할 정의 (role definitions)
• 도구 (Tools) (파일 작업, Bash, 웹 페치, MCP 외부 호출 등)
• 메모리 (Memory) / 상태 (state)
• 권한 (Permissions) 및 가드레일 (guardrails)
• 피드백 루프 (Feedback loop) (재시도, 검증, 하위 에이전트 생성)

실제 사례:
Claude Code의 하네스 = CLI 에이전트 루프 + 도구 세트 + 프로젝트 권한
Cursor의 하네스 = 에디터 통합 + Apply 메커니즘 + 코드베이스 인덱스 (codebase index)
Antigravity의 하네스 = 로컬 앱 서버 + 런타임 + 스킬 팩 (Skill pack) 부착

동일한 모델이라도 하네스가 다르면 → 극적으로 다른 동작을 보입니다. 하네스는 에이전트가 실제로 어떻게 행동하는지를 결정하는 부분입니다.

Agent OS 레이어 (Agent OS layer) / 전문가 워커 레이어 (Specialist worker layer)

Agent OS 레이어 = 여러 UI, 권한 (permissions), 스케줄러 (scheduler), 에이전트 오케스트레이션 (Agent orchestration; Antigravity / Hermes / Copilot Studio)에 걸쳐 하나의 하네스 (harness)를 공유합니다.

전문가 워커 레이어 (Specialist worker layer) = 작업을 수행하기 위해 호출됩니다 (Claude Code / Codex CLI / Grok Build).

"Agent OS"는 Google의 공식 용어가 아니며, 커뮤니티의 프레임워크 및 이 기사의 편집적 관점입니다.

서브에이전트 (Subagent) — 부모 에이전트에 의해 동적으로 생성된 자식 에이전트. Antigravity 2.0의 출시 데모는 93개의 병렬 서브에이전트를 가진 OS를 구축했습니다.

스킬 (Skill) — 에이전트에 부착하는 플러그형 기능 패키지. Android Skills / Firebase Skills는 특정 도메인의 API와 컨벤션 (conventions)을 하네스에 추가합니다.

앱 서버 (App server) — Antigravity 설치 내부에 공유되는 로컬 백엔드 (backend). 데스크톱 UI와 CLI 바이너리 모두 동일한 이 앱 서버를 호출합니다.

다섯 가지 비교 축 (comparison axes) — (1) 하네스 설계 (harness design) / (2) 권한 경계 (permission boundaries) / (3) 컨텍스트 (context) / (4) 스케줄링된 실행 (scheduled execution) / (5) 인간의 검토 (human review).

요약 (TL;DR): Antigravity 2.0은 Desktop / CLI / SDK / AI Studio × Android × Firebase 통합입니다. 이는 흩어진 기능들의 묶음이 아니라, 네 개의 UI에 걸쳐 공유되는 하나의 에이전트 하네스입니다. Claude Code / Codex / Grok Build는 전문가 워커 레이어에 위치하며, Antigravity 2.0은 이들을 결합하는 Agent OS 레이어에 위치합니다. "대결(VS)" 구도는 레이어 전반에 걸쳐 붕괴됩니다. 중요한 축은 다음과 같습니다: (1) 어떤 하네스인가 / (2) 어떤 권한 경계인가 / (3) 어떤 컨텍스트인가 / (4) 어떤 스케줄링된 실행인가 / (5) 어떤 인간의 검토인가.

개인 사용자: Hermes (OSS)를 Antigravity 네이티브와 결합하십시오.
기업 사용자: Copilot Studio / Workspace Studio / Antigravity 중 횡단적인 선택을 하십시오.

에디터 전용 비교는 이제 한 세대 뒤처졌습니다.

§ 01 전환 (SHIFT) — 에디터에서 에이전트 관리로

지난 2년간의 AI 코딩 도구들은 에디터를 중심으로 서술되어 왔습니다: Copilot, Cursor, Claude Code, Codex CLI, Grok Build. 이들은 모두 "AI가 에디터 내부에서 코드를 작성한다"는 전제하에 진화했습니다. Antigravity 2.0은 그 프레임을 깨뜨립니다. 이것은 AI-IDE의 업데이트가 아닙니다.

이것은 Desktop / CLI / SDK / AI Studio 통합을 한 번에 조립하며, 그 결과물은 에이전트를 관리하기 위한 플랫폼, 즉 4개의 UI 전반에 걸쳐 공유되는 단일 에이전트 하네스 (agent harness)입니다. § 02 기둥 (PILLARS) — Desktop / CLI / SDK / 통합 깔때기 (integration funnel)

2-1 Desktop 앱 — 커맨드 센터
수많은 에이전트를 병렬로 실행하기 위한 커맨드 브리지 (command bridge)입니다. 동적 서브 에이전트 (Dynamic subagents, 필요에 따라 자식 에이전트를 생성 및 퇴출), 예약된 작업 (scheduled tasks, cron 스타일 실행), 그리고 프로젝트별 권한 범위 (permission scopes)를 지원합니다. 사용자 경험은 "하나의 에디터에서 하나의 작업"을 하는 느낌에서 "많은 작업이 동시에 실행되며 모두 한눈에 보이는" 느낌으로 전환됩니다.

2-2 Antigravity CLI — 다른 UI, 동일한 하네스
Gemini CLI의 후속작입니다. 터미널 사용자들을 위한 가벼운 UI이지만, 핵심은 Desktop과 동일한 에이전트 하네스 (agent harness)를 공유한다는 점입니다. CLI는 별개의 제품이 아니라, 동일한 기반을 사용하는 다른 인터페이스일 뿐입니다.

▍ "동일한 하네스를 공유한다" — 이것의 실제 의미
두 개의 경쟁하는 앱이 아닙니다. 단일 로컬 설치를 통해 Desktop UI / CLI 바이너리 / 공유 앱 서버 (에이전트 하네스 자체)가 하나로 묶입니다. @karthickdotxyz의 언급에 따르면: "Antigravity 2.0과 동일한 도구 및 앱 서버를 사용합니다." Desktop이나 CLI 중 어느 경로를 선택하든 동시에 실행할 필요 없이 작업을 완료할 수 있습니다. 설정 (Configs), 에이전트 정의, 권한, 예약된 작업은 모두 공유됩니다. 즉, Desktop에서 구성된 작업은 CLI에서 그대로 호출될 수 있습니다. 자연스러운 분할: CLI를 통한 CI / 헤드리스 서버 (headless server) 작업, Desktop을 통한 대화형 개발.

2-3 SDK — 하네스를 귀하의 제품에 내장
Google의 에이전트 하네스는 이제 귀하의 워크플로(workflow)나 제품에 내장할 수 있는 요소가 되었습니다. 이것은 더 이상 "AI가 코드를 작성하게 만드는 도구"가 아니라, "AI 에이전트를 구축하고 운영하기 위한 플랫폼"이 됩니다. SDK 코드는 귀하의 PC, 귀하의 서버, 귀하의 CI 러너 (CI runners)에서 실행됩니다. Google이 런타임 (runtime)을 호스팅하는 것이 아니라, 귀하의 프로세스 내부에서 살아 움직입니다. Antigravity는 단순히 Google의 IDE뿐만 아니라 다른 기업의 제품 내부에서 실행되는 컴포넌트가 될 수 있습니다.

▍ CLI vs SDK — 실제 차이점은 무엇인가?
둘 다 로컬 머신이나 서버에서 실행됩니다.

진정한 차이점은 각 도구가 설계된 주요 사용 사례(use case)에 있습니다:

• CLI = 인간(또는 셸 스크립트)이 에이전트(agent)를 직접 제어하도록 설계된 대화형 프런트엔드(front-end)
• SDK = 프로그램이 함수 호출(function calls)을 통해 에이전트를 제어하도록 설계된 라이브러리(library)

엄밀히 말하면, 프로그램에서 셸 명령(shelling out)을 실행하여 CLI를 호출할 수도 있습니다. 하지만 셸 명령 실행에는 다음과 같은 비용이 따릅니다: (a) 프로세스 시작 오버헤드(process startup overhead), (b) 취약한 텍스트 출력 파싱(text-output parsing), (c) 타입(types) 부재, (d) 스트리밍(streaming) 및 구조화된 이벤트(structured events) 처리의 어려움. SDK는 처음부터 이러한 사용 사례를 전제로 합니다. 이는 AWS CLI와 boto3의 관계와 동일한 형태입니다.

2-4 AI Studio × Android × Firebase 통합
단순히

출시 직후, @grok은 이를 "부상하는 Agent OS 카테고리"라고 불렀으며, @arsh_goyal은 이를 "중앙 집중식 에이전트 관리자 (centralized Agent Manager)"로 정의했습니다. 이 글은 이러한 프레임워크를 빌려 하나의 구조적 패턴을 설명하고자 합니다. 즉, 권한 (permissions), 스케줄링 (scheduling), 그리고 하위 에이전트 오케스트레이션 (sub-agent orchestration)이 하나의 계층에서 통합되어 여러 UI에 걸쳐 공유되는 단일 하네스 (harness)입니다. Antigravity 2.0을 Claude Code / Codex CLI / Grok Build와 나란히 세워두고 "어느 것이 더 나은가"라고 묻는 것은 핵심을 놓치는 것입니다. 이들은 서로 다른 계층에 존재하기 때문입니다.

3-1 전문 작업자 계층 (Specialist worker layer) vs Agent OS 계층 (Agent OS layer)

구분	전문 작업자 계층 (Specialist worker layer)	Agent OS 계층 (Agent OS layer)
역할	작업을 수행하도록 호출됨	오케스트레이션 및 감독
예시	Claude Code / Codex CLI / Grok Build / Cursor	Agent Hermes (OSS) / Microsoft Copilot Studio / Google Antigravity 2.0
강점	즉각적인 추론, 코드 생성, 파일 작업	다중 UI / 병렬 실행 / 권한 / 공유 하네스

3-2 "VS" 프레임워크는 계층 간에 무너집니다

"Antigravity 2.0 vs Claude Code"는 계층 위반 (layer violation)입니다. Antigravity가 타사 제품 내부의 SDK를 통해 확장됨에 따라, 자연스러운 구성은 "Antigravity가 상단에서 Claude Code / Codex CLI / Grok Build를 작업자 (workers)로 호출하는 형태"가 됩니다. 비교해야 할 올바른 대상은 동일한 Agent OS 계층에 있는 Hermes / Copilot Studio입니다.

▍ Hermes / Copilot Studio와의 직접 비교

• Hermes = 오픈 소스 (OSS) / 개별 지향적 / 멀티 모델 (multi-model) / 22개의 게이트웨이 / Obsidian 통합 / 도메인 불문 (코딩 외 영역에서도 작동)
• Microsoft Copilot Studio = M365 영역 / 엔터프라이즈 권한 / Power Platform 통합 / 비즈니스 워크플로우 중심
• Google Antigravity 2.0 = Google 네이티브 / AI Studio × Android × Firebase 수직 계열화 (vertical integration) / 소프트웨어 엔지니어링 특화

범위(scope)의 차이는 중요합니다. 동일한 Agent OS 계층에 있다고 해서 동일한 역할을 의미하지는 않습니다. Hermes는 도메인 불문의 범용 하네스이며, Copilot Studio는 비즈니스 워크플로우를 위한 것이고, Antigravity는 소프트웨어 엔지니어링 작업을 위해 특수 제작되었습니다.

§ 04 AXIS — 비교 축의 갱신

§02의 네 가지 기둥을 구조로 다시 읽어보면, 각 기둥은 기존의 "모델 IQ 축"으로는 포착할 수 없는 설계 선택 사항을 포함하고 있습니다:

• Desktop의 동적 서브 에이전트(subagents) + 예약된 작업(scheduled tasks) → 어떤 하네스(harness)를 활용하며, 언제 자동으로 실행(fire)할 것인가
• Desktop과 앱 서버를 공유하는 CLI → 서로 다른 UI에서 호출되는 동일한 하네스
• 사용자의 자체 프로세스에서 실행되는 SDK → 어떤 권한 경계(permission boundary)와 환경을 가질 것인가
• AI Studio / Android / Firebase Skills → 에이전트에게 어떤 컨텍스트(context)를 제공할 것인가
• 에이전트 기반 IDE의 리뷰 인터페이스(review surface) → 인간이 어떻게 리뷰할 것인가

따라서 Antigravity 2.0의 구조를 솔직하게 풀어본다면, 다섯 가지 축 — 하네스(harness) / 권한 경계(permission boundary) / 컨텍스트(context) / 타이밍(timing) / 리뷰(review) — 가 자연스럽게 드러납니다.

▍ 이것은 저의 개인적인 견해입니다 — 왜 이 5가지 축인가

이 다섯 가지 설계 축은 Google, IDC, Forrester 또는 그 누구도 발표하지 않은 표준 프레임워크가 아닙니다. 이는 무엇이 실제로 중요한지에 대한 저의 편집적 합성(editorial synthesis)입니다.

이 특정 5가지를 선택한 저의 논거는 다음과 같습니다:

• 하네스(harness) — 모델 IQ가 범용화(commoditising)됨에 따라, 하네스 설계가 실제 동작을 결정합니다.
• 권한 경계(permission boundary) — 에이전트가 자율적으로 행동할 때, 권한 범위가 영향 범위(blast radius)를 결정합니다.
• 컨텍스트(context) — 동일한 모델과 동일한 IQ라도 제공된 컨텍스트에 따라 완전히 다른 출력을 생성합니다.
• 타이밍(timing) — 수동(manual) / 훅(hook) / 크론(cron) 에이전트는 서로 다른 특성을 가진 존재입니다. Antigravity 2.0이 예약된 작업을 일급 객체(first-class)로 만든 것이 이것이 중요하다는 증거입니다.
• 리뷰(review) — 인간 참여형(human-in-the-loop) 검증 부하가 생산성의 병목 구간입니다.

개별 용어들은 업계 전반에서 통용되지만, 이 5가지를 "중요한 평가 축"으로 묶는 것은 저의 판단입니다.

에디터 시대와 Agent OS 시대 사이에서 각 축(axis)별로 무엇이 변하는지 나란히 비교해 보겠습니다:

축 (Axis)	에디터 시대 (~2025)	Agent OS 시대 (2026 →)
Harness (하네스/제어 프레임워크)	에디터의 완성 속도 / UX	모델을 둘러싸는 도구, 메모리, 권한, 피드백 루프의 구성
Permission (권한)	거의 논쟁의 여지가 없는 부분 — 수동 제어	자율 에이전트(Autonomous agents) → 프로젝트 / 사용자 / 에이전트 범위의 권한을 통해 영향 범위(blast radius) 정의
Context (컨텍스트)	컨텍스트 윈도우 크기 ("양"의 축)	에이전트에게 가져와서 전달하는 내용 ("질"의 축, 그리고 스킬 팩(Skill packs))
Timing (타이밍)	인간이 타이핑하는 동안의 완성	수동 / 훅(hook) / 크론(cron) / 예약 방식 — 비동기 / 병렬 / 24시간 7일 내내 포함
Review (리뷰)	코드를 쓰기 전후에 인간이 읽음	자동 실행된 에이전트의 출력을 어디까지 신뢰하며, 인간이 어디에서 게이트(gate) 역할을 할 것인가?

각주: 과거의 축이었던 "어떤 모델이 가장 똑똑한가"는 더 이상 단독으로 존재하지 않습니다. 동일한 모델이라도 서로 다른 하네스(harness)와 컨텍스트를 갖추면 완전히 다른 출력을 생성합니다. 이 다섯 가지 요소가 개발자 생산성 그 자체를 결정합니다. 허술한 하네스를 가진 똑똑한 모델은 그저 '슬롭(Slop, 저질 결과물)'을 자동화할 뿐입니다.

§ 05 전장(BATTLEFIELD) — 다음 전장은 에디터 내부가 아니다

다음 전장은 더 이상 에디터 내부가 아닙니다. 바로 Agent OS 오케스트레이션(orchestration) 설계입니다.

2023 : 프롬프트 엔지니어링 (Prompt engineering, 단일 모델 호출)
2024 : 컨텍스트 조립 (Context assembly, RAG + 메모리)
2025 : 에디터 내의 AI (AI in the editor, Copilot + 인라인 제안)
2026+ : 에이전트 오케스트레이션 (Orchestrate agents, Agent OS) — 구성 / 감독 / 지속적 실행

▍ 목소리(VOICES) — 초기 48시간 동안 나타난 유스케이스(use cases)

출시 후 48시간 동안 X(구 트위터)에서 포착된 스냅샷입니다. 대화의 흐름이 눈에 띄게 "전문가 한 명이 코드를 작성한다"에서 "에이전트 함대(fleet of agents)가 오케스트레이션된다"로 이동하고 있습니다.

@andreasawires : "93개의 병렬 서브 에이전트...