기업이 생성형 AI와 머신러닝을 실제 업무에 적용할수록 가장 어려운 질문은 모델의 성능이 아니라 데이터의 신뢰 경계가 됩니다. 의료 기록, 금융 거래, 설비 도면, 고객 상담과 계약서를 클라우드 GPU에서 처리하려면 누가 평문 데이터를 볼 수 있는지 설명할 수 있어야 합니다.
대부분의 시스템은 저장된 데이터와 네트워크로 이동하는 데이터를 암호화합니다. 데이터베이스와 오브젝트 스토리지는 암호화되고, API 통신에는 TLS가 적용됩니다. 그러나 CPU나 GPU가 계산하려면 데이터와 모델이 메모리에서 복호화되는 순간이 생깁니다. 운영체제, 하이퍼바이저, 관리자 권한이나 메모리 덤프가 이 구간에 접근할 수 있다면 암호화의 빈틈이 남습니다.
Confidential Computing은 이 ‘사용 중 데이터(data in use)’를 보호하기 위한 접근입니다. Confidential Computing Consortium의 정의에 따르면 하드웨어 기반이며 증명 가능한 Trusted Execution Environment, 즉 TEE 안에서 계산해 사용 중인 데이터와 코드를 격리합니다. 핵심은 단순한 메모리 암호화가 아니라 실행 환경을 격리하고, 예상한 코드가 예상한 환경에서 실행 중임을 원격으로 증명한 뒤에만 비밀을 제공하는 것입니다.
데이터 보호의 세 번째 구간
데이터 보안은 세 상태로 나눠 생각할 수 있습니다.
| 상태 | 대표 보호 방식 | 남는 위험 |
|---|---|---|
| 저장 중 | 디스크·DB·오브젝트 암호화, KMS | 복호화 후 처리 구간 |
| 전송 중 | TLS, mTLS, VPN | 종단 시스템 내부의 평문 |
| 사용 중 | TEE, 메모리 암호화, 격리, 원격 증명 | 애플리케이션 로직과 출력 유출 |
Confidential Computing은 기존 암호화를 대체하지 않습니다. 저장·전송·사용 중 보호를 함께 적용해야 합니다. 암호화된 파일이 네트워크를 거쳐 TEE로 들어오고, TEE 내부에서만 키를 받아 복호화·추론한 뒤 허용된 결과만 내보내는 구조가 기본입니다.
TEE는 무엇을 신뢰하지 않아도 되게 만드는가
일반 VM에서는 클라우드 하이퍼바이저와 호스트 관리자 계층이 게스트 메모리에 영향을 줄 수 있습니다. TEE는 프로세서와 보안 펌웨어가 제공하는 격리와 메모리 암호화를 사용해 호스트 운영체제나 하이퍼바이저가 워크로드의 평문 메모리를 읽기 어렵게 만듭니다.
보호 단위는 제품과 기술에 따라 다릅니다.
- 프로세스·인클레이브: 애플리케이션의 민감한 일부만 작은 격리 영역에서 실행합니다.
- Confidential VM: 운영체제와 애플리케이션을 포함한 VM 전체의 메모리를 보호해 기존 워크로드 이전이 비교적 쉽습니다.
- Confidential Container: 컨테이너 정책과 이미지 측정을 결합해 오케스트레이션 환경에서 보호 단위를 관리합니다.
- Confidential GPU: CPU TEE와 GPU의 보안 모드·증명을 연결해 모델과 입력, 중간 텐서를 가속기에서도 보호합니다.
선택 기준은 보호하려는 코드의 크기와 운영 복잡성입니다. 작은 인클레이브는 신뢰 기반(Trusted Computing Base)을 줄일 수 있지만 애플리케이션을 분리해 다시 설계해야 합니다. Confidential VM은 기존 시스템을 옮기기 쉽지만 커널과 런타임 등 신뢰해야 할 구성 요소가 더 많습니다.
AI에서는 데이터와 모델을 동시에 보호해야 한다
AI 워크로드에는 두 종류의 핵심 자산이 있습니다. 사용자가 제공하는 프롬프트·문서·특징 데이터와 기업이 투자해 만든 모델 가중치·프롬프트·추론 코드입니다. 데이터 소유자는 클라우드 운영자와 모델 제공자가 원문을 보지 않기를 원하고, 모델 소유자는 데이터 제공자가 모델을 복제하지 않기를 원할 수 있습니다.
TEE는 서로 완전히 신뢰하지 않는 참여자가 보호된 계산 환경만 공동으로 신뢰하게 만드는 기반이 될 수 있습니다. 대표적인 활용은 다음과 같습니다.
- 의료·금융·공공 문서를 외부 인프라에서 분류하거나 요약하는 추론
- 제조사의 설비 데이터와 솔루션사의 모델을 함께 사용하는 예지보전
- 여러 회사의 원본 데이터를 서로 공개하지 않고 수행하는 공동 분석
- 독점 모델 가중치를 고객 환경에 배포하되 평문 노출을 줄이는 서비스
- 민감한 RAG 문서와 벡터를 보호된 환경에서 검색·재순위화·생성하는 구조
다만 TEE가 모델의 답변 자체를 안전하게 만들지는 않습니다. 모델이 프롬프트 인젝션을 따르거나 개인정보를 출력한다면 하드웨어 격리 안에서도 데이터가 정상 출력 경로로 유출될 수 있습니다. TEE는 실행 환경을 보호하고, 애플리케이션 보안은 입력·도구·출력 정책이 담당합니다.
원격 증명은 ‘자물쇠가 있다’가 아니라 ‘올바른 방인가’를 확인한다
서버가 “저는 TEE에서 실행 중입니다”라고 말하는 것만으로는 신뢰할 수 없습니다. 원격 증명(Remote Attestation)은 하드웨어와 보안 펌웨어가 실행 환경의 측정값과 상태를 서명된 증거로 만들고, 외부 검증자가 정책과 비교하는 절차입니다.
일반적인 흐름은 다음과 같습니다.
- 보안 부팅 과정에서 펌웨어, 부트로더, 커널, 컨테이너 이미지와 애플리케이션을 암호학적으로 측정합니다.
- TEE가 측정값, 플랫폼 정보, 임시 공개키와 nonce를 포함한 증명 증거를 생성합니다.
- 검증 서비스가 제조사의 보증 정보와 조직의 승인 정책을 이용해 증거를 평가합니다.
- 검증에 성공하면 서명된 증명 결과 또는 토큰을 발급합니다.
- KMS나 Secret Manager는 토큰과 정책을 확인한 뒤 해당 TEE의 키에만 짧은 수명의 비밀을 전달합니다.
- 워크로드는 TEE 내부에서 데이터와 모델을 복호화하고 추론합니다.
이 구조의 중요한 성질은 키를 먼저 주고 환경을 믿는 것이 아니라, 환경을 증명한 뒤에만 키를 주는 것입니다. 이미지가 변경되거나 디버그 모드로 실행되거나 허용되지 않은 구성이면 키가 해제되지 않아야 합니다.
증명 토큰을 확인하는 것만으로 끝나지 않는다
증명은 암호 검증과 정책 판단이 결합된 과정입니다. 서명이 유효해도 측정값이 회사가 승인한 버전인지, 보안 패치 수준이 충분한지, 디버그 기능이 꺼져 있는지 확인해야 합니다.
정책에는 보통 다음 조건이 들어갑니다.
- 허용된 CPU·GPU TEE 종류와 보안 기능
- 승인된 펌웨어와 마이크로코드 최소 버전
- 운영체제·컨테이너·애플리케이션 이미지 측정값
- 모델과 추론 서버의 서명자 또는 공급망 출처
- Secure Boot와 디버그 모드 상태
- 테넌트, 리전, 네트워크와 서비스 계정 조건
- 증명의 발급 시각, 만료와 nonce 일치 여부
증명 결과를 무기한 캐시하면 이후 환경이 바뀌어도 키를 계속 사용할 수 있습니다. 키를 짧게 유지하고 주기적으로 재증명하며, 취약점이 발견되면 정책에서 해당 펌웨어나 이미지 측정값을 즉시 거부할 수 있어야 합니다.
정책 기반 키 해제가 신뢰의 중심이다
TEE가 있어도 애플리케이션이 시작할 때 환경 변수로 장기 키를 받는다면 보호 효과가 줄어듭니다. 핵심 비밀은 KMS에 두고 유효한 증명과 워크로드 신원, 데이터 사용 정책을 동시에 만족할 때만 해제해야 합니다.
예를 들어 다음 조건을 하나의 정책으로 묶을 수 있습니다.
- 승인된 추론 이미지 해시에서 실행 중이다.
- Confidential GPU와 CPU TEE 증명이 모두 유효하다.
- 요청한 서비스 계정이 해당 고객·모델 조합에 허가돼 있다.
- 데이터 처리 리전과 보존 정책을 만족한다.
- 사람이 승인한 모델 버전과 출력 필터 정책을 사용한다.
조건을 통과하면 데이터 키와 모델 키를 각각 전달하고, 사용이 끝나면 메모리에서 제거합니다. 데이터와 모델 소유자가 다른 경우 서로 다른 KMS와 정책을 사용해 양쪽이 동의한 환경에서만 두 키가 함께 해제되도록 설계할 수 있습니다.
Confidential GPU가 필요한 이유
대규모 모델 추론은 CPU만으로 처리하기 어렵습니다. CPU 메모리가 보호돼도 데이터를 일반 GPU로 보내는 순간 PCIe 전송과 GPU 메모리, 드라이버가 새로운 신뢰 경계가 됩니다. Confidential GPU는 GPU 메모리와 전송 경로를 보호하고 GPU 장치와 드라이버 상태를 증명해 이 경계를 확장합니다.
Azure는 AMD SEV-SNP 기반 Confidential VM과 NVIDIA H100 GPU를 연결한 confidential GPU VM을 제공하며, Google Cloud 문서도 CPU와 GPU 드라이버·장치 증명을 별도로 다룹니다. 실제 설계에서는 “Confidential VM을 사용한다”는 사실만 확인하지 말고 CPU TEE에서 GPU까지의 종단 보호와 증명 연결을 확인해야 합니다.
또한 모든 모델과 프레임워크가 동일하게 지원되는 것은 아닙니다. 드라이버, 커널, 컨테이너 이미지와 GPU 기능의 호환성, 리전과 인스턴스 가용성, 확장 방식과 비용을 PoC에서 검증해야 합니다.
보호된 AI 추론의 권장 데이터 흐름
- 클라이언트는 요청마다 데이터 키를 만들고 입력을 암호화합니다.
- 오케스트레이터는 원문 대신 암호문과 작업 메타데이터만 전달합니다.
- 추론 워크로드는 시작 시 CPU·GPU와 애플리케이션 상태를 증명합니다.
- 검증자는 증거를 승인 정책과 비교하고 짧은 수명의 결과 토큰을 발급합니다.
- KMS는 토큰, 워크로드 신원과 업무 권한을 검사해 TEE에만 키를 전달합니다.
- TEE 내부에서 입력과 모델을 복호화하고 추론한 뒤 원문과 중간 텐서를 제거합니다.
- 출력 정책이 민감정보, 최소 집단 크기, 허용 형식과 사용 목적을 검사합니다.
- 결과를 클라이언트 키로 암호화하고 외부에는 최소 메타데이터만 남깁니다.
관측성 데이터도 민감할 수 있습니다. 프롬프트와 응답을 평문 로그에 남기면 TEE 밖으로 데이터가 다시 유출됩니다. 로그에는 요청 ID, 모델 버전, 정책 결과, 지연시간과 오류 코드만 남기고 내용은 별도 보호 저장소에 암호화해 보관해야 합니다.
Confidential Computing이 해결하지 않는 것
애플리케이션 취약점
TEE 안의 코드에 SQL 인젝션, 원격 코드 실행이나 권한 검사가 빠져 있다면 공격자는 정상 인터페이스를 통해 데이터를 빼낼 수 있습니다. 격리된 환경도 내부 코드가 허용한 행동은 막지 못합니다.
출력과 추론 공격
모델의 출력으로 개인정보가 노출되거나 반복 질의를 통해 학습 데이터를 추론하는 공격은 별도 문제입니다. 출력 필터, 속도 제한, 집계 기준과 프라이버시 보호가 필요합니다.
사이드 채널
실행 시간, 캐시, 메모리 접근과 자원 사용 패턴을 관찰해 정보를 추정하는 공격이 존재합니다. 사용하는 TEE의 알려진 취약점과 보안 권고를 추적하고, 위협 수준에 맞는 완화책을 적용해야 합니다.
가용성과 서비스 거부
TEE는 호스트가 데이터를 읽지 못하게 할 수 있지만 호스트가 VM을 중지하거나 네트워크를 차단하는 것까지 막지는 못합니다. 고가용성, 재시도와 재해복구는 기존 분산 시스템 설계가 담당합니다.
공급망과 잘못된 기준값
서명된 이미지 자체가 악성이라면 증명은 악성 코드가 정확히 실행 중이라는 사실만 확인해줍니다. 빌드 파이프라인, SBOM, 코드 서명과 승인된 측정값 등록 절차가 함께 필요합니다.
성능과 운영 복잡성도 계산해야 한다
메모리 암호화와 격리, 증명, 제한된 입출력 경로에는 비용이 있습니다. 워크로드에 따라 성능 영향이 작을 수도 있지만 메모리 집약도, I/O 패턴, GPU 통신과 인클레이브 전환에 따라 달라집니다. 실제 모델과 입력 크기로 지연시간과 처리량을 측정해야 합니다.
디버깅도 어려워집니다. 관리자와 APM 에이전트가 메모리를 들여다볼 수 없고, 디버그 모드를 켜면 유효한 증명을 받지 못할 수 있습니다. 구조화된 보안 로그, 테스트용 비민감 데이터, 재현 가능한 빌드와 단계별 측정값 비교를 준비해야 합니다.
특수 인스턴스의 리전·수량 제한, 이미지 지원, 자동 확장과 장애 복구 방식도 일반 VM과 다를 수 있습니다. 보안팀만의 PoC가 아니라 플랫폼·데이터·AI·운영팀이 함께 서비스 수준을 검증해야 합니다.
어떤 경우에 도입 가치가 큰가
다음 조건이 여러 개 겹치면 Confidential Computing의 가치가 큽니다.
- 클라우드 운영자와 인프라 관리자까지 신뢰 범위에서 줄여야 한다.
- 규제 데이터나 핵심 설계·모델을 외부 인프라에서 처리해야 한다.
- 서로 신뢰하지 않는 여러 조직이 원본을 공개하지 않고 계산해야 한다.
- 비밀 키를 특정 코드와 하드웨어 상태에만 해제해야 한다.
- 실행 환경의 무결성을 제3자에게 암호학적으로 증명해야 한다.
반대로 일반 접근 통제와 저장·전송 암호화로 위협을 충분히 줄일 수 있고, 데이터가 이미 비식별화돼 있으며, 운영 복잡성이 보호 가치보다 크다면 우선순위가 낮을 수 있습니다. 기술의 최신성보다 위협 모델과 자산 가치로 판단해야 합니다.
작게 검증하는 도입 순서
- 보호 자산과 공격자를 정의합니다. 데이터, 모델, 코드, 키 가운데 무엇을 누구로부터 보호할지 적습니다.
- 신뢰 기반을 그립니다. CPU·GPU, 펌웨어, 커널, 런타임, 모델 서버와 검증 서비스를 포함합니다.
- 작은 추론 구간을 선택합니다. 민감 입력이 들어오고 작은 결과가 나오는 경계가 명확한 업무가 좋습니다.
- 재현 가능한 이미지를 만듭니다. 서명된 빌드와 SBOM, 승인 측정값 등록 절차를 마련합니다.
- 증명 기반 키 해제를 구현합니다. 실패·만료·재생·디버그·변조된 이미지가 거부되는지 시험합니다.
- 실제 성능을 비교합니다. 일반 환경 대비 처리량, 지연시간, 비용과 확장 시간을 측정합니다.
- 출력과 로그 경계를 점검합니다. TEE 밖으로 나가는 모든 데이터에 별도 정책을 적용합니다.
- 취약점 대응을 운영화합니다. 기준값 폐기, 키 회수, 이미지 교체와 재증명 절차를 자동화합니다.
신뢰를 선언하지 말고 증명 가능한 정책으로 만든다
기업 AI에서 “데이터는 안전하게 처리됩니다”라는 문구만으로는 충분하지 않습니다. 어느 코드와 모델이 어떤 하드웨어에서 실행됐고, 누가 그 상태를 검증했으며, 어떤 조건에서 키가 해제됐는지를 기술적으로 설명할 수 있어야 합니다.
Confidential Computing은 클라우드, 플랫폼 관리자, 다른 테넌트와 공급자에 대한 신뢰를 줄이는 강력한 도구입니다. 그러나 애플리케이션 취약점, 모델 출력, 공급망과 가용성까지 해결하는 만능 보호막은 아닙니다. 기존 IAM, 네트워크 보안, 데이터 최소화, 모델 안전성과 함께 계층적으로 사용해야 합니다.
핵심 설계 원칙은 간단합니다. 민감한 데이터와 모델은 증명된 실행 환경 밖에서 평문이 되지 않게 하고, 비밀 키는 코드·플랫폼·사용 목적이 정책을 만족할 때만 짧게 제공하며, 결과는 다시 최소화하고 암호화한다. 이 흐름이 갖춰질 때 Confidential AI는 마케팅 용어가 아니라 검증 가능한 보안 아키텍처가 됩니다.
