신뢰 실행 환경(TEE) 안에서 AI 돌리기

English version: Running AI Inside a Trusted Execution Environment

프로세서 다이 위의 빛나는 금고 안에 봉인된 AI 모델과 데이터 크리스털, 방패 밖에서 차단된 눈과 손

산업 현장의 AI 적용이 갈수록 빨라지고 있는데요, 지난 글에서는 그 AI의 보안을 모델 쪽에서 살펴보았습니다. 생성형 AI와 에이전틱 AI가 자기 답변으로 정보를 흘리는 문제와, 이를 막는 소프트웨어 차원의 방어(워터마킹, 비가역 학습, 제로트러스트)에 관한 이야기였습니다. 다만 이번에는 조금 다른 시각에서 보안에 접근해 보려고 합니다. 모델이 활용되는 인프라, 특히 추론 기능이 내 통제 밖 어딘가에 놓이는 엣지/임베디드 AI 쪽입니다. 여기서는 ‘AI가 뭐라고 답하느냐’보다 ‘AI가 도는 동안 그 모델과 데이터를 누가 훔쳐볼 수 있느냐’가 문제가 되는데요, 그래서 하드웨어 차원의 보안 방법도 함께 검토해 보는 것이 의미가 있을 듯 합니다.

다양한 암호 기법이 데이터 저장과 통신에 적용되고 있습니다. 덕분에 저장된 데이터(암호화된 디스크)와 오가는 데이터(TLS)는 이미 높은 수준의 보안을 갖추고 있고, 관련 규정이나 가이드라인도 많이 나와 있죠. 예를 들어 개인정보는 암호화해서 저장해야 합니다. 그렇다면 데이터가 ‘쓰이는 중’에는 어떨까요? 암호화되어 저장된 데이터도 쓰일 때는 복호화되어 평문 상태로 메모리에 올라갑니다. 이때 그 메모리를 읽을 권한이 있는 주체라면 누구나 평문을 읽을 수 있구요. 운영체제, 하이퍼바이저, 옆방 테넌트, 그 서버를 소유한 클라우드 운영자까지, 메모리 덤프만으로 모델의 구조나 파라미터를 알아낼 수 있는 상황이 생길 수 있습니다.

신뢰 실행 환경(TEE)은 바로 이 세 번째 상태를 하드웨어로 지켜 보자는 발상입니다. 그리고 AI에서는 이것이 꽤 중요한 보안 이슈가 된다고 생각합니다. AI에서 가장 값진 자산인 모델 가중치와 입력 데이터가 GPU가 도는 동안 평문으로 메모리에 올라가 있다면, 누구든 이를 가져갈 수 있기 때문이죠. 이 글은 그 TEE 안에서 AI를 돌리는 이야기입니다. 왜 그렇게까지 하려는지, 지금 하드웨어의 제약은 무엇이고 이를 풀기 위한 연구는 어떻게 진행되고 있는지 가볍게 정리해 보았습니다.

TEE(Trusted Execution Environment)

TEE는 프로세서가 따로 떼어 내 지켜 주는 격리 구역입니다. 보안이 필요한 데이터를 다루기 위해 메모리의 특정 영역을 할당하고, 이 영역의 내용은 암/복호화 대상이 되며, 권한이 없는 프로세스는 접근할 수 없습니다. 구현 방법에 따라 엔클레이브, 시큐어 월드, 컨피덴셜 VM 등 여러 이름으로 불리고 실체도 조금씩 다르지만, 그 안의 코드와 데이터를 지킨다는 궁극적인 목표는 같습니다. 그 보안은 크게 두 가지 성질로 나눠 볼 수 있는데요, 하나는 기밀성입니다. 바깥에서는 아무도 그 메모리를 읽지 못하고, 자기보다 권한이 높은 소프트웨어도 예외가 아닙니다. 다른 하나는 무결성으로, 밖에서 몰래 손댈 수 없고 손대면 들킵니다. 요즘 칩은 이 메모리를 하드웨어가 통째로 암호화하므로, DRAM 버스에 프로브를 꽂아 들여다봐도 암호문만 보이게 됩니다. 대신 믿어야 할 대상이 바뀌는 셈이에요. 소프트웨어 스택 전체를 믿는 대신, 이 약속 하나만 지켜 주면 되는 CPU 제조사를 믿는 구조에 가깝다고 봅니다.

