기초부터 배우는 MLOps 이야기

이제는 ChatGPT, Bard, Stable Diffusion과 같은 모델이 일상속으로 스며들었습니다. 몇몇 모델들은 유료로 사용하고 있습니다. 이런 머신러닝 시대에서 여러분들이 비즈니스에 관심이 많다고 하면 만든 모델들을 서비스화시키고 싶다는 생각을 했을겁니다. 일반 소프트웨어 개발 방식을 그대로 머신러닝에 대입하면 생각보다 모델이 잘 돌아가지 않는다는 걸 알 수 있습니다. 해당 문제를 해결하기 위해서 구글, 마이크로소프트와 같은 글로벌 빅테크부터 네이버, 카카오와 같은 국내 기업들도 해결하기 위해 노력하고 있습니다. 서비스적 관점에서 머신러닝 모델을 배포하고 CI/CD까지 적용한 방식을 흔히 MLOps 라고 부릅니다. 그렇다면 이번에 구글이 공개한 MLOps 시초 논문을 살펴보도록 합시다.

구글이 공개한 MLOps 시초 논문 – Hidden Technical Debt in Machine Learning Systems

그 중 구글은 2015년에 “Hidden Technical Debt in Machine Learning Systems”라는 논문을 발표해 실제 머신러닝 시스템에 숨겨져 있는 소프트웨어적인 기술부채에 대해 언급했습니다.

해당 논문에서 머신러닝 시스템을 개발하고 배포하는 것은 비교적 빠르고 비용이 덜 들지만 머신러닝 시스템을 유지하는 것은 어렵고 비용이 많이 들어간다고 이야기합니다. 또한 시스템 유지에 들어가는 기술 부채들은 코드 리팩토링과 같은 코드 수준에서의 부채가 아닌 시스템적인 수준에서 작동하기 때문에 감지되기도 어렵습니다. 해당 문제를 하나씩 살펴보도록 하겠습니다.

머신러닝과 소프트웨어 개발 방식의 차이(Complex Models Erode Boundaries)

기존에 소프트웨어 개발에서는 캡슐화하고 모듈식으로 설계를 합니다. 모듈로 정리하게 된다면 코드 수준에서 개선이 용이하며 유지관리를 가능하게 만듭니다. 이걸 쉽게 이야기하면 데이터베이스를 정리하는 코드모듈이 따로 있고 웹페이지를 만드는 코드 모듈이 있다고 생각하시면 됩니다. 머신러닝은 어떨까요? 머신러닝은 데이터에 따라서 소프트웨어 로직이 달라지기 때문에 깔끔한 모듈화가 불가능합니다. 예를 들어서 우리가 모델을 학습한다고 진행했을 때 실험을 진행할 때는 Random number를 고정하는 방식을 사용했습니다. 현실 세계의 경우에 추가 학습을 진행하면 파라미터, 학습 설정, 샘플링 방식, 수렴 임계값과 같은 모든 내용이 바뀌게 됩니다. 그렇기에 소프트웨어 프로그래밍 형식으로 머신러닝에 대입하는 건 상당히 어렵습니다.

데이터 디펜더시(Data Dependencies Cost More than Code Dependencies)

소프트웨어 엔지니어링 환경에서 디펜더시는 코드가 복잡하거나 기술 부채가 쌓여서 생기는 문제였습니다. 머신러닝에서의 디펜더시는 코드 수준에서 일어나는 디펜더시도 있지만 데이터 기반으로 일어나는 디펜더시가 더 큰 문제입니다. 머신러닝에서의 코드 디펜더시는 컴파일러로 해결가능하지만 데이터 디펜더시는 기술 부채 쌓는건 비슷하지만 찾는 것부터 어렵습니다. 데이터 디펜더시가 생긴 이유는 몇몇 입력 데이터에서 변환된 신호가 학습을 할때마다 변화할 수 있기 때문입니다. 만일 이러한 입력 신호를 고정되게끔 바꿔버린다고 하면 다른 데이터에 영향을 줄 수 있습니다. 또한 데이터중에서 실제로 그다지 의미가 없는 데이터라 하더라도 마찬가지로 수정을 하면 머신러닝 시스템에 문제를 발생시킬 수 있습니다. 결국 머신러닝 시스템은 데이터에 영향을 받을 수 밖에 없는 시스템이기 때문에 데이터를 수정한다면 머신러닝 전체 시스템에 문제가 발생합니다.

