2021.11.25

모델만 잘 만들면 끝?··· 데이터 과학을 위한 ‘CI/CD’가 필요하다 

Michael Berthold | InfoWorld
데이터 과학 모델을 프로덕션 환경으로 옮기는 것은 애플리케이션 배포와 상당히 유사하다. 하지만 간과해서는 안 되는 중요한 차이점이 있다. 

애자일 프로그래밍은 개발팀이 소프트웨어를 프로덕션 환경으로 릴리즈하고, 피드백을 수집하며, 기본 요건을 개선하는 데 가장 많이 사용하는 방법론이다. 하지만 애자일이 실제로 작동하려면 수정된 애플리케이션을 자동으로 빌드하고, 프로덕션 환경으로 릴리즈할 수 있는 프로세스가 필요하다. 이를 ‘CI/CD’라고 한다.

‘CI/CD’를 통해 소프트웨어 팀은 실제 사용자를 정기적으로 참여시키고, 피드백을 반복적으로 통합하여 초기 요건을 놓칠 위험 없이 복잡한 애플리케이션을 구축할 수 있다.
 
ⓒGetty Images

데이터 과학도 비슷한 문제에 직면해 있다. 데이터 과학팀이 초기 요건을 충족하지 못할 위험은 현재로선 덜하지만 데이터 과학을 프로덕션 환경에 자동으로 배포하는 것과 관련된 문제가 많은 데이터 과학 프로젝트를 서서히 중단시킬 수 있다. 

첫째, IT가 프로덕션 시스템에 무엇이든 투입해야 하는 경우가 너무 많다. 둘째, (만약 있다고 한다면) 유효성 검사가 규정되지 않은 수작업인 경우가 일반적이다. 셋째, 프로덕션 데이터 과학 프로세스를 안정적으로 업데이트하기 어려운 까닭에 이는 완전히 새로운 프로젝트로 취급된다.

데이터 과학이 소프트웨어 개발에서 무엇을 배울 수 있을까? 여기서는 소프트웨어 개발에서의 CI/CD, 데이터 과학과 유사한 부분 그리고 데이터 과학자가 다르게 접근할 필요가 있는 부분을 살펴본다.

소프트웨어 개발에서의 CI/CD
소프트웨어 개발에서 반복 가능한 프로덕션 프로세스는 꽤 오래전에 등장했다. 오늘날 CI/CD는 사실상 ‘표준’이나 마찬가지다. 대규모 소프트웨어 개발은 통상 고도로 모듈화된 접근 방식을 적용한다. 개발팀은 코드 베이스 일부를 작업하고, 해당 모듈을 독립적으로 테스트한다(일반적으로 해당 모듈에 고도로 자동화된 테스트 케이스를 사용한다).

CI/CD의 지속적인 통합 단계에서 코드 베이스의 여러 부분이 연결돼 자동으로 전체 테스트를 거친다. 이러한 통합 작업은 이상적으론 자주(지속적으로) 수행된다. 개별 모듈에는 영향을 미치진 않지만 전체 애플리케이션을 중단시킬 수 있는 문제를 즉시 찾을 수 있기 때문이다. 

전체 테스트 범위를 확보한 이상적인 상황에서는 모듈 변경으로 발생하는 문제가 거의 즉시 포착된다고 할 수 있다. 하지만 실제로는 완전한 테스트 설정은 존재하지 않으며, 복잡한 통합 테스트는 하루 한 번만 실시할 수 있는 게 현실이다. 

CI/CD의 두 번째 부분인 지속적인 배포는 새로 구축된 애플리케이션을 프로덕션 환경으로 옮기는 것을 말한다. 분당 수만 개의 데스크톱 애플리케이션을 업데이트하는 것은 거의 불가능하다.

하지만 클라우드 기반 도구가 점점 더 많이 사용되고 있고, 서버 기반 애플리케이션은 훨씬 더 자주 변경 사항을 롤아웃하고 업데이트를 완료할 수 있다. 버그가 있는 애플리케이션을 롤아웃했을 때도 신속하게 복구할 수 있다. 그다음 배포한 애플리케이션을 지속적으로 모니터링해 잠재적인 문제를 찾게 되는데, 테스트를 제대로 수행했다면 문제가 적게 발생한다.

데이터 과학에서의 CI/CD
데이터 과학 프로세스는 여러 팀이 독립적으로 구축하는 게 아니라 데이터 엔지니어, 머신러닝 전문가, 시각화 전문가 등 여러 전문가가 협력해 구축한다.

