01. MLOps와 ML 엔지니어링 시작하기

✎ 이 문서 수정하기 GitHub에서 수정

1장은 모델을 만드는 일과 서비스로 운영하는 일이 어디서 달라지는지 설명합니다. 학습한 가중치가 있어도 전처리와 로딩 코드, 실행 환경이 맞아야 실제 추론이 가능합니다.

이번 장에서 가장 중요하게 본 부분은 모델 파일을 남기는 것과 모델의 출처를 남기는 일이 다르다는 점입니다. 배포만 자동화되어 있어도 어떤 데이터와 코드로 만든 모델인지 설명하지 못할 수 있습니다.

1.1 ML 생애주기

ML 생애주기는 문제 정의부터 데이터 준비, 학습, 평가, 배포와 개선까지 연결한 지도입니다. 직선처럼 그릴 수 있어도 실제로는 앞 단계로 자주 돌아갑니다. 지표가 나쁘다면 모델뿐 아니라 데이터와 문제 정의도 다시 봐야 합니다.

학습과 추론은 먼저 구분할 필요가 있습니다. 학습은 데이터와 정답을 이용해 모델의 가중치를 구하는 과정입니다. 추론은 이미 학습한 모델에 새 입력을 넣어 예측을 얻는 과정입니다. 새 사진 한 장을 받아 카드 위치를 찾는 API 요청이 들어올 때마다 모델을 다시 학습하는 것은 아닙니다.

1.1.1 실험 단계

실험의 첫 질문은 “이 문제에 ML이 필요한가?”입니다. 단순한 규칙으로 충분하다면 더 저렴하고 설명하기 쉬울 수 있습니다. ML이 필요하다면 어떤 의사결정을 개선할지와 성공 기준부터 정해야 합니다.

여기서 평가(evaluation)는 측정에, 검증(validation)은 의도한 용도에 적합한지 확인하는 데 초점을 둡니다. 조직마다 용어가 다를 수 있으므로 이름보다 절차와 책임을 합의하는 것이 중요합니다.

신분증 탐지를 예로 보면 학습 데이터는 사진만으로 구성되지 않습니다. 사진에서 카드가 어디에 있는지 표시한 경계 상자와 클래스 정보도 필요합니다. 사진은 입력이고 상자와 클래스가 정답입니다. 학습 결과는 이 대응 관계를 반영한 모델 가중치입니다.

데이터를 나누는 이유도 각각 다릅니다. 학습셋은 가중치를 학습하는 데, 검증셋은 모델과 설정을 선택하는 데 사용합니다. 테스트셋은 그 선택에 쓰지 않고 마지막 성능을 확인하는 용도로 남깁니다. 같은 영상에서 뽑은 거의 동일한 프레임이 학습셋과 테스트셋에 섞이면 새로운 촬영 상황에서의 성능을 과대평가하기 쉽습니다.

같은 코드라도 데이터가 바뀌면 다른 모델이 나옵니다. 계보(lineage)는 완성품에서 재료와 제조 이력까지 거슬러 올라가는 연결입니다. 여기서는 데이터, 코드, 설정과 실행, 결과의 관계를 뜻합니다.

    flowchart TD
    accTitle: 실험의 출처와 운영 피드백을 연결하는 ML 생애주기
    accDescr: 문제 정의 후 데이터, 코드, 설정을 학습 실행과 연결한다. 평가와 용도 검증을 거쳐 출시하고, 운영 관측 결과를 다음 실험으로 연결한다.
    A["문제와 평가 기준"] --> B["데이터 버전 + 코드 버전 + 학습 설정"]
    B --> C["학습 실행"]
    C --> D["평가 + 사용 목적 검증"]
    D --> E["모델 산출물 + 배포 버전"]
    E --> F["운영 관측과 개선 결정"]
    F -->|"다음 실험의 근거"| A
  

자동화는 마지막에 붙이는 장식이 아닙니다. 실험부터 준비, 학습, 평가를 파이프라인으로 묶으면 수동 순서와 누락을 줄이고 운영에서도 같은 절차를 재사용하기 쉽습니다. 다만 기록이 있다는 사실만으로 비트 단위의 동일한 결과까지 보장되지는 않습니다.

실험 결과가 나쁘면 가중치 파일만으로는 이유를 알기 어렵습니다. 어떤 이미지와 라벨을 썼는지, 분할은 어떻게 했는지, 전처리와 학습 설정은 무엇이었는지 함께 찾아야 합니다. 모델 파일을 보관하는 일과 모델을 다시 만들 수 있는 상태를 유지하는 일은 다릅니다.

