Google의 Firebase Studio 종료, 개발자들을 최신 AI 도구로 이동시키다

Google은 2027년 3월 22일 Firebase Studio를 종료하고, 기반 Firebase 서비스는 계속 운영하는 한편 개발자들을 최신 AI 도구로 이동시키고 있다. Firebase Studio 종료에 따라 기존 사용자는 이미 배포된 애플리케이션에 호스팅 변경이 필요하지 않더라도 다른 개발 환경을 선택해야 한다. Google은 이들 개발자가 Antigravity 또는 Google AI Studio로 이동하기를 바라고 있다.

이 구분은 중요하다. 개발 환경은 소프트웨어를 작성하고, 테스트하고, 출시 준비를 하는 데 사용하는 도구들을 결합한 것이다. Firebase의 데이터베이스, ID 서비스, 호스팅은 별도로 작동한다. Google은 개발자가 애플리케이션을 구축하는 공간은 종료하는 반면, 해당 애플리케이션이 사용하는 인프라는 유지한다.

핵심 긴장은 연속성에 있다. Google은 이 전환을 더 단순한 제품 라인업으로 제시하지만, 기존 사용자는 그 단순화가 자신의 업무 환경을 개선하는지 판단해야 한다. Firebase Studio는 Google의 이전 브라우저 작업 공간인 Project IDX를 흡수했다. 이제 개발자들은 브라우저 프로토타이핑, 데스크톱 개발, 또는 코드를 다른 곳으로 옮기는 선택지 사이에서 또 한 번의 전환을 마주하고 있다.

Firebase Studio 종료는 이미 진행 중이다

이번 종료는 새롭게 발표된 11월 결정이 아니라, 이미 제한이 적용된 예정된 서비스 철수다.

Google은 2026년 3월 19일 서비스 종료를 발표했다. 신규 계정 등록과 작업 공간 생성은 2026년 6월 22일에 종료됐다. 기존 작업 공간은 최종 종료 시점까지 계속 접근할 수 있다. Google의 서비스 종료 일정에는 이러한 주요 시점이 기록돼 있으며, 이미 배포된 Firebase 애플리케이션은 이후에도 계속 작동한다고 확인한다.

따라서 11월 6일 현재 개발자들은 기존 프로젝트는 받을 수 있지만 새 작업 공간을 통한 확장은 더 이상 지원하지 않는 서비스 안에서 작업하고 있다. 이는 서비스의 실질적 역할을 바꾼다. 현재 작업을 유지하는 공간으로는 남아 있지만, 미래 프로젝트를 시작하는 장소로서 같은 역할을 제공하지는 않는다.

여러 애플리케이션을 관리하는 팀에게 이 구분은 계획 수립 문제를 만든다. 기존 작업은 일시적으로 익숙한 환경에 남을 수 있지만, 새 작업에는 다른 공간이 필요하다. 팀이 의도적으로 결정하지 않는다면 최종 기한이 오기 전에 개발 방식이 여러 환경으로 분리될 수 있다.

따라서 당장의 질문은 애플리케이션이 여전히 열리는지 여부보다 더 넓다. 팀은 향후 변경이 어디에서 이뤄질지, 누가 이를 수행할 수 있는지, 그리고 그러한 변경이 어떻게 사용자에게 전달되는지를 결정해야 한다. 작동 중인 프로덕션 애플리케이션만으로는 이 질문에 답할 수 없다.

Google의 입장은 질서 있는 전환의 여지도 남긴다. 개발자는 작동 중인 모든 Firebase 애플리케이션을 긴급 마이그레이션 대상으로 해석할 필요는 없다. Firebase Studio에 연결된 개발 의존성을 식별하고, 접근이 사라지기 전에 그 의존성을 대체하면 된다.

이 구분은 사안을 균형 있게 보는 데 도움이 된다. 서비스 철수는 실제 작업을 만들지만, 이를 Firebase의 종말로 묘사하는 것은 영향을 받는 제품을 잘못 지목하는 일이다. 또한 당면한 의무가 작업 공간에 관한 것일 때 불필요한 인프라 변경을 부추길 수 있다.

Firebase Studio 종료는 소프트웨어를 유지보수할 수 있는 능력을 보존하기 위한 마감 시한으로 이해하는 것이 가장 적절하다. 애플리케이션은 계속 이용 가능할 수 있지만, 관리자는 이를 업데이트하던 익숙한 경로를 잃을 수 있다. 결함, 보안 문제 또는 비즈니스 요청으로 새 릴리스가 필요해질 때 이 공백은 중요한 문제가 된다.

