[MLOps] MLOps 개념 정리

ARK_dvlp·2025년 9월 19일

커널 아카데미 16기

목록 보기
9/17

머신러닝의 이해

기본 개념

학습

머신러닝에서 학습(Learning)이란, 입력(자극, Stimulus)과 출력(반응, Response)의 관계를 데이터로부터 자동으로 찾아내는 과정이다.

여기서 내부의 규칙이나 함수는 명시적으로 주어지지 않고, 블랙박스(Blackbox) 모델이 데이터를 통해 스스로 학습하게 된다.

  • Stimulus (입력 데이터)
    • 예: 이미지, 음성, 텍스트, 센서 데이터 등
    • 사람이 직접 설계한 특징(feature) 또는 원시(raw) 데이터일 수 있음
  • Blackbox (모델)
    • 머신러닝 알고리즘이 동작하는 핵심 부분
    • 입력과 출력 사이의 규칙을 학습해내는 함수적 구조
    • 초기에는 내부 구조가 "보이지 않는 상자(black box)"로 표현됨
    • 학습이 진행되면서 점차 데이터의 패턴을 잘 설명하는 모델로 발전
  • Response (출력/예측 결과)
    • 예: 이미지 분류 결과(고양이/개), 주가 예측 값, 번역된 문장 등
    • 모델이 학습을 통해 얻게 된 함수적 관계의 결과물

머신러닝 시스템 워크 플로우

비즈니스 문제 정의

데이터 분야에서는 데이터를 바라보는 관점이 매우 중요합니다. 데이터 기반의 프로젝트에서 흔히 하는 실수들이 바로 모델링부터 시작을 하는 것 입니다. 왜냐하면 데이터와 도구가 준비되어 있다고 바로 모델을 만들면, 비즈니스 목표와 문제 정의가 불명확해 모델 결과가 실제로 쓸모없을 수 있습니다. 또한, 데이터 수집·정제·탐색(EDA) 과정을 생략하면 결측치나 이상치가 모델 성능에 영향을 줍니다. 마지막으로, 평가 지표(KPI)를 미리 정하지 않으면 모델이 비즈니스에 기여하는 정도를 판단하기 어렵습니다. 따라서 비즈니스 목표 → 데이터 준비 → 모델 → 평가 지표 순서가 필수적입니다.
또한 데이터를 바라보는 관점 또한 매우 중요합니다. 예를들어 어린 시절에 “여름철에 선풍기를 틀고 자면 죽는다.”라는 정보를 자주 들었을 텐데, 해당 정보는 사실이 아닌 것을 알 수 있었습니다. 위의 예시처럼 데이터를 바라보는 관점을 비판적으로 받아들이는 시각이 빌요합니다.

비즈니스 목표 수립 시 고려사항

  1. 성능 목표
    • 모델이나 시스템이 달성해야 하는 정확도, 재현율, 응답 속도 등 구체적 기준을 정의합니다.
    • 예: 고객 이탈 예측 모델에서 80% 이상의 정확도를 목표로 설정.
  2. 기술 인프라 요구사항
    • 프로젝트 수행과 모델 운영을 위해 필요한 하드웨어, 소프트웨어, 클라우드 환경 등을 명시합니다.
    • 예: GPU 서버 필요 여부, 데이터베이스 구조, 배치 처리 또는 실시간 처리 환경 등.
  3. 비용 제약
    • 프로젝트 기간, 투입 인력, 개발·운영·인프라 비용 등 현실적인 제약 조건을 고려합니다.
    • 예: 3개월 내 PoC 완료, 클라우드 사용 비용 월 500만 원 이하 등.
  4. 투명성, 설명가능성 수준
    • 모델이나 분석 결과를 이해관계자가 이해할 수 있는 정도를 정의합니다.
    • 예: 금융권 신용평가 모델은 설명가능성을 높여 규제 준수와 의사결정 지원 필요.

리스크 평가

  • 특정 기간 동안 모델을 사용할 수 없는 리스크
  • 특정 표본에 대해 잘못된 예측을 반환하는 리스크
  • 시간이 지남에 따라 모델 정확도나 공정성이 떨어지는 리스크
  • 모델을 유지보수하기 위한 기술 및 리소스가 손실될 리스크
    • 예를 들어 담당 유지보수 인력이 퇴사하는 경우

