Google Confidential G4 GPU GA: AI 데이터 사용 중 암호화의 실제 경계
AI 서비스가 민감한 데이터를 다룰수록 “저장할 때 암호화하고 전송할 때 TLS를 쓰면 충분한가?”라는 질문이 남습니다. 실제 추론 중에는 모델 가중치와 프롬프트가 GPU 메모리와 실행 환경에 평문으로 존재할 수 있기 때문입니다. 클라우드 사업자의 운영자, 하이퍼바이저, 호스트 관리자 또는 같은 인프라를 공유하는 경로가 이 데이터를 볼 수 있다면 저장·전송 암호화만으로는 데이터 사용 중 보호가 완성되지 않습니다.
Google Cloud는 2026년 10월 21일 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU를 사용하는 Confidential G4를 정식 출시했습니다. 발표에 따르면 Confidential Computing 기능은 Compute Engine 가상 머신과 GKE 노드에서 36개 존에 제공되며, 하드웨어 키, 메모리 암호화, 원격 검증(remote attestation)을 결합해 AI 모델·프롬프트·생성 결과를 실행 중에도 보호합니다.
이 글은 Google Cloud 공식 발표, Google Cloud Confidential VM GPU 문서, NVIDIA Confidential Computing 개요, NVIDIA 위협 모델, MITRE 지속적 원격 검증 프레임워크를 교차 확인해 작성했습니다. 벤더 발표의 성능 수치와 보안 보장은 배포 방식·드라이버·정책에 따라 달라질 수 있으므로, 실제 도입 전에 조직의 위협 모델을 다시 정의해야 합니다.
1. Confidential G4가 해결하려는 문제
일반적인 AI 추론 경로는 다음과 같습니다.
- 사용자의 프롬프트와 검색 결과가 클라우드 VM으로 전송됩니다.
- 애플리케이션이 모델 가중치와 데이터를 GPU 메모리에 적재합니다.
- GPU가 토큰을 계산하고 결과를 반환합니다.
- 로그·캐시·모니터링 시스템에 일부 입력과 출력이 남습니다.
TLS는 1번과 3번의 네트워크 구간을 보호하고, 디스크 암호화는 저장된 모델과 로그를 보호합니다. 그러나 2번과 3번의 “사용 중인 데이터”는 CPU·GPU 메모리, 드라이버, 하이퍼바이저가 관찰할 수 있는 실행 경계 안에 놓입니다.
Confidential Computing은 이 실행 경계 안에 하드웨어 기반 신뢰 실행 환경(TEE)을 만들고, 데이터가 메모리에서 처리되는 동안에도 암호화·격리를 적용하는 접근입니다. Google Cloud의 Confidential G4는 AMD SEV 기반 Confidential VM과 NVIDIA GPU의 Confidential Computing 기능을 결합합니다. Google은 다음 세 가지를 핵심 구성으로 설명합니다.
- 비수출 하드웨어 키: 키가 소프트웨어나 호스트 운영체제로 복사되지 않고 하드웨어 경계에 묶입니다.
- 메모리 암호화: VM과 GPU가 처리하는 데이터가 보호된 메모리 경계를 벗어나지 않도록 합니다.
- 원격 검증: 워크로드가 실행되기 전에 CPU·GPU·펌웨어·소프트웨어 측정값을 확인하고, 조건을 만족할 때만 모델 키나 데이터 키를 전달합니다.
이 구조의 목표는 “클라우드 운영자는 절대 악의적이지 않다”는 가정에 의존하지 않고, 운영자와 하이퍼바이저를 런타임의 신뢰 경계 바깥으로 밀어내는 것입니다.
2. 이번 GA에서 확인되는 제공 범위
Google 발표의 제공 범위는 단순한 미리보기보다 넓어졌습니다.
| 항목 | 발표 내용 | 설계 시 확인할 점 |
|---|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Server Edition | GPU 세대와 드라이버 조합별 기능 차이 |
| 서비스 | Compute Engine VM, GKE 노드 | VM 이미지와 GKE 노드 구성을 별도 검증 |
| 리전 범위 | 36개 존 | 원하는 리전·쿼터·예약 용량 확인 |
| 소비 방식 | 표준 온디맨드, Spot, Flex-start, 예약 | 비용과 가용성 사이의 트레이드오프 |
| 다자간 데이터 | Confidential Space 지원이 수 주 내 GA 예정 | 현재 GA 시점과 기능별 출시 상태 구분 |
| 애플리케이션 변경 | 표준 Ubuntu 이미지, NVIDIA 드라이버·CUDA-X 사용 가능 | “무변경”은 지원 이미지와 버전을 지킨다는 의미 |
Google은 G4에서 Llama 3, Llama 3.3, ResNet-50, SDXL을 사용해 일반 G4와 비교했고, 처리량 저하가 3.5% 미만이라고 밝혔습니다. 이는 암호화와 검증을 켜도 추론 처리량이 크게 떨어지지 않을 수 있다는 신호입니다. 다만 Google도 특정 g4-standard-48 형태와 특정 모델·소프트웨어 조합의 결과라고 명시합니다. 긴 컨텍스트, 높은 배치 크기, 다중 GPU 통신, 사용자 정의 CUDA 커널, 장시간 학습에서는 결과가 달라질 수 있습니다.
Google Cloud 문서에는 G4 Confidential VM을 만들 때 NVIDIA Confidential Computing 소프트웨어와 서비스 라이선스 비용이 자동으로 발생한다고 적혀 있습니다. 따라서 “Confidential 기능은 추가 비용이 없다”라고 가정하면 안 됩니다.
3. 원격 검증은 어떻게 키를 지키는가
원격 검증은 보안 마케팅 문구가 아니라 키 전달 조건을 만드는 프로토콜입니다. 일반적인 흐름은 다음과 같습니다.
- VM과 GPU가 부팅되면서 펌웨어, 커널, 드라이버, 보안 설정을 측정합니다.
- CPU와 GPU가 서명된 증거를 생성합니다.
- 검증 서비스가 증거의 장치 신원과 측정값을 승인된 기준값(reference values)과 비교합니다.
- 이미지 해시, 드라이버 버전, 보안 모드, 정책 조건이 모두 맞으면 키 브로커가 모델 가중치 또는 데이터 키를 전달합니다.
- 조건이 맞지 않으면 모델은 암호화된 상태로 남고, 워크로드는 실행되지 않거나 제한된 기능만 수행합니다.
NVIDIA 문서가 강조하는 점은 유효한 서명 자체가 곧 승인을 의미하지 않는다는 것입니다. 조직은 어떤 OS, 드라이버, 컨테이너, 모델 런타임을 허용할지 직접 정책으로 정해야 합니다. 검증 서비스는 증거를 평가할 뿐, 그 소프트웨어에 취약점이 없다는 사실까지 증명하지 않습니다.
따라서 실무에서는 다음 자료를 함께 관리해야 합니다.
- 승인된 VM 이미지·컨테이너 이미지의 해시
- NVIDIA 드라이버와 CUDA-X 버전
- CPU·GPU 펌웨어 기준값
- 보안 부팅·SEV·GPU 보안 모드 설정
- 키 브로커가 허용하는 정책 버전
- 검증 증거와 키 발급 이벤트의 감사 ID
이 기록이 있어야 고객에게 “이 답변은 특정 이미지와 특정 GPU에서 실행됐다”는 증거를 나중에 제시할 수 있습니다.
4. GPU까지 보호해야 하는 이유
CPU만 Confidential VM으로 만들고 GPU 메모리는 일반 경로로 두면, 모델과 프롬프트가 GPU로 이동하는 순간 보호 경계가 끊깁니다. NVIDIA Confidential Computing은 GPU 메모리 접근 제어와 GPU 보안 통신을 CPU TEE와 연결해 보호 범위를 확장합니다.
그러나 “GPU 전체가 자동으로 안전하다”는 뜻은 아닙니다. NVIDIA의 위협 모델은 배포 방식에 따라 신뢰 경계와 책임이 달라진다고 설명합니다.
- Confidential VM: 게스트 VM과 워크로드를 보호하지만, 게스트 OS·드라이버·애플리케이션은 여전히 모델 소유자가 신뢰하고 관리해야 합니다.
- Confidential Containers: 컨테이너 단위 경계를 제공하지만, Kubernetes 제어면과 정책 분리가 중요합니다.
- Confidential Bare Metal: 모델 소유자가 호스트 OS와 드라이버까지 관리하는 대신, 인프라 운영자를 런타임 신뢰 경계 밖에 둘 수 있습니다.
즉 G4 VM은 “클라우드 호스트와 하이퍼바이저로부터 보호”하는 시나리오에는 적합하지만, 모델을 운영하는 조직의 관리자나 악성 애플리케이션 자체로부터 사용자 데이터를 자동 보호하지는 않습니다. 모델 제공자가 사용자의 입력을 로그에 기록하거나, 애플리케이션이 프롬프트를 다른 API로 전송한다면 GPU 메모리 암호화만으로는 해결되지 않습니다.
5. 보호되는 경로와 보호되지 않는 경로를 분리하라
Confidential Computing에서 가장 흔한 오해는 TEE 안에 들어간 순간 모든 데이터 경로가 보호된다고 믿는 것입니다. 실제로 데이터는 다음 경로를 통과합니다.
- 사용자 브라우저와 API 게이트웨이
- VM의 가상 NIC와 호스트 네트워크
- CPU 메모리와 GPU 메모리 사이의 PCIe·전용 링크
- GPU 간 NVLink
- 객체 저장소·모델 레지스트리·키 브로커
- 로그·메트릭·트레이싱 시스템
- 백업·스냅샷·캐시
NVIDIA 문서는 보호 기능이 특정 통신 경로와 구성에 한정된다고 설명합니다. 예를 들어 NVLink 암호화가 켜져도 PCIe나 RDMA 경로가 자동으로 암호화되는 것은 아니며, 일부 하드웨어 세대에서는 CPU-GPU 링크나 PCIe의 하드웨어 IDE가 제공되지 않을 수 있습니다. 배포 topology에서 실제로 어떤 링크가 암호화되고 어느 엔드포인트가 평문을 볼 수 있는지 확인해야 합니다.
교육이나 설계 리뷰에서는 “모델이 실행되는 GPU 메모리”만 그리지 말고, 프롬프트가 들어오는 순간부터 결과가 사용자에게 돌아가는 순간까지 데이터 흐름을 그리는 것이 좋습니다. 각 화살표 옆에 암호화 상태, 접근 주체, 로그 보존 여부를 표시하면 보호 공백이 빠르게 드러납니다.
6. 성능 수치를 어떻게 읽어야 하는가
Google의 3.5% 미만 처리량 저하 수치는 도입 판단에 유용하지만, 그대로 SLA에 넣으면 안 됩니다.
먼저 처리량과 지연시간은 다른 지표입니다. 한 고객 사례에서 5.2%의 종단간 지연 증가를 감수하고 하드웨어 수준의 격리를 얻었다고 소개했지만, 이 값은 해당 고객의 워크로드 결과입니다. 암호화·검증 비용은 다음 요인에 따라 달라집니다.
- 모델이 GPU 메모리에 적재되는 빈도
- 배치 크기와 시퀀스 길이
- CPU와 GPU 사이의 데이터 이동량
- GPU 간 통신과 RDMA 사용 여부
- 컨테이너 시작과 원격 검증 횟수
- 모델 서버가 로그와 관찰성 데이터를 얼마나 자주 내보내는지
실무 벤치마크는 최소한 일반 G4와 Confidential G4에서 같은 이미지, 같은 드라이버, 같은 CUDA, 같은 모델 서버를 사용해야 합니다. 토큰 처리량, 첫 토큰 시간, 종단간 지연, GPU 메모리 사용량, 재시작 시간, 검증 실패율을 함께 측정하고, 온디맨드와 Spot을 분리해 비용까지 계산해야 합니다.
7. 에이전트 AI와 결합할 때의 의미
에이전트는 모델 가중치뿐 아니라 도구 토큰, 브라우저 세션, 사내 문서, 고객 데이터, 실행 결과를 동시에 다룹니다. 따라서 Confidential G4는 “모델 도난”만이 아니라 에이전트가 작업하는 동안 사용자의 입력과 내부 데이터가 호스트 운영자에게 노출될 가능성을 줄이는 수단이 될 수 있습니다.
다만 TEE는 에이전트의 행동을 허가하는 정책 엔진이 아닙니다. 다음 통제는 별도로 필요합니다.
- 에이전트가 호출할 수 있는 도구와 도메인 allowlist
- 짧은 수명의 토큰과 최소 권한
- 데이터 분류별 키 분리
- 사용자별 작업 범위와 테넌트 격리
- 브라우저·셸·파일 시스템 샌드박스
- 모든 도구 호출과 출력의 감사 로그
- 위험 행동에 대한 사람 승인과 비상 종료
가장 안전한 패턴은 키 브로커가 증명된 이미지에 모델 키를 전달하고, 애플리케이션 정책 엔진이 도구 키를 별도로 발급하는 방식입니다. 모델 키를 받았다는 사실만으로 네트워크·데이터베이스·결제 API 권한까지 얻지 못하게 해야 합니다.
8. Confidential Space와 다자간 분석
Google은 Confidential G4와 함께 Confidential Space 지원이 수 주 안에 정식 제공될 예정이라고 밝혔습니다. Confidential Space는 서로 신뢰하지 않는 여러 조직이 데이터를 공동 분석하거나 모델을 학습하되, 상대방과 인프라 운영자가 원본 데이터를 보지 못하도록 하는 사용 사례를 겨냥합니다.
예를 들어 여러 병원이 환자 데이터를 중앙 저장소로 모으지 않고 공동 위험 예측 모델을 만들려면 다음 조건이 필요합니다.
- 실행 코드와 이미지가 사전에 합의된 해시와 일치해야 합니다.
- 각 기관이 승인한 TEE에서만 데이터 키를 공개해야 합니다.
- 결과가 원본 데이터를 역추론하지 않는지 별도 평가해야 합니다.
- 실행 후 데이터와 임시 키를 폐기했음을 증명해야 합니다.
TEE와 원격 검증은 1번과 2번을 도와주지만, 3번의 통계적 프라이버시나 모델 출력의 안전성을 자동 보장하지는 않습니다. 따라서 Confidential Space를 데이터 보호의 전부로 소개하기보다, 다자간 거버넌스와 출력 검증을 포함한 한 계층으로 보는 편이 정확합니다.
9. 부트 시 검증만으로는 충분하지 않다
MITRE의 2026년 7월 지속적 원격 검증 프레임워크는 기존 Confidential Computing이 주로 부팅 시점의 측정에 의존한다고 지적합니다. 신뢰된 상태로 시작한 워크로드도 런타임에 코드가 바뀌거나, 커널이 공격받거나, 모델이 조작되거나, 데이터가 유출될 수 있기 때문입니다.
이 지적은 G4 도입에도 그대로 적용됩니다.
- 부팅 당시 승인된 컨테이너가 실행 후 취약한 플러그인을 다운로드하지 않았는가?
- 모델 서버가 런타임에 다른 엔드포인트로 프롬프트를 전송하지 않았는가?
- GPU 커널과 드라이버가 정책에 맞는 상태로 유지되는가?
- 로그·메트릭 에이전트가 민감정보를 외부로 보내지 않는가?
- 배포 중 교체된 노드가 같은 검증 정책을 통과했는가?
따라서 키 발급을 한 번의 부팅 확인으로 끝내지 말고, 장기 실행 에이전트와 모델 서버에는 주기적인 상태 확인, 이미지 불변성, 네트워크 정책, 이상행동 탐지를 결합해야 합니다.
10. 도입 전 체크리스트
- 우리 위협 모델에서 보호해야 할 대상이 모델 가중치인지, 사용자 입력인지, 둘 다인지 정의했는가?
- 호스트 관리자·하이퍼바이저·Kubernetes 관리자·모델 운영자를 각각 어떤 신뢰 경계에 둘 것인가?
- G4가 제공되는 리전·존과 GPU 쿼터·예약 용량을 확인했는가?
- AMD SEV, GPU Confidential Computing, 드라이버, CUDA 버전의 조합을 고정했는가?
- NVIDIA Confidential Computing 라이선스 비용을 예산에 반영했는가?
- 승인된 VM·컨테이너 이미지와 GPU 펌웨어 기준값을 관리하는가?
- 키 브로커가 검증 증거와 정책 조건을 모두 확인한 뒤에만 모델 키를 전달하는가?
- 모델·프롬프트·출력·도구 토큰이 로그와 트레이싱 시스템에 평문으로 남지 않는가?
- PCIe, NVLink, RDMA, 객체 저장소, 네트워크 경로의 보호 상태를 문서화했는가?
- 벤더가 제시한 처리량과 우리 모델의 첫 토큰 시간·종단간 지연을 같은 조건에서 재현했는가?
- 부팅 이후의 코드 변경·드라이버 상태·에이전트 행동을 지속적으로 검증하는가?
- 검증 실패 시 키를 즉시 폐기하고, 실행 중인 세션과 토큰을 종료할 수 있는가?
교육과 실무에서의 실험 과제
학생이나 플랫폼팀은 실제 개인정보 없이 다음 실험을 수행할 수 있습니다.
- 합성 고객 데이터와 테스트용 모델을 암호화된 객체 저장소에 둡니다.
- 승인된 이미지와 변조된 이미지를 각각 Confidential VM에서 실행합니다.
- 키 브로커가 승인된 측정값에만 모델 키를 발급하는지 확인합니다.
- 드라이버 버전, 보안 모드, 이미지 해시를 바꿔 검증 실패를 재현합니다.
- 프롬프트와 출력이 VM·GPU·로그 경계를 통과할 때 어디에서 암호화가 풀리는지 기록합니다.
- 실행 중인 에이전트가 허용되지 않은 도메인으로 나가려 할 때 네트워크 정책이 차단하는지 확인합니다.
- 부팅 후 플러그인을 바꾸고 지속적 검증이 이를 탐지하는지 측정합니다.
- 마지막으로 검증 증거, 키 발급 이벤트, 도구 호출을 하나의 타임라인으로 재구성합니다.
이 실험의 성공 기준은 “TEE에서 모델이 실행됐다”가 아닙니다. 누가 어떤 증거를 확인했고, 어떤 키가 어느 시점에 발급됐으며, 실패 후 어떤 데이터가 남았는지를 설명할 수 있어야 합니다.
한계와 결론
Confidential G4는 AI 인프라의 중요한 신뢰 경계를 GPU 실행 단계까지 확장했다는 점에서 의미가 있습니다. Google은 36개 존, GKE와 Compute Engine 지원, 표준 이미지 사용, 3.5% 미만 처리량 저하라는 현실적인 도입 조건을 제시했습니다. 민감한 데이터를 클라우드 GPU에서 처리해야 하는 조직에는 기존의 “저장·전송 암호화”만으로 부족했던 공백을 줄일 수 있는 선택지입니다.
그러나 다음 사실은 변하지 않습니다.
- 원격 검증은 승인된 구성과 측정값을 증명하지, 승인된 코드에 취약점이 없음을 증명하지 않습니다.
- GPU 메모리 보호는 네트워크·스토리지·로그·애플리케이션 권한을 자동으로 보호하지 않습니다.
- G4의 보호 범위는 VM, GPU, 드라이버, 통신 경로와 정책 설정의 실제 조합에 달려 있습니다.
- 부팅 시점 검증만으로는 장기 실행 에이전트와 런타임 변조를 충분히 다루기 어렵습니다.
- 사용자의 입력을 모델 운영자나 애플리케이션이 의도적으로 수집하는 문제는 TEE 밖의 거버넌스 영역입니다.
따라서 도입 순서는 “비밀 데이터를 곧바로 올리기”가 아니라 다음과 같아야 합니다.
- 보호 대상과 신뢰하지 않을 운영자를 먼저 정의합니다.
- 이미지·드라이버·GPU·키 브로커의 검증 정책을 고정합니다.
- 검증된 워크로드에만 모델과 데이터 키를 전달합니다.
- 데이터가 통과하는 모든 경로의 암호화와 로그를 확인합니다.
- 성능·비용·검증 실패·런타임 이상행동을 함께 측정합니다.
- 지속적 검증과 즉시 키 폐기 절차를 반복 훈련합니다.
Confidential G4의 핵심은 “GPU를 암호화한다”는 한 문장이 아닙니다. 클라우드에서 실행 중인 AI가 어느 하드웨어와 소프트웨어에서, 누구의 정책을 통과해, 어떤 증거를 남기며 실행됐는지를 검증 가능한 사실로 바꾸는 데 있습니다. 그 사실을 키 발급·에이전트 권한·감사 로그와 연결할 때 비로소 하드웨어 보안이 운영 가능한 AI 신뢰로 이어집니다.
참고 자료
- Google Cloud Blog: Hardware-backed security at global scale: Confidential G4 with NVIDIA Blackwell is GA (2026-10-21)
- Google Cloud Documentation: Create a Confidential VM instance with GPU
- Google Cloud: Confidential Computing
- NVIDIA Confidential Computing Overview
- NVIDIA Trust and Threat Model
- MITRE: Framework for Continuous Remote Attestation