Field Notes · 2026 AutoML for MLOps
A Visual Field Guide · v1

AutoML,
MLOps를 이미 아는
사람을 위한 지도.

MLOps의 자동화는 학습→배포→모니터링의 파이프라인 운영이고, AutoML의 자동화는 그 안쪽 모델 빌드 단계를 검색·최적화로 대체합니다. 이 문서는 두 자동화가 어디에서 만나고 어디에서 충돌하는지를, 다이어그램 위주로 정리합니다.

READING 20–25분 SECTIONS 07 FOR ML Platform · MLOps · Applied DS
01 / WHY
위치 잡기 · Position

MLOps와 AutoML은 다른 축을 자동화한다.

MLOps는 시간(T) 축의 자동화입니다 — 학습→배포→모니터링→재학습이 반복되는 라이프사이클을 안정화합니다. AutoML은 모델 공간(𝒜) 축의 자동화입니다 — 한 번의 학습 라운드 안에서 어떤 모델·하이퍼·아키텍처를 시도할지를 검색합니다. 두 자동화는 직교(orthogonal)하며, 잘 결합될 때 비로소 “모델 카탈로그”가 자가복제하기 시작합니다.

T · 시간 / 운영 라이프사이클 𝒜 · 모델·하이퍼·아키텍처 공간 Train Validate Deploy (KServe) Serve Monitor (drift) Retrain Trigger MLOps 루프 — 시간 축 자동화 Hyperparameters lr, batch, depth, λ … Architecture cells, ops, depth, width Feature engineering encoding, agg, interactions Algorithm class tree, linear, NN, kernel AutoML 검색 — 모델공간 축 자동화 결합 영역 / Continuous AutoML 새 데이터가 들어오면 검색공간을 다시 열고 모델을 갱신 Kubeflow Katib · Vertex AutoML · SageMaker Autopilot + MLflow / Model Registry / Drift triggers 자가복제하는 모델 카탈로그 두 축은 직교한다 — orthogonal 한 축만 자동화된 시스템은 반대 축에서 병목이 생긴다.
FIG. 01 · MLOps는 T 축(라이프사이클), AutoML은 𝒜 축(모델 공간)을 자동화한다. 결합 영역에서 “Continuous AutoML”이 발생한다.

MLOps만 있을 때의 병목

파이프라인은 잘 돌지만, 새로운 도메인·새 라벨·새 분포에 대해 모델 후보 자체를 다시 정해야 할 때 사람이 들어와서 EDA→피처→하이퍼를 손으로 다시 짭니다. CI/CD는 자동인데 모델은 수공예입니다.

AutoML만 있을 때의 병목

좋은 모델은 나오지만 언제 다시 돌릴지·어디로 배포할지·드리프트 검출은 누가 하는지가 비어 있습니다. 한 번 좋은 leaderboard가 박제되어 운영 누수가 생깁니다.

Operating principle

실무에서 “AutoML 도입”은 새 라이브러리 채택보다 기존 MLOps의 학습 단계를 검색 단계로 치환하는 작업에 가깝다. Kubeflow가 있으면 Katib을, Vertex AI가 있으면 AutoML 트레이닝잡을 그 자리에 끼우는 식이다.

02 / STAGES
자동화 가능 영역 · Coverage

AutoML이 실제로 자동화하는 단계.

“AutoML”이라는 단어 하나가 너무 많은 것을 가리킵니다. 실제 시스템마다 자동화 범위가 다르고, 같은 프레임워크 안에서도 옵션마다 범위가 달라집니다. 아래 다이어그램은 데이터에서 모델까지 흐름을 펼친 뒤, 어떤 단계가 어떤 도구에 의해 자동화되는지를 표시합니다.

