제7부 엔터프라이즈 운영과 MLOps

7.6 AI 인프라 보안 — 컨테이너·공급망·쿠버네티스

7.6.1 이 장에서 배우는 것 / 선수 지식

제7부(7.1~7.7)는 GPU 클러스터를 운영하는 법(GPU Operator·DCGM·가상화·공유·MLOps)을 다뤘다. 그런데 그 운영 도구들이 다루는 대상 — 컨테이너 이미지·모델 가중치·쿠버네티스 클러스터 — 은 전부 공격면(attack surface) 이기도 하다. 일반 소프트웨어 보안(코드 취약점·네트워크 침입)은 이미 성숙한 분야지만, AI 워크로드는 코드 못지않게 비중이 큰 두 가지를 더 신뢰해야 한다 — 남이 만든 컨테이너 이미지와 남이 학습한 모델 가중치. 이 장은 이 둘을 중심에 두고, GPU 클러스터·쿠버네티스 운영의 보안 함의를 판다.

핵심 통찰: AI 인프라의 공급망은 코드보다 넓다. 전통 소프트웨어 공급망은 "이 라이브러리를 신뢰하는가"를 묻지만, AI 파이프라인은 거기에 "이 컨테이너 이미지 전체를 신뢰하는가"·"이 수십 GB 가중치 파일을 신뢰하는가"·"이 데이터셋을 신뢰하는가"를 더한다. 그리고 가중치 파일은 역사적으로 코드 실행 경로(직렬화 포맷의 함정, 아래 7.6.4)이기도 했다 — "단순한 숫자 배열"이 아니다. 이 장은 번호상 제7부 끝(7.7) 다음에 붙지만(추가 순서), 내용은 7.5(가상화·공유) 직후 — 7.7(MLOps) 직전 자리에 속한다.

배우는 것:

• 왜 AI 인프라 보안이 별도 관심사인가 — 컨테이너·모델 가중치·데이터셋이라는 AI 특유의 넓은 공급망.
• 컨테이너 이미지 공급망 — 이미지 출처·서명·취약점 스캔·SBOM.
• 모델 가중치·체크포인트의 신뢰 — 직렬화 포맷의 코드 실행 위험과 완화(safetensors류), 출처 검증.
• 쿠버네티스 GPU 클러스터의 접근 통제 — RBAC·네임스페이스·네트워크 정책·GPU 쿼터 남용.
• 시크릿·자격증명 관리 — API 키·레지스트리 토큰을 이미지·코드에 심지 않는 법.
• 멀티테넌시 격리의 보안 함의 — MIG(하드 격리) vs MPS·타임슬라이싱(약한 격리), 신뢰 안 되는 테넌트를 어디에 두나(7.5 연결).

선수 지식: 7.1(AI Enterprise — 지원·패칭의 가치)·7.2(GPU Operator — 클러스터 권한의 범위)·7.3(DCGM·모니터링)·7.4~7.5(vGPU·MIG·MPS — 공유와 격리 스펙트럼)·7.7(MLOps — 파이프라인·레지스트리). 컨테이너·쿠버네티스(이미지·파드·네임스페이스·RBAC)의 기초는 가정한다(BK-02). 환경은 0.3·7.2.

정직(중요): 이 장은 일반 클라우드 네이티브·DevSecOps 보안을 GPU/AI 워크로드 맥락에 적용하는 원리를 가르친다 — 대부분의 기법(이미지 스캔·RBAC·시크릿 관리)은 엔비디아 고유가 아니라 컨테이너·쿠버네티스 생태계 전반의 관행이며, NVIDIA 특유의 지점은 GPU Operator의 권한 범위·NGC 이미지·MIG/MPS의 격리 강도 정도다. 구체 도구·CVE·API·규정 준수 요건은 시점·조직·관할 의존이 매우 크다 — 이 장은 개념·사고 틀을 가르치고, 실제 보안 설계·감사·인증은 자격 있는 보안 엔지니어·조직의 보안팀의 영역이다. 이 책으로 프로덕션 보안을 보증할 수 없다.

