본문 바로가기

Gemini

Google Antigravity 완전 가이드 2편 — Agent Manager로 멀티 에이전트 오케스트레이션 실전

반응형

에이전트 하나 쓰면 Cursor랑 다를 게 없습니다. Antigravity의 진짜 힘은 Agent Manager에서 사용자가 직접 에이전트를 세팅하고 동시에 돌리는 것입니다.

[2편 핵심 요약]
→ Agent Manager: Ctrl+Shift+A — 에이전트 생성·모니터링·전환 허브
→ 에이전트는 자동 생성 안 됨 — 사용자가 직접 역할 정의 후 스폰
→ AgentKit 2.0 (3월 2026): Frontend·Backend·Testing·DevOps 16개 전문 에이전트
→ 에이전트 간 직접 통신 없음 — 사용자가 코디네이터
→ 에이전트별 다른 모델 할당 가능 (비용·성능 최적화)
→ 동일 파일 동시 수정 금지 — 에이전트마다 파일 소유권 명시 필요
→ Artifacts: Task List → Implementation Plan → Code → Browser Recording 순서

Agent Manager 기본 구조

[Agent Manager 접근]
Ctrl + Shift + A   → Agent Manager 열기
사이드바 아이콘    → 동일

[Agent Manager 기능]
Spawn   → 새 에이전트 생성 (역할+컨텍스트 직접 정의)
Monitor → 각 에이전트 실시간 상태 확인
Switch  → 에이전트 간 즉시 전환
Rename  → "Agent 1" 대신 "Frontend-Dashboard"처럼 명명
Archive → 완료된 에이전트 정리 (리소스 해제)
Restart → 멈춘 에이전트 컨텍스트 유지하며 재시작

중요한 것: 에이전트는 자동으로 생성되지 않습니다. 사용자가 Agent Manager에서 각 에이전트의 역할을 직접 프롬프트로 정의해야 합니다. 시작 전에 "어떤 에이전트가 어떤 파일을 담당할지" 설계가 먼저입니다.


실전 1 — 첫 에이전트 스폰하기

[에이전트 스폰 프로세스]

1. Agent Manager 열기 (Ctrl+Shift+A)
2. "New Agent" 클릭
3. 에이전트 역할 정의 프롬프트 입력
4. 모델 선택
5. 시작

첫 에이전트 — 추천 프롬프트:
"이 프로젝트 구조를 분석하고
 무엇을 하는 프로젝트인지 파악한 뒤
 프로덕션 배포를 위해 필요한 작업 목록을 작성해줘."

→ Artifacts로 Task List 반환
→ 전체 그림 파악 후 멀티 에이전트 전략 수립

실전 2 — AgentKit 2.0: 16개 전문 에이전트

3월 2026 업데이트로 추가된 전문 에이전트 카탈로그입니다. 직접 만들어도 되지만 AgentKit 프리셋을 쓰면 역할 정의를 자동으로 채워줍니다.

[AgentKit 2.0 — 16개 전문 에이전트]

Frontend (4개):
→ UI Builder       — React/Vue 컴포넌트, 레이아웃
→ Styler           — CSS, TailwindCSS, 디자인 시스템
→ A11y Auditor     — 접근성 감사 및 수정
→ Perf Optimizer   — 번들 최적화, 렌더링 성능

Backend (4개):
→ API Designer     — REST/GraphQL 엔드포인트 설계+구현
→ DB Manager       — 스키마 설계, 마이그레이션, 쿼리 최적화
→ Auth Handler     — 인증·인가, JWT, OAuth
→ Cache Architect  — Redis, 캐싱 전략

Testing (4개):
→ Unit Tester      — 단위 테스트 생성, 커버리지
→ Integration Tester — 통합 테스트, API 검증
→ E2E Tester       — Playwright/Cypress E2E
→ Security Scanner — 취약점 스캔, OWASP 체크

DevOps (4개):
→ CI/CD Builder    — GitHub Actions, 파이프라인
→ Docker Specialist — Dockerfile, Compose 최적화
→ K8s Manager      — Kubernetes 매니페스트
→ Monitor          — 옵저버빌리티, 알림 설정

실전 3 — 멀티 에이전트 실전 세팅

사용자 대시보드 기능 개발 예시입니다.

[사전 설계 — 파일 소유권 먼저 정의]

Agent 1 (Frontend-Dashboard):
→ src/components/Dashboard/ 전담
→ 절대 건드리지 말 것: api/, server/, tests/

Agent 2 (Backend-Dashboard):
→ api/dashboard/ 전담
→ 절대 건드리지 말 것: src/components/, tests/

Agent 3 (Tester-Dashboard):
→ tests/dashboard/ 전담
→ 읽기 전용: api/, src/components/

