OREILLY Introducing MLOps 도입가이드 를 공부하면서 정리 내용입니다.
현재 모든 기업이 AI 프로젝트를 결쟁적으로 도입 하고 있으나 이중 50 ~85% 가 실패 (격하게 공감…) 한다고 합니다. 주요 실패 원인은 아래와 같다고 저역시 비슷한 느낌을 경험하였습니다.
- 불명확한 비즈니스 목표 : 단지 유행이기 때문에, 혹은 뒤쳐지면 안되다는 조급함 때문에 뛰어들어 비즈니스 목표를 설정하지 않고 단순 평가를 수행 함
- 부실한 데이터 품질 : IT 혹은 데이터에 투자하지 않고 단지 AI 머신러닝만 도입 하려고 함
- 조직 간 협력 부족 (제일 공감) : 데이터 과학자가 모든 것을 해결할 수 있다고 포장하거나 비즈니스 담당자가 명확한 커뮤니케이션 없이 수의 계약 형태로 일을 진행 하도록 함
- 뛰어난 인력 부족 : AI 프로젝트가 운영화에 도달하고 지속적으로 운영을 수행할 수 있으려면 비즈니스 담당자가 데이터 분석과 AI를 이해할 수 있도록 지원 해야 함. 그러러면 다양한 실험을 수행하고 방향을 제시할 수 있는 뛰어난 데이터 과학자를 고용해야 하는데, 이러한 인력이 없는 경우 허술한 결과를 내고 조직에 불신만 심어주어 다시는 AI 프로젝트를 시도할 수 없게 됨
MLOps 는 이를 해결할 수 있는 방안이 된다고 합니다. (MLOps 를 만병통치약처럼 과장할 필요도 없지만 마케팅 차원의 일시적 유행으로 치부해서도 안됨)
Part1. MLOps 개념과 필요성
조직 내 머신러닝 모델 생애주기에 대한 도식화 입니다.
MLOps 와 DevOps 공통점이 많은데, 그렇다고 DevOps 담당자를 데이터 사이언스 팀으로 즉시 전환 배치할 수는 없습니다. 그리고 소프트웨어 코드를 상용 배포하는 것과 머신러닝 모델을 사용 배포하는 것은 근본적인 부분에서 차이가 있습니다. - 소프트웨어 코드는 비교적 정적이지만, 데이터는 항상 변함 ( 모델애 대한 CI / CD 가 필요함). 이처럼 머신러닝 모델이 코드와 데이터를 모두 포함한다는 점을 비롯한 여러 환경적 복잡성으로 인해 MLOps 는 새롭고 독특한 원칙이 되었습니다.
책임 있는 AI
모델을 상용 환경에 배포하는 작업은 머신러닝 모델 생애주기의 최종 단계는 아닙니다. 단지 성능과 정상 작동 여부를 확인하는 시작점이 될 뿐입니다. 더 많은 데이터 과학자가 더 많은 머신러닝 모델을 사용ㅇ 환경에 배포할수록, MLOps 는 비즈니스에 치명적일 수 있는 잠재적 리스크를 줄이는 데 필수적인 요소가 됩니다. 모델이 조직 내에서 얼마나 광범위하게 사용되는지 정확하게 확인하기 위해서는 MLOps 를 기반으로 한 모니터링이 필수적입니다.
머신러닝의 책임 있는 Responsible 사용에는 두 가지 영역이 존재합니다.
- 의도 (Intentionality)
- 모델이 목적에 맞게 설계되고 작동하도록 보장하는 것을 의미 함
- 설명 가능성 Explainability 이란 속성을 포함함으로 AI 시스템의 결과물을 인간이 설명할 수 있도록 해야 함. 이상적으로는 시스템을 제작한 사람뿐 아니라 그 외의 사람들도 설명할 수 있어야 함 (현재 가장 절실하게 느끼는 부분 + 가장 업무 난이도가 높은 부분)
- 책무 (Accountability)
- 기업 내 모든 AI 업무에 대한 중앙 통제 및 관리, 감사를 의미
- 어느 팀이 어떤 데이터를 어떻게 어느 모델에서 사용하는지를 전반적으로 파악 (어느 모델이 어떤 비즈니스 프로세스에서 사용되는가를 중앙 집중식으로 이해 → 추적성 Traceability 와 밀접한 연관 )
- 무언가 잘못되었을 때, 파이프라인의 어느 지점에서 어떤 이슈가 발생하는지 쉽게 찾을 수 있어야 함
머신러닝 모델은 전통적인 명령형 코드에 비해서는 투명성이 부족하난 점을 감안해야 합니다. 즉, 예측 결과를 결정하는데 사용하는 특성들 Features 이 무엇인지 파악히가가 어렸기 때문에 모델이 준수해야 하는 규제나 내부 규정에 적합하다고 입증하기도 대단히 어렵습니다.
이러한 이유로 머신러닝 모델에 대한 자동화를실제로 도입할 때 책무 Accountability 를 지는 역할은 조직의 하위에서 상위로 이동합니다. 즉, 과거에는 각각의 업무 담당자가 내리던 결정 (예를 들면, 상품 가격을 결정한다든가 누군가에게 대출을 진행해도 될지 결정하는 것)을 모델이 내리고, 이 결정에 대한 책임은 데이터 팀의 관리자 혹은 임원이 져야 합니다. 이 때문에 책임 있는 AI 의 개념은 더욱 전면으로 부각됩니다.
MLOps 이해관계자들
| 역할 | 머신러닝 모델 생애주기 내의 역할 | MLOps 요구사항 |
|---|---|---|
| 직무 전문가 SME (Subject Matter Expert) | - 머신러닝 모델이 다뤄야 하는 비즈니스 질의, 목표 혹은 KPI 제안 - 모델 성능이 요구사항에 적합하도록 혹은 요구사항을 해결하도록 지속적으로 평가 및 검증 | - 비즈니스 측면에서 모델 성능을 쉽게 이해 할 수 있는 방법 ( Explainability 에 대한 기능 제공 - 모델별 다른 방법) - 비즈니스 요구사항에 맞지 않는 모델의 결과를 표시하기 위한 도구 혹은 피드백 루프 (Feedback Loop) |
| 데이터 과학자 | - 직무 전문가가 제기한 비즈니스 질의 혹은 요구사항을 해결하는 모델 구출 - 상용 환경에서 상용 데이터로 작동할 수 있게 운영 가능한 모델 제공 - 직무 전문가와 협력하여, 최초의 모델 및 이후의 테스트 모델들 품질이 최초의 비즈니스 요구사항에 적합한지 평가 | - 상용 배포를 빠르고 쉽게 안전하게 수행할 수 있는 자동화된 패키징 및 상용 배포 기능 (모델 배포 과정 process화) - 배포한 모델의 품질을 판단하고 지속적으로 개선하기 위한 테스트를 개발하는 기능 (모델 테스트 방법론) - 하나의 중앙 집중화된 위치에서 배포된 모든 모델의 성능을 확인할 수 있는 가시성 (모델 성능 확인 & 모델간 결과 비교) - 모델의 최초 구축자가 누구든 상관없이 빠르게 측정하고 조정할 수 있는, 각 모델의 데이터 파이프라인 조사 가능 (모델링 파이프라인 모니터링) |
| 데이터 엔지니어 | - 머신러닝 모델에 공급하는 데이터의 취합 (Retrieval) 및 사용 (Use) 최적화 | - 배포된 모든 모델의 성능을 확인할 수 있는 가시성 - 데이터 파이프라인의 이슈를 해결하기 위해 개별 파이프라인에 대한 세부 사항을 확인 할 수 있는 기능 |
| 소프트웨어 엔지니어 | - 머신러닝 모델을 회사의 애플리케이션 및 시스템에 통합 - 머신러닝 모델이 비머신러닝 기발 애플리케이션과 원활히 작동하도록 보장 | - 버전 관리 및 자동화된 테스트 (버저닝 관리 프로세스, Regression 테스트 방법화) - 동일 애플리케이션에 대한 동시 작업 지원 |
| DevOps | - 운영체제를 관리하고 개발하며, 보안/성능/가용성 관련 테스트 수행 - 지속적 통합 (Continuous Integration, CI) / 지속적 전달 (Continuous Delivery, CD) 파이프라인 관리 | - 기업에서 더 높은 단계의 DevOps 전략에 원활히 통합할 수 있는 MLOps (DevOps 방법 또는 플랫폼이 변경되어도 대응 가능하도록 파이프라인 구조화) - 끊김 없는 배포 파이프라인 |
| 모델 리스크 관리자 / 감리인 | - 상용 배포한 머신러닝 모델들에 의한 전체 리스크 최소화 - 머신러닝 모델을 상용 배포하기 전에 내/외부 요구사항을 준수했는지 검증 | - 현재 혹은 지금까지 상용 배포된 모든 모델과 데이터 출처까지 포함하는 데이터 파이프라인 전체에 대한 견고하고 자동화된 리포팅 도구 |
| 머신러닝 아키텍트 | - 설계부터 개발 및 모니터링까지 포함하는 확장 가능하고 유연한 머신러닝 모델 파이프라인 환경 확보 - 상용 환경에서 머신러닝 모델의 성능을 개선할 수 있는 새로운 기술 도입 | - 모델들과 모델들의 자원 소모에 대한 고수준의 개괄적인 현황 확인 가능 - 인프라 환경을 검증하고 조정하기 위한 데이터 파이프라인들의 세부 사항 확인 가능 |
Uploaded by N2T