개발자를 위한 ‘MLOps’ 기본 개념 정리 관련

LLM > Article(s)

---

Article(s)

• DevOps부터 살펴보자
• 머신러닝 시스템의 기술 부채
• MLOps란?
• Google MLOps 살펴보기
• MLOps는 ‘Silver Bullet’일까?
• 마치며

---

개발자를 위한 ‘MLOps’ 기본 개념 정리

요즘 AI를 도입하지 않는 기업을 찾아보기 어렵습니다. 그만큼 모든 산업 분야에서 AI를 활용하여 업무 효율을 높이고, 서비스를 개선하려는 노력이 활발히 이루어지고 있습니다. 하지만 AI를 도입하여 좋은 성과를 이루어내는 것은 꽤 어려운 일입니다. 우스갯소리로 AI를 ‘돈 먹는 하마’라고 부르는 것도 사실 농담이 아닙니다. AI를 도입해 투자 수익률을 달성하지 못하는 경우가 허다하니까요. 실제로 POC 단계에서 끝내는 이유도 투자 수익률을 감당하지 못해서 끝내는 경우도 많습니다. 그렇다면 어떻게 해야 좋은 성과를 이루어 낼 수 있을까요? 그 해답은 아마 ‘MLOps’에 있을지도 모릅니다.

요즘 AI를 도입하지 않는 기업을 찾아보기 어렵습니다. 그만큼 모든 산업 분야에서 AI를 활용하여 업무 효율을 높이고, 서비스를 개선하려는 노력이 활발히 이루어지고 있습니다. 하지만 AI를 도입하여 좋은 성과를 이루어내는 것은 꽤 어려운 일입니다. 여러 이유가 있겠지만 데이터 품질과 양을 우선 보장해야 하고, 매끄러운 모델 관리와 배포 관리가 어려운 점, 또 AI 인재가 아직 많이 없다는 점과 가장 큰 문제인 비용이 있을 것 같습니다.

우스갯소리로 AI를 ‘돈 먹는 하마’라고 부르는 것도 사실 농담이 아닙니다. AI를 도입해 투자 수익률을 달성하지 못하는 경우가 허다하니까요. 실제로 POC 단계에서 끝내는 이유도 투자 수익률을 감당하지 못해서 끝내는 경우도 많습니다. 그렇다면 어떻게 해야 좋은 성과를 이루어 낼 수 있을까요? 그 해답은 아마 ‘MLOps’에 있을지도 모릅니다.

---

DevOps부터 살펴보자

DevOps

MLOps를 설명하기 전, 용어 자체가 DevOps와 굉장히 유사해 보이지 않나요? 아마 개발자라면 DevOps는 많이 들어보셨을 겁니다. 그리고 DevOps와 MLOps는 이루고자 하는 목표가 크게 다르지 않습니다. DevOps를 간략하게 설명하자면 development(개발)와 operations(운영)를 합친 용어로써, 개발과 운영을 더 효과적이게 하는 관행이라고 할 수 있습니다. 간단하게는 소프트웨어 개발 및 배포를 매끄럽게 해주는 거라고 생각할 수 있고요.

DevOps에서는 CI/CD가 대표적이라고 볼 수 있습니다. CI/CD는 코드의 통합과 배포를 자동화하여 소프트웨어를 안정적으로 배포하고, 배포 주기를 단축하는 데 큰 역할을 합니다. 예를 들어, 개발자는 개발을 열심히 하면서 퇴근하고 휴식을 취할 때 젠킨스나 Github Actions과 같은 도구가 알아서 릴리즈 브랜치를 가져와 배포를 무사히 마치는 경우도 있을 겁니다.

DevOps는 개발과 운영을 통합하여 매끄럽게 합니다. 그러면 MLOps는 무엇일까요? MLOps도 마찬가지로 개발과 운영을 매끄럽게 하기 위함도 있고, CI/CD 같은 개념이 있습니다. 또 DevOps와는 다르게 CT라는 개념도 있는데, 이 내용은 MLOps를 설명하면서 다시 이야기하겠습니다.

---

머신러닝 시스템의 기술 부채

‘MLOps’라는 개념은 생각보다 그리 오래되지 않은 개념입니다. 2015년에 Google에서 나온 ‘Hidden Technical Debt in ML System’라는 논문에서 처음으로 MLOps가 논의되었습니다. 해당 논문에는 머신러닝 시스템에서 기술 부채가 무엇이 있고, 이것을 어떻게 해결해야 하는가에 대한 고찰이 담겨 있습니다.

