AI 플랫폼 선택 가이드: 매니지드 vs 오픈소스 vs 하이브리드
고객이 AI를 직접 개발하려 할 때 가장 먼저 직면하는 질문은 "매니지드 서비스를 쓸 것인가, 오픈소스로 직접 구축할 것인가?"입니다. 이 문서는 SageMaker Unified Studio, Bedrock AgentCore, EKS 기반 오픈 아키텍처 중 고객 상황에 맞는 최적 접근을 선택할 수 있도록 의사결정 프레임워크를 제공합니다.
AI 플랫폼 구축 경로는 크게 3가지로 나뉩니다:
- (A) AWS 매니지드: Bedrock + Strands SDK + AgentCore로 인프라 운영 없이 시작
- (B) EKS + 오픈소스: vLLM, llm-d, Langfuse 등 자체 호스팅으로 최대 제어권 확보
- (C) 하이브리드: Bedrock과 EKS를 조합하여 비용·통제·속도의 균형 달성
AWS AI 플랫폼 서비스 랜드스케이프
이 문서는 AWS AI 서비스를 역할에 따라 4개의 Tier로 묶어 설명합니다. 이는 AWS가 규정한 제품 계층이 아니라 이 가이드의 분류이며, 각 Tier는 보완적 책임(모델 액세스·개발 환경·운영·인프라)을 나타냅니다. Tier는 반드시 순서대로 거쳐야 하는 성숙도 단계가 아니라 요건에 따라 조합하는 구성 요소로, 예를 들어 Tier 1 Bedrock 추론과 Tier 4 EKS 자체 호스팅을 성숙도 진행 없이 함께 쓸 수 있습니다.
Tier 구분의 핵심:
- Tier 1-3: AWS 매니지드 서비스로 서버·GPU 인프라 운영 없이 시작할 수 있습니다. 다만 매니지드 서비스에서도 IAM·네트워크 경계·비용·프롬프트/모델 평가·관측성 같은 운영 책임은 사용자에게 남습니다.
- Tier 4: 모델 서빙 계층의 세밀한 제어, 지원 모델 범위 밖 가중치의 자체 호스팅, 또는 VPC 내 처리 같은 데이터 주권 요건이 있을 때 선택하며, Kubernetes·GPU 운영 부담을 수반합니다.
- 각 Tier는 보완 관계이므로 고정된 진행 순서 없이 요건에 따라 조합합니다. 처음부터 Tier 1과 Tier 4를 함께 쓰거나, 특정 Tier만 사용할 수도 있습니다.
SageMaker Unified Studio
통합 AI 개발 환경
SageMaker Unified Studio는 2024년 12월 re:Invent에서 프리뷰로 공개되고 2025년 3월 정식 출시(GA)된 통합 AI 개발 환경으로, ML/데이터/분석 작업을 하나의 IDE에서 수행할 수 있도록 설계되었습니다. 기존에는 SageMaker Studio Classic, Athena, Glue Studio 등 분산된 도구를 개별적으로 사용해야 했지만, Unified Studio는 이를 하나로 통합합니다.
핵심 차별점
| 기능 | 설명 | 기존 대비 개선 |
|---|---|---|
| 통합 IDE | JupyterLab + SQL 편집기 + 노코드 인터페이스 | SageMaker Studio Classic 대비 데이터+ML 통합 |
| Built-in MLflow | 실험 추적, 모델 레지스트리, 모델 비교 | 별도 MLflow 서버 운영 불필요 |
| Lakehouse 통합 | Apache Iceberg 테이블, Glue Catalog 네이티브 연동 | 데이터 엔지니어링 → ML 파이프라인 원스톱 |
| 거버넌스 협업 | Amazon DataZone 기반 IAM 공유, 데이터 계보 추적 | 팀 간 안전한 데이터/모델 공유 |
| 통합 컴퓨팅 | 학습, 노트북, 파이프라인을 단일 환경에서 관리 | 리소스 파편화 방지 |
포지셔닝: 언제 선택하는가?
SageMaker Unified Studio는 **개발 환경(Tier 2)**입니다. Bedrock(추론)이나 EKS(서빙)와 보완 관계이며, 특히 데이터 팀과 ML 팀이 하나의 플랫폼에서 협업해야 할 때 가장 큰 가치를 제공합니다.
플랫폼 비교 매트릭스
고객의 상황에 따라 최적 접근이 다릅니다. 5가지 핵심 평가축으로 각 플랫폼 옵션을 비교합니다.
| 평가축 | Bedrock + AgentCore | SageMaker Unified Studio | EKS+오픈소스 | 하이브리드 |
|---|---|---|---|---|
| 비용 구조 | 사용량 과금, GPU 관리 불필요 | 인스턴스+사용량 혼합, 노트북/학습 별도 | Spot/MIG 최적화, 초기 투자 필요 | API 사용량 + SLM 고정비, 라우팅 효과 실측 |
| 운영 부담 | 최소 — AWS 완전 관리 | 낮음 — 인프라 관리 최소, ML 워크플로우 집중 | 중간 — K8s/GPU 운영 역량 필요 (Auto Mode로 절감) | 중간 — 두 환경 모두 이해 필요 |
| 데이터 주권 | 선택한 리전 또는 추론 프로필의 지리 범위에서 처리 (Geo CRIS는 여러 국가 리전을 포함할 수 있음) | VPC 격리. 학습 데이터는 S3 외에 인스턴스 메모리·로컬/EBS 캐시·CloudWatch 로그에도 남을 수 있음 | 완전 제어 — VPC 내 모델+데이터 격리 | 워크로드별 선택적 격리 |
| 커스터마이징 | Bedrock 모델과 Guardrails 중심. AgentCore Runtime의 에이전트는 외부·자체 호스팅 모델도 호출 가능 | MLflow, 커스텀 파이프라인, Fine-tuning 지원 | 높은 유연성 — 선택한 서빙 백엔드가 지원하는 오픈 모델(예: vLLM 지원 아키텍처), LoRA, 커스텀 게이트웨이 | 필요에 따라 선택적 확장 |
| Time-to-Value | API 연결·권한·품질 평가 | 환경·데이터 접근·파이프라인 구성 | 클러스터·GPU·모델 서빙 및 운영 준비 | 두 경로의 연동·품질·전환 검증 |
자체 호스팅과 Bedrock의 상세 비용 비교(손익분기점, Cascade Routing 절감 효과)는 코딩 도구 비용 분석을 참고하세요.
의사결정 플로우차트
고객 미팅에서 활용할 수 있는 의사결정 흐름입니다. 핵심 질문에 답하면서 최적 접근을 찾아갑니다.
이 플로우차트는 대화의 시작점이지, 최종 결론이 아닙니다. 각 분기는 단일 기술로 자동 매핑되지 않으므로 다음 조건을 함께 확인하세요.
- Q1(Open Weight 자체 호스팅): "Yes"가 곧 EKS를 뜻하지는 않습니다. 해당 가중치가 Bedrock Marketplace, Bedrock Custom Model Import, SageMaker AI 엔드포인트 등 매니지드 호스팅으로 지원되는지 먼저 확인하고, 지원되지 않거나 서빙 스택 제어가 필요한 경우에 EKS 자체 호스팅을 선택합니다.
- Q2(데이터 주권): VPC·리전 격리 요건이 반드시 하이브리드를 의미하지는 않습니다. 처리·저장이 허용되는 구체적 국가/리전 범위를 먼저 정의한 뒤, 해당 범위를 리전 고정(SCP)과 Bedrock 추론 프로파일로 충족할 수 있는지, 아니면 자체 호스팅이 필요한지 판단합니다.
- Q3 이후 기본값: 신규가 아닌 모든 워크로드가 하이브리드로 수렴하는 것은 아닙니다. 팀의 Kubernetes·GPU 운영 역량과 실제 운영 용량을 확인하고, 역량이 없으면 매니지드 경로를 유지하는 편이 낫습니다.
실제 고객 상황은 복합적이며, 하이브리드는 요건에 따라 선택하는 설계 중 하나입니다.
네 번째 결정축: 데이터 주권
앞의 플로우차트는 워크로드·볼륨·역량을 기준으로 했지만, 규제 산업에서는 **데이터 주권(Sovereignty)**이 다른 모든 기준에 우선하는 하드 제약으로 작용합니다. 주권 요구는 Public → In-country → Hybrid → Air-gapped 스펙트럼으로 나타나며, 요구 강도가 높을수록 매니지드 의존도는 낮아지고 자체 호스팅·온프레미스 비중이 커집니다.
| 주권 수준 | 추론 위치 | 권장 접근 |
|---|---|---|
| Public | 리전 제약 없음 | AWS Native |
| In-country | 특정 국가 리전 고정 | 대상 국가가 요구하는 처리 범위를 먼저 확인합니다. Bedrock 추론 프로파일(CRIS)의 지리적 범위는 여러 국가에 걸칠 수 있으므로, 단일 국가 거주가 요건이면 해당 국가 리전만 포함하는 프로파일 또는 단일 리전 호출을 선택하고 SCP로 리전을 강제합니다. |
| Hybrid | 온프레미스 + in-country | EKS Hybrid Nodes + 자체 호스팅. Hybrid Nodes는 온프레미스·엣지 노드와 AWS 관리형 컨트롤 플레인 간 안정적 연결이 필요합니다. |
| Air-gapped | 완전 격리 | 온프레미스 EKS(연결 차단 환경은 EKS Anywhere의 에어갭 설치). EKS Hybrid Nodes는 연결을 끊는다고 에어갭이 되지 않으며 DDIL 환경에 적합하지 않으므로, 완전 격리에는 Hybrid Nodes가 아니라 EKS Anywhere 디스커넥티드 라이프사이클을 사용합니다. |
데이터 주권은 의사결정의 첫 번째 필터로 두는 것이 안전합니다. 주권 제약이 EKS 자체 호스팅 또는 하이브리드를 강제하면, 비용·볼륨 기준의 결론보다 우선합니다. 단, "In-country"는 대상 국가의 처리 범위를 확인한 뒤 그에 맞는 리전/프로파일을 선택해야 하며, "Air-gapped"에서 연결형 Hybrid Nodes와 디스커넥티드 EKS Anywhere는 서로 다른 제품·운영 모델이라는 점에 유의하세요.
SCP 리전 강제 정책, Bedrock Geographic cross-Region inference, EKS Hybrid Nodes 기반 하이브리드·in-country 자체 호스팅 구현은 소버린 & 하이브리드 배포를 참조하세요.
고객 성숙도별 권장 경로
고객의 현재 AI/ML 성숙도에 따라 시작점과 확장 경로가 달라집니다.
아래 기간은 단계별 작업 범위를 논의하기 위한 초기 계획값입니다. API 연결, 시범 운영, 운영 승인처럼 완료 기준을 먼저 정하고 팀의 준비 상태에 따라 다시 산정합니다.
| 성숙도 | 특징 | 권장 스택 | 핵심 서비스 | 기간 |
|---|---|---|---|---|
| Level 1 — AI 탐색기 | AI/ML 워크로드 없음, 빠른 PoC 필요 | AWS 매니지드 우선 | Bedrock API + Strands SDK + AgentCore | 2-4주 |
| Level 2 — AI 구축기 | ML 일부 운영, 학습 파이프라인 필요 | SageMaker + Bedrock 하이브리드 | SageMaker Unified Studio + Bedrock + S3/Glue | 1-3개월 |
| Level 3 — AI 최적화기 | 대규모 추론, 비용 압박, 커스텀 모델 | EKS 오픈 아키텍처 + Cascade Routing | EKS + vLLM/llm-d + kgateway + Bifrost + Langfuse | 3-6개월 |
각 레벨별 상세 가이드:
- Level 1 (탐색): → AWS Native 플랫폼
- Level 2 (구축): → SageMaker-EKS 통합
- Level 3 (최적화): → EKS 기반 오픈 아키텍처, 추론 게이트웨이
하이브리드 조합 패턴
다음은 서비스 책임을 나누는 4가지 조합 예제입니다. 실제 적합성은 데이터 경계, 운영 역량, 품질·지연·비용 평가로 확인합니다.
| 패턴 | 구성 | 적합 시나리오 | 복잡도 |
|---|---|---|---|
| Bedrock + EKS SLM | Bedrock(추론) + EKS 자체 SLM(고빈도) | API 비용 절감이 급한 대규모 추론 | ★★☆☆☆ (2/5) |
| SageMaker 학습 + EKS 서빙 | SageMaker(학습/실험) + EKS+vLLM(서빙) | ML 팀과 서빙 팀이 분리된 조직 | ★★★☆☆ (3/5) |
| AgentCore + 자체 모델 | AgentCore(Agent 런타임) + EKS(커스텀 모델 추론) | Agent 운영은 AWS, 모델은 자체 호스팅 | ★★★☆☆ (3/5) |
| Full Stack | Unified Studio(개발) + Bedrock(외부) + EKS(자체) + AgentCore(운영) | 엔터프라이즈 AI CoE, 전체 AI 라이프사이클 관리 | ★★★★☆ (4/5) |
패턴 1: Bedrock + EKS SLM (Cascade Routing)
사용 시점: 자체 SLM으로 품질 기준을 충족하는 요청 집합이 있고, 해당 비중과 두 경로의 전체 운영 비용을 측정할 수 있는 경우
검증할 가치: 품질·지연 기준을 유지하면서 실제 총비용을 줄이는지 확인합니다. 요청 비율만으로 GPU 고정비 감소나 품질 보존을 가정하지 않습니다.
참고: 추론 게이트웨이 & Cascade Routing
패턴 2: SageMaker 학습 + EKS 서빙
사용 시점: 커스텀 모델을 학습하고, 추론 비용을 낮추려는 경우
검증할 가치: SageMaker 관리형 학습으로 모델을 만들고 EKS에서 서빙할 때, 같은 품질·지연 조건에서 Bedrock 등 대안 대비 실제 총비용(GPU 고정비·활용률·운영 포함)이 낮아지는지 측정합니다. 서빙 위치가 EKS라는 사실만으로 비용 효율이 보장되지는 않습니다.
참고: SageMaker-EKS 통합
패턴 3: AgentCore + 자체 모델
사용 시점: Agent 런타임은 서버리스로 운영하되, 특정 도메인 모델은 자체 호스팅하려는 경우
검증할 가치: 자체 호스팅한 도메인 모델이 같은 작업에서 Bedrock 등 매니지드 모델 대비 품질(정확도)이 실제로 더 높은지 평가 데이터로 확인하고, 그 이점이 추가 운영 비용·지연을 상쇄하는지 함께 측정합니다. 커스터마이징·자체 호스팅 자체가 도메인 정확도를 보장하지는 않습니다.
참고: AWS Native 플랫폼
패턴 4: Full Stack (SageMaker + Bedrock + EKS)
가장 복잡하지만 최대 유연성을 제공하는 패턴입니다:
- 데이터 & 학습: SageMaker Unified Studio + Pipelines
- 프로덕션 추론: Bedrock API (고신뢰 작업) + EKS vLLM (고볼륨 작업)
- Agent 런타임: AgentCore (서버리스) + Kagent (Kubernetes 네이티브)
- Observability: CloudWatch (매니지드) + Langfuse (자체 호스팅)
이 패턴은 대규모 엔터프라이즈에서 팀별로 다른 요구사항을 충족하기 위해 선택합니다. 아키텍처 복잡도가 높으므로, 명확한 운영 책임 경계와 서비스 카탈로그가 필수입니다.
참고: 하이브리드 아키텍처의 기술적 구현은 SageMaker-EKS 통합을 참고하세요.
비용 시뮬레이션 요약
월 요청량만으로 최적 옵션이나 비용을 결정할 수 없습니다. 다음 입력을 같은 작업 집합과 서비스 수준에서 수집해 비교합니다.
| 비교 대상 | 수집할 입력 | 확인할 조건 |
|---|---|---|
| Bedrock API | 모델·리전·추론 방식, 입력/출력·캐시 토큰 | 품질·지연과 실제 청구량 |
| Bedrock + EKS SLM | 라우팅 비중, API 청구량, SLM 고정비 | 분류 오류·fallback·유휴 용량 |
| EKS 자체 호스팅 | 노드시간, 처리 용량, 전체 인프라·운영 비용 | 피크 부하·가용성·확장 구간 |
| IDE 구독 도구 | 실제 작업별 크레딧과 구독 총액 | 동일 작업 완료율과 기능 범위 |
과금 단위, 가상의 손익분기 계산과 Cascade 고정비 경계는 코딩 도구 비용 분석을 참고하세요.
고객 Discovery 체크리스트
고객 미팅에서 최적 접근을 파악하기 위한 11가지 핵심 질문입니다.
- 현재 AI/ML 워크로드를 운영하고 있습니까? → 성숙도 레벨 판단
- 월간 추론 요청 규모는 어느 정도입니까? → 비용 최적화 경로
- Open Weight 모델 자체 호스팅이 필요합니까? → EKS 필요성
- 데이터 주권 또는 VPC 격리 요구사항이 있습니까? → 자체 호스팅/하이브리드
- 팀 내 Kubernetes 운영 경험이 있습니까? → 운영 부담 평가
- ML 학습과 데이터 엔지니어링을 함께 수행합니까? → SageMaker Unified Studio
- 월 예산 범위는 어느 정도입니까? → 비용 구조 매칭
- 프로덕션 배포 목표 시점은 언제입니까? → Time-to-Value 경로
- 온프레미스·엣지에서 AWS와 안정적으로 연결해 운영해야 합니까? → EKS Hybrid Nodes (안정적 연결 필요, 다른 클라우드·AWS 리전/Local Zones/Outposts에서는 미지원)
- 다른 클라우드에서도 워크로드를 운영해야 합니까(멀티클라우드)? → EKS Hybrid Nodes는 해당하지 않음. 각 클라우드의 매니지드 Kubernetes 또는 EKS Anywhere 등 지원되는 Kubernetes 관리 옵션을 별도로 선택
- 현재 사용 중인 AWS 서비스는 무엇입니까? → 기존 투자 활용
참고 자료
공식 문서
- Amazon SageMaker Unified Studio — 통합 AI 개발 환경
- Amazon Bedrock Documentation — Bedrock 공식 문서
- Amazon EKS Best Practices — EKS 권장사항
- AWS Well-Architected Framework — 아키텍처 프레임워크
논문 / 기술 블로그
- AWS Machine Learning 블로그 (색인) — 플랫폼 선택 관련 글을 찾는 블로그 색인 페이지(특정 비교를 입증하는 단일 글 아님)
- Cost Optimization for LLM Inference — 비용 최적화 전략
- AWS Architecture Center (색인) — 하이브리드 패턴 등 아키텍처 자료를 찾는 색인 페이지(특정 패턴을 입증하는 단일 글 아님)
- Building Production ML Systems — 프로덕션 ML 가이드
관련 문서 (내부)
- 플랫폼 아키텍처 — 6 레이어 + 3 플레인
- 기술적 도전과제 — 5가지 핵심 과제
- AWS Native 플랫폼 — 매니지드 서비스 상세
- EKS 기반 오픈 아키텍처 — 자체 호스팅 상세
- 소버린 & 하이브리드 배포 — 데이터 주권, SCP 리전 강제, EKS Hybrid Nodes