피드백 순환루프(Feedback Loops)

실험실에서의 머신러닝은 고정된 벤치마크 데이터셋을 이용해서 실험합니다. 그러나 현실에서의 머신러닝은 데이터셋이 고정되어 있지 않습니다. 추천시스템으로 예를 들어 설명하면 여름 데이터셋을 이용해서 만든 머신러닝 모델은 여름에는 잘 작동하지만 계절이 변할 때 정확도가 점점 떨어지게 됩니다. 이를 위해 머신러닝 시스템은 피드백 순환루프를 만들어야 합니다. 더 큰 문제는 한 모델이 여러가지를 수행하는데 피드백을 받아 수정할때 다른 곳에도 영향을 미치는 것입니다. 이런 경우 모델이 문제가 발생하는 것을 알면서도 빠르게 모델 수정을 할 수 없게 되면서 시스템을 마비시킬 수 있습니다.

머신러닝의 안티 패턴들(ML-System Anti-Patterns)

실험실에서의 머신러닝은 추론과 학습이 실험의 대부분을 차지하지만 실제 머신러닝 시스템에서는 데이터 수집부터 모니터링까지 다양한 영역을 커버하고 있습니다. 그렇다보니 머신러닝 시스템에서 접착 코드가 남발하게 되어 이는 효율성에서 매우 떨어집니다. 또한 실험된 모델을 현실에 급하게 적용하다보면 파이프라인을 복잡하게 설계되면 추후에 문제가 발생할 때 처리하기 어려워집니다.

파이프라인이 꼬이고 접착 코드가 남발하면 개별 branch들을 많이 만들어서 실험하게 되고 branch가 많아지게 되면 이전 버전의 호환성 이슈로 비용을 크게 증가시킬 수 있습니다. 그밖에도 데이터가 어떤 타입으로 인코딩 되어있는지, 다양한 라이브러리를 사용해서 만드는 것은 추후 개선작업을 어렵게 만듭니다. 마지막으로 프로토타입을 만드는 것은 좋지만 프로토타입이 현실 세계와 동일하게 작동한다는 착각을 해서는 안됩니다.

설정 부채(Configuration Debt)

머신러닝은 다른 시스템과 달리 하이퍼 파라미터 설정이 필수적입니다. 이러한 설정값은 해당 feature를 사용하는지, 데이터를 어떤 방식으로 선택하고 사용하는지, 전처리 결과등을 설정합니다. 설정값들은 머신러닝 시스템에서 많은 영향을 끼치지만 실제 연구를 진행할 때 해당 설정값에 대한 검증이나 테스트를 진행하지 않는 경향이 있습니다.

현실에서 발생하는 변화들(Dealing with Changes in the External World)

앞서 설명한 것처럼 통제된 환경에서 만들어진 머신러닝과 현실세계의 머신러닝 시스템은 차이가 있습니다. 즉 외부 환경으로 인한 유지보수가 지속적으로 발생하고 특정 수치를 조정해야 할 때가 있으며 모니터링과 테스팅을 지속적으로 진행해줘야 합니다. 이를 해결하기 위해서는 자동으로 변화에 따라 대응하는 시스템을 만들어야 합니다.

위에 있는 내용을 정리하면통제된 환경에서 만들어진 머신러닝은 실제 시스템에 적용했을 때 부채가 발생하며 이를 해결해나가야 한다로 정의할 수 있습니다.

해당 내용들을 읽었을 때 많이 와닿으셨나요?몇몇 분들은 공감하실 수 있겠지만… 몇몇 분들은 잘 와닿지 않았을거라 생각합니다.

그.래.서.준비했습니다!!

모두의연구소에서 매년 진행하고 있는 컨퍼런스인 MODUCON 영상중에서2019년에 윤성국님께서 화성에서 온 ML모델러, 금성에서 온 ML 엔지니어 협업하기에 대한 이야기로 발표하셨습니다. MLOps 영상 보고 오겠습니다!

[MODUCON 2019] 화성에서 온 ML모델러, 금성에서 온 ML엔지니어 협업하기 – 윤성국

No Description