한빛출판네트워크

 

 

머신러닝 시스템이란 무엇인가?

2016년 11월 구글은 다국어 신경망 기계 번역 시스템(MNMT)을 구글 번역에 통합했다고 발표했습니다. 

이는 대규모 프로덕션 환경에 적용한 심층 인공 신경망의 초기 성공 사례 중 하나입니다.

 

구글에 따르면 번역 품질이 지난 10년간 이룩한 것보다 이 업데이트 한 번으로 더 많이 향상됐습니다.

 

이러한 딥러닝의 성공은 머신러닝(ML)에 대한 관심을 촉발했습니다. 점점 더 많은 회사가 까다로운 문제를 해결하기 위해 ML 쪽으로 방향을 틀고 있습니다. 

 

ML은 불과 5년 만에 우리 삶 대부분의 영역에 들어와 정보에 접근하는 방식, 의사소통하는 방식, 일하는 방식, 연애 상대를 찾는 방식 등에 영향을 미칩니다. 보급 속도가 매우 빨라 이제 ML 없는 삶은 상상하기 어렵습니다. 

 

하지만 의료, 운송, 농업, 심지어 우주 연구에 이르기까지 여전히 시도해볼 만한 ML 사례가 많습니다.

 

‘머신러닝 시스템’이라고 하면 많은 사람이 로지스틱 회귀나 다양한 유형의 신경망 등 ML 알고리즘만 떠올립니다. 그러나 프로덕션 환경에서 알고리즘은 ML 시스템의 일부일 뿐입니다. 

 

시스템은 ML 프로젝트의 출발점이 된 비즈니스 요구 사항, 사용자와 개발자가 시스템과 상호 작용하는 인터페이스, 데이터 스택, 모델을 개발 및 모니터링하고 업데이트하기 위한 로직은 물론 해당 로직을 전달할 수 있는 인프라를 포함합니다. [그림 1-1]은 ML 시스템의 다양한 요소와 각 요소를 이 책의 어느 장에서 다룰지 보여줍니다. 

 

MLOps와 ML 시스템 설계 간의 관계 

 

MLOps의 ‘Ops’는 ‘Developments and Operations’의 줄임말인 ‘DevOps’에서 유래합니다.

무언가를 운영함은 그것을 프로덕션 환경에 적용함을 의미하며 여기에는 배포, 모니터링, 유지 관리가 포함됩니다. MLOps는 ML을 프로덕션 환경에 적용하기 위한 도구와 모범 사례의 집합 입니다.

 

ML 시스템 설계는 MLOps에 시스템으로 접근합니다. 즉, 시스템의 각 요소와 이해관계자가 협

업함으로써 정해진 목표와 요구 사항을 충족하도록 ML 시스템을 총체적으로 고려합니다.

 

▲ ML 시스템의 구성 요소

 

 

많은 책에서 각양각색의 ML 알고리즘을 훌륭히 다루고 있습니다. 한편 이 책은 특정 알고리즘을 자세히 다루는 대신 전체 ML 시스템을 전반적으로 이해하도록 돕습니다. 다시 말해, 이 책의 목표는 어떤 알고리즘을 사용하든 관계없이 문제에 가장 적합한 솔루션을 개발할 수 있도록 프레임워크를 제공하는 것입니다. 

 

새로운 알고리즘이 계속 등장하면서 기존 알고리즘은 빠르게 뒤처지기 마련이지만 이 책에서 제안하는 프레임워크는 새로운 알고리즘에도 잘 적용될겁니다.

 

이 장에서는 ML 모델을 프로덕션 환경에 적용하려면 무엇이 필요한지 전체적으로 살펴봅니다.

ML 시스템을 개발하는 방법을 논의하기 전에 먼저 근본적인 질문을 해봐야 합니다. ML을 사용해야 할 때와 사용하지 말아야 할 때는 언제일까요? 이 질문에 답하기 위해 인기 있는 ML 유스 케이스 몇 가지를 살펴볼 겁니다.

 

유스 케이스를 알아보고 나면 ML 시스템을 배포하는 문제로 넘어갑니다. 이때 프로덕션 환경의 ML과 연구 환경의 ML 그리고 전통적인 소프트웨어를 비교하며 이야기해봅니다. 응용 ML시스템을 개발하는 곳에 몸담은 적이 있다면 이 장에서 설명하는 내용이 익숙할 겁니다. 반면 ML을 학계에서만 경험했다면 이 장 내용이 ML에 대한 좀 더 현실적인 관점을 제시하고 여러분의 첫 번째 애플리케이션을 성공적으로 개발하기 위한 토대가 될 겁니다.

  

1.1 머신러닝을 사용해야 하는 경우

다양한 업계에서 ML을 도입하는 사례가 늘고 있다는 점은 ML이 광범위한 문제를 다룰 수 있는 강력한 도구임을 입증합니다. 현장 안팎에서 사람들은 굉장히 흥분하며 과대평가하기도 하지만 ML이 모든 문제를 해결하는 마법의 도구는 아닙니다. ML로 해결 가능한 문제이더라도 그 ML 솔루션이 최선은 아닐 수 있습니다. ML 프로젝트를 시작하기 전에 ML이 필요조건인지, 비용 효율적인지 스스로 질문해봐야 합니다.

 

ML이 무엇을 해결할 수 있을까요? ML을 통한 솔루션은 일반적으로 다음 작업을 수행합니다.

 

ML은 기존 데이터로부터 복잡한 패턴을 학습하고 이러한 패턴을 사용해 본 적 없는 데이터에 대해 예측을 수행하는 접근법입니다.

 

그렇다면 ML로 해결 가능한 문제는 무엇일까요? 위 문장에서 밑줄 친 핵심 구절을 하나씩 짚어봅시다.

 

1. 학습: 시스템에 학습 능력이 있습니다.

예컨대 관계형 데이터베이스는 ML 시스템이 아닙니다. 학습 능력이 없기 때문입니다. 두 열간의 관계를 직접 명시할 수는 있지만 데이터베이스에서 자체적으로 관계를 파악하는 능력은 거의 없습니다.

 

ML 시스템이 학습을 하려면 학습할 대상이 있어야 합니다. 대부분의 경우는 데이터로 학습합니다. 지도 학습 모델을 만드는 예를 든다면, ML 시스템은 한 쌍으로 이뤄진 입력과 출력 데이터를 이용해 입력 데이터에서 출력 데이터를 생성하는 관계를 학습합니다. 예를 들어, 에어비앤비 숙소 임대료를 예측하는 방법을 학습하려고 ML 시스템을 구축한다고 해봅시다. 입력값은 관련 특성 값(넓이, 방 개수, 지역, 편의 시설, 평점 등)이고 그에 따른 출력값은 임대료입니다. 

 

학습을 완료하면 ML 시스템은 특성 값을 감안해 새 숙소의 임대료를 예측할 수 있어야 합니다.

 

2. 복잡한 패턴: 학습할 패턴이 존재하며 복잡합니다.

ML 시스템은 학습할 패턴이 있을 때만 유용합니다. 분별 있는 사람이라면 주사위 결과를 예측하는 ML 시스템을 구축하는 데 돈을 쓰지 않을 겁니다. 결과가 생성되는 방식에 패턴이 없기때문입니다.

 

반면 주식 가격 책정 방식에는 패턴이 있으며 기업들은 이를 학습하는 ML 시스템을 구축하려고 수십억 달러를 투자합니다. 

 

때때로 패턴이 있는지 명확하지 않거나, 있더라도 데이터셋 또는 ML 알고리즘이 이를 포착하기에 충분하지 않기도 합니다. 예를 들어, 일론 머스크 Elon Musk의 트윗이 암호화폐 가격에 미치는 영향에 패턴이 있을 수 있습니다. 하지만 그의 트윗으로 ML 모델을 엄격하게 훈련하고 평가하기 전까지는 패턴 유무를 알 수 없습니다. 모든 모델이 암호화폐 가격을 합리적으로 예측하지 못한다고 해서 패턴이 없는 것은 아닙니다.

 

