모델보다 비즈니스 문제에서 출발하자 - MLOps를 떠받치는 생각의 뼈대
해당 포스팅은 현재 재직 중인 회사와 관련이 없고, 개인 역량 개발을 위한 스터디 자료로 활용할 예정입니다.
읽은 자료: Machine Learning Platform Engineering(Manning, 2026) 1~2장
머신러닝 프로젝트에서 모델을 고르는 일은 생각보다 늦게 찾아온다. 책의 1장에서 던지는 첫 질문은 "어떤 모델을 쓸까"가 아니라 "이 문제를 머신러닝으로 풀어야 하는가"이고, 2장은 배포가 끝이 아니라 시작이라고 말한다. 모델은 완성품이 아니라 목적을 위한 수단이며, 그 목적은 한 번의 배포로 달성되지 않는다. 저자들은 "첫 배포가 끝이었던 머신러닝 프로젝트를 본 적이 없다"고 말한다.
1~2장에서는 도구를 거의 사용하지 않는다. 대신 뒤 장들에서 반복될 사고의 기준을 세운다. 문제를 어떻게 정의하는가, 머신러닝 작업을 왜 하나의 루프로 보아야 하는가, 모델과 코드와 데이터의 리니지(lineage, 계보)를 왜 분리해 추적하는가, MLOps는 DevOps와 어디서 갈라지는가, 그리고 조직의 성숙도를 무엇으로 재는가. 그 다섯 가지 축을 따라 정리했다.
| 장 | 핵심 질문 | 이 글에서 짚는 것 |
|---|---|---|
| 1장: MLOps와 머신러닝 엔지니어링 시작하기 | 실험 결과를 신뢰할 수 있는 서비스로 옮기려면 무엇이 필요한가? | 머신러닝 수명주기, 필요한 역량, 플랫폼을 점진적으로 키운다는 관점 |
| 2장: MLOps란 무엇인가 | 배포 뒤의 변화를 어떤 구조로 다루는가? | 폐쇄 루프, 리니지와 재현성, MLOps가 어려운 이유, DevOps와의 차이, 성숙도 |
1. 머신러닝이 아니라 비즈니스 문제에서 출발한다
책이 가장 먼저 경계하는 것은 "머신러닝이라는 만능 망치"를 향해 손을 뻗고 싶은 충동이다. 단순한 휴리스틱으로 풀리는 문제라면 그것으로 충분하다. 머신러닝은 패턴이 복잡하고 비선형이며 고차원인 데이터를 다룰 때, 즉 규칙으로는 감당하기 어렵다는 근거가 생길 때 비로소 후보가 된다. 비즈니스와 기술 담당자가 함께 "머신러닝이 정말 최적의 해법인가"를 오래 고민한 뒤에야 첫 단계로 넘어간다.
흥미로운 지점은 이 판단이 기술적 선택이 아니라 협업의 결과라는 데 있다. 저자들은 문제 정의를 비즈니스/제품, 기술, 법무·준법 세 집단이 함께 답해야 하는 질문 묶음으로 제시한다. "고객 이탈률을 예측하라" 같은 문장은 모델을 만들기에도 평가 기준을 세우기에도 불충분하다. 무엇을 성공으로 볼지, 틀린 예측의 비즈니스 비용은 얼마인지, 허용 가능한 오류 범위는 어디까지인지가 먼저 합의되어야 한다.
| 관점 | 처음부터 물어야 할 것 |
|---|---|
| 비즈니스·제품 | 왜 머신러닝이어야 하는가? 성공 지표는? 틀린 예측의 비용과 허용 오차는? 로드맵의 어디에서 가치가 가장 큰가? |
| 기술(머신러닝·데이터) | 머신러닝으로 풀 수 있는가? 데이터는 어디에 어떻게 저장되는가? 어떤 지표로 평가하는가? 재훈련을 무엇이 트리거하는가? |
| 법무·준법 | 윤리·프라이버시 우려는? 민감 정보는 어떻게 다루는가? 데이터 거버넌스 요건은? |
이 질문들을 초기에 함께 던지는 이유는 명확하다. 범위와 산출물을 분명히 하고, 비즈니스 목표와 기술 구현을 정렬하고, 잠재적 난관을 일찍 발견하고, 데이터 과학자와 머신러닝 엔지니어가 같은 언어로 대화하게 만들기 위해서다. 책의 메시지는 모델의 정확도보다 한 걸음 앞에 있다. **"문제의 정의가 틀리면 그 위에 쌓는 모든 것이 틀린다"**는 것이다.
2. 수명주기는 되돌아가는 길을 포함한다
1장은 머신러닝 수명주기를 두 단계로 나눈다. 하나는 실험 단계이고, 다른 하나는 개발·스테이징·프로덕션 단계이다.
실험 단계는 문제 정의 → 탐색적 데이터 분석(EDA) → 데이터 수집·준비 → 데이터 버전 관리 → 모델 훈련 → 모델 평가 → 모델 검증으로 이어진다. 하지만 저자들이 강조하는 것은 이 화살표가 한 방향이 아니라는 점이다. 모델 평가 지표가 기준에 못 미치면 다른 구조를 시도하거나, 더 거슬러 올라가 데이터 품질을 다시 점검한다. 단계 사이의 흐름은 비선형이고 루프를 포함한다. 그래서 이 과정을 오케스트레이션된 파이프라인으로 묶으면, 처음부터 자동화를 넣어 추적하기 어려운 실수를 줄일 수 있다.
프로덕션 단계는 얼핏 실험 단계와 닮았다. 데이터 버전 관리, 훈련, 평가, 검증이 양쪽에 모두 등장한다. 차이는 두 가지다. 첫째, 실험 단계에서 "대체로 자동화된" 파이프라인을 프로덕션 단계에서는 완전히 자동화한다. 둘째, 파이프라인 끝에 모델 배포가 붙고, 그 결과물은 보통 REST API 형태의 머신러닝 서비스가 된다. CI나 프로그래밍 방식의 트리거가 파이프라인을 깨우고, 성능 지표가 임계값 아래로 떨어지면 트리거가 다시 작동해 전 과정이 반복된다.
여기서 책이 짚는 두 가지 통찰이 특히 와닿는다.
- 모델 훈련은 생각만큼 시간을 많이 차지하지 않는다. 머신러닝에 처음 입문한 사람들은 훈련이 대부분의 시간을 차지한다고 여기지만, 저자들의 경험은 반대다. 데이터 관련 난관, 특히 충분한 품질의 훈련 데이터를 확보하는 일이 가장 까다롭다.
- 배포는 일의 끝이 아니다. 부하 테스트, 오토스케일링, 버전 관리, 롤백 전략이 모두 배포의 일부다. 모델은 "첫 접촉에서 살아남지 못한다"는 표현처럼, 프로덕션 데이터를 만나면 평가 때만큼 잘하지 못하는 경우가 흔하다.
3. 머신러닝 엔지니어는 세 영역을 잇는 사람이다
1장은 MLOps를 소프트웨어 엔지니어링, DevOps, 데이터 과학이 겹치는 자리로 그린다. 중요한 메시지는 "처음부터 모든 것의 전문가일 필요는 없다"는 것이다. 핵심은 각 역량이 어떻게 맞물려 신뢰할 수 있는 머신러닝 시스템을 만드는지 이해하는 데 있다.
책이 꼽는 머신러닝 엔지니어의 전제 역량은 이렇다. 바탕에는 자명하지 않은 시스템을 실제로 배포해 본 경험이 깔려 있어야 한다. 그 위에 머신러닝과 데이터 과학에 대한 이해가 필요하지만, 역전파의 세부까지 통달할 필요는 없고, TensorFlow·PyTorch·scikit-learn 같은 프레임워크를 다루고 낯선 도구도 집어 들 수 있으면 된다. 그리고 데이터 엔지니어링 감각이 필요하다. 대개 가장 까다로운 것이 데이터 문제이기 때문이다.
그중 저자들이 반복해서 돌아오는 단어가 자동화와 재현성이다. 자동화는 실수를 줄이고 반복 주기를 빠르게 해 피드백을 앞당긴다. 재현성은 개발·스테이징·프로덕션에서 모델이 같게 동작하도록 보장하고, 규제·감사 대상이 되는 순간에는 선택이 아니라 필수가 된다. 책의 문장을 압축하면 재현 가능한 결과가 신뢰로 이어진다.
4. 플랫폼은 반복되는 질문에 답하기 위해 둔다
1장에서 가장 실용적인 조언은 플랫폼을 바라보는 태도다. Kubeflow, Feast, MLflow 같은 도구를 한꺼번에 설치하는 것이 출발점이 아니다. 저자들은 "만능 머신러닝 플랫폼은 없다"고 못 박고, 플랫폼을 점진적으로 키우라고 권한다. 벤더 제품(SageMaker, Vertex AI)을 이미 쓰더라도, 적어도 한 번은 밑바닥부터 직접 구성해 보는 경험이 각 도구가 왜 거기에 있는지 이해하게 해 준다는 것이다.
플랫폼의 구성요소는 결국 팀이 반복해서 받는 질문에 대응한다. 이 책에서 가장 자주 등장하는 개념 두 가지가 그 성격을 잘 보여 준다.
피처 스토어와 training-serving skew. 피처 스토어의 핵심 가치는 피처를 한 번 만들어 훈련과 서빙에서 함께 쓰는 데 있다. 피처는 두 가지 방식으로 제공된다 - 훈련·배치 추론을 위한 오프라인, 실시간 추론을 위한 온라인. 이 분리가 막아 주는 것이 훈련-서빙 왜곡(training-serving skew)이다. 훈련 때의 데이터 변환과 추론 때의 변환이 어긋나면 평가 점수는 좋아도 프로덕션에서 다른 예측이 나온다. 놓치기 쉬운 함정이고, 피처 스토어는 바로 이 지점을 정리해 준다.
모델 레지스트리와 리니지. 훈련 실행의 산출물은 모델 파일만이 아니다. 플롯 이미지, 메타데이터, 사용한 하이퍼파라미터가 모두 포함된다. 재현성을 위해 각 훈련 실행은 이 모든 것을 포착해야 한다. 모델 레지스트리는 메타데이터·파라미터·아티팩트·모델을 담고, 스테이징에서 프로덕션으로 모델을 승격하는 흐름을 가능하게 한다.
| 구성요소 | 주로 담는 것 | 답하려는 반복 질문 |
|---|---|---|
| 파이프라인 오케스트레이션 | 수집 → 훈련 → 평가 → 배포의 실행 순서 | 단계가 빠진 모델이 배포되지 않게 하려면? |
| 피처 스토어 | 피처 정의와 오프라인·온라인 제공 경로 | 훈련과 서빙의 입력 계산을 어떻게 일치시키나? |
| 실험 추적 | 실행별 파라미터·지표·아티팩트 | 어떤 변경이 성능을 바꿨는가? |
| 모델 레지스트리 | 검증된 모델 버전과 배포 단계 | 현재 버전과 되돌릴 버전을 어떻게 구분하나? |
| 서빙·배포 | API, 컨테이너, 배포 설정 | 같은 입력을 반복 가능하게 처리하려면? |
| 모니터링 | API 상태와 데이터·모델 품질 추이 | 문제가 어느 층에서 시작됐나? |
책은 이 토대가 LLM으로도 자연스럽게 확장된다고 예고한다. 전통적인 MLOps 구성요소는 그대로 남고, 문서 수집·벡터 데이터베이스·검색·가드레일·비용 관리 같은 LLMOps 요소가 덧붙는다. 파이프라인 오케스트레이션, 배포, 모니터링이라는 뼈대는 그대로 쓰인다는 것이 저자들의 일관된 주장이다.
5. 폐쇄 루프 - 2장이 세우는 중심 은유
2장의 중심에는 폐쇄 루프라는 은유가 있다. 머신러닝 가치는 한 번의 훈련이 아니라, 시간에 따라 스스로 개선되는 폐쇄 루프의 일부일 때 나온다. 저자들은 모델(가중치와 네트워크), 데이터, 하이퍼파라미터는 한시적인 것이고, 진화하는 대상은 루프 전체라고 보라고 한다.
이 관점이 실용적인 이유는, 프로젝트를 루프로 보면 모델이 바뀔 때를 대비한 프로세스를 자연스럽게 설계하게 되기 때문이다. 현실의 모델은 자주 바뀐다. 중고차 가격 예측 모델은 고객 수요와 시장 조건에 따라 진화하고, 상용·산업 차량용 버전이 파생될 수도 있다. 견고한 빌드·테스트·배포 워크플로가 있으면, 배포 자체에 발목 잡히지 않고 핵심 비즈니스 가치에 집중하면서 새 기능을 내보낼 수 있다.
루프는 문제 정의와 데이터 수집에서 시작해 EDA, 모델링·훈련, 평가, 배포, 모니터링을 지나 유지보수·검토로 닫힌다. 각 단계에서 책이 반복하는 교훈을 모으면 다음과 같다.
- 데이터 수집 - 이후 모든 단계가 이 단계의 편향을 물려받는다. 연구용 머신러닝은 품질이 검증된 공개 데이터셋을 쓰지만, 기업 머신러닝은 대개 데이터셋을 처음부터 만들어야 하고 배포 환경 데이터로 파인튜닝해야 한다. 관련성, 규모, 품질, 편향·누수 방지, 배포 환경을 닮은 분포, 그리고 리니지가 요건이다.
- EDA - 평균과 그래프를 그리는 절차가 아니라, 데이터에 대한 가정을 확인하는 첫 방어선이다. 저자들의 표현을 빌리면 **"모든 가정은 검증되기 전까지 위험"**이며, 그 가정을 데이터 파이프라인 초기에 검사로 고정해 두어야 한다.
- 모델링·훈련 - 리니지와 추적이 핵심이다. 모델·데이터 버전 관리, 실험 추적, 훈련 파이프라인, 하이퍼파라미터 탐색이 모두 "수작업 단계를 없애고 리니지를 남긴다"는 하나의 실로 꿰어진다.
- 평가 - 지표 선택이 곧 도메인 판단이다. 의료는 거짓 양성을 극도로 경계해 정밀도를 중시하고, 금융은 사건을 놓치는 손실을 피하려 재현율을 택하기도 한다. 평가는 누수를 막은 홀드아웃 데이터에서 자동으로 이뤄져야 하며, 홀드아웃도 훈련 데이터만큼 엄격하게 버전·리니지를 관리한다.
6. 모델은 코드만으로 재현되지 않는다
2장에서 가장 중요한 개념 하나를 꼽으라면 모델과 코드는 별개의 개체라는 선언이다. 같은 코드라도 훈련 데이터, 라벨, 초기 가중치, 피처 정의, 훈련 설정이 달라지면 다른 모델이 나온다. 반대로 같은 모델 파일이라도 서빙 전처리가 달라지면 다른 예측이 나온다.
그래서 저자들은 코드베이스를 모듈형으로 짜라고 권한다. 훈련된 모델을 "설정과 데이터를 코드베이스에 적용한 결과물(artifact)"로 보는 관점이다. 모델 구조나 훈련 방식을 바꾸는 일이 설정 파일 한 줄을 고치는 일이 되면 실험 속도가 빨라지고, 그 설정 파일을 Git으로 추적해 모델 리니지에 엮으면 강력한 디버깅과 내부 분석 능력이 생긴다. 과적합이 의심되면 설정값으로 모델 크기를 줄여 가설을 검증하는 식이다.
동시에 책은 과도한 파라미터화를 경계하라고 덧붙인다. 단순한 구성에서 시작해 반복적으로 개선하며 속도와 유연성의 균형을 잡으라는 것이다. 리니지가 중요하다는 말이 "모든 것을 미리 추상화하라"는 뜻은 아니다.
이 개념은 재현성의 실제 의미를 다시 정의한다. 난수 시드만 고정하면 완전히 재현된다고 믿기 쉽지만, 실행 환경과 라이브러리 버전, 전처리 과정까지 남겨야 "왜 어제와 오늘의 결과가 다른가"에 답할 수 있다. 리니지가 없으면 모델 A와 B를 비교할 때 서로 다른 평가 데이터로 비교하는 실수를 하기 쉽고, 구조를 바꿔 좋아진 것인지 더 쉬운 표본을 평가해 좋아 보이는 것인지 구분하지 못한다.
7. 배포 뒤의 모니터링 - 정상 응답과 좋은 예측은 다르다
배포는 모델이 가치를 내기 시작하는 지점이지 끝이 아니다. 2장은 모니터링을 세 갈래로 나눈다.
- 데이터 모니터링 - 입력 데이터의 통계적 성질로 이상을 탐지한다. 데이터 드리프트, 즉 프로덕션 입력이 훈련 데이터와 달라지는 현상이 핵심 감시 대상이다.
- 성능 모니터링 - 정확도 같은 지표를 시간에 따라 추적해 효과가 유지되는지 본다.
- 오류 모니터링 - 틀린 예측을 분석해 에지 케이스에서의 모델 행동을 이해하고 오류의 영향을 줄인다.
저자들이 강조하는 현실적 교훈은 "정상 응답과 좋은 예측은 다르다"는 것이다. API가 200을 반환했다고 그 대답이 유용했다는 뜻은 아니다. 그리고 아무리 좋은 지표와 로그, 리니지가 있어도 알림이 책임자에게 닿지 않으면 없는 것과 같다. 모니터링의 마지막 조각이 신뢰할 수 있는 알림 체계라는 지적은, 기술보다 운영 설계의 문제를 건드린다.
루프는 유지보수·업데이트·검토로 닫힌다. 모니터링 결과로 버그를 고치고, 에지 케이스 데이터를 모으고, 드리프트에 대응해 데이터 수집을 다시 돌린다. 중요한 점은 유지보수가 특정 단계가 아니라 루프 전체에 분산되어 있다는 것이다. 배포 단계에는 프로덕션 모델을 신버전으로 교체하는 유지보수가, 데이터 수집에는 드리프트를 처리하는 업데이트가 내장되어 있다.
8. MLOps는 왜 어려운가
2장에서 가장 솔직한 절은 "MLOps가 어려운 이유"를 나열한 대목이다. 이 목록은 도구 선택의 문제가 아니라 조직과 사람의 문제를 가리킨다.
- 블록마다 전문성이 필요하다. 데이터 수집 하나만 해도 대규모로 제대로 하려면 전문가가 필요하고, 루프의 모든 블록이 복잡성을 한 겹씩 더한다.
- 데이터 관리 비용과 위험이 크다. 가시성·프라이버시·보안을 지키며 대규모 데이터를 다루는 일은 비싸고, 공정성과 편향 제거까지 더하면 복잡성이 또 한 겹 쌓인다.
- 전문가들이 서로 다른 언어를 쓴다. 데이터 과학자는 정밀도·재현율·F1로 말하고, 머신러닝 엔지니어는 모델 레지스트리·서빙 지연·배포 시간으로 말한다. 루프가 돌아가려면 이들이 같은 언어로 대화해야 한다.
- 최적화와 스케일링은 뒤로 밀리지만 모델을 무너뜨릴 수 있다. 세상에서 가장 좋은 모델도 프로덕션에서 돌지 않거나 부하에서 깨지면 가치가 없다. 최적화 뒤의 성능 특성은 최적화 전과 크게 다를 수 있다.
- 현실 데이터는 혼돈스럽다. 에지 케이스와 잘못된 데이터는 눈에 보이는 에러 없이 출력을 왜곡할 수도 있다.
- 도구가 파편화되어 있다. 모델 레지스트리만 해도 10개가 넘고, 포괄적 해법은 드물며 대개 EDA·배포 같은 핵심만 다루고 데이터 관리·리니지 같은 결정적 영역을 놓친다.
그래서 작은 팀은 종종 견고한 MLOps 관행을 건너뛰고 빠른 해법을 택한다. 단기적으로, 혹은 모델 하나에는 통한다. 하지만 저자들은 이것이 막대한 기술 부채를 쌓아 장기적으로 모델을 유지보수 불가능하게 만든다고 경고한다. 이 경고가 책 전체의 동기이기도 하다.
9. DevOps와 MLOps는 어디서 갈라지는가
"MLOps는 그냥 DevOps의 확장 아닌가"라는 질문에 2장은 정면으로 답한다. 공통점은 분명하다. 둘 다 견고한 자동화를 지향하고, CI/CD 정신을 공유하며, 여러 영역에 걸친 제너럴리스트의 협업을 요구한다. 하지만 머신러닝 워크플로에는 DevOps와 구별되는 성질이 있다.
| 축 | DevOps에서 주로 보는 것 | MLOps가 추가로 보는 것 |
|---|---|---|
| 초점 | 소프트웨어·인프라 수명주기 | 모델의 훈련·배포·모니터링·최적화 |
| 데이터 | 상대적으로 덜 엄격 | 데이터를 모델의 핵심 구성요소로 보고 생애주기를 엄격히 관리 |
| 변경의 원천 | 주로 코드·설정 변경 | 코드 변경 없이도 데이터·설정만으로 동작이 바뀜 → 지속적 훈련(CT) |
| 관심사 | 빌드·배포 | 모델 해석 가능성과 편향, 컴플라이언스 |
| 성능 저하 | 비교적 예측 가능 | 입력 데이터 변화로 더 다양한 방식으로 저하 |
| 추적 대상 | 빌드 | 실험 자체를 추적 |
핵심 차이를 한 문장으로 줄이면, 데이터가 모델의 일부이고 모델은 코드 없이도 변한다는 사실이 MLOps에 지속 훈련과 엄격한 버전·리니지 관리를 요구한다는 것이다. 여기에 해석 가능성·편향·컴플라이언스라는 머신러닝 고유의 관심사가 더해진다.
10. 성숙도는 도구 개수가 아니라 자동화 수준으로 잰다
2장은 Google의 분류를 빌려 MLOps 성숙도를 세 단계로 나눈다. 기준은 도구의 개수가 아니라 루프의 단계들을 얼마나 자동화했는가이고, 이는 곧 새 모델을 내놓는 속도로 직결된다.
| 레벨 | 모습 | 특징 |
|---|---|---|
| 레벨 0: 기초 | 스크립트 수작업으로 빌드·훈련·배포, 모니터링 없음 | 대부분의 조직이 여기서 시작. 릴리스가 드물다 |
| 레벨 1: 중급 | 프로덕션에서 재훈련 파이프라인이 돌며 모델을 지속 전달 | 데이터·모델 검증, (필요시) 피처 스토어, 파이프라인 모니터링·리니지, 자동 트리거가 필요 |
| 레벨 2: 고급 | 파이프라인 자체의 빌드·배포까지 자동화 | 데이터·모델 분석을 뺀 거의 모든 것이 자동화. 파이프라인을 팀 전체가 소유 |
레벨 1의 핵심 개념이 실험-운영 대칭성(experimental-operational symmetry)이다. 모듈형 파이프라인 구성요소를 팀끼리 공유해, 개발과 프로덕션에서 같은 파이프라인을 쓰는 상태를 말한다. 레벨 2에서는 데이터 과학자도 관찰에 기반해 새 구성요소를 만들 수 있고, 파이프라인은 머신러닝 엔지니어만이 아니라 조직 전체의 자산이 된다.
저자들은 이 단계들이 난이도가 선형적으로 높아진다는 뜻도, 순위를 매기기 위한 것도 아니라고 분명히 한다. 중요한 것은 지금 조직의 병목이 어디인지 - 수작업 배포인지, 데이터 품질인지, 평가 부재인지 - 를 파악하고 다음 한 걸음을 고르는 것이다. 클러스터에 도구 몇 개를 띄웠다고 레벨 1에 도달한 것은 아니다.
11. 이론에서 실천으로 넘어가는 다리
2장은 이렇게 닫힌다. 개념과 조직의 관점에서 MLOps의 중요성, 어려움, 성숙 방식을 살폈으니, 다음부터는 이 이론적 이해를 확장 가능하고 신뢰할 수 있는 플랫폼으로 번역한다는 것이다. 그 번역의 첫 단추가 컨테이너화와 Kubernetes다. 3장이 Docker·Kubernetes·CI/CD·모니터링을 다루는 이유는 이 도구들이 머신러닝 전용이어서가 아니라, 대규모로 신뢰할 수 있는 머신러닝 시스템을 떠받치는 인프라 토대이기 때문이다.
바꿔 말하면 1~2장의 가치는 코드가 아니라 질문의 틀에 있다. 무엇을 정답으로 볼지, 예측 시점에 무엇을 알 수 있었는지, 어떤 오류가 더 큰 손실인지, 그리고 이 모든 결정의 리니지를 어떻게 남길지. 이 질문들은 이미지든 표 형식 데이터든 RAG든 사라지지 않는다. 책이 뒤에서 다루는 세 프로젝트 - 신분증 탐지(OCR), 영화 추천, 문서 질의응답(RAG) - 가 입력 형태만 다를 뿐 같은 뼈대를 공유하는 이유가 여기에 있다.
12. 읽고 남은 생각
가장 크게 바뀐 것은 질문의 순서다. "어떤 모델을 쓸까"는 늦게 와도 되는 질문이고, 먼저 와야 하는 것은 "이걸 머신러닝으로 풀어야 하는가", "틀렸을 때 비용은 얼마인가", "예측 당시 알 수 있던 값으로 평가했는가"다. 모델을 루프 안의 한시적 산출물로 보는 관점은, 배포를 끝이 아니라 관찰과 개선의 시작으로 바꾼다.
두 번째는 리니지에 대한 태도다. 리니지는 미래의 나를 위한 보험이 아니라, 지금 기술 부채를 얼마나 질지를 정하는 결정이다. 초기 속도를 위해 건너뛰면 나중에 복잡성으로 되돌아온다는 저자들의 경고는 작은 팀일수록 더 뼈아프게 다가온다. 모델과 코드와 데이터를 분리해 각각 버전으로 남기는 습관이, 결국 "왜 결과가 달라졌는가"에 답할 수 있는 유일한 길이다.
세 번째는 MLOps가 결국 사람과 조직의 문제라는 점이다. 데이터 과학자와 머신러닝 엔지니어가 다른 언어로 말하는 한 루프는 돌지 않는다. 도구를 늘리는 것보다, 병목을 찾아 다음 한 단계를 고르는 판단이 성숙의 척도다.