여기서 데이터 과학 모델 생성은 ‘ML 알고리즘 개발(소프트웨어 엔지니어링)’이 아니라 ‘ML 알고리즘을 데이터에 적용하는 것’과 관련 있다는 점을 유념하는 게 중요하다. 이런 알고리즘 ‘개발’과 ‘활용’의 차이가 혼란을 야기하는 경우가 많다. 

또 데이터 과학에서 ‘통합’은 기본 요소를 하나로 모으는 것을 의미한다. 설명하자면, 데이터 과학의 통합은 특정 툴킷의 적절한 라이브러리가 최종 데이터 과학 프로세스와 연결되도록 하고, (데이터 과학 생성 도구에서 추상화를 허용한다면) 이러한 모듈의 적절한 버전도 연결돼야 한다.

통합 단계에서 소프트웨어 개발과 데이터 과학 사이에 한 가지 큰 차이점이 있다. 소프트웨어 개발에서는 애플리케이션을 구축해 배포한다. 통합 과정에서 일부 디버깅 코드를 제거할 순 있지만 최종 제품은 개발 단계에서 구축한 것이다. 하지만 데이터 과학은 그렇지 않다.

데이터 과학은 생성 단계에서 어떤 데이터를 어떻게 결합하고 변환할지 최적화하는 복잡한 프로세스를 구축한다. 이 데이터 과학 모델 생성 프로세스는 모델의 다양한 유형과 매개변수에 따라 반복되며, 이러한 모델 중 일부를 서로 다르게 결합할 수도 있다. 

통합 과정에서 이런 최적화 단계의 결과물이 데이터 과학 프로덕션 프로세스에 결합된다. 즉, 개발 단계에서는 기능을 생성하고 모델을 학습시킨다. 그리고 통합 단계에서 최적화된 기능 생성 프로세스와 학습시킨 모델을 결합한다. 이러한 통합이 프로덕션 프로세스를 구성한다.

그렇다면 데이터 과학에서 지속적인 배포는 무슨 의미일까? 프로덕션 프로세스, 즉 배포해야 하는 통합의 결과물은 데이터 과학 모델 생성 프로세스와 다르다. 실제 배포는 소프트웨어 배포와 유사하다. 

데이터 과학 프로덕션 프로세스에서 또 흥미로운 요건은 모델 성능을 지속적으로 모니터링해야 한다는 것이다. ‘현실’이 변하기 때문이다. 변경 감지는 데이터 과학 프로세스에서 매우 중요하다. 

따라서 프로덕션 프로세스의 성능이 저하될 때, 이를 감지하는 메커니즘을 마련해야 한다. 그다음 모델을 자동으로 재학습시켜 재배포하거나, 데이터 과학팀이 새로운 데이터 과학 프로세스를 만들 수 있도록 문제를 알린다. 이를 통해 데이터 과학 CI/CD 프로세스를 새로 트리거할 수 있다. 

소프트웨어 애플리케이션을 모니터링하면 코드가 자동으로 변경되고 재배포되지 않지만 이는 데이터 과학에서 매우 일반적인 요건이다. 이 자동 통합과 배포에 필요한 유효성 검사 및 테스트 설정은 자동 변경의 복잡성에 따라 달라진다. 

데이터 과학에서 테스트와 모니터링은 프로세스의 필수적인 구성요소다. (솔루션 경로를 아카이브/버전 관리하길 원하지만) 생성 프로세스를 테스트하는 것보다 프로덕션 프로세스를 지속적으로 테스트하는 데 더 중점을 둔다. 여기서 테스트 케이스는 ‘입력-결과’ 쌍이지만 테스트 케이스보다 데이터 포인트로 구성될 가능성이 더 높다.

이러한 모니터링의 차이점은 배포 전 유효성 검사에도 영향을 미친다. 소프트웨어를 배포할 때는 애플리케이션이 테스트를 통과하는지 확인한다. 데이터 과학 프로덕션 프로세스에서는 표준 데이터 포인트가 여전히 동일한 클래스에 속할 것으로 예측되는지(예: 우수 고객이 계속해서 높은 신용 등급을 받는지), 알려진 이상값이 계속 포착되는지(예: 제품 고장이 계속 ‘고장’으로 분류되는지) 테스트할 필요가 있다. 

또 데이터 과학 프로세스가 터무니없는 패턴(예: ‘임신한 남성’ 환자)을 거부하도록 만들어야 한다. 즉, 전형적이거나 비정상적인 데이터 포인트 또는 단순한 이상값(아웃라이어)을 참조하는 테스트 케이스가 예상대로 처리되도록 해야 한다.

