기술보다는 문제에 - 머신러닝 엔지니어링 인 액션

머신러닝 엔지니어링 인 액션 - 머신러닝 엔지니어링 개념부터 프로덕션까지 성공적인 머신러닝 프로젝트 구축하기
벤 윌슨 지음, 김대근.심대열 옮김 / 한빛미디어 / 2023년 12월

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.

머신러닝 붐이 일었을 때와 달리 점점 더 시간이 가면 갈수록 머신러닝 기법에 대한 강조보다는 어떻게 프로젝트를 구성하는지, 실무에서 어떤 점들을 고려해야 하는지, 재무적인 관점을 어떻게 어필해야 하는지와 같이 조금 더 실무와 가까운 내용의 책들이 나오고 있다. 

이 책도 그런 책 중 하나다. 챕터 4까지 코드 한 줄 안나온다. 

계속해서 문제 정의와 스코프 설정에 대한 내용을 강조한다. 

저자는 처음부터 현자였던 걸까? 

그렇게 포장할 수도 있겠지만, 저자는 포장하지 않고 자신의 아픈 상처를 드러낸다. 

66쪽을 보면 이런 구절이 나온다.

흥미로운 최신 알고리듬을 사용하고 싶은 열정이 프로젝트에서 형편없이 발휘된 사례를 여러 번 목격했습니다. 대표적인 예는 이미지 해상도 업스케일링을 위한 GAN 프로젝트로, 12명의 데이터 과학자로 구성된 팀이 10개월이 걸려서야 프로덕션 준비 및 확장 가능한 상태에 도달할 수 있었습니다. 제가 경영진과 대화할 때는 회사가 이탈 모델, 사기 탐지 모델, 수익 예측 모델을 구축하기 위해 컨설턴트를 고용한 상태였습니다. 경영진은 내부 팀이 R&D 프로젝트를 하느라 너무 바쁘기에 중요한 모델링 작업을 외부 컨설턴트에게 맡겨야 한다고 생각했죠. 결국 이 회사와 일한 지 12주 만에 데이터 과학 팀 전체가 해고되었고 회사는 이미지 프로젝트를 포기했습니다.

경영진과 대화를 한다고 하는 걸 봐서, 저자가 팀 리드였던거라고 추론해본다면 저자는 잘못된 프로젝트 선정과 잘못된 스코프 설정 등으로 인해 3개월만에 팀이 폭파되는 경험을 온전히 감내해야만 했다. 단순히 실무자도 아니고 책임자이니 팀원들의 비난까지 얼마나 받았을지 쉽게 상상해볼 수 있다.

그만큼 머신러닝 프로젝트는 예상외로 쉽지 않다. 아무리 ChatGPT가 나오고 코딩을 배워본 적 없는 초심자라도 크롤링도 하고 모든 걸 다 할 수 있는 세상이라고 하지만, 돈이 왔다갔다 하는 실무 환경에서 성과를 내기 위해선 그 이상의 뭔가가 있어야 하고, 그건 예전부터 강조되어왔던 문제정의와 커뮤니케이션 그리고 이를 뒷받침해 줄 적절한 시스템이다. 

XGBoost를 써서 Accuracy가 98.9%나왔느냐 99%가 나왔느냐는 캐글 컴피티션에서는 중요할지 몰라도, 실무에서는 중요할 수도 있고 중요하지 않을 수도 있다. 아니 오히려 전혀 중요하지 않을 수도 있다. 그렇기에 저자는 계속해서 오컴의 면도날 법칙, 즉 간단하게 문제를 처리할 수 있다면 간단하게 처리하는 게 최선이며, 복잡성은 차근차근 높여갈 것을 조언한다. 어느 정도 기법에 대해서 익히고 실무가 궁금한 사람에게 이 책은 적합할 듯 하다.

밑줄긋기

p.16

p.35

ML 프로젝트가 더욱 복잡해지는 이유는 전통적인 소프트웨어 개발 프로젝트와는 다른 두 가지 중요한 요소 때문입니다.

첫째는 프로젝트의 기대치에 대한 세부 사항이 부족하다는 점과

둘째로 ML을 활용함에 있어서 산업의 성숙도가 상대적으로 떨어진다는 점입니다.

1990년대 초반의 소프트웨어 엔지니어링의 상황을 떠올려 보면 이해하기 쉬울 겁니다. 그 당시 기업들은 소프트웨어 기술을 잘 활용하는 방법을 알지 못했고, 관련 도구 또한 턱없이 부족했습니다. 따라서 많은 프로젝트에서 소프트웨어 엔지니어링 팀이 업무 기대치를 충족시키지 못하는 상황이 발생할 수밖에 없었습니다. 과거를 비춰볼 때 현재 2020년대의 ML 업무는 30년 전 소프트웨어 엔지니어링 위치에 있다고 볼 수 있습니다.

