Antigravity Agent Manager - 멀티 에이전트 병렬 개발의 진짜 의미

이 글에서 다루는 내용

Google Antigravity의 진짜 차별점은 Editor 화면이 아니라 Agent Manager입니다. Cursor·Copilot·Claude Code 같은 도구의 공통 패턴인 "한 사람 + 한 에이전트 + 한 화면"을 "한 사람 + N개 에이전트 + 단일 컨트롤 서피스"로 바꾸는 모드라, 잘 익히면 개발 처리량 자체가 달라집니다. 이 글은 Manager 모드의 정체, 4대 구성 요소(Workspaces·Inbox·Playground·Start Conversation), 강점이 드러나는 핵심 기능 6가지, 실전 워크플로우 4가지 패턴, 마지막으로 하드웨어·rate limit 한계까지 한 번에 정리합니다. 설치는 Antigravity 설치 가이드를 먼저 보시면 흐름이 매끄럽습니다. 기준 시점은 2026년 5월입니다.

---

1. Manager가 강점인 이유 - 패러다임 자체가 다르다

Cursor와 Copilot의 패턴을 들여다보면 결국 사람이 운전석에 있고 AI가 보조하는 1대1 구도입니다. 사람이 명령하고, AI가 답하고, 사람이 다시 검토합니다. 이 흐름은 작업 한 개를 빠르게 끝내는 데는 효과적이지만, 여러 개를 동시에 진행하려면 결국 사람이 여러 채널을 직접 관리해야 합니다.

Antigravity Manager는 이 자리를 오케스트레이터로 옮깁니다. 사용자는 N개의 에이전트에 작업을 분배하고, 산출물(Artifacts)이 올라오면 결재만 하는 흐름입니다. Google 공식 발표 표현을 빌리면 "5개의 다른 버그를 5명의 에이전트에 동시에 분배해 처리량을 곱하기로 늘릴 수 있다"는 것이 핵심 가치 제안입니다.

이는 단순한 UI 차이가 아니라 "사람의 시간을 어디에 쓸 것인가"의 변화입니다. 코드 한 줄 한 줄을 같이 쓰는 시간이 줄고, 여러 작업의 방향을 잡고 결재하는 시간이 늘어납니다.

---

2. Manager의 4대 구성 요소

구성 요소	역할
Workspaces (워크스페이스 레인)	VS Code의 워크스페이스를 확장한 개념. 각 워크스페이스에 전용 에이전트가 붙고, 레인끼리 병렬 실행
Inbox	모든 워크스페이스·모든 에이전트의 알림·승인 요청·메시지를 한 곳에 모으는 비동기 통신 원장
Playground	특정 작업을 격리된 샌드박스에서 실행. 멀티 에이전트 비동기 흐름을 망가뜨리지 않고 실험 가능
Start Conversation	에이전트를 띄우는 진입점. 워크스페이스·모델·실행 모드를 선택해 작업 시작

2-1. Workspaces - 한 IDE 안의 여러 작업장

Antigravity의 Workspaces는 단순한 폴더 그룹이 아닙니다. 각 워크스페이스에 전용 에이전트가 배정되고, 모델 선택과 자동화 수준도 워크스페이스별로 다르게 잡을 수 있습니다. 결과적으로 프론트엔드 워크스페이스는 가벼운 Gemini 3 Flash로, 백엔드 리팩터 워크스페이스는 Claude Sonnet 4.6으로 분리해서 운영하는 구도가 가능해집니다.

2-2. Inbox - 결재만 한 곳에서

여러 에이전트가 동시에 일하면 가장 큰 부담은 알림이 흩어지는 것입니다. Inbox는 모든 워크스페이스의 승인 요청과 진행 상황을 한 화면에 모아 줍니다. 사람은 탭을 옮겨 다니지 않고 "OK / 코멘트 / 거부"만 처리하면 되어, 5명이 동시에 일해도 사람은 1명 분량의 결재만 처리하는 흐름이 만들어집니다.

2-3. Playground - 실험 격리실

실제 프로젝트를 망가뜨리지 않고 새 아이디어를 시험하는 공간입니다. 에이전트가 만들어 낸 파일들은 Playground 안에 머물고, 마음에 들 때만 실제 프로젝트로 가져오면 됩니다. 라이브러리 도입 검토나 PoC 코드 생성처럼 "버려도 되는 결과물"이 필요한 작업에 잘 맞습니다.

2-4. Start Conversation - 에이전트의 시작점

에이전트를 띄울 때마다 다음 세 가지를 한 번에 선택합니다.

• 워크스페이스 - 에이전트가 작업할 폴더
• 모델 - Gemini 3.1 Pro / Gemini 3 Flash / Claude Sonnet 4.6 / Claude Opus 4.6 / GPT-OSS
• 실행 모드 - Plan Mode(계획 후 실행) / Fast Mode(즉시 실행)

