기준: MLA-C01 시험 가이드오류 제보

MLA-C01· AssociateWeek 9 · Day 4읽기 약 13분

핵심 정리

학습은 Managed Spot + 체크포인트로 최대 90% 절감. MaxWaitTimeInSeconds ≥ MaxRuntimeInSeconds가 짝이다.
인스턴스는 워크로드에 맞게 — 트리·선형=CPU, 딥러닝 학습=GPU, 딥러닝 추론 단가=Inferentia.
추론 비용의 본질은 유휴 구간 비용. 트래픽이 0으로 떨어지면 서버리스·비동기·배치로 그 구간을 0에 가깝게 만든다.
비용 급증의 범인은 대개 안 끈 리소스 — 유휴 노트북, 잊힌 엔드포인트, 끝나지 않는 학습. 자동 종료로 시스템이 막게 한다.
팀·프로젝트별 비용 분리는 비용 할당 태그 + Cost Explorer, 한도 관리는 Budgets가 정답이다.

Day 4 - ML 비용 최적화: Spot 학습부터 비용 모니터링까지

비용이 새는 세 축

지금까지가 안전하게(보안)였다면, 오늘은 싸게다. ML 워크로드는 GPU 인스턴스·대규모 학습·always-on 엔드포인트 때문에 비용이 빠르게 불어난다. 레버는 세 축으로 정리된다.

축	주 레버	한 줄 요지
학습	Managed Spot + 체크포인트 · right-sizing · 튜닝 조기 중지 · `MaxRuntimeInSeconds`	잠깐 쓰고 버리는 배치 작업이라 할인·상한이 잘 듣는다
추론	서버리스 · 비동기 · 배치 변환 · MME · Inferentia · Auto Scaling	유휴 시간의 always-on 비용을 없애는 게 핵심
운영	노트북 유휴 자동 종료 · 미사용 엔드포인트 정리 · Savings Plans · 태그/Budgets/Cost Explorer	안 끈 리소스를 잡고, 쓴 만큼을 보이게 만든다

Managed Spot Training — 학습 비용을 최대 90% 절감

학습은 보통 한 번 돌고 끝나는(중단돼도 재개 가능한) 작업이라 Spot 인스턴스와 궁합이 좋다. Managed Spot Training 은 SageMaker가 Spot 용량을 관리하며 최대 90%까지 비용을 줄인다.

{
  "EnableManagedSpotTraining": true,
  "StoppingCondition": {
    "MaxRuntimeInSeconds": 86400,
    "MaxWaitTimeInSeconds": 90000
  },
  "CheckpointConfig": {
    "S3Uri": "s3://ml-checkpoints/job-123/"
  }
}

Python SDK에서는 Estimator 파라미터로 같은 설정을 준다.

from sagemaker.estimator import Estimator
 
estimator = Estimator(
    image_uri=container,
    role=role,
    instance_count=1,
    instance_type="ml.g5.xlarge",
    use_spot_instances=True,                           # Spot 학습 켜기
    max_run=86400,                                     # 학습 자체 최대 시간(초)
    max_wait=90000,                                    # Spot 대기 포함 최대 시간(초)
    checkpoint_s3_uri="s3://ml-checkpoints/job-123/",  # 회수 대비 체크포인트
)

MaxWaitTimeInSeconds(max_wait)는 MaxRuntimeInSeconds(max_run)보다 크거나 같아야 한다 — Spot 용량을 기다리는 시간을 포함하기 때문이다.
체크포인트가 핵심: Spot은 중간에 회수(interruption)될 수 있다. CheckpointConfig로 S3에 진행 상태를 저장하면, 회수 후 재개 시 처음부터가 아니라 체크포인트에서 이어간다. 체크포인트 없이 Spot을 쓰면 회수 때마다 처음부터 다시 학습한다.
저장만으로는 부족하다. 학습 스크립트가 재시작 시 그 경로를 읽어 이어받도록 짜여 있어야 실제로 재개된다.

절감이 실제로 났는지는 작업 설명에서 확인한다.

import boto3
 
sm = boto3.client("sagemaker")
d = sm.describe_training_job(TrainingJobName="job-123")
print(d["TrainingTimeInSeconds"])   # 실제 학습에 쓴 시간
print(d["BillableTimeInSeconds"])   # 과금된 시간 — Spot이면 이쪽이 훨씬 작다

Spot이 학습에 잘 맞는 이유는 "학습은 멱등하게 재개 가능한 배치 작업"이라서다. 회수돼도 체크포인트에서 이어가면 결과가 같다. 반대로 실시간 추론 엔드포인트는 회수되면 서비스가 끊기므로 Spot이 부적절하다 — "Spot은 학습에, 실시간 추론에는 안 쓴다"가 시험의 기본 원칙이다.

