Google Private AI Compute 메모리, 클라우드의 상태 비저장 프라이버시 모델에 도전

Google이 Private AI Compute에 영구적인 서버 측 메모리를 추가하며, 기존의 프라이버시 중심 클라우드 AI를 규정하던 상태 비저장 설계에서 한발 나아갔다. 이 시스템은 복호화 키를 사용자가 제어하는 하드웨어에 유지하면서 기기 전반에서 맥락을 기억하도록 설계됐다.

이는 Google Private AI Compute 메모리에 중요한 변화다. 지금까지 Google과 Apple은 망각을 핵심적인 프라이버시 보호 수단으로 다뤘다. 각 클라우드 요청은 격리된 환경에 들어가 응답을 받은 뒤, 영구적인 개인 맥락을 남기지 않고 종료됐다.

Google은 클라우드 환경이 요청마다 모든 것을 잊는다면 어시스턴트는 진정한 연속성을 갖출 수 없다고 주장한다. 이에 대한 해법으로 제시한 것은 클라우드에 남아 있지만 기기에서 파생된 키 없이는 열 수 없는 암호화된 메모리 금고다.

이 아키텍처는 연속성과 데이터 최소화 사이에 직접적인 긴장을 만든다. 더 많이 기억하면 어시스턴트의 유용성은 높아질 수 있지만, 동시에 상태 비저장 시스템이 피하도록 설계된 지속적인 공격 표적도 생긴다.

Google, Private AI Compute에 메모리 부여

Google은 프라이빗 추론 서비스를 지속형 개인 컴퓨팅 계층으로 전환하고 있다.

Google DeepMind는 2026년 9월 23일 이 아키텍처를 공개했다. 기술 업데이트에서는 세션과 기기를 넘나들며 개인 맥락을 유지하는 메모리 계층을 설명한다.

Private AI Compute는 처음에 고사양 AI 작업을 휴대폰의 한계 밖으로 확장하기 위해 도입됐다. 로컬 모델의 컴퓨팅 용량이 부족할 때 기기는 암호화된 요청을 보호된 Google 인프라로 보낼 수 있었다.

이 클라우드 환경은 하드웨어로 격리된 시스템 안에서 요청을 처리했다. 이후 세션의 개인 맥락을 유지하지 않은 채 결과를 반환했다.

Google은 이 초기 설계를 상태 비저장이라고 부른다. 실질적으로 이 서비스는 하나의 요청을 도울 수는 있었지만, 이후에도 같은 경험을 안전하게 이어갈 수는 없었다.

새 메모리 계층은 이 한계를 바꾼다. 추론 요청이 끝난 뒤에도 개인 맥락은 사용자별 데이터베이스에 남아 있을 수 있다. Google은 저장된 정보가 암호화된 상태로 유지되고, 이를 해제하는 데 필요한 키는 사용자의 기기에 남는다고 설명한다.

권한이 부여된 모델이 해당 맥락을 필요로 하면 기기는 격리된 클라우드 환경과 인증된 종단 간 암호화 연결을 수립한다. 그 보안 엔클레이브는 보호된 메모리 안에서 필요한 정보를 일시적으로 복호화한다.

보안 엔클레이브는 더 넓은 서버 환경으로부터 코드와 데이터를 분리하는 하드웨어 강제 영역이다. 권한이 높은 인프라 소프트웨어조차 엔클레이브의 활성 메모리를 자유롭게 검사해서는 안 된다.

요청을 처리한 후 시스템은 유지된 맥락을 업데이트할 수 있다. 이어 해당 맥락을 다시 암호화한 뒤 저장소로 돌려보낸다.

이 구조는 상태 비저장 모델에서는 어려웠던 경험을 지원한다. 휴대폰에서 시작한 대화가 배경 정보를 수동으로 다시 구성하지 않고도 노트북에서 이어질 수 있다.

Google은 스마트 글래스 사례도 제시한다. 사용자가 안경을 통해 안내를 확인한 뒤, 나중에 다른 기기에서 관련 맥락을 불러올 수 있다는 설명이다.

