MLPE 스터디 1주차 - ML 수명주기의 두 국면

Machine Learning Platform Engineering 1장을 읽고 정리한 글이다.

1. ML 프로젝트가 소프트웨어 프로젝트와 다른점

소프트웨어 프로젝트는 안정성을 우선하며 배포한 것이 그대로 돌기를 기대한다.

ML 프로젝트는 맞는 접근을 미리 알 수 없어서 시행착오의 연속이고 단계 사이 흐름이 비선형적이다. 학습을 돌려본 뒤 데이터 준비로 되돌아가는 일이 흔하다.

2. 두가지 국면

같은 단계 이름이 양쪽에 다 나온다는 데서 이 구분이 중요해진다. 데이터 버전 관리, 모델 학습, 평가, 검증이 양쪽 모두에 있다.

두 국면은 누가 언제 실행하는지가 다르다. 실험 국면에서는 사람이 필요할 때 돌리지만 프로덕션 국면에서는 CI나 프로그램 호출이 트리거가 되어 단계들이 연쇄로 실행된다.

프로덕션 국면에서만 새로 등장하는 단계는 모델 배포, 모니터링, 재학습 셋이다.

3. 실험 국면

첫 질문은 “ML을 써야 하는가”

1장의 첫 조언이다. 단순 휴리스틱으로 되는 일도 있으니 ML로 손을 뻗고 싶은 충동을 억누르라고 적혀 있다. 이 결정은 기술 쪽에서 혼자 정하지 않고 비즈니스·제품 쪽과 함께 결정한다.

데이터 버전 관리를 코드와 같은 급으로 둔다

코드를 바꾸면 소프트웨어 동작이 바뀌지만 ML에서는 데이터를 바꿔도 동작이 바뀐다. 난이도는 전혀 다르다. 코드는 git으로 끝나지만 데이터는 형태가 제각각(이미지, CSV, 파케이)이라 별개의 문제가 된다.

평가와 검증은 주체가 다르다

용어가 비슷해 섞어 쓰기 쉽지만 검증은 지표 대신 사람의 판단이 들어가는 단계다.

학습은 처음부터 자동화한다

데이터셋과 전략이 정해지면 학습은 자동화할 수 있다. 처음부터 자동화해두면 데이터 사이언티스트가 실험을 값싸게 돌린다는 논리다.

4. 프로덕션 국면

ML 첫 모델이 라이브 데이터를 만나면 평가 때만큼 성능이 나오지 않는다. 재학습 시점은 “상황에 따라 다르다"로 열어두고 원칙은 단 하나만 둔다. 가능한 한 자동화돼 있어야 한다.

5. 플랫폼은 네 가지로 구성된다

1장에서는 전제부터 밝힌다. 만능 아키텍처는 없다. 구성요소는 그 위에서 넷으로 정리한다.

피처 스토어

세 부분으로 나뉜다.

• 피처 서버(REST/gRPC 서빙)
• 피처 레지스트리(카탈로그)
• 피처 스토리지(영속 계층)

서빙 모드는 학습·배치 추론용 오프라인과 실시간 추론용 온라인 둘이다. 같은 피처를 두 경로로 내보내야 하므로 일관성 문제가 따라온다.

모델 레지스트리

학습을 한 번 돌리면 모델 파일과 함께 플롯 이미지, 메타데이터, 하이퍼파라미터가 산출물로 나온다.

레지스트리는 스테이징에서 프로덕션으로 승격하는 데 가장 실용적으로 쓰인다. 서비스가 레지스트리에서 모델을 가져가도록 구성하면 승격이 곧 배포가 된다.

6. 직접 만들 것인가 사서 쓸 것인가

SageMaker나 Vertex AI를 이미 쓰는데 왜 직접 만들어보냐는 질문에 대한 답이다. 직접 만들어보면 도구들이 어떻게 맞물리는지 깊게 이해하게 되고 한계에 부딪혔을 때 넘어설 방법을 알게 된다.

SageMaker 서빙 옵션을 정리한 글을 쓸 때 느낀 것과 같다. 관리형 서비스는 선택을 줄여주는 대신 왜 그 선택인지를 가린다.

7. MLOps에서 LLMOps로

1장 끝에는 12·13장의 방향이 미리 나온다. 전통적 MLOps 구성요소는 그대로 남고 그 위에 덧붙이는 구조다.

• 의미 검색을 위한 벡터 데이터베이스
• LLM 안전을 위한 가드레일
• 비용 최적화와 프롬프트 관리

책은 파이프라인 오케스트레이션·모델 배포·모니터링 역량이 그대로 쓰인다고 강조한다.