Google Connected Apps Platform, Gemini와 Search를 더 많은 서비스에 개방

Google은 10월 28일 Connected Apps Platform 프리뷰를 공개하며, 앱 배포는 자체 검토 절차 안에 유지한 채 개발자 접근성을 확대했다. Google Connected Apps Platform은 기업이 Gemini와 Search에 연결할 수 있는 공통 경로를 제공한다. 핵심적인 상충 관계는 분명하다. 서비스는 고객에게 도달할 또 하나의 접점을 얻는 반면, Google은 고객이 해당 서비스를 발견하고 이용하는 방식에 더 깊이 관여하게 된다.

이번 발표는 Google이 개별 파트너십을 통해 이미 구축해 온 방식을 공식화한다. 사용자는 대화 중 도움을 요청하고 연결된 서비스를 작업에 활용할 수 있다. 해당 서비스를 제공하는 기업은 여전히 중요하지만, 이제 그 앱이 반드시 출발점일 필요는 없다.

이는 익숙한 배포 모델에 압박을 가한다. 기업들은 전통적으로 고객이 웹사이트를 찾고, 앱을 설치하며, 직접 다시 방문하도록 유도해 왔다. Google의 접근 방식은 또 다른 경로를 추가한다. 고객이 목표를 설명하면 어시스턴트가 참여 서비스로 작업을 수행하도록 돕는 방식이다. 이번 프리뷰는 그 경로를 위한 인프라를 마련한다. 개발자가 얼마나 많은 수요를 얻게 될지, 어떤 서비스가 가장 자주 노출될지, 고객이 이를 선호할지는 아직 확립하지 않는다.

Google Connected Apps Platform, 파트너십을 개발자 채널로 전환

이번 발표는 연결 앱을 처음 도입하는 것이 아니라, 서비스를 Google의 AI 제품에 연결하는 절차를 확대한다.

Google은 Connected Apps 프리뷰를 통해 개발자가 통합을 준비하고 검토를 위해 제출한 뒤 Gemini, Search 또는 둘 다를 선택할 수 있다고 밝혔다. 또한 게시 이후 트래픽, 응답 시간, 오류를 모니터링할 수 있다고 설명했다.

Google은 Search와 Gemini 전반에 걸쳐 50개 이상의 Connected Apps가 있다고 밝힌다. Adobe, Experian, Localiza, Peloton 통합은 이미 Gemini에서 제공되고 있으며, 향후 몇 주 안에 Search로 확장될 예정이다. Calm 역시 두 제품 모두의 발표된 파트너다.

소비자 경험과 개발자 인프라가 함께 발전하고 있다는 점에서 시점은 중요하다. 서비스가 추가되면 어시스턴트는 더 많은 요청에 유용해진다. 반복 가능한 제출 절차는 Google이 개별적으로 협의한 출시를 넘어 확장할 수 있는 방법을 제공한다.

기업 입장에서는 이 차이가 실질적이다. 파트너십 발표는 대개 다른 기업이 무엇을 협상했는지 개발자에게 알려 준다. 플랫폼 발표는 추가 개발자가 직접 평가할 수 있는 경로를 설명한다.

다만 프리뷰 접근 권한을 제한 없는 게시와 혼동해서는 안 된다. Google은 더 많은 개발자, 시장, 제품으로 접근성을 단계적으로 확대할 것이라고 밝혔다. 이는 최종적인 도달 범위와 운영 조건이 아직 정해지지 않았음을 뜻한다.

배포 목적지를 선택하는 것과 그곳에서 주목을 받는 것 사이에도 차이가 있다. Search 또는 Gemini를 선택하는 것은 개발자가 자신의 서비스를 어디에서 제공하고 싶은지 Google에 알리는 일이다. 사용자가 해당 서비스를 요청하거나 어시스턴트가 이를 추천할 것이라는 보장은 아니다.

참여 여부를 결정하는 기업을 생각해 보자. 당장의 질문은 그 서비스가 사람들이 이미 대화형으로 설명하는 작업을 지원하는지다. 약속을 찾거나 계정 세부 정보를 조회하는 일은 복잡한 애플리케이션의 모든 화면을 재현하는 것보다 이 방식에 더 자연스럽게 맞는다.

