Google AI Studio에서 빠르게 만들고 Antigravity로 넘기는 2026 에이전트 개발 흐름

왜 Google은 에이전트 시대에 개발자에게 브라우저에서 빠르게 굴리는 공간과 로컬에서 깊게 운영하는 IDE를 동시에 들고 올까요? 데모 영상만 보면 “다 된다”처럼 보이지만, 실제 운영에서는 질문이 하나로 수렴합니다. 어디까지를 ‘실험’으로 두고, 어디부터를 ‘규율 있는 실행’으로 넘길 것인가입니다.

이 글은 2026년 3월 기준으로, Google AI Studio의 풀스택·프로토타이핑 축과 Google Antigravity의 에이전트 퍼스트 IDE 축을 하나의 제품처럼 섞지 않고, 연결 지점(시크릿, Firebase, 멀티플레이어 협업, Git, 배포)을 기준으로 정리합니다. 뉴스 나열이 아니라 역할 분리와 검증 가능한 산출물(Artifacts) 관점에서, 지금 쓸 수 있는 것과 아직 로드맵인 것을 구분해 두면 이후에 도구가 바뀌어도 판단이 덜 흔들립니다.

한 줄 요약: 2026년 현재 Google 쪽 “에이전트 개발”은 AI Studio에서 빠르게 스펙을 굳히고 백엔드를 붙인 뒤, 필요해지는 순간 Antigravity의 Manager Surface·Artifacts·로컬 워크스페이스로 넘겨 비동기 다중 에이전트와 검증 루프를 도는 흐름이 성립합니다. 다만 Firebase Studio → Google AI Studio 자동 이전 파이프라인은 아직 공식적으로 ‘준비 중’이며, Antigravity로의 이전은 문서화된 보내기·에이전트 보조 절차가 현재의 정공법입니다.

지금 결론

제품을 하나로 착각하면 운영이 깨집니다. Google AI Studio(웹·앱 빌딩·Firebase 연동)와 Antigravity(VS Code 계열의 에이전트 퍼스트 IDE)는 UI도, 신뢰 모델도 다릅니다. 여기에 Gemini API의 Interactions API, Workspace용 스튜디오류 제품까지 끼얹으면 검색 한 번에 뇌가 멈춥니다. 글에서는 AI Studio / Antigravity / Firebase(백엔드 서비스)만을 축으로 말합니다.
“넘긴다”의 현재 의미는 ‘원클릭 통합 완성’이 아니라 ‘경계 이동’에 가깝습니다. Firebase 공식 문서는 Antigravity 쪽 이전을 Zip 내려받기 → 로컬에서 열기 → 에이전트 프롬프트(@fbs-to-agy-export) 또는 CLI(studio:export)로 설명하고, Google AI Studio로의 이전은 “coming soon”으로 명시합니다. 즉 2026년 3월 시점에서 기대치를 로드맵과 문서 절차에 맞추는 게 안전합니다.
데모 흥분보다 Artifacts가 본체입니다. Antigravity는 에이전트가 작업 목록·구현 계획·스크린샷·브라우저 녹화 같은 검증 가능한 산출물로 진행 상황을 남기도록 설계되어 있습니다. 이는 “로그 스크롤”을 인간이 대신하지 않게 하려는 장치이고, 운영에서는 SDD·체크리스트·리뷰 게이트와 직결됩니다. (Developers Blog, 2025-11-20)
Firebase Studio 사용자는 마감이 있습니다. 공식 문서 기준 종료일은 2027년 3월 22일, 신규 워크스페이스 생성 중단은 2026년 6월 22일입니다. 코어 Firebase 서비스(Firestore, Auth, App Hosting 등)는 Studio 종료와 별개로 유지됩니다. (Firebase 문서)
허브 관점에서 이 글의 위치: “AI 개발 워크플로우” 허브의 하위 확장으로, 명세(SDD) → 실행(에이전트) → 검증(Artifacts/테스트) → 배포의 연결고리를 Google 스택에 맞춰 붙인 글입니다. 이미 올라간 SDD·CLI·팀 운영 글과 같이 읽을 때 효과가 큽니다.
“바이브 코딩”과 “스펙 기반”은 적대가 아니라 순서 문제입니다. AI Studio 쪽 공식 서술은 프롬프트에서 풀스택으로 가속한다는 쪽에 무게가 실립니다. 그러나 운영에서 살아남는 팀은 곧바로 데이터 모델·인증 경계·보안 규칙·배포 단위를 문서에 고정합니다. 즉 감으로 시작해 규율로 끝낸다는 뜻에 가깝고, SDD 글에서 말한 명세가 곧 테스트와 리뷰의 기준이 된다는 점과 같은 테이블에 앉습니다.
학습(knowledge)을 원시로 쌓지 말고, 검증 단위로 쌓으라는 메시지가 Antigravity 소개에도 있습니다. 공식 글은 에이전트가 유용한 맥락과 코드 조각을 지식 베이스에 저장해 이후 작업을 개선한다고 설명합니다. 운영 언어로 번역하면 “대화 로그”가 아니라 “재사용 가능한 규칙과 스니펫”을 남기라는 요구에 가깝습니다. 이는 SkillsBench·Codex 글에서 반복된 교훈—만들기보다 검증—과 같은 방향입니다.
멀티 에이전트는 ‘인원 증원’이 아니라 ‘격리 설계’가 먼저입니다. Manager Surface가 비동기 병렬을 지원한다고 해서, 저장소 충돌·환경 차이·브랜치 정책이 사라지지는 않습니다. ClawTeam 글에서 이야기한 worktree·세션 분리는 Google 스택을 쓸 때도 그대로 통합니다. 도구가 바뀌어도 Git이 최후의 진실인 구조는 유지됩니다.
시크릿과 자격증명은 ‘기능’이 아니라 ‘감사 대상’입니다. Firebase 블로그는 결제·지도 같은 외부 서비스 연결에 사용자 자격증명이 필요할 수 있다고 서술합니다. 이 한 줄이 운영에서의 의미는 크습니다. 즉 어떤 키가 어디에 저장되고 누가 회전하는지를 AI가 대신 책임지지 않는다는 뜻입니다. CLI 설계 글의 dry-run·감사 로그 사고방식이 여기에도 이어집니다.
공식 문서가 ‘coming soon’이라고 쓴 부분은 일정이 아니라 리스크입니다. 마이그레이션 파이프라인이 열리기 전에 팀이 할 일은 보내기·GitHub 업로드·Zip 검증 같은 복구 가능한 중간 형태를 미리 연습하는 것입니다. “곧 된다”는 말을 출시 일정으로 읽으면 PM이 울고, 준비 기간으로 읽으면 엔지니어가 웃습니다.

