GPU TEE와 모델 서명을 하나로 묶기: 주권형 멀티테넌트 AI를 위한 증명된 기밀 추론
이 글을 누가 읽으면 좋은가
이 글은 온프렘 또는 에어갭 환경에서 LLM 추론 서비스를 운영하거나, 병원·은행·정부기관처럼 데이터를 외부로 내보낼 수 없는 규제 산업 고객을 위한 AI 플랫폼을 설계하는 엔지니어를 위해 씁니다. GPU 기밀 컴퓨팅(confidential computing)과 원격 증명(remote attestation)이 무엇을 보장하고 무엇을 보장하지 않는지, 그리고 그 보장을 “어떤 모델 가중치가 실제로 서빙되었는가”라는 질문과 어떻게 연결해야 규제기관이 납득할 증거가 되는지를 다룹니다. Kubernetes와 Kueue 위에서 멀티테넌트 GPU 클러스터를 운영하는 조직이라면 특히 관련이 깊습니다.
문제의식: “우리를 믿어달라”는 규제기관에게 통하지 않는다
병원이나 정부기관, 은행이 자체 서버에 LLM을 올리려는 이유는 단순합니다. 데이터를 외부로 내보내지 않기 위해서입니다. 그런데 온프렘 배포의 진짜 목적은 제3자를 배제하는 데서 그치지 않습니다. 갈수록 요구되는 것은 플랫폼을 운영하는 회사 자신조차 테넌트의 데이터를 들여다보지 못하고, 몰래 모델을 바꿔치기하지 못한다는 보장입니다. 문제는 플랫폼 운영자가 클러스터의 root 권한을 쥐고 스케줄러를 통제하며 모델 이미지를 직접 배포한다는 사실입니다. 규제받는 워크로드 앞에서 “저희를 믿어주세요”는 컴플라이언스 근거가 될 수 없습니다. 규제기관이 원하는 것은 약속이 아니라 증명입니다.
구체적으로 주권형 플랫폼은 어떤 추론 요청에 대해서든 사후에, 그리고 운영자를 신뢰하지 않는 제3자에게 두 가지를 증명할 수 있어야 합니다. 첫째는 데이터 기밀성 주장으로, 테넌트의 입력값과 모델 활성화값, 출력값이 GPU 기밀 컴퓨팅 엔클레이브 밖으로 평문 상태로 나간 적이 없다는 것입니다. 호기심 많은 운영자든 같은 클러스터를 쓰는 다른 테넌트든 네트워크 공격자든 이 값을 들여다볼 수 없어야 합니다. 둘째는 모델 프로버넌스 주장으로, 출력을 만들어낸 가중치가 조직의 감사·릴리스 게이트를 통과한 바로 그 아티팩트였다는 것이며, 백도어가 심어졌거나 몰래 파인튜닝되었거나 다른 버전으로 치환된 것이 아니라는 뜻입니다.
이 두 문제는 각각 튼튼한 선행 연구를 갖고 있지만 서로 따로 발전해 왔습니다. NVIDIA Hopper와 Blackwell 세대의 GPU TEE는 하드웨어 신뢰 루트와 원격 증명을 제공해 첫 번째 주장을 뒷받침할 수 있고, 모델 프로버넌스와 공급망 증명에 관한 연구는 학습·릴리스 주장을 모델 아티팩트에 묶어 두 번째 주장을 뒷받침할 수 있습니다. 상용 TEE 위에서 기밀 LLM 서빙을 구현한 시스템도 이미 존재합니다. 그러나 우리가 아는 한 어떤 시스템도 증명 근거 체인을 서명된 모델 프로버넌스 레코드에 암호학적으로 묶어 멀티테넌트 GPU 스케줄러 내부에서 강제하지는 않습니다. 원격 증명은 계산이 어디서 일어났는지를 말해주고, 프로버넌스는 어떤 코드와 가중치가 릴리스되었는지를 말해주지만, 어느 쪽도 “이 요청에 대해 감사받은 그 가중치가 증명된 그 엔클레이브 안에서 돌았다”는 것을 규제기관에게 말해주지 못합니다. 바로 이 이음매가 비어 있습니다.
핵심 기여: 증명과 프로버넌스를 요청 단위로 묶는 ACI 프로토콜
ThakiCloud AI Research가 제안하는 ACI(Attested Confidential Inference)는 RATS 스타일의 원격 증명 근거를 서명된 모델 프로버넌스 레코드에 묶고, 그 결합을 Kubernetes job admission 경계에서 강제하는 프로토콜입니다. 핵심 아이디어를 다섯 개의 논리적 컴포넌트로 나누어 보면, 먼저 릴리스 시점에 감사받은 가중치의 다이제스트와 학습 계보, 빌드 환경, 스캔 결과 같은 릴리스 주장을 서명해 프로버넌스 레코드 $P$를 만드는 프로버넌스 등록기(Provenance Registrar)가 있습니다. 다음으로 매 요청마다 신선한 nonce를 발급하고 GPU/CPU TEE로부터 증거를 받아 검증한 뒤 엔클레이브 측정값을 담은 증명 결과 $A$를 만드는 RATS Verifier 역할의 증명 브로커(Attestation Broker)가 있습니다.
이 둘이 만나는 지점이 논문의 핵심 객체인 바인딩 원장(Binding Ledger)입니다. $A$의 해시와 $P$의 해시, 테넌트 식별자, 요청 ID를 함께 서명해 결합 레코드 $B$를 만들고 append-only 원장에 기록합니다. 이 결합이 곧 “증명된 그 엔클레이브 안에서 감사받은 그 가중치가 서빙되었다”는 단일 서명 증거입니다. 이 검증은 Kueue admission 게이트에서 GPU job을 실제로 스케줄링하기 전에 강제되어, 유효한 결합이 없으면 테넌트 신원과 매칭되는 GPU job이 admit되지 않습니다. 마지막으로 규제기관이 요청 ID만으로 ${A, P, B}$ 전체를 조회하고 서명과 엔클레이브 측정값을 운영자와 독립적으로 재검증할 수 있는 읽기 전용 규제기관 검증 API가 놓입니다.
ACI의 요청 단위 결합 과정을 개념적으로 나타낸 그림입니다. 증명 결과 $A$와 프로버넌스가 검증된 가중치 다이제스트 $P$가 Kueue admission 게이트에서 만나 서명된 결합 $B$를 만듭니다. 실측 하드웨어가 아닌 프로토콜 설계를 시각화한 예시입니다.
여기서 짚어야 할 정직한 지점이 있습니다. 실행 중인 다이제스트를 서명된 참조값과 비교하는 것 자체는 새로운 암호학적 기법이 아닙니다. measured boot나 DICE, TPM quote-vs-golden-value 같은 이미 확립된 measured-launch 패턴과 같은 종류이고, 서명된 릴리스 주장을 아티팩트에 묶는 일도 선행 연구가 이미 하고 있습니다. 이 논문이 정직하게 방어할 수 있는 기여는 새로운 암호 기법이 아니라 합성(composition)입니다. GPU TEE 원격 증명을 서명된 모델 프로버넌스 검증과 결합해, 멀티테넌트 Kubernetes+Kueue 시스템 안에서 스케줄러 admission 시점에 강제되는 요청 단위·규제기관 검증 가능 게이트로 만든 것은 우리가 아는 한 이 작업이 처음입니다.
논문은 취약점 하나를 숨기지 않고 정면으로 다룹니다. 증거가 생성되는 시점(3단계)과 가중치가 로드되어 실제로 요청이 서빙되는 시점(4~6단계) 사이에는 없앨 수 없는 TOCTOU(time-of-check-to-time-of-use) 간극이 존재합니다. 논문은 로드와 다이제스트 검사를 증명 이후로 순서화하고 둘을 하나의 결합 $B$에 함께 묶어 이 창을 좁히지만 완전히 없애지는 못한다고 명시합니다. 이 게이트가 root 권한을 쥔 운영자 자체를 막을 수는 없다는 점도 정직하게 인정합니다. 운영자가 게이트를 우회해 그림자 요청을 처리하면 유효한 결합 $B$가 생성되지 않고, 그 결과 원장에 기록이 남지 않는다는 사실 자체가 규제기관이 이후 청구 로그나 API 게이트웨이 요청 수와 원장을 대조해 발견할 수 있는 증거가 됩니다. 즉 이 게이트는 악의적 운영자를 사전에 막는 예방(prevention)이 아니라, 우회 시 검증 가능한 공백을 남기는 탐지(detection) 메커니즘으로 설계되었습니다.
오버헤드는 어떻게 예측했나: 실측 없이 인용값만으로 짓는 모델
이 논문에서 가장 정직한 부분은 성능 주장입니다. 저자들은 CC 모드 GPU 하드웨어에 접근할 수 없었기 때문에 단 하나의 실측값도 만들어내지 않았습니다. 대신 전체 지연 시간을 $L_{\text{ACI}} = L_{\text{base}} + L_{\text{TEE}} + L_{\text{att}}/N + L_{\text{ledger}}$라는 가산 모델로 분해하고, 각 항목의 값을 오직 인용된 선행 연구가 보고한 범위로만 채웁니다.
오버헤드 모델(식 1)의 각 항목을 출처가 명시된 범위로 정리한 그림입니다. $L_{\text{TEE}}$가 가장 크지만, $L_{\text{att}}$는 요청 수 $N$에 따라 상각되고 $L_{\text{ledger}}$는 파이프라인화하면 critical path에서 빠질 수 있습니다. 실측이 아닌 분석적 모델임을 밝힙니다.
선행 연구에 따르면 GPU 기밀 컴퓨팅 자체의 처리량 페널티($L_{\text{TEE}}$)는 전형적인 쿼리에서 7% 미만이고, 모델이 크고 시퀀스가 길어질수록 거의 0에 가까워집니다. 이는 지배적인 비용이 엔클레이브 내부 연산이 아니라 CPU-GPU 사이의 암호화된 PCIe 전송이기 때문입니다. 반면 ACI가 새로 추가하는 두 항목은 설계로 통제 가능합니다. 증명 핸드셰이크 비용($L_{\text{att}}$)은 같은 증명 세션이 더 많은 요청을 처리할수록 요청당 비용이 0에 가까워지고, 원장 기록 비용($L_{\text{ledger}}$)은 응답을 반환한 뒤 비동기로 처리하면 critical path에서 완전히 제거할 수 있습니다. 논문은 이 지점에서 스스로 선을 긋습니다. ACI의 한계 오버헤드가 결합 자체가 아니라 상각 정책에 의해 좌우될 것이라고 “예측”할 뿐, 그 예측에 구체적인 퍼센트를 붙이지 않습니다. 측정하지 않은 값에 숫자를 붙이지 않겠다는 이 원칙은 논문 전체를 관통합니다.
논문은 다섯 가지 요구사항(증명 신선도, 프로버넌스 결합, 부인 방지, 스케줄러 수준 격리, 수용 가능한 오버헤드)에 대해 세 종류의 공격자(호기심 많은 운영자, 악의적 공동 테넌트, 네트워크 공격자)를 각각 대입해 논증합니다.
다섯 가지 ACI 요구사항이 각각 어떤 공격자 유형에 대응하는지 정리한 매트릭스입니다. 스케줄러 격리 요구사항(R4)은 공동 테넌트와 운영자 두 유형 모두를 커버합니다. 실측이 아닌 위협 모델 분석 결과입니다.
회사·사회·과학에 대한 기여
ThakiCloud 입장에서 이 연구의 의미는 분명합니다. 지금 운영 중인 Keycloak 기반 테넌트 신원, Kueue GPU admission, ArgoCD GitOps 릴리스는 이미 격리 메커니즘으로 작동하고 있습니다. ACI는 이 기존 자산에 새로운 격리 장치를 더하는 대신 암호학적 결합 하나만 얹어, 지금 갖고 있는 멀티테넌트 격리를 규제기관이 검증 가능한 증거로 바꿉니다. 이는 2026년 하반기 릴리스가 겨냥하는 보안·셀프호스팅 방향, 그리고 국내 공공·금융 부문에서 요구되는 망분리·감사 가능성 요건과 정확히 맞닿아 있습니다.
사회적으로 보면 이 결합의 가치는 신뢰 장벽을 낮추는 데 있습니다. 병원이나 정부기관, 금융권처럼 프라이버시가 절대적인 조직이 “플랫폼 운영자를 신뢰해야만” LLM을 쓸 수 있다면 채택은 늦어질 수밖에 없습니다. 증명이 운영자의 정직함에 의존하지 않고 성립한다는 사실은 그 장벽을 실질적으로 낮춥니다.
과학적으로는 이 논문이 새로운 암호 기법을 주장하지 않는다는 점이 오히려 정직한 기여의 근거입니다. GPU TEE 원격 증명과 서명된 모델 프로버넌스 검증을 멀티테넌트 스케줄러 admission 시점에 요청 단위로 강제하는 조합은, 우리가 아는 한 선행 연구가 다루지 않은 자리입니다. 기존 연구들은 증명과 프로버넌스를 각각 따로 발전시켰고, Kubernetes 거버넌스 연구들도 하드웨어 증명에 뿌리를 두지 않은 채 오케스트레이션·텔레메트리 계층에서만 동작했습니다. ACI는 그 사이의 이음매를 처음으로 명시적으로 짚어 보여줍니다.
한계: 이 논문이 스스로 인정하는 것들
이 논문은 실측이 아니라는 사실을 감추지 않습니다. 평가에 사용할 수 있는 CC 모드 GPU 하드웨어나 증명 서비스가 없었기 때문에 ACI는 설계되고 분석되었을 뿐 측정되지는 않았습니다. Hopper/Blackwell CC 모드 위에서 실제로 구현해 $L_{\text{att}}/N$과 $L_{\text{ledger}}$ 항목을 직접 측정하는 일은 이후 과제로 남아 있으며, 이는 하드웨어 접근이 막혀 있기 때문이라고 명시합니다.
그 외에도 논문은 몇 가지 미해결 지점을 스스로 짚습니다. 여러 클러스터에 걸친 배포(MultiKueue)에서 단일 클러스터의 바인딩 원장만으로는 일관된 크로스 클러스터 감사 뷰를 만들 수 없다는 점, 증명 핸드셰이크를 여러 요청에 걸쳐 상각하는 정책이 엔클레이브를 세션 중간에 폐기해야 하는 상황(취약점 공개 등)과 상충한다는 점, 그리고 RAG 배포에서는 기밀성 주장이 모델 가중치뿐 아니라 검색 시점의 컨텍스트로도 확장되어야 한다는 점입니다. 또한 ACI는 서빙된 가중치가 서명된 프로버넌스 레코드와 일치함을 증명할 뿐, 그 프로버넌스 레코드 자체가 신뢰할 만한 모델을 기술하는지, 또는 릴리스 서명 키의 보관이 안전한지는 별개의 공급망 문제로 남겨둡니다.
논문에 관한 더 자세한 내용은 HuggingFace 데이터셋 페이지에서 확인하실 수 있습니다.