![[1주차-MLOPS] CH1. MLOps와 ML 엔지니어링 시작 (2026.10.18)](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdna%2FkJcco%2FdJMcaiyDNGM%2FAAAAAAAAAAAAAAAAAAAAAHJl1DTTqXexopgxcWcdDGEwVscs3ryyOwLpjmjQzlYZ%2Fimg.png%3Fcredential%3DyqXZFxpELC7KVnFOS48ylbz2pIh7yKj8%26expires%3D1793458799%26allow_ip%3D%26allow_referer%3D%26signature%3DAI0uwmTVvqubFg51vAVZ3c8aSLI%253D)
가중치에서 ML 플랫폼까지.
모델이 무엇을 배우는지에서 출발해, 그 모델을 만들고 내보내고 지켜보는 일이 왜 하나의 플랫폼이 되는지까지 따라갑니다. 책 2장(반복적인 MLOps 수명주기)은 ②편에서 이어집니다.
들어가며
이 글은 CloudNet@ 커뮤니티의 Machine Learning Platform Engineering Study 자료입니다.
책 출처: MLOps/LLMOps 이해를 위한 '머신러닝 플랫폼 엔지니어링(번역서)' 책 기반 스터디 — Book
저는 지금 사내 IDP(Internal Developer Platform — 개발자가 인프라·배포·도구를 셀프서비스로 쓰게 해 주는 사내 플랫폼) 개발을 맡고 있습니다. 그러던 중 MLOps 프로젝트를 진행하게 되었고, 우리 환경에 맞추기 전에 일반적으로는 어떻게 하는지부터 탐구해 보고 싶어 이 스터디에 참여했습니다.
이번 기회에 MLOps의 일반적인 흐름을 이해하고, 그 흐름을 프로젝트 상황에 맞게 커스텀할 수 있는 계기로 삼으려 합니다. 이 시리즈는 그 과정을 정리한 기록입니다.
MLOps 스터디 1주차 범위는 책 1·2장입니다. 책 1장은 첫 장부터 수명주기, feature store, model registry, LLMOps까지 한꺼번에 펼쳐 놓습니다. 인프라 쪽에서 오면 "가중치를 기록한다", "재현성을 보장한다" 같은 문장이 무엇을 걱정하는 말인지 감이 잘 오지 않습니다.
그래서 이 글은 모델이 무엇을 배우는지(가중치)부터 다시 짚고, 그 위에서 책 1장의 수명주기·역량·플랫폼·프로젝트를 원본 순서대로 정리합니다. 반대로 설치와 코드 실습, 역전파 같은 수식의 세부, 책 2장 내용은 다루지 않습니다. 책 2장은 ②편에 있습니다.
- 모델의 실체는 학습으로 찾은 가중치(숫자 덩어리)입니다. 코드가 그대로여도 데이터가 바뀌면 가중치가 바뀌고, 동작도 바뀝니다.
- 그래서 ML 프로젝트는 한 번 배포로 끝나지 않고 데이터 → 훈련 → 평가 → 배포 → 모니터링 → 재훈련 루프를 계속 돕니다.
- ML 플랫폼은 이 루프를 자동으로 돌리고 기록하는 도구 묶음입니다. 책은 Kubernetes 위에 Kubeflow Pipelines, Feast, MLflow, BentoML을 하나씩 붙여 직접 조립합니다.
읽는 방법
· 굵은 글씨만 따라가도 흐름이 이어집니다.
· 회색으로 접힌 상자(▸)는 수식이나 보충 설명입니다. 안 열어도 됩니다.
· 그림은 전부 슬라이더를 돌리고 버튼을 눌러 보는 용도입니다. 각 그림 위의 "해볼 것"부터 따라 해 보세요.
· 각 장 끝의 세 줄 요약만 읽고 넘어가도 괜찮습니다.
· 1~2장은 스터디 노트의 필수 사전 지식, 3~5장은 책 1장(1.1~1.4절)입니다. "책 N장"은 책의 장, 그냥 "N장"은 이 글의 장입니다.
01가중치 — 컴퓨터는 규칙을 어떻게 찾나
한 줄 요약: 입력에 곱하는 숫자(가중치)를 고쳐 가며 틀린 답을 없애는 것이 학습입니다.
MLOps 문서는 "모델 파일", "가중치를 기록", "재훈련" 같은 말을 설명 없이 씁니다. 무엇이 바뀌는지 모르면, 왜 그것을 버전 관리하고 다시 만들어야 하는지도 잡히지 않습니다.
이 장에서는 숫자 두 개짜리 가장 작은 모델로 학습을 직접 돌려 봅니다. 예시는 스터디 노트에 정리한 [bRd 3D] 영상의 "어른·아이 구분" 그대로입니다.
- 가중치 (weight)
- 입력값에 곱하는 숫자입니다. 이 장의 예시에는 몸무게(weight)도 나오니, 헷갈리지 않게 가중치로 부릅니다. 학습이 끝나면 모델 파일에 저장되는 것이 바로 이 숫자들입니다.
- 역치 (threshold)
- 합이 이 값 이상이면 1, 아니면 0으로 판정하는 기준선입니다. 이 장에서는 0.5로 고정합니다.
- 학습 (training)
- 정답을 아는 데이터로 계산해 보고, 틀리면 가중치를 고치기를 반복하는 과정입니다.
- 신경망 (neural network) · deep learning
- 이런 계산 단위(뉴런)를 여러 개, 여러 층(layer)으로 이은 것이 신경망입니다. 층을 깊게 쌓으면 deep learning이라고 부릅니다.
- 역전파 (backpropagation)
- 출력에서 생긴 오차를 출력에 가까운 층부터 거꾸로 전하며 가중치를 고치는 방법입니다. 이 글에서는 이름과 방향만 알면 됩니다.
비유 먼저
놀이공원 매표소 직원이 키와 몸무게에 각각 점수를 매겨 더하고, 합이 0.5 이상이면 어른 요금을 받는다고 해 봅시다. 처음에는 점수 배점을 대충 정했다가, 어른을 아이로 잘못 보낼 때마다 배점을 조금씩 올립니다.
이 배점이 가중치이고, 틀릴 때마다 배점을 고치는 일이 학습입니다. 다른 점은 하나뿐입니다. 사람이 아니라 컴퓨터가, 정답이 붙은 데이터를 보면서 고칩니다.
숫자로 한 번
영상의 데이터는 7명의 키·몸무게를 0~1 사이로 줄인 값입니다. 첫 번째 사람(키 0.7, 몸무게 0.8)은 어른입니다. 가중치를 아무렇게나 키 0.3, 몸무게 0.2로 두고 계산해 봅니다.
0.7 × 0.3 = 0.21
0.8 × 0.2 = 0.16
합 0.37 → 0.5보다 작으므로 0(아이) ── 정답은 1(어른), 틀림
두 번째 — 가중치를 둘 다 0.5로 올림
0.7 × 0.5 + 0.8 × 0.5 = 0.35 + 0.40 = 0.75 → 1(어른) ── 맞음
같은 가중치로 7명 전부 계산하면 7명 모두 맞음 ── 이 데이터에서 찾은 최적의 가중치
영상은 여기서 결론을 냅니다. 컴퓨터는 가중치를 바꿔 가며 오차가 없어질 때까지 계산을 반복하고, 그렇게 찾은 가중치로 새 사람도 판정합니다.
가중치 두 개로 어른과 아이 가르기
↔ 슬라이더 · 점 누르기 · 학습 재생옅은 남색 면이 "어른" 판정 구역입니다. 가중치를 바꾸면 경계선이 기울고, 어떤 점이 어느 쪽에 드는지가 바뀝니다.
※ 주: 7명의 키·몸무게와 정답은 원본 영상 수치 그대로 · 남색 원 = 어른, 흰 원 = 아이, 적색 고리 = 틀린 판정 · 학습 규칙(틀리면 입력값 × 0.1만큼 가중치를 고침)은 이 글에서 고른 것
층을 쌓으면 deep learning
위 그림은 뉴런 하나입니다. 데이터가 복잡하면 이런 뉴런을 여러 층으로 쌓아 입력층 → 은닉층 → 출력층으로 값을 흘려보냅니다.
출력에 오차가 생기면 출력에 가까운 층부터 거꾸로 가중치를 고치고, 다시 앞으로 계산하기를 반복합니다. 이것이 역전파입니다.
- 이미지 — 필터로 특징을 뽑습니다. 숫자 인식에서 직선 필터를 쓰면 1의 출력이 커지고, 곡선 필터를 쓰면 2의 출력이 커집니다. 이 특징들로 어떤 숫자인지 확률로 예측합니다.
- 언어 — 입력이 단어 하나일 수도, 문장일 수도 있어 구조가 유연해야 합니다. 앞 단어를 기억해 두고, 그 결과를 다음 단어 예측에 씁니다.
규칙을 사람이 쓰느냐, 데이터에서 찾느냐
| 구분 | 넣는 것 | 나오는 것 |
|---|---|---|
| 일반 프로그램 | 입력 + 사람이 쓴 규칙 | 결과 |
| 머신러닝 (학습할 때) | 입력 + 정답 | 규칙(가중치) |
| 머신러닝 (쓸 때) | 새 입력 + 찾은 가중치 | 예측 |
모델이 어떻게 동작할지는 학습된 가중치가 정합니다. 그래서 MLOps에서 "모델을 저장한다"는 말은 대개 가중치를 저장한다는 뜻이고, "같은 모델을 다시 만든다"는 말은 같은 가중치가 나오게 한다는 뜻입니다.
수식으로도 보고 싶다면
x₁·x₂는 키와 몸무게, w₁·w₂는 가중치입니다. ŷ는 "와이 햇"이라고 읽고 모델이 낸 답을 뜻합니다.
← 는 "왼쪽을 오른쪽 값으로 바꾼다", η는 "에타"라고 읽고 한 번에 고치는 폭(그림 1에서는 0.1)입니다. y는 정답입니다.
맞히면 (y − ŷ)가 0이라 가중치가 그대로이고, 어른을 아이로 틀리면 +1이라 입력값만큼 가중치가 커집니다. 이것이 퍼셉트론 학습 규칙이고, 층이 깊은 신경망에서는 같은 생각을 역전파로 확장합니다.
- 정의 — 가중치는 입력에 곱하는 숫자이고, 모델이 "배운 것"의 실체입니다.
- 계산법 — 입력 × 가중치를 더해 역치와 비교하고, 정답과 다르면 틀린 만큼 가중치를 고치기를 오차가 없어질 때까지 반복합니다.
- 쓰임 — 학습이 끝난 가중치를 저장한 것이 모델 파일이고, MLOps가 버전을 매기고 다시 만들 수 있게 관리하려는 대상입니다.
— 여기까지: 학습 = 가중치 고치기. 다음은 AI·ML·LLM 같은 이름들의 관계와, 모델이 만들어져 쓰이기까지 —
02용어 지도와 모델의 일생 — training, inference, fine-tuning
한 줄 요약: 모델은 training으로 가중치를 얻고 inference로 쓰입니다. 처음부터 훈련하는 대신 큰 모델을 가져와 일부만 고치는 것이 fine-tuning입니다.
MLOps 책은 이 단어들을 섞어 씁니다. 특히 training과 inference를 나눠 보지 않으면, 훈련 pipeline과 서빙(serving)이 왜 따로 있는지 놓칩니다.
이 장은 스터디 노트의 두 책(『그림으로 배우는 생성형 AI』, 『밑바닥부터 만들면서 배우는 LLM』) 정리를 묶었습니다. 1장의 가중치를 실마리로 용어 지도를 그리고, 모델의 일생을 따라갑니다.
- training · inference
- training은 데이터로 가중치를 조정하는 과정, inference는 학습된 모델에 새 입력을 넣어 출력을 얻는 일입니다. inference를 "예측(prediction)"이라고도 부릅니다.
- tensor
- 모델은 숫자만 다룰 수 있어서, 이미지·문장 같은 입력을 다차원 숫자 배열로 바꿉니다. 그 배열이 tensor입니다.
- pre-training · foundation model
- 대량의 데이터로 범용 모델을 먼저 훈련하는 것이 pre-training(사전 훈련)이고, 그 결과물이 foundation model(기초 모델·베이스 모델)입니다.
- transfer learning · fine-tuning
- 이미 훈련된 모델을 가져와 내 문제에 맞게 추가로 학습시키는 것이 transfer learning(전이 학습)입니다. 그중 가중치 일부만 갱신해 맞추는 방법이 fine-tuning(미세 조정)입니다.
- 얼림 (freeze)
- fine-tuning 때 갱신하지 않고 그대로 두는 층입니다. 얼린 층의 가중치는 기초 모델 것을 그대로 씁니다.
- RLHF
- reinforcement learning from human feedback. 사람의 피드백(좋아요 클릭, 오래 본 사진 같은)으로 모델을 더 훈련하는 기법입니다.
- reasoning
- 문제를 쪼개 단계별로 따져 보는 사고 과정입니다. 한국어로 inference와 reasoning을 둘 다 "추론"이라 옮기는 바람에 자주 헷갈립니다.
용어 지도 — 안쪽으로 갈수록 좁아진다
| 이름 | 한 줄 정의 | 예 |
|---|---|---|
| AI | 기계에 사람과 비슷한 능력을 주는 컴퓨터 과학의 한 분야 | 가장 바깥 원 |
| ML (머신러닝) | 데이터에서 자동으로 규칙을 학습하는 AI | 망막 사진을 정상·당뇨·녹내장으로 분류 |
| Deep learning | 층을 많이 쌓은 신경망을 쓰는 ML | 1장의 층 쌓기 |
| GenAI (생성형 AI) | 심층 신경망으로 텍스트·이미지 같은 새 콘텐츠를 만드는 ML. 출력이 훨씬 열려 있음(open-ended) | 모델 GPT-4, 제품 ChatGPT |
| LLM | 대량의 텍스트로 훈련한, 크기가 아주 큰 언어 모델 | ChatGPT를 구동하는 모델 |
스터디 노트는 이 관계를 AI > ML > DL ≥ GenAI ≥ LLM으로 적었습니다. ≥는 "거의 겹친다"는 뜻으로 읽으면 됩니다. GenAI라는 말은 모델·제품·연구 분야·소프트웨어 프레임워크를 통틀어 부를 때도 쓰입니다.
소프트웨어 스택은 두 벌 — 훈련과 실행
ML에는 두 가지 소프트웨어 스택이 필요합니다. 훈련 pipeline은 입력 데이터를 tensor로 바꾸고, 대량의 데이터로 가중치를 조정합니다.
inference 쪽은 훈련이 끝난 모델에 새 데이터를 넣어 출력을 만듭니다. 이 둘이 따로 있다는 것이 뒤에 나올 "훈련 pipeline"과 "서빙"이 갈라지는 이유입니다.
| 구분 | Inference (인퍼런스·실행) | Reasoning (리즈닝·논리적 사고) |
|---|---|---|
| 본질 | 결과 중심 — 이미 학습된 패턴으로 빠르게 답을 냄 | 과정 중심 — 문제를 분해하고 근거를 짚어 가는 생각 |
| 목적 | 새 데이터에 대한 예측·응답 생성 | 복잡한 문제 해결, 단계별 검증, 전략 수립 |
| 속도 | 매우 빠름 (단일 연산 경로) | 느림 (내부 생각 단계가 여러 번) |
| 사례 | 이미지 분류, 챗봇의 즉각 답변 | 수학 문제 풀이, 코딩, 논리적 증명 |
비유 먼저 — 운전 연수와 실제 운전
training은 운전 연수입니다. 실수할 때마다 강사가 바로잡아 주고, 그때마다 몸에 밴 습관(가중치)이 조금씩 바뀝니다.
inference는 혼자 하는 실제 운전입니다. 배운 대로 움직일 뿐, 운전하는 그 순간에 습관이 바뀌지는 않습니다.
fine-tuning은 이미 운전을 할 줄 아는 사람이 화물차 연수만 따로 받는 것입니다. 핸들 감각(앞쪽 층)은 그대로 두고, 화물차에 필요한 부분(뒤쪽 층과 새 출력층)만 새로 익힙니다.
숫자로 한 번 — 가중치는 몇 개나 될까
층 하나의 가중치 수는 "들어오는 값 수 × 나가는 값 수"에, 나가는 값마다 하나씩 붙는 편향(bias)을 더한 만큼입니다. 작은 층부터 세어 봅니다.
3 × 2 = 6 + 편향 2 = 8개
── 그림 2의 작은 신경망 (입력 28×28 = 784픽셀) ──
층 1: 784 × 256 + 256 = 200,960
층 2: 256 × 128 + 128 = 32,896
층 3: 128 × 64 + 64 = 8,256
새 출력층(정상·당뇨·녹내장 3개): 64 × 3 + 3 = 195
합계 242,307개 ── 층 1~3을 얼리면 갱신할 것은 195개뿐
원본 책은 "사진을 잘 분류하려면 가중치가 수백만~수십억 개이고, 그런 모델을 처음부터 훈련하려면 대략 그만큼의 예시 데이터가 필요하다"고 설명합니다. 그래서 실무에서는 기초 모델을 가져와 일부만 fine-tuning합니다. 결과 모델은 해결하려는 문제에 맞춘 새 출력층이 붙은 모양이 됩니다.
fine-tuning — 몇 층을 얼릴까
↔ 슬라이더 · 모드 버튼※ 주: 층 크기는 설명용으로 고른 작은 신경망(입력 784 = 28×28) · "필요한 예시 규모 ≈ 갱신할 가중치 수"는 원본 책(『그림으로 배우는 생성형 AI』)의 어림셈 — 실측 아님
모델의 일생 — 사전 훈련 → fine-tuning → inference
- 사전 훈련 (pre-training) 레이블이 없는 대량의 데이터로 범용 모델을 훈련합니다. 대규모 연산과 높은 비용이 듭니다. 결과물이 foundation model입니다.
- fine-tuning foundation model의 앞쪽 층을 얼리고, 내 데이터(수백 장 수준의 소규모)로 뒤쪽 층과 새 출력층만 훈련합니다. LLM이라면 클래스 레이블이 붙은 데이터로 분류기를, 지시(instruction) 데이터로 개인 비서·채팅 모델을 만듭니다.
- inference 배포된 모델에 처음 보는 입력을 넣어 답을 받습니다. 사용자의 피드백(좋아요 클릭 같은 명시적 피드백, 오래 보기 같은 암묵적 피드백)은 RLHF로 다음 훈련에 다시 쓰입니다.
LLM을 처음부터 만드는 3단계 (『밑바닥부터 만들면서 배우는 LLM』)
1단계 LLM 만들기 — 데이터 준비·샘플링, 어텐션 메커니즘, LLM 구조를 구현합니다.
2단계 foundation model — 레이블 없는 데이터로 사전 훈련합니다. 훈련 반복, 모델 평가, 사전 훈련된 가중치 불러오기가 여기 속합니다.
3단계 fine-tuning — 클래스 레이블 데이터셋으로 분류기를, 지시 데이터셋으로 개인 비서를 만듭니다.
머신러닝 활용 사례를 볼 때는 입력 · 데이터 · 모델 · 기법 · 출력 다섯 가지를 짚으면 정리됩니다. 고양이 사진 분류라면 입력은 이미지 픽셀, 데이터는 레이블 붙은 이미지, 모델은 CNN(합성곱 신경망), 기법은 기초 모델 fine-tuning, 출력은 "고양이·개·호랑이" 같은 제한된 단어 하나입니다.
원본 책은 실제 환경에서 AI가 사람들과 잘 어울려 동작하는지 검증하고, 성능을 지속적으로 모니터링하는 과정도 필수라고 말합니다. 이 문장이 다음 장부터 다룰 MLOps의 출발점입니다.
- 정의 — AI > ML > DL ≥ GenAI ≥ LLM. training은 가중치를 바꾸는 과정이고, inference는 바뀐 가중치를 그대로 쓰는 실행입니다.
- 성질 — 층의 가중치 수는 입력 수 × 출력 수 + 편향이라 금방 수십만~수십억 개가 됩니다. 그래서 큰 모델을 처음부터 훈련하는 대신 앞쪽 층을 얼리고 일부만 fine-tuning합니다.
- 쓰임 — 훈련과 실행이 서로 다른 스택이라는 점이 MLOps에서 훈련 pipeline과 서빙을 따로 설계하는 이유가 됩니다.
— 여기까지: 사전 지식(가중치, training과 inference). 다음부터 책 1장 — 모델 하나가 아니라 모델을 만드는 과정 전체를 봅니다 —
03ML 수명주기 — 실험 단계에서 프로덕션까지 (책 1.1절)
한 줄 요약: 실험 단계의 pipeline을 프로덕션에서 완전히 자동화하고, 끝에 배포·모니터링·재훈련 트리거를 붙이면 루프가 닫힙니다.
책 저자들은 첫 번째 배포로 마무리된 ML 프로젝트를 아직 본 적이 없다고 말합니다. 실험에서 좋은 점수를 받은 모델도 실제 데이터를 만나면 성능이 떨어지고, 그때마다 앞 단계로 돌아가야 합니다.
이 장에서는 책 1.1절의 두 그림(실험 단계, 개발·스테이징·프로덕션 단계)을 다시 그려, 단계들이 어떻게 하나의 반복 루프가 되는지 봅니다.
- 수명주기 (lifecycle)
- 문제 정의부터 데이터·훈련·평가·배포·모니터링·재훈련까지, 모델이 만들어지고 쓰이고 바뀌는 전체 과정입니다.
- 휴리스틱 (heuristic)
- 데이터로 학습하지 않고 사람이 정한 규칙(if/else, 임계값, 점수 공식)으로 푸는 방식입니다. 최적은 아니어도 "충분히 좋은 답"을 빠르고 싸게 냅니다.
- baseline
- ML 모델이 넘어야 할 기준 성능입니다. 보통 휴리스틱으로 먼저 만들어 잽니다.
- annotation · label
- 원본 데이터에 사람이 정답을 붙이는 작업이 annotation, 붙인 정답이 label입니다. 데이터(입력 X)와 레이블(정답 y)의 쌍으로 학습합니다.
- 합성 데이터 (synthetic data)
- 실제로 수집하지 않고, 실제 데이터의 통계적 특성과 패턴을 흉내 내 프로그램으로 만든 데이터입니다.
- 데이터 버전 관리 (data versioning) · 재현성 (reproducibility)
- 데이터에도 버전을 붙여 관리하는 것입니다. 같은 데이터와 코드로 다시 실행하면 같은 결과가 나오는 성질이 재현성입니다.
- artifact
- 실행이 남기는 결과물입니다. 훈련된 모델, 데이터, 그래프 파일 같은 것들입니다.
- 평가 (evaluation) · 검증 (validation)
- 평가는 훈련에 쓰지 않은 데이터로 지표를 재는 것, 여기서 검증은 비즈니스 담당자가 모델이 기대대로 동작하는지 확인하는 것입니다.
- pipeline orchestration
- 여러 단계를 정해진 순서와 조건으로 이어 실행·관리하는 것입니다. CI 파이프라인이 빌드·테스트·배포를 잇는 것과 같은 발상입니다.
- drift
- 운영 중 들어오는 데이터나 데이터와 정답의 관계가 훈련 때와 달라지는 현상입니다. 자세한 내용은 ②편에서 다룹니다.
비유 먼저 — 시험 주방과 매장
식당의 신메뉴는 시험 주방에서 나옵니다. 재료를 고르고, 만들어 보고, 맛을 보고, 마음에 안 들면 재료 단계로 돌아갑니다. 이것이 실험 단계입니다.
메뉴가 매장에 걸리면 일이 달라집니다. 매일 같은 맛으로 내야 하고, 손님 반응을 지켜보다 재료가 바뀌면 레시피를 다시 손봅니다. 이것이 개발·스테이징·프로덕션 단계입니다.
실험 단계 (책 1.1.1)
- 문제 정의 가장 먼저 "ML을 써야 하나?"를 묻습니다. 휴리스틱으로 충분할 때가 많고, 그 결과가 baseline이 됩니다. 비즈니스·제품 담당자와 기술 담당자가 충분히 고민한 끝에 ML이 최선이라고 판단했다면, 모델이 풀 문제를 명확히 정의합니다. 예: 신분증 이미지에서 ID 번호를 뽑는 OCR.
- 데이터 수집·준비 훈련·평가에 쓸 데이터를 어디서 확보할지 정합니다. OCR이라면 신분증 이미지가 필요하고, 사람이 ID 번호 주변에 경계 상자(bounding box)를 그리고 번호를 입력해 레이블을 붙입니다. 실제 데이터를 구하기 어려우면 합성 데이터를 만들고, 레이블이 준비되면 훈련·검증·테스트 데이터셋으로 나눕니다.
- 데이터 버전 관리 코드를 바꾸면 소프트웨어 동작이 바뀌듯, ML에서는 데이터를 바꿔도 동작이 바뀝니다. 그래서 데이터에도 버전이 필요합니다. 다만 이미지·CSV·pandas 데이터프레임처럼 형태가 제각각이라, Git처럼 모두가 쓰는 표준 도구는 아직 자리 잡지 못했습니다.
- 모델 훈련 데이터를 모델에 공급해 예측값과 실제값의 오차가 줄도록 가중치를 조정합니다. 데이터셋과 훈련 전략이 정해지면 자동화할 수 있고, 자동화하면 파라미터와 artifact가 추적되어 재현성이 생깁니다. 처음 접하는 사람은 훈련에 시간이 가장 많이 든다고 생각하지만, 저자들의 경험은 반대라고 합니다.
- 모델 평가 → 모델 검증 훈련 세트에 없는 데이터로 precision·recall·AUC 같은 지표를 잽니다(F1은 ②편에서 직접 계산해 봅니다). 통과하면 모델을 만든 팀과 다른 비즈니스 이해관계자가 기대대로 동작하는지 확인합니다.
책의 그림에는 화살표가 한 방향으로 그려져 있지만, 실제로는 거의 모든 단계에서 되돌아갑니다. 평가 지표가 기준에 못 미치면 다른 아키텍처를 검토하거나, 더 앞 단계로 가서 데이터 품질을 다시 봅니다. 그래서 처음부터 모든 단계를 하나의 오케스트레이션 pipeline으로 묶어 추적하기 어려운 실수를 줄입니다.
| 데이터셋 | 비유 | 용도 | 학습에 사용? | 통상 비율 |
|---|---|---|---|---|
| 훈련 (train) | 교과서·문제집 | 모델이 패턴을 학습 | 예 | 60~80% |
| 검증 (validation) | 모의고사 | 하이퍼파라미터 조정, 모델 선택 | 아니오 (간접 영향) | 10~20% |
| 테스트 (test) | 수능 | 최종 성능을 한 번 잼 | 절대 아니오 | 10~20% |
휴리스틱으로 충분한 예와 "ML을 쓸지" 판단하는 법 (스터디 노트)
예 — 스팸 필터 초기판: "무료 당첨", "대출 승인" 같은 키워드가 있거나 링크가 5개를 넘으면 스팸 · 이상 거래 1차 차단: 결제액이 평소 평균의 5배를 넘고 거주국이 아니면 검토 · 수요 예측 baseline: "내일 판매량 = 지난주 같은 요일 판매량" · 추천 초기판: 최근 7일 판매 상위 10개 · 이탈 알림: 30일간 로그인이 없으면 이탈 위험.
판단 ① 휴리스틱 baseline을 먼저 만들어 잰다.
판단 ② ML이 비즈니스 지표에서 의미 있게 좋아지는지 본다. 정확도 1~2%p로는 학습 pipeline·feature store·서빙·모니터링 운영 비용을 정당화하기 어렵다.
판단 ③ 규칙이 너무 많거나 복잡하고(이미지, 자연어), 시간에 따라 자주 바뀌고, 레이블 데이터가 충분하면 ML 쪽이다.
위양성 (false positive) — 실제로는 음성(정상)인데 양성(이상)으로 잘못 판정하는 오류. 사기 탐지는 위양성을 줄이면서 부정 거래를 빨리 잡아야 합니다.
개발·스테이징·프로덕션 단계 (책 1.1.2)
모양은 실험 단계와 비슷합니다. 다른 점은 셋입니다.
pipeline을 완전히 자동화하고, 끝에 모델 배포를 붙이고, 성능 모니터링이 다시 트리거를 당깁니다. 트리거는 CI나 프로그램 호출에서 오고, 결과물은 대개 REST API 형태의 ML 서비스입니다. 이 단계부터는 윤리적 제약, 보안, 확장성, 견고성, 실시간 성능이 우선순위에 올라옵니다.
- 모델 배포 — 추론을 수행하는 REST API를 붙이고, 도커로 컨테이너화해 AWS·GCP 같은 클라우드에 올립니다. 여기서 끝이 아니라 부하 테스트(load test), 자동 스케일링, 배포 버전 관리, 롤백 전략이 필요합니다. 일부 조직은 이 시점에 DevOps·MLOps 팀으로 일을 넘기지만, 저자들은 데이터 과학자도 계속 참여시키는 편이 낫다고 봅니다.
- 모델 모니터링 — 실제 데이터를 만나면 평가 때만큼 성능이 안 나오는 것이 보통입니다. 시스템·운영 지표(초당 요청 수 RPS, HTTP 상태 코드), ML 전용 지표(데이터·모델 drift), 비즈니스 지표(이탈률, 유지율)를 함께 봅니다.
- 모델 재훈련 — 가능한 한 자동화하고, 새 모델이 나오면 배포까지 자동으로 이어지게 합니다. 트리거는 고정 일정(예: 매월)이나 임계값(예: 대출 승인 건수가 갑자기 급감)입니다.
숫자로 한 번
평가 기준을 0.80으로 정했다고 합시다. 첫 평가가 0.74라면 기준 미달이라 데이터 수집·준비로 돌아가 데이터를 보강합니다.
2회차 평가 0.77 < 0.80 → 다시 되돌아감
3회차 평가 0.80 ≥ 0.80 → 검증으로 진행 ── 되돌아갈 때마다 +0.03은 설명용 가정
프로덕션에서도 같은 일이 일어납니다. 운영 지표가 임계값 아래로 내려가면 재훈련 트리거가 pipeline을 처음부터 다시 돌립니다.
실험 단계와 프로덕션 단계 — 기준 미달이면 되돌아간다
↔ 모드 · 슬라이더 · 재생※ 주: 점수·지표 값과 "되돌아갈 때마다 +0.03", "재훈련 후 운영 지표 0.86"은 흐름을 보여 주려는 예시 — 실측 아님 · 단계 구성은 책 그림 1.1·1.2를 다시 그림 · 남색 채움 = 지금, 남색 테두리 = 지나옴, 회색 점선 = 아직
- 정의 — ML 수명주기는 문제 정의 → 데이터 수집·준비 → 데이터 버전 관리 → 훈련 → 평가 → 검증, 그리고 배포 → 모니터링 → 재훈련으로 이어지는 반복 루프입니다.
- 성질 — 실험 단계에서 일부 자동화한 pipeline을 프로덕션에서 완전히 자동화하고, 기준 미달이나 지표 하락이 생기면 앞 단계로 되돌아갑니다.
- 쓰임 — 처음부터 단계를 하나의 오케스트레이션 pipeline으로 묶어 두면 재현성이 생기고, 재훈련과 배포를 자동으로 걸 수 있습니다.
— 여기까지: 수명주기는 되돌아가는 루프. 다음은 이 루프를 돌릴 사람의 역량과, 루프를 받쳐 주는 ML 플랫폼의 부품 —
04역량과 ML 플랫폼 — 루프를 받치는 부품들 (책 1.2·1.3절)
한 줄 요약: MLOps는 소프트웨어 엔지니어링·DevOps·데이터 과학이 겹치는 자리이고, ML 플랫폼은 수명주기의 각 단계를 받치는 도구 묶음입니다.
3장의 루프를 사람이 손으로 돌리면 실수가 끼어들고 기록이 빠집니다. 루프를 자동으로 돌리고 기록해 줄 부품이 필요합니다.
이 장에서는 ML 엔지니어에게 필요한 역량(책 1.2절)을 짧게 보고, 책 전체에서 계속 쓰는 플랫폼 지도와 도구(책 1.3절)를 따라갑니다.
- ML 플랫폼
- 수명주기의 필수 단계를 처리하는 도구와 인프라의 묶음입니다. 신뢰할 수 있는 ML 시스템의 토대입니다.
- Kubeflow · Kubeflow Pipelines (KFP)
- Kubernetes 위에서 도는 오픈소스 ML 플랫폼이 Kubeflow이고, 그 핵심 컴포넌트로 pipeline orchestration을 맡는 것이 KFP입니다. 수명주기의 각 단계가 pipeline component 하나가 됩니다.
- feature · feature store
- feature는 모델이 입력으로 받는 가공된 값입니다(예: 최근 7일 평균 결제액). feature store는 feature를 한 번 정의·계산·저장해 두고 훈련과 서빙이 같은 곳에서 가져다 쓰게 하는 소프트웨어입니다. 책은 Feast를 씁니다.
- offline store · online store
- feature store의 두 저장소입니다. offline은 훈련·배치 inference용 대량 과거 이력(느려도 됨), online은 실시간 서빙용 엔티티별 최신 값(밀리초 응답)입니다.
- training-serving skew
- 훈련할 때 계산한 feature와 서빙할 때 계산한 feature가 미묘하게 달라 성능이 떨어지는 현상입니다. 훈련-서빙 불일치(왜곡)라고도 합니다.
- entity · entity key
- feature가 누구(무엇)에 대한 값인지 가리키는 대상과 그 식별자입니다. 예를 들어 사용자(user_id = 42)입니다. feature store는 이 키로 값을 찾습니다.
- feature view · feature service (Feast)
- 한 원천에서 나온 feature 묶음의 정의가 feature view, 여러 feature view에서 모델 하나가 쓰는 feature를 골라 묶은 것이 feature service입니다. 둘 다 registry에 등록됩니다.
- registry · TTL
- Feast의 정의·메타데이터 카탈로그가 registry(feast apply로 갱신), historical 데이터셋을 만들 때 얼마나 과거까지 거슬러 볼지의 한계가 TTL입니다.
- materialize
- offline store의 이력에서 엔티티별 최신 값을 뽑아 online store로 주기적으로 복사하는 작업입니다.
- point-in-time 조회 · 데이터 누수 (leakage)
- 훈련 데이터의 각 행에 "그 행이 일어난 시점까지 알 수 있었던 값"만 붙이는 조회가 point-in-time입니다. 미래의 값이 섞여 들어가면 데이터 누수가 됩니다.
- experiment tracking · model registry
- 훈련 실행마다 파라미터·지표·artifact를 기록하는 것이 experiment tracking, 모델 버전을 모아 두고 staging에서 production으로 승격하는 저장소가 model registry입니다. 책은 둘 다 MLflow로 합니다.
- 하이퍼파라미터 (hyperparameter)
- 학습 전에 사람이 정하는 설정값입니다(학습률, 에폭 수, 배치 크기, 트리 깊이). 학습으로 얻는 가중치와는 다릅니다.
- LLMOps
- LLM 시스템을 운영하기 위해 MLOps에 벡터 데이터베이스, 가드레일(guardrail), 비용·프롬프트 관리 같은 부품을 더한 것입니다.
필요한 역량 (책 1.2절)
책 그림 1.3은 세 원이 겹친 그림입니다. 소프트웨어 엔지니어링, DevOps, 데이터 과학이 겹치는 가운데가 MLOps입니다. 처음엔 막막하게 느껴질 수 있지만, 저자들은 처음부터 모든 것을 알 필요는 없고 기술들이 어떻게 맞물리는지 이해하는 것이 중요하다고 말합니다.
- 소프트웨어 엔지니어링 — 간단하지 않은 소프트웨어를 여러 번 배포해 본 경험, 디버깅, 성능 문제를 찾아 해결하는 능력.
- ML·데이터 과학 이해 — 알고리즘 전문가이거나 역전파 세부까지 알 필요는 없습니다. TensorFlow·PyTorch·scikit-learn을 능숙하게 다루고, 낯선 프레임워크도 거리낌 없이 익히면 됩니다.
- 데이터 엔지니어링 — 실무자 대부분이 데이터 문제, 특히 양질의 훈련 데이터를 충분히 모으는 일이 가장 어렵다고 말합니다.
- 자동화와 실험 재현성 — 자동화는 실수를 줄이고 반복을 빠르게 합니다. 개발·스테이징·프로덕션에서 모델이 똑같이 동작하려면 재현성이 필요하고, 규제·감사 대상이라면 더 결정적입니다.
코끼리를 먹는 방법은 한 번에 한 입씩입니다. 책은 Kubernetes 기초 → ML 플랫폼 구축 → 그 위의 ML 시스템 순으로 쪼개 갑니다.
비유 먼저 — 놀이공원 안내 지도
놀이공원 안내 지도에는 놀이기구마다 번호가, 화장실·매표소 같은 편의시설마다 기호가 붙어 있습니다. 책의 플랫폼 지도(책 그림 1.4)도 그렇습니다. 데이터가 흐르는 단계에는 숫자(1~9), 그 단계를 받치는 인프라에는 알파벳(A~E)이 붙어 있고, 책은 장마다 이 지도에서 지금 다루는 블록을 강조해 보여 줍니다.
ML 플랫폼 지도 — 숫자는 데이터 흐름, 알파벳은 인프라
↔ 모드 · 슬라이더※ 주: 책 그림 1.4·1.5를 단순화해 다시 그림 · 남색 채움 = 지금 단계, 남색 테두리 = 지나온 단계, 회색 점선 = 아직 · Evidently·BentoML은 책 2장(②편)에서 소개하는 도구
책에서 쓰는 도구
저자들은 직접 써서 효과를 본, 커뮤니티 지원이 탄탄한 오픈소스를 골랐습니다. SageMaker(AWS)나 Vertex AI(GCP) 같은 상용 플랫폼이 있어도, 오픈소스 부품을 직접 조립해 보는 경험이 한계에 부딪혔을 때 넘는 힘이 된다는 것이 책의 입장입니다.
- pipeline 자동화 — Kubeflow Pipelines: 각 단계가 pipeline component이고, 앞 컴포넌트의 데이터를 받아 일을 마친 뒤 다음 컴포넌트로 넘깁니다(책 그림 1.6). Kubeflow는 feature store를 기본 제공하지 않아 책은 플랫폼을 확장해 갑니다.
- feature store — Feast: 내부에 feature server(REST·gRPC로 제공), feature registry(목록), feature storage(저장)를 둡니다. offline·online 두 모드로 feature를 내주어 training-serving skew를 막습니다(책 그림 1.7).
- model registry — MLflow: 실험 추적과 모델 저장을 함께 맡습니다. 모델을 staging에서 production으로 승격하고, ML 서비스가 registry에서 바로 모델을 받게 할 수도 있습니다(책 그림 1.8).
- 모델 배포 — CI/CD + Kubernetes: 트리거가 오면 CI/CD가 도커 이미지를 빌드해 컨테이너 레지스트리에 push하고, 그 이미지를 가리키는 Kubernetes 매니페스트를 적용해 ML 서비스를 띄웁니다(책 그림 1.9). 이식성·확장성·성능(GPU 여부)·신뢰성을 고려하는 엔지니어링 작업입니다.
| 훈련 실행의 출력물 | 무엇인가 | 예 | 왜 기록하나 |
|---|---|---|---|
| 모델 (가중치) | 학습이 끝난 결과물 파일 | model.pkl, best.pt | 배포·재사용의 본체 |
| 하이퍼파라미터 | 학습 전에 사람이 정한 설정값 | 학습률 0.01, 트리 깊이 6 | 같은 설정으로 재실행 |
| 플롯 이미지 | 학습 과정·결과를 그린 그림 | 손실 곡선, 혼동 행렬 | 사람이 상태를 빠르게 파악 |
| 메타데이터 | 실행을 설명하는 부가 정보 | 데이터 버전, 코드 커밋, 실행 시각, 환경 | 어떤 조건에서 나왔는지 추적 |
이 네 가지를 매 실행마다 함께 남겨야 "지난달 그 좋았던 모델"을 다시 만들거나 비교할 수 있습니다. 모델 파일만 있으면 "이 모델은 어디서 왔지?"에 답할 수 없습니다.
가중치 · 파라미터 · 하이퍼파라미터 비교 (스터디 노트)
가중치는 입력에 곱하는 계수, 파라미터는 가중치에 편향(bias)까지 포함해 학습 중에 갱신되는 모든 값입니다. 실무에서는 둘을 거의 같은 뜻으로 섞어 씁니다. 하이퍼파라미터는 파라미터가 아니라, "파라미터를 어떻게 학습할지" 정하는 바깥쪽 설정이고 학습 시작 전에 고정됩니다.
요리로 치면 하이퍼파라미터는 불 세기와 조리 시간, 가중치는 맛을 보며 조절하다 마지막에 굳어진 양념 배합입니다. LLM 모델 파일도 가중치, 토크나이저, config.json으로 나뉘어 저장됩니다.
숫자로 한 번 — feature store가 막는 사고
사기 탐지 모델이 feature로 "최근 7일 평균 결제액"을 쓰고, "오늘 결제액이 평균의 3배 이상이면 의심"으로 판정한다고 합시다. 데이터 과학자는 노트북에서 거래일 전 7일(D-7 ~ D-1)로 계산했는데, 서빙 쪽 엔지니어가 다시 구현하면서 오늘을 포함한 7일(D-6 ~ 오늘)로 짰습니다.
훈련 때 정의: (4+5+3+6+4+5+3) ÷ 7 = 30 ÷ 7 ≈ 4.29 → 14 ÷ 4.29 ≈ 3.27배 → 의심
서빙 때 구현: (5+3+6+4+5+3+14) ÷ 7 = 40 ÷ 7 ≈ 5.71 → 14 ÷ 5.71 ≈ 2.45배 → 정상 ── 같은 거래인데 판정이 다름
코드 한 줄 차이로 모델이 훈련 때 본 적 없는 값을 받게 된 것입니다. feature store는 feature 정의를 하나로 두고 훈련(offline)과 서빙(online)이 같은 정의에서 값을 가져가게 해 이 차이를 없앱니다.
feature store 켜고 끄기 — training-serving skew
↔ 슬라이더 · 토글※ 주: 결제액과 "평균의 3배 이상이면 의심" 규칙은 설명용 예시 · feature("최근 7일 평균 결제액")와 skew 사례는 스터디 노트의 feature store 설명에서 가져옴
feature store 더 들여다보기 — 책 4장 미리 보기
책은 1장에서 feature store를 소개만 하고, 테이블 데이터를 쓰는 영화 추천 프로젝트(책 4장)에서 Feast로 직접 다룹니다. 여기서는 스터디 노트를 바탕으로, 실습 전에 잡아 두면 좋은 그림을 먼저 그립니다.
비유 — feature store는 식당의 손질된 재료 보관소입니다. 요리사(모델)가 매번 원물을 손질하지 않고 손질된 재료를 꺼내 쓰며, 훈련 주방과 서빙 주방이 같은 재료를 씁니다.
없으면 생기는 일 — 스터디 노트는 세 가지를 꼽습니다.
- 데이터 과학자가 훈련용 feature 계산 코드를 노트북에 짭니다.
- 엔지니어가 서빙용으로 같은 로직을 다시 구현하다 미묘하게 달라집니다. 그림 5의 skew가 이것입니다.
- 다른 팀이 같은 feature를 또 계산합니다.
| 구분 | feature store 없음 | feature store 사용 |
|---|---|---|
| feature 계산 코드 | 훈련용·서빙용을 따로 작성 | 한 번 정의해 양쪽에서 재사용 |
| training-serving skew | 생기기 쉬움 | 줄어듦 |
| 팀 간 재사용 | 복붙, 중복 계산 | 카탈로그(registry)에서 찾아 공유 |
| 과거 시점 재현 | 직접 구현해야 함 | point-in-time 조회 지원 |
두 저장소 — 대부분의 feature store는 하나의 feature 정의 아래 저장소를 둘 둡니다. offline 이력에서 엔티티별 최신 값을 주기적으로 online으로 복사(materialize)해 둘을 맞춥니다.
| 구분 | offline store | online store |
|---|---|---|
| 목적 | 모델 훈련·배치 inference용 대량 조회 | 실시간 서빙용 빠른 조회 |
| 데이터 양 | 과거 전체 이력 (대용량) | 엔티티별 최신 값만 |
| 응답 속도 | 느려도 됨 (분~초) | 밀리초 단위 |
| 저장소 예 | Parquet, S3, BigQuery | Redis, DynamoDB |
| 조회 방식 | 특정 시점 기준 과거 값 (point-in-time) | entity key로 최신 값 |
안쪽 부품 (책 그림 1.7) — 배치·스트리밍 원천 데이터가 변환을 거쳐 feature store로 들어옵니다. 안에는 feature를 REST·gRPC로 내주는 feature server, 쓸 수 있는 feature 목록인 feature registry, 실제로 저장하는 feature storage가 있습니다. 밖으로는 offline feature(훈련, 배치 inference)와 online feature(실시간 inference) 두 갈래로 나갑니다.
핵심 기능 — point-in-time 조회 — 과거 데이터로 훈련할 때는 그 행이 일어난 시점에 알 수 있었던 값만 써야 합니다. 3월 1일 거래의 사기 여부를 학습하는데 그 뒤에 계산된 "최근 7일 평균"을 붙이면 미래 정보가 새어 들어갑니다. feature store는 각 행의 타임스탬프를 기준으로 그때의 값을 찾아 붙여 이를 막습니다.
point-in-time: 3/1 0시 기준 7일 평균(2/22~2/28) = 30 ÷ 7 ≈ 4.29 → 14 ÷ 4.29 ≈ 3.27배 → 훈련 행 "3.27배 → 사기"
최신 값으로 붙이면: 3/8 0시 기준 7일 평균(3/1~3/7) = (14+4+5+6+3+4+5) ÷ 7 = 41 ÷ 7 ≈ 5.86 → 14 ÷ 5.86 ≈ 2.39배 ── 3월 1일 거래 자신과 그 뒤의 결제가 평균에 섞임
두 번째 방식으로 만든 훈련 데이터는 서빙 때 결코 볼 수 없는 값으로 채워집니다. 훈련 때 본 값과 서빙 때 받는 값의 기준이 달라져, 그림 5와 같은 종류의 불일치가 생깁니다.
point-in-time 조회 — 훈련 데이터 한 줄에 어떤 값을 붙이나
↔ 조회 방식 버튼 · 슬라이더※ 주: 결제액·날짜는 그림 5와 같은 설명용 예시 · feature 값 = 그날 0시 기준 직전 7일 평균 · "그 뒤에 계산된 평균을 쓰면 누수" 사례는 스터디 노트의 point-in-time 설명
Feast의 부품 — 책 4장 실습 전에 이름 익히기
책 4장에서 Feast를 쓰면 낯선 이름이 한꺼번에 나옵니다. Feast 공식 문서 기준으로 부품을 먼저 정리해 두면, 실습 코드의 각 줄이 무엇을 하는지 읽힙니다.
| 부품 | 하는 일 | 이 글의 예 |
|---|---|---|
| Entity · join key | feature가 누구에 대한 값인지와 그 기본 키입니다. 훈련 때는 키 + 시각으로, 서빙 때는 키만으로 값을 찾습니다. | user (join key user_id) |
| Data source | feature의 원천입니다. 이벤트가 일어난 시각(event timestamp) 열이 있어야 point-in-time 조회가 됩니다. | payments.parquet |
| Feature view | 한 원천에서 나온 시계열 feature 묶음입니다. 이름·entity·schema·source·TTL을 갖고, 타임스탬프가 없는 데이터에는 쓰지 못합니다. | user_payment_7d |
| TTL | historical 데이터셋을 만들 때 얼마나 과거까지 거슬러 볼지의 한계입니다. | 30일 |
| Feature service | 여러 feature view에서 고른 feature 묶음으로, 보통 모델 버전마다 하나 둡니다. apply해도 실제 서비스가 배포되지는 않습니다. | fraud_model_v1 |
| Registry | 모든 정의와 메타데이터의 카탈로그입니다. feast apply로 갱신되고, materialize 진행 상황도 여기에 남습니다. | 로컬 파일·S3·GCS |
| Offline · online store | 앞의 표와 같습니다. 훈련용 전체 이력과 서빙용 최신 값입니다. | Parquet / Redis 등 |
흐름은 네 동작입니다. feast apply로 정의를 registry에 올리고, 훈련 때는 get_historical_features가 entity와 시각이 적힌 표(entity dataframe)에 그때의 값을 붙입니다(그림 6의 point-in-time). materialize가 offline의 최신 값을 online으로 옮겨 두면, 서빙 때 get_online_features가 키 하나로 값을 꺼냅니다.
materialize는 두 가지입니다. feast materialize는 시작·끝 시각을 매번 직접 주는 무상태 명령이라 Airflow처럼 상태를 기억하는 스케줄러에서 돌리기 좋습니다. feast materialize-incremental은 끝 시각만 주면 feature view마다 지난번 끝 시점을 registry에서 찾아 그 이후만 복사합니다.
그래서 online store는 마지막 materialize 시점만큼만 최신입니다. 스케줄을 놓치면 서빙은 며칠 전 값으로 판정하게 되는데, 이는 그림 5의 skew(계산 방식 차이)와는 다른 종류의 어긋남(값의 신선도)입니다.
10일에 다시 실행 → 지난 끝 시점(5일) 이후인 6~10일만 복사 ── registry의 끝 시점이 10일로 바뀜
그 사이 6~9일에 서빙했다면 → online 값은 계속 5일 값
feature service는 ②편의 lineage와도 이어집니다. 모델 버전마다 feature service를 하나씩 두면 "이 모델은 어떤 feature 정의로 학습했나"가 registry에 남아, lineage 사슬의 feature 고리가 됩니다.
Feast — online store는 마지막 materialize만큼만 최신이다
↔ 날짜 슬라이더 · materialize 버튼 · 스케줄러※ 주: 평균 결제액·날짜는 설명용 예시 · 부품 이름과 materialize-incremental 동작은 Feast 공식 문서 기준 · 남색 채움 = 오늘, 옅은 남색 칸 = online에 복사된 날, 흰 칸 = 아직 offline에만 있는 날
Feast에서는 어떻게 생겼나 — 모양만 보는 예
Feast에서는 feature를 FeatureView로 한 번 정의하고, 훈련용은 get_historical_features(point-in-time 조회), 서빙용은 get_online_features로 꺼냅니다. 그 사이를 materialize가 잇습니다.
아래 코드는 구조를 보여 주려는 예이고, 책 4장 실습 코드와는 다를 수 있습니다.
from datetime import datetime, timedelta
from feast import Entity, FeatureStore, FeatureView, Field, FileSource
from feast.types import Float32
user = Entity(name="user", join_keys=["user_id"]) # entity key
payments = FileSource(path="payments.parquet", timestamp_field="event_timestamp")
avg_7d = FeatureView(name="user_payment_7d", entities=[user], ttl=timedelta(days=30),
schema=[Field(name="avg_amount_7d", dtype=Float32)], source=payments)
store = FeatureStore(repo_path=".")
# 훈련: entity_df의 행마다 그 행의 event_timestamp 시점 값을 붙인다 (offline · point-in-time)
train_df = store.get_historical_features(entity_df=entity_df,
features=["user_payment_7d:avg_amount_7d"]).to_df()
# offline → online 복사
store.materialize_incremental(end_date=datetime.now())
# 서빙: online store에서 최신 값 하나를 밀리초로 조회
store.get_online_features(features=["user_payment_7d:avg_amount_7d"],
entity_rows=[{"user_id": 42}]).to_dict()
스터디 노트에 따르면 책 저장소의 chapters/ch04-feast/에 정의(feast/)와 조회 예제(feast_retrieval/의 retrieve_features.py, retrieve_online_features.py)가 있는 것으로 보입니다. 실습 때 확인할 부분입니다.
앞으로의 전망 — MLOps에서 LLMOps로
책 그림 1.5는 기존 MLOps 부품(왼쪽)이 그대로 핵심을 맡고, 오른쪽에 LLMOps 확장 부품이 붙는 모습입니다. 시맨틱 검색(semantic search)을 위한 벡터 데이터베이스, LLM 안전을 위한 가드레일, 비용 최적화와 프롬프트 관리 도구가 더해집니다(책 12·13장). 지금 익히는 pipeline orchestration, 모델 배포, 모니터링은 LLMOps에서도 그대로 쓰입니다.
책의 아키텍처는 저자들의 조직에서 잘 통한 것일 뿐 정답이 아닙니다. 도구도 출발점으로 보고, 며칠 동안 개념 증명(PoC) 수준으로 직접 써 보며 맞는지 판단하라고 권합니다. 초기에 실험해 보면 나중에 치명적인 문제로 커질 한계를 미리 발견할 수 있습니다.
- 정의 — MLOps는 소프트웨어 엔지니어링·DevOps·데이터 과학이 겹치는 자리이고, ML 플랫폼은 수명주기 단계를 받치는 도구·인프라 묶음입니다.
- 구조 — 플랫폼 지도는 데이터 흐름(1~9)과 인프라(A~E)로 나뉘며, 책은 Kubernetes 위에 KFP(A)·MLflow(B·C)·Feast(D)·모델 서빙(E)을 붙여 갑니다.
- 쓰임 — feature store는 정의 하나로 훈련(offline)과 서빙(online)에 같은 값을 주고, 훈련에는 그 시점까지의 값만 붙여 skew와 누수를 막습니다. experiment tracking과 model registry는 재현성과 승격·롤백을 맡습니다.
— 여기까지: 역량과 플랫폼 부품. 다음은 이 플랫폼 위에서 책이 진행할 세 가지 프로젝트 —
05세 가지 프로젝트 — 같은 뼈대, 다른 데이터 (책 1.4절)
한 줄 요약: 신분증 OCR, 영화 추천, RAG 문서 도우미는 데이터 모달리티가 다를 뿐, 같은 MLOps 뼈대 위에서 같은 단계를 밟습니다.
한 종류의 프로젝트만 보면 그 도메인에만 통하는 요령과 MLOps의 원칙이 구분되지 않습니다.
이 장에서는 세 프로젝트를 같은 단계 표에 나란히 놓고, 무엇이 같고 무엇이 바뀌는지 봅니다. 책 2장에서 나오는 도구 이름도 미리 채워 두었습니다.
- 모달리티 (modality)
- 데이터의 형태입니다. 표(정형) 데이터, 이미지, 텍스트, 음성, 시계열처럼 형태마다 저장·레이블·전처리·평가 방법이 달라집니다.
- OCR · 객체 탐지 (object detection)
- OCR은 이미지 속 글자를 읽는 기술, 객체 탐지는 이미지에서 무엇이 어디에 있는지 상자로 찾는 일입니다.
- YOLO · COCO
- YOLO(You Only Look Once)는 널리 쓰이는 객체 탐지 모델이고, COCO는 YOLO가 기본으로 훈련된 데이터셋(91가지 객체)입니다. COCO에는 신분증과 여권이 없습니다.
- 테이블 형식 데이터 (tabular data)
- 행과 열로 된 표 데이터입니다. 이미 숫자이거나 숫자 feature로 바꾸기 쉬워 실습에 유리합니다.
- RAG · embedding
- RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 질문과 관련된 문서를 먼저 찾아 LLM 프롬프트에 붙여 답하게 하는 방식입니다. 문서를 의미가 담긴 숫자 벡터로 바꾸는 것이 embedding입니다.
- one-hot encoding · 증강 (augmentation)
- 범주 하나를 0/1 열 여러 개로 펼치는 인코딩이 one-hot, 뒤집기·회전·밝기 변화처럼 정답은 그대로 둔 채 데이터를 변형해 늘리는 일이 증강입니다.
- RMSE · IoU · mAP
- 예측값과 실제값 차이를 제곱해 평균 낸 뒤 제곱근을 씌운 값(작을수록 좋음)이 RMSE, 예측 상자와 정답 상자가 겹친 넓이 ÷ 합친 넓이가 IoU, 여러 클래스·기준에 걸친 탐지 정확도의 평균이 mAP입니다.
- chunking
- 긴 문서를 검색하기 좋은 크기의 조각(chunk)으로 나누는 일입니다. RAG는 chunk마다 embedding을 만들어 찾습니다.
- observability (관측 가능성)
- 시스템 내부에서 무슨 일이 일어나는지 로그·지표·추적으로 들여다볼 수 있는 정도입니다.
비유 먼저 — 같은 주방, 다른 재료
같은 주방 설비로 한식, 양식, 디저트를 만든다고 해 봅시다. 재료가 다르면 손질법은 달라지지만, 냉장고·화구·위생 점검 절차는 같습니다. 모달리티가 재료이고, MLOps 뼈대가 주방 설비와 절차입니다.
세 프로젝트
- 프로젝트 1 · 신분증 OCR (이미지) — 신분증 탐지라는 문제 정의에서 출발해 데이터셋을 만들고, 이미지 탐지기를 학습시킵니다. 오픈소스 라이브러리로 초기 구현을 한 뒤 레이블 데이터셋으로 fine-tuning하고, 서비스로 배포합니다.
- 프로젝트 2 · 영화 추천 (표) — 단계는 같지만 테이블 형식 데이터에는 고유한 특성과 도구가 있습니다. feature store, drift 탐지, 모델 테스트, observability를 설명하기에 더 알맞습니다.
- 프로젝트 3 · RAG 문서 도우미 DakkaBot (텍스트) — 엔지니어가 사내 문서를 자연어로 묻게 해 주는 도우미입니다. 문서 수집 → 벡터 embedding → RAG pipeline을 만든 뒤 안전 가드레일, 비용 최적화, 시맨틱 평가로 확장합니다.
세 프로젝트 모두 데이터 준비부터 모니터링, 마지막 모델 폐기까지 수명주기 전체를 밟습니다. 일부 도구(예: Kubeflow Pipelines)는 프로젝트를 건너 재사용하고, 때로는 앞서 쓴 도구의 한계를 짚고 대안을 씁니다.
ML 프로젝트는 선형으로 진행되는 경우가 드물고 대부분 반복됩니다. 훈련 중 성능이 안 나오면 데이터 준비로 돌아갑니다.
요구사항도 시간에 따라 바뀌어 다른 도구와 기법을 찾게 됩니다. 그래도 핵심 개념은 유형·도메인·단계를 막론하고 쓰입니다.
모달리티 — 컴퓨터에게는 전부 숫자, 놓인 모양이 다를 뿐
모달리티(modality)는 데이터의 "종류" 또는 "형태"입니다. 사람이 세상을 눈·귀·글로 받아들이는 방식이 다르듯, 데이터도 표·이미지·텍스트·음성처럼 담긴 형태가 다르고, 형태마다 컴퓨터가 읽는 방법과 모델이 배우는 방법이 다릅니다.
| 모달리티 | 예시 | 컴퓨터가 보는 형태 | 다룰 때의 어려움 |
|---|---|---|---|
| 표 (정형) | 거래 내역, 평점 | 행·열의 숫자와 범주 | 결측치, 범주 인코딩, feature 설계 |
| 이미지 | 신분증 사진 | 픽셀 숫자 배열 | 용량이 큼, 조명·각도 다양성, 박스 annotation |
| 텍스트 | 문서, 질문, 챗봇 대화 | 토큰(단어 조각) 숫자 열 | 문서 분할, 의미 검색, 정답 평가가 모호 |
| 음성 | 통화 녹음 | 시간별 파형 | 잡음, 화자·억양 차이 |
| 시계열 | 센서 값, 주가 | 시간 순서의 숫자열 | 시간 누수, 계절성 |
결국 컴퓨터에게는 전부 숫자입니다. 다만 숫자가 놓인 모양이 달라서, 표는 칸마다 뜻이 정해져 있고, 이미지는 픽셀 격자이고, 텍스트는 순서가 중요한 단어 조각의 열입니다.
그래서 ②편에서 볼 데이터 수집·큐레이션·annotation·분할도 모달리티마다 구체적인 방법이 갈립니다. 같은 질문 "레이블은 어떻게 붙이나?"에도 답이 다릅니다.
| 구분 | 표 (영화 추천) | 이미지 (신분증 OCR) | 텍스트 (RAG) |
|---|---|---|---|
| 저장 | DB 테이블, CSV, Parquet | 이미지 파일 (PNG, JPG) | 문서 파일, 벡터 DB |
| 레이블 | 컬럼 하나가 정답 | 박스 그리기, 분류 라벨 | 정답이 정해지지 않은 경우가 많음 |
| 전처리 | 결측 처리, 인코딩 | 크기 조정, 정규화, 증강 | chunking, embedding |
| 평가 | 정확도, F1, RMSE | mAP, IoU | 검색 정확도, 답변 충실도 |
책이 서로 다른 모달리티의 프로젝트 셋을 고른 이유가 여기 있습니다. 같은 원칙(품질, 편향 방지, lineage)이 형태에 따라 어떻게 다르게 적용되고 어떤 어려움이 생기는지 보여 주려는 것입니다.
숫자로 한 번 — 샘플 한 건은 숫자 몇 개인가
신분증 사진 한 장 (224×224, RGB): 224 × 224 × 3 = 150,528개
문서 chunk 하나: 토큰 수만큼의 ID → embedding하면 고정 길이 벡터 하나 ── 예: 768개 숫자
같은 "한 건"이라도 숫자 개수가 수만 배 차이 납니다. 이미지가 저장 공간과 GPU를 많이 쓰고, 표 데이터가 실습에 유리한 이유입니다.
모달리티 — 같은 질문, 모달리티마다 다른 답
↔ 모달리티 · 단계 버튼※ 주: 표·픽셀·토큰 값은 설명용 예시 · 모달리티별 저장·레이블·전처리·평가는 스터디 노트의 데이터 모달리티 설명 · 픽셀 밝기는 회색 명도 단계로 표시
숫자로 한 번 — 원본 수치 읽기
MovieLens 1M (영화 추천): 평점 1,000,000건 ÷ 사용자 6,000명 ≈ 사용자당 약 167건 ── 영화는 약 3,000편
COCO (YOLO 기본 훈련): 91가지 객체 ── 신분증·여권은 없음 → fine-tuning이 필요한 이유
세 프로젝트를 같은 단계 표에 놓기
↔ 프로젝트 버튼 · 단계 슬라이더※ 주: 칸 내용은 책 1.4절과 2.1절(②편)에서 모음 · 데이터셋 수치는 원본 값 그대로
- 정의 — 책의 세 프로젝트는 이미지(신분증 OCR), 표(영화 추천), 텍스트(RAG 도우미) 모달리티를 하나씩 맡습니다.
- 성질 — 문제 정의 → 데이터 → 모델 → 평가 → 서빙 → 모니터링이라는 뼈대는 같고, 모달리티에 따라 저장·레이블·전처리·평가 방식과 일부 도구가 바뀝니다.
- 쓰임 — 내 프로젝트가 셋과 달라도, 같은 뼈대에 맞춰 놓고 보면 어떤 단계에 어떤 부품이 필요한지 정리됩니다.
마치며
처음 질문은 "모델을 학습시킨다는 건 무엇이 바뀐다는 말일까"였습니다. 답은 가중치였고, MLOps는 그 가중치가 데이터·코드·설정과 함께 계속 바뀐다는 사실을 다루는 일이었습니다. 책 1장은 그 변화를 감당할 루프(수명주기)와, 루프를 받칠 부품(ML 플랫폼)을 먼저 펼쳐 놓은 장입니다.
- 모델 파일 = 학습으로 찾은 가중치. 같은 가중치를 다시 만들 수 있어야 재현성이 있습니다.
- ML은 첫 배포로 끝나지 않습니다. 기준 미달과 지표 하락이 앞 단계로 되돌아가는 길을 만듭니다.
- 플랫폼 지도의 숫자(데이터 흐름)와 알파벳(인프라)을 기억해 두면 책의 다음 장들이 어느 블록 이야기인지 바로 보입니다.
댓글로 알려 주시면 고치겠습니다. 참고한 자료는 MLOps 스터디 1주차 정리 노트, 원서 Machine Learning Platform Engineering(Manning) 1장, [bRd 3D] "인공지능의 작동방식" 영상, 『그림으로 배우는 생성형 AI』, 『밑바닥부터 만들면서 배우는 LLM』입니다.
'AI > [MLOPS] ML Platform Engineering 스터디' 카테고리의 다른 글
| [1주차-MLOPS] CH3. K8s CI/CD (2026.10.18) (0) | 2026.10.25 |
|---|---|
| [1주차-MLOPS] CH2. MLOps란 무엇인가 (2026.10.18) (0) | 2026.10.25 |