회사는 이번 공개에서 광범위한 소비자 출시 일정을 발표하지 않았다. 이 아키텍처를 향후 지속형 메모리 경험을 가능하게 할 기능으로 설명한다.

이 구분은 중요하다. Google은 보안 모델을 공개했지만, 독자가 아직 저장된 메모리를 검사할 수 있는 완전한 제품 목록이나 표준 제어 기능을 갖게 된 것은 아니다.

그럼에도 이번 발표는 전략적 전환을 의미한다. Google은 더 이상 프라이빗 클라우드 추론과 지속적인 개인화를 별개의 문제로 다루지 않는다.

기존 Private AI Compute 플랫폼은 민감한 요청에 기존 클라우드 접근 패턴을 적용하지 않고 더 큰 Gemini 워크로드를 실행하는 데 초점을 맞췄다. 지속형 메모리는 시스템의 책임을 추론 순간 너머로 확장한다.

이제 이 서비스는 전송 중, 활성 처리 중, 장기 저장, 이후 검색, 삭제 과정에서 정보를 보호해야 한다. 단계가 추가될 때마다 설계 오류가 프라이버시에 영향을 미칠 수 있는 지점도 하나씩 늘어난다.

더 넓어진 이 책임이 핵심이다. Google은 클라우드 AI가 운영자에게 그 메모리에 대한 일반적인 접근 권한을 주지 않으면서도 한 사람을 시간에 걸쳐 기억할 수 있다고 제안한다.

상태 비저장 클라우드 AI가 한계에 도달한 이유

기밀 클라우드 AI를 더 신뢰하기 쉽게 만든 프라이버시 기능은 개인 어시스턴트로서의 역량도 제한했다.

상태 비저장 처리는 서버에 남는 개인 정보의 양을 최소화한다. 그러나 모델이 이전 상호작용에 대한 지속적인 기록 없이 각 보호 세션을 시작하기 때문에 연속성도 제한된다.

개발자는 일부 선호 정보를 다른 곳에 저장해 이 문제를 우회할 수 있다. 어시스턴트는 사용자가 선호하는 언어, 식단 제한 또는 자주 찾는 목적지를 유지할 수 있다.

하지만 고립된 사실 목록만으로는 변화하는 대화를 재현할 수 없다. 미완성 작업, 바뀌는 우선순위, 또는 서로 다른 기기에서 완료된 활동 간 관계를 완전히 표현할 수 없다.

그 결과 사용자는 반복적인 선택에 직면한다. 같은 맥락을 다시 설명하거나, 일반적인 클라우드 계정에 이를 저장하도록 허용하거나, 덜 개인화된 어시스턴트를 받아들여야 한다.

Google Private AI Compute 메모리는 이 선택지를 없애기 위한 것이다. 지속형 암호화 저장소를 정보를 읽을 수 있게 만드는 데 필요한 키와 분리한다.

이 분리는 고도화된 AI 모델이 여전히 상당한 서버 자원을 필요로 하기 때문에 중요하다. 휴대폰과 노트북은 점점 더 유능한 로컬 모델을 실행할 수 있지만, 최전선 규모의 모든 작업을 효율적으로 수행할 수는 없다.

클라우드 인프라는 더 큰 모델, 특수 가속기, 더 많은 가용 메모리를 제공한다. 동시에 민감한 정보를 다른 조직이 통제하는 환경으로 옮긴다.

기밀 컴퓨팅은 이 신뢰 격차를 좁히려 한다. 저장 중이거나 네트워크를 통해 이동 중일 때뿐 아니라 데이터가 사용되는 동안에도 이를 보호한다.

기존 암호화는 저장된 데이터와 전송 중인 데이터를 보호한다. 그러나 일반 서버는 모델이 처리하기 전에 여전히 어딘가에서 이 정보를 복호화해야 한다.

신뢰 실행 환경, 즉 TEE는 이 노출된 단계를 제한한다. 승인된 코드는 격리된 경계 내부에서 읽을 수 있는 정보를 처리하고, 주변 호스트는 이를 직접 검사할 수 없는 상태로 남는다.

Google Cloud는 기밀 컴퓨팅을 처리 중 민감한 워크로드를 보호하는 방법으로 설명한다. 활용 사례에는 분석, 머신러닝, 보호된 데이터세트 간 협업이 포함된다.

