Google은 AI 워크로드를 감시하고 CycloneDX 1.6 ML-BOM 문서를 생성하는 Kubernetes 컨트롤러인 k8s-aibom을 오픈 소스로 공개했습니다.

이 문장은 마치 컴플라이언스(compliance) 연구실에서 커피를 너무 많이 마신 사람이 말하는 것처럼 들립니다.

하지만 계속 읽어보세요. 흥미로운 부분은 약어의 나열이 아닙니다. 흥미로운 점은 업계가 매우 지루한 진실을 서서히 인정하고 있다는 사실입니다. 즉, 인벤토리(inventory)를 파악할 수 없는 AI 시스템은 거버넌스(governance)를 수행할 수 없다는 것입니다.

스프레드시트로는 불가능합니다.

세 번의 릴리스 전에 누군가가 작성한 배포 계획(deployment plan)으로도 불가능합니다.

구석에 "TODO: vector db 추가"라고 여전히 적혀 있는 아키텍처 다이어그램(architecture diagram)으로도 불가능합니다.

런타임(runtime)으로부터 파악해야 합니다.

클러스터(cluster)로부터 파악해야 합니다.

실제로 트래픽을 처리하고, 모델 API를 호출하며, 임베딩(embeddings)을 보유하고, 평가 작업(evaluation jobs)을 실행하며, GPU 예산을 소모하고 있는 바로 그 대상으로부터 파악해야 합니다.

show me the inventory

모델은 시스템의 전부가 아닙니다

사람들이 AI 거버넌스(AI governance)에서 계속 범하는 실수는 모델을 관리의 단위로 취급하는 것입니다.

우리는 어떤 모델을 사용하고 있습니까?

그것은 어디에서 왔습니까?

오픈 소스입니까?

법무팀의 승인을 받았습니까?

이것들은 좋은 질문들입니다. 하지만 이것만으로는 충분하지 않습니다.

프로덕션(production) AI 워크로드는 모델 하나가 아닙니다. 그것은 스택(stack)입니다. 대개는 약간 황당한 스택이죠.

모델 런타임(model runtime)이 있습니다: vLLM, Triton, Hugging Face TGI, Ollama, Ray Serve, SGLang, 또는 이번 달 내부 테스트에서 승리한 무엇이든 말이죠. 컨테이너(containers), 이미지 다이제스트(image digests), 환경 변수(environment variables), API 키(API keys), 트레이싱 설정(tracing settings), 그리고 2월부터 계속 '임시' 상태인 몇 가지 '임시' 플래그(flags)들이 있습니다.

에이전트 프레임워크(agent framework), 벡터 데이터베이스(vector database), 학습 작업(training job), 평가 하네스(evaluation harness), 텔레메트리 시스템(telemetry system), 그리고 유일한 알람이 CPU뿐이라 모든 것이 괜찮다고 말하는 대시보드(dashboard)가 있을 수도 있습니다.

그 전체가 바로 AI 시스템입니다.

모델은 마케팅 측면에서 가장 돋보일 뿐입니다.

빌드 타임 인벤토리(build-time inventory)는 좋은 의도이지만

SBOM(Software Bill of Materials)은 소프트웨어 아티팩트(artifact) 내부에 무엇이 들어있는지 묻도록 우리를 훈련시켰습니다. 그것은 유용했습니다. 고통스러웠지만, 유용했습니다.

일반적인 애플리케이션 소프트웨어의 경우, 빌드 타임 인벤토리(build-time inventory)만으로도 꽤 많은 것을 파악할 수 있습니다. 종속성(dependencies), 패키지 버전, 라이선스, 취약점, 출처(provenance), 그리고 서명(signatures)을 검사할 수 있습니다. 배포 전에 정책 결정을 내릴 수도 있습니다.

AI 워크로드(workloads)는 이를 더 어렵게 만듭니다.

어떤 중요한 사실들은 오직 런타임(runtime)에만 나타납니다. 포드(pod)가 실제로 로드한 모델은 무엇인가? 어떤 이미지 다이제스트(image digest)가 풀(pull)되었는가? 에이전트(agent)가 호출하도록 설정된 외부 LLM 제공업체는 어디인가? 어떤 벡터 스토어(vector store)가 연결되어 있는가? 어떤 데이터셋 볼륨(dataset volume)이 학습 작업(training job)에 마운트되었는가? 검토하기 좋은 YAML 파일이 실제 현실이 된 후, 어떤 워크로드가 변경되었는가?

이것이 k8s-aibom 아이디어가 흥미로운 이유입니다. 컨트롤러(controller)는 Kubernetes API를 통해 워크로드를 관찰하고, 일반적인 클러스터 운영의 부수 효과(side effect)로서 ML-BOM을 생성합니다. 이는 더 유용한 플랫폼 질문을 던집니다:

