Google for Developers Korea Blog: 프로덕션 환경에서 실제로 사용되는 머신러닝, TensorFlow Extended(TFX)에 대해 소개합니다

프로덕션 환경에서 실제로 사용되는 머신러닝, TensorFlow Extended(TFX)에 대해 소개합니다

2019년 11월 21일 목요일

.post-body span { white-space: normal !important; } 게시자: Robert Crowe, Konstantinos (Gus) Katsiapis, Kevin Haas(TFX 팀을 대표해 게시함)

사람들은 머신러닝에 대해 생각할 때, 보통은 지금 만들 수 있는 훌륭한 모델에 대해서만 생각합니다. 결국, 대다수 연구 논문에서 초점을 맞춰 설명하는 내용이기도 합니다. 하지만 그런 멋진 모델을 실제 사용 환경에서 사용할 수 있도록 하고 싶다면 모니터링, 신뢰성, 유효성 검사 등, 프로덕션 솔루션에 필요한 모든 사항에 대해 생각해봐야 합니다. 그게 바로 Google에서 TensorFlow Extended(TFX)를 만들어 우리의 머신러닝(ML) 파이프라인을 위한 프로덕션 수준의 지원을 제공하는 이유입니다. 우리는 모든 곳의 개발자가 프로덕션 수준 TFX 파이프라인을 통해 모델을 만들고 배포할 수 있도록 오픈소스 커뮤니티와 함께 TFX를 공유하고 있습니다.
Google은 TFX가 필요했기 때문에 TFX를 만든 것이며, 그 전에는 우리의 요구를 충족시켜 줄 만한 것이 없었습니다. Google, 좀 더 일반적으로 Alphabet은 대부분의 자사 제품에 ML을 광범위하게 사용합니다. 사실, Google이 만든 최초의 ML 파이프라인 프레임워크는 TFX가 아니었습니다. TFX는 이전부터 이루어진 여러 차례의 시도를 통해 진화한 결과물로, 지금은 Google의 대다수 ML 프로덕션 솔루션을 위한 기본 프레임워크가 되어 있습니다. TFX는 Google 이외에 Twitter, Airbnb, PayPal을 비롯한 우리 파트너들에게도 깊은 영향을 미쳤습니다. 단순히 ML만의 문제가 아닌 TFX 애플리케이션에 ML을 결합할 계획을 세우기 시작할 때, 일반적으로 ML에 대해 생각할 수 있는 모든 사항을 고려할 것입니다. 지도 학습을 수행할 경우에는 라벨을 지정한 데이터를 가져오고 데이터셋에 가능한 입력 데이터를 위한 공간이 충분히 확보되어 있는지 확인하는 등의 작업이 여기에 포함됩니다. 또한 피쳐셋에 포함되는 예측 정보는 최대화하면서도 피쳐셋의 차원은 최소화하고 싶을 것입니다. 공정성에 대해 생각해보고 애플리케이션이 불공정하게 편향되지 않도록 해야 합니다. 드물게 발생할 뿐이지만 중요한 상황이 벌어지는 조건에 대해 예측할 수 있는 헬스케어와 같은 애플리케이션에서는 특히 드물게 발생하는 조건도 고려해야 합니다. 마지막으로, 이런 애플리케이션은 시간이 흐르면서 새로운 데이터가 유입되고 조건이 바뀜에 따라 진화하는, 살아 있는 솔루션이 될 것이라는 점을 염두에 두고 데이터의 수명 주기 관리를 계획해야 합니다. 하지만 그 모든 점 외에도, 소프트웨어 애플리케이션을 프로덕션 환경에 적용한다는 점을 잊어선 안 됩니다. 즉, 안전과 보안뿐 아니라 확장성, 일관성, 모듈성, 테스트 가능성을 비롯하여, 어떤 프로덕션 소프트웨어 애플리케이션이라도 가지고 있는 모든 요구사항이 그대로 적용된다는 뜻입니다. 이제는 모델을 단순히 훈련하는 차원을 훌쩍 넘어섰습니다! 이런 문제는 그 자체로 모든 프로덕션 소프트웨어 배포 시에 맞이하게 되는 해결 과제이며, ML을 수행한다는 이유만으로 잊어도 되는 문제가 아닙니다. 어떻게 이 모든 요구를 충족시키고 새롭고 놀라운 모델을 프로덕션 환경에 적용해야 할까요? 그 해답은 바로 TFX입니다. TFX를 사용하면 프로덕션 소프트웨어 배포와 모범 사례에 대한 요구사항 중 다수를 포함하는 프로덕션 ML 파이프라인을 만들 수 있습니다. 이는 데이터를 내부 데이터화하는 단계부터 시작해 데이터 유효성 검사, 특징 추출, 훈련, 평가, 서빙의 순서로 흘러갑니다. TensorFlow 자체 외에, Google은 ML 파이프라인의 각 주요 단계를 위한 라이브러리인 TensorFlow Data Validation, TensorFlow Transform, TensorFlow Model Analysis도 만들었습니다. 또한 서버 팜(TensorFlow Serving), 네이티브 모바일 애플리케이션(TensorFlow Lite), 자바스크립트 애플리케이션(TensorFlow JS)을 비롯한 다양한 배포 대상을 위한 프레임워크도 만들었습니다. TFX는 라이브러리를 활용하는 일련의 파이프라인 구성 요소를 구현하고, 개발자가 자체적인 구성 요소를 만들 수도 있도록 허용합니다. 이 모든 것을 함께 연계하기 위해, Google은 파이프라인 저장, 구성 및 오케스트레이션과 같은 작업을 위한 몇 가지 수평적 계층을 만들었습니다. 이런 계층은 파이프라인과 파이프라인에서 실행하는 애플리케이션을 관리하고 최적화하는 데 실로 중요합니다. 프로덕션 환경의 ML은 많은 도전적 과제를 안겨주는데, Google은 그에 대한 모든 해법을 가지고 있는 것처럼 행세하지 않습니다. TFX는 ML 커뮤니티에서 계속 발전하고 진화하는 분야이며, 이러한 발전에 대한 기여를 적극적으로 환영합니다. 프로덕션 환경에서 머신러닝이 안고 있는 난제에 대한 개요를 훌륭하게 설명한 이 논문을 참조하시기 바랍니다. '파이프라인'과 '구성 요소'란 무엇일까요? TFX 파이프라인은 각각 다른 작업을 수행하는 구성 요소의 시퀀스로 생성됩니다. 구성 요소는 'DAG', 즉 Directed Acyclic Graph로 구성됩니다. 하지만 정확히는 어떻게 구성되어 있을까요?