워크플로 한 장: 프롬프트에서 Git·배포까지

아래는 역할 분리를 전제로 한 흐름입니다. “항상 이대로”가 아니라, 경계가 흐릿해질 때 다시 펼쳐볼 지도로 쓰면 됩니다.

flowchart LR
  P[Prompt / 초기 의도] --> AIS[Google AI Studio\n시크릿·자격증명\nFirebase Auth / Firestore\n멀티 디바이스 협업]
  AIS -->|프로토타입 완성\n보안 규칙·스키마 초안| BR{분기:\n로컬 깊이·\n다중 에이전트?}
  BR -->|No| AIS_DEPLOY[AI Studio에서\n계속 다듬기 /\nFirebase 배포]
  BR -->|Yes| AGY[Antigravity\nEditor View: 동기 편집\nManager Surface: 비동기\n멀티 에이전트]
  AGY --> ART[Artifacts\n작업목록·플랜\n스크린샷·워크스루]
  ART --> GIT[Git 브랜치 /\n리뷰 가능한 단위]
  GIT --> DEP[firebase deploy /\nApp Hosting 등]

읽는 법 (한 번에 정리):

AI Studio는 “브라우저에서 빠르게”와 “Firebase를 자연어로 붙이기”에 최적화된 축입니다. Firebase 블로그(2026년 3월)에 따르면, 앱 빌딩 시 에이전트가 저장소·인증 필요성을 감지하고 사용자 승인 하에 Firestore·Authentication을 연결할 수 있습니다. 보안 규칙은 생성되더라도 배포 전 반드시 재검토하라고 명시되어 있습니다. (Firebase Blog)
Antigravity는 “에이전트에게 전용 공간을 준다”는 전제의 IDE입니다. Editor View는 익숙한 동기 편집, Manager Surface는 여러 워크스페이스에 걸친 비동기 다중 에이전트 조율에 쓰입니다. (Developers Blog)
Artifacts는 중간 관리자가 아니라 신뢰 장치입니다. 인간이 남긴 코멘트를 에이전트가 흐름을 끊지 않고 흡수하도록 설계되어 있다는 점이, “그냥 잘 돌아가네?” 수준의 데모와 운영의 차이를 만듭니다.

Google AI Studio 쪽이 공식적으로 강조하는 변화 (풀스택 + 코딩 에이전트)

Firebase 블로그(2026년 3월)는 두 갈래를 동시에 밀고 있습니다. 첫째는 Firebase를 AI Studio 앱 빌딩에 네이티브로 연결해 프롬프트만으로도 저장소·인증까지 가져가게 한다는 것이고, 둘째는 Google AI Studio의 코딩 에이전트를 Antigravity의 에이전트 하네스 핵심 구성 요소로 업그레이드했다는 것입니다.

여기서 운영자가 챙겨야 할 포인트만 뽑으면 다음과 같습니다.

