[1주차-MLOPS] CH2. MLOps란 무엇인가 (2026.10.18)

MLOps 1주차 ② 책 2장 들어가며 1 문제·데이터·EDA 2 모델링~유지보수 3 왜 어려운가 4 DevOps vs MLOps 5 성숙도 마치며

MLOps 스터디 1주차 · 책 2장

모델이 아니라 루프를 만든다.

책 2장은 ①편에서 본 수명주기를 "시간이 지나며 계속 도는 폐쇄 루프"로 다시 보고, 단계마다 무엇을 묻고 무엇을 기록해야 하는지 짚습니다. 그다음 MLOps가 어려운 이유, DevOps와 다른 점, 조직의 성숙도 수준까지 이어 갑니다.

들어가며

읽는 시간 약 45분 대상 K8s·CI/CD는 익숙하고 ML은 처음인 개발자 사전 지식 ①편(가중치, 수명주기, ML 플랫폼) 정도 그림 9개 · 전부 조작 가능

스터디 자료 출처

이 글은 CloudNet@ 커뮤니티의 Machine Learning Platform Engineering Study 자료입니다.

책 출처: MLOps/LLMOps 이해를 위한 '머신러닝 플랫폼 엔지니어링(번역서)' 책 기반 스터디 — Book

책 2장은 분량에 비해 낯선 말이 많습니다. lineage, curation, holdout, drift처럼 비슷해 보이는 개념이 한 절에 몰려 나와서, 스터디 노트에도 풀어 쓴 설명 토글을 가장 많이 단 장입니다. 읽다 보면 "그래서 무엇을 기록해야 하고, 무엇을 지켜봐야 하지?"가 흐려집니다.

그래서 이 글은 책 2장을 원본 순서대로 따라가면서, 각 단계에서 무엇을 묻고 무엇을 남기는지에 초점을 맞춥니다. 2.1절(반복 루프)은 길어서 앞부분(1장)과 뒷부분(2장)으로 나눴습니다. 반대로 도구 설치와 코드 실습(Feast·MLflow·BentoML은 책 4장 이후), 지표의 수학적 유도는 다루지 않습니다.

결론부터 세 줄

1. ML의 가치는 모델 하나가 아니라 시간이 지나며 개선되는 폐쇄 루프에서 나옵니다. 모델·데이터·하이퍼파라미터는 루프의 일시적인 부품입니다.
2. 루프를 버티게 하는 공통 줄기는 lineage(이 모델이 어떤 데이터·코드·설정에서 나왔는지)와 자동화입니다.
3. MLOps가 DevOps와 갈리는 지점은 데이터입니다. 코드가 그대로여도 모델은 나빠지므로 지속적 훈련(CT)과 실험 추적이 필요하고, 그것을 얼마나 자동화했는지가 성숙도(Level 0·1·2)입니다.

읽는 방법

· 굵은 글씨만 따라가도 흐름이 이어집니다.

· 회색으로 접힌 상자(▸)는 수식이나 보충 표입니다. 안 열어도 됩니다.

· 그림은 전부 슬라이더를 돌리고 버튼을 눌러 보는 용도입니다. 각 그림 위의 "해볼 것"부터 따라 해 보세요.

· "책 N장·N.N절"은 책의 위치, 그냥 "N장"은 이 글의 장, "①편"은 책 1장을 다룬 앞 글입니다.

01루프의 앞부분 — 문제 정의, 데이터 수집, EDA (책 2.1.0~2.1.2)

한 줄 요약: ML은 한 번 만드는 물건이 아니라 도는 루프입니다. 루프의 시작에서 문제를 함께 정의하고, 데이터를 족보(lineage)와 함께 모아야 뒤에서 고칠 수 있습니다.

왜 이걸 배우나

모델을 만들기 전에 무엇을 정하고, 데이터를 어떻게 모아 두어야 나중에 덜 고생할까?

책은 진짜 모델 연구를 하는 기업은 극소수이고, 대부분 기존 아키텍처를 재사용한다고 말합니다. Hugging Face 같은 라이브러리 덕에 모델링 자체는 어렵지 않은 일이 되기도 합니다. 어려운 질문은 그다음에 나옵니다 — 어떻게 훈련하고, 데이터를 어떻게 전달하고, 다른 서비스와 어떻게 붙고, 어디서 돌리고, 시간이 지나도 정확도를 어떻게 지킬까.

이 장은 그 질문들을 루프의 앞부분(문제 정의 → 데이터 수집 → 탐색적 분석)에서 다룹니다. 책 그림 2.1의 지도에서 ①(문제 정의)과 ②(모델 설계) 블록에 해당합니다.

이 장에 나오는 낯선 말

폐쇄 루프 (closed loop)

결과가 다시 입력으로 돌아와 계속 개선되는 구조입니다. ML에서는 모니터링 결과가 데이터 수집으로 돌아갑니다.

KPI (key performance indicator)

프로젝트 성공을 재는 핵심 성과 지표입니다. "고객 이탈률을 예측하라"만으로는 부족하고, 무엇을 얼마나 맞히면 성공인지 정해야 합니다.

lineage (리니지)

"이 모델(또는 데이터)이 무엇으로부터 어떤 과정을 거쳐 만들어졌는가"를 잇는 계보입니다. 원래 뜻은 혈통·족보입니다.

curation (큐레이션)

모은 원시 데이터를 골라 다듬고(선별·정제·중복 제거·균형 조정) 그 기준을 기록하는 일입니다. 수집이 장보기라면 큐레이션은 재료 손질입니다.

데이터 카드 (data card)

데이터셋의 출처·수집 기간·큐레이션 기준·알려진 한계를 적은 문서입니다. 무엇을 왜 뺐는지가 여기 남아야 lineage에서 데이터 단계를 거슬러 갈 수 있습니다.

균형 조정 (balancing) · oversampling

특정 부류가 너무 적을 때 쏠림을 줄이는 일입니다. 적은 쪽 샘플을 늘리면 oversampling, 많은 쪽을 줄이면 undersampling입니다.

lineage 유지 · 추적

유지는 훈련·배포할 때마다 연결 정보를 기록하는 쓰기, 추적은 문제가 생겼을 때 그 기록을 따라 올라가거나 내려가는 읽기입니다.

편향 (bias) · 데이터 누수 (data leakage)

편향은 데이터가 세상을 고르게 담지 못해 모델이 특정 경우에 계속 틀리는 것, 누수는 시험 문제나 정답이 학습 자료에 섞여 들어가 점수가 실제보다 좋게 나오는 것입니다.

ETL

extract(추출) · transform(변환) · load(적재). 데이터를 꺼내 가공해 저장하는 pipeline입니다. 버전을 매긴 ETL pipeline으로 데이터셋을 만들면 lineage가 생깁니다.

human-in-the-loop · CVAT

사람이 레이블을 붙이고 모델이 제안하고 사람이 고치는 일을 반복하는 구조가 human-in-the-loop, 그때 쓰는 오픈소스 웹 annotation 도구가 CVAT입니다.

EDA (exploratory data analysis)

탐색적 데이터 분석. 쓸 수 있는 데이터를 살펴보고 스키마(schema), 분포, 이상값(outlier) 같은 통계적 특성을 파악하는 단계입니다.

비유 먼저 — 족보가 있는 요리

식당에서 손님이 배탈이 났다고 합시다. 재료를 어느 날 어느 가게에서 샀고, 누가 어떤 레시피로 조리했는지 적어 둔 식당은 원인을 금방 찾습니다. 기록이 없는 식당은 가게부터 레시피까지 전부 다시 의심해야 합니다.

ML도 같습니다. 운영 중인 모델이 이상하면 그 모델이 어떤 데이터·코드·설정에서 나왔는지를 거슬러 올라가야 합니다. 이 기록이 lineage이고, 책 2장 내내 다시 등장합니다.

ML을 루프로 보기 (책 2.1.0)

책 그림 2.2는 ML을 하나의 루프로 그립니다. 비즈니스 use case → 데이터 수집 → 분석·준비 → 개발·훈련 → 평가 → 배포 → 모니터링, 그리고 성능이 떨어지거나 비즈니스 요구가 바뀌면 다시 데이터 수집으로 돌아가고, 더 쓸 이유가 없으면 모델을 폐기합니다. 저자들은 모델, 데이터, 하이퍼파라미터를 일시적인 존재로 보고, 시간이 흐르며 진화하는 루프의 일부로 이해하라고 권합니다.

예를 들어 중고차 판매 사이트에 차량 가격 예측 모델을 배포했다고 합시다. 시간이 지나면 고객 요구와 시장 상황에 맞춰 모델이 바뀌고, 상업용·산업용 차량을 위한 버전이 따로 생길 수도 있습니다. 모델을 빌드·테스트·배포하는 워크플로가 탄탄하면, 배포 자체보다 모델이 주는 비즈니스 가치에 집중하면서 새 버전을 계속 낼 수 있습니다.

그림 1

ML은 루프 — 모니터링 결과가 다음 바퀴를 정한다

↔ 상황 버튼 · 재생

해볼 것 — ① 기본 상황은 "성능 하락"입니다. [재생]을 누르면 남색으로 채워진 상자가 수집부터 모니터링까지 간 뒤, 판정에서 적색 화살표를 따라 데이터 수집으로 되돌아갑니다. 바퀴 수가 늘어납니다. ② 재생 중에 [이상 없음]으로 바꾸면 판정 뒤 모니터링으로만 돌아가 계속 지켜봅니다. ③ [더 필요 없음]을 누르면 판정에서 오른쪽 "모델 폐기"로 가서 멈춥니다. 루프의 끝은 배포가 아니라 폐기입니다.

