Day 4 - SageMaker 개요: Studio, 학습/추론, 빌트인 알고리즘

📌 핵심 정리

• Studio는 컴퓨팅과 스토리지를 분리한 ML 전용 IDE — 코드는 EFS에 두고 실행할 때만 커널(인스턴스)을 붙인다.
• 권한 구조는 도메인(팀 경계) → 사용자 프로필(개인·역할). 프로필별로 다른 IAM 역할을 매핑해 권한을 나눈다.
• 학습은 일시적 컨테이너에서 일어난다 — 끝나면 인스턴스 자동 종료, 스팟으로 비용 절감.
• 추론은 트래픽 패턴으로 고른다: 실시간 / 서버리스 / 배치 변환 / 비동기.
• 빌트인 알고리즘 약 17종으로 모델 코드 작성을 생략할 수 있다. 테이블 데이터 분류·회귀 = XGBoost가 기본값.

SageMaker Studio: ML 작업의 통합 IDE

SageMaker는 단일 서비스가 아니라 ML 수명주기 전체를 덮는 도구 모음이고, MLA-C01 문제의 대부분이 "이 작업엔 SageMaker의 어느 기능을 쓰나"를 묻는다.

SageMaker Studio는 브라우저 기반 통합 개발 환경이다. 노트북, 실험 추적, 파이프라인, 모델 배포를 한 화면에서 한다. VS Code가 일반 개발의 IDE라면 Studio는 ML의 IDE다.

Studio가 기존 노트북 인스턴스와 다른 핵심은 컴퓨팅과 스토리지의 분리다.

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의 권한 구조

SageMaker Studio를 쓰려면 먼저 **도메인(Domain)**을 만들어야 한다. 도메인은 Studio 환경의 최상위 경계로, 하나의 VPC·인증 방식·공유 스토리지(EFS)를 묶는다. 한 조직(또는 팀)당 보통 하나의 도메인을 둔다.

도메인 안에 **사용자 프로필(User Profile)**이 있다. 사용자 한 명(또는 페르소나)당 하나이며, 각자의 IAM 역할·홈 디렉터리·기본 설정을 가진다.

Domain (조직/팀 경계, VPC·EFS·인증 공유)
 ├─ User Profile: data-scientist-kim  (역할 A: 학습 권한)
 ├─ User Profile: ml-engineer-lee     (역할 B: 학습+배포 권한)
 └─ Shared Space: team-collab         (협업용 공유 공간)

이 계층이 시험에 나오는 이유는 권한 분리 때문이다. 데이터 사이언티스트에게는 학습 권한만, ML 엔지니어에게는 배포까지 부여하는 식으로 사용자 프로필별 IAM 역할을 다르게 매핑한다. 권한 문제가 생기면 "어느 사용자 프로필의 어느 역할이 무슨 권한을 갖고 있나"를 추적해야 한다.

🔍 더 깊이: 도메인 생성 시 네트워크 모드를 고른다. VPC only 모드는 모든 트래픽이 고객 VPC를 통하므로 인터넷을 차단하고 PrivateLink로 SageMaker API에 닿게 할 수 있다 — 규제·보안 환경의 표준이다. Public internet 모드는 AWS 관리 네트워크로 편하지만 통제가 약하다. 금융·의료 시나리오에서 "데이터가 인터넷에 노출되면 안 된다"가 나오면 VPC only가 답이다.

학습(Training): 일시적 컨테이너에서 일어난다

SageMaker 학습의 핵심 메커니즘은 **학습 작업(Training Job)**이다. 학습을 요청하면 SageMaker가 다음 순서로 처리한다.

   [fit() 호출]
        │
        v
  ① 인스턴스 프로비저닝 (지정한 타입·개수)
        │
        v
  ② S3에서 학습 데이터 다운로드/스트리밍
        │
        v
  ③ 컨테이너 안에서 학습 코드 실행
        │
        v
  ④ 모델 산출물(model.tar.gz)을 S3에 저장
        │
        v
  ⑤ 인스턴스 자동 종료  ← 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 엔지니어가 학습 비용을 줄이는 흔한 기법이다. 학습은 중단돼도 체크포인트에서 재개할 수 있으므로 저렴한 스팟 인스턴스에 적합하다.

⚠️ 함정: 스팟은 싸지만 언제든 회수될 수 있다. 체크포인트 없이 스팟으로 장시간 학습을 돌리면 중단 시 처음부터 다시 해야 해 오히려 손해다. "비용 절감"이라는 단서만 보고 스팟을 고르되, 중단 내성(체크포인트)이 함께 언급되는지 확인하라.

추론(Inference): 네 가지 옵션

학습된 모델을 서빙하는 방법은 트래픽 패턴에 따라 네 가지다. MLA-C01에서 가장 자주 묻는 비교다.

판별은 트래픽 모양으로 한다.

• "초당 수천 요청, 낮은 지연" → 실시간 엔드포인트
• "하루 한 번 전체 고객 점수 매기기" → 배치 변환
• "가끔 들어오고 유휴 비용이 아깝다" → 서버리스 추론
• "이미지·영상처럼 큰 입력에 처리가 오래 걸린다" → 비동기 추론

