Google Cloud, 대화형 분석 확장… 그러나 진짜 시험대는 엔터프라이즈 신뢰

Google Cloud는 핵심 비즈니스 데이터를 생성형 AI에 맡기는 데 대한 의구심이 지속되는 가운데, 두 가지 대화형 분석 제품을 정식 출시했다. BigQuery Conversational Analytics와 Conversational Analytics API는 이제 BigQuery와 Looker용 프로덕션 준비 상태를 갖췄다. 데이터베이스 지원은 여전히 프리뷰 단계다.

7월 28일 발표는 단순한 또 하나의 챗봇 출시보다 큰 의미를 지닌다. Google은 데이터 웨어하우스, 운영 데이터베이스, 비즈니스 인텔리전스 도구, 맞춤형 애플리케이션, 업무용 어시스턴트를 아우르는 거버넌스 기반 분석 계층을 구축하고 있다. 액세스 제어와 합의된 비즈니스 정의를 잃지 않으면서, 자연어 분석이 이 환경 전반에서 직원들을 따라다니게 하려는 것이다.

이 전략은 Snowflake, Microsoft, Databricks 및 전문 분석 벤더에 압박을 가한다. 그러나 더 근본적인 경쟁은 Google과 특정 경쟁사 간의 대결이 아니다. 비즈니스가 수치를 정의하는 방식을 이해하지 못한 채 그럴듯한 답변을 생성하는 범용 언어 모델 래퍼와, 거버넌스가 적용된 데이터 에이전트 간의 경쟁이다.

Google Cloud, 대화형 분석을 프로덕션 환경으로 전환

당장의 변화는 대화형 분석이 여러 실험의 집합에서 지원되는 Google Cloud 제품 아키텍처로 넘어왔다는 점이다.

회사는 BigQuery Conversational Analytics와 Conversational Analytics API를 정식 출시했다. 이 API는 개발자가 Google의 기본 인터페이스를 넘어 애플리케이션에 동일한 기능을 구현할 수 있는 프로그래밍 방식의 경로를 제공한다.

Looker의 Conversational Analytics는 이미 정식 출시된 상태였다. 이제 Google은 AlloyDB, Cloud SQL, Spanner에 대한 프리뷰 지원을 추가하며, 자연어 분석을 분석용 웨어하우스에서 운영 데이터베이스로 확장하고 있다.

이 구분은 중요하다. 웨어하우스에는 일반적으로 보고를 위해 준비된 정제 데이터가 담긴다. 반면 운영 데이터베이스에는 애플리케이션, 거래, 재고 시스템, 고객 경험을 뒷받침하는 실시간 레코드가 있다. 이러한 시스템과 관련된 질문에는 더 엄격한 통제와 신중한 해석이 필요하다.

공식 제품 발표는 접근 가능한 데이터 자산의 범위도 넓힌다. 에이전트는 Lakehouse Managed Service 테이블, Apache Iceberg REST 카탈로그, 연합된 AWS S3 Unity Catalogs를 분석할 수 있다.

따라서 Google은 제품을 자사 클라우드 내부에 완전히 저장된 데이터로만 제한하지 않는다. 서로 다른 스토리지와 클라우드 구성을 아우를 수 있는 인터페이스로 대화형 분석을 제시하고 있다.

직원들은 BigQuery Studio, BigQuery Data Canvas, Database Studio, Looker, Data Studio, Gemini Enterprise에서 이러한 에이전트를 접할 수 있다. 데이터 팀은 여러 Google 데이터 제품의 에이전트를 Gemini Enterprise에 게시해 조직 전체가 더 폭넓게 접근하도록 할 수 있다.

개발자에게는 또 다른 배포 경로가 제공된다. 정식 출시된 API는 Node.js, Java, Go, Python, PHP, Ruby, .NET용 SDK를 제공한다. Google은 Agent Development Kit 및 Model Context Protocol, 즉 MCP를 통해 구축한 통합도 지원한다.

