에이전트 개발 도구를 조금만 써보면 금방 한계가 보입니다. 한 에이전트에게 긴 작업을 맡기면 진행 상황을 계속 들여다봐야 하고, 다른 작업을 병렬로 돌리려 하면 맥락이 섞이거나 검증이 어려워집니다. 결국 사람은 코드보다 감독 업무를 더 많이 하게 됩니다. 그래서 Google이 Antigravity를 ‘코드를 더 빨리 쓰는 편집기’가 아니라 ‘작업 단위로 에이전트를 오케스트레이션하는 플랫폼’이라고 설명하는 건 꽤 정확한 포지셔닝입니다.
공식 소개에 따르면 Antigravity는 Editor View와 Manager Surface를 함께 제공하고, 에이전트가 editor·terminal·browser를 오가며 계획, 실행, 검증까지 수행하게 합니다. 또 로그 대신 Artifacts, 예를 들면 작업 계획, 스크린샷, 브라우저 녹화 같은 산출물로 검증하게 한다는 점을 강하게 밀고 있습니다. 저는 이 포인트가 제일 중요하다고 봅니다. 에이전트 여러 개를 동시에 돌릴 때 진짜 병목은 생성 능력이 아니라 검증 표면이기 때문입니다.
Antigravity 같은 agent-first 플랫폼은 모든 팀에 즉시 필요한 건 아닙니다. 1인 개발자가 작은 저장소 하나만 다루거나, 단순 보조 자동완성만 쓰는 팀은 과할 수 있습니다. 대신 아래 상황에선 체감 가치가 큽니다.
즉, 코드를 쓰는 것보다 ‘작업을 쪼개고 추적하는 비용’이 커진 팀에게 맞는 도구입니다.
공식 설명대로라면 Editor View는 기존 IDE처럼 동기식 작업에 가깝고, Manager Surface는 비동기식 에이전트 조율 공간입니다. 문제는 많은 팀이 이 둘을 구분하지 않고 그냥 아무 작업이나 매니저로 던진다는 겁니다. 그러면 금방 혼란이 옵니다.
추천하는 기준은 단순합니다.
예를 들어 컴포넌트 스타일 조정, 함수 하나 리팩터링, 테스트 한 케이스 수정은 Editor View 쪽이 낫습니다. 반대로 이슈 재현, 테스트 케이스 생성, 브라우저 검증, 문서 반영, 유사 파일 일괄 수정처럼 흐름이 긴 작업은 Manager Surface 쪽이 맞습니다.
이 구분이 없으면 에이전트가 아니라 사용자가 도구에 끌려다닙니다.
Antigravity의 매력은 여러 에이전트를 병렬로 돌릴 수 있다는 점입니다. 그런데 병렬성은 생산성을 올리기 전에 먼저 사고 반경을 키웁니다. 그래서 최소한 다음 규칙이 있어야 합니다.
첫째, 각 에이전트의 목표를 한 문장으로 제한합니다. ‘신규 기능 개발 + 버그 수정 + 문서 업데이트’처럼 묶지 마세요.
둘째, 작업별 검증 산출물을 미리 정합니다. UI 작업이면 스크린샷, 브라우저 녹화, 변경 파일 목록. 백엔드 작업이면 테스트 결과, 로그 요약, diff 요약이 있어야 합니다.
셋째, 서로 다른 에이전트가 같은 파일군을 동시에 건드리지 않게 범위를 나눕니다. 충돌이 나면 병렬성 이익이 바로 사라집니다.
넷째, 장기 작업은 중간 체크포인트를 강제합니다. 예를 들어 20분 이상 실행되면 현재 계획·진행도·남은 위험을 artifact로 남기게 하는 식입니다.
다섯째, 종료 기준을 사람이 먼저 적습니다. 에이전트가 ‘완료’라고 말하는 것과 팀이 완료로 인정하는 것은 다릅니다.
Google은 로그 대신 Artifacts로 검증하라고 말합니다. 이건 마케팅 문구가 아니라 운영 힌트에 가깝습니다. 에이전트 시스템이 커질수록 raw tool log를 사람이 일일이 읽는 방식은 버틸 수 없습니다. 중요한 건 모든 호출을 보는 게 아니라, 사람이 승인해야 하는 결과를 빠르게 보는 겁니다.
좋은 artifact는 이런 질문에 답해야 합니다.
예를 들어 UI 수정 작업이면 전후 스크린샷 두 장과 수정 파일 목록, 브라우저 확인 항목 3개면 충분할 수 있습니다. 백엔드 버그 수정이면 재현 로그, 수정 요약, 테스트 통과 여부, 추가 위험 메모가 핵심입니다. 이게 없으면 에이전트가 열심히 일해도 사람은 믿을 근거가 없습니다.
처음부터 핵심 서비스 전체를 맡기면 실패 확률이 높습니다. 시작은 안전한 반복 작업이 좋습니다.
이런 작업은 end-to-end 흐름을 경험하게 해주면서도, 망가져도 복구가 쉽습니다. 여기서 Manager Surface 운영 규칙을 먼저 다듬는 편이 훨씬 낫습니다.
Antigravity류 도구를 도입할 때 자주 보는 실수도 있습니다.
결국 병렬성은 자동으로 이득을 주지 않습니다. 작업 분해가 좋아야 이득이 납니다. 도구보다 운영 규칙이 먼저인 이유가 여기 있습니다.
Google Antigravity의 핵심은 ‘더 강한 모델’이 아닙니다. 사람이 여러 작업을 병렬로 던지고, 중간 개입 없이도 검증 가능한 산출물로 상태를 확인하게 만드는 운영 표면입니다. 이건 앞으로 다른 agent-first 도구를 쓸 때도 그대로 적용되는 원칙입니다.
만약 지금 팀이 에이전트를 써도 계속 붙어서 지켜봐야 한다면, 문제는 모델 지능보다 작업 관리 표면이 약한 쪽일 가능성이 큽니다. 그럴 때 필요한 건 더 긴 프롬프트가 아니라 더 좋은 Manager 규칙, 더 명확한 artifact 기준, 더 작은 작업 단위입니다.
공식 출처: Google Developers Blog, Build with Google Antigravity, our new agentic development platform