이 접근 방식이 모든 신뢰 가정을 없애지는 않는다. 대신 신뢰해야 하는 구성 요소를 바꾸고, 기기가 자신의 데이터를 받는 환경에 관한 기술적 증거를 얻도록 한다.

지속형 메모리는 이러한 보장의 중요성을 높인다. 단일 추론 요청은 제한된 기간 동안 제한된 맥락 일부만 노출한다.

지속형 AI 메모리는 대화, 선호도, 문서, 위치, 행동 패턴을 축적할 수 있다. 어시스턴트에 대한 가치가 높을수록 공격자에게도 더 가치 있는 대상이 된다.

지식 노동자라면 그 매력을 쉽게 이해할 것이다. 개인 어시스턴트는 시간에 걸쳐 회의, 파일, 결정, 미완성 작업을 연결할 수 있을 때 더 유용해진다.

같은 원리는 개인 지식 베이스에도 적용된다. 유용한 검색은 지속적인 맥락, 명확한 소유권, 관련 없는 사람이 접근하지 못하게 하는 제어 기능에 달려 있다.

Google은 이러한 원칙을 클라우드 규모에 적용하려 한다. 공급자가 읽을 수 있는 개인 이력의 관리자가 되지 않으면서도 연속성을 유지해야 한다.

이 압력은 Google을 넘어선다. 모든 주요 어시스턴트 공급업체는 연속성이 작업 완료율을 높이고 반복적인 프롬프팅을 줄이기 때문에 더 오래 지속되는 맥락을 원한다.

이제 어려운 질문은 어시스턴트가 기억해야 하는지 여부가 아니다. 사용자가 기존 서버 측 가시성을 받아들이지 않고도 유용한 메모리를 얻을 수 있는지가 관건이다.

Google Private AI Compute 메모리의 작동 방식

이 설계는 암호화된 메모리를 Google 인프라에 두되, 이를 실질적으로 해제할 권한은 개인 기기에 연결해 둔다.

Google은 메모리 저장소를 안전한 디지털 금고로 설명한다. 각 사용자는 해당 사용자의 기기와 연관된 암호화로 보호되는 격리된 저장소를 제공받는다.

이 아키텍처는 일반적으로 DEK라고 하는 데이터 암호화 키를 사용해 저장된 메모리를 암호화한다. 두 번째 키는 해당 DEK를 보호하므로 데이터베이스가 직접 사용할 수 있는 잠금 해제 비밀을 보유하지 않는다.

Google의 도표는 이 두 번째 계층을 키 암호화 키 구성으로 식별한다. 기기는 저장된 데이터를 풀어내는 데 필요한 키 자료를 파생하거나 보호하는 과정에 참여한다.

이 설계는 암호화된 데이터베이스를 탈취하는 것만으로는 그 내용을 드러낼 수 없어야 한다는 뜻이다. 공격자는 권한이 부여된 키 경로와 승인된 처리 환경에도 접근해야 한다.

어시스턴트가 맥락을 필요로 할 때 클라이언트는 먼저 원격 환경을 검증한다. 이 과정을 원격 증명이라고 한다.

원격 증명을 통해 기기는 민감한 정보를 공개하기 전에 서버의 하드웨어와 실행 중인 소프트웨어에 관한 주장을 확인할 수 있다. 유효한 보고서는 승인된 코드가 예상된 엔클레이브 안에서 작동하고 있음을 보여줘야 한다.

그다음 기기는 해당 환경에 암호화된 채널을 만든다. 시스템이 필요한 검증을 통과한 뒤에만 메모리는 격리된 메모리 내부에서 복호화된다.

모델은 이 맥락을 사용해 요청에 답할 수 있다. 또한 메모리 서비스가 이후 상호작용을 위해 저장할 새 정보를 생성할 수도 있다.

Google은 관리자나 일반 클라우드 서비스 모두 이 정보를 검사할 수 없다고 말한다. 더 나아가 이 아키텍처가 Google조차 데이터에 접근할 수 없게 만든다고 주장한다.