여기에 두 가지가 더 붙어야 비로소 쓸 만해집니다. 하나는 증명(attestation)입니다. 환경이 원격의 상대에게 “나는 이 벤더의 진짜 TEE고, 지금 내 안에서 도는 코드의 해시는 정확히 이 값이다”라고 내보이는 절차인데요, 상대는 이 증거를 확인한 뒤에야 비밀을 넘깁니다. 다른 하나는 봉인(sealing)입니다. 암호 키를 하드웨어와 코드의 측정값에 묶어 두는 것으로, 이렇게 하면 같은 기계의 같은 코드만 그 데이터를 다시 열 수 있습니다. 현장에서 자주 마주치는 이름은 대략 세 가지 정도인 것 같아요. ARM TrustZone(시큐어 월드와 노멀 월드로 나누는 방식으로, 스마트폰과 엣지 기기 어디에나 있습니다), Intel SGX(작은 프로세스 단위 엔클레이브로, 요즘은 VM 단위인 TDX 쪽으로 무게가 옮겨 갔습니다), 그리고 AMD SEV-SNP(암호화와 증명을 지원하는 VM)입니다.

이 기술들은 크게 두 가지로 나눠 볼 수 있습니다. 프로세스 하나를 지키는 TEE와, 하이퍼바이저 위에서 VM 전체를 지키는 TEE 하이퍼바이저(컨피덴셜 VM)입니다.

	TEE (엔클레이브)	TEE 하이퍼바이저 (컨피덴셜 VM)
지키는 대상	앱의 일부(엔클레이브)	게스트 VM 전체
대표 기술	Intel SGX, ARM TrustZone	Intel TDX, AMD SEV-SNP, ARM CCA
신뢰 기반(TCB)	작음 (엔클레이브 코드만)	큼 (게스트 OS + 앱)
호스트	OS 불신, 앱이 직접 보호	하이퍼바이저 불신, 하드웨어+모니터가 격리
앱 수정	대개 재작성 또는 분리	그대로 이식(lift-and-shift)
보호 메모리	작음 (예전엔 ~100 MB)	VM 전체 RAM (GB급)
AI 적용	모델 탑재 불가	기밀 AI의 현실적인 출발점

뒤에 나올 이야기, 특히 메모리 문제는 어느 쪽을 고르느냐에 크게 좌우됩니다. 일단 여기까지만 알아 두시면 될 것 같구요, 나머지는 이 안에 모델을 실제로 넣으려 할 때 벌어지는 일입니다. 그럼 AI에서는 왜 굳이 TEE를 찾게 될까요?

AI에서 TEE가 주목받는 이유

이유는 비교적 단순한데요, 호스트가 들여다볼 수 없는 곳에서 모델을 돌리고 싶기 때문입니다. 정해진 사람이 아니면 모델의 구조나 파라미터를 볼 수 없게 하려는 것이죠.

모델/가중치 탈취: 학습된 가중치가 곧 자산이다. 그런데 남의 기계, 그러니까 클라우드 서버든 내가 손댈 수 없는 온프렘 장비든 root 권한을 쥔 내부자든, 거기서는 메모리에서 가중치를 통째로 복사해 갈 수 있다. TEE를 쓰면 경계 안을 제외한 모든 곳에서 가중치가 암호문으로 남는다.
학습 데이터 및 멤버십 추출: 공격자는 학습 데이터를 되살리거나, 특정 기록이 학습셋에 있었는지 알아내려 한다. 모델과 그 입출력을 기밀로 묶으면 공격할 틈이 줄어들긴 한다. 다만 솔직히 말하면, TEE가 지키는 것은 ‘돌아가는 바탕’이지 ‘질문을 받는 창구’가 아니다. 정상적인 경로로 질문을 던지는 사람은 여전히 모델을 캐낼 수 있으므로, 모델 자체를 손보는 방어(비가역 학습, 워터마킹, 출력 필터링)와 함께 쓰는 것이 바람직하며, TEE가 그것을 대신하지는 못한다.
입력/프롬프트 프라이버시: 의료, 금융, 산업 현장의 입력을 추론 서버 운영자조차 읽지 못하도록 구성할 수 있다.
증명을 통한 무결성: 지금 돌고 있는 것이 바로 그 모델, 그 코드라는 사실을 입증할 수 있다. 몰래 바꿔치기했거나 백도어를 심은 가중치가 아니라는 뜻이다.

이를 하나로 묶는 그림이 기밀 추론(confidential inference)입니다. 요즘은 기밀 학습까지 시도되고 있구요. 모델 소유자와 데이터 소유자가 증명으로 서로의 TEE를 확인한 뒤에야, 한쪽은 가중치를, 다른 쪽은 데이터를 어떤 호스트도 읽지 못하는 환경 안으로 들여보냅니다. 이는 이론에 그치지 않고 이미 실제로 쓰이고 있습니다. 클라우드 사업자들은 기밀 GPU VM을 판매하고, 모델을 서비스로 제공하는 업체는 가중치를 끝까지 공개하지 않은 채 서빙하며, 병원들은 컨피덴셜 VM 안에서 기록을 모아 공동 모델을 만듭니다. 요즘 대형 소비자 AI 백엔드도 증명된 기밀 컴퓨팅을 활용해, 운영자조차 이용자의 요청을 읽지 못하게 해 두고 있습니다.

