머신러닝 인프라를 처음 설계하는 엔지니어가 가장 자주 빠지는 함정은 "모델을 EC2에 띄우고 Flask로 서빙하면 되지 않나"라는 생각이다. 실제로 모델 하나를 띄우는 것 자체는 어렵지 않다. 문제는 그 다음이다. 데이터가 바뀌면 모델 성능이 조용히 무너지고(drift), 학습 때 쓴 피처와 추론 때 쓰는 피처가 미묘하게 달라져 정확도가 떨어지고(train-serve skew), 모델을 새로 배포할 때마다 다운타임이 생기고, GPU 인스턴스 비용이 month-end에 청구서로 돌아와 충격을 준다. SageMaker는 이 "모델 이후의 모든 것"을 관리형으로 묶은 플랫폼이다. SAP-C02 시험에서 SageMaker는 단일 기능이 아니라 **"어떤 추론 패턴을 고를 것인가", "학습 비용을 어떻게 90% 줄일 것인가", "재학습을 어떻게 자동화할 것인가"**라는 아키텍처 의사결정으로 출제된다.
오늘은 SageMaker의 컴포넌트를 나열하는 대신, ML 라이프사이클이 왜 그렇게 생겼는지, 추론 엔드포인트 4종이 각각 어떤 물리적 제약에서 갈라지는지, 그리고 Spot 학습의 비용 수학이 어떻게 성립하는지를 분해한다.
전통적인 소프트웨어는 코드를 배포하면 그 동작이 고정된다. 입력 X에 대해 항상 같은 출력 Y를 낸다. 머신러닝 시스템은 다르다. 모델의 동작은 학습 시점의 데이터 분포에 묶여 있고, 세상이 변하면 그 분포가 변한다