AI 모델을 지원하는 인프라를 구축한다. Gemma 4가 내 직업을 위협한다.

출처: Dev.to

Gemma 4 챌린지: Gemma 4에 대해 쓰기 제출물

이 글은 Gemma 4 챌린지 “Gemma 4에 대해 쓰기”에 대한 제출물입니다.
대부분의 Gemma 4 관련 포스트는 “다운로드해서 로컬에서 실행했다”는 문장으로 시작합니다. 제 이야기는 다릅니다.

저는 Gemma 4와 같은 모델을 서비스하는 플랫폼을 구축합니다. 하루하루 Kubernetes 매니페스트를 작성하고, KServe InferenceService를 설정하고, Knative 인그레스 라우트를 디버깅하고, Kyverno 정책이 나쁜 배포가 클러스터에 도달하기 전에 차단하도록 관리합니다. 제 프로젝트인 NeuroScale은 개발자가 Backstage 폼을 채우면 플랫폼이 Pull Request를 만들고, ArgoCD가 배포하며, 프로덕션 급 추론 엔드포인트가 바로 살아나는 셀프 서비스 AI 추론 플랫폼입니다.

저는 말 그대로 AI 모델 서빙을 위한 전등을 켜두는 사람입니다.

그래서 Google이 Gemma 4를 발표하고 2B 파라미터 모델은 라즈베리 파이에서, 31B 모델은 워크스테이션에서 실행할 수 있다고 했을 때, 제 첫 생각은 “멋지다, 한번 써보자”가 아니라 “이게 내 전체 플랫폼을 쓸모 없게 만들까?”였습니다.

그 질문—그리고 결국 도출한 답—이 바로 이 글의 핵심입니다.

플랫폼 엔지니어링의 숨은 비밀

AI 모델을 운영하는 비용의 대부분은 모델 자체가 아니라 모델 주변에 있는 모든 것입니다.

NeuroScale에서 단일 sklearn InferenceService를 KServe에 배포하면 대략 5개의 파드가 생성됩니다. 하나가 아니라 다섯 개입니다.

• Predictor 파드
• Transformer 파드(설정된 경우)
• Istio/Kourier 사이드카 또는 게이트웨이 파드
• Knative가 주입하는 queue‑proxy 파드
• 시작 시 모델 아티팩트를 다운로드하는 스토리지 이니셜라이저 파드

각 파드마다 CPU 요청, 메모리 제한, 헬스 프로브가 필요하고, 우리는 Kyverno 입장 정책을 통해 소유자 라벨과 비용 센터 라벨이 없으면 파드가 생성되지 않도록 강제합니다.

# This gets DENIED by our Kyverno policy — no owner, no deploy
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: gemma-model
  namespace: default
spec:
  predictor:
    sklearn:
      storageUri: gs://models/gemma/v1
# ❌ Blocked: missing app.kubernetes.io/owner and cost-center labels

로컬 k3d 클러스터(제가 개발에 사용하는 환경)에서 단일 InferenceService는 약 1.2 GB의 RAM을 차지합니다. 여기에 Backstage(개발자 포털), ArgoCD(GitOps), Kyverno(정책 엔진), OpenCost(비용 추적)를 더하면, 예측 하나도 처리하지 않은 상태에서 인프라 메모리 사용량이 6~8 GB에 달합니다.

이것이 바로 “서빙 세금”이며, 모든 플랫폼 엔지니어가 매일 내는 비용이지만, 이에 대한 블로그 글은 거의 없습니다.

Gemma 4의 E2B 모델(20억 파라미터, 멀티모달, 128K 컨텍스트 창)이 라즈베리 파이 5에서 7.5 W만 소비한다는 소식을 접했을 때 무언가가 ‘딸깍’했습니다.

흥분해서가 아니라, 핵심 전제가 조용히 틀렸다는 깨달음이었습니다.

제 플랫폼은 **“AI 모델을 배포하는 것은 어렵고 위험하며 인프라 가드레일이 필요하다”**는 전제 위에 서 있습니다. NeuroScale의 강점은 Kubernetes를 몰라도 추론 엔드포인트를 손쉽게 얻을 수 있다는 점입니다. 폼만 채우면 YAML, 드리프트 교정, 정책 적용, 비용 추적까지 전부 자동으로 처리됩니다.

그런데 만약 모델이 그냥 실행된다면 어떨까요? 디바이스 자체에서, YAML도, Kubernetes도, 플랫폼도 없이 말이죠?

Gemma 4 모델군은 이 질문을 이전 오픈 모델들이 제공하지 못했던 구체적인 형태로 제시합니다.

아래 두 줄은 제 세계와 일치합니다. 위의 두 줄은 그렇지 않죠.

내 NeuroScale 구축 과정 중 가장 힘들었던 3시간

KServe를 처음 설정했을 때, 모든 InferenceService 생성이 클러스터 전체에서 차단되었습니다. 모델이 하나도 배포되지 않았습니다. 이유는? KServe 기본 설정이 Istio를 서비스 메시로 가정하고 있었기 때문입니다. 우리는 Kourier(경량 Envoy 기반 인그레스 게이트웨이)를 사용하고 있었는데, 이는 약 100 MB만 차지하고 Istio의 ~1 GB에 비해 훨씬 가볍습니다. k3d 클러스터에 Istio를 돌릴 메모리 여유가 없었기 때문이죠.

문제 해결을 위한 한 줄 패치:

# infrastructure/serving-stack/patches/inferenceservice-config-ingress.yaml
ingress:
  disableIstioVirtualHost: true

disableIstioVirtualHost: true 한 줄이 “모든 추론이 차단됨”과 “모든 것이 정상 작동함” 사이를 가르는 열쇠였습니다. 이 플래그는 KServe 시작 가이드에 전혀 언급되지 않았으며, 저는 KServe 컨트롤러 소스를 읽으며 찾아냈습니다.

3시간 동안 서비스가 중단되었습니다. 단 한 개의 불리언 때문이었습니다.

만약 제가 로컬에서 Ollama를 통해 Gemma 4 E2B를 실행하고 있었다면, 이런 장애는 발생하지 않았을 겁니다. 인그레스도, 서비스 메시도, Kubernetes도 없고, 포트 하나만 열려 있는 프로세스일 뿐이니까요.

# 로컬 Gemma 4 전체 "플랫폼"
ollama run gemma4:e2b
# 끝. YAML도, CRD도, 3시간 장애도 없음.

그럼 왜 우리 같은 플랫폼이 여전히 필요한 걸까요?

모델과 서빙의 차이

모델을 실행한다는 것은: 가중치를 다운로드하고, 메모리에 로드하고, 프롬프트를 보내고, 응답을 받는 일입니다. Gemma 4 E2B는 소비자용 하드웨어에서도 이를 아름답게 수행합니다.

반면 모델을 서빙한다는 것은: 3개 팀의 50명 개발자에게