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

  • 한석진 마이크로소프트 AI 테크니컬 스페셜리스트
    입력 2020.08.02 08:00

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

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

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


    필자 한석진은 마이크로소프트 글로벌 블랙 벨트팀 AI 테크니컬 스페셜리스트로 활동하고 있다. 컴퓨터가 좋아 IT를 선택했고, 데이터 웨어하우징에서 커리어를 시작했다. 클라우드 스케일의 빅데이터 아키텍처와 관련된 일을 하다가 지금은 머신러닝 플랫폼을 포함한 인공지능 서비스의 매력에 흠뻑 빠져 있다. 개인적으로는 인공지능을 사회적으로 의미 있는 일에 쓰는 ‘AI for Good’ 흐름에 관심이 많다.

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

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


    <그림1> AI 관련해 기업이 바라보는 방향. 출처: ‘100 Data and Analytics Predictions Through 2021’, 가트너, 2017. ‘Predicts 2018: AI and the Future of Work’, 가트너, 2018.


    <그림2> 마치 여느 사람들의 새해 목표처럼 AI에 대한 기대와 현실도 차이가 크다. 가트너, 2019, BCG, 2017.
    AI를 한다고 하면 머신러닝 모델의 개발이 전부라고 생각할 수 있다. 하지만 모델의 개발뿐만 아니라 서비스 형태로 배포하고, 이를 실데이터와 연결해 예측값을 도출해 활용하는 부분 그리고 이 전체 사이클을 잘 연결하고 자동화하는 것도 중요한 영역이다. 이러한 머신러닝 모델을 각 기업이 보유·확보한 데이터를 이용해 직접 개발할 수도 있다. 하지만 이미 타사에서 개발해 오픈소스 또는 서비스 형태로 제공하는 AI 기술이 다양하므로 이를 이용해 빠르게 자사 업무에 적용하는 것도 중요한 전략적 대안이 된다. 결국 AI 역량에 대한 기업의 방향도 내재화와 외주 사이에서 의사결정이 된다. 기업은 자사의 핵심역량이 무엇인가의 질문으로 돌아가 그 핵심 역량을 극대화하는 방향으로 의사결정해야 할 것이다.

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

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

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

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

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

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

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

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

    <그림3> 머신러닝 프로젝트의 라이프 사이클. 일반적으로 머신러닝 모델을 최적화하는 과정인 학습 과정만을 생각하기 쉽다. 그러나 운영 시스템에서 머신러닝 모델을 활용하려면 추론 성능 최적화와 패키징, 배포·모니터링, 재학습으로 이뤄지는 전체 사이클에 대한 고민이 중요하다.
    (1)데이터 이동·연계

    클라우드에는 실시간 및 배치 형태로 다양한 유형의 데이터를 다루는 그래픽 유저 인터페이스(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)의 아이디어를 접목해 접근했다. 자세한 내용은 논문을 참고하기 바라며, 팟캐스트에서는 해당 기술이 탄생한 배경을 다룬다.

    <그림4> 애저 ML의 오토 ML은 어떻게 전처리, 알고리즘 선택, 하이퍼 파라미터 결정을 했을 때 모델의 성능이 향상되는지를 실시간으로 파악해 다음 파이프라인을 추천한다.
    단계별로 조금씩 더 살펴보면 다음과 같다.
    (1)전처리
    데이터 전처리(또는 Feature Engineering)를 어떻게 하느냐에 따라 모델 성능이 달라짐은 주지의 사실이다. 어떤 알고리즘은 특정 전처리를 필요로 하기도 한다. 차원의 크기를 줄이기 위해 전처리가 필요하기도 하고, 오버피팅(Overfitting)을 최소화하거나 아웃라이어(outlier)를 처리하기 위한 전처리 기법도 있다. 데이터의 내용(값)에 따라 제거하거나 인코딩하는 것이 필요하기도 하다. 이러한 경우의 수를 자동으로 수행해보고 보다 나은 전처리 로직을 다음 파이프라인에서 수행하게 된다. <그림5> 참조.

    <그림5> 애저 ML의 오토 ML에서 지원되는 데이터 전처리 로직들. 다양한 상황에서 최적화를 위해 사용되는 기법들이 녹아 있다.
    전처리 단계의 자동화의 이점에 대한 예를 하나 살펴보자. 오토 ML에 포함된 워드 임베딩 중에는 NLP를 다루는 사람들이 모두 알 만한 BERT 모델이 있다. BERT는 Bidirectional Encoder Representations from Transformers의 약자로, 텍스트에서 전후 문맥을 잘 표현하는 임베딩 정보를 추출함으로써 이후 여러 작업에 활용될 수 있는 언어 모델이다. 오토 ML에서는 주어진 데이터를 이용해 BERT 모델을 먼저 미세 조정(fine-tuning)하고, 이를 이용해 임베딩 정보를 추출한 후 분류(Classification)나 회귀 분석(Regression) 등을 할 수 있다. <그림5-1>은 오토 ML에서 BERT에서 생성한 정보를 이용해서 텍스트를 분류했을 때 일반적인 Bag-of-Words 방식보다 빠르게 성능이 향상되는 사례를 보여준다.(참고 링크)

    <그림5-1> AG News 데이터셋에서 Bag-of-Words 방식에 비해 BERT 모델이 빠르게 수렴하는 것을 보여주는 사례
    (2)알고리즘/하이퍼 파라미터 선택
    알고리즘이 정해진 상태에서 하이퍼 파라미터 튜닝을 하는 것 자체는 오래된 시도이. 그러나 하이퍼 파라미터 튜닝도 랜덤 샘플링 대신 최적화 규칙(Bayesian Optimization)을 이용한 탐색을 통해 보다 효율적인 탐색이 가능하다. 알고리즘 자체도 여러 가지를 시도·비교하는 것이 자동화될 수 있다. 분류, 회귀 분석, 시계열 예측(Forecasting) 문제에 적용될 수 있다. 여러 파이프라인이 비교되면서, 최종적으로는 보팅 앙상블(Voting Ensemble)과 스택 앙상블(Stack Ensemble) 모델도 자동 생성된다. 자동으로 만들어진 모델은 모두 별도로 다운로드해 직접 추가 튜닝에 활용될 수 있다. <그림6> 참조.

    <그림6> 애저 ML의 오토 ML에서 지원되는 알고리즘. 알고리즘은 클라우드의 특성에 맞게 시간이 지나면서 추가·개선된다.
    (3)평가·비교
    문제 유형에 따라 다양한 모델 평가 지표가 있으며, 자동 탐색 시 기준이 되는 평가 지표를 지정할 수 있다. 특정 점수에 도달하거나 지표 개선이 없으면 자동 탐색을 멈추거나, 예산(컴퓨팅 자원 사용시간)을 지정해 예산 소모 시까지만 수행하도록 할 수도 있다. 오토 스케일이 지원되는 클라우드 환경을 최대한 활용할 경우, 지정한 병렬도만큼 다수 노드를 활용한 탐색을 진행할 수도 있다. <그림7> 참조.

    <그림7> 애저 ML의 오토 ML에서 생성되는 모델은 지정한 평가 지표에 따라 정렬된다. 각 모델은 파이프라인의 상세 조건과 최종 모델을 직접 확인하고 추가 튜닝에 활용될 수 있다.
    애저 ML에서 오토 ML은 GUI 방식과 코딩 방식 두 가지로 접근할 수 있다. 코딩 방식에서 핵심은 아래와 유사한 형태다.

    <코드1> SDK를 이용해 오토 ML을 수행한 사례. 평가 지표를 선택하는 부분, 조기 종료를 허용하는 부분, 원격 컴퓨팅(서버·클러스터)을 지정하는 부분, 병렬도를 지정하는 부분 그리고 포케스팅에 특화된 파라미터를 전달하는 부분을 확인할 수 있다. 깃허브에 토 ML을 활용하는 여러 시나리오별 예제가 있으니 참고하길 바란다.

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

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

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

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

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

    <그림8> 데이터 사이언티스트와 개발자(운영 시스템 담당자)의 서로 다른 입장. 모델링은 3개월이 걸렸는데 1년 동안 배포하지 못했다는 이야기가 그냥 나온 것은 아니다. 둘 다 성공할 수 있는 길이 있다. 아니, 둘 다 성공해야 머신러닝 프로젝트가 성공적이라 할 수 있다.
    먼저 데브옵스 개념이 어떻게 머신러닝에 적용될 수 있는지를 살펴보자. 여기서 다룰 내용은 데이터 사이언티스트에게는 친숙하나, 개발자에게는 낯선 개념일 수 있다. 일반적인 소프트웨어 개발 프로세스를 보면 대략적으로 코드는 컴파일을 통해 실행 런타임으로 변환되고, 이것이 목표 환경에서 실행되는 형태가 된다. 여기서 이 변환이라는 과정을 하나의 프로세스로 보면, 이 프로세스는 입력으로 코드를 받고, 내부적으로 컴파일이라는 과정을 거치며, 출력으로 실행 바이너리를 반환한다고 볼 수 있다. 이를 머신러닝 프로젝트와 비교하면, 데이터라는 추가적인 변수가 있다는 것과 머신러닝 모델이라고 하는 특이한 형태의 출력물이 있다는 점을 빼면 매우 비슷한 구조임을 알 수 있다. <그림9> 참조.

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

    <그림9> 전통적인 소프트웨어 개발·배포·모니터링과 머신러닝 프로젝트에서의 개발·배포·모니터링의 비교. 입력·내부처리·출력이라는 구조는 동일하다. 차이는 머신러닝 프로젝트에서는 데이터와 모델이라는 개념이 추가된 것이다.
    이번에는 개발자에게는 친숙하지만, 데이터 사이언티스트에게는 낯설 수 있는 부분을 살펴보자. 일반적인 데브옵스에서는 코드가 릴리즈 브랜치(release branch)에 푸시될 때마다 컴파일과 단위 테스트가 수행되며 생성된 바이너리가 개발·테스트 환경에 배포된다. 통합 테스트가 수행되며, 결과적으로 승인 과정을 거쳐 운영 환경에 배포되는 과정이 이뤄진다. 모니터링 과정에서 결함이 발견되면 이슈가 생성되고, 스플린트(Splint) 일정에 따라 새로운 버전이 릴리즈 브랜치에 추가되면 위의 과정이 반복된다. 소위 지속적인 통합(Continuous Integration), 지속적인 배포(Continuous Delivery) 과정이다. 확인한 바와 같이 머신러닝 프로젝트도 입력·처리·출력의 내용이 다를 뿐 진행 과정은 같다는 것을 생각하면, ML옵스도 결국 같은 철학으로 접근이 가능하다는 것을 유추할 수 있다.

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

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

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

    <그림10> 머신러닝 모델의 등록. 버전별로 관리되며 언제든 다시 SDK를 통해 접근할 수 있다. 실험 이름과 Run ID는 이 모델이 만들어진 머신러닝 실험을 추적할 수 있게 돕는다. 엔드포인트는 이 모델이 배포된 서비스의 상세 정보를 확인할 수 있다.
    3-2. 모델의 패키징·배포

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

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

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

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

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

    <표1> 머신러닝 모델의 패키징 후 배포 대상. 기본적으로 직접 도커 풀로 가져와서 서버를 구성할 수도 있고, 이와 같이 준비된 타깃으로 배포 시에는 SDK 등의 방식으로 자동 연결까지 지원한다.

    추론 성능 향상을 위한 최적화 단계도 빼놓을 수 없다. 우선 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> 참조.

    <그림11> 파이프라인 기능을 사용해서 관련 작업을 통합·관리하는 경우 단계별 진행 상황을 자연스럽게 추적할 수 있다. 깃허브 리포트를 참고해 예시를 실행해 볼 수 있다.
    파이프라인을 쓰지 않더라도 애저 ML은 머신러닝 라이프 사이클에 포함된 전후 단계를 연계해서 추적할 수 있다. 이를 머신러닝 실험과 머신러닝 모델을 중심으로 전후, 혹은 입·출력을 생각해보자.
    (1) 머신러닝 실험: 이는 단순화하면 학습 데이터를 준비하고 학습 스크립트를 지정한 학습 플랫폼(서버, 클러스터)에서 실행하는 것이다. 그 결과 머신러닝 모델이 만들어진다. <그림12>와 같이 애저 ML에서 실험·관리 화면으로 가보면, 해당 실험이 어느 학습 플랫폼에서 어떤 파라미터로 실행됐고, 그 결과물을 아웃풋 메뉴에서 확인할 수 있다. <그림13>과 같이 스냅샷 메뉴에서 당시 실행됐던 스크립트를 확인할 수 있다.

    <그림12> 애저 ML의 머신러닝 실험 관리 화면(기본)
    <그림13> 애저 ML의 머신러닝 실험 관리 화면(스냅샷)
    (2)머신러닝 모델: 머신러닝 실험 결과로 머신러닝 모델이 만들어진다. 여기에 스코어링을 위한 로직을 스크립트로 구성하고, 모델과 스코어링 스크립트를 SDK에 제공하면 컨테이너 이미지가 생성되고 타깃 플랫폼에 배포된다. 머신러닝 모델을 등록하면 이 모델이 입력되는 머신러닝 실험과 모델이 출력되는 배포된 서비스를 추적할 수 있다는 점을 <그림10>에서 확인했다.

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

    3-4. 모델의 검증

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

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

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

    <그림14> 애저 ML에서 제공되는 Explainer의 종류. 대부분의 모델에 대한 설명을 지원한다.
    <표2> ML Explainer 종류별 접근 방법

    <그림15> Explainer 결과 시각화. 글로벌 관점의 전체 데이터 포인트에 대한 분석과 더불어 로컬 관점에서 특정 데이터 포인트별 분석도 가능하다. 예시 화면은 특정 데이터 포인트의 Local Feature Importance를 분석하는 예시.
    <그림16> Explainer에서 Perturbation 탐색. Feature값을 특정값으로 변경했을 때 예측값에 영향을 주는 결과를 시뮬레이션하는 기능 예시. 이외에도 특정값이 아니라 최소에서 최대까지 단계적으로 변화 시 영향 확인도 가능하다.
    3-5. 모델의 모니터링

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


    <그림17> 애플리케이션 로그와 데이터 자동 수집 설정 화면. 서비스 배포 시 옵션을 체크하면 자동으로 배포된 서비스에 들어오는 입출력 데이터가 수집된다.
    ML옵스 측면에서 매우 중요한 모니터링 대상이 있다. ML옵스의 흐름이 클로즈 루프(Close Loop)가 되려면, 서비스 모니터링의 결과가 루프의 처음인 재학습 단계로 연결되어야 한다. 중요한 질문은 언제 이 재학습이 트리거링(Triggering)되는지다. 우선 스케줄에 따라서(예를 들어 매주), 학습 스크립트나 스코어링 스크립트가 업데이트(git push)되었을 때를 생각해볼 수 있다. 다른 하나는 모델의 예측 성능이 저하될 것으로 보일 때다.

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

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

    <그림18> Data Drift 모니터링 결과 시각화 예시. 특정 기간에 수집된 추론용 데이터와 모델 학습 시 활용됐던 학습 데이터의 패턴 차이를 시각화한 것이다.
    3-6. 모든 단계를 잇기

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


    <그림19> 애저 데브옵스에서 ML옵스의 각 단계를 태스크로 구성한 예시. GUI 방식을 쓴 예시이지만 YAML로 구성하거나 Jenkins와 연동하는 방식도 가능하다.


    <그림20> 애저 데브옵스에서 빌드 파이프라인을 구성한 예시. 학습 결과 생성된 모델의 성능이 기존 버전의 모델 성능보다 나을 경우에만 배포되도록 구성해둔 사례다.
    이상으로 머신러닝 프로젝트를 수행할 때 고민해야 하는 것들을 살펴봤다. 그리고 클라우드를 활용했을 때 이를 어떻게 가장 효과적으로 접근할 수 있을지 알아봤다. 오토 ML이 어디까지 가능하고 어떤 잠재력이 있는지, ML옵스라는 다소 무거운 주제를 약간은 작은 조각들로 나누어 살펴봤다. 글 하나로 소화하기에는 많은 내용이나 당면한 머신러닝 프로젝트의 틀을 잡고 개선할 수 있는 아이디어를 얻을 수 있으면 좋겠다.

    [마.필.톡] 400호 특집! 한국MS 한석진 필자가 쓴 글은? 영상 / 촬영 편집 노창호 PD


    키워드

    관련기사를 더 보시려면,

    [누구나 개발자 #1] 신용녀 박사 "미래의 컴퓨팅 파워, 애저 퀀텀으로 한발 더 가깝게" 최용석 기자
    [누구나 개발자 #1] ⑥모두를 AI 전문가로 ‘학습 가이드’ 이주연 한국마이크로소프트 애저 담당 부장
    [누구나 개발자 #1] ⑤오피스 안으로 들어온 AI 박은정 오피스 365 MVP
    [누구나 개발자 #1] ④‘인텔리전트 엣지와 클라우드’의 궁극적 지향점 이건복 마이크로소프트 IoT솔루션사업부 상무
    [누구나 개발자 #1] ②오픈소스 AI 개발 도구가 애저 클라우드와 만났을 때 최영락 마이크로소프트 클라우드 엔터프라이즈 사업부 매니저
    [누구나 개발자 #1] ①AI is everywhere 김영욱 한국마이크로소프트 부장