레이크하우스에서 MLOps 설계

Databricks는 수천 명의 고객이 머신러닝(ML)을 프로덕션에 도입할 수 있도록 지원해 왔습니다.
Shell은 160개 이상의 활성 AI 프로젝트를 통해 수백만 달러를 절약하고 있습니다.
Comcast는 MLflow를 사용하여 100개의 머신 러닝 모델을 쉽게 관리합니다.
그리고 다른 많은 사람들이 성공적인 ML 기반 솔루션을 구축했습니다.

Microsoft와 협력하기 전에는 많은 고객이 ML을 프로덕션에 도입하는 데 어려움을 겪었는데,
그 이유는 기계 학습 운영(MLOps) 이 까다롭기 때문입니다.
MLOps는 프로덕션을 향한 여정에서 코드(DevOps), 데이터(DataOps) 및 모델(ModelOps)을
공동으로 관리하는 것을 포함합니다. 우리가 목격한 가장 일반적이고 고통스러운 문제는
데이터와 ML 간의 격차이며, 종종 제대로 연결되지 않은 도구와 팀으로 나뉩니다.

이 문제를 해결하기 위해 Databricks Machine Learning 은 레이크하우스 아키텍처를
기반으로 하여 주요 이점인 단순성과 개방성을 MLOps로 확장합니다.

AWS 플랫폼은 DevOps, DataOps 및 ModelOps의 모범 사례를 통합하는
데이터 중심 워크플로를 정의하여 ML을 간소화합니다.
기계 학습 파이프라인은 궁극적으로 데이터가 여러 페르소나의
손을 통해 흐르는 데이터 파이프라인입니다.

데이터 엔지니어는 데이터를 수집하고 준비합니다.
데이터 사이언티스트는 데이터에서 모델을 구축합니다.
ML 엔지니어는 모델 메트릭을 모니터링합니다.
비즈니스 애널리스트는 예측을 검토합니다.

Databricks는 이러한 데이터 팀이 사일로 대신 단일 플랫폼에서
풍부한 데이터를 협업하고 관리할 수 있도록 하여 프로덕션 머신 러닝을 간소화합니다.
예를 들어, 우리의 특징점은 모델과 기능을 공동으로 생산할 수 있습니다:
데이터 사이언티스트는 ML 엔지니어가 더 간단한 프로세스로 모델을
배포할 수 있도록 필요한 기능을 "인식"하는 모델을 생성합니다.

MLOps에 대한 Databricks의 접근 방식은 업계 전반의 개방형 표준을 기반으로 합니다.
DevOps의 경우 Git 및 CI/CD 도구와 통합됩니다.
DataOps의 경우 개방형 고성능 데이터 처리를 위한 사실상의 아키텍처인
Delta Lake 와 레이크하우스를 기반으로 합니다.

ModelOps의 경우 모델 관리를 위한 가장 인기 있는
오픈 소스 도구인 MLflow를 기반으로 합니다.
개방형 형식 및 APIs 기반으로이 기반을 통해 고객은 다양한 요구 사항에 맞게
플랫폼을 조정할 수 있습니다. 예를 들어 MLflow 제품을 중심으로 모델 관리를
중앙 집중화하는 고객은 필요에 따라 기본 내장 모델 제공 또는 기타 솔루션을 사용할 수 있습니다.

이 블로그 게시물에서 MLOps 아키텍처를 공유하게 되어 기쁩니다.
공동 DevOps + DataOps + ModelOps의 과제에 대해 논의하고, 솔루션을 개괄하고,
참조 아키텍처를 설명합니다. 더 자세히 알아보려면 MLOps의 빅 북 을 다운로드하고
다가오는 Data+AI Summit 2022 에서 MLOps 강연 에 참석하세요.

코드, 데이터 및 모델을 공동으로 관리

MLOps는 ML 시스템의 안정적인 성능과 장기적인 효율성 이라는 두 가지 목표를 달성하기 위해
코드, 데이터 및 모델을 관리하는 프로세스 및 자동화 집합 입니다.
간단히 말해서 MLOps = DevOps + DataOps + ModelOps입니다.

개발, 준비 및 생산