여기서 무엇이 실행되고 있는가?

"여기"라는 단어가 중요합니다.

"리포지토리(repo)가 무엇이라고 말했는가?"가 아닙니다.

"골든 패스(golden path) 템플릿이 무엇을 의도했는가?"도 아닙니다.

지금 이 클러스터에서, 이 네임스페이스(namespace)에서, 바로 지금 무엇이 실행되고 있는가?

[

everything is fine in the pod]

신뢰도(confidence)는 각주가 아닙니다

이 프로젝트에서 제가 가장 좋아하는 디테일은 BOM을 생성한다는 점이 아닙니다.

속성(attributes)에 신뢰도(confidence)가 있다는 점입니다.

컨트롤러는 값을 declared(선언됨), inferred(추론됨), 또는 unresolved(해결되지 않음)로 표시할 수 있습니다. 컨테이너 인자(argument)에서 가져온 모델 이름은 declared입니다. 이미지 이름으로부터 런타임에 추측한 것은 inferred입니다.

이것은 아주 작은 메타데이터처럼 들리겠지만, 불확실성이 슬라이드 데크(slide deck)에서 보기 좋지 않다는 이유로 모두가 확신하는 척하는 컴플라이언스(compliance) 검토 회의에 앉아본 적이 있다면 이야기가 달라집니다.

다음 사이에는 엄청난 차이가 있습니다:

"이 워크로드는 vLLM을 실행하며 모델 X를 서빙합니다."

그리고:

"워크로드는 환경 변수에 모델 X를 선언하고, 런타임은 이미지 이름에 기반하여 vLLM인 것으로 보이며, 포드(pod)가 아직 풀(pull)하지 않았기 때문에 다이제스트(digest)가 해결되지 않은 상태입니다."

두 번째 버전은 덜 예쁩니다.

하지만 훨씬 더 정직합니다.

여기서 정직함은 단순한 도덕적 선호가 아닙니다. 운영 측면에서 유용합니다. 선언된 사실(Declared facts)은 정책(policy)에 따라 검증될 수 있습니다. 추론된 사실(Inferred facts)은 주석(annotations)을 통해 검토하거나 개선할 수 있습니다. 해결되지 않은 사실(Unresolved facts)은 큐(queue)가 될 수 있습니다. 누군가는 왜 프로덕션 추론 서비스가 검증된 모델 식별자(model identity)를 생성할 수 없는지 물을 수 있습니다.

그것은 지루한 작업입니다.

좋습니다.

지루한 작업이야말로 거버넌스(governance)가 실질적으로 구현되는 지점입니다.

런타임 인벤토리가 소유권을 변화시킨다

AI 인벤토리가 클러스터 리소스가 되면, 소유권에 대한 논의가 바뀝니다.

플랫폼 팀은 더 이상 모델 서빙 컨테이너를 배포하는 방법만을 제공하는 것이 아닙니다. 그들에 대한 질문에 답하는 방법을 제공하는 것입니다.

어떤 팀이 추론(inference)을 실행하고 있는가?

어떤 워크로드가 외부 LLM API를 호출하는가?

어떤 네임스페이스(namespace)에 에이전트 프레임워크(agent frameworks)가 있는가?

어떤 런타임 버전이 드리프트(drifting)되고 있는가?

어떤 모델 식별자가 단지 추론된 것뿐인가?

마지막 배포 이후 어떤 BOM(Bill of Materials)이 변경되었는가?

이것은 단순히 대시보드를 만들기 위한 것이 아닙니다. 제발, 우리는 이미 대시보드가 충분합니다. 그중 일부는 이제 법적으로 가구(furniture)로 분류될 정도입니다. 이것은 제어 루프(control loop)입니다.

클러스터가 AI 자재 명세서(AI BOM)를 생성할 수 있다면, 보안, 컴플라이언스(compliance), 플랫폼, 그리고 제품 팀은 더 이상 '느낌(vibes)'에 의존해 논쟁하지 않아도 됩니다. 그들은 증거를 바탕으로 논쟁할 수 있습니다. 여전히 시끄럽겠지만 말입니다. 적어도 객체 이름(object names)을 가지고 말이죠.

이 지점이 바로 Kubernetes의 형태가 의미를 갖는 곳이기도 합니다. Kubernetes는 이미 인프라 의도(infrastructure intent)가 런타임 상태(runtime state)로 전환되는 장소가 되었습니다: Deployment, Job, Service, GPU claim, secret reference, service account, label, annotation, event 등 말입니다. 때로는 지저분할 수도 있지만, 현실이 모이는 곳이기도 합니다.

그러니 네, 당연하게도 AI 인벤토리는 컨트롤러(controller)가 되고 싶어 합니다.

Kubernetes 근처에 충분히 오래 두면, 모든 것은 결국 컨트롤러가 됩니다.

