주피터 노트북에서 모델을 만들고, 도커로 컨테이너화하고, 쿠버네티스로 배포하고, 프로메테우스로 모니터링하고, Airflow로 재학습 스케줄링하고. ML 엔지니어의 하루입니다. 각 도구는 훌륭하지만 조합하면 악몽이 됩니다. 버전 충돌, 설정 불일치, 인증 연동, 네트워크 정책. 하나씩 손으로 연결하다 보면 개발보다 인프라에 더 많은 시간을 씁니다.
Elancer 조사에 따르면 MLOps 도입 시 가장 큰 장애물은 도구 파편화입니다. 데이터 과학자는 TensorFlow, PyTorch, Hugging Face를 쓰고 싶어 합니다. 인프라 팀은 쿠버네티스, Terraform, Helm을 고집합니다. 보안팀은 Vault, Istio, Policy Engine을 요구합니다. 각 팀이 선택한 도구들을 하나의 파이프라인으로 엮으려면 전문가가 몇 달을 투입해야 합니다.
Red Hat OpenShift AI는 이 문제를 정확히 이해합니다. 30년간 엔터프라이즈 오픈소스를 통합해온 노하우로 주피터, Tekton, KServe, Prometheus를 하나의 플랫폼에 녹여냈습니다. 데이터 과학자는 익숙한 주피터 노트북에서 코드를 작성하고, 클릭 한 번으로 파이프라인을 실행하고, 자동으로 프로덕션에 배포됩니다. 쿠버네티스를 몰라도 됩니다. 도커 파일을 손으로 작성할 필요도 없습니다. 플랫폼이 모든 복잡성을 추상화하기 때문입니다.
Forrester 조사는 놀라운 수치를 보여줍니다. Red Hat OpenShift AI 도입 시 데이터 과학자 생산성 20% 증가, 개발 및 운영 효율 60% 향상, 3년 ROI 210%. 이게 가능한 이유는 간단합니다. 엔지니어가 인프라가 아니라 모델에 집중할 수 있기 때문입니다.
개발 따로 운영 따로 MLOps의 병목 현상 해결하기
데이터 과학자 Alice는 훌륭한 추천 모델을 만들었습니다. 정확도 95%, 로컬 테스트 완벽. 그런데 프로덕션 배포는 DevOps 팀 Bob의 몫입니다. Bob은 Alice의 주피터 노트북을 받고 당황합니다. 절대 경로, 하드코딩된 API 키, 로컬 파일 시스템 의존. 쿠버네티스에서 돌아갈 리 없습니다.
Bob은 코드를 리팩토링하고, 도커파일을 작성하고, ConfigMap으로 설정을 분리하고, Secret으로 인증을 관리합니다. 2주가 걸렸습니다. 배포했더니 성능이 10배 느립니다. Alice의 노트북은 GPU를 썼는데 Bob의 컨테이너는 CPU로 돌아갑니다. GPU 설정을 추가하고, 드라이버를 맞추고, 리소스 할당을 조정합니다. 또 1주일. 드디어 배포 성공. 그런데 Alice가 모델을 업데이트했습니다. 다시 처음부터 시작입니다.
이게 전통적인 ML 개발의 현실입니다. Taehun's Blog 분석에 따르면 ML 프로젝트의 가장 큰 문제는 확장성과 신뢰성 부족입니다. 로컬에서 잘 돌아가던 모델이 프로덕션에서 안 돌아갑니다. 리소스가 부족하고, 의존성이 꼬이고, 환경이 다릅니다. 수동 배포는 실수를 낳고, 실수는 장애로 이어집니다.
MLOps는 이 간극을 메웁니다. 개발부터 배포까지 자동화된 파이프라인으로 연결하는 겁니다. 하지만 MLOps 자체가 복잡합니다. Kubeflow, MLflow, DVC, Airflow, Seldon Core. 각각 설치하고, 연동하고, 버전 맞추고, 보안 설정하고. 6개월 걸려 구축했더니 유지보수가 또 다른 악몽입니다.
# 전통적인 ML 배포의 문제점 - 수동 단계가 너무 많음
# Step 1: 데이터 과학자가 로컬에서 모델 개발
# my_notebook.ipynb
import pandas as pd
import tensorflow as tf
# 문제 1: 절대 경로 하드코딩
data = pd.read_csv('/Users/alice/data/train.csv')
# 문제 2: API 키 하드코딩
api_key = "sk-1234567890abcdef"
# 문제 3: GPU 설정이 환경 의존적
model = tf.keras.models.Sequential([...])
model.fit(data, epochs=10) # 로컬 GPU 사용
# 문제 4: 모델 저장 경로가 로컬
model.save('/Users/alice/models/recommender_v1.h5')
# Step 2: DevOps 엔지니어가 컨테이너화 (1주일 소요)
# Dockerfile
FROM tensorflow/tensorflow:2.14.0-gpu
# 문제 5: 의존성 버전 충돌
RUN pip install pandas==1.5.0 tensorflow==2.14.0 numpy==1.23.0
# 문제 6: CUDA 버전 매칭 문제
# 로컬은 CUDA 11.8, 서버는 CUDA 12.0
COPY app.py /app/
CMD ["python", "/app/app.py"]
# Step 3: 쿠버네티스 매니페스트 작성 (며칠 소요)
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: ml-model
spec:
replicas: 3
template:
spec:
containers:
- name: model
image: myregistry/model:v1
resources:
limits:
nvidia.com/gpu: 1 # 문제 7: GPU 할당 수동 설정
env:
- name: API_KEY
valueFrom:
secretKeyRef:
name: api-secret # 문제 8: Secret 별도 생성 필요
key: api-key
# Step 4: 모니터링 설정 (또 며칠)
# ServiceMonitor, PrometheusRule 수동 작성
# 문제 9: 메트릭 엔드포인트 직접 구현 필요
# Step 5: CI/CD 파이프라인 구성 (일주일 이상)
# .github/workflows/deploy.yml
# 문제 10: 테스트, 빌드, 배포 모두 수동 스크립트
# 총 소요 시간: 최소 3~4주
# 유지보수 부담: 매 업데이트마다 반복# Red Hat OpenShift AI 방식 - 통합 플랫폼으로 단순화
# Step 1: 데이터 과학자는 그냥 코드만 작성
# my_notebook.ipynb (OpenShift AI 워크벤치에서)
import pandas as pd
import tensorflow as tf
# ✅ S3 호환 스토리지 자동 연동 (환경 변수로 주입)
data = pd.read_csv(f"{os.environ['DATA_PATH']}/train.csv")
# ✅ Secret Manager 자동 연동
api_key = os.environ['API_KEY']
# ✅ GPU 자동 할당 (워크벤치 설정에서 클릭)
model = tf.keras.models.Sequential([...])
model.fit(data, epochs=10)
# ✅ 모델 레지스트리 자동 연동
import boto3
s3 = boto3.client('s3')
model.save('s3://models/recommender_v1.h5')
# Step 2: 파이프라인 정의 (YAML 또는 UI에서 드래그앤드롭)
# pipeline.yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: ml-pipeline
spec:
tasks:
- name: data-prep
taskRef:
name: data-preparation
- name: train
taskRef:
name: model-training
runAfter: ["data-prep"]
params:
- name: gpu
value: "1" # GPU 자동 할당
- name: validate
taskRef:
name: model-validation
runAfter: ["train"]
- name: deploy
taskRef:
name: model-serving
runAfter: ["validate"]
params:
- name: replicas
value: "3"
- name: canary-percent
value: "10" # 카나리 배포 자동
# Step 3: 배포 - 클릭 한 번
# OpenShift AI UI에서 "Deploy" 버튼 클릭
# 자동으로:
# - 컨테이너 빌드
# - GPU 리소스 할당
# - KServe InferenceService 생성
# - 오토스케일링 설정
# - 모니터링 대시보드 생성
# - 로깅 수집 시작
# 총 소요 시간: 1~2일
# 유지보수: 자동화된 CI/CD로 업데이트 10분| 작업 | 전통적 방식 | OpenShift AI 방식 | 시간 절감 |
|---|---|---|---|
| 개발 환경 설정 | 의존성 수동 설치 버전 충돌 해결 | 사전 구성된 이미지 선택 TensorFlow PyTorch 등 | 2일 → 10분 |
| 모델 학습 | 로컬 GPU 또는 클라우드 VM 직접 관리 | GPU 자동 할당 분산 학습 지원 | 설정 1일 → 클릭 1번 |
| 컨테이너화 | Dockerfile 작성 의존성 관리 레지스트리 푸시 | 자동 빌드 및 푸시 S2I Source-to-Image | 3일 → 자동 |
| 쿠버네티스 배포 | YAML 작성 리소스 할당 네트워크 설정 | UI에서 클릭 또는 파이프라인 실행 | 5일 → 10분 |
| GPU 설정 | 드라이버 설치 CUDA 버전 매칭 리소스 할당 | 플랫폼이 자동 처리 | 2일 → 0분 |
| 모니터링 | Prometheus 설정 Grafana 대시보드 생성 | 자동 메트릭 수집 사전 구성 대시보드 | 3일 → 즉시 |
| CI/CD 파이프라인 | Jenkins/GitHub Actions 스크립트 작성 | Tekton 기반 파이프라인 템플릿 | 1주 → 1일 |
| 모델 서빙 | Flask/FastAPI 서버 작성 오토스케일링 설정 | KServe 자동 서빙 내장 오토스케일링 | 3일 → 클릭 1번 |
| 보안 설정 | Secret 관리 RBAC 설정 네트워크 정책 | 통합 인증 자동 Secret 주입 | 2일 → 설정 패널 |
| 재학습 자동화 | Airflow DAG 작성 스케줄링 설정 | 파이프라인 트리거 설정 | 2일 → 30분 |
OpenShift AI가 제공하는 가치는 추상화입니다. 데이터 과학자는 쿠버네티스, 도커, Helm을 몰라도 됩니다. 익숙한 주피터 노트북에서 코드를 작성하고, 버튼을 누르면 플랫폼이 알아서 배포합니다. 뒤에서는 Tekton이 파이프라인을 실행하고, S2I가 컨테이너를 빌드하고, KServe가 모델을 서빙하지만 사용자는 몰라도 됩니다.
AWS MLOps 사례를 보면 조직별 파편화된 기술 환경이 가장 큰 문제였습니다. 각 팀이 다른 도구를 쓰면 협업이 불가능합니다. OpenShift AI는 모든 팀이 하나의 플랫폼에서 일하게 만듭니다. 데이터 과학자, ML 엔지니어, DevOps, 보안팀이 동일한 인터페이스를 보고, 동일한 파이프라인을 공유하고, 동일한 메트릭을 모니터링합니다.
Red Hat OpenShift AI 핵심 기능 딥다이브 워크벤치와 파이프라인
OpenShift AI의 핵심은 세 가지 레이어로 구성됩니다. 첫 번째는 워크벤치입니다. 데이터 과학자가 모델을 개발하는 IDE 환경이죠. 주피터랩, VS Code, RStudio 중에서 선택할 수 있고, 사전 구성된 이미지에는 TensorFlow, PyTorch, scikit-learn이 이미 설치되어 있습니다. GPU도 클릭 한 번으로 할당됩니다.
워크벤치는 단순한 노트북 서버가 아닙니다. Git 통합으로 버전 관리되고, S3 호환 스토리지로 데이터를 읽고, Secret Manager에서 인증 정보를 가져옵니다. 환경 변수, 볼륨, 리소스 할당이 모두 UI에서 설정됩니다. 쿠버네티스 Pod로 실행되지만 사용자는 그냥 주피터 노트북을 쓰는 것처럼 느낍니다.
두 번째는 파이프라인입니다. Tekton 기반 CI/CD로 모델 학습부터 배포까지 자동화합니다. 각 단계는 컨테이너로 실행되고, 실패하면 자동 재시도하며, 성공하면 다음 단계로 진행합니다. 데이터 준비, 전처리, 학습, 검증, 배포를 하나의 워크플로우로 정의할 수 있습니다.
파이프라인은 재사용 가능합니다. 한 번 정의하면 다른 프로젝트에서 가져다 쓸 수 있고, 파라미터만 바꿔서 실행할 수 있습니다. Git 커밋이나 스케줄로 자동 트리거도 가능합니다. Jozu 사례를 보면 KitOps와 OpenShift Pipelines를 결합해서 Hugging Face 모델을 자동으로 가져와 배포하는 파이프라인을 만들었습니다. 수동 작업 없이 완전 자동화됐죠.
세 번째는 모델 서빙입니다. KServe로 모델을 REST API로 노출합니다. vLLM 같은 고성능 추론 엔진을 내장해서 대형 언어 모델도 빠르게 서빙할 수 있습니다. 오토스케일링이 기본이라 트래픽 증가에 자동 대응하고, 카나리 배포로 새 모델을 안전하게 롤아웃할 수 있습니다.
# OpenShift AI 워크벤치에서 개발부터 배포까지
# 1. 워크벤치에서 모델 개발
# Jupyter 노트북 my_model.ipynb
import os
import tensorflow as tf
from tensorflow import keras
import boto3
# ✅ 환경 변수로 설정 주입 (OpenShift Secret에서 자동)
DATA_BUCKET = os.environ['DATA_BUCKET']
MODEL_REGISTRY = os.environ['MODEL_REGISTRY']
# ✅ S3 호환 스토리지 자동 연동
s3 = boto3.client('s3',
endpoint_url=os.environ['S3_ENDPOINT'],
aws_access_key_id=os.environ['AWS_ACCESS_KEY_ID'],
aws_secret_access_key=os.environ['AWS_SECRET_ACCESS_KEY']
)
# 데이터 로드
s3.download_file(DATA_BUCKET, 'train.parquet', '/tmp/train.parquet')
import pandas as pd
df = pd.read_parquet('/tmp/train.parquet')
# 모델 정의 및 학습
model = keras.Sequential([
keras.layers.Dense(128, activation='relu', input_shape=(784,)),
keras.layers.Dropout(0.2),
keras.layers.Dense(10, activation='softmax')
])
model.compile(optimizer='adam',
loss='sparse_categorical_crossentropy',
metrics=['accuracy'])
# ✅ GPU 자동 활용 (워크벤치 설정에서 GPU=1 선택)
model.fit(df[['features']], df['label'], epochs=10, batch_size=32)
# 모델 저장 (S3 모델 레지스트리로)
model.save('/tmp/my_model')
s3.upload_file('/tmp/my_model', MODEL_REGISTRY, 'my_model_v1.h5')
print("✅ 모델 학습 완료 및 레지스트리 저장")
# 2. 파이프라인 정의 (OpenShift AI UI 또는 YAML)
# pipeline.yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: ml-training-pipeline
namespace: data-science-project
spec:
params:
- name: model-name
type: string
default: "my-classifier"
- name: gpu-count
type: string
default: "1"
tasks:
# Task 1: 데이터 검증
- name: validate-data
taskRef:
name: data-validation
params:
- name: dataset-path
value: "s3://data/train.parquet"
# Task 2: 모델 학습
- name: train-model
runAfter: ["validate-data"]
taskRef:
name: model-training
params:
- name: notebook-path
value: "notebooks/my_model.ipynb"
- name: image
value: "quay.io/rhoai/tensorflow:2.14"
- name: gpu
value: $(params.gpu-count)
workspaces:
- name: source
workspace: shared-workspace
# Task 3: 모델 검증
- name: validate-model
runAfter: ["train-model"]
taskRef:
name: model-validation
params:
- name: model-path
value: "s3://models/my_model_v1.h5"
- name: min-accuracy
value: "0.95"
# Task 4: 모델 배포
- name: deploy-model
runAfter: ["validate-model"]
when:
- input: "$(tasks.validate-model.results.accuracy)"
operator: gt
values: ["0.95"]
taskRef:
name: model-deployment
params:
- name: model-name
value: $(params.model-name)
- name: model-path
value: "s3://models/my_model_v1.h5"
- name: replicas
value: "3"
- name: inference-engine
value: "tensorflow-serving"
workspaces:
- name: shared-workspace
# 3. 모델 서빙 (KServe InferenceService 자동 생성)
# OpenShift AI가 자동으로 생성하는 리소스
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: my-classifier
namespace: data-science-project
spec:
predictor:
model:
modelFormat:
name: tensorflow
storageUri: "s3://models/my_model_v1.h5"
resources:
requests:
memory: "4Gi"
cpu: "2"
limits:
memory: "8Gi"
nvidia.com/gpu: "1"
minReplicas: 1
maxReplicas: 5
scaleMetric: concurrency
scaleTarget: 10 # 동시 요청 10개당 Pod 1개
# 카나리 배포 (선택 사항)
canaryTrafficPercent: 20
# 트래픽 라우팅
traffic:
- tag: stable
revisionName: my-classifier-v1
percent: 80
- tag: canary
revisionName: my-classifier-v2
percent: 20
# 4. 모니터링 (Prometheus 메트릭 자동 수집)
# OpenShift AI가 자동으로 수집하는 메트릭:
# - inference_requests_total
# - inference_latency_seconds
# - model_accuracy
# - gpu_utilization_percent
# - memory_usage_bytes
# Grafana 대시보드도 자동 생성됨| 컴포넌트 | 기술 스택 | 제공 기능 | 사용자 경험 |
|---|---|---|---|
| 워크벤치 | JupyterLab VS Code RStudio | 통합 IDE GPU 자동 할당 Git 연동 S3 스토리지 | 클릭 몇 번으로 시작 쿠버네티스 몰라도 됨 |
| 파이프라인 | Tekton Pipelines Argo Workflows | CI/CD 자동화 재사용 가능한 Task 스케줄링 트리거 | 드래그앤드롭 UI 또는 YAML 정의 |
| 모델 레지스트리 | S3 호환 스토리지 | 버전 관리 메타데이터 추적 접근 제어 | 자동 업로드 및 다운로드 |
| 모델 서빙 | KServe vLLM TorchServe | REST API 노출 오토스케일링 카나리 배포 A/B 테스트 | 클릭으로 배포 자동 엔드포인트 생성 |
| 모니터링 | Prometheus Grafana | 메트릭 수집 사전 구성 대시보드 알림 설정 | 즉시 사용 가능한 대시보드 |
| 데이터 연결 | S3 PostgreSQL MinIO | 데이터 소스 통합 자동 마운트 | UI에서 연결 설정 자동 환경 변수 주입 |
| 분산 학습 | Kubeflow Training Operator PyTorch Distributed | 다중 GPU 다중 노드 학습 | 설정 파일로 자동 분산 |
| 실험 추적 | MLflow Weights & Biases | 하이퍼파라미터 로깅 메트릭 비교 | 자동 로깅 통합 |
OpenShift AI의 강력함은 통합에 있습니다. 각 컴포넌트가 유기적으로 연결되어 있어서 데이터가 끊김 없이 흐릅니다. 워크벤치에서 개발한 노트북이 파이프라인에서 그대로 실행되고, 학습된 모델이 자동으로 레지스트리에 저장되며, 검증을 통과하면 즉시 서빙으로 배포됩니다. 수동 개입이 최소화되니 오류가 줄고 속도가 빨라집니다.
Guidehouse가 미국 제대군인부를 위해 구축한 AI 플랫폼이 좋은 사례입니다. 재향 군인의 극단적 선택을 예방하기 위해 건강 데이터를 실시간으로 분석하는 AI를 만들었는데, OpenShift AI의 통합 파이프라인 덕분에 개발부터 배포까지 빠르게 진행할 수 있었습니다. 생명을 다루는 민감한 시스템이라 안정성이 최우선이었는데, Red Hat의 엔터프라이즈 지원과 검증된 스택이 신뢰를 줬죠.
쿠버네티스 기반의 유연한 GPU 스케줄링과 자원 관리
GPU는 비쌉니다. NVIDIA H100 하나에 수천만 원입니다. 놀리면 돈이 타들어 갑니다. 문제는 ML 워크로드가 GPU를 비효율적으로 씁니다. 학습은 100% 쓰지만, 전처리는 0%, 검증은 50%. 평균 활용률이 30%면 70%는 낭비입니다.
쿠버네티스 기본 GPU 스케줄러는 단순합니다. Pod에 GPU 1개 할당하면 다른 Pod는 못 씁니다. 8개 GPU 서버에 8개 Pod를 돌리면 각각 GPU 1개씩 독점합니다. 하나가 30%만 쓰고 있어도 다른 Pod는 대기해야 합니다. Cast AI 분석에 따르면 이런 비효율이 클라우드 비용을 2배 이상 증가시킵니다.
OpenShift AI는 고급 GPU 스케줄링을 지원합니다. Time-slicing으로 하나의 GPU를 여러 Pod가 나눠 씁니다. MIG로 A100을 7개 조각으로 나눠서 독립적인 GPU처럼 씁니다. Dynamic Resource Allocation으로 Pod가 실행 중에 GPU를 동적으로 요청하고 반환할 수 있습니다.
KCD Korea 2025 발표를 보면 대규모 AI 클러스터에서 GPU 오케스트레이션이 얼마나 중요한지 알 수 있습니다. 수천 개 노드, 수만 개 GPU를 효율적으로 쓰려면 배치 큐잉, 우선순위 스케줄링, 선점, 백필 같은 HPC 기법이 필요합니다. NVIDIA KAI Scheduler는 이런 고급 기능을 쿠버네티스에 통합했고, OpenShift AI는 이를 플랫폼 레벨에서 지원합니다.
# OpenShift AI GPU 스케줄링 고급 기법
# 1. GPU Time-Slicing - 하나의 GPU를 여러 Pod가 나눠 쓰기
apiVersion: v1
kind: ConfigMap
metadata:
name: gpu-sharing-config
namespace: gpu-operator
data:
any: |-
version: v1
sharing:
timeSlicing:
resources:
- name: nvidia.com/gpu
replicas: 4 # GPU 1개를 4개 논리 GPU로 분할
---
# Pod가 논리 GPU 요청
apiVersion: v1
kind: Pod
metadata:
name: training-job-1
spec:
containers:
- name: trainer
image: tensorflow/tensorflow:latest-gpu
resources:
limits:
nvidia.com/gpu: 1 # 실제로는 물리 GPU의 1/4 사용
---
# 동시에 4개 Pod가 같은 GPU 사용 가능
apiVersion: v1
kind: Pod
metadata:
name: training-job-2
spec:
containers:
- name: trainer
image: pytorch/pytorch:latest
resources:
limits:
nvidia.com/gpu: 1 # 동일 GPU의 다른 슬라이스
# 2. MIG (Multi-Instance GPU) - A100/H100 물리적 분할
apiVersion: v1
kind: ConfigMap
metadata:
name: mig-config
data:
config.yaml: |-
version: v1
mig-configs:
all-1g.10gb:
- devices: [0]
mig-devices:
"1g.10gb": 7 # A100을 7개 1g.10gb 인스턴스로 분할
---
# MIG 인스턴스 요청
apiVersion: batch/v1
kind: Job
metadata:
name: inference-job
spec:
template:
spec:
containers:
- name: model-server
image: nvcr.io/nvidia/pytorch:23.12-py3
resources:
limits:
nvidia.com/mig-1g.10gb: 1 # MIG 인스턴스 1개
---
# 7개 Job이 하나의 A100을 동시 사용 가능
# 3. Dynamic Resource Allocation (DRA) - 동적 GPU 할당
apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaim
metadata:
name: gpu-claim
spec:
resourceClassName: gpu.nvidia.com
parametersRef:
apiGroup: gpu.nvidia.com
kind: GpuClaimParameters
name: high-performance
---
apiVersion: v1
kind: Pod
metadata:
name: dynamic-gpu-pod
spec:
resourceClaims:
- name: gpu-resource
source:
resourceClaimName: gpu-claim
containers:
- name: trainer
image: tensorflow/tensorflow:latest-gpu
resources:
claims:
- name: gpu-resource
# Pod 실행 중에 GPU 동적 할당/해제 가능
# 4. Gang Scheduling - 분산 학습을 위한 동시 스케줄링
apiVersion: scheduling.volcano.sh/v1beta1
kind: PodGroup
metadata:
name: distributed-training
spec:
minMember: 8 # 8개 Pod가 모두 스케줄되어야 시작
queue: gpu-queue
priorityClassName: high-priority
---
apiVersion: batch/v1
kind: Job
metadata:
name: distributed-training-job
spec:
parallelism: 8
template:
metadata:
annotations:
scheduling.k8s.io/group-name: distributed-training
spec:
schedulerName: volcano # Gang 스케줄러 사용
containers:
- name: trainer
image: horovod/horovod:latest
resources:
limits:
nvidia.com/gpu: 1
env:
- name: NCCL_DEBUG
value: INFO
# 8개 Pod가 동시에 시작되어 분산 학습 수행
# 5. GPU Binpacking - 비용 최적화를 위한 밀집 배치
apiVersion: v1
kind: Pod
metadata:
name: inference-pod
spec:
schedulerName: default-scheduler
priorityClassName: low-priority
affinity:
nodeAffinity:
# GPU가 이미 사용 중인 노드 선호 (빈 노드 생성 방지)
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: gpu-utilization
operator: Gt
values: ["50"]
containers:
- name: model-server
resources:
limits:
nvidia.com/gpu: 1
# 6. Preemption - 우선순위 기반 선점
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: critical-training
value: 1000000
globalDefault: false
description: "Critical ML training jobs"
---
apiVersion: v1
kind: Pod
metadata:
name: critical-job
spec:
priorityClassName: critical-training
containers:
- name: trainer
resources:
limits:
nvidia.com/gpu: 4
# 이 Pod는 낮은 우선순위 Pod를 선점하여 GPU 확보 가능| GPU 최적화 기법 | 활용률 개선 | 비용 절감 | 적용 워크로드 | 난이도 |
|---|---|---|---|---|
| Time-Slicing | GPU 1개 → 4~8개 논리 GPU | 50~70% 절감 | 추론 경량 학습 개발 환경 | 쉬움 |
| MIG 분할 | A100 1개 → 7개 인스턴스 | 60~80% 절감 | 다중 테넌트 소규모 모델 | 중간 |
| DRA 동적 할당 | 유휴 시간 제거 | 30~50% 절감 | 간헐적 GPU 사용 | 중간 |
| Gang Scheduling | 분산 학습 대기 시간 최소화 | 20~30% 시간 절감 | 분산 학습 대규모 모델 | 어려움 |
| Binpacking | 노드 활용률 80% 이상 | 40~60% 인프라 비용 절감 | 모든 워크로드 | 중간 |
| Preemption | 중요 작업 대기 시간 제거 | ROI 향상 | 우선순위 있는 워크로드 | 중간 |
| Spot Instance 통합 | 온디맨드 대비 70% 저렴 | 70~90% 컴퓨팅 비용 절감 | 내결함성 작업 | 어려움 |
OpenShift AI는 이런 고급 기법을 플랫폼에 통합했습니다. 관리자는 GPU 공유 정책을 ConfigMap으로 설정하고, 사용자는 그냥 GPU 개수만 요청하면 됩니다. 백그라운드에서 스케줄러가 최적 배치를 찾아줍니다. Time-slicing, MIG, DRA를 조합해서 물리 GPU 8개로 논리 GPU 40~50개를 만들 수 있습니다. 활용률이 30%에서 80%로 올라가면 비용은 절반 이하로 떨어집니다.
Kubernetes GPU 스케줄링 세션에서 강조한 것처럼 대규모 클러스터에서는 eBPF로 커널 레벨 성능 데이터를 수집해서 병목을 찾아야 합니다. OpenShift AI는 Prometheus로 GPU 활용률, 메모리 사용량, PCIe 대역폭을 실시간 수집하고, Grafana 대시보드로 시각화합니다. 비효율이 보이면 즉시 최적화할 수 있죠.
Hugging Face 모델을 사내 인프라로 가져오는 법
Hugging Face에는 50만 개 이상의 오픈소스 모델이 있습니다. Llama, Mistral, BERT, GPT-Neo. 그냥 다운받아 쓰면 될 것 같지만 현실은 다릅니다. 인터넷에서 받은 모델을 프로덕션에 바로 올릴 순 없습니다. 보안 검증, 라이선스 확인, 성능 최적화가 필요합니다.
OpenShift AI는 Hugging Face 모델을 안전하게 가져오는 워크플로우를 제공합니다. 첫 단계는 모델 다운로드입니다. Hugging Face Hub API로 모델 가중치와 설정 파일을 가져옵니다. 두 번째는 보안 스캔입니다. 모델 파일에 악성 코드나 취약점이 없는지 검사합니다. 세 번째는 최적화입니다. vLLM, TensorRT로 추론 속도를 10배 높입니다. 네 번째는 배포입니다. KServe로 모델을 서빙하고 오토스케일링을 설정합니다.
# Hugging Face 모델을 OpenShift AI로 가져오기
# Step 1: 워크벤치에서 모델 다운로드 및 테스트
# jupyter notebook
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
import os
# Hugging Face 모델 다운로드
model_name = "meta-llama/Llama-2-7b-chat-hf"
# ✅ OpenShift Secret에서 HF 토큰 가져오기
hf_token = os.environ.get('HF_TOKEN')
tokenizer = AutoTokenizer.from_pretrained(
model_name,
token=hf_token
)
model = AutoModelForCausalLM.from_pretrained(
model_name,
torch_dtype=torch.float16,
device_map="auto", # GPU 자동 할당
token=hf_token
)
# 로컬 테스트
prompt = "What is machine learning?"
inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
outputs = model.generate(**inputs, max_length=100)
print(tokenizer.decode(outputs[0]))
# ✅ 모델을 S3 모델 레지스트리로 업로드
model.save_pretrained("/mnt/models/llama-2-7b-chat")
tokenizer.save_pretrained("/mnt/models/llama-2-7b-chat")
print("✅ 모델 저장 완료")
# Step 2: vLLM으로 최적화된 서빙
# vllm_deployment.yaml
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: llama-2-chat
namespace: llm-models
spec:
predictor:
model:
modelFormat:
name: vllm
storageUri: "s3://models/llama-2-7b-chat"
resources:
requests:
memory: "16Gi"
cpu: "4"
limits:
memory: "32Gi"
nvidia.com/gpu: "1"
env:
- name: MODEL_NAME
value: "llama-2-7b-chat"
- name: MAX_MODEL_LEN
value: "4096"
- name: GPU_MEMORY_UTILIZATION
value: "0.9"
- name: DTYPE
value: "half" # FP16으로 메모리 절반
- name: TRUST_REMOTE_CODE
value: "true"
minReplicas: 1
maxReplicas: 10
scaleMetric: concurrency
scaleTarget: 20 # 동시 요청 20개당 Pod 1개
# Step 3: Tekton 파이프라인으로 자동화
# hf-import-pipeline.yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: huggingface-import
spec:
params:
- name: model-id
description: "Hugging Face model ID"
type: string
- name: model-name
description: "Internal model name"
type: string
tasks:
# Task 1: Hugging Face에서 다운로드
- name: download-model
taskSpec:
params:
- name: model-id
type: string
steps:
- name: download
image: python:3.11
script: |
#!/usr/bin/env python3
from transformers import AutoModel, AutoTokenizer
import os
model_id = "$(params.model-id)"
hf_token = os.environ['HF_TOKEN']
print(f"Downloading {model_id}...")
tokenizer = AutoTokenizer.from_pretrained(
model_id, token=hf_token
)
model = AutoModel.from_pretrained(
model_id, token=hf_token
)
# 로컬 저장
output_path = "/workspace/model"
model.save_pretrained(output_path)
tokenizer.save_pretrained(output_path)
print(f"✅ Downloaded to {output_path}")
env:
- name: HF_TOKEN
valueFrom:
secretKeyRef:
name: huggingface-secret
key: token
volumeMounts:
- name: model-storage
mountPath: /workspace
volumes:
- name: model-storage
persistentVolumeClaim:
claimName: model-pvc
# Task 2: 보안 스캔
- name: security-scan
runAfter: ["download-model"]
taskSpec:
steps:
- name: scan
image: aquasec/trivy:latest
script: |
#!/bin/sh
echo "Scanning model files for vulnerabilities..."
trivy fs /workspace/model --severity HIGH,CRITICAL
volumeMounts:
- name: model-storage
mountPath: /workspace
volumes:
- name: model-storage
persistentVolumeClaim:
claimName: model-pvc
# Task 3: 최적화 (양자화)
- name: optimize-model
runAfter: ["security-scan"]
taskSpec:
steps:
- name: quantize
image: python:3.11
script: |
#!/usr/bin/env python3
from transformers import AutoModel, AutoTokenizer
import torch
print("Loading model for quantization...")
model = AutoModel.from_pretrained("/workspace/model")
tokenizer = AutoTokenizer.from_pretrained("/workspace/model")
# INT8 양자화 (모델 크기 1/4)
quantized_model = torch.quantization.quantize_dynamic(
model, {torch.nn.Linear}, dtype=torch.qint8
)
# 최적화된 모델 저장
quantized_model.save_pretrained("/workspace/model-optimized")
tokenizer.save_pretrained("/workspace/model-optimized")
print("✅ Model optimized with INT8 quantization")
volumeMounts:
- name: model-storage
mountPath: /workspace
volumes:
- name: model-storage
persistentVolumeClaim:
claimName: model-pvc
# Task 4: S3 레지스트리로 업로드
- name: upload-to-registry
runAfter: ["optimize-model"]
taskSpec:
params:
- name: model-name
type: string
steps:
- name: upload
image: amazon/aws-cli:latest
script: |
#!/bin/sh
aws s3 sync /workspace/model-optimized \
s3://models/$(params.model-name) \
--endpoint-url $S3_ENDPOINT
echo "✅ Model uploaded to S3"
env:
- name: AWS_ACCESS_KEY_ID
valueFrom:
secretKeyRef:
name: s3-credentials
key: access-key
- name: AWS_SECRET_ACCESS_KEY
valueFrom:
secretKeyRef:
name: s3-credentials
key: secret-key
- name: S3_ENDPOINT
value: "http://minio.storage.svc:9000"
volumeMounts:
- name: model-storage
mountPath: /workspace
volumes:
- name: model-storage
persistentVolumeClaim:
claimName: model-pvc
# Task 5: KServe로 자동 배포
- name: deploy-model
runAfter: ["upload-to-registry"]
taskSpec:
params:
- name: model-name
type: string
steps:
- name: create-inferenceservice
image: bitnami/kubectl:latest
script: |
#!/bin/sh
cat <<EOF | kubectl apply -f -
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: $(params.model-name)
spec:
predictor:
model:
modelFormat:
name: vllm
storageUri: "s3://models/$(params.model-name)"
resources:
limits:
nvidia.com/gpu: 1
EOF
echo "✅ Model deployed as InferenceService"
# Step 4: 파이프라인 실행
# oc create -f hf-import-pipeline.yaml
# PipelineRun 생성
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
name: import-llama-2
spec:
pipelineRef:
name: huggingface-import
params:
- name: model-id
value: "meta-llama/Llama-2-7b-chat-hf"
- name: model-name
value: "llama-2-7b-chat-v1"
workspaces:
- name: shared-workspace
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Gi
# 실행 모니터링
# tkn pipelinerun logs import-llama-2 -f
# Step 5: 배포된 모델 테스트
curl -X POST https://llama-2-chat.apps.openshift.com/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "llama-2-7b-chat",
"prompt": "What is machine learning?",
"max_tokens": 100,
"temperature": 0.7
}'| 단계 | 수동 방식 | OpenShift AI 파이프라인 | 시간 절감 |
|---|---|---|---|
| 모델 검색 | Hugging Face 웹 탐색 | 카탈로그에서 검색 | 동일 |
| 다운로드 | Python 스크립트 작성 | Task로 자동화 | 1시간 → 자동 |
| 보안 검증 | 수동 파일 검사 | Trivy 자동 스캔 | 1일 → 5분 |
| 최적화 | 양자화 스크립트 작성 | 자동 INT8/FP16 변환 | 2일 → 자동 |
| 레지스트리 업로드 | AWS CLI 수동 실행 | 파이프라인 Step | 30분 → 자동 |
| 배포 | YAML 작성 및 적용 | InferenceService 자동 생성 | 1일 → 자동 |
| 모니터링 설정 | Prometheus 설정 | 자동 메트릭 수집 | 1일 → 즉시 |
| 전체 프로세스 | 5~7일 수동 작업 | 1~2시간 자동화 | 95% 시간 절감 |
Jozu 사례는 이 워크플로우가 얼마나 강력한지 보여줍니다. KitOps와 OpenShift Pipelines를 결합해서 Hugging Face 챗봇 모델을 자동으로 가져와 배포하는 파이프라인을 만들었습니다. Git에 모델 ID만 커밋하면 파이프라인이 트리거되고, 10분 후에는 프로덕션에서 모델이 서빙됩니다. 수동 개입이 전혀 없습니다.
보안도 중요합니다. Hugging Face 모델은 오픈소스지만 라이선스가 제각각입니다. Llama 2는 상업적 사용에 제한이 있고, GPT-Neo는 MIT 라이선스입니다. OpenShift AI 파이프라인에 라이선스 체크를 넣으면 규정 위반 모델이 자동으로 걸러집니다. 법무팀이 안심할 수 있죠.
성공 사례 Red Hat과 함께 AI 전환에 성공한 기업들
Guidehouse와 미국 제대군인부의 사례는 감동적입니다. 재향 군인의 극단적 선택을 예방하기 위해 건강 데이터를 AI로 분석하는 플랫폼을 구축했습니다. 수십만 재향 군인의 의료 기록, 처방 정보, 상담 기록을 실시간으로 분석해서 위험 신호를 조기에 감지합니다.
이 프로젝트의 도전 과제는 엄청났습니다. 첫째는 보안입니다. 의료 데이터는 HIPAA 규정을 준수해야 하고, 정부 시스템은 FISMA 인증이 필요합니다. 퍼블릭 클라우드 AI 서비스는 쓸 수 없었죠. Red Hat OpenShift AI를 온프레미스에 구축해서 데이터가 외부로 나가지 않게 했습니다.
둘째는 확장성입니다. 초기에는 몇천 명 데이터로 시작했지만, 전국 병원으로 확대하면서 수십만 명으로 늘었습니다. OpenShift의 오토스케일링과 분산 처리로 데이터 증가에 대응했습니다. 셋째는 정확도입니다. 생명이 걸린 시스템이라 오탐과 미탐을 최소화해야 했습니다. MLOps 파이프라인으로 모델을 지속적으로 재학습하고, A/B 테스트로 검증한 후에만 배포했습니다.
결과는 놀라웠습니다. AI가 위험 신호를 조기에 감지해서 상담사가 선제적으로 개입할 수 있게 됐습니다. 수많은 생명을 구했죠. Guidehouse는 이 성공을 바탕으로 다른 정부 기관에도 OpenShift AI 기반 솔루션을 제공하고 있습니다.
Airbus Helicopters는 항공 산업에서 OpenShift AI를 활용합니다. 헬리콥터 센서 데이터를 분석해서 고장을 예측하는 AI를 만들었습니다. 수천 개 센서가 실시간으로 데이터를 보내는데, 이걸 처리하려면 엄청난 컴퓨팅 파워가 필요합니다.
OpenShift AI의 분산 처리로 대용량 데이터를 빠르게 분석하고, Prometheus 모니터링으로 이상 징후를 즉시 감지합니다. 클러스터 업데이트 주기가 몇 주에서 며칠로 단축됐고, 애플리케이션 배포 시간은 80% 줄었습니다. 예측 정비로 항공기 가동률이 올라가고 유지보수 비용은 내려갔습니다.
Novobanco는 금융권 사례입니다. Microsoft Azure Red Hat OpenShift에 하이브리드 환경을 구축해서 고객 디지털 뱅킹 경험을 혁신했습니다. 챗봇으로 고객 문의에 24시간 응답하고, 이상 거래를 AI로 탐지하며, 개인화된 금융 상품을 추천합니다.
금융권의 엄격한 규제를 준수하면서 클라우드의 민첩성을 얻는 게 핵심이었습니다. 민감한 데이터는 온프레미스에 두고, 비즈니스 로직은 Azure에서 돌립니다. OpenShift가 하이브리드 환경을 단일 플랫폼으로 통합해서 시장 출시 시간을 단축하고, 운영 비용을 줄이고, 고객 기반을 확장할 수 있었습니다.
| 기업 | 산업 | 도전 과제 | OpenShift AI 활용 | 성과 |
|---|---|---|---|---|
| Guidehouse + VA | 정부 의료 | HIPAA 규정 준수 대규모 의료 데이터 생명 관련 정확도 | 온프레미스 프라이빗 배포 MLOps 자동화 지속적 재학습 | 재향 군인 생명 구조 조기 위험 감지 규정 준수 |
| Airbus Helicopters | 항공 제조 | 실시간 센서 데이터 예측 정비 고가용성 | 분산 데이터 처리 실시간 모니터링 오토스케일링 | 배포 시간 80% 단축 가동률 향상 비용 절감 |
| Novobanco | 금융 | 금융 규제 하이브리드 클라우드 고객 경험 | Azure + 온프레미스 통합 챗봇 및 추천 시스템 이상 거래 탐지 | 시장 출시 가속화 운영 비용 감소 고객 기반 확장 |
| DNEG | 영상 제작 | 대용량 렌더링 개발자 생산성 유연한 확장 | GPU 클러스터 관리 아티스트용 워크플로우 Platform Plus | 프로덕션 간소화 효율성 증대 확장 가능 환경 |
이 사례들의 공통점은 명확합니다. 첫째는 규제 준수입니다. 의료, 금융, 항공처럼 민감한 산업에서는 데이터 주권과 보안이 최우선입니다. Red Hat의 엔터프라이즈급 보안과 규정 준수 지원이 신뢰를 줬습니다.
둘째는 하이브리드 클라우드입니다. 모든 워크로드를 퍼블릭 클라우드로 옮길 순 없습니다. 레거시 시스템, 데이터 위치, 비용 고려사항이 있죠. OpenShift AI는 온프레미스, 프라이빗 클라우드, 퍼블릭 클라우드를 단일 플랫폼으로 통합합니다.
셋째는 MLOps 자동화입니다. 수동 배포는 확장할 수 없습니다. Tekton 파이프라인으로 개발부터 배포까지 자동화하면 속도와 안정성이 모두 올라갑니다. Forrester가 측정한 210% ROI는 이런 효율 증대에서 나옵니다.
MLOps는 더 이상 선택이 아닙니다. AI를 프로덕션에서 운영하려면 필수입니다. 하지만 도구가 파편화되어 있으면 구축도 유지보수도 악몽이 됩니다. Red Hat OpenShift AI는 주피터에서 쿠버네티스까지, 개발에서 운영까지, 모든 걸 하나의 플랫폼으로 통합했습니다.
데이터 과학자는 익숙한 도구로 일하고, DevOps는 검증된 쿠버네티스로 배포하며, 보안팀은 규정 준수를 자동화합니다. GPU는 효율적으로 공유되고, Hugging Face 모델은 안전하게 가져오며, 파이프라인은 자동으로 실행됩니다. Forrester가 측정한 대로 생산성 20% 증가, 효율 60% 향상, 3년 ROI 210%가 가능한 이유입니다.
지금 당신의 MLOps 환경은 얼마나 파편화되어 있나요. 6개월 걸려 구축한 파이프라인이 다음 프로젝트에서 또 6개월 걸리나요. OpenShift AI는 한 번 구축하면 계속 재사용할 수 있는 플랫폼입니다. Red Hat이 30년간 엔터프라이즈를 지원해온 신뢰로 AI 여정을 함께 합니다.
공식 참고 링크 안내
Red Hat OpenShift AI MLOps 가이드
.jpg)
.jpg)
.jpg)
0 댓글