MLOps란, Kubeflow

클라우드/DevOps

MLOps란, Kubeflow

dayeonsheep 2025. 3. 23. 18:35

DevOps 관심 + 이번학기 ML 배움 + AI/ML 스킬의 요구가 전반적으로 늘어남

= MLOps를 공부해 보자~

1. MLOps의 개념

머신러닝 모델의 개발, 배포, 운영, 유지보수를 자동화하고 최적화하는 프로세스
소프트웨어 개발에서 DevOps가 개발과 운영을 연결하는 것처럼, MLOps는 머신러닝 모델의 전체 수명 주기를 관리하여 신뢰성과 재현성을 높이는 것을 목표
- 머신러닝 모델 개발(ML Dev)과 머신러닝 모델 운영(Ops)의 격차를 최소화(통합)하고 빠르고 효율적으로 비즈니스 가치를 창출하는 것이 목표
프로덕션 환경에서 머신러닝 모델을 안정적이고 효율적으로 배포 및 유지 관리하는 것을 의미

MLOps는 크게 ML(학습) 단계와 Ops(운영) 단계로 나눌 수 있습니다.
- ML 단계: 데이터 수집, 전처리, 모델 구축, 학습, 평가 등
- Ops 단계: 모델 배포, 모니터링, 테스트 등
- MLOps는 머신러닝 엔지니어링, 데이터 엔지니어링, 클라우드, 인프라 등을 모두 포함

https://jaemunbro.medium.com/mlops%EA%B0%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B3%A0-84f68e4690be

[MLOps란] MLOps가 무엇인고?

MLOps의 정의, 그리고 ML Lifecycle에 대해 알아보자

jaemunbro.medium.com

2. DevOps와의 통합

MLOps는 DevOps의 원칙을 머신러닝에 적용하여 코드뿐만 아니라 데이터와 모델의 관리까지 포함

DevOps와의 통합은?
- CI/CD 파이프라인: 머신러닝 모델을 지속적으로 통합하고 배포하는 자동화된 파이프라인 구축
- 버전 관리: 코드뿐만 아니라 데이터 및 모델의 버전 관리
- 모니터링 및 피드백 루프: 모델의 성능을 지속적으로 모니터링하고 개선

모델이 작업을 충분히 빠르게 처리하는지, 적절한 용량의 메모리와 CPU 처리 시간을 사용하고 있는지 등을 체크
상용 환경에서 모델을 재학습시켜야 한다면, 컴퓨팅 자원의 확장성은 중요한 고려사항
특히 딥러닝 모델은 단순한 의사결정 트리보다 훨씬 많은 자원을 필요로 함
DevOps팀이 이미 보유하고 있는 모니터링과 자원 관리에 대한 전문 역량을 머신러닝 모델에도 적용할 수 있음

MLOps와 DevOps의 차이점

DevOps는 개발 팀과 운영 팀 간의 격차를 해소하는 것을 목표로 합니다.
- DevOps는 코드 변경 사항이 자동으로 테스트되고 통합되어 효율적이고 안정적으로 프로덕션에 배포되도록 지원합니다.
- 협업 문화를 장려하여 릴리스 주기를 단축하고 애플리케이션 품질을 개선하며 리소스를 보다 효율적으로 사용할 수 있도록 합니다.
반면 MLOps는 기계 학습 프로젝트를 위해 특별히 설계된 일련의 모범 사례입니다.
- 기존 소프트웨어를 배포하고 통합하는 것은 비교적 간단할 수 있지만 ML 모델은 고유한 과제를 안고 있습니다.
- 여기에는 데이터 수집, 모델 훈련, 검증, 배포, 지속적인 모니터링 및 재훈련이 포함됩니다.
- MLOps는 ML 수명 주기 자동화에 중점을 둡니다. 모델을 개발하는 데 그치지 않고 체계적이고 반복적으로 배포, 모니터링 및 재훈련하는 데 도움이 됩니다.
  - 이는 ML에 DevOps 원칙을 가져옵니다.
MLOps를 사용하면 ML 모델을 더 빠르게 배포하고 시간이 지남에 따라 정확도가 향상되며 실제 비즈니스 가치를 제공한다는 확신을 강화할 수 있습니다.

https://aws.amazon.com/ko/what-is/mlops/

MLOps란?- 기계 학습 운영 설명 - AWS