구글 연구원들은 ML이 유행하기 아주 오래전부터 이런 점들이 문제가 될 것이라는 걸 알고 있었던 거죠. 정말 대단한 것 같습니다. 해당 논문에는 아주 유명한 이미지가 있는데, 바로 아래 이미지입니다. 해당 이미지는 MLOps를 아신다면 한 번쯤은 보셨을 겁니다. 논문에는 머신러닝 시스템 중에서 ML Code는 극히 일부에 해당하며, 기술 부채가 나오는 건 코드가 아닌 전체적인 시스템에서라고 이야기합니다.

Hidden Technical Debt in ML System
<출처: 구글>

머신러닝 시스템에서 기술 부채는 무엇이 있을까요? 생각나는 건 우선 데이터가 가장 클 것 같습니다. 현실 세계에서는 시간이 지남에 따라서 데이터가 달라집니다. 데이터가 달라지게 되면, 이전의 데이터로 학습한 모델과 현재 데이터에 대한 성능이 좋지 않아 시간이 지날수록 모델의 성능이 떨어집니다. 다음으로 데이터를 어떻게 어디에 관리를 할 것인가도 매우 중요한 요소입니다. ML 연구원들이 각자 개발한 모델과 데이터를 계속해서 SCP나 NAS에서 파일을 직접 주고받으면 대참사가 일어날 수밖에 없습니다. 이런 점에서 규칙을 정하고 관리할 수 있어야 합니다.

또한 모델을 학습하고 배포할 때도 문제입니다. 학습이 된 모델을 서비스에 내보내려면 배포해야 하는데, 이 배포 과정도 주기적으로 해주어야 하죠. 모델이 개수가 적으면 수동으로 할 수 있지만, 모델이 많아지면 이걸 매번 수동으로 할 수 없는 노릇입니다. 위 예시가 다는 아니지만, 중요한 점은 머신러닝 시스템은 기술 부채가 일어날 만한 상황이 단순히 코드에서만 있는 것이 아니고, 시스템 전반적으로 기술 부채가 일어난다는 것입니다. 그리고 이 기술 부채를 해결할 방법을 찾아야 하죠.

---

MLOps란?

MLOps

서론이 길었습니다. DevOps는 Dev + Ops를 의미하며 개발과 운영의 통합이라면, MLOps는 ML + Ops를 의미하며 머신러닝과 운영의 통합을 의미합니다. 머신러닝 시스템 + 자동화라고 할 수 있습니다.

머신러닝 시스템에서는 기본적인 구조는 다음과 같습니다.

MLOPS by NVIDIA
<출처: NVIDIA>

지속적으로 들어오는 데이터를 수집하고, 데이터를 머신러닝 시스템에 사용할 수 있도록 준비하고, 데이터를 검사하고 분석하여 적절한 데이터를 선별합니다. 그 다음 라벨링하고, 검증합니다. 머신러닝 시스템에서는 모델을 학습하고, 학습된 모델을 평가하고, 모델 시스템이 배포될 수 있는지 검증한 다음 모델 시스템을 프로덕션에 배포합니다.

꽤나 복잡하죠? 데이터를 수집, 분석하기도, 모델을 연구하는 것도 굉장히 바쁘고 힘든 일인데 이런 걸 하나하나 수동으로 진행시키는 것은 매우 힘든 일입니다. 그리고 더 큰 재앙은 시간이 지나면서 데이터가 달라지므로 이걸 다시 반복해야 하는 것이죠. 모델이 늘어가면 늘어갈수록 이러한 파이프라인을 늘어날 것이며, 그걸 매번 수동으로 할 수는 없습니다.

그래서 구글은 이 문제를 해결해 줄 MLOps 시스템을 제안을 했습니다. Google에서는 MLOps를 Level 0, 1, 2 구분 지어 설명했는데, 한번 살펴보겠습니다.

---

Google MLOps 살펴보기

<출처: 구글>

우선 Level 0은 기본적으로 모든 단계가 수동입니다. 그리고 모델을 학습하는 연구원과 배포하는 연구원이 따로 분리되어 작동합니다. 이 Level 0은 운영할 모델이 몇 없고, 배포도 1년에 한두 번 정도인 환경에서 유효한 전략입니다. ML을 적용하기 시작할 때는 대부분 이런 프로세스에서 시작하는 것 같습니다.

하지만 Level 0의 단점은 너무나도 명확합니다. 일단 모두 수동이라는 점으로, 관리해야 할 모델과 배포가 자주 일어나는 환경이면 이 환경은 매우 힘들어질 겁니다. 또한 CI/CD가 없어서 코드, 데이터 테스트도 없습니다. 모델 배포도 직접 일일이 해줘야 하죠. 그리고 데이터의 특성이 많이 바뀌는 환경에 처하면 아주 피곤하겠지요. 심지어 모델 품질을 모니터링할 수 없어, 성능 저하도 감지하지 못합니다.

