20장. 머신러닝과 MLOps

6부 · 가치 — 어떻게 성과로 바꾸는가
19장 · 20장

추천 모델을 만들어 배포했다.

석 달이 지났다.

그동안 사용자 구성은 꽤 달라졌는데
모델 성능을 확인한 사람은 아무도 없다.

19장에서 데이터를 소비하는 환경을 만들었다.

여기서 한 걸음 더 나가면 머신러닝이 있다.

이 장에서는 모델을 만드는 이야기보다
모델을 계속 운영하는 이야기를 주로 다룬다.

좋은 모델 하나를 만드는 것보다
모델을 반복해서 만들 수 있는 체계가 어렵기 때문이다.

데이터 활용이 아직 그 단계가 아니라면
이 장은 건너뛰어도 된다.

1. 고급 분석과 머신러닝

데이터 활용이 발전하면
머신러닝을 사용할 수 있다.

예를 들어

구매 가능성이 높은 사용자는 누구인가?

이탈 위험 사용자는 누구인가?

이 결제는 이상거래인가?

어떤 상품을 추천해야 하는가?

같은 문제를 해결할 수 있다.

BI와는 무엇이 다른가

앞 장에서 본 BI와 헷갈리기 쉽다.

흔히 이렇게 나눈다.

BI = 과거 분석
ML = 미래 예측

외우기는 쉽지만 정확하지 않다.

BI에서도 예측이나 What-if 분석을 할 수 있고,
머신러닝도 예측 말고 분류·군집화·이상탐지·추천에 쓰인다.

차이는 시점이 아니라 하는 일에 있다.

BI는 사람이 결정하고, ML은 결정의 일부를 기계에 넘긴다.

넘기는 순간 새로운 문제가 생긴다.

하지만 여기에서 중요한 점이 있다.

모델을 만드는 것보다
모델을 지속적으로 운영하는 것이 더 어렵다.

그래서 등장하는 것이 MLOps다.

2. MLOps란 무엇인가

MLOps는

머신러닝 모델을 안정적으로 개발하고,
검증하고, 배포하고, 운영하기 위한 엔지니어링 체계

라고 이해하면 된다.

흔히

ML + DevOps

라고 설명하지만, 실제로는 DevOps보다 관리 대상이 많다.

일반 애플리케이션은 주로

Code

를 관리한다.

ML 시스템에서는 다음을 함께 관리해야 한다.

Code
Data
Feature
Model
Configuration
Environment

3. 머신러닝 전체 생애주기

MLOps에서는 모델 하나만 보지 않고
프로젝트 전체 흐름을 관리한다.

flowchart LR
    n0["비즈니스 문제 정의"] --> n1["데이터 탐색"] --> n2["데이터 준비"] --> n3["피처 엔지니어링"] --> n4["모델 학습"] --> n5["모델 평가"] --> n6["배포"] --> n7["운영 모니터링"] --> n8["필요 시 재학습"]

이 과정은 한 번으로 끝나는 것이 아니라
계속 반복된다.

4. 프로젝트 시작부터 표준화한다

새로운 ML 프로젝트를 시작할 때마다

Git 저장소
폴더 구조
환경
CI/CD
실험 기록 방식

을 새로 정의하면 비효율적이다.

따라서 조직에서는

프로젝트 템플릿
표준 코드 구조
공통 라이브러리
공통 실행 환경

을 제공할 수 있다.

다만 모든 프로젝트를 똑같이 만들 필요는 없다.

반복되는 부분을 표준화하고
특수한 부분만 개별적으로 설계하는 것이 목적이다.

5. Experiment Tracking

머신러닝 실험에서는 작은 차이만으로도
모델 결과가 달라질 수 있다.

예를 들어

데이터셋
Feature
Algorithm
Hyperparameter
Code Version

이 달라지면 결과도 달라진다.

그래서 실험할 때마다 다음을 기록한다.

어떤 데이터를 사용했는가?

어떤 피처를 사용했는가?

어떤 파라미터인가?

성능은 얼마인가?

어떤 코드 버전인가?

이것을 Experiment Tracking이라고 한다.

MLflow 같은 도구가 대표적인 예다.

6. 재현 가능성

머신러닝에서는

지난달 만들어진 모델을
오늘 동일한 조건에서 다시 만들 수 있는가?

가 중요하다.

이를 위해

Code Version
Data Version
Feature Version
Parameter
Environment

를 함께 관리해야 한다.

이를 Reproducibility, 즉 재현 가능성이라고 한다.

7. Feature Engineering

원본 데이터를 그대로 모델에 사용하는 것보다
새로운 의미를 가진 입력값을 만들어 사용하는 경우가 많다.

예를 들어 원본에는

