AWS SageMaker 완벽 가이드 - ML 플랫폼 기초

AWS SageMaker를 처음 시작하는 개발자를 위한 실전 가이드입니다. Studio 설정부터 모델 배포까지, 머신러닝 워크플로우의 핵심을 단계별로 살펴봅니다.

---

목차

1. SageMaker_Studio_설정
2. IAM_역할_구성하기
3. Training_Jobs_실행하기
4. 하이퍼파라미터_튜닝
5. Spot_Instance로_비용_절감
6. Endpoints_배포하기

---

1. SageMaker Studio 설정

김개발 씨는 회사에서 처음으로 머신러닝 프로젝트를 맡게 되었습니다. 로컬 컴퓨터에서 주피터 노트북으로 모델을 만들어봤지만, 본격적인 프로덕션 환경은 어떻게 구축해야 할지 막막했습니다.

선배가 추천해준 것은 바로 AWS SageMaker Studio였습니다.

SageMaker Studio는 머신러닝을 위한 통합 개발 환경입니다. 마치 개발자에게 VS Code가 있듯이, 데이터 사이언티스트에게는 SageMaker Studio가 있습니다.

데이터 준비부터 모델 학습, 배포까지 모든 ML 워크플로우를 한 곳에서 처리할 수 있습니다.

다음 코드를 살펴봅시다.

import boto3

# SageMaker 클라이언트 생성
sagemaker_client = boto3.client('sagemaker', region_name='ap-northeast-2')

# Studio 도메인 생성
response = sagemaker_client.create_domain(
    DomainName='my-ml-studio',
    AuthMode='IAM',  # IAM 인증 방식 사용
    DefaultUserSettings={
        'ExecutionRole': 'arn:aws:iam::123456789012:role/SageMakerRole'
    },
    SubnetIds=['subnet-xxxxx'],
    VpcId='vpc-xxxxx'
)

print(f"Domain ARN: {response['DomainArn']}")

김개발 씨는 입사 6개월 차 개발자입니다. 어느 날 팀장님이 다가와 말했습니다.

"개발 씨, 이번에 추천 시스템 모델을 만들어봐요. AWS에서 해보면 좋겠어요." 로컬에서 주피터 노트북으로 간단한 모델은 만들어봤지만, 클라우드 환경은 처음이었습니다.

김개발 씨는 AWS 콘솔에 접속해서 SageMaker를 찾아보기 시작했습니다. 그렇다면 SageMaker Studio란 정확히 무엇일까요?

쉽게 비유하자면, SageMaker Studio는 마치 요리사를 위한 최신식 주방과 같습니다. 일반 주방에서는 재료를 사러 마트에 가고, 조리 도구를 따로 구비하고, 음식을 담을 그릇도 준비해야 합니다.

하지만 최신식 주방에는 이 모든 것이 갖춰져 있습니다. SageMaker Studio도 마찬가지입니다.

데이터 준비, 모델 학습, 배포에 필요한 모든 도구가 한 곳에 모여 있습니다. SageMaker Studio가 없던 시절에는 어땠을까요?

개발자들은 EC2 인스턴스를 직접 띄우고, 주피터 노트북을 설치하고, 필요한 라이브러리를 하나하나 세팅해야 했습니다. GPU 드라이버 설치에서 막히는 경우도 허다했습니다.

더 큰 문제는 팀원들과의 협업이었습니다. 각자 다른 환경에서 작업하다 보니 "내 컴퓨터에서는 되는데요?"라는 말이 자주 오갔습니다.

바로 이런 문제를 해결하기 위해 SageMaker Studio가 등장했습니다. Studio를 사용하면 브라우저만 열면 바로 ML 개발을 시작할 수 있습니다.

또한 팀원 모두가 같은 환경에서 작업하기 때문에 협업이 수월해집니다. 무엇보다 인프라 관리에 신경 쓰지 않고 모델 개발에만 집중할 수 있다는 큰 이점이 있습니다.

위의 코드를 살펴보겠습니다. 먼저 boto3 클라이언트를 생성합니다.