결론적으로는 Level 0은 초기 단계의 머신러닝 적용 과정에서 유용할 수 있지만, 모델이나 배포의 규모가 커지면서 자주 업데이트가 필요할 경우 적절하지 않은 전략이 됩니다. 모든 작업이 수동으로 진행되므로 빠른 변화에 대응하기 어렵고, 오류의 가능성이 높아집니다.

따라서 더 체계적이고 자동화된 프로세스를 통해 효율성을 증가시키고, 지속적인 통합 및 배포(CI/CD)를 도입하는 것이 중요합니다. 그리고 모델을 주기적으로 학습할 수 있는 지속적 학습(CT)이 필요합니다. 이를 통해 모델의 지속적인 개선과 데이터의 변화에 능동적으로 대응할 수 있게 됩니다.

이 지속적 학습은 Level 1에서 해결합니다.

<출처: 구글>

위 Level 1에서 중요한 요소는 바로 지속적 학습(CT)입니다. 이를 통해 데이터가 달라짐에 따른 성능 감소를 방지할 수 있습니다. Level 0과 다른 점은 모델을 실험할 때는 각각 단계는 자동으로 이루어집니다. 흔히 코드 하나로 다 하는 경우도 많이 봤습니다. 오히려 이 단계는 각각의 프로세스를 수동으로 하는 경우는 크게 보지 못한 것 같습니다. 그 다음에 프로덕션에서도 학습할 수 있게, 연구원들이 최종적인 실험에 썼던 학습 코드 전체를 프로덕션 환경에 배포합니다. 이 작업은 수동으로 이루어집니다.

그렇게 프로덕션에 올라간 학습 코드는 최신의 데이터를 기반으로 학습이 진행됩니다. 그리고 학습이 끝나면 알아서 모델 배포를 진행하죠. 모델 배포를 한 후, 성능 모니터링이 들어가고 그 모니터링을 통해 트리거를 지정합니다. 트리거는 단순 시간에 따라 트리거를 발생시켜 학습시킬 수도 있고, 성능 감소를 트리거 삼아서 학습을 진행할 수 있습니다.

Feature Store Data Flow
<출처: Pronojit Saha>

이에 더해, ‘Feature Store’가 있는데 간단히 설명하면 최신 데이터가 들어오는 ‘데이터 저장소’라고 보면 될 것 같습니다. 이를 통해 데이터 사이언티스트들은 최신 데이터로 실험을 할 수 있어, 오프라인 학습 환경과 프로덕션 학습 환경과의 괴리를 줄일 수 있습니다.

결론적으로는 Level 1은 모델을 프로덕션에서 학습과 배포를 자동적으로 진행합니다. 연구원이 작성한 학습 코드를 통해 프로덕션 환경에 배포하고, 적절한 트리거에 따라 프로덕션에서 학습을 진행합니다. 학습이 끝나면 모델을 자동으로 배포합니다. 그리고 Feature Store를 통해 실제 데이터도 데이터 사이언티스트들이 접근할 수 있어 빠르게 연구하고, 좋은 성능의 모델을 학습할 수 있게 됩니다.

이 정도는 돼야 ‘MLOps’라고 부를 수 있습니다. 하지만 아직 완벽하진 않고 더 추가해야 할 것이 있습니다. 아직 ML과 Ops를 완전히 통합하지는 못했기 때문인데요. 아직도 연구원이 모델 학습을 위해 파이프라인을 작성하면 개발자가 이를 프로덕션에 수동으로 배포해야 합니다. 이 파이프라인을 프로덕션에 넣기 위해 손봐야 하는 것도 몇 가지 있어서 그렇습니다. 이제 CT는 도입했으니, CI/CD를 도입할 단계입니다.

<출처: 구글>

CI/CD를 도입한 Level 2입니다. Level 1과 크게 다른 점은 바로 파이프라인을 프로덕션에 배포하는 것을 자동화한다는 점입니다. 모델 파이프라인을 Github와 같은 리파지토리에 Push하면, 단위 테스트와 파이프라인 구성요소 간의 통합을 테스트하는 과정을 거칩니다. 이는 CI에 해당합니다. 이러한 테스트는 젠킨스나 Github Actions를 통해서 진행하고요.

그럼 파이프라인 배포는 어떻게 진행할까요? 대부분 학습 코드 파이프라인을 컨테이너로 묶어, 이미지를 만드는 형태로 진행하는 것으로 알고 있습니다. 이 또한 자동으로 이루어집니다. 그리고 배포에 대한 테스트가 필요합니다. 예를 들어, 배포할 환경에 인프라 및 호환성 체크나, 예상되는 입력으로 예상되는 응답을 가져오는지 확인하고, 프로덕션 환경에서 파이프라인이 정상적으로 실행되는지 미리 테스트하는 것도 포함이 됩니다.