모니터링에서 보이는 상황

※ 주: 책 그림 2.2를 다시 그림 · 남색 채움 = 지금, 남색 테두리 = 이번 바퀴에 지나옴, 회색 점선 = 아직 · 적색 화살표 = 성능 하락으로 되돌아감

모델과 코드는 따로 움직인다

책은 모델(가중치 + 네트워크)과 코드(아키텍처 정의 + 지원 코드)는 서로 별개라는 점을 명심하라고 합니다. 코드는 그대로인데 새 데이터로 재훈련해 모델만 바뀌기도 하고, 반대로 모델 파일은 그대로인데 전처리 코드만 고치기도 합니다.

둘은 짝이 맞아야 동작해서, 층 크기를 바꾼 코드로 예전 가중치를 불러오면 에러가 나거나 더 나쁘게는 조용히 엉뚱한 결과가 나옵니다. 그래서 lineage를 유지하고 추적하는 일이 지속 가능한 워크플로의 핵심이 됩니다.

구분	모델 (가중치 + 네트워크)	코드 (아키텍처 정의 + 지원 코드)
정체	학습 결과로 만들어진 파일	사람이 작성한 소스 코드
저장 형태	model.pkl, best.pt, model.onnx	.py 파일, Git 저장소
버전 관리	model registry, artifact 저장소	Git
바뀌는 계기	재훈련할 때마다	로직·구조를 고칠 때

저장 방식에 따라 파일에 담기는 것 · pickle 주의 (스터디 노트)

가중치만(state_dict) 저장하면 숫자만 담겨서 불러올 때 아키텍처 코드가 꼭 필요합니다. TorchScript·ONNX·SavedModel은 숫자와 연산 구조를 함께 담아 코드 없이도 실행할 수 있습니다. pickle 전체 객체는 원래 클래스 코드가 같은 경로·버전으로 있어야 합니다.

pickle 파일은 불러올 때 코드를 실행할 수 있어서, 출처를 모르는 모델 파일을 pickle로 불러오면 보안 위험이 있습니다. 모델에 "어느 코드 커밋과 짝인지"를 메타데이터로 남기는 이유이기도 합니다.

문제 정의 — 이해관계자별로 물어야 할 것

루프는 문제를 정의하고 예측에 쓸 데이터를 모으는 데서 시작합니다. 착수 전에 이해관계자와 합의해야 하며, 책은 그룹별 핵심 질문을 정리해 둡니다.

이해관계자	핵심 질문
비즈니스·제품	왜 ML이 필요한가 · 성공을 재는 지표는 · 노력 대비 가치는 · 일정은 · 로드맵에서 가치가 가장 큰 지점은 · 잘못된 예측의 영향과 허용 오차는
기술 팀 (ML 엔지니어·데이터 과학자)	ML로 풀 수 있고 최선인가 · 데이터는 어디에 어떻게 저장되고 어떤 pipeline이 필요한가 · 어떤 지표로 평가하나 · 훈련·서빙 컴퓨팅 자원은 · 업그레이드·유지보수가 되는 배포 전략은 · 어떤 지표가 재훈련을 촉발해야 하나
법무·컴플라이언스	윤리·개인정보 문제는 · 민감 정보는 어떻게 다루나 · 지켜야 할 데이터 거버넌스 요건은

함께 답을 내면 범위와 산출물이 명확해지고, 비즈니스 목표와 기술 구현이 맞물리고, 과제를 일찍 발견하고, 데이터 과학자와 ML 엔지니어가 같은 말로 소통하게 됩니다.

데이터 수집 (책 2.1.1)

KPI가 정해지면 데이터를 모읍니다. 이후의 모든 단계가 이 단계의 편향을 그대로 물려받기 때문에 수집과 큐레이션은 신중해야 합니다. 한 동네 맛집만 가 본 사람이 "이 나라 음식은 다 짜다"고 결론 내리듯, 모델은 받은 데이터가 세상의 전부인 줄 알고 배웁니다.

여기서 연구와 기업이 갈립니다. 연구는 검토를 거친 대규모 오픈소스 데이터셋을 쓰고 품질이 충분하다고 가정하지만, 기업은 목표 도메인에 맞는 오픈소스 데이터셋이 없는 경우가 많습니다.

있어도 배포 환경의 데이터로 fine-tuning(transfer learning)을 거쳐야 합니다. 그래도 데이터 수집의 핵심 요건은 둘 모두에게 같습니다.

• 문제 도메인과의 관련성 · 문제의 복잡도에 맞는 크기 · 데이터셋의 품질
• 유해한 편향과 의도하지 않은 샘플 유출(데이터 누수) 방지
• 배포 환경을 대표하는 데이터·feature 분포 · 문제 도메인을 정의할 만큼의 다양성
• 원시 데이터, 중간 버전, 증강·annotation 데이터셋 전부에 대한 lineage와 상세한 추적

편향 세 가지 · 누수 세 가지 (스터디 노트)

표본 편향 — 밝은 실내 신분증만 학습해 어두운 사진에서 실패. 선택 편향 — 신고된 사기만 사기로 표시해 신고 안 된 사기를 놓침. 과거 편향 — 과거 대출 심사의 차별이 모델에 복제됨.

샘플 중복 누수 — 같은 사진이 훈련과 테스트에 모두 들어감. 미래 정보 누수 — 3월 1일 판정에 3월 5일 값을 씀. 정답 단서 누수 — 사기 확정 뒤에 생기는 "계정 정지 여부"를 feature로 씀.

막는 법: 분할 전에 중복 제거, 시간 순서 데이터는 시간 순서로 분할, "예측 시점에 이 값을 알 수 있나?"를 매번 자문, 점수가 지나치게 좋으면 성공이 아니라 누수를 의심. 균형 조정(사기 샘플 늘리기)은 훈련 데이터에만 합니다.

큐레이션 — 모은 데이터를 쓸 수 있는 데이터셋으로

책은 수집과 함께 큐레이션(curation)을 신중히 하라고 합니다. 미술관 큐레이터가 작품을 모으기만 하지 않고 전시 목적에 맞게 고르고, 배치하고, 설명을 붙이듯, 데이터 큐레이션은 "이 데이터를 쓸지, 어떻게 손볼지, 무엇이 빠졌는지"를 판단하고 기록하는 일입니다.

구분	수집 (collection)	큐레이션 (curation)
핵심 질문	데이터를 어디서 얼마나 가져올까	가져온 데이터가 쓸 만하고 균형 잡혔나
하는 일	로그, DB, API, 크롤링, 구매, 합성 생성	선별, 정제, 중복 제거, 균형 조정, 문서화
결과물	원시(raw) 데이터	모델링에 쓸 수 있게 다듬은 데이터셋
비유	장보기	재료를 고르고 씻고 손질하기

큐레이션에서 하는 일은 여섯 가지로 정리됩니다. 예시는 스터디 노트의 신분증 OCR·사기 탐지 사례입니다.

작업	내용	예시
선별 (selection)	목적에 맞는 데이터만 고름	유효한 신분증만, 흐릿하거나 잘린 이미지는 제외
정제 (cleaning)	오류·중복·결측을 고치거나 제거	같은 거래의 중복 행 삭제, 금액이 음수인 오류 제거
균형 조정 (balancing)	특정 부류 쏠림 완화	사기가 0.1%뿐이면 사기 샘플 보강
대표성 확보	실제 운영 환경을 반영	여러 국가·기기·조명의 신분증 포함
레이블 품질 관리	레이블 오류·불일치 점검	annotator 두 명의 입력이 다른 건 재검수
문서화·버전화	출처·기준을 기록	데이터 카드, 데이터셋 버전 태그

같은 작업이라도 언제, 어디에 하느냐에 따라 평가가 현실과 어긋납니다. 스터디 노트는 세 가지를 짚습니다.

• 균형 조정은 훈련 데이터에만 — 사기 샘플을 늘리는 조정을 검증·테스트에까지 하면, 사기가 드문 실제 운영 환경과 달라져 성능이 부풀려 보입니다.
• 중복 제거는 분할 전에 — 같은 데이터가 훈련과 테스트에 모두 들어가면 시험 문제를 미리 본 셈(누수)이 됩니다.
• 기준을 기록 — 어떤 기준으로 무엇을 뺐는지 데이터 카드에 남겨야, 뒤에서 볼 lineage가 데이터 단계까지 이어집니다.

숫자로 한 번 — 중복 500쌍은 얼마나 새어 나가나

거래 10,000건에 같은 거래가 두 번 들어간 쌍이 500개 있다고 합시다. 중복을 지우지 않고 70 : 30으로 무작위 분할하면, 한 쌍이 훈련과 테스트로 갈라질 확률은 이렇습니다.

한 쌍이 갈라질 확률 = 0.7 × 0.3 + 0.3 × 0.7 = 0.42 ── 첫 행이 훈련·둘째가 테스트, 또는 그 반대
500쌍 × 0.42 ≈ 210쌍 ── 테스트의 210건은 모델이 훈련에서 이미 본 거래
분할 뒤에 중복을 지워도 갈라진 210쌍은 그대로 ── 각 쪽 안에서는 짝이 없어 중복으로 안 보임