에어비앤비처럼 여러 숙소 목록이 있는 웹사이트를 생각해보세요. 각 숙소에는 우편 번호가 붙어 있습니다. 이때 숙소를 주 별로 정렬하는 데는 ML 시스템이 필요하지 않습니다. 

 

패턴이 단순하기 때문입니다. 우편 번호마다 어느 주에 해당하는지는 이미 알고 있으니 조회 테이블만

사용하면 되죠.

 

임대료와 모든 특성 값 간의 관계는 훨씬 더 복잡한 패턴을 따르므로 수동으로 지정하기가 매우 어렵습니다. 이때 ML이 좋은 솔루션입니다. 특성 값 항목으로부터 임대료를 계산하는 방법을 시스템에 직접 알려주는 대신 임대료와 특성 값을 제공하고 ML 시스템이 스스로 패턴을 파악하게끔 합니다.

 

▲ [그림 1-2]는 ML 솔루션과 조회 테이블 lookup table 솔루션 그리고 전통적인 소프트웨어 솔루션 간의 차이점을 보여줍니다. 이러한 이유로 ML을 소프트웨어 2.0이라고 부르기도 합니다.

 

 

ML은 객체 탐지나 음성 인식처럼 복잡한 패턴을 다루는 작업에서 매우 유용합니다. 

기계에게 복잡한 일과 인간에게 복잡한 일은 성질이 많이 다릅니다. 인간이 하기 어려운 일이 기계에게는 쉽기도 하고(예: 10의 거듭제곱 계산하기) 반대로 인간이 하기 쉬운 일이 기계에게는 어렵기도 합니다(예: 사진에 고양이가 있는지 판별하기). 

 

3. 기존 데이터: 사용 가능한 데이터가 있거나 데이터 수집이 가능합니다.

ML은 데이터로 학습하므로 학습 가능한 데이터가 있어야 합니다. 한 사람이 1년 동안 지불할 세금을 예측하는 모델을 만든다면 어떨까요? 흥미로운 모델이긴 하지만 인구 다수의 세금과 소득 데이터에 접근할 수 없다면 모델을 만들 수 없습니다.

 

제로샷 학습(zero-shot learning, 제로 데이터 학습이라고도 함)의 맥락에서 ML 시스템은 특정 작업 관련 데이터로 훈련하지 않았더라도 좋은 예측을 해낼 수 있습니다. 

 

다만 이러한 ML 시스템은 특정 작업과 연관된 다른 데이터로 훈련되는 것이 일반적입니다. 즉, 시스템이 학습을 하려면 당면한 작업에 대한 학습 데이터는 필요하지 않더라도 여전히 데이터가 필요하다는 사실은 변함없습니다.

 

데이터 없이 ML 시스템을 시작하는 것도 가능합니다. 예를 들어, 연속 학습(continual learning)의 맥락에서 어떤 데이터로도 훈련하지 않은 ML 모델을 배포한 뒤 프로덕션 환경에서 들어오는 데이터로 학습합니다.

 

다만 충분히 훈련하지 않은 모델을 사용자에게 제공해 고객 경험이 악화되는 등 위험 요소가 있습니다.

데이터가 없고 연속 학습도 사용할 수 없을 때, 많은 기업은 실제 ML 모델이 만들어지기 전까지 마치 ML 모델이 있는 것처럼 작동하는 룰이나 소프트웨어를 운용함으로써 데이터를 수집하고 모델이 만들어질 수 있는 여건을 마련합니다.

 

앞으로 모일 데이터를 사용해 ML을 훈련할 수 있을 거라는 바람 아래, ML 모델 대신 사람이 만든 예측을 우선 제공하는 제품을 출시하는 방법입니다.

 

4. 예측: 예측에 대한 문제입니다.

ML 모델은 예측을 수행하므로 예측을 통한 답변이 필요한 문제를 주로 해결합니다. 비용이 낮고 근삿값인 예측을 대규모로 수행해 이득을 얻을 수 있을 때 ML은 특히나 매력적입니다. ‘예측’은 ‘미래 가치를 추정하다’라는 뜻입니다. 

 

예를 들어, 내일 날씨는 어떨지, 올해 슈퍼볼 우승자는 누가 될지, 사용자가 다음으로 보고 싶어 할 영화는 무엇일지 등을 예측합니다.

 

ML 모델을 비롯한 예측 알고리즘이 효과적인 도구가 되면서 점점 더 많은 문제가 예측 문제로 재구성되고 있습니다. 어떤 질문이든 “이 질문에 대한 답은 무엇이 될까요?” 같은 형태로 구성할 수 있으며 질문이 미래에 관한 것이든 현재에 관한 것이든, 심지어 과거에 관한 것이든 상관 없습니다.

 

계산 집약적 문제를 예측 문제로 재구성해 매우 성공적으로 해결한 것이 좋은 예입니다. ML보다 훨씬 큰 계산 비용과 시간을 들여 프로세스 결과를 정확하게 계산하는 대신 “이 프로세스의 결과는 어떻게 생겼을까요?” 같은 형태로 문제를 구성하고 ML 모델을 적용해 근삿값을 구합니다.

 

출력은 정확한 출력의 근삿값이지만 보통은 이 정도면 충분합니다.

 

이러한 사례는 이미지 잡음 제거나 스크린 공간 셰이딩 같은 그래픽 렌더링에서 많이 보입니다.

 

5. 본 적 없는 데이터: 본 적 없는 데이터가 훈련 데이터와 동일한 패턴을 갖습니다.

모델이 기존 데이터로 학습한 패턴이 유용한 경우는 오직 본 적 없는 데이터에 동일한 패턴이 있는 경우입니다. 2023년 크리스마스에 사람들이 특정 앱을 다운로드할지 예측하는 모델을 생각해봅시다. 

 

이 모델을 2008년의 데이터로 훈련한다면 예측을 잘하지 못할 겁니다. 2008년에 앱 스토어에서 가장 인기 있는 앱은 코이 폰드(Koi Pond)였습니다. 하지만 지금은 사람들에게 많이 잊혔죠.

 

이것이 기술적으로 의미하는 바는 본 적 없는 데이터와 훈련 데이터가 유사한 분포에서 생성돼야 한다는 점입니다. “본 적 없는 데이터인데 어떤 분포에서 생성됐는지 어떻게 아나요?”라고 반문할 수 있습니다. 

 

물론 어려운 일입니다. 다만 미래의 사용자 행동이 오늘의 사용자 행동과 크게 다르지 않을 것이라고 예상하는 식으로 가정을 세우고 그 가정이 잘 들어맞기를 바라며 남은 일을 진행할 수 있죠. 가정이 틀린다면 성능이 낮은 모델을 갖게 되며, 이는 8장에서 다룰 모니터링과 9장에서 다룰 프로덕션 테스트를 통해 알아냅니다.

 

오늘날 대부분의 ML 알고리즘이 학습하는 방식을 고려할 때, 풀고자 하는 문제에 다음과 같은 특징이 더 있다면 ML 솔루션이 더욱 진가를 발휘합니다.

 

6. 반복적입니다.

인간은 퓨샷 학습(few-shot learning)에 능숙합니다. 아이들은 고양이 사진을 몇 장만 봐도 다음번에 고양이를 만나면 대부분 알아봅니다. 퓨샷 학습 연구의 흥미로운 발전에도 불구하고 대부분의 ML 알고리즘은 여전히 패턴을 학습하는 데 많은 데이터를 필요로 합니다. 작업이 반복되면 각 패턴이 여러 차례 반복되므로 기계가 학습하기 쉽습니다. 

 

7. 잘못된 예측으로 발생하는 비용이 낮습니다.

ML 모델 성능이 항상 100%가 아니라면(의미 있는 작업에서는 100%인 경우가 거의 없음) 모델은 어느 정도 실수를 범하는 셈입니다. ML은 잘못된 예측으로 발생하는 비용이 낮을 때 특히 적합합니다.

 

예를 들어, 추천 시스템은 오늘날 ML이 가장 많이 활용되는 사례에 해당합니다. 