에이전트가 Firestore·Authentication을 “제안하고, 승인받고, 연결”한다. 자동으로 몰래 붙는 구조라기보다, Enable Firebase 같은 승인 게이트가 전제로 깔려 있습니다. 프로토타입 단계에서도 누가 승인했는지가 나중에 감사됩니다.
보안 규칙은 초안일 뿐이다. 블로그는 앱 로직에 맞춰 규칙을 생성하지만 배포·공유 전에 반드시 더블체크하라고 반복합니다. 이 문장은 AI 시대 개발 방법론 논쟁에서 흔히 빠지는 “일단 돌아가게”와 정면으로 충돌합니다. 돌아가게 만드는 것과 안전하게 만드는 것 사이에는 인간 리뷰가 필수입니다.
코딩 에이전트는 더 복잡한 액션을 더 짧은 프롬프트로 시도한다. 공식 서술은 멀티 스텝 편집·반복 속도·정확도를 강조합니다. 또한 현대 웹 도구 생태계를 검색해 앱에 맞는 도구를 찾을 수 있다고 적습니다. 이는 편리함과 동시에 공급망(의존 패키지·외부 API) 리스크를 키울 수 있어, 허용 목록·버전 핀 같은 팀 규율이 없으면 금방 난장판이 됩니다.
결제·지도 같은 “진짜 세계” 연결은 자격증명이 필요하다. 즉 데모용 샘플과 운영용 키를 분리하지 않으면, 프롬프트 한 줄이 재무·개인정보 경계를 넘나들 수 있습니다. 이건 Google만의 문제가 아니라, Cowork Dispatch류 운영에서 반복되는 사고 패턴과 같습니다.

미니 시나리오 A — AI Studio에서 “협업 레시피 앱”을 빠르게 깎는 팀

Firebase 블로그가 예로 든 Heirloom Recipes류 앱을 상상해 보겠습니다. 팀은 UI 카피와 데이터 모델 초안을 AI Studio에서 빠르게 맞추고, Google 로그인까지 포함한 인증 흐름을 끼워 넣습니다. 이 단계에서의 목표는 사용자 시나리오가 끊기지 않는지를 이해관계자에게 보여 주는 것입니다.

이때 SDD 관점에서 미리 고정해 두면 좋은 것은 다음과 같습니다.

역할(role): 누가 읽기/쓰기 가능한가 (본인 데이터만? 가족 공유?)
문서 스키마: 레시피 필드, 태그, 이미지 URL 규칙
오프라인·동기화 요구: “실시간”이 진짜 필요한지, 아니면 배치 동기면 되는지

이 세 가지가 없으면 에이전트는 화려한 화면만 양산합니다. 반대로 이 세 가지가 있으면, AI Studio에서 나온 결과물이 Antigravity로 넘어갔을 때 리팩터링 비용이 줄어듭니다.

미니 시나리오 B — 같은 팀이 Antigravity에서 “결제 연동”을 붙이기로 한 경우

가상으로, 레시피 앱에 유료 구독을 붙이기로 했다고 칩시다. Firebase 블로그는 에이전트가 결제 프로세서 같은 외부 서비스를 찾아 연결하는 데 사용자의 자격증명이 필요할 수 있다고 말합니다. 운영에서의 체크리스트는 이렇게 바뀝니다.

샌드박스 키 vs 라이브 키 분리
Webhook 시크릿 회전 절차
환경 변수를 Git에 올리지 않는 팀 규율
에이전트가 생성한 결제 플로우 코드에 대한 페어 리뷰 (Artifacts나 PR 단위)

여기까지 오면 “AI Studio에서 잘 되던데?”가 “로컬·스테이징·프로덕션이 각각 다른 신뢰 경계”로 바뀝니다. 이 경계는 Antigravity의 터미널·브라우저·에디터를 오가는 에이전트가 더 자주 건드리므로, Manager Surface에 작업을 던지기 전에 Editor View에서 신뢰 경계를 문서화해 두는 편이 안전합니다.

Editor View vs Manager Surface — 역할을 이렇게 나눠 쓴다

공식 소개를 운영 언어로 번역하면 대략 다음 표에 가깝습니다. 이 표는 “정답”이 아니라 팀 규율 초안으로 쓰세요.

구분	Editor View (동기)	Manager Surface (비동기)
목적	내가 손으로 잡고 있는 변경	내가 잠시 손을 뗀 동안 진행되는 작업 패키지
전제	파일·터미널·브라우저를 즉시 조정 가능	에이전트가 여러 워크스페이스를 오갈 수 있음
검증	인라인 리뷰·로컬 실행	Artifacts (목록·플랜·캡처·녹화)
실패 시	바로 되돌리기 쉬움	중단 조건을 미리 안 쓰면 “어디까지 했지?”가 됨
팀 규율	브랜치·커밋 단위	작업 단위별 브랜치·아티팩트 승인자 지정

Manager Surface에 던지기 전에 Editor View에서 끝내야 할 최소 조건으로는 다음을 추천합니다.

브랜치 이름 규칙과 베이스 커밋 고정
실행 커맨드 (npm test, pnpm lint 등)를 README나 스크립트로 고정
완료 정의: “스크린샷 n장 + 테스트 통과 + PR 링크”처럼 검증 산출물을 문장으로 고정

이 세 줄이 있으면 Artifacts가 감상용 캡처가 아니라 릴리즈 게이트로 바뀝니다.

“넘기기”의 정의: 지금 가능한 것 vs 로드맵