1.1.2 개발, 스테이징, 프로덕션 단계

실험이 “어떤 방법이 좋은가?”를 찾는다면, 운영에서는 그 방법을 반복해서 안전하게 실행하고 바꾸는 능력이 중요합니다. 스테이징은 실제 출시 전 조합을 확인하는 검증 환경입니다. 여기서 확인한 모델, 전처리, 환경 조합이 프로덕션에도 일치해야 합니다.

운영에서는 모델을 API나 배치 작업으로 배포하고 부하, 오류, 데이터 변화, 예측 품질을 관측합니다. 새 데이터나 관측 결과가 재학습의 계기가 될 수 있지만 재학습 자동화와 무조건적인 자동 출시는 구분해야 합니다.

배포에는 가중치 외에도 입력을 모델이 기대하는 형식으로 바꾸는 전처리와 결과를 응답으로 만드는 코드가 포함됩니다. 학습에서는 이미지를 일정한 크기로 바꾸고 픽셀값을 정규화했는데 API에서는 원본을 그대로 넣는다면 같은 모델도 다른 입력을 받습니다. 이런 차이가 학습과 서빙 사이의 불일치입니다.

재학습은 새 후보를 만드는 과정이고 출시는 그 후보를 사용자에게 연결하는 결정입니다. 기존 모델보다 점수가 좋아도 특정 문서 유형에서 실패하거나 응답 시간이 늘었다면 출시를 보류할 수 있습니다. 문제가 생겼을 때는 모델만이 아니라 호환되는 전처리와 서비스 코드까지 함께 되돌려야 합니다.

배포 전에는 되돌릴 모델과 코드, 설정 조합을 정해 둬야 합니다. 새 모델의 점수뿐 아니라 실제 요청 지연과 자원 사용, 승인과 복구를 맡을 사람도 필요합니다.

1.2 MLOps에 필요한 역량

1.2.1 ML 엔지니어의 역량

ML 엔지니어는 알고리즘 하나만 잘 알아서는 부족합니다. 소프트웨어 설계, 테스트, 디버깅, 데이터 처리, 모델 평가, 실행 환경과 자동화를 연결해야 합니다.

예측 오류가 발생하면 코드 버그인지, 데이터 오류인지, 모델의 한계인지, 인프라 장애인지부터 좁혀야 합니다.

예를 들어 모델이 카드를 잘 찾지 못한다는 증상도 원인은 여러 가집니다. 이미지 회전 정보를 전처리에서 누락했을 수도 있고, 새 카메라의 촬영 조건이 학습 데이터와 다를 수도 있습니다. 모델 로딩 실패로 다른 버전이 실행되고 있을 가능성도 있습니다. 알고리즘 지식과 서비스 디버깅을 따로 떼기 어려운 이유입니다.

1.2.2 선수 지식

Python과 기본적인 ML 흐름을 이해하고, 익숙하지 않은 프레임워크, 운영 도구를 배울 준비가 필요합니다. 책은 Kubernetes 기초를 설명한 뒤 플랫폼을 점진적으로 붙이는 구성입니다.

한 사람이 모든 영역의 전문가여야 한다는 뜻은 아닐 것 같습니다. 데이터와 평가를 잘 아는 사람, 서비스와 인프라를 잘 아는 사람이 같은 실행 흐름을 보면서 책임과 연결 지점을 합의하는 것이 먼저입니다.

1.3 ML 플랫폼 구축

플랫폼은 도구를 모아 놓은 화면이 아니라 실험과 학습, 배포와 관측을 반복할 수 있게 하는 공통 기반입니다. 원천 데이터 수집과 데이터 웨어하우스 전체를 모두 플랫폼의 책임으로 넣을 필요는 없습니다. 어떤 입력을 받아 무엇을 제공하는지, 누가 운영하는지부터 정해야 합니다.

그림 1.4. ML 플랫폼의 구성. 출처: Machine Learning Platform Engineering, 1장.

이 그림은 위에서 아래로 내려오는 모델 개발 흐름과 옆에서 받쳐 주는 공통 기능을 함께 보여 줍니다.

