Day 1 - 추론 옵션 개요: 4가지 배포 방식과 선택 기준

4가지 추론 옵션 한눈에 보기

모델은 사용자 요청에 응답하거나 쌓인 데이터를 일괄 처리하는 형태로 배포(deployment)되어야 비로소 비즈니스 가치를 만든다. SageMaker는 추론(inference) 워크로드의 성격에 따라 4가지 방식을 제공하고, MLA-C01은 "이 시나리오에 어떤 방식인가"를 끊임없이 묻는다.

• 실시간·서버리스 = 동기(synchronous). 호출하면 그 자리에서 결과가 돌아온다.
• 비동기·배치 = 요청을 던지고 나중에 결과를 받는 구조다.

동기 vs 비동기 요청 흐름
 
[동기]   클라이언트 ── invoke_endpoint ──▶ 엔드포인트 ──▶ 모델
                   ◀────── 응답(ms~초) ──────────────────┘
         실시간 / 서버리스
 
[비동기] 클라이언트 ── invoke_endpoint_async ──▶ 내부 큐 ──▶ 엔드포인트
                   ◀── OutputLocation 즉시 반환              │
                                                    ┌────────┴────────┐
                                                    ▼                 ▼
                                              S3(결과 저장)      SNS(완료 알림)
 
[배치]   S3(입력) ──▶ [일시적 클러스터 N대 병렬 추론] ──▶ S3(출력) ──▶ 클러스터 종료
         엔드포인트 자체가 없다

import boto3
runtime = boto3.client("sagemaker-runtime")
 
# 실시간 엔드포인트 호출: 즉시 응답이 돌아온다
response = runtime.invoke_endpoint(
    EndpointName="my-realtime-endpoint",
    ContentType="application/json",
    Body='{"features": [5.1, 3.5, 1.4, 0.2]}',
)
result = response["Body"].read()

추론 옵션 선택은 본질적으로 "always-on 비용 vs 지연 시간(latency) vs 처리량(throughput)"의 삼각 트레이드오프다. 실시간 엔드포인트는 인스턴스를 항상 켜두므로 트래픽이 없어도 비용이 나가지만 지연이 가장 낮다. 서버리스는 트래픽이 0이면 비용도 0이지만 콜드 스타트(cold start) 지연이 생긴다. 배치는 대량 처리당 비용이 가장 효율적이지만 즉시성이 없다. 시험은 이 셋 중 무엇을 우선해야 하는지 시나리오로 묻는다.

실시간 엔드포인트 — 즉시 응답이 생명일 때

HTTPS 엔드포인트로 항상 켜진 인스턴스가 요청을 받아 밀리초~초 단위로 응답한다.

• 지정한 인스턴스가 24시간 가동 → 트래픽이 없어도 시간당 비용 발생
• 가장 낮은 지연 시간(low latency), 일관된 성능
• Auto Scaling으로 트래픽 증감에 인스턴스 수 조절 가능 — 단 최소 1대는 유지(0 불가)
• 페이로드 6MB 이하, 응답 60초 이내 제약
• 적합 사례: 추천 시스템, 사기 탐지, 챗봇처럼 사용자가 결과를 기다리고 있는 온라인 서비스

→ 트래픽이 꾸준하고 지연에 민감하면 실시간이 기본 선택지다.

서버리스 추론 — 트래픽이 들쭉날쭉할 때

인스턴스를 직접 관리하지 않고, 요청이 올 때만 컴퓨팅을 자동 프로비저닝한다.

• 트래픽이 없으면 0으로 스케일 다운 → 유휴 비용이 들지 않는다
• 지정할 것은 메모리 크기(1~6GB)와 최대 동시성(MaxConcurrency) 둘뿐 — 인스턴스 타입을 고르지 않는다
• 페이로드 4MB 이하, 처리 60초 이내
• 적합 사례: 사내 도구, 가끔 호출되는 데모, 트래픽이 들쑥날쑥한 신규 서비스

# 서버리스 엔드포인트 구성 — 메모리와 동시성만 지정
serverless_config = {
    "MemorySizeInMB": 2048,
    "MaxConcurrency": 10,
}

단점은 콜드 스타트다. 한동안 호출이 없다가 첫 요청이 오면 컨테이너를 띄우는 동안 지연이 생긴다. 일관된 저지연이 필요하면 부적합하다.

⚠️ 함정: "비용을 줄이고 싶다"는 키워드만 보고 무조건 서버리스를 고르면 안 된다. 트래픽이 꾸준히 많은 워크로드에서는 서버리스가 오히려 실시간 엔드포인트보다 비쌀 수 있다. 서버리스의 비용 이점은 "유휴 시간이 많을 때" 발생한다. 또 콜드 스타트를 못 견디는 SLA가 있으면 서버리스는 탈락이다. "간헐적/예측 불가 트래픽 + 콜드 스타트 허용"이 서버리스의 정확한 조건이다.

비동기 추론 — 크고 오래 걸리는 요청일 때

비동기 추론(Asynchronous Inference)은 요청을 내부 큐에 넣고 순차 처리한 뒤, 결과를 S3에 저장하고 SNS로 완료를 알린다.

• 페이로드 최대 1GB, 처리 최대 60분 — 실시간/서버리스가 못 받는 구간을 커버한다
• 입력을 본문에 싣지 않고 S3 위치(InputLocation)만 전달한다
• 요청이 없으면 인스턴스를 0까지 줄일 수 있다(실시간은 최소 1대 유지)
• 큐에 요청이 쌓이면 자동으로 인스턴스를 띄우고, 큐가 비면 다시 0으로 줄여 비용을 아낀다
• 적합 사례: 큰 이미지/비디오 처리, 대용량 NLP 문서 추론