TEE 하드웨어의 제약

TEE는 AI를 위해 설계된 기술이 아닙니다. 컴퓨팅 보안 기술로서 오래전부터 개발되고 쓰여 왔죠. 예를 들어 부팅 단계의 Secure Boot 등이 실제로 컴퓨터 보안을 담당해 오고 있습니다. 다만 컴퓨터를 쓰는 입장에서 TEE가 다소 부담스러운 영역인 것도 사실입니다. 특정 메모리 영역이나 컴퓨팅 자원을 미리 할당해 둬야 하고, 메모리 암/복호화가 필요하므로 이 영역을 불필요하게 쓰면 시스템 성능이 떨어질 수 있거든요. 그래서 지금까지의 TEE는 꼭 필요한 부분을 보호하는 데 집중해 왔고, 시스템 부하를 최소화하는 것도 주요 목적 중 하나였습니다. 이렇다 보니 점점 커지는 AI 모델을 돌리기에는 하드웨어 제약이 꽤 큰 편인 것 같아요.

작은 엔클레이브 메모리: 예전 CPU 엔클레이브가 지켜 주는 메모리는 많아야 100 MB 남짓이었습니다. 요즘 모델은 기가바이트 단위죠. 애초에 들어가지 않고, 작은 엔클레이브에 가중치를 넣었다 뺐다 페이징하면 견디기 어려울 만큼 느려집니다. VM 단위 TEE(TDX, SEV-SNP)가 VM 메모리를 통째로 지키면서 이 한계 하나는 해소했지만, 여전히 CPU 쪽 이야기입니다.

CPU 중심의 TEE, 아직 진행 중인 GPU 보호: AI는 GPU에서 돌아갑니다. 그런데 얼마 전까지 GPU는 신뢰 경계 바깥에 통째로 놓여 있었는데요, 그래서 둘 중 하나를 골라야 했습니다. 모델을 CPU TEE에 넣고 GPU 가속을 포기하거나(실전 모델에는 쓸 수 없을 만큼 느립니다), 데이터를 믿을 수 없는 GPU로 넘기면서 애초에 TEE를 쓴 이유인 기밀성을 포기하거나.

CPU-GPU 연결 비용: NVIDIA의 컨피덴셜 컴퓨팅(Confidential Computing)은 Hopper H100부터 GPU를 신뢰 경계 안으로 끌어들였습니다. GPU가 기밀 모드에서 암호화된 메모리 위에서 동작하고, CPU의 컨피덴셜 VM과 GPU 사이 PCIe를 건너는 데이터도 암호화되며, GPU 자체도 증명할 수 있습니다. 증명된 H100에 컨피덴셜 VM(TDX 또는 SEV-SNP)을 붙이면 CPU와 GPU를 아우르는 하나의 TEE가 되는 셈이에요. 문제는 바로 그 PCIe 구간입니다. 데이터가 CPU TEE 안의 바운스 버퍼를 거쳐 암호화된 다음 GPU로 복사되므로, 호스트와 GPU 사이를 자주 오갈수록 비용이 늘어납니다. 크고 연산이 무거운 모델이라면 오버헤드가 크지 않지만, 작은 모델이나 데이터 왕복이 잦은 파이프라인이라면 성능 저하도 함께 고려해 보는 것이 좋을 듯 합니다.

하나의 신뢰 경계 안에서 컨피덴셜 VM(CPU)과 증명된 GPU가 자물쇠로 잠긴 암호화 채널로 연결되고, 신뢰되지 않는 호스트는 경계 밖에서 차단된 구조

최근 연구 토픽들

그렇다면 TEE를 피할 수 없는 상황에서 하드웨어 제약을 어떻게 극복할 수 있을까요? 최근 이에 대한 연구가 활발히 진행되고 있습니다. Intel은 SGX 등에서 VM 기반 TEE를 지원하고 있고, NVIDIA도 Jetson 등 임베디드 플랫폼에서 TEE 지원을 시작했지만, 아직 대용량 모델을 직접 운영하기에는 여러 문제가 있습니다. 특히 서버급 CPU를 제외하고는 TEE 기능을 빼고 있는 Intel, Blackwell 계열임에도 사용에 제약이 있는 NVIDIA Jetson Thor, TEE 활용 자체를 제한하는 Apple M 시리즈 칩 등, 아직 하드웨어의 전폭적인 지원을 기대하기는 어려운 것 같아요. 그래서 다양한 소프트웨어 기법이 함께 연구되고 있습니다.