Data ingestion 스키마·결측치 타입 추론 Cleaning imputation outlier · scaling Feature eng. encoding · interaction agg · DFS · embedding Model selection tree · linear · NN kernel · boosting HPO hyperparam + early stop NAS depth · width cell · ops Ensembling stacking weighted blend AutoML이 다루는 핵심 영역 Optuna · Ray Tune · Hyperopt · Katib(HPO) Tabular AutoML — AutoGluon · H2O · FLAML · Auto-sklearn · TPOT Deep AutoML — AutoKeras · NNI · AutoGluon-DL · Vertex/SageMaker AutoML Cloud E2E AutoML — Vertex AI AutoML · SageMaker Autopilot · Azure AutoML (데이터 업로드만 하면 끝) ‣ 회색 단계(Ingestion·Cleaning)는 도메인 의존도가 높아 거의 자동화되지 않는다 — 사람이 만든 컨트랙트가 입력으로 들어가야 한다. ‣ Feature eng.은 정형 데이터에서는 Featuretools/AutoFeat 같은 DFS로 자동화 가능, 비정형(이미지·텍스트)에서는 사실상 “좋은 백본 임베딩 선택”으로 환원된다. ‣ Ensembling은 거의 모든 AutoML 시스템이 마지막에 자동으로 붙인다 — 단일 모델로 비교하면 AutoML이 손해를 본다.
FIG. 02 · 같은 단어 “AutoML”이라도 도구마다 자동화 영역이 다르다. 도입 전에 “어디부터 어디까지 책임지는가”를 먼저 합의해야 한다.
03 / HPO
하이퍼파라미터 최적화 · Search Algorithms

HPO 알고리즘은 샘플링 패턴이 다 다르다.

모든 HPO 알고리즘은 같은 문제를 풉니다 — 비싼 black-box 함수 val_loss = f(λ)의 최소점을 찾되 호출 횟수를 줄이는 것. 차이는 어디를 다음에 시도할지 결정하는 정책뿐입니다. 같은 2D 손실 표면 위에서 각 알고리즘이 어떻게 점을 찍는지 비교합니다.

A · Grid Search B · Random Search C · Bayesian (TPE / GP) D · Hyperband / ASHA 동일 간격, 차원 늘면 폭발 차원이 많을수록 강함 surrogate로 다음 위치 선택 자원을 짧게 → 점점 길게 k^d trials · d↑ → 폭발 동일 예산이면 grid보다 강력 최소점 주변으로 수렴 resources → rung 0 (R/9 epochs) rung 1 (R/3 epochs) rung 2 (R epochs) 최종 후보 train full Successive Halving + 다중 bracket
FIG. 03 · 동일한 손실 표면 위에서의 샘플링 패턴. Grid는 차원이 늘면 폭발, Bayesian은 점점 모이고, Hyperband는 자원을 단계적으로 키우며 솎아낸다.

Grid Search kd

차원 d가 작고, 모델 학습이 빠를 때만. 재현성·해석은 최고. d=3만 넘어가도 폭발.

Random Search O(N)

실용적인 베이스라인. 중요한 차원이 소수일 때 grid보다 우수함이 이론·실험 모두 입증(Bergstra & Bengio, 2012).

Bayesian (TPE/GP) SURROGATE

이전 시도로 surrogate를 학습하고 acquisition function으로 다음 점 선택. Optuna는 기본이 TPE.

Hyperband / ASHA MULTI-FIDELITY

“가벼운 학습으로 거른 뒤 살아남은 후보만 길게.” 분산 환경에서는 ASHA가 사실상 표준.

BOHB BAYES + HYPERBAND

Hyperband의 자원 배분 + 각 bracket 안에서 TPE로 후보 선택. 두 세계를 합친 형태.

PBT (Population-Based Training) EVOLUTION

여러 학습을 병렬로 돌리며 학습 도중에 하이퍼를 mutation. RL/대형 NN에서 강력. Ray Tune이 기본 지원.

Evolutionary GA / CMA-ES

표면이 험하거나 비미분형 metric일 때. CMA-ES는 연속·중차원에서 안정.

Gradient-based HPO HYPERGRADIENT

학습률 스케줄·손실 가중치 같이 미분 가능한 하이퍼에 한해, hypergradient를 직접 역전파.

실무 선택 기준

학습이 짧고 차원이 적다 → Random으로 충분. 학습이 길다 → ASHA / Hyperband로 자원부터 아껴라. 1회 학습이 정말 비싼 NN에서 분산 자원이 있다 → PBT. 표면이 매끄럽고 호출이 비싸다 → Bayesian. 잘 모르겠으면 Optuna(TPE) + ASHA pruner가 안정적인 기본값이다.