# 비동기 호출: 입력을 S3에 두고 위치만 전달, 즉시 응답 대신 출력 위치를 받는다
response = runtime.invoke_endpoint_async(
    EndpointName="my-async-endpoint",
    InputLocation="s3://my-bucket/input/large-image.png",
)
output_location = response["OutputLocation"]  # 결과가 저장될 S3 경로

비동기 추론은 실시간과 배치의 중간 지대를 메운다. 실시간처럼 엔드포인트가 살아 있어 개별 요청 단위로 호출하지만, 큐를 두어 요청 폭주를 흡수하고 큰 페이로드와 긴 처리시간을 허용한다. "엔드포인트가 필요하지만(개별 호출) 페이로드가 6MB를 넘거나 처리가 60초를 넘어 실시간 제약을 못 맞춘다" → 비동기가 정답인 전형적 신호다.

배치 변환 — 전체 데이터셋을 한 번에

배치 변환(Batch Transform)은 엔드포인트를 두지 않는다. S3의 대량 입력을 읽어 일괄 추론하고 결과를 S3에 쓴 뒤, 작업이 끝나면 리소스를 모두 종료한다.

• 영구적인 엔드포인트 비용이 없다 — 작업이 도는 시간만 과금
• 데이터를 여러 인스턴스에 분할해 병렬 처리(수평 확장)
• 적합 사례: 야간 일괄 점수 계산, 전체 고객 이탈 예측, 누적 로그 분류처럼 즉시성이 필요 없고 한꺼번에 처리하면 되는 작업

from sagemaker.transformer import Transformer
 
transformer = Transformer(
    model_name="my-model",
    instance_count=4,           # 데이터를 분할해 병렬 처리
    instance_type="ml.m5.xlarge",
    output_path="s3://my-bucket/batch-output/",
)
transformer.transform(
    data="s3://my-bucket/batch-input/",
    content_type="text/csv",
    split_type="Line",          # 레코드 단위 분할
)

배치 변환은 데이터를 여러 인스턴스에 분할(split_type)하고 각 인스턴스가 미니배치(BatchStrategy, MaxPayloadInMB)로 처리해 수평 확장한다. 처리가 끝나면 클러스터가 통째로 사라지므로 always-on 비용이 0이다. "실시간성이 전혀 필요 없는 대량 일괄 처리"라는 키워드가 나오면 배치 변환이 거의 항상 가장 저렴한 정답이다.

제약 조건 비교 — 탈락 조건부터 거른다

시나리오에 숫자가 등장하면 제약으로 후보를 먼저 줄이는 편이 빠르다.

⚠️ 함정: 서버리스 추론은 GPU를 쓸 수 없다. "딥러닝 추론인데 트래픽이 간헐적이니 서버리스로 비용을 줄이자"는 선택지는 GPU가 필요한 모델이라면 애초에 성립하지 않는다. 페이로드·처리시간뿐 아니라 하드웨어 요구도 탈락 조건이라는 점을 같이 봐야 한다는 점이다.

선택 기준 결정 트리

① 즉시(동기) 응답이 필요한가?
   │
   ├─ 아니오 ─┬─ 전체 데이터셋을 한 번에?        ──▶ 배치 변환
   │          └─ 개별 요청인데 크거나 오래 걸림? ──▶ 비동기 추론
   │
   └─ 예 ─────┬─ 트래픽이 꾸준한가?              ──▶ 실시간 엔드포인트
              └─ 간헐적 + 콜드 스타트 허용?      ──▶ 서버리스 추론
 
② 제약 재확인: 페이로드 > 6MB 이거나 처리 > 60초
   → 실시간/서버리스 탈락 → 비동기(1GB·60분) 또는 배치 변환

시나리오 키워드 → 정답 매핑

증상 → 원인 → 조치

다음 글에서는 가장 핵심인 실시간 엔드포인트를 깊이 파고들어 구성, Auto Scaling, 인스턴스 선택을 본다.

📖 용어

• 추론(Inference) : 학습이 끝난 모델에 새 데이터를 넣어 예측값을 얻는 단계. 모델을 "쓰는" 쪽이다.
• 배포(Deployment) : 학습된 모델을 다른 시스템이 호출할 수 있는 형태로 올려두는 일.
• 엔드포인트(Endpoint) : 모델을 호출할 수 있게 열어 둔 HTTPS 주소. 살아 있는 동안 요청을 받는다.
• 동기 호출 : 요청을 보내면 그 자리에서 결과가 돌아오는 방식. 호출한 쪽이 기다린다.
• 비동기 호출 : 요청만 접수하고 결과는 나중에 별도 경로(S3·알림)로 받는 방식.
• 페이로드(Payload) : 한 번의 호출에 실어 보내는 데이터 본문. 크기 한도가 옵션마다 다르다.
• 콜드 스타트(Cold start) : 한동안 안 쓰던 서비스의 첫 요청에서 컨테이너·모델을 새로 올리느라 생기는 지연.
• always-on 비용 : 요청이 없어도 인스턴스가 켜져 있어 계속 나가는 고정 비용.
• 지연 시간(Latency) : 요청을 보낸 뒤 응답이 돌아올 때까지 걸리는 시간.
• 처리량(Throughput) : 단위 시간에 처리할 수 있는 요청·레코드의 개수.