SageMaker 기본 패턴으로 보는 선형 회귀 프로젝트

이번 글은 Udemy 강의의 프로젝트 #1(급여 예측), 프로젝트 #2(의료 보험료 예측)을 SageMaker 기본 워크플로우 중심으로 재구성한 요약이다. 새로운 회귀 문제를 SageMaker로 해결해야 할 때, 여기 정리한 코드 패턴만 기억해도 거의 그대로 재사용할 수 있다.

이 글 핵심 요약 3~5줄

• SageMaker 회귀 프로젝트는 결국 Estimator 정의 → Training Job 실행 → Endpoint 배포 → 예측 호출 패턴으로 귀결된다.
• 프로젝트 #1과 #2의 차이는 단일 피처 회귀 vs 다중 피처 회귀(카테고리 포함) 정도이며, SageMaker 관점에서는 흐름이 동일하다.
• 데이터 전처리와 피처 처리만 잘 준비되면 SageMaker 내부 로직은 대부분 자동화된다.
• 실무 확장 시 ANN·XGBoost 등으로 모델만 바꾸면 같은 코드 패턴을 그대로 활용할 수 있다.

---

SageMaker 공통 워크플로우 한 장 요약

아래는 SageMaker Notebook/Studio에서 회귀 모델을 만들 때 거의 항상 반복되는 순서다.

[1] 데이터 로드 & 간단 EDA
      - 결측치, 기초 통계, 스케일 확인
[2] 데이터 전처리 & Train/Test Split
[3] (선택) 로컬에서 간단한 baseline 모델 학습
[4] SageMaker Estimator 정의
[5] estimator.fit() → Training Job 실행
[6] estimator.deploy() → Endpoint 생성
[7] Predictor.invoke() → 예측 호출
[8] 배포 비용 절감을 위해 Endpoint 삭제

핵심은 4~7번이며, 이 부분은 프로젝트가 바뀌어도 형태가 거의 같아 재사용성이 매우 높다.

---

공통 코드 패턴: Estimator, Training, Endpoint

아래는 SageMaker 선형 학습기(Linear Learner) 기반 예시 코드다. 프로젝트 전체 코드 중 진짜 재사용해야 하는 부분만 추렸다.

1) Estimator 정의 패턴

from sagemaker import LinearLearner

linear_estimator = LinearLearner(
    role=role,
    instance_type="ml.m5.large",
    instance_count=1,
    predictor_type="regressor",   # 회귀 문제 선언
    objective="MSE",              # 손실 함수
    output_path=s3_output_path,
)

핵심 파라미터 설명

• role: S3 접근 권한이 포함된 IAM Role
• instance_type: 학습 인스턴스 타입
• predictor_type: 회귀(regressor) 또는 분류(binary_classifier/multiclass)
• objective: 선형 알고리즘이 최소화해야 하는 손실(MSE 등)
• output_path: 모델 아티팩트를 저장할 S3 경로

포인트: 알고리즘이 무엇이든 Estimator의 구조는 거의 동일하다. 즉, 모델을 바꿔도 코드 패턴은 변하지 않는다.

---

2) Training Job 실행 패턴

linear_estimator.fit({"train": train_s3_uri, "validation": val_s3_uri})

• 입력 형식은 보통 recordio_protobuf 또는 csv
• “train”, “validation” 키 이름은 알고리즘마다 다를 수 있으나 선형 학습기는 위와 같이 사용 가능

포인트: .fit() 호출 순간 AWS 내부에서 자동으로 컨테이너 → 학습 스케줄링 → S3에서 데이터 로드 → 모델 아티팩트 저장이 일어난다.

---

3) Endpoint 배포 패턴

predictor = linear_estimator.deploy(
    initial_instance_count=1,
    instance_type="ml.m5.large"
)

• .deploy()가 끝나면 HTTPS 엔드포인트가 생성됨
• 배포 비용은 학습보다 오래 유지될수록 더 커지므로 실무에서는 사용 후 즉시 삭제 필요

