MLOps 개요와 ML 라이프사이클 완벽 가이드

머신러닝 모델을 실제 서비스에 배포하고 운영하는 MLOps의 핵심 개념을 알아봅니다. DevOps와의 차이점부터 ML 라이프사이클, 성숙도 레벨까지 초급 개발자도 쉽게 이해할 수 있도록 설명합니다.

---

목차

1. MLOps란_무엇인가
2. DevOps_vs_MLOps
3. ML_라이프사이클_단계
4. 기술_부채와_도전_과제
5. MLOps_성숙도_레벨
6. 주요_도구_생태계

---

1. MLOps란 무엇인가

김개발 씨는 데이터 사이언스 팀에서 만든 머신러닝 모델을 실제 서비스에 적용하는 업무를 맡게 되었습니다. 주피터 노트북에서는 잘 작동하던 모델이 왜 운영 환경에서는 문제를 일으키는 걸까요?

선배 박시니어 씨가 다가와 말합니다. "MLOps를 모르면 ML 프로젝트의 90%는 실패한다네."

MLOps는 Machine Learning과 Operations의 합성어로, 머신러닝 모델의 개발부터 배포, 운영까지의 전체 과정을 체계적으로 관리하는 방법론입니다. 마치 자동차 공장에서 설계부터 생산, 품질 관리, 출하까지 일련의 프로세스가 있듯이, MLOps는 ML 모델의 생애 전체를 관리합니다.

이를 통해 모델 배포 시간을 단축하고, 안정적인 서비스 운영이 가능해집니다.

다음 코드를 살펴봅시다.

# MLOps 기본 파이프라인 구조 예시
class MLOpsPipeline:
    def __init__(self, model_name: str):
        self.model_name = model_name
        self.version = "1.0.0"

    # 데이터 수집 및 검증 단계
    def data_ingestion(self, source: str):
        return self.validate_data(source)

    # 모델 학습 단계
    def train_model(self, data):
        model = self.build_model()
        return model.fit(data)

    # 모델 배포 단계
    def deploy_model(self, model, environment: str):
        self.register_model(model)
        return self.serve_model(environment)

김개발 씨는 입사 6개월 차 ML 엔지니어입니다. 오늘 드디어 데이터 사이언스 팀이 3개월간 개발한 추천 모델을 서비스에 적용하는 날입니다.

하지만 노트북에서 완벽하게 돌아가던 모델이 서버에 올리자마자 에러를 뿜어댑니다. "패키지 버전이 안 맞아요." "학습 데이터는 어디서 가져오죠?" "모델 성능이 갑자기 떨어졌는데 어떻게 롤백하죠?" 질문이 꼬리에 꼬리를 물었습니다.

박시니어 씨가 커피 한 잔을 건네며 말합니다. "이게 바로 많은 ML 프로젝트가 실패하는 이유야.

모델 개발만 하고, 운영은 생각하지 않았거든." 그렇다면 MLOps란 정확히 무엇일까요? 쉽게 비유하자면, MLOps는 마치 레스토랑의 주방 시스템과 같습니다.

아무리 뛰어난 셰프라도 재료 관리, 조리 과정, 서빙, 고객 피드백이라는 시스템 없이는 좋은 요리를 지속적으로 제공할 수 없습니다. MLOps도 마찬가지입니다.

데이터 수집부터 모델 학습, 배포, 모니터링까지 전체 과정을 하나의 시스템으로 연결합니다. MLOps가 없던 시절에는 어땠을까요?

데이터 사이언티스트가 노트북에서 모델을 만들면, 엔지니어가 처음부터 코드를 다시 작성해야 했습니다. 모델 버전 관리는 파일명에 날짜를 붙이는 수준이었습니다.

model_final.pkl, model_final_v2.pkl, model_really_final.pkl 같은 파일들이 난무했습니다. 모델 성능이 떨어져도 언제, 왜 떨어졌는지 추적할 방법이 없었습니다.

바로 이런 문제를 해결하기 위해 MLOps가 등장했습니다. MLOps를 도입하면 재현성이 보장됩니다.