그래서 순서가 중요합니다. "중복 제거를 했다"가 아니라 "분할 전에 했다"여야 누수가 막힙니다.

그림 2

큐레이션 — 같은 작업도 순서와 범위가 평가를 바꾼다

↔ 단계 토글 · 중복 제거 시점 · 균형 조정 범위

해볼 것 — ① 기본값은 중복 제거를 분할 뒤로 미룬 상태입니다. 테스트 막대 왼쪽의 점선 칸이 훈련에서 이미 본 210건이고, 테스트 상자에 적색 테두리가 쳐집니다. [분할 전]을 누르면 점선 칸과 테두리가 사라집니다. ② 균형 조정을 [훈련+테스트]로 바꾸면 테스트 막대의 남색(사기) 부분이 20%로 커지며 다시 적색 테두리가 쳐집니다. 사기가 2%인 운영 환경을 더는 대표하지 못합니다. ③ [데이터 카드 기록]을 끄면 아래 기록 상자가 회색 점선이 됩니다. 숫자는 그대로지만, 나중에 누가 무엇을 왜 뺐는지 알 수 없게 됩니다.

단계

중복 제거 시점

균형 조정 범위

※ 주: 건수·비율은 설명용 예시 — 실측 아님 · 큐레이션 작업과 "균형 조정은 훈련에만, 중복 제거는 분할 전에, 기준은 기록"은 스터디 노트의 큐레이션 설명 · 막대의 회색 = 정상, 남색 = 사기, 점선 칸 = 훈련에서 본 거래

저자들은 lineage가 프로젝트 초반에 자주 간과되며, 초기 속도를 위해 미래의 유지보수성을 희생하는 기술 부채와 비슷하다고 말합니다. lineage가 중요한 이유는 둘입니다.

1. 데이터의 출처를 세운다 언제, 어디서, 어떻게, 왜 수집했는지에 관한 메타데이터가 있어야 데이터의 한계를 이해하고 알맞은 feature를 고를 수 있습니다.
2. 데이터셋 수정을 선형적인 과정으로 만든다 첫 버전의 데이터셋이 최선인 경우는 드뭅니다. lineage가 있으면 오류가 났을 때 복잡한 추출 스크립트를 다시 짜는 대신 쿼리 하나로 데이터셋을 다시 만들 수 있습니다.

lineage — 무엇을 기록하고, 어떻게 쓰나

lineage는 "이 모델(또는 결과)이 무엇으로부터 어떤 과정을 거쳐 만들어졌는가"를 잇는 계보입니다. 사람의 족보가 부모 → 자식으로 이어지듯, ML에서는 원천 데이터 → 전처리 → feature → 학습 실행(코드 + 하이퍼파라미터) → 모델 → 운영 배포로 이어지고, 이 사슬의 고리마다 남기는 기록이 lineage입니다.

고리	기록할 내용	예시
데이터	원천, 버전, 전처리·큐레이션 이력	스냅샷 10-01, 결측치 제거 스크립트 v3, 데이터 카드
feature	어떤 feature 정의로 만들었나	Feast feature view·feature service 이름 (①편 4장)
코드	학습·전처리 코드 버전	git 커밋 해시
설정	하이퍼파라미터, 실행 환경	학습률 0.01, 라이브러리 버전
모델	결과물과 평가 지표	model v7, F1 0.91
배포	어디에 어떤 버전이 떠 있나	운영 서비스 = model v7

①편에서 본 재현성이 "같은 조건이면 같은 결과가 나오는 성질"이라면, lineage는 그 조건이 무엇이었는지 연결해 알려 주는 정보입니다. 앞에서 모델과 코드를 따로 다루라고 한 이유도 여기에 닿습니다. 둘이 어느 버전끼리 짝인지를 lineage가 알려 줍니다.

유지와 추적은 한 세트입니다. 유지는 일기를 쓰는 일, 추적은 그 일기를 읽는 일이고, 유지를 안 하면 추적할 것이 없습니다.

구분	lineage 유지	lineage 추적
하는 일	각 단계에서 연결 정보를 기록·보존	기록을 따라 거슬러 올라가거나 내려가며 조회
시점	훈련·배포하는 동안 (쓰기)	문제가 생기거나 감사할 때 (읽기)
방법	실험 추적 도구, 모델 레지스트리, 데이터·코드 버전 관리	레지스트리·추적 UI에서 모델 → 실행 → 데이터 조회
실패하면	나중에 추적할 단서가 없음	원인 파악·재현 불가

사람이 손으로 기록하면 빠뜨리기 쉬워서 도구와 자동화에 맡깁니다. 책에서는 MLflow의 실험 추적과 모델 레지스트리가 이 역할을 하며, 책 4~6장 실습에서 직접 다룹니다.

추적에는 방향이 둘 있습니다. 운영 모델 성능이 떨어졌을 때 "이 모델은 무엇으로 만들었지?"를 찾는 거슬러 올라가기와, 학습 데이터의 오류가 판명됐을 때 "이 데이터로 만든 모델은 어디에 떠 있지?"를 찾는 내려가기입니다. 아래 그림 4가 이 두 방향을 보여 줍니다.

그래서 lineage는 지속 가능한 워크플로의 조건이 됩니다. 원인이 데이터·코드·설정 중 어디인지 좁히는 디버깅, 지난달 모델을 정확히 다시 만들거나 되돌리는 재현과 롤백, "이 판단을 한 모델이 어떤 데이터로 학습됐나"에 답하는 감사와 규정 준수, 담당자가 바뀌어도 출처를 아는 인수인계가 모두 여기에 기댑니다.

선형적인 수정 — 첫 버전은 대개 틀린다

데이터는 한 번에 완벽하게 만들어지지 않습니다. 분석하다 보면 "이 구간 데이터가 이상하다", "이 부류가 빠졌다", "레이블이 잘못됐다"를 뒤늦게 발견하니, 수정을 전제로 일하고 고칠 때 드는 비용을 줄여 두는 것이 lineage의 역할입니다.

lineage가 있으면 데이터셋이 v1 → v2 → v3처럼 한 줄로 이어지고, 각 버전이 이전 버전에서 어떤 기준으로 만들어졌는지 남습니다. 문서 편집기의 변경 이력처럼 "v2에서 중복 제거 기준을 잘못 잡았네" 하고 그 지점으로 돌아가 고치면 됩니다.

한 달 뒤에 "3월에 수집한 거래에 중복이 섞여 있었다"는 걸 알았다고 합시다. 스터디 노트는 두 경우를 이렇게 비교합니다.

구분	lineage 없음	lineage 있음
오류 발견 시	어디서 틀렸는지 찾기 어려움	기록을 따라 해당 단계로 바로 이동
데이터셋 재생성	추출 스크립트를 다시 짜고 처음부터 재실행	"원천 테이블의 이 기간, 이 조건, 이 전처리 버전"으로 쿼리 실행
걸리는 시간	며칠	몇 분
다른 버전과 비교	기억에 의존	버전별 기록으로 비교

앞의 큐레이션 기준 문서화(데이터 카드)도 이를 위한 준비이고, 책이 뒤에서 Feast와 MLflow로 데이터와 실험 이력을 남기는 이유이기도 합니다.

그림 3

데이터셋 고치기 — lineage가 있을 때와 없을 때

↔ 오류 종류 · 발견 시점 슬라이더 · lineage 토글

해볼 것 — ① 기본값은 3월 수집분의 중복을 두 달 뒤에 발견한 상황입니다. 남색으로 채워진 v2·v3와 model-2·3만 다시 만들고, 남색 테두리의 v1은 그대로 둡니다. ② 슬라이더를 4달 뒤까지 밀면 그사이 쌓인 v4·v5와 모델도 남색으로 채워집니다. 늦게 찾을수록 다시 만들 것이 늘지만, 영향받지 않은 v1은 끝까지 그대로입니다. ③ [lineage 기록]을 끄면 모든 버전에 물음표가 붙고 적색 테두리가 쳐집니다. 어느 버전이 오염됐는지 모르니 전부 처음부터 다시 만들어야 하고, 걸리는 시간이 "몇 분"에서 "며칠"로 바뀝니다. [전처리 v2 버그]도 눌러 보세요.

발견한 오류

발견 시점 2달 뒤

※ 주: 버전·기간·모델 이름은 설명용 예시 · "몇 분 vs 며칠"은 스터디 노트 비교표의 표현으로 추정치 — 실측 아님 · 남색 채움 = 다시 만듦, 남색 테두리 = 그대로, 회색 = 오염 여부를 모름

책의 차량 가격 예측 예시에서는 중고 시장의 승용차만 모으고 트럭·오토바이는 빼며, 대표성을 위해 샘플링을 신경 쓰고, 버전을 관리하는 ETL pipeline으로 데이터셋을 만들어 lineage를 세웁니다. 클래스가 과대·과소 대표되는 편향은 특히 주의하되, 처음부터 모든 조건을 채울 수는 없으니 최대한 충족하는 데이터셋으로 시작해 반복합니다.

프로젝트별 데이터 — 모달리티가 다르면 방법이 다르다

