Gemini Antigravity, 코딩 환경을 얼마나 바꿀까?

구글이 제안한 '코딩 에이전트 IDE'의 초안

개발 도구를 여전히 코드 에디터 정도로만 바라보면 시야가 좁아집니다. Gemini Antigravity는 아예 IDE 자체를 멀티 에이전트 작업 공간으로 재구성하려는 시도에 가깝습니다. 코드 편집기 위에 모델, 브라우저, 테스트 러너를 통째로 올려놓고 에이전트에게 프로젝트를 맡기는 구조입니다.

이번 미리보기 버전만 보면 완성형과는 거리가 있습니다. 속도와 제약도 분명히 드러납니다. 그럼에도 현재 나와 있는 코딩 에이전트들 중에서, 실제 개발 흐름 전체를 통으로 묶어보려는 시도라는 점에서 의미가 있습니다. 단순 자동완성을 넘어서 계획 수립, 리서치, 구현, 테스트까지 이어지는 하나의 파이프라인을 직접 보여주기 때문입니다.

UI를 통째로 맡기는 'Nano Banana' 실험의 의미

Antigravity에서 가장 눈에 띄는 영역은 UI 제작을 프롬프트로 넘기는 시나리오입니다. Nano Banana 통합 기능을 통해 테마와 스타일을 설명하면, IDE가 그에 맞는 웹사이트 디자인 초안을 제안합니다. 예를 들어 빈티지 느낌의 사진 포트폴리오 사이트를 요청하면, 서로 다른 스타일의 디자인 세 가지를 먼저 뽑아줍니다. 개발자는 그중 하나를 골라 구현을 진행합니다.

생성된 결과는 시안과 구현이 완전히 일치하지는 않습니다. 다만 전체적인 톤과 폰트 선택, 레이아웃 방향은 충분히 쓸 만한 수준입니다. 초기 버전의 포트폴리오나 프로토타입을 만드는 용도라면, 디자이너가 옆에 없는 상황에서 시간을 크게 줄일 수 있습니다. 여기에 웹사이트에 들어갈 이미지까지 Nano Banana가 생성해 채워 넣을 수 있다는 점은, 기획·디자인·구현의 경계가 흐려지는 흐름을 단적으로 보여줍니다.

여러 에이전트가 한 프로젝트를 함께 만지는 구조

에이전트 매니저 기능은 Antigravity의 방향성을 가장 잘 드러내는 부분입니다. 하나의 프로젝트 안에서 여러 에이전트가 동시에 작업하는 구조를 전제로 합니다. 각 에이전트는 별도의 작업 트리에서 고립된 채 움직이지 않습니다. 같은 코드베이스를 공유하면서, 역할만 나눕니다. 예를 들어 한 에이전트는 UI, 다른 에이전트는 API, 또 다른 하나는 테스트를 맡는 방식입니다.

이 에이전트들의 진행 상황은 인박스 형태의 알림 흐름으로 정리됩니다. 작업이 끝날 때마다 결과와 로그가 쌓이며, 사용자는 그때그때 상태를 확인하고 수정 방향을 제시합니다. 동시에 여러 워크스페이스를 열어 프로젝트를 분리할 수 있어, 팀 단위 작업 구조와도 어느 정도 맞닿습니다. 에이전트를 프로젝트 멤버처럼 관리하는 감각에 가깝습니다.

브라우저 통합, 단순 '검색'이 아닌 리서치와 테스트

Antigravity의 브라우저 확장 기능은 흥미롭습니다. 별도의 크롬 프로필 위에서 돌아가며, 에이전트가 사용자의 실제 브라우징과 섞이지 않도록 설계되어 있습니다. 이 브라우저를 통해 모델이 직접 웹을 열고, 쿠키 허용 여부를 묻고, 자료를 수집합니다. 작업이 끝나면 기록과 화면 녹화가 남습니다. 모델 입장에서는 자기 행동 이력을 아티팩트로 활용하는 셈입니다.

