[AI] 16. ADR 081‐085 ‐ SageMaker 도입 - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki

ADR 081-085: Amazon SageMaker 도입 및 ML 운영 전략

작성일: 2026-02-23
상태: 제안됨 (Proposed)

📚 목차

ADR-081: Amazon SageMaker 도입 결정 — 관리형 ML 서빙 플랫폼 선정
ADR-082: SageMaker 호스팅 방식 — 실시간 vs 서버리스 vs 비동기
ADR-083: SageMaker와 기존 vLLM·RunPod 통합 전략 — 8B 파인튜닝·서빙, 32B 당분간 미사용(비용·할당량 제약)
ADR-084: SageMaker 모델 패키징 및 배포 파이프라인
ADR-085: SageMaker 모니터링 및 비용 관리

ADR-081: Amazon SageMaker 도입 결정 — 관리형 ML 서빙 플랫폼 선정

📋 메타데이터

항목	내용
상태	제안됨 (Proposed)
작성일	2026-02-23
결정자	AI/인프라팀
관련 기능	LLM 서빙(Exaone 8B/32B), GPU 인프라, 모델 배포
관련 ADR	ADR-047 (EXAONE 32B GPU 인프라), ADR-041 (RunPod + Lambda)

🎯 컨텍스트 (Context)

현재 LLM·OCR 서빙은 vLLM Docker + RunPod(32B) 및 EasyOCR 서버리스로 구성되어 있다. AWS 기반 CI/CD·Parameter Store 등은 이미 사용 중이나, GPU 모델 서빙은 RunPod 등 외부에 분리되어 있어 운영·보안·비용 관리를 일원화할 필요가 있다.

현재 상태:

Exaone 8B: vLLM Docker (AWS/GCP 서버리스 GPU 또는 로컬)
Exaone 32B: RunPod 서버리스 (확정) — v2 인프라 설계 반영
EasyOCR: FastAPI 서버리스 GPU
VectorDB: ChromaDB Server (Docker)
배포: v2 Docker / v3 K8s 전환 예정

문제점:

RunPod·vLLM·EasyOCR이 서로 다른 플랫폼에 분산 → 모니터링·비용·보안 정책 통합 어려움
모델 버전·롤백·A/B 테스트를 위한 공통 플랫폼 부재
AWS 계정 내 GPU 리소스 활용 시 관리형 옵션(SageMaker) 검토 필요

요구사항:

AWS 생태계와 통합된 관리형 ML 서빙 옵션 검토
기존 RunPod·vLLM 전략과 충돌하지 않는 단계적 도입 경로
실시간 추론·비용·확장성·보안 요구 충족

🔍 선택지 분석 (Options)

Option 1: Amazon SageMaker 도입 (권장) ⭐

SageMaker를 사용해 일부 모델(예: Exaone 8B, EasyOCR) 또는 신규 모델을 AWS 내 관리형 엔드포인트로 서빙한다. RunPod 32B는 단기 유지, 중장기 이전 검토.

장점	단점
✅ AWS IAM·VPC·CloudWatch와 자연스러운 통합	⚠️ RunPod 대비 단위 비용이 높을 수 있음
✅ 모델 레지스트리·버전 관리·롤백 표준화	⚠️ vLLM 커스텀 이미지/옵션 제약 가능
✅ 실시간·서버리스·비동기 추론 옵션 제공	⚠️ 학습·도입 리소스 필요
✅ MLOps(파이프라인, 모니터링) 내장	-

Option 2: 기존 구성 유지 (RunPod + vLLM + EasyOCR)

현재처럼 RunPod(32B), vLLM Docker(8B), EasyOCR 서버리스 유지. SageMaker 미도입.

장점	단점
✅ 추가 도입 비용·학습 없음	❌ 플랫폼 분산으로 운영 부담 증가
✅ 이미 검증된 구성	❌ AWS 일원화 불가
-	❌ 모델 버전·롤백 체계화 어려움

Option 3: 타 관리형 서비스 (Vertex AI, Azure ML)

GCP Vertex AI 또는 Azure ML로 이전. AWS 외 클라우드로 통합.

장점	단점
✅ 관리형 MLOps 기능	❌ 현재 인프라가 AWS 중심 → 이중화·복잡도 증가
✅ 각 클라우드 네이티브 기능	❌ RunPod·기존 AWS 자산과 통합 비용 큼

결정 (Decision)

Option 1: Amazon SageMaker 도입을 선택합니다.

근거:

