컴퓨터 비전 데이터를 위한 DataOps의 모든 것 Part1
*본 글은 Superb AI의 James Le가 작성한 ‘Part 1: An Overview of DataOps For Computer Vision’의 번역본입니다.
일반적으로 머신러닝 애플리케이션, 특히 컴퓨터 비전 애플리케이션 모델 학습은 데이터에 크게 의존합니다. 상용화 시스템에서는 추론을 수행하기 위해 입력 데이터가 공급되는데요. 이 추론의 결과값은 다시, 이어서 진행되는 반복 학습의 입력값으로 투입되어 훈련 데이터의 기초로 사용됩니다. 이렇게 유기적으로 서로 영향을 주는 데이터 플라이휠 구조에서는 낮은 품질의 데이터는 시스템 전체의 품질에 막대한 부정적 영향을 미칠 수 있습니다. 즉, 데이터 품질을 신경쓰지 않은 컴퓨터 비전 시스템이 프로덕션 초기단계에 투입되었다면 시간이 지남에 따라 이 시스템의 품질이 저하되는 것은 자명합니다.
1. 데이터 분석을 위한 DataOps는 무엇일까?
애자일 개발 및 DevOps 기술은 지난 20년 동안 소프트웨어 산업에 엄청난 혁명을 가져 왔습니다. DevOps 우선 기업은 소프트웨어 버그 및 결함 수를 줄이는 동시에, 매일 또는 매시간 소프트웨어를 배포합니다. DevOps와 소프트웨어 개발팀의 고성과(high performance)사이의 상관 관계에 대한 과학적 연구 사례가 있습니다.
그렇다면 DataOps와 DevOps 사이의 가장 큰 차이점은 무엇일까요? DevOps는 소프트웨어 개발자에 의한 소프트웨어 배포 시스템을 탈바꿈시킵니다. 반면에 DataOps는 데이터 분석가와 데이터 엔지니어에 의한 정보시스템과 분석 모델을 바꿉니다.
DevOps vs DataOps vs MLOps
(Source: DataOps - Adjusting DevOps For Analytics)
DevOps의 목표는 엔지니어링과 IT 운영, 그리고 QA 간의 프로세스를 자동화하여 소프트웨어 개발 및 릴리즈에 투입되는 비용과 시간을 줄이는 것입니다. 여기에 DataOps를 더할 경우, 이 프로세스에 데이터라는 한 층이 더 생기게 됩니다. DataOps의 목표는 데이터 엔지니어링, 데이터 분석과 IT 운영의 긴밀한 협업 구조를 통해 raw data 수집, 데이터 파이프라인의 구축과 실천가능한 유의미한 인사이트를 얻는 부분에서의 효율성을 극대화하는 것입니다. 머신러닝 애플리케이션을 위한 데이터 사용에 적용한다면, 데이터 사이언스와 머신러닝 엔지니어링을 일명 MLOps로 알려진 이 방정식에 적용해야 하는 것이죠.
DevOps가 소프트웨어 엔지니어링팀에 엄청난 영향을 미친 것처럼, DataOps는 데이터 분석팀이 어떻게 기능하는지를 근본적으로 재정의합니다. DataOps가 없다면 데이터 파이프라인 간 연결고리가 생길 수 없고, 데이터 생산자와 데이터 소비자 간의 협업 또한 불가능합니다. 이는 결국 수작업과 중복 코드의 발생, 오류의 증가로 인해 시장 진출이 늦어지는 문제로 이어질 것입니다.
2. 왜 컴퓨터 비전을 위한 DataOps인가?
컴퓨터 비전(일반적으로 ML)을 사용하여 운영 및 의사 결정 프로세스를 개선하려는 회사의 경우, 데이터 생산자와 데이터 소비자의 생산성 향상에 도움이 되는 도구를 채택하는 것이 중요합니다. 이러한 도구는 데이터를 신뢰할 수 있게 해주고 데이터의 발견과 재사용 또한 용이하게 해줄 것입니다.
그럼 지금부터 컴퓨터 비전을 위한 DataOps가 중요한 세 가지 이유에 대해 알아보겠습니다.
첫 번째 이유 - 데이터가 모델보다 더 중요하다
대부분의 컴퓨터 비전을 포함한 실제 머신러닝 프로젝트에서는 데이터가 핵심입니다! 더 나은 데이터를 얻는 것이 성능 향상 측면에서 가장 좋은 방법일 수 있습니다. 이런 데이터에 대한 인식을 제고하자는 주장은 모델링 구성 요소를 강조하는 학문적 머신러닝과는 대조되는 내용이죠.
Keras의 창시자 Francois Chollet의 코멘트
데이터와 관련된 달성하기 쉬운 목표 중 중 우리가 놓치고 있는 것은 무엇일까요? Shreya Shankar는 13개의 머신러닝 강의를 모두 듣고 나서, ‘좋은 모델이 무엇일까’라는 질문에는 답을 찾을 수 있었으나 실시간으로 변하는 데이터의 반복작업은 어떻게 해야하는지 알 수 없었다고 말하며 “반복적으로 진행하는 데이터작업”이 모델링과 동등하거나 혹은 더 중요하게 다뤄져야 한다고 주장합니다. 이는 손실 함수를 조정하는 것이 아니라, 문제에 대한 완전히 새로운 측면의 인사이트를 주는 또 다른 데이터를 찾는 것을 의미하는데요. 모델 성능이 나쁠 때마다 모델 구조를 조사하고 하이퍼 매개 변수를 조정하는 데에만 의존하는 것이 아니라, 데이터 성능 저하의 근본적인 원인을 찾기 위한 노력도 기울여야 합니다.
DataOps는 (1) 라벨링 할 가치가 있고 (2) 주어진 작업과 관련하여 가장 중요한 가치를 산출하는 데이터 포인트에 대한 탐색/시각화와 샘플링/큐레이팅, 수집/라벨링하는 데 도움을 줍니다. 데이터 관찰 가능성 사례(섹션 3의 네 번째 원칙 참조)를 활용하면 번거로움 없이 이런 작업을 진행할 수 있습니다.
두 번째 이유 - 비정형 데이터 준비의 어려움
오류가 많은 데이터 라벨은 많은 오류를 가진 ML 모델을 낳기 마련입니다. 여기에 데이터 소스가 많아지고, 최신 데이터의 유동적인 속성과 다운 스트림 사용으로 인한 복잡성의 증가는 데이터와 라벨의 품질을 보장하기 어렵게 만드는데요. 컴퓨터 비전은 비정형 데이터를 다루는데, 비정형 데이터는 스키마가 없고 예전 형식의 데이터 스토리지, 처리 및 분석과 호환되지 않습니다.
컴퓨터 비전 분야에서 방대한 양의 비정형 데이터를 준비하는 데에는 몇 가지 어려움이 있습니다. 예측 불가능한 속성을 가진 이미지 및 비디오 데이터의 처리, 라벨링 인력 관리 및 충분한 라벨링 예산 확보, 데이터 개인 정보 보호 등과 관련한 어려움이 있습니다. 모델링 구성 요소를 수행하기 전 라벨링 된 데이터의 정확도와 품질에 대한 검사 또한 필요합니다. 데이터가 훈련 데이터의 한 부분으로 활용될 수 있는지는 엄격한 데이터 처리, 데이터 변환, 데이터 보강, 데이터 시각화 및 라벨 유효성 검사를 통해서만 확인할 수 있습니다.
DataOps는 팀이 지속적인 테스트를 통해 관련 없는 데이터 포인트를 필터링하여 가치가 높은 데이터를 수집하고 귀중한 데이터셋을 만드는 데 시간을 할애하도록 돕습니다(섹션 3의 세 번째 원칙 참조). CI/CD를 사용하면 데이터 엔지니어들은 데이터 준비 워크플로우를 원활하게 자동화 할 수 있습니다(섹션 3의 두 번째 원칙 참조).
세 번째 이유 - 컴퓨터 비전 제품 구축의 반복적 특성
Taivo Pungas는 알고리즘 개발 루프와 제품 개발 루프를 포함하는 알고리즘 제품 구축의 두 루프에 대해 훌륭한 강연을 한 바 있습니다.
알고리즘 개발 루프는 다음의 과정으로 이루어집니다. (1) 컴퓨터 비전 전문가가 알고리즘 프레임워크를 활용하여 알고리즘 구축하고, (2) 프로덕트 오너가 정한 어노테이션 스펙에 견주어 ML 엔지니어가 구축한 대규모 테스트 도구를 통한 데이터셋 측정을 마칩니다. 그리고 자체 검수 도구로 리뷰하고 분석하여 실패로 부터 배우는 과정을 반복합니다.
제품 개발 루프는 (1) ML 엔지니어가 서비스와 인프라 프레임 워크를 사용하여 제품을 구축한 후, (2) 모니터링 로깅 도구를 통해 프로덕션 단계의 제품을 측정하고, (3) 컴퓨터 비전 전문가가 실시간 성능 데이터의 대시 보드와 분석을 통해 실패사례를 수집하고 또 거기서 배우는 순환 프로세스를 수반합니다.
프로덕트와 알고리즘의 반복적인 개발 과정
데이터 중심적 사고방식을 적용할 경우, DataOps를 통해 아래에 제시된 두 가지 방법을 통해 두 순환 작업을 함께 작동시킴으로써 속도를 높일 수 있습니다.
- ML 연구원이 구축한 알고리즘을 ML 엔지니어에게 제공하여 컴퓨터 비전 제품에 통합합니다. (❸단계부터 ❹단계까지).
- 한 번의 순환을 거쳐 실패 use case로 부터 학습을 한 후, ML 연구원은 오류가 발생하기 쉬운 어려운 데이터 포인트만 샘플링하고 어노테이션을 진행합니다. 그런 다음 새 데이터 포인트와 기존 데이터 포인트를 비교 측정 후 다음 알고리즘 개발 반복작업에 투입합니다. (❻단계부터 ❶단계까지)
소프트웨어 엔지니어링 모범 사례는 두 단계가 문제 없이 표준화되어 수행될 수 있도록 보장합니다(섹션 3의 첫 번째 원칙 참조)
3. 컴퓨터 비전을 위한 DataOps 원칙
데이터가 제품에 이르기까지의 여러 단계들이 효율적으로 진행되는 데 있어 DataOps가 핵심적 역할을 한다는 것을 파악했다면, DataOps의 주요 원칙을 이해하는 것은 필수적입니다. Vijay Karan(Head of Data engineering at SODA)은 모든 데이터 분석 프로젝트에는 여섯 가지 DataOps 원칙이 있다고 설명합니다. 아래에서 그가 언급한 이 원칙들을 설명하고, 이러한 원칙들이 컴퓨터 비전 프로젝트에 어떻게 적용될 수 있는지 함께 살펴보면 좋을 자료를 소개해드리겠습니다.
첫 번째 원칙 - 소프트웨어 개발 수명주기 지침 준수
첫 번째 원칙은 개발을 위한 최적의 사례를 구현하는 것입니다. 데이터 엔지니어와 데이터 분석가, 그리고 데이터 사이언티스트는 다양한 배경을 가지고 있습니다. 데이터 엔지니어링과 데이터 과학 부분에서 코딩의 비중이 아주 높다는 점을 고려할 때, 이러한 분야의 실무자는 소프트웨어 개발 수명 주기 지침을 따르는 것이 중요합니다.
실제로 이런 지침에는 Git를 사용하여 코드의 변경사항을 추적하는 버전 컨트롤, 코드 요청을 푸싱(pushing)하거나 풀링(pulling)하는 코드 리뷰, 유닛 테스트, Docker 이미지를 포함하는 아티팩트 관리, 배포 자동화와 Terraform을 사용하여 코드로 인프라 버전을 유지하거나 변경하는 코드형 인프라가 포함됩니다. 이런 소프트웨어 개발 모범 사례를 컴퓨터 비전에 적용하는 것은 간단한데요. 이를 시작하기 위해 먼저 컴퓨터 비전 시스템의 소프트웨어 엔지니어링과 관련해 두 파트로 구성되어 있는 CVPR 2018 튜토리얼(파트1 / 파트2)을 보는 것을 추천합니다.
두 번째 원칙 - 지속적인 통합과 배포
두 번째 원칙은 초기 소스에서 최종 배포까지 이르는 모든 데이터의 흐름을 자동화하고 조율하는 것입니다.
여러분은 Jenkins 또는 CircleCI와 같은 툴로 CI/CD 파이프라인을 만들어 배포를 자동화하고 수동으로 진행하는 데이터 랭글링(목적에 맞게 데이터의 형식을 변환하는 것)은 피하고 싶을 것입니다. Apache Airflow와 같은 워크플로우 관리도구를 역채움(backfilling : 과거의 데이터를 채워넣기)과 스케줄링, 파이프라인 메트릭 수집 등의 작업에 사용하여 데이터를 흐르게 함으로써 이를 실현할 수 있습니다. 오픈 소스 툴로는 Luigi와 Prefect가 있습니다.
머신러닝을 위한 CD(지속적 배포)
컴퓨터 비전에 CI/CD를 적용하는 것도 어렵지 않습니다. 이를 시작하기 위한 좋은 리소스는 ML 애플리케이션에 CD의 원칙과 성공사례를 담은 글인 ThoughtWorks의 CD4ML 입니다. 또한 Algorithmia의 글에서도 소스, 빌드, 테스트와 배포를 포함하는 머신 러닝을 위한 CI/CD 파이프 라인의 네 가지 핵심 단계를 설명하고 있는데요. 훌륭한 CI/CD 파이프 라인의 주요 특징과 이점은 속도와 신뢰성, 그리고 정확도입니다.
세 번째 원칙 - 지속적인 테스트
세 번째 원칙은 데이터 생애 주기의 모든 단계에서 데이터 품질을 테스트하는 것입니다. 데이터는 모든 데이터 프로젝트의 구성 단위이므로, 전체 데이터 생애 주기의 다양한 단계에서 데이터를 검증하는 것이 필요합니다.
실제로는 데이터 유닛 테스트 또는 스키마/ 스트리밍/ SQL 테스트 작성을 통해 소스에서 데이터를 테스트하고 싶을 겁니다(파이프 라인이 연결된 데이터 소스에 따라 다름). 그런 다음 데이터가 소스에서 스테이징 환경(운영환경으로 넘어가기 전 여러가지 성능이나 기능을 검증해볼 수 있도록 운영환경과 비슷하게 구성해 놓은 환경)으로 이동해서 변환이 진행되고, 프로덕션으로 승격되어 데이터 웨어하우스로 이동할 때, 데이터의 유효성을 검사하려 할 것입니다. 다음으로 앞서 언급한 단계에서 메트릭을 캡쳐 및 게시하고, 마지막에는 이 다음의 프로젝트들에서도 테스트 도구를 재사용하고자 할 것입니다. ‘했던 일을 반복하지 말라'는 원칙으로, 이것이 소위 데이터팀 전체에 표준화된 공통 테스팅 프레임워크가 될 수도 있습니다. 이와 관련하여 잘 설계된 오픈 소스로는 Great Expectations가 있습니다.
컴퓨터 비전은 지속적인 테스트를 진행하기가 좀 더 까다로운데요. 빅데이터 라벨링의 저주를 감안하면, 어떻게 라벨의 품질을 테스트 할 수 있을까요? 우선 데이터 라벨링의 품질과 정확성은 동일하지 않다는 것에 주목해야 합니다. 데이터셋의 품질은 전체 데이셋의 정확성에 관한 것으로, 여기에는 라벨의 일관성 외에도 raw data 분포와 같은 항목이 포함됩니다. 모든 라벨러들의 작업이 동일한가요? 라벨링이 전체 데이터셋에 걸쳐 일관성을 가지고 있습니까? Human-in-the-loop 구성 요소가 ‘사람=라벨러'라는 것을 감안한다면, 라벨 품질에 대한 공통 테스트 프레임워크를 구축하는 것은 결코 쉬운 일이 아닙니다.
네 번째 원칙 - 관찰가능성(Observability)의 향상
네 번째 원칙은 데이터 흐름 전반에 걸친 품질과 성능 메트릭을 모니터링하는 것입니다. DevOps에서는 관찰가능성이라는 말이 자주 언급되는데요. 추적, 로그, 메트릭을 통해 시스템의 가시성을 확보하여 문제를 맥락적 차원으로 발견할 수 있게 도와주는 것을 의미합니다. DataOps에서도 적용되는 이 원칙의 중요한 점은 데이터 흐름 전반에 걸쳐 일관적인 품질 메트릭과 성능 메트릭을 가질 수 있어야 한다는 점일 것입니다.
실전에서는, 데이터 품질 메트릭을 정의하는 것이 첫 단계입니다. 데이터 품질 메트릭은 기술적 메트릭(예: 데이터 흡수 단계(데이터를 획득해서 저장소에 저장되도록 하거나 바로 쓸 수 있는 형태로 임포트 되는 과정) 이후 데이터 스키마 행의 개수), 비즈니스에 의한 기능 메트릭, 예상 SLA에 도달하는 데 걸리는 시간을 파악하기 위한 성능 메트릭으로 나눌 수 있습니다.
두 번째 단계는 Looker나 Power BI를 사용하여 이런 메트릭을 시각화하고, 이를 데이터 이해 관계자들에게 전달하여 문제 해결에 인사이트를 얻는 모니터링이 가능하도록 하는 것입니다. Monte Carlo Data, Accel Data 및 Datafold 같은 SaaS 솔루션을 활용한다면 좀 더 정교한 데이터 관찰가능성 원칙을 지킬 수 있을 것입니다.
What Is Data Observability?
컴퓨터 비전에서의 관찰 가능성은 데이터 관찰 가능성과 모델 관찰 가능성의 결합이라고 볼 수 있습니다.
- 데이터 관찰 가능성 :
Monte Carlo는 데이터 관찰 가능성의 다섯 가지 특징을 최신성, 분포, 크기, 스키마, 리니지로 꼽았습니다. 그리고 각각의 특징을 컴퓨터 비전과 관련지어 해석해보자면 다음과 같이 설명할 수 있습니다.
- 최신성 : 라벨이 최신으로 업데이트 되는지
- 분포 : 라벨이 이미지나 비디오에서 어떻게 분포하는지
- 크기 : 이미지의 수가 얼마나 큰지
- 스키마 (데이터베이스에서 자료의 구조, 자료의 표현 방법, 자료 간의 관계를 형식 언어로 정의한 구조) : 라벨링의 시각화와 포맷화가 어떻게 적용되는지
- 리니지(데이터의 흐름을 시각화 해놓은 것): 이미지 데이터의 버전관리
- 모델 관찰 가능성 :
Arize AI는 모델 관찰 가능성을 모델 학습과 유효성 검사, 프로덕션 환경에서 모델 평가를 수집한 다음, 분석과 함께 입력하여 이런 포인트들을 연결하여 ML 엔지니어링 문제를 해결하는 프로세스로 정의합니다. 목표는 모델 액션의 근원을 이해하고 워크플로우를 구축하여 개선하는 것입니다. 이는 한 모델의 출력 예측이 다음 모델 반복을 위한 학습 데이터로 사용되는 컴퓨터 비전 워크플로우가 됩니다.
다섯 번째 원칙 - 데이터 의미론에 대한 주목
다섯 번째 원칙은 공통 데이터 모델( 여러 기관에 흩어져 있는 데이터를 공통된 형태로 만들수 있도록 해주는 데이터 모델을 의미) 및 메타데이터 모델을 구축하는 것입니다. 이는 DataOps를 만들고 가치를 신속하게 제공하는 데 많은 도움이 됩니다. 하지만 대부분의 조직들은 데이터를 서로 다른 소스로부터 제공받고 모두 다른 각도에서 시스템을 바라보기 때문에 큰 문제에 직면하게 되는데요.
소프트웨어 개발의 도메인 주도 설계(DDD) 컨셉을 차용한다면, 여러분은 서로 다른 영역에서 사용하는 비슷한 용어를 식별하고 이를 엔지니어링, 데이터, 그리고 비즈니스 등 서로 다른 팀에게 공유할 수 있습니다. dbt와 같은 툴을 사용하면 다양한 데이터 소스를 결합하여 공동 데이터 웨어하우스에 넣을 수 있는데요. 기업 중심의 접근 방식은 데이터 카탈로그에 투자하여 데이터 조직(SaaS의 경우 Atlan, Atlation 및 Collibra, 오픈 소스의 경우 Amundsen, DataHub 및 Marquez) 전반에 걸쳐 데이터 지식을 보다 폭넓게 공유하는 것입니다. 데이터 카탈로그를 통해 각각의 데이터 오너는 자신이 무엇을 제공받았는지를 정확하게 알 수 있습니다.
컴퓨터 비전의 경우, 이는 구조, 품질, 정의 및 사용법에 대한 주석을 포함하여 다양한 소스의 모든 이미지 및 비디오 데이터 저장소를 만드는 것을 의미합니다. 이상적으로는 사용자가 데이터 자체와 함께 JSON 오브젝트 같은 메타데이터에 액세스할 수 있는데요. 제 생각에 비정형 데이터에 대한 버전 관리는 여전히 어렵습니다. DVC 및 Pachyderm과 같은 정형데이터 사례에 더 중점을 두는 것으로 보입니다. 새롭게 떠오르는 Data Lakehouse는 비정형 데이터를 저장, 정제, 분석, 그리고 그런 데이터에 접근하도록 하는 것은 가능하지만, 버전 제어기능은 아직 없습니다. 더 나아가 데이터 리니지를 그래픽으로 표현하는 정교한 솔루션은 미래의 데이터 관리 및 준수 문제를 간소화할 수 있을 것입니다.
여섯 번째 원칙 - 다기능(Cross-Functional)팀
여섯 번째 원칙은 데이터 이해 관계자 간의 협업을 강화하는 것입니다. 데이터팀을 구성하는 방법에는 여러 가지가 있지만, 가장 좋은 방법은 모든 팀이 데이터 사고를 할 수 있도록 하는 것입니다. 이는 핵심 기능에 따라 팀을 구분하지 않고 다기능팀(다양한 직무가 목적 중심으로 혼합된 조직)을 구성하려는 애자일 원칙과 유사합니다. 이러한 팀은 중요한 메트릭과 KPI를 함께 정의하고 비즈니스 목표 아래 공동의 목적을 세워 공유합니다. 또한 데이터 사용에 대한 잠재적인 병목 현상을 제거하기 위해 팀내에서 셀프 서비스 데이터 모니터링(Soda Data)을 설치하고 모든 구성원이 데이터에 쉽게 접근할 수 있도록 합니다.(Immuta Data)
비즈니스 요구 사항을 중심으로 한 DataOps의 이상적인 팀 구성
컴퓨터 비전 애플리케이션을 구축하는 동안에는 라벨러와 라벨링 프로젝트 매니저 같은 데이터 생산자, 데이터 엔지니어 및 ML 엔지니어를 예로 들 수 있는 데이터 소비자, 그리고 소프트웨어 엔지니어와 IT 운영 전문가와 같은 DevOps 실무자를 주요 이해관계자라고 할 수 있습니다. 저는 그들 사이의 협업 프로세스가 대부분의 조직에서 여전히 임시방편으로 진행되고 있긴 하지만, 이를 보다 효율적으로 만들 수 있는 도구를 활용할 여지가 있다고 믿습니다.
DataOps는 컴퓨터 비전 파이프라인 및 애플리케이션 개발에 엄격한 적용과 재사용, 그리고 자동화를 가져오는 데 도움을 줍니다. DataOps는 데이터 준비 프로세스를 자동화하여 민첩하며 고통스럽지 않은 것으로 변화 시켜 주는데요. Superb AI는 이런 DataOps의 원칙을 강력하게 지지합니다. Superb AI Suite는 컴퓨터 비전팀의 협업 및 자동화를 촉진하여, raw data 수집에서 라벨링 된 데이터 전달에 이르기까지, 시간과 비용 측면에서 효율적인 데이터 라벨링 파이프라인의 구축을 가능하게 합니다.
‘컴퓨터 비전을 위한 DataOps’ 시리즈 2편에서는 이미지/비디오 데이터 준비의 주요 과제와 이를 해결하기 위해 Superb AI에서 "준비 중인" DataOps 파이프라인을 소개해드리겠습니다.