---

3. 강점이 드러나는 핵심 기능 6가지

3-1. 다중 워크스페이스 병렬 실행

플랜에 따라 동시 에이전트 수가 다릅니다. Free 2명, Pro 5명, Enterprise 무제한입니다. 각 에이전트가 서로 다른 폴더와 다른 모델을 쓸 수 있어 작업 성격에 맞춰 분배할 수 있습니다.

3-2. Plan Mode (계획 산출물)

복잡한 작업에는 코드를 쓰기 전에 Plan Artifact를 먼저 만들고 사람의 검토를 받게 할 수 있습니다. Fast Mode는 즉시 실행이라 빠른 수정에 좋고, Plan Mode는 큰 변경 전에 방향을 잡을 때 안전합니다.

3-3. 표준화된 산출물(Artifacts)로 검토

생짜 로그를 읽지 않고 표준 포맷으로 결과를 받습니다.

• Task List - 단계별 진행 표
• Implementation Plan - 아키텍처 결정 정리
• Walkthrough - 작업 완료 후 변경 요약
• Code Diff - 줄 단위 변경 비교
• 고해상도 스크린샷 / MP4 브라우저 녹화 - UI 변경 검증

UI 변경의 경우 로컬 서버를 띄우지 않고도 Manager 안에서 결과 영상을 바로 확인할 수 있다는 점이 풀스택 개발자에게 특히 호평됩니다.

3-4. Google Docs 스타일 댓글 피드백

Plan이나 스크린샷 위에 직접 코멘트를 달면 에이전트가 다음 단계에서 그 코멘트를 반영합니다. 처음부터 다시 시키지 않고 공유 문서를 협업하듯 단계별로 궤도를 수정할 수 있어, 큰 작업도 한 번에 끝까지 위임할 수 있습니다.

3-5. Inbox 기반 비동기 결재

승인이 필요한 결정만 사람에게 모이게 하는 구조라, N개 에이전트가 동시에 일해도 사용자는 한 화면에서 처리할 수 있습니다. 이 흐름이 "사람이 5배 빠지는" 효과를 만듭니다.

3-6. AgentKit 2.0 - 16개 전문 에이전트

2026년 3월에 추가된 기능입니다. 프론트엔드·백엔드·테스트·DevOps에 특화된 16개 전문 에이전트가 기본 제공되어, 사용자가 직접 시스템 프롬프트를 짜지 않고도 역할 분담된 팀을 즉시 띄울 수 있습니다.

---

4. 실전 워크플로우 4가지 패턴

패턴 A - 병렬 버그 처리 (팬아웃)

이슈 트래커의 5개 버그를 5개 워크스페이스에 1개씩 분배합니다. 각 에이전트가 독립적으로 재현·수정·테스트·diff를 산출하고, 사람은 Inbox에서 5건의 승인을 한 곳에서 처리합니다. 가장 확실한 처리량 효과가 나오는 패턴이라 첫 도입에 추천됩니다.

패턴 B - 파이프라인 (순차 협업)

Plan 에이전트 → Code 에이전트 → Test 에이전트 → Review 에이전트 순서로 산출물을 넘기는 구조입니다. 각 단계의 입출력이 표준화된 Artifacts라 인계가 매끄럽고, 단계마다 검토 지점을 둘 수 있습니다. 이때 파일 소유권을 명확히 분리하는 것이 충돌 방지의 핵심입니다.

패턴 C - 스택별 분업 (프론트/백/DB 동시 진행)

같은 프로젝트의 다른 디렉터리에 각각 에이전트를 배치합니다. 프론트엔드 에이전트는 React 컴포넌트, 백엔드는 API, DB는 마이그레이션을 동시에 진행합니다. 빌드까지의 리드타임이 단축됩니다. 모델 선택을 다르게 가져가면 비용 효율도 올라갑니다.

패턴 D - 장기 작업 백그라운드화

대규모 리팩터링이나 의존성 업그레이드처럼 시간이 오래 걸리는 작업을 Manager에 던져 두고 사람은 다른 일에 집중합니다. 진행 상황은 Artifacts로 비동기 점검할 수 있어, "맡겨 두고 점심 먹고 결과 받기" 식의 운영이 가능합니다.

---

5. 모델 선택 전략 - 같은 작업도 다른 모델로

Manager의 강점을 살리는 또 한 가지 포인트는 워크스페이스별로 모델을 다르게 가져가는 것입니다. 같은 Pro 한도를 가장 효율적으로 쓰는 권장 조합은 다음과 같습니다.

