프레임워크 전용 클래스를 대체하는 ModelTrainer
알고리즘 코드를 수정할 때마다 Docker 이미지를 다시 빌드하고 ECR(Amazon Elastic Container Registry)에 푸시해야 했던 과정이 사라졌다. 기존 워크플로우에서는 하이퍼파라미터 수정이나 로직 변경 시에도 이미지 생성, 태깅, 업로드 단계를 반드시 거쳐야 했다. SDK v3는 로컬 소스 코드를 런타임에 컨테이너로 직접 동기화하는 방식을 도입해 코드 수정이 즉시 실행으로 이어지도록 변경했다.
이번 업데이트의 핵심은 SDK v3가 기존 구조를 처음부터 다시 설계(redesign from scratch)했다는 점이다. SKLearn, PyTorch, XGBoost 등 개별 프레임워크마다 별도로 존재하던 Estimator 클래스를 제거하고, 모든 모델에 공통으로 적용되는 단일화된 통합 인터페이스를 구축했다. 이를 통해 개발자는 프레임워크를 변경할 때마다 학습 코드를 수정해야 하는 제약 없이 일관된 제어 방식을 사용할 수 있다.
통합 인터페이스는 목적에 따라 `ModelTrainer`와 `ModelBuilder`라는 두 개의 클래스로 재편되었다. `ModelTrainer`는 데이터 입력부터 훈련 스크립트 실행까지의 학습 과정만을 전담하며, `ModelBuilder`는 학습이 완료된 모델 아티팩트를 서비스 가능한 엔드포인트로 배포하는 역할에 집중한다. 기능적 분리를 통해 배포 단계에서 인프라를 미리 띄우지 않고도 모델을 패키징할 수 있게 되었다.
이러한 설계 변경은 BYOM(Bring Your Own Model) 워크플로우를 최적화한다. 프레임워크 전용 클래스의 제약이 사라져 사용자가 정의한 임의의 모델 구조나 커스텀 학습 로직을 SageMaker 환경에 주입하는 과정이 간결해졌기 때문이다. 세부 구현 사항과 적용 사례 코드는 공식 GitHub 저장소(https://github.com/aws/sagemaker-python-sdk)에서 제공된다. 이러한 통합 인터페이스의 핵심 작동 원리는 `SourceCode` 객체를 통한 런타임 주입에 있다.
SourceCode 객체를 통한 코드-컨테이너 디커플링 메커니즘
SDK v3는 `SourceCode`라는 설정 객체를 도입해 실행 시점에 코드를 주입하는 방식을 구현했다. 이 객체는 로컬의 소스 코드 경로를 지정하는 `source_dir`과 실행할 명령어를 정의하는 `entry_script` 설정을 포함한다. 개발자는 로컬 환경에서 작성한 코드를 즉시 클라우드 런타임에 반영할 수 있다.
작동 원리는 런타임 동기화에 있다. 프로그램이 실행되는 시점에 SageMaker가 로컬 디렉토리의 내용을 컨테이너 내부로 복사한다. 이미지는 ECR에서 가져오며, 사용자가 직접 만든 이미지나 AWS 제공 딥러닝 컨테이너 모두 사용할 수 있다. SDK가 실행 시점에 `command` 문자열을 통해 주입된 코드를 구동하므로 이미지 자체는 변하지 않는다.
이 구조에서 학습용 컨테이너는 런타임 환경과 프레임워크 라이브러리를 제공하는 기반 역할로 제한된다. 학습 코드가 이미지에 포함되지 않으므로, 동일한 이미지 하나로 서로 다른 여러 개의 사이킷런 모델을 학습시킬 수 있다. 한 번 빌드하여 ECR에 올린 이미지는 고정된 상태로 유지되며, 개발자는 로컬에서 스크립트만 수정해 즉시 재실행한다.
실험 과정의 하이퍼파라미터, 메트릭, 모델 아티팩트 이력을 관리하려면 MLflow 설정을 추가한다. `MLFLOW_ARN`과 `MLFLOW_EXPERIMENT_NAME` 변수를 설정하면 SageMaker AI의 완전 관리형 MLflow에 로그가 자동으로 기록된다. 추적이 필요 없는 경우에는 해당 값을 None으로 설정해 기능을 끌 수 있다.
전통적 ML부터 Stable Diffusion 3.5 LoRA 튜닝까지의 구현
Scikit-learn 기반의 랜덤 포레스트 분류기 학습과 Stable Diffusion 3.5 Medium의 LoRA 튜닝은 동일한 소스코드 패턴을 공유한다. 먼저 당뇨병 데이터셋을 활용해 분류 모델을 학습시키고 이를 실시간 엔드포인트에 배포하는 워크플로우를 구현한다. 이때 사용되는 컨테이너는 아래 Dockerfile과 같이 런타임 환경 역할만 수행한다.
FROM python:3.9-slim
RUN pip install scikit-learn pandas모델 빌드가 완료되면 `deploy()` 함수를 호출하여 실시간 엔드포인트를 생성하고 Endpoint 인터페이스를 반환받는다. 워크로드 특성에 따라 단일 모델을 독립적인 엔드포인트에 호스팅하거나, 추론 구성 요소 기능을 통해 하나의 엔드포인트에 여러 모델을 배치하여 자원을 개별적으로 할당할 수 있다.
동일한 원리는 멀티 GPU를 사용하는 생성형 AI 모델의 분산 학습으로 확장된다. Stable Diffusion 3.5 Medium 모델을 LoRA(Low-Rank Adaptation) 방식으로 파인튜닝하는 사례가 이에 해당한다. 학습 인프라는 `ml.g5.12xlarge` 인스턴스를 사용하며 4개의 A10G GPU를 통해 분산 처리를 수행한다. 이때 Hugging Face Accelerate 라이브러리를 사용하여 연산 효율을 높인다.
FROM nvidia/cuda:12.1.0-base-ubuntu22.04
RUN apt-get update && apt-get install -y python3-pip
RUN pip install torch diffusers accelerate transformers로컬 파일에서 LoRA 랭크를 조정하거나 베이스 모델을 변경하고 학습 루프 코드를 수정해도 Docker 컨테이너를 다시 빌드할 필요가 없다. 데이터 입력은 `InputData` 설정을 통해 관리하며, Hugging Face에서 드림부스 데이터셋을 내려받아 S3 버킷에 저장한 뒤 학습 작업에 전달한다.
`InputData`에서 지정한 `channel_name` 값은 SageMaker가 학습 컨테이너 내부의 `/opt/ml/input/data/<channel_name>` 경로로 데이터를 자동 다운로드하는 기준이 된다. 작업 시작 시점에 각 채널의 콘텐츠가 해당 경로로 동기화되므로 사용자는 컨테이너 내부 경로를 통해 데이터에 접근한다.
ModelBuilder를 활용한 배포 최적화와 추론 구성 요소의 실무적 이점
`ModelBuilder.build()`는 인프라 자원을 할당하지 않고 추론 핸들러와 모델 아티팩트를 패키징하여 SageMaker 모델로 등록한다. 이 기능은 DJL Serving(Deep Java Library Serving)의 컨벤션을 준수한다. SDK가 로컬 디렉토리에 있는 핸들러와 `entry_script`를 모델 아카이브 내부에 포함해 패키징하면, 런타임 환경의 DJL Serving이 이를 인식해 추론 로직을 실행한다.
`ModelBuilder.deploy()`는 등록한 모델을 기반으로 실시간 엔드포인트를 생성하고 `Endpoint` 인터페이스를 반환한다. 배포 시에는 커스텀 이미지나 AWS Deep Learning Containers를 선택할 수 있다. 커스텀 이미지는 특정 라이브러리 버전이나 OS 설정이 필수적인 환경에서 사용하며, 사전 빌드 이미지는 AWS가 최적화한 프레임워크 환경을 사용하여 배포 속도를 높인다. 관련 정보는 공식 문서에서 제공한다.
배포 효율을 높이는 핵심은 추론 구성 요소(Inference Components)의 도입이다. 이는 하나의 엔드포인트 내에 여러 개의 모델을 동시에 배치하고, 각 모델에 할당되는 자원을 독립적으로 설정하는 기능이다. 기존에는 모델 하나당 하나의 엔드포인트를 생성해야 했으나, 추론 구성 요소를 사용하면 단일 엔드포인트 내에서 모델별로 메모리와 GPU 자원을 세분화해 할당하고 개별 모델 단위로 확장할 수 있다.
`ModelBuilder`는 학습 작업의 메타데이터를 활용해 S3에 저장된 최종 모델 아티팩트 경로를 자동으로 찾아 객체에 공급한다. 추론 핸들러가 포함된 소스 코드는 모델 아카이브와 결합되어 하나의 배포 단위로 묶인다. 이를 통해 개발자는 패키징 오류를 먼저 잡아내고, 실제 인프라 비용이 발생하는 시점을 배포 단계로 늦출 수 있다.
모델 실험 주기에서 Docker 빌드 단계를 제거하여 CI/CD 파이프라인 시간을 단축하고 실험 반복 속도를 높일 수 있다.