발표 시점은 또 다른 이유에서도 중요하다. 이는 더 이상 단순한 제품 로드맵 논쟁이 아니다. 오늘 선택지를 평가하는 개발자는 자신의 프로젝트로 대체 워크플로를 점검할 수 있다. 이제 결정은 후속 제품이 언젠가 제공할 기능에 대한 약속이 아니라, 입증된 연속성에 관한 것이다.

Google의 단순한 라인업은 기존 사용자에게 일을 만든다

Google은 개발자들에게 제품 간 전환을 감당하도록 요구하면서 제품 간 중복을 줄이고 있다.

통합에는 타당한 논거가 있다. 유사한 도구가 많으면 어디서 시작해야 하는지, 어떤 제품이 새 기능을 받는지, 또는 어느 문서가 적용되는지 파악하기 어려울 수 있다. 브라우저 프로토타이핑과 데스크톱 개발을 더 명확히 구분하면 신규 사용자는 더 이해하기 쉬운 출발점을 얻는다.

기존 사용자는 같은 결정을 다르게 경험한다. 이들은 이미 출발점을 선택했고, 인터페이스를 익혔으며, 그에 맞춰 업무를 조직했다. 미래 고객을 위한 더 단순한 선택 화면이 기존 사용자가 그러한 습관을 다시 구축하는 비용을 자동으로 보상하지는 않는다.

압박은 코드 주변의 환경에 워크플로가 의존하는 사람들에게 가장 직접적으로 가해진다. 소스 파일은 애플리케이션을 구성하지만, 실제 작업 환경에는 지침, 개발 명령, 권한, 릴리스 관행도 포함된다. 이러한 책임을 옮기려면 폴더를 복사하는 것보다 더 많은 판단이 필요하다.

내부 승인 애플리케이션을 유지보수하는 작은 팀을 생각해 보자. 애플리케이션은 여전히 직원들에게 정상적으로 서비스를 제공할 수 있다. 실질적인 마이그레이션 질문은 다른 권한 있는 관리자가 종료되는 작업 공간에 의존하지 않고 변경을 수행하고, 검증하고, 배포할 수 있는지다.

이는 보도된 고객 사례가 아니라 예시 시나리오다. 마이그레이션 성공은 일반적인 유지보수 작업을 통해 판단해야 하는 이유를 보여준다. 성공적인 가져오기는 파일이 도착했음을 보여준다. 성공적인 릴리스는 팀이 소프트웨어 운영 능력을 회복했음을 보여준다.

부담은 조직마다 다르다. 독립 개발자는 개인적인 실험을 통해 도구를 바꿀 수 있다. 기업은 대체 환경이 애플리케이션을 유지하는 모든 사람에게 쓸 수 있게 되기 전에 접근 권한, 설치 규칙, 문서화, 지원 책임을 조율해야 할 수 있다.

브라우저를 열어 작업을 재개하는 데 익숙한 사람에게 데스크톱 환경은 다른 운영 방식을 도입한다. 반대로 로컬 도구를 직접 제어하고 싶은 개발자라면 이 변화를 반길 수 있다. 어느 쪽 선호도 마이그레이션이 간단하다는 사실을 입증하지는 않는다.

이 전환은 소유권에 대한 질문도 제기한다. 원래 구축자만 새 환경을 이해한다면 애플리케이션은 여전히 그 사람에게 의존한다. 지속 가능한 마이그레이션은 다음 관리자가 소스 코드만으로는 분명해지지 않았던 결정까지 포함해 작업을 이어갈 충분한 맥락을 제공한다.

그러한 맥락을 검색 가능한 지식 베이스에 보관하면 인수인계를 지원할 수 있다. 관련 자료에는 아키텍처 결정, 릴리스 지침, 알려진 제한 사항, 그리고 특이한 구성 선택의 배경이 포함된다.

바로 이 지점에서 Google의 단순화 주장은 현실적인 단서가 필요하다. 제품 통합은 전체 라인업을 개선하는 동시에 특정 고객의 작업량을 늘릴 수 있다. 두 결과는 모두 사실일 수 있으며, 마이그레이션 지원의 품질이 이들 사이의 충돌을 얼마나 크게 만드는지 결정한다.