언제든 같은 조건으로 모델을 다시 학습시킬 수 있습니다. 자동화를 통해 반복 작업을 줄이고 배포 속도를 높일 수 있습니다.

무엇보다 모니터링으로 모델 성능을 실시간으로 추적하고 문제 발생 시 빠르게 대응할 수 있습니다. 위의 코드를 살펴보겠습니다.

MLOpsPipeline 클래스는 MLOps의 핵심 단계를 보여줍니다. data_ingestion에서 데이터를 수집하고 검증합니다.

train_model에서 모델을 학습시킵니다. deploy_model에서 학습된 모델을 운영 환경에 배포합니다.

각 단계가 명확히 분리되어 있어 문제 발생 시 어디서 발생했는지 쉽게 파악할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

넷플릭스는 MLOps를 통해 수천 개의 추천 모델을 동시에 운영합니다. 새로운 모델을 배포하고, 성능을 비교하고, 최적의 모델을 자동으로 선택합니다.

이 모든 과정이 자동화되어 있기에 가능한 일입니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 처음부터 완벽한 MLOps 파이프라인을 구축하려는 것입니다. 이렇게 하면 프로젝트가 시작도 전에 지쳐버립니다.

따라서 작은 것부터 시작하여 점진적으로 확장해 나가는 것이 현명합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 우리에게 MLOps가 필요했군요!"

실전 팁

💡 - MLOps는 한 번에 완성되지 않습니다. 버전 관리부터 시작해서 점진적으로 확장하세요

• 데이터 사이언티스트와 ML 엔지니어 간의 협업 문화가 MLOps 성공의 핵심입니다

---

2. DevOps vs MLOps

김개발 씨는 이전에 웹 개발팀에서 DevOps를 경험한 적이 있습니다. "DevOps랑 비슷한 거 아닌가요?" 김개발 씨가 물었습니다.

박시니어 씨가 미소를 지으며 답합니다. "비슷하면서도 완전히 다르지.

ML에는 데이터라는 변수가 있거든."

DevOps가 코드의 지속적 통합과 배포에 집중한다면, MLOps는 여기에 데이터와 모델이라는 두 가지 차원을 추가합니다. 웹 애플리케이션은 코드만 바뀌면 동작이 바뀌지만, ML 모델은 같은 코드라도 데이터가 달라지면 완전히 다른 결과를 냅니다.

이것이 MLOps가 더 복잡한 이유입니다.

다음 코드를 살펴봅시다.

# DevOps vs MLOps 파이프라인 비교

# DevOps: 코드 중심 파이프라인
class DevOpsPipeline:
    stages = ["Code", "Build", "Test", "Deploy"]

    def deploy(self, code_version: str):
        # 코드 버전만 관리하면 됨
        return f"Deployed code v{code_version}"

# MLOps: 코드 + 데이터 + 모델 관리
class MLOpsPipelineExtended:
    stages = ["Data", "Code", "Model", "Train", "Validate", "Deploy", "Monitor"]

    def deploy(self, code_version: str, data_version: str, model_version: str):
        # 세 가지 버전을 모두 추적해야 함
        return f"Deployed model v{model_version} (code: {code_version}, data: {data_version})"

김개발 씨는 예전 웹 개발팀에서 일할 때 DevOps를 꽤 잘 활용했습니다. 코드를 푸시하면 자동으로 테스트가 돌아가고, 통과하면 서버에 배포되었습니다.

단순하고 명쾌했습니다. "그때처럼 하면 되지 않나요?" 김개발 씨가 물었습니다.

박시니어 씨가 화이트보드에 그림을 그리기 시작했습니다. "DevOps에서는 코드가 같으면 결과도 같아.

2 더하기 2는 항상 4지. 하지만 ML에서는 다르네." ML 모델은 비결정적입니다.

같은 코드라도 학습 데이터가 다르면 전혀 다른 모델이 만들어집니다. 심지어 같은 데이터로 학습해도 랜덤 시드에 따라 미세하게 다른 결과가 나올 수 있습니다.

