대부분의 ML 프로젝트는 모델 자체가 잘못되어서 실패하는 것이 아닙니다. 모델에 데이터를 공급하는 데이터 파이프라인이 프로덕션 환경과 접촉했을 때 살아남지 못해서 실패합니다. 깨끗한 CSV로 모델을 훈련시키는 노트북은 실제 사용자나 실제 시스템이 개입했을 때 그 모델이 신선하고, 정확하며, 시기적절한 데이터를 얻을 수 있는지에 대해서는 아무것도 증명하지 못합니다.

데이터 엔지니어링과 ML 엔지니어링은 빠르게 통합되고 있습니다. 파이프라인 설계를 최우선 과제(first-class discipline)로 다루는 팀은 이를 단순 배관 작업으로 취급하는 팀보다 더 빠르게 제품을 출시하고 고장도 덜 납니다.

배치(Batch) 대 스트리밍(Streaming): 적절한 처리 모델 선택

첫 번째 아키텍처 결정은 파이프라인이 데이터를 배치로 처리할지 아니면 연속적인 스트림으로 처리할지 여부이며, 이 선택은 다운스트림의 모든 것을 형성합니다.

배치 파이프라인은 일정에 따라 누적된 데이터를 처리합니다: 시간별, 일별 또는 스토리지에 파일이 도착하는 것과 같은 이벤트로 트리거됩니다. 이는 훈련 파이프라인, 주기적인 피처 재계산(feature recomputation), 그리고 몇 시간 정도의 데이터 지연(staleness)이 허용되는 워크로드에 적합합니다. 배치 시스템은 이해하기 쉽고, 디버깅하기 쉬우며, 컴퓨팅 자원이 항상 켜져 있지 않기 때문에 실행 비용도 저렴합니다.

스트리밍 파이프라인은 이벤트가 도착함에 따라 처리하며, 일반적으로 Apache Kafka, AWS Kinesis 또는 Google Pub/Sub과 같은 메시지 브로커를 통해 이루어집니다. 이는 예측의 신선도가 중요한 사용 사례(use cases)에 적합합니다: 사기 탐지(fraud detection), 사용자의 최근 세 번 클릭에 반응하는 추천 시스템, 또는 동적 가격 책정(dynamic pricing). 스트리밍은 실질적인 복잡성을 도입합니다: 순서가 맞지 않는 이벤트(out-of-order events), 늦게 도착하는 데이터(late-arriving data), 윈도우 로직(windowing logic) 및 일정에 따라 실행되는 것이 아니라 지속적으로 실행되는 인프라입니다.

대부분의 프로덕션 ML 시스템은 단일 모델만을 사용하지 않습니다. 일반적인 패턴은 람다 아키텍처(lambda architecture)인데, 이 구조에서는 배치 레이어(batch layer)가 정확한 히스토리 피처를 계산하고 스트리밍 레이어(streaming layer)가 근사 실시간 피처를 계산하며, 두 가지 모두 공유된 피처 스토어(feature store)를 통해 동일한 모델에 데이터를 공급합니다. 배치로 할 수 있는 것을 스트리밍으로 선택하는 것은 이점 없이 운영 비용만 추가합니다. 반대로, 실시간 추론이 필요한데 배치를 사용하면 이미 사용자들이 더 이상 묻지 않는 질문에 답하는 모델을 만들게 됩니다.

피처 스토어(Feature Stores): 트레이닝-서빙 격차 해소하기

프로덕션 ML에서 가장 흔한 버그는 트레이닝-서빙 편향(training-serving skew)입니다. 이는 학습 시에는 한 방식으로 계산된 피처가 추론 시에는 미묘하게 다른 방식으로 계산되는 경우를 말합니다. 7일 이동 평균으로 학습된 모델을 5일 평균을 계산하는 피처 파이프라인으로 서비스하면, 모델 성능이 조용히 저하되며 그 실패는 종종 파이프라인 버그라기보다는 모델 드리프트(model drift)처럼 보입니다.