추천 결과가 적합하지 않더라도 보통은 큰 문제를 야기하지 않기 때문입니다. 그저 사용자가 추천 결과를 클릭하지 않을 뿐이죠.

 

한 번의 예측 실수가 치명적인 결과를 초래할 가능성이 있더라도 올바른 예측에 따른 이익이 잘못된 예측에 따른 비용보다 평균적으로 크다면 ML은 여전히 적합한 솔루션일 수 있습니다. 

 

자율 주행 자동차를 예로 들어봅시다. 알고리즘 오류로 사망 사고가 일어날 가능성이 있어도 통계적으로 자율 주행 자동차가 인간 운전자보다 안전하다면 잠재적으로 더 많은 생명을 구할수 있습니다.

따라서 지금도 많은 기업이 자율 주행 자동차 개발에 뛰어들고 있습니다.

8. 대규모로 수행됩니다.

ML 솔루션은 종종 데이터, 컴퓨팅, 인프라와 인재에 대해 적지 않은 선행 투자를 필요로 합니다. 

따라서 ML 솔루션은 대규모로 적용 가능할 때 합리적이라고 간주됩니다.

 

‘대규모 수행’이라 함은 경우에 따라 의미가 다를 수 있지만 일반적으로 대규모 예측을 잘 수행 한다는 의미입니다. 예를 들어, 연간 이메일 수백만 건을 정렬하거나 하루 수천 개에 달하는 고객 지원 티켓을 어느 부서로 전달할지 예측하는 일이 있습니다.

 

문제가 일회성 예측 같지만 사실상 연달아 이어지는 예측인 경우도 있습니다. 미국 대통령 선거에서 누가 승리할지 예측하는 모델은 4년에 한 번만 예측하면 될까요? 실제로는 매시간 혹은 그보다 자주 예측을 수행합니다. 새로운 정보를 반영해 예측을 계속 업데이트해야 하기 때문이죠.

 

주어진 문제가 대규모로 수행된다는 점은 수집할 데이터가 많음을 의미하며, 이는 ML 모델을 훈련하는 데 유용한 성질입니다.

 

9. 패턴이 지속적으로 변합니다.

문화는 변합니다. 취향도 변합니다. 기술도 변합니다.

오늘날 유행하는 것이 내일은 한물 간 뉴스가 되기도 합니다. 스팸 이메일을 분류하는 작업을 생각해봅시다. 스팸 이메일을 걸러내는 문구가 오늘은 ‘나이지리아 왕자’이지만 내일은 ‘정신 나간 베트남 작가’가 될 수 있습니다.

문제가 하나 이상의 지속적으로 변하는 패턴과 관련됐다면 수작업으로 정한 규칙처럼 하드 코딩한 솔루션은 빠르게 뒤처져 구식이 될 수 있습니다. 규칙을 적절히 업데이트하기 위해 문제가 어떻게 변하는지 파악하는 작업 또한 비용이 너무 크거나 아예 불가능할 수 있습니다. 

 

한편 ML은 데이터로 학습합니다. 데이터가 어떻게 변하는지 명시적으로 파악할 필요 없이 새로운 데이터를 통해 ML 모델을 업데이트할 수 있죠. 변하는 데이터 분포에 적응하게끔 시스템을 설정할 수도 있습니다. 

 

이 접근법은 9.1절 ‘연속 학습’에서 다룹니다. 

유스 케이스는 계속 늘어나고 있으며 업계의 ML 도입이 확대됨에 따라 더욱 많아질 겁니다. 세상에 존재하는 모든 문제를 고려할 때 ML은 그 일부를 매우 잘 해결해나가고 있지만 반대로 어떤 문제는 잘 해결하지 못하며 심지어 ML을 사용하면 안 되는 문제도 있습니다. 다음과 같은 경우 오늘날 ML 알고리즘의 대다수는 사용해서는 안 됩니다.

 

● 비윤리적인 경우: 11.3.1절의 ‘사례 연구 1: 자동 채점기의 편향’에서는 ML 알고리즘 사용을 비윤리적

이라고 간주할 수 있는 사례 연구를 살펴봅니다.

● 보다 단순한 솔루션이 효과 있는 경우: 6장에서는 첫 번째 단계가 ML 솔루션이 아닌, 즉 ML 솔루션부

터 시작하지 않는 ML 모델 개발의 네 단계를 다룹니다.

● 비용 효율적이지 않은 경우

한편 ML이 문제 전체를 해결하지는 못하더라도 문제를 더 작은 구성 요소로 나눴을 때 그 일부를 해결하는 경우가 있습니다. 예를 들어, 모든 고객 문의에 답하는 챗봇을 구축하기는 어렵더라도 특정 문의가 자주 묻는 질문(FAQ) 중 하나와 일치하는지 예측하는 ML 모델은 구축할 수 있습니다.

 

자주 묻는 질문 중에 일치하는 것이 있다면 해당 답변을 제시하고, 없다면 고객 서비스 쪽으로 안내하면 되겠죠. 새로운 기술이 지금 당장은 기존 기술만큼 비용 효율적이지 않다는 이유만으로 외면하지는 않길 바랍니다. 

 

기술 발전은 대부분 점진적으로 이뤄집니다. 지금 당장은 비효율적인 기술도 시간이 흐르고 더 많은 투자가 이뤄지면 효율적으로 바뀔 수 있습니다. 기술의 가치가 다른 업계에서 입증되기까지 기다렸다가 진입하면 경쟁 업체보다 몇 년에서 수십 년까지 뒤처지게 됩니다.

 

1.1.1 머신러닝 유스 케이스

ML 유스 케이스는 기업과 소비자 애플리케이션 양쪽 모두에서 증가하고 있습니다. 2010년대 중반부터 ML을 활용해 우수한, 심지어 이전에는 불가능했던 서비스를 소비자에게 제공하는 애플리케이션이 폭발적으로 증가했습니다.

 

정보와 서비스가 폭발적으로 증가함에 따라 ML의 도움, 예컨대 검색 엔진이나 추천 시스템이 없었다면 원하는 것을 찾기가 무척 어려웠을 겁니다. 

 

아마존이나 넷플릭스 같은 웹사이트는 개인의 취향에 가장 부합할 것 같은 품목들을 추천해줍니다. 추천 품목이 마음에 들지 않으면 원하는 품목을 직접 검색할 수 있고 검색 결과 또한 ML 기반일 가능성이 큽니다. 스마트폰을 사용한다면 이미 ML이 일상생활의 많은 부분을 도와주고 있는 셈입니다. 

 

다음으로 쓸 내용을 제안하는 타이핑 예측 ML 시스템을 사용하면 문자 입력이 수월해집니다. 사진 편집 앱에서 실행되는 ML 시스템은 사진 품질을 향상하기에 가장 좋은 방법을 제안하죠. 지문이나 얼굴 인식으로 다양한 인증을 수행할 수도 있습니다. 이때 지문이나 얼굴이 사용자와 일치하는지 예측하는 ML 시스템이 필요합니다.

 

한 언어를 다른 언어로 자동 번역하는 기계 번역은 필자가 이 분야에 뛰어들게 된 계기입니다. 기계 번역은 잠재적으로 서로 다른 문화권에 속하는 사람들 간의 언어 장벽을 없애 의사소통이 가능하도록 해줍니다. 

 

베트남인인 부모님은 영어를 못하지만 구글 번역 덕분에 필자가 쓴 글을 읽고 베트남어를 못하는 필자의 친구들과 이야기를 나누기도 합니다. 

 

ML은 가정에서도 점점 더 많이 사용됩니다. 아마존 알렉사나 구글 어시스턴트 같은 스마트 개인 비서를 사용하면 반려동물이 집을 나가거나 외부인이 들어올 때 스마트 보안 카메라가 이를 알려줍니다.

 

한 친구는 노모가 홀로 지내는 것을 걱정해 가정용 건강 모니터링 시스템을 사용합니다. 

노모가 집에 혼자 있다가 넘어지면 도와줄 사람이 없지만 모니터링 시스템이 집 안에서 누군가 넘어졌는지 예측해서 알려줍니다.

 

