프로덕션 환경은 일반적으로 개발 환경과 매우 다를 뿐만 아니라 상업적 리스크도 크다. 그러므로 배포하기 전에 테스트하고 잠재적인 리스크를 적절히 완화하는 것이 중요하다. 이 장에서는 프로덕션으로의 배포를 준비하는 데 필요한 단계를 살펴 볼 예정이다.

  • 프로덕션이란?
      실제 서비스를 위한 운영 환경



런타임 환경

  • 런타임 환경이란?
     프로그램이 실행되고 있을 때 존재하는 곳을 말한다. 즉, 아이폰 내에서 프로그램이 기동되면, 아이폰이 그 프로그램의 런타임이다.


모델을 프로덕션으로 보내는 첫 번째 단계는 모델이 해당 환경에서 구동이 가능한 지 체크하는 것이다. 프로덕션 환경은 사용자 맞춤형 서비스, 데이터 사이언스 플랫폼, TensorFlow Serving, Kubernetes, 임베디드 시스템의 JVM등 다양한 형태를 취하고 있다. 개발 환경에서 실행되는 모델이 검증된 후 바로 프로덕션으로 전송되는 것이 가장 이상적이지만, 그렇지 못한 경우도 발생한다.


개발에서 프로덕션 환경으로의 적용


개발 및 프로덕션 플랫폼이 동일한 공급업체에서 제공되면 실제 환경에 적용할 때 큰 수정없이 실행될 수 있다. 이 경우 모델을 프로덕션에 투입하는 데 필요한 단계는 몇번의 클릭 또는 명령으로 줄어들 수 있다.

하지만 이와 다른 경우에는 모델을 처음부터 다시 구현해야 하는 경우가 있다. 리소스와 시간을 고려했을 때는 결코 합리적이지 않은 선택이다. 그러나 여전히 많은 조직에서 이런 현상이 발생하며 종종 적절한 툴과 프로세스의 부족으로 발생한다.

이 두가지 극단적인 예시에서 모델 또는 환경과의 상호 작용을 통해 수행되는 많은 변환이 있을 수 있다. 그래서 개발 환경이 아닌 가능한 프로덕션과 가까운 환경에서 검증을 수행하는 것이 중요하다.


도구 고려 사항


프로덕션 환경으로 배포하기 전에 서로 다른 프레임워크 환경에서 만들어진 모델들이 서로 호환될 수 있도록 고려해야한다. 예를 들어 모델이 scikit-learn (Python)을 사용하여 개발되었는데, 프로덕션에서 ONNX를 입력으로 예상하는 java 기반 환경인 경우 변환이 필요하다.


이 경우에 팀이 모델을 개발하는 동안, 모델이 완료되기 전에 사용할 도구를 설정해야 된다. 이 파이프 라인을 미리 생성하지 못하면 유효성 검사 프로세스를 실행하지 못한다.


  • ONNX(Open Neural Network Exchange)란?
     Tensorflow, PyTorch와 같은 서로 다른 딥러닝 환경에서 만들어진 모델들을 호환되도록 만들어진 공유 플랫폼.


  • 유효성 검사란?
     정해진 형식의 데이터만 입력 가능하도록 제한하는 기능. 즉, 잘못된 데이터가 입력되지 않도록 방지하는 기능.


성능 고려 사항


[프로그래밍 언어별 성능 차이]


변환이 필요한 또 다른 이유는 성능 때문이다. 예를 들어 Python 같은 경우에는 C++ 보다 훨씬 느린 단점을 가지고 있다. 성능이 좋은 컴퓨터에서 테스트를 할 때는 고려하지 않아도 되지만, 임베디드 혹은 모바일 기기 같은 제한적인 성능을 가진 런타임 환경이라면 지연 시간을 고려해야 된다.

이런 저전력 장치에서 모델을 실행해야 되는 경우에는 최적화된 런타임만으로는 충분하지 않다. 더 나은 성능을 얻으려면 모델 자체를 최적화 해야된다. 그렇다면 최적화 기술에는 어떤 것이 있는 지 살펴보도록 하겠다.


  • 양자화(Quantization)

    파라미터의 정밀도를 줄여서 저비트(lower-bit)를 사용해서 훈련한다. 예를 들어 int(보통 32bit 사용)로 사용된 숫자들을 8 bit로 압축시키는 것이다. 이렇게 되면 모델이 더 적은 메모리를 사용하고 연산 효율성도 높이기 때문에 전력을 효율적으로 사용할 수 있다. 또한 연산 속도가 빨라지고 성능이 향상된다. 하지만 정확도가 떨어질 수 있는 단점이 있다.

  • 가지치기(Pruning)

    모델의 파라미터에서 중요도가 떨어지는 값들을 모두 0으로 변경해서 모델의 크기를 줄여준다. 결과적으로 정확도에 손실을 줄 수 있지만, 연산 속도가 빨라집니다.

  • 지식증류(Knowledge Distlation)

    지식 증류는 이미 학습된 모델의 파라미터 값을 모당(mimic)해서 ‘학생’ 네트워크를 만드는 것이다. 적절하게 사용한다면 적은 파라미터를 사용하여 더 나은 모델로 만들어 질 수 있다.