인프라 일원화: 이미 AWS(CodeDeploy, Parameter Store, VPC 등)를 사용 중이므로, GPU 모델 서빙을 SageMaker로 단계적 이전 시 보안·네트워크·비용 가시성 확보에 유리하다.
ADR-047과의 정합성: 32B는 당분간 RunPod 유지 가능하며, SageMaker는 먼저 Exaone 8B 또는 EasyOCR·신규 모델 대상으로 도입해 리스크를 나눌 수 있다.
MLOps 표준화: 모델 레지스트리, 파이프라인, 엔드포인트 모니터링을 한 플랫폼에서 수행할 수 있어 장기 유지보수에 유리하다.

Consequences (결과)

긍정적 영향:

AWS 계정 내에서 모델 배포·모니터링·비용 통합
IAM·VPC 기반 보안 정책 일관 적용
실시간/서버리스/비동기 추론 중 요구에 맞는 호스팅 선택 가능

부정적 영향 / 트레이드오프:

SageMaker 학습 및 초기 구축 비용 발생
RunPod 대비 인스턴스 단가가 높을 수 있음 → 서버리스·스케일 투 제로로 완화

후속 작업:

ADR-082: 호스팅 방식(실시간/서버리스/비동기) 결정
ADR-083: vLLM·RunPod와의 단계적 통합 계획 수립
ADR-084·085: 패키징·배포·모니터링 설계

이력

날짜	변경 내용
2026-02-23	초기 작성

ADR-082: SageMaker 호스팅 방식 — 실시간 vs 서버리스 vs 비동기

📋 메타데이터

항목	내용
상태	제안됨 (Proposed)
작성일	2026-02-23
결정자	AI/인프라팀
관련 기능	SageMaker 추론, Exaone 8B, 채팅/면접 실시간 응답

🎯 컨텍스트 (Context)

SageMaker에서 모델을 서빙하는 방식은 실시간 엔드포인트, 서버리스 추론, 비동기 추론 등이 있다. 채팅·면접은 낮은 지연시간이 필요하고, 배치 분석·리포트 생성은 비동기로 처리 가능하다.

요구사항:

채팅/면접: 실시간 스트리밍·저지연 (< 수 초)
배치 작업(예: 대량 이력서 분석): 비동기 허용, 비용 최소화

🔍 선택지 분석 (Options)

Option 1: 실시간 엔드포인트 (Real-time Endpoint) ⭐ — 채팅/면접

전용 인스턴스에 모델을 상주 배치해 항상 요청을 즉시 처리한다.

[Client] ---> [SageMaker Real-time Endpoint] ---> [Exaone 8B / vLLM 컨테이너]

장점	단점
✅ 낮은 지연시간, 예측 가능한 성능	❌ 인스턴스 상시 가동 비용
✅ vLLM·커스텀 서빙 코드 배포 가능	❌ 스케일 제로 불가 (콜드스타트 있음)

Option 2: 서버리스 추론 (Serverless Inference)

트래홵에 따라 자동 스케일, 유휴 시 0으로 스케일 다운. 콜드스타트 존재.

장점	단점
✅ 유휴 시 비용 없음	❌ 콜드스타트로 첫 요청 지연
✅ 운영 부담 적음	⚠️ 모델 크기·메모리 제약 있음

Option 3: 비동기 추론 (Asynchronous Inference)

S3 입력/출력 기반으로 대량 요청을 큐에 넣고 비동기 처리. 실시간 부적합.

장점	단점
✅ 대량 배치 비용 효율적	❌ 실시간 채팅/면접에는 부적합
✅ 스케일 투 제로 가능	-

결정 (Decision)

모델·사용처별 호스팅 전략:

사용처	호스팅 방식	근거
채팅·면접 (Exaone 8B/32B)	실시간 엔드포인트 (Option 1)	저지연·스트리밍 요구, vLLM 호환
배치 분석·리포트	비동기 추론 (Option 3)	비용·처리량 우선
트래홵 매우 적은 실험용	서버리스 추론 (Option 2) 검토	유휴 비용 제로 필요 시

근거: 실시간 응답이 핵심인 채팅/면접은 실시간 엔드포인트로 안정적 지연을 보장하고, 배치성 작업은 비동기로 비용을 절감한다.

Consequences (결과)

긍정적 영향: 사용처별로 적절한 비용/성능 트레이드오프 선택 가능.

부정적 영향: 실시간 엔드포인트는 최소 1인스턴스 유지 비용 발생 → 인스턴스 타입·스케일 설정으로 조절.

후속 작업:

실시간 엔드포인트 인스턴스 타입(G6e 등) 및 인스턴스 수 결정
비동기 추론 S3 입출력 포맷 및 타임아웃 정책 정의

이력

