2026년 MLOps: MLflow, 모델 레지스트리와 기술 면접 질문

MLOps 면접 질문은 2026년 들어 틈새 전문 영역에서 데이터 사이언스와 머신러닝 엔지니어링 채용의 핵심 요소로 자리 잡았습니다. 이제 팀은 모델이 어떻게 학습되는지만 묻지 않고, 실제 트래픽이 유입된 이후 모델이 어떻게 추적되고 버전 관리되며 배포되고 모니터링되는지를 파고듭니다. 이 가이드는 MLOps 면접에서 반복적으로 등장하는 질문들을 라이프사이클 단계별로 정리하고, 프로덕션 환경을 그대로 반영한 MLflow 예제와 함께 다룹니다.

머신러닝 라이프사이클에 관한 MLOps 면접 질문

Q1: MLOps란 무엇이며 DevOps와 어떻게 다른가요?

MLOps는 자동화, CI/CD, 모니터링 같은 DevOps 원칙을 머신러닝 시스템에 적용한 뒤, 전통적인 소프트웨어에는 없는 세 가지 관심사를 더합니다. 데이터 버전 관리, 모델 버전 관리, 그리고 실시간 데이터 분포에 대한 지속적 검증입니다. 고전적인 DevOps에서는 코드만이 변하는 유일한 아티팩트입니다. MLOps에서는 코드, 데이터, 학습된 모델이 각각 독립적으로 버전을 가지며, 이 셋 중 어느 하나라도 코드 한 줄 바뀌지 않은 채 출력 품질을 조용히 저하시킬 수 있습니다. 자주 인용되는 머신러닝 시스템의 숨겨진 기술 부채 논문은 모델 코드가 실제 ML 시스템에서 아주 작은 부분에 불과하며, 데이터 파이프라인, 모니터링, 설정이 표면적의 대부분을 차지한다는 점을 짚습니다.

Q2: 프로덕션 ML 라이프사이클의 단계들을 설명해 보세요.

좋은 답변은 다섯 단계와 각 단계가 만들어내는 아티팩트를 함께 언급합니다. 데이터 수집 및 검증(버전이 매겨진 데이터셋), 실험(지표가 추적되는 실행), 모델 등록(버전이 매겨지고 승격 가능한 모델), 배포(서빙 엔드포인트 또는 배치 작업), 모니터링(재학습으로 되먹임되는 드리프트 및 성능 텔레메트리)입니다. 면접관은 피드백 루프에 귀를 기울입니다. 모니터링은 반드시 실험으로 되돌아 연결되어야 하며, 그렇지 않으면 시스템은 시간이 지나며 썩어가는 단방향 파이프라인에 지나지 않습니다.

MLflow 튜토리얼 예제로 살펴보는 실험 추적

실험 추적은 대부분의 MLOps 질문이 그 위에 쌓이는 토대이므로, 실제 로깅을 보여주는 MLflow 튜토리얼 답변이 무게를 갖습니다. MLflow는 실행마다 파라미터, 지표, 아티팩트를 기록하여 어떤 결과든 그 실행 ID로부터 재현할 수 있게 만듭니다.

Q3: MLflow 추적은 실험을 어떻게 포착하며, 실행 ID는 왜 중요한가요?

mlflow.start_run()을 호출할 때마다 하이퍼파라미터, 지표, 직렬화된 모델을 기록하는 실행이 하나 열립니다. 실행 ID는 하나의 지표를 그것을 만들어낸 정확한 코드, 파라미터, 데이터 스냅샷에 묶어주는 불변의 핸들이며, 이것이 몇 달 뒤에도 실험을 재현할 수 있게 하는 요소입니다.

# train_with_mlflow.py
import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import f1_score

mlflow.set_tracking_uri("http://localhost:5000")  # tracking server
mlflow.set_experiment("churn-prediction")