규정 준수는 증거를 요구할 뿐, 연극을 요구하지 않는다

k8s-aibom의 README는 EU AI Act 로깅 및 투명성 의무, NIST AI RMF(Risk Management Framework) 통제 항목, 그리고 ISO/IEC 42001 인벤토리 및 라이프사이클 조항에 대해 언급합니다. 이는 엔지니어들이 감사 일정 초대장이 나타날 때까지 건너뛰는 종류의 단락입니다.

저도 이해합니다.

규정 준수 관련 문구는 업무와 동떨어진 느낌을 줄 수 있습니다. 종종 PDF 파일, 체크리스트, 그리고 주요 결과물이 약간의 절망감인 회의 형태로 도착하기 때문입니다.

하지만 근본적인 요구 사항은 터무니없지 않습니다. AI 시스템을 배포한다면, 그것이 무엇인지, 어디에서 실행되는지, 무엇에 의존하는지, 그리고 어떻게 변경되었는지 알아야 합니다.

나쁜 버전은 연극입니다. 한 팀이

• 런타임 (runtime) 시점에 AI 워크로드 (workloads) 관찰
• 증거 로케이터 (evidence locators) 포함
• 선언된 사실 (declared facts)과 추론된 추측 (inferred guesses)의 구분
• 드리프트 (drift)의 가시화

그러한 패턴은 더 많은 제품에서 나타날 것입니다.

당연히 그래야만 합니다.

왜냐하면 AI 시스템은 기억에만 의존하여 관리하기에는 너무나 분산되어 있고, 너무나 중요해지고 있기 때문입니다.

플랫폼 팀이 훔쳐야 할 것들

설령 이 컨트롤러 (controller)를 직접 실행하지 않더라도, 질문들은 훔쳐 오십시오.

클러스터 내의 모든 모델 서빙 (model-serving) 워크로드를 나열할 수 있습니까?

각 워크로드가 어떤 런타임 (runtime)을 사용하는지 말할 수 있습니까?

에이전트 스택 (agent stacks)과 그들이 호출하는 외부 LLM API를 식별할 수 있습니까?

팀이 선언한 사실과 도구에 의해 추론된 사실을 구분할 수 있습니까?

인벤토리 (inventory)를 증명할 수 있습니까, 아니면 오래된 스크린샷이 담긴 위키 (wiki) 페이지를 믿고 있습니까?

답변이 당장 내일부터 완벽할 필요는 없습니다. 하지만 답변이 "주변에 물어봐야 합니다"라면, 그것은 거버넌스 (governance)가 아닙니다. 그것은 알림 기능이 달린 고고학일 뿐입니다.

실질적인 경로는 작게 시작하는 것입니다. 네임스페이스 (namespaces)에 라벨 (label)을 붙이십시오. 모델 및 런타임 어노테이션 (annotations)을 요구하십시오. 이미지 다이제스트 (image digests)를 추적하십시오. 외부 AI 제공업체를 인벤토리화하십시오. BOM을 소유권 (ownership)과 연결하십시오. 해결되지 않은 필드는 작업 항목 (work items)으로 취급하십시오.

가시성 (Visibility)이 우선입니다.

그다음이 제어 (control)입니다.

그다음에야 논쟁들이 유용해질 수 있습니다.

핵심 (the punchline)

AI 자재 명세서 (AI BOM)가 컴플라이언스 (compliance) 서류 작업처럼 들리는 이유는, 불행히도 부분적으로는 실제로 그렇기 때문입니다.

하지만 런타임 버전은 서류 작업보다 훨씬 더 흥미롭습니다.

그것은 AI 시스템을 위한 클러스터 인벤토리 (cluster inventory)입니다.

이것이 중요한 이유는 프로덕션 (production) AI 시스템이 단지 모델뿐만이 아니기 때문입니다. 그것은 런타임 (runtime), 컨테이너 (container), 에이전트 프레임워크 (agent framework), 벡터 스토어 (vector store), 학습 작업 (training job), 외부 API 의존성 (external API dependency), 텔레메트리 (telemetry) 설정, 네임스페이스 (namespace), 서비스 계정 (service account), 그리고 누군가 장애 상황 중에 추가하고 삭제하는 것을 잊어버린 기묘한 어노테이션 (annotation)까지 모두 포함합니다.

이러한 구성 요소들을 볼 수 없다면, 그것들을 관리할 수 없습니다.

그저 다이어그램 (diagram)이 여전히 유효하기만을 바랄 뿐입니다.

그리고 수년간의 소프트웨어 엔지니어링이 우리에게 가르쳐준 것이 있다면, 그것은 다이어그램은 결코 계속해서 유효하지 않다는 사실입니다.

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 사용할 수 있는 20달러(USD)를 원하신다면, 이 링크를 사용하세요.