요약: Google Antigravity는 단순 코드 자동완성 도구가 아니라 에디터, 터미널, 브라우저를 오가는 에이전트 개발 플랫폼입니다. 핵심은 에이전트에게 일을 맡기는 것이 아니라, 결과물을 검증 가능한 단위로 받는 프로세스를 만드는 것입니다.
Google Antigravity는 agentic development platform으로 소개됐습니다. 공식 설명의 핵심은 두 가지 화면입니다. 하나는 익숙한 Editor View이고, 다른 하나는 여러 에이전트를 비동기로 실행하고 관찰하는 Manager Surface입니다. 기존 AI IDE가 “옆에서 코드를 도와주는 챗봇”에 가까웠다면, Antigravity는 에이전트가 독립 작업 공간에서 계획, 실행, 검증을 하도록 설계됐습니다.
이 차이는 작지 않습니다. 코드 자동완성은 개발자의 손을 빠르게 합니다. 에이전트 플랫폼은 개발자의 관리 방식을 바꿉니다. 작업을 쪼개고, 맡기고, 결과물을 검토하고, 다시 피드백하는 흐름이 필요합니다. 따라서 Antigravity를 도입할 때는 “얼마나 똑똑한가”보다 “어떤 작업을 어떤 기준으로 맡길 것인가”가 더 중요합니다.
검색 의도 기준 키워드는 Google Antigravity, agentic development platform, AI IDE, 에이전트 개발, 개발 자동화입니다. 이 글은 기능 소개보다 팀 적용법에 집중합니다.
Antigravity의 Manager Surface는 여러 에이전트를 띄워 장기 작업을 맡기는 인터페이스입니다. 예를 들어 한 에이전트는 버그 재현을 맡고, 다른 에이전트는 테스트 케이스 생성을 맡고, 또 다른 에이전트는 UI 수정안을 구현할 수 있습니다. 개발자는 모든 로그를 실시간으로 따라가지 않고 결과 Artifacts를 보며 판단합니다.
이 구조는 제품팀의 작업 방식과 비슷합니다. 사람이 여러 티켓을 병렬로 처리하듯, 에이전트도 여러 작업을 병렬로 처리합니다. 하지만 에이전트는 맥락을 오해할 수 있고, 검증 없이 자신 있게 보고할 수 있습니다. 그래서 Manager Surface를 잘 쓰려면 작업 정의가 중요합니다.
좋은 작업 지시는 다음 요소를 포함해야 합니다. 목표, 수정 가능 범위, 금지 범위, 완료 조건, 테스트 명령, 산출물 형식입니다. “버그 고쳐줘”는 나쁜 지시입니다. “로그인 후 설정 페이지에서 저장 버튼이 비활성화되는 문제를 재현하고, 원인 파일을 찾아 테스트를 추가한 뒤 수정 PR 초안을 만들어라. 결제 관련 파일은 수정하지 마라”는 더 좋은 지시입니다.
공식 발표에서 Antigravity는 Artifacts를 강조합니다. task list, implementation plan, screenshots, browser recordings 같은 산출물을 만들어 검토자가 에이전트의 논리와 결과를 확인할 수 있게 합니다. 이 부분이 중요합니다. 에이전트 작업에서 가장 큰 비용은 로그를 읽는 시간입니다. 도구 호출 로그는 많고, 사람이 읽기 어렵습니다.
Artifacts는 “증거 기반 보고서” 역할을 해야 합니다. UI 작업이면 변경 전후 스크린샷이 있어야 합니다. 브라우저 플로우 작업이면 녹화나 단계별 캡처가 있어야 합니다. 백엔드 작업이면 테스트 결과, API 응답 예시, 마이그레이션 영향 범위가 있어야 합니다. 문서 작업이면 변경 요약과 누락된 항목 목록이 있어야 합니다.
팀에서는 Artifacts 기준을 미리 정하는 것이 좋습니다. 예를 들어 프론트엔드 변경은 스크린샷 2장 이상, 테스트 결과, 접근성 체크를 요구합니다. 백엔드 변경은 실패 테스트와 성공 테스트, 로그 샘플, 롤백 방법을 요구합니다. 이렇게 해야 에이전트 결과를 사람 PR처럼 리뷰할 수 있습니다.
Antigravity에 먼저 맡기기 좋은 작업은 검증 결과가 명확한 일입니다. 예를 들어 UI 컴포넌트 수정, 버그 재현, 테스트 케이스 추가, 문서 갱신, 작은 리팩터링, 브라우저 기반 QA가 있습니다. 이런 작업은 스크린샷, 테스트, diff로 판단할 수 있습니다.
장기 유지보수 작업도 적합합니다. 오래된 TODO 제거, deprecated API 교체 후보 조사, flaky test 원인 분류, Storybook 누락 케이스 추가처럼 시간이 오래 걸리지만 위험도가 낮은 작업은 비동기 에이전트와 잘 맞습니다.
반대로 조심해야 할 작업도 있습니다. 결제, 인증, 권한, 데이터 삭제, 인프라 배포, 개인정보 처리, 라이선스 변경은 자동 실행 대상이 아닙니다. 에이전트가 초안을 만들 수는 있지만 최종 승인과 실행은 사람이 해야 합니다. 특히 브라우저를 조작할 수 있는 에이전트는 실서비스에 접근하지 않도록 sandbox나 staging 환경을 써야 합니다.
첫째, 에이전트용 티켓 템플릿을 만듭니다. 템플릿에는 목적, 배경, 수정 가능 범위, 제외 범위, 검증 방법, 기대 산출물, 위험도가 들어갑니다. 이 템플릿이 없으면 에이전트가 자기 방식대로 일을 해석합니다.
둘째, 브랜치 전략을 분리합니다. 에이전트 작업은 agent/작업명 같은 별도 브랜치에서 시작하게 합니다. 사람이 직접 작업하는 브랜치와 섞이면 책임 추적이 어려워집니다. 커밋 메시지에도 에이전트 작업임을 표시하고, PR 본문에는 어떤 Artifacts가 생성됐는지 링크합니다.
셋째, 리뷰 기준을 낮추지 않습니다. “AI가 만들었으니 대충 보자”가 아니라 “AI가 만들었으니 더 기계적으로 보자”가 맞습니다. 변경 범위, 테스트 결과, 보안 영향, 접근성, 성능 영향, 롤백 가능성을 체크해야 합니다.
넷째, 피드백 루프를 만듭니다. 에이전트가 자주 실패하는 지시 유형을 모아 템플릿을 개선합니다. 예를 들어 UI 작업에서 매번 반응형을 빼먹는다면 템플릿에 모바일 캡처 요구를 추가합니다. API 작업에서 에러 케이스 테스트를 빼먹는다면 완료 조건에 명시합니다.
Antigravity는 팀 단위 도구처럼 보이지만 개인 개발자에게도 의미가 있습니다. 사이드 프로젝트나 1인 개발에서는 가장 부족한 것이 QA 시간입니다. 에이전트에게 “내가 만든 기능을 사용자처럼 써보고 문제를 찾아라”라고 맡기면 좋은 보조 리뷰어가 됩니다.
다만 개인일수록 더 조심해야 합니다. 사람이 적으면 리뷰 안전망도 적습니다. 에이전트가 만든 변경을 바로 배포하지 말고, 최소한 테스트와 수동 확인을 거쳐야 합니다. 로컬 개발 서버, 테스트 계정, 더미 데이터, preview 배포를 사용하는 습관이 필요합니다.
또한 지식 베이스 기능을 쓴다면 프로젝트 규칙을 정리해두는 것이 좋습니다. 폴더 구조, 코딩 컨벤션, 금지 패키지, 디자인 시스템, 배포 절차를 문서화하면 에이전트가 같은 실수를 덜 합니다.
좋은 지시는 길다고 좋은 것이 아닙니다. 실행 가능한 제약이 있어야 합니다. 다음 구조가 유용합니다.
이 구조는 Antigravity뿐 아니라 Claude Code, Gemini CLI, Cursor류 에이전트에도 통합니다. 결국 에이전트 개발의 품질은 모델보다 작업 계약서에 크게 좌우됩니다.
출처: Google Developers Blog “Build with Google Antigravity, our new agentic development platform”, Antigravity 공개 프리뷰 안내.