# 실시간 엔드포인트 배포
predictor = estimator.deploy(
    initial_instance_count=1, instance_type="ml.m5.large",
    endpoint_name="churn-endpoint",
)
result = predictor.predict(payload)   # ms 단위 응답

              요청이 계속 들어오나?
                   │
        ┌──── 예 ──┴── 아니오 ────┐
        │                         │
  지연이 중요한가?          한 번에 대량인가?
   │         │                │        │
  예        아니오            예       아니오
   │         │                │        │
실시간   비동기(큰 입력)   배치 변환   서버리스

💡 관련 이론: 서버리스 추론은 "유휴 비용 0 vs 콜드 스타트 지연"이라는 고전적 트레이드오프다. 트래픽이 없을 때 인스턴스를 0으로 줄여 비용을 안 받지만, 다음 요청 시 컨테이너를 새로 띄우는 콜드 스타트가 생긴다. 지연이 일관되게 낮아야 하는 서비스는 실시간 엔드포인트(상시 가동)를, 비용 민감하고 간헐적이면 서버리스를 고른다. 이는 Lambda의 콜드 스타트 트레이드오프와 같은 구조다.

빌트인 알고리즘: 직접 안 짜도 되는 17종

SageMaker는 검증된 알고리즘 약 17종을 컨테이너로 제공한다. 직접 모델 코드를 작성할 필요 없이 데이터와 하이퍼파라미터만 넘기면 된다. 문제 유형별로 대표를 기억해두면 시험에서 빠르게 고른다.

빌트인이 안 맞으면 어떻게 하나 — 세 단계로 넓어진다.

"테이블 데이터 분류/회귀"는 거의 항상 XGBoost가 기본 답이다.

⚠️ 함정: 빌트인 알고리즘은 입력 포맷 요구가 있다. 여러 알고리즘이 CSV 외에 RecordIO-protobuf를 지원하며, 대용량 순차 학습에서는 후자가 유리하다. "빌트인을 쓰는데 데이터가 준비되지 않아 실패"하는 시나리오는 포맷·컨텐츠 타입 불일치를 의심하라.

엔드포인트를 여러 모델로 운영하기

모델이 수십·수백 개로 늘면 모델마다 엔드포인트를 두는 것이 비효율적이다. SageMaker는 하나의 엔드포인트에 여러 모델을 얹는 방식을 제공한다.

• 멀티모델은 자주 안 쓰이는 모델까지 상시 인스턴스를 잡아두는 낭비를 없앤다.
• 대신 오랫동안 호출되지 않은 모델은 처음 요청 시 로드 지연이 생길 수 있다.
• variant 가중치 조정은 Day 1에서 본 카나리 배포의 실행 수단이다.

모델 산출물과 레지스트리

학습 작업이 끝나면 산출물은 model.tar.gz 형태로 output_path에 저장된다. 이 파일이 배포의 재료다.

[Training Job] ──> s3://bucket/models/<job-name>/output/model.tar.gz
                          │
                          ├──> [Model] 생성(이미지 + 산출물 + 역할)
                          │        │
                          │        ├──> 실시간 엔드포인트
                          │        └──> 배치 변환 작업
                          │
                          └──> [Model Registry] 버전 등록·승인 상태 관리

Model Registry는 "어떤 모델 버전이 승인되어 프로덕션에 나갈 수 있는가"를 관리한다. 자동 재학습 파이프라인에서 승인 단계를 두는 지점이 여기다.

학습·추론 운영에서 흔한 실수

다음 글에서는 이번 주에 배운 ML 기초와 AWS 스택을 종합 복습하며 Week 1을 마무리한다.

📖 용어

• SageMaker Studio : 노트북·실험·파이프라인·배포를 한 화면에서 다루는 ML 전용 브라우저 IDE.
• 컴퓨팅-스토리지 분리 : 코드는 영구 저장소에 두고 실행 자원은 필요할 때만 붙이는 구조. 유휴 비용을 없앤다.
• 커널(kernel) : 노트북 코드를 실제로 실행하는 인스턴스. CPU/GPU로 갈아끼울 수 있다.
• 도메인(Domain) : Studio 환경의 최상위 경계. VPC·인증·공유 스토리지를 묶는 팀 단위 울타리.
• 사용자 프로필(User Profile) : 도메인 안의 개인 계정. 각자 IAM 역할과 홈 디렉터리를 가진다.
• VPC only 모드 : Studio 트래픽을 고객 VPC로만 흐르게 해 인터넷 노출을 막는 네트워크 설정.
• 학습 작업(Training Job) : 인스턴스를 띄워 학습하고 산출물을 S3에 남긴 뒤 스스로 꺼지는 일회성 작업.
• 스팟 인스턴스 : 남는 용량을 싸게 쓰는 대신 언제든 회수될 수 있는 인스턴스. 체크포인트와 함께 쓴다.
• 콜드 스타트 : 유휴 상태에서 첫 요청이 왔을 때 컨테이너를 새로 띄우느라 생기는 초기 지연.
• 배치 변환(Batch Transform) : 상시 엔드포인트 없이 대량 데이터를 한 번에 채점하고 끝나는 추론 방식.