기업 구매자에게 이는 전환 지원이 제품 평가의 일부임을 뜻한다. 개발 도구는 이를 떠나는 데 필요한 작업을 기준으로도 평가해야 한다. 서비스 종료는 보통 가정에 머물던 이 질문을 즉각적인 책임으로 바꾼다.

Antigravity와 AI Studio는 Firebase Studio가 결합했던 작업을 나눈다

대체 전략은 Firebase Studio가 처음에는 함께 제공하려 했던 개발자 선호를 분리한다.

Firebase Studio는 2025년 4월 9일 프리뷰로 출시됐다. Google의 초기 작업 공간 발표는 Project IDX, 앱 프로토타이핑, 코딩 작업 공간, 배포 옵션을 결합한 통합 경험을 설명했다. 이 발표는 자연어 기반 빌더와 자체 기술 선택지를 가져오는 숙련 개발자 모두를 명시적으로 대상으로 했다.

이러한 이력은 현재의 전환을 일반적인 에디터 교체보다 더 흥미롭게 만든다. Google은 처음에 통합을 장점으로 제시했다. 이제 Google이 선호하는 구성은 작업을 별도의 제품에 분산하며, 각기 다른 환경이 서로 다른 개발 스타일을 지원한다.

Antigravity는 데스크톱 방향을 대표한다. Google AI Studio는 프롬프트와 앱 생성이 경험의 중심인 브라우저 방향을 대표한다. 이 선택은 개발자가 어디에서 작업할지, 그리고 구현과 얼마나 직접적으로 상호작용하고 싶은지에 관한 것이다.

AI 코딩 에이전트는 프로젝트를 검사하고 개발 작업을 수행하기 위해 도구를 사용할 수 있는 소프트웨어다. 그 역할은 다음 코드 줄을 제안하는 데 그치지 않는다. 에이전트가 중심이 될수록 인터페이스는 사람들이 작업을 지시하고, 변경 사항을 검토하며, 결과가 수용 가능한지 판단하도록 도와야 한다.

Google은 업그레이드된 AI Studio 경험이 모델의 행동과 도구를 조율하는 소프트웨어인 Antigravity의 에이전트 하니스 핵심 구성 요소를 사용한다고 말한다. 사용자 승인을 거쳐 제공되는 Firebase 통합은 데이터베이스와 로그인 설정을 지원할 수 있다. Google은 공유 레시피 애플리케이션을 통해 이 접근 방식을 설명한다.

이 예시는 제품 논리를 설명한다. 공유 레시피 앱에는 생성된 화면 이상이 필요하다. 지속적인 정보와 활동을 사람과 연결하는 방법이 필요하다. 이러한 기능을 제작 환경 안에서 연결하면 매력적인 프로토타입과 실제로 사용할 수 있는 애플리케이션 사이의 거리를 줄일 수 있다.

이는 통합에 기술적 근거를 제공한다. AI Studio가 앱 제작과 Firebase 통합을 조율할 수 있다면, 별도의 Firebase 브랜드 환경은 Google의 제품 서사에서 덜 필수적이 된다. 인프라는 개발 도구의 이름이나 인터페이스를 결정하지 않고도 애플리케이션을 지원할 수 있다.

하지만 이를 Firebase Studio에 AI가 없었다는 주장으로 확대해서는 안 된다. 출시 발표부터 이미 AI는 핵심 제안이었다. 변화는 기존 코딩에서 AI 개발로 깔끔하게 전환되는 것이 아니라, 제품 구성과 선호되는 작업 인터페이스에 관한 것이다.

이 구분은 모든 개발자를 하나의 단일한 사용자층으로 취급하는 방식의 한계도 드러낸다. 브라우저 접근은 어떤 사람에게는 필수적이고, 다른 사람에게는 부수적일 수 있다. 로컬 도구에 대한 세부적인 제어는 어떤 팀에게는 가치가 있지만, 다른 팀에게는 관리상의 장애물이 될 수 있다.

Firebase Studio 대안을 검토하는 사용자에게 이러한 구분은 모델 브랜딩을 비교하기에 앞서 고려해야 한다. 대체 환경은 실제 유지보수 과정에 맞아야 한다. 인상적인 데모만으로는 특정 팀이 일상 업무를 재현할 수 있는지 입증할 수 없다.

따라서 이번 전환은 구체적이다. Google의 이전 통합 작업 공간은 더 세분화된 라인업으로 바뀌고 있다. Google은 이것이 개발을 더 명확하게 만든다고 주장한다. 기존 사용자는 그 결과로 나온 선택지가 결합형 제품에서 자신들이 중요하게 여긴 유연성을 보존하는지 확인해야 한다.