이로써 완전한 자동화를 이루어냈습니다. 이제 모델 연구원과 데이터 사이언티스트, 데이터 엔지니어는 아주 편리하게 본인 일을 열심히 할 수 있게 되었습니다. 모델 최적화 및 배포 엔지니어도 마찬가지죠.

---

MLOps는 ‘Silver Bullet’일까?

MLOps는 머신러닝 시스템의 개발, 배포, 유지관리를 효율적으로 수행하기 위한 분야로 여전히 발전 중입니다. 물론 복잡성은 MLOps의 가장 큰 문제이지만, 이를 해결하기 위해 다양한 오픈소스 플랫폼들이 개발되었습니다. 예를 들어, Kubeflow는 사용의 편리성을 목표로 제작되었지만 그 복잡성 때문에 종종 비판의 대상이 되기도 하죠.

이러한 복잡성을 회피하기 위해 많은 기업에서 Airflow와 같은 도구를 이용해 자체 파이프라인을 구축하거나, AWS의 SageMaker, 구글의 Vertex AI 같은 클라우드 기반 서비스를 사용합니다. 이러한 다양한 접근 방식 때문에 MLOps에 대한 의견이 분분하며, 일부에서는 머신러닝 개발의 빠른 속도가 MLOps의 발전을 따라잡지 못한다고 지적하기도 합니다.

하지만 잘 구축된 MLOps 환경이 머신러닝 시스템 성공에 크게 기여할 수 있다는 점은 부정할 수 없습니다. 그렇지만 “잘 구축된 MLOps 환경”이라는 말이 큰 무게감을 가지고 있다는 것도 부정할 수 없죠. MLOps 시스템 도입에는 비용, 시간, 기술적 어려움이 동반되며, 다양한 전문가들이 협력하여 모두가 납득할 수 있는 시스템을 구축해야 합니다. 이는 데이터 과학자부터 데이터 엔지니어, 모델 연구원, 최적화 엔지니어, 배포 엔지니어 모두를 만족시켜야 하는 복잡한 과정을 포함합니다.

과연 이를 다 해결해 줄 ‘신’ 같은 개발자가 있을까요? 물론 있을 수도 있지만, 분명 많진 않을 겁니다.

---

마치며

이번 글에서는 MLOps이 무엇인가? 시스템 구성은 어떻게 되어있나? 그리고 MLOps에 대한 개인적인 견해를 작성해 보았습니다. 결론은 MLOps는 여전히 발전 중인 분야이며, 여러 문제점과 해야 할 일이 많지만 그 가능성과 중요성은 무시할 수 없다는 점입니다. 물론 모든 기술이 그렇듯 MLOps도 도입 초기에는 투자 비용과 시간, 기술적 어려움 등의 문제에 직면할 수 있습니다. 그러나 시스템의 복잡성과 운영의 규모가 커짐에 따라, 이러한 초기 투자가 더 큰 효율성과 경제성을 가져다줄 수 있습니다.

또한 지속적인 모델의 성능 모니터링과 개선을 통해 변화하는 환경에 빠르게 적응할 수 있게 해주며, 이는 장기적으로 봤을 때 무시할 수 없는 큰 이점입니다. 따라서 MLOps는 머신러닝 시스템을 더욱 믿을 수 있고 관리하기 쉬운 방향으로 발전시키는 중요한 역할을 할 것이며, 기술의 발전과 함께 점차 표준화되는 과정을 거칠 것으로 보입니다. 이러한 흐름을 따라가며 기초를 쌓는 것이 머신러닝 분야에서 계속 발전하기 위한 좋은 방법이 될 것입니다.

MLOps에 대해서 알아보자

Learn about MLOps

개발자를 위한 ‘MLOps’ 기본 개념 정리

---

요즘 AI를 도입하지 않는 기업을 찾아보기 어렵습니다. 그만큼 모든 산업 분야에서 AI를 활용하여 업무 효율을 높이고, 서비스를 개선하려는 노력이 활발히 이루어지고 있습니다. 하지만 AI를 도입하여 좋은 성과를 이루어내는 것은 꽤 어려운 일입니다. 우스갯소리로 AI를 ‘돈 먹는 하마’라고 부르는 것도 사실 농담이 아닙니다. AI를 도입해 투자 수익률을 달성하지 못하는 경우가 허다하니까요. 실제로 POC 단계에서 끝내는 이유도 투자 수익률을 감당하지 못해서 끝내는 경우도 많습니다. 그렇다면 어떻게 해야 좋은 성과를 이루어 낼 수 있을까요? 그 해답은 아마 ‘MLOps’에 있을지도 모릅니다.