⚠️ 함정: "마감이 빡빡해 절대 지연되면 안 되는 학습"에는 Spot이 오답이다. Spot은 용량을 기다릴 수 있고 회수도 될 수 있어 완료 시각을 보장하지 않는다. 비용 문항이라도 "기한 보장"이 조건에 붙어 있으면 온디맨드가 답이다.

적정 인스턴스 선택(Right-sizing)

인스턴스를 잘못 고르면 돈을 버린다. 두 방향의 낭비가 있다 — 너무 크게(과프로비저닝) 또는 작업에 안 맞는 종류로.

워크로드	고를 것	이유
전통 ML 학습(XGBoost, 선형 등)	CPU (m5/c5)	트리·선형 모델은 GPU 이득이 거의 없다. p4d를 붙이는 건 돈 낭비
딥러닝 학습	GPU (g5/p4d)	큰 모델일수록 GPU 메모리·병렬 연산 성능이 중요
딥러닝 추론 단가 절감	Inferentia (inf1/inf2)	추론 전용 가속기로 단위 비용을 낮춤
추론 인스턴스가 뭐가 맞는지 모를 때	Inference Recommender	부하 테스트로 비용·지연 최적 인스턴스를 추천

학습 쪽은 자동 추천이 없으므로, 작은 데이터로 시험 실행해 메트릭(GPU 사용률·처리량)을 보고 조정한다.

Right-sizing의 원칙은 "워크로드 특성에 맞는 최소 충분 크기"다. GPU는 병렬 행렬 연산(딥러닝)에서만 값을 하고, 트리 모델에는 거의 무용하다. 비용 상황에서 "XGBoost에 GPU"는 오답이 되기 쉽고, "딥러닝 추론에 Inferentia"는 정답 후보가 된다.

하이퍼파라미터 튜닝 비용 — 곱셈으로 늘어난다

튜닝은 학습 작업을 여러 번 돌리는 것이므로 비용이 작업 수 × 작업당 비용으로 커진다. 여기서 새는 돈이 의외로 크다.

from sagemaker.tuner import HyperparameterTuner
 
tuner = HyperparameterTuner(
    estimator=estimator,
    objective_metric_name="validation:auc",
    hyperparameter_ranges=ranges,
    max_jobs=20,                 # 총 학습 작업 수 = 비용 상한
    max_parallel_jobs=2,         # 동시 실행 수(너무 크면 탐색 효율이 떨어진다)
    early_stopping_type="Auto",  # 가망 없는 작업을 조기 중지
)

max_jobs가 사실상 튜닝의 예산 상한이다. 범위를 좁히고 작업 수를 줄이는 게 가장 확실한 절감이다.
early_stopping_type을 켜면 목표 지표가 가망 없는 작업을 중간에 끊어 낭비를 막는다.
튜닝 작업의 개별 학습에도 Spot을 적용할 수 있다(Estimator에 설정하면 튜닝이 그 설정을 따른다).
학습이 발산하거나 과적합으로 치닫는 걸 규칙으로 감지해 작업을 자동 중지시키는 것도 낭비를 끊는 장치다(Debugger 규칙).

추론 옵션으로 유휴 비용 없애기

추론 비용의 큰 그림은 "트래픽이 0인 구간의 always-on 비용을 없애는 것"이다(Week 6 복습과 연결).

옵션	과금 대상	트래픽이 0일 때	적합한 상황
실시간 엔드포인트	떠 있는 인스턴스 시간	최소 1대 비용이 계속 발생	꾸준한 트래픽, 낮은 지연이 필수
서버리스 추론	호출 처리 시간·메모리	0	간헐적·예측 어려운 트래픽. 콜드 스타트 감수
비동기 추론	인스턴스 시간	큐가 비면 0까지 축소 가능	큰 페이로드·긴 처리, 즉답 불필요
배치 변환	작업이 도는 동안만	0 (작업 끝나면 인스턴스 종료)	일괄 점수화. 가장 저렴
MME(다중 모델 엔드포인트)	공유 인스턴스 시간	인스턴스 비용은 발생	모델이 아주 많고 각각의 호출은 드물 때

비용 최적화 결정
유휴 구간이 있는가?
 ├─ 예 → 일괄 처리 가능? → 예: 배치 변환 / 아니오: 서버리스(작은 페이로드) 또는 비동기(큰 페이로드)
 └─ 아니오(상시 트래픽) → 실시간 + 오토스케일링 + MME(다수 모델) + Inferentia(딥러닝)

