빙글빙글 돕니다, MLOps Lifecycle

복잡한 것 같다고요? 그렇지 않습니다! 단지 거듭할 뿐입니다...

안녕하세요, 에디터 SA입니다. 처음 [AI, 더 쉽게]의 콘텐츠로 소개해 드렸던 내용, 혹시 기억나시나요? :) MLOp와 MLOps Lifecycle를 톺아보았었는데요. 아무래도 첫 주제이고 간략하게 소개해 드리다 보니, MLOps Lifecycle에 대한 상세한 설명을 해드리지 못해, 아쉬움이 있었어요. 혹시 기억이 가물가물하시다면, 한 번 보고 오세요!

▶ 머신러닝, MLOps와 MLOps Lifecycle 톺아보기

TEN에서는 MLOps Lifecycle을 차용하여 AI Pub과 Coaster를 위의 그림으로 설명하고 있어요

MLOps는 DevOps의 개념을 머신러닝에 도입한 방법론입니다. DevOps는 프로세스에 따라 개발, 운영하는 과정을 도식화하면, 원 또는 8자로 표현되는 사이클이 완성되는데요. MLOps도 DevOps의 개념을 도입하였으므로, 개발/학습/운영을 거듭하여 더 나은 머신러닝 아웃풋을 내는 과정을 그림으로 표현하면 Lifecycle을 그릴 수 있게 됩니다. 이 사이클을 따라 개발과 운영을 반복하게 되면서 더 나은 성과를 낼 수 있고요. 그러니, 머신러닝을 사업의 레벨에서 서비스로 구현한다면, MLOps는 꼭 필요한 방법이라 할 수 있습니다.

이번에는 MLOps Lifecycle에 대해 좀 더 파고들어 볼까 합니다. :) AI Lifecyle을 바탕으로, 데이터 사이언티스트, DevOps 엔지니어, IT로 구성된 협업 과정들이 어떤 순서로 진행되어야 하는지에 대해 설명하는 시간이 될 거예요. 물론 몇 개의 콘텐츠로 MLOps Lifecycle을 완벽히 이해하기에는 무리가 있겠지만, 그래도 전체 흐름을 더 선명하게 이해하실 수 있을 거예요. :D

[ 풀어야 하는 문제가 무엇인고? 데이터를 모아보자! ]

머신러닝을 위해 제일 먼저 해야 할 일은, 바로 문제가 무엇인지 ‘정의’하는 것입니다. 어떤 것을 해결하기 위한 모델을 만들 것인지 방향성이 정해지지 않으면, 어떤 데이터를 모으고 학습한 결과를 어떻게 산출할 것인지 정할 수 없으니까요. 문제를 정의하고, 어떤 데이터를 확보해야 할지 정하는 과정에서는 그것이 ‘가치’를 창출할 수 있는지도 고려해야 합니다. 저희 ‘주식회사 텐’이 미션으로 삼고 이야기하는, 세상을 ‘AI롭게’ 한다는 것이 바로 그 ‘가치’와 맥이 닿는 것이기도 해요. :) 이 과정을 통틀어 ‘비즈니스 이해’라는 이름으로 부르기도 합니다. 

문제를 정의하고, 어떤 데이터를 모아야 할 지도 정했다면, 이제 데이터를 ‘확보’해야 할 텐데요. 실제로 데이터를 확보하는 행동에 앞서, 어떻게 확보해야 할지, 그 방법 또는 방안을 정해야 합니다. 머신러닝에 필요한 데이터는 요새 언급되는 거대언어모델(LLM)이 아니더라도, 사람이 일일이 컨트롤할 수 없을 정도의 양인데요. @.@ 

그러니 데이터 확보 방안을 미리 준비해야만, 모델 학습에 필요한 데이터를 잘 관리할 수 있게 됩니다. 데이터를 수집 및 확보하고 나면, 데이터 연계 과정을 거치게 됩니다. 데이터 형태에 따른 정리, 가공의 과정이라 생각하시면 돼요. 이 과정에서 수집한 데이터셋이 계속 변하는 값인 경우는, 버전 관리 및 공유가 필요하겠지요.

이렇게 수집한 데이터를 바로 모델에 학습시킬 수는 없어요. 연계 과정을 거친 데이터셋에는, “일단 진행시켜!” 하고 수집된 수많은 데이터가 들쑥날쑥 존재하기 때문입니다. 정의한 문제에 맞게 모델이 학습하고 결과를 낼 수 있을지는, 수집한 데이터의 성향과 품질이 큰 영향을 미치기에, 수집된 데이터들을 탐색하고 가공하는 과정이 필요하게 됩니다.