비유하자면, DevOps가 레시피대로 요리하는 것이라면, MLOps는 재료 농장부터 관리하는 것입니다. 같은 레시피라도 토마토가 어디서 왔는지, 얼마나 익었는지에 따라 맛이 달라지는 것처럼, ML 모델도 데이터의 품질과 분포에 따라 성능이 천차만별입니다.

DevOps와 MLOps의 또 다른 차이는 테스트 방식입니다. 일반 소프트웨어는 단위 테스트와 통합 테스트로 품질을 검증합니다.

입력이 주어지면 예상되는 출력이 나오는지 확인하면 됩니다. 하지만 ML 모델은 어떻게 테스트할까요?

고양이 사진을 넣었을 때 고양이라고 대답하는지 확인하는 것만으로는 부족합니다. ML 모델 테스트에는 정확도, 정밀도, 재현율 같은 통계적 지표가 필요합니다.

그리고 이 지표들은 시간이 지나면 변할 수 있습니다. 이것을 모델 드리프트라고 합니다.

위의 코드에서 두 파이프라인의 차이를 볼 수 있습니다. DevOpsPipeline은 코드 버전만 관리합니다.

4단계로 단순합니다. 반면 MLOpsPipelineExtended는 7단계가 필요하고, deploy 함수에서 code_version, data_version, model_version을 모두 추적합니다.

모니터링도 크게 다릅니다. 웹 서비스는 응답 시간, 에러율 정도만 모니터링하면 됩니다.

하지만 ML 서비스는 예측 정확도, 입력 데이터 분포, 모델 편향성까지 추적해야 합니다. 서비스가 정상적으로 응답해도 모델이 엉뚱한 예측을 하고 있을 수 있기 때문입니다.

김개발 씨가 질문했습니다. "그러면 DevOps를 아는 것이 MLOps에 도움이 되나요?" 박시니어 씨가 고개를 끄덕였습니다.

"물론이지. MLOps는 DevOps를 기반으로 확장된 거야.

CI/CD, 인프라 자동화, 컨테이너화 같은 DevOps의 핵심 개념은 MLOps에서도 그대로 사용해. 거기에 데이터와 모델 관리가 추가된 것뿐이야."

실전 팁

💡 - DevOps 경험이 있다면 MLOps 학습이 훨씬 수월합니다. 기존 지식을 활용하세요

• ML 프로젝트에서는 코드뿐 아니라 데이터 버전 관리를 반드시 도입하세요

---

3. ML 라이프사이클 단계

"그럼 ML 프로젝트는 구체적으로 어떤 단계를 거치나요?" 김개발 씨가 노트를 펼치며 물었습니다. 박시니어 씨가 화이트보드에 원형 그림을 그리기 시작합니다.

"ML 라이프사이클은 직선이 아니라 순환이야. 끝이 없는 개선의 연속이지."

ML 라이프사이클은 문제 정의부터 시작해서 데이터 수집, 모델 개발, 배포, 모니터링까지의 전체 과정을 의미합니다. 마치 계절이 순환하듯이, ML 모델도 배포 후 모니터링을 통해 발견된 문제를 바탕으로 다시 데이터를 수집하고 모델을 개선하는 순환 구조를 가집니다.

각 단계를 이해하면 전체 프로젝트를 효과적으로 관리할 수 있습니다.

다음 코드를 살펴봅시다.

# ML 라이프사이클 각 단계 구현 예시
class MLLifecycle:
    # 1단계: 문제 정의 및 데이터 수집
    def collect_data(self, sources: list) -> dict:
        raw_data = self.extract_from_sources(sources)
        return self.validate_schema(raw_data)

    # 2단계: 데이터 전처리 및 피처 엔지니어링
    def prepare_features(self, data: dict) -> np.ndarray:
        cleaned = self.clean_missing_values(data)
        return self.engineer_features(cleaned)

    # 3단계: 모델 학습 및 검증
    def train_and_validate(self, features: np.ndarray, labels: np.ndarray):
        model = self.select_algorithm()
        model.fit(features, labels)
        return self.cross_validate(model)

    # 4단계: 배포 및 서빙
    def deploy_to_production(self, model, endpoint: str):
        serialized = self.serialize_model(model)
        return self.create_inference_endpoint(serialized, endpoint)

    # 5단계: 모니터링 및 재학습
    def monitor_and_retrain(self, model_id: str):
        metrics = self.collect_performance_metrics(model_id)
        if metrics["accuracy"] < self.threshold:
            return self.trigger_retraining()