이는 엔지니어링 결정에 앞서 제품 결정을 요구한다. 개발자는 자체 인터페이스 밖에서 어떤 서비스 부분이 의미가 있는지 판단해야 한다. 모든 것을 노출하면 고객 경험을 반드시 개선하지 않으면서 복잡성만 높일 수 있다.

따라서 이번 발표는 이용 가능한 배포 선택지를 바꾸지만, 사업성 판단은 개별 서비스에 남겨 둔다. 개발자는 더 체계적인 진입점을 얻었다. 그러나 그에 따른 상호작용이 유용한 수요를 만들어 낸다는 근거는 여전히 필요하다.

더 큰 의미는 선별된 통합에서 관리되는 채널로 옮겨 가는 변화에 있다. Google은 어시스턴트, 개발자, 고객 사이에 반복 가능한 관계를 만들고 있다. 그 관계가 어떻게 작동하는지는 얼마나 많은 앱이 참여하는지만큼 중요할 것이다.

Search는 행동을 시작하는 공간이 되고 있다

연결 서비스는 Search를 정보 탐색을 넘어선 영역으로 확장하지만, 일부 중요한 거래는 기본 제공업체에 남긴다.

Google의 7월 Search 연결 앱 발표는 구체적인 사례를 제공한다. 바비큐를 계획하는 사람은 Google의 대화형 검색 경험인 AI Mode에 식료품 관련 도움을 요청할 수 있다. Instacart가 연결된 경우 재료를 장바구니에 담을 수 있다. 이후 결제는 Instacart의 앱이나 웹사이트에서 이뤄진다.

이러한 인계는 중요한 경계다. Search는 전체 거래를 직접 소유하지 않고도 의도를 정리하고 행동을 준비하도록 도울 수 있다. 모든 연결 경험을 앱 대체재로 설명하면 이 차이를 놓치게 된다.

Google은 Canva를 사용해 디자인 템플릿을 찾고 YouTube Music에 재생목록을 저장하는 방식도 소개했다. 이 사례들은 서로 다른 참여 수준을 보여 준다. 서비스는 선택지를 제공하거나, 준비된 객체를 받거나, 특정 행동을 완료할 수 있다.

소비자에게 매력적인 점은 무엇을 할지 결정하는 순간과 실제로 시작하는 순간 사이의 방해가 줄어든다는 것이다. 원하는 결과를 이미 아는 사람은 애플리케이션의 전체 메뉴 구조를 탐색하고 싶지 않을 수 있다.

기업에는 같은 편리함이 배포상의 질문을 던진다. 고객이 브랜드가 아니라 요청으로 시작한다면, 해당 서비스는 어시스턴트의 응답 중에 관련성을 확보해야 한다.

이는 성공적인 발견 순간의 모습을 바꾼다. 웹사이트 방문은 고객에게 탐색 요소, 추천, 추가 제품을 노출할 수 있다. 좁게 요청된 행동은 그 경험의 상당 부분을 우회할 수 있다.

이 상충 관계가 자동으로 불리한 것은 아니다. 명확한 목표를 지닌 고객은 행동 없이 떠나는 방문자보다 더 유용할 수 있다. 중요한 비교 대상은 그 결과로 생기는 관계의 가치다.

개발자는 추가 활동과 자체 자산에서 이동한 활동을 구분해야 한다. 어시스턴트를 통해 완료된 작업은 신규 고객, 기존 고객이 선호하는 지름길, 또는 대체된 방문을 의미할 수 있다.

이 결과들은 서로 다른 의미를 가진다. 추가 수요는 추가 투자를 뒷받침한다. 편리한 지름길은 유지율을 개선할 수 있다. 대체된 방문은 서비스를 설명하거나 혼란을 해결할 기회를 줄인다면 더 면밀히 살펴봐야 할 수 있다.

Google Search 연결 앱은 사람들이 의도를 표현하는 순간에 Search가 이미 자리하고 있기 때문에 이러한 질문을 더 시급하게 만든다. 확장은 요청에 답하는 것에서 그 요청을 이행하도록 돕는 방향으로 이뤄진다.

