Gemini가 앱 제작을 맡으면서 Google이 AI Studio 모바일 앱을 취소하다

Google은 Android와 iOS용 별도 AI Studio 앱 계획을 발표한 지 불과 두 달 만에 해당 제품을 Gemini에 흡수하고 있다. 9to5Google의 Google 관련 보도에 따르면 이 모바일 앱들은 취소됐다. Google은 이제 앱 제작 기능을 Gemini 자체에 통합하고, 궁극적으로 모바일과 데스크톱 소프트웨어 모두를 대상으로 할 계획이다.

이는 Google의 또 다른 취소된 실험 이상의 의미를 지닌다. 휴대폰에서 제작할 수 있는 전용 공간으로 AI Studio 모바일을 내세웠던 회사의 I/O 2026 발표를 뒤집는 결정이다. Google은 대신 사람들이 이미 사용하는 어시스턴트 안에 앱 생성 기능이 있어야 한다고 판단하는 것으로 보인다.

이 결정은 독립형 개발 환경과 통합형 대화 환경을 맞세운다. AI Studio는 웹에서 계속 이용할 수 있지만, Gemini의 월간 사용자는 9억 명이 넘는다. 제작 기능을 이 더 큰 제품에 통합하면 앱 개발은 별도의 목적지가 아니라 대화의 일상적인 일부가 될 수 있다.

9to5Google의 Google 관련 보도가 전하는 변화

Google은 소프트웨어 제작을 일상 기기에서 접근 가능하게 하려는 더 큰 노력이 아니라, 독립형 모바일 컨테이너를 취소했다.

Google은 5월 19일 열린 Google I/O에서 Android 및 iOS 전용 AI Studio 앱 사전등록을 사용자에게 안내했다. 계획된 경험은 휴대폰에서 완전한 Build mode를 제공하겠다고 약속했다. Build mode는 애플리케이션을 생성하고 미리 볼 수 있는 AI Studio의 프롬프트 기반 환경이다.

Google은 책상에서 떨어진 곳에서 아이디어를 포착하는 것으로 시작되는 워크플로를 설명했다. 이후 사용자는 코드를 반복 수정하고, 빌드를 미리 보고, 갤러리 프로젝트를 리믹스하며, 라이브 배포본을 공유할 수 있었다. 같은 작업은 나중에 데스크톱에서 계속할 수 있었다.

회사의 기존 모바일 앱 계획은 휴대성을 핵심 장점으로 다뤘다. 휴대폰은 다른 곳에서 생성된 앱을 단순히 표시하는 기기가 아니라, 작지만 온전한 개발 환경이 되는 구상이었다.

iOS 등록 페이지는 7월 출시 예정일을 시사했고, Android 사용자는 Google Play에서 사전등록할 수 있었다. 그러나 두 버전 모두 처음 발표된 방식으로는 아직 공개되지 않았다.

7월 31일자 앱 취소 보도에 따르면, Google은 이 전략을 변경했다. 회사는 전용 AI Studio 모바일 클라이언트에서 물러나 Gemini 안에서의 앱 제작에 초점을 맞추고 있다.

Google의 공개적인 설명은 사용자가 궁극적으로 일반적인 Gemini 대화를 통해 모바일 및 데스크톱 애플리케이션을 만들게 될 것임을 시사한다. 누군가 여행을 논의하거나, 업무를 정리하거나, 실용적인 문제를 해결하는 과정에서 아이디어가 떠오를 수 있다. Gemini는 그 필요를 인터랙티브 소프트웨어로 전환할 수 있다.

이 표현은 서로 다른 상호작용 모델을 설명한다는 점에서 중요하다. AI Studio에서는 사용자가 앱 아이디어를 가지고 개발 환경에 들어가야 한다. 반면 Gemini는 사용자가 이미 목표를 설명하는 동안 소프트웨어의 기회를 파악할 수 있다.

이 차이는 시작점을 바꾼다. 사용자는 시작하기 전에 애플리케이션이 해답이라고 결정할 필요가 없다. Gemini는 근본적인 작업을 이해한 뒤 인터페이스를 제안하거나 생성할 수 있다.

