본문 바로가기
AI.IT

Google Antigravity 사용기, 에이전트 개발 흐름이 왜 달라졌나

by bamsik 2026. 4. 14.
반응형

Google Antigravity 사용기, 에이전트 개발 흐름이 왜 달라졌나

Google Antigravity는 에이전트 개발을 에디터, 터미널, 브라우저로 나눠서 보던 흐름을 한 화면에서 다시 묶으려는 플랫폼이다. 이번 공개 자료를 보면서, 실제 작업 속도가 빨라질 만한 지점과 아직 손이 더 가는 부분을 따로 적어봤다.

나도 요즘 AI 코딩 도구를 붙여 쓸 때 가장 답답했던 건 계획은 채팅창에 있고, 실행은 터미널에 있고, 검증은 브라우저에서 따로 해야 한다는 점이었다. 도구가 많아질수록 편해지는 게 아니라 오히려 맥락이 흩어지더라. Antigravity는 바로 그 틈을 줄이려는 시도가 꽤 선명했다.

무엇이 달라졌나, 그냥 또 하나의 AI IDE는 아니었다

Google이 소개한 Antigravity의 핵심은 AI가 코드를 추천하는 수준을 넘어서, 작업 계획 수립과 실행, 그리고 결과 확인까지 하나의 작업 흐름으로 묶는 데 있다. 공개 설명을 보면 Editor View와 Manager Surface를 중심으로 여러 에이전트가 작업을 나눠 처리하고, 진행 상황은 스크린샷이나 기록 형태의 Artifacts로 남긴다.

이 구조가 인상적인 이유는 분명하다. 예전에는 프롬프트 한 번 던지고 결과 텍스트만 받아서 사람이 직접 다시 확인해야 했다. 반면 이런 방식은 에이전트가 브라우저에서 실제로 뭘 눌렀는지, 터미널에서 어떤 명령을 돌렸는지, 중간 결과가 어떤지까지 확인 가능한 흐름으로 가져간다. 특히 복잡한 작업에서 체감 차이가 크다.

  • 계획 수립: 해야 할 일을 단계별로 분해
  • 실행 분산: 에디터, 터미널, 브라우저에서 작업 병행
  • 검증 기록: 스크린샷, 녹화, 산출물로 확인 가능

써보는 입장에서는 이 세 단계가 붙어 있다는 점이 꽤 중요하다. 코드 자동완성만 잘하는 도구보다, 실패했을 때 어디서 어긋났는지 추적 가능한 도구가 실제 업무에서는 더 오래 남는다.

개발 흐름에서 체감되는 장점 3가지

첫째, 컨텍스트 점프가 줄어든다. 예를 들어 API 연결, UI 수정, 로그인 검증 같은 작업을 할 때 기존에는 IDE, 브라우저, 작업 노트를 계속 오가야 했다. Antigravity는 이걸 한 작업 세트로 본다. 이 방식은 단순해 보여도 집중력 손실을 꽤 줄인다. 하루 기준으로 5분, 10분씩 새는 시간이 쌓이면 체감이 크거든.

둘째, 에이전트 결과를 검증하기 쉽다. Google이 예시로 든 Artifacts 개념은 그냥 보기 좋은 부가 기능이 아니라, 결과 신뢰도를 올리는 장치에 가깝다. 스크린샷이나 기록이 남으면 사람이 마지막 확인만 해도 된다. 텍스트 설명만 남는 방식보다 훨씬 낫다.

셋째, 여러 오픈소스 에이전트 프레임워크와의 연결이 강조된다. 최근 에이전트 도구는 ADK, Letta, mem0처럼 메모리나 오케스트레이션을 따로 붙이는 흐름이 강한데, Antigravity는 이런 조합을 실제 개발 화면에서 다루려는 방향으로 보였다. 단순 챗봇이 아니라 작업 시스템으로 가는 흐름에 가깝다.

그렇다고 바로 갈아탈 수준이냐고 묻는다면

여기서는 조금 신중하게 봐야 한다. 아직 공개 단계가 퍼블릭 프리뷰라서, 안정성이나 팀 협업 규칙까지 검증됐다고 보긴 어렵다. 특히 회사 환경에서는 권한 관리, 로그 보존, 실패 시 복구 흐름이 중요하다. 이런 부분이 충분히 다듬어지지 않으면 멋진 데모와 실제 도입 사이 간격이 꽤 크다.

또 하나는 비용과 운영 복잡도다. 에이전트가 에디터와 브라우저, 터미널을 다 건드리기 시작하면 토큰 비용만이 아니라 검증 비용도 커진다. 내가 보기엔 단순 CRUD 화면 수정처럼 반복 패턴이 뚜렷한 작업엔 잘 맞지만, 요구사항이 계속 바뀌는 초기 기획 단계에서는 오히려 사람이 직접 잡는 편이 빠를 수도 있다.

그래도 흐름은 읽힌다. 예전에는 AI 코딩 도구가 코드를 얼마나 빨리 써주느냐가 중심이었다면, 지금은 작업을 어떻게 나누고 끝까지 확인하느냐가 더 중요해졌다. Antigravity는 그 변화를 꽤 또렷하게 보여주는 사례였다.

이런 팀이라면 한번 볼 만하다

반복적인 프론트엔드 수정, 테스트 시나리오 점검, 관리 화면 자동화처럼 여러 도구를 자주 넘나드는 팀이라면 한 번쯤 체크해볼 만하다. 반대로 작은 스크립트 한두 개 만드는 정도라면 기존 CLI 기반 에이전트만으로도 충분할 수 있다. 결국 중요한 건 도구 이름보다, 계획과 실행과 검증이 하나의 흐름으로 이어지느냐다.

나도 이런 흐름이 앞으로 더 많아질 거라고 본다. AI가 코드를 대신 써주는 시대를 넘어서, 작업 전체를 대신 굴리는 방향으로 가고 있으니까. 다만 지금 시점에서는 무조건 갈아타기보다, 어떤 팀과 어떤 작업에 맞는지 냉정하게 보는 편이 맞다.


📎 참고 자료


📌 함께 보면 좋은 글

반응형