1) Firebase Studio 사용자가 Antigravity로 옮기는 경우 (공식 절차가 있는 축)

Firebase 문서는 Antigravity 이전을 “지금 가능”으로 두고, 대략 다음을 안내합니다.

워크스페이스에서 Zip & Download 또는 커맨드 팔레트의 Firebase Studio: Zip & Download
로컬에 풀고 Antigravity로 열기
에이전트 창에서 @fbs-to-agy-export 프롬프트로 변환 작업을 돕게 하거나, 토큰을 아끼려면 npx firebase-tools@latest studio:export PATH 같은 수동 CLI 경로
Next.js·Flutter·Angular 워크스페이스에 최적화되어 있고, 다른 타입은 일부 아티팩트가 덜 갱신될 수 있다는 공식 한계 고지가 있습니다.

여기까지가 2026년 3월 기준 “넘긴다”의 실체에 가깝습니다. 완전 무인 원클릭 마법이라기보다, 보내기 + 로컬 IDE + 에이전트 보조의 조합입니다. (Firebase migrating-project)

2) Firebase Studio → Google AI Studio (아직 파이프라인이 열리는 중인 축)

Firebase 문서는 Google AI Studio로의 이전에 대해 “We’re still working on the migration pipeline”, 즉 신뢰할 수 있게 만들기 위해 준비 중이라고 적습니다. 동시에 Firebase 블로그(2026년 3월)에는 향후 수 주에 걸쳐 Firebase Studio에서 코드를 패키징해 Google AI Studio로 직접 가져오는 기능을 롤아웃한다는 설명이 있습니다.

정리하면: “곧 편해진다”는 방향은 맞지만, 언제·어떤 제약으로 열리는지는 공지·문서를 계속 봐야 하는 영역입니다. 데모 영상의 편집점처럼 보이는 완성도를 오늘 당장 기대하면 일정이 어긋납니다.

3) “AI Studio에서 만든 앱”을 Antigravity로 제품 차원에서 원터너로 잇는 이야기

사용자 커뮤니티에서 돌아가는 말과 달리, 이 글은 확인된 공식 문장만 채택합니다. Antigravity 공식 소개는 공개 프리뷰·개인 무료·크로스 플랫폼·모델 선택지를 강조하고, AI Studio 쪽은 Firebase 통합·코딩 에이전트 업그레이드를 Firebase 블로그와 Google 블로그가 각각 설명합니다. 두 축을 잇는 단일 버튼의 완성도는 마케팅과 문서 사이에서 시간차가 날 수 있으므로, 실무에서는 Git·폴더·프로젝트 ID·보안 규칙을 기준으로 경계를 잡는 편이 덜 다칩니다.

이럴 때 쓰고, 이럴 때는 굳이 안 써도 됩니다

쓸 만한 때

Firestore·Auth·App Hosting을 전제로 한 풀스택 실험을 빠르게 돌려보고, 데이터 모델과 인증 흐름을 사용자 시나리오와 함께 검증해야 할 때. (Firebase Blog의 통합 설명과 샘플 앱 흐름 참고)
브라우저만 되는 환경에서 이해관계자와 함께 UI를 굴리며, 백엔드 연결 여부를 승인 게이트로 통제하고 싶을 때. (“Enable Firebase”는 자동 강제가 아니라 승인 구조로 서술됩니다.)
로컬에서 터미널·브라우저·에디터를 오가는 대형 작업을 비동기 에이전트에게 떨어뜨리되, 중간 산출물을 Artifacts로 리뷰하고 싶을 때. (Antigravity Developers Blog의 Use case 2·3)
장기 유지보수 이슈를 백그라운드 에이전트에게 맡기고, 본업은 Editor View에서 동기 개발에 집중하고 싶을 때.

굳이 이 조합이 답이 아닐 때

규제·보안상 코드와 시크릿이 브라우저 기반 워크스페이스에 남는 것 자체가 정책 위배일 때. 이 경우는 로컬·VPC·자체 러너 쪽이 먼저입니다.
완료 정의(DoD) 없이 “에이전트가 알아서 하겠지”로 시작할 때. 에이전트는 DoD가 없으면 엉뚱한 완료를 아주 정교하게 생산합니다. 이건 Google 도구만의 문제가 아니라, 허브의 SDD 글에서 말한 명세의 가치와 연결됩니다.
팀 Git 규율·브랜치 전략·코드리뷰 없이 다중 에이전트만 늘릴 때. Manager Surface는 속도 도구이지 충돌 소멸 장치가 아닙니다.
CLI 자동화·CI 게이트가 없어서 “돌아간 것 같음”만으로 머지하는 팀. 이 경우 Antigravity를 쓰면 머지 속도만 빨라질 뿐, 장애 속도도 같이 빨라집니다. CLI 설계 글의 JSON·schema·dry-run 사고방식이 선행되는 편이 낫습니다.

실수 TOP: 여기서 시간이 탄다

