머신 러닝(machine learning)에 대한 관심이 높아짐과 동시에 위드 코로나 시대를 맞아 비대면(untact) 기술 수요가 증가하면서 일상생활을 편리하고 빠르게 해결해 주는 머신 러닝 서비스가 많이 탄생하고 있습니다. 머신 러닝 모델을 고객에게 서비스로 전달하기 위해서는 모델을 연구하고 학습하는 학습(train) 과정 외에도 여러 과정이 필요합니다. 머신 러닝 모델을 학습하기 위한 데이터를 수집하고 변형, 기록하는 데이터(data) 처리 과정이 필요하고, 학습이 완료된 모델을 서비스로 연결하기 위한 최적화와 배포, 운영 관리와 같은 서빙(serving) 과정이 필요합니다.

CLOps는 이 세 가지 과정 중에서 '서빙' 과정을 담당하는 플랫폼입니다. 더욱 안정적으로 서빙하면서 자동화할 수 있는 플랫폼을 만들기 위해 고민했던 점과 개발하면서 어떤 시행착오를 겪었는지를 몇 편의 시리즈로 묶어 공유하고자 합니다.

기존 시스템의 문제점

기존 시스템에서는 모델을 개발해서 서비스로 만드는 과정을 크게 모델링과 서비스 출시라는 단계로 나누고 각 단계를 일반적으로 모델러와 머신 러닝 엔지니어가 담당했습니다. 이렇게 나누면 각 단계별 역할의 경계가 명확해지기 때문에 프로세스를 단순화할 수 있다는 장점이 있습니다. 하지만 다양한 분야에서 머신 러닝을 활용하기 시작하고 기술의 발전 속도가 빨라지면서 모델 개발과 서비스 출시의 라이프사이클 주기가 짧아졌고, 그로 인해 여러 가지 문제가 나타나기 시작했습니다.

문제점 1: 역할 간 관점 차이로 인한 기민성 저하 문제

모델러와 머신 러닝 엔지니어는 서로 관점에 차이가 있습니다. 각 역할 별로 달성해야 할 목표가 다르기 때문입니다. 모델러는 모델의 성능을 높이는 것이 목표지만, 머신 러닝 엔지니어는 모델의 추론 속도를 높이는 게 목표입니다. 그런데 일반적으로 모델의 성능과 추론 속도는 서로 반비례 관계입니다. 이 때문에 서비스로 전환하는 과정에서 역할 간 커뮤니케이션 비용이 높아지면서 서비스 전환 속도가 매우 느려졌습니다. 이 문제는 기획부터 서비스 출시까지 걸리는 시간을 늘리는 큰 걸림돌이 되었습니다.

문제점 2: 모델 성능의 유지 보수성이 지속적으로 저하되는 문제

서비스를 출시한 후에도 실시간으로 변화하는 데이터를 지속적으로 모델에 학습시키고 성능을 평가해야 합니다. 끊임없이 생성되고 변화하는 데이터의 특성에 따라 서비스하고 있는 모델의 성능이 저하될 수 있기 때문입니다. 그런데 앞서 [문제점 1]에서 말씀드렸던 것과 같은 이유로 커뮤니케이션 비용이 증가하면서 지속적으로 학습하고 배포하는 사이클을 유지하는 게 쉽지 않았습니다. 또한 서비스 출시 후 모델러가 실시간으로 변화하는 데이터를 분석한 뒤 모델에 학습시키기 위해서는 항상 머신 러닝 엔지니어를 거쳐 모델을 전달받아야 한다는 문제가 발생했습니다.

문제점 3: 모델을 개별적으로 서비스하면서 분산화되고 파편화되는 문제

서비스 기획을 담당하는 팀과 서비스 출시를 담당하는 팀이 서로 독립적으로 업무를 진행하면서 모델 관리 방법 및 인프라 구성이 다양해지고 컴퓨팅 리소스가 파편화되기 시작했습니다. 이로 인해 담당 인력이 바뀌거나 업무가 이관되는 상황이 발생하면 모델 인수인계 및 유지 보수가 어려워졌고, 인프라가 광범위하게 분산되면서 운영에 필요한 부가 작업을 중복으로 수행해야 하는 문제가 발생했습니다. 또한, 모델 트래픽에 따라 달라지는 컴퓨팅 리소스의 변화를 예측하는 게 어려워졌고 컴퓨팅 리소스가 단편화되는 문제가 많아졌습니다.

문제점 4: 모델과 모델 파라미터의 형상 유지 문제

모델을 서빙하기 위해서는 모델(소스 코드)과 모델 파라미터(학습된 값)가 필요합니다. 머신 러닝에서 모델 연구 및 실험 결과에 대한 메타 데이터와 모델 파라미터의 저장소는 학습뿐 아니라 모델을 안정적으로 배포하기 위해서도 꼭 필요합니다. 이런 저장소를 일반적으로 모델 레지스트리라고 부릅니다. 그런데 이런 데이터를 개인이 관리하는 경우도 있었고, 그렇지 않더라도 누구나 알기 쉽게 정형화해 놓지 않아서 배포된 형상을 찾거나 관리하기가 어려웠습니다.

기존 시스템의 단점을 보완해 이와 같은 문제를 해결하기 위해서, 모델 서빙을 담당하는 머신 러닝 엔지니어가 개별적으로 수행하던 업무를 자동화하고 중복 작업을 최소화하자는 목표를 세웠습니다. 더 나아가 모델러가 모델 연구에서 서빙까지 빠르게 진행해서 지속적으로 모델을 테스트하고 개선할 수 있는 환경을 제공하고 컴퓨팅 리소스가 파편화되는 것을 막아 효율적으로 관리할 수 있는 시스템을 만들기 위해 고민했습니다. CLOps 플랫폼은 바로 이 고민에서 시작했습니다.