TFX 구성 요소로는 driver, executor, publisher라는 세 가지 주요 부분이 있습니다. 이들 중 드라이버와 publisher의 두 부분은 주로 변경할 수도 있지만 아마도 절대 그럴 필요가 없을 상용구 코드입니다. 개발자가 실제로 자신의 코드를 삽입하고 사용자 설정을 하는 부분은 바로 executor입니다.
driver는 실제 환경의 상태를 검사하여 어떤 작업을 수행해야 할지 결정함으로써 작업 실행을 오케스트레이션하고 executor에게 메타데이터를 피드합니다. publisher는 executor의 결과를 받아 메타데이터 저장소를 업데이트합니다. 하지만 executor는 실제로는 각 구성 요소에 대한 작업이 수행되는 곳입니다.
그래서 첫째, 구성 요소에 대한 구성이 필요하고 TFX에서는 Python을 사용하여 그런 구성이 수행됩니다. 다음으로, 구성 요소에 대한 입력과 결과를 보낼 장소가 필요합니다. 바로 메타데이터 저장소가 그 역할을 합니다. 메타데이터 저장소에 관해 좀 더 자세히 설명하겠지만, 지금은 대부분의 구성 요소에 대해서는 입력 메타데이터가 메타데이터 저장소에서 오고 결과 메타데이터가 메타데이터 저장소에 다시 기록된다는 점만 알아두시기 바랍니다.