박시니어 씨가 화이트보드에 다섯 개의 원을 그리고 화살표로 연결했습니다. "ML 라이프사이클은 크게 다섯 단계로 나눌 수 있어." 첫 번째 단계는 문제 정의와 데이터 수집입니다. 모든 ML 프로젝트는 비즈니스 문제를 명확히 정의하는 것에서 시작합니다.

"고객 이탈을 예측하고 싶다"는 좋은 문제 정의입니다. 하지만 "AI로 뭔가 해보고 싶다"는 문제 정의가 아닙니다.

문제가 정의되면 그에 맞는 데이터를 수집합니다. 데이터베이스, 로그 파일, 외부 API 등 다양한 소스에서 데이터를 모읍니다.

두 번째 단계는 데이터 전처리와 피처 엔지니어링입니다. 수집된 원시 데이터는 바로 사용할 수 없습니다. 결측치를 처리하고, 이상치를 제거하고, 형식을 통일해야 합니다.

그리고 원시 데이터에서 의미 있는 피처를 추출합니다. 예를 들어 날짜 데이터에서 요일, 월, 공휴일 여부 등을 새로운 피처로 만들 수 있습니다.

이 단계가 전체 프로젝트의 80%를 차지한다는 말이 있을 정도로 중요합니다. 세 번째 단계는 모델 학습과 검증입니다. 이제 드디어 모델을 학습시킵니다.

여러 알고리즘을 실험하고, 하이퍼파라미터를 튜닝하고, 교차 검증으로 성능을 평가합니다. 이 단계에서 MLflow 같은 실험 추적 도구를 사용하면 어떤 설정이 가장 좋은 결과를 냈는지 기록할 수 있습니다.

네 번째 단계는 배포와 서빙입니다. 검증된 모델을 운영 환경에 배포합니다. REST API 형태로 서빙하거나, 배치 작업으로 예측 결과를 생성합니다.

이 단계에서 컨테이너화, 로드 밸런싱, 오토스케일링 등 인프라 지식이 필요합니다. 다섯 번째 단계는 모니터링과 재학습입니다. 배포 후가 진짜 시작입니다.

모델 성능을 지속적으로 모니터링하고, 성능이 저하되면 재학습을 트리거합니다. 이것이 ML 라이프사이클이 순환하는 이유입니다.

한 번 배포하고 끝나는 것이 아니라, 계속해서 개선해 나가야 합니다. 위의 코드에서 각 단계가 메서드로 구현되어 있습니다.

collect_data에서 데이터를 수집하고, prepare_features에서 전처리합니다. train_and_validate에서 모델을 학습시키고, deploy_to_production에서 배포합니다.

마지막으로 monitor_and_retrain에서 모니터링하고 필요시 재학습을 시작합니다. 김개발 씨가 물었습니다.

"각 단계 중에 가장 중요한 건 뭐예요?" 박시니어 씨가 웃으며 답했습니다. "다 중요하지만, 현업에서 가장 과소평가되는 건 모니터링이야.

많은 팀이 배포하고 나면 끝났다고 생각해. 하지만 데이터 분포는 계속 변하고, 어제의 좋은 모델이 오늘의 나쁜 모델이 될 수 있어."

실전 팁

💡 - 데이터 전처리에 충분한 시간을 투자하세요. 쓰레기가 들어가면 쓰레기가 나옵니다

• 배포 후 모니터링 체계를 반드시 구축하세요. 문제는 항상 배포 후에 발견됩니다

---

4. 기술 부채와 도전 과제