ML옵스(MLOps), 모델옵스(ModelOps), 엑스옵스(XOps)
이 모든 것이 ML옵스, 모델옵스, 엑스옵스(가트너에 따르면 이는 데이터옵스, 모델옵스, 데브옵스의 조합을 일컫는다)와 어떤 관련이 있을까? 이러한 용어를 언급하는 사람들이 무시하는 2가지 사실이 있다. 

첫째, 데이터 전처리는 프로덕션 프로세스의 일부다(단순히 프로덕션에 투입되는 ‘모델’이 아니다). 둘째, 프로덕션 환경에서 모델 모니터링은 정적이고 비반응적인 경우가 많다.

현재 많은 데이터 과학 스택은 데이터 과학 수명주기의 일부만 다룬다. 다른 부분은 수동으로 처리해야 한다. 기술 간 격차로 코딩을 다시 해야 하는 경우도 많다. 따라서 ‘완전히 자동으로’ 프로덕션 데이터 과학 프로세스를 추출하는 것은 불가능에 가깝다. 

진정한 데이터 과학 모델 구축이 단순히 잘 구축된 모델을 (프로덕션 환경으로) 던져버리는 것 이상이라는 사실을 깨닫기 전까지는, 데이터 과학을 기업 운영의 필수적인 부분으로 정착시키려고 시도할 때마다 실패를 보게 될 것이다. 

데이터 과학 프로세스는 아직 갈 길이 멀다. 하지만 CI/CD는 토대로 삼을 수 있는 교훈을 제공한다. 그러나 데이터 과학을 위한 CI/CD와 소프트웨어 개발을 위한 CI/CD 사이에는 2가지 기본적인 차이점이 있다는 점을 유의해야 한다. 

첫째, 통합 과정에서 자동으로 생성되는 ‘데이터 과학 프로덕션 프로세스’는 데이터 과학팀이 만든 것과는 다르다. 둘째, 프로덕션 환경에서의 모니터링은 자동 업데이트 및 재배포로 이어질 수 있다. 

다시 말해, 프로덕션 환경의 데이터 과학 프로세스를 확인하는 모니터링 프로세스에 의해 배포 주기가 자동으로 트리거될 수 있으며, 해당 모니터링이 중요한 변경 사항을 감지해야 전체 프로세스를 다시 시작할 수 있다. ciokr@idg.co.kr


 



2021.11.25

모델만 잘 만들면 끝?··· 데이터 과학을 위한 ‘CI/CD’가 필요하다 

Michael Berthold | InfoWorld
데이터 과학 모델을 프로덕션 환경으로 옮기는 것은 애플리케이션 배포와 상당히 유사하다. 하지만 간과해서는 안 되는 중요한 차이점이 있다. 

애자일 프로그래밍은 개발팀이 소프트웨어를 프로덕션 환경으로 릴리즈하고, 피드백을 수집하며, 기본 요건을 개선하는 데 가장 많이 사용하는 방법론이다. 하지만 애자일이 실제로 작동하려면 수정된 애플리케이션을 자동으로 빌드하고, 프로덕션 환경으로 릴리즈할 수 있는 프로세스가 필요하다. 이를 ‘CI/CD’라고 한다.

‘CI/CD’를 통해 소프트웨어 팀은 실제 사용자를 정기적으로 참여시키고, 피드백을 반복적으로 통합하여 초기 요건을 놓칠 위험 없이 복잡한 애플리케이션을 구축할 수 있다.
 
ⓒGetty Images

데이터 과학도 비슷한 문제에 직면해 있다. 데이터 과학팀이 초기 요건을 충족하지 못할 위험은 현재로선 덜하지만 데이터 과학을 프로덕션 환경에 자동으로 배포하는 것과 관련된 문제가 많은 데이터 과학 프로젝트를 서서히 중단시킬 수 있다. 

첫째, IT가 프로덕션 시스템에 무엇이든 투입해야 하는 경우가 너무 많다. 둘째, (만약 있다고 한다면) 유효성 검사가 규정되지 않은 수작업인 경우가 일반적이다. 셋째, 프로덕션 데이터 과학 프로세스를 안정적으로 업데이트하기 어려운 까닭에 이는 완전히 새로운 프로젝트로 취급된다.

데이터 과학이 소프트웨어 개발에서 무엇을 배울 수 있을까? 여기서는 소프트웨어 개발에서의 CI/CD, 데이터 과학과 유사한 부분 그리고 데이터 과학자가 다르게 접근할 필요가 있는 부분을 살펴본다.