신분증 탐지는 공개 데이터셋 MIDV-500(여러 나라 신분증·여권·운전면허증 50종, 영상 500편)을 씁니다. CVAT으로 사람이 직접 annotation하는 절은 선택 사항이고, 대부분은 합성 데이터라 이미지와 레이블이 프로그램으로 함께 만들어집니다. 영화 추천은 MovieLens 1M(사용자 6,000명, 영화 약 3,000편, 평점 100만 건)을 작은 조각으로 나눠, 운영 중 데이터가 점점 들어오는 상황을 흉내 내고 그때부터 데이터셋 버전 관리를 시작합니다.

모달리티마다 저장·레이블·전처리·평가 방법이 어떻게 갈리는지는 ①편 5장의 표와 그림 8에 모았습니다.

MIDV-500 · CVAT · 합성 데이터 더 보기 (스터디 노트)

MIDV-500은 Mobile Identity Document Video 500의 줄임말로, 문서 50종 × 영상 10편을 스마트폰으로 찍은 공개 데이터셋입니다. 책상 위, 키보드 위, 손에 든 상태, 손가락으로 일부 가림, 어수선한 배경의 다섯 가지 조건에서 촬영했습니다. 프레임마다 문서의 네 모서리 위치와 텍스트 필드가 정답으로 붙어 있고, 견본(specimen) 문서라 실제 개인정보가 없습니다.

CVAT의 human-in-the-loop는 사람이 처음 박스를 그리면 → 모델이 학습해 새 이미지에 박스를 제안하고 → 사람은 틀린 박스만 고치고 → 고친 레이블로 다시 학습하는 반복입니다. 모델이 나아질수록 사람의 일이 "그리기"에서 "고치기"로 줄어듭니다.

사람 annotation의 문제	쉬운 설명	대응
시간·비용	사람이 일일이 그려서 느리고 비쌈	모델 제안을 고치는 방식으로 작업량 감소
사람마다 다른 기준	누구는 테두리 안쪽, 누구는 바깥쪽에 그림	작업 지침서, 교차 검수
실수와 오류	피곤하면 박스가 어긋나거나 빠짐	샘플 재검수, 오류 신고
병목	레이블이 늦으면 학습도 늦어짐	필요한 데이터부터 우선 작업
레이블 버전 관리	고친 레이블이 어느 버전인지 헷갈림	레이블도 데이터처럼 버전·lineage 기록

합성 데이터는 프로그램이 신분증 템플릿을 배경 위에 임의의 위치·각도·크기로 붙여 만듭니다. 붙이는 순간 네 모서리 좌표를 계산할 수 있어 레이블이 함께 나오고, 사람의 레이블 오류도 거의 없습니다.

대신 합성 이미지가 현실과 너무 다르면 실제 사진에서 성능이 떨어질 수 있어 실제 데이터로 평가해야 한다고 스터디 노트는 짚습니다. 책이 실제로 어떻게 합성하고 평가하는지는 해당 절에서 확인할 부분입니다.

숫자로 한 번 — 데이터 조각과 데이터 분할은 다르다

MovieLens 100만 건을 조각으로 나눠 버전을 쌓는다고 해 봅시다. 몇 조각으로 나눌지는 책 해당 절에서 확인할 부분이라, 여기서는 20%씩이라고 가정합니다.

v1 = 처음 20% = 200,000건 ── 서비스 시작 때 확보한 데이터
v2 = v1 + 다음 20% = 400,000건 ── 한 달 뒤
v3 = v2 + 다음 20% = 600,000건 ── 두 달 뒤
v1 안에서도 다시 분할 (70 / 15 / 15%): 훈련 140,000 · 검증 30,000 · 테스트 30,000건

조각 나누기는 데이터가 도착하는 시점을 흉내 내려는 것이고, 훈련·검증·테스트 분할은 성능을 정직하게 재려는 것입니다. 목적이 다르니 각 버전 안에서 분할이 또 필요합니다. "이 모델은 v2로 학습했다"고 말할 수 있어야 v2에 문제가 생겼을 때 v1로 돌아가거나 v2만 다시 만들 수 있습니다.

그림 4

lineage — 거슬러 올라가기와 내려가기

↔ 질문 버튼 · 기록 토글

해볼 것 — ① 기본 질문은 "운영 모델 성능이 떨어졌다"입니다. 남색 경로가 운영 중인 model v7에서 run-42, feature v3를 거쳐 스냅샷 10-01까지 거슬러 올라갑니다. ② [스냅샷 10-01에 오류]를 누르면 반대로 내려갑니다. 그 데이터로 만든 모델 v6·v7이 남색으로 잡히고, 그중 v7이 운영 중이라는 것까지 보입니다. ③ [lineage 기록]을 끄면 연결선이 회색 점선으로 끊기고 어느 질문에도 답할 수 없게 됩니다(적색 고리).

질문

※ 주: 스냅샷 날짜·run 번호·커밋·모델 버전은 설명용 예시 · lineage 사슬(원천 데이터 → feature → 학습 실행(코드+설정) → 모델 → 배포)은 스터디 노트의 lineage 설명을 따름

EDA — 가정을 검증하는 첫 방어선 (책 2.1.2)

EDA는 가장 중요한 단계 중 하나입니다. 데이터셋 문제처럼 명확히 정의되지 않은 문제에 대한 첫 번째 방어선이고, 모델 개발·유지에 드는 작업량을 가늠하는 데도 쓰입니다. 책이 꼽는 목표는 다섯 가지입니다.

• 형태 — 스키마는 무엇이고 바뀔 수 있나, 유효하지 않은 값은 어떻게 막나, 정제가 필요한가
• 분포 — 모든 target이 고르게 있나, 클래스 균형 조정이 필요한가
• feature — 목표 작업에 쓸 만한 feature가 있나, 계산 비용이 큰가
• 주기·외부 요인 — 입력이 주기적으로 변하나, 모델에 없는 외부 요인과 상관이 있나
• 이상값 — outlier가 있나, 프로덕션에서는 어떻게 다루나

핵심은 데이터에 대해 세운 가정을 검증 전까지 믿지 않는 것입니다. 스키마처럼 단순한 가정부터 샘플링에 숨은 편향, 필드에 대한 오해까지, 데이터 pipeline 초기에 검증 장치를 두면 나중의 디버깅 시간이 크게 줄고 근본 원인 분석(root-cause analysis)과 drift 같은 배포 문제의 단서도 됩니다. EDA는 새 인사이트를 얻거나 실험이 실패할 때마다 가정을 다시 보는 반복 과정이라, 다른 접근이나 문제 정의를 바꾸는 데 열려 있어야 합니다.

다변량 분석과 차원 축소 — PCA vs t-SNE (스터디 노트)

다변량 분석(multivariate analysis)은 변수 여러 개를 동시에 보는 분석입니다. 키와 몸무게를 따로 보면 평범해도 같이 보면 "키에 비해 몸무게가 유난히 큰 사람"이 드러나고, 그런 단서로 새 feature(예: BMI)를 만듭니다.

변수가 수십~수백 개면 눈으로 볼 수 없어 차원 축소(dimensionality reduction)로 2~3차원에 펼쳐 봅니다. PCA는 가장 넓게 퍼진 방향으로 선형 투영해 빠르고 결과가 일정하지만 비선형 구조는 못 잡습니다. t-SNE는 가까운 점끼리 가깝게 배치해 군집을 보기 좋지만, 느리고 실행마다 결과가 다르며 군집 간 거리·크기는 해석하면 안 됩니다.

1장 세 줄 요약

1. 정의 — ML은 use case에서 시작해 모니터링 결과가 다시 데이터 수집으로 돌아가는 폐쇄 루프이고, 더 쓸 이유가 없으면 모델을 폐기합니다.
2. 성질 — 뒤 단계는 데이터 단계의 편향을 그대로 물려받습니다. 모델과 코드는 따로 버전이 바뀌므로 lineage로 짝을 기록해야 거슬러 올라가고 내려갈 수 있습니다.
3. 쓰임 — 이해관계자별 질문으로 문제를 정의하고, 버전 관리되는 ETL pipeline으로 데이터를 모아 큐레이션 기준을 데이터 카드에 남기고, EDA로 가정을 초기에 검증합니다.

— 여기까지: 루프의 앞부분과 lineage. 다음은 루프의 뒷부분 — 모델링, 평가, 배포, 모니터링, 유지보수 —

02루프의 뒷부분 — 모델링, 평가, 배포, 모니터링, 유지보수 (책 2.1.3~2.1.7)

한 줄 요약: 모델은 코드·설정·데이터를 조합한 artifact로 다루고, 목표 도메인에 맞는 지표로 평가하고, 배포 뒤에는 drift와 오류를 지켜보며 루프를 다시 돌립니다.

왜 이걸 배우나

모델을 훈련하고 평가하고 배포한 다음에는, 무엇을 기록하고 무엇을 지켜봐야 할까?

정확도 하나로 모델을 고르고, 설정을 코드 안에 박아 두고, 배포한 뒤 지표를 안 보면 루프가 끊깁니다. 다시 만들 수도, 왜 나빠졌는지 알 수도 없게 됩니다.

이 장은 책 2.1.3~2.1.7절을 따라가며 모델링 단계의 도구상자, 지표 고르는 법(F1), 배포·모니터링·유지보수의 체크포인트를 봅니다.

이 장에 나오는 낯선 말

분류 (classification) · 탐지 (detection) · 회귀 (regression)