with mlflow.start_run(run_name="rf-baseline") as run:
    params = {"n_estimators": 300, "max_depth": 12}
    model = RandomForestClassifier(**params).fit(X_train, y_train)

    f1 = f1_score(y_val, model.predict(X_val))

    mlflow.log_params(params)                       # hyperparameters
    mlflow.log_metric("val_f1", f1)                 # validation metric
    mlflow.sklearn.log_model(model, name="model")   # MLflow 3.x uses name=

    print("run_id:", run.info.run_id)               # reproducibility handle

name 인자는 MLflow 3.x에서 더 이상 권장되지 않는 artifact_path를 대체하며, 현재 API를 인지하고 있음을 보여주기 위해 언급할 가치가 있는 변경점입니다. ML 파이프라인 검증 패턴을 통해 피처와 데이터셋 추적을 언급하는 지원자는 대체로 더 높은 점수를 받는데, 재현성은 모델만이 아니라 파이프라인 전체에 달려 있기 때문입니다.

모델 레지스트리 2026: 버전 관리와 승격

MLflow 모델 레지스트리는 실행 아티팩트를 거버넌스가 적용되고 승격 가능한 객체로 바꿉니다. 가장 큰 최근 변화이자 2026년 면접에서 자주 파고드는 지점은 이름이 붙은 스테이지에서 벗어난 전환입니다.

Q4: MLflow 모델 레지스트리는 모델을 어떻게 승격하며, 2026년에 무엇이 바뀌었나요?

이전 MLflow 버전은 Staging, Production, Archived라는 이름의 고정된 스테이지를 통해 모델을 승격했습니다. MLflow 3.x는 이러한 스테이지를 폐기하고 별칭(alias)과 태그를 채택했는데, 하드코딩된 스테이지 목록으로는 챔피언, 챌린저, 섀도우 같은 실제 배포 토폴로지를 표현할 수 없었기 때문입니다. 별칭은 하나의 버전을 가리키는 변경 가능한 포인터이므로, 승격은 모델을 변형하는 것이 아니라 별칭을 재지정하는 일이 됩니다.

# register_and_promote.py
import mlflow
from mlflow import MlflowClient

client = MlflowClient()

# Register a logged run artifact as a new model version
result = mlflow.register_model(
    model_uri=f"runs:/{run_id}/model",
    name="churn-classifier"
)

# MLflow 3.x: aliases replace deprecated stages
client.set_registered_model_alias(
    name="churn-classifier",
    alias="champion",        # production traffic resolves here
    version=result.version
)

# Any service loads the current champion without knowing the version
model = mlflow.pyfunc.load_model("models:/churn-classifier@champion")

소비자가 models:/churn-classifier@champion을 로드하기 때문에, 롤백은 이전 버전으로 별칭을 한 번 재지정하는 것으로 끝나며 재배포가 필요 없습니다. 공식 MLflow 모델 레지스트리 문서는 별칭 거버넌스와 웹훅 트리거를 깊이 있게 다룹니다.

머신러닝 배포 패턴과 서빙

배포 질문은 모델을 실제로 출시해 본 지원자와 학습만 해 본 지원자를 갈라놓습니다. 패턴 선택은 개인 취향이 아니라 지연 시간 예산을 따릅니다.

Q5: 배치, 온라인, 스트리밍 머신러닝 배포를 비교해 보세요.

| 패턴 | 지연 시간 | 대표적 활용 사례 | 서빙 표면 | |---------|---------|------------------|-----------------| | 배치 | 수 시간에서 하루 | 이탈 스코어링, 추천 갱신 | 테이블에 기록하는 예약 작업 | | 온라인(실시간) | 수십 밀리초 | 사기 탐지, 요청 시점 랭킹 | REST 또는 gRPC 엔드포인트 | | 스트리밍 | 1초 미만, 연속적 | 이벤트 흐름의 이상 탐지 | 메시지 큐의 컨슈머 |