p.37~38

잘못된 문제를 해결하기 위한 ML 솔루션 구축만큼 사기를 저하시키는 일은 없습니다.

프로젝트가 실패하는 다양한 원인 중에서 프로젝트 계획 수립 실패는 프로젝트가 무산되는 가장 큰 이유입니다. 여러분이 새로 입사한 데이터 과학자라고 생각해보세요. 첫째 주에는 마케팅 팀의 임원이 찾아와 심각한 비즈니스 문제를 그들의 용어로 설명합니다. 마케팅 팀에서는 고객과 소통할 수 있는 효율적인 방법을 찾아내 고객이 관심 있어 할 만한 행사를 이메일로 홍보해야 하는 상황입니다. 하지만 경영진은 세부적인 내용을 완전히 무시한 채 "이메일 열람 비율이 올라갔으면 좋곘다"라고만 말합니다.

이 상황에서 마케팅 팀의 팀원들에게 이메일 열람률 상승이라는 최종 목표에만 촛점을 두고 질문한다면 그들은 이를 달성할 무수한 방법을 이야기할 것입니다. 고객에게 맞춤화된 콘텐츠를 추천해주는 이메일을 작성하고 싶은가요? 자연어 처리 기반의 시스템으로 각 고객에게 적합한 제목을 찾고 싶은가요? 아니면 추천 시스템을 구축해 일별 판매 데이터를 기반으로 고객과 연관성이 높은 제품 목록을 예측하려고 하나요?

문제에 대한 가이드가 거의 주어지지 않은 채 선택할 수 있는 옵션이 매우 다양하고, 복잡성 또한 각기 다르기 때문에 경영진의 기대에 부합하는 솔루션을 만들기란 거의 불가능합니다. 하지만 적절한 계획 수립에 대해 논의해본다면 더 디테일한 부분을 파악할 수 있고, 경영진이 기대하는 바를 명확하게 정의할 수 있습니다. 즉, 경영진의 목적은 이메일을 읽을 가능성이 가장 높은 시간을 예측하는 것이었죠. 경영진은 단지 전 세계에 있는 사용자들의 출퇴근 시간과 수면 시간을 파악해 각 사용자의 시간대에 맞춰 읽을 가능성이 높은 고객에게만 이메일을 보내고 싶을 뿐입니다. 하루 종일 효율적으로 이메일을 발송하고 싶은 것이지요.

안타깝게도 대부분의 ML 프로젝트가 이런 식으로 시작되곤 합니다. 프로젝트 시작에 앞서 의사소통이 거의 이루어지지 않는 경우가 많으며, 보통은 데이터 과학 팀이 어떻게든 알아서 해줄 거라 기대하곤 합니다. 하지만 무엇을 구축해야 하는지, 어떤 기능을 해야 하는지, 최종 목표가 어떤 것인지에 대한 적절한 가이드가 없다면 프로젝트가 실패할 확률이 매우 높습니다.

사용자의 IP 주소로 알아낼 수 있는 접속 위치 기반으로 쿼리하고, 사용자의 시차를 간단히 분석만 해도 되는 작업이었는데, 수개월의 개발 시간과 노력을 들여 기능이 다양한 추천 시스템을 구축했다면 어떤 일이 발생했을까요? 프로젝트는 중간에 취소되었을 확률이 가장 높고, 만약 구축을 완료했다 하더라도 이렇게 거대한 시스템을 구축한 이유와 막대한 개발 비용이 어떻게 쓰였는지 추궁하는 역공에 시달렸을 것입니다.

p.39

p.41~42

p.49

p.50

배포 전략 중심으로 프로젝트를 계획하지 않으면 손님이 몇 명이나 올지 모르는 채로 디너파티를 여는 것과 같습니다. 돈을 낭비하거나 경험을 망칠 수도 있죠.

p.51

ML 아키텍처를 구축할 때는 가능한 한 가장 단순하게 설계하기 위해 노력하세요. 프로젝트의 추론 주기가 1주일인 경우 실시간 스트리밍이 아닌 배치 프로세스를 사용하는 것이 좋습니다. 데이터 볼륨이 메가바이트 단위인 경우, 데이터베이스와 간단한 가상 머신(VM)을 사용할 수도 있습니다. 여러 노드가 달린 아파치 스파크 클러스터까지는 필요 없습니다. 훈련 수행 시간이 몇 시간이 아니라 분 단위로 측정되는 경우 GPU가 아닌 CPU만으로도 충분합니다.

