You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/kor/docs/introduction/intro.md
+61-22Lines changed: 61 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title : "1. What is MLOps?"
3
3
description: "Introduction to MLOps"
4
4
lead: ""
5
5
date: 2021-12-03
6
-
lastmod: 2021-12-13
6
+
lastmod: 2022-03-05
7
7
draft: false
8
8
weight: 101
9
9
contributors: ["Jongseob Jeon"]
@@ -29,46 +29,85 @@ menu:
29
29
30
30
그리고 몇 년이 지난 후 머신러닝과 딥러닝은 가능성을 입증해내어, 이제 사람들은 실제 서비스에 적용하고자 했습니다.
31
31
하지만 곧 많은 사람이 실제 서비스는 쉽지 않다는 것을 깨달았습니다.
32
-
****
33
32
34
-
## Before MLOps
33
+
## Devops
35
34
36
-
사람들은 머신러닝과 딥러닝을 일반적인 소프트웨어와 같은 시선으로 바라보고 기존과 같은 방식으로 운영하고자 했습니다.
35
+
MLOps는 이전에 없던 새로운 개념이 아니라 DevOps라고 불리는 개발 방법론에서 파생된 단어입니다. 그렇기에 DevOps를 이해한다면 MLOps를 이해하는 데 도움이 됩니다.
37
36
38
-
일반적인 소프트웨어에서는 어떤 문제가 발생하면 해당 부분을 담당한 소프트웨어 엔지니어가 문제의 원인을 진단하고 이를 해결한 후 다시 배포하는 프로세스를 거칩니다.
37
+
### DevOps
38
+
39
+
DevOps는 Development(개발)와 Operations(운영)의 합성어로 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말합니다.
40
+
DevOps의 목적은 소프트웨어 개발 조직과 운영 조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 합니다.
41
+
42
+
### Silo Effect
43
+
44
+
그럼 간단한 상황 설명을 통해 DevOps가 왜 필요한지 알아보도록 하겠습니다.
45
+
46
+
서비스 초기에는 지원하는 기능이 많지 않으며 팀 또는 회사의 규모가 작습니다. 이때에는 개발팀과 운영팀의 구분이 없거나 작은 규모의 팀으로 구분되어 있습니다. 핵심은 규모가 작다는 것에 있습니다. 이때는 서로 소통할 수 있는 접점이 많고, 집중해야 하는 서비스가 적기 때문에 빠르게 서비스를 개선해 나갈 수 있습니다.
47
+
48
+
하지만 서비스의 규모가 커질수록 개발팀과 운영팀은 분리되고 서로 소통할 수 있는 채널의 물리적인 한계가 오게 됩니다. 예를 들어서 다른 팀과 함께하는 미팅에 팀원 전체가 미팅을 하는 것이 아니라 각 팀의 팀장 혹은 소수의 시니어만 참석하여 미팅을 진행하게 됩니다. 이런 소통 채널의 한계는 필연적으로 소통의 부재로 이어지게 됩니다. 그러다 보면 개발팀은 새로운 기능들을 계속해서 개발하고 운영팀 입장에서는 개발팀에서 개발한 기능이 배포 시 장애를 일으키는 등 여러 문제가 생기게 됩니다.
다시 말해, 머신러닝 엔지니어와 소프트웨어 엔지니어들은 **모델(*Network 구조와 Weights가 담긴 파일*)** 을 매개체로 서로 소통했습니다.
51
-
머신러닝 엔지니어들은 DB에서 직접 쿼리를 이용해 데이터를 내려받고 모델을 학습 후, 학습된 모델을 소프트웨어 엔지니어에게 전달하였고, 소프트웨어 엔지니어는 전달받은 모델을 로드한 뒤, 정해진 추론(inference) 함수를 제공하는 API Server를 만들어 배포하였습니다.
69
+
이 방법을 통해서 개발팀에서는 운영팀의 환경을 이해하고 개발팀에서 개발 중인 기능이 정상적으로 배포까지 이어질 수 있는지 확인합니다. 운영팀은 검증된 기능 또는 개선된 제품을 더 자주 배포해 고객의 제품 경험을 상승시킵니다.
70
+
앞에서 설명한 내용을 종합하자면 DevOps는 개발팀과 운영팀 간의 문제가 있었고 이를 해결하기 위한 방법론입니다.
52
71
53
-
이 과정에서 소프트웨어 엔지니어는 안정된 서비스 개발 및 배포를 위해, 머신러닝 엔지니어에게 정해진 형식에 맞춰서 구현할 것을 요청합니다. 예를 들면 OS, 파이썬 버전, 사용한 패키지, 클래스 구조 등을 포함합니다.
72
+
## MLOps
54
73
55
-
소프트웨어 엔지니어와 머신러닝 엔지니어는 서로 어떤 환경에서 작업하는지 알지 못하기 때문에, 소통의 과정에서 미리 약속한 형식에서 하나라도 어긋난다면 배포와 성능 재현 문제가 발생합니다.
56
-
예를 들어서 개발 환경에서는 동작했던 코드가 실행 환경에서는 동작하지 않는다든지, 개발 환경과 같은 성능이 재현되지 않는 문제가 발생하게 됩니다.
74
+
### 1) ML+Ops
57
75
58
-
## After MLOps
76
+
MLOps는 Machine Learning 과 Operations의 합성어로 DevOps에서 Dev가 ML로 바뀌었습니다. 이제 앞에서 살펴본 DevOps를 통해 MLOps가 무엇인지 짐작해 볼 수 있습니다.
77
+
“MLOps는 머신러닝팀과 운영팀의 문제를 해결하기 위한 방법입니다.”
78
+
이 말은 머신러닝팀과 운영팀 사이에 문제가 발생했다는 의미입니다. 그럼 왜 머신러닝팀과 운영팀에는 문제가 발생했을까요? 두 팀 간의 문제를 알아보기 위해서 추천시스템을 예시로 알아보겠습니다.
79
+
80
+
#### Rule Based
81
+
82
+
처음 추천시스템을 만드는 경우 간단한 규칙을 기반으로 아이템을 추천합니다. 예를 들어서 1주일간 판매량이 가장 많은 순서대로 보여주는 식의 방식을 이용합니다. 이 방식으로 모델을 정한다면 특별한 이유가 없는 이상 모델의 수정이 필요 없습니다.
83
+
84
+
#### Machine Learning
85
+
86
+
서비스의 규모가 조금 커지고 로그 데이터가 많이 쌓인다면 이를 이용해 아이템 기반 혹은 유저 기반의 머신러닝 모델을 생성합니다. 이때 모델은 정해진 주기에 따라 모델을 재학습 후 재배포합니다.
87
+
88
+
#### Deep Learning
89
+
90
+
개인화 추천에 대한 요구가 더 커지고 더 좋은 성능을 내는 모델을 필요해질 경우 딥러닝을 이용한 모델을 개발하기 시작합니다. 이때 만드는 모델은 머신러닝과 같이 정해진 주기에 따라 모델을 재학습 후 재배포합니다.
MLOps에서는 **파이프라인**을 이용해 서로 소통합니다. 여기서 파이프라인이란 단순히 학습된 모델만이 아닌 모델에 종속된 모든 작업을 포함한 개념입니다.
96
+
위에서 설명한 것을 x축을 모델의 복잡도, y축을 모델의 성능으로 두고 그래프로 표현한다면 다음과 같이 복잡도가 올라갈 때 모델의 성능이 올라가는 상승 관계를 갖습니다. 머신러닝에서 딥러닝으로 넘어갈 머신러닝 팀이 새로 생기게 됩니다.
97
+
98
+
만약 관리해야할 모델이 적다면 서로 협업을 통해서 충분히 해결할 수 있지만 개발해야 할 모델이 많아진다면 DevOps의 경우와 같이 사일로 현상이 나타나게 됩니다.
99
+
100
+
DevOps의 목표와 맞춰서 생각해보면 MLOps의 목표는 개발한 모델이 정상적으로 배포될 수 있는지 테스트하는 것입니다. 개발팀에서 개발한 기능이 정상적으로 배포될 수 있는지 확인하는 것이 DevOps의 목표였다면, MLOps의 목표는 머신러닝 팀에서 개발한 모델이 정상적으로 배포될 수 있는지 확인하는 것입니다.
101
+
102
+
### 2) ML -> Ops
65
103
66
-
### Continuous Integration & Deployment
104
+
하지만 최근 나오고 있는 MLOps 관련 제품과 설명을 보면 꼭 앞에서 설명한 목표만을 대상으로 하고 있지 않습니다.
105
+
어떤 경우에는 머신러닝 팀에서 만든 모델을 이용해 직접 운영을 할 수 있도록 도와주려고 합니다. 이러한 니즈는 최근 머신러닝 프로젝트가 진행되는 과정에서 알 수 있습니다.
67
106
68
-
머신러닝 엔지니어는 데이터를 내려받고, 전처리를 수행하며, 모델을 생성하기까지의 모든 과정을 파이프라인의 형태로 작성하여 소프트웨어 엔지니어에게 전달하고, 소프트웨어 엔지니어는 전달받은 파이프라인에서 생성된 모델을 배포합니다.
69
-
머신러닝 엔지니어와 소프트웨어 엔지니어는 같은 파이프라인을 사용하기 때문에 언제 어디서나 같은 성능의 모델을 빌드하고 배포하는 것을 보장할 수 있게 됩니다.
107
+
추천시스템의 경우 운영에서 간단한 모델부터 시작해 운영할 수 있었습니다. 하지만 자연어, 이미지와 같은 곳에서는 규칙 기반의 모델보다는 딥러닝을 이용해 주어진 태스크를 해결할 수 있는지 검증(POC)를 선행하는 경우가 많습니다. 검증이 끝난 프로젝트는 이제 서비스를 위한 운영 환경을 개발하기 시작합니다. 하지만 머신러닝 팀 내의 자체 역량으로는 이 문제를 해결하기 쉽지 않습니다. 이를 해결하기 위해서 MLOps가 필요한 경우도 있습니다.
70
108
71
-
### Continuous Training
109
+
### 3) 결론
72
110
73
-
머신러닝 모델은 한 번 학습되어 뛰어난 성능을 보였던 모델이라고 하더라도, 시간이 지남에 따라 성능이 저하되는 경우가 자주 발생합니다. 학습 데이터가 충분히 일반적이지 않거나, 실제 배포 환경에서의 테스트 데이터의 분포가 변화하기도 하기 때문입니다.
74
-
이 때문에 최신 데이터를 이용해 모델 성능 하락의 원인을 분석하고, 새로운 모델을 개발하거나 재학습하여 성능을 다시 끌어올리는 작업은 자주 수행되어야 합니다. 기존과 같은 모델을 매개체로 하는 소통에서는 머신러닝 엔지니어가 수동으로 학습을 새로 진행한 뒤, 새로 학습된 모델을 소프트웨어 엔지니어에게 전달했다면, 잘 설계된 파이프라인을 사용하여 Continuous Training 프로세스를 자동화할 수 있습니다.
111
+
요약하자면 MLOps는 두 가지 목표가 있습니다.
112
+
앞에서 설명한 MLOps는 ML+Ops 로 두 팀의 생산성 향상을 위한 것이였습니다.
113
+
반면, 뒤에서 설명한 것은 ML->Ops 로 머신러닝 팀에서 직접 운영을 할 수 있도록 도와주는 것을 말합니다.
0 commit comments