이것이 AWS 서비스와 소통하는 창구 역할을 합니다. create_domain 함수에서 AuthMode를 IAM으로 설정하면 AWS IAM 사용자로 인증할 수 있습니다.

DefaultUserSettings에는 Studio 사용자가 기본으로 사용할 IAM 역할을 지정합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 추천 시스템을 개발한다고 가정해봅시다. 데이터 엔지니어는 Studio에서 데이터를 전처리하고, 데이터 사이언티스트는 같은 환경에서 모델을 실험합니다.

ML 엔지니어는 완성된 모델을 바로 배포 파이프라인에 연결할 수 있습니다. 모든 작업 히스토리가 기록되어 감사 추적도 용이합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 VPC 설정을 제대로 하지 않는 것입니다.

Studio가 다른 AWS 리소스에 접근하려면 적절한 네트워크 설정이 필수입니다. 따라서 VPC, 서브넷, 보안 그룹을 미리 잘 계획해두어야 합니다.

김개발 씨는 AWS 콘솔에서 몇 번의 클릭만으로 Studio 도메인을 생성했습니다. 브라우저에서 바로 주피터 환경이 열리는 것을 보며 감탄했습니다.

"이제 진짜 ML 개발을 시작할 수 있겠군요!"

실전 팁

💡 - Studio 도메인은 리전당 하나만 생성할 수 있으니 신중하게 계획하세요

• 비용 절감을 위해 사용하지 않는 커널은 꼭 종료해두세요

---

2. IAM 역할 구성하기

김개발 씨가 SageMaker Studio에서 S3 버킷의 데이터를 읽으려고 했습니다. 그런데 "Access Denied" 에러가 떴습니다.

분명히 S3에 데이터가 있는데 왜 접근이 안 되는 걸까요? 박시니어 씨가 다가와 말했습니다.

"IAM 역할 설정은 했어요?"

IAM 역할은 SageMaker가 다른 AWS 서비스에 접근할 수 있는 권한을 부여합니다. 마치 회사에서 출입증이 있어야 특정 구역에 들어갈 수 있듯이, SageMaker도 적절한 IAM 역할이 있어야 S3, ECR 등의 서비스를 사용할 수 있습니다.

다음 코드를 살펴봅시다.

import json

# SageMaker 실행 역할을 위한 신뢰 정책
trust_policy = {
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {"Service": "sagemaker.amazonaws.com"},
        "Action": "sts:AssumeRole"
    }]
}

# IAM 클라이언트로 역할 생성
iam_client = boto3.client('iam')
iam_client.create_role(
    RoleName='SageMakerExecutionRole',
    AssumeRolePolicyDocument=json.dumps(trust_policy)
)

# S3 접근 권한 추가
iam_client.attach_role_policy(
    RoleName='SageMakerExecutionRole',
    PolicyArn='arn:aws:iam::aws:policy/AmazonS3FullAccess'
)

김개발 씨는 당황했습니다. 코드는 분명히 맞는 것 같은데 자꾸 권한 에러가 납니다.

박시니어 씨가 옆에 앉아 설명을 시작했습니다. "클라우드에서는 보안이 정말 중요해요.

모든 서비스가 서로 접근하려면 명시적인 허가가 필요합니다." 그렇다면 IAM 역할이란 정확히 무엇일까요? 쉽게 비유하자면, IAM 역할은 마치 호텔 키카드와 같습니다.

호텔에 투숙하면 키카드를 받는데, 이 카드로 내 방에는 들어갈 수 있지만 다른 손님 방에는 못 들어갑니다. 수영장 이용권이 포함된 키카드라면 수영장에도 들어갈 수 있겠죠.

IAM 역할도 마찬가지입니다. 어떤 서비스에 접근할 수 있는지를 정의하는 디지털 키카드인 셈입니다.

IAM 역할이 제대로 설정되지 않으면 어떻게 될까요? SageMaker 노트북에서 S3 데이터를 읽을 수 없습니다.

학습된 모델을 S3에 저장할 수도 없습니다. 더 심각한 경우에는 Training Job 자체가 실행되지 않습니다.

개발자는 코드가 맞는데 왜 안 되는지 한참을 헤매게 됩니다. 바로 이런 문제를 방지하기 위해 IAM 역할을 처음부터 제대로 설정해야 합니다.