지식 노동자에게 이는 행동 수행과 그 맥락 보존 사이의 분리도 만든다. 어시스턴트를 통해 작업을 완료한다고 해서 그 뒤의 추론을 정리된 기록으로 자동 생성하는 것은 아니다.

개인 지식 베이스는 즉각적인 상호작용이 끝난 뒤에도 유용한 정보를 이용 가능하게 유지한다는 관련 요구를 충족한다. 인터페이스가 이들을 더 가깝게 연결하더라도 발견, 실행, 회상은 여전히 구분되는 역할이다.

공통 연결 방식도 서로 다른 제품 경험을 남긴다

Google은 서비스 연결 방식을 표준화하면서도 클라우드 서비스와 Android 애플리케이션에 서로 다른 역할을 유지한다.

플랫폼의 통합 개요는 AI 애플리케이션을 외부 도구 및 데이터와 연결하는 개방형 표준인 Model Context Protocol, 즉 MCP를 설명한다. 원격 MCP 서버는 서비스의 승인된 기능을 이용 가능하게 한다.

Google은 Android 앱이 어시스턴트에 기능을 노출할 수 있게 하는 인터페이스인 AppFunctions를 통해 Android MCP도 지원한다. 이 경로는 기기에서 실행할 때 이점이 있는 기능을 위한 것이다.

이 경로들은 서로 다른 상황을 다룬다. 클라우드 서비스는 여러 기기에서 계정 기반 작업을 제공할 수 있다. 네이티브 애플리케이션은 휴대전화의 현재 상태와 연결된 정보나 기능이 필요할 수 있다.

이 차이는 Google의 한 번 구축하면 된다는 메시지를 단순하게 해석하는 데 한계를 둔다. 공통 플랫폼이 모든 기능이 어디서나 동일하게 작동한다는 뜻은 아니다. 개발자는 여전히 기능이 어디에서 실행되는지, 어떤 맥락이 필요한지 이해해야 한다.

가상의 여행 서비스를 상상해 보자. 계정의 예약을 검색하는 일은 클라우드 연결에 적합할 수 있다. 특정 모바일 경험 안에서만 이용 가능한 정보에 따라 행동하는 일은 다른 접근 방식이 필요할 수 있다.

이는 발표된 여행 통합이 아니라 아키텍처 선택을 설명하기 위한 예시다. 사업적 결과는 배포 전략과 구현이 여전히 연결되어 있다는 점이다.

광범위한 제공을 원하는 서비스는 깊이 통합된 휴대전화 경험에 집중하는 서비스와 다른 요구사항을 평가하게 된다. 둘 다 Google의 방향성에 참여할 수 있지만, 서로 대체 가능한 구현이 되는 것은 아니다.

Google 제품 전반의 Gemini 앱 통합에도 같은 주의가 적용된다. 지속적인 대화를 중심으로 설계된 기능은 사용자가 구체적인 쿼리로 시작하는 Search에서 다른 방식의 제시가 필요할 수 있다.

고객이 이러한 엔지니어링 차이를 이해할 필요는 없다. 그러나 개발자는 이해해야 한다. 테스트 환경에서 작동하는 행동도 잘못된 제품 맥락에서는 여전히 어색하게 느껴질 수 있기 때문이다.

유용한 비교 대상은 독립형 애플리케이션과 어시스턴트가 매개하는 작업이다. 애플리케이션은 화면의 순서를 제어하고 결정 전에 설명을 제시할 수 있다. 어시스턴트는 언어로 시작하며 요청을 이용 가능한 작업으로 매핑해야 한다.

이는 탐색을 줄일 수 있지만, 개발자가 고객을 안내하는 데 사용하는 구조 일부도 없앤다. 잘 설계된 통합은 대화 안에 전체 애플리케이션을 재현하지 않으면서 필요한 맥락을 복원해야 한다.

따라서 Google Connected Apps Platform은 개발자에게 보편적인 고객 경험이 아닌 공통 진입점을 제공한다. 제품 설계는 여전히 상당한 작업의 일부다.

기업은 통합을 복제된 매장으로 취급해서도 안 된다. 가장 강력한 활용 방식은 자주 요청되는 소수의 행동일 수 있다. 그 가치는 고객이 이를 명확하게 완료하고 문제가 발생했을 때 회복할 수 있는지에 달려 있다.