Google은 이 기능의 상세한 출시 일정을 공개하지 않았다. 또한 어떤 플랫폼, 계정 유형 또는 국가에 먼저 제공할지도 정의하지 않았다. 취소는 구체적이지만, 대체 방안은 아직 미래의 제품 방향에 머물러 있다.

AI Studio 자체가 종료되는 것은 아니다. 웹 제품은 여전히 앱 생성, 모델 실험, 배포, 네이티브 Android 개발을 지원한다. 취소된 제품은 계획됐던 독립형 모바일 클라이언트다.

이 경계는 중요하다. 일부 반응은 이 결정을 Google이 AI Studio를 없애는 일로 묘사했지만, 현재 उपलब्ध한 근거는 그 결론을 뒷받침하지 않는다. Google은 소비자 대상 제작 경험이 자리할 위치를 바꾸고 있다.

따라서 9to5Google의 Google 관련 보도에는 후퇴와 확장이 함께 담겨 있다. 약속됐던 두 개의 모바일 앱은 사라졌다. 그러나 그 근저의 야심은 이제 데스크톱 애플리케이션과 훨씬 더 큰 Gemini 이용자층까지 포함한다.

이러한 전환은 핵심 질문을 낳는다. 범용 어시스턴트가 본격적인 앱 제작에 충분한 제어 기능을 제공할 수 있을까, 아니면 통합이 AI Studio를 유용하게 만든 명확성을 지워버릴까?

Google은 전용 빌더 대신 Gemini의 도달 범위를 택하고 있다

취소된 앱은 하나의 분명한 목적지를 없애지만, Google에는 수억 명의 기존 사용자 앞에 앱 생성 기능을 배치할 기회를 제공한다.

Google은 5월 Gemini가 230개국 이상, 70개 이상의 언어권에서 월간 사용자 9억 명 이상에게 서비스를 제공한다고 밝혔다. 1년 전 회사는 사용자 수가 4억 명이라고 보고했다. 이 수치는 Google이 제시한 것으로, 독립적인 감사를 거치지 않았다.

그러한 단서를 감안하더라도 규모 차이는 상당하다. AI Studio는 개발자, 기술 창작자, Gemini 모델을 적극적으로 실험하는 사람들을 대상으로 한다. Gemini 앱은 개발자 도구를 한 번도 방문하지 않을 수 있는 더 폭넓은 이용자층에 도달한다.

Google의 Gemini 앱 업데이트 역시 통합이 현재 전략에 부합하는 이유를 보여준다. 회사는 Gemini를 질의응답 챗봇에 머물게 하기보다 범용 작업 계층으로 전환하고 있다.

I/O에서 Google은 사용자 지시에 따라 백그라운드 작업을 수행하도록 설계된 에이전트 Gemini Spark를 공개했다. 또한 파일 생성, 연결된 서비스, 선제적 지원 기능을 확장했다. 앱 제작은 대화를 실행 가능한 결과물로 바꾸기 때문에 이 방향에 들어맞는다.

제품 출시를 계획하는 프로젝트 매니저를 생각해 보자. 대화 과정에서 상태 대시보드, 리스크 추적기, 피드백 분류 도구의 필요성이 드러날 수 있다. Gemini는 사용자가 별도 개발 제품을 열지 않아도 그러한 인터페이스를 생성할 수 있다.

교사는 답변마다 적응하는 교실 퀴즈를 요청할 수 있다. 영업 관리자는 공유 스프레드시트와 연결된 모바일 입력 양식을 요청할 수 있다. 여행자는 여행 일정에 관한 대화를 오프라인 체크리스트로 바꿀 수 있다.

이러한 사례는 Google이 통합 기능을 출시하기 전까지는 가정에 머문다. 그럼에도 대화 맥락이 중요한 이유를 보여준다. Gemini는 애플리케이션을 생성하기 전에 이미 사용자의 목표, 제약 조건, 파일, 선호하는 결과물을 알고 있을 수 있다.

