GKE shadow AI 추적, Google이 k8s-aibom으로 연 런타임 BOM

AI 거버넌스의 빈칸은 모델 카드보다 클러스터 안에 있다. 개발팀이 vLLM, Triton, Ollama, LangChain, AutoGen 같은 런타임과 agent framework를 빠르게 띄우면 보안팀은 “무엇이 실제로 실행 중인가”를 뒤늦게 확인하게 된다. Google Cloud가 2026년 7월 14일 공개한 k8s-aibom은 이 문제를 빌드 산출물이 아니라 Kubernetes 런타임에서 다룬다.

핵심은 가벼운 비권한 컨트롤러다. Google Cloud 설명에 따르면 k8s-aibom은 GKE를 포함한 Kubernetes 클러스터 API와 컨테이너 환경을 계속 관찰하면서 KServe 리소스, Deployment, StatefulSet, DaemonSet, Job을 훑는다. 그 과정에서 AI serving runtime, agent framework, vector database, RAG 저장소, 분산 학습 job, 평가 harness를 식별하고 OWASP CycloneDX 1.6 Machine Learning Bill of Materials 문서로 정리한다.

보안팀 입장에서 중요한 변화는 개발자 workflow를 건드리지 않는다는 점이다. pod spec 수정, sidecar 주입, privileged DaemonSet, eBPF kernel module 없이 단일 Deployment로 동작한다. 이미 운영 중인 AI workload를 느리게 멈춰 세우지 않고도 inventory를 만들 수 있다는 뜻이다. 특히 shadow AI처럼 공식 등록 없이 시작된 workload는 기존 scanner의 사각지대가 되기 쉬웠다.

k8s-aibom은 발견 결과를 “declared”, “inferred”, “unresolved”로 나눠 신뢰도를 표시한다. 명시적으로 모델명이 인자로 들어간 경우와 컨테이너 이미지·환경변수 패턴으로 추론한 경우를 분리하고, 버전이나 weight를 확정하지 못한 workload는 보안 검토 대상으로 올린다. 이 구분은 audit 문서에서 “사람이 선언한 구성”과 “도구가 추론한 상태”를 섞지 않게 만든다.

또 하나의 관전점은 증거 보존이다. Google Cloud는 외부 sink로 Cloud Storage를 쓸 때 object creation precondition을 적용해 한 번 기록된 ML-BOM이 조용히 덮어써지지 않도록 설계했다고 설명했다. 규제 대응에서는 EU AI Act의 logging·transparency 조항, NIST AI RMF, ISO/IEC 42001과 연결될 수 있다. AI 보안이 prompt guardrail만의 문제가 아니라 runtime asset inventory의 문제로 이동하고 있다는 신호다.