위의 코드에서 핵심은 **신뢰 정책(Trust Policy)**입니다. 이 정책은 "sagemaker.amazonaws.com 서비스가 이 역할을 맡을 수 있다"고 선언합니다.

그 다음 attach_role_policy로 실제 권한을 부여합니다. 여기서는 S3 전체 접근 권한을 추가했습니다.

실제 현업에서는 보안을 위해 더 세밀한 권한 설정을 합니다. 예를 들어 특정 S3 버킷만 접근하도록 제한하거나, 읽기 전용 권한만 부여하기도 합니다.

**최소 권한 원칙(Principle of Least Privilege)**을 따르는 것이 보안의 기본입니다. 초보 개발자들이 흔히 하는 실수가 있습니다.

테스트할 때 편하다고 AdministratorAccess 권한을 부여하는 것입니다. 이렇게 하면 당장은 편하지만, 보안 사고의 원인이 될 수 있습니다.

프로덕션 환경에서는 절대 이렇게 하면 안 됩니다. 김개발 씨는 박시니어 씨의 도움으로 IAM 역할을 올바르게 설정했습니다.

S3 데이터가 정상적으로 읽히는 것을 확인하고 안도의 한숨을 쉬었습니다. "보안이 이렇게 중요한 거였군요."

실전 팁

💡 - 프로덕션에서는 반드시 최소 권한 원칙을 따르세요

• IAM 정책 시뮬레이터를 활용하면 권한을 미리 테스트할 수 있습니다

---

3. Training Jobs 실행하기

드디어 김개발 씨가 모델 학습을 시작할 차례입니다. 로컬에서는 model.fit()으로 간단히 학습했는데, SageMaker에서는 어떻게 해야 할까요?

데이터도 크고 학습 시간도 오래 걸릴 텐데, 내 노트북을 계속 켜둬야 하는 걸까요?

Training Job은 SageMaker에서 모델을 학습시키는 핵심 기능입니다. 마치 빨래를 세탁기에 맡기면 알아서 돌아가듯이, Training Job을 제출하면 SageMaker가 인프라를 자동으로 관리하며 학습을 진행합니다.

학습이 끝나면 결과 모델이 S3에 저장됩니다.

다음 코드를 살펴봅시다.

from sagemaker.estimator import Estimator

# XGBoost 알고리즘을 사용하는 Estimator 생성
estimator = Estimator(
    image_uri='123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/xgboost:latest',
    role='arn:aws:iam::123456789012:role/SageMakerExecutionRole',
    instance_count=1,
    instance_type='ml.m5.xlarge',  # 학습용 인스턴스 타입
    output_path='s3://my-bucket/model-output',
    hyperparameters={
        'max_depth': 5,
        'eta': 0.2,
        'objective': 'binary:logistic'
    }
)

# 학습 시작 - S3의 데이터를 입력으로 사용
estimator.fit({'train': 's3://my-bucket/train-data'})

김개발 씨는 로컬에서 만든 모델이 잘 동작하는 것을 확인했습니다. 하지만 문제가 있었습니다.

실제 서비스 데이터는 수십 GB에 달했고, 로컬 컴퓨터로는 며칠이 걸릴 것 같았습니다. 박시니어 씨가 조언했습니다.

"SageMaker Training Job을 사용하면 돼요. 클라우드의 강력한 GPU 인스턴스에서 학습할 수 있어요." 그렇다면 Training Job이란 정확히 무엇일까요?

쉽게 비유하자면, Training Job은 마치 자동 세차장과 같습니다. 일반 세차는 직접 물을 뿌리고 비누칠을 해야 합니다.

하지만 자동 세차장에서는 차를 맡기고 기다리기만 하면 됩니다. 세차가 끝나면 깨끗해진 차를 받아갑니다.

Training Job도 마찬가지입니다. 데이터와 알고리즘을 맡기면 SageMaker가 알아서 학습을 진행하고, 완성된 모델을 돌려줍니다.