날짜	변경 내용
2026-02-23	초기 작성

ADR-083: SageMaker와 기존 vLLM·RunPod 통합 전략 — 8B 파인튜닝·서빙, 32B 당분간 미사용(비용·할당량 제약)

📋 메타데이터

항목	내용
상태	제안됨 (Proposed)
작성일	2026-02-23
결정자	AI/인프라팀
관련 기능	LLM 역할 분리, 채용 트렌드 배치 학습, SageMaker 파인튜닝·서빙
관련 ADR	ADR-081 (SageMaker 도입), ADR-047 (32B GPU 인프라), ADR-082 (호스팅 방식)

🎯 컨텍스트 (Context)

SageMaker 도입 시 모델별 역할을 비용·할당량 제약에 맞게 조정한다. AWS 32B 비용 부담 및 RunPod 32B GPU 할당량 신청 기각 등으로 32B를 당분간 사용하기 어려우므로, SageMaker 파인튜닝·서빙은 8B로 수행하고, 32B는 할당량·비용 확보 시까지 미사용한다.

제약 반영:

Exaone 8B: SageMaker에서 파인튜닝(채용 트렌드 등 배치 데이터) 후 SageMaker Endpoint로 서빙. 요약·경량 QA는 ADR-086에 따라 Gemini 유지하거나, 파인튜닝된 8B 엔드포인트를 보조로 활용 가능.
Exaone 32B: 원래 일반 QA·배치 학습 대상이었으나, AWS 비용·RunPod 32B GPU 할당량 제약으로 당분간 미사용. 추후 할당량·비용 확보 시 재검토.

현재 코드 참조:

3.model/docker-compose.yml: exaone-8b(vLLM), exaone-32b(vLLM, 프로덕션은 RunPod)
환경 변수: VLLM_8B_BASE_URL, VLLM_32B_BASE_URL 등으로 엔드포인트 분리

🔍 선택지 분석 (Options)

Option 1: 8B SageMaker 파인튜닝·서빙, 32B 당분간 미사용 (권장) ⭐

8B: SageMaker Training Job으로 채용 트렌드 등 배치 데이터 파인튜닝 → Model Registry·Endpoint로 서빙. 요약·경량 QA는 ADR-086에 따라 Gemini 주력, 필요 시 파인튜닝 8B 보조.
32B: AWS 비용·RunPod 32B GPU 할당량 제약으로 당분간 미사용. 일반 QA·면접은 Gemini·8B(파인튜닝) 조합으로 대체. 할당량·비용 확보 시 재검토.

장점	단점
✅ 8B 파인튜닝은 GPU·비용 부담이 32B보다 적어 AWS에서 수용 가능	⚠️ 32B 대비 품질·역할 제한 가능성, 모니터링 필요
✅ 배치 학습·서빙을 SageMaker 한 플랫폼에서 처리	⚠️ 배치 학습 파이프라인(SageMaker Training 등) 설계 필요
✅ 32B 할당량 없이도 채용 트렌드 반영 파이프라인 구축 가능	-

Option 2: 8B·32B 역할 유지(기존과 동일), SageMaker만 인프라 추가

8B는 기존처럼 다양한 용도, 32B는 면접·일부 QA. “요약 전용 8B + 32B 일반 QA·배치 학습” 시나리오는 도입하지 않음.

장점	단점
✅ 기존 라우팅·코드 변경 최소	❌ 사용자 시나리오(트렌드 데이터 배치 학습) 미반영
-	❌ 8B 과다 사용·32B 미활용 구조 유지 가능

Option 3: 32B만 일반 QA·배치 학습, 8B는 단계적 폐지

요약도 32B로 통합하고 8B 호스팅을 줄이거나 제거.

장점	단점
✅ 모델 단일화로 운영 단순	❌ 요약은 8B로 충분한 경우 32B 비용·지연 증가
-	❌ 8B 제거 시 기존 요약 API 마이그레이션 부담

결정 (Decision)

Option 1: 8B SageMaker 파인튜닝·서빙, 32B 당분간 미사용을 선택합니다.

근거:

비용·할당량 제약: AWS에서 32B 파인튜닝·서빙 비용이 부담되고, RunPod 32B GPU 할당량 신청이 기각되는 등 32B 사용이 어려우므로, SageMaker 파인튜닝·서빙은 8B로 수행한다.
8B 파인튜닝: 채용 트렌드 등 데이터를 실시간/주기 수집 → 배치 처리로 정제·학습(SageMaker Training Job) → 8B 모델 갱신 → SageMaker Endpoint로 서빙. 요약·경량 QA는 ADR-086에 따라 Gemini 주력, 필요 시 파인튜닝 8B 보조.
32B: 할당량·비용 확보 시 일반 QA·배치 학습 재검토. 당분간 일반 QA·면접은 Gemini 및 파인튜닝 8B로 대체.