더 넓은 도달 범위는 발견에 대한 통제 공유를 뜻한다

핵심 긴장은 Google의 대화에 접근하는 것과 고객 여정에 대한 통제를 유지하는 것 사이에 있다.

Google의 MCP 서버 가이드는 개발자가 노출할 기능을 결정한다고 설명한다. 또한 앱 이름이나 멘션을 통한 명시적 앱 호출과 함께, 모델이 언제 작업을 위임해야 하는지 인식하도록 돕는 지침도 설명한다.

이들은 서로 다른 발견 상황이다. 서비스를 이름으로 지목하는 고객은 이미 브랜드 선택을 했다. 요구를 설명하는 고객은 매칭 결정의 더 많은 부분을 어시스턴트에 맡긴다.

인지도 있는 브랜드의 경우 직접 호출은 기존 관계를 확장할 수 있다. 고객은 제공업체를 알고 있으며, 해당 서비스로 가는 더 짧은 경로를 원한다.

익숙하지 않은 기업에게 참여는 또 다른 질문을 제기합니다. 자격을 갖춘 역량이 어떻게 선택되는 역량이 되는가? 기술적 호환성만으로는 그 상업적 질문에 답할 수 없습니다.

현재 공개된 발표는 노출을 보장하는 공식이 있음을 입증하지 않습니다. 개발자는 승인이 예측 가능한 수요를 만들거나 완전한 설명이 우대받는 대우를 보장한다고 가정해서는 안 됩니다.

이 지점에서 기존 앱 배포와의 비교가 유용해집니다. 독립형 앱은 인터페이스, 고객 지원, 직접적인 관계를 통해 경쟁할 수 있습니다. 하지만 어시스턴트 안에서는 첫 접점이 더 좁은 기능을 중심으로 형성될 수 있습니다.

그렇다고 브랜드 가치가 사라지는 것은 아닙니다. 브랜드 가치가 드러나야 하는 위치가 달라지는 것입니다. 서비스 자체 인터페이스의 존재감이 약할 때는 명확한 출처 표시, 신뢰할 수 있는 결과, 알아볼 수 있는 계정 관계가 특히 중요해집니다.

Google은 개발자가 검증된 로고와 인증된 계정을 포함한 브랜드 요소를 유지한다고 말합니다. 이러한 조항은 인지도 문제를 다룹니다. 하지만 반복 사용이나 고객 충성도에 관한 모든 질문을 해결하지는 않습니다.

비즈니스 관점에서 성공적인 작업과 지속적인 관계는 서로 다른 결과입니다. 고객은 어떤 작업을 만족스럽게 여길 수 있지만, 이를 제공한 회사가 어디인지 기억하지 못할 수 있습니다.

이 가능성은 제품 팀이 단순 호출 수치 이상을 측정하도록 압박합니다. 고객이 다시 돌아오는지, 제공업체를 인식하는지, 최초 요청이 실패했을 때 유용한 서비스를 받는지를 파악해야 합니다.

소규모 개발자는 특히 섬세한 결정을 내려야 합니다. 새로운 채널은 독자적으로는 만들기 어려웠을 기회를 창출할 수 있습니다. 동시에 해당 채널을 지원하려면 엔지니어링 및 운영 역량이 소모됩니다.

올바른 대응은 서비스의 경제성과 고객 행동에 따라 달라집니다. 출시 자료에는 모든 카테고리가 동일한 혜택을 받는다는 근거가 없습니다.

Google의 유인은 더 명확합니다. 더 폭넓은 선택지는 Google의 AI 제품이 더 많은 작업에 유용해지게 합니다. 이 채널이 가치 있는 수요를 만들 때 개발자의 유인은 그 목표와 겹칩니다.

플랫폼의 참여가 제공업체 비즈니스의 상응하는 개선 없이 증가할 때는 양측의 유인이 엇갈립니다. 이는 발표로 입증된 결과가 아니라 측정해야 할 가능성입니다.

따라서 핵심 이야기는 편의성만큼이나 협상력에 관한 것입니다. 접근하기 쉬운 통합은 참여 범위를 넓히는 동시에 중요한 고객 접점을 Google 내부에 집중시킬 수 있습니다.