복잡한 아키텍처나 플랫폼, 기술을 한번 써보기 위해서 도입하려고 한다면 이미 충분히 복잡한 솔루션에 불필요한 복잡성이 추가될 뿐입니다. 새로운 것이 추가될 때마다 무언가 고장 날 가능성이 높아진다는 것을 잊지 마세요. 그리고 쉽게 해결되지도 않습니다. 솔루션을 안정적으로 일관되게 효과적으로 운영하기 위해서는 기술, 스택 및 아키텍처를 단순하게 유지하는 것이 권장하는 모범 사례입니다. 프로젝트의 시급한 비즈니스 요구 사항을 해결하는 데 딱 필요한 만큼만 있으면 됩니다.

p.55

"지난 분기 예산을 살펴보니 이 ML 프로젝트에 분기당 63,750달러(한화로 약 8천만 원)가 들었습니다. 그럼 이 프로젝트로 도대체 얼마를 벌고 있는 걸까요?"

-> 이 질문은 비용이 어느 정도 발생하는 상황에서 받을 수 있는 질문입니다. 프로젝트 비용이 매우 낮아 회사 예산에서 거의 눈에 띄지 않는 수준이라면 이런 질문을 받을 일이 없겠지만, 비용이 많이 든다면...

수익 기여도라니... 

당황스럽습니다. 

전년 대비 매출을 비교할까요?

손실 지표면 충분한 거 아닌가요?

매출이 늘고 있는데, 그럼 된 거 아닌가요?

프로젝트 계획 단계에서 기여도와 측정 방식에 대해 합의를 도출하지 못하고 모델의 효율성에 대한 철저한 통계 분석이 지속적으로 이뤄지지 않는다면 아무리 훌륭한 솔루션이라도 무용지물이 될 수 있습니다.

p.56

모델의 기여도를 정확하게 측정하는 유일한 방법은 A/B 테스트를 수행하고 적절한 통계 모델을 사용하는 것입니다. 모델에 의한 추가 매출이 얼마나 되는지 보여주는 매출 상승률을 추정 오차를 포함해서 계산하는 것입니다. 하지만 이미 모든 고객에게 솔루션이 배포되었기 때문에 A/B 테스트라는 버스는 이미 떠난 후입니다. 팀은 모델의 지속적인 존재를 정당화할 수 있는 기회를 잃었습니다. 이 프로젝트가 당장 중단되지는 않겠지만, 회사가 예산 지출을 줄여야 한다면 분명히 도마 위에 오를 것입니다.

이런 경우를 대비해 항상 미리 생각하고 계획하는 것이 좋습니다. 

p.65

p.66

최신 기법이 정교하지 않은 이유는 매우 간단합니다. 솔루션을 유지 관리해야 하기 때문이죠. 월별이든 매일이든 실시간이든 솔루션과 코드를 디버깅하고, 개선하고, 불일치 문제를 해결하고, 지속적으로 실행해야 합니다. 주어진 솔루션이 정교할수록 장애를 진단하는 데 시간이 오래 걸리고, 문제를 해결하기가 더 어렵고, 추가 기능을 위해 내부 로직을 변경하는 것이 난해합니다.

단순한 솔루션을 추구하는 방식(즉, 문제를 해결하는 가장 단순한 설계 및 접근 방식)은 이미 해결한 문제의 솔루션을 유지 관리하는 데 필요한 시간을 단축하는 것과 직결됩니다. 그러면 더 많은 문제를 해결하고 회사에 더 많은 가치를 제공하며, 더 많은 문제를 살펴볼 수 있게 됩니다.

흥미로운 최신 알고리듬을 사용하고 싶은 열정이 프로젝트에서 형편없이 발휘된 사례를 여러 번 목격했습니다. 대표적인 예는 이미지 해상도 업스케일링을 위한 GAN 프로젝트로, 12명의 데이터 과학자로 구성된 팀이 10개월이 걸려서야 프로덕션 준비 및 확장 가능한 상태에 도달할 수 있었습니다. 제가 경영진과 대화할 때는 회사가 이탈 모델, 사기 탐지 모델, 수익 예측 모델을 구축하기 위해 컨설턴트를 고용한 상태였습니다. 경영진은 내부 팀이 R&D 프로젝트를 하느라 너무 바쁘기에 중요한 모델링 작업을 외부 컨설턴트에게 맡겨야 한다고 생각했죠. 결국 이 회사와 일한 지 12주 만에 데이터 과학 팀 전체가 해고되었고 회사는 이미지 프로젝트를 포기했습니다.

때로는 회사에 엄청난 가치를 가져다주는 기본적인 업무를 수행하는 것이 일자리를 유지하는 데 도움이 됩니다(그렇다고 예측, 이탈, 사기 탐지 모델링이 특별히 흥미로워 보이지 않더라도 간단하다는 의미는 아닙니다).

p.67