비용 관점 의사결정: 트래픽이 0으로 떨어지는 구간이 있으면 서버리스·비동기·배치로 그 구간 비용을 0에 가깝게. 항상 트래픽이 차 있으면 실시간 + Auto Scaling + (다수 모델이면)MME + (딥러닝이면)Inferentia로 단위 비용을 낮춘다.

⚠️ 함정: 모델 하나를 위해 엔드포인트 하나를 만드는 습관이 비용을 조용히 갉아먹는다. 모델이 수십·수백 개인데 각각 호출 빈도가 낮으면 답은 인스턴스 축소가 아니라 MME로 합치는 것이다. 반대로 모든 모델이 상시 고트래픽이면 MME는 오히려 서로 자원을 다투게 만든다.

자동 종료 — 잊고 켜둔 리소스 잡기

비용의 숨은 범인은 "쓰고 안 끈" 리소스다.

Studio·노트북 자동 종료: 유휴 노트북은 라이프사이클 구성(LCC)이나 Studio의 유휴 종료 설정으로 일정 시간 후 자동 종료. 데이터 사이언티스트가 켜두고 퇴근하는 비용을 막는다.
학습 작업 MaxRuntimeInSeconds: 무한정 도는 작업을 시간으로 끊는다. 버그로 멈춘 학습이 GPU를 며칠씩 태우는 사고를 방지.
엔드포인트 정리: 안 쓰는 실시간 엔드포인트는 always-on 비용이 계속 나가므로 삭제하거나 서버리스로 전환.
Auto Scaling + 스케일 인: 트래픽이 줄면 인스턴스를 줄여(최소 용량까지) 비용을 낮춘다.
S3 수명 주기: 오래된 데이터셋·구버전 아티팩트·로그는 저빈도/아카이브 계층으로 옮기거나 만료시킨다. 학습이 끝나도 스토리지 비용은 계속 쌓인다.

ML 비용 사고는 대개 "끄지 않은 리소스"에서 나온다 — 유휴 노트북, 잊힌 엔드포인트, 무한 루프 학습. 자동 종료(유휴 타이머, MaxRuntime, 오토스케일 스케일인)는 사람의 실수를 시스템으로 막는 장치다. 시험에서 "예상치 못한 비용 급증"의 정답은 대개 이 자동 종료/정리 관련이다.

비용 모니터링과 거버넌스

비용을 보이게 만들어야 통제할 수 있다.

도구	무엇에 쓰나	고르는 순간
비용 할당 태그	`Project`·`Team`·`Environment`로 비용을 귀속	"누가 얼마 썼는지" 나눠 보고 싶을 때
Cost Explorer	비용 추세·구성 분석, 태그별 집계	어떤 서비스·인스턴스가 돈을 먹는지 파악
AWS Budgets	예산 한도 설정, 임계치·예측 기반 알림	한도를 정하고 넘으면 알림받고 싶을 때
Cost Anomaly Detection	평소와 다른 비용 급등을 자동 탐지	예산 이전에 이상 징후를 빨리 잡고 싶을 때
CloudWatch	`Invocations`·`ModelLatency` 등 사용률 지표	유휴·과프로비저닝을 근거로 증명할 때
Savings Plans / 예약 인스턴스	약정으로 온디맨드보다 낮은 요금	상시 엔드포인트·정기 학습처럼 사용량이 예측될 때

[비용 거버넌스 순환]
태그 부여 ──▶ Cost Explorer로 귀속 확인 ──▶ Budgets로 한도·알림 ──▶ 초과 원인 조치
    ▲                                                                        │
    └──────────── 새로 만드는 리소스에도 태그를 강제(정책·자동화) ◀───────────┘
 
태그 예시 (비용 할당)
TrainingJob tags: { "Project": "fraud-ml", "Team": "risk", "Environment": "prod" }
→ Cost Explorer에서 Project별 필터로 fraud-ml 비용만 집계

태그를 붙였는데 Cost Explorer에서 안 보인다는 상황이 있다. 태그는 붙이는 것만으로 끝이 아니라 Billing 콘솔에서 "비용 할당 태그"로 활성화해야 비용 보고서에 나타나고, 활성화 이후의 사용분부터 집계된다. 과거 비용이 소급되지 않는다는 점까지 기억한다.

비용 거버넌스는 "측정 → 귀속 → 예산 → 알림"의 순환이다. 태그로 비용을 팀·프로젝트에 귀속(allocation)시켜야 누가 얼마 쓰는지 보이고, Budgets로 한도를 정하고 초과 시 알린다. "비용을 팀별로 나눠 보고 싶다"는 시나리오의 정답은 거의 항상 비용 할당 태그다.

비용이 샐 때: 증상 → 원인 → 조치

