커피고래가 생각하는 MLOps

기계학습 프로젝트를 경험하면서 느낀 점과 어떻게 하면 더 나은 구조로 나아갈 수 있을지에 대해 개인적인 생각을 정리해 보았습니다. 정답을 말하기 보다는 개인적인 희망을 적어 봅니다.

기계학습 시대의 도래

기계학습 시대가 다가 왔습니다. 불과 몇년 전까지만 하더라도 인공지능, 기계학습의 성능이 연구분야에서만 머물러 있었다면 이제는 바둑에서 기계가 인간을 이기고 기계 스스로 새로운 이미지를 생성하는 시대에 살고 있습니다. 뿐만 아니라 사람의 음성을 인식하여 원하는 서비스를 제공하는 인공지능 비서의 성능은 날로 발전하고 있습니다.(아직도 많이 부족하긴 하지만요.) 단순히 흥미를 불러일으키는 것을 넘어 이제는 현실 비즈니스 분야에서도 기계학습 모델이 큰 역할을 담당하고 있습니다. 맥킨지 리서치에 의하면 성공적인 AI 적용 후, 적게는 3%에서 많게는 15%의 이윤을 증대되었다고 합니다. 하지만 기계학습 모델이라고해서 모든 프로젝트가 성공적으로 비즈니스에 적용되는 것은 아닙니다. 오히려 그 반대입니다. 동일한 보고서에서 88%의 기계학습 프로젝트가 운영 환경까지 가지 못하고 모델 실험 단계를 넘어서지 못한다고 얘기합니다. 그렇다면 그 이유는 무엇일까요?

기계학습 프로젝트의 어려움

기계학습 프로젝트가 기존 프로젝트보다 성공하기 어려운 이유는 복잡성에 있다고 생각합니다. 모든 복잡성은 소프트웨어 프로젝트에 해당되는 내용이지만 특히 기계학습에서는 그 복잡성이 기하급수적으로 증가합니다. 그 이유는 다음과 같습니다.

• 데이터 종속성 문제
• 상이한 개발환경
• 서버 자원 관리
• 다양한 기계학습 워크플로우
• Data Scientist와 Engineer와의 큰 간극
• 지속적인 변경

데이터 종속성 문제

모델을 개발하기 위해서는 반드시 학습할 데이터가 필요합니다. 이는 필연적으로 프로젝트 생명주기 전반적으로 데이터에 종속성을 가질 수 밖에 없게 만듭니다. 예를 들어, 아무리 비즈니스 사이드에서 매일 새로운 예측 결과를 필요하더라도 데이터의 주기가 주단위로 밖에 얻을수 없다면 결국에는 주단위로 모델을 예측할 수 밖에 없을 것입니다. 또 다른 예로 아무리 AWS, GCP와 같은 클라우드 플랫폼 위에서 모델을 학습 시키고 싶더라도 데이터 보안상, 혹은 사내외 규제상 데이터를 외부로 전송하지 못한다면 결국 온프레미스 환경에서 모델을 학습하고 예측 서비스를 구축할 수 밖에 없게 됩니다. 이것은 다시 말해, 비즈니스 요구사항에 의해서 프로젝트 환경이 구성되는 것이 아닌, 데이터 제약사항에 의해 프로젝트 구성이 결정된다는 것입니다.

상이한 개발/운영 환경

분석 개발 환경은 일반 소프트웨어 개발 환경과는 다르게 사람마다, 프로젝트마다, 학습하는 모델마다 상이한 분석 환경을 요구합니다. 어떤 데이터 분석 일은 연구(experiments)에 더 가까운 경우도 있는데 연구 환경을 획일화 하는 일은 쉽지 않을 뿐더러 더 좋은 연구 결과를 도출하는데 방해가 될 수도 있습니다. 이러한 이유로 개별적으로 개발환경을 구축하여 모델을 생성하게 되면 자연스럽게 그 설정을 운영 환경에서까지 동일하게 가져가야 되고 결과적으로 많은 수의 환경을 체계적으로 관리할 수 있어야 합니다.

서버 자원 관리

기계학습은 한번에 정답을 찾는 문제가 아닌 여러 시도(trial & error)를 통해 최적의 해결책을 찾아나가는 과정이라 생각합니다. 초기 모델을 개발할 시점에서는 한두개의 서버만 이용하여 모델링을 수행하게 되지만 어느 정도 모델 개발이 완료된 이후, 여러가지 하이퍼파라미터 및 설정들을 탐색 (exploration)하는 시점에서는 많은 컴퓨팅 자원이 필요합니다. 어떤 경우에는 모델을 고도화하는 것보다 여러 컴퓨팅 자원을 바탕으로 많은 양의 데이터를 학습 시키는것이 더 좋은 결과로 이어질 수 있습니다. 이러한 이유로 기계학습에 많은 서버들을 사용하기에 효율적으로 서버 자원들을 관리하고 활용할 수 있는 체계가 필요합니다.