의도와 책무

MLOps에서의 의도와 책무는 단순히 모델을 배포하고 운영하는 수준을 넘어, 모델의 품질, 안정성, 신뢰성, 규제 준수를 보장하는 핵심 원칙입니다.

데이터 과학자, 엔지니어, 비즈니스 팀 등 각 참여자가 자신의 역할과 책임을 명확히 수행함으로써, 모델이 기대한 성능을 유지하고 오류나 편향으로 인한 리스크를 최소화할 수 있습니다.

예를 들어, 금융권에서 신용평가 모델을 운영할 때 데이터 엔지니어는 데이터 파이프라인을 안정적으로 관리하고, 데이터 과학자는 모델 성능과 설명가능성을 검증하며, 운영팀은 배포 환경과 모니터링을 책임집니다. 실제로 요즘 LLM 관련 이슈가 종종있습니다. “이루다”라는 서비스는 차별 및 혐오 발언, 개인정보 유출 논란으로 서비스 종료가 되었습니다. 또한 최근에는 제타 AI라는 AI 쳇봇 대화 어플에서 10대 청소년들이 음담패설을 해서 검열을 강화하는 식으로 서비스가 개선 된 예시도 있습니다.

AI와 ‘야한 대화’에 빠진 초등생들... 학교는 안절부절

이러한 의도와 책무를 준수하면, 모델이 규제를 준수하면서 안정적으로 운영되고, 결과적으로 비즈니스 의사결정과 성과 향상으로 이어집니다.

직무전문가

직무 전문가(Subject Matter Expert, SME)는 프로젝트에서 달성해야 할 명확한 목표, 해결해야 할 비즈니스 과제, 그리고 KPI를 제시하는 역할을 담당합니다. 예를 들어, “분기 KPI 달성을 위해 고객 이탈률을 10% 줄인다”라는 목표가 명확하지 않으면 프로젝트가 방향성을 잃고 실패할 수 있습니다.

따라서 비즈니스 목표를 정의할 때는 프로젝트의 이해관계자들과 충분히 협의하여 성능 목표, 기술 인프라 요구사항, 비용 제약 등 현실적인 조건을 반영해야 합니다. 이를 통해 프로젝트의 방향성을 명확히 하고, 모델링과 분석 과정에서 불필요한 시행착오를 줄이며, 비즈니스 성과로 직결될 수 있는 결과를 도출할 수 있습니다.

데이터 탐색 및 전처리

적합한 데이터 찾기

핵심 체크리스트

  • 관련 데이터 세트 중 어떤 것을 사용할 수 있는가?
  • 이 데이터는 충분히 정확하고 신뢰할 수 있는가?
  • 이해관계자들이 이 데이터에 접근할 권한이 있는가?
  • 여러 데이터 소스를 조합하여 필요한 특성을 만들어낼 수 있는가?
  • 이 데이터의 수집 주기는 요구사항에 맞는가?
  • 데이터 레이블링이 필요한가?
    • 데이터 레이블링이 필요하다면 시간과 자원 측면에서 충분한가?
  • 모델을 배포한 후 데이터를 어떻게 갱신할 것인가?
  • 비즈니스 목표와 함께 정의한 KPI를 어떻게 측정할 것인가?
  • 이용약관, 목적성, PII(개인 식별 정보) 여부, 법적 검토, 소수 집단에 대한 고려 등을 준수 하였는가?

데이터 분석과 특성 선택

  • 데이터는 머신러닝 알고리즘의 근본 요소이므로, EDA를 통해 데이터 패턴을 이해하고 의미가 있을 것으로
    추정되는 특성을 추출하고 선택
  • 특성(feature)은 고정된 크기의 숫자 배열로서, 머신러닝 알고리즘이 유일하게 이해할 수 있는 객체
  • 선택 된 데이터의 전처리 과정을 데이터 엔지니어와 협의하여 데이터 수집 파이프라인을 정의

데이터 파이프라인 정의

선택 된 특성의 전처리 과정을 데이터 엔지니어와 협의하여 데이터 수집 파이프라인을 정의해야 하고, 아래와 같은
요소들을 고려해야 함

  • 데이터 수집 흐름(Workflow)
  • 데이터 수집 주기
  • 데이터 수집 양 혹은 기간
  • 데이터 저장 위치(스토리지, 데이터베이스, 피처 스토어 등)
  • 워크플로우 수행 시간
  • 실패 혹은 예외 등의 장애 처리