1. 업무 요구에서 문제와 모델을 정의합니다. 어떤 문제를 풀지 결정하는 일까지 플랫폼이 대신하지는 않습니다.
2. 파란 영역에서는 데이터를 준비하고 모델을 학습한 뒤 평가하고 배포합니다. 파이프라인 오케스트레이션은 이 단계의 순서와 실행 의존성을 관리합니다.
3. 실험 추적에는 파라미터와 지표를 남깁니다. 모델 레지스트리에는 관리할 모델과 버전을 등록합니다. 둘을 연결해야 배포한 모델이 어느 실험에서 나왔는지 찾을 수 있습니다.
4. 아래의 Model API는 사용자 요청을 받습니다. 모니터링 결과는 다시 개선이나 재학습의 근거가 됩니다.

피처 스토어에서 나오는 선이 학습과 API 양쪽으로 연결되는 점도 중요합니다. 학습 때 계산한 특성을 실제 요청에서도 같은 의미로 제공해야 한다는 뜻입니다. 다만 그림의 부품을 전부 설치해야 한다는 의미는 아닙니다. 이미지 모델처럼 전처리가 서비스 안에서 끝나는 경우와 여러 팀이 공통 특성을 쓰는 표 데이터 모델은 필요한 구성이 다릅니다.

1.3.1 자체 구축과 구매

직접 구축하면 각 구성 요소의 역할과 한계를 파악할 수 있습니다. 그렇다고 실제 도입에서도 자체 구축이 항상 유리한 것은 아닙니다.

관리형 서비스는 구축 부담을 줄일 수 있지만 통합, 권한, 비용 관리가 남습니다. 자체 구축은 조정의 자유가 큰 대신 업그레이드와 장애, 사용자 지원을 감당해야 합니다. 같은 요구사항과 기간으로 총비용을 비교해야 합니다.

직접 구축하면 사용료가 사라진다는 식의 비교는 맞지 않습니다. 운영 담당자의 시간과 장애 위험도 비용입니다. 반대로 관리형이라고 플랫폼과 모델의 운영 책임까지 모두 없어지는 것도 아닙니다.

1.3.2 MLOps에서 LLMOps로

LLM 애플리케이션에서도 버전, 배포와 모니터링은 유효합니다. 여기에 문서 처리, 임베딩, 벡터 검색, 프롬프트, 답변 평가, 안전과 토큰 비용이 추가됩니다.

즉 모델 파일만이 아니라 어떤 문서와 인덱스, 프롬프트와 모델 API의 조합으로 답했는지도 추적해야 합니다. 이 장에서는 확장을 예고하고 자세한 구현은 후반부에서 다룹니다.

임베딩은 문서나 질문을 벡터로 표현하는 방식이고, 벡터 검색은 그 표현의 유사도를 이용해 관련 자료를 찾는 방식입니다. 여기서는 두 역할을 구분하는 정도로 이해했습니다.

1.3.3 책에서 사용하는 도구

MLflow를 설치했다고 데이터 품질이 보장되지는 않고, 피처 스토어를 넣었다고 학습, 서빙의 모든 차이가 사라지지도 않습니다. 도구 사이의 데이터와 설정을 일관되게 연결해야 합니다.

오케스트레이터는 모델을 학습하는 알고리즘이 아니라 작업을 실행하고 연결하는 쪽입니다. 실험 추적은 어떤 조건에서 어떤 결과가 나왔는지 기록하고, 레지스트리는 그중 어떤 모델을 관리하고 서비스할지 연결합니다. 역할이 겹쳐 보이는 도구를 비교할 때도 이 차이를 먼저 봐야 합니다.

새 도구를 제안할 때는 해결할 문제와 기존 체계와의 연결, 운영 담당자를 함께 정해야 합니다. 책의 조합이 모든 조직에 그대로 맞지는 않습니다.

Run, artifact와 피처 시점

MLflow 공식 문서에서 run은 한 번의 실행, experiment는 관련 실행을 묶는 단위, artifact는 가중치, 그래프처럼 실행이 남긴 파일 산출물로 구분합니다. 모델 파일을 저장하는 것과 그 모델을 만든 과정을 추적하는 것은 다른 일입니다.