7.6.2 왜 AI 인프라 보안이 별도 주제인가

일반 애플리케이션의 공급망은 대략 "코드 + 라이브러리 의존성"이다. AI 파이프라인은 그 위에 두 겹을 더 쌓는다:

• 컨테이너 이미지가 크고 깊다: NGC·Docker Hub 등에서 받는 딥러닝 이미지는 OS + CUDA + cuDNN + 프레임워크(PyTorch 등) + 앱 코드까지 수 GB 규모의 단일 신뢰 단위다. 레이어 하나하나의 출처·패치 상태를 다 확인하기 어렵다.
• 모델 가중치가 새로운 종류의 아티팩트다: 소스코드는 리뷰·정적분석 관행이 성숙했지만, "이 78억 개 숫자가 안전한가"는 다른 질문이다 — 숫자 자체는 무해해 보여도, 그 숫자를 담는 파일 포맷이 임의 코드를 실행시킬 수 있었던 역사가 있다(7.6.4).
• AI 인프라 보안 = 전통 보안 + AI 특유의 공급망: RBAC·네트워크 정책·시크릿 관리 같은 전통 클라우드 네이티브 보안은 그대로 필요하고(7.6.5·7.6.6), 거기에 이미지·가중치 공급망(7.6.3·7.6.4)이 추가로 적층된다.

견해: AI 인프라 보안 팀이 가장 먼저 물어야 할 질문은 "이 코드가 안전한가"가 아니라 "이 이미지·이 가중치가 어디서 왔고, 왜 신뢰하는가" 다 — AI 파이프라인의 신뢰 경계는 전통 앱보다 훨씬 크고 불투명하다.

7.6.3 컨테이너 이미지 공급망

출처(provenance): NGC(NVIDIA)·Docker Hub·조직 내부 레지스트리 등 어디서 받았는가가 신뢰의 출발점이다. NVIDIA 공식 NGC 이미지는 NVIDIA가 빌드하며 무결성 검증 장치(서명 등)를 제공하지만(정확한 방식·범위는 시점 의존, 확인 필요), 그 위에 조직이 레이어를 추가하면(커스텀 앱·의존성 추가) 그 레이어의 보안은 조직 책임이다.

취약점 스캔: 이미지의 각 레이어(OS 패키지·언어 런타임 라이브러리)를 알려진 CVE 데이터베이스와 대조하는 스캐너(범용 도구 — Trivy·Grype·클라우드 벤더 스캐너 등, 특정 제품명은 시점 의존)를 CI/CD 파이프라인에 넣어 빌드 시점에 취약점을 검출한다. 딥러닝 이미지는 크고 레이어가 많아(CUDA·cuDNN·프레임워크·수백 개 파이썬 패키지) 스캔 대상이 넓다.

서명·검증: 이미지가 빌드 후 변조되지 않았음을 암호학적으로 보증하려면 이미지 서명(예: Sigstore/cosign류 — 특정 프로젝트명은 생태계 진화 중, 확인 필요)을 쓴다. 배포 파이프라인이 서명 없는(또는 검증 실패한) 이미지를 거부하도록 정책화한다.

SBOM(Software Bill of Materials): 이미지 안에 무엇이 들었는지(OS 패키지·라이브러리·버전)를 목록화한 문서. 새 CVE가 발표됐을 때 "우리 이미지 중 몇 개가 영향받는가"를 SBOM으로 빠르게 조회한다 — 매번 이미지를 다시 스캔하지 않고도.

비엔비디아 정직: 이미지 스캔·서명·SBOM은 컨테이너 생태계 전반의 관행(NVIDIA 이미지에 국한 안 됨)이다. NVIDIA 딥러닝 이미지가 특히 크고(수 GB) 레이어가 많다는 점만 AI 워크로드 특유의 강조점이다.

7.6.4 모델 가중치·체크포인트의 신뢰

