MLOps란
들어가며
최근 스타트업에서 검색 및 추천 엔진과 관련된 인공지능 시스템 추가 예정과 동시에 사내 시스템에서 MLOps를 공부해야할 일이 있었다.
따라서, 스타트업에서도 MLOps를 도입하는 것이 효율적일 것 같아서, 공부한 내용을 이렇게 정리한다.
이전부터 AI의 관심이 높아지면서, 인공지능을 사용하지 않는 기업 찾기는 어려워졌다.
그만큼 AI의 성과가 매우 뛰어나다는 것인데, 반면에 AI를 도입하여 좋은 성과를 이루어내는 것은 매우 어려운 일이다.
왜냐하면, 인공지능이라는 것은 어린 아이를 가르치는 것과 유사하기 때문이다.
어린 아이에게 고양이와 강아지를 구별하는 방법에 대해서 알려준다고 해보자.
가장 간단한 방법은 고양이와 강아지의 차이에 대해서 설명하기 보다, 수많은 강아지와 고양이를 보게 해주면서 스스로 차이를 깨닫게 하는 것이다.
인공지능의 학습 원리가 위와 같다.
따라서, 데이터의 품질과 양이 보장되어야하고, 모델 및 배포를 관리하는 데 있어서 쉽지가 않다.
또한, 이러한 노력 자체가 시간과 돈이기 때문에 투자 수익률을 고려했을 때, 해당 사업이 흐지부지하게 마무리되는 경우도 꽤나 있다.
그렇다면 어떻게 이를 조금이나마 효율적으로 관리할 수 있을까?
어쩌면 위의 문제의 해결책이 될 수 있는 MLOps에 대해서 알아보도록 하자.
DevOps
MLOps에 대해서 설명하기 이전에 DevOps를 빼놓을 수 없다.
둘의 이름이 뭔가 비슷하지 않는가?
이름뿐만 아니라, 개념 역시 상당히 유사하다.
DevOps에 대해서 간단하게 설명하자면, 이는 Development(개발)과 Operations(운영)을 합친 용어로, 개발과 운영을 효율적으로 만들어주는 기법이다.
소프트웨어는 개발이 완료되었다고 해서 끝난 것이 아니다.
배포까지 이루어져야 소프트웨어라고 할 수가 있다.
즉, 물건을 잘 만드는 것이 그치지 않고 괜찮은 마케팅으로 소비자에게 유통되어야 한다는 것이다.
DevOps의 대표적인 tool 중 하나인 Jenkins와 Github Action은 이를 위해서 자동으로 코드를 합치고, 테스트하고 배포해주는데, 매우 효율적이다.
즉, 개발자가 코드를 완성하고 쉬는 동안에 자동으로 일을 해주는 셈이다.
MLOps
사실 MLOps는 오래된 개념이 아니다.
2015년에 Google에서 나온 Hidden Technical Debt in ML System라는 논문에서 처음으로 MLOps가 논의되었다.
해당 논문에는 머신러닝 시스템에서 기술 부채가 무엇이 있고, 이것을 어떻게 해결해야하는가에 대한 고찰이 담겨 있다.
위의 이미지는 논문에 실린 이미지 중 하나이다.
이는 머신러닝 시스템 중에서 ML Code는 극히 일부에 해당하며 기술 부채가 나오는 건 코드가 아닌 전체적인 시스템에서 기술 부채가 나온다는 것을 의미한다.
그렇다면 머신러닝 시스템에서는 어떤 기술 부채가 있을까?
앞서 언급한 고양이와 강아지를 구별할 때, 많은 양의 갱얼쥐가 있으면 된다고 언급했다.
따라서, 인공지능은 데이터가 가장 영향이 크다고 할 수 있다.
심지어, 현실 세계에서는 시간이 지남에 따라서 데이터가 달라지니 말이다.
데이터가 달라지게 되면, 이전의 데이터로 학습한 모델과 현재 데이터에 대한 성능이 좋지 않아 시간이 지날수록 모델의 성능이 떨어지기 때문에 예민할 수 밖에 없고 상당히 곤란하다.
그 뿐만 아니라, 데이터를 어떻게 어디에 관리를 할 것 인가도 매우 중요한 요소이다.
ML 개발자들은 각자 개발한 모델과 데이터를 계속해서 SCP나 NAS에서 파일을 직접 주고 받으면 대참사가 날 가능성도 존재하기에 이런 점을 규칙을 정하고 관리하는 것도 필수적이다.
그 외에도 모델을 학습하고 배포를 할 때의 문제 역시 존재하는데, 학습이 된 모델을 서비스에 내보내려면 배포가 필수인데, 이 배포 과정도 역시 주기적으로 해야한다.
모델 개수가 적으면 수동으로 할 수 있지만, 모델이 많아지면 이걸 매번 수동으로 할 수는 없다.
위의 예시가 다는 아니지만, 결론은 머신러닝 시스템에서 기술 부채가 일어날 만한 상황이 단순히 코드에서만 있는 것이 아니고 시스템 전반적으로 기술 부채가 일어난다는 것이다.
그리고 이 기술 부채를 해결할 방법을 찾기 위해 MLOps가 대두되었다.
DevOps가 Dev + Ops를 의미하며 개발과 운영의 통합이라면, MLOps는 ML + Ops를 의미하며 머신러닝과 운영의 통합을 의미한다.
머신러닝 시스템 (CT: Continuous Training) + 자동화 (CI/CD)라고 할 수 있다.
기존의 머신러닝 시스템의 과정은 크게 아래와 같다.
- 지속적으로 들어오는 데이터를 수집하고, 데이터를 머신러닝 시스템에 사용할 수 있도록 준비하고, 데이터를 검사하고 분석하여 적절한 데이터를 선별하고, 데이터를 라벨링 하고, 데이터를 검증하고, 데이터를 준비한다.
- 모델을 학습하고, 학습된 모델을 평가하고, 모델 시스템이 배포될 수 있는지 검증하고, 모델 시스템을 프로덕션에 배포한다.
대충 봐도 꽤나 복잡해보이지 않는가?
데이터를 수집, 분석을 하기도 바쁘고, 모델을 연구하는 것도 굉장히 바쁘고 힘든 일인데 이런 걸 하나하나 수동으로 진행시키는 것은 매우 힘들다.
더 나아가, 앞서 언급했듯이 시간이 지나면서 데이터가 달라진다면 이걸 다시 반복 해야하는 것이다.
모델이 늘어가면 늘어갈수록 이러한 파이프라인을 늘어날 것이며, 그걸 매번 수동으로 다 할 수는 없다.
따라서, Google은 이 문제를 해결해 줄 MLOps 시스템을 제안을 하였다.
Google에서는 MLOps를 Level 0, 1, 2 구분지어 설명했는데, 각각의 내용은 다음과 같다.
MLOps Level 0
Level 0는 기본적으로 모든 단계가 수동이다.
그리고 모델을 학습하는 개발자과 배포하는 개발자이 따로 분리되어 작동한다.
해당 레벨에서는 운영할 모델이 몇 없고, 배포도 1년에 한 두 번 정도인 환경에서 유리한 전략이다.
하지만 Level 0의 단점은 너무나도 명확하다.
일단 모두 수동이라는 점으로, 관리해야할 모델과 배포가 자주 일어나는 환경이면 이 환경은 매우 힘들어질 것이다.
또한, CI/CD가 없기에 코드, 데이터 테스트도 존재하지 않아서 모델 배포도 직접 일일이 해주어야 한다. 심지어 모델 품질을 모니터링을 할 수 없어, 성능 저하도 감지하지 못한다.
결론적으로는 Level 0은 초기 단계의 머신러닝 적용 과정에서 유용할 수 있지만, 모델이나 배포의 규모가 커지면서 자주 업데이트가 필요할 경우 적절하지 않은 전략이 된다.
따라서, 더 체계적이고 자동화된 프로세스를 통해 효율성을 증가시키고, 지속적인 통합 및 배포(CI/CD)를 도입하는 것이 중요하다.
또한, 모델을 주기적으로 학습할 수 있는 지속적 학습(CT)이 필요한데, 이를 통해 모델의 지속적인 개선과 데이터의 변화에 능동적인 대응이 가능해진다.
이러한 지속적 학습은 Level 1에서 보완된다.
MLOps Level 1
위는 Level 1 에서는 제일 중요한 요소는 지속적 학습(CT)이다.
이를 통해서 데이터가 달라짐에 따른 성능 감소를 방지할 수 있다.
Level 0과의 가장 큰 차이점은 모델을 실험 할 때는 각각 단계는 자동으로 이루어진다는 것이다. (딸깍)
하지만 모든 것이 자동화된 작업은 아니다.
그 다음에 프로덕션에서도 학습을 할 수 있게, 개발들이 최종적인 실험에 썼던 학습 코드 전체를 프로덕션 환경에 배포를 하는데, 해당 작업은 수동으로 이루어진다고 한다.
프로덕션에 올라간 학습 코드는 최신의 데이터를 기반으로 학습이 진행된다.
그리고 학습이 끝나면 알아서 모델 배포를 진행한다.
또 모델 배포를 하고 성능 모니터링이 들어가서, 그 모니터링을 통해서 트리거를 지정한다.
트리거는 단순 시간에 따라서 트리거를 발생시켜 학습 시킬 수 있고, 성능 감소를 트리거 삼아서 학습을 진행 할 수 있다.
여기서 Feature Store라는 새로운 개념이 존재하는데, 이는 간단하게 말하자면 최신 데이터가 들어오는 데이터 저장소이다.
이를 통해 데이터 사이언티스트들은 최신 데이터로 실험을 할 수 있어 오프라인 학습 환경과 프로덕션 학습 환경과의 괴리를 줄일 수 있다.
결론적으로는 Level 1은 모델을 프로덕션에서 학습과 배포를 자동적으로 진행한다.
개발자가 작성한 학습 코드를 통해서 프로덕션 환경에 배포하고, 적절한 트리거에 따라서 프로덕션에서 학습을 진행하게 되는데, 학습이 끝나면 모델을 자동으로 배포한다.
Feature Store를 통해서 실제 데이터도 데이터 사이언티스트들이 접근 할 수 있어, 연구를 빠르게 할 수 있고, 좋은 성능의 모델을 학습이 가능해진다.
이 정도는 수준이 되면 비로소 MLOps라고 할 수 있다.
하지만 아직 완벽하진 않고, 더 추가해야할 것이 있다.
아직 ML과 Ops를 완전히 통합하지는 못했다.
따라서, 아직까지는 개발자 모델 학습을 위해 파이프라인을 작성하면 개발자가 이를 프로덕션에 배포를 수동으로 해야한다.
Level 2에서는 CT는 도입을 했으니, 이제 CI/CD를 도입할 단계이다.
MLOps Level 2
위는 CT와 더불어, CI/CD를 도입한 Level 2이다.
Level 1과 크게 다른 점은 바로 파이프라인을 프로덕션에 배포하는 것을 자동화한다는 점이다.
모델 파이프라인을 Github와 같은 레포지토리에 Push를 하면 단위 테스트와 파이프라인 구성요소간의 통합을 테스트 하는 과정을 거치는데, 이는 CI에 해당된다.
그렇다면 파이프라인 배포는 어떻게 진행할까?
대부분 학습 코드 파이프라인을 컨테이너로 묶어서 이미지를 만드는 형태로 진행하게 되는데, 이또한 자동적으로 이루어진다.
그리고 배포에 대한 테스트가 필요하다.
예를 들어 배포할 환경에 인프라 및 호환성 체크나, 예상되는 입력으로 예상되는 응답을 가져오는지 확인하고, 프로덕션 환경에서 파이프라인이 정상적으로 실행되는 지 미리 테스트하는 것도 포함이다.
이렇게 되면 완전한 자동화를 설계한 것이다.
그래서 MLOps가 만능인가?
결론부터 말하자면, 그렇지 않다.
MLOps가 머신러닝 시스템의 개발, 배포, 유지관리를 효율적으로 수행하기 위한 분야로, 여전히 발전 중이긴 하지만, 여전히 문제가 되고 있는 단점은 바로 복잡하다는 것이다.
이를 해결하기 위해 다양한 오픈소스 플랫폼들이 개발되었다.
예를 들어, Kubeflow는 사용의 편리성을 목표로 제작되었으나, 그 복잡성 때문에 종종 비판의 대상이 되기도 한다.
복잡한 일을 해결하기 위해 도구를 만들었으나, 그 도구마저 사용하기 복잡한 셈이다.
따라서, MLOps에 대한 의견은 분분하며, 일부에서는 머신러닝 개발의 빠른 속도가 MLOps의 발전을 따라잡지 못한다고 지적하기도 한다.
하지만 잘 구축된 MLOps 환경이 머신러닝 시스템의 성공에 큰 기여를 할 수 있다는 점은 부정 할 수 없다.
그렇지만, “잘 구축된 MLOps 환경”이라는 말은 엄청나게 큰 무게감을 가지고 있다는 것도 부정 할 수 없다.
마치며
오늘은 이렇게 MLOps에 대해서 알아보았다.
MLOps는 여전히 발전 중인 분야이며 여러 문제점과 해야 할 일이 많이 존재하지만, 그 가능성과 중요성은 무시할 수 없다.
물론, 모든 기술이 그렇듯 MLOps도 도입 초기에는 투자 비용과 시간, 기술적 어려움 등의 문제에 직면할 수 있다.
허나, 시스템의 복잡성과 운영의 규모가 커짐에 따라, 이러한 초기 투자가 더 큰 효율성과 경제성을 가져다 줄 수 있다는 것은 사실이다.
또한, 지속적인 모델의 성능 모니터링과 개선을 통해 변화하는 환경에 빠르게 적응할 수 있게 해주며, 이는 장기적으로 봤을 때 무시할 수 없는 큰 이점이다.
따라서, 점차 표준화가 되지 않을까 생각이 든다. (배워야겠죠?)