검증 및 프로덕션 시작 전 데이터 엑세스



검증 전에 해결해야 할 또 다른 이슈는 데이터 엑세스이다. 데이터 세트가 너무 크거나 항상 최신의 데이터를 요구하는 경우에는 데이터베이스에 엑세스하여 사용해야 한다. 원활한 환경을 위해서는 통신에 필요한 적절한 네트워크 연결, 라이브러리 또는 드라이버를 가져야한다.

이 설정과 구성을 관리하는 것은 상당히 복잡할 수 있다. 적절한 도구와 협업이 필요하기 때문이다. 외부 데이터를 엑세스하는 기술 연결이 프로덕션 오작동의 일반적인 원인이기 때문에 신중한 관리가 필요하다. 또한 프로덕션 환경과 거의 일치하는 상황에서 모델 검증이 필요하다.


런타임 환경에 대한 결론

모델을 훈련할 때는 일반적으로 방대한 자원과 GPU가 필요하다. 하지만 전체적인 MLOps 프로세스에서 보면 대부분의 계산이 추론에 소모된다. 왜냐하면 모델은 한 번만 훈련되고 추론에는 수 십억번이나 사용될 수 있기 때문이다.

복잡한 모델의 경우 추론에 드는 확장 비용이 많이 들고 에너지 및 환경에 상당한 영향을 미칠 수 있다. 그렇기 때문에 모델의 복잡성을 낮추거나 복잡한 모델을 압축하여 성능을 높이고 전력 소비를 줄이는 일은 매우 중요한 단계이다.


모델 위험 평가

모델을 구현에는 버그가 있을 수 있다. 프로덕션 환경에서 모델이 외부에서 받을 수 있는 영향은 확실하지 않다. 사소하다고 생각되는 오류가 실제 시스템에선 엄청난 결과를 초례할 수 있다.


모델 검증 목적

모델을 프로덕션에 적용하기 전에 최악의 경우를 대비해야 된다. 조직이 복잡 해짐에 따라 오작동 또는 악의적인 공격이 머신러닝 사용에서 잠재적인 위협을 받고 있음을 이해해야 된다. 그래서 다음과 같은 문제에 대비해야 된다.


  • 모델이 열악한 상황에서 최악의 방식으로 작동되면 어떻게 될까?
  • 사용자가 모델의 학습 데이터 또는 내부 논리를 추출 하게 된다면 어떻게 될까?
  • 재정, 비즈니스, 법률, 안전 및 평판 리스크에는 무엇이 있을까?


ML모델 리스크의 원인

ML모델의 리스크는 수학적으로 모델링 하기 어렵다. 그리고 모델을 실제로 배포했을 때 비로소 리스크가 구체화된다. cost matrix를 통해 모델의 예상 평균 비용을 예상할 수 있지만, 예상 비용을 훨씬 넘어서는 문제가 발생할 수 있다. 이렇게 리스크는 재정적인 문제, 개인의 안전 문제 또는 조직의 실존적 위협으로 다가 올 수 있다. ML 모델 리스크의 본질적인 원인은 다음과 같다.


  • 모델 설계, 학습, 또는 평가시 버그와 오류
  • 런타임 프레임 워크의 버그, 모델 후처리 후 버그 또는 비 호환성
  • 저 품질의 학습 데이터
  • 프로덕션 데이터와 학습 데이터 간의 괴리
  • 저작권 침해 또는 모델 출력에 대한 법적 위험
  • 머신러닝의 비 윤리적 사용으로 인한 위험


머신러닝을 위한 QA



  • QA란?
     ‘Quality Assurance‘의 약자로 품질 보증을 뜻한다. 일정 수준의 품질을 가질 수 있도록 제품 출시 전에 각종 테스트 및 검수 작업을 하는 업무를 말한다.


소프트웨어 엔지니어링은 QA가 잘 마련되어 있지만, 데이터 및 모델에 대한 QA는 아직 MLOps 프로세스에 통합하기엔 부족한 점이 있다. 그러나 QA는 머신러닝 학습의 최종 검증에만 사용되는 것이 아니라 모든 단계에서 수행되어야 한다. 왜냐하면 QA의 목적은 프로세스 준수와 리스크 수준에 비례하는 세부 사항을 보장해야 하는 것이기 때문이다.