MCP는 AI 시스템을 외부 도구와 컨텍스트에 연결하기 위한 표준이다. 여기서는 다른 에이전트가 데이터베이스 로직을 독립적으로 생성하는 대신, 거버넌스가 적용된 분석 에이전트를 호출할 수 있게 한다.

예를 들어 공급망 어시스턴트는 재무 데이터 에이전트에 지연된 배송이 마진에 미치는 영향을 계산해 달라고 요청할 수 있다. 이 계산은 거버넌스가 적용된 재무 정의와 요청한 직원의 권한에 계속 연결된다.

Google은 Slack 봇과 맞춤형 애플리케이션도 가능한 대상이라고 설명한다. 이는 분석 제품을 방문하는 방식에서, 의사결정이 이뤄지는 어느 곳에서나 분석을 호출하는 방식으로 배포 모델을 바꾼다.

API 릴리스 노트에 따르면 정식 출시는 2026년 6월 23일이다. 또한 버전 1 REST 엔드포인트, 데이터 레지던시 기능, 엔터프라이즈 보안 제어도 문서화한다.

이후 블로그 발표는 이러한 기술적 이정표를 더 폭넓은 제품 스토리로 묶는다. Google Cloud는 데이터 시스템, 사용자 인터페이스, 에이전트 워크플로우 전반에 하나의 대화형 계층을 두려 한다.

이러한 폭넓은 범위는 핵심적인 긴장을 낳는다. 배포 확장은 도입을 늘릴 수 있지만, 추가되는 모든 접점은 잘못된 답변이 의사결정에 영향을 미칠 수 있는 또 다른 장소가 된다.

Google Cloud는 범용 챗봇보다 거버넌스가 우위에 설 것이라 본다

Google Cloud는 비즈니스 의미를 배포 후 덧붙이는 추가 프롬프트 텍스트가 아니라 인프라로 다루고 있다.

범용 챗봇은 질문을 SQL로 변환할 수 있다. 그렇다고 조직이 인식 매출, 활성 고객, 적격 거래를 어떻게 정의하는지 안다는 뜻은 아니다.

이러한 정의는 종종 승인된 필터, 조인, 제외 조건, 회계 규칙, 보고 기간에 의존한다. 문법적으로 유효한 두 쿼리는 서로 다른 답을 낼 수 있으며, 비기술 직원에게는 둘 다 똑같이 확신에 찬 결과처럼 보일 수 있다.

Google의 해법은 언어 모델을 메타데이터, 시맨틱 모델, 검증된 쿼리, 기존 데이터 권한과 결합하는 것이다. 시맨틱 모델은 애플리케이션이 재사용할 수 있도록 비즈니스 개념에 일관된 정의를 부여한다.

Looker에서는 중앙 관리형 차원, 측정값, 조인, 액세스 규칙을 위한 모델링 언어인 LookML이 이러한 근거를 제공한다. 에이전트는 테이블과 열 이름을 바탕으로 비즈니스 로직을 지어내는 대신 이 정의를 가져올 수 있다.

Google은 Golden Queries라고 부르는 요소도 활용한다. 이는 반복적인 질문에 대해 승인된 비즈니스 로직을 담은 검증 사례다. 에이전트가 새 쿼리를 구성할 때 신뢰할 수 있는 패턴을 제공한다.

Knowledge Catalog는 설명, 용어집, 관계 컨텍스트를 제공한다. BigQuery Graph와 Spanner Graph는 여러 엔터티에 걸친 연결을 표현해, 에이전트가 여러 단계의 관계를 추론하도록 도울 수 있다.

이 설계는 중요하다. 데이터베이스 스키마는 스스로를 설명하는 경우가 드물기 때문이다. status라는 열은 결제 상태, 배송 상태, 계정 상태 또는 내부 처리 상태를 뜻할 수 있다.

모델은 올바르게 선택하기 전에 비즈니스 컨텍스트가 필요하다. 카탈로그와 시맨틱 계층을 통해 컨텍스트를 추가하는 편이, 직원이 모든 질문에서 각 정의를 설명하도록 기대하는 것보다 더 신뢰할 수 있다.