Training Job 없이 직접 EC2에서 학습하면 어떨까요? 인스턴스를 띄우고, 환경을 설정하고, 학습 스크립트를 실행해야 합니다.

학습 중간에 인스턴스가 죽으면? 처음부터 다시 해야 합니다.

학습이 끝났는데 인스턴스를 끄는 것을 잊으면? 비용이 계속 나갑니다.

이런 관리 부담이 상당합니다. Training Job은 이 모든 것을 자동화합니다.

위의 코드에서 Estimator 클래스가 핵심입니다. image_uri는 학습에 사용할 알고리즘 컨테이너 이미지입니다.

AWS에서 제공하는 빌트인 알고리즘을 사용하거나, 직접 만든 커스텀 이미지를 사용할 수 있습니다. instance_type은 학습에 사용할 인스턴스 종류입니다.

단순한 모델이라면 ml.m5.xlarge로 충분하지만, 딥러닝 모델이라면 ml.p3.2xlarge 같은 GPU 인스턴스가 필요합니다. fit() 메서드를 호출하면 실제 학습이 시작됩니다.

SageMaker는 지정된 인스턴스를 프로비저닝하고, 데이터를 다운로드하고, 학습을 실행합니다. 학습이 끝나면 모델 아티팩트를 S3에 저장하고 인스턴스를 자동으로 종료합니다.

실제 현업에서는 다양한 옵션을 활용합니다. Spot Instance를 사용해 비용을 70%까지 절감하거나, 분산 학습으로 여러 인스턴스에서 동시에 학습을 진행하기도 합니다.

Checkpointing을 설정해서 학습 중간 결과를 저장하면, 학습이 중단되더라도 이어서 진행할 수 있습니다. 김개발 씨는 Training Job을 제출하고 CloudWatch에서 로그를 확인했습니다.

로컬에서 하루가 걸리던 학습이 2시간 만에 끝났습니다. "클라우드의 힘이 이런 거구나!"

실전 팁

💡 - 학습 전에 작은 데이터셋으로 먼저 테스트해서 코드 오류를 잡으세요

• CloudWatch Logs에서 학습 진행 상황을 실시간으로 확인할 수 있습니다

---

4. 하이퍼파라미터 튜닝

김개발 씨의 모델 정확도는 85%였습니다. 나쁘지 않지만 팀장님은 90% 이상을 원했습니다.

하이퍼파라미터를 조정하면 성능이 올라간다는데, learning_rate는 얼마로 해야 하고, max_depth는 몇으로 해야 할까요? 경우의 수가 너무 많았습니다.

하이퍼파라미터 튜닝은 최적의 모델 설정값을 자동으로 찾아주는 기능입니다. 마치 요리에서 소금 양, 불 세기, 조리 시간을 조절해가며 최고의 맛을 찾듯이, SageMaker가 다양한 하이퍼파라미터 조합을 실험하며 최적의 모델을 찾아줍니다.

다음 코드를 살펴봅시다.

from sagemaker.tuner import HyperparameterTuner, ContinuousParameter, IntegerParameter

# 튜닝할 하이퍼파라미터 범위 정의
hyperparameter_ranges = {
    'eta': ContinuousParameter(0.01, 0.3),      # 학습률
    'max_depth': IntegerParameter(3, 10),       # 트리 깊이
    'min_child_weight': IntegerParameter(1, 10) # 최소 자식 가중치
}

# 튜닝 작업 생성
tuner = HyperparameterTuner(
    estimator=estimator,
    objective_metric_name='validation:auc',
    hyperparameter_ranges=hyperparameter_ranges,
    max_jobs=20,       # 최대 20개 조합 시도
    max_parallel_jobs=4 # 동시에 4개씩 실행
)

# 튜닝 시작
tuner.fit({'train': 's3://my-bucket/train', 'validation': 's3://my-bucket/val'})

김개발 씨는 하이퍼파라미터 튜닝의 늪에 빠졌습니다. learning_rate를 0.1로 했더니 85%, 0.05로 했더니 83%, 0.2로 했더니 82%.

이것 말고도 조절할 파라미터가 열 개가 넘습니다. 모든 조합을 시도하려면 평생이 걸릴 것 같았습니다.