전용 AI Studio 앱은 더 적은 맥락에서 시작하게 된다. 프로젝트 기록에는 접근할 수 있겠지만, 사용자는 여전히 현실의 문제를 개발 요청으로 번역해야 한다. Gemini는 잠재적으로 그 번역 단계를 없앨 수 있다.

이 지점에서 Google의 Workspace 통합은 전략적으로 유용해진다. AI Studio는 이미 Sheets, Drive, 문서와 함께 작동하는 애플리케이션을 만들 수 있다. 이러한 연결은 생성된 소프트웨어가 사람들이 업무에서 사용하는 정보에 작동하도록 한다.

회사의 개발자 하이라이트는 AI Studio를 더 넓은 사슬 안에 배치했다. 사용자는 AI Studio에서 프로토타입을 만들고, 프로젝트를 Antigravity로 내보낸 뒤, 배포를 향해 작업을 이어갈 수 있었다.

Gemini는 같은 사슬의 첫 단계가 될 수 있다. 의도를 포착하고 초기 경험을 생성하는 역할이다. 이후 프로젝트의 요구가 커질 때 AI Studio나 Antigravity가 더 깊은 제어 기능을 제공할 수 있다.

이 구조는 대체라기보다 퍼널에 가깝다. Gemini는 대규모 이용자층에 앱 제작 기능을 제공한다. AI Studio는 브라우저 기반 제작을 담당하고, Antigravity는 더 광범위한 개발과 에이전트 오케스트레이션을 지원한다.

과제는 매끄러운 인계를 유지하는 것이다. 생성된 애플리케이션은 인증, 데이터베이스, 권한, 결제, 외부 서비스가 추가될수록 유지 관리가 더 어려워진다. 사용자는 코드, 구성, 테스트, 배포 기록에 접근할 수 있어야 한다.

Google은 Gemini 프로젝트가 이러한 전문 도구 환경으로 어떻게 이동할지 설명하지 않았다. 대화 맥락, 생성된 파일, 시크릿, 배포 설정이 함께 이동할지 여부도 밝히지 않았다.

회사는 이미 맥락을 첨부한 상태로 AI Studio 프로젝트를 Antigravity로 내보내는 기능을 지원한다. Gemini에서 출발하는 비슷한 연결 고리가 있다면 통합 전략의 신뢰도는 더 높아질 것이다. 그런 연결이 없다면 생성된 앱은 일시적인 시연물에 그칠 위험이 있다.

Google 입장에서는 도달 범위 논리가 여전히 설득력 있다. 별도의 모바일 이용자층을 구축하려면 설치, 온보딩, 반복적인 참여가 필요하다. Gemini는 이미 이러한 관계를 갖추고 있으며 Android, iOS, 웹, 데스크톱에서 자리를 차지하고 있다.

사용자에게도 통합은 제품 혼란을 줄인다. Google은 Gemini, AI Studio, Android Studio, Firebase, Antigravity 그리고 여러 클라우드 개발 서비스를 제공한다. 또 하나의 모바일 애플리케이션은 이해해야 할 새로운 경계를 추가했을 것이다.

그럼에도 도달 범위가 채택을 보장하지는 않는다. 사람들은 소프트웨어와 무관한 수많은 작업을 위해 Gemini를 연다. Google은 일반적인 대화를 방해하거나 원치 않는 인터페이스를 만들어 내지 않으면서 앱 생성 기능을 발견 가능하게 해야 한다.

9to5Google의 Google 관련 보도는 배포에 대한 승부수를 포착한다. Google은 앱 제작 기능을 가장 큰 어시스턴트 안에 등장시키기 위해 집중된 제품을 포기하고 있다. 그 선택의 성공은 이용자 규모만이 아니라 실행력에 달려 있다.

진정한 전환은 앱 아이디어가 시작되는 지점이다

Google은 처음에 의도적인 제작을 중심으로 모바일 AI Studio를 설계했지만, Gemini 계획은 대화 중에 드러나는 필요에서 출발한다.