모델 개발

모델 개발 도구와 의존성

  • 프로그래밍 언어 ex) python
  • 머신러닝 플랫폼 및 도구 ex) SageMaker, Alteryx, DataRobot, …
  • 머신러닝 프레임워크 & 라이브러리 ex) Torch, Tensorflow, Keras, …
  • 의존성 관리 도구 ex) pip
  • 코드 형상 관리
    ex) GitHub, GitLab, BitBucket, CodeCommit, …

모델 학습 시 입출력 요소

  • 데이터셋
  • 각종 파라미터
    • 모델 파라미터 : 레이어의 가중치(weight)와 편향(bias)
    • 수행 파라미터 : 날짜 등의 일반적인 애플리케이션 수행에 필요한 동작 매개변수
    • 하이퍼파라미터 : 학습률, 배치 크기, 레이어 수 등의 모델 학습 관련 사전 설정 값
  • 학습된 모델(가중치 파일)
  • 모델의 출력 데이터(추론 결과)
  • 모델 지표
  • 수행 로그

모델 배포

모델 배포 시 고려사항

모델 배포는 단순히 모델을 서버에 올리는 작업이 아니라, 실제 서비스 환경에서 안정적이고 확장 가능하게 운영될 수 있도록 하는 과정입니다.

  • 확장성: 사용자 수가 늘어나도 성능 저하 없이 대응 가능해야 함
  • 신뢰성: 예측 결과가 일관되고 안정적으로 제공되어야 함
  • 보안: 모델 및 데이터 접근 권한 관리, 개인정보 보호 준수 필요

컨테이너화

모델 배포 시 컨테이너(Docker, Podman 등)를 활용하면 환경 간 차이를 최소화하고, 재현성과 확장성을 확보할 수 있습니다.

  • 이점: 의존성 관리 용이, 클라우드/온프레미스 어디서든 실행 가능
  • 활용: Docker 이미지로 모델 패키징 후 Kubernetes 같은 오케스트레이션 도구와 결합

워크플로우 관리 도구

복잡한 ML 파이프라인을 체계적으로 관리하기 위해 워크플로우 관리 도구를 활용합니다.

  • 예시: Airflow, Kubeflow, MLflow, Prefect
  • 기능: 데이터 수집 → 학습 → 배포 → 모니터링까지 전체 과정을 자동화하고 스케줄링 지원

저장소

모델과 데이터를 안전하게 버전 관리하기 위해 저장소를 운영합니다.

  • 모델 저장소: MLflow Model Registry, S3, GCP Artifact Registry
  • 데이터 저장소: 데이터 레이크, 데이터 웨어하우스
  • 코드 저장소: GitHub, GitLab 등을 통한 코드 및 실험 관리

모델 모니터링 및 피드백

모델 모니터링 요소

운영 환경에서 모델은 지속적으로 모니터링되어야 합니다.

  • 성능 지표: 정확도, 재현율, AUC 등 모델의 예측 품질
  • 데이터 분포: 입력 데이터의 분포가 학습 시점과 달라지는 데이터 드리프트 감지
  • 운영 지표: 응답 시간, 리소스 사용량, 장애 발생 여부

모델의 피드백 루프

모델은 한 번 배포로 끝나는 것이 아니라, 피드백을 받아 개선되는 순환 구조를 가져야 합니다.

  • 사용자 피드백: 실제 서비스 이용자의 반응과 성능 검증
  • 재학습(Continuous Training): 최신 데이터를 반영해 모델을 주기적으로 업데이트
  • 자동화 루프: 모니터링 → 이상 감지 → 데이터 수집 → 재학습 → 재배포

MLOps란 무엇인가?

기존 시스템

기존의 머신러닝 프로젝트는 모델 개발과 운영이 분리되어 있어, 연구 단계에서 성능이 좋아도 운영 환경에서 동일한 성능을 보장하지 못하는 경우가 많았습니다.

비즈니스의 발전

비즈니스는 점점 더 실시간 데이터, 대규모 사용자, 빠른 피드백을 요구하고 있습니다. 이에 따라 모델을 안정적으로 배포하고 운영하는 능력이 기업 경쟁력으로 직결되고 있습니다.