소비자를 위한 ML 애플리케이션 시장도 급성장하고 있지만 아직까지 대부분의 ML 유스 케이스는 기업에서 이뤄집니다. 기업 ML 애플리케이션은 요구 사항과 고려 사항 측면에서 소비자 애플리케이션과 매우 다릅니다. 예외도 많지만 대부분의 기업 애플리케이션은 정확도 요구 사항이 비교적 엄격하고 레이턴시(latency) 요구 사항은 비교적 관대합니다. 예를 들어, 음성 인식 시스템의 정확도를 95%에서 95.5%로 개선했다고 해봅시다.

 

소비자 입장에서는 크게 주목할 만한 일이 아닐 겁니다. 반면 리소스 할당 시스템의 효율성을 0.1%만 개선해도 구글이나 제너럴 모터스 같은 기업은 수백만 달러를 절약할 수 있습니다. 반대의 경우도 봅시다. 

 

소비자는 1초의 레이턴시에도 집중력을 잃고 다른 앱을 열곤 하지만 기업 사용자는 레이턴시가 길어도 좀 더 관대하게 대응합니다. ML 애플리케이션으로 창업하려는 사람들에게 소비자를 대상으로 하는 앱은 배포하기는 쉬울지 몰라도 수익을 창출하기는 훨씬 어려운 편입니다. 한편 대부분의 기업 유스 케이스는 직접 경험해보지 않으면 구체적인 내용을 알기 어렵습니다.

 

알고리드미아(Algorithmia)에서 수행한 ‘2020년 기업에서 사용하는 머신러닝 현황 조사’에 따르면 기업 ML 애플리케이션은 [그림 1-3]과 같이 내부 유스 케이스(비용 절감, 고객 인사이트와 인텔리전스 생성, 내부 프로세스 자동화)와 외부 유스 케이스(고객 경험 개선, 고객 유지, 고객 상호 작용) 양쪽 모두를 다루며 매우 광범위합니다.

 

 

 

 

이상 거래 탐지는 기업 환경에서 아주 오랫동안 사용해온 ML 애플리케이션입니다. 금전적 가치를 지닌 거래를 다루는 제품과 서비스는 이상 거래 행위에 취약하기 마련입니다. 이상 탐지를 위한 ML 솔루션을 활용하면 과거의 이상 거래로 학습해 향후 거래가 이상 거래인지 여부를 예측하는 시스템을 만들 수 있습니다.

 

제품이나 서비스의 가격을 결정하는 일은 매우 까다로운 비즈니스 의사 결정 사안입니다. 여기에 ML을 적용하지 않을 이유가 있을까요? 가격 최적화는 일정 기간 동안 잘 정의된 목적 함수, 예컨대 회사의 마진, 매출, 성장률 등을 최대로 만드는 가격을 추정하는 프로세스입니다. ML 기반 가격 최적화는 수요가 계속 변하고 변동하는 가격을 소비자가 기꺼이 받아들이며 트랜잭션이 많은 경우에 가장 적합합니다. 

 

인터넷 광고, 항공권, 숙박 예약, 승차 공유처럼 말이죠.

비즈니스를 운영할 때는 예산을 세우고, 재고를 채우고, 자원을 할당하고, 가격 정책을 변경합니다.

 

이때 고객 수요를 예측하는 일이 매우 중요합니다. 

 

예를 들어, 식료품점을 운영하는 경우 재고량이 너무 적어도 너무 많아도 문제가 됩니다. 품절로 인해 고객 수요를 놓치지 않도록 재고를 넉넉히 유지하고 싶겠지만 재고량이 너무 많으면 식료품 상태가 나빠져 손실로 이어질 수 있죠.

 

새로운 사용자를 획득하는 데는 큰 비용이 듭니다. 2019년 기준, 앱 내 구매를 할 사용자 한 명을 획득하는 데 지출하는 비용은 평균 86.61달러입니다. 리프트(Lyft)의 획득 비용은 라이더당 158달러로 추산되며 기업 고객의 경우 비용은 훨씬 더 높습니다. 투자자들은 고객 획득 비용을 스타트업 실패의 주된 요인으로 꼽습니다.

 

한편 고객 획득 비용을 조금만 줄여도 수익이 크게 증가할 수 있습니다.

잠재 고객을 보다 잘 식별하고, 광고 타깃을 보다 잘 설정하고, 적시에 할인을 제공하는 식으로 말이죠. 이는 모두 ML에 적합한 작업들입니다.

 

큰 비용을 들여 획득한 고객이 그만 떠나버린다면 매우 안타까운 일이겠죠. 새로운 사용자를 획득하는 비용은 기존 사용자를 유지하는 비용의 대략 5~25배입니다.

 

고객 이탈 예측은 특정 고객이 제품 또는 서비스 사용을 중단하려고 하는 시점을 예측하고 적절한 조치를 취해 고객을 잃지 않도록 합니다. 이는 고객뿐 아니라 직원에게도 적용 가능합니다.

 

고객이 떠나지 않게 하려면 문제가 발생하는 즉시 해결해서 고객 불만을 최소화하는 일이 중요 합니다. 이때 자동화된 고객 지원 티켓 분류가 도움이 될 수 있습니다.

 

예전에는 고객이 고객 지원 티켓을 열거나 이메일을 보내면 수신 처리가 먼저 이뤄진 다음 관련 부서들을 이리저리 돌고 나서야 이를 해결할 담당자에게 도착했습니다. ML 시스템은 티켓 내용을 분석하고 어디로 보낼지 예측함으로써 응답 시간을 단축하고 고객 만족도를 높입니다. 

 

이는 내부 IT 티켓을 분류하는 데도 활용 가능합니다.

브랜드 모니터링 또한 기업 환경에서 인기 있는 ML 유스 케이스입니다. 브랜드는 기업의 소중한 자산이며, 따라서 대중과 고객이 브랜드를 어떻게 느끼는지 모니터링하는 일이 중요합니다.

 

예를 들어, 누군가가 브랜드를 언제, 어디서, 어떤 식으로 언급했는지(‘구글’과 같은 명시적 언급과 ‘검색 분야 거대 기업’과 같은 암시적 언급 양쪽 모두) 그리고 해당 언급이 어떤 감정을 담고 있는지 파악합니다.

 

갑자기 브랜드에 대한 부정적 언급이 증가하면 가능한 한 빨리 해결 하는 편이 좋겠죠. 이때 사용하는 감성 분석은 보편적인 ML 작업에 해당합니다.

 

헬스케어는 최근 많은 관심을 불러일으킨 ML 유스 케이스입니다. 피부암을 감지하고 당뇨병을 진단해주는 ML 시스템이 있습니다. 많은 헬스케어 애플리케이션이 소비자를 대상으로 하지만 정확도와 개인 정보 보호에 관한 요구 사항이 엄격하기 때문에 주로 병원 같은 의료 서비스 제공자를 통해서 혹은 의사의 진료 보조 도구로만 사용됩니다.

 

1.2 머신러닝 시스템 이해하기

ML 시스템을 이해하면 시스템을 설계하고 개발하는 데 도움이 됩니다. 이 절에서는 ML 시스템이 연구에서 활용하거나 학교에서 가르치는 ML 그리고 전통적인 소프트웨어와 어떻게 다른지 살펴봅니다.

 

1.2.1 연구용 머신러닝 vs. 프로덕션용 머신러닝

산업계에서는 ML 사례가 여전히 생소해서 ML 전문 지식이 있는 분들은 대부분 강의를 듣거나 연구를 수행하고 학술 논문을 읽는 등 학계를 통해 ML 사례를 얻고 있습니다. 이 책을 읽는 여러분도 배경이 비슷하다면 ML 시스템을 실제로 배포하는 문제를 이해하고 수많은 솔루션을 탐색하는 과정에서 겪는 학습 곡선이 가파를 수 있습니다. 프로덕션용 ML은 연구용 ML과 매우 다르기 때문이죠.

 

[표 1-1]은 주요 차이점 다섯 가지를 보여줍니다.

 