기존 개념은 익숙한 개발 순서를 따랐다. 누군가 아이디어를 떠올리고, AI Studio를 열어 애플리케이션을 설명하고, 결과물을 검토한 뒤 배포본을 공유한다. 휴대폰은 기기를 바꿨을 뿐 기본 워크플로는 바꾸지 않았다.

새로운 개념은 워크플로 자체를 바꾼다. 사용자는 소프트웨어를 요청하는 대신 문제를 논의하는 것으로 시작할 수 있다. Gemini는 인터랙티브 애플리케이션이 유용한 응답이라고 판단할 수 있다.

이것이 이 글의 핵심 전환이다. Google은 “빌더를 열라”에서 “적절할 때 어시스턴트가 만들게 하라”로 이동하고 있다. 이는 주도권을 사용자에게서 모델 쪽으로 옮긴다.

이 접근 방식은 대화형 AI 제품 전반에 이미 등장하고 있는 기능을 기반으로 한다. 어시스턴트는 문서, 스프레드시트, 차트, 인터랙티브 시각화, 작은 코드 기반 결과물을 만들 수 있다. 애플리케이션은 이러한 결과물 모델을 더 크게 확장한 것이다.

Google은 4월 Gemini에 다운로드 가능한 파일 생성 기능을 추가했다. 사용자는 채팅을 떠나지 않고 문서, 스프레드시트, PDF 및 기타 형식을 요청할 수 있다. 회사는 이제 소프트웨어를 대화가 만들어낼 수 있는 또 하나의 결과물로 자리매김하고 있다.

애플리케이션은 상태와 동작을 지닌다는 점에서 파일과 다르다. 사용자 입력을 받고, 외부 서비스를 호출하며, 정보를 저장하거나 시간에 따라 변화할 수 있다. 이는 생성을 더 유용하게 만들지만, 실패 가능성도 더 많이 만든다.

Google AI Studio는 이미 인터페이스, 서버 로직, 연결된 데이터 서비스를 결합하는 프롬프트 기반 풀스택 애플리케이션을 지원한다. 현재의 Build mode 가이드는 Gemini 기능, 배포, 서버 측 시크릿 처리를 중심으로 앱 생성을 설명한다.

웹 도구는 눈에 보이는 개발 제어 기능을 제공한다. 사용자는 코드를 검사하고, 프롬프트를 조정하며, 동작을 테스트하고, 서비스를 연결하고, 배포를 관리할 수 있다. 이러한 제어 기능은 대화와 소프트웨어 엔지니어링 사이에 개념적 경계를 만든다.

Gemini의 대화형 인터페이스는 의도적으로 덜 기술적이다. 이는 접근성을 높이지만, 중요한 결정을 숨길 수도 있다. 생성된 애플리케이션에도 여전히 권한, 데이터 규칙, 오류 처리, 보안 경계가 필요하다.

Google은 그 복잡성 중 얼마나 많은 부분을 채팅에 드러낼지 결정해야 한다. 설정이 지나치게 많으면 Gemini는 통합 개발 환경처럼 느껴질 것이다. 반대로 너무 적으면 사용자는 생성된 애플리케이션이 무엇을 하는지 판단할 수 없게 된다.

모바일 및 데스크톱 생성은 또 다른 층위의 문제를 더한다. Google은 AI Studio에서 Kotlin과 Android의 현대적 인터페이스 프레임워크인 Jetpack Compose를 활용해 네이티브 Android 앱을 만드는 기능을 시연했다. 사용자는 브라우저 기반 에뮬레이터에서 코드를 미리 보고, 빌드를 내부 테스트 트랙으로 전송할 수 있다.

데스크톱 개발은 정의가 더 불분명하다. Google은 Gemini를 통해 지원할 운영체제, 애플리케이션 프레임워크, 패키징 형식, 배포 방식을 아직 밝히지 않았다.

“Desktop apps”는 Windows 및 macOS용으로 설치 가능한 소프트웨어를 의미할 수 있다. 더 큰 화면에 최적화된 웹 애플리케이션을 뜻할 수도 있다. 이는 본질적으로 다른 약속이므로 Google은 이 용어를 명확히 정의해야 한다.

