어제 AWS ML 스택의 중심이 SageMaker라는 것을 봤다. 오늘은 그 안으로 들어간다. SageMaker는 단일 서비스가 아니라 ML 수명주기 전체를 덮는 도구 모음이다. ML 엔지니어가 매일 만지는 곳이고, MLA-C01 문제의 대부분이 "이 작업엔 SageMaker의 어느 기능을 쓰나"를 묻는다.
오늘은 SageMaker의 작업 공간(Studio)과 그 안의 권한 구조(도메인·사용자 프로필), 학습과 추론이 실제로 어떻게 돌아가는지, 그리고 직접 알고리즘을 짜지 않아도 되는 빌트인 알고리즘을 본다. 큰 그림을 잡는 게 목표다 — 각 기능의 세부는 이후 주차에서 깊이 다룬다.
SageMaker Studio는 브라우저 기반 통합 개발 환경이다. 노트북, 실험 추적, 파이프라인, 모델 배포를 한 화면에서 한다. VS Code가 일반 개발의 IDE라면 Studio는 ML의 IDE다.
Studio가 기존 노트북 인스턴스와 다른 핵심은 컴퓨팅과 스토리지의 분리다. 노트북 코드는 EFS에 영구 저장되고, 실행할 때만 원하는 인스턴스(커널)를 붙인다. CPU로 코드를 짜다가 학습할 때만 GPU 커널로 갈아끼울 수 있고, 안 쓰는 커널은 꺼서 비용을 아낀다.
# Studio 노트북 안에서 SageMaker SDK 세션 시작
import sagemaker
session = sagemaker.Session()
role = sagemaker.get_execution_role() # 노트북에 부여된 IAM 역할
bucket = session.default_bucket() # 기본 S3 버킷
print(region := session.boto_region_name)get_execution_role()이 반환하는 IAM 역할이 중요하다. 노트북에서 하는 모든 SageMaker·S3 작업은 이 역할의 권한으로 실행되므로, 권한이 부족하면 학습이나 배포가 AccessDenied로 실패한다.
💡 관련 이론: 컴퓨팅-스토리지 분리는 클라우드 ML의 핵심 비용 원칙이다. 학습은 GPU가 몇 시간 필요하지만 코드 작성은 CPU로 충분하다. 둘을 묶어두면 코드 짜는 동안에도 비싼 GPU 비용이 나간다. Studio는 코드(EFS)와 실행(on-demand 커널)을 분리해 "쓸 때만 비싼 자원"을 빌리게 한다. 이것이 노트북 인스턴스 대비 Studio의 비용 이점이다.
SageMaker Studio를 쓰려면 먼저 **도메인(Domain)**을 만들어야 한다. 도메인은 Studio 환경의 최상위 경계로, 하나의 VPC·인증 방식·공유 스토리지(EFS)를 묶는다. 한 조직(또는 팀)당 보통 하나의 도메인을 둔다.
도메인 안에 **사용자 프로필(User Profile)**이 있다. 사용자 한 명(또는 페르소나)당 하나이며, 각자의 IAM 역할·홈 디렉터리·기본 설정을 가진다.
Domain (조직/팀 경계, VPC·EFS·인증 공유)
├─ User Profile: data-scientist-kim (역할 A: 학습 권한)
├─ User Profile: ml-engineer-lee (역할 B: 학습+배포 권한)
└─ User Profile: shared-space (협업용 공유 공간)
선택지를 클릭하면 정답·해설이 펼쳐집니다.
문제 1
SageMaker Studio가 기존 노트북 인스턴스 대비 비용 효율적인 핵심 이유는?
문제 2
SageMaker Studio에서 데이터 사이언티스트에게는 학습 권한만, ML 엔지니어에게는 배포 권한까지 부여하려 한다. 이를 구현하는 구조는?
문제 3
SageMaker 학습 작업(Training Job)에서 학습 비용이 학습 시간만큼만 청구되는 이유는?
문제 4
"하루에 한 번, 전체 고객 데이터에 대해 이탈 점수를 일괄 계산"하는 워크로드에 가장 적합한 추론 옵션은?
문제 5
정형(테이블) 데이터의 이진 분류 문제를 SageMaker 빌트인 알고리즘으로 풀 때 가장 일반적인 기본 선택은?
이 계층이 시험에 나오는 이유는 권한 분리 때문이다. 데이터 사이언티스트에게는 학습 권한만, ML 엔지니어에게는 배포까지 부여하는 식으로 사용자 프로필별 IAM 역할을 다르게 매핑한다. 권한 문제가 생기면 "어느 사용자 프로필의 어느 역할이 무슨 권한을 갖고 있나"를 추적해야 한다.
🔍 더 깊이: 도메인 생성 시 네트워크 모드를 고른다. VPC only 모드는 모든 트래픽이 고객 VPC를 통하므로 인터넷을 차단하고 PrivateLink로 SageMaker API에 닿게 할 수 있다 — 규제·보안 환경의 표준이다. Public internet 모드는 AWS 관리 네트워크로 편하지만 통제가 약하다. 금융·의료 시나리오에서 "데이터가 인터넷에 노출되면 안 된다"가 나오면 VPC only가 답이다.
SageMaker 학습의 핵심 메커니즘은 **학습 작업(Training Job)**이다. 학습을 요청하면 SageMaker가 ① 지정한 인스턴스를 띄우고, ② S3에서 데이터를 받아, ③ 컨테이너 안에서 학습 코드를 돌리고, ④ 모델 산출물을 S3에 저장한 뒤, ⑤ 인스턴스를 자동 종료한다. 학습이 끝나면 인스턴스는 사라지므로 GPU 비용이 학습 시간만큼만 청구된다.
from sagemaker.estimator import Estimator
estimator = Estimator(
image_uri=sagemaker.image_uris.retrieve("xgboost", region, "1.7-1"),
role=role,
instance_count=2, # 분산 학습 시 2대 이상
instance_type="ml.m5.xlarge",
output_path=f"s3://{bucket}/models/",
use_spot_instances=True, # 스팟으로 학습 비용 최대 90% 절감
max_wait=7200, max_run=3600,
)
estimator.fit({"train": f"s3://{bucket}/train/"})use_spot_instances=True는 ML 엔지니어가 학습 비용을 줄이는 흔한 기법이다. 학습은 중단돼도 체크포인트에서 재개할 수 있으므로 저렴한 스팟 인스턴스에 적합하다.
학습된 모델을 서빙하는 방법은 트래픽 패턴에 따라 네 가지다. MLA-C01에서 자주 묻는 핵심 비교다.
| 옵션 | 적합한 상황 | 특징 |
|---|---|---|
| 실시간 엔드포인트 | 지속적인 저지연 요청 | 항상 켜져 있음(비용 상시), ms 응답 |
| 서버리스 추론 | 간헐적·예측 불가 트래픽 | 자동 스케일, 콜드 스타트 있음, 유휴 비용 0 |
| 배치 변환 | 대량 데이터 일괄 추론 | 엔드포인트 불필요, 끝나면 종료 |
| 비동기 추론 | 큰 페이로드·긴 처리 | 큐 기반, 대용량/장시간 작업 |
판별은 트래픽 모양으로 한다. "초당 수천 요청, 낮은 지연" → 실시간. "하루 한 번 전체 고객 점수 매기기" → 배치 변환. "가끔 들어오고 유휴 비용 아까움" → 서버리스. "이미지·영상처럼 큰 입력에 처리 오래" → 비동기.
# 실시간 엔드포인트 배포
predictor = estimator.deploy(
initial_instance_count=1, instance_type="ml.m5.large",
endpoint_name="churn-endpoint",
)
result = predictor.predict(payload) # ms 단위 응답💡 관련 이론: 서버리스 추론은 "유휴 비용 0 vs 콜드 스타트 지연"이라는 고전적 트레이드오프다. 트래픽이 없을 때 인스턴스를 0으로 줄여 비용을 안 받지만, 다음 요청 시 컨테이너를 새로 띄우는 콜드 스타트(수백 ms~수 초)가 생긴다. 지연이 일관되게 낮아야 하는 서비스는 실시간 엔드포인트(상시 가동)를, 비용 민감하고 간헐적이면 서버리스를 고른다. 이는 Lambda의 콜드 스타트 트레이드오프와 같은 구조다.
SageMaker는 검증된 알고리즘 약 17종을 컨테이너로 제공한다. 직접 모델 코드를 작성할 필요 없이 데이터와 하이퍼파라미터만 넘기면 된다. 문제 유형별로 대표를 기억해두면 시험에서 빠르게 고른다.
| 문제 유형 | 빌트인 알고리즘 |
|---|---|
| 분류·회귀(테이블) | XGBoost, Linear Learner |
| 군집 | K-Means |
| 차원 축소 | PCA |
| 이상 탐지 | Random Cut Forest (RCF) |
| 추천 | Factorization Machines |
| 이미지 분류 | Image Classification |
| 객체 탐지 | Object Detection |
| 시계열 예측 | DeepAR |
| 토픽 모델링 | LDA, NTM |
빌트인이 안 맞으면 커스텀 컨테이너(직접 만든 Docker 이미지)나 스크립트 모드(자체 학습 스크립트 + AWS 관리 프레임워크 컨테이너)로 간다. "테이블 데이터 분류/회귀"는 거의 항상 XGBoost가 기본 답이다.
오늘의 핵심 셋. 첫째, Studio는 컴퓨팅-스토리지 분리로 ML 작업을 통합하는 IDE이고, 도메인-사용자 프로필 계층으로 권한을 나눈다. 둘째, 학습은 일시적 컨테이너에서 일어나 끝나면 인스턴스가 사라지며 스팟으로 비용을 줄인다. 셋째, 추론은 트래픽 패턴에 따라 실시간/서버리스/배치/비동기 중 고르고, 빌트인 알고리즘으로 모델 코드 작성을 생략할 수 있다.
다음 글에서는 이번 주에 배운 ML 기초와 AWS 스택을 종합 복습하며 Week 1을 마무리한다.