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

 

 

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

 

이 책도 그런 책 중 하나다. 챕터 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

 

p.84

 

 

p.85

대규모 ML을 수행할 때 모델의 오류 지표와 검증 점수에 의존하고 싶을 수 있습니다. 이 방식은 최근 들어 흔해진 대규모 데이터셋에 대한 예측 품질을 바탕으로 객관적으로 측정하는 유일하고도 현실적인 방법일 뿐만 아니라, 특정 구현의 예측 품질을 판단할 수 있는 유일하고 유효한 정량적 수단일 때가 많기 때문입니다. 

 

그러나 모델 점수 지표를 전적으로 의존하지 않는 것이 중요합니다. 해결해야 하는 문제에 적합한 지표를 사용하되, 예측의 효율성을 주관적으로 측정할 수 있는 수단을 추가해 보완해야 합니다. [그림 3-5]에서 볼 수 있듯이 개별 사용자에 대한 예측을 간단히 시각화하면 어떠한 예측 순서 평가 알고리듬이나 손실 추정보다 훨씬 더 객관적이고 주관적으로 품질을 측정할 수 있습니다. 이 추가적인 최종 사용 시뮬레이션 샘플에 대한 평가는 주제 저너문가 수준의 예측 품질을 판단할 수 있는 경우가 아니라면 데이터 과학 팀이 수행해서는 안 됩니다. 지금 다루고 있는 유스케이스에서는 데이터 과학팀이 마케팅 분석가 몇 명과 협력해 비공식적인 품질 보증 검증을 수행한 후, 전체 팀에 결과를 공유하는 것이 좋습니다.

 

p.94

 

 

p.97

 

p.122

어려운 대화를 어떻게 부드럽게 진행할 수 있는지 묻는 사람들에게 제가 하는 대답은 간단합니다. 그냥 들어보세요. 덜 말하세요. 사업부에서는 이야기하지 마세요. 그들이 우려하는 바를 경청하고 그들이 이해할 수 있는 용어로 명확하게 소통하세요. 무엇보다도 솔직하게 말하세요. 실행 능력을 넘어서는 마법 같은 솔루션이나 납기일을 약속하지 마세요. 그들은 경청과 정직한 토론에 고마워할 겁니다. 진정으로 타인의 고충에 귀 기울이는 공감적 태도는 제가 알고 있는 그 어떤 방법보다도 적대적인 토론을 완화하는 데 효과적입니다.

 

p.123

 

p.132

'어떻게 작동해야 할까?'라는 간단한 질문을 던지고 표준 알고리듬 구현에 초점을 두지 않는 습관은 그 어떤 기술, 플랫폼, 알고리듬보다 ML 프로젝트의 성공을 보장하는 데 더 유익합니다. 이 질문은 프로젝트에 참여한 전원이 같은 생각을 갖고 있는지 확인하는 가장 중요한 질문입니다. 이 질문은 조사하고 실험해야 할 핵심 기능을 파악하기 위한 질문과 함께하는 것이 좋습니다. 핵심 요구 사항에 대해 혼란스러운 점이 있거나 구체적인 이론이 미진한 경우, 프로젝트 스폰서의 비전에 부합하지도 않는 솔루션 구축에 몇 달의 시간과 노력을 쏟아붓기보다 단 몇 시간의 계획 수립 회의를 진행해 초기 단계에서 가능한 모든 비즈니스 세부 사항을 정교하게 다듬는 편이 훨씬 더 이롭습니다.

 

p.136

ML 프로젝트, 특히 추천 엔진처럼 비즈니스 일부와 수많은 인터페이스를 요하는 프로젝트는 복잡하다는 특성상 회의가 결정적으로 중요합니다. 하지만 모든 회의가 똑같이 중요한 것은 아닙니다. 

 

사람들이 매일 정해진 주기로 케이던스 회의를 하고 싶어하는 것은 뿌리치기 힘든 유혹이지만, 프로젝트 회의는 프로젝트 마일스톤에 맞춰 진행해야 합니다. 프로젝트 기반 마일스톤 회의는 다음 원칙을 지켜야 합니다.

 

- 일일 스탠드업 회의를 대체하지 않습니다.

- 각 부서의 팀 회의와 겹치지 않아야 합니다.

- 항상 팀 전체가 참석한 상태에서 진행합니다.

- 논쟁의 여지가 있는 주제에 대해서는 항상 프로젝트 팀장이 참석해 최종 결정을 내립니다.

- 해당 시점의 설루션을 제시하는 데 집중하고 그 외는 제시하지 않습니다.

 

p.156-157

MVP 리뷰를 받을 때쯤이면 모든 사람이 프로젝트에 대해 들뜬 상태이면서 지쳐있을 것입니다. 마지막 단계입니다. 내부 엔지니어링 검토가 완료되었고, 시스템이 올바르게 작동하고, 통합 테스트를 모두 통과했으며, 대규모 버스트 트래픽 규모에서 레이턴시(latency)를 검증했고, 개발에 관여한 모든 실무자가 휴가를 떠날 준비를 마쳤습니다.

 

이 단계에서 팀과 회사가 프로덕션 설루션을 바로 출시하는 것을 놀라울 정도로 많이 보았습니다. 그런데 그 때마다 그들은 후회했습니다. MVP를 구축하고 합의한 후에는 몇 차례 갖게 될 스프린트 회의에서 코드 강화, 즉 테스트, 모니터링, 기록, 면밀함 검토가 가능한 프로덕션용 코드 제작에 초점을 둬야 합니다. 

 

p.163

