주식회사 텐 | AIPub RBAC 심층 가이드: GPU 너머 전체 스택 접근 제어 설계하기

"K8s RBAC만으로 GPU 인프라 보안이 된다고 생각하셨나요? 스토리지와 이미지는 어떻게 통제하고 계신가요?"

여러 팀이 같은 GPU 클러스터를 공유하는 환경은 이제 예외가 아니라 기본입니다. 엔터프라이즈의 AI팀·데이터팀·DevOps팀이 같은 클러스터를 쓰고, 대학에서는 여러 연구실이 GPU 서버를 나눠 쓰고, GPUaaS 사업자는 수십 개 고객사가 동일 인프라 위에서 워크로드를 실행합니다.

문제는 이 공유 환경에서 Kubernetes의 기본 RBAC만으로는 GPU 인프라를 안전하게 격리할 수 없다는 점입니다.

이 글에서는 K8s RBAC의 구조적 한계가 무엇인지, 왜 GPU 인프라에는 전체 스택에 걸친 접근 제어가 필요한지, 그리고 AIPub이 이 문제를 어떻게 해결하는지를 실전 가이드로 정리합니다.

Kubernetes RBAC는 무엇을 하고, 무엇을 못 하는가

먼저 K8s RBAC가 잘 하는 것부터 살펴봅시다.

Kubernetes RBAC는 클러스터 내에서 "누가 어떤 API 리소스에 어떤 작업을 할 수 있는지"를 제어합니다. Pod 생성, Deployment 수정, Service 조회 등 Kubernetes API 수준의 접근 권한을 네임스페이스 단위로 관리할 수 있습니다. 멀티테넌시의 첫 번째 레이어로서 K8s RBAC는 필수적입니다.

하지만 GPU 인프라 환경에서 K8s RBAC에는 명확한 한계가 있습니다.

첫째, K8s RBAC는 API 접근만 제어합니다. 네트워크 트래픽이나 실제 자원 소비는 통제하지 못합니다. RBAC를 설정했더라도 NetworkPolicy 없이는 모든 Pod가 네임스페이스와 무관하게 서로 통신할 수 있고, ResourceQuota 없이는 한 테넌트가 클러스터 자원을 전부 소비해 다른 테넌트에 영향을 줄 수 있습니다.
둘째, K8s는 GPU를 "전체 단위"로만 할당합니다. GPU 1개를 여러 팀이 나눠 쓰는 세밀한 제어가 기본적으로 불가능합니다. Kubernetes의 네이티브 멀티테넌시 기능에는 GPU 레벨의 테넌시가 포함되어 있지 않습니다.
셋째, 컨테이너 이미지와 스토리지는 RBAC 밖에 있습니다. K8s RBAC로 Pod 생성 권한을 제한해도, 이미지 레지스트리에 대한 접근이나 스토리지 볼륨의 팀별 격리는 별도로 관리해야 합니다. GPU는 잘 나눴는데, 다른 팀의 이미지를 가져다 쓸 수 있거나 다른 팀의 데이터에 접근할 수 있다면 격리는 무의미합니다.

결과적으로 K8s RBAC는 멀티테넌시의 필요조건이지, 충분조건이 아닙니다. 공유 GPU 인프라의 보안은 RBAC 위에 네트워크 격리, 자원 격리, 이미지·스토리지 격리가 함께 갖춰져야 비로소 완성됩니다.

GPU 인프라에서 접근 제어가 특히 중요한 이유

일반적인 웹 서비스 클러스터와 달리, GPU 인프라 환경에서 접근 제어의 중요성은 더욱 높아집니다.

GPU 자원은 비쌉니다. H100 한 대의 시간당 비용이 $2~3이고, 잘못된 접근이나 무단 사용이 곧 실질적인 금전 손실로 이어집니다. 공유 GPU 인프라에서 자원 격리는 거버넌스 차원의 선택이 아니라 운영상의 필수 요건입니다.
에이전틱 AI가 접근 제어의 복잡성을 한 단계 높였습니다. 에이전트가 자율적으로 파일을 읽고, 코드를 실행하고, 외부 서비스에 접근하고, 하위 에이전트를 생성하는 환경에서는 "이 에이전트가 어디까지 접근할 수 있는지"를 명확히 정의하지 않으면 보안 사고로 이어질 수 있습니다.
멀티테넌트 환경의 "Noisy Neighbor" 문제도 있습니다. 제어되지 않는 연구 워크로드가 프로덕션 추론 엔드포인트의 지연 시간을 높이는 상황은 실제로 빈번합니다. 자원 격리가 불완전하면 한 팀의 실험이 다른 팀의 서비스 품질을 떨어뜨립니다.
규제 환경도 강화되고 있습니다. 금융, 공공, 의료 등 규제 환경에서는 공유 인프라가 각 레이어에서 격리되어 있음을 증명해야 합니다. 네임스페이스, RBAC, 네트워킹, 워크로드 수준에서 문서화된 통제가 있는 멀티테넌시가 "팀마다 별도 클러스터"보다 오히려 더 일관된 보안 수준을 제공할 수 있습니다.