이 주장은 암호화만으로 성립하지 않는다. 기기는 서버를 정확히 검증해야 하고, 엔클레이브는 격리를 강제해야 하며, 소프트웨어는 출력물을 통해 데이터가 유출되지 않도록 해야 한다.

키 관리 역시 핵심이 된다. 계정 복구, 기기 교체, 동기화 또는 권한 철회 과정에서 대체 접근 경로가 은밀히 도입되면 프라이빗 시스템도 실패할 수 있다.

Google은 공개 발표에서 이러한 사용자 수명 주기 시나리오를 완전히 상세히 설명하지 않았다. 이들은 실제 배포된 시스템이 아키텍처적 약속에 얼마나 부합하는지를 좌우할 것이다.

예를 들어 신뢰할 수 있는 기기를 모두 잃는 상황은 어려운 선택을 만든다. 강력한 기기 전용 키는 메모리를 영구적으로 복구 불가능하게 할 수 있다.

편리한 공급자 제어형 복구 메커니즘은 이 위험을 줄일 수 있다. 그러나 사용자 이외의 누군가가 접근할 수 있는 또 다른 경로를 만들 수도 있다.

새 휴대폰을 추가하는 일도 관련된 문제를 제기한다. 시스템은 중개자에게 키를 노출하거나 권한 없는 등록을 허용하지 않으면서 해당 기기에 권한을 이전해야 한다.

삭제 역시 화면에 보이는 메모리 항목을 제거하는 것 이상을 포함해야 한다. 사용자는 폐기된 키, 복제본, 백업, 캐시, 파생된 맥락이 나중에 삭제된 것으로 여겨진 정보를 복원할 수 없다는 확신이 필요하다.

이는 일반적인 운영 요건이지 Google의 설계에 결함이 있다는 증거는 아니다. 프라이빗 AI 메모리가 데이터베이스를 엔클레이브 뒤에 두는 것 이상의 문제인 이유를 보여준다.

추론 경로 자체에는 여러 구성 요소가 포함된다. 앞선 독립 평가에서는 암호화된 클라이언트 연결, 프런트엔드 서비스, 오케스트레이션 시스템, AI 안전 모듈, 강화된 TPU 인프라를 설명했다.

이러한 구성 요소는 서로를 인증하고, 증명을 사용해 승인된 통신 경로를 수립한다. 추가되는 각 서비스는 의도된 개인정보 보호 경계 안에 머물러야 한다.

Google은 서버 소프트웨어에 대한 변조 방지 기록도 공개할 계획이다. 클라이언트는 개인 데이터를 전송하기 전에 서버가 증명한 소프트웨어 측정값을 공개 기록과 비교할 수 있다.

이 메커니즘은 미묘한 클라우드 위험을 겨냥한다. 제공업체가 검토용으로는 안전한 코드를 공개하지만, 실제 운영 환경에서는 다른 소프트웨어를 실행할 수 있다.

추가 전용 투명성 기록은 탐지되지 않은 대체를 어렵게 만든다. 연구자들은 등록된 빌드를 검사할 수 있고, 기기는 승인된 측정값과 일치하지 않는 환경을 거부한다.

이 메커니즘이 승인된 모든 빌드에 취약점이 없음을 증명하는 것은 아니다. 다만 검토된 소프트웨어가 기기가 신뢰하도록 허용된 소프트웨어와 일치한다는 증거를 제공한다.

이 구분은 중요하다. 투명성은 검증을 가능하게 하지만, 검증에는 접근 가능한 아티팩트와 역량 있는 연구자, 그리고 시간이 여전히 필요하다.

개인정보 보호 약속에는 여전히 하드웨어 경계가 있다

Google은 클라우드 관리자의 권한을 줄일 수 있지만, Google이 설계한 하드웨어와 소프트웨어에 대한 모든 의존성을 없앨 수는 없다.

Google은 2025년 봄부터 NCC Group에 Private AI Compute의 일부 구성 요소 평가를 의뢰했다. 컨설턴트 10명은 아키텍처 및 구성 요소 검토에 총 100 인일을 투입한 것으로 알려졌다.