거버넌스 계층은 결과를 볼 수 있는 사람도 제한한다. Google은 에이전트가 행 수준 및 열 수준 권한을 포함한 기존 역할 기반 액세스를 적용한다고 말한다.

지역 관리자는 글로벌 임원과 같은 질문을 하더라도 더 제한된 결과를 받을 수 있다. 에이전트는 별도의 액세스 시스템을 만드는 대신, 기반 플랫폼에서 권한을 상속해야 한다.

Google은 Customer-Managed Encryption Keys, 프라이빗 네트워킹 제어, 데이터 레지던시 옵션을 추가했다. 머신러닝 처리가 미국 또는 유럽연합 내 지원되는 멀티 리전 엔드포인트 안에 유지될 수 있다고 설명한다.

회사는 사용 가능한 제어 항목에 HIPAA 준수도 포함한다고 밝힌다. 이러한 기능은 조달 요건을 충족하는 데 도움이 되지만, 그 자체로 답변의 정확성을 보장하지는 않는다.

정확성은 에이전트가 직원에게 배포된 후에도 지속적인 평가를 필요로 한다. Google은 관리자가 시스템 관측성 업계 표준인 OpenTelemetry를 통해 지연 시간, 토큰 소비량, 상태, 도구 사용 지표를 내보낼 수 있도록 한다.

팀은 트레이스와 사용자 피드백도 검토할 수 있다. BigQuery 쿼리 라벨과 Looker 활동 로그는 사용량을 이해하고 예상치 못하게 비용이 많이 들거나 의문스러운 요청을 조사하는 또 다른 방법을 제공한다.

기본 제한 기능은 쿼리가 처리할 수 있는 최대 바이트 수를 제한할 수 있다. 가벼운 자연어 질문이 대규모 데이터세트 전체를 광범위하게 스캔하는 일을 방지하는 데 이 제어가 중요하다.

이러한 요소는 대화형 분석을 데모가 아닌 운영되는 서비스로 바꾼다. 동시에 데이터 팀에 상당한 책임을 부여한다.

부실한 카탈로그, 일관성 없는 지표 정의, 불완전한 액세스 정책은 결국 부실한 결과를 낳는다. 에이전트는 그 아래에 이미 존재하는 모든 거버넌스 문제를 해결할 수 없다.

광범위한 배포를 고려하는 조직은 시맨틱 준비를 공유 지식 계층을 유지하는 일처럼 다뤄야 한다. 가치는 관련 컨텍스트를 연결하면서 그 출처, 범위, 의미를 보존하는 데서 나온다.

진짜 경쟁은 거버넌스가 적용된 데이터 에이전트와 그럴듯한 답변의 대결이다

시장은 하나의 교훈으로 수렴하고 있다. 대화형 분석은 모델의 대화 유창성보다 준비된 시맨틱에 더 크게 좌우된다.

Google Cloud만 이 결론에 도달한 것은 아니다. Snowflake와 Microsoft도 시맨틱 컨텍스트, 검증 사례, 권한, 검사 가능한 쿼리를 중심으로 각자의 접근 방식을 구축했다.

Snowflake의 Cortex Analyst는 시맨틱 모델과 Verified Query Repository를 사용한다. 이 리포지터리는 자연어 질문을 사람이 확인한 SQL과 연결한다.

검증된 쿼리 시스템은 새 질문이 승인된 질문과 비슷할 때 관련 사례를 가져올 수 있다. Snowflake는 유효하지 않은 검증 쿼리가 답변 품질을 떨어뜨릴 수 있다고 경고한다.

이 경고는 중요한 현실을 드러낸다. AI 인터페이스가 도입되어도 사람의 검증은 사라지지 않는다. 팀이 지표를 정의하고 대표 쿼리를 승인하는 프로세스의 앞단으로 이동할 뿐이다.

Snowflake는 쿼리 이력을 분석하고, 누락된 필터·지표·검증 사례를 제안하는 피드백 루프도 개발했다. 모델 제안은 시맨틱 계층의 일부가 되기 전에 사람의 검토를 요구한다.

