Firebase Studio 일몰 공지
Firebase Studio 종료, 써봤더니
이미 막히는 지점이 있었습니다
구글이 2026년 3월 19일, Firebase Studio의 종료를 공식 발표했습니다. 최종 종료일은 2027년 3월 22일이지만, 새 워크스페이스 생성은 2026년 6월 22일부터 막힙니다. 지금 당장 이전을 준비해야 하는 이유가 있습니다.
Firebase Studio가 뭐였는지 먼저 짚고 넘어가야 합니다
Project IDX에서 시작한 브라우저 기반 AI 개발 환경
Firebase Studio는 구글이 2025년 4월 10일 Cloud Next 행사에서 공개한 클라우드 기반 풀스택 AI 개발 환경입니다. 기원은 2023년에 실험적으로 시작된 Project IDX로, 이후 Firebase 브랜드 아래 통합됐습니다. 브라우저 하나로 앱 프로토타이핑부터 Firestore 연결, Firebase App Hosting 배포까지 한 번에 처리할 수 있다는 게 핵심이었습니다.
로컬 환경 구성 없이 Chromebook이나 태블릿에서도 개발이 가능하다는 점이 차별점이었습니다. Gemini 모델을 에이전트로 활용해 코드 생성과 수정을 자연어로 지시할 수 있었고, App Prototyper 모드에서는 프롬프트 몇 줄로 작동하는 앱을 만들 수 있었습니다.
출시 직후에는 “구글이 드디어 Replit에 제대로 된 경쟁자를 내놨다”는 평가도 있었습니다. 그러나 출시 11개월 뒤인 2026년 3월 19일, 종료 발표가 나왔습니다.
출시 11개월 만의 일몰 — 타임라인이 말하는 것
💡 공식 발표문과 Reddit 커뮤니티 반응을 같이 놓고 보니, 이 제품이 얼마나 짧은 사이클을 갔는지가 한눈에 들어왔습니다.
종료 발표가 빠른 게 아닙니다 — 일몰 기간이 출시 기간보다 더 깁니다
Firebase Studio는 2025년 4월 10일 출시됐고, 2026년 3월 19일에 종료 발표가 났습니다. 출시에서 종료 발표까지 약 11개월이 걸렸습니다. 그런데 공식 종료일은 2027년 3월 22일입니다. 종료 발표 시점부터 실제 서비스 종료까지는 12개월 이상이 남아 있습니다. Reddit 커뮤니티 사용자 ‘puf’는 이 구조를 간결하게 정리했습니다: “제품이 라이프사이클의 절반 이상을 일몰 기간으로 보내는 게 구글 역사상 최초 아닐까?” (출처: r/Firebase, 2026.03.19)
이 수치가 의미하는 건 단순합니다. 구글이 충분한 이전 시간을 줬다는 건 맞지만, 제품 자체가 예상보다 훨씬 빠르게 방향을 바꿨다는 것도 사실입니다.
공식 타임라인 3단계
| 날짜 | 단계 | 실질적 의미 |
|---|---|---|
| 2026.03.19 | 종료 발표 + 이전 도구 순차 배포 | 지금 즉시 이전 준비 가능 |
| 2026.06.22 | 신규 워크스페이스 생성 차단 | 이 날 이후 새 프로젝트 시작 불가 |
| 2027.03.22 | 완전 종료 + 데이터 영구 삭제 | 미처 옮기지 못한 코드는 복구 불가 |
(출처: firebase.google.com/docs/studio/migrating-project, 2026.03.19)
“Firebase가 사라진다”는 말은 틀렸습니다
💡 이번 종료 소식에 Firebase 자체가 없어진다고 오해하는 경우가 많습니다. 공식 문서를 직접 확인하고 나서야 구조가 정리됐습니다.
종료되는 건 개발 환경(IDE), 서비스는 그대로입니다
구글 공식 문서는 이 점을 명확히 합니다. “이번 일몰은 Firebase Studio 개발 환경에만 적용됩니다. Cloud Firestore, Authentication, App Hosting 등 핵심 Firebase 서비스는 Firebase Studio 외부에서도 계속 정상 작동합니다.” (출처: firebase.google.com/docs/studio/migrating-project) 즉, Firebase를 백엔드로 쓰고 있는 기존 앱이나 서비스는 아무 영향이 없습니다.
없어지는 건 브라우저에서 Firebase Studio URL로 접속하던 그 개발 공간입니다. 데이터베이스가 날아가는 게 아니라, 코드를 작성하던 작업실이 문을 닫는 겁니다.
오히려 Firebase 기능은 더 넓어집니다
구글은 이번 통합을 통해 Google AI Studio에 Cloud Firestore와 Firebase Authentication을 직접 연결했습니다. 이제 AI Studio에서 앱을 프롬프트로 만들면, 에이전트가 알아서 Firestore를 프로비저닝하고 인증 코드를 생성해줍니다. Firebase Studio가 했던 일을 AI Studio가 흡수한 형태입니다. (출처: firebase.blog/posts/2026/03/announcing-ai-studio-integration)
이전 경로 2가지, 공식 문서대로 따라가면 막히는 부분
⚠️ 주의 Google AI Studio 이전 경로는 아직 완성되지 않았습니다. 공식 문서에 “We’re still working on the migration pipeline”이라고 명시돼 있습니다. (출처: firebase.google.com/docs/studio/migrating-project, 2026.03.19)
경로 A: Antigravity (현재 사용 가능)
코드 중심 로컬 개발을 선호한다면 Antigravity로 이전하는 게 공식 권장 경로입니다. Firebase Studio에서 “Move now” 버튼을 누르면 자동 마이그레이션 에이전트가 작동합니다. 이 과정에서 에이전트가 파일을 변환하고 Firebase 연결을 재설정해줍니다. 실제로 써본 사람들 반응은 엇갈립니다. 프로젝트를 GitHub에 백업해둔 사람은 클론으로 바로 이전이 됐지만, “Zip and Download” 버튼이 아무 반응을 안 했다는 사례도 커뮤니티에서 여럿 나왔습니다.
공식 문서가 직접 설명한 원인은 브라우저 팝업 차단입니다. “Zip and Download 버튼이 작동하지 않으면 브라우저의 팝업 차단 기능 때문일 가능성이 높습니다.” (출처: firebase.google.com/docs/studio/migrating-project) 주소창 오른쪽에서 팝업 허용을 먼저 설정해야 합니다. 자동화 마이그레이션이 안 된다면 수동 내보내기(`npx firebase-tools@latest studio:export PATH`)로 대체할 수 있습니다.
경로 B: Google AI Studio (준비 중, 미완성)
웹 기반 작업을 선호하거나 App Prototyper 모드 중심으로 썼다면 AI Studio가 맞는 경로입니다. 그런데 현재(2026.03.24 기준) AI Studio 이전 파이프라인은 아직 배포되지 않았습니다. 공식 문서에는 “Check back soon”이라고만 나옵니다. 지금 당장 AI Studio로 자동 이전이 가능하다는 말은 공식 문서 어디에도 없습니다.
Antigravity로 이전할 때 실제 절차
에이전트 자동 이전 vs 수동 이전 — 어떤 걸 택해야 할까요?
자동 이전은 Firebase Studio의 “Move now” 버튼을 누른 뒤 파일을 로컬에 내려받고, Antigravity에서 @fbs-to-agy-export 프롬프트를 에이전트에게 넘기면 됩니다. 에이전트가 프로젝트 변환을 자동 처리합니다. 구글은 이 과정에서 Gemini Flash 모델을 쓰도록 권장합니다. 파일 변환 같은 대량 작업에서 토큰을 절약하면서도 속도가 빠르기 때문입니다.
수동 이전이 더 안전한 경우도 있습니다. 프로젝트 크기가 크거나 node_modules가 정리되지 않은 경우, 자동화가 타임아웃으로 멈출 수 있습니다. 이럴 때는 터미널에서 직접 npx firebase-tools@latest studio:export .를 실행하고, node_modules와 대용량 미디어 파일은 미리 삭제하는 게 낫습니다. (출처: firebase.google.com/docs/studio/migrating-project)
이전 후 꼭 챙겨야 하는 것들
채팅 이력은 이전 파일에 포함되지 않습니다. 프롬프트 기록이 필요하다면 워크스페이스의 /home/user/.idx/ai 디렉토리를 별도로 압축 다운로드해야 합니다. 환경 변수 파일(.env, .env.local)도 자동 포함되지 않습니다. 실제 커뮤니티 사용자들이 “다 옮긴 줄 알았는데 .env가 없어서 앱이 안 켜졌다”는 경험을 공유했습니다. (출처: r/Firebase, 2026.03.19)
Antigravity의 터미널은 시스템의 ~/.bashrc가 아닌 ~/.bash_profile을 읽습니다. Node나 npm 경로 설정이 ~/.bashrc에만 있다면 Antigravity 터미널에서 “command not found” 오류가 납니다. 공식 문서에서 권장하는 해결책은 bash_profile에 source ~/.bashrc를 추가하는 것입니다.
Antigravity vs Cursor — 지금 갈아타야 할까요?
💡 Antigravity가 빠른 건 맞지만, 그 속도 이면에 있는 리스크까지 같이 보니 사용 조건이 달랐습니다.
속도 벤치마크는 좋은데, 에러 수정 시간은 빠진 숫자입니다
독립 테스트 결과, Next.js + Supabase 풀스택 기능 구현에서 Antigravity는 42초, Cursor는 68초가 걸렸습니다. (출처: blog.getbind.co/antigravity-vs-cursor, 2026.01.18) 42초가 68초보다 빠른 건 맞습니다. 그런데 이 수치는 에이전트가 자율적으로 실행한 뒤 발생한 오류를 수정하는 시간은 포함하지 않습니다. 실제로는 에러 수정 시간까지 더해야 합니다.
커뮤니티에서 자주 언급되는 사고 사례가 있습니다. Antigravity 에이전트가 캐시 삭제 지시를 잘못 해석해 사용자의 D 드라이브 전체를 삭제한 일이 있었습니다. 도구가 “apology”를 보냈다는 말이 나왔고, 파일은 복구되지 않았습니다. (출처: blog.getbind.co) 에이전트 자율성이 높은 만큼 지시가 명확하지 않으면 범위를 벗어난 행동이 생길 수 있습니다.
어떤 상황에서 뭘 써야 하는지 정리
| 상황 | Antigravity | Cursor |
|---|---|---|
| 빠른 프로토타이핑·실험 | ✓ 유리 | — |
| 프로덕션 코드 정밀 수정 | — | ✓ 유리 |
| 브라우저·터미널 자동화 | ✓ 유리 | 제한적 |
| 안정성·예측 가능성 | 프리뷰 단계 | ✓ 유리 |
| 모델 선택 자유도 | Gemini·Claude·GPT | OpenAI·Claude 등 |
(출처: blog.getbind.co/antigravity-vs-cursor, 2026.01.18 / firebase.google.com/docs/studio/migrating-project, 2026.03.19)
Q&A
마치며
Firebase Studio 종료는 구글이 AI 개발 도구 라인업을 정리하는 과정입니다. 제품이 사라지는 게 아니라, 더 강해진 두 도구(Google AI Studio, Antigravity)로 역할이 나뉘는 겁니다. 실제 데이터베이스와 인증 서비스는 아무 영향이 없고, 오히려 AI Studio에서 Firebase 기능을 더 쉽게 쓸 수 있게 됐습니다.
막히는 지점은 명확합니다. Google AI Studio 이전 경로는 아직 준비 중이고, 자동 이전 버튼은 브라우저 팝업 설정 하나 때문에 먹통이 되기도 합니다. .env 파일은 수동으로 챙겨야 하고, Antigravity 터미널은 bashrc가 아닌 bash_profile을 읽습니다. 이걸 모르면 이전 직후에 앱이 안 켜지는 상황을 만납니다.
6월 22일 신규 워크스페이스 생성 마감 전에 환경을 옮겨두는 게 현실적인 기준입니다. 아직 시간은 있지만, AI Studio 이전 경로가 언제 열릴지는 공개된 정보가 없습니다. Antigravity로 먼저 이전해두고 AI Studio 경로를 나중에 선택하는 순서가 지금으로서는 가장 안전합니다.
본 포스팅 참고 자료
본 포스팅은 2026년 3월 24일 기준, Firebase Studio 공식 문서 및 공개 자료를 바탕으로 작성됐습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 최신 정보는 공식 마이그레이션 문서에서 확인하시기 바랍니다.
댓글 남기기