직렬화 포맷의 함정: 딥러닝 프레임워크의 전통적 저장 포맷(예: 파이썬 pickle 기반 직렬화)은 객체를 저장할 뿐 아니라 로드 시점에 임의 코드를 실행할 수 있는 구조였다 — 악의적으로 조작된 체크포인트 파일을 load 하는 것만으로 공격자의 코드가 실행될 수 있다는 뜻이다. 이는 이론적 우려가 아니라 커뮤니티가 실제로 겪어 온 문제이고, 그 대응으로 가중치만 담고 임의 코드 실행 경로가 없는 포맷(예: safetensors류 — weights-only, 역직렬화 시 코드 실행 없음)이 자리 잡았다. 정확한 포맷명·프레임워크별 기본값은 생태계가 빠르게 바뀌므로 시점 의존, 확인 필요.

출처 검증: 모델 허브(Hugging Face Hub·NGC 등)에서 받은 가중치는 "누가 학습했나·원본과 같은가"를 확인하기 어려운 경우가 많다 — 체크섬·서명·허브의 검증 배지(있다면)를 확인하고, 프로덕션에 배포하기 전 격리된 환경에서 로드·스캔하는 절차를 둔다.

공급망 관점의 파인튜닝: 6.4(LoRA)처럼 남이 만든 어댑터·파인튜닝 가중치를 가져다 쓸 때도 같은 신뢰 문제가 있다 — 어댑터 파일도 결국 직렬화된 아티팩트다.

견해: "가중치 파일은 순수 데이터"라는 통념은 역사적으로 틀렸다 — 로드 경로가 코드 실행을 허용하는 포맷이면 데이터가 아니라 페이로드다. weights-only 포맷을 기본으로 쓰고, 신뢰 못 하는 출처의 체크포인트는 격리된 샌드박스에서만 연다.

7.6.5 쿠버네티스 GPU 클러스터의 접근 통제

GPU Operator(7.2)가 노드에 드라이버·컨테이너 툴킷·디바이스 플러그인을 자동 설치한다고 배웠다 — 드라이버·커널 모듈 설치는 본질적으로 호스트 특권 수준의 작업이라, GPU Operator 자체가 신뢰 경계라는 것이 이 절의 확장이다(7.2은 운영 편의 관점에서 이를 다루며, 권한·보안 프레이밍 자체는 이 장이 더한 것). 클러스터 접근 통제는 전통 쿠버네티스 보안과 GPU 특유의 리소스 통제가 겹친다:

GPU 리소스 남용의 특수성: 일반 CPU/메모리는 오버커밋·throttling으로 어느 정도 완화되지만, GPU는 (MIG가 아닌 한) 온전한 장치 단위로 배정되는 경우가 많아 한 파드가 GPU를 붙잡으면 다른 테넌트가 완전히 못 쓴다 — 쿼터·스케줄링 정책(7.3)이 곧 보안·공정성 문제로 이어진다.

7.6.6 시크릿·자격증명 관리

AI 파이프라인은 자격증명이 유난히 많다 — 모델 허브 토큰(Hugging Face·NGC API 키)·클라우드 스토리지 키·데이터베이스·모니터링 대시보드 접근키 등. 흔한 실수와 대응:

• 이미지에 하드코딩 금지: API 키를 Dockerfile이나 코드에 하드코딩해 이미지에 포함하지 않는다 — 이미지가 유출되면 키도 함께 유출된다.
• 쿠버네티스 Secrets(또는 외부 볼트)로 주입: 런타임에 환경변수·볼륨으로 주입하고, 이미지 자체는 자격증명 없이 이식 가능하게 유지.
• 회전(rotation): 유출·직원 이탈 시 키를 무효화·재발급할 수 있는 절차. 하드코딩된 키는 회전이 사실상 불가능(이미지를 전부 재빌드·재배포해야).
• 최소 권한: 노트북·실험 환경의 키가 프로덕션 레지스트리 전체를 쓸 수 있게 두지 않는다 — 용도별로 범위를 좁힌다.