코드 내보내기로는 전체 개발 워크플로를 보존할 수 없다

가장 강력한 마이그레이션 증거는 대상 환경에서 검증된 유지보수 주기다.

Google의 프로젝트 마이그레이션 안내는 대체 제품과 다른 환경으로 이동하는 경로를 제공한다. 또한 중요한 한계도 명시한다. 표준 내보내기 아카이브에는 에이전트 채팅 기록이 포함되지 않으며, 마이그레이션 도구가 모든 프로젝트 아티팩트를 반드시 업데이트하는 것은 아니다.

그러한 세부 사항은 이식성에 신중한 해석이 필요한 이유를 보여준다. 코드 이식성이란 개발자가 자신의 파일을 확보할 수 있다는 뜻이다. 워크플로 이식성이란 이전한 뒤에도 애플리케이션을 이해하고, 수정하고, 테스트하고, 출시할 수 있다는 뜻이다. 전자는 후자를 뒷받침하지만, 그것만으로 후자가 성립하는 것은 아니다.

채팅 기록은 그 차이를 잘 보여준다. 대화에는 우회 방법의 설명, 포기한 접근 방식, 또는 최종 코드에 일부만 반영된 요구 사항이 담겨 있을 수 있다. 그 기록을 잃는다고 해서 반드시 애플리케이션이 망가지는 것은 아니다. 다만 다음 변경을 평가하기는 더 어려워질 수 있다.

이는 개발자가 프롬프트를 통해 애플리케이션의 상당 부분을 만들었을 때 특히 중요하다. 결과물 파일은 무엇이 존재하는지를 보여주지만, 대화는 작성자가 무엇을 의도했는지 설명할 수 있다. 이 기록들이 서로 다를 때 유지보수 담당자는 의도된 동작을 식별할 수 있을 만큼의 맥락이 필요하다.

배포는 또 다른 경계를 만든다. 배포란 사용자가 접근하는 환경에 애플리케이션 버전을 출시하는 것을 의미한다. Google은 기존 App Hosting 주소를 유지하는 방법과, 다른 호스팅 구성을 도입하는 Cloud Run 경로를 함께 문서화하고 있다.

따라서 팀은 개발 도구를 바꾸는 일과 프로덕션 호스팅을 바꾸는 일을 구분해야 한다. 두 변경을 함께 진행하는 것이 적절할 수는 있지만, 검토 대상 작업은 늘어난다. 관련 없는 인프라 변경이 동시에 발생하면 마이그레이션 결정을 진단하기가 더 까다로워진다.

자격 증명도 비슷한 주의가 필요하다. 이는 소프트웨어가 서비스에 접근할 수 있도록 하는 키와 기타 비밀 정보다. Google의 안내는 대체 워크플로를 기존 인프라에 연결할 때 개발자가 처리해야 하는 구성 책임을 설명한다.

여기서 중요한 분석은 운영 관점이다. 대체 환경이 프로젝트를 올바르게 열 수 있어도, 프로덕션 출시를 위해 필요한 구성이 부족할 수 있다. 에디터와 에이전트가 정상적으로 작동하는 것처럼 보여도 이는 마이그레이션 공백이다.

Google의 문서에는 Firebase Studio에 남아 있는 워크스페이스 데이터가 종료 시 영구 삭제된다고도 명시되어 있다. 따라서 독립적인 보존은 중요한 문제가 된다. 개발자는 기존 워크스페이스가 계속 이용 가능하리라는 가정 대신, 프로젝트를 유지하는 데 필요한 자료를 직접 검증한 기록으로 보존해야 한다.

이러한 사항 중 어느 것도 마이그레이션 도구가 일반적으로 실패한다는 점을 입증하지는 않는다. 문서는 그런 결론을 뒷받침할 만큼 충분한 증거를 제공하지 않는다. 대신 성공적인 파일 전송만으로 연속성이 보장된다는 보편적 증거가 되는 것을 막는 경계를 식별한다.

공정한 평가는 애플리케이션 결함과 마이그레이션 결함도 구분한다. 원래 워크스페이스에 존재하던 문제를 자동으로 대체 환경의 책임으로 돌려서는 안 된다. 마찬가지로 에이전트가 결국 문제를 해결했다는 이유만으로 새로운 구성 작업이 평가에서 사라져서도 안 된다.