모델이 무엇을 출력하느냐로 나눕니다. 분류는 정해진 범주 하나(스팸인가), 탐지는 범주와 위치 상자(무엇이 어디에), 회귀는 연속적인 숫자(얼마인가)입니다.

실험 추적 (experiment tracking) · checkpoint

실험마다 쓴 데이터·설정과 중간 저장본(checkpoint)을 결과와 함께 기록하는 것입니다. 실험과 결과가 유실되지 않습니다.

하이퍼파라미터 최적화

사람이 탐색 공간(예: 학습률 0.001~0.1)과 손실 함수(좋고 나쁨의 기준)만 주면, 도구가 여러 조합을 시도해 가장 좋은 값을 찾는 과정입니다.

config (설정 파일) · 모듈식 코드베이스

모델 구조와 학습 방식을 코드 밖 설정 파일에 두는 것입니다. 코드·설정·데이터를 나눠 두고, 훈련된 모델을 그 조합의 artifact로 봅니다.

과적합 (overfitting)

훈련 데이터에서는 잘 맞는데 처음 보는 데이터에서는 성능이 떨어지는 상태입니다. 문제를 외운 학생과 같습니다.

precision · recall · F1 score

precision(정밀도)은 양성이라 한 것 중 진짜 비율, recall(재현율)은 진짜 양성 중 찾아낸 비율, F1은 둘을 하나로 합친 점수(0~1)입니다.

holdout 데이터셋

학습에 절대 쓰지 않고 따로 빼 둔 최종 시험지입니다.

quantization · latency

quantization(양자화)은 모델의 숫자 정밀도를 낮춰 가볍고 빠르게 만드는 최적화, latency는 요청 하나에 답하기까지 걸리는 시간입니다.

data drift · concept drift

data drift는 입력 데이터의 분포가 훈련 때와 달라지는 것, concept drift는 입력과 정답의 관계 자체가 달라지는 것입니다.

비유 먼저 — 레시피 카드

요리사가 레시피를 머릿속에만 두면, 맛이 달라졌을 때 무엇을 바꿨는지 모릅니다. 불 세기·조리 시간을 카드에 적어 두고 바꿀 때마다 새 카드를 남기면, 어제 맛과 오늘 맛의 차이를 카드 두 장으로 비교할 수 있습니다.

ML에서 그 카드가 설정 파일(config)이고, 카드를 Git에 쌓는 것이 실험 기록입니다. 코드는 레시피 절차, 설정은 불 세기와 시간, 데이터는 재료, 훈련된 모델은 완성된 요리입니다.

모델링과 훈련 (책 2.1.3)

모델링은 문제를 풀 모델이나 알고리즘을 고르는 데서 시작합니다. 판단 요인은 이론적 성능, 입력 데이터 타입, 문제 유형(분류·탐지·회귀)입니다.

같은 영화 평점도 "좋음/나쁨"으로 맞히면 분류, "3.7점"으로 맞히면 회귀입니다. 이 단계에서 MLOps 도구상자의 네 가지가 등장합니다.

1. 모델·데이터 버전 관리모든 모델이 특정 데이터셋 버전과 묶여, 디버깅이나 컴플라이언스 때문에 처음부터 다시 만들 수 있게 합니다.
2. 실험 추적그 엄격함을 프로토타입 단계까지 넓힙니다. 쓴 데이터와 정확한 설정, checkpoint가 결과와 함께 남아 실험이 사라지지 않습니다.
3. 모델 훈련 pipeline실수로 이어지는 수작업 단계를 없앱니다.
4. 하이퍼파라미터 탐색탐색 공간 안에서 최적의 값을 찾습니다. 도구가 설정만 바꿔 같은 코드를 반복 실행하려면 설정이 코드 안에 박혀 있으면 안 됩니다.

그래서 책은 처음부터 모듈식 코드베이스를 권합니다(책 그림 2.5). 코드와 모델 설정과 사전 훈련 가중치가 모여 모델이 되고, 여기에 데이터셋과 훈련 설정이 더해져 훈련된 모델이 됩니다. 어떤 모델이 과적합으로 의심되면, 손으로 실험을 돌리는 대신 설정에서 층 수와 크기를 줄여 가설을 검증합니다. 설정 파일을 Git으로 추적하고 lineage와 묶으면, 모델을 블랙박스로 두지 않고 어떤 설정·데이터·코드로 만들어졌는지 들여다보는 introspection(내부 분석)이 됩니다.

숫자로 한 번 — 과적합 가설 검증

run-01 · num_layers 6 · 훈련 점수 0.98 · 검증 점수 0.79 ── 차이 0.19, 과적합 의심
가설: 모델이 너무 크다 → 설정에서 num_layers만 6 → 3으로 바꿈 (코드는 그대로)
run-02 · num_layers 3 · 훈련 점수 0.89 · 검증 점수 0.90 ── 검증 점수가 올랐으니 가설이 맞음
두 run의 설정 diff: num_layers 6 → 3 · 나머지 동일 → 원인 후보가 하나로 좁혀짐

그림 5

설정만 바꿔 다시 훈련하기 — 모듈식 코드베이스와 실행 기록

↔ 슬라이더 · 버튼

해볼 것 — ① 기본 상태의 run-01(num_layers 6)은 훈련 점수(회색 막대)와 검증 점수(파란 막대)의 차이가 커서 적색 "과적합 의심" 표시가 붙어 있습니다. ② 슬라이더를 3으로 내리고 [이 설정으로 훈련]을 누르세요. 아래 실행 기록에 run-02가 추가되고, 오른쪽에 run-01과의 설정 차이(diff)가 한 줄로 나옵니다. ③ 슬라이더를 1까지 내려 보세요. 이번엔 두 점수가 함께 낮아집니다(모델이 너무 작음). 데이터 버전 버튼을 바꿔 훈련하면 기록의 data 칸이 바뀌어 lineage가 남습니다.

model config · num_layers 6 데이터셋 버전

※ 주: 훈련·검증 점수는 층 수에 따른 경향을 보여 주려고 만든 예시 곡선 — 실측 아님 · 커밋 해시·run 번호도 예시 · 구조는 책 그림 2.5를 단순화

팩토리 패턴과 과도한 파라미터화 (스터디 노트)

팩토리 패턴은 객체를 만드는 일을 한곳에 맡기는 설계입니다. 설정에 model: resnet이라고 적으면 팩토리가 그 모델 객체를 만들어 돌려주므로, 모델을 바꿀 때 설정 한 줄만 고치면 됩니다.

반대로 설정으로 뺄 수 있는 것을 전부 빼면(과도한 파라미터화) 항목이 수백 개가 되어 무엇을 바꿔야 할지 막막해지고 원인 후보가 폭발적으로 늘어납니다. 책의 조언은 단순한 설정으로 시작해, 실제로 바꿔 보고 싶은 값이 생길 때 하나씩 설정으로 옮기라는 것입니다.

프로젝트에서는 신분증 탐지에 YOLO를 씁니다. 책 집필 시점 기준 12번째 버전이었고(스터디 노트 기준 2026년에는 26 버전), COCO 데이터셋 91종으로 훈련되어 신분증·여권은 모르지만 잘 레이블된 데이터로 fine-tuning하면 YOLOv8이 신분증을 탐지합니다.

추천 프로젝트는 베이스라인 모델로 시작해 재훈련 pipeline과 추적 서버를 붙이고, RAG는 embedding 모델·벡터 DB·채팅 인터페이스를 더합니다. MLOps의 핵심 개념은 그대로이고 겉보기에 다른 도메인에서도 재사용된다는 것이 요점입니다.

모델 평가 (책 2.1.4)

테스트 성능이 좋은 모델을 얻었다면, 실제 목표 도메인에서도 잘 동작하는지 확인해야 합니다. 여기서 문제 정의와 지표 선택이 중요해집니다.

분류·탐지에는 precision·recall·F1, 회귀에는 MAE(평균 절대 오차)·MSE(평균 제곱 오차)가 맞습니다. 같은 분류여도 의료는 위양성률과 precision에 엄격하고, 금융은 놓친 사건의 손실을 줄이려고 recall을 중시하기도 합니다.

숫자로 한 번 — F1

메일 100통 중 진짜 스팸이 10통이고, 모델이 8통을 스팸이라 판정했는데 그중 6통이 진짜였다고 합시다(스터디 노트의 예시).

TP 6 (맞힌 스팸) · FP 2 (멀쩡한 메일을 스팸으로) · FN 4 (놓친 스팸) · TN 88 (정상을 정상으로)
precision = 6 ÷ 8 = 0.75  ·  recall = 6 ÷ 10 = 0.60  ·  accuracy = 94 ÷ 100 = 0.94
F1 = 0.667 ── 두 값의 조화평균
모든 메일을 스팸이라고 찍으면: precision 0.10 · recall 1.00 → 산술평균 0.55인데 F1은 0.18

F1은 한쪽만 높으면 후하게 쳐 주지 않습니다. 그리고 스팸이 10%뿐이면 전부 정상이라고 찍어도 accuracy가 0.90이라, 클래스가 불균형할 때는 accuracy만으로 부족합니다.

그림 6

F1 계산기 — 판정 임계값을 움직이면

↔ 슬라이더 · 캔버스 끌기