비즈니스 또는 고객 대면 애플리케이션을 향한 여정에서 ML 자산(코드, 데이터 및 모델)은
일련의 단계를 거칩니다. 개발("개발" 단계), 테스트("스테이징" 단계) 및
배포("프로덕션" 단계)해야 합니다. 이 작업은 Databricks 워크스페이스와 같은
실행 환경 내에서 수행됩니다. 위의 모든 것(실행 환경, 코드, 데이터 및 모델)은
dev, staging 및 prod로 나뉩니다. 이러한 구분은 품질 보증 및 액세스 제어 측면에서
이해할 수 있습니다. 개발 중인 자산은 더 광범위하게 액세스할 수 있지만 품질이
보장되지 않습니다. 생산 중인 자산은 일반적으로 비즈니스에 중요하며,
테스트 및 품질을 가장 많이 보장하지만 수정할 수 있는 사람에 대한 엄격한 통제가 있습니다.

주요 과제

위의 요구 사항은 쉽게 폭발적으로 증가할 수 있습니다: 개발, 테스트 및 프로덕션, 여러 팀,
액세스 제어 및 여러 기술과 같은 복잡성을 사용하여 코드, 데이터 및 모델을 어떻게 관리해야 합니까?
우리는 이러한 복잡성이 몇 가지 주요 과제로 이어지는 것을 관찰했습니다.

운영 프로세스
DevOps 아이디어는 MLOps로 직접 변환되지 않습니다. DevOps에서는 실행 환경,
코드 및 데이터 간에 밀접한 관계가 있습니다. 예를 들어 프로덕션 환경은 프로덕션
수준 코드만 실행하고 프로덕션 수준 데이터만 생성합니다.
ML 모델은 모델 및 코드 수명 주기 단계가 비동기식으로 작동하는 경우가 많기 때문에
상황을 복잡하게 만듭니다. 코드 변경을 푸시하기 전에 새 모델 버전을 푸시할 수 있으며
그 반대의 경우도 마찬가지입니다. 다음과 같은 시나리오를 생각해 볼 수 있습니다.

• 사기 거래를 탐지하기 위해 매주 모델을 재훈련하는 ML 파이프라인을 개발합니다.
  코드를 분기별로 업데이트하지만 매주 새 모델이 자동으로 학습, 테스트 및 프로덕션으로
  이동됩니다. 이 시나리오에서는 모델 수명 주기가 코드 수명 주기보다 빠릅니다.
• 대규모 신경망을 사용하여 문서를 분류하기 위해 모델을 학습하고 배포하는 것은 비용 때문에
  일회성 프로세스인 경우가 많습니다. 그러나 다운스트림 시스템이 주기적으로 변경됨에 따라
  그에 맞게 제공 및 모니터링 코드를 업데이트합니다. 이 시나리오에서는 코드 수명 주기가
  모델 수명 주기보다 빠릅니다.

협업 및 관리
MLOps는 데이터 사이언티스트가 모델을 개발하고 유지 관리할 수 있는 유연성과 가시성을
갖추어야 하는 필요성과 ML 엔지니어가 프로덕션 시스템을 제어해야 하는 상충되는
요구 사항 사이에서 균형을 맞춰야 합니다. 데이터 사이언티스트는 프로덕션 데이터에서
코드를 실행하고 프로덕션 시스템의 로그, 모델 및 기타 결과를 확인해야 합니다.
ML 엔지니어는 안정성을 유지하고 때로는 데이터 프라이버시를 유지하기 위해
프로덕션 시스템에 대한 액세스를 제한해야 합니다. 이러한 요구 사항을 해결하는 것은
플랫폼이 단일 액세스 제어 모델을 공유하지 않는 여러 분리된 기술에서 함께 연결될 때
훨씬 더 어려워집니다.

통합 및 사용자 지정
ML을 위한 많은 도구는 개방형으로 설계되지 않았습니다.
예를 들어 일부 ML 도구는 JAR 파일과 같은 블랙박스 형식으로만 모델을 내보냅니다.
많은 데이터 도구는 ML용으로 설계되지 않았습니다. 예를 들어, 데이터 웨어하우스는
데이터를 ML 도구로 내보내야 하므로 스토리지 비용과 거버넌스 문제가 발생합니다.
이러한 구성 요소 도구가 개방형 형식 및 APIs기반으로 하지 않는 경우 통합 플랫폼에 통합할 수 없습니다.

레이크하우스를 통한 MLOps 간소화