기계 학습은 조직이 데이터를 분석하고 의사 결정을 위한 인사이트를 도출하는 데 도움이 됩니다. 그러나 이는 혁신적이고 실험적인 분야로 나름의 과제를 안고 있습니다. 민감한 데이터 보호,

aws.amazon.com

3. MLOps vs AIOps vs LLMOps

구분	MLOps	AIOps	LLMOps
목적	머신러닝 모델 개발 및 운영 자동화	IT 운영에서 AI 기반 모니터링 및 문제 해결	대규모 언어 모델(LLM)의 학습, 배포, 운영 관리
주요 초점	데이터 관리, 모델 배포, 성능 모니터링	시스템 이상 탐지, 자동 복구	LLM의 지속적 학습, 모델 성능 최적화
활용 분야	예측 모델, 추천 시스템	IT 인프라 모니터링, 네트워크 보안	챗봇, AI 콘텐츠 생성

MLOps는 관리에서 유지 보수까지 머신 러닝 모델의 수명 주기에 초점을 맞추며, 안정적인 방식으로 ML 이니셔티브를 확장해야 하는 기업에 가장 적합한 접근 방식
- 머신 러닝 모델의 종단 간 수명 주기를 관리하고 효율적으로 배포하고 지속적으로 모니터링할 방법에 적합
AIOps는 작업 자동화, 이상 감지, 시스템 성능 최적화를 담당하므로 IT 인프라를 개선하려는 조직에 적합
- 문제 발생 시 성능에 영향을 미칠 수 있으므로 IT 운영을 자동화하고 시스템 관찰력을 높이는 것이 목표에 적합
LLMOps는 대규모 언어 모델의 배포와 최적화에 맞춰 설계되어 확장성, 성능 및 리소스 관리 측면에서 고유한 요구 사항을 해결하므로 고급 NLP 애플리케이션이 포함된 프로젝트에 필수적
- 대규모 언어 모델을 작업 중이고 성능과 확장성을 최적화하는 데 중점을 두고 있는 경우, 특히 리소스 집약적인 NLP 작업인 경우

https://neptune.ai/blog/mlops-vs-aiops-differences

MLOps vs AIOps – What's the Difference?

Comparing MLOps and AIOps, a detailed distinctions and insights into selecting the right MLOps architecture.

neptune.ai

https://www.nscale.com/blog/aiops-vs-mlops-vs-llmops-choosing-the-right-ai-operations-strategy

AIOps vs. MLOps vs. LLMOps: Choosing the right AI operations strategy | Nscale

Dive into the key differences between AIOps, MLOps, and LLMOps and understand their unique roles within AI operations. Follow our blog for more insights from Nscale.

www.nscale.com

4. MLOps Workflow

데이터 수집 및 준비: 데이터 정제, 변환, 증강
모델 개발: 실험, 하이퍼파라미터 튜닝, 검증
모델 배포: API 또는 컨테이너를 이용한 배포
모델 모니터링: 성능 저하 감지, 데이터 드리프트 확인
모델 재학습 및 유지보수: 지속적인 개선 및 업데이트

단계별 MLOps (google의 단계 분할)

MLOps level 0: Manual Process

출처 : https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning?hl=ko

데이터 추출과 분석, 모델 학습, 검증을 포함한 모든 단계가 수동
- ML과 Operation간 disconnection : 데이터 사이언티스트가 모델을 아티팩트로 전달하고, 엔지니어가 low latency로 프로덕션 환경에 배포. training-serving skew가 발생할 수 있다.
- Infrequent release iteration : 새 모델 버전의 배포가 비정기적으로 발생한다.
- No CI : 변경이 많지 않으므로 CI가 고려되지 않는다. 스크립트 수행이나 노트북에서 개인적으로 테스트를 수행한다.
- No CD : 배포가 자주 없으므로 CD까지 필요하지 않다.
- Active performance monitoring의 부재 : 로그나 모델의 예측 성능 등을 모니터링하지 않는다. 모델의 성능이 저하되거나 모델이 이상동작 하는 것을 감지할 수 없다.

도전 과제(모델의 정확도를 프로덕션 환경에서 유지하기 위해)
- 프로덕션 환경에서 모델의 품질을 모니터링 하여 성능 저하 및 모델 비활성을 감지해야 한다.
- 새로운 데이터 패턴이 포착(Data Shift)되면 최신 데이터로 모델을 재학습시켜야 한다.
- 특성 추출, 아키텍처, 하이퍼파라미터 등의 새로운 구현을 지속적으로 시도해야 한다.