후속 질문은 거의 언제나 온라인 사례를 어떻게 서빙할지를 묻습니다. MLflow 모델은 자체 환경을 함께 패키징하므로, 레지스트리 URI에 대해 명령어 하나로 서빙할 수 있습니다.

# serve_model.sh
# Serve the current champion as a REST endpoint on port 5001
mlflow models serve \
  --model-uri "models:/churn-classifier@champion" \
  --host 0.0.0.0 --port 5001 --env-manager uv

Q6: 블루-그린과 카나리 배포는 모델 롤아웃의 위험을 어떻게 줄이나요?

블루-그린은 두 개의 동일한 환경을 유지하다가 새 모델이 검사를 통과한 뒤 모든 트래픽을 한 번에 전환하여 즉각적인 롤백 경로를 제공합니다. 카나리는 트래픽의 작은 비율을 새 버전으로 보내고 실시간 지표를 관찰한 뒤 점진적으로 늘려갑니다. 모델의 경우 대개 카나리가 더 안전한데, 모델 품질 문제는 실제 입력에 대해서만 드러나며 카나리가 그 영향 범위를 일부 사용자로 제한하기 때문입니다. 두 방식 모두 별칭 재지정으로 전환과 롤백을 구현할 수 있어, 레지스트리를 트래픽 라우팅의 단일 진실 원천으로 삼는 것이 실무 감각을 보여주는 답변입니다.

머신러닝 파이프라인의 테스트와 CI/CD

Q7: ML 파이프라인의 CI/CD는 일반 소프트웨어 파이프라인이 하지 않는 무엇을 테스트하나요?

소프트웨어 CI 파이프라인은 코드에 대해 단위 테스트와 통합 테스트를 실행합니다. ML 파이프라인은 그 위에 데이터 및 모델 테스트를 더합니다. 유입 데이터에 대한 스키마 검증, 학습 실행이 손상된 피처를 조용히 흡수하지 않도록 하는 분포 검사, 그리고 후보 모델이 고정된 홀드아웃 세트에서 현재 챔피언보다 낮은 점수를 받으면 빌드를 실패시키는 모델 품질 게이트입니다. 따라서 ML을 위한 지속적 전달은 컨테이너 이미지뿐 아니라 모델 아티팩트를 승격하며, 승격 게이트는 초록불 테스트 스위트만이 아니라 지표 임계값입니다. 엄격한 파이프라인은 또한 데이터 스냅샷과 의존성 버전을 고정하여 어떤 재실행이든 결정론적으로 만드는데, 이것이 재현 가능한 빌드와 오늘 우연히 통과하는 빌드를 가르는 차이입니다.

모니터링, 데이터 드리프트, 모델 재학습

배포된 모델은 세상이 그 아래에서 변해감에 따라 성능이 저하되므로, 모니터링 질문은 시니어 신호가 드러나는 지점입니다. 여기서 면접관은 지원자가 지표를 정의하고 임계값을 정하며 경보를 재학습 결정으로 연결하는지를 살핍니다.

Q8: 데이터 드리프트는 어떻게 탐지하며, 어떤 지표가 그것을 정량화하나요?

데이터 드리프트란 프로덕션 입력의 분포가 학습 분포에서 멀어졌다는 뜻입니다. 인구 안정성 지수(PSI, Population Stability Index)는 흔히 쓰이는 프레임워크 독립적 측정치입니다. 기준 분포를 구간으로 나누고, 그 구간에 대해 프로덕션 빈도를 비교한 뒤, 가중 로그 차이를 합산합니다.

# population_stability_index.py
import numpy as np

def psi(reference, production, bins=10):
    # Bin edges come from the reference (training) distribution
    edges = np.quantile(reference, np.linspace(0, 1, bins + 1))
    edges[0], edges[-1] = -np.inf, np.inf

    ref_pct = np.histogram(reference, edges)[0] / len(reference)
    prod_pct = np.histogram(production, edges)[0] / len(production)

    # Clip to avoid division by zero and log(0)
    ref_pct = np.clip(ref_pct, 1e-6, None)
    prod_pct = np.clip(prod_pct, 1e-6, None)

    return float(np.sum((prod_pct - ref_pct) * np.log(prod_pct / ref_pct)))