박시니어 씨가 구원의 손길을 내밀었습니다. "SageMaker 하이퍼파라미터 튜닝을 써봐요.

자동으로 최적값을 찾아줘요." 그렇다면 하이퍼파라미터 튜닝이란 정확히 무엇일까요? 쉽게 비유하자면, 라디오 주파수를 맞추는 것과 같습니다.

옛날 라디오는 다이얼을 돌려가며 잡음이 없는 주파수를 찾아야 했습니다. 조금만 틀어져도 지직거리고, 딱 맞으면 선명하게 들립니다.

하이퍼파라미터도 마찬가지입니다. 딱 맞는 값을 찾으면 모델 성능이 확 올라갑니다.

수동으로 튜닝하면 어떤 문제가 있을까요? 첫째, 시간이 너무 오래 걸립니다.

파라미터 하나당 10가지 값을 시도한다면, 파라미터 5개면 10만 가지 조합입니다. 둘째, 사람의 직관에는 한계가 있습니다.

최적의 조합이 예상과 전혀 다른 곳에 있을 수 있습니다. SageMaker의 하이퍼파라미터 튜닝은 베이지안 최적화를 사용합니다.

이전 실험 결과를 바탕으로 다음에 시도할 값을 똑똑하게 선택합니다. 무작위로 시도하는 것보다 훨씬 빠르게 최적값에 수렴합니다.

위의 코드에서 hyperparameter_ranges에 탐색할 범위를 정의합니다. ContinuousParameter는 연속적인 실수 값, IntegerParameter는 정수 값을 탐색합니다.

objective_metric_name은 최적화 목표 지표입니다. 여기서는 검증 세트의 AUC를 최대화하도록 설정했습니다.

max_jobs는 총 실험 횟수, max_parallel_jobs는 동시에 실행할 실험 수입니다. 동시에 여러 실험을 돌리면 시간을 크게 단축할 수 있습니다.

실제 현업에서는 비용과 시간의 균형을 고려합니다. 너무 많은 실험을 하면 비용이 늘어나고, 너무 적으면 최적값을 놓칠 수 있습니다.

보통 20-50개 정도의 실험으로 시작해서 결과를 보며 조정합니다. 김개발 씨는 튜닝 작업을 제출하고 다음 날 출근했습니다.

결과를 확인하니 정확도가 92%까지 올라 있었습니다. 최적 파라미터는 eta=0.08, max_depth=7이었는데, 직접 시도했던 값들과는 꽤 달랐습니다.

"역시 자동화의 힘이구나!"

실전 팁

💡 - 처음에는 넓은 범위로 탐색하고, 결과를 보며 범위를 좁혀가세요

• Warm Start 기능으로 이전 튜닝 결과를 활용할 수 있습니다

---

5. Spot Instance로 비용 절감

김개발 씨의 팀은 매달 AWS 비용이 늘어나는 것을 걱정하고 있었습니다. 특히 대규모 모델 학습에 GPU 인스턴스를 사용하면 비용이 어마어마했습니다.

팀장님이 물었습니다. "비용을 줄일 방법이 없을까요?" 박시니어 씨가 답했습니다.

"Spot Instance를 써보는 건 어때요?"

Spot Instance는 AWS의 여유 컴퓨팅 자원을 할인된 가격에 사용하는 방식입니다. 마치 항공사의 땡처리 티켓처럼, 남는 자원을 최대 90%까지 저렴하게 사용할 수 있습니다.

단, AWS가 자원을 회수하면 작업이 중단될 수 있어 체크포인트 설정이 필수입니다.

다음 코드를 살펴봅시다.

from sagemaker.estimator import Estimator

# Spot Instance를 사용하는 Estimator 설정
estimator = Estimator(
    image_uri='123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/pytorch:latest',
    role='arn:aws:iam::123456789012:role/SageMakerExecutionRole',
    instance_count=1,
    instance_type='ml.p3.2xlarge',
    output_path='s3://my-bucket/output',
    # Spot Instance 설정
    use_spot_instances=True,           # Spot 사용 활성화
    max_run=3600,                       # 최대 실행 시간 (초)
    max_wait=7200,                      # 최대 대기 시간 (초)
    checkpoint_s3_uri='s3://my-bucket/checkpoints'  # 체크포인트 저장 위치
)