Microsoft Fabric도 유사한 패턴을 따른다. 데이터 에이전트는 웨어하우스, 레이크하우스, Power BI 시맨틱 모델, KQL 데이터베이스, 온톨로지, Microsoft Graph를 통해 노출되는 조직 데이터를 쿼리할 수 있다.

Microsoft는 데이터 액세스가 직원의 ID 및 기존 권한에 따라 실행된다고 설명한다. 해당 에이전트는 읽기 전용 쿼리를 생성하고 검사할 수 있도록 중간 단계를 노출한다.

회사의 데이터 에이전트 가이드는 중요한 한계도 명시한다. 에이전트는 고급 분석, 머신러닝, 인과 추론을 수행하지 않는다.

이 한계는 유용하다. 유창한 답변은 단순 집계를 더 깊은 분석처럼 보이게 할 수 있기 때문이다. 과거 데이터에서 상관관계를 식별한 시스템이 그 관계가 존재하는 이유까지 설명한 것은 아니다.

Google은 내장 분석 도구로 경계를 넓히고 있다. 에이전트는 예측, 이상 탐지, 임베딩, 분류, 스코어링, 기여도 분석 기능을 호출할 수 있다.

시계열 예측을 위한 Google의 파운데이션 모델인 TimesFM은 일부 예측 및 이상 탐지 작업을 지원한다. ai.key_drivers 함수는 예상치 못한 지표 변화와 연관된 요인을 식별하는 것을 목표로 한다.

Agentic Workflows는 시스템을 한 단계 더 확장한다. 프리뷰 단계에서 보고서를 예약하고, 지표를 모니터링하며, 사람이 첫 질문을 작성할 때까지 기다리지 않고 이상을 조사할 수 있다.

Google은 다차원 조사가 지표 변화의 배경에 있는 10~20개의 기여 요인을 검토할 수 있다고 말한다. 스트리밍 이상 탐지는 측정값이 정의된 임계값을 넘을 때 조사도 시작할 수 있다.

이는 단순한 채팅보다 더 중대한 변화다. 챗봇은 사용자의 입력을 기다리지만, 모니터링 에이전트는 무엇이 주목할 만한지 판단하고 그에 대한 설명을 구성한다.

이 모델은 데이터 에이전트에서 운영 에이전트로 이동하는 Microsoft의 전략과 경쟁한다. 또한 대시보드, 알림, 애널리스트가 만든 보고서를 중심으로 구축된 전통적인 비즈니스 인텔리전스 워크플로에도 도전한다.

하지만 모든 공급업체는 같은 병목에 직면한다. 생성된 쿼리는 유효할 수 있지만, 잘못된 비즈니스 질문에 답할 수 있다.

매출이 왜 감소했는지 묻는 영업 임원을 생각해 보자. 올바른 분석을 위해서는 환율 정규화, 취소 주문 제외, 지역별 달력 조정, 매출 인식 규칙이 필요할 수 있다.

언어 모델은 이러한 규칙을 적용하지 않은 채 인상적인 SQL을 작성할 수 있다. 거버넌스가 적용된 에이전트는 규칙을 시맨틱 레이어와 검증된 예시에 담을 수 있기 때문에 더 나은 가능성을 갖는다.

Google의 강점은 데이터 제품과 연결된 인터페이스의 폭이다. Snowflake의 강점은 대화를 자사 플랫폼 내에서 거버넌스가 적용된 데이터 가까이에 유지하는 데 있다.

Microsoft는 분석 기능을 Microsoft 365, Teams, Power BI, Copilot Studio와 연결할 수 있다. Databricks는 자체 데이터 인텔리전스와 레이크하우스 맥락을 같은 경쟁에 가져온다.

승자는 준비된 질문에 대한 벤치마크 정확도만으로 결정되지 않을 것이다. 기업은 수천 건의 실제 요청 전반에서 유지보수 노력, 추적 가능성, 접근 제어, 지연 시간, 장애 처리 방식을 검토할 것이다.