7.6.7 멀티테넌시 격리의 보안 함의 (7.5 연결)

7.5에서 GPU 공유 방식의 격리 스펙트럼(타임슬라이싱 < MPS < vGPU < MIG, 약함→강함)을 배웠다. 그 격리 강도는 성능 트레이드오프였을 뿐 아니라 보안 경계이기도 하다:

견해: "이 GPU를 서로 모르는 팀·고객이 나눠 쓰는가"라는 질문에 답이 "그렇다"면 MIG(또는 VM 경계 vGPU) 로, "같은 조직·같은 신뢰 경계 안"이면 MPS·타임슬라이싱도 실용적이다. 격리 강도를 성능 지표로만 보지 말고 누구와 공유하는가로 결정한다(7.5의 선택 프레임에 보안 축 추가).

7.6.8 워크스루 — 보안 점검 체크리스트(개념 골격)

배포 전 점검 흐름(개략, 조직·도구마다 다름 — 개념 순서로 읽는다):

1) 이미지: 출처 확인(신뢰 레지스트리) → CVE 스캔 통과 → 서명 검증
2) 가중치: 출처 확인 → weights-only 포맷 확인(또는 격리 로드) → 체크섬 대조
3) 클러스터: 배포 네임스페이스 RBAC·쿼터 확인 → 네트워크 정책 적용 여부 확인
4) 시크릿: 이미지에 하드코딩된 키 없는지 grep(예: `docker history`·이미지 레이어 검사) → Secrets/볼트 주입 확인
5) 격리: 이 워크로드가 신뢰 안 되는 테넌트와 공유되는가 → 격리 방식 재확인(MIG 필요?)

# 예시(개념 골격 — 실제 명령·도구는 조직 정책·버전 의존):
# 이미지 취약점 스캔(범용 스캐너 예)
trivy image myregistry.example.com/my-training-image:tag

# 이미지 레이어에 하드코딩된 문자열(키 후보) 탐색
docker history --no-trunc myregistry.example.com/my-training-image:tag | grep -i "key\|token\|secret"

7.6.9 중간 점검 (체크포인트)

• [ ] AI 파이프라인의 공급망이 전통 소프트웨어보다 넓은 이유(컨테이너 이미지·모델 가중치·데이터셋)를 설명한다.
• [ ] 컨테이너 이미지 보안의 3요소(스캔·서명·SBOM)와 각각의 역할을 안다.
• [ ] 모델 가중치 직렬화 포맷이 왜 보안 문제일 수 있는지, weights-only 포맷이 무엇을 막는지 안다.
• [ ] 쿠버네티스 GPU 클러스터에서 RBAC·네임스페이스·네트워크 정책·쿼터가 각각 무엇을 통제하는지 안다.
• [ ] 시크릿을 이미지에 하드코딩하면 안 되는 이유와 대안을 안다.
• [ ] MIG·MPS·타임슬라이싱·vGPU의 격리 강도를 보안 경계 관점에서 다시 설명한다(7.5 연결).

증상→의심: 이미지가 크고 출처가 여럿 → 레지스트리 신뢰 정책·스캔 자동화 필요. 모델을 허브에서 받아 바로 프로덕션에 → 출처·포맷 미검증 → 격리 로드·weights-only 확인. 한 팀이 GPU 쿼터를 독점 → RBAC·쿼터 미설정. 이미지 유출 후 키 회전 불가 → 하드코딩 확인. 상호 비신뢰 테넌트가 MPS 공유 → MIG로 격리 강화 검토.

7.6.10 트레이드오프·대안

비엔비디아 정직: 이 장에서 다룬 관행(이미지 스캔·서명·RBAC·시크릿 관리·SBOM)은 컨테이너·쿠버네티스 생태계 전반의 표준 관행이며 특정 벤더 종속이 아니다. NVIDIA 특유의 지점은 GPU Operator의 노드 권한 범위와 MIG/MPS/타임슬라이싱의 격리 강도뿐이다. 조직에 이미 클라우드 보안팀·정책이 있다면 이 장은 "GPU/AI 워크로드에 그 정책을 어떻게 적용하는가"의 체크리스트로 쓰인다.