보안 규칙을 ‘생성됨’으로 착각하기. Firebase 블로그는 Firestore Security Rules를 초안으로 만들 수 있지만 배포·공유 전 반드시 재검토하라고 못 박습니다. 프롬프트가 규칙을 “써줬다”는 사실과 “안전하다”는 사실은 다릅니다.
자주 나오는 장면: 데모에서 “다른 사용자 데이터가 보인다”는 제보가 들어온다. 원인은 규칙이 if true에 가깝게 열려 있거나, 테스트용 프로젝트 설정이 그대로 붙은 경우다.
즉시 할 일: 규칙 파일을 인간이 읽을 수 있는 형태로 PR에 올리고, 스테이징에서 읽기/쓰기 매트릭스를 표로 검증한다. AI가 써준 문장을 그대로 머지하지 않는다.
Studio 종료 일정을 개인 일정에 안 박기. 2026년 6월 22일 이후 신규 워크스페이스 생성 불가, 2027년 3월 22일 완전 종료·데이터 삭제는 문서에 명시된 하드 데드라인입니다. 팀 단위로는 지금 쓰는 워크스페이스 소유자가 누구인지부터 정리해야 합니다.
자주 나오는 장면: 휴가철 직전에 “예전에 파둔 스튜디오 앱”을 찾으려다, 소유자 계정이 막혀 있다.
즉시 할 일: 워크스페이스 목록을 스프레드시트로 만들고 소유자·마지막 배포일·Git 미러 여부를 채운다. 공유 워크스페이스는 문서대로 duplicate 가능 여부를 확인한다.
보내기 Zip에 node_modules·대용량 산출물을 그대로 넣기. Firebase 문서는 마이그레이션이 멈출 때 용량을 먼저 의심하라고 합니다. 로컬에서 npm install로 복구 가능한 것과, 반드시 같이 가야 하는 소스의 구분이 필요합니다.
자주 나오는 장면: Zip 생성은 됐는데 업로드/압축 해제에서 시간이 무한대로 간다.
즉시 할 일: .git 히스토리·빌드 산출물·미디어 원본을 분리한다. 필요하면 GitHub 미러를 먼저 만들고 Zip은 최소 단위로만 쓴다.
Antigravity 터미널에서만 npx가 안 될 때 .bashrc만 고집하기. 공식 트러블슈팅은 터미널이 ~/.bash_profile을 본다는 점을 짚고, .bashrc를 프로파일에서 source 하라고 안내합니다. “IDE 버그”로 치부하기 전에 셸 초기화 경로를 의심하는 게 빠릅니다.
자주 나오는 장면: macOS에서 터미널 앱은 되는데 Antigravity 터미널만 command not found.
즉시 할 일: 문서에 나온 대로 ~/.bash_profile에 if [ -f ~/.bashrc ]; then source ~/.bashrc; fi를 넣고 IDE를 재시작한다. 팀은 표준 셸을 문서화한다.
Artifacts 없이 ‘대충 믿기’. 로그만으로 승인하면, 나중에 재현 불가능한 결정이 쌓입니다. 스크린샷·워크스루·작업 목록은 감사 추적에 가깝게 취급하는 게 안전합니다.
자주 나오는 장면: “어제는 됐는데 오늘은 왜 안 되지?”에 대해 어제의 성공 조건을 아무도 설명 못 한다.
즉시 할 일: 작업 티켓에 아티팩트 링크 또는 첨부를 필수 필드로 둔다. 스크린샷은 어느 환경·어느 계정인지 캡션을 단다.
에이전트 채팅 이력을 ‘자동으로 옮겨준다’고 가정하기. Firebase 문서는 Zip에 에이전트 채팅 이력이 기본 포함되지 않는다고 명시하고, 특정 경로(.idx/ai)를 따로 압축하는 절차를 안내합니다. 운영에서의 교훈은 단순합니다. 대화는 지식이 아니라 이벤트 로그이고, 지식으로 남기려면 명세와 규칙으로 승격시켜야 합니다.
공유 워크스페이스에서 코드만 복사해 ‘내 프로젝트’인 척하기. 문서는 수동보내기 시 백엔드 설정이 원 소유자 자원을 가리킬 수 있다고 경고합니다. 이 상태로 배포하면 타인 프로젝트 과금·데이터 유출로 이어질 수 있습니다.

운영 체크리스트: 주간 점검에 그대로 붙여 넣기

아래는 허브_expand 관점에서 “AI 개발 워크플로우” 트래커에 붙일 수 있는 최소 질문 세트입니다. Yes/No로 답할 수 있게 짰습니다.

이번 주에 생성된 Firestore 규칙 변경은 전부 인간 리뷰 PR을 통과했는가?
프로덕션 키가 프론트 번들·레포·채팅 로그에 새로 노출된 흔적은 없는가?
Firebase Studio 의존 레포가 남아 있다면, 소유자·Zip·GitHub 미러 중 하나는 확보됐는가?
Antigravity Manager Surface 작업은 각각 브랜치·베이스 커밋·완료 정의가 티켓에 적혀 있는가?
배포 직전 Gemini API rate limit / billing tier를 공식 문서로 다시 확인했는가?