이 통합 브라우저의 진짜 포인트는 웹앱 테스트 자동화입니다. 에이전트가 실제 페이지를 열고 스크롤을 내리고 버튼을 누릅니다. 화면을 오가며 스크린샷을 찍고, 문제로 보이는 부분을 짚어냅니다. 테스트 과정에서 발견한 이슈를 바로 코드 수정에 연결하려는 의도입니다. 아직은 레이아웃이나 패딩처럼 세밀한 UI 문제를 완전히 해결하지 못하는 한계가 있습니다. 그럼에도 테스트와 수정이 하나의 루프 안에 묶이는 구조는 CI 파이프라인 바깥의 "인터랙션 레벨 테스트"에 대한 새로운 접근으로 볼 수 있습니다.

계획 모드와 코멘트, 개발 프로세스 자체를 UI로 드러내기

Antigravity의 계획 모드는 기능 자체보다 개발 과정을 어떻게 노출할지에 대한 고민이 반영된 부분입니다. 사용자가 무언가를 만들라고 요청하면, 모델은 먼저 상세한 구현 계획을 작성합니다. 이 계획은 곧바로 실행되지 않습니다. 사용자가 검토하고 수정을 요청할 수 있습니다. 승인을 눌러야 비로소 구현이 시작됩니다.

여기서 중요한 부분이 코멘트 기능입니다. 계획 문서뿐 아니라 이후 생성되는 아티팩트에도 직접 주석을 달 수 있습니다. 실행이 이미 진행 중인 상태에서도 코멘트를 남길 수 있고, 모델은 이를 반영해 구현 방향을 조정합니다. 일반적인 채팅 인터페이스에 비해, 피드백이 코드나 계획의 특정 지점에 정박된 형태로 남는 구조입니다. 팀 개발에서 익숙한 코드 리뷰와 이슈 코멘트를, 에이전트와의 상호작용에도 그대로 끌어온 셈입니다.

현실적으로 따져봐야 할 부분들

Antigravity는 분명 흥미로운 비전을 보여줍니다. 그러나 지금 단계에서 바로 일상 개발 도구로 치환하기에는 넘어야 할 산이 많습니다. 먼저, 현재 미리보기 버전의 속도와 레이트 리밋 문제는 생산성 도구로서 치명적입니다. 모델 호출이 막히거나 지연되는 순간 멀티 에이전트 구조의 이점이 곧바로 사라집니다. 결국 개발자가 다시 수동으로 처리해야 하는 영역이 크게 남습니다.

또한 브라우저 리서치와 테스트 자동화는 개념상 매력적이지만, 현실 개발 환경에는 이미 정교한 테스트 프레임워크와 모니터링 도구가 자리 잡고 있습니다. 이들과의 연계 전략 없이, 에이전트가 독립적으로 브라우저를 돌리는 방식만으로는 장애 대응과 품질 보증 체계를 대체하기 어렵습니다. 팀 단위에서 신뢰할 수 있는 수준의 재현성과 로그 구조가 필요합니다.

마지막으로, 계획 모드와 코멘트 기반 피드백 루프는 협업 관점에서 분명 유용합니다. 다만 이 기능이 진짜 가치가 있으려면, 에이전트가 만든 계획이 일정 수준 이상 일관되고 재사용 가능해야 합니다. 여러 번 실행할 때마다 계획 품질이 들쭉날쭉하다면, 오히려 검토 비용만 늘어납니다. 현재 Antigravity는 "새로운 작업 방식의 프리뷰"로 보는 편이 안전합니다. 개발 조직 입장에서는 곧바로 전면 도입을 고민하기보다, 프로토타입 제작이나 실험적 사이드 프로젝트에서 이 도구의 강점과 한계를 먼저 검증하는 접근이 더 현실적입니다.

출처 및 참고 :