증상	흔한 원인	조치
이번 달 비용이 갑자기 급증	안 끈 노트북, 잊힌 엔드포인트	유휴 자동 종료 설정, 미사용 엔드포인트 삭제, Cost Anomaly Detection 알림
엔드포인트는 떠 있는데 호출이 거의 없다	간헐적 트래픽에 실시간 엔드포인트를 씀	서버리스·비동기·배치로 전환, Auto Scaling 최소 용량 하향
Spot 학습이 매번 처음부터 다시 돈다	`CheckpointConfig` 미지정 또는 스크립트가 체크포인트를 안 읽음	체크포인트 경로 지정 + 재개 로직 구현
Spot 작업이 시작도 못 하고 끝난다	`MaxWaitTimeInSeconds`가 `MaxRuntimeInSeconds`보다 작음	대기 포함 상한을 학습 상한 이상으로 올린다
학습이 며칠째 끝나지 않는다	수렴 실패·버그로 폭주	`MaxRuntimeInSeconds`로 상한, 규칙 기반 자동 중지
GPU로 바꿨는데 비용만 늘었다	트리 계열이라 GPU 이득이 없음	CPU(m5/c5)로 되돌린다
튜닝 비용이 예상의 몇 배	작업 수·동시 실행 수 과다	`max_jobs` 축소, 탐색 범위 좁히기, 조기 중지 활성화
팀별로 누가 얼마 쓰는지 알 수 없다	태그 없음 또는 비용 할당 태그 미활성화	태그 부여 + Billing에서 활성화 후 Cost Explorer 집계
상시 도는 워크로드인데 계속 온디맨드 요금	약정 할인 미적용	사용량이 안정적이면 Savings Plans 검토

내일은 Week 9 전체(보안·거버넌스·비용)를 하나의 의사결정 흐름으로 종합한다.

📖 용어

Managed Spot Training : SageMaker가 Spot 용량을 대신 관리해 주는 학습 방식. 최대 90% 저렴하지만 중간에 회수될 수 있다.
체크포인트 (CheckpointConfig) : 학습 중간 상태를 S3에 저장해 둔 것. Spot 회수 후 처음이 아니라 그 지점부터 재개하게 해준다.
MaxRuntimeInSeconds / MaxWaitTimeInSeconds : 학습 자체의 최대 시간 / Spot 대기를 포함한 최대 시간. 뒤쪽이 앞쪽보다 크거나 같아야 한다.
Right-sizing : 워크로드에 맞는 최소 충분 크기의 인스턴스를 고르는 것. 과프로비저닝과 종류 오선택이 양대 낭비다.
Inferentia (inf1/inf2) : 추론 전용 AWS 가속기. 딥러닝 추론의 단위 비용을 낮출 때 쓴다.
Inference Recommender : 부하 테스트를 돌려 비용·지연 기준으로 추론 인스턴스를 추천해 주는 기능.
유휴 비용 : 트래픽이 없는데도 인스턴스가 떠 있어 나가는 비용. 서버리스·비동기·배치가 이걸 0에 가깝게 만든다.
MME (다중 모델 엔드포인트) : 하나의 엔드포인트 인스턴스에 여러 모델을 올려 공유하는 방식. 모델이 많고 호출이 드물 때 유리하다.
비용 할당 태그 : 리소스에 붙여 비용을 팀·프로젝트에 귀속시키는 태그. Billing에서 활성화해야 보고서에 집계된다.
Savings Plans : 일정 사용량을 약정하고 온디맨드보다 낮은 요금을 적용받는 방식. 사용량이 안정적일 때 쓴다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

며칠씩 걸리는 딥러닝 학습 작업의 비용을 최대한 줄이려 한다. 작업은 중단 후 재개가 가능하다. 가장 적절한 구성은?

문제 2

사내 ML 도구의 추론 엔드포인트가 업무 시간에만 가끔 호출되고 야간·주말에는 트래픽이 0이다. 비용을 줄이는 가장 적절한 방법은?

문제 3

매월 ML 비용이 예상보다 크게 초과되어 조사해보니, 데이터 사이언티스트들이 노트북 인스턴스와 일부 실시간 엔드포인트를 사용 후 끄지 않고 방치하고 있었다. 재발을 막는 가장 효과적인 조치는?

문제 4

여러 팀이 공용 AWS 계정에서 SageMaker를 쓰는데, 어떤 팀·프로젝트가 ML 비용을 얼마나 쓰는지 분리해서 보고 싶다. 가장 적절한 방법은?

문제 5

다음 중 인스턴스 선택과 비용 효율의 연결로 잘못된 것은?

참고 공식 자료