→ 파일 소유권 미리 안 정하면
  두 에이전트가 같은 파일 동시 수정 → 충돌 발생

Agent 1 스폰 프롬프트:

이 프로젝트의 React 프론트엔드 전담 에이전트야.
src/components/Dashboard/ 디렉토리만 수정해.

할 일:
- 사이드바 네비게이션 컴포넌트
- 통계 그리드 (카드 4개)
- 최근 활동 피드

API 엔드포인트는 아직 없으니까
mock 데이터로 먼저 구현하고
나중에 교체할 수 있게 서비스 레이어 분리해줘.

Agent 2 스폰 프롬프트:

이 프로젝트의 FastAPI 백엔드 전담 에이전트야.
api/dashboard/ 디렉토리만 수정해.

할 일:
- GET /api/stats — 대시보드 통계 데이터
- GET /api/activity — 최근 활동 목록
- PUT /api/settings — 사용자 설정 업데이트

타입 힌트 필수, Pydantic 모델로 응답 스키마 정의해줘.

Agent 3 스폰 프롬프트:

이 프로젝트의 테스트 전담 에이전트야.
tests/dashboard/ 에만 파일 생성해.

api/dashboard/ 코드 읽어서
모든 엔드포인트 통합 테스트 작성해줘.
엣지케이스 포함, 커버리지 80% 이상.
Agent 2 완료 알림 받으면 시작해.
[세 에이전트 동시 실행 후 Agent Manager 상태]

Frontend-Dashboard  🔄 진행 중... 45%
Backend-Dashboard   🔄 진행 중... 70%
Tester-Dashboard    🔵 대기 (Backend 완료 기다리는 중)

실전 4 — 에이전트별 모델 할당

[태스크 복잡도별 모델 전략]

Gemini 3.1 Pro (2M 토큰):
→ 아키텍처 설계, 복잡한 리팩토링
→ 전체 코드베이스 인덱싱 필요할 때
→ Claude Opus 4.6도 가능

Gemini 3 Pro:
→ 일반 코드 생성, API 구현
→ 품질·속도 균형

Gemini 3 Flash:
→ 포매팅, 린팅, 문서화
→ 단순 반복 태스크
→ 크레딧 절약용

Claude Sonnet 4.6:
→ 복잡한 추론, 보안 분석
→ 코드 리뷰, 버그 분석

[실전 배치]
Frontend-Dashboard  → Gemini 3 Pro
Backend-Dashboard   → Gemini 3 Pro
Tester-Dashboard    → Gemini Flash (단순 반복)
Architecture Agent  → Gemini 3.1 Pro (전체 코드 분석)
⚠️ 주의: 모델 변경은 해당 에이전트에만 적용
→ 한 에이전트 모델 바꿔도 다른 에이전트 영향 없음
→ 이미 실행 중인 에이전트 모델 변경 불가
→ 새 에이전트 스폰 시 모델 선택

실전 5 — Artifacts 검토 워크플로우

[Artifacts 4단계]

1. Task List
→ 코드 한 줄 전에 생성
→ 계획 검토 + 수정 요청 가능
→ 잘못된 방향 여기서 차단 (비용 최소)

2. Implementation Plan
→ 변경 파일 목록 + 접근 방식
→ Google Docs처럼 인라인 코멘트 가능
→ "user_id FK 추가해줘" → 에이전트가 반영 후 재제출

3. Code Changes
→ 파일별 diff 뷰
→ 파일 단위 수락/거절 가능
→ 특정 파일만 "다시 해줘" 요청 가능

4. Browser Recording
→ 에이전트가 직접 앱 실행 + 클릭 + 검증
→ 스크린샷 + 영상으로 결과 확인
→ 3편에서 상세 다룸

흔한 실수와 해결법

❌ 실수 1: 파일 소유권 미정의
→ 두 에이전트가 같은 파일 수정 → 충돌
→ 해결: 스폰 프롬프트에 "이 디렉토리만 수정해" 명시

❌ 실수 2: 에이전트 이름 방치
→ "Agent 1", "Agent 2" → 어떤 에이전트가 뭔지 헷갈림
→ 해결: Rename → "Frontend-Auth", "Backend-Payment"처럼

❌ 실수 3: 완료된 에이전트 방치
→ 유휴 에이전트도 리소스 소모
→ 해결: 완료 후 Archive 클릭

❌ 실수 4: 한 에이전트에 너무 많이 시킴
→ 에이전트가 길어질수록 성능 저하
→ 해결: 태스크 단위로 새 에이전트 스폰

❌ 실수 5: Artifacts 검토 없이 바로 수락
→ 잘못된 Implementation Plan 승인 → 대규모 수정 필요
→ 해결: Task List + Plan 단계에서 꼼꼼히 검토

관련 글


 

반응형