유용한 비교는 대표적인 작업을 처음부터 끝까지 따라간다. 팀이 요청을 이해하고, 변경을 수행하고, 동작을 검증하고, 새 구성으로 배포할 수 있는가? 이 결과는 오류 메시지 없이 가져오기가 완료됐는지보다 더 큰 의미를 가진다.

경쟁 코딩 도구가 연속성을 경쟁의 일부로 만든다

Firebase 인프라를 유지한다고 해서 개발자가 Google의 에디터에 계속 충성하는 것은 아니므로, Google은 대체 환경 경험을 통해 개발자를 붙잡아야 한다.

더 넓은 시장에는 이미 코딩 에이전트를 중심으로 구성된 개발 도구가 존재한다. Cursor의 agent capabilities에는 코드베이스 검색, 파일 편집, 터미널 명령 실행, 오류 대응 기능이 포함된다. 해당 문서는 클라우드 에이전트를 통한 브라우저 접근도 설명한다.

이 비교는 에이전트 기능만으로는 Google의 경쟁적 위치를 설명할 수 없는 이유를 보여준다. 여러 제품이 개발 작업 전반에 걸친 지원을 약속할 수 있다. 의미 있는 차이는 프로젝트에 어떻게 맞춰지는지, 변경 사항을 어떻게 드러내는지, 중단을 어떻게 처리하는지, 지속적인 유지보수를 어떻게 지원하는지에서 나타난다.

여기서 검토한 증거만으로는 모든 기존 Firebase Studio 사용자에게 독립적으로 확립된 승자는 없다. 브라우저 작업을 선호한다고 해서 선택이 결정되는 것은 아니다. 주변 개발 워크플로가 해당 모델이 무엇을 할 수 있는지 결정한다는 점에서, 특정 모델을 선호하는 것 역시 선택을 확정하지 않는다.

이미 Google 인프라를 사용하는 개발자에게 Google은 분명한 장점을 갖고 있다. 바로 익숙함이다. 연관된 제품 안에 머무르면 팀이 새롭게 익혀야 하는 지식의 양을 줄일 수 있다. 이는 그럴듯한 이점이지만, 실제 마이그레이션 결과에서 확인되어야 한다.

경쟁 환경에는 다른 기회가 있다. 강제 전환은 사용자가 이전에는 그대로 두었던 가정을 다시 검토하는 계기를 만든다. 개발자가 어차피 새 작업 환경을 평가해야 하는 상황이라면 Google의 권장 사항을 다른 도구와 비교할 수 있다.

따라서 중요한 경쟁 질문은 연속성을 통한 유지다. Google의 대체 환경이 애플리케이션을 보존하고 이후 작업을 더 쉽게 만든다면, 통합은 Google의 입지를 강화할 수 있다. 개발자가 반복해서 워크플로를 재구축해야 한다면, 마이그레이션은 경쟁사에 기회가 된다.

이 점은 생산성 주장도 읽는 방식을 바꾼다. 초기 구현을 빠르게 만들어내는 에이전트도 검토나 수정 작업을 추가로 만들 수 있다. 중요한 결과에는 승인된 출시까지 도달하는 데 필요한 노력도 포함된다.

유지보수되는 비즈니스 애플리케이션에서는 인상적인 생성 데모보다 예측 가능한 인수인계가 더 중요할 수 있다. 팀은 무엇이, 왜 바뀌었는지와 필요 시 어떻게 되돌릴지를 알아야 한다. 에이전트가 구현의 상당 부분을 수행하더라도 이러한 요구 사항은 남는다.

비교에는 AI 지원 없이 이루어지는 작업도 포함되어야 한다. 개발자는 여전히 파일을 점검하고, 실패를 이해하며, 에이전트가 요청을 잘못 이해했을 때 작업을 이어갈 수 있는 방법이 필요하다. 위임 중심으로 구성된 인터페이스도 직접적인 조사를 지원해야 한다.

따라서 Firebase Studio 대안은 동일한 애플리케이션 및 유지보수 작업을 기준으로 평가해야 한다. 그렇지 않으면 사용자는 익숙한 도구에 누적된 문제와 대체 도구의 신중하게 선별된 데모를 비교하게 될 위험이 있다. 그런 비교는 운영상 개선을 입증하지 못한 채 새로움에 유리하게 작용한다.

Google의 결정이 클라우드 개발 환경이 시대에 뒤떨어졌음을 증명하는 것은 아니다. 이는 Google이 개발 제품을 어느 곳에 집중하려 하는지에 대한 선택을 보여준다. 브라우저 접근의 지속적인 중요성은 이 특정 워크스페이스의 운명과는 별개다.