표 1-1 연구용 ML과 프로덕션용 ML의 주요 차이점

	연구용ML	프로덕션용 ML
요구 사항	벤치마크 데이터셋에서 최적의 모델 성능 달성하기	이해관계자마다 다름
계산 우선 순위	빠른 훈련, 높은 스루풋	빠른 추론, 낮은 레이턴시
데이터	정적임	끊임없이 변동함
공정성	중요하지 않은 경우가 많음	반드시 고려해야 함
해석 가능성	중요하지 않은 경우가 많음	반드시 고려해야 함

 

* 연구용 ML 중에서도 연속 학습에 중점을 두는 분야가 있습니다. 연속 학습은 데이터 분포가 변화하는 환경에서 모델을 개발하는 방법이며, 9장에서 이를 자세히 다룹니다.

  

 

다양한 이해관계자와 요구 사항

연구나 리더보드 프로젝트에 참여하는 분들은 종종 하나의 목표를 추구합니다. 가장 일반적인 목표는 모델 성능, 다시 말해 벤치마크 데이터셋에서 최첨단 결과를 달성하는 모델을 개발하는 일입니다. 연구원들은 약간의 성능 향상을 위해 모델 구조를 너무 복잡하게 만들어 프로덕션 적용을 어렵게 하는 경우가 많습니다.

 

ML 시스템을 프로덕션에 적용하는 과정에는 많은 이해관계자가 얽혀 있으며 각각 요구 사항이 다릅니다. 요구 사항들은 서로 충돌할 때도 많으므로 모든 요구 사항을 충족하는 ML 모델을 설계, 개발, 선택하기는 어려울 수 있습니다.

 

한 가지 프로젝트를 예로 들어보죠. 사용자에게 음식점을 추천하는 모바일 앱을 개발한다고 합시다. 이 앱은 주문이 들어올 때마다 음식점에 수수료 10%를 부과해 수익을 창출합니다. 

 

주문 금액이 높으면 주문 금액이 낮을 때보다 더 많은 수익을 창출한다는 의미죠. 이 프로젝트에는 ML 엔지니어, 영업 사원, 프로덕트 매니저, 인프라 엔지니어 및 관리자가 있습니다. 

 

각 이해관계자의 요구 사항을 살펴봅시다.

ML 엔지니어

더 많은 데이터가 포함된 더 복잡한 모델을 사용해 사용자가 주문할 가능성이 가장 높은 음식점을 추천하기를 원합니다.

영업 팀

비싼 음식점일수록 수수료가 높으므로 더 비싼 음식점을 추천하는 모델을 원합니다. 

 

제품 팀

레이턴시가 증가할 때마다 서비스를 통한 주문이 감소하므로 100밀리초 이내에 추천 음식점을 반환할 수 있는 모델을 원합니다.

 

ML 플랫폼 팀

트래픽이 증가함에 따라 기존 시스템을 스케일링하는 문제 때문에 한밤중에 일어나야하는 경우가 있어, 플랫폼 개선을 우선시하기 위해 모델 업데이트를 보류하기를 원합니다.

 

관리자

마진을 최대화하기를 원합니다. 한 가지 방법은 ML 팀을 내보내는 것입니다. 

 

‘사용자가 클릭할 가능성이 가장 높은 음식점 추천하기’와 ‘앱에 가장 큰 수익을 가져올 음식점 추천하기’는 서로 다른 두 가지 목표입니다. 

 

2.4.2절 ‘목적 함수’의 ‘목적 함수 분리하기’에서 서로 다른 목적을 만족시키는 ML 시스템을 개발하는 방법을 논의할 텐데, 이때 목표마다 모델을 하나씩 개발한 뒤 각각의 예측을 결합합니다.

서로 다른 모델 두 개가 있다고 상상해봅시다. 모델 A는 사용자가 클릭할 가능성이 가장 높은 음식점을 추천하고 모델 B는 앱에 가장 큰 수익을 가져올 음식점을 추천합니다. 

 

A와 B는 매우 다른 모델일 수 있습니다. 둘 중 어느 모델을 사용자에게 배포해야 할까요? 결정을 더 어렵게 만들어보죠. A와 B 모두 제품 팀에서 제시한 요구 사항을 충족하지 않는다고 가정합시다. 

 

즉, 100밀리초 이내에 음식점 추천을 반환할 수 없습니다. ML 프로젝트를 개발할 때 ML 엔지니어는 모든 이해관계자의 요구 사항을 파악하고 각각이 얼마나 엄격한지 이해해야 합니다. 

 

예를 들어, 100밀리초 이내에 추천 결과를 반환하는 것이 필수 요구 사항이라고 가정해보죠. 그런데 회사는 모델이 음식점을 추천하기까지 100밀리초 이상이 소요된다면 사용자 중 10%가 인내심을 잃고 앱을 종료한다는 사실을 발견했습니다. 

 

그러면 모델 A, B 모두 작동하지 않겠죠. 반면에 이것이 필수 요구 사항이 아니라면 여전히 모델 A나 B를 고려할 만합니다.

 

프로덕션용 ML은 연구용 ML과 요구 사항이 다릅니다. 따라서 연구 프로젝트가 성공적이더라도 프로덕션에 사용되지는 않을 수 있죠. 예를 들어, 앙상블은 100만 달러 상금으로 유명한 넷플릭스 프라이즈를 비롯한 많은 ML 대회 우승자 사이에서 인기 있는 기술이지만 프로덕션에서는 널리 사용되지 않습니다. 앙상블은 여러 학습 알고리즘을 결합해 단일 학습 알고리즘보다 예측 성능을 개선합니다.

 

ML 시스템 성능을 약간 향상하지만 한편으로는 시스템이 너무 복잡해져 프로덕션에 유용하지 않게 되기도 하죠. 앙상블에 관해서는 6.1.2절 ‘앙상블 ’에서 더 논의합니다.

 

많은 작업에서 성능이 약간만 좋아져도 수익이 크게 향상되거나 비용이 크게 절감되기도 합니다. 

 

예를 들어, 제품 추천 시스템의 클릭률(CTR)이 0.2% 향상되면 전자 상거래 사이트의 수익이 수백만 달러 증가합니다. 반면에 많은 작업의 경우 작은 개선 사항이 사용자에게 눈에 띄지 않을 수 있습니다. 이러한 작업에서는, 단순한 모델의 성능이 합리적이라면 복잡한 모델은 복잡성을 정당화할 만큼 훨씬 나은 성능을 발휘해야 합니다.

 

ML 리더보드에 대한 비판

최근 몇 년간 ML 리더보드에 대해 많은 비판이 이어지고 있습니다. 캐글 같은 대회와 이미지넷이나 GLUE19 같은 연구 리더보드 모두에 말이죠.

 

이러한 대회에서는 ML 시스템 구축에 필요한 많은 어려운 단계들이 이미 완료됐다는 비판은 타당합니다. 게다가 여러 팀이 동일한 홀드아웃 테스트 세트에서 테스트할 때 발생하는 다중 가설 테스트 시나리오로 인해, 우연히 어떤 모델이 나머지 모델보다 더 잘 수행된다는 주장도 있습니다. 

 

연구자들은 연구와 프로덕션 사이의 이해 불일치에 주목해왔습니다. 

EMNLP 2020 논문에서 에트하야라즈와 주래프스키는 벤치마크가 간결성, 공정성, 에너지 효율성 등 실무자가 중시하는 특성을 희생해 보다 정확한 모델을 만들도록 장려함으로써 자연어 처리(NLP)의 발전을 주도하는 데 기여했다고 주장했습니다.  

  

계산 우선순위

ML 시스템을 배포한 경험이 없는 분들은 시스템을 설계할 때 종종 모델 개발에만 너무 집중하고 배포와 유지 관리를 소홀히 하는 실수를 합니다.

 

모델 개발 프로세스에서 각기 다른 모델 여러 개를 훈련할 수 있으며 각 모델은 훈련 데이터를 여러 번 순회합니다. 그리고 훈련된 모델은 각각 검증 데이터에 대한 예측을 생성해 점수를 리포트합니다.

 