그래서 주된 경쟁 상대는 범용 래퍼 접근 방식이다. 이는 빠른 데모를 약속하는 반면, 거버넌스형 에이전트는 광범위한 배포 전에 시맨틱 모델링과 운영 규율을 요구한다.

래퍼는 출시하기가 더 쉽다. 거버넌스 시스템은 재무, 컴플라이언스, 보안, 경영진 의사결정의 현실과 맞닿은 뒤에도 살아남을 가능성이 더 높다고 주장할 근거가 있다.

더 많은 데이터 접근은 더 많은 오류 가능성도 만든다

Google Cloud는 누구도 분석 신뢰도를 측정하기 위한 보편적 표준을 확립하기 전에 에이전트의 범위를 더 빠르게 확장했다.

정식 출시는 제품 성숙도와 지원 약속을 의미한다. 그렇다고 모든 생성 답변이 모든 스키마, 질문, 조직의 정의에 대해 정확하다는 뜻은 아니다.

Google은 그라운딩 기능에 대해 신중한 표현을 사용한다. 시맨틱 모델과 Golden Queries는 추정에 기반한 조인을 줄이는 데 도움이 되지만, 모든 새로운 질문이 승인된 해석으로 매핑된다고 보장할 수는 없다.

검증된 예시는 월간 매출을 다룰 수 있지만 보고 기간 이후에 반영된 환불까지 포함하지는 않을 수 있다. 익숙하지 않은 변형은 시스템을 그럴듯해 보이지만 정책을 위반하는 로직으로 이끌 수 있다.

메타데이터 품질 역시 기업마다 다르다. 많은 조직에는 중복된 지표, 문서화되지 않은 테이블, 방치된 대시보드, 일관성 없는 명명 규칙이 있다.

대화형 접근은 이러한 불일치를 더 많은 사람에게 노출할 수 있다. 에이전트는 기존 거버넌스 문제를 해결하지 못한 채 더 뚜렷하게 드러낼 수 있다.

운영 데이터베이스는 또 다른 과제를 더한다. 이들의 스키마는 이해하기 쉬운 분석 개념보다 애플리케이션 성능과 트랜잭션 무결성을 우선시하는 경우가 많다.

BigQuery, Cloud SQL, Spanner, AlloyDB, 외부 카탈로그 전반의 데이터를 조인하면 최신성, 지역별 가용성, ID 매핑, 지표 정의의 차이가 발생할 수 있다.

소스 간 결과가 일치하지 않을 때 시스템에는 명확한 대응 방식도 필요하다. 하나의 답을 조용히 선택하면 잘못된 확신을 만들고, 모든 충돌을 나열하면 어시스턴트의 유용성이 떨어질 수 있다.

보안도 비슷한 복잡성을 물려받는다. 행 수준 권한은 쿼리 결과를 제한할 수 있지만, 에이전트의 설명은 요약이나 비교를 통해 민감한 패턴을 드러낼 수 있다.

조직은 추론 위험, 프롬프트 인젝션, 악의적인 메타데이터, 무단 도구 호출을 위한 테스트가 필요하다. 생성된 쿼리와 그 결과를 설명하는 데 사용된 언어를 모두 검토해야 한다.

분석 에이전트를 일반 업무용 어시스턴트에 게시하면 숙련된 애널리스트를 넘어 더 넓은 사용자가 접근하게 된다. 이는 사용성을 높이지만, 모든 사용자가 생성된 로직을 검토할 가능성은 낮춘다.

애널리스트는 SQL을 읽고 소스 테이블을 확인해 의심스러운 결과에 이의를 제기할 수 있다. 채팅에서 답을 받는 영업 관리자는 표현이 자신감 있어 보인다는 이유로 동일한 결과를 받아들일 수 있다.

선제적 워크플로는 위험도를 다시 높인다. 예약된 요약은 누구도 요청하기 전에 잘못된 해석을 퍼뜨릴 수 있다.

트리거된 조사는 관련 없는 기여 요인을 선택할 수도 있다. 기여도 분석은 통계적 연관성을 식별할 뿐, 반드시 인과적 동인을 식별하는 것은 아니다.