MLOps의 요구 사항을 충족하기 위해 Databricks는 레이크하우스 아키텍처를 기반으로
접근 방식을 구축했습니다. 레이크하우스는 데이터 레이크와 데이터 웨어하우스의 기능을
단일 아키텍처로 통합하며, 두 가지 유형의 데이터 워크로드를 모두 지원하는 개방형 형식과
APIs 사용하여 이러한 간소화가 가능합니다. 마찬가지로 MLOps의 경우 개방형 데이터 표준을
기반으로 MLOps를 빌드하기 때문에 더 간단한 아키텍처를 제공합니다.

아키텍처 접근 방식에 대해 자세히 알아보기 전에 이를 개략적으로 설명하고 주요 이점을 강조합니다.

운영 프로세스
우리의 접근 방식은 DevOps 아이디어를 ML로 확장하여 코드, 데이터 및 모델에 대한
"프로덕션으로의 이동"이 의미하는 바에 대한 명확한 의미 체계를 정의합니다.
기존 DevOps 도구 및 CI/CD 프로세스를 재사용하여 ML 파이프라인의 코드를
관리할 수 있습니다. 기능 계산, 추론 및 기타 데이터 파이프라인은 모델 학습 코드와
동일한 배포 프로세스를 따르므로 운영이 간소화됩니다.

지정된 서비스인 MLflow 모델 레지스트리를 사용하면 코드와 모델을 독립적으로
업데이트할 수 있으므로 DevOps 메서드를 ML에 적용할 때 발생하는 주요 과제를 해결할 수 있습니다.

협업 및 관리
우리의 접근 방식은 data engineering, 탐색 Data Science, 프로덕션 ML 및 비즈니스 분석을
지원하는 통합 플랫폼을 기반으로 하며, 이 모든 것은 공유 레이크하우스 데이터 계층에 의해
뒷받침됩니다. ML 데이터는 다른 데이터 파이프라인에 사용되는 것과 동일한 레이크하우스
아키텍처에서 관리되므로 핸드오프가 간소화됩니다. 실행 환경, 코드, 데이터 및 모델에 대한
액세스 제어를 통해 적절한 팀이 적절한 수준의 액세스 권한을 얻을 수 있어 관리가 간소화됩니다.

통합 및 사용자 지정
우리의 접근 방식은 Git 및 관련 CI/CD 도구, Delta Lake 및 레이크하우스 아키텍처,
MLflow와 같은 개방형 형식 및 APIs기반으로 합니다. 코드, 데이터 및 모델은 개방형 형식으로
클라우드 계정(구독)에 저장되며 개방형 APIs있는 서비스에서 지원됩니다.
아래에 설명된 참조 아키텍처는 Databricks 내에서 완전히 구현할 수 있지만 각 모듈은
기존 인프라와 통합하고 사용자 지정할 수 있습니다.
예를 들어 모델 재학습은 완전히 자동화되거나, 부분적으로 자동화되거나, 수동일 수 있습니다.

MLOps에 대한 참조 아키텍처

이제 Databricks 레이크하우스 플랫폼에서 MLOps를 구현하기 위한 참조 아키텍처를 검토할
준비가 되었습니다. 이 아키텍처와 일반적으로 Databricks는 클라우드에 구애받지 않으며
하나 이상의 클라우드에서 사용할 수 있습니다. 따라서 이는 특정 요구 사항에 맞게 조정하기 위한
참조 아키텍처 입니다. 아키텍처 및 잠재적 사용자 지정에 대한 자세한 내용은 MLOps의 Big Book 을 참조하세요.

개요

이 아키텍처는 MLOps 프로세스를 개략적으로 설명합니다.
아래에서는 아키텍처의 주요 구성 요소와 ML 파이프라인을 프로덕션으로
이동하기 위한 단계별 워크플로에 대해 설명합니다.

구성 요소

우리는 몇 가지 주요 자산(실행 환경, 코드, 데이터 및 모델)을 관리하는 측면에서
접근 방식을 정의합니다. 실행 환경 은 코드에서 모델과 데이터를 만들거나
사용하는 곳입니다. 환경은 개발, 스테이징 및 프로덕션을 위한 Databricks
워크스페이스(AWS, Azure, GCP)로 정의되며, 워크스페이스 액세스 제어는
역할 분리를 적용하는 데 사용됩니다. 아키텍처 다이어그램에서 파란색,
빨간색 및 녹색 영역은 세 가지 환경을 나타냅니다.