iOS 경로도 마찬가지로 불확실하다. AI Studio가 발표한 네이티브 개발 지원은 Android에 집중됐다. Google은 네이티브 iPhone 애플리케이션을 생성하는 동등한 Swift 기반 워크플로를 발표하지 않았다.

iOS 클라이언트를 취소한다고 해서 자동으로 iOS 개발 지원이 생기는 것은 아니다. 그 클라이언트는 사람들이 iPhone에서 AI Studio를 사용하도록 했을 것이다. 네이티브 iOS 소프트웨어를 반드시 생성해 주는 것은 아니었을 것이다.

이 구분은 헤드라인에서 쉽게 사라질 수 있다. Google은 Gemini가 궁극적으로 모바일 애플리케이션을 만들게 될 것이라고 말하지만, 출력 형식은 여전히 명시되지 않았다. 모바일 친화적인 웹 앱은 스토어 출시가 가능한 네이티브 애플리케이션과 같지 않다.

Google 계획의 가장 강력한 형태는 대화를 통해 필요를 파악하고, 작동하는 인터페이스를 만들며, 사용자가 출력 대상을 선택하게 하는 방식일 것이다. 이후 배포 전에 코드와 테스트 도구를 제공하게 된다.

더 약한 형태는 Gemini 내부에서만 작동하는 일회성 인터랙티브 카드를 만드는 방식일 것이다. 그러한 경험도 사용자에게 도움이 될 수는 있지만, 독립적인 모바일 또는 데스크톱 소프트웨어에 대한 일반적 기대에는 부합하지 않는다.

제품의 경계는 누가 압박을 받게 될지를 결정한다. 프롬프트 기반 빌더는 전용 작업 공간, 재사용 가능한 프로젝트, 호스팅, 배포를 제공하며 경쟁한다. Gemini의 대화형 결과물이 계속 편집 가능하고 이식 가능하다면 이들을 위협할 수 있다.

전통적인 개발 환경은 다른 압박을 받는다. Google이 단일 프롬프트로 전문 엔지니어링을 대체하는 것은 아니다. 많은 사용자가 이미 자신의 필요를 설명하는 공간으로 초기 프로토타이핑을 옮기고 있다.

개발자는 코딩 도구를 한 번도 열지 않은 동료들로부터 부분적으로 생성된 프로젝트를 더 많이 받게 될 수 있다. 이는 발견 과정을 가속할 수 있지만, 유지보수 작업도 만들 수 있다. 생성된 코드는 민감한 정보를 다루거나 실제 고객에게 서비스를 제공하기 전에 여전히 검토가 필요하다.

팀은 대화형 프로토타입을 완성된 제품이 아니라 요구사항 산출물로 취급함으로써 대비할 수 있다. 프롬프트, 예상 동작, 테스트 케이스, 소스 자료를 보존해야 한다. 검색 가능한 엔지니어링 문서 모음은 이러한 인수인계를 더 쉽게 만들 수 있다.

Google의 판단은 누군가 자신이 소프트웨어를 개발하고 있다고 인식하기 전부터 앱 제작이 시작된다는 데 있다. Gemini는 이미 그 이전 단계에 자리하고 있다. AI Studio는 그렇지 않다.

Gemini 앱 제작에는 여전히 통제 문제 가 있다

통합 전략은 마찰을 줄이지만, Google은 Gemini가 테스트, 보안, 이식성, 장기 유지보수를 어떻게 처리할지 보여주지 않았다.

첫 번째 불확실성은 제품 정의에 관한 것이다. Google은 완성된 기능이 아니라 미래 방향을 설명했다. Gemini 내부의 모바일 및 데스크톱 생성에 대한 공개 출시일, 지원 플랫폼 목록, 상세 시연은 없다.

이 공백은 독립형 앱이 사전 등록을 받을 만큼 구체적이었다는 점에서 중요하다. Google은 기능을 발표하고, 인터페이스를 보여주며, 기기 간 워크플로를 설명했다. 현재의 대체안은 운영 측면의 세부 정보가 더 적다.

