MLOps: 과대적합된 접근인 이유

최근 벤처 캐피털(VC) 조사에 따르면, 오늘날 수백 개의 회사가 자신들을 MLOps 카테고리의 일원으로 정의하고 있습니다. MLOps 시스템은 ML 실무자들이 개발부터 생산까지의 작업 생애 주기를 견고하고 재현 가능하게 관리할 수 있는 인프라를 제공합니다. 이러한 도구들은 E2E(End-to-End) 요구 사항을 다루거나 프로세스의 특정 단계 또는 아티팩트에 중점을 둡니다.

데이터의 세계는 임시 SQL 문을 주로 사용하는 분석가부터 고유한 알고리즘을 실행하는 박사 학위 소지자에 이르기까지 다양한 데이터 실무자로 구성되어 있습니다. 그렇다면 모든 것을 통제할 수 있는 하나의 DevOps 접근 방식이 있을까요? 아니면 ML은 고유한 접근 방식과 일치하는 인프라가 필요한 독특한 실무일까요? 이 질문에 답하기 위해 DevOps의 기초와 DataOps가 어떻게 DevOps 내에서 자연스럽게 전문성을 발휘하는지를 살펴보겠습니다. 그리고 ML의 필요를 이해하고, 그것이 DataOps와 어떻게 다를 수 있는지를 살펴보겠습니다.

마지막으로, ML 실무자가 얼마나 많은 인프라를 다루어야 하는지에 대한 질문을 다룰 것입니다. 이는 다른 데이터 실무자와 어떻게 다른지, 소프트웨어 엔지니어와 비교했을 때 어떤 위치에 있는지를 포함합니다. 이 질문은 실무자에게 제공되는 Ops의 필요성을 유도하기 때문에 중요한 질문입니다.

 

MLOps: 과대적합된 접근인 이유

 

DevOps란 무엇인가?

“DevOps는 소프트웨어 개발 및 IT 산업에서 사용하는 방법론입니다. DevOps는 소프트웨어 개발(Dev)과 IT 운영(Ops)의 작업을 통합하고 자동화하여 시스템 개발 생애 주기를 개선하고 단축하는 데 사용됩니다.”

DevOps는 애자일 소프트웨어 개발을 보완하며, 여러 DevOps 측면이 애자일 작업 방식에서 유래했습니다. 애자일 방법론은 제품 설계자와 사용자 간의 짧은 피드백 루프를 유지할 수 있는 능력에 의존합니다. 짧은 피드백 루프를 유지하려면 개발부터 생산까지의 효율적인 소프트웨어 제공 생애 주기가 필요합니다. 이를 유지하는 데 필요한 인프라와 도구는 DevOps 팀의 책임입니다.

따라서 효율성이 게임의 이름입니다. DevOps의 주요 구성 요소를 요약하면 다음과 같습니다:

1. 개발 환경: 협업과 새로운 또는 변경된 코드를 테스트할 수 있는 개발 환경.
2. 지속적 통합: 새로운/변경된 코드를 코드베이스에 지속적으로 추가하면서 품질을 유지할 수 있는 능력.
3. 스테이징: 새로운/변경된 기능을 포함한 시스템의 품질을 보장하기 위해 품질 테스트를 설정하고 실행하는 환경.
4. 지속적 배포: 새로운/변경된 기능을 생산 환경에 배포할 수 있는 능력.
5. 모니터링: 생산의 건강 상태를 관찰하고 문제 발생 시 롤백하여 빠르게 복구할 수 있는 능력.
6. 모듈화: 새로운 서비스와 같은 구성 요소를 쉽게 추가하면서 생산 안정성과 건강 모니터링을 유지할 수 있는 능력.

 

조직 구조에 따라 많은 직함이 있을 수 있지만(DevOps/SRE/Production Engineering), 그들의 책임은 동일합니다. 이 기능은 코드를 개발에서 생산으로 이동시키기 위한 인프라를 제공하는 책임이 있습니다. 제품 엔지니어링 팀은 그들의 전문성과 관련된 일부 도구를 선택하는 데 참여할 수 있습니다.

이 목표를 지원하고 애자일 프로세스를 허용하기 위해 소프트웨어 엔지니어는 Git과 같은 소스 제어 및 Jenkins와 같은 자동화 도구, 단위 및 통합 테스트 플랫폼과 같은 다양한 도구에 대해 훈련을 받습니다. 모든 소프트웨어 엔지니어는 애플리케이션의 생애 주기 관리를 이해하고 이를 지원하는 도구와 함께 작업하는 것이 가장 중요한 "현장에서의" 훈련이라는 것을 알고 있습니다. 이를 숙달하면 생산성이 크게 향상되며, 자연스럽게 일상 작업의 일부가 됩니다.

 

DataOps란 무엇인가?

DataOps는 데이터 집약적인 애플리케이션을 위한 DevOps입니다. 이러한 애플리케이션은 데이터 파이프라인에 의존하여 애플리케이션의 핵심인 데이터 파생물을 생성합니다. 데이터 집약적인 애플리케이션의 예로는 내부 BI 시스템, 디지털 헬스 애플리케이션, 자율 주행 자동차, 제조 라인 최적화, 생성 AI 엔진 등이 있습니다.

