솔직한 한계와 위험

Antigravity는 분명 매력적인 도구입니다. 계획도 세우고, 코드를 고치고, 터미널도 돌리고, 브라우저까지 열어 검증합니다. 처음 써 보면 "이제 진짜 개발 방식이 바뀌는 건가?"라는 생각이 듭니다. 문제는 바로 그 강력함입니다. 강력한 도구는 작은 실수도 크게 만듭니다.

좋은 도구를 오래 쓰고 싶다면, 장점보다 한계를 먼저 알아두는 편이 낫습니다. 그래야 실망하지 않고, 더 안전하게, 더 오래, 더 잘 쓸 수 있습니다.

MCP는 있어도, 운영 적합성은 별개다

Antigravity는 공식적으로 MCP를 지원합니다. 문서에서도 MCP를 외부 데이터와 도구를 연결하는 다리처럼 설명합니다.¹ 실제로 데이터베이스, 로그, 내부 도구, 외부 서비스와의 연결 가능성은 분명한 장점입니다.

하지만 실무에서 부딪히는 문제는 단순한 지원 여부가 아닙니다. 진짜 질문은 이것입니다. 내가 원하는 방식으로, 내가 원하는 생태계와, 내가 원하는 보안 정책 아래서 안정적으로 쓸 수 있는가?

여기서부터 그림이 조금 달라집니다. 개인 개발자에게는 조금 불편한 정도일 수 있습니다. 그러나 팀 단위에서는 이야기가 달라집니다. 이미 사내 표준 툴체인, 자체 래퍼, 내부 게이트웨이, 감사 로깅 파이프라인이 있는 조직이라면, 단순한 기능 지원보다 운영 가능성이 더 중요합니다. 연결은 되지만 정책상 추가 검토가 필요하거나, 지금은 되지만 사용 방식이 바뀔 수 있다면, 그건 기술 문제가 아니라 운영 리스크입니다.

Antigravity를 도입할 때 "MCP 지원" 체크박스 하나로 안심하면 안 되는 이유가 여기에 있습니다. 확장은 가능하지만, 그 확장이 늘 곧바로 팀 표준 운영으로 이어지는 것은 아닙니다.

클라우드 처리의 편리함은 데이터 경계의 불편함을 함께 데려온다

Antigravity의 생산성은 로컬 편집기 하나에서만 나오지 않습니다. 에이전트는 편집기, 터미널, 브라우저를 넘나들고, 필요하면 기업 데이터 소스에도 접근합니다.³ 이 구조는 강력합니다. 동시에 불편한 질문도 만듭니다. 내 코드, 프롬프트, 스크린샷, 브라우저 녹화, 실행 문맥이 어디까지 흘러가는가?

문제는 많은 팀이 이 질문을 너무 늦게 한다는 점입니다. 데모 단계에서는 대개 샘플 데이터만 쓰니까 괜찮아 보입니다. 하지만 실제 프로젝트로 넘어가면 고객 정보, 내부 문서, 운영 URL, 비공개 설정값, 심지어 브라우저 화면 속 민감 정보까지 에이전트의 작업 맥락에 섞이기 시작합니다. 어느 순간부터는 "코드를 도와주는 도구"가 아니라 "우리 시스템의 여러 표면을 읽을 수 있는 자동화 주체"가 됩니다.

특히 데이터 거주성, 로그 보존 기간, 감사용 내보내기, 프롬프트와 산출물의 저장 위치 같은 항목은 규제 산업에서 아주 예민합니다. 작은 팀은 "편하다"라고 느낄 수 있지만, 조직 단위에서는 "어디까지 열려 있고, 무엇이 남는가?"라는 질문이 먼저 나옵니다.

쉽게 말해, 속도는 좋아졌는데 경계선은 흐려집니다. 이건 작은 스타트업보다 오히려 큰 조직에서 더 아픈 문제입니다.

신뢰 문제는 아직 끝나지 않았다