검증 담당자가 모델을 개발에 참여한 사람이 아닌 경우 머신러닝에 대한 이해가 필요하다. 또한 개발 팀은 조직의 구조와 문화를 적절하게 보고하고 위험 수준을 체크하며 지속적인 개선에 기여해야한다. 프로덕션으로 보내기 전에 QA를 수행하는 것은 기술 검증 뿐만 아닌 지침에 따라서 모델을 검증하는 기회이기도 하다. 특히 모든 입력 데이터셋, pre-trained 모델 또는 기타 자원에 대한 출처를 알려야한다.


테스트 시 고려 사항

모델을 테스트 할 때는 모델에 데이터를 입력하고 조건에 따라 측정 값을 검증하는 것으로 구성 될 것이다. 테스트 데이터는 ‘실제 환경‘의 데이터와 다른 경우가 흔히 있다. 예를 들어 이상치, 결측값과 같은 의외의 데이터가 들어올 경우를 대비하는 것이 좋다.

Metrics는 정확도, 정밀도, 재현율과 같은 통계적 측면 뿐만 아니라 지연시간 등과 같은 계산에 대한 측면 또한 모두 수집해야 한다. 이 중 하나라도 어긋나게 된다면 테스트 시나리오가 실패하게 될 것입니다.

ML과 계산 성능 metric 검증 외에도 모델 안정성은 중요한 테스트 속성이다. 하나의 기능을 조금 변형하면 약간의 변형이 일어 날 것이라고 예상할 수 있다. 하지만 기능을 살짝 변경했는데 성능이 급격히 나빠지는 경우 매우 불안정한 모델이라고 할 수 있다. 이렇게 되면 성능이 좋은 모델이라도 신뢰할 수 없는 모델이라고 말 할 수 있을 것이다.


재현성 및 검토 가능성

MLOps에서 재현성은 다음과 같은 내용이 포함된다.


  1. 다른 사람이 설명만으로 실험을 복제 할 수 있고, 동일한 결론에 도달 할 수 있다.
  2. 정확히 동일한 실험을 쉽게 재실행 할 수 있다.


위의 2번 째 내용이 MLOps 재현성의 핵심이다. 모델의 자세한 문서, 학습 및 테스트에 사용되는 데이터, 그리고 전체 사양을 제공하는 아티팩트와 함께 제공된다는 것을 의미한다. 재현성은 모델 결과를 증명할 뿐만 아니라 이전 실험을 디버그하거나 구축하는 데 필수적이다.

모델을 검토 할 수 있으려면 중앙의 안정적인 저장소에서 다음과 같이 추적을 용이하게 하는 자료를 갖추어야한다.


  • 전체 문서
  • 정확하게 초기 환경으로 모델을 실행할 수 있는 아티팩트.
  • 모델 설명 및 공정성 보고서를 포함한 테스트 결과
  • 자세한 모델 로그 및 모니터링 메타 데이터


이러한 요구 사항들은 자칫 중요하지 않은 것으로 치부 될 수 있다. 하지만 프로젝트의 중요도에 따라서 많은 사람들이 모델의 세부사항을 이해할 수 있게 해야한다. 사회에 많은 영향을 끼칠 수 있는 프로젝트인 만큼 신중한 검토가 필요하기 때문이다.


  • 아티팩트란?
      소프트웨어 개발 프로젝트를 진행하면서 생성하는 다양한 산출물을 의미한다. 각종 설계문서, 소스코드, 소스를 빌드하여 생성된 라이브러리나 실행 파일 모드 아티팩트에 속한다.


머신러닝의 보안

머신러닝은 소프트웨어이다. 그러므로 웹이나 앱상으로 배포된 프레임워크는 다양한 보안 문제에 직면할 수 있다. 머신러닝 기술이 내포하고 있는 보안 취약점과 이를 통해 발생하는 문제점을 알아보고자 한다.


적대적 공격

기존의 해킹 방법은 유무선 네트워크나 시스템, 단말기 등 취약점을 이용했다. 하지만 새로운 해킹 방법은 머신러닝 알고리즘이 내재하고 있는 취약점을 이용한다. 딥러닝 추론은 본질적으로 행렬곱이기 때문에 작은 변화에도 출력 수에 큰 변화를 일으킬 수 있다.

이에 대한 한가지 예가 있다. 한 연구팀이 도로 교통 표지판에 이미지 스티커를 부착해 자율주행 자동차의 표지판 인식 모듈을 교란하는 실험을 발표했다. 스티커 부착만으로 자율주행차가 ‘정지’ 표시를 ‘속도제한’ 표시로 오인식 하도록 만들었다. 이처럼 머신러닝 알고리즘에 내재하고 있는 취약점에 의해 발생할 수 있는 위험을 적대적 공격(Adversarial Attack)라고 한다.