주문 이벤트
조회 이벤트
결제 이벤트

가 있을 수 있다.

이를 이용해 다음과 같은 피처를 만든다.

최근 7일 주문 횟수
최근 30일 체류시간
마지막 결제 후 경과일
최근 30일 결제금액

이처럼 모델이 사용할 입력 변수를 만드는 과정을
Feature Engineering이라고 한다.

8. Feature Store

여러 모델이 같은 피처를 반복 사용한다면
각 팀이 따로 구현하는 것은 비효율적일 수 있다.

이때 Feature Store를 사용할 수 있다.

예를 들어

Feature Store

user_7d_order_count
user_30d_watch_minutes
days_since_last_payment

처럼 공통 피처를 관리할 수 있다.

주요 장점은 다음과 같다.

피처 재사용
정의 일관성
학습과 서비스 간 계산 차이 감소
유지보수 개선

하지만 Feature Store는
모든 ML 시스템에 반드시 필요한 것은 아니다.

모델이 적고 피처 공유가 거의 없다면
기존 Data Warehouse나 DB만으로도 충분할 수 있다.

즉,

반복적으로 사용하고 운영할 가치가 있는 피처를
중앙 관리할 필요가 있을 때 도입한다.

9. 모델 제공 방식

학습한 모델을 실제 서비스에서 사용하는 방식은 여러 가지다.

대표적으로 다음 세 가지를 생각할 수 있다.

여기서 Stream 모델이라는 별도의 모델 종류가 있는 것은 아니다.

정확히는

스트림으로 들어오는 이벤트를 모델이 계속 추론하는 구조

라고 이해하면 된다.

10. Model Registry

모델이 계속 만들어지면
파일 이름만으로 관리하기 어렵다.

model_v1
model_v2
model_final
model_final2
really_final

같은 상황이 발생한다.

그래서 Model Registry를 사용할 수 있다.

Order Prediction

v1 → Archived
v2 → Staging
v3 → Production

같이 버전과 상태를 관리한다.

모델과 함께 다음 정보도 기록할 수 있다.

학습 데이터
피처
성능
작성자
배포 시점
모델 버전

11. 모델 배포 후 모니터링

모델을 배포했다고 프로젝트가 끝나는 것은 아니다.

운영 환경에서는 계속 상태를 확인해야 한다.

모델 성능
응답시간
오류율
입력 데이터 품질
입력 데이터 분포
예측 결과 분포

특히 시간이 지나면서
운영 환경의 데이터가 달라질 수 있다.

12. Drift를 구분해서 이해한다

Drift라는 말을 하나의 현상처럼 사용하기 쉽지만
조금 더 구분하는 것이 좋다.

Data Drift

입력 데이터의 분포가 달라지는 현상이다.

예를 들어 예전에는

20대 사용자 70%

였는데 어느 순간

40대 사용자 60%

가 되었다면 입력 분포가 크게 바뀐 것이다.

Prediction Drift

모델이 출력하는 예측값의 분포가 달라지는 현상이다.

예를 들어 기존에는

고위험 사용자 5%

였는데 갑자기

고위험 사용자 40%

가 된다면 점검이 필요하다.

Concept Drift

입력과 실제 결과 사이의 관계 자체가 바뀌는 현상이다.

예전에 구매 가능성을 높이던 행동이
시장이나 사용자 행동 변화로 더 이상 같은 의미를 가지지 않을 수 있다.

중요한 점은

Drift가 발생했다고 해서 반드시 모델 성능이 떨어졌다는 뜻은 아니며,
모델 성능 저하 역시 Drift 하나만으로 설명되는 것은 아니다.

따라서 여러 신호를 함께 봐야 한다.

13. 모델 재학습

모델은 필요할 때 다시 학습할 수 있다.

재학습 기준은 여러 방식으로 정할 수 있다.

매주 재학습

신규 데이터 일정량 누적

성능 기준 이하로 하락

Data Drift 발생

중요한 비즈니스 이벤트 발생

다만 모든 모델을 자주 재학습할 필요는 없다.

데이터 분포가 안정적이고
모델 성능도 유지되고 있다면
재학습 빈도가 매우 낮아도 된다.

즉,

재학습 주기는 모델의 특성과 데이터 변화 속도를 기준으로 결정한다.

14. 자동 재학습과 자동 배포는 구분한다

재학습을 자동화한다고 해서

flowchart LR
    n0["재학습"] --> n1["즉시 운영 배포"]

까지 자동으로 해야 하는 것은 아니다.

위험도가 높은 시스템에서는

flowchart LR
    n0["재학습"] --> n1["자동 평가"] --> n2["사람 또는 정책 기반 승인"] --> n3["운영 배포"]

를 사용할 수 있다.