김개발 씨는 ML 프로젝트를 몇 개 진행하면서 이상한 점을 느꼈습니다. 처음에는 빠르게 진행되던 프로젝트가 시간이 갈수록 점점 느려집니다.

박시니어 씨가 말합니다. "그게 바로 ML 시스템의 기술 부채야.

보이지 않는 곳에서 쌓여가지."

기술 부채란 빠른 개발을 위해 임시로 선택한 해결책이 나중에 더 큰 비용을 초래하는 현상입니다. ML 시스템에서는 이 부채가 특히 빠르게 쌓입니다.

구글의 유명한 논문에 따르면, ML 시스템에서 실제 ML 코드는 전체의 5%에 불과하고, 나머지 95%는 데이터 파이프라인, 설정 관리, 모니터링 등 주변 인프라입니다. 이 주변 인프라가 기술 부채의 온상입니다.

다음 코드를 살펴봅시다.

# ML 시스템의 숨겨진 기술 부채 예시

# 문제 1: 글루 코드 (Glue Code)
class LegacyDataAdapter:
    """외부 라이브러리 연동을 위한 임시 코드가 쌓임"""
    def adapt_sklearn_to_internal(self, model):
        # 임시방편으로 작성한 코드가 영구적이 됨
        return self.hacky_conversion(model)

# 문제 2: 파이프라인 정글 (Pipeline Jungle)
def process_data_v1(data): pass  # 아직 사용 중인가?
def process_data_v2(data): pass  # 언제 추가됐지?
def process_data_final(data): pass  # 정말 마지막?
def process_data_final_v2(data): pass  # 또?

# 문제 3: 설정 부채 (Configuration Debt)
CONFIG = {
    "learning_rate": 0.001,  # 왜 이 값인지 모름
    "batch_size": 32,  # 누가 정했는지 모름
    "magic_number": 42,  # 바꾸면 뭔가 깨짐
}

2015년, 구글은 "Hidden Technical Debt in Machine Learning Systems"라는 논문을 발표했습니다. 이 논문은 ML 커뮤니티에 큰 충격을 주었습니다.

모두가 알고리즘과 모델 성능에만 집중하고 있을 때, 구글은 시스템 전체를 바라보았습니다. 논문의 핵심 메시지는 간단했습니다.

ML 시스템에서 실제 ML 코드는 아주 작은 부분에 불과합니다. 나머지는 데이터 수집, 피처 추출, 설정 관리, 모니터링, 서빙 인프라 등입니다.

그리고 기술 부채는 대부분 이 주변 시스템에서 발생합니다. 글루 코드는 가장 흔한 기술 부채입니다.

외부 라이브러리나 레거시 시스템과 연동하기 위해 임시로 작성한 코드가 점점 쌓입니다. 처음에는 몇 줄이었던 어댑터 코드가 어느새 수천 줄이 됩니다.

아무도 건드리고 싶어하지 않지만, 삭제할 수도 없습니다. 파이프라인 정글도 심각한 문제입니다.

새로운 요구사항이 생길 때마다 기존 파이프라인에 가지가 추가됩니다. 시간이 지나면 어떤 경로로 데이터가 흐르는지, 어떤 파이프라인이 아직 사용 중인지 아무도 모르게 됩니다.

위의 코드에서 process_data 함수들이 그 예입니다. 설정 부채는 눈에 잘 보이지 않습니다.

하이퍼파라미터, 피처 설정, 모델 버전 등 수많은 설정이 여기저기 흩어져 있습니다. 왜 그 값으로 설정되어 있는지 아무도 모릅니다.

바꾸면 뭔가 깨질 것 같아서 아무도 건드리지 않습니다. 데이터 의존성도 중요한 문제입니다.

일반 소프트웨어에서 코드 의존성은 명확히 보입니다. import문을 보면 됩니다.

하지만 데이터 의존성은 암묵적입니다. 피처 A가 피처 B에 의존하고, 피처 B는 외부 데이터 소스 C에 의존합니다.

이런 의존성 그래프는 코드에 명시되어 있지 않습니다. 피드백 루프는 더 미묘한 문제입니다.

