배포 결정: 어떤 인프라가 적합한가
모델을 훈련하는 것보다 프로덕션에서 안정적으로 실행되도록 배포하는 것이 훨씬 더 복잡한 경우가 많습니다. AWS SageMaker는 사용 패턴에 따라 네 가지 추론 모드를 제공하며, 각각이 최적인 시나리오가 명확히 다릅니다. MLA-C01 시험에서는 요구사항 설명을 보고 올바른 배포 유형을 선택하는 능력을 자주 테스트합니다.
결정의 핵심 기준은 세 가지입니다: 응답 지연 허용 범위, 페이로드 크기, 그리고 트래픽 패턴. 이 세 가지를 먼저 파악하면 나머지 선택은 상당히 좁혀집니다.
실시간 엔드포인트: 즉각적인 예측이 필요할 때
SageMaker 실시간 엔드포인트(Real-time Endpoint)는 애플리케이션이 HTTP 요청을 보내고 수백 밀리초 이내에 예측 결과를 받아야 하는 경우에 사용합니다. 웹 애플리케이션의 추천 시스템, 금융 사기 탐지, 실시간 이미지 분석 등이 전형적인 사례입니다.
엔드포인트를 생성할 때 인스턴스 타입과 수를 직접 지정합니다. 인스턴스 선택은 비용과 성능의 균형에 달려 있습니다. GPU가 필요한 딥러닝 모델에는 ml.g4dn, ml.g5, ml.p3 계열을 고려하고, 전통적인 ML 모델이나 NLP 모델 중 경량 모델에는 ml.c5, ml.m5 같은 CPU 인스턴스도 충분한 경우가 많습니다. AWS Inferentia 기반의 ml.inf1, ml.inf2 인스턴스는 GPU 대비 최대 70% 비용 절감이 가능하면서 높은 처리량을 제공합니다.
프로덕션 변형(Production Variant)을 통해 하나의 엔드포인트에 여러 모델 버전을 배포하고 트래픽 비율을 조정할 수 있습니다. 이는 A/B 테스트나 점진적 배포에 활용됩니다. 예를 들어, 새 모델 버전에 트래픽의 10%만 먼저 보내어 성능을 검증한 후 점진적으로 비율을 높이는 방식입니다.
배치 변환: 대규모 오프라인 채점
Batch Transform은 이미 수집된 대량의 데이터를 한꺼번에 처리해야 하는 경우에 최적입니다. 실시간 응답이 필요하지 않고, S3에 저장된 수백만 개의 레코드에 대한 예측을 실행해야 할 때 사용합니다. 야간 배치 점수화, 데이터 파이프라인의 전처리 단계, 대규모 추천 오프라인 생성 등이 해당됩니다.
Batch Transform은 작업이 완료되면 인스턴스를 자동으로 종료하므로 지속적인 비용이 발생하지 않습니다. 입력 데이터는 S3에서 읽고 출력 결과도 S3에 저장됩니다. 대용량 데이터를 병렬로 처리하기 위해 여러 인스턴스를 지정할 수 있으며, SageMaker가 데이터 분할과 재조합을 자동으로 처리합니다.
서버리스 추론: 간헐적 트래픽을 위한 비용 최적화
Serverless Inference는 트래픽이 예측 불가능하거나 간헐적인 워크로드에 적합합니다. 사용한 컴퓨팅 시간과 처리된 데이터량에 따라서만 요금이 부과되므로, 트래픽이 없는 시간대에는 비용이 발생하지 않습니다.
가장 큰 트레이드오프는 콜드 스타트입니다. 일정 시간 이상 요청이 없으면 컨테이너가 종료되고, 다음 요청 시 재시작 시간(수 초)이 추가됩니다. 따라서 일관된 낮은 지연 시간이 중요한 서비스에는 부적합합니다. 반면 내부 도구, 개발 환경, 비정기적으로 호출되는 예측 API에는 비용 효율적인 선택입니다. 메모리 크기(1GB~6GB)를 직접 지정하며, 이 값이 요금에 영향을 줍니다.
비동기 추론: 대용량 페이로드 처리
Async Inference는 요청 페이로드가 크거나(최대 1GB), 처리 시간이 길어 동기식으로 응답을 기다리기 어려운 경우에 사용합니다. 요청을 큐에 넣으면 SageMaker가 비동기로 처리하고 결과를 S3에 저장합니다. 클라이언트는 결과 S3 위치를 폴링하거나 SNS 알림을 받을 수 있습니다.
의료 영상 분석, 동영상 처리, 대형 문서 처리 등 요청 하나를 처리하는 데 수십 초 이상이 걸리는 시나리오에 적합합니다. 비동기 엔드포인트도 Auto Scaling을 지원하며, 큐 깊이를 기반으로 스케일 조정이 가능합니다.
네 가지 추론 모드 비교
| 모드 | 지연 시간 | 최대 페이로드 | 비용 구조 | 대표 사용 사례 | |------|----------|------------|---------|------------| | 실시간 엔드포인트 | 밀리초 단위 | 6MB | 인스턴스 가동 시간 | 실시간 추천, 사기 탐지 | | Batch Transform | 해당 없음 (비동기) | 무제한 | 작업 시간 | 오프라인 대규모 채점 | | Serverless Inference | 수십~수백 ms (콜드 스타트 있음) | 4MB | 호출 수 + 처리 시간 | 간헐적 트래픽, 내부 도구 | | Async Inference | 수초~수분 | 1GB | 인스턴스 가동 시간 | 대용량 파일 처리 |
!SageMaker 추론 모드 4가지
멀티모델 엔드포인트와 멀티컨테이너 엔드포인트
하나의 엔드포인트로 여러 모델을 서빙해야 하는 경우 두 가지 옵션이 있습니다.
멀티모델 엔드포인트(MME)는 수백~수천 개의 유사한 모델을 하나의 엔드포인트에서 관리합니다. 모델들은 S3에 저장되고, 요청 시 동적으로 로드됩니다. 자주 사용되는 모델은 메모리에 캐시되고, 사용되지 않는 모델은 언로드됩니다. 고객별 개인화 모델이나 지역별 모델처럼 모델 수가 매우 많지만 각각의 트래픽이 낮을 때 비용 효율적입니다.
멀티컨테이너 엔드포인트는 하나의 엔드포인트 내에서 최대 15개의 서로 다른 컨테이너를 실행합니다. 각 컨테이너에 다른 프레임워크나 모델을 배포할 수 있으며, 순차적(파이프라인) 또는 직접 호출 방식으로 요청을 라우팅할 수 있습니다. NLP 전처리 모델 + 분류 모델 + 후처리 모델을 하나의 엔드포인트로 묶는 ML 파이프라인 시나리오에 적합합니다.
SageMaker Neo와 AWS Inferentia: 하드웨어 최적화
SageMaker Neo는 모델을 특정 하드웨어 대상으로 컴파일하여 추론 성능을 높이는 도구입니다. TensorFlow, PyTorch, MXNet, XGBoost 등 주요 프레임워크를 지원하며, EC2 인스턴스(x86, ARM), 에지 디바이스(NVIDIA Jetson, Raspberry Pi), AWS Inferentia 등 다양한 타깃을 지원합니다. 컴파일된 모델은 Neo Runtime(DLR) 위에서 실행됩니다.
AWS Inferentia는 Amazon이 직접 설계한 ML 추론 전용 칩입니다. Inf1 인스턴스(Inferentia1)는 이미 프로덕션에서 광범위하게 사용되고 있으며, Inf2 인스턴스(Inferentia2)는 대형 모델과 생성형 AI 워크로드를 위해 더 높은 메모리와 연결 대역폭을 제공합니다. GPU 인스턴스 대비 비용 효율이 높아 높은 처리량이 필요한 추론 워크로드에서 경쟁력이 있습니다. Neuron SDK를 사용해 모델을 컴파일하고 배포합니다.
Auto Scaling 정책
SageMaker 엔드포인트는 Application Auto Scaling과 통합되어 세 가지 스케일링 정책을 지원합니다.
대상 추적(Target Tracking) 정책은 가장 일반적으로 사용되며, InvocationsPerInstance(인스턴스당 호출 수)나 CPUUtilization 같은 지표를 목표값에 유지하도록 자동으로 인스턴스를 추가하거나 제거합니다. 설정이 간단하고 대부분의 경우에 잘 작동합니다.
단계 스케일링(Step Scaling) 정책은 지표의 임계값 위반 크기에 따라 다른 스케일링 양을 적용합니다. 예를 들어 InvocationsPerInstance가 70을 초과하면 1개 추가, 90을 초과하면 3개 추가처럼 단계별로 다르게 반응하도록 설정할 수 있습니다. 예측 가능한 트래픽 급증 패턴이 있을 때 유용합니다.
예약 스케일링(Scheduled Scaling)은 특정 시간에 미리 인스턴스 수를 늘려두는 방식입니다. 매주 월요일 오전 9시에 트래픽이 급증하는 것을 알고 있다면, 그 전에 인스턴스를 미리 확장해 콜드 스타트 지연을 방지할 수 있습니다.
커스텀 CloudWatch 지표도 스케일링 트리거로 사용할 수 있습니다. 예를 들어 큐 깊이나 비즈니스 수준의 지표를 기반으로 스케일링하는 것이 가능합니다.
컨테이너 옵션: 기본 제공 vs BYOC
SageMaker는 TensorFlow, PyTorch, XGBoost, Scikit-learn 등 주요 프레임워크에 대해 사전 구축된 컨테이너를 제공합니다. 이를 사용하면 컨테이너를 직접 관리할 필요 없이 모델 아티팩트만 제공하면 됩니다. 보안 패치와 프레임워크 업데이트를 AWS가 관리합니다.
특수한 라이브러리, 커스텀 전처리 로직, 또는 독점 소프트웨어가 필요한 경우에는 자체 컨테이너를 가져올 수 있습니다(BYOC, Bring Your Own Container). Docker 이미지를 빌드하고 ECR(Amazon Elastic Container Registry)에 푸시한 후 SageMaker에 등록합니다. ECR은 컨테이너 이미지의 버전 관리, 취약점 스캐닝, 복제를 지원합니다.
VPC 구성과 에지 배포
프로덕션 환경에서는 SageMaker 엔드포인트를 VPC 내부에 배포하여 인터넷에 직접 노출되지 않도록 구성하는 것이 일반적입니다. VPC 모드에서는 PrivateLink를 통해 SageMaker 서비스에 접근하고, 엔드포인트와 S3 간 트래픽도 VPC 내에서 처리됩니다.
에지 디바이스에 모델을 배포하려면 AWS IoT Greengrass와 SageMaker Edge Manager를 결합합니다. Neo로 컴파일된 모델을 엣지 디바이스에 배포하고, SageMaker Edge Manager가 플릿 전체의 모델 버전 관리와 성능 모니터링을 담당합니다.
인프라를 코드로 관리하는 IaC 관점에서 CloudFormation이나 CDK를 사용해 SageMaker 엔드포인트를 정의하면, 환경 간 일관성을 보장하고 변경 이력을 추적할 수 있습니다.
시험 핵심 포인트
"밀리초 지연, 지속적 트래픽" -- 실시간 엔드포인트 "대량 데이터 일괄 처리, 결과를 S3에" -- Batch Transform "간헐적 트래픽, 비용 최적화" -- Serverless Inference (콜드 스타트 허용 시) "페이로드 1GB, 처리 시간 길다" -- Async Inference "수천 개 모델, 낮은 개별 트래픽" -- 멀티모델 엔드포인트(MME) "GPU 대비 비용 절감 추론" -- AWS Inferentia (Inf1/Inf2) "에지 디바이스 배포 + 모델 컴파일" -- SageMaker Neo + IoT Greengrass "InvocationsPerInstance 기반 자동 확장" -- Target Tracking Auto Scaling "신규 모델 버전 10% 트래픽 테스트" -- Production Variant "커스텀 프레임워크, 독점 라이브러리" -- BYOC + ECR