제품의 관측 가능성 제어 기능은 이러한 실패를 모니터링할 수 있는 경로를 제공한다. 관리자는 에이전트 추적, 피드백, 지연 시간, 토큰 사용량, 기반 도구 호출을 검사할 수 있다.

그러나 텔레메트리 수집은 첫 단계일 뿐이다. 기업에는 여전히 평가 세트, 에스컬레이션 경로, 비즈니스 정의 담당자, 잘못된 답변을 수정하는 프로세스가 필요하다.

도입과 신뢰를 구분하는 지표도 필요하다. 높은 질문 수는 열성적인 사용, 반복 재시도, 또는 직원들이 일관성 없는 답변을 확인하는 상황을 반영할 수 있다.

마찬가지로 긍정적인 피드백도 오해를 불러일으킬 수 있다. 사용자는 기저 계산을 검증할 수 없을 때에도 명확한 표현에는 좋은 평가를 주는 경우가 많다.

가장 유용한 평가는 반복 질문과 익숙하지 않은 질문 전반에서 에이전트의 답변을 애널리스트 검토 결과와 비교할 것이다. 테스트에는 모호한 언어, 제한된 레코드, 불완전한 데이터, 상충하는 정의가 포함되어야 한다.

팀은 불확실성이 중대할 때 에이전트가 명확화를 요청하는지 기록해야 한다. 추측을 거부하는 것이 즉시 차트를 생성하는 것보다 더 나은 결과일 수 있다.

비용 제어도 비슷한 수준의 검토가 필요하다. 최대 쿼리 크기 제한은 과도한 스캔을 막을 수 있지만, 사용자가 제한을 이해하지 못하면 부분적인 분석 결과를 낼 수도 있다.

토큰 측정은 비용의 일부만 포착한다. 시맨틱 모델 유지보수, 평가, 사고 검토, 인간 검증도 배포의 총 운영 부담을 좌우한다.

Google Cloud의 아키텍처는 범용 챗봇 래퍼보다 이러한 우려를 더 직접적으로 다룬다. 그럼에도 회사는 완전한 시스템이 분석적 환각을 제거한다는 독립적인 증거를 공개하지 않았다.

방어 가능한 결론은 더 제한적이다. 그라운딩, 권한, 검증된 로직, 관측 가능성은 신뢰할 수 있는 분석을 위한 더 나은 조건을 만든다.

이러한 조건이 신뢰할 수 있는 답변을 만들어 내는지는 각 조직의 데이터 품질, 시맨틱 규율, 평가 프로세스, 중대한 의사결정에 대해 인간의 책임을 유지하려는 의지에 달려 있다.

Google Cloud 출시 이후 주목할 점

다음 단계는 또 하나의 세련된 채팅 데모가 아니라 운영 환경의 증거, 데이터베이스 준비 상태, 경쟁사의 대응으로 결정될 것이다.

첫 번째 신호는 정식 출시된 BigQuery 및 Looker 제품의 측정 가능한 도입이다. Google은 실험에서 엔터프라이즈 배포로의 전환을 설명했지만, 구매자는 더 명확한 운영 증거를 필요로 한다.

유용한 지표에는 활성 사용자 수, 반복 사용량, 질문 성공률, 쿼리 볼륨, 애널리스트 수정이 필요한 답변의 비중이 포함된다. Google의 모니터링 도구는 이러한 그림의 일부를 포착할 수 있다.

고객 사례 연구는 배포 범위도 설명해야 한다. 소규모 데이터 전문가 그룹은 수만 명의 비즈니스 직원과는 다른 신뢰 과제를 제시한다.

낮은 수정률과 함께 광범위한 도입이 입증된다면 대화형 분석이 표준 데이터 인터페이스가 될 수 있다는 Google의 주장은 강화될 것이다. 수동 검토가 많이 필요하다면 폭넓은 자율성의 근거는 약화될 것이다.