구현 방향:

[요약·경량 QA]  →  Gemini API (ADR-086) 또는 (선택) SageMaker 8B Endpoint
[채용 트렌드 등] → 실시간/주기 수집 → S3 배치 데이터 → SageMaker Training Job (8B 파인튜닝)
                       → Model Registry → SageMaker Endpoint (8B)
[32B]           →  당분간 미사용 (RunPod 할당량·AWS 비용 제약). 확보 시 재검토.

8B: SageMaker Training으로 파인튜닝 → Model Registry·Endpoint. VLLM_8B_BASE_URL 또는 SageMaker 8B 엔드포인트로 라우팅 가능.
32B: VLLM_32B_BASE_URL은 당분간 미사용. 배치 학습은 SageMaker Training Job(8B) 으로 설계.

Consequences (결과)

긍정적 영향:

8B 파인튜닝·서빙으로 AWS 비용·GPU 할당량 제약 내에서 채용 트렌드 반영 파이프라인 구축 가능.
32B 미사용으로 당분간 RunPod·AWS 32B 비용 부담 없음.

부정적 영향 / 트레이드오프:

32B 대비 8B 품질·역할 제한 가능성; 모니터링·품질 검증 필요.
채용 트렌드 수집·배치 학습 파이프라인(스케줄, 데이터 포맷, 8B 학습) 설계·운영 부담.

후속 작업:

라우팅 규칙: 요약·경량 QA는 Gemini(ADR-086), 필요 시 SageMaker 8B 엔드포인트 보조
채용 트렌드 등 실시간/주기 수집 소스 및 S3 저장소 정의
배치 학습 파이프라인(SageMaker Training Job, 8B 파인튜닝) 및 반영 주기 정리
SageMaker 8B Endpoint URL 및 IAM 역할 정의

이력

날짜	변경 내용
2026-02-23	초기 작성
2026-02-23	8B 요약 전용·32B 일반 QA·채용 트렌드 배치 학습 시나리오로 결정 반영
2026-02-23	32B 비용·할당량 제약 반영 — 8B SageMaker 파인튜닝·서빙, 32B 당분간 미사용으로 수정

ADR-084: SageMaker 모델 패키징 및 배포 파이프라인

📋 메타데이터

항목	내용
상태	제안됨 (Proposed)
작성일	2026-02-23
결정자	AI/인프라팀
관련 기능	CI/CD, 모델 배포, SageMaker Pipelines·레지스트리

🎯 컨텍스트 (Context)

SageMaker에 모델을 배포하려면 모델 아티팩트(이미지·모델 데이터) 를 S3에 두고, SageMaker 모델·엔드포인트 설정을 해야 한다. 재현 가능한 배포와 롤백을 위해 패키징·배포 파이프라인을 정립할 필요가 있다.

요구사항:

모델 버전별 추적 및 롤백
기존 Docker/vLLM 워크플로와 가능한 통합 (예: 빌드 산출물 재사용)

🔍 선택지 분석 (Options)

Option 1: SageMaker Pipelines + 모델 레지스트리 ⭐

SageMaker Pipelines로 빌드·등록·엔드포인트 배포 단계를 자동화하고, SageMaker Model Registry로 버전 관리.

[소스 코드] --> [빌드 이미지] --> [S3 아티팩트] --> [모델 등록] --> [엔드포인트 배포]
                     ↑                                    ↑
                ECR 이미지                    SageMaker Model Registry

장점	단점
✅ 버전·승인·롤백을 레지스트리에서 관리	⚠️ 파이프라인 정의·유지보수 필요
✅ CI/CD(CodePipeline, GitHub Actions)와 연동 가능	-

Option 2: 수동 배포 + 스크립트

CLI/콘솔로 모델 업로드·엔드포인트 생성. 스크립트로 반복 작업만 자동화.

장점	단점
✅ 구현 단순	❌ 버전 추적·롤백이 수동에 의존
-	❌ 휴먼 에러 가능성

Option 3: 기존 Docker 빌드 + SageMaker 호환

이미지만 ECR에 푸시하고, SageMaker는 해당 이미지를 사용하는 모델/엔드포인트만 생성. 파이프라인은 최소화.

장점	단점
✅ 기존 `docker-compose`·Dockerfile 재사용	⚠️ 레지스트리·자동 롤백은 별도 설계 필요
✅ vLLM 이미지 그대로 활용 가능	-

