데이터를 암호화해 Cloud에 저장하고, TLS로 안전하게 전송했습니다. 그런데 애플리케이션이 데이터를 읽어 연산하는 순간, 메모리에서는 평문으로 복호화됩니다. 그렇다면 그 데이터는 정말 끝까지 보호되고 있는 것일까요?
바로 이 질문에서 기밀 컴퓨팅(Confidential Computing)의 필요성이 시작됩니다.
기존 Cloud 보안은 크게 두 영역에 집중해 왔습니다.
- 저장 중 데이터(At Rest): 디스크, 데이터베이스, 오브젝트 스토리지에 저장된 데이터를 암호화
- 전송 중 데이터(In Transit): 사용자와 서버, 서비스 간 통신을 TLS 등으로 암호화
하지만 실제 업무 처리는 데이터가 반드시 메모리에 올라와 계산되는 과정에서 이뤄집니다. 즉, 데이터는 사용 중(In Use) 상태에서 평문이 될 수밖에 없습니다. 이 구간은 운영체제, 하이퍼바이저, 관리자 권한, 메모리 덤프, 악성코드 침입 등 여러 위험과 맞닿아 있습니다.
특히 Cloud 환경은 여러 고객이 동일한 물리 인프라를 공유하는 멀티테넌트 구조입니다. 일반적인 접근 제어와 암호화는 매우 중요하지만, 규제가 엄격한 산업에서는 한 단계 더 강한 질문이 등장합니다.
“클라우드 제공자의 운영자나 인프라 관리 권한을 가진 사람도 우리 데이터를 볼 수 없도록 만들 수 있는가?”
이 요구를 현실로 옮기는 기술이 바로 기밀 컴퓨팅입니다. 기밀 컴퓨팅은 CPU 내부의 TEE(Trusted Execution Environment, 신뢰 실행 환경)를 활용해 민감한 코드와 데이터를 격리된 영역에서 실행합니다. 이 영역에서는 데이터가 연산을 위해 복호화되더라도, 일반 운영체제나 하이퍼바이저, 다른 가상 머신이 그 내용을 직접 읽을 수 없습니다.
쉽게 말해 기존 보안이 “문을 잠그고 안전하게 운반하는 방식”이었다면, 기밀 컴퓨팅은 데이터를 처리하는 작업실 자체를 외부에서 들여다볼 수 없는 공간으로 만드는 방식입니다.
이 변화는 금융, 의료, 공공기관뿐 아니라 생성형 AI를 도입하는 기업에도 중요합니다. 고객 정보, 내부 문서, 소스코드, 모델 파라미터, 프롬프트처럼 외부 노출이 치명적인 데이터를 Cloud에서 활용하려면, 저장과 전송을 넘어 연산 중인 데이터까지 보호하는 구조가 필요하기 때문입니다.
결국 오늘날 Cloud 보안의 핵심은 “누가 접근할 수 있는가”를 넘어섭니다. 이제는 더 근본적으로, 권한이 있더라도 데이터를 볼 수 없게 만들 수 있는가가 경쟁력이 되고 있습니다.
Cloud 보안의 사각지대, 실행 중인 데이터를 지키는 Confidential Computing
데이터는 저장할 때 암호화하고, 네트워크로 이동할 때도 TLS로 보호합니다. 그런데 데이터가 실행되는 순간, 즉 애플리케이션이 데이터를 복호화해 계산하고 처리하는 순간에는 어떻게 될까요?
이때 데이터는 메모리 위에 평문으로 존재할 수 있습니다. 전통적인 Cloud 보안 체계에서는 운영체제, 하이퍼바이저, 고권한 관리자 계정, 침해된 호스트 환경 등이 이 실행 중 데이터에 접근할 위험이 남습니다. 저장 데이터와 전송 데이터의 암호화만으로는 완전히 닫히지 않는 마지막 빈틈입니다.
이 빈틈을 메우기 위해 등장한 기술이 Confidential Computing(기밀 컴퓨팅)입니다.
암호화는 왜 실행 순간에 약해질까?
일반적인 보안 모델은 데이터를 크게 두 상태로 나눠 보호합니다.
- 저장 데이터(At Rest): 디스크, 데이터베이스, 백업 파일에 저장된 데이터
- 전송 데이터(In Transit): 사용자와 서버, 서버와 서버 사이를 이동하는 데이터
하지만 서비스가 실제로 요청을 처리하려면 데이터는 결국 메모리에서 복호화되어야 합니다. 예를 들어 Cloud 환경에서 고객의 주민번호, 결제 정보, 의료 기록, AI 프롬프트를 분석하려면 애플리케이션이 해당 값을 읽고 연산해야 합니다.
바로 이 사용 중 데이터(In Use)가 핵심 문제입니다.
저장소의 암호화된 데이터
↓ 복호화
애플리케이션 메모리에서 처리
↓
연산 결과 반환
기존 환경에서는 메모리에 올라온 민감 데이터가 운영체제나 하이퍼바이저 같은 고권한 계층에 노출될 가능성을 완전히 배제하기 어려웠습니다. Cloud 제공자의 운영 인력, 악성 관리자 계정, 호스트 침해 사고까지 위협 모델에 포함하면 더욱 그렇습니다.
Confidential Computing은 이 실행 구간을 별도의 보호 영역으로 만들고, 데이터가 처리되는 중에도 기밀성을 유지하도록 설계합니다.
TEE: 실행 중인 데이터를 위한 하드웨어 금고
기밀 컴퓨팅의 중심에는 TEE(Trusted Execution Environment, 신뢰 실행 환경)가 있습니다. TEE는 CPU 또는 가속기 내부에 마련되는 하드웨어 기반의 격리 공간입니다.
이 공간에서는 코드와 데이터가 일반 실행 영역과 분리되어 처리됩니다. 중요한 점은 단순한 소프트웨어 권한 관리가 아니라, 하드웨어가 직접 접근을 제한한다는 것입니다.
TEE는 일반적으로 다음 기능을 제공합니다.
- 메모리 암호화: 실행 중인 데이터를 메모리 수준에서 암호화합니다.
- 강제 격리: 다른 프로세스, 운영체제, 하이퍼바이저가 보호 영역의 메모리를 읽거나 수정하지 못하도록 차단합니다.
- 무결성 보호: 실행 코드나 데이터가 변조되지 않았는지 확인합니다.
- 원격 검증(Attestation): 외부 사용자가 신뢰할 수 있는 하드웨어와 승인된 코드가 실제로 실행 중인지 암호학적으로 확인할 수 있게 합니다.
쉽게 말하면 TEE는 Cloud 서버 안에 만들어지는 “운영자조차 열어볼 수 없는 실행 금고”에 가깝습니다. 민감한 데이터와 핵심 로직은 이 금고 안에서만 처리되고, 필요한 결과만 외부로 전달됩니다.
Enclave는 무엇이 다른가?
TEE 내부에는 보통 Enclave(엔클레이브)라는 격리 실행 공간이 생성됩니다. 모든 애플리케이션을 통째로 넣기보다, 암호 키 처리나 개인정보 분석처럼 특히 민감한 기능만 엔클레이브로 분리하는 방식이 일반적입니다.
예를 들어 금융 서비스의 신용평가 API를 생각해 볼 수 있습니다.
사용자 요청
↓
일반 웹/API 서버
↓
Enclave 내부의 신용평가 로직
├─ 고객 데이터 복호화
├─ 위험도 계산
└─ 결과 생성
↓
점수 또는 승인 결과만 외부 반환
이 구조에서 일반 웹 서버는 요청을 받고 결과를 반환할 수 있습니다. 그러나 고객의 원본 데이터, 복호화 키, 평가 알고리즘의 핵심 로직은 엔클레이브 밖으로 나오지 않습니다.
따라서 Cloud 운영 환경의 관리자 권한이 탈취되더라도, 공격자가 엔클레이브 내부의 평문 데이터나 비밀 키를 곧바로 읽는 것은 훨씬 어려워집니다.
원격 검증이 신뢰를 완성한다
TEE만으로는 충분하지 않습니다. 고객 입장에서는 “정말 올바른 Cloud 환경에서, 변조되지 않은 코드가 실행되고 있는가?”를 확인할 방법이 필요합니다. 이 역할을 하는 것이 원격 검증(Remote Attestation)입니다.
원격 검증은 실행 환경이 생성한 암호학적 증명서를 바탕으로 다음 사항을 확인하는 절차입니다.
- 요청한 TEE 하드웨어가 실제로 사용되고 있는가
- 승인된 버전의 애플리케이션 코드가 실행 중인가
- 부팅 설정이나 보안 정책이 기대한 상태와 일치하는가
- 검증된 환경에만 암호화 키를 전달할 수 있는가
이 흐름은 키 관리 시스템(KMS)과 결합될 때 더욱 강력해집니다. KMS는 검증 결과가 정책에 맞을 때만 복호화 키를 제공하도록 구성할 수 있습니다.
즉, 코드가 변조되었거나 승인되지 않은 환경에서 실행되면 키를 받을 수 없습니다. 키가 없으면 민감 데이터도 복호화할 수 없습니다. 이는 단순히 “접근을 금지하는” 수준을 넘어, 신뢰 조건이 충족되지 않으면 데이터 자체를 사용할 수 없게 만드는 구조입니다.
Cloud 환경에서 특히 중요한 이유
Cloud는 여러 고객이 물리 인프라를 공유하는 멀티테넌트 환경입니다. 가상화, IAM, 네트워크 분리, 암호화는 이미 강력한 보안 수단이지만, 기밀 컴퓨팅은 여기서 한 단계 더 나아갑니다.
기존 보안이 “누가 접근할 수 있는가”를 통제했다면, Confidential Computing은 다음과 같은 질문에 답합니다.
접근 권한이 매우 높은 운영자나 인프라 계층조차도 데이터를 볼 수 없게 만들 수 있는가?
이 질문은 특히 다음과 같은 워크로드에서 중요합니다.
- 고객 프롬프트와 사내 문서를 다루는 생성형 AI 서비스
- 금융 거래, 신용평가, 부정거래 탐지 시스템
- 병원·연구기관 간 의료 데이터 공동 분석
- 기업 간 원본 데이터를 공개하지 않는 데이터 협업
- 소스코드, 암호 키, 모델 파라미터를 처리하는 B2B SaaS
Confidential Computing은 모든 보안 문제를 해결하는 만능 기술은 아닙니다. 애플리케이션 취약점, 잘못된 IAM 정책, 입력값 공격, 데이터 유출형 로그 같은 문제는 여전히 별도로 관리해야 합니다. 또한 성능 오버헤드와 제한된 디버깅 환경도 설계 단계에서 고려해야 합니다.
그럼에도 TEE와 원격 검증은 Cloud 보안의 신뢰 경계를 하드웨어 수준까지 확장합니다. 데이터가 저장될 때와 이동할 때뿐 아니라, 가장 민감한 실행 순간까지 보호한다는 점에서 Confidential Computing은 암호화의 마지막 빈틈을 닫는 핵심 기술로 주목받고 있습니다.
Cloud 기밀 컴퓨팅: 키를 받지 못하면 데이터도 열 수 없다
기밀 VM 안의 코드가 단 한 줄이라도 변조되었다면 어떻게 될까요?
정답은 간단합니다. 원격 검증(Remote Attestation)에 실패하고, 암호화 키를 받지 못합니다. 키가 없다면 데이터는 복호화할 수 없고, 민감한 연산도 시작할 수 없습니다.
이것이 Cloud 환경에서 기밀 컴퓨팅이 기존 암호화와 차별화되는 핵심입니다. 단순히 데이터를 암호화해 저장하는 데 그치지 않고, 검증된 실행 환경에서만 키와 데이터 접근을 허용합니다.
원격 검증은 무엇을 확인할까?
원격 검증은 클라이언트나 키 관리 시스템이 기밀 VM에 다음과 같은 질문을 던지는 과정입니다.
- 지금 실행 중인 환경이 신뢰할 수 있는 TEE인가?
- 승인된 하드웨어와 보안 설정으로 부팅되었는가?
- 운영체제, 부트 체인, 애플리케이션 코드가 기대한 값과 일치하는가?
- 알려진 취약 설정이나 변조 흔적은 없는가?
기밀 VM은 이 질문에 대해 하드웨어 기반의 증명 정보(attestation evidence) 를 생성합니다. 여기에는 보통 실행 환경의 측정값, 코드 해시, 보안 정책 정보 등이 포함됩니다.
키 관리 서비스(KMS) 또는 고객의 검증 시스템은 이 증명 정보를 확인합니다. 검증 결과가 정책과 일치할 때만 데이터 암호화 키를 해당 VM에 전달합니다.
신뢰할 수 있는 환경임이 증명되기 전까지는, 키도 전달하지 않는다.
코드 해시가 달라지면 어떤 일이 벌어질까?
예를 들어 금융 데이터를 분석하는 Cloud 애플리케이션이 있다고 가정해 보겠습니다. 정상 코드의 해시값은 사전에 등록되어 있으며, 키 관리 시스템은 이 값과 일치하는 기밀 VM에만 복호화 키를 제공하도록 설정됩니다.
그런데 누군가 애플리케이션에 단 한 줄의 코드를 추가했습니다. 외부로 데이터를 전송하는 코드일 수도 있고, 디버그 로그를 남기는 코드일 수도 있습니다.
코드가 조금만 달라져도 측정값은 변경됩니다. 그 결과는 명확합니다.
- 기밀 VM이 원격 검증 정보를 생성합니다.
- KMS가 등록된 정책과 현재 측정값을 비교합니다.
- 코드 해시 불일치를 감지합니다.
- 검증이 거부됩니다.
- 복호화 키가 전달되지 않습니다.
- 암호화된 데이터는 열리지 않습니다.
즉, 공격자가 VM을 장악했더라도 민감 데이터에 접근하기 위한 키를 얻지 못하면 실질적인 공격은 훨씬 어려워집니다.
Cloud KMS와 결합될 때 강해지는 보안 구조
기밀 컴퓨팅은 TEE만으로 완성되지 않습니다. 강력한 구조는 보통 TEE, 원격 검증, KMS, 최소 권한 정책이 함께 작동할 때 만들어집니다.
일반적인 흐름은 다음과 같습니다.
기밀 VM 부팅
↓
TEE가 코드·환경 측정값 생성
↓
원격 검증 서비스 또는 KMS에 증명 정보 제출
↓
정책 검증: 승인된 하드웨어·코드·설정인가?
↓
검증 성공 시에만 복호화 키 전달
↓
기밀 VM 내부에서만 데이터 복호화 및 연산 수행
이 설계에서는 데이터 암호화 키가 단순히 “권한 있는 사용자”에게 전달되지 않습니다. 정해진 코드가, 정해진 하드웨어 보호 영역에서, 정해진 보안 정책을 만족할 때만 키를 받을 수 있습니다.
운영자 권한만으로는 부족한 이유
전통적인 Cloud 보안 모델에서는 관리자 권한, IAM 권한, 네트워크 접근 제어가 매우 중요합니다. 하지만 높은 권한은 언제든 공격 표면이 될 수 있습니다. 계정 탈취, 잘못된 권한 설정, 내부자 위협은 완전히 사라지지 않습니다.
기밀 컴퓨팅의 키 릴리스 정책은 여기서 한 단계 더 나아갑니다.
- 관리자 권한이 있어도 검증되지 않은 VM에는 키를 주지 않습니다.
- 하이퍼바이저나 호스트 운영체제가 데이터를 읽으려 해도 메모리는 보호됩니다.
- 승인되지 않은 코드로 VM 이미지를 교체하면 키 접근이 차단됩니다.
- 공격자가 데이터를 복사해 가도 키가 없다면 암호문만 확보하게 됩니다.
물론 이것이 모든 보안 위협을 제거하는 것은 아닙니다. 애플리케이션 자체의 취약점, 허용된 코드의 논리 오류, 키 정책의 잘못된 구성은 여전히 관리해야 합니다. 그러나 “검증된 실행 환경에만 키를 제공한다”는 원칙은 공격 성공에 필요한 조건을 크게 늘립니다.
설계할 때 반드시 정해야 할 정책
기밀 Cloud 워크로드를 설계할 때는 “무엇을 암호화할 것인가”만큼 “어떤 조건에서 키를 풀어줄 것인가”가 중요합니다.
특히 다음 항목을 명확히 정의해야 합니다.
- 허용할 VM 이미지와 애플리케이션 코드의 측정값
- 허용할 TEE 하드웨어 및 Cloud 리전
- 운영체제·커널·부트 체인 버전 정책
- 키의 사용 기간과 자동 폐기·교체 기준
- 검증 실패 시 서비스가 처리할 방식
- 장애 대응을 위한 승인 절차와 감사 로그 정책
핵심은 단순합니다. 민감 데이터의 키는 사람이 편하게 꺼내 쓰는 자산이 아니라, 신뢰가 증명된 실행 환경에 조건부로 전달되는 자산이어야 합니다.
기밀 컴퓨팅은 바로 이 원칙을 하드웨어와 암호학으로 구현합니다. 코드가 변조되었다면, 키는 오지 않습니다. 그리고 키가 없다면 데이터는 열리지 않습니다.
AI와 경쟁 기업이 서로의 데이터를 보지 않고 협업하는 법: Cloud 기밀 컴퓨팅
서로 믿지 못하는 병원들이 환자 원본 데이터를 공개하지 않은 채 공동 연구를 할 수 있을까요? 경쟁 관계의 금융사가 사기 탐지 모델을 함께 고도화하면서도 고객 거래 내역을 숨길 수 있을까요? 또 기업은 내부 프롬프트와 자체 LLM 모델을 외부 Cloud 환경에서 안전하게 운영할 수 있을까요?
기밀 컴퓨팅(Confidential Computing)은 이 질문에 현실적인 답을 제시합니다. 핵심은 데이터를 단순히 저장하거나 전송할 때만 암호화하는 것이 아니라, 실행 중인 데이터까지 보호하는 것입니다.
신뢰할 수 없는 참여자 사이에 만드는 신뢰 구역
기존 협업 구조에서는 참여 기관이 데이터를 한곳에 모아야 분석이 가능했습니다. 하지만 환자 정보, 금융 거래 기록, 기업 기밀은 쉽게 외부로 옮길 수 없습니다. 법적 규제와 경쟁 관계, 유출 위험이 모두 걸림돌이 됩니다.
기밀 컴퓨팅은 Cloud 인프라의 하드웨어 기반 격리 영역인 TEE(Trusted Execution Environment) 안에서 데이터를 처리합니다. 이 환경에서는 다음과 같은 원칙이 적용됩니다.
- 원본 데이터는 TEE 내부에서만 복호화되고 연산됩니다.
- 클라우드 운영자, 호스트 OS, 하이퍼바이저는 데이터의 평문을 볼 수 없습니다.
- 참여 기관은 검증된 코드가 실행되는지 원격 검증(Remote Attestation)으로 확인할 수 있습니다.
- 분석 결과만 외부로 전달하고, 원본 데이터와 암호 키는 보호 구역 밖으로 꺼내지 않습니다.
즉, 참여자들이 서로를 완전히 신뢰하지 않아도 됩니다. 대신 검증 가능한 하드웨어와 변조되지 않은 실행 환경을 신뢰의 기준으로 삼습니다.
병원 공동 연구는 어떻게 달라질까
예를 들어 여러 병원이 희귀 질환의 치료 효과를 분석한다고 가정해 보겠습니다. 각 병원은 환자의 진단 기록, 검사 결과, 투약 이력처럼 민감한 데이터를 보유하고 있습니다. 이를 중앙 서버에 평문으로 모으는 방식은 개인정보 보호 규제와 내부 보안 정책 때문에 현실적으로 어렵습니다.
기밀 컴퓨팅 기반 Cloud 아키텍처에서는 다음과 같은 흐름으로 협업할 수 있습니다.
- 각 병원이 데이터를 자체 키로 암호화합니다.
- 암호화된 데이터만 기밀 분석 환경으로 전송합니다.
- 병원은 원격 검증을 통해 지정한 분석 코드와 TEE 환경이 정상인지 확인합니다.
- 검증이 완료된 환경에만 복호화 키가 전달됩니다.
- TEE 내부에서 통계 분석 또는 머신러닝 학습을 수행합니다.
- 참여자에게는 집계 결과, 모델 성능, 승인된 연구 결과만 제공됩니다.
이 구조에서 A 병원은 B 병원의 환자 원본 데이터를 볼 수 없습니다. Cloud 제공자 역시 데이터 내용을 확인할 수 없습니다. 연구자는 필요한 분석 결과를 얻되, 민감한 개인 정보의 노출 범위는 최소화할 수 있습니다.
기업의 프롬프트와 LLM 모델도 보호할 수 있다
생성형 AI 도입이 확산되면서 기업은 사내 문서, 소스코드, 고객 상담 기록을 LLM에 연결하고 있습니다. 그러나 이때 가장 큰 우려는 명확합니다. “우리의 프롬프트와 데이터, 모델 파라미터를 누가 볼 수 있는가?”
기밀 컴퓨팅을 적용한 Cloud AI 서비스에서는 민감한 AI 처리 과정을 보호 구역으로 옮길 수 있습니다.
- 고객의 프롬프트와 첨부 문서를 TEE 내부에서만 처리
- 벡터 데이터베이스 검색 결과를 보호된 메모리에서 결합
- 기업 고유의 모델 가중치와 시스템 프롬프트를 격리
- 추론 결과만 정책에 따라 외부 애플리케이션으로 반환
- 원격 검증을 통과한 워크로드에만 모델 키와 데이터 키 제공
이를 통해 AI 서비스 제공자는 고객 데이터가 일반 운영 환경이나 다른 테넌트에 노출되지 않도록 설계할 수 있습니다. 특히 법률, 의료, 금융, 제조처럼 데이터의 기밀성이 경쟁력과 직결되는 산업에서 중요한 기반이 됩니다.
기술의 핵심은 원격 검증과 키 통제다
TEE만 만든다고 보안이 완성되는 것은 아닙니다. 실제 신뢰는 원격 검증과 키 관리의 결합에서 만들어집니다.
원격 검증은 실행 환경이 특정 하드웨어에서, 승인된 코드 상태로 구동되고 있음을 암호학적으로 증명합니다. 데이터 소유자는 이 증명 정보를 확인한 뒤에만 암호화 키를 전달합니다.
이 방식은 다음과 같은 보안 정책을 가능하게 합니다.
승인된 Cloud 기밀 환경에서, 승인된 애플리케이션 코드가 실행될 때만 데이터를 복호화할 수 있다.
만약 실행 코드가 변경되거나, 허용되지 않은 이미지로 워크로드가 실행되거나, 검증 정책을 충족하지 못하면 키를 받을 수 없습니다. 데이터를 탈취하더라도 복호화할 방법이 없는 구조가 되는 것입니다.
협업의 범위는 넓어지지만, 설계는 더 정교해야 한다
기밀 컴퓨팅은 경쟁 기업 간 데이터 협업의 문을 열어주지만, 모든 문제를 자동으로 해결하지는 않습니다. 특히 다음 항목은 별도로 설계해야 합니다.
- 결과 유출 관리: 집계 결과만 공개해도 특정 개인이나 기업의 정보를 역추론할 가능성이 있는지 검토해야 합니다.
- 접근 권한 정책: 누가 분석을 실행하고, 어떤 결과를 조회하며, 언제 키를 받을 수 있는지 명확히 정의해야 합니다.
- 로그와 모니터링: TEE 내부는 볼 수 없으므로, 민감 정보를 노출하지 않는 감사 로그와 장애 대응 체계가 필요합니다.
- 성능과 비용: 메모리 암호화, 검증, 제한된 디버깅 환경으로 인해 일반 워크로드보다 운영 복잡도와 비용이 증가할 수 있습니다.
- 출력 통제: 모델이 반환하는 결과 자체가 민감 정보를 포함하지 않도록 데이터 마스킹, 차등 프라이버시, 승인 절차를 함께 적용해야 합니다.
결국 기밀 컴퓨팅은 “데이터를 안전하게 숨기는 기술”을 넘어, 데이터를 공개하지 않고도 가치를 교환하게 만드는 Cloud 협업 인프라입니다. AI 시대에 기업과 기관이 경쟁과 협업을 동시에 수행하려면, 신뢰를 계약서가 아니라 검증 가능한 실행 환경으로 옮기는 전략이 필요합니다.
Cloud 보안 옵션을 넘어 새로운 신뢰 모델로
운영자조차 데이터를 볼 수 없게 만들면 보안은 완성될까요? 결론부터 말하면, 아닙니다. 기밀 컴퓨팅은 보안의 종착점이 아니라 새로운 Cloud 설계의 출발점입니다.
기존 클라우드 보안은 IAM, 네트워크 분리, 암호화, 키 관리처럼 “누가 접근할 수 있는가”를 통제하는 데 집중했습니다. 반면 Confidential Computing은 한 단계 더 나아갑니다. 운영체제, 하이퍼바이저, 인프라 운영자처럼 높은 권한을 가진 주체까지 잠재적 위협 모델에 포함하고, 민감 데이터와 코드를 TEE(Trusted Execution Environment) 내부에서만 처리하도록 만듭니다.
이 변화의 핵심은 신뢰의 기준이 바뀐다는 점입니다.
- 과거에는 클라우드 제공자의 운영 절차와 접근 통제를 신뢰해야 했습니다.
- 이제는 검증 가능한 하드웨어 환경과 변조되지 않은 코드를 신뢰합니다.
- 데이터 암호화 키도 단순히 서버에 전달하지 않습니다. 원격 검증(Attestation)을 통해 승인된 TEE 환경임이 확인된 경우에만 키를 전달합니다.
즉, “운영자가 데이터를 보지 않는다”는 정책적 약속이 아니라, 운영자가 보려고 해도 볼 수 없도록 설계하는 구조가 만들어지는 것입니다.
하지만 이 구조는 새로운 과제도 함께 가져옵니다. 엔클레이브 내부는 외부에서 쉽게 관찰할 수 없기 때문에 디버깅, 성능 분석, 로그 수집, 장애 대응 방식도 달라져야 합니다. 민감 데이터가 로그에 남지 않도록 마스킹 정책을 정하고, 어떤 이벤트를 외부로 내보낼지 설계해야 합니다. 또한 원격 검증 실패, 키 전달 거부, TEE 노드 장애와 같은 상황을 고려한 운영 시나리오도 필요합니다.
따라서 성공적인 Cloud 기밀 컴퓨팅 도입은 모든 시스템을 enclave로 옮기는 일이 아닙니다. 핵심은 다음 질문에 답하는 것입니다.
“우리 서비스에서 반드시 보호해야 할 데이터와 연산은 무엇이며, 평문이 존재해도 되는 경계는 어디까지인가?”
예를 들어 AI 서비스라면 고객 프롬프트, 검색 증강 생성(RAG)용 사내 문서, 모델 파라미터, 암호화 키 처리 구간을 우선 보호 대상으로 분리할 수 있습니다. 금융 서비스라면 신용평가 로직, 거래 탐지 모델, 개인식별정보 처리 영역을 기밀 실행 환경으로 이동하는 방식이 적합합니다.
결국 기밀 컴퓨팅은 단순한 보안 옵션이 아닙니다. 데이터·코드·키·운영 권한의 관계를 다시 정의하는 새로운 Cloud 신뢰 모델입니다. 그리고 이 모델을 제대로 활용하는 기업은 규제 대응을 넘어, 이전에는 공유할 수 없었던 데이터와 모델을 기반으로 더 안전한 협업과 새로운 서비스를 만들어낼 수 있습니다.