다양한 기계학습 워크플로우

기계학습에는 여러가지 워크플로우가 존재합니다. 크게 데이터 수집 및 전처리, 학습 및 평가 그리고 배포 후 예측을 수행하는 모델 서빙 등이 있습니다. 하지만 세부적으로 본다면 다양한 형태의 흐름을 가지게 됩니다. 예를 들어, 어떤 프로젝트에서는 데이터 수집 이후, 병렬로 각기 다른 전처리 작업을 수행할 수 있고 학습 시, 모델별로 다양한 하이퍼 파라미터도 병렬로 실험해 볼 수 있습니다. 이것은 프로젝트마다 처리해야 할 데이터가 다르고 사용하는 모델이 다르기 때문입니다. 결과적으로 프로젝트별로 다양한 기계학습 워크플로우를 관리하고 각 단계의 상태를 확인할 수 있는 체계가 필요합니다.

Data Scientist와 Engineer와의 간극

데이터 분석은 공학보다 과학에 더 가까운 경우가 많습니다. 문제 해결을 위해 주어진 해결책 내에서 최적의 대안을 찾는 것이 아니라 미지의 분야를 끊임 없이 파고들어 새로운 해결책을 제시하는 경우가 많기 때문입니다. 반대로 데이터 엔지니어는 어떻게 효율적으로 데이터를 가공하고 견고한 데이터 관리 체계를 만들 것인가 더 집중합니다. 그렇다 보니 데이터 사이언티스와 데이터 엔지니어가 생각하는 방식과 사용하는 용어에 차이가 생깁니다. 예를 들어, 데이터 사이언티스는 안정적으로 서비스를 운영하는 것보다 빠르고 정확하게 문제를 해결해 나갈 수 있는 방법에 더 초점을 두고 고민하고 (그렇다고 데이터 사이언티스가 전혀 운영 요소를 고려하지 않는다는 얘기는 아닙니다. 상대적인 관점에서 얘기합니다.) 데이터 엔지니어는 체계적이고 안정적으로 데이터 파이프 라인 시스템을 구축하고 예측 서비스를 운영하는 것을 고민합니다. 용어에서도 두 직군간의 간극이 존재합니다. 데이터 사이언티스에게 “파라미터”라고 얘기를 하면 보통 모델의 파라미터(theta)값을 혹은 하이퍼파라미터를 많이 생각하고 데이터 엔지니어에게 “파라미터”란 함수나 프로세스에게 넘겨주는 매개변수로 쉽게 인지합니다. 그렇기 때문에 데이터 직군 사이에서도 명확한 용어 정리 및 개념 통일 작업이 필요합니다.

잦은 변경

데이터의 구조(schema)가 바뀌거나 전처리의 로직이 추가되거나 모델의 학습 코드를 개선하면 어김 없이 기계학습 플로우를 수정하거나 추가해야 합니다. 또한 비즈니스 요구에 따라 모델의 성능을 개선하기 위해 지속적으로 모델을 업데이트해야 합니다. 처음부터 모든 것을 계획해서 프로젝트를 진행할 수 없기 때문에 지속적으로 변경하며 완성도를 높여 가는 것이 일반적입니다.

기계학습이란 무엇인가?

MLOps가 무엇인가 알아보기 전에 먼저 기계학습에 대해서 잠깐 생각해 봅시다. 보통 기계학습라고 하면 흔히 “학습” 단계를 많이 생각하게 됩니다. 이는 용어에서부터 “학습”이라는 단어를 사용하기 때문이기도 하고 기계가 사람처럼 학습하여 지금껏 접하지 못한 새로운 질문에 답할 수 있다는 점이 흥미롭기 때문이기도 한 것 같습니다. 하지만 조금만 더 살펴보면 학습 뿐만 아니라 학습을 위해 필요한 여러가지 작업들이 많은 것을 알 수 있습니다. 간단히 생각해 보아도 학습을 위한 데이터를 확보하는 작업, 모델을 평가하고 검증하는 작업, 데이터에서 의미 있는 특징들을 추출하고 정리하는 작업 등이 있을 수 있고 시스템 관점에서는 기계학습을 위한 서버 인프라를 관리하고 모니터링하는 작업들이 있을 수 있습니다.