피처 스토어는 이 격차를 해소하기 위해 존재합니다. Feast, Tecton 같은 도구와 Databricks 및 SageMaker 내부의 피처 스토어 구성 요소들은 팀이 피처를 한 번 정의하고 이를 트레이닝 작업과 온라인 추론 엔드포인트 모두에 일관되게 제공할 수 있도록 합니다. 이 스토어는 일반적으로 대규모 배치 학습 데이터를 위한 오프라인 스토어(offline store)와, 추론 시 실시간 조회를 위한 Redis나 DynamoDB 같은 낮은 지연 시간의 키-값 데이터베이스를 사용하는 온라인 스토어(online store)로 나뉩니다.

피처 스토어는 또한 팀 간 피처 재사용 문제를 해결합니다. 이것이 없다면, 모든 모델 팀이 동일한 고객 생애 가치(customer lifetime value)나 세션 길이 피처를 약간 다른 로직으로 재계산하게 되며, 두 모델이 왜 의견이 다른지 아무도 설명할 수 없습니다. 공유되고 버전 관리되는 피처 정의는 이러한 모호성을 제거합니다.

데이터 버전 관리(Data Versioning), 계보(Lineage), 그리고 재현성(Reproducibility)

6개월 전에 원래 형태가 존재하지 않는 데이터로 학습된 모델은 재현(reproducible)이 불가능하며, 이는 단순한 불편함을 넘어 컴플라이언스(compliance) 및 디버깅(debugging) 문제입니다. 이해관계자가 모델이 왜 특정 예측을 했는지 물을 때, 그 답변을 위해서는 당시 사용된 정확한 학습 데이터셋, 정확한 피처 변환(feature transformations), 그리고 정확한 코드 버전을 재구성해야 하는 경우가 많습니다.

DVC, LakeFS, 그리고 Delta Lake의 타임 트래블(time travel) 기능과 같은 데이터 버전 관리(Data versioning) 도구들은 Git이 코드를 스냅샷(snapshot)하는 방식처럼 데이터셋을 스냅샷할 수 있게 해줍니다. 여기에 각 데이터셋이 어떤 변환을 거쳐 상위 소스(upstream sources)로부터 유도되었는지를 기록하는 계보(lineage) 추적을 결합하면, 고고학적 조사 없이도 "이 수치가 어디에서 왔는가"라는 질문에 답할 수 있는 감사 추적(audit trail)을 확보할 수 있습니다.

계보(Lineage)는 파이프라인이 깨졌을 때 더욱 중요해집니다. 하류(downstream) 지표가 잘못된 것처럼 보일 때, OpenLineage나 Marquez와 같은 도구를 사용하면 엔지니어가 흩어진 스크립트를 검색(grep)하며 추측하는 대신, 이상 징후를 소스 테이블(source table)까지 역추적할 수 있습니다.

대규모 환경에서의 스키마 드리프트(Schema Drift)와 데이터 품질

상위(upstream) 시스템은 예고 없이 변경됩니다. 제품 팀이 컬럼(column)의 이름을 바꾸거나, 이벤트 스키마(event schema)에 새로운 필수 필드가 추가되거나, 제3자 API가 데이터 타입을 정수(integer)에서 문자열(string)로 조용히 변경할 수 있습니다. 규모가 작은 파이프라인에서는 누군가 즉시 이를 알아차립니다. 하지만 수십 개의 소스에 걸쳐 하루에 수백만 개의 행을 처리하는 파이프라인에서는, 누군가 알아차리기 전에 해당 변경 사항이 전파되며, 문제의 첫 번째 신호는 모델이 터무니없는 예측을 내놓는 것으로 나타납니다.

스키마 드리프트(Schema drift) 탐지는 수동이 아닌 자동화되어야 합니다. Great Expectations, Deequ, Soda Core와 같은 도구들을 사용하면 팀은 기대 사항(expectations)(예: 이 컬럼은 절대 null이 아니어야 함, 이 값은 특정 범위 내에 있어야 함, 이 범주형 필드는 특정 값들만 포함해야 함)을 정의하고 이를 모든 파이프라인 실행의 일부로 실행할 수 있습니다. 기대 사항이 충족되지 않으면, 잘못된 데이터가 학습 작업(training job)이나 서빙 레이어(serving layer)에 도달하기 전, 즉 모델이 이미 오염된 입력값으로 재학습되기 전에 파이프라인을 중단시켜야 합니다.