‘데이터셋 탐색’은, 수집된 데이터가 어떻게 분포해 있는지 확인하는 과정입니다. 탐색 과정에는 데이터셋의 분포를 요약하고, 시각화해서 확인하고, 각 데이터에 대한 레이블이 필요하다면 데이터에 태그하는 단계를 거칩니다. 예를 들어, 수집한 데이터들이 ‘김치’에 대한 이미지라고 할 때, 수많은 과일 이미지 중 ‘배추김치’에 대한 이미지, ‘총각김치’에 대한 이미지, ‘동치미’에 대한 이미지들에 각각 레이블을 붙이고, 시각화하면, 이 데이터들이 어떻게 분포되어 있는지 파악하기 수월할 거예요. ‘배추김치’ 이미지가 23,950개 더 많이 확보되었구나. ‘갓김치’에 관련된 이미지는 적게 수집되었구나, 하고요. 그 결과 이 데이터들을 학습한 모델이 낼 결과를 예측해 볼 수도 있겠지요? :)

우리의 예시 속 '김치 판별 모델' 은 이 사진 속 '겉절이'를 '배추김치'로 분류할까요?

탐색을 거친 데이터셋을 기반으로 진행할 다음 단계는 ‘피처 탐색’입니다. 데이터의 어떤 속성(피처, Feature)이 중요한지 선별하는 작업인데요. 이 ‘피처’는 ‘칼럼’으로 판별하기도 합니다. 모델 학습, 통계 분석을 통해 피처 중요한 것과 아닌 것을 파악하고, 피처 간 연관성도 확인합니다. 다시 한번 ‘김치’ 를 이야기하자면, ‘배추김치’의 이미지를 판별할 때 가장 큰 영향을 줄 특성을 확인하는 것인데요. 재료의 형태가 될 수도 있고, 이미지에서 나타나는 김치의 모습 중 고춧가루가 덮이지 않은 면적이라든지 하는 색상의 부분일 수도 있을 거예요.

마지막으로 데이터 품질 관리의 기반이 되는, 데이터 검증 과정을 거치게 돼요. 데이터 검증은 테이블별 건수 검증, 코드 검증, 무결성 검증의 요건을 따라서 설계한 검증 쿼리를 개발해서, 그 결과를 모니터링하고 피드백하는 프로세스를 거치는 과정입니다. 앞서 이야기한 ‘김치’의 예를 다시 가져와 볼게요. 데이터 중에는 여러 가지 ‘김치’의 이미지가 포함되어 있을 텐데요. 이 중 ‘김치 제조 공장’의 로고 이미지(!!)가 들어 있다면 어떨까요? 만약 개발할 모델이 해결할 문제가 ‘김치 종류 판별’이라면, 이 로고 이미지는 도움이 되지 않는 이미지일 거예요. 

이렇게 데이터를 가공한 결과는 모델 설계, 개발에 영향을 줄 수 있습니다. 막상 데이터를 수집하여 가공하고 보니, 예상하지 못했던 데이터 분류나 성향이 발견되기도 하니까요. 또는 데이터의 양이 예측한 것보다 많을 수도 있습니다. 이런 데이터의 특성들은 모델에 영향을 직접 주게 됩니다.

[ 이런 모델은 어때? 모델은 맞게 학습되고 있는 건가? ]

수많은 데이터를 수집하고 모았습니다. 데이터를 인간이 일일이 수집하지 않음에도 불구하고, 분류하고 검증하는 과정에서 많은 고민이 필요한 단계였는데요. 이제 그 데이터를 기반으로 하여 어떻게 모델을 설계, 개발해야 합니다. 그러기 위해서는 먼저 ‘실험’이 필요한데요. “실험?”하고 의아해하실 분이 계실 수 있겠어요. 이 ‘실험’은 만족스러운 성능을 낼, 최적의 모델을 찾아가기 위한 실험입니다. :)

모델은 데이터, 학습 알고리즘, 하이퍼파라미터에 의해 결정되는데요. 이 세 가지를 바꿔가면서 문제 해결에 최적인 모델을 찾아가게 돼요. 이때 모델 실험 중 남은 추적 데이터들이 중요하게 활용됩니다. 실험을 거치면서 남게 되는 데이터와 이력을 잘 추적하고 관리해야, 실험에서 나온 결과치를 평가하거나, 오류를 추적하고 인사이트를 얻을 수 있겠지요? :) 따라서 실험마다 입력한 조건의 내용, 산출된 모델의 메타 정보, 실험 이력 등을 체계적으로 정리하여 남겨두어야 합니다. 실험은 최적의 모델을 찾을 때까지 계속 반복되므로, 실험 추적을 자동화하기 위한 도구를 사용하기도 합니다.