Antigravity는 Artifacts를 통해 블랙박스를 줄이려 합니다. 이것은 큰 진전입니다. 하지만 블랙박스가 줄었다고 해서 위험이 사라진 것은 아닙니다. 특히 에이전트가 외부 콘텐츠를 읽고, 저장소를 열고, 명령을 실행하는 순간부터 공격 표면은 넓어집니다.

실무에서 더 무서운 점은 이런 문제가 꼭 노골적인 공격에서만 생기지 않는다는 것입니다. README, 웹페이지, 외부 문서, 저장소 설정 같은 평범한 입력도 혼선을 만들 수 있습니다. 에이전트가 어떤 패키지를 설치하자고 하고, 테스트도 통과하고, 화면도 멀쩡해 보일 수 있습니다. 그런데 나중에 보면 왜 그 패키지가 들어왔는지 설명이 모호하거나, 내가 의도하지 않은 파일까지 읽고 판단한 흔적이 남아 있을 수 있습니다.

여기서 핵심은 "AI가 사악해서"가 아닙니다. 위험의 본질은 더 현실적입니다. 에이전트가 내 권한으로, 내 환경에서, 내 속도로 행동한다는 점입니다. 실수든 공격이든, 결과는 결국 내 시스템 위에서 발생합니다.

쿼터는 숫자보다 예측 가능성의 문제다

Antigravity의 쿼터는 흔한 SaaS처럼 "하루 몇 회"처럼 단순하게 느껴지지 않을 수 있습니다. 공식 문서도 사용량이 단순한 프롬프트 횟수보다 더 복합적인 작업량과 연관된다는 점을 시사합니다.² 이 말은 곧, 같은 한 번의 요청이라도 비용이 다르다는 뜻입니다.

"버튼 색만 바꿔줘"는 가볍습니다. 반면 "이 레거시 서비스 구조를 파악하고, 테스트 추가하고, 브라우저로 검증하고, 계획 문서까지 남겨줘"는 훨씬 무겁습니다. 사용자는 같은 한 문장이라고 느끼지만, 시스템 입장에서는 전혀 같은 요청이 아닙니다.

이 불확실성은 단순한 불편함을 넘습니다. 팀 작업에서는 예측 가능성이 곧 생산성입니다. 스프린트 중반에 핵심 모델 사용감이 갑자기 달라지면, 그날의 개발 흐름이 끊깁니다. 더 답답한 점은 원인이 프롬프트 횟수인지, 긴 컨텍스트인지, 브라우저 검증인지, 멀티 에이전트 병렬 실행인지 사용자가 정확히 가늠하기 어렵다는 것입니다.

결국 Antigravity를 진지하게 쓰려면 "쿼터를 얼마나 주는가"보다 "쿼터를 얼마나 예측할 수 있는가"를 함께 봐야 합니다.

프리뷰 제품은 오늘의 약속이 내일도 같다고 보장하지 않는다

Antigravity는 공개 초기부터 개인 사용자에게 매우 공격적인 가성비와 강한 인상을 줬습니다. 하지만 프리뷰의 본질은 늘 같습니다. 지금 좋다고, 그 조건이 그대로 유지된다는 보장은 없습니다.

이것은 이상한 일이 아닙니다. 오히려 자연스럽습니다. 무거운 모델, 긴 컨텍스트, 브라우저 자동화, 멀티 에이전트 실행은 모두 비용이 큰 기능이기 때문입니다. 개인에게는 무료나 저가처럼 보여도, 서비스 운영자 입장에서는 계속 비용을 감수하는 구조일 수 있습니다.

정책 변화도 변수입니다. 기능 조합, 접근 조건, 플랜 구조, 사용 가이드가 바뀌면, 팀이 익숙하게 쓰던 워크플로우도 영향을 받을 수 있습니다. 그래서 핵심 워크플로우를 Antigravity 한 곳에만 깊게 묶어 두는 일은 조심해야 합니다. 특히 팀 규칙, 스펙 문서, 리뷰 흐름, 배포 전 검증 체계를 전부 특정 프리뷰 제품의 UI와 정책에 의존해 버리면, 정책 변경이 곧 팀 프로세스 장애가 됩니다.