검증 데이터는 일반적으로 훈련 데이터보다 훨씬 작습니다. 즉, 모델 개발 단계에서 훈련이 병목이 됩니다. 반면에 모델을 배포하고 나면 모델의 역할은 예측을 생성하는 일이므로 추론이 병목입니다.

 

연구에서는 일반적으로 빠른 훈련을 우선시하지만 프로덕션에서는 일반적으로 빠른 추론을 우선시합니다. 

한 가지 결론은 연구에서는 높은 스루풋을 우선시하는 반면에 프로덕션에서는 낮은 레이턴시를 우선시한다는 점입니다. 

 

레이턴시는 쿼리를 수신하고 결과를 반환하는 데 걸리는 시간을 의미하며 스루풋은 특정 기간 내에 처리된 쿼리 수를 의미합니다.

 

 NOTE   용어 충돌

일부 책에서는 레이턴시와 응답 시간(response time)을 구별합니다. 마틴 클레프만은 자신의 저서 『데이터 중심 애플리케이션 설계』(위키북스, 2018)에 “응답 시간은 고객이 느끼는 시간입니다. 

 

요청을 처리하는 시간(서비스 시간)뿐 아니라 네트워크 지연과 대기열 지연도 포함됩니다.

레이턴시는 요청이 처리되기를 기다리는 기간이며, 이 기간 동안 애플리케이션은 서비스를 기다리는 대기 상태입니다.”라고 썼습니다.

 

이 책에서는 논의를 단순화하고 ML 커뮤니티에서 사용하는 용어와 일관성을 유지하고자 레이턴시를 ‘응답 시간’이라는 의미로 사용합니다. 따라서 요청에 대한 레이턴시는 요청을 전송한 후 응답을 수신하기까지 시간을 측정한 수치입니다.

 

구글 번역을 예로 들면, 평균 레이턴시는 사용자가 ‘번역’을 클릭한 후 번역 결과가 표시 되기까지 걸리는 평균 시간이고 스루풋은 초당 처리되는 쿼리 개수입니다.

 

시스템이 항상 쿼리를 한 번에 하나씩 처리한다면 레이턴시가 길수록 스루풋이 낮아집니다. 

평균 레이턴시가 10밀리초이면, 즉 쿼리를 처리하는 데 10밀리초가 소요되면 스루풋은 초당 100개 쿼리입니다. 평균 레이턴시가 100밀리초이면 스루풋은 초당 10개 쿼리가 되죠. 

 

한편 최신 분산 시스템은 대부분 쿼리를 배치 처리하므로 레이턴시가 길수록 스루풋이 높습니다.

쿼리를 한 번에 열 개씩 처리하고 배치 처리를 실행하는 데 10밀리초가 걸린다면 평균 레이턴시는 여전히 10밀리초지만 스루풋은 10배 높아집니다(초당 쿼리 1,000개). 

 

쿼리를 한번에 50개씩 처리하고 배치 처리를 실행하는 데 20밀리초가 걸린다면 평균 레이턴시는 20밀리초이고 스루풋은 초당 2,500개 쿼리입니다. 레이턴시와 스루풋이 모두 증가했네요! [그림1-4]는 쿼리를 한 번에 하나씩 처리할 때와 배치 처리할 때 각각 레이턴시와 스루풋 간의 트레이드오프가 어떤지 보여줍니다.

 

 

 

온라인 쿼리를 배치 처리한다면 훨씬 복잡합니다. 배치 처리를 할 때는 시스템이 쿼리를 처리하기 전에 충분한 쿼리가 배치에 도달할 때까지 기다려야 하므로 레이턴시가 더욱 길어지죠.

 

연구에서는 1초에 처리할 수 있는 샘플 수, 즉 스루풋에 더 집중하고 각 샘플이 처리되는 데 걸리는 시간인 레이턴시는 상대적으로 덜 고려합니다. 예를 들어, 적극적으로 배치 처리를 사용해 스루풋을 늘리기 위해 레이턴시를 늘리기도 합니다.

 

반면에 모델을 실제 환경에 배포하면 레이턴시가 매우 중요해집니다. 2017년 아카마이(Akamai) 연구에 따르면 100밀리초가 지연되면 전환율 conversion rate이 7% 감소할 수 있습니다.23 2019년 부킹닷컴(Booking.com)은 레이턴시가 약 30% 증가하면 전환율이 약 0.5% 증가한다는 사실을 발견했으며 2016년 구글은 페이지를 로드하는 데 3초 이상 걸리면 모바일 사용자 중 절반 이상이 페이지를 떠난다는 사실을 발견했습니다.

 

오늘날 사용자들은 그보다 더 인내심이 부족하죠.

 

프로덕션 레이턴시를 줄이려면 하드웨어 하나로 한 번에 처리 가능한 쿼리 개수를 줄여야 할 수 있습니다. 하드웨어가 한 번에 처리할 수 있는 개수보다 훨씬 적은 쿼리를 처리한다면 하드웨어 활용도가 낮아져 각 쿼리를 처리하는 비용이 늘어나는 셈입니다.

 

레이턴시는 개별 수치가 아닌 분포임을 기억합시다. 이 분포를 단순화해 단일 수치(타임 윈도 내 모든 요청의 평균 레이턴시)로 나타내고 싶지만 이 수치는 오해의 소지가 있습니다. 

 

요청 10개가 있고 레이턴시는 각각 100밀리초, 102밀리초, 100밀리초, 100밀리초, 99밀리초, 104밀리초, 110밀리초, 90밀리초, 3,000밀리초, 95밀리초라고 가정해보죠. 이때 평균 레이턴시는 390밀리초로 이때 평균 레이턴시는 390밀리초로 시스템의 실제 레이턴시보다 느린 값이 됩니다. 

 

이 경우 네트워크 오류로 한 요청을 처리하는 것이 다른 요청들을 처리하는 것보다 훨씬 느려졌을 수 있으므로 해당 문제가 발생한 요청을 검토해야 합니다.

 

산술 평균 같은 단일 수치보다 백분위수를 사용하면 유용합니다. 백분위수는 요청의 특정 비율에 대해 알려줍니다. 가장 흔히 사용하는 백분위수는 50번째 백분위수(p50으로 약칭)로 중앙값(median)이라고도 합니다. 중앙값이 100밀리초이면 요청의 절반은 100밀리초보다 오래 걸리고 요청의 절반은 100밀리초보다 적게 걸립니다.

 

높은 백분위수는 문제의 징후일 수 있는 이상치outlier를 발견하는 데 도움이 됩니다. 일반적으로 확인하는 백분위수는 p90, p95, p99입니다. 앞선 예시의 10개 요청에 대한 90번째 백분위수(p90)는 3,000밀리초로 이상치입니다.

 

이렇게 높은 백분위수는 사용자 중 매우 낮은 비율만이 해당하지만 때로는 가장 중요한 사용자 이기도 하니 잘 살펴봅시다. 예를 들어, 아마존 Amazon 웹사이트에서 가장 느린 요청을 받은 고객은 계정에 가장 많은 데이터가 있는 고객인 경우가 많습니다. 그동안 상품을 많이 구매했고, 따라서 가장 가치 있는 고객이죠.

 

따라서 높은 백분위수를 사용해 시스템의 성능 요구 사항을 지정하는 것은 일반적입니다. 예를들어, 프로덕트 매니저는 시스템의 90번째 백분위수 또는 99.9번째 백분위수 레이턴시가 특정수치보다 낮아야 한다고 지정할 수 있습니다.

 

데이터

연구 단계에서 작업하는 데이터셋은 종종 깨끗하고 형식이 잘 지정돼 있어 우리가 모델 개발에 집중할 수 있습니다. 이러한 데이터셋은 본질적으로 정적이라 커뮤니티가 새로운 아키텍처와 기술을 벤치마킹하는 데 사용할 수 있죠. 

 