두 번째 불확실성은 사용자 통제에 관한 것이다. 대화는 의도를 수집하는 데는 좋지만 구조화된 프로젝트 관리의 부실한 대체재다. 애플리케이션에는 버전 기록, 파일, 종속성, 환경 변수, 배포 설정, 반복 가능한 테스트가 필요하다.

사용자는 Gemini가 애플리케이션을 제안하는 시점도 이해해야 한다. 복잡한 질문마다 자동으로 인터페이스를 생성하면 혼란이 생긴다. 명시적인 요청을 기다리면 앱이 대화에서 자연스럽게 등장한다는 약속은 약해진다.

Google은 명확한 동의 단계를 마련해야 한다. Gemini는 애플리케이션을 제안하고, 무엇에 접근할지 설명한 뒤, 사용자에게 생성을 승인해 달라고 요청할 수 있다. 이는 대화형 발견 과정을 유지하면서 사용자의 통제권도 지킬 수 있다.

권한에도 비슷한 접근이 필요하다. 스프레드시트에 연결된 대시보드는 로컬 계산기와 다른 접근 권한이 필요하다. 이메일을 보내거나 고객 정보를 저장하는 애플리케이션은 인터랙티브 차트보다 더 큰 위험을 수반한다.

Google의 Firebase 문서는 이미 개발자에게 Gemini API 키를 클라이언트 코드에 넣지 말라고 경고한다. 연결된 서비스에는 보안 규칙과 애플리케이션 검사도 권장한다. Gemini가 프로젝트를 생성했다는 이유만으로 이런 안전장치가 사라져서는 안 된다.

생성된 애플리케이션에는 안전하지 않은 기본 설정, 신뢰할 수 없는 로직, 알려진 취약점을 가진 종속성이 포함될 수 있다. 세련된 인터페이스가 애플리케이션의 안전성을 보장하지는 않는다. Gemini가 설득력 있는 미리보기를 만들었다는 이유로 사용자는 품질을 과대평가할 수 있다.

따라서 9to5Google의 Google 기사는 Gemini가 소프트웨어 팀을 대체할 수 있다는 증거로 읽혀서는 안 된다. Google은 배포 및 인터페이스 전략을 발표했다. 모바일과 데스크톱 플랫폼 전반에서 신뢰할 수 있는 엔드투엔드 개발을 입증하지는 않았다.

이식성도 또 다른 위험이다. 사용자는 생성된 코드를 내보내고, 다른 곳에 배포하며, Gemini 없이 개발을 계속할 수 있는지 알아야 한다. 대화 안에 갇힌 프로젝트는 장기적인 작업에서 가치가 제한적이다.

AI Studio는 현재 코드 중심 워크플로와 다른 Google 개발 도구와의 연결을 제공한다. 이는 프로토타입에서 유지 관리되는 프로젝트로 이어지는 경로를 만든다. Gemini도 AI Studio, Antigravity, Android Studio 또는 다른 표준 환경으로 나가는 동등하게 명확한 경로가 필요하다.

플랫폼 전반의 테스트도 더 복잡해진다. 데스크톱 애플리케이션은 Windows와 macOS에서 다르게 동작할 수 있다. 모바일 애플리케이션은 화면 크기, 권한, 백그라운드 활동, 배터리 사용량, 스토어 정책을 고려해야 한다.

Google은 Android와 Google Play를 통제하므로 직접적인 테스트 및 배포 경로를 갖고 있다. Apple의 개발 환경이나 App Store 심사 절차는 통제하지 않는다. 크로스플랫폼 주장은 반응형 인터페이스 생성 이상의 증거를 필요로 한다.

회사의 I/O 시연은 Android에 유용한 기준을 제시했다. AI Studio는 Kotlin 코드를 생성하고, 브라우저 에뮬레이터에서 실행하며, Android Debug Bridge를 통해 연결하고, 내부 테스트 트랙에 게시할 수 있었다. 사용자가 결과물을 배포 가능한 소프트웨어로 간주하기 전에 Gemini는 이러한 통제 수준을 갖춰야 한다.