두 번째 신호는 프리뷰 기능이 안정적인 운영 환경 상태에 도달하는지 여부다. AlloyDB, Cloud SQL, Spanner를 위한 Conversational Analytics는 데이터 웨어하우스 중심 분석을 넘어선 중대한 확장을 의미한다.

Agentic Workflows도 여전히 프리뷰 상태다. 이들의 진전은 Google이 질문에 답하는 수준에서 지표를 모니터링하고 조사를 시작하는 수준으로 얼마나 빨리 이동할 수 있는지를 보여줄 것이다.

이 기능들의 정식 출시는 Google이 운영 환경 약속을 할 만큼 충분한 신뢰성, 보안, 지원 문제를 해결했음을 시사할 것이다. 긴 프리뷰 기간은 해결되지 않은 복잡성을 암시할 수 있다.

라벨보다 세부 사항이 더 중요하다. 구매자는 각 데이터베이스의 지원 지역, 권한 동작, 감사 범위, 지연 시간, 기능 차이를 검토해야 한다.

선제적 워크플로에 더 강력한 승인 게이트가 추가되는지도 지켜봐야 한다. 자동화된 조사는 유용하지만, 영향력이 큰 조치에는 여전히 명확한 인간 통제가 필요하다.

세 번째 신호는 Snowflake, Microsoft, Databricks의 대응 방식이다. 각 공급업체는 이미 자연어에서 거버넌스가 적용된 엔터프라이즈 데이터로 이어지는 경로를 보유하고 있다.

더 폭넓은 소스 지원, 더 깊은 업무 환경 통합, 더 강력한 시맨틱 자동화, 공개된 평가 방법을 주목해야 한다. 검증된 쿼리 시스템은 이 분야 전반에서 더 중심적인 역할을 하게 될 가능성이 높다.

Fabric은 시맨틱 모델, 조직 ID, 협업 도구, 워크플로 자동화를 결합하기 때문에 Microsoft의 진전은 특히 주목할 가치가 있다. Snowflake는 자사 데이터 플랫폼 가까이에서 강력하게 거버넌스된 분석으로 대응할 수 있다.

경쟁 압력은 상호 운용성을 개선할 수 있다. 플랫폼 전략과 관계없이 기업은 모든 운영 및 분석 데이터를 하나의 공급업체 경계 안에 보관하는 경우가 드물다.

오픈 카탈로그, MCP 연결, 연합 소스 지원은 종속을 줄일 수 있다. 그러나 크로스 플랫폼 접근은 보안 검토와 시맨틱 일관성을 더 복잡하게 만든다.

결정적인 고객 질문은 에이전트가 인상적인 프롬프트에 답할 수 있는지가 아니다. 숨겨진 검증 업무 대기열을 만들지 않고 직원들이 일상적인 답변을 신뢰할 수 있는지가 핵심이다.

Google Cloud는 이 문제에 대한 진지한 대응책을 마련했다. 하나의 아키텍처에서 데이터 접근, 시맨틱 그라운딩, 권한, 관측 가능성, API, 업무 환경 배포를 결합한다.

그 결과 엔터프라이즈의 대화가 달라진다. 데이터베이스를 감싼 맞춤형 챗봇은 이제 완성된 제품이라기보다 초기 프로토타입처럼 보인다.

그렇더라도 거버넌스 기능이 자동으로 신뢰를 만들어 내지는 않는다. 조직은 지표를 정의하고, 메타데이터를 정비하며, 모호한 질문을 테스트하고, 실패의 담당자를 지정해야 한다.

대화형 분석을 확장하기 전에 하나의 중대한 워크플로를 선택해 전체 경로를 측정하라. 질문, 생성된 로직, 수정 사항, 권한, 지연 시간, 그 뒤에 이어지는 비즈니스 의사결정을 추적해야 한다.

Google Cloud가 이러한 통제된 배포를 반복 가능한 증거로 전환할 수 있다면, 대화형 분석은 채팅을 넘어설 것이다. 기업이 자체 운영을 조사하는 방식을 위한 거버넌스형 인터페이스가 될 것이다.