04 / NAS
신경망 구조 탐색 · Neural Architecture Search

NAS는 세 부품의 조합 게임이다.

NAS는 만들어진 알고리즘이라기보다 “Search Space × Search Strategy × Performance Estimation”의 조합 카탈로그입니다. 이 셋의 선택이 NASNet · DARTS · EfficientNet · ENAS · Once-for-All 같은 이름들을 만듭니다.

SEARCH SPACE 𝒜 어떤 네트워크가 가능한가? Macro space Conv Pool Conv FC Cell space (NASNet, DARTS) in out Hierarchical / Mobile EfficientNet · MobileNetV3 : depth · width · resolution 동시에 SEARCH STRATEGY 어떻게 다음 후보를 고르는가? RL controller NASNet · ENAS — 컨트롤러가 후보 생성, validation reward로 업데이트 Evolutionary AmoebaNet — population에서 mutation/crossover Gradient-based (DARTS) edge별 ops를 softmax 가중합 → α를 SGD로 학습 Bayesian / Random discrete BO·랜덤 샘플 — 작은 검색공간에서 의외로 강함 One-shot supernet Once-for-All · BigNAS — 한 번 학습해 여러 sub-net 평가 PERF. ESTIMATION 후보를 얼마나 “싸게” 평가하는가? Full training 정확하지만 가장 비쌈 — 초기 NAS의 GPU-month들 Lower fidelity epoch ↓ · resolution ↓ · subset 학습 (Hyperband와 사촌) Weight sharing supernet의 가중치를 공유 — 평가 비용 100~1000× 감소 Performance predictor graph 기반 회귀로 점수 예측 — 학습 자체를 생략 Zero-cost proxies 초기화 시점 gradient·jacobian 기반 점수 — 거의 즉시 정의 평가
FIG. 04 · NAS 시스템은 세 박스의 조합 — 같은 검색공간이라도 전략·평가에 따라 비용이 1000× 차이난다.
DARTS · 2018

Gradient-based NAS — 왜 빨랐나

각 edge에 후보 ops {3×3conv, 5×5conv, max-pool, identity, …}를 두고 softmax(α)로 가중합. validation loss를 α에 대해 미분해 SGD로 갱신. 이산 탐색을 연속 공간으로 푸는 트릭이 GPU-day 수준으로 NAS 비용을 끌어내렸다.

단점: skip-connection으로 collapse, 메모리 폭증, 재현 어려움 — PC-DARTS·DARTS+가 보완.

ONCE-FOR-ALL · 2020

Supernet 한 번, sub-net N개

거대한 supernet을 한 번 학습해 두면 그 안의 어떤 sub-net이든 추가 학습 없이 평가·배포 가능. 디바이스 별로 latency 제약을 만족하는 sub-net을 골라낼 수 있어 엣지 배포와 잘 맞는다.

05 / META
메타학습과 워밍업 · Warm-start

좋은 AutoML은 처음부터 시작하지 않는다.

AutoML 시스템이 빨라지는 결정적 이유는 “어디부터 시작할지를 안다”는 점입니다. 메타학습은 이전 데이터셋·과거 실험 결과를 사용해 검색의 시작점, 모델 우선순위, 하이퍼의 사전분포를 결정합니다.

META-STORE 과거 데이터셋·실험·결과 dataset_meta_features.json past_trial_results.parquet model_priors.yaml portfolio.csv (top-K) AUTOML INNER LOOP Suggest config surrogate / sampler Train (lo-fidelity) epoch ↓ / subset Evaluate metric · cost Prune / Update ASHA · TPE 관측을 surrogate에 누적 Final ensemble + retrain on full data warm-start priors 새 trial 결과를 다시 meta-store로 환원
FIG. 05 · 메타학습은 검색의 시작점을 결정한다. AutoML 시스템은 바깥 루프(메타)와 안쪽 루프(검색)가 함께 도는 구조다.
06 / INTEGRATION
기존 MLOps와의 결합 · Stack Mapping

당신의 스택 어디에 꽂는가.

AutoML은 별도 시스템이 아니라 기존 파이프라인의 “학습 단계”를 “검색 단계”로 치환하는 작업입니다. 각 도구가 어디 자리에 들어가는지를 가장 흔한 K8s + Kubeflow + MLflow 조합으로 그렸습니다.