신뢰성과 권한이 사용자의 재방문 여부를 좌우할 것이다

통합은 고객이 작업을 신뢰하고 그 결과를 이해할 수 있을 때 유용해집니다.

Google의 게시 요건은 도메인 검증, 테스트, 가용성, 개별 도구를 위한 제어 수단을 설명합니다. 개발자는 사용자 확인을 구성할 수 있으며, 파괴적 도구 주석은 자동으로 확인 요구 사항을 선택합니다.

문서는 또한 클라우드 MCP 연결과 Android MCP를 구분합니다. 대화형 MCP Apps 리소스는 베타 단계이며 사용 가능하지 않거나 렌더링되지 않을 수 있다고 경고합니다.

이러한 세부 사항은 게시와 제품 준비 상태가 별개의 문제인 이유를 보여 줍니다. 통합은 유효한 작업을 노출하면서도 여전히 혼란스러운 고객 경험을 만들 수 있습니다.

가상의 일정 예약 서비스를 생각해 봅시다. 이용 가능한 예약 시간을 찾는 것과 이를 확정하는 것은 다릅니다. 기존 예약을 변경하면 또 다른 결과가 따릅니다.

고객은 어시스턴트가 어떤 작업을 수행했는지, 어떤 작업이 아직 대기 중인지, 어떤 계정이 영향을 받는지 알아야 합니다. 그 경계의 모호함은 기반 서비스가 올바르게 응답하더라도 신뢰를 약화시킬 수 있습니다.

이는 Google의 출시가 그러한 실패를 보여 주었다는 주장이 아니라 제품 위험에 관한 이야기입니다. 공개 자료는 제어 수단을 설명하지만, 참여하는 모든 서비스 전반의 신뢰성을 입증하지는 않습니다.

같은 구분은 계정의 신원을 확인하는 과정인 인증에도 적용됩니다. 연결에 성공했다고 해서 이후의 모든 요청이 올바른 권한이나 최신 계정 상태를 갖는다는 뜻은 아닙니다.

개발자는 만료된 접근 권한, 이용할 수 없는 서비스, 지원되는 역량과 일치하지 않는 요청을 고려해야 합니다. 어시스턴트 역시 이러한 제약을 유용한 방식으로 전달해야 합니다.

일반적인 실패 메시지는 고객이 재시도해야 할지 알 수 없게 만듭니다. 명확한 결과는 고객이 대화 안에서 계속할지, 제공업체의 애플리케이션을 열지 결정할 수 있게 합니다.

정보에도 또 다른 경계가 있습니다. 어시스턴트는 작업을 완료할 만큼의 맥락이 필요할 수 있지만, 기업은 무엇이 필요한지 정확히 판단해야 합니다.

엔터프라이즈 구매자에게 이는 통합이 일반적으로 안전한지 묻는 것보다 더 구체적인 검토를 의미합니다. 관련 질문은 사용 가능한 작업, 허용된 정보, 확인 동작, 조직의 기존 승인 절차에 관한 것입니다.

이러한 고려 사항 가운데 어느 것도 이 모델을 거부할 필요는 없습니다. 다만 어디에 적합한지를 결정합니다. 단순 조회 작업과 중요한 계정 변경은 서로 다르게 다뤄져야 합니다.

Gemini 앱 통합은 직접 애플리케이션 사용이 제공하는 익숙한 신뢰성과도 경쟁하게 됩니다. 고객은 이미 특정 제어 기능을 어디에서 찾아야 하는지 알고 있습니다. 대화형 경로는 명확성과 편의성으로 전환의 이유를 제시해야 합니다.

프리뷰는 더 광범위한 배포 전에 그 균형을 살펴볼 기회를 제공합니다. 이를 자연어 상호작용이 기존 인터페이스보다 뛰어나다는 독립적인 증거로 해석해서는 안 됩니다.

따라서 회의적인 관점은 구체적입니다. Google은 역량을 연결하고 검토하기 위한 경로를 문서화했지만, 소비자 가치는 반복 사용에서 나온 증거를 필요로 합니다. 기술적 접근은 필수이지만, 도입 과정의 일부에 불과합니다.

Search 확장, 개발자 접근성, 반복 사용을 지켜봐야 한다