즉, 많은 사람이 동일한 데이터셋을 사용하고 논의했을 수 있으며 데이터셋의 단점 또한 알려져 있음을 의미합니다. 데이터를 처리하고 모델에 직접 입력하는 오픈 소스 스크립트를 찾을 수도 있죠.

한편 프로덕션 단계의 데이터는 훨씬 더 복잡합니다. 잡음이 많고 비정형일 수 있으며 끊임없이 변화하죠. 게다가 데이터가 편향됐을 수 있는데 어떻게 편향됐는지 모를 가능성이 큽니다. 

 

레이블이 있는 경우 레이블이 희소하고 불균형하거나 올바르지 않을 수도 있습니다. 프로젝트 또는 비즈니스 요구 사항을 변경하려면 기존 레이블의 일부 또는 전체를 업데이트해야 할 수 있습니다.

 

사용자 데이터로 작업할 때는 개인 정보 보호 및 규제 문제도 주의해야 합니다.

11.3.1절의 ‘사례 연구 2: 익명화된 데이터의 위험성’에서는 사용자 데이터를 부적절하게 처리하는 사례 연구를 살펴봅니다.

 

연구에서는 대부분 과거 데이터, 예컨대 이미 존재하고 어딘가에 저장된 데이터로 작업합니다. 반면에 프로덕션 환경에서는 사용자, 시스템 및 서드 파티 데이터에 의해 지속적으로 생성되는 데이터로 작업해야 할 가능성이 높습니다.

 

[그림 1-5]는 테슬라 Tesla AI 디렉터로 재직했던 안드레이 카르파티(Andrej Karpathy)가 테슬라에서

직면한 데이터 문제와 박사 과정 중에 직면한 데이터 문제를 비교해 보여줍니다.

 

 

 

공정성

연구 단계에서는 아직 모델이 사용되지 않아 연구자가 공정성을 나중으로 미루기 쉽습니다. ‘먼저 최첨단 기술을 습득하고 공정성은 프로덕션에 들어갈 때 고민해보자’라고 생각할 수 있죠. 

 

하지만 프로덕션에 들어가고 나면 너무 늦습니다. 더 높은 정확도나 더 낮은 레이턴시를 위해 모델을 최적화하면 모델이 최고 수준의 기술을 능가한다는 것을 보여줄 수 있죠. 하지만 이 책을 쓰는 시점에 공정성을 객관적으로 비교 측정할 수 있는 지표는 없는 상황입니다.

 

여러분 혹은 주변에 있는 누군가는 자신도 모르는 사이에 편향된 수학 알고리즘의 희생자일 수 있습니다. 몇 가지 예를 들어봅시다. 대출 심사 관련 ML 알고리즘이 우편 번호를 활용한다면, 여기에 개인의 사회경제적 배경에 대한 편견이 담겨 있어 대출 신청이 거부될 수 있습니다. 

 

이력서 랭킹 시스템의 고용주가 이름 철자를 활용해 이력서의 순위가 낮게 나올 수 있습니다. 

담보 대출은 신용 점수를 부분적으로 고려하는데, 이는 부자에게 유리하고 가난한 사람에게 불리해 가난한 사람의 이자율이 더 높게 책정될 수도 있죠. 현실에서 나타나는 ML 편향의 또 다른 예로는 예측 치안(predictive policing) 알고리즘, 잠재적 고용주가 관리하는 성격 검사, 대학 순위 등 이 있습니다.

CBS 뉴스 기사에 따르면 2019년에 버클리 연구원들은 대면 대출과 온라인 대출 모두 2008년에서 2015년 사이에 총 130만 명의 신용할 수 있는 흑인 및 라틴계 지원자를 거부했다는 사실을 발견했습니다. 거부된 신청서에서 소득과 신용 점수는 그대로 사용하고 인종 식별자를 삭제 했더니 담보 대출이 승인됐죠.

 

더 끔찍한 예시가 궁금하다면 캐시 오닐 Cathy O’Neil의 『대량살상수학무기 Weapons of Math Destruction』(흐름출판, 2017)를 읽어보기 바랍니다.

 

ML 알고리즘은 과거 시점 데이터를 대량으로 분석하고 패턴을 찾아내 이를 기반으로 신규 데이터에 대한 추론을 수행합니다. 훈련 시점과 추론 시점이 일치하지 않으므로 시점 차이에서 발생할 수 있는 데이터 분포 시프트 같은 편향이 발생할 수 있습니다(데이터 분포 시프트는 8장에서 자세히 다룹니다). 

 

예를 들어, ML 알고리즘이 대규모로 배포되면 알고리즘은 대규모로 사람을 분류합니다. 운영자가 한 번에 소수의 개인에 대해서만 종합적인 판단을 내릴 수 있다면, ML 알고리즘은 몇 초 만에 수백만 명에 대해 포괄적인 판단을 내릴 수 있죠. 하지만 이는 소수 그룹의 구성원에게 피해를 줄 수도 있음을 의미합니다. 

 

소수 그룹을 잘못 분류해도 모델의 전체 성능 지표에는 영향이 적기 때문이죠. 

알고리즘이 이미 인구의 98%에 대해 정확한 예측을 할 수 있고 나머지 2%에 대한 예측을 개선하는 데 몇 배의 비용이 발생한다면, 안타깝지만 일부 회사는 예측을 개선하지 않을 수 있습니다.

2019년 맥킨지 앤 컴퍼니의 연구 조사에서 설문에 응한 대기업 중 13%만이 알고리즘 편향 및 차별과 같은 형평성과 공정성에 대한 위험을 완화하기 위해 조치를 취하고 있다고 답했습니다.

 

하지만 이런 추세는 빠르게 변화하고 있습니다. 11장에서 책임 있는(responsible AI)의 공정성을 비롯한 여러 측면을 다룹니다.

 

해석 가능성

2020년 초, 튜링상(Turing Award) 수상자인 제프리 힌튼 교수는 ML 시스템의 해석 가능성의 중요성에 관해 논란이 많은 질문을 제시했습니다. “당신이 암에 걸렸다고 가정해보세요. AI 외과의는 어떻게 작동하는지 설명할 수 없는 블랙박스이지만 완치율이 90%이고 인간 외과의는 완치율이 80%라고 할 때 둘 중 하나를 선택해야 합니다. AI 외과의가 불법이기를 원하나요?”

 

몇 주 후 비기술 분야 공기업의 기술 경영자 30명으로 구성된 그룹에 이 질문을 했더니 그룹의 절반만이 매우 효과적이지만 설명할 수 없는 AI 외과의에게 수술받기를 원했고, 나머지 절반은인간 외과의에게 수술받기를 원했습니다.

 

우리는 대부분 전자레인지가 어떻게 작동하는지 모르면서도 사용하는 데 거리낌이 없죠. 하지만 AI에 대해서는 다릅니다. 특히 AI가 인생에서 중요한 결정을 내리는 경우 그 작동 방식을 이해하고 싶어 하는 사람이 많습니다.

 

대부분의 ML 연구가 여전히 모델 성능이라는 단일 목표로만 평가되기에 모델 해석 가능성에 대한 연구는 장려되지 않습니다. 하지만 산업계 대부분의 ML 유스 케이스에서 해석 가능성은 선택이 아닌 필수입니다.

첫 번째 이유는 해석 가능성이 비즈니스 리더와 최종 사용자 모두에게 중요하기 때문입니다. 모델을 신뢰하고 앞서 언급한 잠재 편향을 감지할 수 있도록 결정이 내려진 이유를 이해해야 하죠.

 

두 번째 이유는 개발자가 모델을 디버깅하고 개선할 수 있는 것이 중요하기 때문입니다. 해석 가능성이 요구 사항이라고 해서 모두가 요구 사항을 따르지는 않습니다. 2019년 기준, 대기업 중 19%만이 알고리즘의 설명 가능성을 개선하기 위해 노력하고 있죠. 

 

논의

누군가는 ML의 학문적 측면만 알아도 괜찮다고 주장할 수 있습니다. 연구 분야에 일자리가 충분히 많다며 말이죠. 첫 번째 부분, 즉 ML의 학문적 측면만 알아도 된다는 점은 사실이지만 두번째 부분은 그렇지 않습니다.