독립 검토는 Oak Session 암호화 라이브러리, 원격 증명, IP 비식별 릴레이, 투명성 로깅, 그리고 일부 서버 코드를 조사했다. 이 작업은 감사받지 않은 제품 주장보다 더 실질적인 근거를 제공한다.

그러나 그 범위는 중요하다. 일부 구성 요소에 대한 검토가 향후의 모든 메모리 기능, 클라이언트 구현, 하드웨어 개정판 또는 운영 절차를 인증하는 것은 아니다.

이 평가는 근본적인 한계도 지적한다. 실용적인 AI 추론은 현재 어떤 물리적 컴퓨팅 시스템 내부에서 읽을 수 있는 데이터로 작동한다.

따라서 암호화된 정보는 연산 중 보호된 프로세서 안에서 평문이 된다. 하드웨어와 승인된 코드는 요청된 작업을 수행해야 하므로 해당 정보에 접근할 수 있다.

NCC 보고서는 하드웨어 설계자가 이론적으로 칩에 데이터 유출 경로를 만들 수 있는 능력을 여전히 보유한다고 언급한다. Private AI Compute는 궁극적으로 Google의 강화된 TPU 플랫폼이 설명된 대로 동작한다는 전제에 의존한다.

이 한계는 기밀 컴퓨팅 전반에 적용된다. 엔클레이브는 하이퍼바이저, 관리자, 손상된 호스트 소프트웨어에 대한 노출을 줄이지만, 물리적 연산을 신뢰가 전혀 필요 없는 것으로 만들지는 않는다.

사이드채널 공격도 또 다른 우려를 낳는다. 이러한 공격은 타이밍, 메모리 접근, 리소스 경합, 전력 사용량처럼 관찰 가능한 동작으로부터 보호된 정보를 추론한다.

기밀 플랫폼은 지속적으로 완화책을 추가하지만, 새로운 하드웨어 취약점은 기존 보안 가정을 바꿀 수 있다. 따라서 시스템의 개인정보 보호 근거는 위협 환경과 함께 발전해야 한다.

엔클레이브 내부의 소프트웨어도 실수할 수 있다. 모델이나 지원 서비스는 기반 저장소가 암호학적으로 보호되더라도 출력물을 통해 민감한 세부 정보를 노출할 수 있다.

프롬프트 인젝션은 관련된 과제를 제기한다. 악의적인 콘텐츠가 어시스턴트를 조작해 사용자가 해당 맥락에서 공유할 의도가 없었던 정보를 검색하거나 공개하게 만들 수 있다.

엔클레이브는 요청이 사용자의 실제 의도를 나타내는지 자동으로 판단할 수 없다. 엔클레이브는 개발자가 구현한 정책 아래에서 승인된 소프트웨어를 실행한다.

지속적 컨텍스트는 한 번의 손상된 상호작용 중 더 많은 정보가 이용 가능할 수 있으므로 위험을 높인다. 액세스 제어는 각 기능이 검색할 수 있는 메모리를 제한해야 한다.

시스템에는 메타데이터 추론을 방지하는 안전장치도 필요하다. 저장 용량, 접근 빈도, 기기 타이밍, 네트워크 패턴은 메모리의 정확한 내용을 노출하지 않고도 정보를 드러낼 수 있다.

Google의 기존 아키텍처에는 사용자 신원과 요청을 분리하도록 설계된 IP 비식별 릴레이가 포함된다. 지속형 시스템은 메모리 읽기와 업데이트 전반에서 유사한 보호를 유지해야 한다.

연구자들은 기밀 AI에 대한 더 개방적인 접근법을 제안해 왔다. 2026년 OpenPCC 논문은 Google과 Apple의 초기 시스템이 독점 인프라에 크게 의존한다고 주장한다.

저자들은 상용으로 이용 가능한 신뢰 실행 환경을 활용해 오픈소스 프로토타입을 구축했다. 이들의 비판은 Google에 중요한 검증 질문을 제기한다.

외부 연구자들은 의미 있는 개인정보 보호 주장을 검증할 수 있도록 충분한 코드, 측정값, 도구를 필요로 한다. 공개 로그만으로 완전한 재현성이 생기는 것은 아니다.