데이터가 파이프라인을 통해 이동함에 따라, 구성 요소는 이전의 구성 요소에서 생성된 메타데이터를 읽고, 파이프라인의 하부에 있는 구성 요소에서 사용하게 될 메타데이터를 작성합니다. 파이프라인의 시작 및 끝에서처럼 몇 가지 예외는 있지만, 대다수의 부분에서는 데이터가 위와 같은 방식으로 TFX 파이프라인을 통해 흐릅니다.
TFX 파이프라인 오케스트레이션 이 모든 구성 요소를 구성하고 이런 파이프라인을 관리하려면 오케스트레이션이 필요합니다. 그런데 오케스트레이션이란 정확히 무엇이고 오케스트레이션이 어떤 도움이 되는 걸까요? ML 파이프라인을 만들고 그 파이프라인을 구성하는 구성 요소의 시퀀스를 정의하고 그 실행을 관리하려면 오케스트레이터가 필요합니다. 오케스트레이터는 작업을 트리거하고 구성 요소를 모니터링하는 데 사용할 수 있는 관리 인터페이스를 제공합니다. 파이프라인의 다음 단계를 시작하기만 하면 될 경우에는 작업을 인식하는 아키텍처로 충분합니다. 이전의 구성 요소가 작업을 마치자마자 다음 구성 요소를 곧바로 시작할 수 있습니다. 하지만 작업과 데이터를 인식하는 아키텍처는 훨씬 더 강력하며, 수많은 실행이 이루어지는 동안 모든 구성 요소로부터의 모든 아티팩트를 저장하므로 실제로 어떤 프로덕션 시스템에 대해서도 거의 필수적인 요건이라 할 수 있습니다. 바로 그 메타데이터를 확보하면 훨씬 더 강력한 파이프라인이 생성되고, 만약 메타데이터를 확보하지 못했더라면 매우 어려웠을 많은 일들이 가능해지므로, TFX는 작업과 데이터를 인식하는 파이프라인 아키텍처를 구현합니다. 개방적이고 확장 가능한 TFX를 구현하는 방법 중 하나는 오케스트레이션을 사용하는 것입니다. Google은 별도의 구성 없이 바로 사용 가능한 Apache Airflow와 Kubeflow를 위한 지원을 제공하지만, 필요하다면 다른 오케스트레이터를 사용하기 위한 코드를 작성할 수 있습니다. 마음에 드는 워크플로 엔진이 이미 있다면, TFX와 함께 그 엔진을 사용하도록 실행기를 빌드할 수 있습니다.
왜 메타데이터를 저장해야 할까요? TFX는 ML 파이프라인을 위한 메타데이터를 정의하고 저장하고 쿼리하기 위한 오픈소스 라이브러리인 ML-Metadata(MLMD)를 사용하여 메타데이터 저장소를 구현합니다. MLMD는 관계형 백엔드에 메타데이터를 저장합니다. 현재 구현에서는 별도의 구성 없이 SQLite 및 MySQL을 바로 사용할 수 있도록 지원하지만, 기본적으로 어떤 SQL 호환 데이터베이스에 대해서든 ML-Metadata를 확장하는 코드를 작성할 수 있습니다. 그렇지만 메타데이터 저장소에 정확히 무엇을 저장하는 것일까요? 첫째, 개발자가 훈련한 모델에 관한 정보, 개발자가 모델을 훈련할 때 사용한 데이터, 그리고 평가 결과를 저장합니다. 우리는 이런 유형의 메타데이터를 '아티팩트'라고 지칭하는데, 아티팩트에는 속성이 있습니다. 데이터 자체는 데이터베이스 외부에 저장되지만, 데이터의 속성과 위치는 메타데이터 저장소에 보관됩니다. 다음으로, 우리는 각 구성 요소가 실행될 때마다 해당 실행 기록을 보관합니다. ML 파이프라인은 긴 수명에 걸쳐 새로운 데이터가 들어오거나 조건이 변경됨에 따라 수시로 실행되므로, 해당 기록을 보관하는 것이 디버깅, 재현 및 감사에 중요하게 됩니다. 마지막으로, 우리는 데이터 객체가 파이프라인을 따라 흐를 때 데이터 객체의 계보 또는 출처도 포함합니다. 따라서 파이프라인을 통해 전후로 추적하여 데이터와 코드의 변경에 따른 구성 요소의 출처와 실행 결과를 파악할 수 있습니다. 이는 파이프라인의 최적화나 디버그가 필요할 때 실로 중요하며, 이것이 없다면 최적화나 디버그에 상당한 어려움이 있을 것입니다.
메타데이터로 작동되는 기능 이제 메타데이터 저장소에 무엇이 저장되는지 알게 되었으므로, 이 저장소에서 얻는 기능상 이점에 대해 살펴봅시다. 첫째, 모든 데이터 아티팩트의 계보와 출처를 알고 있으면 파이프라인에서 앞쪽과 뒤쪽으로 추적할 수 있습니다. 예를 들어 모델을 훈련할 때 어떤 데이터를 사용했는지, 새로운 특징 추출이 평가 측정항목에 어떤 영향을 미쳤는지 등을 파악할 수 있습니다. 일부 사용 사례에서는 데이터의 출처와 결과를 추적하는 이 기능이 규정이나 법률에 정해진 필수 요건인 경우도 있습니다. 이 기능은 현재의 모델이나 현재의 결과를 위한 것만은 아니라는 점을 기억하세요. 시간이 흐르면서 새로운 데이터를 가져와 모델을 다시 훈련할 때 데이터와 결과가 어떻게 바뀔지 파악하는 데도 관심 있으실 것입니다. 종종 어제나 지난주에 실행한 모델 실행 결과와 비교해 결과가 개선되거나 악화된 이유를 알고 싶을 것입니다. 프로덕션 솔루션은 일회용이 아니라 필요한 만큼 오랫동안 사용되므로, 몇 개월이나 몇 년의 수명을 가질 수 있습니다. 또한 필요할 때만 구성 요소를 다시 실행하고 웜 부팅을 사용하여 훈련을 계속함으로써 파이프라인을 훨씬 더 효율적으로 만들 수도 있습니다. 개발자는 실행에 몇 시간이나 며칠이 걸릴 수 있는 큰 데이터세트를 종종 다루게 된다는 점을 유념하세요. 이미 하루 동안 모델을 훈련했는데 좀 더 훈련하고 싶은 경우 처음부터 다시 시작하는 대신 직전에 훈련을 끝낸 부분부터 시작할 수 있습니다. 메타데이터에 모델에 관한 정보를 저장해두었다면 훨씬 더 쉽습니다. 또한 입력 또는 코드가 바뀌었을 때 파이프라인의 다른 구성 요소만 다시 실행하여 이들을 훨씬 더 효율적으로 만들 수도 있습니다. 구성 요소를 다시 실행하는 대신, 캐시에서 이전 결과를 그냥 끌어올 수 있습니다. 예를 들어 파이프라인을 새로 실행할 때 훈련자의 매개변수만 변경되는 경우에는 파이프라인이 어휘와 같은 데이터 전처리 아티팩트를 재사용할 수 있으며, 데이터 볼륨이 크면 데이터 전처리 비용이 비싸다는 점을 고려하면 이를 통해 많은 시간을 절약할 수 있습니다. TFX와 MLMD를 사용할 때 별도의 구성 없이 이런 재사용이 가능한데, 더 간단한 '파이프라인 실행' 인터페이스가 표시되며 실행할 구성 요소를 수동으로 선택하는 문제를 걱정할 필요가 없습니다. 이 점 역시 처리 시간을 단축하는 데 도움이 됩니다. 구성 요소의 입력 데이터와 결과를 메타데이터에 저장했다면 훨씬 더 쉬울 것입니다.
구성 요소? 어떤 종류의 구성 요소일까요? 이제 오케스트레이터가 있으므로, TFX에 기본으로 제공되는 구성 요소에 대해 얘기해봅시다. 하지만 먼저 Apache Beam에 대해 얘기해봅시다. Apache Beam에 대해 먼저 설명한 후 기본 구성 요소에 대해 설명하겠습니다. 대량의 데이터, 특히 ML 작업 부하와 같은 계산 집약적 데이터의 분산 처리 문제를 다루려면 Apache Spark, Apache Flink 또는 Google Cloud Dataflow와 같은 분산 처리 파이프라인 프레임워크가 필요합니다. TFX 구성 요소는 대부분 여러 실행 엔진에서 실행 가능한 통합 프로그래밍 모델인 Apache Beam 상에서 실행됩니다. Beam 덕분에 개발자가 이미 가지고 있는 분산 처리 프레임워크를 사용하거나, 우리가 선택한 분산 처리 프레임워크를 강제로 사용하지 않고 개발자가 원하는 프레임워크를 선택할 수 있습니다. 현재, Beam Python은 Flink, Spark 및 Dataflow 실행기에 실행할 수 있지만, 새로운 실행기가 추가되고 있습니다. 또한 직접 실행기도 포함하고 있는데, 이 실행기를 사용하면 노트북과 같은 로컬 시스템에서 개발 중인 TFX 파이프라인을 실행할 수 있습니다. 기본 구성 요소