해볼 것 — ① 기본 임계값 0.60에서 남색 세로선 오른쪽이 "스팸 판정"입니다. 오른쪽 값이 원본 예시(TP 6, FP 2, FN 4, TN 88)와 같은지 확인하세요. 적색 고리가 틀린 판정입니다. ② 임계값을 0.40 근처로 내리면 놓친 스팸이 줄어 recall이 오르고, 대신 정상 메일이 더 걸려 precision이 내려갑니다. 둘은 맞바꾸는 관계입니다. ③ [전부 스팸이라 찍기]를 누르면 recall 1.00, precision 0.10인데 F1은 0.18까지 떨어집니다.

판정 임계값 0.60

※ 주: 메일 100통(스팸 10)과 기본 판정 결과는 스터디 노트의 예시 · 각 메일의 점수는 그 결과가 나오도록 만든 예시 값 · 남색 네모 = 실제 스팸, 회색 원 = 실제 정상

수식으로도 보고 싶다면

precision = TP ÷ (TP + FP)    recall = TP ÷ (TP + FN)

F1 = 2 × precision × recall ÷ (precision + recall)

TP(true positive)는 맞힌 양성, FP(false positive)는 정상을 양성으로 오판한 것, FN(false negative)은 놓친 양성입니다. F1은 precision과 recall의 조화평균이라, 둘 중 작은 값 쪽으로 끌려 내려갑니다. 다중 클래스에서는 macro·micro 같은 평균 방식을 따로 정해야 합니다.

공식 환경에서 평가는 별도의 holdout 데이터셋으로 자동 실행합니다. holdout은 프로덕션 데이터의 다양성·분포·특성을 닮게 구성하고, 누수를 막고, 훈련 데이터만큼 엄격하게 버전과 lineage를 관리합니다.

평가를 자동화하면 사람 실수로 인한 흔들림이 사라지고 결과가 반복·재현됩니다. 테스트·훈련·holdout 분할이 바뀌면 예전 시험지 문제가 새 훈련 데이터에 섞일 수 있어 재평가·재훈련 루프가 필요해집니다.

평가는 오류를 정밀하게 뜯어보는 단계이기도 합니다. 오분류된 샘플의 패턴에서 시스템적 문제와 편향을 찾아 데이터 수집으로 되돌려 보내고, 민감도(sensitivity)와 견고성(robustness)을 적대적 테스트와 edge case 시뮬레이션으로 검증합니다.

배포 (책 2.1.5)

배포 방법은 크게 둘입니다. 마이크로서비스용 엔드포인트(API 계층 뒤에서 모델이 동작)와 특정 하드웨어·edge 디바이스(자동차, 보안 장비, 로보틱스처럼 기기에서 인지를 수행)입니다.

둘 다 성능과 latency가 중요해서 원본 모델을 배포 환경에 맞게 최적화한 뒤 내보내는데, 테스트는 최적화된 최종 버전으로 해야 합니다. GPU에서는 요구사항을 맞췄어도 임베디드 장치에서는 양자화 처리 방식에 따라 성능이 크게 달라질 수 있습니다.

배포는 대개 스테이징 → 프로덕션 2단계입니다. 스테이징의 모델은 평가 모드로 돌며 프로덕션 모델과 비교되고, 평가를 통과하면 자동으로 프로덕션으로 옮겨집니다. 버전 관리와 lineage가 탄탄하면 롤백은 운영 모델을 바꾸는 것만큼 단순해집니다.

책의 첫 두 프로젝트는 BentoML로 HTTP 엔드포인트를 만들고 도커로 묶어 Yatai로 배포하며, LLM 프로젝트는 Chainlit으로 채팅 인터페이스를 냅니다. BentoML 서비스가 기본으로 노출하는 Prometheus 지표(RPS, HTTP 응답 코드)와 배치 처리(batching), 카나리 배포(canary), A/B 테스트도 다룹니다.

모니터링 (책 2.1.6)

입력 데이터의 변화, concept drift, 하드웨어·소프트웨어 장애로 모델 성능은 시간이 지나며 달라집니다. 잘못된 예측은 비즈니스에 실질적인 장애나 손해를 줄 수 있습니다. 책은 세 가지 모니터링을 듭니다.

• 데이터 모니터링 — 입력의 통계적 특성을 평가해 이상 징후와 data drift를 찾습니다.
• 성능 모니터링 — 프로덕션에서 정확도 같은 지표를 시간에 따라 추적합니다.
• 오류 모니터링 — 잘못된 예측을 모아 edge case에서의 동작을 이해하고 개선합니다.

알림이 닿지 않으면 없는 것과 같다

최고의 지표를 모두 기록하고 lineage를 상세히 유지해도, 알림과 지표가 담당자에게 전달되지 않으면 결과적으로 아무것도 안 갖춘 것과 다를 바 없다고 책은 강조합니다. 신뢰할 수 있는 알람·통보 시스템이 모니터링의 일부입니다.

책은 탐지된 drift에 대해 재훈련 실행을 찾아 트리거하는 도구로 Evidently를 새로 소개합니다. 로깅과 버전 관리를 함께 쓰면 규제 산업에서 중요한 문서화 수단도 됩니다.

유지보수·업데이트·검토 (책 2.1.7)

마지막 컴포넌트는 모니터링 결과로 버그를 고치고, edge case용 데이터를 더 모으고, drift에 대응해 재훈련하며 루프를 닫습니다. 책은 이것이 루프 전체에 흩어져 있다고 봅니다.

배포 컴포넌트가 운영 모델을 새 버전으로 바꾸는 것도, 데이터 수집이 drift를 반영해 갱신되는 것도 유지보수입니다. 프로젝트에서는 훈련 때 못 본 신분증이 들어올 때의 동작(즉시 교체 가능한 drop-in replacement가 될 수 있는지), 추천 모델의 새 아키텍처를 운영 모델과 나란히 평가하는 일, RAG의 Langfuse 관측과 가드레일·적대적 테스트·입력 정제·프롬프트 안정화·환각 테스트를 다룹니다.

2장 세 줄 요약

1. 정의 — 훈련된 모델은 코드·설정·데이터를 조합한 artifact이고, 실험 추적·버전 관리가 그 조합을 기록합니다.
2. 계산법 — F1은 precision과 recall의 조화평균이라 한쪽만 높으면 낮게 나오며, 임계값을 옮기면 둘이 맞바뀝니다. 평가는 버전이 관리되는 holdout으로 자동 실행합니다.
3. 쓰임 — 스테이징→프로덕션 2단계 배포, 데이터·성능·오류 모니터링과 담당자에게 닿는 알림, drift에 대한 재훈련이 루프를 다시 돌립니다.

— 여기까지: 반복 루프 전체(책 2.1절). 다음은 이 루프를 실제로 굴리기가 왜 어려운지, 잘 굴리면 조직이 무엇을 얻는지 —

03MLOps가 어려운 이유, 잘하면 얻는 것 (책 2.2·2.3절)

한 줄 요약: 루프의 블록마다 복잡성이 한 겹씩 쌓이고 움직이는 부품의 조합이 폭발하지만, 그것을 표준화한 조직은 속도·비용·협업·추적성에서 보상을 받습니다.

왜 이걸 배우나

단계마다 도구를 하나씩 붙이면 끝날 것 같은데, 왜 MLOps는 여전히 어렵다고 할까?

1~2장에서 본 단계 하나하나는 그럴듯해 보입니다. 하지만 블록이 모이면 서로의 버전과 결정이 얽혀 전체 그림을 잡기 어려워집니다.

이 장에서는 책 2.2절의 어려운 이유를 정리하고, 그중 "움직이는 부품이 많다"를 숫자로 확인한 뒤, 2.3절에서 성숙한 조직이 얻는 이점을 봅니다.

이 장에 나오는 낯선 말

기술 부채 (technical debt)

지금 빨리 가려고 미룬 정리 작업이 나중에 이자처럼 불어나는 비용입니다.

사일로 (silo)

팀마다 따로 쌓은 개발·인프라 체계입니다. 자원이 비효율적으로 쓰이고 모범 사례가 흩어집니다.

거버넌스 (governance) · 컴플라이언스 (compliance)

데이터와 모델을 다루는 규칙·책임 체계, 그리고 법규·규정을 지키는 것입니다. 설명 가능하고 해석 가능한 ML을 요구합니다.

도구 파편화 (fragmentation)

같은 문제를 푼다는 도구가 너무 많고, 각자 일부만 다루는 상태입니다. model registry만 해도 10가지가 넘는다고 책은 말합니다.

결정론적 (deterministic)

같은 입력이면 언제나 같은 출력이 나오는 성질입니다.

어려운 이유 (책 2.2절)

• 넓은 전문성 — 소프트웨어 공학, 고성능 컴퓨팅, CI/CD, 버전 관리, 통계까지 필요합니다.
• 블록마다 한 겹의 복잡성 — 데이터 수집 하나만 해도 대규모로 하려면 전문가가 필요하고, 좋은 해법에 수렴할 때까지 컴포넌트와 인프라를 계속 조정해야 합니다.
• 데이터 — 가시성을 해치지 않으면서 대규모로 관리하고, 프라이버시와 보안을 지키고, 공정성·다양성·편향 배제를 유지해야 합니다. 비용이 크고 법적 위험도 있습니다.
• 시스템 복잡성 — 관리·추출·annotation·버전 관리·EDA·훈련·배포·모니터링을 모두 갖춘 시스템은 움직이는 부품이 너무 많아 구조적 결함을 진단하기 어렵습니다.
• 역할마다 다른 언어 — 데이터 과학자는 precision·recall·F1을, ML 엔지니어는 model registry·서빙 latency·배포 시간·스케일링을 말합니다. 같은 언어로 이해해야 루프가 돕니다.
• 최적화와 스케일링 — 과부하에 실패하는 모델은 가치가 없고, 최적화한 모델은 성능 특성이 원본과 크게 다를 수 있습니다.
• 지저분한 실세계 데이터 — edge case에 대비하지 않으면 오류가 나거나, 최악의 경우 눈에 띄는 오류 없이 출력이 왜곡됩니다.
• 거버넌스와 도구 파편화 — 설명 가능성과 편향 해소를 요구받는데, 포괄적인 도구는 드물고 데이터 관리·lineage 같은 측면을 놓치는 경우가 많습니다.