AIPub의 전체 스택 RBAC 아키텍처

AIPub은 K8s RBAC의 한계를 보완하는 것이 아니라, GPU 인프라를 위한 전용 접근 제어 계층을 그 위에 추가합니다.

핵심 개념은 통합 리소스 집합(Unified Resource Set)입니다.

AIPub은 GPU 노드, 컨테이너 이미지(ImageHub), 스토리지 볼륨(Volume)을 하나의 통합 리소스 집합으로 관리합니다. K8s RBAC가 API 리소스를 네임스페이스 단위로 제어한다면, AIPub RBAC는 GPU 인프라의 실제 자원을 팀·프로젝트·역할 단위로 통합 제어합니다.

이 세 가지를 하나의 정책으로 관리하는 이유는 명확합니다. GPU를 아무리 세밀하게 나눠도, 이미지 레지스트리와 스토리지가 열려 있으면 격리가 깨지기 때문입니다. 전체 스택을 하나의 정책으로 통합해야 비로소 진짜 격리가 완성됩니다.

AIPub이 제어하는 3가지 리소스:

GPU 노드: 블록 단위(최대 100블록) 정밀 배정. 각 팀/프로젝트에 필요한 만큼만 GPU 자원을 할당하고, 할당 범위를 넘는 접근을 차단합니다.
ImageHub: 팀별 컨테이너 이미지 레지스트리 격리. 각 프로젝트는 자신에게 허용된 이미지만 사용할 수 있으며, 다른 팀의 이미지에 접근할 수 없습니다.
Volume: 프로젝트별 스토리지 볼륨 접근 제어. 학습 데이터, 모델 체크포인트, 로그 등 프로젝트별 데이터가 다른 프로젝트에 노출되지 않도록 격리합니다.

계층 구조: Admin → Project Manager → Member

AIPub의 RBAC는 3단계 계층 구조로 설계되어 있습니다.

Admin(인프라 관리자)은 전체 리소스 풀을 관리합니다. GPU 노드 풀, ImageHub, Volume 풀을 설정하고, 프로젝트를 생성하며, 각 프로젝트의 Project Manager를 지정합니다. 클러스터 전체의 보안 정책과 자원 할당의 최상위 권한을 가집니다.

Project Manager(프로젝트 리더)는 Admin이 배정한 리소스 범위 안에서 구성원의 접근 권한을 세밀하게 설정합니다. GPU 블록 배분, 이미지 접근 범위, 볼륨 마운트 권한을 결정합니다. 팀의 실무 운영을 책임지는 역할입니다.

Member(연구원/개발자)는 할당된 리소스 내에서 워크로드를 실행합니다. 다른 프로젝트의 GPU 블록, 이미지, 볼륨에는 접근할 수 없으며, 자신에게 배정된 범위 안에서만 작업합니다.

이 계층 구조의 장점은 Admin이 모든 세부 권한을 직접 관리하지 않아도 된다는 점입니다. Admin은 프로젝트 단위로 자원을 배정하고, 세부 권한 관리는 각 Project Manager에게 위임합니다. 조직이 커질수록 이 위임 구조가 운영 효율에서 큰 차이를 만듭니다.

시나리오별 RBAC 설계 예시

AIPub RBAC가 실제 환경에서 어떻게 적용되는지, 세 가지 대표 시나리오를 살펴보겠습니다.

[시나리오 A: 대학/연구소]

3개 연구실이 8-GPU 서버 1대를 공유하는 환경입니다.