추천 시스템을 생각해 보세요. 모델이 특정 아이템을 추천하면, 사용자들은 그 아이템을 더 많이 클릭합니다.

그러면 다음 학습 때 그 아이템의 점수가 더 올라갑니다. 모델이 자기 자신을 강화하는 것입니다.

이런 피드백 루프는 예측하기 어렵고, 편향을 심화시킬 수 있습니다. 김개발 씨가 한숨을 쉬었습니다.

"정말 복잡하네요. 어떻게 해결하죠?" 박시니어 씨가 답했습니다.

"완벽한 해결책은 없어. 하지만 몇 가지 원칙은 있지.

첫째, 모든 것을 버전 관리해. 코드뿐만 아니라 데이터, 설정, 모델까지.

둘째, 자동화된 테스트를 작성해. 데이터 품질 테스트, 모델 성능 테스트를 포함해서.

셋째, 문서화를 생활화해. 왜 그런 결정을 했는지 기록해 둬."

실전 팁

💡 - 기술 부채는 피할 수 없지만, 관리할 수는 있습니다. 정기적으로 청소 시간을 가지세요

• 새로운 코드를 추가할 때마다 "이것이 기술 부채가 될까?"라고 스스로에게 물어보세요

---

5. MLOps 성숙도 레벨

김개발 씨의 팀은 MLOps 도입을 결정했습니다. 하지만 어디서부터 시작해야 할지 막막합니다.

박시니어 씨가 말합니다. "MLOps에는 성숙도 레벨이 있어.

레벨 0부터 차근차근 올라가면 돼. 처음부터 레벨 2를 목표로 하면 실패해."

MLOps 성숙도 레벨은 조직의 ML 운영 능력을 측정하는 기준입니다. 레벨 0은 모든 것이 수동인 상태이고, 레벨 1은 ML 파이프라인이 자동화된 상태이며, 레벨 2는 CI/CD까지 완전히 자동화된 상태입니다.

각 레벨은 이전 레벨을 기반으로 하므로, 단계를 건너뛸 수 없습니다. 현재 조직의 레벨을 파악하고 다음 레벨로 나아가는 것이 중요합니다.

다음 코드를 살펴봅시다.

# MLOps 성숙도 레벨 구현 비교

# Level 0: 수동 프로세스
def level0_workflow():
    # 데이터 사이언티스트가 수동으로 모든 작업 수행
    data = manually_download_data()
    model = train_in_notebook(data)
    save_model_to_file(model, "model_final.pkl")
    # 배포? IT팀에 이메일로 요청...

# Level 1: ML 파이프라인 자동화
def level1_workflow():
    # 파이프라인은 자동화, 하지만 트리거는 수동
    pipeline = MLPipeline()
    pipeline.add_step(DataIngestion())
    pipeline.add_step(FeatureEngineering())
    pipeline.add_step(ModelTraining())
    pipeline.add_step(ModelValidation())
    pipeline.run()  # 수동으로 실행

# Level 2: CI/CD 완전 자동화
def level2_workflow():
    # 코드 푸시 시 자동으로 전체 파이프라인 실행
    @on_code_push
    def trigger_pipeline():
        run_tests()
        retrain_model()
        validate_model()
        if performance_improved():
            deploy_to_production()

구글 클라우드는 MLOps 성숙도를 세 단계로 정의했습니다. 이 프레임워크는 업계에서 널리 사용되고 있습니다.

레벨 0: 수동 프로세스 대부분의 ML 팀이 여기서 시작합니다. 데이터 사이언티스트가 주피터 노트북에서 모델을 개발합니다.

학습, 검증, 배포 모두 수동입니다. 버전 관리는 파일명으로 합니다.

배포는 IT팀에 이메일로 요청합니다. 레벨 0의 특징은 ML과 운영의 완전한 분리입니다.

데이터 사이언티스트는 모델만 만들고, 엔지니어는 그것을 어떻게든 운영 환경에 올립니다. 소통 비용이 크고, 배포 주기가 깁니다.