실험을 거쳐 최적의 모델을 찾아냈다면, 그 모델이 앞서 설정한 ‘문제’를 해결하기에 정말 적합한지 검증하는 과정을 거칩니다. 모델이 예측하여 내놓은 결과가 실제와 얼마나 정확하게 합치되는지, 그 결괏값은 얼마나 일반적(generalized)인지 확인합니다. 모델의 성능은 처리 성능, 추론 성능, 처리 성능 등으로 나누어 살펴볼 수 있습니다.

모델 개발에 참여하는 사람의 직무에 따라 다른 방향으로 중점을 두고 검증하게 되는데요. 데이터 사이언티스트(DS, Data Scientist)라면 모델의 ‘처리 성능’, 예를 들어 모델이 예측값을 계산해 내는 데 얼마나 시간이 소요되는지, 사용하는 컴퓨팅 자원은 얼마나 되는지 등을 중점적으로 보게 됩니다. 데이터 엔지니어(DE, Data Engineer)라면, 처리 시간, 처리 데이터양, 실패 유형 등 모델을 서비스로 배포하였을 때 얼마나 안정적으로 운영될 수 있을지를 더 살피게 되겠지요.

그 외에도, 모델의 정확도만으로 평가할 수 없는 모델의 다른 부분도 평가해야 할 텐데요. 이 과정을 ‘모델 해석’이라는 이름으로, ‘모델 검증’과 분리하여 진행하기도 합니다. 모델 해석은 다양한 분류 기준을 가지고 있고, 해석 방법도 다양합니다. 관련한 내용을 다루기에는 방대한 내용이므로, 기회가 되면 모델 검증과 해석에 대해 더 자세히 다뤄보도록 할게요.

[ 배포한 모델을 모니터링하고, 다시 데이터를 찾아서 ]

모델의 검증까지 마쳤다면, 개발, 학습한 모델을 세상에 공개할 차례입니다. ‘모델 배포’라고 부르는데요. 모델을 다른 애플리케이션에서 사용할 수 있도록 배포하거나, 모델 API를 제공하는 과정입니다.

모델을 배포했다고 해서 그 모델을 그대로 둘 수는 없습니다. 지속적인 모니터링과 관리가 필요하겠지요? AI 모델을 개발하는 것이 아니더라도, ‘개발’이라는 것은 으레, 배포 후에 예상하지 못한 문제나 성능에 대한 이슈가 생기기 마련이니까요. 머신러닝 모델도 이 문제에서 벗어날 수 없습니다. 모델 모니터링 과정에서 모델 성능이 하락한 것이 확인되면, 일반적으로 다음과 같은 원인 때문이라고 하네요. :)

- Data Drift (데이터 통계 변형)
- Schema Drift (데이터 스키마 변형)
- Data Skew (데이터 불균형)
- Concept Drift (비즈니스 목적 변형)

비즈니스 목적이 변경되는 경우를 제외하면, 대체로 데이터와 결부된 문제인데요. 이 지점에서, AI에서 데이터가 얼마나 중요한지, 그 중요성을 확인할 수 있다고 하겠습니다. 이 ‘데이터’ 문제를 추적해 보면, 모델 설계상의 오류가 있을 수도 있고, 수많은 데이터를 모델이 소화하기 위한 인프라 문제 등이 더 발견될 수도 있겠습니다. 

MLOps Lifecycle의 각 Step을 좀 더 자세히 알아보았습니다. 거대 AI 모델에 대한 개발이 주목받는 최근의 경향을 보았을 때, ‘문제’를 설정하고 데이터 수집 규모를 예측하는 과정에서, 인프라에 대한 고민도 중요할 것으로 보였습니다. 모델 학습과 개발, 배포 후 운영에 이르기까지 인프라를 마음껏 사용할 수 있다면 좋겠지만, 비용과 연계된 문제이기 때문에 현실적으로 어렵지요. 이때, AI Pub과 같은 MLOps 솔루션의 도움을 받을 수 있습니다. :)

AI Pub은 인프라에 특화된 솔루션으로, 한정된 인프라 자원을 모델에 할당하고, 인프라 자원의 가동률을 모니터링 할 수 있어, 추후 모델의 성능을 검증할 때도 유용한 솔루션이에요. 할당받은 모델 개발과 자원 활용의 문제를 동시에 고민하기에 머신러닝 모델을 개발하는 과정은 지난합니다. MLOps Lifecycle을 따라가며 그 어려움과 대단함을 느껴볼 수 있었어요. 다음 시간에도 쉽게 이해할 수 있는 AI 이야기로 다시 찾아뵙겠습니다. :D