실험 코드는 약간 '버벅거림'이 있어야 합니다. 스크립트로 작성하고, 주석을 달고, 보기 흉하며, 테스트를 거의 할 수 없어야 합니다. 차트, 그래프, 인쇄 명령문과 온갖 잘못된 코딩 관행으로 가득 찬 스크립트여야 합니다.

 

결국 실험입니다. 실험적 동작을 결정하기 위해 빡빡한 일정을 따르고 있다면 클래스, 메서드, 인터페이스, 열거자, 팩토리 빌더 패턴, 전달 구성(couriering configuration) 등을 만들 시간이 없을 겁니다. 상위 수준 API, 선언적 스크립팅, 정적 데이터셋을 사용하게 되죠. 

 

실험이 끝날 때 코드 상태에 대해 걱정하지 마세요. 실험 코드는 팀이 표준 소프트웨어 개발 방식으로 유지 관리 가능한 소프트웨어를 구축할 때 적절한 코딩을 하기 위해 참고할 수 있는 정도면 됩니다. 그리고 어떤 상황에서든 최종 솔루션에서 실험 코드를 확장해서는 안 됩니다. 

 

p.163-164

데이터 과학 팀 팀장, 아키텍트 또는 팀의 선임 데이터 과학자는 프로젝트에 무엇을 포함할지 면밀히 살펴보고 어려운 질문을 던지며 정직한 답변을 해야 합니다. 가장 중요한 질문은 다음과 같습니다.

 

- 설루션을 구축하는 데 얼마나 걸릴까요?

- 코드 기반이 얼마나 복잡할까요?

- 필요한 재훈련 일정에 따라 훈련 비용이 얼마나 들까요?

- 우리 팀은 설루션을 유지 관리하는 데 필요한 기술을 보유하고 있나요? 모두가 이 알고리듬/언어/플랫폼을 알고 있나요?

- 데이터 훈련과 추론으로 무언가가 크게 바뀌면 설루션을 얼마나 빨리 수정할 수 있나요?

- 이 방법론/플랫폼/언어/API를 사용해 성공한 사례를 보고한 사람이 있나요? 우리는 바퀴를 재발명하고 있나요, 아니면 사각형 바퀴를 만들고 있나요?

- 피처 목표를 모두 충족하면서 설루션이 작동하게 하려면 팀에서 추가 작업을 얼마나 많이 수행해야 하나요?

- 확장 가능할까요? 버전 2.0 제작이 불가피하다면 이 설루션을 쉽게 개선할 수 있을까요?

- 테스트 가능한가요?

- 감사가 가능한가요?

 

p.167

XGBoost만 알면 모든 문제가 그레이디언트 부스팅처럼 보입니다.

 

연구를 수행하지 않고, 대체 접근 방식을 배우거나 테스트하지도 않고, 실험이나 개발을 몇 가지 도구로 제한하는 등 이런 식으로 자신을 제한할 때 설루션은 한계와 스스로 부과한 경계에 갇힐 것입니다. 한 가지 도구나 새로운 유행을 모든 문제에 일률적으로 적용하는 것은 최적의 해결책이 아닙니다. 더 비참한 것은 네모를 둥근 구멍에 끼워 맞추기 위해 필요도 없는 복잡한 코드를 훨씬 많이 작성하게 된다는 것입니다.

 

팀이나 자신이 PDD의 길을 걷고 있는지 여부를 알려면 프로젝트의 프로토타입 단계에서 기획한 사항을 확인하세요. 테스트 중인 모델이 몇 개인가요? 프레임워크는 몇 개를 검증하고 있나요? 두 질문 중 '하나'가 있고 팀원 중 해당 문제를 여러 번 해결해본 사람이 없다면 PDD를 하고 있는 것입니다. 중단해야 합니다.

 

p.175

회의에서 주제 전문가가 "모델이 이 그룹 사람들에게 매우 관련성이 높다고 예측한 항목이 왜 그들 장바구니에 들어 있지 않나요?"라고 반문한다면 답할 방법이 전혀 없습니다. 이 때는 질문자의 짜증 섞인 질문을 무시하는 대신, 모델이 '볼 수 있는' 현실적 관점에서 설명하면서 몇 가지 질문을 던지기만 하면 됩니다. 사용자가 다른 사람을 위해 쇼핑 중이었을 수 있습니다. 어쩌면 그들은 어떤 사건에서 영감을 받아 데이터에 나타나지 않은 새로운 것을 찾고 있었을 겁니다. 그냥 기분이 안 좋았던 걸지도 몰라요.

 

'현실 세계'에서 사건 행동에 영향을 미치는 잠재 요소는 놀라울 정도로 무한합니다. 우주를 관측해 알 수 있는 모든 정보와 지표를 수집한다 해도 무슨 일이 일어날지, 그렇다면 어디서 왜 일어나는지, 또는 아무 일도 일어나지 않을지를 확실하게 예측할 수는 없을 겁니다. 모델이 그런 방식으로 작동한 이유와 예상한 대로 결과(사용자가 상품을 구매하기 위해 돈을 지불하는 것)가 나오지 않은 이유를 주제 전문가가 알고 싶어하는 것은 십분 이해합니다. 사람인 우리는 질서를 설명하기 위해 분투하는 존재니까요.

 

안심하세요. 모델이 완벽하지 않듯 우리도 그렇습니다. 세상은 꽤 혼란스러운 곳입니다. 틀리게 추측한 것보다 앞으로 일어날 일을 정확히 추측하는 것이 더 많기를 바랄 뿐입니다.

 

p.179-180

 

 

p.180

 

 

p.185

 

 

p.185-186

 

 

p.188

 

 

p.189