보통 몇 달에 한 번 새 모델이 배포됩니다. 레벨 1: ML 파이프라인 자동화 이 단계에서는 ML 파이프라인이 자동화됩니다.

데이터 전처리부터 모델 학습, 검증까지 하나의 파이프라인으로 연결됩니다. 파이프라인을 한 번 실행하면 전체 과정이 자동으로 수행됩니다.

하지만 파이프라인 자체는 여전히 수동으로 트리거됩니다. 새 데이터가 들어왔을 때, 누군가가 파이프라인 실행 버튼을 눌러야 합니다.

파이프라인 코드의 변경도 수동으로 테스트하고 배포합니다. 레벨 1의 핵심은 피처 스토어의 도입입니다.

피처를 중앙에서 관리하고, 학습과 서빙에서 동일한 피처를 사용합니다. 이것은 학습-서빙 왜곡 문제를 방지합니다.

레벨 2: CI/CD 파이프라인 자동화 가장 성숙한 단계입니다. 코드 변경 시 자동으로 테스트가 실행되고, 통과하면 모델이 재학습되고, 성능이 검증되면 자동으로 배포됩니다.

데이터 변경에 대해서도 자동으로 재학습이 트리거됩니다. 레벨 2에서는 ML 파이프라인 자체가 CI/CD의 대상이 됩니다.

파이프라인 코드를 변경하면, 그 파이프라인이 제대로 동작하는지 자동으로 테스트됩니다. 모든 것이 코드로 관리되고, 모든 변경이 추적됩니다.

김개발 씨가 물었습니다. "저희 팀은 어느 레벨인가요?" 박시니어 씨가 웃었습니다.

"솔직히 말하면, 대부분의 팀이 레벨 0이야. 레벨 1에 도달한 팀도 많지 않아.

하지만 괜찮아. 중요한 건 현재 위치를 인식하고, 한 걸음씩 나아가는 거야." 레벨 0에서 레벨 1로 가는 것이 가장 큰 도약입니다.

노트북에서 벗어나 파이프라인을 구축하는 것, 버전 관리를 도입하는 것, 실험을 추적하는 것. 이런 기본적인 것들부터 시작하면 됩니다.

실전 팁

💡 - 현재 팀의 성숙도 레벨을 솔직하게 평가하세요. 과대평가하면 잘못된 도구를 선택하게 됩니다

• 레벨을 올리는 것보다 현재 레벨을 안정화하는 것이 먼저입니다

---

6. 주요 도구 생태계

김개발 씨는 MLOps 도구를 검색해 보았습니다. MLflow, Kubeflow, Airflow, DVC, Feast...

수십 개의 도구가 쏟아집니다. "도대체 뭘 써야 하죠?" 박시니어 씨가 답합니다.

"도구는 문제를 해결하기 위한 수단일 뿐이야. 먼저 우리가 어떤 문제를 해결하려는지 명확히 하자."

MLOps 도구 생태계는 크게 실험 추적, 피처 스토어, 오케스트레이션, 모델 서빙, 모니터링의 다섯 가지 영역으로 나눌 수 있습니다. 각 영역에서 여러 오픈소스와 상용 도구가 경쟁하고 있습니다.

모든 도구를 한 번에 도입할 필요는 없습니다. 가장 급한 문제부터 해결하는 도구를 선택하고, 점진적으로 확장해 나가는 것이 현명합니다.

다음 코드를 살펴봅시다.

# MLOps 도구 생태계 활용 예시

# 1. 실험 추적: MLflow
import mlflow
with mlflow.start_run():
    mlflow.log_param("learning_rate", 0.01)
    mlflow.log_metric("accuracy", 0.95)
    mlflow.sklearn.log_model(model, "model")

# 2. 데이터 버전 관리: DVC
# dvc add data/training_data.csv
# dvc push

# 3. 오케스트레이션: Airflow DAG 정의
from airflow import DAG
from airflow.operators.python import PythonOperator
dag = DAG('ml_pipeline', schedule_interval='@daily')
train_task = PythonOperator(task_id='train', python_callable=train_model, dag=dag)