Google은 업데이트된 아키텍처 세부 사항, 보안 증명, 검증 프로토콜, 감사 결과를 공개하고 있다고 말한다. 그 공개의 깊이가 연구자들이 메모리 계층을 얼마나 독립적으로 평가할 수 있는지를 결정할 것이다.

따라서 사용자는 “Google조차 접근할 수 없음”이라는 표현을 계층화된 통제로 뒷받침되는 보안 목표로 해석해야 한다. 이는 Google에 대한 신뢰가 전혀 필요 없다는 주장이 아니다.

이 아키텍처는 개인 컨텍스트를 볼 수 있는 사람과 시스템의 수를 줄인다. 또한 무단 접근을 기술적으로 더 어렵고 더 탐지하기 쉽게 만든다.

이는 주로 정책과 관리 액세스 제어로 보호되는 일반적인 클라우드 데이터베이스보다 더 강력한 기준이다. 그러나 모든 정보를 연결이 끊긴 하드웨어에 보관하는 것과 동등하지는 않다.

Apple의 상태 비저장 모델이 이제 주요 대조점이다

Google은 사용자의 실질적인 개인정보 보호 경계를 약화하지 않으면서 사적인 지속성이 엄격한 망각보다 더 나은 성능을 낼 수 있다고 보고 있다.

Apple의 Private Cloud Compute는 가장 명확한 비교 대상이다. Apple은 PCC를 상태 비저장 처리, 제한된 관리 액세스, 비표적성, 검증 가능한 소프트웨어 투명성을 중심으로 구축했다.

Apple의 보안 아키텍처는 요청이 완료된 뒤 사용자 데이터가 남아서는 안 된다고 설명한다. 노드 데이터 볼륨의 암호화 키는 재부팅 시 변경되며 보존되지 않는다.

Apple은 PCC 노드에서 대화형 디버깅 도구와 범용 로깅도 제거한다. Apple의 공개 모델은 사용자 데이터를 보존할 수 없다는 점을 강제 가능한 속성으로 본다.

Google도 Private AI Compute를 출시했을 당시 이 상태 비저장 철학을 상당 부분 공유했다. 이제 지속형 서버 측 메모리는 두 접근법 간의 뚜렷한 차이를 만든다.

Apple의 모델은 영속적인 클라우드 상태를 최소화한다. Google의 새 설계는 기기 간 연속성을 개인 AI에 필수적인 요소로 보기 때문에 영속적인 암호화 상태를 받아들인다.

어느 입장도 모든 문제를 해결하지는 못한다. 상태 비저장 처리는 장기적 축적을 막지만, 어시스턴트가 자연스럽게 작업을 이어가는 능력은 제한한다.

지속적인 암호화 메모리는 더 풍부한 개인화를 지원한다. 대신 생성, 검색, 수정, 전송, 보존, 삭제를 아우르는 더 큰 수명주기를 만든다.

이 비교는 단순히 Google 대 Apple의 대결이 아니다. 이는 프라이빗 클라우드 AI가 무엇을 보장해야 하는지에 관한 두 가지 정의를 나타낸다.

한 정의는 프라이빗 연산이 모든 작업 뒤에 잊어야 한다고 말한다. 다른 정의는 기억하되, 사용자의 기기가 승인한 키와 소프트웨어를 통해서만 기억해야 한다고 말한다.

Apple은 고사양 워크로드를 위해 PCC를 Google Cloud 인프라로도 확장했다. Apple은 Apple 기기가 여전히 Apple이 암호학적으로 승인한 소프트웨어만 신뢰한다고 말한다.

이 협력은 하드웨어 소유권과 개인정보 보호 통제가 항상 같은 조직에 속하지는 않는다는 점을 보여준다. 소프트웨어 증명을 통해 한 회사가 다른 회사의 인프라에 요구사항을 적용할 수 있다.

그러나 Apple은 PCC를 계속 상태 비저장으로 설명한다. 따라서 Google의 지속형 계층은 Apple이 핵심 안전장치로 제시하는 속성을 넘어선다.

그 차이는 제품 동작을 통해 구체적으로 드러날 것이다. 상태 비저장 어시스턴트는 클라우드에 진입할 때마다 기기나 별도의 사용자 제어 저장소에서 컨텍스트를 가져와야 한다.

