이 문서는 AWS, Google Cloud, Azure에서 제공하는 대표적인 AI/ML 플랫폼 서비스의 특징을 비교하고, 프로젝트의 요구사항에 맞춰 '자체 구축 모델'과 '관리형 서비스' 중 어떤 것을 선택할지에 대한 의사결정을 돕기 위해 작성되었습니다.
---
## 1. 주요 클라우드 AI 플랫폼 비교: `AWS SageMaker` vs. `Google Vertex AI` vs. `Azure ML`
세 플랫폼 모두 데이터 준비부터 모델 학습, 배포, 모니터링에 이르는 End-to-End MLOps 라이프사이클을 지원하는 것을 목표로 하지만, 각 클라우드의 기존 서비스 생태계와 강점에 따라 조금씩 다른 특징을 보입니다.
| 구분 항목 | Amazon SageMaker (AWS) | Vertex AI (Google Cloud) | Azure Machine Learning (Azure) |
| :--- | :--- | :--- | :--- |
| **핵심 특징** | **가장 성숙하고 포괄적인 기능**: ML을 위한 거의 모든 도구와 서비스를 모듈 형태로 제공. 유연성과 제어권이 높음. | **강력한 AutoML 및 구글 AI 기술 통합**: AutoML 기능이 매우 강력하며, 구글의 최신 AI 연구(e.g., Gemini)가 빠르게 통합됨. | **엔터프라이즈 및 하이브리드 환경에 최적화**: MS 생태계와의 강력한 통합. 책임감 있는 AI(Responsible AI) 기능 강조. |
| **개발 환경** | - SageMaker Studio<br>- SageMaker Notebook Instances<br>- 로컬 환경 + SageMaker SDK | - Vertex AI Workbench (JupyterLab)<br>- Colab Enterprise | - Azure ML Studio<br>- VS Code 통합<br>- Azure ML SDK |
| **주요 기능** | - **Data Wrangler**: 데이터 준비<br>- **Feature Store**: 피처 관리<br>- **JumpStart**: 사전 훈련된 모델<br>- **Clarify**: 편향성 및 설명가능성 | - **AutoML**: 코드 없이 모델 학습<br>- **Model Garden**: 구글 및 오픈소스 모델 탐색<br>- **Generative AI Studio**: 생성형 AI 모델 맞춤화<br>- **Matching Engine**: 벡터 검색 | - **Designer**: GUI 기반 모델링<br>- **Responsible AI Dashboard**: 모델 공정성, 설명가능성 분석<br>- **Prompt Flow**: LLM 앱 개발 및 평가 |
| **생태계** | AWS의 방대한 서비스(S3, EC2, Lambda 등)와 가장 긴밀하게 연동됨. 가장 큰 시장 점유율과 커뮤니티. | Google Cloud의 데이터/분석 서비스(BigQuery, Looker)와 긴밀하게 연동. 딥러닝 및 AI 연구 분야의 강점. | Microsoft 365, GitHub, Power BI 등 MS의 엔터프라이즈 솔루션과 강력하게 연동. |
| **강점** | - **유연성 및 사용자 제어**: 사용자가 MLOps 파이프라인의 각 단계를 세밀하게 제어하고 커스터마이징할 수 있음.<br>- **성숙도와 안정성**: 가장 먼저 출시되어 시장에서 검증됨. | - **최신 AI 기술 접근성**: Gemini, PaLM 등 구글의 최첨단 모델을 빠르게 활용 가능.<br>- **사용자 친화성**: 특히 AutoML과 Vertex AI Studio의 UI/UX가 직관적임. | - **책임감 있는 AI (RAI)**: 공정성, 개인정보보호 등 윤리적 AI 구축을 위한 도구를 통합적으로 제공.<br>- **강력한 보안 및 거버넌스**. |
| **고려사항** | 기능이 매우 많은 만큼, 처음 사용하는 경우 학습 곡선이 다소 가파를 수 있음. | 일부 최신 기능은 다른 리전보다 미국에서 먼저 출시되는 경향이 있음. | SageMaker에 비해 상대적으로 MLOps 관련 서드파티 솔루션 생태계가 작을 수 있음. |
### 어떤 플랫폼을 선택해야 할까?
-**`Amazon SageMaker`**:
- 이미 **AWS 생태계**를 활발히 사용하고 있는 조직.
- ML 파이프라인의 **모든 단계를 직접 제어하고 커스터마이징**하고 싶은 숙련된 ML 엔지니어 팀.
- 다양한 옵션과 유연성이 중요한 복잡한 프로젝트.
-**`Google Vertex AI`**:
-**BigQuery** 등 Google Cloud의 데이터 플랫폼을 중심으로 데이터를 관리하는 조직.
- 코딩 없이 **강력한 AutoML**을 활용하여 빠르게 모델을 만들고 싶거나, **Gemini와 같은 최신 구글 AI 모델**을 활용하고 싶은 경우.
- 직관적인 UI와 사용자 경험을 중요하게 생각하는 팀.
-**`Azure Machine Learning`**:
-**Microsoft 365, Teams, Power BI** 등 MS 오피스 및 엔터프라이즈 솔루션을 주로 사용하는 기업 환경.
-**보안, 거버넌스, 책임감 있는 AI(RAI)** 원칙 준수가 매우 중요한 프로젝트.
- GUI 기반의 `Designer`나 `Prompt Flow`를 활용하여 개발 생산성을 높이고 싶은 팀.
---
## 2. 선택의 기로: 자체 구축 모델 vs. 관리형 AI 서비스
클라우드 플랫폼은 위에서 소개한 MLOps 플랫폼 외에도, 특정 기능에 특화된 수많은 '관리형 AI 서비스'(예: Vision API, Translate API, Rekognition 등)를 제공합니다. 이제 우리는 중요한 선택의 기로에 놓입니다. 밑바닥부터 우리만의 모델을 만들어야 할까요, 아니면 이미 만들어진 서비스를 가져다 쓰는 것이 현명할까요?
정답은 없으며, 프로젝트의 목표와 상황에 따라 최적의 선택은 달라집니다. 아래의 기준을 통해 합리적인 의사결정을 내리는 데 도움을 얻을 수 있습니다.
### 의사결정 프레임워크
| 고려 항목 | 자체 구축 모델 (Build Your Own Model) | 관리형 AI 서비스 (Use Managed Services) |
| :--- | :--- | :--- |
| **문제의 종류** | **독창적이고 복잡한 문제**: 기존에 해결책이 없거나, 우리 비즈니스 도메인에 매우 특화된 문제를 해결해야 할 때. | **보편적이고 표준화된 문제**: 이미지 분류, 객체 탐지, 텍스트 번역, 감성 분석 등 이미 잘 알려진 문제를 해결할 때. |
| **커스터마이징** | **필요성 높음**: 모델 아키텍처, 학습 과정, 데이터 전처리 등 모든 단계를 세밀하게 제어하고 최적화해야 할 때. | **필요성 낮음**: API 요청/응답 형식으로 충분하며, 내부 모델 구조를 몰라도 괜찮을 때. |
| **데이터** | **대규모의 고품질 데이터 보유**: 모델을 처음부터 학습시키기에 충분한 양과 품질의 레이블링된 데이터가 준비되어 있을 때. | **데이터 부족 또는 없음**: 자체 데이터를 수집하거나 레이블링하기 어렵고, 일반적인 데이터로 학습된 모델로도 충분할 때. |
| **인력 및 전문성** | **전문 ML 엔지니어/과학자 팀 보유**: 딥러닝 프레임워크, MLOps, 인프라 관리에 대한 높은 전문성을 가진 팀이 있을 때. | **개발자 중심 팀**: ML 전문가는 부족하지만, API를 활용하여 빠르게 애플리케이션을 개발할 수 있는 팀. |
| **개발 속도** | **상대적으로 느림**: 데이터 준비, 모델 설계, 학습, 튜닝, 배포 등 많은 시간과 노력이 소요됨. | **매우 빠름**: API 키 발급 후 몇 줄의 코드로 즉시 기능을 구현하고 테스트할 수 있음. |
| **비용** | **높은 초기 투자 비용**: GPU 서버 임대/구매, 인건비 등 초기 투자 비용이 큼. 장기적으로는 트래픽 양에 따라 API 호출 비용보다 저렴해질 수 있음. | **낮은 초기 비용**: 초기 개발 비용이 거의 없음. API 호출량에 따라 비용이 증가하는 예측 가능한 종량제 구조. |
| **유지보수** | **지속적인 노력 필요**: 모델 성능 저하 모니터링, 재학습, 인프라 관리 등 지속적인 유지보수 노력이 필요함. | **거의 필요 없음**: 모델 및 인프라에 대한 유지보수는 전적으로 클라우드 제공업체가 담당함. |
### 최종 권장 사항
-**`관리형 AI 서비스`로 먼저 시작하세요 (Start with Managed Services First):**
- 풀어야 할 문제가 이미지 인식, 번역, STT/TTS 등 **보편적인 문제**라면, 굳이 바퀴를 재발명할 필요가 없습니다.
- API를 활용하여 **빠르게 프로토타입을 만들고 사업 가설을 검증**하는 데 집중하세요. 서비스가 성공적으로 성장하여 API 비용이 부담되거나, 더 높은 수준의 커스터마이징이 필요해지는 시점에 자체 모델 구축을 고려해도 늦지 않습니다.
-**`자체 구축 모델`이 필요한 명확한 이유가 있을 때 도전하세요 (Build a Model for a Good Reason):**
- 우리의 서비스가 **핵심적인 경쟁력**을 가지려면 반드시 해결해야 하는 **독창적인 문제**일 경우.
- 세상에 없는 새로운 모델 구조를 연구하거나, 우리만이 보유한 **독점적인 대규모 데이터셋**의 가치를 극대화하고 싶을 경우.
- 장기적으로 API 호출 비용보다 **총소유비용(TCO)을 절감**할 수 있다는 명확한 계산이 섰을 경우.
결론적으로, 대부분의 기업과 개발자에게 가장 현명한 전략은 **"가능한 한 관리형 서비스를 최대한 활용하고, 그것만으로는 해결할 수 없는 우리만의 핵심 문제에만 집중하여 모델을 구축하는 것"** 입니다. 이는 한정된 자원을 가장 중요한 곳에 집중하여 비즈니스 가치를 극대화하는 길이 될 것입니다.
본 문서는 AI 전문가 과정의 주요 실습 과제를 짝 프로그래밍 방식으로 진행하고자 하는 분들을 위한 가이드라인입니다.
## 1. 짝 프로그래밍이란?
짝 프로그래밍은 두 명의 개발자가 하나의 컴퓨터(워크스테이션)에서 함께 작업하는 애자일 소프트웨어 개발 방법론입니다. 두 개발자는 다음과 같은 역할을 번갈아 수행합니다.
-**드라이버 (Driver)**: 키보드와 마우스를 잡고 실제로 코드를 작성하는 역할을 합니다. '어떻게' 구현할 것인가(How)에 집중하며, 당면한 로직을 코드로 옮기는 데 집중합니다.
-**네비게이터 (Navigator)**: 작성 중인 코드를 실시간으로 검토하고, 다음에 진행할 방향을 제시합니다. '무엇을, 왜'(What, Why) 해야 하는지에 집중하며, 큰 그림을 보고 잠재적인 오류나 더 나은 설계 방향을 고민합니다.
## 2. 왜 짝 프로그래밍을 해야 할까요?
이 과정에서 짝 프로그래밍을 권장하는 이유는 다음과 같습니다.
-**지식 공유 및 학습 효과 증대**: 서로의 지식과 경험을 실시간으로 공유하며 혼자서는 발견하기 어려운 새로운 해결책을 찾을 수 있습니다.
-**코드 품질 향상**: 네비게이터의 지속적인 코드 리뷰를 통해 버그를 조기에 발견하고, 더 명확하고 효율적인 코드를 작성할 수 있습니다.
-**문제 해결 능력 강화**: 복잡한 문제에 직면했을 때, 함께 논의하며 다양한 관점에서 해결책을 모색할 수 있어 문제 해결 능력이 향상됩니다.
-**커뮤니케이션 능력 향상**: 자신의 생각을 명확히 설명하고, 동료의 의견을 경청하며 합의를 이끌어내는 과정을 통해 협업 능력을 기를 수 있습니다.
## 3. 성공적인 짝 프로그래밍 세션 진행 방법
1.**시작 전 (5-10분)**
- 실습 과제의 요구사항을 함께 읽고 목표를 명확히 이해합니다.
- 코드를 작성하기 전에, 전체적인 구조와 접근 방식에 대해 함께 논의하고 간단한 계획을 세웁니다. (예: "먼저 데이터 로딩 함수부터 만들고, 그 다음 API 엔드포인트를 설계하자.")
2.**진행 중**
-**역할 교대**: 20~30분 간격으로 타이머를 설정하여 '드라이버'와 '네비게이터' 역할을 주기적으로 교대합니다. 이는 두 사람의 집중력을 유지하고 양쪽 모두가 동등하게 기여하도록 돕습니다.
-**지속적인 소통**: 드라이버는 자신이 작성하는 코드의 의도를 소리 내어 설명하고, 네비게이터는 질문하거나 대안을 제시하며 적극적으로 대화에 참여합니다. 침묵은 길어지지 않는 것이 좋습니다.
-**존중하는 자세**: 아이디어에 대해 비판하되, 사람을 비판하지 않습니다. 정중하고 건설적인 방식으로 의견을 교환합니다.
3.**문제가 막혔을 때**
- 곧바로 혼자 검색부터 시작하지 마세요.
- 먼저 두 사람이 현재 상황과 문제점을 다시 한번 정리하고, 시도해 본 방법과 가능한 다음 단계를 함께 논의합니다.
- 함께 논의한 후, 검색 키워드를 정해 해결책을 찾아봅니다.
4.**세션 종료 후**
- 완성된 코드를 함께 리뷰하며, 잘된 점과 다음 세션에서 개선할 점에 대해 간단히 회고합니다.
## 4. 도구 및 환경 설정
-**VS Code Live Share**: 원격으로 짝 프로그래밍을 진행할 때 가장 추천하는 도구입니다. 한 사람이 호스트가 되어 세션을 시작하고, 링크를 공유하면 다른 사람이 게스트로 참여하여 실시간으로 코드를 편집하고, 서버를 공유하며, 터미널을 함께 사용할 수 있습니다.
1. VS Code의 '확장(Extensions)' 탭에서 `Live Share`를 검색하여 설치합니다.
2. 설치 후 VS Code 좌측 하단의 Live Share 아이콘을 클릭하여 로그인 및 세션을 시작할 수 있습니다.
## 5. 본 과정에서의 적용 예시
다음과 같은 실습 과제들은 짝 프로그래밍을 통해 더 큰 학습 효과를 얻을 수 있습니다.
-**`08_model_serving_with_fastapi`**: FastAPI를 사용하여 API 엔드포인트의 요청/응답 스키마를 정의하고, 라우팅 로직을 구현할 때.
-**`09_production_ready_api`**: Dockerfile을 작성하고, 테스트 코드를 구현하며 API 구조를 설계할 때.
-**`13_generative_ai/advanced_rag_chatbot.py`**: 복잡한 RAG 파이프라인(문서 로딩, 분할, 임베딩, 검색)의 전체적인 흐름을 설계하고 구현할 때.
-**`15_capstone_project`**: 전체 프로젝트는 기획부터 구현, 테스트까지 모든 단계를 짝 프로그래밍으로 진행하기에 매우 적합합니다.
짝 프로그래밍은 단순한 기술이 아닌, 협업과 소통의 문화입니다. 열린 마음으로 시도해본다면 기술적 성장과 더불어 훌륭한 동료를 얻는 값진 경험을 하게 될 것입니다.
이 문서는 AI 프로젝트 개발 과정에서 마주하게 되는 주요 도구와 프레임워크들의 특징을 비교하고, 기술 선택에 도움이 되는 가이드라인을 제공하기 위해 작성되었습니다.
---
## 1. Deep Learning Frameworks: `TensorFlow` vs. `PyTorch`
TensorFlow와 PyTorch는 현재 딥러NING 모델 개발의 양대 산맥을 이루는 가장 중요한 프레임워크입니다. 두 도구 모두 강력한 기능과 방대한 커뮤니티를 자랑하지만, 설계 철학과 강점에서 차이를 보입니다.
| 구분 항목 | TensorFlow (Google) | PyTorch (Meta) |
| :--- | :--- | :--- |
| **핵심 철학** | "Define-and-Run" (정적 계산 그래프) | "Define-by-Run" (동적 계산 그래프) |
| **API 스타일** | Keras를 통한 고수준 API의 강력한 추상화 | Pythonic하고 직관적인 저수준 API |
| **그래프 모델** | **정적 그래프 (Static Graph)**: 먼저 전체 모델의 계산 그래프를 정의하고, 세션(Session)을 통해 데이터를 주입하여 실행. 최적화에 유리. | **동적 그래프 (Dynamic Graph)**: 코드가 실행되는 시점에 그래프가 생성. 유연하고 디버깅이 쉬움. |
| **사용 편의성** | Keras 통합 이후 매우 쉬워졌으나, 저수준 API는 다소 복잡. | NumPy와 유사한 구조로 Python 개발자에게 매우 친숙하고 직관적. |
| **디버깅** | `tf.print` 또는 별도 디버거 필요. 정적 그래프 특성상 디버깅이 상대적으로 까다로움. | 표준 Python 디버깅 도구(e.g., `pdb`)를 그대로 사용 가능하여 매우 편리함. |
| **생태계** | **TensorFlow Extended (TFX)**를 중심으로 한 강력한 프로덕션 및 배포 생태계 (TensorFlow Serving, TensorFlow Lite 등) | 학계 및 연구 커뮤니티에서 압도적인 지지를 받으며, 최신 논문 구현체가 빠르게 공유됨. (Hugging Face 등) |
| **배포** | 모바일, 엣지, 서버 등 다양한 환경에 모델을 배포하기 위한 **TensorFlow Serving**, **TF Lite** 등 성숙한 솔루션 보유. | **TorchServe**, **ONNX** 등을 통해 배포를 지원하지만, 과거에는 TensorFlow 대비 약점으로 꼽혔음. 최근 빠르게 발전 중. |
| **시각화** | **TensorBoard**: 강력하고 상세한 모델 분석 및 시각화 기능 기본 제공. | TensorBoard를 함께 사용할 수 있으나, 내장 솔루션은 상대적으로 기능이 적음. |
| **커뮤니티** | 대기업 중심의 강력한 지원과 방대한 사용자 기반 보유. | 연구자 및 학계 커뮤니티가 매우 활발하며, 최신 기술 트렌드를 주도. |
### 선택 가이드 (When to use what?)
-**`TensorFlow`를 선택하는 경우:**
-**프로덕션 환경에 바로 배포**해야 하는 상용 서비스를 개발할 때. (특히 모바일/엣지 디바이스 포함)
-**확장성**과 **분산 학습** 성능이 매우 중요한 대규모 프로젝트를 진행할 때.
- TFX(TensorFlow Extended)를 활용하여 데이터 전처리부터 모델 서빙까지 **End-to-End MLOps 파이프라인**을 구축하고자 할 때.
-**`PyTorch`를 선택하는 경우:**
-**최신 연구 논문을 빠르게 구현**하고 실험해야 하는 연구/개발 환경일 때.
-**유연한 모델 구조**와 **직관적인 디버깅**이 중요한 프로토타이핑 단계일 때.
- Python 코드처럼 간결하고 직관적인 개발 경험을 선호할 때.
**결론:** "연구는 PyTorch, 프로덕션은 TensorFlow"라는 말은 이제 옛말이 되었습니다. PyTorch가 프로덕션 지원을 강화하고 TensorFlow가 Keras와 Eager Execution으로 유연성을 확보하면서 두 프레임워크는 서로의 장점을 흡수하며 발전하고 있습니다. 그럼에도 불구하고, **빠른 실험과 연구에는 `PyTorch`가, 강력하고 성숙한 배포 생태계가 필요할 때는 `TensorFlow`가 여전히 약간의 우위**를 가지고 있다고 볼 수 있습니다. 프로젝트의 목적과 팀의 숙련도에 따라 적절한 도구를 선택하는 것이 중요합니다.
| **핵심 철학** | **개방형 MLOps 플랫폼**: 실험 트래킹, 모델 관리, 배포 등 MLOps 라이프사이클 전반을 포괄하는 모듈형 오픈소스. | **개발자 우선의 실험 관리 도구**: 아름답고 강력한 UI/UX를 통해 실험 과정을 시각화하고 협업하는 것에 집중. |
| **주요 기능** | **Tracking**: 파라미터, 메트릭, 아티팩트 로깅<br>**Projects**: 코드 환경 재현<br>**Models**: 모델 저장 및 버전 관리<br>**Registry**: 중앙 모델 레지스트리 | **Experiments**: 자동 로깅, 실시간 시각화<br>**Sweeps**: 하이퍼파라미터 튜닝<br>**Artifacts**: 데이터셋/모델 버전 관리<br>**Reports**: 분석 내용 공유 및 협업 |
| **UI 및 사용성** | 기능적이지만 다소 투박한 기본 UI. | 매우 세련되고 직관적이며, 커스터마이징 가능한 대시보드 제공. 사용자 경험이 뛰어남. |
| **설치 및 호스팅** | **완전한 오픈소스**: 로컬, 자체 서버, Databricks 등 원하는 환경에 자유롭게 설치 및 운영 가능. | **SaaS가 기본**: W&B 클라우드에 데이터를 저장. Self-hosting 옵션은 엔터프라이즈 플랜에서 제공. |
| **시각화** | 기본적인 그래프 및 비교 기능 제공. | 매우 강력하고 인터랙티브한 시각화 기능 제공. 여러 실험 결과를 비교하고 분석하는 데 탁월함. |
| **협업 기능** | 모델 레지스트리를 통한 협업에 중점. | 프로젝트, 팀, 리포트 기능을 통해 여러 개발자가 실험 결과를 공유하고 논의하기에 매우 용이함. |
| **비용** | **무료 (오픈소스)**. 단, 자체 서버 운영 시 인프라 비용 발생. | 개인 및 학술용은 무료. 팀/기업용은 유료 구독 모델 (사용자 수, 기능에 따라 차등) |
### 선택 가이드 (When to use what?)
-**`MLflow`를 선택하는 경우:**
-**오픈소스 기반**으로 모든 것을 직접 구축하고 제어하고 싶을 때.
-**특정 클라우드나 기술 스택에 종속되지 않는** 유연한 솔루션을 원할 때.
- 이미 Databricks 생태계를 사용하고 있거나, 실험 추적을 넘어 **모델 서빙까지 포괄하는 End-to-End 파이프라인**을 하나의 프레임워크로 관리하고 싶을 때.
- 비용에 민감하여 **무료 솔루션**이 필요할 때.
-**`Weights & Biases (W&B)`를 선택하는 경우:**
-**최고 수준의 사용자 경험과 시각화**를 통해 실험 과정을 분석하고 인사이트를 얻고 싶을 때.
-**팀원들과의 협업**이 매우 중요하고, 실험 결과를 쉽게 공유하고 논의할 필요가 있을 때.
-**하이퍼파라미터 스윕(Sweep)** 기능을 적극적으로 활용하여 모델을 최적화하고 싶을 때.
- 인프라 관리에 드는 노력을 최소화하고, **SaaS 형태로 빠르게 시작**하고 싶을 때.
**결론:**`MLflow`는 **유연성과 확장성을 갖춘 개방형 플랫폼**을 지향하며, MLOps의 전체 사이클을 커버하려는 큰 그림을 가지고 있습니다. 반면 `W&B`는 **실험 추적과 시각화, 협업이라는 특정 문제에 깊게 파고들어 매우 완성도 높은 사용자 경험을 제공**하는 데 집중합니다. **'직접 구축하는 자유도'가 중요하다면 `MLflow`**를, **'최고의 실험 관리 경험과 협업'이 중요하다면 `W&B`**가 매력적인 선택지가 될 것입니다.
---
## 3. Containerization & Orchestration: `Docker` vs. `Kubernetes` for ML
"제 컴퓨터에서는 잘 되는데요?" 라는 말은 AI/ML 프로젝트에서 가장 피해야 할 상황 중 하나입니다. Docker와 Kubernetes는 개발 환경의 일관성을 보장하고, 학습 및 서빙 환경을 안정적으로 운영하기 위한 핵심 기술입니다. 둘은 경쟁 관계가 아닌, 함께 사용될 때 강력한 시너지를 내는 상호 보완적인 관계입니다.
| **개념** | 애플리케이션과 그 종속성(라이브러리, 코드 등)을 **'컨테이너'라는 격리된 표준 단위로 패키징**하는 기술. | 수많은 컨테이너들을 **클러스터 환경에서 자동으로 배포, 확장, 관리**하는 시스템. |
| **주요 기능** | - `Dockerfile`을 통한 이미지 빌드<br>- 컨테이너 생성, 실행, 중지<br>- Docker Hub를 통한 이미지 공유 | - 자동화된 롤아웃과 롤백<br>- 서비스 디스커버리 및 로드 밸런싱<br>- 스토리지 오케스트레이션<br>- 자동화된 복구(Self-healing) |
| **사용 목적** | **Build & Ship**: 개발 환경을 코드처럼 관리하고, 어떤 환경에서든 동일하게 실행되도록 보장. | **Run & Scale**: 여러 서버에 걸쳐 컨테이너화된 애플리케이션을 안정적으로 운영하고, 트래픽에 따라 동적으로 확장. |
| **복잡성** | 상대적으로 배우기 쉽고, CLI 명령어가 직관적임. | 개념이 많고(Pod, Service, Ingress 등) 설정이 복잡하여 학습 곡선이 가파름. |
| **ML/AI 활용** | - **재현 가능한 연구 환경**: `requirements.txt`, CUDA 드라이버 등 복잡한 의존성을 Docker 이미지 하나로 관리.<br>- **모델 서빙 API 패키징**: 학습된 모델과 FastAPI/Flask 앱을 함께 패키징. | - **분산 학습**: 여러 노드에 학습 작업을 분산시켜 대규모 모델 학습.<br>- **모델 서빙**: 수백/수천 개의 모델 서빙 API 컨테이너를 무중단으로 운영 및 확장.<br>- **ML 파이프라인 자동화**: Kubeflow, Argo와 같은 도구를 통해 k8s 위에서 전체 ML 파이프라인을 구축. |
### Docker와 Kubernetes는 어떻게 함께 사용되나요?
1.**개발 (Docker)**: 개발자는 자신의 로컬 머신에서 `Dockerfile`을 작성하여, Python 버전, CUDA 버전, 라이브러리 등이 모두 포함된 **ML 개발 환경 이미지**를 만듭니다.
2.**패키징 (Docker)**: 학습이 완료된 모델과 예측을 수행하는 API 서버 코드를 **하나의 Docker 이미지로 패키징**합니다.
3.**배포 (Kubernetes)**: 운영팀은 이 Docker 이미지를 **Kubernetes 클러스터에 배포**합니다. Kubernetes는 사용자 요청에 따라 이 이미지를 여러 서버에 자동으로 분산시키고, 트래픽을 분산(로드 밸런싱)합니다.
4.**운영 및 확장 (Kubernetes)**: 특정 모델에 대한 요청이 급증하면, Kubernetes는 해당 모델의 컨테이너 수를 **자동으로 늘려(Auto-scaling)** 안정적인 서비스를 보장합니다. 특정 서버에 장애가 발생하면, 다른 서버에 컨테이너를 **자동으로 다시 시작(Self-healing)** 시켜 서비스 중단을 방지합니다.
### 선택 가이드 (When to use what?)
-**`Docker`만으로 충분한 경우:**
- 개인 연구자나 소규모 팀이 **개발 환경의 일관성**을 맞추고 싶을 때.
- 모델을 **단일 서버**에 배포하여 소규모 트래픽을 처리하는 경우.
- 복잡한 온라인 서빙보다는, 배치(Batch) 예측 작업을 컨테이너화하여 실행하는 경우.
-**`Kubernetes`까지 필요한 경우:**
-**여러 서버(노드)에 걸쳐 대규모 분산 학습**을 수행해야 할 때.
-**높은 가용성(High Availability)**과 **무중단 배포**가 필수적인 프로덕션 환경에서 모델을 서빙할 때.
-**수십, 수백 개 이상의 다양한 모델**을 동시에 서비스하고 관리해야 할 때 (Multi-tenant serving).
-**Kubeflow, Argo Workflows** 등 Kubernetes 네이티브 MLOps 도구를 활용하여 전체 머신러닝 파이프라인을 자동화하고 싶을 때.
**결론:**`Docker`는 **'어디서든 동일하게 실행되는 환경'**을 만드는 **'포장 기술'**이고, `Kubernetes`는 이렇게 포장된 수많은 박스들을 **'자동으로 관리하고 지휘하는 거대한 물류 시스템'**과 같습니다. 대부분의 ML 프로젝트는 `Docker`로 시작하여 개발 및 실험의 재현성을 확보하고, 프로젝트가 성숙하여 **'확장성'과 '안정성'** 이라는 프로덕션 요구사항에 직면했을 때 `Kubernetes`를 도입하게 됩니다.