MLOps level 1: ML pipeline automation
- ML 파이프라인을 자동화하여 모델을 지속적으로 학습시키는 것!

Level 1 의 특징들
- Rapid experiment : 실험을 빠르게 반복하고, 전체 파이프라인을 프로덕션으로 빠르게 배포
- 개발 환경에서 쓰인 파이프라인이 운영 환경에도 그대로 쓰임. DevOps의 MLOps 통합에 있어 핵심적인 요소
- 프로덕션 모델의 CT(Continuous Training) : 새로운 데이터를 사용하여 프로덕션 모델이 자동으로 학습
- CD: 새로운 데이터로 학습되고 검증된 모델이 지속적으로 배포됨.
- Level 0에서는 학습된 모델만을 배포했다면 Level 1에서는 전체 파이프라인이 배포됨.
CT를 위해 필요한 것들
- 새로운 데이터를 통해 새로운 모델을 지속적으로 학습하므로, data validation과 model validation이 필수적이다.
- 데이터 & 모델 검증
  - 데이터 검증: 모델 학습 전에 모델을 재학습 할 것인지 혹은 파이프라인 실행을 중지 할 것인지를 결정합니다.
    ex) 예상치 못한 데이터가 Input으로 들어온 경우, 데이터 패턴이 변경되었을 경우
  - 모델 검증: 새 데이터로 모델을 학습시킨 뒤, 해당 모델을 프로덕션에 올려보낼 것인지를 평가하고 검증합니다.
    ex) 오프라인 모델 테스트(정확도, 정밀도, 재현율, ...), 온라인 모델 테스트(A/B 테스트, ...) 등
- 특성 저장소(Feature Store): 학습과 서빙에 사용되는 feature들을 모아둔 저장소입니다. 특성 저장소는 다음과 같은 요소들로 구성되어 있습니다.
  - 원시 데이터를 처리 및 가공하여 feature를 생성합니다.
  - 생성된 feature를 저장합니다.(data warehouse)
  - feature의 메타정보를 저장합니다.(metadata storage)
  - 데이터 과학자가 feature에 쉽게 접근할 수 있는 API를 제공합니다.
- 메타데이터 관리: 재현성, 비교, 로깅 등을 위해 파이프라인을 실행할 때마다 다음과 같은 메타데이터를 기록합니다.
  - 실행된 파이프라인 & 구성요소 버전, 시간정보
  - 파이프라인 실행자
  - 매개변수 인수
  - 파이프라인의 각 단계에서 생성된 아티팩트에 대한 포인터(라인 중간중간의 기록을 남기기 위해)
  - 이전 모델에 대한 포인터(롤백이 필요한 경우를 위해)
  - 모델 평가 측정 항목(성능 비교를 위해)
- ML파이프라인 트리거

MLOps level 2: CI/CD pipeline automation
- Google은 Level 1에서 CI/CD면에서 집중적으로 강화된 시스템을 MLOps Level 2로 구분하고 있다.
- CI/CD 자동화 파이프라인의 단계는 다음과 같이 보여줄 수 있다.

CI/CD 자동화된 ML 파이프라인의 단계, 출처 : https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning?hl=ko

MLOps에서 말하는 자동화된 CI/CD의 대상은 DevOps와 같은 소스 코드이지만, 중점은 '학습 파이프라인'에 있습니다.

따라서 모델을 학습하는데 있어서 영향이 있는 소스코드 변화에 대해 실제로 모델이 정상적으로 학습이 되는지, 학습된 모델이 정상적으로 동작하는지 등을 확인합니다.

CI: 소스코드가 커밋되거나 공유저장소로 푸쉬될 때 빌드, 테스트, 패키징됩니다. CI에선 다음과 같은 테스트가 포함될 수 있습니다.
- 특성 추출 로직 테스트
- 모델 학습이 수렴하는지 테스트
- 모델에 구현된 메서드를 단위 테스트
- 모델 학습에서 0으로 나누거나 작은 값 또는 큰 값을 조작하여 NaN 값을 생성하진 않는지 테스트
- 파이프라인의 각 구성요소 간 통합을 테스트
CD: 새 파이프라인 구현을 지속적으로 배포하여 새 모델의 서비스를 Production에 전달합니다. 빠르고 안정적인 CD를 위해 다음 사항을 고려해야 합니다.
- 모델 배포 전 모델과 인프라의 호환성을 확인(패키지, 메모리, 컴퓨팅 자원 등)
- API 호출 테스트
- QPS 및 지연 시간과 같은 서비스 부하 테스트
- 예측 성능이 목표치를 충족하는지

