[AI] 23. ADR 116‐120 ‐ SageMaker 자동화 전략 - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki
ADR 116-120: SageMaker 자동화 도구 선정 및 ML 파이프라인 고도화
작성일: 2026-02-27 상태: 승인됨 (Accepted) 배경: ADR-081~090에서 SageMaker 도입을 결정했으나 개별 도구를 수동으로 조합하는 방식이었음. 오버엔지니어링을 방지하고 자동화 플랫폼을 최대한 활용하는 방향으로 전환.
📚 목차
- ADR-116: SageMaker 자동화 도구 비교 — 도입 vs 제외 결정
- ADR-117: SageMaker Pipelines vs Airflow — ML 워크플로우 자동화 도구 선정
- ADR-118: SageMaker AMT 도입 — 하이퍼파라미터 자동화 (Pipeline TuningStep)
- ADR-119: ECR 기반 학습 컨테이너 통합 관리 — SageMaker JumpStart 미사용 결정
- ADR-120: SageMaker Experiments 도입 — Langfuse와 역할 분리
ADR-116: SageMaker 자동화 도구 비교 — 도입 vs 제외 결정
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | ✅ 승인됨 (Accepted) |
| 작성일 | 2026-02-27 |
| 결정자 | AI/인프라팀 |
| 관련 기능 | ML 파이프라인, 모델 학습·배포, 모니터링 |
| 관련 ADR | ADR-081 (SageMaker 도입), ADR-091 (Langfuse LLM-as-Judge), ADR-114 (Dev/Prod 분리 전략) |
🎯 컨텍스트 (Context)
ADR-081~090에서 SageMaker 도입을 결정했으나, 각 도구를 수동으로 개별 연결하는 방식이었다. ADR-114에서 Dev(학습) / Prod(추론) 분리 아키텍처가 확정된 시점에서, SageMaker의 다양한 도구 중 프로젝트에 실질적으로 필요한 것과 오버엔지니어링에 해당하는 것을 명확히 분류해야 한다.
특히 유사해 보이는 도구들(Autopilot vs Canvas, AMT vs Pipelines, Model Monitor vs Langfuse)에 대한 혼동을 해소하고 도입 범위를 확정한다.
🔍 선택지 분석 (Options)
Dev 서버 (학습 단계) — 도구별 결정
| 도구 | 역할 | 결정 | 근거 |
|---|---|---|---|
| SageMaker Training | GPU Training Job. EXAONE 8B / Cross-Encoder 파인튜닝 | ✅ 도입 | ADR-087 확정 |
| SageMaker Pipelines | 학습~배포 전체 워크플로우 자동화 오케스트레이터 | ✅ 핵심 채택 | 수동 조합 대체. Airflow 없이 ML 파이프라인 완결 |
| SageMaker AMT | 하이퍼파라미터 자동 탐색. Pipeline TuningStep으로 통합 | ✅ 도입 | 최적 파라미터 자동화. Pipeline과 연동 |
| SageMaker Experiments | 학습 실험 이력 추적·비교. Pipeline 자동 연동 | ✅ 도입 | 추가 코드 없이 자동 로깅 |
| SageMaker Model Registry | 학습 완료 모델 버전 관리 및 승인 프로세스 | ✅ 도입 | ADR-087 확정 |
| ECR (커스텀 이미지) | 학습 컨테이너 이미지 통합 관리 | ✅ 도입 | ADR-089 확정. JumpStart 대체 |
Prod 서버 (추론 단계) — 도구별 결정
| 도구 | 역할 | 결정 | 근거 |
|---|---|---|---|
| SageMaker Inference (Endpoint) | 파인튜닝된 모델 실시간 추론 API | ✅ 도입 | ADR-082 확정 |
제외 도구
| 도구 | 제외 이유 |
|---|---|
| SageMaker Autopilot | 전통적 테이블형 데이터 기반 자동 ML. LLM 파인튜닝 지원 불가 |
| SageMaker Canvas | Autopilot의 비즈니스 사용자용 No-Code GUI. 동일 제외 이유 |
| SageMaker JumpStart | ECR 커스텀 이미지로 대체. EXAONE 8B 공식 지원 불확실 + 추가 과금 가능 |
| SageMaker Clarify | LLM 편향 탐지는 프롬프트 설계 + LLM-as-Judge(ADR-091)로 관리 중. 현재 불필요 |
| SageMaker Feature Store | 전통 ML 피처 저장소. LLM 기반 서비스에서 피처 엔지니어링 불필요. S3 + ChromaDB 대체 |
| SageMaker Data Wrangler | GUI 데이터 전처리 도구. Pipeline ProcessingStep(코드 기반)으로 대체 가능 |
| SageMaker Model Card | 모델 메타 문서화. ADR 문서가 역할 대체. 우선순위 낮음 |
| Amazon Model Monitor | 전통 ML 모델 드리프트 탐지 특화. LLM 추론 모니터링은 Langfuse + LLM-as-Judge로 충분 |
| SageMaker Studio | ML 통합 IDE. Celery Beat + boto3 트리거로 파이프라인 완전 자동화 → 직접 코딩 환경 불필요 |
| SageMaker Notebooks | Studio 내 Jupyter 환경. Studio 미도입과 동일 이유로 제외 |
✅ 결정 (Decision)
도입 도구(6종): Training, Pipelines, AMT, Experiments, Model Registry, ECR 추론 서빙(1종): SageMaker Endpoint 제외 도구(10종): Autopilot, Canvas, JumpStart, Clarify, Feature Store, Data Wrangler, Model Card, Model Monitor, Studio, Notebooks
📊 유사 도구 차이 정리
Autopilot vs Canvas
Autopilot: 개발자용 SDK. 자동 알고리즘 선정·학습·튜닝.
Canvas : Autopilot 위에 올라간 비즈니스 사용자용 GUI.
공통 제외 : 테이블형 데이터 기반 전통 ML 전용. LLM 파인튜닝 불가.
AMT vs SageMaker Pipelines
AMT : 동일 Training Job을 수십 회 실행 → 최적 하이퍼파라미터 탐색. 학습에만 특화.
Pipelines: 데이터 수집 → 학습 → 평가 → 배포까지 전체 ML 워크플로우 오케스트레이션.
관계 : AMT를 Pipeline의 TuningStep으로 포함시킬 수 있음.
(Pipeline 없이 AMT 단독 사용 시 배포까지 자동화 안 됨)
Model Monitor vs Langfuse
Model Monitor: 전통 ML 모델의 데이터 드리프트·정확도 저하 감지 특화.
Langfuse : LLM 추론 전용 트레이싱 (토큰 비용, 레이턴시, Judge 점수).
결론 : LLM 서비스에서 Langfuse가 더 적합. Model Monitor 불필요.
ADR-117: SageMaker Pipelines vs Airflow — ML 워크플로우 자동화 도구 선정
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | ✅ 승인됨 (Accepted) |
| 작성일 | 2026-02-27 |
| 결정자 | AI/인프라팀 |
| 관련 기능 | ML 파이프라인 오케스트레이션, 학습 자동화, 배포 자동화 |
| 관련 ADR | ADR-015 (배치 처리 시스템), ADR-088 (배치 학습 파이프라인, Airflow 전환 언급), ADR-096 (Celery Beat), ADR-114 (Dev/Prod 분리) |
🎯 컨텍스트 (Context)
ADR-088에서 cron + Celery Beat → SageMaker Training Job 방식을 결정하고 "추후 Airflow 전환" 을 언급했다.
ADR-114에서 Dev(학습) / Prod(추론) 분리 아키텍처가 확정된 시점에서, 학습 파이프라인 오케스트레이션 도구를 최종 결정해야 한다.
핵심 아키텍처 — Dev/Prod 분리 + 자동 재배포 흐름
[Prod 서버 — EC2 + FastAPI]
사용자 요청 → FastAPI → SageMaker Endpoint (추론)
사용자 데이터 → ChromaDB(VectorDB) + PostgreSQL 적재 (익명화 처리)
↓ Celery Beat 주기적 동기화
Prod VectorDB(ChromaDB)에서 익명화 데이터 Pull → S3 스테이징 버킷 업로드
↓ boto3로 Pipeline 트리거
[Dev 서버 — EC2 + FastAPI (관리자 수동 테스트용)]
[SageMaker Pipelines — 일회성 GPU 인스턴스 자동 할당]
ProcessingStep ← S3에서 Prod 수집 데이터 로딩·전처리
TuningStep(AMT) ← 하이퍼파라미터 자동 탐색 (ADR-118)
TrainingStep ← Phase 1: Cross-Encoder / Phase 2: EXAONE 8B LoRA 파인튜닝
학습 완료 가중치 → S3 (model.tar.gz)
EvaluationStep ← LLM-as-Judge 품질 평가 (ADR-091 연동)
ConditionStep
├─ 통과 → RegisterModelStep → Model Registry 등록
│ → Prod SageMaker Endpoint 무중단 핫스왑 배포 (새 인스턴스 교체)
└─ 실패 → Prometheus → Discord 알림 → 기존 Prod Endpoint 유지
🔍 선택지 분석 (Options)
| 항목 | Airflow | SageMaker Pipelines |
|---|---|---|
| 인프라 | 별도 Airflow 서버 운영 필요 (EC2/EKS) | AWS 관리형, 추가 서버 불필요 |
| 비용 | 서버 상시 운영 비용 발생 | Pipeline 실행 시간 기준 과금 |
| ML 통합 | SageMaker 별도 연동 (boto3 오퍼레이터) | SageMaker 네이티브 (Training/Registry/Endpoint 내장) |
| ML 특화 기능 | 없음 (범용 DAG 오케스트레이터) | TuningStep(AMT), ConditionStep, ModelRegistry 내장 |
| 운영 복잡도 | 높음 (DAG 서버 + 별도 모니터링) | 낮음 (SDK/Console 기반 관리) |
| Celery Beat와의 관계 | 중복 오케스트레이션 | Celery Beat가 Pipeline 트리거 역할, 역할 분리 명확 |
| 적합 케이스 | 다수 팀·다중 파이프라인·비ML 작업 혼합 | 단일 ML 파이프라인, AWS 중심 스택 |
| 현재 프로젝트 규모 | 오버엔지니어링 | ✅ 적합 |
✅ 결정 (Decision)
SageMaker Pipelines 채택, Airflow 미도입 — ADR-088 "추후 Airflow 전환" 재검토하여 번복
근거:
- 현재 파이프라인은 EXAONE 8B 파인튜닝 단일 흐름 → Airflow의 복잡한 DAG 관리 불필요
- Celery Beat가 이미 스케줄러 역할 수행 중 → Airflow 추가 시 오케스트레이션 계층 중복
- SageMaker Pipelines이 TuningStep / ConditionStep / ModelRegistry를 네이티브로 지원 → 학습~배포 자체 완결
- Airflow 서버 별도 운영에 따른 인프라·비용 복잡도 추가 불필요
📊 결과 (Consequences)
Airflow 도입이 필요해지는 재검토 기준:
- 독립적인 ML 파이프라인이 다수 추가되는 경우
- dbt, Spark 등 비ML 데이터 엔지니어링 작업과 ML 학습을 하나의 DAG로 연결해야 하는 경우
- 다수의 팀이 공유 오케스트레이션 플랫폼을 함께 사용해야 하는 경우
→ 현재 해당 없음. 프로젝트 규모 확장 시 재검토 가능
ADR-118: SageMaker AMT 도입 — 하이퍼파라미터 자동화 (Pipeline TuningStep)
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | ✅ 승인됨 (Accepted) |
| 작성일 | 2026-02-27 |
| 결정자 | AI팀 |
| 관련 기능 | 모델 학습 최적화, 하이퍼파라미터 탐색, EXAONE 8B 파인튜닝 |
| 관련 ADR | ADR-117 (SageMaker Pipelines), ADR-083 (EXAONE 8B), ADR-104 (FlashRank), ADR-114 (Phase별 학습 대상) |
🎯 컨텍스트 (Context)
ADR-114에서 확정된 학습 대상(Phase 1: Cross-Encoder 파인튜닝, Phase 2: EXAONE 8B LoRA 파인튜닝)에 최적 하이퍼파라미터를 수동으로 탐색하는 것은 비효율적이다.
임베딩 모델 제외: Gemini API 임베딩을 그대로 유지. 외부 API이므로 파인튜닝 불가 → AMT 탐색 대상 아님.
AMT(Automatic Model Tuning)를 Pipeline의 TuningStep으로 통합하여 하이퍼파라미터 탐색을 자동화한다.
🔍 선택지 분석 (Options)
| 항목 | AMT 단독 사용 | Pipeline TuningStep 통합 |
|---|---|---|
| 하이퍼파라미터 자동 탐색 | ✅ | ✅ |
| 학습 후 평가·배포 자동 연결 | ❌ (별도 구현 필요) | ✅ (Pipeline ConditionStep과 자동 연결) |
| SageMaker Experiments 자동 연동 | 제한적 | ✅ (자동 로깅) |
| 결과 기반 Model Registry 등록 | ❌ | ✅ |
| 선택 | — | ✅ 채택 |
✅ 결정 (Decision)
AMT를 SageMaker Pipeline의 TuningStep으로 통합 채택
Phase별 탐색 대상 하이퍼파라미터
Phase 1 — Cross-Encoder (FlashRank 리랭커) 도메인 파인튜닝
| 항목 | 내용 |
|---|---|
| 대상 모델 | FlashRank 기반 Cross-Encoder (ADR-104) |
| 학습 데이터 | 채용 트렌드 공개 데이터 (S3) |
| 목적 | 채용 도메인 특화 문서 재순위 정확도 향상 |
| 파라미터 | 탐색 범위 |
|---|---|
| learning_rate | 1e-5 ~ 5e-4 (로그 스케일) |
| batch_size | 16, 32 |
| num_epochs | 3, 5 |
Phase 2 — EXAONE 8B LoRA 파인튜닝 (면접 질문 생성 강화)
| 항목 | 내용 |
|---|---|
| 대상 모델 | EXAONE 8B (ADR-083) |
| 학습 데이터 | Prod에서 수집된 익명화 사용자 데이터 (면접 Q&A 패턴) |
| 목적 | 면접 도메인 생성 품질 향상 |
| 파라미터 | 탐색 범위 |
|---|---|
| learning_rate | 1e-5 ~ 1e-3 (로그 스케일) |
| per_device_train_batch_size | 4, 8, 16 |
| lora_r (LoRA rank) | 8, 16, 32 |
| lora_alpha | 16, 32, 64 |
| num_train_epochs | 1, 2, 3 |
📊 결과 (Consequences)
| 항목 | 내용 |
|---|---|
| 탐색 전략 | Bayesian Optimization (Random/Grid 대비 적은 시도로 최적값 수렴) |
| 최대 병렬 잡 | 2~3개 (GPU 할당량 및 비용 제어) |
| 평가 지표 | LLM-as-Judge 점수 (ADR-091 체계 연동) |
| 임베딩 모델 | Gemini API 유지. AMT 탐색 대상 제외 |
ADR-119: ECR 기반 학습 컨테이너 통합 관리 — SageMaker JumpStart 미사용 결정
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | ✅ 승인됨 (Accepted) |
| 작성일 | 2026-02-27 |
| 결정자 | AI/인프라팀 |
| 관련 기능 | 학습 컨테이너 관리, 베이스 모델 로딩, 이미지 버전 관리 |
| 관련 ADR | ADR-083 (EXAONE 8B), ADR-089 (ECR 이미지 관리), ADR-118 (Phase별 학습 대상) |
🎯 컨텍스트 (Context)
SageMaker Training Job 실행 시 베이스 모델 컨테이너 이미지를 어떻게 관리할지 결정해야 한다. 초기 계획에서 JumpStart 활용을 검토했으나, 기존 인프라(ECR)와의 일관성 및 비용·커스터마이징 측면을 재검토한다.
🔍 선택지 분석 (Options)
| 항목 | SageMaker JumpStart | ECR 커스텀 이미지 (ADR-089 확정) |
|---|---|---|
| 초기 설정 공수 | 낮음 (SDK 몇 줄) | 중간 (Dockerfile 작성) |
| 비용 | JumpStart 사용 시 추가 과금 가능 | ECR 저장 비용만 발생 (저렴) |
| 커스터마이징 | 제한적 (제공 컨테이너 기반) | 완전 자유 (PyTorch 버전, CUDA, 의존성 직접 관리) |
| EXAONE 8B 공식 지원 | 불확실 (HF 연동 여부 미확인) | ✅ HF Hub model_id로 직접 다운로드 |
| 기존 인프라 재사용 | ❌ (신규 도구) | ✅ (ADR-089 확정 인프라 동일 활용) |
| 버전 관리 | JumpStart 버전에 종속 | ECR 이미지 태그로 자유 관리 |
| 일관성 | 낮음 (ECR + JumpStart 혼용) | 높음 (ECR 단일화) |
✅ 결정 (Decision)
ECR 커스텀 이미지 확정, JumpStart 미사용
근거:
- JumpStart 사용 시 추가 과금 발생 가능 + EXAONE 8B 공식 지원 불확실
- ADR-089에서 이미 ECR 기반 이미지 관리 확정 → 동일 인프라 재사용으로 일관성 유지
- PyTorch 버전, CUDA, PEFT 등 학습 환경 커스텀 컨트롤 필요
- HF Hub
model_id방식으로 EXAONE 8B 직접 다운로드 가능 → JumpStart 없이도 동일 효과
📊 결과 (Consequences)
ECR 이미지 구성
| 이미지 태그 | 용도 | 포함 패키지 | 이미지 크기 |
|---|---|---|---|
training-exaone8b-lora:latest |
Phase 1 Cross-Encoder + Phase 2 EXAONE 8B LoRA 파인튜닝 통합 환경 | PyTorch, Transformers, PEFT, bitsandbytes, datasets, accelerate, sentence-transformers, flashrank | ~16GB |
inference-exaone8b:latest |
추론 전용 이미지 (양자화 적용) | vLLM, AWQ/GPTQ | ~8GB |
이미지 통합 결정: Cross-Encoder(Phase 1)와 EXAONE 8B(Phase 2) 학습을 단일 이미지에서 처리. 이미지 관리 단순화 및 ECR 저장 비용 절감.
모델 아티팩트 흐름:
TrainingStep 완료
→ 학습 가중치 → model.tar.gz 압축
→ S3 버킷 업로드
→ SageMaker Endpoint 배포 시 /opt/ml/model/ 자동 마운트
Prod Endpoint 인스턴스: ml.g6.xlarge, 24시간 상시 가동 (추론 전용)
모델 로딩 방식: SageMaker Training Job 실행 시 HF Hub model_id → 컨테이너 내 자동 다운로드
ADR-120: SageMaker Experiments 도입 — Langfuse와 역할 분리
📋 메타데이터
| 항목 | 내용 |
|---|---|
| 상태 | ✅ 승인됨 (Accepted) |
| 작성일 | 2026-02-27 |
| 결정자 | AI팀 |
| 관련 기능 | 학습 실험 추적, 모델 비교, Dev/Prod 모니터링 역할 분리 |
| 관련 ADR | ADR-091 (Langfuse LLM-as-Judge), ADR-112 (AI 평가 고도화), ADR-113 (Langfuse RAG 평가), ADR-117 (SageMaker Pipelines) |
🎯 컨텍스트 (Context)
ADR-112~113에서 Langfuse 기반 RAG 평가 고도화를 확정했으나, 이는 Prod 추론 단계 모니터링에 특화된 도구다.
Dev 학습 단계에서는 여러 실험(AMT 하이퍼파라미터 조합, Phase별 데이터셋 버전 비교)을 추적·비교할 전용 도구가 필요하다. SageMaker Experiments는 Pipeline과 자동 연동되어 추가 코드 없이 학습 실험을 기록하고 비교할 수 있다.
🔍 선택지 분석 (Options)
| 구분 | SageMaker Experiments | Langfuse |
|---|---|---|
| 적용 환경 | Dev 서버 (학습 단계) | Prod 서버 (추론 단계) |
| 추적 대상 | Training Loss, 검증 지표, 학습 시간, GPU 사용률 | 토큰 비용, 응답 레이턴시, LLM-as-Judge 점수 |
| 연동 | SageMaker Training/Pipelines 자동 연동 | LangChain Callbacks (ADR-068) |
| 시각화 | SageMaker SDK/Console 실험 비교 (Studio 미사용) | Langfuse 대시보드 |
| A/B 비교 | 하이퍼파라미터·데이터셋 버전 비교 | 프롬프트 v1 vs v2 비교 (ADR-113) |
| 추가 코드 | Pipeline 실행 시 자동 로깅 (불필요) | SDK 직접 연동 필요 |
| 역할 | 학습 단계 실험 관리 | 추론 단계 품질·비용 관리 |
✅ 결정 (Decision)
Dev/Prod 단계별 모니터링 역할 분리
- Dev (학습 단계) → SageMaker Experiments
- Prod (추론 단계) → Langfuse (ADR-091~113 체계 유지)
📊 결과 (Consequences)
전체 모니터링 흐름 — Dev/Prod 완전 분리
[Dev 서버 — 학습 단계]
SageMaker Experiments (Pipeline 자동 로깅)
├─ Phase 1: Cross-Encoder AMT 파라미터 조합별 검증 점수
├─ Phase 2: EXAONE 8B LoRA AMT 조합별 LLM-as-Judge 점수
├─ 최적 모델 → Model Registry 등록
└─ ConditionStep 결과
├─ 통과 → Prod Endpoint 무중단 핫스왑 배포
└─ 실패 → Prometheus → Discord 인프라 알림 → 기존 Endpoint 유지
↓ 자동 배포 (ConditionStep 통과)
[Prod 서버 — 추론 단계]
Langfuse
├─ RAG 파이프라인 트레이싱 (ADR-091)
├─ LLM-as-Judge 품질 점수
├─ 토큰 비용 추적 (ADR-112)
└─ 온라인 샘플링 평가 (ADR-113 Phase 2)
↓ 사용자 데이터 수집
[Celery Beat (Prod)]
└─ Prod VectorDB(ChromaDB) 익명화 데이터 Pull → S3 스테이징 → Dev Pipeline 재트리거
모니터링 계층 요약:
| 계층 | 도구 | 역할 |
|---|---|---|
| 인프라 알림 | Prometheus → Discord | ConditionStep 실패 시 즉시 알림 |
| 학습 실험 추적 | SageMaker Experiments | AMT 파라미터 조합별 학습 결과 비교 |
| 추론 품질 추적 | Langfuse | 토큰 비용, 레이턴시, LLM-as-Judge 점수 |
핵심 피드백 루프:
Prod 사용자 데이터 수집 → Dev 학습 → Prod 자동 배포 → 다시 Prod 데이터 수집
이 사이클을 통해 서비스가 운영되면서 지속적으로 모델 품질이 향상되는 구조를 갖춘다.