DATA Object Store (MinIO/S3) · Feature Store · Versioned datasets (DVC, lakeFS) ORCHESTRATION Kubeflow Pipelines / Argo Workflows / Airflow — 단계 정의·재실행·스케줄 Ingest Preprocess AutoML / HPO ← 학습 단계 치환 Validate Deploy Monitor SEARCH ENGINE Kubeflow Katib / Ray Tune / Optuna — 분산 trial 스케줄링·early stopping Trial scheduler Suggester (TPE/CMA) Early-stop (ASHA) Worker pool (GPU/CPU) Resource quotas / spot · preemptible 처리 TRACKING / REGISTRY MLflow · W&B · Comet — 모든 trial을 같은 실험 ID 아래 누적 → best run을 자동으로 Model Registry stage 승격 (Production / Staging) SERVE & OBSERVE KServe / Seldon · Prometheus · Evidently / WhyLabs → drift 감지 → Pipeline 재실행 → AutoML 재검색 (continuous loop) Continuous AutoML — 재학습이 아니라 재검색
FIG. 06 · AutoML은 노란 박스 자리에 들어간다. 위(데이터)·아래(서빙) 계층은 그대로다 — 그래서 도입이 점진적으로 가능하다.

Kubeflow를 쓰고 있다면

학습 컴포넌트를 그대로 두고 그 자리에 Katib Experiment를 끼우면 됩니다. trial template은 기존 TFJob/PyTorchJob을 그대로 쓰고, suggestion algorithm만 골라주면 됩니다(random/TPE/CMA-ES/HyperBand). 결과 메트릭은 metrics-collector가 stdout/file/Prometheus에서 긁어옵니다.

MLflow를 쓰고 있다면

Optuna/Ray Tune의 callback으로 모든 trial을 같은 실험에 기록하고, best run을 Model Registry로 승격하는 단계만 추가하면 자동화가 닫힙니다. 이때 모델 시그니처와 입력 예제는 반드시 같이 저장 — AutoML이 모델 클래스를 바꿀 때 호환성 사고가 가장 많이 납니다.

비용 함수의 변화

AutoML은 “GPU-hour ↔ 모델 품질”의 환율을 명시적으로 만든다. budget-aware로 설계해야 함 — 무한 검색은 무한 비용이다. Kubeflow Katib의 maxTrialCount·maxFailedTrialCount·parallelTrialCount가 그 역할을 한다.

07 / TOOLING
프레임워크 비교 · Landscape

현실에서 쓰는 도구들의 분포.

AutoML 생태계는 1) HPO 라이브러리, 2) End-to-end 정형 AutoML, 3) Deep AutoML/NAS, 4) 클라우드 매니지드의 4그룹으로 분리됩니다. 같은 그룹 안에서는 호환 가능, 그룹을 가로지를 땐 “학습 단계 치환” 관점에서 따져야 합니다.

Framework Group HPO NAS Tabular E2E Distributed 한 줄 메모
Optuna오픈소스 / Python HPO library 강력 없음 아님 RDB 백엔드 TPE 기본 + ASHA pruner. 가장 무난한 기본값.
Ray Tune오픈소스 / Ray HPO library 강력 간접 아님 native PBT·BOHB 풍부, K8s 분산이 가장 매끄럽다.
Kubeflow KatibK8s native HPO + NAS engine CRD 기반 ENAS/DARTS 아님 K8s Kubeflow 스택의 표준 HPO. Trial = 자체 Job.
Auto-sklearn오픈소스 Tabular E2E SMAC 없음 강력 단일 노드 OpenML 메타학습 portfolio — 시작이 빠르다.
AutoGluonAWS · 오픈소스 Tabular + Multimodal 제한 제한 강력 분산 학습 거의 “튜닝 없이” 강력한 ensemble. 사실상 베이스라인 절대강자.
H2O AutoMLH2O.ai Tabular E2E 랜덤 없음 강력 cluster JVM 클러스터 기반, 엔터프라이즈 정형 데이터 강함.
FLAMLMicrosoft HPO + Tabular cost-frugal 없음 강력 Ray 옵션 예산 적을 때 가성비 1위. 모델별 cost를 고려해 검색.
AutoKerasKeras 기반 Deep AutoML 있음 간단 제한 제한 이미지·텍스트 전용 task API가 깔끔.
NNIMicrosoft HPO + NAS 강력 DARTS+ 아님 K8s 등 NAS 알고리즘 카탈로그가 가장 풍부.
Vertex AI AutoMLGoogle Cloud Cloud E2E 매니지드 매니지드 매니지드 매니지드 데이터셋 업로드만으로 동작. 비용 통제 어려움.
SageMaker AutopilotAWS Cloud E2E 매니지드 제한 매니지드 매니지드 노트북을 자동 생성해줘 “재현 가능한 AutoML”에 가깝다.
Azure AutoMLMicrosoft Cloud E2E 매니지드 제한 매니지드 매니지드 Time-series·NLP 모듈이 잘 갖춰져 있음.
합리적인 기본 조합 (자체 호스팅 K8s)