소프트웨어 개발에서의 CI/CD
소프트웨어 개발에서 반복 가능한 프로덕션 프로세스는 꽤 오래전에 등장했다. 오늘날 CI/CD는 사실상 ‘표준’이나 마찬가지다. 대규모 소프트웨어 개발은 통상 고도로 모듈화된 접근 방식을 적용한다. 개발팀은 코드 베이스 일부를 작업하고, 해당 모듈을 독립적으로 테스트한다(일반적으로 해당 모듈에 고도로 자동화된 테스트 케이스를 사용한다).

CI/CD의 지속적인 통합 단계에서 코드 베이스의 여러 부분이 연결돼 자동으로 전체 테스트를 거친다. 이러한 통합 작업은 이상적으론 자주(지속적으로) 수행된다. 개별 모듈에는 영향을 미치진 않지만 전체 애플리케이션을 중단시킬 수 있는 문제를 즉시 찾을 수 있기 때문이다. 

전체 테스트 범위를 확보한 이상적인 상황에서는 모듈 변경으로 발생하는 문제가 거의 즉시 포착된다고 할 수 있다. 하지만 실제로는 완전한 테스트 설정은 존재하지 않으며, 복잡한 통합 테스트는 하루 한 번만 실시할 수 있는 게 현실이다. 

CI/CD의 두 번째 부분인 지속적인 배포는 새로 구축된 애플리케이션을 프로덕션 환경으로 옮기는 것을 말한다. 분당 수만 개의 데스크톱 애플리케이션을 업데이트하는 것은 거의 불가능하다.

하지만 클라우드 기반 도구가 점점 더 많이 사용되고 있고, 서버 기반 애플리케이션은 훨씬 더 자주 변경 사항을 롤아웃하고 업데이트를 완료할 수 있다. 버그가 있는 애플리케이션을 롤아웃했을 때도 신속하게 복구할 수 있다. 그다음 배포한 애플리케이션을 지속적으로 모니터링해 잠재적인 문제를 찾게 되는데, 테스트를 제대로 수행했다면 문제가 적게 발생한다.

데이터 과학에서의 CI/CD
데이터 과학 프로세스는 여러 팀이 독립적으로 구축하는 게 아니라 데이터 엔지니어, 머신러닝 전문가, 시각화 전문가 등 여러 전문가가 협력해 구축한다.

여기서 데이터 과학 모델 생성은 ‘ML 알고리즘 개발(소프트웨어 엔지니어링)’이 아니라 ‘ML 알고리즘을 데이터에 적용하는 것’과 관련 있다는 점을 유념하는 게 중요하다. 이런 알고리즘 ‘개발’과 ‘활용’의 차이가 혼란을 야기하는 경우가 많다. 

또 데이터 과학에서 ‘통합’은 기본 요소를 하나로 모으는 것을 의미한다. 설명하자면, 데이터 과학의 통합은 특정 툴킷의 적절한 라이브러리가 최종 데이터 과학 프로세스와 연결되도록 하고, (데이터 과학 생성 도구에서 추상화를 허용한다면) 이러한 모듈의 적절한 버전도 연결돼야 한다.

통합 단계에서 소프트웨어 개발과 데이터 과학 사이에 한 가지 큰 차이점이 있다. 소프트웨어 개발에서는 애플리케이션을 구축해 배포한다. 통합 과정에서 일부 디버깅 코드를 제거할 순 있지만 최종 제품은 개발 단계에서 구축한 것이다. 하지만 데이터 과학은 그렇지 않다.

데이터 과학은 생성 단계에서 어떤 데이터를 어떻게 결합하고 변환할지 최적화하는 복잡한 프로세스를 구축한다. 이 데이터 과학 모델 생성 프로세스는 모델의 다양한 유형과 매개변수에 따라 반복되며, 이러한 모델 중 일부를 서로 다르게 결합할 수도 있다. 

통합 과정에서 이런 최적화 단계의 결과물이 데이터 과학 프로덕션 프로세스에 결합된다. 즉, 개발 단계에서는 기능을 생성하고 모델을 학습시킨다. 그리고 통합 단계에서 최적화된 기능 생성 프로세스와 학습시킨 모델을 결합한다. 이러한 통합이 프로덕션 프로세스를 구성한다.

그렇다면 데이터 과학에서 지속적인 배포는 무슨 의미일까? 프로덕션 프로세스, 즉 배포해야 하는 통합의 결과물은 데이터 과학 모델 생성 프로세스와 다르다. 실제 배포는 소프트웨어 배포와 유사하다. 

데이터 과학 프로덕션 프로세스에서 또 흥미로운 요건은 모델 성능을 지속적으로 모니터링해야 한다는 것이다. ‘현실’이 변하기 때문이다. 변경 감지는 데이터 과학 프로세스에서 매우 중요하다. 