환경 내에서 각 ML 파이프라인(다이어그램의 작은 상자)은
compute clusters 서비스(AWS, Azure, GCP)에서 관리하는
인스턴스에서 실행됩니다. 이러한 단계는 수동으로 실행하거나
워크플로 및 작업(AWS, Azure, GCP)을 통해 자동화할 수 있습니다.
각 단계에서는 미리 설치된 default 라이브러리(AWS, Azure,GCP)가 있는
ML용 Databricks Runtime 을 사용해야 하지만 사용자 지정 라이브러리
(AWS, Azure, GCP)를 사용할 수도 있습니다.

ML 파이프라인을 정의하는 코드는 버전 제어를 위해 Git에 저장됩니다.
ML 파이프라인에는 기능화, 모델 학습 및 튜닝, 추론 및 모니터링이
포함될 수 있습니다. 높은 수준에서 "ML을 프로덕션으로 이동"은
개발 분기에서 스테이징 분기(일반적으로 'main')를 통해 코드를
승격하고 프로덕션 사용을 위해 분기를 릴리스하는 것을 의미합니다.
DevOps와의 이러한 정렬을 통해 사용자는 기존 CI/CD 도구를
통합할 수 있습니다. 위의 아키텍처 다이어그램에서 코드를 승격하는
이 프로세스는 맨 위에 표시됩니다.

ML 파이프라인을 개발할 때 데이터 사이언티스트는 노트북으로
시작하여 필요에 따라 모듈화된 코드로 전환하여 Databricks
또는 IDE에서 작업할 수 있습니다. Databricks repo git 공급자와
통합하여 노트북 및 소스 코드를 Databricks 워크스페이스
(AWS, Azure, GCP)와 동기화합니다. Databricks 개발자 도구를
사용하면 IDE 및 기존 CI/CD 시스템(AWS, Azure, GCP)에서 연결할 수 있습니다.

데이터는 레이크하우스 아키텍처에 저장되며 모두 클라우드 계정에
저장됩니다. 기능화, 유추 및 모니터링을 위한 파이프라인은 모두
데이터 파이프라인으로 처리될 수 있습니다.

예를 들어 모델 모니터링은 원시 이벤트에서 대시보드에 대한
집계 테이블을 위한 점진적 데이터 구체화의 medallion 아키텍처를
따라야 query 합니다. 위의 아키텍처 다이어그램에서 데이터는
하단에 일반 "레이크하우스" 데이터로 표시되며 개발, 스테이징 및
프로덕션 수준 데이터로 구분됩니다.

default하면 가공되지 않은 데이터와 기능 테이블은 모두 성능 및
일관성 보장을 위해 Delta 테이블로 저장되어야 합니다.
Delta Lake 는 Databricks(AWS , Azure, GCP)에 최적화된
사용하여 정형 및 비정형 데이터를 위한 효율적인 개방형 스토리지
계층을 제공합니다.Delta Engine 특징점 테이블은 계보
(Delta AWS, Azure, GCP)와 같은 추가 메타데이터가 있는
테이블입니다. 원시 파일 및 테이블은 필요에 따라 부여하거나
제한할 수 있는 액세스 제어 하에 있습니다.

모델은 MLflow에 의해 관리되며, 이를 통해 Databricks 내부 및
외부의 모든 배포 모드에 대해 모든 ML 라이브러리의 모델을 균일하게
관리할 수 있습니다. Databricks는 액세스 제어, 수백만 개의 모델에 대한
확장성 및 오픈 소스 MLflow 의 상위 집합이 포함된 관리형 버전의
MLflow를 APIs 제공합니다.

개발 시 MLflow 추적 서버는 코드 스냅샷, parameter, 메트릭 및 기타 메타데이터
(AWS, Azure, GCP)와 함께 프로토타입 모델을 추적합니다.
프로덕션에서는 동일한 프로세스가 재현성 및 거버넌스에 대한 기록을 저장합니다.

CD(지속적인 배포)의 경우 는 MLflow Model Registry 모델 배포 상태를
추적하고 웹후크(AWS, Azure, GCP) 및 APIs (AWS, Azure, GCP)를 통해
CD 시스템과 통합 합니다. Model Registry 서비스는 코드 수명 주기와 별도로
모델 수명 주기를 추적합니다. 모델과 코드의 이러한 느슨한 결합은
코드 변경 없이 프로덕션 모델을 업데이트할 수 있는 유연성을 제공하며,
그 반대의 경우도 마찬가지입니다. 예를 들어 자동화된 재학습 파이프라인은
업데이트된 모델("개발" 모델)을 학습시키고, 테스트하고("스테이징" 모델),
배포("프로덕션" 모델)할 수 있으며, 이 모든 작업을 프로덕션 환경 내에서 수행할 수 있습니다.