자동화 수준 역시
업무 위험도에 따라 결정해야 한다.

15. 안전한 모델 배포

새 모델을 만들었다고
기존 모델을 한 번에 교체할 필요는 없다.

A/B 테스트

기존 모델 → 일부 사용자
신규 모델 → 일부 사용자

로 나누어 실제 서비스 지표를 비교한다.

반드시 50:50일 필요는 없다.

99:1
95:5
90:10

처럼 작은 비율로 시작할 수도 있다.

Shadow Deployment

실제 요청을 두 모델이 모두 처리하지만
사용자에게는 기존 모델 결과만 보여준다.

flowchart LR
    req["실제 요청"] --> a["기존 모델"] --> s["실제 서비스에 사용"]
    req --> b["신규 모델"] --> l["결과만 기록"]

신규 모델을 실제 트래픽에서
안전하게 검증하는 방법이다.

A/B 테스트와 Shadow 방식은 유용한 선택지이지만
모든 모델에 반드시 필요한 절차는 아니다.

16. 모델 지표와 비즈니스 지표

모델의 기술적인 정확도가 높아졌다고 해서
반드시 비즈니스가 좋아지는 것은 아니다.

예를 들어 추천 모델의 정확도가 올라갔어도

체류시간
재방문율
주문율
매출

이 개선되지 않았다면
비즈니스 관점에서는 성공이라고 보기 어려울 수 있다.

따라서

Model Metric
+
Business Metric

을 함께 본다.

예를 들어

flowchart LR
    M["추천 정확도 ↑<br/>모델 지표"] --> S["체류시간 ↑"] --> C["주문 전환율 ↑<br/>비즈니스 지표"]

    style M fill:#fafafa,stroke:#bbb,color:#1a1a1a
    style C fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

까지 연결되어야 한다.

모델 지표만 보고 있으면
정확도는 올랐는데 아무것도 나아지지 않은 상태를 알아차리지 못한다.

17. 학습한 환경과 서비스하는 환경이 다르다면

모델을 만드는 곳과 쓰는 곳은 환경이 다른 경우가 많다.

모델은 파이썬으로 PyTorch를 써서 만들었는데,
그 모델을 쓸 서비스는 Java로 돌아갈 수 있다.

학습에 쓴 프레임워크를 서비스 서버에 그대로 올리자니
무겁고, 언어도 맞지 않는다.

그래서 모델을 프레임워크에서 떼어내는 형식이 필요하다.

ONNX

ONNX(Open Neural Network Exchange) 가 그런 형식 중 하나다.

이미지에 PNG라는 공통 형식이 있는 것과 비슷하다.
어떤 그림 도구로 그렸든 PNG로 저장하면 어디서나 열린다.

모델도 마찬가지로, 학습에 쓴 도구와 상관없이
공통 형식으로 저장해 두면 다른 환경에서 실행할 수 있다.

flowchart LR
    PT["PyTorch"] --> ONNX
    TF["TensorFlow"] --> ONNX
    SK["scikit-learn"] --> ONNX

    ONNX["ONNX 파일<br/>──────────<br/>프레임워크에 묶이지 않은<br/>공통 형식"]

    ONNX --> RT["ONNX Runtime"]
    RT --> J["Java 서비스"]
    RT --> C["C++ 서비스"]
    RT --> M["모바일 · 엣지"]

    style ONNX fill:#e8f4ff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a

학습은 익숙한 프레임워크로 하고,
서비스는 ONNX Runtime이 있는 환경이면 어디서든 돌린다.

추론에 최적화된 런타임을 쓸 수 있어
속도나 자원 면에서 이득을 보기도 한다.

만능은 아니다

다만 이렇게 생각하면 안 된다.

ONNX로 변환하면
어디에서든 100% 동일하게 실행된다.

변환 과정에서 지원되지 않는 연산자가 있을 수 있고,
직접 만든 계층은 그대로 옮겨지지 않을 수 있다.
런타임 구현에 따라 결과가 미세하게 달라지기도 한다.

그래서 변환한 뒤에는
원래 모델과 같은 결과가 나오는지 반드시 확인한다.

ONNX는 모델의 상호운용성을 높이는 수단이지
모든 환경을 똑같이 만들어 주는 장치가 아니다.

18. MLOps의 본질

결국 MLOps의 목적은

좋은 모델 하나 만들기

가 아니다.

좋은 모델을
반복해서 만들고
검증하고
배포하고
감시하고
개선할 수 있는 체계

를 만드는 것이다.

즉,

모델이 아니라 모델을 만드는 공장을 만드는 것

이라고 생각하면 이해하기 쉽다.

이 장에서 나온 장치들을 다시 보면 모두 같은 일을 한다.