한 항목이라도 No면, 그 주의 우선순위는 새 에이전트 스킬 추가가 아니라 규율 메꾸기입니다.

비용과 쿼터: 공식 문서가 말하는 범위 안에서만

이 섹션은 제3자 요약 블로그나 커뮤니티 추정치를 배제하고, 인용 가능한 공식 문장만 둡니다.

Antigravity (공개 프리뷰)

Google Developers Blog(2025-11-20)는 Antigravity를 공개 프리뷰로 소개하며, 개인 사용자에게 무료라고 명시합니다. 또한 Gemini 3 Pro에 대해 관대한(rate limits) 한도, 그리고 Anthropic Claude Sonnet 4.5, OpenAI GPT-OSS 지원을 함께 언급합니다. 정확한 RPM/TPM 숫자는 프리뷰 정책이 변할 수 있으므로, 항상 제품 내 표시와 최신 공지를 우선하세요.

Build with Google Antigravity — Google Developers Blog (2025-11-20)

Gemini Developer API / AI Studio (과금·한도의 원천)

Google AI Studio 자체의 이용과 Gemini API의 요금·청구·사용 한도는 ai.google.dev 문서가 원천입니다. 모델별 가격표, 무료/유료 티어, Rate limits 문서에 정리된 RPM·TPM·RPD 같은 지표는 모델과 티어에 따라 변동합니다. 이 글은 특정 숫자를 박아 넣지 않고, 공식 가격·한도 페이지를 북마크해 두고 배포 직전에 다시 확인하는 방식을 권합니다.

Firebase / AI Studio 통합 문구

Firebase 블로그는 통합된 앱 클래스를 설명하며 free tier 언급과 함께, 기능 범위를 서술합니다. 다만 실제 과금은 연결된 GCP·Firebase 프로젝트 설정에 좌우되므로, “무료로 만들었다”와 “운영 비용이 0”은 다시 분리해서 봐야 합니다.

From prompt to production — The Firebase Blog (2026-03)

운영자가 직접 열어봐야 하는 페이지 (비용 사고의 최소 세트)

이 글은 숫자를 복사해 오지 않습니다. 대신 배포 전에 같은 자리를 다시 여는 습관을 권합니다.

Gemini API Pricing — 이번 주 선택한 모델이 입력/출력 토큰 단가에서 어떻게 잡히는지 확인합니다. 프리뷰 모델은 표가 자주 바뀝니다.
Rate limits — 같은 모델이라도 무료/유료 티어에 따라 RPM·TPM·RPD가 달라집니다. “어제 되던 호출이 오늘 429”는 대부분 여기서 답이 납니다.
Billing — 팀 프로젝트로 넘어갈 때 지출 상한, 결제 프로필, 티어 승급 조건을 확인합니다. 개인 실험과 팀 운영은 완전히 다른 곡선입니다.
GCP 콘솔의 Firebase 프로젝트 — Firestore 읽기/쓰기, 스토리지, 호스팅 전송량은 모델 비용과 별개로 청구될 수 있습니다. AI가 코드를 한 번에 많이 생성할수록 의도치 않은 읽기 폭증이 나오기 쉽습니다.

정리하면, LLM 요금 + 백엔드 사용량 + 외부 API(결제/지도) 세 층을 동시에 봐야 “한 달에 얼마 나왔지?”가 설명됩니다.

FAQ

Q1. Antigravity는 그냥 “VS Code + 챗봇” 아닌가요? 공식 소개는 에디터 + 터미널 + 브라우저를 넘나드는 작업 지향 에이전트와, Manager Surface에서의 비동기 다중 에이전트를 핵심 차별점으로 둡니다. 챗봇은 UI일 뿐이고, 운영에서는 Artifacts로 검증하는지가 체감 차이를 만듭니다.

Q2. Google AI Studio와 Antigravity 중 뭐만 써야 하나요? 둘 중 하나가 정답이라기보다, 프로토타입·협업·백엔드 연결은 AI Studio 축이, 로컬 깊이·장시간 자율 작업·다중 에이전트는 Antigravity 축이 유리한 경우가 많습니다. Firebase Studio 사용자는 문서 기준 Antigravity 이전은 지금, AI Studio 이전은 파이프라인 준비 중입니다.

Q3. Firebase Studio 안 써도 이 글이 의미 있나요? 있습니다. Studio 종료는 Google이 AI 개발 진입점을 AI Studio + Antigravity로 정리하겠다는 신호이기도 해서, 신규 프로젝트는 처음부터 두 축에 맞춰 설계하는 편이 덜 돌아갑니다.

Q4. 모델은 무엇을 써야 하나요? Antigravity는 공식 글에서 Gemini 3 Pro·Claude Sonnet 4.5·GPT-OSS를 함께 언급합니다. 마이그레이션 문서는 변환 작업에는 Gemini Flash를 추천해 토큰을 아끼라고 안내합니다. 즉 작업 유형별로 모델을 바꾸는 운영이 전제입니다.