Kubeflow Pipelines (orchestration) → Katib 또는 Ray Tune (search) → MLflow (tracking · registry) → KServe (serving) → Prometheus + Evidently (monitoring). 정형 데이터 베이스라인은 무조건 AutoGluon으로 한 번 돌리고 시작하라 — 절약되는 시간이 막대하다.

08 / DECISION
언제 도입하고 언제 미루나 · Decision

AutoML은 모든 문제의 답이 아니다.

도입이 합리적

  • 정형 데이터 분류/회귀 — 베이스라인을 빨리 만들어야 할 때
  • 비슷한 문제가 자주 반복되는 사내 모델 카탈로그(수십~수백 개 모델)
  • 도메인 전문가는 있지만 ML 엔지니어가 부족한 조직
  • 리튜닝 주기가 짧은 라이브 시스템 — 사람 인-the-loop가 병목
  • 엣지 디바이스 별 latency 제약을 만족해야 할 때 (NAS · Once-for-All)
  • HPO 단독 — 기존 모델 코드는 그대로 두고 search만 분산할 때

도입이 위험

  • 데이터셋이 작거나 라벨 노이즈가 큰 경우 — AutoML이 leaderboard에 과적합
  • 비표준 손실/제약/공정성 요구사항이 강한 경우
  • 인과추론·시계열 외삽 — 검증 분포가 학습 분포와 다른 영역
  • 모델 해석가능성이 1순위 요구사항인 도메인(의료·금융 일부)
  • SOTA 연구급 성능이 목표 — AutoML은 “좋은 평균”에 강하지 “정점”에 약함
  • 비용 통제가 안 된 클라우드 매니지드 사용 — 한 번에 수천 달러도 가능
PITFALL · 01

Validation 누수

AutoML은 같은 검증셋을 수백 번 본다. 이때의 “best score”는 진짜 일반화 성능이 아니다. 3-way split (train/val/test)에서 test는 검색이 끝난 다음에만 한 번 보고, nested CV를 권장.

PITFALL · 02

Leaderboard 디바이스 미스매치

NAS가 찾은 “정확도 최고”가 엣지에서 안 돌아간다. 검색 단계에서 latency · 메모리 · 에너지를 multi-objective로 같이 넣어야 한다(NSGA-II 등).

PITFALL · 03

모델 클래스 변경 사고

어제까지 LightGBM이던 모델이 오늘 NN으로 바뀌면 서빙 컨테이너·전처리·시그니처가 모두 깨진다. model contract(입력 스키마, 출력 형태, 의존성)를 검색공간 외부에 고정하라.

PITFALL · 04

“블랙박스” 책임 공백

매니지드 AutoML이 잘 돌면 누구도 모델 내부를 모른다. 사고 시 디버깅 불가. 최소한 최종 모델의 재학습 가능한 코드를 산출물로 받는 도구를 선호하라(SageMaker Autopilot의 노트북 산출물이 좋은 예).

요약 한 줄

AutoML을 “모델을 대신 만들어주는 도구”가 아니라, “검색을 1급 시민으로 만드는 MLOps 패턴”으로 받아들일 때 도입이 안정적이다. 도입 비용은 라이브러리 학습이 아니라 검색공간 정의·예산 정책·컨트랙트 고정이라는 운영 비용이다.