Google의 접근법은 기기 승인 후 보호된 클라우드 환경이 이전 컨텍스트를 직접 검색할 수 있게 한다. 이는 지연 시간, 반복 전송, 제품 간 단절을 줄일 수 있다.

반면 Google의 메모리 형식과 기기 등록 시스템에 대한 의존도를 높일 수도 있다. 사용자는 내부 어시스턴트에 최적화된 기록을 검사하거나 이전하기 어렵다고 느낄 수 있다.

이 발표에서는 이동성이 다뤄지지 않았다. 표준 내보내기 형식, 기본 보존 설정, 호환 가능한 메모리 서비스를 다른 곳에서 실행할 수 있는 능력도 마찬가지다.

이 문제들은 개인정보 보호만큼이나 경쟁에 영향을 미친다. 유용한 메모리는 시간이 지날수록 개선되는 개인화 자산이 된다.

그 자산이 하나의 어시스턴트에 묶여 있다면, 서비스를 전환하려면 축적된 컨텍스트를 잃거나 이전 과정에서 이를 노출해야 한다. 암호화만으로는 종속을 막을 수 없다.

Google은 사용자에게 명확한 검사, 내보내기, 수정, 삭제 제어 기능을 제공함으로써 입지를 강화할 수 있다. 또한 사람들이 기기나 계정을 바꿀 때 메모리가 어떻게 이동하는지도 문서화할 수 있다.

한편 Apple은 상태 비저장 설계가 비슷한 수준의 연속성을 제공할 수 있음을 보여줘야 한다는 압박을 받고 있다. Apple은 암호화된 기기 저장소에 더 크게 의존하고, 각 요청에 필요한 최소한의 컨텍스트만 동기화할 수 있다.

다른 어시스턴트 공급업체도 같은 선택에 직면한다. 이들은 기존 계정 데이터베이스에 메모리를 보관하거나, 기밀 인프라를 채택하거나, 장기 컨텍스트를 사용자가 제어하는 기기에 남겨둘 수 있다.

Google의 설계는 고도로 개인적인 어시스턴트에 일반적인 서버 측 저장소를 사용하는 것이 덜 정당화될 수 있음을 보여준다. 더 강력한 통제가 존재하는 상황에서 개인정보 보호에 민감한 사용자는 경쟁업체가 왜 이를 사용하지 않는지 물을 수 있다.

사용자와 연구자가 다음으로 지켜봐야 할 점

이 아키텍처는 다이어그램만으로가 아니라, 배포된 통제와 외부 검증을 통해 신뢰를 얻을 것이다.

첫 번째 신호는 제품 출시다. Google은 어떤 Gemini 경험이 지속형 Private AI Compute 메모리를 사용하고, 어떤 경험이 다른 저장 시스템을 계속 사용하는지 밝혀야 한다.

사용자가 요청이 보호된 환경에 들어갈 때 이를 알 수 있는 눈에 보이는 표시가 있어야 한다. Google은 이미 지원되는 Pixel 기기에서 Private AI Compute 네트워크 정보를 제공하고 있다.

지속형 메모리에는 그에 못지않게 명확한 제어 기능이 필요하다. 사용자는 무엇이 보존되었는지, 왜 검색되었는지, 어떤 기기가 작업을 승인했는지 확인할 수 있어야 한다.

그 인터페이스는 Google AI 메모리 개인정보 보호가 보안 논문 밖에서도 이해 가능한지 보여줄 것이다. 숨겨진 메모리나 지나치게 광범위한 메모리는 아키텍처의 실질적 가치를 약화할 수 있다.

두 번째 신호는 독립적 검증이다. 연구자들은 새로운 메모리 구성 요소를 위해 사용할 수 있는 소프트웨어 기록, 검사 도구, 증명 근거, 문서를 필요로 한다.

Google의 투명성 로그는 지속형 컨텍스트를 검색하거나 업데이트할 수 있는 모든 보안 핵심 서비스를 포괄해야 한다. 부분적인 적용 범위는 중요한 코드를 공개 검증 밖에 남길 수 있다.