관통하는 낱말은 셋이다.

표준화
자동화
재사용

사람이 매번 손으로 처리하면 느리고 실수가 생긴다.
템플릿, CI/CD, 자동 테스트, 자동 모니터링으로 옮길 수 있는 것은 옮긴다.

환경별로 코드를 따로 두지 않는 것도 같은 생각이다.
DB 주소나 모델 버전 같은 값은 코드에 박지 않고
공통 코드 하나에 환경별 설정을 붙인다.

정책도 문서로만 두면 지켜지지 않는다.
개인정보 암호화나 저장 지역 제한 같은 규칙은
시스템이 자동으로 검사하게 만들 수 있다.

이 이야기는 ML에만 해당하지 않는다.
조직 전체에 어떻게 적용하는지는
22장 「플랫폼과 조직」에서 다룬다.

19. 19~20장을 하나로 연결하면

6부에 등장한 용어가 많아서
처음에는 각각 별개의 주제처럼 느껴질 수 있다.

하지만 하나로 이으면 단순하다.

flowchart LR
    sys["업무 시스템<br/>회원 · 결제 · 배송 · 주문"]
    dp["Data Product"]
    dds["소비 환경"]

    sys --> dp --> dds

    dds --> bi["BI"]
    dds --> ml["ML"]

    bi --> sem["Semantic Layer"] --> ss["Self-Service"] --> dec["사람의 의사결정"]
    ml --> fe["Feature"] --> mt["Model"] --> ops["MLOps"] --> auto["예측 · 추천 · 자동화"]

    style dds fill:#f8fbff,stroke:#4a90e2,stroke-width:2px,color:#1a1a1a
    style dec fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a
    style auto fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

갈라지는 지점은 하나뿐이다.
사람이 결정하느냐, 기계가 결정하느냐다.

그리고 이 모든 것을 밑에서 받치는 기반이 있다.

Platform
Governance
Security
Metadata
Lineage
Automation

셋은 같은 것을 한다

소비 환경, BI, MLOps를 나란히 놓으면
사실 같은 방향을 향하고 있다.

• 소비 환경 — 데이터 소비를 표준화하고 재사용한다
• BI — 분석과 지표를 표준화하고 재사용한다
• MLOps — ML 개발과 운영을 표준화하고 재사용한다

조직의 데이터 활용은 대체로 이 길을 지난다.

flowchart LR
    n0["개인의 수작업"] --> n1["공통 패턴 발견"] --> n2["표준화"] --> n3["자동화"] --> n4["재사용"] --> n5["운영 가능한 시스템"]

    style n0 fill:#fff4f4,stroke:#d9534f,color:#1a1a1a
    style n5 fill:#f2fbf4,stroke:#4caf50,stroke-width:2px,color:#1a1a1a

6부의 제목이 「가치」인 이유가 여기에 있다.

데이터가 가치가 되는 것은 많이 저장해서가 아니라
이 사슬이 끝까지 이어질 때다.

20. 20장 정리

네 가지만 기억하면 된다.

모델을 만드는 것보다 운영하는 것이 어렵다.
그래서 MLOps는 모델이 아니라 모델을 만드는 공장을 다룬다.

ML은 관리할 것이 코드만이 아니다.
데이터, 피처, 모델, 설정, 환경까지 함께 버전을 맞춰야
지난달 모델을 오늘 다시 만들 수 있다.

자동 재학습과 자동 배포는 다른 문제다.
재학습을 자동화했다고 바로 운영에 올릴 이유는 없다.
위험도에 따라 평가와 승인을 사이에 둔다.

모델 지표가 올라도 비즈니스 지표는 그대로일 수 있다.
정확도와 체류시간과 전환율이 이어지는지 함께 봐야 한다.

여기까지가 6부다.

데이터의 가치는 많이 저장하는 데서 생기지 않는다.
신뢰할 수 있는 데이터를 사람들이 쉽게 찾고 소비하며,
반복 가능한 분석과 의사결정과 자동화로 연결할 때 만들어진다.

좋은 데이터 아키텍처의 최종 목표는
거대한 데이터베이스를 만드는 것이 아니다.

조직의 사람들이 데이터를 믿을 수 있고,
필요한 데이터를 쉽게 찾을 수 있고,
필요한 형태로 안전하게 쓸 수 있으며,

좋은 분석과 모델이 발견되면
그 결과를 조직 전체가 다시 쓸 수 있는 시스템으로 키우는 것.

그것이 데이터를 비즈니스 가치로 바꾸는 아키텍처의 핵심이다.

이 장에서 나온 용어는 부록 C 「용어집」에 정리해 두었다.

다음 부에서는 지금까지의 이야기를
실제 조직에서 어떻게 시작할지 다룬다.