기존 시스템의 문제

  • 수동 배포로 인한 오류 및 비효율
  • 데이터 및 모델 버전 관리 부재
  • 운영 중 성능 저하와 데이터 드리프트 감지 어려움
  • 개발과 운영 팀 간 협업 부족

MLOps에 대한 관심

이러한 문제를 해결하기 위해 DevOps 개념을 머신러닝 분야에 적용한 것이 MLOps입니다.

Report

MLOps는 모델 개발, 배포, 모니터링, 재학습을 자동화된 파이프라인으로 통합 관리하여 효율성과 신뢰성을 보장합니다. 이를 통해 모델의 지속적 전달(Continuous Delivery)과 지속적 훈련(Continuous Training)이 가능해집니다.

DevOps VS MLOps

  • DevOps: 소프트웨어 애플리케이션의 개발과 운영을 자동화 및 최적화
  • MLOps: DevOps 개념을 확장하여, 데이터, 모델, 실험 관리까지 포함
  • DevOps가 코드 중심이라면, MLOps는 코드 + 데이터 + 모델을 모두 관리해야 하는 점이 다릅니다.

MLOps 아키텍처 설계

모델 및 서빙 요구 사항

요구사항

모델 서빙은 단순히 예측 결과를 반환하는 것을 넘어, 성능·안정성·확장성·보안성을 충족해야 합니다.

  • 성능: 충분한 정확도와 예측 속도 확보
  • 안정성: 서비스 장애 시에도 빠른 복구 가능
  • 확장성: 요청량이 증가해도 일정 수준의 성능 유지
  • 보안성: 데이터 보호 및 접근 권한 관리

응답지연

실시간 서비스를 제공하는 경우, 응답 시간(latency)이 핵심 요구사항입니다.

  • 저지연(Real-time): 금융 거래 탐지, 광고 추천 등은 수 ms~수백 ms 수준 필요
  • 중지연(Near real-time): 고객 지원 챗봇, 온라인 게임 분석 등 수 초 이내 필요
  • 고지연(Batch): 리포트 생성, 모델 재학습 등 수 분~수 시간도 허용

요구사항 요약

  • 정확도: KPI 충족 수준의 모델 성능
  • 지연시간: 서비스 특성에 맞는 응답 속도 확보
  • 확장성: 클라우드/온프레미스 환경에서 수평 확장 가능
  • 가용성: 고가용성(HA) 아키텍처 기반 운영
  • 보안 및 규제: 개인정보 보호, 산업 규제 준수

온라인 학습 vs 오프라인 학습

  • 온라인 학습: 데이터가 실시간으로 들어올 때, 즉시 모델 파라미터를 업데이트
    • 장점: 최신 데이터 반영 가능, 빠른 적응
    • 단점: 모델 안정성 유지가 어려움
  • 오프라인 학습: 일정 기간 데이터를 모아 일괄 학습
    • 장점: 안정적이고 대규모 데이터 학습 가능
    • 단점: 데이터 반영 시점이 늦음

온라인 추론

  • 요청이 들어올 때마다 즉시 예측 값을 반환하는 방식
  • 예시: 검색 추천, 광고 노출, 실시간 사기 탐지

오프라인 추론

  • 대량 데이터를 모아 일괄 처리 후 결과를 저장, 이후 필요 시 활용
  • 예시: 고객 세분화, 월간 리포트 생성, 캠페인 대상자 추출

다양한 추론 패턴

  • 동기식 추론: 요청과 동시에 응답 (API 호출 기반)
  • 비동기식 추론: 요청 후 큐에 저장하고, 처리 완료 시 알림
  • 배치 추론: 주기적으로 대량 데이터 처리
  • 스트리밍 추론: Kafka, Flink 등을 통한 이벤트 기반 실시간 추론

안티 패턴

  • 모델 재현 불가: 학습 코드, 데이터 버전 관리 없이 배포 → 동일 모델 재현 불가
  • 데이터 드리프트 무시: 운영 중 데이터 분포 변화를 감지하지 않음
  • 과도한 복잡성: 필요 이상으로 복잡한 아키텍처를 적용해 유지보수 비용 증가
  • 성능만 집중: 응답 지연, 확장성, 보안 요구사항을 무시하고 정확도만 추구

0개의 댓글