ML 시스템 설계는 MLOps에 시스템으로 접근한다. 이는 비즈니스 요구 사항, 데이터 스택, 인프라, 배포와 모니터링 등 구성 요소와 각 요소에 속하는 이해관계자가 협업할 수 있도록 ML 시스템을 전반적으로 고려한다는 의미이다.

ML 시스템 설계는 비즈니스 목적 확인, 요구 사항 도출, 반복 프로세스, ML로 해결 가능한 작업 형태로 구조화하는 과정을 거친다.

2.1 비즈니스와 머신러닝의 목적

정확도, F1 점수와 같이 ML 모델을 측정하는 지표에 기업은 큰 관심이 없다. 기업은 비즈니스 지표에 영향을 주지 않는 한 모델 정확도를 94%에서 94.2%로 올리는 일에 신경쓰지 않는다.

기업의 궁극적인 목적은 주주의 이익을 극대화하는 것이므로 직간접적인 이윤과 ML 프로젝트의 목적이 연관되어야 한다. (= ML 프로젝트가 성공하려면 ML 시스템 성과를 전체적인 비즈니스 성과와 연결해야 한다.)

하지만 ML 프로젝트가 비즈니스 목적에 미치는 영향은 추론하기 어려울 수 있고, 비즈니스 지표에 미치는 영향을 명확히 파악하려면 실험이 필요한 경우가 많다.

2.2 머신러닝 시스템 요구 사항

ML 시스템의 구체적인 요구 사항은 유즈 케이스에 따라 다르지만, 대부분의 시스템은 신뢰성, 확장성, 유지보수성, 적응성 등 네 가지 특성을 갖춰야 한다.

• 신뢰성: 시스템은 다양한 문제 상황이 발생해도 목표 성능을 만족하면서 지속적으로 기능을 수행해야 한다. 하지만 ML 시스템은 ‘시스템 동작의 올바름’을 판단하기 어렵다. 예를 들어 model.predict()를 호출한 결과값의 형태는 기대대로 출력되지만, 그 예측이 엉터리인지는 ground truth 레이블이 없는 한 정확히 알기 어렵다. 이 문제를 다루는 방법은 추후 8장(데이터 분포 시프트와 모니터링)에서 다룬다.
• 확장성: ML 시스템은 다양한 이유로 확장이 필요할 수 있다. 시스템 복잡도가 증가하든(ex. 새로운 구조의 모델 도입으로 더 큰 VRAM이 필요한 상황), 트래픽 양이 증가하든(ex. 사용자 기반 증가로 요청 건수가 폭증한 상황), ML 모델 개수가 증가하든(ex. 기업이 제공하는 서비스가 다양해지는 상황) 상관없이 규모 증가를 처리할 합리적인 방법이 필요하다. 이렇게 확장성을 이야기할 때 주로 자원 스케일링(업 스케일링 or 다운 스케일링)을 생각한다. 한편 규모 증가를 처리하는 일에는 아티팩트(ML 개발 과정에서 발생하는 다양한 유형의 부산물) 관리도 포함된다. 모델 개수가 적으면 수동으로 모니터링하거나 신규 데이터로 모델을 수동 업데이트할 수 있지만, 개수가 많아지면 이러한 과정을 자동화하고 적절히 재현 가능하도록 코드 생성을 관리할 방법도 필요해진다.
• 유지보수성: ML 시스템에는 ML 엔지니어, 데브옵스 엔지니어, 도메인 전문가 등 다양한 직군이 얽혀 있다. 각 직군 별 사용하는 프로그래밍 언어와 도구가 다르고, 직군마다 프로세서에서 서로 다른 부분을 맡는다. 그러므로 워크로드(주어진 기간에 IT 시스템에 의해 실행되어야 할 작업의 할당량)를 구조화하고 인프라를 설정하는 일이 중요하다. 코드는 문서화하고 코드, 데이터, 아티팩트는 버전을 관리해야 한다.
• 적응성: 시스템은 변화하는 데이터 분포와 비즈니스 요구 사항에 적응할 수 있어야 한다. 데이터는 빠르게 변하므로 ML 시스템 또한 자체적으로 빠르게 진화할 수 있어야 한다. 유지보수성과 밀접한 연관이 있다.

2.3 반복 프로세스

ML 시스템 개발은 반복적이며 대부분 끝이 없는 프로세스이다. 시스템을 프로덕션 환경에 배포하면 지속적으로 모니터링하고 업데이트 해야 한다.

1. 프로젝트 범위 산정

프로젝트의 시작은 범위를 산정하고 목표, 목적과 제약 사항을 설정하는 일이다. 이해관계자를 파악해 참여시키고 사용할 자원을 추정하고 할당한다.

2. 데이터 엔지니어링

ML 모델은 대부분 데이터를 학습하므로 ML 모델 개발은 데이터 엔지니어링에서 시작한다.

3. ML 모델 개발

초기 훈련 데이터셋을 활용하여 초기 모델을 개발한다. ML 관련 지식이 가장 많이 필요한 단계이며 ML 교육 과정에서 가장 많이 다루는 단계이다.

4. 배포

개발한 모델에 사용자가 접근할 수 있도록 한다.

5. 모니터링과 연속 학습

모델을 프로덕션 환경에 배포한 뒤에는 지속적으로 성능 저하를 모니터링하고 변화하는 환경과 요구 사항에 적응하도록 유지 관리해야 한다.

6. 비즈니스 분석

모델 성능을 비즈니스 목표 관점에서 평가하고 분석해 비즈니스 인사이트를 추출한다. 얻은 인사이트를 토대로 비생산적인 프로젝트를 중단하거나 새로운 프로젝트의 범위를 산정한다. 1단계와 밀접하게 연관된다.

2.4 머신러닝 문제 구조화하기