향후 평가는 이전의 상태 비저장 인프라만이 아니라 배포된 메모리 경로를 시험해야 한다. 키 처리, 기기 등록, 삭제, 복구, 악의적 입력에 대한 저항성을 조사해야 한다.

공개 취약점 연구는 공개 문서의 수보다 더 중요할 것이다. 신뢰할 만한 발견, 수정, 공개 일정은 플랫폼이 압박 속에서 어떻게 작동하는지를 보여줄 것이다.

세 번째 신호는 경쟁사의 대응이다. Apple의 상태 비저장 처리에 대한 약속은 이제 Google의 설계를 판단할 수 있는 명확한 대안으로 작용한다.

Google이 중대한 개인정보 보호 실패 없이 유용한 기기 간 연속성을 제공한다면, 엄격한 상태 비저장 방식은 불필요하게 제한적으로 보이기 시작할 수 있다. 경쟁사들은 보호된 지속성을 추가해야 한다는 압박을 받게 될 것이다.

삭제 또는 검증 과정이 불투명하다면, Apple의 ‘망각 우선’ 아키텍처가 더 설득력을 얻게 된다. 같은 결과는 기억을 로컬에 보관하는 어시스턴트에도 유리하게 작용할 것이다.

기업 구매자들은 Google이 이 시스템을 조직 데이터에 맞게 조정하는지도 살펴봐야 한다. 개인 기기 키는 직원 이직, 법적 보존 의무, 공유 작업 공간과 깔끔하게 맞아떨어지지 않는다.

기업은 관리자가 기록을 복구하거나 접근 권한을 제거할 수 있어야 할 수 있다. 이러한 요구는 제공업체조차 저장된 컨텍스트를 복호화할 수 없다는 약속과 충돌할 수 있다.

개발자는 향후 제공될 접근 모델을 검토해야 한다. 프라이빗 메모리 계층에는 한 애플리케이션이 무관한 용도로 생성된 컨텍스트를 가져오지 못하도록 세분화된 권한이 필요하다.

사용자는 모든 Google AI 기능이 자동으로 이러한 보호를 받는다고 가정해서는 안 된다. Private AI Compute는 모든 클라우드 처리에 적용되는 범용 라벨이 아니라 특정 아키텍처다.

제품 문서에는 시스템이 언제 활성화되는지와 사용할 수 없을 때 어떤 일이 발생하는지를 명시해야 한다. 요청이 별도 고지 없이 보호 수준이 낮은 서비스로 이동한다면 대체 동작은 프라이버시를 훼손할 수 있다.

Google Private AI Compute 메모리는 프라이빗 클라우드 어시스턴트의 실질적인 약점을 해결한다. 상태 비저장 시스템은 망각을 통해 사용자를 보호하지만, 여러 기기에서 연속적인 작업을 지원하는 데 어려움을 겪는다.

Google의 대안은 기술적으로 야심 차면서도 개념적으로는 단순하다. 컨텍스트는 원격에 저장하고, 키는 사용자가 보유하며, 검증된 소프트웨어 내부에서만 복호화한다.

어려운 부분은 이 설계가 다이어그램을 벗어난 뒤부터 시작된다. 계정 복구, 기기 이전, 접근 경계, 투명성, 삭제, 소프트웨어 결함이 실제 프라이버시 수준을 결정할 것이다.

사용자가 지금 할 일은 간단하다. 향후 Gemini 메모리 기능이 Private AI Compute를 명시하는지, 보존된 컨텍스트를 보여주는지, 직접 삭제할 수 있는 제어 기능을 제공하는지 확인해야 한다.

연구자에게는 시험 기준이 더 엄격하다. 독립 전문가가 프로덕션 소프트웨어를 검증하고, 신뢰 체인을 재현하며, 공격자보다 먼저 의미 있는 취약점을 찾아낼 수 있을까?

Google은 클라우드 어시스턴트가 더 이상 메모리와 프라이버시 사이에서 선택할 필요가 없다고 제안했다. 다음 출시에서는 안전한 서버 측 메모리가 시간이 지나도 그 약속을 지킬 수 있는지 보여줘야 한다.