Q5. “Interactions API”나 Workspace 스튜디오는 어디에 두면 되나요? 이 글의 범위 밖입니다. 혼동이 생기면 지금 해결하려는 작업이 (A) 웹 앱 프로토타입+Firebase인지, (B) 로컬 리포지토리 에이전트인지, (C) 완전히 다른 API 제품인지를 먼저 택일하세요.

Q6. 팀으로 쓸 때 최소한의 규율은? 브랜치·폴더 소유권·리뷰 게이트·시크릿 저장 위치·Artifacts에 대한 승인 기준 다섯 가지를 문서화하세요. ClawTeam 글의 worktree·세션 분리 사고방식과도 잘 맞물립니다.

Q7. NotebookLM과 Antigravity 연동 가이드는 이 글에 왜 안 나오나요? 볼트 안에 노트가 있다는 맥락은 있으나, 이 글은 공개 URL로 검증된 출처만 인용하는 TECHTAEK 허브 글입니다. 내부 노트 경로를 여기에 적지 않은 이유는 독자 재현성 때문입니다. 내부 자료는 Obsidian에서 따로 열어 보완하세요.

Q8. Codex·Claude Code와 Antigravity를 같이 쓰면 어떤가요? 도구를 늘리는 문제가 아니라 신뢰 경계 문제입니다. 각 런타임이 같은 리포지토리를 만지면 충돌이 납니다. 한 저장소에서는 한 시점에 하나의 에이전트 체인을 우선하고, 병렬은 worktree로 격리하세요. (ClawTeam 글 참고)

Q9. SkillsBench 글과 이 글의 연결점은? SkillsBench 글의 핵심은 스킬을 많이 만드는 것보다 검증이라는 점입니다. Antigravity의 Artifacts는 같은 철학이 UI 레이어에 올라온 형태로 읽을 수 있습니다. 다만 이 글은 SkillsBench 전용 URL을 제공받지 못해 본문 링크는 생략합니다.

Q10. “에이전트가 브라우저로 검증까지 한다”는데 믿어도 되나요? 공식 유스케이스는 코드 작성 → 터미널 실행 → 브라우저에서 확인까지를 한 흐름으로 설명합니다. 그러나 이는 자동 QA를 대체한다는 뜻이 아니라, 인간이 검토할 근거를 스크린샷·워크스루로 남기자는 뜻에 가깝습니다. 프로덕션 릴리즈에는 여전히 자동 테스트·스테이징·관측성이 필요합니다.

공식 출처

부록 A — Firebase Studio 일정만 공식 문서에서 발췌

아래 날짜는 Firebase Studio 마이그레이션 문서에 적힌 그대로입니다. 이 글은 해석을 최소화하고 일정 관리용으로만 둡니다.

날짜	의미
2026-03-19	Studio 종료 공지, 마이그레이션 도구 롤아웃 시작
2026-06-22	신규 워크스페이스 생성 불가 (기존 워크스페이스는 이전·작업 가능)
2027-03-22	Firebase Studio 완전 종료, 남은 데이터 영구 삭제

코어 Firebase 서비스는 별도로 계속된다는 점, 그리고 종료 대상이 Studio 개발 환경이라는 점을 헷갈리지 않는 것이 중요합니다.

부록 B — 제품 이름을 섞으면 생기는 사고 (3줄 요약)

Google AI Studio: 브라우저 중심의 빌드·프롬프트·앱 제작 축. 2026년 3월 기준 Firebase 통합과 코딩 에이전트 업그레이드가 공식 발표 축입니다.
Google Antigravity: 로컬 설치형 에이전트 퍼스트 IDE. Editor View와 Manager Surface, Artifacts가 공식 소개의 중심입니다.
Firebase Studio: 곧 종료되는 프리뷰 개발 환경. 백엔드 서비스 자체가 사라진다는 뜻이 아닙니다.

여기에 Gemini API의 다른 엔드포인트나 Workspace 제품군을 한 끼 식사처럼 한 그릇에 담으면, 글을 쓴 본인도 일주일 뒤에 어떤 콘솔을 열어야 하는지를 잊습니다. 글을 저장할 때 북마크 폴더도 위 세 덩어리로만 나눠 두세요.

부록 C — Antigravity 공식 유스케이스를 ‘업무 티켓’으로 번역

Developers Blog에 나온 세 가지 적용 예는, 운영에서는 다음처럼 티켓 제목으로 바꾸면 팀이 이해하기 쉽습니다.

“멀티 툴 기능 개발” 티켓: 코드·터미널·브라우저를 한 사이클에 쓰는 작업. 완료 정의에 로컬 실행 증거와 UI 캡처를 넣습니다.
“UI 반복 개선” 티켓: 화면을 고치고 스크린샷·워크스루 Artifact로 리뷰합니다. 코멘트는 Artifact에 남깁니다.
“백그라운드 유지보수/버그” 티켓: 재현→테스트→수정까지 비동기 에이전트에 맡기되, 브랜치와 충돌 가능 파일을 미리 분리합니다.