Admin(전산팀)이 각 연구실을 프로젝트로 생성하고, 연구실장을 Project Manager로 지정합니다. 연구실 A에 GPU 30블록, 연구실 B에 40블록, 연구실 C에 30블록을 배정합니다. 각 연구실의 ImageHub와 Volume은 독립적으로 격리되어, 연구실 간 학습 데이터와 모델이 교차 접근되지 않습니다.

연구실장은 자기 연구실 내에서 대학원생과 연구원에게 블록을 세부 배분합니다. 교내 예산 배분이나 외부 과제 정산에 필요한 연구실별 사용량 리포트도 자동 생성됩니다.

[시나리오 B: 엔터프라이즈]

AI팀, 데이터팀, DevOps팀이 GPU 클러스터를 공유하는 환경입니다.

Admin(인프라팀)이 각 부서를 프로젝트로 생성하고, 부서별 GPU 블록 할당과 ImageHub·Volume 접근 범위를 설정합니다. AI팀의 학습 모델 이미지가 DevOps팀에 노출되지 않고, 데이터팀의 전처리 데이터가 AI팀의 Volume에서 분리됩니다.

부서별 GPU 사용량은 블록 단위로 추적되어 Chargeback 리포트로 자동 생성됩니다. "우리 부서는 할당받은 만큼 못 썼는데 왜 같은 비용을 내야 하나요?"라는 질문에 데이터로 답할 수 있습니다.

[시나리오 C: GPUaaS 사업자]

다수 고객사가 동일 클러스터에서 워크로드를 실행하는 환경입니다.

각 고객사를 프로젝트로 생성하고, 고객사 간 완전한 멀티테넌트 격리를 적용합니다. 고객사 A의 워크로드가 고객사 B의 GPU 블록, 이미지, 스토리지에 접근할 수 없으며, 성능 간섭(Noisy Neighbor)도 공간분할 방식으로 최소화됩니다.

고객사별 사용량은 블록 단위로 정밀 추적되어 사용량 기반 과금의 근거가 됩니다. 과잉 프로비저닝 없이 필요한 만큼만 자원을 배정하고, 유휴 블록은 동적 할당으로 재배분해 클러스터 전체 활용률을 높일 수 있습니다.

K8s RBAC vs AIPub RBAC 비교

두 시스템은 대체 관계가 아니라 보완 관계입니다.
AIPub RBAC는 K8s RBAC를 대체하는 것이 아니라, 그 위에 GPU 인프라 전용 접근 제어 계층을 추가하는 구조입니다.

RBAC 자가진단 체크리스트

지금 우리 조직의 GPU 인프라 접근 제어 수준을 점검해 보세요.

✅ GPU 자원을 팀·프로젝트 단위로 세밀하게 배정하고 접근을 제어하고 있는가?
✅ 컨테이너 이미지 레지스트리가 팀별로 격리되어 있는가, 아니면 누구나 접근 가능한가?
✅ 스토리지 볼륨이 프로젝트별로 분리되어 있는가, 아니면 교차 접근이 가능한가?
✅ 한 팀의 워크로드가 다른 팀의 GPU 성능에 영향을 주는 Noisy Neighbor 문제가 통제되고 있는가?
✅ 팀별·프로젝트별 GPU 사용량을 추적하고 비용을 귀속시킬 수 있는가?

하나라도 "아니요"라면, GPU 인프라의 접근 제어에 구조적 빈틈이 있을 가능성이 높습니다.

에이전틱 AI 시대에 RBAC는 "있으면 좋은 기능"이 아니라 보안의 기본 토대입니다. 에이전트가 자율적으로 인프라 전체 스택을 소비하는 환경에서, GPU 레벨의 접근 제어만으로는 충분하지 않습니다. GPU 노드, 이미지, 스토리지까지 하나의 정책으로 통합 관리해야 비로소 안전한 공유 환경이 완성됩니다.

AIPub은 GPU 노드, ImageHub, Volume을 통합 리소스 집합으로 관리하고, Admin → Project Manager → Member의 계층 구조로 권한을 위임하며, 블록 단위 자원 격리와 사용량 추적을 하나의 플랫폼에서 제공합니다.

GPU 인프라의 접근 제어를 체계적으로 설계하고 싶다면, 혼자 고민하지 마세요.
TEN의 전문가와 함께 우리 조직에 맞는 RBAC 구조를 설계해 보세요!

👉 AIPub 자세히 보기: https://ten1010.io/products/aipub-dev
📩 전문가와 직접 상담하기: https://ten1010.io/inquiry