그래서 작은 팀은 견고한 MLOps를 건너뛰고 빠르게 만드는 쪽을 택하기 쉽습니다. 단기·단일 모델에서는 통하지만, 장기적으로는 막대한 기술 부채가 쌓여 모델을 유지할 수 없게 됩니다.

비유 먼저 — 옷장 코디

셔츠 3벌, 바지 3벌, 신발 3켤레가 있으면 코디는 27가지입니다. 사진 한 장만 보고 그날 어떤 조합이었는지 맞히려면, 그날 무엇을 입었는지 적어 둔 기록이 있어야 합니다.

ML 시스템의 부품(데이터, 코드, 설정, feature, 모델, 환경)도 각자 버전이 있습니다. 운영 중인 모델 하나가 어느 조합에서 나왔는지는 기록 없이는 알 수 없습니다.

숫자로 한 번

부품 3개(데이터·코드·설정) × 각 3개 버전 = 3 × 3 × 3 = 27가지
feature·환경까지 5개 부품이면 = 3 × 3 × 3 × 3 × 3 = 243가지
lineage가 있으면 = 1가지 ── 기록이 운영 모델의 조합을 특정함

그림 7

움직이는 부품이 많아지면 — 조합 수와 lineage

↔ 슬라이더 · 토글

해볼 것 — ① 기본값(부품 4개 × 버전 3개)에서 회색 선 하나하나가 가능한 연결입니다. 오른쪽 "운영 중인 모델"이 81가지 조합 중 어느 것인지 알 수 없어 적색 테두리가 붙어 있습니다. ② [lineage 기록]을 켜면 남색 경로 하나만 남습니다. 조합이 하나로 특정됩니다. ③ 기록을 끈 채 부품을 6개, 버전을 5개로 올려 보세요. 조합이 15,625가지로 늘어 선이 화면을 덮습니다.

부품 수 4 부품마다 버전 수 3

※ 주: 부품 이름과 버전 수는 설명용 · 조합 수 = 버전 수를 부품 수만큼 곱한 값(정확한 계산)

성숙한 조직이 얻는 것 (책 2.3절)

ML 조직이 성숙하면 견고한 MLOps가 모델의 개발·배포·관리·모니터링·최적화를 굴리는 핵심 동력이 됩니다. 책이 꼽는 이점은 여섯 가지입니다.

이점	내용
혁신과 실험 가속	인프라를 추상화하고 버전 관리·lineage·A/B 테스트 환경을 갖추면 데이터 과학자가 모델 개발과 빠른 반복에 집중합니다.
비용 최적화	팀별 사일로 대신 중앙 전략으로 컴포넌트를 공유하고, 자원 배분·자동 스케일링·비용 모니터링을 관리합니다.
팀 간 협업	서로의 활동이 보이고 워크플로마다 표준 도구가 있어 도메인 경계를 넘어 함께 일합니다.
효율성 향상	데이터 마이닝·전처리·feature engineering·훈련·배포의 반복 작업을 자동화해 실수를 줄이고 결정론적인 출력을 보장합니다.
반복성·추적성	모델 변화가 보이고, 모니터링·디버깅·롤백 방법이 있고, lineage로 훈련 설정과 데이터셋을 추적해 오프라인에서 디버깅합니다.
강력한 스케일링	공통 워크플로와 최적화된 자원 배분으로 대규모 데이터 처리를 표준화합니다.

좋은 MLOps는 올바른 습관의 문턱을 낮춘다

모델 로깅이 훈련 코드에 미리 들어가 있으면, 데이터 과학자는 훈련 실행을 손으로 관리하거나 임시 보고서를 쓰는 대신 기본으로 버전 관리와 로깅을 쓰게 됩니다. 성숙한 조직에서 MLOps는 사람·전문성·프로세스·모범 사례를 한데 모아 모든 컴포넌트를 쓰기 좋게 만드는 일입니다.

3장 세 줄 요약

1. 정의 — MLOps가 어려운 이유는 넓은 전문성, 블록마다 쌓이는 복잡성, 데이터 관리, 역할 간 언어 차이, 스케일링, 실세계 데이터, 거버넌스, 도구 파편화입니다.
2. 계산법 — 부품마다 버전이 있으면 가능한 조합은 버전 수를 부품 수만큼 곱한 만큼 늘고, lineage 기록이 그중 하나를 특정합니다.
3. 쓰임 — 표준화된 MLOps는 실험 속도, 비용, 협업, 효율, 추적성, 스케일링에서 보상을 주고 기술 부채를 막습니다.

— 여기까지: 어려운 이유와 얻는 것. 다음은 "그럼 DevOps와 뭐가 다른가"라는 질문 —

04DevOps vs MLOps (책 2.4절)

한 줄 요약: 자동화·CI/CD·다학제성은 같지만, MLOps는 데이터를 핵심 컴포넌트로 다루고 코드가 그대로여도 나빠지는 모델을 지속적 훈련(CT)으로 붙잡습니다.

왜 이걸 배우나

MLOps는 DevOps에 데이터만 얹은 것 아닌가? 왜 따로 부를까?

인프라·백엔드 쪽에서 보면 MLOps의 상당 부분이 익숙합니다. 파이프라인, 컨테이너, 배포 자동화, 모니터링. 그래서 차이가 어디서 생기는지 짚지 않으면 ML 시스템을 일반 서비스처럼 운영하게 됩니다.

이 장에서는 책 2.4절의 공통점과 차이점을 표로 정리하고, 차이의 핵심인 "코드가 그대로인데 성능이 떨어지는" 현상을 그림으로 봅니다.

이 장에 나오는 낯선 말

CT (continuous training, 지속적 훈련)

새 데이터나 성능 하락을 계기로 모델을 자동으로 다시 훈련하는 것입니다. CI/CD에 ML이 더한 축입니다.

generalist

여러 도메인에 두루 익숙한 사람입니다. DevOps와 MLOps 모두 이런 다학제(multidisciplinary) 역할을 자주 필요로 합니다.

해석 가능성 (interpretability)

모델이 왜 그런 답을 냈는지 사람이 이해할 수 있는 정도입니다.

비유 먼저 — 계산기와 일기예보관

계산기는 코드를 바꾸지 않으면 1 + 1을 영원히 2라고 답합니다. 일반 소프트웨어가 그렇습니다.

일기예보관은 다릅니다. 같은 사람, 같은 방법인데도 기후가 바뀌면 예전 경험이 점점 덜 맞습니다.

ML 모델이 그렇습니다. 그래서 새 날씨 기록으로 다시 공부(재훈련)해야 합니다.

구분	DevOps	MLOps
공통	강력한 자동화 지향 · CI/CD 철학(자동 테스트, 프로덕션 자동 배포) · 다학제적이며 generalist가 필요
주된 대상	소프트웨어와 인프라의 수명주기	모델의 훈련·배포·모니터링·최적화
데이터	같은 수준의 엄격함을 두지 않음	모델과 프로세스의 필수 컴포넌트, 데이터 수명주기 관리에 큰 비중
변화의 원인	코드 변경	코드 변경이 없어도 모델이 계속 변함 → CT, 모델 관리·버전 관리
품질 기준	기능·성능 테스트	해석 가능성과 편향까지 · 합의된 기준 준수 모니터링
모니터링	서비스 상태	입력 데이터 변화로 인한 모델 성능 저하 — 일반 SW보다 더 다양한 방식으로 나빠짐(Google)
추적 대상	빌드	빌드 + 실험 자체 — 본질적으로 실험적·반복적

숫자로 한 번

배포 때 정확도 0.92인 모델이 data drift로 매달 0.01씩 떨어지고, 운영 기준이 0.85라고 해 봅시다(예시 값).

7개월째: 0.92 − 0.07 = 0.85 → 아직 기준선
8개월째: 0.92 − 0.08 = 0.84 < 0.85 → 기준 미달 — 코드는 한 줄도 안 바뀜
CT를 켜면: 8개월째 재훈련 → 0.92로 복귀, 16개월째 다시 재훈련

그림 8

코드는 그대로인데 성능이 떨어진다 — CT 켜고 끄기

↔ 슬라이더 · 토글

해볼 것 — ① 기본값(월 0.010 drift, CT 꺼짐)에서 회색 실선(일반 SW)은 평평하고, 남색 선(ML 모델)만 내려가 8개월째부터 기준선 아래로 적색이 됩니다. ② [CT 켜기]를 누르면 기준선에 닿을 때마다 재훈련되어 파란 선으로 0.92까지 돌아옵니다. 오른쪽 재훈련 횟수를 보세요. ③ drift를 0으로 내리면 ML 모델도 일반 SW처럼 평평합니다. 데이터가 변하지 않으면 CT가 할 일이 없습니다. 0.020으로 올리면 4개월마다 재훈련이 필요해집니다.