이미지 출처: 구글 논문(https://papers.nips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf)

그렇다면 복잡한 분석과 어려운 모델링을 통해 우리는 무엇을 얻으려 하는 것일까요? 아마도 그것은 지금까지 발견하지 못한 새로운 가치들을 데이터로부터 찾아내어 그것을 비즈니스에 활용하기 위함이라 생각할 수 있습니다. 다시 말해 기계학습이란, 간단한 분석 결과 도출에서부터 복잡한 예측까지

• 데이터를 확보하여
• 분석가의 모델링을 통해
• 새로운 인사이트를 얻기 위한 과정

이라고 정의할 수 있습니다.

여기서 중요하게 짚고 넘어가고 싶은 부분은, 기계학습이란 한번의 작업으로 최종 목표를 달성하는 것이 아니라 여러 번 시도하며 개선해 나가는 과정이라는 점입니다. 그렇기 때문에 끊임 없이 모델을 고도화하고 빠르게 비즈니스에 반영할 수 있는 새로운 형태의 기계학습 운영 방법이 필요하게 되었고 MLOps가 이것을 해결하고자 나온 것이라 생각합니다.

MLOps란 무엇인가?

앞에서 기계학습 워크플로우에 대해서 간략하게 소개하였지만 이것을 MLOps 관점에서 다시 살펴봅시다. MLOps는 단어 그대로 크게 모델을 개발하는 모델 개발(Model dev) 단계와 학습한 모델을 활용하는 모델 운영(Model Ops) 단계가 있습니다. 모델 개발 단계에서는 데이터 수집 및 전처리, 모델 구축 및 학습, 모델 평가 등이 있고 운영 단계에서는 생성한 모델을 배포하여 예측을 하고 그 결과를 받아 모델 및 시스템 성능을 모니터링하여 필요 시 재학습하는 단계가 있습니다. 사실 각 단계들은 명확히 구별되지 않고 유기적으로 연결되며 한번으로 끝나는 것이 아니라 지속적으로 순환(cycle)되는 특징이 있습니다. 그리고 MLOps는 특정 오픈소스 제품이나 서비스가 아닌 방법론에 가깝다고 생각합니다. MLOps의 방법을 따라 기계학습 프로젝트에서 발생하는 문제점들을 최소화하고 비즈니스 가치 창출을 최대화하는 것이 MLOps의 최종 목표라 할 수 있습니다.

MLOps의 목표

MLOps의 목표는 다음과 같습니다.

• 손쉬운 모델 개발
• 빠른 모델 운영 반영
• 자동화를 통한 인적 오류 최소화
• 모델 관리를 통한 예측 품질 향상

한 마디로, 모델 개발을 편리하게 하고 운영을 자동화하는 것에 초점이 맞춰져 있습니다.

손쉬운 모델 개발

MLOps의 중요한 목표 중 하나로 손쉬운 모델 개발을 들 수 있습니다. 실제 모델링을 시작하기에 앞서 작업해야 할 일이 많습니다. 먼저 데이터를 확보하고 필요에 맞게 가공해야 하고 모델링에 필요한 패키지들을 설치하여 개발 환경을 구축해야 합니다. 전부 시간이 많이 드는 작업들이죠. 또한 모델을 실제로 개발하는 시점에는 코드의 실행 결과를 보기 위해서 가용한 서버를 찾아 실행해야 하고 로그를 확인해야 합니다. MLOps는 이러한 모델 개발의 어려움을 풀고자 합니다.

빠른 모델 운영 반영

기계학습의 최종적인 목표는 학습한 모델을 비즈니스에 활용하여 새로운 가치를 창출하는 것에 있기에 빠른 비즈니스 요구사항의 변화에 따라 모델을 빠르게 운영 반영하는 것이 중요한 목표가 됩니다. 많은 기계학습 프로젝트에서 학습한 모델을 빠르게 비즈니스에 반영하지 못해 그 가치를 증명하지 못하거나 효과가 미미한 경우가 많습니다. (하루 지난 날씨 예측을 생각해 봅시다.)

자동화를 통한 인적 오류 최소화

ML 프로젝트에서 관리해야 하는 모델과 워크플로우가 많아지면 자연스럽게 실수를 할 가능성이 많아지고 그 실수는 워크플로우를 따라 오류가 전파 됩니다. 예를 들어, 학습에 사용할 하이퍼 파라미터를 잘못 넣게 되면 잘못된 모델이 만들어지고 그것이 운영에 배포되면 비즈니스적으로 큰 손실을 불러오게 됩니다. 비슷한 예로, 모델은 정상적으로 만들어졌지만 배포할 모델을 잘못 선택하게 되면 마찬가지의 결과를 초래합니다. MLOps는 자동화를 통해 인적 오류를 최소화하고 모니터링 시스템을 두어 오류(혹은 성능 저하)를 최대한 빠른 단계에서 발견하는 것을 목표로 합니다.

모델 관리를 통한 예측 품질 향상

연구 분야에서는 한 개 모델을 깊게 파고 들어 분석하는 경우가 많다면 비즈니스에서는 여러 모델을 조합하여 앙상블 모델로 예측하는 경우가 많습니다. 또한 성능 향상을 위해 지속적으로 모델을 재학습합니다. 이러한 작업들은 필연적으로 여러 개의 모델 아티팩트(모델 결과물)를 생성합니다. 뿐만 아니라 기계학습 프로젝트가 늘어나게 되면 관리해야 할 모델의 개수가 기하급수적으로 많아지게 됩니다. 모델을 관리한다는 의미는 모델의 성능을 확인할 수 있어야 하고 모델의 버전을 추적할 수 있어야 합니다. 또한 모델이 생성된 요인을(하이퍼 파라미터 및 사용한 알고리즘) 기록할 수 있어야 하고 마지막으로 학습에서 생성되는 로그 정보들을 보관할 수 있어야 합니다. 이러한 모든 작업들이 추후에 모델의 성능을 개선하고 유의미한 분석 결과를 도출하는데 사용하게 됩니다. MLOps는 효율적인 모델 관리를 통하여 예측의 품질을 향상 시키는데 관심을 갖습니다.

MLOps 특징 및 장점

• 지속적 모델 개발
• Scalable training
• 컴퓨팅 자원 최적화
• 워크플로우 관리
• 모니터링
  • 모델 성능 모니터링
  • 시스템 모니터링
  • 모델 로깅
• 협력성 증대
• 역할에 따른 관심사 분리
• 운영 안정성 확보

지속적 모델 개발

계속해서 변화하는 비즈니스 요구사항에 맞춰 모델 개발도 끊임 없이 바뀌기 때문에 MLOps는 지속적인 모델 개발 (continuous model integration)에 관심을 가집니다. 지속적 모델 개발에는, 다양한 모델 개발환경 지원, 모델 검증 자동화(model validation), 모델 배포 자동화(deployment automation) 등이 있습니다. 사람이 직접 개발해야 하는 부분을 제외하고는 최대한 자동화하여 지속적인 모델 개발을 지원하는 것이 특징입니다. 그래서 MLOps에서도 CI/CD 플랫폼에 큰 관심을 가지고 모델 개발의 라이프사이클을 자동화하는데 노력합니다. 이를 통해 모델을 빠르게 운영에 반영할 수 있으면 그 만큼 빠른 피드백을 받을 수 있습니다. 분석 프로젝트 대부분은 비즈니스 상황에 따라 민감하게 방향성이 결정되는 경우가 많고 그 다음 모델 개발 주기(cycle)에서 여러 가설의 폭을 좁혀 주는 역할을 하기 때문에 피드백을 빠르게 받을 수 있는 점은 큰 장점이 됩니다.

Scalable training

다양한 하이퍼 파라미터를 가지고 다양한 모델을 실험해 보기 위해서 확장 가능한 training 플랫폼이 있어야 합니다. 또한 이것을 순차적으로 수행하게 되면 굉장히 많은 시간이 소요되기에 서로 간의 종속성이 없는 작업에 대해서 분산하여 학습을 실행할 수 있어야 합니다.

컴퓨팅 자원 최적화

모델마다, 데이터 크기에 따라 필요한 컴퓨팅 자원이 달라집니다. 또한 기계학습 특성상 항상 많은 자원이 필요한 것은 아니라 학습 시점에서 최대 자원을 사용합니다. 이러한 기계학습 프로세스의 특성을 잘 반영하여 컴퓨팅 자원을 최적화할 수 있는 스케줄링 정책이 필요하고 상황에 따라서는 자동 확장(auto scaling) 기능을 이용한 기계학습 수행으로 불필용한 서버 운영 비용을 줄이고 필요한 만큼의 자원만을 사용하여 최소한의 비용으로 최대한의 성능을 끌어 올릴 수 있습니다.

기계학습 워크플로우 관리

앞서 설명한 것처럼 기계학습 프로젝트에서는 다양한 워크플로우가 존재하기 때문에 MLOps에서는 이것을 어떻게 관리할 것인가에 대해 고민합니다. 워크플로우 관리를 통해 다양한 기계학습 플로우를 처리할 수 있고 병렬로 여러가지 실험들을 테스트해 볼 수 있습니다.

모니터링

MLOps에서 모니터링을 한다고 하였을 때 여러가지를 의미합니다.

가장 먼저 모델의 성능 모니터링이 있습니다. 비즈니스에 적용된 모델에 대해서 지속적으로 성능을 추적하여 의미 있는 결과가 나오도록 모니터링해야 합니다. 이것은 생각보다 쉽지 않는데요, 주기적으로 테스트셋 데이터와 정답셋 데이터를 획득해야 하는데 매번 검증에 딱 맞는 테스트셋, 정답셋 세트를 구하기 힘들 뿐더러 주기도 일정하지 않을 경우가 많습니다.

두번째로 시스템적인 모니터링이 있습니다. 이것은 ML 시스템의 전반적인 리소스 사용량, 장애 발생 여부 등을 체크하는 부분입니다. 기계학습에는 많은 리소스가 사용되기 때문에 필연적으로 여러 서버를 운영하게 되고 각각의 서버가 정상적으로 동작하는지 전체적으로 확인할 수 있는 시스템이 필요합니다.

마지막은 모델이 뱉는 로그기록을 추적하는 시스템입니다. 장애가 발생하거나 모델 성능이 예상한 것보다 낮을 때 가장 먼저 확인해야 할 것이 모델에서 나오는 로그를 보는 것입니다. 한개 서버에서 작업을 할 때에는 단순히 콘솔로 출력 시켜 확인하거나 특정 파일 위치에 로그를 적재하는 방법을 사용해도 무방하지만 서버가 많아지고 모델의 개수가 많아지면 이를 체계적으로 수집하고 적재할 시스템이 필요합니다.

협력성 증대

기계학습 프로젝트는 한 사람의 영웅이 모든 것을 이끌지 못합니다. 비즈니스 도메인을 잘 아는 사람이 있고 목적에 맞게 모델링을 잘 할 수 있는 사람이 있고 이 모든 것을 기술적으로 어떻게 풀 수 있는지 잘 아는 사람이 각각 다릅니다. MLOps를 통해 통일된 인터페이스와 표준을 세우게 되면 서로 간의 이해도와 관심 분야가 다르다 하더라도 서로 약속된 규정을 통해 서로의 영역을 자세히 몰라도 협력할 수 있는 점이 MLOps의 큰 장점 중 하나라고 생각합니다.

역할에 따른 관심사 분리

MLOps의 마지막 장점으로 데이터 분석 프로젝트내의 역할에 따라 개발환경과 담당 영역을 분리할 수 있다는 점이 있습니다. 데이터 과학자는 운영되고 있는 환경과는 상관 없이 자신의 모델의 성능과 정합성에 대해서만 관심을 가질 수 있으며 데이터 엔지니어는 모델 환경에 신경을 쓰지 않고도 모니터링, 네트워크 설정, 서버 자원 관리 등과 같이 운영에 필요한 요소만 확인할 수 있습니다. 역할에 따라 관심사를 명확히 분리해 냄으로써 작업의 효율을 높히고 운영의 안정성을 높힐 수 있게 됩니다.

운영 안정성 확보

지금까지 살펴 본 자동화, 모니터링, 컴퓨팅 자원 최적화를 통해 인적 오류를 최소화하고 운영에서 발생할 수 있는 장애를 최소화하여 안정적인 기계학습 예측 서비스를 제공할 수 있습니다.

마치며

제가 처음 쿠버네티스에 관심을 가지게 된 이유도 바로 이 MLOps를 어떻게 잘할 수 있을까를 고민하면서 부터였습니다. 쿠버네티스는 단순히 머신러닝 플랫폼만을 위해 만들어진 시스템은 아니지만 쿠버네티스를 사용하면 MLOps가 풀고자 하는 많은 문제들을 손쉽게 해결할 수 있습니다. Kubeflow가 인기를 끄는 것만봐도 이를 반증한다고 할 수 있습니다. 쿠버네티스가 제공하는 좋은 기능과 ML 진영에서 계속해서 나오는 좋은 오픈소스 혹은 상용 솔루션을 잘 조합하면 멋진 MLOps 플랫폼이 탄생하지 않을까 기대합니다. 저도 저만의 방법으로 문제를 풀려고 한 글이 있으니 한번 참고해 주시기 바랍니다. 이번 포스트는 MLOps의 개괄론적인 내용에 대해서 설명을 드렸는데 실제로 쿠버네티스를 이용하면 어떤 점에서 유용한지에 대해서는 저의 예전 포스트, MLOps와 쿠버네티스를 참고해 주시기 바랍니다.