CPU-TEE, GPU, 메모리의 연계: 엔클레이브는 작고 CPU 쪽에 있는데, 모델과 연산은 GPU에 있다. 양쪽 모두에서 최대 성능을 끌어내는 것은 보안 문제이자 자원 최적화 문제다. 민감한 부분은 보호된 상태로 두고 무거운 연산은 가속기로 돌리도록 모델을 나눠 배치하고, 암호화된 CPU↔GPU 트래픽을 최대한 줄여 성능 저하를 최소화하는 방법이 연구되고 있다.
보호할 계층 선택: 모델을 통째로 TEE에 넣는 것이 가장 간단하지만 가장 비싸고, 실제 모델을 통째로 넣을 수 있는 하드웨어도 아직 부족하다. 그렇다면 앞의 예처럼 모델의 특정 부분만 TEE에서 운용하는 방안을 고려하게 되는데, 방대한 모델 구조에서 어느 부분을 TEE에 넣어야 보호 효과가 가장 클지에 대한 고민이 이어지고 있다. 일반적인 CNN은 MLP 부분을, transformer 기반 모델은 Q, V 등의 연산을 TEE에서 운용하는 방안이 제시되고 있으나, 아직 새로운 방안을 고려해 볼 여지가 많아 보인다.
실재하는 하드웨어 하한: 기밀 GPU 추론을 하려면 컨피덴셜 컴퓨팅을 지원하는 데이터센터 GPU(Hopper의 H100/H200, 또는 Blackwell의 B100/B200/GB200)와 컨피덴셜 VM을 지원하는 CPU가 필요하다. 그 이전 세대(Ada, Ampere)에는 이 기능이 없다. 그리고 아키텍처 세대가 같다고 되는 것도 아니다. Jetson Thor는 Blackwell 세대 GPU로 만들어졌는데도 이 기능을 쓸 수 없다. 컨피덴셜 컴퓨팅은 NVIDIA 데이터센터용 개별 GPU와 그 플랫폼에 들어간 기능이며, CC용 하드웨어 보안 엔진도 펌웨어도 증명 경로도 없는 Jetson/임베디드 SoC 라인의 기능이 아니기 때문이다. Thor는 엣지 로보틱스를 겨냥한 제품이지, 증명된 기밀 추론을 겨냥한 제품이 아니다. ‘Blackwell이니까’라는 이유만으로 GB200 같은 TEE가 만들어지지는 않는다.

아직 어느 것도 완벽한 대안을 제시하지는 못하지만, AI 운용에서 모델 보안에 대한 요구는 분명하다고 생각합니다. 산업 현장의 AI 적용이 갈수록 빨라지는 흐름을 보면, 앞으로 AI 정보보호는 점점 더 중요해질 것이고 TEE에 대한 요구도 그만큼 커질 것 같아요. TEE는 ‘쓰이는 중’인 AI 데이터를 지키는 하드웨어 보안 도구를 하나 더 보태 줄 수 있을 것으로 봅니다.

참고 문헌

Florian Tramèr, Dan Boneh, Slalom: Fast, Verifiable and Private Execution of Neural Networks in Trusted Hardware, ICLR 2019: 민감한 연산은 CPU TEE 안에 두고, 무거운 선형 계층은 더 빠르지만 믿을 수 없는 보조 프로세서로 넘기는 방식. CPU-TEE ↔ GPU 분할의 초기 사례다.
Stavros Volos, Kapil Vaswani, Rodrigo Bruno, Graviton: Trusted Execution Environments on GPUs, USENIX OSDI 2018: 최초의 연구용 GPU TEE. 오버헤드 대부분이 GPU를 오가는 트래픽의 암호화에서 나온다는 점이 본문의 CPU↔GPU 비용 이야기와 그대로 겹친다.
Ziqi Zhang 외, No Privacy Left Outside: On the (In-)Security of TEE-Shielded DNN Partition for On-Device ML, IEEE S&P 2024: 일부 계층만 TEE로 가리는 것이 생각보다 까다롭다는 점을 보이고 TEESlice를 제안한다. 본문의 ‘보호할 계층 선택’과 바로 이어진다.
NVIDIA, Confidential Compute on NVIDIA Hopper H100 (백서): 컨피덴셜 컴퓨팅을 지원하는 최초의 GPU인 H100의 온다이 신뢰 기반, GPU 증명, 암호화된 CPU↔GPU 바운스 버퍼를 다룬다.