Day 3 - AWS ML 스택 한눈에 보기

AWS ML 스택의 3층 구조

AWS의 ML 관련 서비스는 수십 개라 처음 보면 막막하다. 하지만 "직접 모델을 만들 거냐, 완성된 모델을 API로 호출할 거냐, 아니면 바닥 인프라부터 다룰 거냐"라는 질문 하나로 세 개의 층에 깔끔하게 정리된다.

┌─────────────────────────────────────────────────┐  추상화 ↑
│ 상위: AI 서비스 (사전 학습 모델, API 호출만)        │  통제권 ↓
│   Rekognition, Comprehend, Transcribe,           │  ML 전문성 ↓
│   Translate, Polly, Textract, Forecast, Bedrock  │  구현 속도 ↑
├─────────────────────────────────────────────────┤
│ 중위: ML 플랫폼 (직접 학습·배포)                    │
│   Amazon SageMaker (AI)                          │
├─────────────────────────────────────────────────┤
│ 하위: ML 인프라 (직접 컴퓨팅 관리)                  │  추상화 ↓
│   EC2(GPU), Inferentia, Trainium, EKS, ECS, FSx  │  통제권 ↑
└─────────────────────────────────────────────────┘  운영 부담 ↑

세 층을 한 표로 비교하면 판별이 빨라진다.

판별 원칙은 추상화 레벨과 통제권의 트레이드오프다. ML 엔지니어는 "ML 전문성이 없어도 되는 표준 작업이면 위, 커스텀 모델이 필요하면 중간, 극한의 성능·비용 최적화가 필요하면 아래"로 고른다.

이건 공동 책임 모델의 ML 버전이다. AI 서비스는 모델 학습·인프라까지 AWS가 책임지고 고객은 API 호출과 데이터만, SageMaker는 모델 코드·데이터는 고객이지만 인프라 관리는 AWS가, EC2 자체 구축은 거의 모든 것을 고객이 책임진다. 추상화가 올라갈수록 책임 경계선이 위로 올라간다는 원칙이 그대로 적용된다.

상위: AI 서비스 — 모델 없이 ML 기능 쓰기

AI 서비스는 AWS가 미리 학습해둔 모델을 API 호출 한 번으로 쓰는 것이다. ML 지식이 거의 없어도 된다. 시험에 잘 나오는 매핑을 외워두면 시나리오 문제가 쉬워진다.

import boto3
 
# Comprehend로 감정 분석 — 모델 학습 0줄
comprehend = boto3.client("comprehend", region_name="ap-northeast-2")
resp = comprehend.detect_sentiment(
    Text="이 제품 정말 만족스럽고 배송도 빨랐어요!",
    LanguageCode="ko",
)
print(resp["Sentiment"])         # POSITIVE
print(resp["SentimentScore"])    # {'Positive': 0.98, ...}

위 코드에 학습 데이터도 모델도 없다. AWS의 사전 학습 모델을 호출만 한다. "고객 리뷰 감정을 분석하라"는 시나리오에 SageMaker로 모델을 만들겠다고 답하면 과한 선택이다 — Comprehend가 정답이다.

중간 선택지도 있다. AI 서비스와 SageMaker 사이에는 "사전 학습 모델을 내 라벨로 살짝 조정"하는 옵션이 있다.

"표준 감정 분석이면 기본 Comprehend, 우리 회사 고유 분류 체계가 필요하면 Custom"으로 판별한다. Custom 옵션은 SageMaker 풀 커스텀보다 훨씬 적은 노력으로 끝나므로, 시험에서 "최소한의 ML 전문성으로 도메인 특화"라는 조건이 붙으면 Custom 계열이 정답 후보다.

중위: SageMaker — 직접 모델을 만드는 곳

표준 AI 서비스로 안 되는 커스텀 모델이 필요하면 Amazon SageMaker다. 데이터 준비부터 학습·튜닝·배포·모니터링까지 ML 수명주기 전체를 담당하는 통합 플랫폼이며, MLA-C01의 사실상 주인공이다.

SageMaker가 제공하는 것을 수명주기 단계별로 보면:

# SageMaker는 "직접 학습"한다 — AI 서비스와 결정적 차이
from sagemaker.estimator import Estimator
 
estimator = Estimator(
    image_uri=sagemaker.image_uris.retrieve("xgboost", region, "1.7-1"),
    role=role, instance_count=1, instance_type="ml.m5.xlarge",
    hyperparameters={"objective": "binary:logistic", "num_round": 100},
)
estimator.fit({"train": "s3://my-bucket/train/", "validation": "s3://my-bucket/val/"})
predictor = estimator.deploy(initial_instance_count=1, instance_type="ml.t2.medium")

AI 서비스 코드와 비교해보면 차이가 분명하다. Comprehend는 detect_sentiment() 한 줄이지만, SageMaker는 학습 데이터·알고리즘·인스턴스·하이퍼파라미터를 전부 지정한다. 그 대가로 무엇이든 만들 수 있다.

내일(Day 4) SageMaker를 본격적으로 다룬다. 오늘은 "SageMaker는 커스텀 모델을 직접 학습·배포하는 중간 층"이라는 위치만 잡으면 된다.