https://velog.io/@whattsup_kim/MLOps%EB%9E%80

MLOps란?

MLOps란 무엇일까요?

velog.io

5. MLOps의 목표 및 이점

목표

머신러닝 모델의 재현성(reproducibility) 확보
자동화된 배포 및 운영을 통해 효율성 향상
모델의 신뢰성을 유지하며 지속적인 개선

이점

개발 속도 향상: 자동화된 파이프라인을 통해 모델 배포 속도 증가
운영 비용 절감: 최적화된 리소스 사용으로 비용 효율성 확보
데이터 및 모델의 품질 보장: 버전 관리 및 지속적인 모니터링을 통한 품질 유지

모델 수명 주기 관리: MLOps는 개발부터 배포까지 머신 러닝 모델의 전체 수명 주기를 효율적으로 관리합니다.
- MLflow 및 Kubeflow와 같은 도구는 모델 파이프라인에서 일관성과 안정성을 유지하는 동시에 각 ML 작업에 대한 메타데이터 추적을 제공
ML 파이프라인 자동화 : MLOps는 한 번의 클릭으로 ML 모델을 배포하거나 훈련하기 위한 파이프라인을 만들고 자동화할 수 있습니다.
- 여기에 CI/CD 프로세스 포함
확장성 및 보안 : MLOps는 클라우드 컴퓨팅 리소스를 활용하는 동안 보안 표준이 충족되고 유지될 수 있도록 보장할 뿐만 아니라 확장 가능한 배포를 위한 모델 패키징도 용이하게 함... 어떻게?
1. 컨테이너화(Containerization)로 확장성 확보
  - MLOps에서는 Docker 같은 컨테이너 기술을 활용하여 머신러닝 모델을 패키징합니다.
  - 모델과 그에 필요한 의존성(libraries, dependencies) 을 하나의 컨테이너 이미지로 만들 수 있음.
  - 컨테이너 기반 배포를 하면 어느 환경에서든 동일한 방식으로 실행 가능, 개발 환경과 운영 환경의 차이를 최소화할 수 있음.
  - Kubernetes와 같은 오케스트레이션 툴을 활용하면, 트래픽 증가에 따라 자동 확장(Auto Scaling) 이 가능.
2. 모델 서빙(Model Serving) 프레임워크 활용
  - MLOps는 모델을 효율적으로 배포하고 관리하기 위해 전문적인 서빙 솔루션을 활용함.
  - KFServing(KServe), TensorFlow Serving(TFServing), Triton Inference Server 같은 서빙 솔루션을 활용하면, 모델을 여러 개의 엔드포인트로 배포 가능
  - A/B 테스트 및 Canary Deployment(점진적 배포) 가능
  - GPU 가속 및 고가용성 유지 가능
3. CI/CD 파이프라인을 활용한 보안 강화
  - MLOps는 DevOps의 CI/CD 개념을 적용하여 보안성을 유지하면서 모델을 안정적으로 배포할 수 있도록 함.
  - 모델을 패키징한 후 배포하기 전에 자동 테스트(Automated Testing) 및 보안 스캔(Security Scan) 을 수행
  - AWS SageMaker Pipelines, GitHub Actions, Jenkins 등과 연계하여 자동화된 검증 및 배포 가능
  - Role-Based Access Control(RBAC), API 인증 등과 연계하여 보안 표준 준수
4. IAM & 데이터 보안 정책 적용
  - MLOps 환경에서는 클라우드 네이티브 보안 정책을 활용하여 모델과 데이터를 보호할 수 있음.
  - AWS IAM, Google Cloud IAM 등을 이용하여 모델 접근 권한을 세분화
  - 데이터 암호화(AWS KMS, Google Cloud KMS)를 적용하여 데이터 보안 유지
  - GDPR, HIPAA 등 보안 및 개인 정보 보호 규정을 준수하도록 모델을 패키징 및 배포