은행에서 일하는 상황을 가정할 때 상사가 ML을 사용해 고객 서비스 지원 속도를 향상할 방법이 있는지 조사하라는 지시를 내렸다. 어떻게 문제를 구조화할 것인가?

-> 고객 서비스 지원의 병목이 고객 요청 응답에 있다는 사실을 확인. 고객 요청을 회계, 재고, 인사, IT 등 4개 부서 중 적합한 곳으로 라우팅하는데 시간이 오래걸리는 상황이다.

-> 이러한 병목 현상을 해소하기 위해 고객 요청을 입력, 요청을 보낼 부서를 출력, 목적 함수는 예측한 부서와 실제 부서 간 차이를 최소화하는 것으로 구조화할 수 있다.

2.4.1 머신러닝 작업 유형

모델의 출력 형태가 작업 유형을 결정한다. 작업 유형은 지도 학습을 기준으로 크게 분류와 회귀로 나뉜다.

분류 vs. 회귀

입력을 여러 범주로 분류하면 분류, 연속 값을 출력하면 회귀

분류와 회귀는 서로 쉽게 바꿔 구조화할 수 있다.

이진 분류 vs. 다중 클래스 분류

분류 문제에서 클래스가 2개면 이진 분류, 3개 이상이면 다중 클래스 분류라고 한다.

다중 클래스 vs. 다중 레이블 분류

입력에 따른 정답이 2개 이상 존재할 때 다중 레이블 분류로 취급한다. 데이터 포인트가 여러 클래스에 동시에 속할 수 있는 상황.

다중 레이블 분류는 실제 기업에서 가장 많이 직면하는 유형이다.

문제를 구조화하는 다양한 방법

문제를 구조화하는 방법에 따라 문제가 훨씬 어려워지거나 쉬워진다. 스마트폰 사용자가 다음으로 사용할 앱을 예측하는 작업을 생각해보자.

사용자가 사용할 앱을 예측할 때 유용한 피처와 데이터가 있고 사용자가 다음으로 사용할 앱 후보 개수는 N개이다. 이 때 다중 클래스 분류 문제로 접근한다면 N이 변할 때마다 모델 학습을 처음부터 다시 해야 한다. 하지만 회귀 문제로 구조화한다면 데이터 포인트(인스턴스) 별 N번의 예측을 한 후 나온 결과값을 비교해야 하지만 N이 변하더라도 모델을 처음부터 다시 훈련시키지 않아도 된다.

2.4.2 목적 함수

ML 모델에는 학습 프로세스를 이끌어갈 목적 함수가 필요하다. 일반적으로 회귀에는 RMSE, 분류에는 크로스 엔트로피 함수를 목적 함수로 활용한다.

목적 함수 분리하기

최소화할 목적 함수가 여러 개이면 ML 문제 구조화가 까다롭다. 사용자 뉴스 피드 항목 순위를 지정하는 랭킹 시스템을 개발하는 상황에서 내용의 품질과 사용자 참여도(클릭할 확률)을 모두 고려하여 게시물 랭킹을 정하고자 한다면 둘 중 하나만을 고려하여 랭킹 시스템을 개발할 때 보다 구조화하기 어렵다.

게시글의 품질을 기준으로 순위를 지정하려면 게시글 별 품질을 예측해야 한다. 따라서 게시글 별 모델이 품질을 예측한 결과와 실제 품질 간 차이를 최소화하는 회귀 문제로 구조화하여 생각할 수 있다. 이 때 예측 품질과 실제 품질 간 차이, 즉 quality_loss를 최소화해야 한다.

마찬가지로 사용자 참여도를 기준으로 순위를 지정하기 위해서 사용자 클릭수를 예측해야 하고, 사용자 클릭수를 예측하는 회귀 문제로 구조화하여 예측 클릭수와 실제 클릭수의 차이인 engagement_loss도 최소화해야 한다.

두 가지 목적 함수를 최소화하기 위해 모델을 훈련시킬 때 손실 함수를 다음과 같이 정의할 수 있다.

loss = a * quality_loss + b * engagement_loss

a와 b를 조절해가며 어느 요소에 더욱 적합시킬지 결정할 수 있지만 각 하이퍼파라미터를 조절할 때마다 모델을 새롭게 학습해야 한다는 단점이 있다.

그렇기 때문에 각각의 손실 함수에 최적화된 2개의 모델을 만들고, 각 모델의 결과값에 가중치를 두고 조절한다면 여러번 모델 학습하지 않아도 되니 시스템을 조정하기 더 편하다. 또한 목적 함수마다 유지 관리 일정이 상이할 경우 유지 관리가 더 용이하다는 장점도 있다.

2.5 지성 vs. 데이터

ML 시스템의 성공 여부에 ML 알고리즘 개선과 데이터 관리와 개선 중 어느 요소가 더 중요한지에 대한 논쟁을 다룬다.

지난 10년간 딥러닝의 발전은 상당 부분 대량의 데이터를 통해 이뤄진 것이 사실이고, 어느 쪽이 옳다고 밝혀지든 간에 현재 데이터가 ML 시스템 성공에 필수 요소임은 부정할 수 없다.

2.6 정리

ML 시스템 설계 소개와 설계 시 고려사항을 알아보았다.

어떤 프로젝트든 시작하기 전에 먼저 그 프로젝트가 왜 필요한지부터 고민해야한다.

ML 시스템을 개발하기에 앞서 좋은 시스템이 되려면 어떤 요구 사항을 충족해야 하는지 이해해야 한다.

ML 시스템 개발은 일회성 작업이 아니라 반복 프로세스이다.

데이터가 지능형 설계를 압도할 수 있는지는 차치하더라도, ML에 데이터가 중요하다는 사실은 누구도 부정할 수 없다.