결정 (Decision)

Option 1(SageMaker Pipelines + 모델 레지스트리)을 목표로, 단계적으로 Option 3로 시작합니다.

근거:

단기: 현재 vLLM Docker 이미지를 ECR에 올리고, SageMaker 모델은 해당 이미지 + S3(필요 시)로 등록해 엔드포인트만 배포(Option 3). 빠른 도입이 목표.
중기: 배포 단계를 SageMaker Pipelines로 옮겨 빌드 → S3/ECR → 모델 등록 → 엔드포인트 배포를 자동화(Option 1).
모델 레지스트리: 버전·스테이징(Staging/Production)·승인 플로우를 도입해 롤백·감사에 대비한다.

후속 작업:

vLLM용 SageMaker 호환 Docker 이미지 스펙 및 ECR 푸시 절차
SageMaker Model Registry 그룹명·승인 규칙 정의
Pipeline 정의(YAML 또는 코드) 및 CI 연동

Consequences (결과)

긍정적 영향: 재현 가능한 배포, 버전 추적, 롤백 용이.

부정적 영향: 파이프라인 구축 초기 비용·학습 필요.

이력

날짜	변경 내용
2026-02-23	초기 작성

ADR-085: SageMaker 모니터링 및 비용 관리

📋 메타데이터

항목	내용
상태	제안됨 (Proposed)
작성일	2026-02-23
결정자	AI/인프라팀
관련 기능	CloudWatch, 비용 할당, 모델 성능·가용성 모니터링

🎯 컨텍스트 (Context)

SageMaker 엔드포인트의 가용성·지연·에러율·비용을 가시화하고, RunPod·기타 서비스와 비교해 비용을 관리할 수 있어야 한다.

요구사항:

엔드포인트 상태·지연시간·4xx/5xx 모니터링
SageMaker 비용을 태그/비용 할당으로 추적
(선택) 모델 품질 지표(예: 토큰 수, 실패율) 수집

🔍 선택지 분석 (Options)

Option 1: CloudWatch 기본 지표 + 비용 탐색기 ⭐

SageMaker가 제공하는 CloudWatch 지표(ModelLatency, Invocations, ModelErrors 등)와 비용 탐색기(Cost Explorer)로 모니터링·비용 추적.

장점	단점
✅ 별도 에이전트 없이 사용 가능	⚠️ 커스텀 비즈니스 지표는 추가 구현 필요
✅ AWS 비용 태그와 연동 용이	-

Option 2: SageMaker Model Monitor + 커스텀 지표

Model Monitor로 드리프트·데이터 품질을 보고, 애플리케이션에서 커스텀 지표(토큰/요청당 비용 등)를 CloudWatch에 전송.

장점	단점
✅ 드리프트·품질 모니터링	❌ 설정·유지보수 부담 큼
✅ 세밀한 비즈니스 지표	-

Option 3: 기존 Langfuse·Prometheus와 연동

Langfuse(Prompt/LLM 관찰성) 및 Prometheus/Grafana는 유지하고, SageMaker 지표만 CloudWatch에서 가져와 통합 대시보드 구성.

장점	단점
✅ 팀이 이미 사용 중인 도구와 통합	⚠️ CloudWatch ↔ Prometheus 연동 설정 필요
-	-

결정 (Decision)

Option 1(CloudWatch 기본 지표 + 비용 탐색기)을 기본으로 하고, 필요 시 Option 3(기존 모니터링과 연동)를 추가합니다.

근거:

SageMaker 기본 지표만으로도 가용성·지연·에러율 추적 가능.
비용 할당 태그(SageMaker 엔드포인트·모델 그룹)로 월별 비용을 RunPod 등과 비교 가능.
Langfuse는 트레이스·프롬프트 품질용으로 유지하고, 인프라 지표는 CloudWatch에 두어 역할을 나눈다.

구체적 조치:

SageMaker 리소스에 비용 할당 태그 적용(예: Project=DevthsAI, Model=Exaone8B).
CloudWatch 알람: ModelErrors 또는 Invocations 이상 시 SNS/이메일 알림.
(선택) 주간 비용 리뷰에서 SageMaker vs RunPod 비용 비교.

Consequences (결과)

긍정적 영향: 비용 가시성·알람으로 이상 징후 조기 발견.

부정적 영향: Model Monitor·커스텀 지표는 초기에는 생략해 복잡도 완화.

후속 작업:

비용 할당 태그 정책 및 알람 임계값 문서화
(선택) CloudWatch 대시보드 또는 Grafana 데이터 소스 연동

이력

날짜	변경 내용
2026-02-23	초기 작성