월별 drift (정확도 하락폭) 0.010 운영 기간 커서 (개월) 12

※ 주: 정확도 0.92, 기준 0.85, 월별 하락폭은 개념을 보여 주려는 예시 — 실측 아님 · 실제 drift는 직선으로 떨어지지 않고 계절성이나 급변이 섞입니다

4장 세 줄 요약

1. 정의 — DevOps와 MLOps는 자동화·CI/CD·다학제성을 공유하지만, MLOps는 모델과 데이터의 수명주기를 다룹니다.
2. 성질 — 코드 변경 없이도 데이터가 변하면 모델 성능이 떨어지므로, 성능 모니터링과 지속적 훈련(CT), 실험 추적이 추가로 필요합니다.
3. 쓰임 — 기존 DevOps 역량(pipeline, 배포, 모니터링)을 그대로 쓰되, 데이터 버전·모델 성능·재훈련 트리거를 운영 대상에 넣습니다.

— 여기까지: DevOps와 갈리는 지점은 데이터와 CT. 마지막은 이걸 얼마나 자동화했는지로 조직의 위치를 재는 성숙도 —

05MLOps 성숙도 수준 — Level 0·1·2 (책 2.5절)

한 줄 요약: Level 0은 전부 수동, Level 1은 데이터가 바뀌면 재훈련 pipeline이 자동으로 돌고, Level 2는 코드가 바뀌면 pipeline 자체의 빌드·배포까지 자동입니다.

왜 이걸 배우나

우리 팀은 지금 어디쯤이고, 다음에 무엇을 자동화해야 할까?

"MLOps를 도입하자"는 말은 범위가 너무 넓습니다. 무엇이 바뀌었을 때 무엇이 자동으로 도는지를 기준으로 보면 지금 위치와 다음 단계가 보입니다.

책은 Google의 구분을 빌려, 1장에서 본 루프의 각 단계가 얼마나 자동화되었는지를 성숙도의 지표로 씁니다. 새 모델 개발 속도와 변화에 대한 대응 속도와 바로 이어집니다.

이 장에 나오는 낯선 말

Level 0 · 1 · 2

Google 문서 "MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인"의 구분입니다. 0 수동 프로세스, 1 ML pipeline 자동화, 2 CI/CD pipeline 자동화.

실험-운영 대칭성 (experimental-operational symmetry)

개발 환경과 프로덕션 환경에서 같은 pipeline을 쓰는 것입니다. Level 1의 핵심 요소입니다.

ML metadata store

pipeline 실행마다 쓴 데이터·파라미터·결과를 기록하는 저장소입니다. lineage의 바탕이 됩니다.

트리거 (trigger)

pipeline을 시작시키는 계기입니다. 일정, 새 데이터 도착, 성능 저하 같은 것이 있습니다.

비유 먼저 — 빵집 세 곳

Level 0 빵집은 밀가루가 새로 들어오든 레시피가 바뀌든 제빵사가 반죽부터 진열까지 손으로 합니다.

Level 1 빵집은 생산 라인이 있어, 새 밀가루가 들어오면 반죽·굽기·진열이 알아서 돌아갑니다. 다만 레시피를 바꾸면 사람이 라인을 다시 세팅해야 합니다.

Level 2 빵집은 새 레시피를 등록하면 라인 재설정과 시험 굽기까지 자동이라, 제빵사는 레시피 연구만 합니다.

레벨	특징	무엇이 바뀌면 자동인가	사람이 하는 일
Level 0 · 기초	구축·훈련·배포를 수동 스크립트로. 모니터링 없음. 릴리스가 드묾. 배포 대상은 모델	없음	추출부터 배포까지 전부
Level 1 · 중급	실험 속도와 프로덕션의 지속적 재훈련. 배포 대상은 재훈련 pipeline 전체. 모듈식 컴포넌트를 팀 간 공유, 실험-운영 대칭성	데이터 → 재훈련·등록·서빙	pipeline 코드 배포
Level 2 · 고급	pipeline 자체의 빌드·배포 자동화. 데이터 분석·모델 분석을 빼면 거의 전부 자동. 조직 전체가 pipeline을 관리하고 데이터 과학자도 컴포넌트를 제안	코드 → 테스트·빌드·배포까지	실험하고 커밋

Level 1에 필요한 컴포넌트는 견고한 데이터·모델 검증, feature store(필요하면), pipeline 모니터링·lineage·메타데이터, 사용자 정의 트리거로 도는 자동 pipeline입니다. 레벨은 대략적인 기준이고 단계 간 난이도가 선형으로 오르지도 않지만, 자신의 위치를 알면 다음 단계를 계획하기 좋습니다. 책의 도구들은 모든 레벨에 맞춰 확장할 수 있습니다.

숫자로 한 번

한 달 동안 새 데이터가 4번 들어오고, 모델 코드(새 아이디어)가 1번 바뀌었다고 합시다. 사람이 직접 처리해야 하는 횟수는 이렇습니다.

Level 0: 4 + 1 = 5번 ── 무엇이 바뀌어도 사람이 처음부터
Level 1: 0 + 1 = 1번 ── 데이터는 자동, 코드 변경은 사람이 pipeline 배포
Level 2: 0번 ── 사람은 실험하고 커밋만, 나머지는 CI/CD

그림 9

성숙도 — 무엇이 바뀌면 무엇이 자동으로 도는가

↔ 레벨 슬라이더 · 사건 버튼

해볼 것 — ① 기본값(Level 1, 새 데이터 도착)에서 트리거 → 자동 pipeline → registry → 서빙이 남색으로 채워집니다. 사람 손이 닿지 않는 경로입니다. ② [코드 변경]을 누르면 Level 1에서는 "pipeline 배포" 상자가 남색 테두리(사람이 함)로 바뀝니다. 슬라이더를 2로 올리면 CI·CD가 그 자리를 채워 경로 전체가 자동이 됩니다. ③ 슬라이더를 0으로 내리면 자동 pipeline·트리거·모니터링이 회색 점선(없음)이 되고, 어떤 사건이든 사람이 실험부터 모델 전달까지 손으로 합니다.

성숙도 레벨 1 사건

※ 주: Google Cloud 문서의 Level 0·1·2 구성도를 단순화해 다시 그림 · 남색 채움 = 자동으로 도는 경로, 남색 테두리 = 경로 위에서 사람이 하는 단계, 회색 실선 = 있지만 이번 사건과 무관, 회색 점선 = 이 레벨에는 없음

5장 세 줄 요약

1. 정의 — 성숙도는 루프의 각 단계가 얼마나 자동화되었는지로 잽니다. Level 0 수동, Level 1 ML pipeline 자동화(CT), Level 2 CI/CD pipeline 자동화입니다.
2. 성질 — Level 1은 데이터 변화에, Level 2는 코드 변화에 자동으로 반응합니다. 배포 대상이 모델 → 재훈련 pipeline → pipeline을 만드는 pipeline으로 넓어집니다.
3. 쓰임 — "무엇이 바뀌면 무엇이 자동인가"로 지금 위치를 확인하고, Level 1 필수 컴포넌트(검증, feature store, 메타데이터, 트리거)부터 채웁니다.

마치며

처음 질문은 "무엇을 기록하고 무엇을 지켜봐야 할까"였습니다. 책 2장의 답은 루프 전체에 걸친 lineage와, 데이터가 변한다는 사실을 전제로 한 자동화였습니다. 책 3장부터는 이 개념들을 Kubernetes 위에서 실제 플랫폼으로 옮기기 시작합니다.

가져가실 것

1. 모델·데이터·하이퍼파라미터는 일시적입니다. 남겨야 하는 것은 그것들을 잇는 기록(lineage)입니다.
2. accuracy 하나로 모델을 고르지 않습니다. 목표 도메인이 precision과 recall 중 무엇을 더 아끼는지부터 정합니다.
3. "무엇이 바뀌면 무엇이 자동으로 도는가" 한 문장으로 우리 팀의 성숙도를 말할 수 있습니다.

다시 묻게 된 질문 — 꼭 MLOps를 써야 하는가

정리하면서 "꼭 MLOps를 써야 하는가?"라는 질문을 다시 생각하게 됐습니다. 이해관계자 질문의 첫 줄이 "왜 ML이 필요한가"였고, ①편에서 본 대로 휴리스틱 baseline으로 충분한 문제도 많습니다. 성숙도 레벨 역시 높을수록 좋은 점수라기보다, 지금 필요한 자동화가 어디까지인지 고르는 기준으로 읽혔습니다.

실무에서도 문제를 보면 플랫폼부터 떠올리기보다 더 단순하게 해결할 수 있는 방법은 없는지를 항상 먼저 생각하는 자세를 가져야겠습니다. 규칙 몇 줄이나 배치 스크립트로 풀리는 일이라면 그쪽이 운영 비용도 적습니다.

틀린 곳이 있다면

댓글로 알려 주시면 고치겠습니다. 참고한 자료는 MLOps 스터디 1주차 정리 노트, 원서 Machine Learning Platform Engineering(Manning) 2장, Google Cloud 문서 MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인, if(kakao)dev2022 "카카오뱅크의 MLOps" 발표, roadmap.sh MLOps 로드맵입니다.