# 4. 모델 서빙: FastAPI + Docker
from fastapi import FastAPI
app = FastAPI()
@app.post("/predict")
def predict(data: InputData):
    return {"prediction": model.predict(data)}

MLOps 도구의 세계는 방대합니다. 하지만 두려워할 필요 없습니다.

각 도구가 해결하려는 문제를 이해하면, 선택이 명확해집니다. 실험 추적 도구는 모델 개발 과정을 기록합니다.

대표적인 도구는 MLflow입니다. 어떤 하이퍼파라미터로 학습했는지, 성능 지표는 어땠는지, 결과 모델은 무엇인지 추적합니다.

주피터 노트북에서 실험할 때 "이 결과가 어떤 설정이었지?"라고 헤맨 경험이 있다면, 이 도구가 필요합니다. 데이터 버전 관리 도구는 데이터와 모델 파일을 버전 관리합니다.

DVC(Data Version Control)가 대표적입니다. Git은 코드 버전 관리에 최적화되어 있어서, 대용량 데이터 파일을 다루기 어렵습니다.

DVC는 Git과 함께 사용하면서 데이터 파일을 효율적으로 관리합니다. 피처 스토어는 피처를 중앙에서 관리합니다.

Feast가 오픈소스 피처 스토어의 대표 주자입니다. 학습 시에 사용한 피처와 서빙 시에 사용하는 피처가 다르면 문제가 생깁니다.

피처 스토어는 이런 학습-서빙 왜곡 문제를 방지합니다. 오케스트레이션 도구는 복잡한 ML 파이프라인을 관리합니다.

Airflow는 범용 워크플로우 오케스트레이터로, ML 파이프라인에도 널리 사용됩니다. Kubeflow Pipelines는 쿠버네티스 환경에 특화된 ML 파이프라인 도구입니다.

모델 서빙 도구는 학습된 모델을 API로 제공합니다. 간단한 경우 FastAPI로 직접 서빙 서버를 구축할 수 있습니다.

더 복잡한 요구사항이 있다면 Seldon, BentoML, TensorFlow Serving 같은 전문 도구를 사용합니다. 모니터링 도구는 배포된 모델의 성능을 추적합니다.

Evidently, Whylogs, Great Expectations 같은 도구로 데이터 드리프트와 모델 성능 저하를 감지할 수 있습니다. 위의 코드에서 각 도구의 기본 사용법을 볼 수 있습니다.

MLflow로 실험을 추적하고, DVC로 데이터를 버전 관리합니다. Airflow로 일일 학습 파이프라인을 스케줄링하고, FastAPI로 모델을 서빙합니다.

김개발 씨가 물었습니다. "어떤 도구부터 시작하는 게 좋을까요?" 박시니어 씨가 답했습니다.

"대부분의 팀에게 첫 번째 도구는 MLflow야. 실험 추적이 모든 것의 시작이거든.

어떤 설정이 좋은 결과를 냈는지 모르면, 개선할 수가 없어. MLflow는 설치도 쉽고, 학습 곡선도 낮아." 두 번째로는 보통 DVC를 추가합니다.

데이터와 모델 파일을 버전 관리하면, 재현성이 크게 향상됩니다. "지난달에 더 좋았던 모델이 뭐였지?"라는 질문에 바로 답할 수 있게 됩니다.

오케스트레이션 도구는 그 다음입니다. 파이프라인이 복잡해지고, 정기적인 재학습이 필요해지면 Airflow나 Kubeflow를 도입합니다.

중요한 것은 도구에 휘둘리지 않는 것입니다. 도구는 문제를 해결하기 위한 수단입니다.

문제가 명확하지 않으면, 도구를 도입해도 효과가 없습니다. "왜 이 도구가 필요한가?"라는 질문에 명확히 답할 수 있을 때 도입하세요.

실전 팁

💡 - 처음에는 MLflow 하나로 시작하세요. 실험 추적만 해도 큰 변화를 느낄 수 있습니다

• 상용 도구보다 오픈소스로 시작하세요. 나중에 필요하면 마이그레이션할 수 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!