순수한 연구를 추구하는 것도 중요하지만 대부분의 회사는 단기 비즈니스 적용 및 성과로 이어지지 않는 한 이를 감당할 여력이 없습니다. 연구 커뮤니티가 ‘더 크고 더 나은’ 접근법을 취한 현 시점은 특히 그렇습니다.

 

새로운 모델에는 종종 방대한 데이터가 필요하고 컴퓨팅에만 수천만 달러가 들죠.

 

ML 연구와 기성(off-the-shelf)모델에 접근하기 쉬워지면서 점점 많은 사람과 조직이 기성 모델을 응용할 방법을 찾고 싶어 하고, 따라서 프로덕션 ML에 대한 수요가 증가합니다.

ML 관련 업무의 대부분은 ML을 프로덕션에 적용하기를 요구할 것이며, 이미 적용하고 있습니다.

 

1.2.2 머신러닝 시스템 vs. 전통적인 소프트웨어

ML은 소프트웨어 엔지니어링(SWE)의 일부이며 소프트웨어는 반세기 이상 프로덕션에서 성공적으로 사용되고 있습니다. 그런데 왜 소프트웨어 엔지니어링에서 검증된 모범 사례를 ML에 적용하지 않을까요?

 

좋은 아이디어네요. 사실 ML 전문가가 훌륭한 소프트웨어 엔지니어라면 ML 프로덕션도 훌륭할 겁니다. 기존 SWE 도구로 ML 애플리케이션을 개발하고 배포할 수 있죠.

 

하지만 ML 애플리케이션에는 고유한 난제가 많기에 자체 도구가 필요합니다. SWE에는 코드와 데이터가 분리돼 있다는 가정이 있습니다. SWE에서는 가능한 한 코드와 데이터를 모듈화 되고 분리된 상태로 유지하기를 원합니다(자세한 내용은 위키백과 문서 ‘관심사 분리(Separation of concerns)’를 참조하기 바랍니다).

반대로 ML 시스템은 코드, 데이터 그리고 이 둘로부터 생성된 아티팩트(부산물)로 이루어져 있습니다. 지난 10년간의 추세는 가장 많고 좋은 데이터로 개발한 애플리케이션이 우세함을 보여줍니다. 

 

대부분의 기업은 ML 알고리즘을 개선하기보다는 데이터를 개선하는 데 집중할 겁니다. 데이터는 빠르게 변할 수 있으므로 ML 애플리케이션은 더 빠른 개발 및 배포 주기가 필요한 변화하는 환경에 적응해야 하죠.

 

기존 SWE에서는 코드 테스트 및 버전 관리에만 집중하면 되지만 ML을 사용하면 데이터 또한 테스트하고 버전을 지정해야 합니다. 이것이 어려운 부분입니다. 대규모 데이터셋의 버전은 어떻게 지정할까요? 데이터 샘플이 시스템에 좋은지 나쁜지 어떻게 알 수 있을까요? 모든 데이터 샘플이 동일하지는 않습니다.

 

일부 샘플이 나머지 샘플보다 여러분의 모델에 더 중요할 수 있죠. 예를 들어, 모델이 이미 정상 폐 스캔 100만 건과 악성 폐 스캔 1,000건으로 훈련했다면, 악성 폐 스캔은 정상 폐 스캔보다 훨씬 가치가 높습니다. 사용 가능한 모든 데이터를 무차별적으로 사용하면 모델은 성능이 저하되고 데이터 오염 공격에 취약해질 수도 있습니다. 

 

ML 모델의 크기 또한 과제입니다. 2022년 기준, ML 모델에는 일반적으로 수억 혹은 수십억 개 매개변수가 있으며, 이를 메모리에 올리려면 수 기가바이트에 달하는 램이 필요합니다. 

 

지금부터 몇 년 후에는 10억 개의 매개변수도 평범해 보일 수 있죠. 예를 들면, “사람을 달에 보낸 컴퓨터에 32메가바이트의 램만 있었다는 것이 믿기나요?”

 

그러나 현재 시점에서, 특히 에지 디바이스35에서 이러한 대형 모델을 프로덕션에 적용하는 일은 엄청난 엔지니어링 과제입니다. 그리고 모델을 실생활에 유용할 만큼 빠르게 실행할 방법도 고민해야 하죠.

 

텍스트 자동 완성 모델을 예로 들면, 다음 문자를 제안하는 데 걸리는 시간이 입력하는 데 걸리는 시간보다 길면 모델은 쓸모가 없습니다. 

 

프로덕션 환경에서 이러한 모델을 모니터링하고 디버깅하는 일 또한 사소하지 않습니다. ML 모델이 복잡해지고 작업에 대한 가시성이 떨어짐에 따라, 무엇이 잘못됐는지 파악하거나 문제가 발생했을 때 신속하게 경고를 받기가 어렵습니다.

 

좋은 소식은 이러한 엔지니어링 과제들이 엄청난 속도로 해결되고 있다는 점입니다. 2018년에BERT(Bidirectional Encoder Representations from Transformers) 논문이 처음 공개됐을 때 사람들은 BERT가 너무 크고 복잡하고 느려서 실용적이지 않다고 평했습니다. 

 

사전 훈련된 대형 BERT 모델은 매개변수가 3억 4,000만 개이고 용량은 1.35기가바이트죠. 하지만 2년 후 BERT와 그변형 모델들은 구글 내 거의 모든 영어 검색에 사용됐습니다.

 

1.3 정리

1장에서는 ML을 실제로 적용하는 데 필요한 것들을 전달하고자 했습니다. 먼저 프로덕션용 ML의 광범위한 유스 케이스를 둘러봤습니다. 사람들은 보통 소비자 대상 애플리케이션의 ML에 익숙하지만 ML 유스 케이스의 대다수는 엔터프라이즈용입니다. 따라서 어떤 경우에 ML 솔루션이 적절한지 논의했습니다.

 

ML은 많은 문제를 훌륭히 해결하지만 모든 문제를 해결할 수는 없으며 모든 문제에 적합하지도 않습니다.

다만 ML이 해결할 수 없는 문제일지라도 ML이 해결책의 실마리가 될 수 있습니다.

 

이 장에서는 또한 연구용 ML과 프로덕션용 ML의 차이점을 강조했습니다. 차이점에는 관련 이해관계자, 계산 우선순위, 사용된 데이터 속성, 공정성 문제의 심각성, 해석 가능성 요구 사항등이 있습니다.

 

이 내용은 학계에서 ML 프로덕션으로 넘어오는 분에게 가장 유용합니다. 이어서 ML 시스템이 전통적인 소프트웨어 시스템과 어떻게 다른지 논의했는데, 이것이 이 책이 필요한 이유입니다.

 

ML 시스템은 다양한 요소로 구성된 복잡한 시스템입니다. 프로덕션에서 ML 시스템을 작업하는 데이터 과학자와 ML 엔지니어는 ML 알고리즘에만 집중하는 걸로는 절대 충분치 않다는 사실을 깨달을 겁니다.

 

알고리즘 외에 시스템의 다른 측면, 예컨대 데이터 스택, 배포, 모니터링, 유지 관리, 인프라에 관해 아는 것이 중요합니다. 이 책은 ML 시스템 개발에 대해 시스템 접근법을 취합니다.

 

ML 알고리즘만 다루지 않고 시스템의 모든 구성 요소를 전체적으로 고려한다는 뜻이죠. 이러한 전체적인 접근법이 무엇을 의미하는지 다음 장에서 자세히 알아봅시다.

 

---

 

<머신러닝 시스템 설계>33페이지 ~ 59페이지 내용을 발췌하여 작성 되었습니다. 

  

머신러닝 시스템 설계: 프로젝트 범위 산정부터 프로덕션 배포 후 모니터링까지, MLOps 완벽 해부하기

 

• 저자: 칩 후옌
• 번역: 김대근 , 김영민
• 출간: 2023-03-14
• 페이지: 436 쪽
• ISBN: 9791169210850