따라서 프로덕션 프로세스의 성능이 저하될 때, 이를 감지하는 메커니즘을 마련해야 한다. 그다음 모델을 자동으로 재학습시켜 재배포하거나, 데이터 과학팀이 새로운 데이터 과학 프로세스를 만들 수 있도록 문제를 알린다. 이를 통해 데이터 과학 CI/CD 프로세스를 새로 트리거할 수 있다. 

소프트웨어 애플리케이션을 모니터링하면 코드가 자동으로 변경되고 재배포되지 않지만 이는 데이터 과학에서 매우 일반적인 요건이다. 이 자동 통합과 배포에 필요한 유효성 검사 및 테스트 설정은 자동 변경의 복잡성에 따라 달라진다. 

데이터 과학에서 테스트와 모니터링은 프로세스의 필수적인 구성요소다. (솔루션 경로를 아카이브/버전 관리하길 원하지만) 생성 프로세스를 테스트하는 것보다 프로덕션 프로세스를 지속적으로 테스트하는 데 더 중점을 둔다. 여기서 테스트 케이스는 ‘입력-결과’ 쌍이지만 테스트 케이스보다 데이터 포인트로 구성될 가능성이 더 높다.

이러한 모니터링의 차이점은 배포 전 유효성 검사에도 영향을 미친다. 소프트웨어를 배포할 때는 애플리케이션이 테스트를 통과하는지 확인한다. 데이터 과학 프로덕션 프로세스에서는 표준 데이터 포인트가 여전히 동일한 클래스에 속할 것으로 예측되는지(예: 우수 고객이 계속해서 높은 신용 등급을 받는지), 알려진 이상값이 계속 포착되는지(예: 제품 고장이 계속 ‘고장’으로 분류되는지) 테스트할 필요가 있다. 

또 데이터 과학 프로세스가 터무니없는 패턴(예: ‘임신한 남성’ 환자)을 거부하도록 만들어야 한다. 즉, 전형적이거나 비정상적인 데이터 포인트 또는 단순한 이상값(아웃라이어)을 참조하는 테스트 케이스가 예상대로 처리되도록 해야 한다.

ML옵스(MLOps), 모델옵스(ModelOps), 엑스옵스(XOps)
이 모든 것이 ML옵스, 모델옵스, 엑스옵스(가트너에 따르면 이는 데이터옵스, 모델옵스, 데브옵스의 조합을 일컫는다)와 어떤 관련이 있을까? 이러한 용어를 언급하는 사람들이 무시하는 2가지 사실이 있다. 

첫째, 데이터 전처리는 프로덕션 프로세스의 일부다(단순히 프로덕션에 투입되는 ‘모델’이 아니다). 둘째, 프로덕션 환경에서 모델 모니터링은 정적이고 비반응적인 경우가 많다.

현재 많은 데이터 과학 스택은 데이터 과학 수명주기의 일부만 다룬다. 다른 부분은 수동으로 처리해야 한다. 기술 간 격차로 코딩을 다시 해야 하는 경우도 많다. 따라서 ‘완전히 자동으로’ 프로덕션 데이터 과학 프로세스를 추출하는 것은 불가능에 가깝다. 

진정한 데이터 과학 모델 구축이 단순히 잘 구축된 모델을 (프로덕션 환경으로) 던져버리는 것 이상이라는 사실을 깨닫기 전까지는, 데이터 과학을 기업 운영의 필수적인 부분으로 정착시키려고 시도할 때마다 실패를 보게 될 것이다. 

데이터 과학 프로세스는 아직 갈 길이 멀다. 하지만 CI/CD는 토대로 삼을 수 있는 교훈을 제공한다. 그러나 데이터 과학을 위한 CI/CD와 소프트웨어 개발을 위한 CI/CD 사이에는 2가지 기본적인 차이점이 있다는 점을 유의해야 한다. 

첫째, 통합 과정에서 자동으로 생성되는 ‘데이터 과학 프로덕션 프로세스’는 데이터 과학팀이 만든 것과는 다르다. 둘째, 프로덕션 환경에서의 모니터링은 자동 업데이트 및 재배포로 이어질 수 있다. 

다시 말해, 프로덕션 환경의 데이터 과학 프로세스를 확인하는 모니터링 프로세스에 의해 배포 주기가 자동으로 트리거될 수 있으며, 해당 모니터링이 중요한 변경 사항을 감지해야 전체 프로세스를 다시 시작할 수 있다. ciokr@idg.co.kr


 

X