estimator.fit({'train': 's3://my-bucket/train'})

김개발 씨는 지난달 AWS 청구서를 보고 놀랐습니다. 모델 학습에만 200만원이 넘게 나왔습니다.

GPU 인스턴스 ml.p3.2xlarge는 시간당 약 4천원인데, 여러 실험을 하다 보니 비용이 눈덩이처럼 불어났습니다. 박시니어 씨가 제안했습니다.

"Spot Instance를 사용하면 같은 인스턴스를 70-90% 저렴하게 쓸 수 있어요." 그렇다면 Spot Instance란 정확히 무엇일까요? 쉽게 비유하자면, 호텔의 당일 할인과 같습니다.

호텔은 빈 방을 그냥 두느니 할인해서라도 팔고 싶어합니다. AWS도 마찬가지입니다.

사용되지 않는 서버 자원을 저렴하게 제공합니다. 단, 정가 손님이 오면 방을 비워줘야 하듯이, AWS가 자원을 필요로 하면 Spot Instance는 2분 전 경고와 함께 종료됩니다.

그렇다면 학습 중에 인스턴스가 종료되면 어떻게 될까요? 아무 준비가 없다면 처음부터 다시 학습해야 합니다.

몇 시간 동안 학습하다가 갑자기 중단되면 그 시간과 비용이 모두 날아갑니다. 바로 이런 문제를 방지하기 위해 **체크포인트(Checkpoint)**가 필수입니다.

위의 코드에서 use_spot_instances=True로 Spot 사용을 활성화합니다. max_run은 학습 자체의 최대 시간, max_wait는 Spot 자원을 기다리는 최대 시간입니다.

Spot은 항상 바로 사용 가능하지 않을 수 있어서 대기 시간을 설정합니다. 가장 중요한 것은 checkpoint_s3_uri 설정입니다.

학습 중간 결과를 S3에 주기적으로 저장합니다. 인스턴스가 종료되더라도 마지막 체크포인트부터 이어서 학습할 수 있습니다.

실제 현업에서는 Spot을 전략적으로 사용합니다. 모든 학습에 Spot을 쓰는 것은 아닙니다.

급하게 결과가 필요한 경우에는 온디맨드 인스턴스를, 시간 여유가 있는 실험적 학습에는 Spot을 사용합니다. 하이퍼파라미터 튜닝처럼 여러 실험을 동시에 돌릴 때 Spot이 특히 효과적입니다.

주의할 점도 있습니다. Spot의 가용성은 지역과 인스턴스 타입에 따라 다릅니다.

인기 있는 GPU 인스턴스는 Spot으로 구하기 어려울 수 있습니다. 또한 체크포인트 저장 주기를 너무 짧게 하면 오버헤드가 커지고, 너무 길게 하면 중단 시 손실이 커집니다.

김개발 씨는 Spot Instance를 적용한 후 다음 달 청구서를 확인했습니다. 같은 양의 학습을 했는데 비용이 60만원으로 줄었습니다.

"이렇게 절약할 수 있었다니!"

실전 팁

💡 - 학습 코드에서 체크포인트 저장 로직을 꼭 구현하세요

• Spot 인스턴스 중단 알림을 CloudWatch로 모니터링할 수 있습니다

---

6. Endpoints 배포하기

김개발 씨의 모델이 드디어 완성되었습니다. 정확도도 높고, 팀장님도 만족했습니다.

이제 남은 것은 실제 서비스에서 사용할 수 있도록 배포하는 것입니다. "모델을 API로 만들어서 다른 팀에서도 호출할 수 있게 해주세요." 어떻게 해야 할까요?

SageMaker Endpoint는 학습된 모델을 실시간 API로 배포하는 서비스입니다. 마치 레스토랑에서 주문을 받으면 요리를 내어주듯이, Endpoint는 예측 요청을 받으면 모델 추론 결과를 반환합니다.

트래픽에 따라 자동 확장되며, 여러 모델 버전을 동시에 운영할 수도 있습니다.