TFX는 처음 설치할 때 완벽히 구비된 기본 구성 요소 집합을 포함하는데, 각 구성 요소는 프로덕션 ML 파이프라인의 각기 다른 부분에 맞춰 설계되었습니다. 예를 들어 Transform 구성 요소는 Apache Beam을 사용하여 어휘를 생성하거나 기본 구성 요소 분석(PCA)을 실행하는 등, 특징 추출 변환을 수행합니다. 이와 같은 변환은 Dataflow를 사용하여 Flink나 Spark 클러스터 또는 Google Cloud에서 실행할 수 있습니다. Apache Beam의 이식성 덕분에, 코드를 변경하지 않고 이들 사이에서 이전할 수 있습니다. Trainer 구성 요소는 TensorFlow만 사용합니다. 놀라운 모델을 만들어 훈련할 생각만 하던 때를 기억하시나요? 그게 바로 여기서 사용할 코드입니다. 현재, TFX는 tf.estimators만 지원합니다. 호환성에 관한 다른 정보는 여기에 나열되어 있습니다. 어떤 구성 요소는 무척 단순합니다. 예를 들어 Pusher 구성 요소는 Python만 있으면 주어진 작업을 수행할 수 있습니다. 이 모든 것을 한데 모아서 오케스트레이터로 관리하면 TFX 파이프라인을 가지게 되는 것입니다. 한쪽에서는 데이터를 내부 데이터화하고 다른 쪽에서는 SavedModel을 배포 대상 중 하나 이상으로 푸시합니다. 여기에는 TensorFlow Hub, TensorFlow JS를 사용하는 자바스크립트 환경, TensorFlow Lite를 사용하는 네이티브 모바일 애플리케이션, TensorFlow Serving을 사용하는 서버 팜, 또는 위 모든 것이 포함됩니다. 이제 이들 각 구성 요소를 좀 더 자세히 살펴봅시다. 데이터 읽어오기 먼저 ExampleGen을 사용하여 입력 데이터를 내부 데이터화합니다. ExampleGen은 Beam에서 실행되는 구성 요소 중 하나입니다. 이 구성 요소는 지원되는 다양한 소스와 유형에서 데이터를 읽어와 훈련과 평가로 분할하고 tf.examples 형식으로 지정합니다. ExampleGen을 위한 구성은 매우 간단한데, 단 두 줄의 Python 코드에 불과합니다. 다음으로, StatisticsGen은 Beam을 사용하여 데이터를 완전히 한 차례 통과하는 것을 하나의 완전한 epoch로 만들고 각 특징에 대해 설명적인 통계 수치를 계산합니다. 이를 위해 StatisticsGen은 Jupyter 노트북에서 실행할 수 있는 시각화 도구를 위한 지원을 포함하는 TensorFlow Data Validation(TFDV) 라이브러리를 활용합니다. 이를 통해 데이터를 탐색하여 이해하고, 있을지 모를 문제를 찾을 수 있습니다. 이는 전형적인 데이터 랭글링 작업으로, 우리 모두가 모델을 훈련하기 위해 데이터를 준비할 때 수행하는 것과 같은 일입니다. 그 다음 구성 요소인 SchemaGen 역시 TensorFlow Data Validation 라이브러리를 사용합니다. 이 구성 요소는 StatisticsGen에 의해 생성된 통계 정보를 살펴보고 특징 값의 데이터 형식, 값의 범위, 카테고리를 포함하여, 특징의 기본 속성에 대한 추론을 시도합니다. 필요에 따라 스키마를 검사하고 오케스트레이션해야 합니다(예: 표시될 것으로 기대하는 새 카테고리 추가). 그 다음 구성 요소인 ExampleValidator는 StatisticsGen과 스키마(SchemaGen의 출력이거나 사용자 큐레이션의 결과일 수 있음)에서 통계 정보를 받으며 문제가 있는지 찾아봅니다. 이 구성 요소는 누락된 값 또는 스키마와 일치하지 않는 값, 훈련/서비스 제공 간의 편중, 데이터 드리프트를 포함한 다양한 이상 클래스를 찾으며, 찾은 내용에 대한 보고서를 생성합니다. 항상 새 데이터를 받게 되므로 문제가 발생할 때 이를 알아차려야 합니다. 특징 추출 Transform은 더 복잡한 구성 요소 중 하나로, 더 많은 구성뿐 아니라 추가 코드도 필요합니다. Transform은 Beam을 사용하여 특징 추출을 수행하는데, 특징에 변환을 적용해 모델의 성능을 향상합니다. 예를 들어 Transform은 어휘를 생성하거나 값을 분류하거나 입력에 대해 PCA를 실행할 수 있습니다. 개발자가 작성하는 코드는 모델과 데이터세트를 위해 어떤 특징 추출을 수행해야 하느냐에 따라 결정됩니다. Transform은 데이터를 완전히 한 차례 통과하는 것을 하나의 완전한 epoch로 만들고 두 가지 다른 종류의 결과를 생성합니다. 모든 예제에 대해 동일한 숫자인 특징의 중앙값 또는 표준편차 계산과 같은 작업의 경우, Transform은 상수를 출력합니다. 예제마다 다른 값을 정규화하는 것과 같은 작업의 경우, Transform은 TensorFlow Op를 출력합니다. 그런 다음, Transform은 이러한 상수 및 연산자를 이용해 TensorFlow 그래프를 출력합니다. 그래프는 밀폐되어 있으므로, 그와 같은 변환을 적용하는 데 필요한 모든 정보를 담고 있고 모델을 위한 입력 단계를 형성하게 됩니다. 즉, 훈련과 서비스 제공 사이에 동일한 변환이 일관되게 적용되어 훈련/서비스 제공의 편중을 없애준다는 뜻입니다. 대신에 훈련 환경에서 서비스 제공 환경 또는 애플리케이션으로 모델을 이동하고 두 장소에서 모두 같은 특징 추출을 적용하려는 경우 변환이 똑같기를 바라겠지만 때로는 똑같지 않다는 사실을 발견하게 됩니다. 우리는 그런 상황을 훈련/서비스 제공의 편중이라 부르는데, Transform은 개발자가 모델을 실행하는 어디서든 정확하게 같은 코드를 사용하여 이런 편중을 제거합니다. 모델 훈련 이제는 최종적으로 모델을 훈련할 준비를 마쳤으며, 모델 훈련은 전체 프로세스에서 사람들이 머신러닝을 생각할 때 흔히 떠올리게 되는 부분입니다. Trainer는 Transform에서 변환 그래프와 데이터를 가져오고 SchemaGen에서 스키마를 가져온 후, 작성한 모델링 코드를 사용하여 모델을 훈련합니다. 이것이 일반적인 모델 훈련이지만, 훈련이 완료되면 Trainer는 두 가지 다른 SavedModel을 저장합니다. 하나는 프로덕션 환경에 배포되는 SavedModel이고, 다른 하나는 모델의 성능 분석에 사용할 EvalSavedModel입니다. 단계 수나 웜 부팅의 사용 여부와 같은 Trainer를 위한 구성을 예상하실 것입니다. Trainer를 위해 만드는 코드가 모델링 코드이므로, 필요한 만큼 단순하거나 복잡하게 만들 수 있습니다. 훈련 프로세스를 모니터링하고 분석하려면 일반적인 방법과 똑같이 TensorBoard를 사용할 수 있습니다. 이 경우에는 현재 모델 훈련의 실행을 보거나 여러 차례의 모델 훈련 실행에서 얻은 결과를 비교할 수 있습니다. 이는 위에서 설명한 ML-Metadata 저장소이기에 가능한 일일 뿐입니다. TFX를 사용하면 이런 종류의 비교 작업을 상당히 수월하게 수행할 수 있다는 점을 자주 확인할 수 있습니다. 충분히 좋은가요? 모델 훈련을 마쳤는데, 결과가 어때 보입니까? Evaluator 구성 요소는 Trainer가 생성한 EvalSavedModel과 원본 입력 데이터를 받아 Beam과 TensorFlow Model Analysis 라이브러리를 사용하여 심층 분석을 수행합니다. 이는 전체 데이터세트에서 최상위 레벨 결과만 살펴보는 것이 아니라, 데이터세트의 개별 조각 수준에서 그보다 더 깊은 곳을 들여다보는 것입니다. 이는 모델의 각 사용자의 사용 환경이 개별 데이터 요소에 따라 결정되므로 중요한 사항입니다. 모델이 전체 데이터세트에서 잘 돌아갈 수도 있겠지만, 모델이 사용자가 제공하는 데이터 요소에서 제대로 작동하지 않을 경우 사용자 환경 역시 열악해집니다. 이 점에 대해서는 다음 게시물에서 자세히 다루겠습니다. 이제 모델의 성능도 살펴보았는데, 그대로 프로덕션 단계로 진행해야 할까요? 이미 프로덕션 환경에 있는 모델보다 나은가요, 아니면 못한가요? 단순히 새 모델이라는 이유로 성능이 나쁜 모델을 프로덕션 단계로 푸시하고 싶지는 않을 것입니다. 그래서 ModelValidator 구성 요소가 Beam을 사용해 앞서 설명한 비교 작업을 수행하는데, 개발자가 정의한 기준에 따라 새 모델을 프로덕션 단계로 푸시할지 여부를 결정합니다. ModelValidator가 새 모델이 프로덕션 단계로 넘어갈 준비가 되었다고 판단할 경우에는 Pusher가 모델을 배포 대상으로 실제로 푸시하는 작업을 수행합니다. 그와 같은 대상은 모바일 애플리케이션을 개발 중인 경우에는 TensorFlow Lite가 될 수 있고, 자바스크립트 환경에 배포 중인 경우에는 TensorFlow JS가 될 수 있으며, 서버 팜에 배포 중인 경우에는 TensorFlow Serving이 될 수 있습니다. 또는 위의 모두가 될 수도 있습니다. 이젠 어디로 가야 할까요? TFX 및 ML 파이프라인의 일반적인 기본 개요를 제공하고 주요 개념을 소개하는 것이 이 게시물의 목표였습니다. 이어지는 게시물에서는 필요에 따라 TFX를 확장할 수 있는 방법에 대한 논의를 비롯해, TFX에 대해 더 깊이 알아보도록 하겠습니다. TFX는 오픈소스이므로, Google에서는 소프트웨어 및 ML 커뮤니티에서 TFX의 개선에 도움을 받길 기다리고 있습니다. TFX 개발자 가이드도 참고해보세요. 관련 주제 TensorFlow Extended: 머신러닝 파이프라인과 모델의 이해(Google I/O’19) TFX: TensorFlow 기반 프로덕션 스케일의 머신러닝 플랫폼(KDD 2017) YouTube에 소개된 TFX