# PSI < 0.1 stable | 0.1-0.25 moderate shift | > 0.25 major drift, investigate
score = psi(reference_scores, production_scores)

직접 구현한 지표를 넘어, 프로덕션 팀은 Evidently 같은 도구를 활용하여 피처 드리프트, 타깃 드리프트, 데이터 품질을 정기적으로 추적합니다. 완결된 답변은 데이터 드리프트(입력이 이동)와 개념 드리프트(입력과 출력의 관계가 이동)를 구분하는데, 후자는 입력만 관찰해서는 잡을 수 없고 라벨링된 결과가 필요하기 때문입니다.

Q9: 재학습 파이프라인은 무엇에 의해 트리거되어야 하나요?

고정된 주기에 따른 시간 기반 재학습은 가장 단순한 선택지이지만, 아무것도 변하지 않았을 때는 컴퓨팅을 낭비하고 무언가 망가졌을 때는 느리게 반응합니다. 더 나은 트리거는 지표 기반입니다. PSI가 임계값을 넘을 때, 실시간 평가 지표가 하한 아래로 떨어질 때, 또는 새로 라벨링된 데이터에 대한 예약 백테스트가 퇴보할 때 재학습하는 것입니다. 그러면 재학습 작업은 챌린저를 등록하고, 어떤 별칭이 재지정되기 전에 카나리 롤아웃이 이를 현재 챔피언과 비교합니다.

MLOps 시스템 디자인 면접 질문

Q10: 일관된 피처로 수백 개의 모델을 서빙하는 플랫폼을 설계해 보세요.

기대되는 핵심은 피처 스토어입니다. 피처를 한 번 계산하여 학습과 추론 양쪽에 동일한 값을 제공함으로써 학습-서빙 편향(training-serving skew)을 해결합니다. Feast 같은 도구는 학습을 위한 오프라인 스토어와 서빙을 위한 저지연 온라인 스토어를 제공합니다. 완전한 설계는 버전 관리를 위한 모델 레지스트리, 계보를 위한 추적 서버, 파이프라인을 위한 오케스트레이터, 그리고 재학습으로 루프를 닫는 모니터링 계층까지 함께 언급합니다. 이 피처 엔지니어링 면접 가이드에서 다루는 트레이드오프처럼 실제 피처 작업에 답변을 근거 짓는 것은 다이어그램 암기가 아니라 실무 경험을 보여주는 신호입니다.

결론

• MLOps를 DevOps에 데이터와 모델 버전 관리를 더한 것으로 규정하세요. 재현성, 승격 안정성, 모니터링이 면접관이 점수를 매기는 세 축입니다
• MLflow 3.x API 변화를 알아두세요. 별칭과 태그가 폐기된 Staging 및 Production 스테이지를 대체하고, log_model은 이제 artifact_path 대신 name을 받습니다
• 배포 패턴을 지연 시간 예산에 맞추고, 모델 롤아웃에서는 품질 문제가 실시간 입력에 대해서만 나타나므로 블루-그린보다 카나리를 기본값으로 삼으세요
• PSI 같은 구체적 지표로 드리프트를 정량화하고, 라벨 없이 보이는 것은 둘 중 하나뿐이므로 데이터 드리프트와 개념 드리프트를 구분하세요
• 달력이 아니라 지표에 따라 재학습을 트리거하고, 그 결과로 나온 챌린저를 챔피언 별칭을 재지정하기 전에 카나리로 통과시키세요
• 어떤 시스템 디자인 답변에서든 피처 스토어를 언급하여, 후속 질문으로 제기되기 전에 학습-서빙 편향 간극을 메우세요