다음 코드를 살펴봅시다.

from sagemaker.predictor import Predictor
from sagemaker.serializers import JSONSerializer
from sagemaker.deserializers import JSONDeserializer

# 학습된 모델을 엔드포인트로 배포
predictor = estimator.deploy(
    initial_instance_count=1,
    instance_type='ml.m5.large',       # 추론용 인스턴스
    endpoint_name='my-recommendation-endpoint'
)

# 예측 요청 보내기
predictor.serializer = JSONSerializer()
predictor.deserializer = JSONDeserializer()

# 실시간 추론
result = predictor.predict({
    'user_id': '12345',
    'item_features': [0.1, 0.5, 0.3, 0.8]
})
print(f"추천 결과: {result}")

김개발 씨는 모델 파일을 손에 들고 고민에 빠졌습니다. pickle 파일로 저장된 모델을 어떻게 API로 만들지?

Flask 서버를 직접 구축해야 하나? 트래픽이 많아지면 서버를 어떻게 확장하지?

박시니어 씨가 옆에서 말했습니다. "SageMaker Endpoint를 사용하면 한 줄로 배포할 수 있어요.

나머지는 AWS가 다 알아서 해줍니다." 그렇다면 SageMaker Endpoint란 정확히 무엇일까요? 쉽게 비유하자면, 패스트푸드점의 드라이브 스루와 같습니다.

손님이 마이크로 주문하면(요청), 주방에서 음식을 만들고(추론), 창구로 전달합니다(응답). 손님이 많아지면 창구를 늘리고(오토스케일링), 한가해지면 줄입니다.

Endpoint도 이와 똑같이 동작합니다. Endpoint 없이 직접 서버를 구축하면 어떨까요?

EC2에 Flask 서버를 올리고, 모델을 로드하고, API를 만들어야 합니다. 로드밸런서를 설정하고, 오토스케일링 그룹을 구성해야 합니다.

모델이 업데이트되면 배포 파이프라인도 만들어야 합니다. 인프라 관리에 엄청난 시간이 소요됩니다.

SageMaker Endpoint는 이 모든 것을 자동화합니다. 위의 코드에서 deploy() 메서드 한 줄이 모든 것을 처리합니다.

지정된 인스턴스를 프로비저닝하고, 모델을 로드하고, 외부에서 접근할 수 있는 HTTPS 엔드포인트를 생성합니다. initial_instance_count는 초기 인스턴스 수입니다.

트래픽이 늘어나면 오토스케일링 정책에 따라 자동으로 인스턴스가 추가됩니다. instance_type은 추론에 사용할 인스턴스입니다.

학습 때보다 작은 인스턴스를 사용하는 것이 일반적입니다. Serializer와 Deserializer는 데이터 형식을 지정합니다.

JSON으로 요청을 보내고 JSON으로 응답을 받도록 설정했습니다. 실제 현업에서는 다양한 배포 전략을 사용합니다.

A/B 테스트로 여러 모델 버전의 성능을 비교할 수 있습니다. 트래픽의 10%는 새 모델로, 90%는 기존 모델로 보내는 식입니다.

카나리 배포로 새 버전을 점진적으로 롤아웃할 수도 있습니다. 주의할 점도 있습니다.

Endpoint는 항상 켜져 있으므로 비용이 계속 발생합니다. 개발이나 테스트 중에는 사용 후 반드시 삭제해야 합니다.

또한 콜드 스타트 문제가 있어서, 오랫동안 요청이 없다가 갑자기 요청이 오면 첫 응답이 느릴 수 있습니다. 김개발 씨는 Endpoint를 배포하고 다른 팀에 API 주소를 공유했습니다.

프론트엔드 팀에서 추천 기능을 호출하자 수 밀리초 만에 결과가 반환되었습니다. "드디어 내가 만든 모델이 실제 서비스에서 동작하는구나!"

실전 팁

💡 - 개발 환경의 Endpoint는 반드시 사용 후 삭제하세요 (predictor.delete_endpoint())

• 서버리스 추론(Serverless Inference)을 사용하면 요청이 있을 때만 비용이 발생합니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!