작업 성격	권장 모델	이유
단순 변환·반복 작업	Gemini 3 Flash	속도와 한도 효율
아키텍처 결정·복잡한 디버깅	Gemini 3.1 Pro 또는 Claude Opus 4.6	깊은 추론과 큰 컨텍스트
코드 생성·리팩터링	Claude Sonnet 4.6	코드 품질 균형
실험적·격식 적은 작업	GPT-OSS	한도 분산용

💡 모든 워크스페이스를 Opus 같은 고성능 모델로 채우면 한도가 빠르게 소진됩니다. 큰 결정 한두 자리에만 무거운 모델을 두고 나머지는 Flash로 분배하는 편이 같은 한도로 더 많은 작업을 끝낼 수 있습니다.

---

트러블슈팅 - Manager의 한계와 주의점

문제 1: 16GB 노트북에서도 Manager가 무겁다

"수십 개 에이전트 동시 실행"은 마케팅 메시지이고, 실제로는 5개만 돌려도 16GB가 빠듯합니다. 파일 시스템 모니터링·터미널 스트림·내장 브라우저 렌더링이 동시에 일어나기 때문입니다. 동시 에이전트 수를 줄이고, 작업이 끝난 워크스페이스는 닫아 메모리를 회수하는 운영이 안전합니다.

문제 2: 무료 한도가 빠르게 소진된다

무료 플랜은 주간 한도, Pro/Ultra는 5시간 단위로 갱신됩니다. 출시 이후 한도가 점진적으로 인하되어 왔으므로 헤비 사용자는 한도 도달이 잦습니다. 5번에서 다룬 모델 분산 전략을 적용하시면 같은 한도로 훨씬 더 많은 작업을 처리할 수 있습니다.

문제 3: Windows에서 Inbox·Playground 메뉴가 동작하지 않는다

일부 Windows 환경에서 Manager 메뉴가 클릭에 반응하지 않는 알려진 버그가 보고되어 있습니다(Google AI Developers Forum). 최신 버전으로 업데이트하시고, 그래도 동일하면 사용자 단독 설치(%LOCALAPPDATA%)로 재설치를 권장합니다.

문제 4: 여러 에이전트가 같은 파일을 만져 충돌이 난다

워크플로우 설계 단계에서 각 에이전트의 파일 영역을 미리 분리하는 것이 핵심입니다. 패턴 B(파이프라인)는 자연스럽게 충돌이 적고, 패턴 C(스택별 분업)는 디렉터리 단위로 책임을 나누면 안전합니다.

문제 5: 회사 코드에 그대로 적용해도 될까

공식 약관이 "보안상의 알려진 한계가 있다"고 명시하고 있습니다. 데이터 유출과 임의 코드 실행 위험이 거론되므로, 회사 운영 코드에는 자율 실행 모드(Agent-Driven)를 피하고 Review-Driven 모드를 우선 적용하시기 바랍니다. 처음 도입하실 때는 사이드 프로젝트와 비핵심 작업부터 적용해 감을 잡는 것이 자료에서 가장 자주 권장되는 도입 순서입니다.

---

마무리

Antigravity Manager의 강점은 "개별 에이전트가 더 똑똑해서"가 아니라 "여러 에이전트의 흐름을 1등 시민으로 다루기 때문"입니다. 단일 작업 한 개를 처리하는 속도라면 Cursor나 Claude Code와 큰 차이가 없을 수 있습니다. 하지만 5개를 동시에 돌리고 결재만 하는 운영 방식이 가능해지는 순간 처리량 곡선이 갈라집니다. 핵심은 결국 두 가지로 정리됩니다.

1. 작업을 잘게 쪼개고 분배할 수 있는가 - 멀티 에이전트의 효과는 잘 분리된 작업에서만 나옵니다. 하나의 거대한 작업을 5개 에이전트가 동시에 진행하면 충돌만 늘어납니다.
2. 결재 시간을 잘 쓰는가 - Manager는 결재 시간을 줄여주지 않고 한곳에 모아줍니다. Inbox를 무시하면 Manager의 가치가 사라집니다.

두 가지가 손에 익으면 Manager는 단일 에이전트 도구로 돌아가기 어려운 작업 흐름을 만들어 줍니다. 다만 하드웨어·rate limit·보안 한계가 분명하므로, 사이드 프로젝트와 비핵심 작업부터 점진적으로 적용하는 것이 안전한 도입 경로입니다.

• Antigravity 공식: antigravity.google
• Agent Manager 공식 문서: antigravity.google/docs/agent-manager
• Mete Atamel - Parallel agents in Antigravity: atamel.dev

관련 글

함께 읽으면 좋은 글

• Google Antigravity 설치 가이드 - Windows·macOS 단계별 따라하기
• Claude Code 설치 및 활용 완벽 가이드