지속적인 개선 및 모니터링 : MLOps는 모니터링 및 실험을 통해 문제를 식별하고 해결하여 시간이 지남에 따라 더욱 정확하고 신뢰할 수 있게 만들 수 있습니다.
- 새로운 데이터에 대한 자동화된 retraining pipelines과 프로덕션 환경의 통찰력을 통합하기 위한 피드백 루프 구현을 통해 달성할 수 있다
버전 관리 및 재현성 : 팀은 MLOps 버전 관리 데이터 및 모델 지원을 통해 변경 사항을 추적하고 이전 버전으로 되돌릴 수 있습니다.
- DagsHub 또는 DVC와 같은 도구는 이 프로세스를 용이하게 하여 규정 준수 이유와 ML 실험에서 일관된 결과를 얻는 데 중요한 재현성과 책임을 보장합니다.
강력한 거버넌스 : MLOps는 데이터, 코드 및 모델이 적절하게 버전 관리되고 추적되도록 거버넌스 관행을 구현하여 복잡한 ML 스택에 대한 투명성을 높이고 실패 지점이나 규정 준수 실패를 더 쉽게 파악
협업 개선: Data Sciencetist 와 Ops 팀 간의 연결을 개선

6. MLOps에 활용되는 주요 툴

카테고리	툴	설명
데이터 버전 관리	DVC, MLflow	데이터와 모델의 버전 관리
모델 서빙	TensorFlow Serving, TorchServe, KServe	모델을 API로 배포
오케스트레이션	Kubeflow, MLflow, Metaflow	머신러닝 워크플로우 자동화
모니터링	Prometheus, Grafana, Evidently	모델 성능 모니터링 및 데이터 드리프트 감지
CI/CD	GitHub Actions, Jenkins, ArgoCD	모델 및 코드의 지속적 통합과 배포

https://roadmap.sh/mlops

MLOps Roadmap

Learn about MLOps using this roadmap. Community driven, articles, resources, guides, interview questions, quizzes for modern backend development.

roadmap.sh

0. Kubeflow란?

Kubeflow는 Kubernetes 기반의 ML 플랫폼으로, 머신러닝 모델의 개발, 배포, 운영을 자동화하고 최적화하는 데 도움을 주는 오픈소스

출처 : https://www.kubeflow.org/docs/started/architecture/

1. Kubernetes 네이티브

Kubeflow는 Kubernetes 위에서 실행되도록 설계되어 확장성(Scalability) 과 유연성(Flexibility) 을 제공합니다.

컨테이너 기반 환경에서 ML 워크로드를 실행할 수 있으며, 클러스터 내에서 리소스를 효율적으로 관리할 수 있습니다.

2. 엔드투엔드 ML 파이프라인 제공

Kubeflow는 머신러닝의 전체 수명 주기(End-to-End Lifecycle)를 자동화할 수 있는 Kubeflow Pipelines(KFP) 를 제공합니다.

이를 통해 다음과 같은 단계를 쉽게 관리할 수 있습니다.

데이터 준비
모델 훈련(Training)
하이퍼파라미터 튜닝
모델 서빙(Serving)
모니터링 및 재학습(Auto Retraining)

3. 다양한 ML 프레임워크 지원

Kubeflow는 TensorFlow, PyTorch, XGBoost, Scikit-learn 등 다양한 머신러닝 프레임워크와 호환됩니다.

각 프레임워크에 맞는 오퍼레이터(TFJob, PyTorchJob 등)를 제공하여 분산 훈련을 지원합니다.

4. Jupyter Notebook 통합

Kubeflow는 Jupyter Notebook 서버를 관리할 수 있는 기능을 내장하고 있어,

연구자와 데이터 과학자들이 클라우드 환경에서 쉽게 실험할 수 있도록 도와줍니다.

5. 모델 서빙 지원

훈련된 모델을 TFServing, KFServing(KServe), Seldon 등을 이용해 쉽게 배포하고 운영할 수 있습니다.

대규모 모델 배포 및 A/B 테스트가 가능해집니다.

6. Kubeflow Katib을 통한 자동화된 하이퍼파라미터 튜닝

Katib은 AutoML 기능을 제공하여, 머신러닝 모델의 최적의 하이퍼파라미터를 찾는 자동화된 실험을 수행할 수 있도록 도와줍니다.

7. Kubeflow의 주요 컴포넌트

Kubeflow Pipelines	머신러닝 워크플로우를 정의하고 자동화하는 도구
KFServing (KServe)	서빙 가능한 머신러닝 모델을 쉽게 배포하는 프레임워크
TFJob / PyTorchJob	TensorFlow 및 PyTorch 모델의 분산 훈련 지원
Katib	AutoML을 위한 하이퍼파라미터 튜닝 도구
Jupyter Notebook	클라우드에서 Jupyter Notebook 환경 제공