궁극적으로 경쟁 압력은 이동 후에도 남는 것이 개선될 때에만 사용자에게 이익이 된다. 더 많은 에이전트 기능은 실제 소프트웨어 유지보수에 드는 노력을 줄일 때 중요하다. 개발자가 에이전트에 필요한 맥락을 반복해서 재구성해야 한다면 그 중요성은 낮아진다.

마이그레이션 신뢰성, 워크플로 범위, 반복 배포를 지켜봐야 한다

다음으로 유용한 증거는 Firebase Studio를 떠난 뒤에도 일반적인 프로젝트가 성공적으로 지속되는 사례에서 나올 것이다.

향후 몇 달간 첫 번째 신호는 마이그레이션 신뢰성이다. 지원되는 프로젝트 유형에 관한 더 명확한 문서, 해결된 변환 문제, 반복 가능한 이전 사례를 살펴봐야 한다. 이 부분의 개선은 통합이 관리 가능한 전환을 만든다는 Google의 주장을 강화할 것이다.

그 증거의 질은 중요하다. 성공적인 시연은 선택된 프로젝트 하나가 이전되었음을 증명한다. 더 폭넓은 신뢰를 얻으려면 최초 생성 이후 크게 변경된 프로젝트를 포함해 다양한 작업 패턴을 다루는 사례가 필요하다. 일반적인 구성에서 반복되는 문제는 단순화 주장을 약화시킬 것이다.

두 번째 신호는 워크플로 범위다. 브라우저 중심 사용자가 호스팅된 워크스페이스를 가치 있게 만들었던 작업을 보존할 수 있는지 지켜봐야 한다. 또한 데스크톱 사용자가 대체 환경을 반복해서 즉흥적으로 마련하지 않고도 프로젝트의 구성과 개발 관행을 복구할 수 있는지도 살펴봐야 한다.

이 신호는 핵심 제품 분화를 시험한다. 대체 환경이 이러한 서로 다른 요구를 분명하게 충족한다면 Google의 제품군은 실제 사용에서 더 이해하기 쉬워진다. 사용자가 이전 워크플로에서 빠진 부분을 복구하기 위해 계속 도구 사이를 오간다면, 주장된 명확성은 설득력을 잃는다.

세 번째 신호는 마이그레이션 이후의 반복 배포다. 가져오기 성공은 초기 이정표다. 지속적인 유지보수는 개발자가 애플리케이션에 대한 통제권을 회복했고 새 요구 사항에 대응할 수 있다는 더 강력한 증거를 제공한다.

가장 드러나는 사례는 실제 변경, 수행한 검증, 그 결과로 이루어진 배포를 설명할 것이다. 반복적인 구성 수정이나 누락된 프로젝트 맥락에 관한 보고는 반대 방향을 가리킬 것이다. 홍보용 앱 수치나 개별 불만만으로는 전체 결과를 단독으로 확립할 수 없다.

이러한 신호는 분석에 합리적인 한계도 설정한다. Google이 공개한 종료 일정은 무엇이 닫힐지를 확립한다. 제품 발표는 개발자가 무엇을 사용하기를 의도하는지 보여준다. 어느 출처도 모든 고객이 이전에 얼마나 많은 시간을 쓸지를 독립적으로 확립하지는 않는다.

현재 Firebase Studio 종료는 부담이 고르지 않은 명확한 의무를 만든다. Google은 후속 제품을 제시했고 기반 Firebase 서비스도 유지했다. 개발자는 선택한 환경이 자신이 만든 것을 유지할 능력을 보존하는지 여전히 검증해야 한다.

남은 접근 기간을 그 연속성을 확립하는 시간으로 활용해야 한다. 대표적인 애플리케이션 변경 하나를 선택해 요청 이해부터 결과 배포까지 대체 환경에서 따라가야 한다. 다른 유지보수 담당자에게 필요한 프로젝트 결정과 구성 지식을 보존해야 한다. 검토와 수정에 든 노력을 포함해 완료된 작업을 통해 대체 환경을 평가해야 한다. Google의 최신 AI 도구도 다른 선택지와 함께 이 기준으로 평가받아야 한다. 기존 워크스페이스가 사라지기 전에, 팀의 다른 누군가가 떠나는 환경에 의존하지 않고도 자신 있게 애플리케이션을 유지보수하고 배포할 수 있는가?