아래 표는 코드, 데이터 및 모델에 대한 "개발", "스테이징" 및 "프로덕션"의 의미를 요약한 것입니다.

워크플로

위에서 설명한 아키텍처의 주요 구성 요소를 통해 이제 ML 파이프라인을 개발에서
프로덕션으로 전환하는 워크플로를 안내할 수 있습니다.

개발 환경: 데이터 사이언티스트는 주로 개발 환경에서 작업하며 기능 계산, 모델 학습, 추론,
모니터링 등을 포함할 수 있는 ML 파이프라인용 코드를 빌드합니다.

1. dev 분기 만들기: 새 파이프라인 또는 업데이트된 파이프라인은 Git 프로젝트의 개발 분기에서 프로토타입을 만들고 repo통해 Databricks 워크스페이스와 동기화됩니다.
2. 탐색적 데이터 분석(EDA): 데이터 사이언티스트 노트북, 시각화 및 Databricks SQL을 사용하여 대화형의 반복적인 프로세스로 데이터를 탐색하고 분석합니다.
3. 기능 테이블 refresh: 기능화 논리는 특징점 및 기타 레이크하우스 테이블에서 읽을 수 있고 특징점에 쓰는 파이프라인으로 캡슐화됩니다.
   기능 파이프라인은 특히 별도의 팀에서 소유하는 경우 다른 ML 파이프라인과 별도로 관리할 수 있습니다.
4. 모델 학습 및 기타 파이프라인: 데이터 사이언티스트는 읽기 전용 프로덕션 데이터 또는 수정된 데이터 또는 합성 데이터에서 이러한 파이프라인을 개발합니다.
   이 참조 아키텍처에서 파이프라인(모델이 아님)은 프로덕션으로 승격됩니다.
   필요한 경우 모델을 승격하는 방법에 대한 자세한 내용은 전체 백서를 참조하십시오 .
5. 커밋 코드: 새 ML 파이프라인 또는 업데이트된 ML 파이프라인은 소스 제어에 커밋됩니다.
   업데이트는 단일 ML 파이프라인 또는 한 번에 여러 파이프라인에 영향을 줄 수 있습니다.

스테이징 환경: ML 엔지니어는 ML 파이프라인이 테스트되는 스테이징 환경을 소유합니다.

6. 병합(끌어오기) 요청: 스테이징 분기(일반적으로 "기본" 분기)에 대한 병합 요청은
   CI(연속 통합) 프로세스를 트리거합니다.
7. 단위 테스트(CI): CI 프로세스는 먼저 데이터 또는 다른 서비스와 상호 작용하지 않는
   단위 테스트를 실행합니다.
8. 통합 테스트(CI): 그런 다음 CI 프로세스는 ML 파이프라인을 공동으로 테스트하는
   더 긴 통합 테스트를 실행합니다. 모델을 학습시키는 통합 테스트는 속도를 위해
   작은 데이터 또는 몇 번의 반복을 사용할 수 있습니다.
9. 병합: 테스트를 통과하면 코드를 준비 분기에 병합할 수 있습니다.
10. 절단 릴리스 분기: 준비가 되면 코드 릴리스를 잘라내고
    CI/CD 시스템을 트리거하여 프로덕션 작업을 업데이트하여 코드를 프로덕션에 배포할 수 있습니다.

프로덕션 환경: ML 엔지니어는 ML 파이프라인이 배포되는 프로덕션 환경을 소유합니다.

11. 기능 테이블 refresh: 이 파이프라인은 새로운 프로덕션 데이터를 수집하고 프로덕션 특징점
    테이블을 refresh . 예약, 트리거 또는 지속적으로 실행되는 배치 또는 스트리밍 작업일 수 있습니다.
12. 모델 학습: 모델은 전체 프로덕션 데이터에 대해 학습되고 MLflow Model Registry푸시됩니다.
    학습은 코드 변경 또는 자동화된 재학습 작업에 의해 트리거될 수 있습니다.
13. 지속적 배포(CD): CD 프로세스는 새 모델(Model Registry "stage=None")을 가져와서
    테스트하고("stage=Staging"을 통해 전환) 성공적으로 배포("stage=Production"으로 승격)합니다.
    CD는 Model Registry 웹훅 및/또는 자체 CD 시스템을 사용하여 구현할 수 있습니다.
