Intel SGX 단계적 종료로 Diamond Rapids가 enclave를 지원하는 마지막 Xeon으로 남는다
Intel은 Intel SGX를 단계적으로 종료한다고 확인했으며, 이에 따라 2027년 Diamond Rapids Xeon 플랫폼이 enclave 기술을 포함하는 마지막 세대가 된다.
이번 결정으로 Intel의 기밀 컴퓨팅 전략에서 중요한 한 장이 마무리된다. Software Guard Extensions, 즉 SGX는 enclave라고 불리는 하드웨어 보호 메모리 영역 안에서 선택된 애플리케이션 코드와 데이터를 격리한다. Intel은 앞으로 완전한 가상 머신을 격리하는 Trust Domain Extensions, 즉 TDX에 투자를 집중할 예정이다.
이 변화는 단순한 기능 퇴출 이상의 의미를 지닌다. SGX는 개발자에게 좁은 보안 경계를 제공하지만, 특화된 애플리케이션 설계를 요구한다. 반면 TDX는 더 큰 환경을 보호하면서도 클라우드 제공업체와 엔터프라이즈 인프라 팀이 이미 사용하는 가상 머신 모델에 부합한다.
Intel은 기존 SGX 플랫폼이 2030년대 초반까지 지원과 보안 업데이트를 받을 것이라고 밝혔다. 따라서 고객에게는 마이그레이션 경로를 검토할 시간이 있다. 다만 새로운 기밀 컴퓨팅 프로젝트는 이제 더 분명한 아키텍처 선택에 직면한다. TDX를 중심으로 구축하거나, SGX의 제한된 미래를 감수하거나, 다른 하드웨어 플랫폼을 검토해야 한다.
Intel SGX 단계적 종료는 Diamond Rapids 이후 시작된다
Diamond Rapids는 마지막 Xeon 세대에서 SGX를 유지하지만, Intel의 장기 로드맵은 이제 TDX에 속한다.
Intel은 2026년 10월 9일 이 결정을 공개했다. 회사는 Diamond Rapids가 SGX를 포함하는 마지막 Xeon 플랫폼이 될 것이라고 밝혔다. Intel은 이 프로세서 제품군을 2027년에 출시할 계획이다.
회사는 기존 enclave를 즉시 비활성화하거나 현재 지원을 종료하지는 않는다. 기밀 컴퓨팅 로드맵은 2030년대 초반까지 보안 업데이트와 플랫폼 지원을 약속한다. 이 일정은 규제 산업 기업과 인프라 공급업체에 계획을 수립할 수 있는 수년의 시간을 제공한다.
Intel은 2017년 데이터센터 프로세서에 처음으로 SGX를 도입했다. 이후 Sapphire Rapids를 통해 주력 Xeon 서버 플랫폼에 이 기술을 적용했다. SGX는 애플리케이션이 데이터를 실제로 처리하는 동안 데이터를 보호하는 가장 널리 알려진 접근 방식 중 하나가 됐다.
기존 암호화는 저장 중이거나 네트워크를 통해 이동하는 정보를 보호한다. 기밀 컴퓨팅은 하드웨어로 강제되는 신뢰 실행 환경 안에 워크로드를 배치해 사용 중인 데이터를 보호한다. 호스트 관리자, hypervisor 또는 인접 워크로드는 보호된 메모리에 직접 접근할 수 없어야 한다.
SGX는 이 개념을 애플리케이션 수준에 적용한다. 개발자는 민감한 기능과 데이터를 선택해 enclave 안에 배치한다. 운영 체제와 hypervisor는 신뢰 경계 밖에 남는다.
TDX는 격리 단위를 바꾼다. TDX는 호스트와 다른 가상 머신으로부터 하드웨어 수준에서 격리되는 가상 머신인 trust domain을 생성한다. 이 환경 안의 애플리케이션은 enclave 구성 요소와 비-enclave 구성 요소로 나뉘지 않고도 실행할 수 있는 경우가 많다.
이 차이가 Intel의 발표가 중요한 이유를 설명한다. 회사는 SGX의 더 작고 특화된 경계보다 배포가 쉬운 더 넓은 보호 경계를 선택하고 있다.
Intel은 시장이 가상 머신 격리 방식으로 점차 정렬됐다고도 설명한다. 주요 퍼블릭 클라우드는 이미 가상 머신, 이미지, orchestration 계층, 그리고 확립된 관리 도구를 중심으로 운영된다. TDX는 애플리케이션 enclave보다 이러한 시스템에 더 직접적으로 부합한다.
로드맵의 최종성은 즉각적인 계획 수립상의 결과를 낳는다. 조직은 여전히 SGX 지원 시스템을 구매, 배포, 유지할 수 있다. 그러나 미래 Xeon 세대가 동일한 애플리케이션 아키텍처를 유지할 것이라고 가정해서는 안 된다.
Diamond Rapids는 이제 두 가지 역할을 맡는다. Intel의 차세대 고성능 Xeon 플랫폼이자, 여전히 SGX에 의존하는 고객을 위한 마지막 가교다.
이 가교는 하드웨어 교체 주기가 긴 조직에 유용할 것이다. 그러나 방향 자체를 바꾸지는 않는다. Intel은 앞으로의 기밀 컴퓨팅 작업을 TDX에 할당한다고 공개적으로 밝혔다.
Intel이 지금 SGX에서 TDX로 전환하는 이유
이 전환은 운영상의 현실을 반영한다. 전체 가상 머신을 보호하는 방식이 각 애플리케이션을 enclave 중심으로 재설계하는 것보다 도입하기 쉽다.
SGX와 TDX는 겹치는 위협으로부터 방어하지만, 서로 다른 책임을 요구한다. SGX는 보안상 신뢰해야 하는 코드와 구성 요소를 뜻하는 작은 신뢰 컴퓨팅 기반을 만들 수 있다. 더 작은 경계는 공격자에게 노출되는 소프트웨어의 양을 줄일 수 있다.
하지만 이 장점에는 엔지니어링 비용이 따른다. 개발자는 민감한 로직을 식별하고, 보호된 코드와 보호되지 않은 코드 간 전환을 관리하며, enclave 메모리 제약을 처리해야 한다. 또한 enclave 모델을 중심으로 attestation, 비밀 정보 전달, 오류 처리, 소프트웨어 업데이트를 설계해야 한다.
이러한 요구 사항은 암호화 서비스, 신원 관리 시스템, 금융 처리 또는 매우 민감한 비밀 정보를 보유한 애플리케이션에는 정당화될 수 있다. 그러나 조직이 수천 개의 일반 워크로드를 보호하려 할 때는 정당화하기가 더 어려워진다.
TDX는 다른 절충안을 제시한다. 인프라 팀은 운영 체제, 애플리케이션 스택, 지원 서비스를 기밀 가상 머신 안에 배치할 수 있다. 기존 워크로드에는 애플리케이션별 수정이 더 적게 필요하다.
Intel은 TDX를 더 낮은 총운영비용으로 제공되는 확장성과 유연성이 더 높은 접근 방식으로 설명한다. SGX 전환 가이드는 전환 이유로 특히 사용 편의성과 배포 유연성을 꼽는다.
클라우드 도입은 이러한 주장을 강화한다. Microsoft Azure, Google Cloud, IBM Cloud, Alibaba Cloud, Volcano Cloud는 Intel TDX 기반 서비스를 제공해 왔다. Red Hat, Canonical, VMware 역시 엔터프라이즈 및 프라이빗 클라우드 환경 지원에 참여해 왔다.
이처럼 주변을 이루는 소프트웨어는 프로세서 기능만큼 중요하다. 기밀 컴퓨팅은 이미지 생성, 키 관리, 정책 시행, orchestration, 모니터링, 원격 attestation과 연결돼야 한다.
Attestation은 원격 당사자가 비밀 정보를 공개하기 전에 보호된 환경의 신원과 예상 상태를 확인할 수 있게 한다. 기존 배포 시스템에 맞지 않는 기술은 특화된 보안 기능으로 남을 위험이 있다.
데이터 주권도 또 다른 동인이다. 규제와 내부 정책은 정보가 어디에 있는지뿐 아니라 누가 정보에 접근할 수 있는지 점점 더 묻고 있다. 하드웨어 격리는 클라우드 관리자 또는 손상된 호스트 소프트웨어에 대한 노출을 제한할 수 있다.
Intel은 TDX를 이러한 배포를 위한 기술적 통제로 제시한다. 기밀 가상 머신은 기반 인프라가 다른 조직에 속하더라도 메모리를 격리된 상태로 유지할 수 있다.
Agentic AI는 더 새로운 수요 원천을 추가한다. AI 에이전트는 엔터프라이즈 기록을 읽고, 외부 서비스를 호출하며, 시스템을 업데이트하고, 다른 에이전트와 정보를 교환할 수 있다. 따라서 이들의 실행 환경에는 자격 증명, 독점 데이터, 민감한 중간 결과가 축적될 수 있다.
신중히 선택한 하나의 기능만 보호하는 방식이 항상 이 워크로드에 부합하는 것은 아니다. AI 에이전트는 runtime, 모델 인터페이스, 검색 서비스, 도구 통합, 다수의 소프트웨어 라이브러리에 의존할 수 있다. 전체 환경을 격리하는 방식이 더 실용적일 수 있다.
그렇다고 모든 보안 문제에서 TDX가 본질적으로 더 우수하다는 뜻은 아니다. 이는 TDX가 Intel이 기밀 클라우드 및 엔터프라이즈 컴퓨팅에서 주류가 될 것으로 예상하는 배포 모델에 부합한다는 의미다.
Intel SGX 단계적 종료는 이러한 선택을 공식화한다. Intel은 두 가지 상이한 격리 모델에 무기한 투자하는 대신, 더 폭넓은 인프라 지원을 갖춘 하나의 모델에 로드맵을 집중하고 있다.
Intel SGX 대 TDX는 단순한 업그레이드가 아닌 절충안이다
TDX는 신뢰 경계를 넓혀 배포를 단순화하는 반면, SGX는 그 경계를 작게 유지하기 위해 더 많은 엔지니어링을 요구한다.
Intel SGX와 TDX의 가장 중요한 차이는 세분성이다. SGX는 선택된 코드와 데이터를 격리한다. TDX는 게스트 운영 체제와 애플리케이션 종속성을 포함한 전체 가상 머신을 격리한다.
이렇게 확장된 범위는 TDX를 더 쉽게 사용할 수 있게 한다. 동시에 더 많은 소프트웨어가 신뢰 컴퓨팅 기반 안에 위치한다는 뜻이기도 하다. 보호된 게스트 내부의 취약점은 해당 게스트가 접근할 수 있는 데이터를 여전히 손상시킬 수 있다.
SGX는 보안 팀이 신뢰 영역에 들어가는 요소를 더 세밀하게 통제할 수 있게 한다. enclave는 운영 체제, 대부분의 라이브러리, 관련 없는 애플리케이션 구성 요소를 제외할 수 있다. 개발자가 이를 올바르게 구현할 경우, 이 구조는 엄격한 구획화를 지원한다.
엔지니어링 부담은 상당하다. 일반적인 운영 체제 환경용으로 작성된 애플리케이션은 시스템 호출, 동적 메모리, 파일, 네트워킹, 대규모 소프트웨어 프레임워크에 의존할 수 있다. 민감한 구성 요소만 enclave로 옮기려면 세심한 분리가 필요하다.
Library operating system은 enclave 내부 또는 주변에서 친숙한 운영 체제 기능을 제공해 이러한 노력을 줄일 수 있다. 그러나 여전히 아키텍처 결정, 호환성 테스트, 추가 신뢰 구성 요소를 도입한다.
TDX는 문제의 더 많은 부분을 인프라로 옮긴다. 팀은 애플리케이션을 기밀 가상 머신으로 패키징하고 익숙한 클라우드 도구로 관리할 수 있다. 이는 기존 소프트웨어 포트폴리오 전반에서 더 빠른 도입을 지원한다.
따라서 보안 비교는 워크로드에 따라 달라진다.
신뢰 경계
SGX: enclave 내부에서 선택된 애플리케이션 기능과 데이터를 보호한다.
TDX: 호스트 환경으로부터 전체 가상 머신을 보호한다.
애플리케이션 변경
SGX: 코드 분리, enclave 인식 개발 또는 호환 가능한 library operating system이 필요한 경우가 많다.
TDX: 제한적인 애플리케이션 변경만으로 많은 기존 워크로드를 실행할 수 있다.
운영 모델
SGX: 개별 enclave를 중심으로 보호와 attestation을 수행한다.
TDX: 가상 머신 이미지, 클라우드 프로비저닝, 인프라 orchestration에 부합한다.
보안 책임
SGX: 더 많은 호스트 소프트웨어를 신뢰 경계 밖에 두지만, 애플리케이션 개발자에게 추가 설계 책임을 부여한다.
TDX: 호스트를 신뢰 경계에서 제거하지만, 더 많은 게스트 소프트웨어를 신뢰해야 한다.
마이그레이션은 단순히 하나의 프로세서 설정을 다른 것으로 바꾸는 것보다 더 복잡하다. Intel의 전환 문서는 SGX 애플리케이션을 서로 다른 아키텍처 패턴으로 구분한다. 각 패턴은 서로 다른 목적지로 이어질 수 있다.
이미 library operating system을 통해 실행 중인 애플리케이션은 중간 수준의 변경으로 기밀 컨테이너 또는 TDX 가상 머신으로 이전할 수 있다. SGX development kit에 직접 맞춰 구축된 소프트웨어는 더 깊은 재설계가 필요할 수 있다.
일부 애플리케이션은 수년간 enclave 아키텍처를 유지할 수 있다. 다른 애플리케이션은 민감한 기능을 별도 서비스로 분리할 수 있다. 팀은 단계적 마이그레이션 과정에서 기존 SGX 워크로드를 더 넓은 기밀 환경 안에 배치할 수도 있다.
원격 attestation도 또 다른 차이를 보인다. SGX는 enclave 코드의 신원과 측정값을 attest할 수 있다. TDX는 trust domain과 부팅 환경의 상태를 attest한다. 조직은 키를 공개하거나 보호된 결과를 수락할 시점을 결정하는 정책을 조정해야 한다.
팀은 이러한 측정값이 동일한 의미를 지닌다고 가정해서는 안 된다. 검증 서비스, 기준값, 인증서 절차, 업데이트 규칙을 검토해야 한다.
그 결과는 단순한 Intel TDX 마이그레이션 버튼이 아니다. 애플리케이션 소유자, 플랫폼 엔지니어, 보안 팀, 컴플라이언스 전문가가 함께 참여하는 아키텍처 프로그램이다.
TDX Connect, CPU와 가속기 사이의 취약한 연결 고리 겨냥
기밀 AI는 프로세서, GPU 및 기타 장치 간에 정보를 점점 더 많이 이동시키므로 Intel의 로드맵은 CPU 메모리 너머의 데이터까지 보호해야 한다.
기밀 가상 머신은 호스트로부터 CPU 메모리를 격리할 수 있다. 그러나 이 보호가 가속기나 주변 장치로의 모든 전송을 자동으로 보호하는 것은 아니다.
이 공백은 AI에서 중요하다. 보호된 워크로드는 CPU 환경에서 GPU로 프롬프트, 모델 파라미터, 임베딩 또는 중간 결과를 보낼 수 있다. 이 전송 과정에서 데이터는 원래의 신뢰 경계를 벗어날 수 있다.
Intel은 보호된 장치 통신을 위해 설계된 신뢰할 수 있는 입출력 아키텍처인 TDX Connect를 통해 TDX를 확장할 계획이다. 목표는 기밀 가상 머신이 할당된 하드웨어와 상호작용할 때 격리를 유지하는 것이다.
Intel은 일부 CPU-장치 간 전송을 위해 소프트웨어 기반 암호화 바운스 버퍼를 이미 설명한 바 있다. 바운스 버퍼는 대상 장치가 복호화하기 전에 호스트가 접근할 수 있는 메모리를 통해 암호화된 데이터를 이동시킨다. 이는 기능적인 연결 경로를 만들지만, 오버헤드를 유발할 수 있다.
TDX Connect는 보다 직접적인 하드웨어 기반 경로를 지원하기 위한 것이다. Intel은 향후 개발에 더 강력한 인증과 포스트 양자 암호화도 포함될 것이라고 밝혔다. 다만 회사는 각 개선 사항의 정확한 제공 시점을 발표하지 않았다.
이 일정의 부재는 중요하다. Intel의 전략적 방향은 분명하지만, 고객에게는 여전히 제품 수준의 세부 정보가 필요하다. 어떤 프로세서, 플랫폼, 장치, 펌웨어 버전 및 클라우드 서비스가 각 기능을 지원하는지 알아야 한다.
Intel은 CPU와 GPU 전반의 기밀 컴퓨팅을 조율하기 위해 Nvidia와 협력하고 있다. Nvidia는 이미 암호화된 메모리와 인증을 포함해 일부 가속기에서 보호된 실행 기능을 제공한다. 이 결합 모델은 AI 시스템 전반에 걸쳐 연속적인 신뢰 사슬을 구축하는 것을 목표로 한다.
이 사슬은 여전히 기술적으로 까다롭다. CPU, 가속기, 펌웨어, 장치 할당 시스템, 가상 머신 모니터 및 인증 서비스는 보호된 환경에 대해 일치된 판단을 내려야 한다. 한 계층의 취약점은 전체 배포 환경에 대한 신뢰를 낮출 수 있다.
Apple은 더 넓은 방향성을 보여 주는 가시적인 사례를 제공한다. Apple의 Private Cloud Compute 설계는 클라우드 처리를 보호하기 위해 특수 하드웨어, 검증 가능한 소프트웨어 및 외부 검토 메커니즘을 사용한다. Intel은 Google Cloud와의 확장 협력이 Xeon 인프라의 TDX 신뢰 도메인을 활용한다고 밝혔다.
이 사례는 하드웨어 격리만으로는 충분하지 않은 이유를 보여 준다. 고객에게는 소프트웨어 신원, 업데이트 통제, 로깅, 키 제공 및 관리 액세스에 관한 증거도 필요하다.
에이전틱 시스템은 이러한 질문을 더욱 시급하게 만든다. 자율 서비스는 데이터베이스, 이메일 시스템, 소스 저장소 또는 비즈니스 애플리케이션의 자격 증명을 보유할 수 있다. 도구 자격 증명을 노출한 채 모델 호출만 보호한다면 치명적인 공백이 남는다.
기밀 가상 머신은 에이전트 런타임과 그 커넥터를 하나의 격리된 환경 안에 배치할 수 있다. 이후 신뢰할 수 있는 I/O는 가속기 및 할당된 장치와의 교환을 보호하는 데 도움이 될 수 있다.
이 모델은 TDX에 대한 Intel의 논거를 뒷받침한다. 동시에 고객이 검증해야 할 범위도 넓어진다. 보안은 이제 단일 엔클레이브 경계가 아니라 연결된 시스템에 달려 있다.
TDX 로드맵은 구현 세부 사항, 독립적인 테스트 및 클라우드 가용성으로 평가될 것이다. 계획된 기능 목록은 배포 가능한 하드웨어와 재현 가능한 보안 증거를 대체할 수 없다.
보안 이력은 신중함을 요구한다
SGX와 TDX 어느 쪽도 소프트웨어 취약점, 사이드 채널 또는 독립적인 보안 검토의 필요성을 없애지 않는다.
Intel은 SGX 퇴출의 원인을 보안 결함으로 지목하지 않았다. 대신 도입률, 확장성, 배포 단순성 및 가상 머신 격리에 대한 업계의 선호를 이유로 들었다.
그럼에도 신뢰 실행 환경의 역사는 신중하게 해석해야 한다. 연구자들은 기밀 컴퓨팅 기술에 영향을 미치는 사이드 채널 공격, 권한 상승 경로 및 인증 관련 취약점을 공개해 왔다.
SGX는 여러 주요 공격 계열에 직면했다. 일부는 추측 실행 또는 마이크로아키텍처 동작을 악용해 보호된 정보를 추론했다. 다른 공격은 Intel이 정의한 위협 모델 밖의 구현 오류, 소프트웨어 인터페이스 또는 가정을 겨냥했다.
TDX 역시 광범위한 검증이 필요했다. Intel은 출시 전 연구에 4인년의 보안 분석이 투입됐다고 밝혔다. 이 작업은 수십 건의 취약점을 확인하고, 12건이 넘는 아키텍처 또는 심층 방어 개선을 이끌어 냈다.
이후 Google은 라이브 마이그레이션과 신뢰 도메인 파티셔닝을 포함한 TDX 1.5 기능 평가에서 Intel과 협력했다. 해당 연구는 버그를 발견하는 한편 수정과 보안 강화 작업에도 기여했다.
이 과정은 복잡한 보안 기술에서 일반적이다. 이것이 플랫폼이 안전하지 않다는 증거는 아니다. 다만 완전한 보호에 관한 주장이 왜 회의적인 검토를 받아야 하는지를 보여 준다.
기밀 컴퓨팅은 특정 인프라 위험을 줄인다. 그러나 모든 악성 애플리케이션, 손상된 종속성, 탈취된 자격 증명 또는 결함 있는 액세스 정책까지 방어하지는 않는다. 보호된 환경도 유해하거나 취약한 소프트웨어를 안전하게 실행할 수 있다.
위협 모델과 마케팅 언어의 구분은 중요하다. TDX는 신뢰할 수 없거나 손상된 호스트로부터 게스트를 보호하는 것을 목표로 한다. 게스트 내부의 모든 구성 요소를 자동으로 신뢰할 수 있게 만드는 것은 아니다.
인증은 예상된 기준값과 측정값이 일치하는지 확인할 수 있다. 측정된 애플리케이션에 논리 오류가 있는지는 판단할 수 없다. 또한 신뢰할 수 있는 검증 서비스와 신중하게 관리되는 기준 정책에 의존한다.
라이브 마이그레이션은 또 다른 과제를 만든다. 클라우드 운영자는 메모리를 노출하거나 신뢰를 깨뜨리지 않으면서 보호된 가상 머신을 호스트 간에 이동해야 한다. 이 기능은 연구자들이 검토해야 할 프로토콜, 키, 상태 전환 및 추가 코드를 도입한다.
장치 액세스는 복잡성을 더한다. 신뢰할 수 있는 I/O는 장치 성능과 관리 가능성을 유지하면서 호스트가 보호된 트래픽을 검사하거나 변경하지 못하도록 해야 한다. 가속기 펌웨어와 장치 보안은 실질적인 신뢰 체계의 일부가 된다.
포스트 양자 암호화도 유사한 질문을 제기한다. Intel은 이를 향후 투자 영역으로 언급했지만, 이 명칭은 서로 다른 알고리즘과 시스템 구성 요소를 포괄할 수 있다. 고객은 무엇이 언제 바뀌는지 알아야 한다.
따라서 보안 팀은 Intel TDX 마이그레이션을 SGX 보증 사례의 자동적 연장이 아니라 새로운 평가로 다뤄야 한다. 기존 위협 모델, 통제 체계 및 컴플라이언스 증거는 수정이 필요하다.
복구 절차도 살펴봐야 한다. 하드웨어 인증 시스템은 인증서, 서명 인프라, 폐기 메커니즘 및 신뢰 서비스에 의존한다. 장애나 정책 오류가 발생하면 정상적인 워크로드가 비밀 정보를 받지 못할 수 있다.
벤더 다양성도 고려할 가치가 있다. AMD는 일반적으로 SEV-SNP라고 불리는 Secure Nested Paging 기반의 Secure Encrypted Virtualization을 제공한다. 이 역시 호스트 환경의 일부로부터 가상 머신을 보호한다.
AMD SEV 문서는 메모리 암호화, 무결성 보호 및 게스트 인증을 설명한다. 클라우드 제공업체는 AMD와 Intel 기밀 가상 머신 옵션을 모두 제공할 수 있어, 구매자에게 아키텍처 및 공급 선택권을 제공한다.
Nvidia의 confidential computing 플랫폼은 지원되는 GPU까지 보호를 확장한다. Arm의 Confidential Compute Architecture는 Arm 환경에서의 보호된 실행을 목표로 한다. 각 설계는 성숙도, 가용성 및 위협 가정이 다르다.
따라서 Intel은 프로세서 성능 이상의 영역에서 경쟁한다. 문서화, 독립 검토, 클라우드 배포 및 예측 가능한 보안 유지 관리를 통해 신뢰를 얻어야 한다.
Intel의 SGX 단계적 폐지는 Intel의 로드맵을 단순화한다. 그러나 고객이 답해야 할 보안 질문을 단순화하지는 않는다.
SGX 고객에게는 워크로드별 마이그레이션 계획이 필요하다
가장 안전한 대응은 지금 SGX 종속성을 파악한 뒤, 각 워크로드를 필요한 보호 경계에 맞추는 것이다.
조직은 조사부터 시작해야 한다. SGX 인터페이스를 직접 호출하거나, 엔클레이브 인식 프레임워크에 의존하거나, 그 종속성을 드러내지 않은 채 SGX 기반 서비스를 사용하는 애플리케이션을 식별해야 한다.
관리형 서비스에는 특별한 주의가 필요하다. 기업은 데이터베이스, 블록체인 서비스, 키 관리 제품 또는 기밀 분석 플랫폼을 통해 SGX에 의존할 수 있다. 고객이 엔클레이브를 직접 운영하지 않을 수도 있다.
이후 각 워크로드에는 보안 프로필이 필요하다. 팀은 보호 대상 자산, 예상 공격자, 신뢰 구성 요소, 인증 절차, 성능 제약 및 규제 의무를 문서화해야 한다.
이 프로필은 TDX가 수용 가능한 대체 수단인지 결정한다. 최소 엔클레이브 경계를 중심으로 설계된 워크로드는 더 큰 게스트 환경으로 옮겨졌을 때 동등한 격리를 얻지 못할 수 있다.
다른 애플리케이션은 더 쉽게 이전할 수 있다. 주로 클라우드 관리자로부터 전체 서비스를 보호하기 위해 SGX를 도입한 소프트웨어는 기밀 가상 머신에 잘 맞을 수 있다. TDX는 하드웨어 기반 호스트 격리를 유지하면서 맞춤형 코드를 줄일 수 있다.
Intel의 마이그레이션 가이드는 몇 가지 가능한 경로를 제시한다. 여기에는 라이브러리 운영 체제 워크로드 이전, SGX 개발 키트 애플리케이션 재설계 및 기밀 컨테이너 도입이 포함된다.
기밀 컨테이너는 컨테이너 워크플로와 하드웨어로 격리된 가상 머신을 결합한다. 컨테이너 인터페이스는 익숙한 형태로 유지되며, 신뢰 도메인이 워크로드를 호스트와 분리한다. 이는 이미 Kubernetes와 Kata Containers를 사용하는 팀에 적합할 수 있다.
테스트는 애플리케이션 시작을 넘어야 한다. 팀은 인증, 비밀 정보 제공, 업그레이드, 백업, 복원, 관측 가능성, 인시던트 대응 및 호스트 간 마이그레이션을 검증해야 한다.
성능도 측정이 필요하다. TDX 환경은 SGX 엔클레이브보다 더 큰 소프트웨어 스택을 보호하고 메모리를 다르게 처리한다. 워크로드 동작은 프로세서, 클라우드 구성 및 장치 경로에 따라 달라질 수 있다.
조직은 SGX 지원이 종료될 때까지 모든 결정을 미루지 않아야 한다. 규제 환경에서는 하드웨어 조달, 애플리케이션 재설계, 인증 및 공급업체 승인에 수년이 걸릴 수 있다.
불필요한 긴급 마이그레이션도 피해야 한다. Intel은 긴 지원 기간을 약속했으며, Diamond Rapids는 SGX를 지원하는 또 하나의 세대를 제공한다. 팀이 대체 방안을 검증하는 동안 기존 시스템은 계속 적절한 선택일 수 있다.
가장 강력한 마이그레이션 프로그램은 기존 환경과 신규 환경 모두에 대한 증거를 유지할 것이다. 보안 팀은 하드웨어 기능의 이름만이 아니라 실제 신뢰 컴퓨팅 기반을 비교해야 한다.
조달 계약은 업데이트가 필요할 수 있다. 구매자는 클라우드 및 소프트웨어 벤더에 SGX 서비스가 얼마나 오래 제공될지 물어야 한다. 또한 TDX 지원, 인증 인터페이스 및 신뢰할 수 있는 I/O에 대한 일정을 요청해야 한다.
개발자에게는 명확한 소유권이 필요하다. 인프라 팀은 TDX 인스턴스를 프로비저닝할 수 있지만, 애플리케이션 팀은 여전히 종속성, 비밀 정보 및 권한 부여를 통제한다. 기밀 컴퓨팅이 이러한 책임을 없애지는 않는다.
이 결정은 미래 아키텍처에도 영향을 미친다. 신규 SGX 프로젝트는 축소되는 하드웨어 로드맵에도 불구하고 엔클레이브가 여전히 필요한 이유를 입증해야 한다. 신규 TDX 프로젝트는 전체 게스트가 수용 가능한 보안 경계인 이유를 입증해야 한다.
따라서 Intel TDX 마이그레이션은 전면적인 재작성 방식이 아니라 위험 기반 포트폴리오로 진행해야 한다. 일부 워크로드는 조기에 이전할 수 있지만, 다른 워크로드는 남아 있는 SGX 지원 기간을 활용해야 한다.
Intel이 TDX를 선택한 이후 주목할 점
세 가지 신호가 Intel이 더 간결한 로드맵을 신뢰할 수 있는 기밀 컴퓨팅 플랫폼으로 전환할 수 있는지를 보여줄 것이다.
첫 번째 신호는 Diamond Rapids의 구체적인 출시 일정이다. Intel은 2027년 프로세서를 마지막 SGX 세대로 제시했지만, 고객에게는 정확한 플랫폼 일정과 제품 적용 범위가 필요하다.
이 세부 사항은 실질적인 마이그레이션 일정을 결정한다. 안정적인 SGX 지원을 갖춘 폭넓은 Diamond Rapids 포트폴리오는 선택지를 유지해 줄 것이다. 공급이 제한되면 특화된 enclave 배포 환경을 운영하는 고객의 부담은 커질 것이다.
두 번째 신호는 실제 배포 가능한 TDX Connect 지원이다. Intel은 기밀 AI와 디바이스 연결 워크로드를 위한 핵심 확장 기능으로 신뢰할 수 있는 I/O를 설명해 왔다. 구매자는 출하 가능한 하드웨어, 호환 가속기, 펌웨어 가이드, 독립적인 검증을 필요로 한다.
이 신호는 Intel의 agentic AI 주장을 강화하거나 약화시킬 것이다. 폭넓고 검증된 지원은 TDX가 AI 처리 경로의 더 많은 부분을 보호하는 데 도움이 될 것이다. 지연이 발생하면 소프트웨어 우회책과 분절된 신뢰 경계가 계속 남게 된다.
세 번째 신호는 클라우드 및 소프트웨어 공급업체의 마이그레이션 행보다. Azure, Google Cloud, IBM Cloud, Alibaba Cloud, Red Hat, Canonical, VMware는 이미 TDX 생태계의 일부를 이루고 있다. 이들의 서비스 로드맵은 고객이 Intel의 방향을 따르는지 보여줄 것이다.
새로운 기밀 가상 머신 리전, 더 강력한 attestation 도구, 기밀 컨테이너 지원, SGX 기반 서비스에서의 전환을 문서화한 사례를 주시해야 한다. 공급업체가 특화된 제품을 위해 SGX를 유지하는지도 살펴볼 필요가 있다.
경쟁사의 움직임도 유용한 기준점이 된다. AMD SEV-SNP의 채택 확대나 가속기 수준의 대안 강화는 시장이 단일 공급업체로 수렴하지 않고도 기밀 가상 머신을 지원한다는 점을 보여줄 것이다.
가장 큰 불확실성은 보안 세분성에 있다. TDX의 운영 단순성은 가치가 있지만, SGX의 좁은 enclave 경계를 재현하지는 않는다. 엄격한 분리 요구 사항을 가진 고객은 더 넓은 신뢰 도메인이 수용 가능한지 판단해야 한다.
Intel은 이들 고객에게 시간을 제공하고 있지만, 무기한의 로드맵을 제시하는 것은 아니다. Diamond Rapids는 Xeon에서 SGX를 지원하는 마지막 계획된 단계다. 이후의 모든 Intel 서버 세대는 신규 배포를 TDX로 이끌게 된다.
개발자와 기업 구매자가 취해야 할 다음 조치는 구체적이다. SGX가 운영 시스템을 보호하는 위치를 목록화하고, 각 enclave가 존재하는 이유를 문서화하며, TDX가 필요한 보장 수준을 유지하는지 테스트해야 한다.
지원 종료일을 출발 신호로 취급해서는 안 된다. 지원 기간을 활용해 아키텍처를 비교하고, attestation 정책을 검증하며, 공급업체에 구체적인 배포 약속을 요구해야 한다.
Intel의 SGX 단계적 폐지는 궁극적으로 enclave 특화보다 운영 규모를 선택한 결정이다. 이 선택의 성공 여부는 보안 증거, 생태계 실행력, 실제 마이그레이션 경로의 품질에 달려 있다.