7.6.11 흔한 함정

• "가중치는 단순한 숫자"라는 가정. 직렬화 포맷에 따라 로드가 코드 실행일 수 있다 — weights-only 포맷·격리 로드 확인.
• 이미지에 API 키 하드코딩. 이미지 유출 = 키 유출. Secrets/볼트로 주입.
• GPU Operator 권한을 당연시. 노드 커널 모듈 설치급 권한이다 — 배포·업데이트 채널의 신뢰를 확인.
• 스캔을 배포 후에만. 취약점은 빌드 시점(CI)에 검출하는 것이 비용이 낮다 — 배포 후 발견은 롤백·긴급 패치 비용.
• MPS를 상호 비신뢰 테넌트에. 공간 공유는 하드 격리가 아니다 — 신뢰 경계를 넘는 공유엔 MIG(7.5).
• 네임스페이스만 나누고 네트워크 정책은 생략. 논리적 분리(네임스페이스)와 트래픽 통제(네트워크 정책)는 별개 — 둘 다 필요.
• 모델 허브 다운로드를 그대로 프로덕션에. 출처 미검증 가중치를 격리 없이 로드 — 스캔·격리 절차 없이 신뢰 확장.

7.6.12 연습문제

연습 1 (공급망 비교). 전통 소프트웨어 공급망과 AI 파이프라인 공급망의 차이를 설명하고, AI 파이프라인에 새로 추가되는 신뢰 단위 두 가지를 제시하라.

연습 2 (가중치 신뢰). 한 팀이 모델 허브에서 받은 체크포인트를 곧바로 프로덕션 서빙 파이프라인에 로드하려 한다. 어떤 리스크가 있고, 어떻게 완화하나?

연습 3 (격리 선택). SaaS 회사가 서로 경쟁 관계인 두 고객사의 파인튜닝 작업을 같은 GPU 클러스터에서 서빙하려 한다. 어떤 공유 방식을 권하고, 왜 MPS/타임슬라이싱은 부적합한가?

7.6.13 요약 · 다음 장

• AI 인프라 보안은 전통 소프트웨어 보안에 컨테이너 이미지 전체·모델 가중치·데이터셋이라는 AI 특유의 넓은 공급망을 더한 것이다.
• 컨테이너 이미지: 출처·취약점 스캔(CI에서)·서명·SBOM으로 신뢰를 관리한다.
• 모델 가중치: 직렬화 포맷이 코드 실행 경로였던 역사가 있어 weights-only 포맷·출처 검증·격리 로드가 중요하다.
• 쿠버네티스: RBAC·네임스페이스·네트워크 정책·쿼터로 접근·자원을 통제한다. GPU Operator는 노드 권한이 크다는 것 자체가 신뢰 경계.
• 시크릿: 이미지에 하드코딩하지 않고 Secrets/볼트로 주입, 회전 가능하게.
• 격리: MIG(하드)·vGPU(하이퍼바이저)·MPS(공간, 약함)·타임슬라이싱(없음)의 스펙트럼(7.5)은 성능 트레이드오프이자 보안 경계다 — 신뢰 안 되는 테넌트일수록 강한 격리로.
• 정직: 대부분의 관행은 클라우드 네이티브 생태계 전반의 것이며, 실제 보안 설계·감사는 자격 있는 보안 엔지니어의 영역이다.

번호는 이 장이 책 끝(제7부 이후 추가 순서)이지만, 내용은 7.5(가상화·공유) 바로 다음 — 7.7(MLOps) 직전 자리에 속한다. 다음 장(논리적으로): 7.7 MLOps 라이프사이클과 관측성. 인프라를 안전하게 운영하는 법을 봤으니, 그 위에서 실행되는 모델 파이프라인의 라이프사이클(버저닝·재현성·드리프트·관측성)로 제7부를 마무리한다.