Kubeflow Spark Operator는 데이터 준비 및 기능 엔지니어링 단계에 사용할 수 있습니다.
Kubeflow Notebooks를 사용하면 모델을 개발하고 대화형 데이터 과학을 활용하여 ML 워크플로를 실험할 수 있습니다.
Kubeflow Katib은 다양한 AutoML 알고리즘을 사용하여 모델 최적화 및 하이퍼파라미터 튜닝에 사용할 수 있습니다.
Kubeflow Trainer는 대규모 분산 학습이나 LLM 미세 조정에 사용할 수 있습니다.
Kubeflow Model Registry는 ML 메타데이터와 모델 아티팩트를 저장하고, 프로덕션 서비스를 위한 모델을 준비하는 데 사용할 수 있습니다.
KServe는 모델 제공 단계에서 온라인 및 일괄 추론에 사용될 수 있습니다.
Feast는 기능 저장소로 사용할 수 있으며 오프라인 및 온라인 기능을 관리하는 데 사용할 수 있습니다.
Kubeflow Pipelines를 사용하면 ML 라이프사이클의 각 단계를 빌드, 배포 및 관리할 수 있습니다.

대부분의 Kubeflow 구성 요소를 독립형 도구 로 사용하여 기존 AI/ML 플랫폼에 통합할 수 있고, 전체 Kubeflow 플랫폼을 배포하여 종단 간 ML 라이프사이클에 대한 모든 Kubeflow 구성 요소를 얻을 수 있습니다.

8. Kubeflow의 장점과 단점

✅ 장점

Kubernetes 기반으로 확장성이 뛰어나고 대규모 모델 배포 가능
ML 파이프라인 자동화로 개발부터 배포까지 일관된 워크플로우 유지
다양한 ML 프레임워크 지원 및 하이퍼파라미터 튜닝 기능 제공
클라우드 네이티브 환경에서 실행 가능 (AWS, GCP, Azure 등과 호환)

❌ 단점

설치 및 설정이 복잡하여 Kubernetes에 대한 지식이 필요
완전한 Managed Service가 아니므로 운영 부담이 있음
작은 규모의 ML 프로젝트에서는 오버헤드가 클 수 있음

https://cloud.google.com/discover/what-is-kubeflow

cloud.google.com

https://www.samsungsds.com/kr/insights/kubeflow.html

쿠버네티스 기반의 AI 플랫폼: 쿠브플로우 Kubeflow | 인사이트리포트 | 삼성SDS

쿠브플로우는 엔드투엔드 End-to-End AI 플랫폼입니다. 머신러닝 워크플로우의 머신러닝 모델 학습부터 배포 단계까지 모든 작업에 필요한 도구와 환경을 쿠버네티스 Kubernetes 위에서 쿠브플로우

www.samsungsds.com

https://www.kubeflow.org/docs/started/architecture/

Architecture

An overview of Kubeflow's architecture

www.kubeflow.org

MLOps 스터디 하면서 추가 사항

각 필요한 단계들이 큰 분야라서 각 단계별로 특화해서 함

모델서빙, 워크플로우만 하거나, 배포 관심있으면 K8s + CNI

모델 이해 + DevOps = MLOps

GDPR, HIPAA 등 보안 및 개인 정보 보호 규정, data 거버넌스 얼마나 중요한지?

코드 유출은 괜찮아도 data유출은 절대 ㄴㄴㄴㄴ

신경쓰는 정도가 아니라 무조건!! 중요

그래서 퍼블릭 플랫폼 안 쓰는 경우도 많고, 직접 플랫폼 구축하거나 다 구매해서 깔거나 하는 경우도 O

금융권은 악착같이 자기구축 보안이 무진장 중요하니까는

kubeflow 이용할 수 있을지?

핸즈온에서 할거면 캐글 모델 정도 이용 + data 입히는 게 중요하지 어떤 data인지 별로 중요 X

스크래치로 파이프라인정도 만져보는 거 정도

모델 평가!! -> 가장 큰 차이이자 중요한 점인 것 같다

모델을 키우기 위한 중요한 요소는 모델을 평가하는거다

LLM -> MCP 핫하다

오픈 API가 제공하는 API가 다름. 프로토콜 자체가 호출하는 식이 아니라 연동하는 식

Azure를 많이 쓰는 이유?

여러 기업에서 많이 씀 -> 왜? Azure가 기업상대로 크레딧을 많이 뿌렸음(Aws경쟁) & OpenAI 제공 << 이게 크다 함

저작자표시 비영리 변경금지 (새창열림)