Amazon SageMaker

모델을 직접 학습하고 배포하려는데 노트북 환경, GPU 학습 잡, 모델 저장, 추론 엔드포인트를 각각 따로 꾸리면 실험보다 인프라 준비가 더 오래 걸립니다. 팀마다 환경이 달라지면 같은 모델도 재현하기 어려워집니다.

초기 ML 팀은 데이터 준비, 학습, 배포 각 단계마다 환경을 따로 꾸려야 했습니다. 노트북에서 실험한 코드가 GPU 학습 잡에서 다른 버전의 라이브러리와 충돌하거나, 학습이 끝난 모델을 서빙 환경에 올렸더니 패키지 버전 불일치로 배포가 실패하는 일이 반복됐습니다. 단계마다 환경이 달라 재현도 어렵고, 인프라 설정을 고치는 데 실제 모델 개선보다 더 많은 시간이 소모됐습니다. 이런 압박을 해소하기 위해 ML 수명주기 전체를 하나의 플랫폼으로 통합한 SageMaker가 필요해졌습니다.

SageMaker는 ML 수명주기를 네 단계의 인과 흐름으로 연결합니다. 먼저 노트북에서 데이터를 탐색하고 모델 아이디어를 빠르게 실험합니다. 실험이 가능성 있어 보이면 학습 잡으로 넘겨 GPU 인스턴스에서 대규모 데이터셋으로 실제 학습을 돌립니다. 이때 HPO(Hyperparameter Optimization, 하이퍼파라미터 자동 최적화)를 걸면 학습률이나 배치 크기 같은 설정을 여러 조합으로 동시에 시도해, 사람이 일일이 바꿔가며 실험하는 시간을 줄여 줍니다. 학습이 끝나면 모델 파일(아티팩트)이 S3에 저장되고, 이 아티팩트를 추론 엔드포인트로 배포해 애플리케이션이 예측 요청을 보낼 수 있게 됩니다. 각 단계는 ECR(Elastic Container Registry)에 등록된 컨테이너 이미지를 기반으로 실행 환경을 고정합니다. 노트북에서 쓴 라이브러리 버전과 학습·배포 환경의 버전이 같은 이미지에서 나오므로, '실험에서는 됐는데 배포에서 안 되는' 환경 차이 문제를 막을 수 있습니다.

SageMaker와 Bedrock은 둘 다 AI 서비스지만 접근 방식이 다릅니다. SageMaker는 직접 모델을 학습·튜닝·배포하는 플랫폼이고, Bedrock은 관리형 파운데이션 모델 API를 소비하는 서비스입니다. 자체 데이터로 모델을 만들고 운영해야 하면 SageMaker를 보고, 이미 준비된 모델을 호출해 기능을 붙이는 게 목적이면 Bedrock을 보면 됩니다.

추천팀이 매주 사용자 행동 로그로 모델을 재학습하고, 새 모델의 정확도를 확인한 뒤 A/B 테스트용 엔드포인트를 교체하는 운영 루프가 대표적입니다. 금요일에 학습 잡을 돌리고 월요일에 새 엔드포인트를 올리는 주간 사이클을 SageMaker Pipelines로 자동화하면, 모델 갱신이 배포 부담 없이 반복됩니다. 이상 탐지 팀이라면 실시간 트래픽 데이터를 S3에 쌓아두고 야간에 재학습을 걸어 모델을 갱신한 뒤, 기존 엔드포인트를 블루/그린으로 교체하는 패턴을 씁니다. 모델 성능이 떨어지는 신호가 보이면 SageMaker가 재학습을 트리거하도록 파이프라인을 짜 두면 수동 개입을 줄일 수 있습니다. 자체 데이터로 모델을 직접 학습하지 않고 파운데이션 모델 API만 호출하는 경우에는 과합니다.