Great Expectations의 2024 데이터 품질 현황 (State of Data Quality) 보고서에 따르면, 조사된 데이터 팀들 사이에서 데이터 품질 문제는 모델 성능 문제보다 앞서 ML 배포를 지연시키는 주요 원인으로 계속 언급되고 있습니다. 데이터 품질은 마지막에 덧붙이는 체크 항목이 아닙니다. 그것은 그 위에 구축된 모든 것을 신뢰할 수 있는지 결정하는 레이어 (layer)입니다.

오케스트레이션 (Orchestration): 파이프라인이 실제로 실행되는 곳

파이프라인을 스케줄링(scheduling), 재시도(retrying), 모니터링(monitoring)하는 신뢰할 수 있는 시스템이 없다면 위의 사항들은 아무런 의미가 없습니다. 오케스트레이션 도구는 작업(task) 간의 의존성을 조정하고, 실패를 처리하며, 엔지니어에게 무엇이 실행되었고, 무엇이 실패했으며, 그 이유가 무엇인지에 대한 가시성을 제공합니다.

Apache Airflow는 Python으로 정의된 DAG와 데이터베이스, 클라우드 스토리지, ML 플랫폼을 위한 방대한 오퍼레이터 (operator) 생태계를 갖춘 가장 널리 채택된 오케스트레이터 (orchestrator)로 남아 있습니다. Dagster는 보다 자산 중심적인 (asset-centric) 접근 방식을 취하며, 데이터셋과 피처 (feature)를 단계 간의 타입이 지정된 계약 (typed contracts)을 가진 일급 객체 (first-class objects)로 취급합니다. 이는 Airflow의 작업 중심 (task-centric) 모델보다 통합 오류를 더 일찍 잡아냅니다. Kubeflow Pipelines는 이미 Kubernetes에서 운영 중이면서 데이터 준비와 모델 학습을 동일한 DAG 내에서 아우르는 오케스트레이션을 원하는 팀을 대상으로 하며, 네이티브 GPU 스케줄링 (GPU scheduling) 지원을 제공합니다.

올바른 선택은 기능 체크리스트보다는 팀의 상황에 더 좌우됩니다. 즉, 기존 인프라, 팀이 이미 보유한 기술 스택, 그리고 주요 요구 사항이 일반적인 데이터 이동인지 아니면 ML 특화 워크플로 추적인지에 따라 달라집니다.

노트북에서 프로덕션으로: 아무도 예산을 책정하지 않는 격차

노트북 (notebook)은 특정 시점의 고정된 데이터셋에서 아이디어가 작동함을 증명합니다. 프로덕션 (production)에서는 동일한 로직이 형태가 변하고, 늦게 도착하며, 때때로 누락되고, 원본 노트북을 작성하지 않은 여러 사람에 의해 처리되는 데이터에서도 올바르게 실행되어야 합니다.

그 격차를 메운다는 것은 노트북 셀(notebook cells)을 테스트 가능하고, 매개변수화(parameterized)되었으며, 버전 관리(version-controlled)가 되는 함수로 전환하고, 파이프라인의 상태(health)와 데이터 품질(data quality)을 위한 모니터링 및 알림(alerting)을 추가하며, 새벽 2시에 무언가 실패할 수밖에 없는 상황을 대비해 재시도(retry) 및 백필(backfill) 로직을 구축하는 것을 의미합니다. 또한, 이는 빠른 탐색적 아이디어 검증(exploratory idea validation)과, 다른 모든 핵심 서비스와 동일한 엔지니어링 규율(engineering discipline)을 따르는 프로덕션 강화(production-hardening) 작업을 분리하는 것을 의미하기도 합니다. 이러한 전환 과정을 건너뛰는 팀은 결국 아무도 건드리고 싶어 하지 않는 취약한 파이프라인을 갖게 되며, 새로운 기능 요청이 있을 때마다 학습(training)이나 서빙(serving)이 깨질 위험을 안게 됩니다.

이러한 규율을 조기에 구축하는 비용은 잘못된 모델 배포 이후에 파이프라인을 재구축하는 비용보다 적게 듭니다. 구조화된 데이터 엔지니어링 교육 (data engineering training)은 파이프라인이 병목 현상(bottleneck)이 되기 전에 팀이 이러한 기술을 구축할 수 있도록 돕습니다.