피처 스토어는 모델 입력으로 쓸 특성값의 정의와 조회, 재사용을 관리합니다. Point-in-time join은 지금의 최신 값이 아니라 학습 샘플의 과거 기준 시점에 맞는 값을 붙이는 방식입니다.

    flowchart TD
    accTitle: 피처 조회에서 예측 기준 시점을 지켜야 하는 이유
    accDescr: 오전 10시의 예측을 재구성할 때 그 전에 관측되고 사용할 수 있던 값은 후보가 된다. 오전 11시의 값이나 나중에 보정된 값이 들어가면 미래 정보가 섞일 수 있다.
    T["재구성할 예측 시점, 오전 10시"]
    A["오전 9시에 관측, 제공된 피처"] -->|"조건에 맞으면 사용"| T
    B["오전 11시에 생긴 피처"] -.->|"예측 이후 값, 제외"| T
    C["오전 9시 값이지만 오후에 보정, 제공"] -.->|"당시 사용 가능 여부 별도 확인"| T
  

Feast의 point-in-time join 문서를 확인하면 이벤트 시각과 값이 실제로 만들어진 시각도 구분해야 합니다. 시간 컬럼 하나가 있다고 미래 정보 누수가 자동으로 막히는 것은 아닙니다. 저장소, 버전이 제공하는 시점 처리와 지연 도착, 보정 데이터 정책까지 확인할 부분입니다.

1.4 ML 시스템 만들기

1.4.1 프로젝트를 통해 배우는 것

프로젝트는 한 번 끝내는 튜토리얼이 아니라 데이터와 요구가 바뀌면 앞 단계로 돌아가는 생애주기의 연습입니다. 모델 성능이 낮으면 더 큰 모델부터 찾기보다 데이터와 평가의 가정도 다시 확인합니다.

신분증 객체 탐지, 영화 추천, 문서 기반 RAG는 데이터와 모델은 다르지만 준비 → 실행 → 검증 → 배포 → 관측 → 개선이라는 문제를 공유합니다. 이미지에서 익힌 데이터 전달과 배포 원칙을 표 데이터와 LLM에도 다시 적용하는 구조입니다.

1.4.2 세 프로젝트의 차이와 운영 질문

첫 프로젝트는 OCR이라는 넓은 문맥 안에 있지만 카드 위치를 찾는 객체 탐지와 글자 인식은 다른 작업입니다. 세 프로젝트를 비교할 때도 기능의 이름보다 실제 입력, 출력과 실패 비용을 구분해야 합니다.

플랫폼 경계와 책임

ML 플랫폼팀이 데이터 수집부터 모든 모델의 업무 성과까지 책임진다고 가정하면 경계가 무한히 커집니다. 플랫폼이 제공하는 기능, 모델팀이 결정하는 품질, 데이터팀이 보장하는 입력, 업무팀이 승인하는 출시 조건을 먼저 나눠야 합니다.

총비용은 라이선스나 클라우드 청구서만이 아닙니다. 구축, 통합 작업, 업그레이드, 온콜, 보안 검토, 사용자 지원과 향후 이전 비용을 같은 기간으로 비교해야 합니다. 오픈소스의 무료 사용과 무료 운영은 다릅니다.

모델 이력에 필요한 정보

중고차 가격 예측 모델이라면 다음 정보를 함께 관리해야 합니다.

채우기 어려운 항목은 모델링보다 먼저 합의해야 할 부분입니다.

질문

모델 성능이 좋아도 프로젝트를 중단할 수 있을까요?

문제 자체의 가치가 작거나 정답 수집과 운영 비용이 효과보다 클 수 있습니다. 평가 지표와 실제 의사결정의 관계를 먼저 설명해야 합니다.

플랫폼을 직접 만들어야 할까요?

반복되는 불편 하나를 기준으로 직접 구축, 관리형 서비스, 간단한 스크립트의 유지 비용을 비교해야 합니다. 학습을 위한 구축과 회사의 도입 결정도 분리할 필요가 있습니다.

REST API가 응답한다고 프로덕션 전환이 끝난 것은 아닙니다. 데이터 변화와 부하, 롤백도 고려해야 합니다.

마치며

처음에는 플랫폼을 구성하는 도구에 눈이 갔지만, 1장에서 더 중요하게 느낀 것은 모델의 생성 근거와 운영 책임을 연결하는 일이었습니다. 실험 기록과 데이터 버전, 코드와 배포 버전을 따로 보관하는 것만으로는 충분하지 않습니다.

어떤 모델이 왜 만들어졌고 어떤 근거로 배포됐는지 따라갈 수 있어야 합니다. 이후 장에서 도구를 보더라도 이 연결이 어디에서 만들어지는지 먼저 확인하려고 합니다.

이전: 책 전체 구성, 시리즈 목차, 다음: 02. MLOps란 무엇인가