이 외에도 머신러닝 보안의 취약점을 이용한 공격 방법이 존재한다.


  • 오염 공격 (Poisoning attack)

    악의적인 데이터를 최소한으로 주입해 모델의 성능을 크게 떨어뜨리는 공격

  • 회피공격 (Evasion attack)

    입력데이터에 최소한의 변조를 가해 머신러닝을 속이는 기법. 이미지 분류 머신러닝의 경우, 사람의 눈으로는 식별하기 어려운 방식으로 이미지를 변조해 머신러닝 이미지 분류 모델이 착오를 일으키게 만드는 수법

  • 학습 데이터 추출 공격 (Inversion attack)

    머신러닝 모델에 수많은 쿼리를 던진 후, 산출된 결과값을 분석해 모델 학습을 위해 사용된 데이터를 추출하는 공격

  • 모델 추출 공격 (Model extraction attack)

    머신러닝 모델에 쿼리를 계속 던지면서 결과값을 분석하는 방식의 공격


위험 완화 모델

모델 배포 범위가 넓을수록 발생할 수 있는 리스크이 더 커지게 된다. 리스크가 충분히 높다고 생각되면 엄격하게 제어되는 MLOps 프로세스를 배포하는 것이 중요하다. 새로운 버전의 모델을 조직 또는 일부 고객에게 먼저 제공하고 그 비율을 천천히 증가 시키면서 모니터링하고 피드백을 받아야한다.


변화하는 환경

급변하는 환경은 다음과 같은 위험을 동반한다.


  • 모니터링 시스템이 경고를 보내기 전에도 변경 사항이 너무 빠르기 때문에 결과가 발생.
  • 효율적인 모니터링 시스템과 모델 재학습이 있어도 수정에 필요한 시간이 촉박함.
  • 특히 새 데이터 학습이 아닌, 새로운 모델을 개발해야 되는 경우 더욱 시간이 부족함.


이런 문제로 인해서 시스템이 잘못 작동하게 되면 조직에 큰 손실을 가져올 수 있다.

이 위험을 제어하기 위해서는 모니터링이 충분히 대응적이어야 하며, MLOps 절차에서 수정에 필요한 기간을 고려해야한다. 재학습 및 배포 전략 외에도 성능 저하에 따라 모델을 트리거 하는 임계값을 설정 할 수 있다. 단순히 최종 사용자에게 표시되는 경고 메시지를 보낼 수 있지만, 과감하게 장애가 있는 시스템을 종료하게 할 수도 있다. 다른 해결책은 성능이 낮고 자주 변경되는 환경에서 더 일관 될 수 있는 덜 복잡한 모델을 사용하는 것이다.


모델 간의 상호 작용

모델 간의 복잡한 상호 작용은 위험 요소를 더욱 어렵게 만든다. 이 문제는 ML 모델이 보편화 됨에 따라서 관심사가 더욱 증가할 것이다. 모델을 추가하면 복잡성이 모델 수에 선형적으로 증가할 것 같지만, 잠재적인 상호작용을 고려하면 더욱 복잡해 질 것이다.

또한 복잡성은 로컬 규모로 설계되고 조직 규모에서 관리되는 방식에 따라 크게 결정된다. 모델이 다른 모델의 입력을 사용하는 경우 완전히 예상치 못한 결과가 발생할 수 있으며, 추가적인 복잡성이 발생할 수 있다. 하지만 가능한 짧고 설명가능하며 독립적인 모델을 사용하면 훨씬 더 수월한 관리가 될 것이다.


  1. 모델 간에 상호작용이 없으면 복잡성이 선형에 가까워진다.
  2. 중복 처리 체인(모델이 다른 모델의 입력 사용)에 사용되는 모델은 오류를 방지 할 수 있다.
  3. 일반적으로 모델이 복잡할수록 다른 시스템과의 상호 작용이 더 복잡해질 수 있다.


모델 오작동

실시간으로 입력과 출력을 검사하는 것을 포함해서 여러 측정 값을 통해 오작동을 판별할 수 있다. 추론시 feature 값이 범위를 벗어난 경우 시스템은 적절한 조치를 취할 수 있어야 한다. feature 값 간격을 제어하는 것은 유용하지만 충분하지 않을 수 있다. 예를 들어, 피처의 수가 많을 경우 차원의 저주로 인해 문제를 피할 수 없게 된다.

이런 상황에서는 모델이 프로그램 도메인 외부에서 사용되는 기록을 식별하기 위해 이상 탐지 등 정교한 방법을 사용할 수 있다. 분류의 경우 많은 알고리즘이 예측 외에 certainty scores를 제공하여 output을 수용하도록 임계값을 수정할 수 있다.


Introducing MLOps (저자:Mark Treveil) 의 책을 읽고 MLOps에 대해 정리한 글이다. 더 자세한 내용을 알고 싶다면 MLOps 책 소개를 보길 바란다.