고급 사용자에게는 발견 가능성 문제도 있다. AI Studio는 실험을 위해 설계된 환경에서 모델, 프롬프트, 도구, 코드를 분리한다. Gemini의 더 단순한 인터페이스는 모델 선택을 가리거나 이러한 사용자가 필요로 하는 구성 옵션을 없앨 수 있다.

통합은 Google이 서로 다른 통제 수준을 보존할 때만 작동한다. 일반 사용자는 자동 생성된 미니 앱을 받아들일 수 있다. 개발자는 구현을 검사하고 작동 방식을 변경할 수 있어야 한다.

사용자 반응은 이미 양쪽 측면을 모두 보여준다. 일부 사람들은 AI Studio가 모바일 브라우저를 통해 작동하므로 독립형 앱이 불필요하다고 본다. 다른 이들은 제작 기능을 Gemini에 통합하면 AI Studio의 더 깊은 통제 기능에 대한 접근성이 줄어들 것을 우려한다.

대체 제품이 출시되기 전에는 어느 쪽 관점도 결론낼 수 없다. 이번 취소는 오늘날 애플리케이션 혼잡을 줄인다. 동시에 Google이 Gemini가 동등한 경험을 제공한다는 것을 보여주기 전에 약속된 경험을 없앤다.

Google의 제품 역사는 이해할 만한 회의론을 더한다. 회사는 종종 중복되는 서비스를 통합하지만, 사용자는 그러한 전환 과정에서 워크플로를 잃을 수 있다. 취소된 사전 등록은 실제 작동하는 소프트웨어 없이 미래의 약속을 평가하기 더 어렵게 만든다.

신중한 해석은 제한적이다. Google은 대화형 앱 제작이 독립형 AI Studio 모바일 클라이언트보다 더 큰 전략적 가치를 지닌다고 본다. 그 결정이 제작자에게 이득이 되는지는 내보내기, 테스트, 플랫폼 지원, 신뢰성에 달려 있다.

Google, 개발자, 경쟁사가 다음으로 입증해야 할 것

세 가지 신호는 Google이 앱 제작을 위한 더 나은 경로를 찾았는지, 아니면 대체 제품이 준비되기 전에 제품을 취소했을 뿐인지 보여줄 것이다.

첫 번째 신호는 작동하는 Gemini 앱 생성 미리보기다. Google은 편집 가능한 애플리케이션으로 이어지는 완전한 대화를 보여줘야 한다. 시연에는 생성된 동작, 권한, 테스트, 내보내기 경로가 포함돼야 한다.

기본적인 인터랙티브 카드는 더 큰 주장을 약화시킬 것이다. 컨텍스트를 그대로 유지한 채 AI Studio 또는 Antigravity로 이동하는 프로젝트는 Google의 통합 전략을 뒷받침할 것이다.

두 번째 신호는 정확한 플랫폼 정의다. Google은 모바일 및 데스크톱 앱이 무엇을 의미하는지 설명해야 한다. 개발자는 Gemini가 네이티브 코드, 크로스플랫폼 패키지, 프로그레시브 웹 앱, 또는 Gemini에 한정된 경험을 생성하는지 알아야 한다.

네이티브 Android 지원은 Google이 이미 발표한 기능을 기반으로 할 수 있다. 네이티브 iOS, Windows 또는 macOS 결과물에는 새로운 도구 체인과 배포 워크플로가 필요하다. 각 대상은 서로 다른 기술적 및 정책적 요구사항을 만든다.

세 번째 신호는 경쟁 빌더의 대응 방식이다. 프롬프트-투-앱 제작에 집중하는 서비스는 예측 가능한 편집, 배포, 통합, 코드 소유권을 강조할 수 있다. 또한 Google의 점점 늘어나는 제품군보다 크로스플랫폼 지원을 더 쉽게 이해하도록 만들 수 있다.

경쟁사가 자연어 프로토타입에서 유지 관리되는 코드로의 인수인계를 개선한다면, Google의 배포 우위가 시장을 결정하지 못할 수 있다. 사용자는 더 명확한 통제를 제공한다면 추가 애플리케이션을 기꺼이 받아들이는 경우가 많다.