모델 서빙의 주요 요소

개발하기에 앞서 모델 서빙에는 어떤 요소가 있고 어떻게 각 요소 간의 우선순위를 정해 어떤 방식으로 자동화해야 기존 시스템의 문제를 해결할 수 있을지 고민했습니다. 수많은 모델을 서빙하면서 겪은 경험을 바탕으로 모델을 서빙하는 데 필요한 요소를 아래와 같이 크게 다섯 가지로 나눠 정의했습니다.

• 코드를 변경하지 않고 다양한 기능을 자동으로 확장하고 배포하며 제어하기 위한 코어 컴포넌트
• 컴퓨팅 리소스를 효율적으로 할당하고 회수하며 관리하기 위한 컴퓨팅 리소스 관리
• 모델 레지스트리와 다양한 서빙 형태, 모델 A/B 테스트와 같은 확장 기능인 모델 부가 기능 확장
• 지속적이고 안정적으로 운영할 수 있는 환경을 제공하는 모델 운영 관리
• 플랫폼을 쉽고 편하게 사용하기 위한 인터페이스

위 다섯 가지 요소에 대해서는 다음 글에서 차근차근 심도 있게 살펴보기로 하고, 이번 글에서는 CLOps의 제공 환경과 개발 스택, 아키텍처를 간략히 살펴보겠습니다.

CLOps의 시작

CLOps는 CLOVA와 MLOps의 합성어로, 모델 서빙 방식을 표준화하고 자동화할 수 있는 MLOps 서빙 플랫폼을 목표로 개발을 시작했습니다. 사실 Seldon이나 Kubeflow와 같이 CLOps와 동일한 목표로 서비스를 제공하는 여러 오픈소스 프로젝트가 이미 존재합니다. 이처럼 활발히 개발되고 있는 프로젝트가 있었음에도 직접 개발하게 된 이유는 사내 환경에 맞게 기능을 변경하는 게 필요하기도 했고, 그보다 더 중요한 이유로 모델러의 요구 사항을 만족시킬 수 있도록 근거리에서 아주 작은 피드백까지 잘 듣고 반영하기 위해서입니다. 이와 같은 목표를 달성하기 위해 가장 먼저 한 일은 1) 기존 시스템의 문제점을 분석하고 2) 모델 서빙을 자동화하기 위한 주요 요소를 정의한 것입니다. 이를 토대로 제공할 플랫폼의 환경 및 개발 스택을 선정하고 아키텍처를 설계했습니다.

제공 환경 및 개발 스택 선정

플랫폼 제공 환경을 선정하면서 고려했던 주요 요구 사항은 다음과 같습니다.

• 기존 시스템의 문제점을 해결할 수 있고 자동화를 위한 기능 확장이 용이해야 함
• 모델러가 쉽게 이해하고 사용할 수 있는 환경이어야 함
• 컴퓨팅 리소스 스케줄링을 추상화할 수 있어야 함
• 안정적이고 회복 가능한 환경을 제공해야 함

이를 요약하면 확장성, 쉬운 배포와 스케줄링, 안정적인 운영을 지원하는 환경이라고 할 수 있습니다. 이와 같은 요구 사항을 만족하면서 안정적인 환경을 제공하는 인프라는 쿠버네티스와 Hadoop 등 다양하게 존재합니다. 그중에서 쿠버네티스를 선택한 이유는 내부 기능을 커스터마이징해서 확장할 수 있는 쿠버네티스 오퍼레이터의 가능성 때문입니다. 필요한 환경은 기본적으로 제공하면서 마치 쿠버네티스를 직접 개발하듯 기능을 확장할 수 있는 인프라는 쿠버네티스가 유일했기에 쿠버네티스로 선정했습니다.

쿠버네티스를 선택하면서 자연스럽게 쿠버네티스 확장 개발에 용이한 Go 언어를 개발에 사용할 주 언어로 선택했습니다. Go 언어는 코드가 간결하면서 컴파일 언어답게 높은 성능을 낼 수 있는 언어로, 수많은 요청과 처리를 수행하는 쿠버네티스를 구현한 언어이기도 합니다. 또한, 쿠버네티스 기능 확장과 관련해 방대한 문서가 존재하고 커뮤니티도 활성화돼 있어서 개발 스택으로써 Go 언어를 선정하는 데 이견이 없었습니다.

아키텍처

모든 모델러가 각자의 기호에 맞게 준비된 여러 인터페이스를 통해 플랫폼을 사용하면서 동일한 경험을 할 수 있어야 한다고 생각했습니다. 이를 위해 단일화된 API 서버를 통해 통신할 수 있는 구조로 설계했고, 사용자별 인증과 권한 부여가 가능한 구조로 설계했습니다. 또한, 대부분의 확장 기능을 쿠버네티스 기반으로 커스텀 리소스를 통해 자동화할 수 있도록 설계했습니다. 이런 구조로 설계하면 쿠버네티스 환경이면 어느 곳에서든 동일한 환경을 재현하는 기능을 제공할 수 있습니다.

이번 글에서는 기존 시스템의 문제점을 짚어보며 CLOps 플랫폼을 개발하게 된 배경과 모델 서빙 과정의 주요 요소가 무엇인지 살펴봤습니다. 또한 새로운 플랫폼을 제공할 환경 및 개발 스택을 선정한 과정과 아키텍처를 간략히 알아보았습니다. 더욱 자세한 내용이 궁금하지 않으신가요? 이어지는 시리즈에서는 앞서 설명한 주요 요소들을 개발하면서 고민했던 점과 어떤 시행착오를 겪었는지 공유하겠습니다.