[누구나 개발자 #1] ③Azure에서 머신러닝을 한다는 것

‘AI의 대중화’ 시대다. [누구나 개발자] 1편에서는 국내 유일의 소프트웨어전문지인 마이크로소프트웨어(이하 마소) 400호에 인공지능에 대한 이야기를 풀어낸 ‘스팟라이트’ 섹션의 기고를 소개한다. [편집자주]

① AI is everywhere
② 오픈소스 AI 개발 도구가 애저 클라우드와 만났을 때
③ 애저에서 머신러닝을 한다는 것...머신러닝이 클라우드, 오토 ML과 ML옵스를 만났을 때
④ 인텔리전트 ‘엣지와 클라우드’의 궁극적 지향점
⑤ 오피스 안으로 들어온 AI
⑥ 누구나 AI 전문가로!
⑦ 양자 컴퓨팅 활용의 지름길 ‘애저 퀀텀'
⑧ 알고리즘랩스 "인공지능 기술 보편화에 기여하겠다"

애저에서 머신러닝을 한다는 것
머신러닝이 클라우드, 오토 ML과 ML옵스를 만났을 때

AI(Artificial Intelligence)라는 용어는 이제 어디에서나 들을 수 있다. 집에서 매일 쓰는 가전제품에도 AI가 빠지지 않는다. 아이들이 공부할 때 쓰는 학습지도 AI를 통한 개인화된 서비스가 화두다. 심지어는 이삿짐 서비스에서도 AI가 강조된다. 한국은 알파고 사건 이후 AI에 대한 엄청난 대중의 기대와 관심이 생겼다. 심지어 이 기대와 관심에 비해 AI 강국이 되기 위한 실제 행동과 투자가 부족하다는 지적과 반성도 있다. 어쨌거나 이는 AI의 잠재력에 대한 각성의 기회가 되기에 산업 전반에 호재라고 볼 수 있다. 그러나 <그림1>과 같이 각 기업이 얼마나 AI와 관련된 기회들을 스스로의 문제로 받아들이고 실질적으로 접근했는지는 돌아볼 필요가 있다.

나는 업무상 많은 기업과 의사소통하며 AI를 내재화 혹은 활용하기 위한 고민을 듣고 대안을 논의할 기회가 많은데, 지난 수년간의 분위기 변화는 매우 고무적이다. 그러나 아직도 앞서가는 기업과 시작점에 있는 기업 간의 격차는 <그림2>에서와 같이 매우 크다. 이는 기업 규모나 공공·민간 부문 여부와 상관없이 관찰되는데, 해당 기업의 주 관심사를 통해 알아볼 수 있다. 즉, 어떤 기업은 이미 상당 부분 기술의 내재화가 되어 있고 어떻게 하면 오픈소스와 데이터 자산을 활용해 세상에 없던 서비스를 만들 것인가를 고민한다. 반면, 어떤 기업은 데이터만 제공하면 AI가 새로운 통찰력을 저절로 제공해 주는 게 아닌가 질문하기도 한다. 이러한 격차가 한국에서만 발견되는 상황은 아닌 듯하다.

이번 글에서는 머신러닝 내재화라는 방향을 택했을 때 반드시 짚고 넘어가야 할 주제 몇 가지를 다루고자 한다.

첫째, 머신러닝 기술을 내재화하고 서비스를 구현하고자 할 때 고려하는 사항들이 있다. 이에 대해서 머신러닝 프로젝트 라이프 사이클 측면에서 알아보고, 클라우드 플랫폼이 이러한 고민을 푸는 데 어떤 도움이 될 수 있는지를 살펴본다.

둘째, 머신러닝 프로젝트 운영과 관련해 생산성 측면에서 큰 바람을 일으키고 있는 오토메이티드 머신러닝(Automated Machine Learning,이하 오토 ML)의 개념과 실제에 대해 알아본다.

마지막으로 데스옵스 개념을 머신러닝에 적용한 ML옵스(MLOps)에서 고려할 사항은 무엇이고 어떻게 접근할 수 있는지에 대해 알아본다.

머신러닝 관련한 핫한 주제가 매우 많다. 그러나 세 가지는 그중에서도 꼭 짚고 가야 할 주제가 아닌가 한다. 참고로 앞으로 풀어낼 이야기에서 클라우드와 관련해 구체적인 기능이 소개된 것들은 마이크로소프트의 클라우드인 애저(Azure) 그리고 머신러닝 프로젝트를 지원하기 위한 플랫폼 서비스인 애저 머신러닝(이하 애저 ML)을 가리킨다. 그러나 애저 ML의 기능 설명이라는 협소한 관점에서 이해하기보다는 머신러닝 프로젝트 관련해 고려해야 하는 시나리오 관점에서 바라보는 것이 더욱 유용할 것으로 본다.

1. 머신러닝 프로젝트의 공통된 고민, 클라우드를 만나다

앞에서 언급했듯이 머신러닝 프로젝트는 모델의 개발뿐만 아니라 모델을 실데이터 예측에 활용할 수 있도록 연결하는 부분까지 진행되어야 한 사이클을 돌았다고 할 수 있다. 물론 모델 개발이라는 과정도 학습에 활용될 데이터를 확보하고 가공하는 단계를 포함한다. 통상 이야기하듯이 이렇게 데이터를 준비하는 과정이 프로젝트의 상당 부분에 해당하기도 한다.

풀고자 하는 문제가 제대로 정의되고, 이에 필요한 데이터가 선택되고 접근 전략이 결정되면, 머신러닝 프로젝트는 클라우드에서 대략 <그림3>과 같은 단계로 진행된다.

클라우드에는 실시간 및 배치 형태로 다양한 유형의 데이터를 다루는 그래픽 유저 인터페이스(GUI)나 코딩 형태로 활용하는 다양한 서비스가 제공된다. 비정형 데이터나 빅데이터 스케일의 데이터를 다루는 데 전문화된 서비스가 있다. 기업의 데이터가 클라우드가 아닌 자체 전산망에 있을 경우, 데이터 이동 없이 전산망 내의 컴퓨팅 자원을 이용해 모델을 학습하는 등의 시나리오도 가능하다. 이 경우에도 클라우드에서 전체 자원 및 데이터 통합 관리가 가능하다.
(2)데이터 가공(다양한 데이터 통합, 정형 정보 추출, 피처 엔지니어링 등)
클라우드의 특징 중 하나는 확장성(Scalability)이다. 데이터의 크기가 작든 크든 큰 변경 없이 적용할 수 있는 기술이 다양하게 제공된다. 예를 들어 스파크(Spark)에 기반한 빅데이터 클러스터가 사용량에 따라 자동으로 크기 조정이 되어 컴퓨팅 수요에 맞는 최적의 비용으로 작업을 수행할 수 있다.
(3)모델 학습
클라우드에서는 GUI 방식이든 코딩 방식이든 CPU, GPU 등을 이용해 모델 학습을 진행할 수 있다. 생산성 측면에서 오토 ML과 같이 최적의 데이터 전처리, 알고리즘, 하이퍼 파라미터를 선택해주는 방식도 지원된다. 오토 ML에서는 컴퓨팅 자원을 효율적으로 사용하기 위한 장치가 제공된다. 예를 들면 학습 작업이 수행되는 동안에만 GPU 클러스터 노드가 자동 생성·운영되고 작업이 종료되면 노드가 자동 제거된다거나, 총작업 시간을 지정함으로써 예산 통제를 손쉽게 하는 등의 특징이 있다.
(4)모델 검증
일반적인 모델 성능 비교 외에도 모델의 설명 가능성(interpretability) 차원에서 제공되는 서비스가 있다. 어떤 데이터 속성이 예측 결과에 영향을 주는지 투명하게 설명 가능하다. 이는 매우 빠르게 성장하는 분야다(참고 링크).
(5)모델 패키징 및 배포(테스트 환경, 운영 환경)
머신러닝 모델 개발 시 활용되는 다양한 소프트웨어 환경(예: 파이썬 패키지별 버전)은 모델마다 상이할 수 있다. 애저에서는 이러한 파이썬 환경을 체계적으로 관리하고 서비스 배포 시에도 활용될 수 있도록 하며 컨테이너 기술로 모델을 패키징해 웹 API 형태로 자동 배포한다. 쿠버네티스 기반 클러스터 서비스를 통해 오토 스케일, 보안·인증, 모니터링 등을 기본 제공한다.
(6)서비스 모니터링
기본적인 서비스 모니터링(response, availability)뿐만 아니라, 해당 서비스로 전달되는 입력 데이터, 예측 결과를 체계적으로 수집·관리할 수 있다. 입력 데이터의 패턴이 학습에 활용된 데이터의 패턴과 다를 경우(Data Drift) 머신러닝 모델의 예측 성능이 떨어질 수 있다. 이를 정기 모니터링하도록 스케줄링할 수 있어서 머신러닝 재학습 시점을 판단하는 데 중요한 정보를 확보할 수 있다.
(7)복잡한 머신러닝 실험 과정·결과물의 체계적인 관리
상기 각 단계는 모두 유기적으로 연계되어 있다. 예를 들어 특정 모델을 생성해낸 실험과 연계된 모든 산출물이 체계적으로 관리되고 접근 가능해야 한다. 예를 들면 특정 머신러닝 실험 내용을 보면, 어떤 데이터셋과 코드가 활용됐고, 그 결과 어떤 성능을 보이는 모델이 생성됐고, 이 모델이 패키징되어 어떤 서비스로 배포됐는지의 리니지(Lineage)가 확인되어야 한다. 모델이나 서비스는 버전별로 라이프 사이클이 관리되어야 한다. 예를 들면 과거 모델과 현재 모델의 성능 비교가 가능해야 한다.
(8)재학습·재배포 자동화
이상의 모든 과정은 SDK 형태로 단계별로 실행·관리됨으로써, 데브옵스 관점에서 전체 단계를 통합 관리할 수 있어야 한다. 머신러닝 관련 코드(학습용 코드, 서비스용 코드)에 변동이 있거나(깃 등으로 소스관리), 정기적으로 머신러닝 모델 재학습을 자동화할 수 있으며, 모델의 성능이 기존 모델보다 개선된 경우에만 실험 환경으로 재배포를 수행한다. 각종 통합 테스트 결과까지 자동 도출된 후, 담당자의 승인을 거쳐 운영 환경에 배포하는 데까지의 단계가 모두 자동화될 수 있다.
모든 머신러닝 프로젝트가 (1)~(8)의 전체 단계를 포함하지는 않겠지만, 이상적인 머신러닝 프로젝트는 위 사항들을 충분히 고려해 진행될 것으로 생각한다. 애저 ML은 상기 머신러닝 전체 과정을 통합 관리할 수 있는 기초를 제공한다. 이 부분은 뒤에서 ML옵스를 다룰 때 조금 더 자세히 다루도록 하겠다.

2. 오토 ML, 이제는 피할 수 없다

머신러닝 프로젝트에서 최적 모델에 이르기까지 과정은 반복적이고 많은 시간이 소요된다. 그중 한 부분은 데이터 확보·정제·가공(피처 엔지니어링 포함)에 있고, 또 다른 부분은 모델 학습을 위한 알고리즘과 하이퍼 파라미터의 선택에 있다. 데이터(feature), 알고리즘, 하이퍼 파라미터 중 하나만 바뀌더라도 다른 모델을 얻게 된다. 선택한 평가 방법상 최적의 모델을 얻기 위해서 탐색해야 하는 특징 공간(feature space)은 문제에 따라 매우 넓고, 이 안에서 최적의 조건을 랜덤하게 찾기에는 컴퓨팅 자원(예산에 직결되는)이 충분하지 않은 경우가 많다.

오토 ML은 이러한 상황에서 데이터 사이언티스트가 선택할 수 있는 보완적 도구다. 하나의 머신러닝 파이프라인이 데이터 전처리와 알고리즘, 하이퍼 파라미터 셋을 가지고 있다면, 수많은 머신러닝 파이프라인 중에서 어떤 것이 더 성능 좋은 모델을 만들어낼 것인가? 이 자체를 머신러닝 문제로 보고 접근하는 것이 오토 ML이다. <그림4>와 같이 초기 파이프라인 세팅으로 수차례의 파이프라인을 수행한다. 그 결과물인 모델의 성능을 파악한 후, 이후에 어떤 파이프라인을 수행해야 더 나은 모델을 만들어낼 것인지를 예측하는, 일종의 머신러닝 파이프라인에 대한 추천(Recommender)을 제공한다고 볼 수 있다. 이러한 메타 학습 문제를 애저 ML에서는 협업 필터링(Collaborative Filtering)과 최적화 규칙(Bayesian Optimization)의 아이디어를 접목해 접근했다. 자세한 내용은 논문을 참고하기 바라며, 팟캐스트에서는 해당 기술이 탄생한 배경을 다룬다.

언제나 그렇듯이 직접 해보는 것이 항상 새로운 개념을 이해하는 데 도움 되는데, 코딩 방식은 위 깃허브를 따라가 보는 것이 가장 쉬울 것이고, GUI를 이용하는 것은 가이드를 참고해도 좋다.

오토 ML이 클라우드와 만나면서 데이터 사이언티스트는 최적 모델 탐색 과정을 보다 효율적으로 수행할 수 있게 됐다. 앞으로 오토 ML은 데이터 사이언티스트의 필수 도구가 될 가능성이 크다고 본다.

3. ML옵스, 어떻게 구현할 것인가

먼저 머신러닝 프로젝트에 관여하는 주요한 두 액터(Actor)를 이해해야 ML옵스 개념을 이해하기 쉽다. 머신러닝 프로젝트 사이클을 들여다보면 흥미로운 점을 발견할 수 있다. 그것은 전통적인 데이터 사이언티스트와 개발자(또는 운영 시스템 담당자)가 만나 협업하는 구조라는 점이다. 이들의 역할을 비교해보자.

데이터 사이언티스트는 머신러닝 모델의 개발과 최적화를 담당한다. 개발자(또는 운영 시스템 담당자)는 데이터 사이언티스트에게 데이터를 제공하고, 최종적으로 만들어진 모델을 서비스 형태로 배포해 실세계의 데이터를 이용해 예측값을 얻어내 활용할 수 있도록 한다(이들은 데이터 엔지니어, 또는 소프트웨어 엔지니어라고 부를 수도 있을 것이다). 두 진영은 <그림8>과 같이 서로 다른 배경에서 머신러닝 프로젝트를 바라본다. 양쪽이 상대편을 이해하고 얼마나 잘 협업하느냐가 프로젝트의 성사를 결정 짓기도 한다.

다시 말해 머신러닝 프로젝트에서 첫 번째 프로세스(그림9의 ①)는 입력을 머신러닝 학습용 코드와 학습 데이터를 받아서, 내부적으로 학습·최적화라는 과정을 거치며, 출력으로 머신러닝 모델을 반환하게 된다(이상 학습 단계). 머신러닝 프로젝트는 두 번째 프로세스(그림9의 ②)가 있는데 이는 입력으로 (첫 번째 프로세스의 출력값인) 머신러닝 모델과 테스트 데이터(예측에 활용될 기반 정보)를 받고, 내부적으로 모델을 이용한 예측값을 계산한 후, 출력으로 이 예측값을 반환하게 된다(이상 추론 단계).

여기서 일반적인 데브옵스에서 ML옵스로 가려면 풀어야 할 숙제가 있다. ML옵스에서는 어떻게 산출물의 버전을 관리하고, 여러 단계의 작업을 자동화할 수 있으며, 작업 결과를 체계적으로 관리하고 분석·감사·모니터링을 수행할까? 일반 개발 프로젝트에 비해 머신러닝 프로젝트에서 더해지는 복잡성을 ML옵스에서는 어떻게 관리할 수 있을까? 이와 같은 ML옵스의 숙제를 애저 머신러닝에서는 다음과 같이 접근한다.

3-1. 모델 등록 및 버전 관리

머신러닝 모델은 앞에서 확인할 것처럼 전처리, 알고리즘, 하이퍼 파라미터 세팅에 따라 다수가 도출될 수 있다. 이들은 서로 비교 평가돼 최적의 모델이 선정될 수 있고, 특정 버전으로 정식 등록될 수 있다. 그러나 하나의 머신러닝 프로젝트에서 모델 한 개가 최종 산출물이라고 보면 오산이다. 때에 따라 하나의 목적에도 다수의 모델이 만들어지는 경우가 있을 수 있고(예를 들면 매장별이나 제품군별, 또는 그 조합의 개수만큼 별도 모델이 생성되는 경우), 모델 배포가 된 시점 이후 시간이 흐르면서 데이터 패턴이 변화하며 새로운 버전의 모델이 필요하게 되기도 한다. 모델의 버전 관리는 운영 관점에서 보았을 때 필수적인 요건이다. <그림10> 참조. ML옵스에서는 재학습된 모델과 과거 모델의 성능을 비교해, 재학습 모델의 배포 여부를 판단할 때도 버전별 모델 등록 기능이 활용된다.

모델을 배포하는 가장 원시적인 방법은 모델 파일(예를 들어 텐서플로 모델 파일들이나 피클 파일) 자체를 타깃 서버 또는 애플리케이션에 포함시키고, 요청받으면 해당 모델에 데이터를 전달해 예측값을 얻어내 반환하도록 구성하는 것이다. (물론 여러 이유로 이 방법이 최선일 경우도 있지만) 이 방식의 가장 큰 문제점은 모델이라는 것 자체가 한 번 배포되면 끝나는 것이 아니라 계속해서 새로운 버전이 나오며, 그때마다 컴파일·배포가 필요하다는 점이다.

이보다 진보된 방식은 모델 파일을 타깃 플랫폼에 직접 포함하는 것이 아니라, 모델 파일을 호스팅하는 API 서버를 별도로 구성하고, 타깃 플랫폼에서는 해당 API를 호출하는 방식이다. 버전 변경이 필요하면 API 서버만 업그레이드하면 된다. 애저 ML 방식은 조금 더 진화한 형태라고 볼 수 있다. API 서버를 구성하는 것 자체를 패키징(Containerization)을 통해 자동화하는 것이 골자다.

애저 ML에서 모델을 패키징할 때는 모델 파일, 예측 스크립트 그리고 예측 수행 시 사용할 파이썬 환경 정보(pip나 conda를 이용해 설치할 패키지 의존성 정보)를 전달한다. 이때 예측 스크립트에 포함되는 내용은 ①주어진 데이터 예측을 위해 가공하는 과정 ②모델에 데이터를 전달해 예측값을 계산하는 과정 ③산출된 값을 필요에 따라 다시 가공하는 과정이다. 이는 비즈니스 로직에 따라 정해지는 부분이다. 웹 API 구성, 인증, 텔레메트리 수집 등 공용 부분은 자동 구성된다.

이렇게 생성된 컨테이너 이미지는 말 그대로 오픈소스 도커 이미지 형태이므로 다양한 활용이 가능하다. 임의로 도커 풀(pull)로 가져와서 별도 서버에서 실행하는 것도 가능하다.

클라우드에서는 실시간 예측을 위해 쿠버네티스 기반 클러스터에 배포하면 오토 스케일, 고가용성, 키 및 토큰 기반 인증, 텔레메트리 수집, 입출력 데이터 자동 수집 등의 장점을 활용할 수 있다. 엣지에서는 애저 IoT 엣지라는 소프트웨어 런타임을 통해 해당 컨테이너 이미지를 엣지 디바이스에서 실행해, 클라우드와 분리된 엣지에서의 예측 수행이 가능하다. 단순히 서버에 도커 풀로 실행하는 것과 달리, 클라우드에서 각 엣지 디바이스와 능동적으로 인증·통신한다는 점이 특이하다. 배치 예측을 위해서는 파이프라인을 구성해 역시 오토 스케일이 지원되는 애저 ML 컴퓨트나 애저 데이터브릭(스파크 기반) 등을 통해 서비스하는 형태로 구성된다. <표1> 참조.

추론 성능 향상을 위한 최적화 단계도 빼놓을 수 없다. 우선 ONNX(Open Neural Network Exchange)는 리눅스 파운데이션 AI(LF AI)의 Graduate Project로서, 신경망 모델의 구조(그래프)와 연산(오퍼레이터)을 구분해 정의하고 이 연산 부분을 각 딥러닝 프레임워크(텐서플로, 파이토치 등)에서 확장 구현 가능하도록 했다. 이를 통해 처음 개발 시 어떤 딥러닝 프레임워크를 사용했든지 간에 최종 모델은 ONNX 포맷으로 변환이 가능하다. 서비스를 배포하는 시점에서는 ONNX 기반의 배포만을 수행하면 된다.

데이터 사이언티스트에게는 딥러닝 프레임워크를 선택할 수 있는 자유를 주면서도 개발자(운영 시스템 담당자)에게는 배포의 단순화를 추구할 수 있는 것이다. 뿐만 아니라 ONNX는 양자화(Quantization, 원래 디지털 신호처리에서 연산량을 줄이는 데 사용되던 기법. 신경망 기반 모델의 추론 속도를 빠르게 하기 위해서 활용된다. 참고 ONNX에서의 구현 방향성) 또는 타깃 플랫폼에 맞는 하드웨어 최적화 부분이 진행되어(참고 링크), 원래의 프레임워크에서보다 빠른 추론 성능을 얻는 방법이 되기도 한다. 이외 비공개 프리뷰(Private Preview)로 진행 중인 모델 추론 최적화 기능이 SDK로 제공되어 모델의 패키징·배포 단계에 포함될 수 있다.

3-3. 추적·감사

추적(Lineage)·감사(Audit)는 머신러닝 프로젝트의 거버넌스(Governance) 관리 차원에서 흥미로운 주제다. 머신러닝 프로젝트는 다른 개발 프로젝트와 마찬가지로 각 단계에서의 산출물이 이전·이후와 연결되며, 이를 유기적으로 원하는 시점에 추적할 수 있어야 한다. 앞서 살펴봤던 <그림3>이나 <그림8>을 다시 보자.

한 가지 측면은 파이프라인 관리다. 애저 ML에서는 파이프라인을 GUI 또는 코딩으로 개발할 수 있는데, GUI는 드래그 앤드 드롭 방식으로 데이터 전처리, 알고리즘·하이퍼파라미터 선택, 학습, 평가, 배포 등을 수행할 수 있다. 각 단계는 일종의 모듈 형태로 제공되는 기능을 마우스로 드래그 앤드 드롭으로 캔버스(작업 공간)에 옮기고, 각 모듈의 상세 설정을 입력하고 역시 마우스로 각 모듈 간 입출력 연결을 하는 방식이 된다. 이와 유사한 처리를 코딩으로도 할 수 있다. 코딩에서는 각 단계를 스텝이라고 부르며, 스텝 간 주고받는 입출력을 연결하는 작업이 코딩으로 이뤄진다. 각 스텝에서 수행하는 작업은 일반적인 파이썬 스크립트뿐만 아니라 데이터 팩토리나 데이터 브릭스와 같은 외부 컴퓨팅·서비스를 연계한다든지, 앞에서 살펴봤던 오토 ML을 수행하는 등이 가능하다. 파이프라인에서는 각 스텝 간 의존성이 명확하게 확인되고, 어떻게 데이터가 가공 과정을 거쳐 학습 단계에 전달되고, 검증이나 테스트로 이어지는지를 확인할 수 있다. <그림11> 참조.

머신러닝 프로젝트는 일회성으로 수행되는 것이 아니라 예측 시스템이 운영되는 단계에서도 지속적인 변경·관리가 필요하다. 특히 프로젝트를 혼자 수행하기보다 다수의 인원이 협업하는 경우가 많기 때문에 이러한 추적·감사 기능은 어떤 형태로든 풀어야 할 숙제일 것이다.

3-4. 모델의 검증

일반적인 개발 프로젝트에서는 테스트 시나리오에 따른 개발 산출물의 검증이 이뤄진다. 머신러닝 프로젝트에서는 학습 스크립트와 스코어링 스크립트에 대해서는 이와 동일한 과정이 필요하다. 그러나 머신러닝 프로젝트에서는 이에 더해 머신러닝 모델의 검증이라는 과정이 필요하다. 머신러닝 모델의 검증을 ‘성능’ 검증이라고도 한다. 주지하다시피 일반적으로 애플리케이션 성능이라고 표현하는 처리 성능(얼마나 빠르게 처리하는가) 측면뿐만 아니라, 머신러닝 관점에서의 예측 성능(얼마나 정확하게 예측하는가) 측면도 중요하다.

ML옵스 관점에서 모델이 서비스 형태로 배포되면, REST API 형태로 예측 서비스를 테스트할 수 있게 된다. 특히 개발 환경에 먼저 배포하면 애플리케이션 수준의 통합 테스트(연계 테스트, 성능 테스트 포함)를 수행할 수 있다. 머신러닝 모델의 예측 성능도 신규 모델이 비즈니스 목표 수준을 초과하고 기존의 모델 대비 우수한 성능을 보이는지를 사전에 점검할 수 있다. 더 심화한 응용 사례로는 기존 모델과 신규 모델을 모두 운영 배포하고 일부 트래픽만 신규 모델로 보내 일종의 A/B 테스트를 수행하고 그 결과에 따라 트래픽 전송 비율을 조정하는 방식을 들 수 있다.

개발 환경에서 운영 환경으로의 이관 전 담당자의 모델 성능 관련 검증이 있을 수 있다. 이때 일반적인 모델 성능에 더해 Explainer를 이용한 검증이 고려될 수 있다. 애저 ML에서는 특정 모델의 예측에 가장 큰 영향을 미치는 피처를 추정할 수 있는 도구를 함께 제공하는데, 모델 유형에 따라 다양한 Explainer가 제공되니 참고하기 바란다. <그림14~16>, <표2> 참조.

모델이 서비스로 배포되어 예측을 실시간 또는 배치로 수행한다면, 해당 서비스의 Health 체크나 응답 시간에 대한 추적, 오류가 있다면 오류 유형의 로깅 및 추적이 필요할 것이다. 일반적인 애플리케이션과 다르게 머신러닝 모델이 배포된 서비스는 데이터를 받아서 예측을 수행하기 때문에, 입력 데이터(예측을 위한 feature 정보)와 출력 데이터(예측값)를 수집해 분석하는 것도 중요하다. 이 데이터는 예측 서비스의 활용 분석에도 사용될 수 있지만, 향후 예측 성능 향상을 위해 학습 데이터로 활용될 수도 있다. 애저 ML에서는 서비스 배포 시 옵션으로 애플리케이션 인사이트 서비스를 연결하도록 선택하면, 배포 서비스에서 상기 정보를 자동으로 수집·저장하고 향후 분석할 수 있게 된다. <그림17> 참조.

그런데 모델의 예측 성능이 저하될지는 어떻게 알 수 있는가? 통상 지도 학습(Supervised Learning)의 경우, 실제값(Ground Truth)이 있을 경우 예측값과 비교해 여러 평가 지표를 계산해볼 수 있다. 그러나 실제 서비스가 배포된 상태에서는 실제값이 있기 전에 예측을 수행한다. 즉 예측 시점에서는 실제값이 없기 때문에 비교할 대상이 없어 방금 수행한 예측의 성능을 판별하기 쉽지 않다는 것이다. 이때 들어오는 개념이 데이터 드리프트(Data Drift) 모니터링이다.

데이터 드리프트 모니터링은 배포된 모델이 학습될 시점에 활용됐던 학습 데이터의 패턴을 기억하고 있다가, 실제 추론 시점에 들어오는 데이터 패턴과 비교해보는 것이다. 머신러닝 모델은 학습 데이터의 패턴이 유지될 것을 가정하는데, 이 가정과 차이 나는 데이터가 들어오면 예측 성능이 나빠질 것을 예상할 수 있다. 이를 운영 모니터링 관점에서 쉽게 추적할 수 있도록 도구를 제공하는 것으로 이해할 수 있다.

위의 모든 단계는 SDK로 접근이 가능하다. 이제는 모든 단계를 이어 전체 파이프라인을 구성하는 일이 남았다. 애저 ML에서 제공되는 기능을 빌드 및 릴리즈를 위한 파이프라인을 관리하는 도구와 결합하면 매우 다양한 형태의 ML옵스 시나리오를 구현할 수 있다. <그림19, 20> 참조.