다음으로 유용한 증거는 또 다른 파트너 목록의 규모가 아니라 가용성과 고객 행동에 관한 것입니다.

첫 번째 신호는 발표된 Search 확장이 설명된 대로 사용자에게 도달하는지 여부입니다. 향후 몇 주에 걸쳐 추가 연결 서비스를 Search에 제공하겠다는 Google의 약속은 구체적인 단기 점검 시점을 만듭니다.

가용성은 실제 역량 수준에서 살펴봐야 합니다. 서비스가 메뉴에 표시된다고 해서 고객이 기대한 작업을 수행할 수 있다는 뜻은 아닙니다.

폭넓고 명확하게 작동하는 가용성은 Google이 제품 전반에 걸친 공동 배포 채널을 만들고 있다는 주장을 강화할 것입니다. 제한적이거나 일관되지 않은 역량은 더 좁은 해석을 뒷받침할 것입니다.

두 번째 신호는 개발자 접근성이 초기 프리뷰를 넘어 확장되는지 여부입니다. Google은 개발자와 시장을 추가할 의향이 있다고 밝혔지만, 발표는 모든 기업에 게시 일정을 제공하지는 않습니다.

독립적으로 제출된 서비스의 범위가 확대되면 플랫폼이 밝힌 방향을 뒷받침할 것입니다. 선택된 소수의 출시 사례에 계속 의존한다면 기존 파트너십 모델이 더 많이 유지될 것입니다.

여기서 카테고리 다양성이 중요합니다. Google의 이전 Gemini 앱 확장에는 생산성, 창작, 라이프스타일 서비스가 포함되었습니다. 이는 이번 개발자 플랫폼 발표 이전에 의도된 활용 범위를 보여 주었습니다.

다음 질문은 그러한 폭이 제출 절차를 통해 추가 기업으로 확장되는지 여부입니다. 반복 가능한 채널은 결국 문서뿐 아니라 누가 참여하는지에서도 드러나야 합니다.

세 번째 신호는 기반 제공업체에 유용한 결과를 만들어 내는 반복 사용입니다. 출시 당시의 관심은 호기심을 보여 줄 수 있습니다. 다시 돌아오는 고객은 상호작용이 반복되는 문제를 해결한다는 더 나은 증거를 제공합니다.

공개 앱 수치만으로는 그 질문에 답할 수 없습니다. 개발자는 완료율, 고객 유지율, Google을 통해 유입되는 활동의 품질을 자체적으로 측정해야 합니다.

이러한 지표는 브랜드가 명시된 요청과 일반적인 탐색도 구분해야 합니다. 고객이 알고 있는 서비스를 호출하는 것은 편의성을 보여 줍니다. 고객이 적합하지만 낯선 서비스를 찾는 것은 다른 무언가를 보여 줍니다.

두 결과 모두 가치 있을 수 있지만, 플랫폼에 관한 서로 다른 주장을 뒷받침합니다. 전자는 기존 관계를 강화합니다. 후자는 추가적인 고객 확보 채널을 시사합니다.

Google Connected Apps Platform은 이 질문들을 미리 결론 내리지 않고도 검증 가능하게 만듭니다. 검증된 변화는 서비스가 Google의 AI 경험에 참여할 수 있는 더 체계적인 경로입니다.

프리뷰를 평가하는 개발자라면 고객이 이미 반복하는 작업에서 시작하고, 성공적인 상호작용이 무엇을 달성해야 하는지 정의해야 합니다. 대화형 경로를 애플리케이션 내부의 경험과 비교하세요. 사람들이 작업을 완료하는지, 다시 돌아오는지, 어떤 서비스가 도움을 주었는지 이해하는지 살펴보세요. 비즈니스 구매자는 같은 작업을 둘러싼 권한 및 확인 경계를 검토해야 합니다. 일반 사용자는 익숙한 서비스의 사용 가능한 통합을 시험해 보고 인계가 어디에서 이루어지는지 확인해 보세요. 앞으로 몇 달 동안 Google의 확장은 신뢰할 수 있게 되는 작업과 지속을 돕는 관계를 기준으로 판단하세요. 어시스턴트에서 시작하는 것이 서비스와 그 책임을 명확히 유지하면서 작업을 더 쉽게 만드나요?