DataOps 팀의 목표는 DevOps 팀과 유사하지만, 데이터 실무자가 짧은 피드백 루프를 달성할 수 있도록 하는 기술 스택에 대한 전문 지식을 포함합니다. 이러한 기술에는 분산 저장, 분산 컴퓨팅 엔진, 분산 수집 시스템, 데이터 파이프라인을 관리하는 오케스트레이션 도구 및 데이터 집약적인 애플리케이션의 데이터 측면의 품질 테스트 및 생산 모니터링을 허용하는 데이터 관찰 도구가 포함됩니다.

요약하면, 이러한 전문 지식은 다음을 가능하게 합니다:

1. 개발 환경: 협업과 새로운/변경된 데이터 파이프라인을 테스트할 수 있는 개발 환경. 인프라에는 기능 코드뿐만 아니라 파이프라인 코드와 데이터 관리도 포함됩니다.
2. 코드의 지속적 통합: 새로운/변경된 코드를 코드베이스에 지속적으로 추가할 수 있는 능력.
3. 데이터의 지속적 통합: 새로운/변경된 데이터를 데이터 세트에 지속적으로 추가할 수 있는 능력.
4. 스테이징: 새로운/변경된 기능을 포함한 시스템의 품질을 보장하기 위해 코드와 데이터를 모두 테스트하는 환경.
5. 지속적 배포: 새로운/변경된 기능이나 데이터를 자동으로 생산 환경에 배포할 수 있는 능력.
6. 생산 건강 모니터링: 생산의 건강 상태를 모니터링하고 문제 발생 시 빠르게 복구할 수 있는 능력. 애플리케이션과 통합된 데이터를 모두 포함합니다.
7. 모듈화: 새로운 서비스/데이터 아티팩트를 쉽게 추가하면서 생산 안정성과 건강 모니터링을 유지할 수 있는 능력.

 

MLOps와 DataOps 비교

DevOps와 DataOps의 맥락에서 MLOps는 ML 생애 주기를 목표로 하는 DataOps의 한 사례입니다. 여기서 우리는 이 기사의 주요 질문에 답해야 합니다. MLOps는 정말로 DataOps와 다르며, 만약 그렇다면 어떻게 다른가요?

ML 기반 애플리케이션은 코드, 데이터 및 환경 버전 제어, 오케스트레이션 및 데이터 기술의 프로비저닝을 필요로 하기 때문에, 이 분야에서 그들의 요구 사항은 다른 데이터 실무자와 유사하며, 여기 정의된 DataOps 내에서 잘 맞습니다. 데이터 품질 도구와 데이터 모니터링 도구에 대해서도 마찬가지입니다. 이러한 도구는 일부 테스트에서 ML 특정일 수 있지만, 이는 C++ 개발자의 도구와 자바스크립트 개발자의 도구의 차이와 다르지 않습니다. 우리는 이를 DevOps의 다른 카테고리로 정의하지 않습니다.

 

과대적합된 MLOps의 원인

많은 데이터 과학자들의 인프라 요구 사항에 대한 논의에서 기본적인 소프트웨어 기술에 대한 질문이 제기됩니다. "데이터 과학자가 Git 개념을 이해할 수 없다고 기대하지 마세요", "데이터 과학자는 적절한 로깅을 가진 코드를 작성할 수 없어요, 그들은 소프트웨어 엔지니어가 아닙니다"와 같은 발언들. 이러한 사고 방식은 MLOps를 과대적합하게 만들었다고 생각합니다.

데이터 과학자는 고도로 숙련된 개인으로, 버전 제어의 개념을 빠르게 이해하고 CI/CD 자동화 서버 작업의 복잡성을 숙달할 수 있습니다. 신입 소프트웨어 엔지니어가 현장에서 이 작업을 배우듯이, 데이터 과학자도 상업적 가치를 제공하기 위해서는 이를 배워야 한다고 생각합니다.

 

결론

데이터 운영이 광범위한 조직(곧 모든 조직이 될 것입니다)은 DevOps 팀이 고품질의 일반 데이터 인프라와 모든 데이터 실무자를 위한 모범 사례를 제공할 수 있도록 데이터 전문성을 갖추어야 하며, 모든 데이터 실무자가 이 인프라를 최적으로 관리할 수 있도록 잘 교육받도록 해야 합니다. 대기업에서는 이를 전담하는 부서가 있을 수 있습니다.

좋은 실습과 내부 교육은 결국 데이터 실무자의 접근성을 제한하는 과대적합된 도구의 필요성을 제거할 수 있습니다. 단기적으로 단순한 시스템에 대해 모든 요구를 충족하는 원스톱 샵을 제공할 수 있지만, 장기적으로는 심화된 전문가 시스템의 깊이가 필요해집니다. 예를 들어, 오케스트레이션의 경우 E2E 도구를 사용하는 대신 Airflow, Prefect, Dagster와 같은 강력한 오케스트레이션 시스템으로 이동할 것입니다.