Google은 AI Studio의 지속적인 역할도 명확히 해야 한다. 웹 도구를 계속 제공하는 것만으로는 충분하지 않다. 회사는 어떤 작업이 Gemini에서 시작되고, 어떤 작업이 AI Studio로 이동하며, 어떤 작업이 Antigravity 또는 Android Studio에 속하는지 설명해야 한다.

그 지도는 일반 제작자와 전문 팀 모두에게 도움이 될 것이다. 그것이 없으면 제품군은 같은 질문에 대한 여러 개의 중복된 답처럼 느껴질 수 있다.

개발자에게 단기적 대응은 실용적이어야 한다. 아직 출시되지 않은 Gemini 기능을 중심으로 워크플로를 재설계하지 말아야 한다. 프로젝트 요구에 부합할 때는 AI Studio의 현재 웹 도구를 계속 사용해야 한다.

동시에 엔지니어링 외부에서 시작되는 프로젝트를 주시해야 한다. 동료들은 머지않아 일상적인 Gemini 대화 중 생성된 프로토타입을 가져올 수 있다. 팀은 그러한 산출물이 검토, 테스트, 보안 평가, 소유권 관리에 어떻게 들어올지 결정해야 한다.

기업 구매자는 시연 속도보다 거버넌스에 집중해야 한다. 생성된 애플리케이션이 어떤 데이터에 접근했는지, 어떤 코드가 배포됐는지, 각 권한을 누가 승인했는지를 보여주는 기록이 필요하다.

지식 근로자는 Gemini가 요청 없이 얼마나 자주 애플리케이션을 제안하는지 지켜봐야 한다. 유용한 제안은 반복 업무를 작고 개인화된 도구로 바꿀 수 있다. 좋지 않은 제안은 대화를 더 탐색하기 어렵게 만들 수 있다.

핵심 경쟁은 전용 빌더와 통합 어시스턴트 사이에 남아 있다. AI Studio는 의도, 구조, 가시적인 통제를 제공한다. Gemini는 맥락, 배포력, 더 낮은 시작 장벽을 제공한다.

Google은 통합 어시스턴트를 주요 소비자 경로로 선택했다. 그러나 프로토타입이 중요해진 뒤 필요한 통제를 이 경로가 보존할 수 있다는 점은 아직 입증하지 못했다.

이는 취소된 앱들을 이례적으로 많은 것을 보여주는 제품 결정으로 만든다. Google은 휴대폰이 적합하지 않아서 모바일 제작을 포기한 것이 아니다. 제작 기능을 Gemini 안에 넣는 편이 별도의 목적지를 제공하는 것보다 더 가치 있다고 판단했다.

앞으로 몇 달이 이 판단이 맞았는지를 보여줄 것이다. Gemini의 구체적인 미리보기가 나온다면 그 판단에 힘이 실릴 것이다. 반면 모호한 데모, 제한적인 내보내기 기능, 또는 플랫폼 지원에 대한 지속적인 침묵은 이를 약화시킬 것이다.

9to5Google의 Google 보도는 발표된 한 제품의 종료를 뜻하지만, Google의 모바일 개발 야심이 끝났다는 의미는 아니다. 이는 Gemini가 핵심 선택지를 숨기지 않은 채 대화, 코드, 배포를 연결해야 한다는 더 큰 책임을 지게 했음을 의미한다.

이제 사용자는 무엇을 해야 할까? 현재 존재하는 도구로 계속 개발하되, Gemini의 미래 앱 제작 기능은 다듬어진 미리보기가 아니라 내보낸 코드로 평가해야 한다. 대화가 끝난 뒤에도 프로젝트가 편집 가능하고, 테스트 가능하며, 이식 가능한지 물어야 한다. 개발자는 생성된 소프트웨어를 실제 데이터에 연결하기 전에 명확한 권한 경계를 요구해야 한다. Google이 이러한 요소를 제공한다면 독립형 앱 취소는 집중된 통합으로 보일 것이다. 그렇지 않다면 이 결정은 더 큰 약속으로 포장한 성급한 후퇴로 보일 것이다.