---

4) Endpoint 호출 패턴

result = predictor.predict(test_array)
print(result)

• test_array는 일반적으로 numpy array 또는 list 형태
• 반환값은 모델에 따라 score, predicted_label 등의 필드 포함

---

이 섹션에서 기억해야 할 코드 패턴

• estimator = LinearLearner(...)
• estimator.fit({"train": ..., "validation": ...})
• predictor = estimator.deploy(...)
• predictor.predict(data)

---

프로젝트 #1: 급여 예측 – 단순 선형 회귀

데이터 구조

• feature: 경력(Experience 또는 Years)
• target: Salary
• 단일 피처 기반의 매우 단순한 회귀 문제

로컬 모델 vs SageMaker 모델

• 로컬에서는 sklearn.LinearRegression으로 쉽게 baseline 생성
• SageMaker에서는 동일한 개념이지만 대규모 데이터·배포 자동화·확장성을 제공하는 차이

최소 EDA 체크리스트

• 스케일 확인(연봉 단위)
• 결측치 여부
• 이상치(outlier) 존재 여부
• 단일 피처라 시각화(E→Salary)로 충분히 구조 파악 가능

Train/Test Split 패턴

from sklearn.model_selection import train_test_split
train, test = train_test_split(df, test_size=0.2, random_state=42)

평가 지표

• RMSE 또는 MAE 정도면 충분
• 목적: baseline 품질 확인

---

이 섹션에서 기억해야 할 코드 패턴

• 단일 피처라도 SageMaker에서는 데이터 구조를 CSV + S3 Upload → fit() 호출하면 끝
• 모델 복잡성과 관계없이 SageMaker 호출 패턴은 동일

---

프로젝트 #2: 의료 보험료 예측 – 다중 선형 회귀 + ANN 맛보기

데이터 특징

• feature: 나이, BMI, 자녀 수, 흡연 여부, 지역 등
• 범주형 feature 존재 → 인코딩 필요
• 다중 피처이므로 feature interaction → 성능 영향 가능

달라지는 점

• 카테고리 변수를 원핫 인코딩하거나 임베딩 필요
• 피처 수가 증가하므로 모델 해석이 어려워지고 규제(L1/L2) 중요
• 선형 회귀의 한계가 명확해지면서 ANN으로 확장할 이유가 생김

ANN을 고려하는 상황

• 피처가 많고 비선형 관계가 강할 때
• 충분한 데이터가 있을 때
• 모델 해석보다 예측 성능이 중요할 때

그러나 실무에서는 선형 모델이 여전히 좋은 이유

• 해석 가능성(보험료 산정에 필요)
• 빠른 학습·낮은 비용
• 적은 피처에서도 안정적 성능
• 규제(L1/L2)를 통한 피처 중요도 관리 용이

---

이 섹션에서 기억해야 할 코드 패턴

• 다중 피처 회귀라도 SageMaker 호출은 변하지 않는다.
• 변하는 것은 전처리(범주형 처리) 와 피처 수 증가에 따른 튜닝 포인트뿐.

---

실무에서 회귀 문제 설계 시 체크리스트

• 데이터 크기: 선형 모델은 적은 데이터에서도 우수. ANN은 데이터가 많을수록 강함.
• 피처 수 / 구조: 범주형이 많으면 인코딩 비용 증가. 비선형성이 강하면 ANN 고려.
• 평가 지표 선택: RMSE vs MAE vs MAPE 중 문제 특성에 맞게 선택
• 해석 가능성: 금융·의료 도메인은 선형 모델 선호
• 배포 고려: Endpoint 비용, 예측 속도, 모니터링 필요
• 모델 갱신 전략: 데이터 드리프트 감시, 주기적인 재학습

---

• 참고: 초보자를 위한 AWS SageMaker 실습 | 6개 프로젝트 구축하기