가장 큰 위험은 과도한 자율성이다

에이전트 도구를 오래 쓰다 보면 사람은 빠르게 익숙해집니다. 익숙함은 편리함을 낳고, 편리함은 승인 습관을 느슨하게 만듭니다. 세 번째부터는 명령을 읽고, 다섯 번째부터는 로그를 안 보고, 열 번째부터는 "대충 괜찮겠지"가 됩니다. 문제는 그 열한 번째가 하필 위험한 작업일 수 있다는 점입니다.

자율성은 켜고 끄는 스위치가 아닙니다. 작업마다 다른 강도로 조절해야 하는 다이얼에 가깝습니다. 파일 읽기만 하는 에이전트와, 패키지 설치·배포·외부 API 호출·운영 자격 증명 접근까지 가능한 에이전트는 같은 자동화가 아닙니다.

Vibe Coding의 함정도 여기 숨어 있습니다. 손이 덜 가는 경험은 달콤합니다. 그러나 너무 많이 맡기면, 어느 순간부터 개발자는 구현자가 아니라 관찰자도 아닌 방관자가 됩니다. 테스트가 통과했다고 안심하고, 화면이 예쁘다고 만족하고, Artifact가 길다고 믿어 버리면 실제 통제는 이미 사라진 뒤일 수 있습니다.

좋은 운영 방식은 반대입니다. 저위험 작업에는 자율성을 넉넉히 주고, 고위험 작업에는 승인을 촘촘히 겁니다. 예를 들어 UI 문구 수정과 스냅샷 검증은 자율성이 높아도 됩니다. 반면 의존성 추가, 데이터 마이그레이션, 인증 설정 변경, 배포, 시크릿 접근은 사람이 반드시 개입해야 합니다.

오래 쓰는 팀은 처음부터 가드레일을 깐다

Antigravity를 현실적으로 잘 쓰는 팀은 대개 속도보다 경계부터 설계합니다. 시작점은 거창하지 않습니다. 다만 몇 가지 원칙은 초반부터 분명해야 합니다.

• 운영·고객 데이터와 분리된 샌드박스에서 먼저 검증한다.

• 터미널 자동 실행은 최소 권한으로 시작하고, Allow List와 Deny List를 보수적으로 운영한다.

• 브라우저 녹화, 스크린샷, 계획 문서, 로그의 보존 위치와 열람 권한을 정한다.

• 의존성 설치, 시크릿 접근, 배포, 데이터 변경은 자동 승인 대상에서 뺀다.

• 쿼터 제한이나 정책 변화에 대비해 대체 워크플로우를 준비한다.

이 다섯 가지만 지켜도 Antigravity는 훨씬 덜 위험하고, 훨씬 더 오래 쓸 수 있는 도구가 됩니다. 반대로 이 기본기를 건너뛰면 생산성은 잠깐 오르지만 신뢰는 빨리 떨어집니다.

마법처럼 쓰지 말고, 운영체계처럼 써야 한다

Antigravity의 약점은 곧 에이전트 도구 전체의 약점이기도 합니다. 개방성은 기대만큼 단순하지 않고, 클라우드의 편리함은 데이터 경계를 흐리며, 쿼터는 유동적이고, 프리뷰는 흔들리며, 자율성은 쉽게 과해집니다.

그렇다고 비관할 필요는 없습니다. 오히려 반대입니다. 이 한계들을 일찍 이해한 팀이 결국 가장 멀리 갑니다. 마법처럼 대하면 실망하고, 운영체계처럼 대하면 강해집니다.

좋은 개발자는 코드를 잘 쓰는 사람만이 아닙니다. 이제는 에이전트가 어디까지 일하게 할지, 어디서 멈추게 할지 설계할 줄 아는 사람이 더 강합니다. Antigravity를 오래 쓰고 싶다면, 먼저 속도가 아니라 경계를 설계하십시오.

참고

¹Google Antigravity MCP 문서

²Google Antigravity Plans 문서

³Connect your enterprise data to Google's new Antigravity IDE