하위: ML 인프라 — 성능과 비용을 직접 깎기

SageMaker가 추상화하는 그 아래에는 실제 컴퓨팅이 있다. 극한의 성능·비용 최적화가 필요하거나 기존 EKS/ECS 위에 ML을 얹어야 할 때 이 층을 직접 다룬다.

핵심 구분은 Trainium은 학습용, Inferentia는 추론용이라는 점이다. 두 작업은 연산 성격 자체가 다르다.

추론은 학습보다 훨씬 자주 일어나므로 추론 비용 절감이 총비용에 더 크게 기여한다. 그래서 AWS가 추론 전용 칩 Inferentia를 따로 만든 것이다.

대규모 추론 트래픽을 가진 서비스는 추론 비용이 학습 비용을 압도하는 경우가 많다. 모델은 한 번 학습하지만 추론은 사용자 요청마다 무한히 반복되기 때문이다. AWS가 GPU 외에 Inferentia라는 추론 전용 칩을 별도로 설계한 배경이 이것이고, 같은 모델을 GPU 대비 더 낮은 단가·전력으로 서빙해 총소유비용을 낮추는 것이 목표다. ML 엔지니어가 "학습 칩과 추론 칩을 분리해서 고른다"는 감각을 가져야 하는 이유다.

학습은 순전파+역전파로 그래디언트를 계산하고 큰 배치를 한 번에 처리(throughput 중심)하지만, 추론은 순전파만 하고 낮은 지연으로 작은 배치를 자주 처리(latency 중심)한다. 이 차이 때문에 Trainium(고처리량 학습)과 Inferentia(저지연 추론)를 칩 레벨에서 분리하는 것이 합리적이다.

시나리오로 층 고르기

시험 문제는 거의 항상 시나리오다. 판별 흐름을 정리하면:

시나리오를 읽는다
   │
   ├─ 이미지/음성/번역/OCR/감정 같은 표준 작업인가?
   │     예 → AI 서비스 (Rekognition, Comprehend, Textract ...)
   │           └─ 우리 회사 고유 분류/객체가 필요한가?
   │                 예 → Comprehend Custom / Rekognition Custom Labels
   │
   ├─ 고유 데이터로 커스텀 모델을 만들어야 하는가?
   │     예 → SageMaker (학습 → 튜닝 → 배포)
   │
   └─ 극한 비용·성능 최적화 또는 기존 컨테이너 통합인가?
         예 → EC2 GPU / Trainium(학습) / Inferentia(추론) / EKS·ECS

빠른 매핑 연습:

⚠️ 함정: "표준 작업인데 SageMaker로 직접 학습"은 시험에서 오답이 되기 쉽다. 기술적으로 가능하더라도 시간·비용·운영 부담이 과하기 때문이다. 반대로 "도메인 특화 데이터인데 기본 AI 서비스"도 오답이다. 지문에서 작업의 일반성 vs 고유성을 가르는 단서를 먼저 찾는다.

지문에서 층을 가르는 단서

시나리오 문제는 결국 몇 개의 단어로 층이 갈린다. 단서를 미리 표로 익혀두면 읽는 속도가 붙는다.

층을 잘못 고르면 생기는 손실

⚠️ 함정: "가장 정확한 방법"과 "가장 적절한 방법"은 다르다. 시험은 요구사항을 만족하는 가장 적은 노력·비용의 선택을 정답으로 본다. 기술적으로 가능한 답이 여러 개일 때는 운영 부담을 기준으로 거른다.

다음 글에서는 이 스택의 중심인 SageMaker를 본격적으로 파고들어, Studio·학습·추론·빌트인 알고리즘·도메인과 사용자 프로필 구조를 본다.

📖 용어

• AI 서비스 : AWS가 미리 학습해둔 모델을 API 호출만으로 쓰는 상위 계층 서비스. 학습이 필요 없다.
• 사전 학습 모델(pre-trained model) : 이미 대량 데이터로 학습을 마쳐 바로 쓸 수 있는 모델.
• 추상화 레벨 : 세부 사항을 얼마나 감춰주는가의 정도. 높을수록 편하지만 손댈 수 있는 게 줄어든다.
• 커스터마이징 : 내 데이터·요구에 맞게 모델을 고치는 것. AI 서비스는 제한적, SageMaker는 자유롭다.
• Comprehend Custom : 회사 고유 라벨로 Comprehend를 미세조정해 자체 분류·개체 추출을 만드는 기능.
• Rekognition Custom Labels : 일반 모델이 모르는 특정 도메인 객체를 이미지로 학습시키는 기능.
• Trainium(Trn1) : AWS가 만든 학습 전용 칩. 대규모 모델 학습 비용을 낮추는 것이 목표다.
• Inferentia(Inf2) : AWS가 만든 추론 전용 칩. 요청마다 반복되는 추론의 단가·전력을 낮춘다.
• 순전파 / 역전파 : 입력을 흘려 예측을 내는 계산 / 오차를 거슬러 보내 가중치를 고치는 계산.
• 처리량(throughput) vs 지연(latency) : 단위 시간에 얼마나 많이 처리하나 / 한 건이 얼마나 빨리 끝나나.