이렇게 번역해 두면 “에이전트 시대”라는 말이 회의실 용어에서 스프린트 백로그로 내려옵니다.

부록 D — 1주 실험 설계 (개인·소규모 팀용)

이 글을 “읽고 끝”내지 않으려면, 한 주짜리 실험으로 몸에 붙이는 편이 빠릅니다. 아래는 장비 영업이 아니라 판단 근육을 기르는 최소 과제입니다.

Day 1 — 경계 고정: 같은 저장소에 대해 “AI Studio에서만 할 일”과 “Antigravity에서만 할 일”을 각각 한 문장씩 적습니다. 예를 들어 전자는 데이터 모델·로그인 플로우 시연, 후자는 로컬 테스트·리팩터·배포 스크립트 같은 식입니다.

Day 2 — 명세 한 장: SDD 글의 톤을 빌려, 사용자 스토리 3개와 완료 정의를 종이 한 장에 적습니다. “에이전트가 알아서”라는 문장이 나오면 실패입니다. 주어는 항상 팀이거나 시스템 경계여야 합니다.

Day 3 — AI Studio에서 프로토타입: Firebase 통합이 필요하면 Enable Firebase 흐름을 실제로 밟되, 보안 규칙 파일을 PR로 분리합니다. 이 날의 목표는 시연이지 머지가 아닙니다.

Day 4 — Antigravity로 보내기 연습: Zip 또는 Git 미러 중 팀 규율에 맞는 방법으로 로컬 사본을 만듭니다. @fbs-to-agy-export를 쓰든 CLI를 쓰든, 산출물은 “어떤 파일이 바뀌었는지 목록”이어야 합니다.

Day 5 — Manager Surface에 작은 일 맡기기: 브랜치를 새로 치고, 문서화·테스트 보강·단순 리팩터 중 하나를 비동기 에이전트에 맡깁니다. 승인은 Artifact 기준으로만 합니다. 로그만 보고 승인하면 실험 실패입니다.

주말 — 회고: “시간이 줄었는가?”보다 먼저 “무엇이 검증 가능해졌는가?”를 씁니다. 후자가 Yes일 때만 도입을 이어가도 늦지 않습니다.

부록 E — 팀 회의에서 쓸 질문 카드 (역할 분리 점검)

아래 질문에 팀이 즉답을 못 하면, Antigravity의 병렬 에이전트를 켜는 것은 다음 스프린트로 미루는 편이 안전합니다.

우리는 프로덕션 비밀을 어디에 두고, 에이전트의 작업 범위에서 어떻게 제외하나요?
Firestore 규칙 변경은 누가 승인하며, 승인 기준 문서는 어디에 있나요?
동시에 돌아가는 에이전트가 같은 파일을 만질 때, 소유권 규칙은 무엇인가요?
Artifacts가 없는 작업을 완료로 칠 수 있나요? (Yes면 규율을 고쳐야 합니다)
Studio·AI Studio·Antigravity 중 어느 콘솔에서 무엇을 끄고 켜야 하는지 온콜이 설명할 수 있나요?

이 카드는 Google 제품이 아니라 팀의 신경계를 점검하는 용도입니다. 답이 문서화되면, 도구는 바뀌어도 팀은 덜 흔들립니다.

마지막으로 한 가지만 덧붙이면, 이 실험은 도구 전환 비용을 미리 치르는 행위입니다. 2027년 3월 22일은 아직 멀어 보이지만, 팀 단위로는 두 분기 전부터 움직여야 캘린더가 넉넉합니다. 공식 문서가 주는 시간은 관대해 보이지만, 사람 일정은 그렇지 않습니다.

메타 정보 (작성 시점 스냅샷)

사용한 도입부 유형: TYPE 6 (질문) — “왜 Google은 … 동시에 들고 올까요?”
idea_id: BLOG-20260321-004
hub_expand 실행 요약: “AI 개발 워크플로우” 허브에 Google 스택(AI Studio ↔ Antigravity ↔ Firebase 서비스) 관점의 경계·검증·마이그레이션 현황을 연결하는 하위 글로 확장. 기존 SDD·팀·CLI 글과 역할 분리·검증 우선 키워드로 정렬.
본문 ## 섹션 수: 본문 기준 20개 (지금 결론, 워크플로, AI Studio 변화, Editor/Manager, 넘기기 정의, 사용/비사용, 실수 TOP, 운영 체크리스트, 비용·쿼터, FAQ, 공식 출처, 관련 글, 부록 A~E, 메타).
전체 줄 수: 400줄 (wc -l 기준, 2026-03-21 작성). 발행 직전 로컬에서 한 번 더 확인 권장.
CTA: 별도 뉴스레터·제휴 링크 미제공으로 생략.
검증: 본문 인용 날짜·마이그레이션 문구는 2026-03-21 시점 공식 페이지와 대조됨.
볼트 경로: 02.Areas/blog/TECHTAEK/260321_Google-AI-Studio-Antigravity-에이전트-개발-워크플로-역할분리-검증-2026.md