14. 추론 및 제공: Model Registry의 프로덕션 모델은 처리량이 많은 사용 사례를 위한 배치 및
    스트리밍 작업과 짧은 대기 시간(REST API) 사용 사례를 위한 온라인 서비스 등 여러 모드로 배포할 수 있습니다.
15. 모니터링: 모든 배포 모드의 경우 모델의 입력 query 및 예측이 Delta 테이블에 기록됩니다.
    여기에서 작업은 데이터 및 모델 드리프트를 모니터링할 수 있으며 Databricks SQL 대시보드는
    상태를 표시하고 경고를 보낼 수 있습니다. 개발 환경에서 데이터 사이언티스트는 프로덕션 문제를
    조사하기 위해 로그 및 메트릭에 대한 액세스 권한을 부여받을 수 있습니다.
16. 재교육: 간단한 일정을 통해 최신 데이터에 대해 모델을 재학습하거나
    모니터링 작업을 통해 재학습을 트리거할 수 있습니다.

MLOps 아키텍처 구현

이 블로그를 통해 레이크하우스 패러다임을 기반으로 하는 데이터 중심 MLOps 아키텍처가 코드,
데이터 및 모델의 공동 관리를 간소화하는 방법을 이해할 수 있기를 바랍니다.
이 블로그는 필연적으로 짧고 많은 세부 사항을 생략합니다.
MLOps 아키텍처 구현 또는 개선을 시작하려면 다음을 수행하는 것이 좋습니다.

• 워크플로우 단계에 대한 자세한 내용과 옵션 및 사용자 지정에 대한 설명을 제공하는
  전체 ebook읽어보십시오. 여기에서 다운로드하십시오.
• 6월 27일부터 30일까지 MLOps에 대한 Data+AI Summit 2022 회담에 참석하세요.
  최고의 선택은 다음과 같습니다.
  • 고위급 회담
    • 2일차 오프닝 기조 연설: 공동 창립자와 제품 관리자가 DS 및 ML과 관련된
      오픈 소스 및 Databricks 프로젝트의 최신 비전과 로드맵을 공유합니다.
    • 레이크하우스의 ML: 데이터와 ML을 결합하여 AI 사용 사례 가속화:
      Databricks 제품 관리자 및 고객 개요 레이크하우스 아키텍처의 머신 러닝.
  • MLOps의 Databricks 심층 분석
    • Databricks의 MLOps: 방법 가이드: 이 블로그 게시물의 작성자는 ebook
      지침의 세부 정보를 설명하고 Databricks의 MLOps 프로세스를 시연합니다.
    • MLflow 파이프라인: 개발에서 프로덕션까지 MLOps 가속화:
      Databricks 엔지니어가 MLflow의 최신 혁신에 대해 자세히 설명합니다.
    • Databricks를 사용하여 프로덕션 ML 사용 특징점:
      Databricks 엔지니어가 특징점에 대해 자세히 설명합니다.
  • ML 플랫폼에 대해 논의하는 고객

     

    • Building and Scaling Machine Learning Based Products in the World's Largest Brewery (세계 최대 양조장에서 기계 학습 기반 제품 구축 및 확장)
    • DoorDash에서 Data Science 을 위한 레이크하우스 건설
• 요구 사항에 대한 논의를 안내하고, 이 참조 아키텍처를 프로젝트에 적용하고, 교육 및 구현에 필요한 리소스를 더 많이 활용할 수 있는 Databricks 계정 팀과 상담하세요.

MLOps에 대한 자세한 배경 정보는 다음을 수행하는 것이 좋습니다.

• 데이터 중심 ML 플랫폼 의 필요성 → 이 게시물에서는 MLOps와 데이터 중심의 필요성에
  대해 자세히 설명하고, 새로운 ML 기반 애플리케이션을 개발하는 데이터 팀의 구체적인
  예를 살펴봅니다.
• 기계 학습 플랫폼 선택을 위한 세 가지 원칙 → 이 게시물은 현재 게시물보다 한 단계 높습니다.
  ML 플랫폼을 위한 기술 선택에 대해 논의하고, 높은 수준의 지침을 제공하며, 관련 고객 사례를 인용합니다.
• 특징점 → 특징점에 대한 종합 안내서 는 그 자체로 전체 주제입니다.
  이 가이드에서는 자세히 설명합니다.