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

ML 제품 개발이 단순한 기술 문제가 아니라 팀 전체의 협업과 프로세스 문제라는 관점이 정말 새로웠습니다. 특히 현상유지 편향 같은 인간의 심리적 특성까지 고려한 접근이 현실적이고 실용적이라고 느꼈어요. 기술적인 내용뿐만 아니라 팀 운영과 제품 전달까지 포괄적으로 다뤄서, ML 프로젝트를 진행하면서 놓치고 있던 부분들을 많이 발견할 수 있었습니다. 당장 우리 팀에서도 적용해볼 만한 구체적인 방법들이 가득해서 정말 도움이 될 것 같습니다.

이 책의 전반적인 내용은 실제 제품과 관련도 되어있고,

이러한 제품을 유지보수 하는 측면에서 다루는 내용도 꽤 많다.

​

현실적으로 봤을때, 이 부분에 공감하는 기업은 손에 꼽을 것이다.

하지만 근 3년동안 꿈꿔왔던 이상적인 프로세스이고

내가 꿈꿔온 이상적인 ML 생테계를 공감해주는 것 같은 그런 책이다.

​

현실과 너무 비교되는 미래를 그리고 있는 것이라 그런건진 몰라도

더 간절해지고, 괴리감만 더 크게 느껴진다.

전체 리뷰 : https://blog.naver.com/ab415/223949174952

? 책 선택 이유

 팀 프로젝트를 진행할 때 대부분 팀장 역할을 맡다 보니 팀을 효과적이고 효율적으로 이끄는 방법에 대해 자주 고민해왔다. 여러 프로젝트를 경험하며 사람을 관리하는 방식이나 일정 조율 등에 대해서는 나름 체계적인 방식을 갖추게 되었지만 기술적인 측면에서의 팀 운영에는 아직 경험이 부족하다는 점을 느꼈다. 특히 앞으로 회사 생활을 하게 된다면 이 부분이 팀의 성과에 큰 영향을 미칠 것이라고 생각하게 되었다. 그러던 중 '잘되는 머신러닝 팀엔 이유가 있다'라는 책을 접하게 되었고 제목부터 흥미를 끌어 읽어보게 되었다.

?? 책의 특징 및 차별점

[모델 개발부터 실제 서비스화까지의 체계적인 방법론]

 이 책은 단순히 머신러닝 모델을 설계하고 학습하는 기술에 머무르지 않는다. 모델이 어떻게 실제 제품에 녹아들고 사용자에게 도달하며 안정적으로 운영되는지를 전체적인 흐름 속에서 설명하는 점이 인상 깊다. 특히 초반에는 ML 프로젝트의 전달 방식이나 제품화 전략을 다루고, 후반부에서는 CD4ML이나 MLOps와 같이 운영 환경에 적합한 형태로 ML 시스템을 발전시키는 과정에 집중한다. 모델 개발 이후의 과정에서 막막함을 느꼈던 사람이라면 이 책을 통해 머신러닝을 실질적으로 활용하는 데 필요한 큰 그림을 얻을 수 있다.

[효과적인 ML 프로젝트를 위한 엔지니어링 관점의 다양한 기술 소개]

 머신러닝을 단순한 모델링 문제가 아니라, 복잡한 소프트웨어 개발 과정의 일부로 다룬다. 개발자라면 익숙한 의존성 관리, 테스트 자동화, 코드 품질 관리 등의 개념을 ML 프로젝트에 맞게 재해석하여 설명하고 있으며 각 기술의 적용 방법과 필요성도 구체적으로 서술한다. 예를 들어, 모델 테스트는 단순히 성능 수치만을 보는 것이 아니라 모델의 신뢰성과 유지보수 가능성을 확보하기 위한 테스트 전략이 필요함을 강조한다. 이러한 접근은 머신러닝을 단발성 실험이 아닌 지속 가능한 시스템으로 바라보게 만든다.

? 추천 독자

1. 머신러닝 모델은 만들 줄 알지만 제품화와 서비스 운영 과정에서 어려움을 느꼈던 실무자

2. 기술뿐 아니라 일정, 협업, 코드 품질 등 ML 프로젝트 전반을 아우르는 조직적 운영 방식을 배우고 싶은 사람

3. 모델 성능 외에도 지속 가능한 ML 시스템 구축, 테스트, 리팩터링, MLOps 등 엔지니어링 기반의 실전 노하우가 궁금한 사람

'잘되는 머신러닝 팀엔 이유가 있다'는 단순히 ML 모델을 개발하는 기술서를 넘어, 머신러닝 프로젝트의 성패를 좌우하는 팀 구조, 협업 방식, 엔지니어링 관행, 문화적 요소까지 통합적으로 다루는 실무 중심의 안내서이다. 현실에서 많은 ML 프로젝트가 PoC 단계에 머무르고, 성능 저하나 기술 부채, 팀 간 갈등으로 좌초되는 사례가 많은데, 이 책은 그런 문제를 해결하기 위한 실제 전략과 조직 설계 방식을 구체적으로 제시한다. 또한 웹페이지 구조나 자동 테스트, 리팩터링, CI/CD, 컨테이너 환경 구성, 협업 프로세스 등을 통해 팀 전체가 효과적으로 움직일 수 있는 기반을 구축하도록 안내한다. '잘되는 머신러닝 팀엔 이유가 있다'는 단순히 ML 모델을 잘 만드는 방법을 알려주는 책이 아니라, 팀이 효과적으로 구성되어 ML 기술을 제품으로 연결하는 전체 프로세스를 안내하는 실무 중심의 가이드다. 기술 리더, 데이터 사이언티스트, ML 엔지니어, 프로젝트 매니저, 스타트업 CTO 등 다양한 역할의 실무자에게 조직적 사고와 엔지니어링 기반의 협업 구조를 설계하는 데 큰 도움이 될 것으로 확신한다. 머신러닝과 조직, 제품 개발을 함께 고민하는 모든 실무자에게 강력히 추천한다.

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

잘 되는 머신러닝 팀엔 이유가 있다.

딥러닝 오픈소스를 설치해서 사용하면 안되는 경우가 많다.

특정 cuda 에 특정 패키지 버전에, ...

그래서 그런지 의존성을 관리하는 것에 대해서도 작성되어 있다.

의존성 관리는 단순히 머신런닝 프로젝트 이외에도 다양하게 사용할 수 있으므로 유심히 읽어보았다.

의존성 관리 실패

가끔 운용환경과 개발환경 사이에, CPU 칩과 명령어 집합을 사용해야할 때가 있다.

ex. AMD64, AARCH64, ARM64, ... 

나는 Dockerfile 내부에 각 컴파일러 등을 설치했지만, 책에서는 buildx 도구를 활용하면 기다양한 아키텍처 이미지를 생성할 수 있게 해준다.

수준별 의존성 분리

어플리케이션 수준의 의존성 관리에서, 책에서는 poety 를 소개한다.

- 의존성 고정

- 자동으로 pyproject.toml 을 업데이트

- 운용과 개발 의존성을 명확하게 정의.

- 패키징 및 배포의 유용성

그러나, 요즘은 uv 를 선호하는 사람이 더 많아지는 듯 하다.

빠르고, 간단하고 표준이되고 있다.

개인적으로 uv 를 썻을 때, 설정 관련되서 업데이트 해야하는 부분들이 보이긴 했다.

그러나 현재 많은 오픈소스(빅테크 포함)에서 많이 사용되고 있으므로 성숙도가 빠르게 높아질 것으로 보인다.

의존성 관리는 각 업무를 분류하게 하고, 분류된 모델은 일종의 테스트 단위가 되어 자동화 될 수 있다.

이런 흐름은 의존성을 고려하다보면,

각 Task 를 정의하게 되고, 

분류된 각 Task 는 하나의 작업단위로써, 테스트 가능하게 된다.

개별 테스트 가능성은 전체 파이프라인을 자동화시키고,

전체적인 효율을 엄청나게 향상시킨다.

전체적으로 책이 말하고자 하는 것은,

동작하는 코드의 품질을 유지하도록 하는 방법을 말하고자 하는 것 같다.

- 누구나 빠르게 설정하고 동작시켜봄으로써, 빠르게 기여하게 할 수 있도록 하기.

- 알아보기 쉬운 테스트를 구축함으로써, 사이드이펙트를 사전에 차단하기

- 자동화(ex. 테스트) 전환을 통한 품질 향상하기.

- 개발에 IDE 의 활용하여, 인지부하와 실수 줄이기

- 효율적으로 커뮤니케이션하여 하나의 팀 되기.

- ...

"개발 단계를 넘어, 어떻게 코드를 유지보수할 수 있을까?" 에 대한 부분은 많은 사람들이 놓치고 있는 부분이라고 생각한다.

무엇을 만드는 것에만 너무 초첨을 맞추기보다는, 그 다음 단계인 유지보수를 생각해보는 시간이 많아지길 바란다.

나는 소프트웨어의 철학이 유지보수를 고려할 때, 더 깊은 생각을 하게 만든다고 생각한다.

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

ML이란 단어가 더 이상 특별하지 않은 시대다. 대부분의 조직이 머신러닝을 도입하고 있고, 모델을 훈련시키는 건 이제 기술적으로 큰 장벽이 아니다. 그런데 왜 많은 ML 프로젝트는 끝내 배포되지 못한 채 사라질까? 이 책은 그 질문에서 출발한다. 단순히 모델을 만드는 법이 아니라, '머신러닝 팀이 어떻게 일해야 하는가?'를 묻고 답한다. 즉, ‘기술’이 아닌 ‘팀’, ‘문화’, ‘프로세스’라는 현실적인 키워드를 중심에 둔다.

Part 1에서는 ML이 제품으로 구현되기까지의 전 과정에서 어떤 준비와 구조가 필요한지를 다룬다. 제품 기획 단계부터 전달까지, ML 기술이 단순한 성능 자랑이 아닌 고객 가치로 전환되기 위한 전략과 실행 방식이 설득력 있게 제시된다. Part 2는 보다 실무적인 내용으로 채워져 있다. 의존성 관리, 자동 테스트, 컨테이너 환경 구성, 리팩터링, 기술 부채, CI/CD 등 ML 개발 과정에서 마주칠 수밖에 없는 문제와 그에 대한 구체적인 해법을 담았다. 특히 모델 테스트를 별도 챕터로 구성해 설명한 점은 ML 특유의 문제 의식을 깊이 이해하고 있다는 방증이다. 그리고 Part 3에서는 기술만으로는 성과를 만들 수 없다는 전제를 바탕으로, 효율적인 팀 구성과 리더십, 조직 설계, 협업 구조까지 촘촘하게 짚는다. 조직의 성숙도가 프로젝트의 성공 가능성과 직결된다는 점이 여러 사례와 함께 풀려 있다. 한편, IDE 활용법이나 노트북 코드 리팩터링처럼 실무의 생산성을 끌어올리는 작고도 실질적인 요소들까지 놓치지 않고 다뤘다는 점이 인상 깊다. 표면적인 기술 트렌드보다 일하는 방식을 개선하는 데 집중한 점이 이 책의 진짜 매력이다.

이 책은 단순한 개발서도, 팀 운영 매뉴얼도 아니다. ML을 실전에서 다루는 팀에게 꼭 필요한 구조적 사고, 실용적인 엔지니어링 프레임워크, 그리고 일의 지속 가능성을 만드는 문화적 감각이 유기적으로 엮여 있다. 기술만 잘 다룬다고 해서 좋은 팀이 되진 않는다. 일의 방식부터 다시 묻고 싶은 팀이라면, 이 책은 꽤 현실적인 방향을 제시해 줄 것이다.



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

이 책을 보자마자 떠오르는 생각이 하나 있었다.

“왜 하필 머신러닝 팀을 기준으로 제품 개발과 관리 노하우, 팀 운영 전략을 담아냈을까?”

최근에 활용하고 있는 구글의 제미나이를 통해 머신러닝 팀이 직면하는 특별한 상황들은 다음과 같다.

1. 데이터 의존성: 일반적인 소프트웨어는 '코드'가 중심이지만, 머신러닝은 '데이터'가 핵심입니다. 데이터의 수집, 전처리, 정제, 버전 관리, 파이프라인 구축 등 데이터에 대한 의존성과 복잡성이 상상을 초월합니다. 데이터가 바뀌면 모델도 바뀌어야 하고, 이는 운영 환경에 지속적인 영향을 미칩니다.
2. 실험적이고 반복적인 개발: 소프트웨어 개발은 기획-설계-구현-테스트라는 비교적 선형적인 흐름을 따르지만, 머신러닝은 가설 설정-실험-평가-개선이라는 훨씬 더 반복적이고 실험적인 과정을 거칩니다. 최적의 모델을 찾기 위해 수많은 시도를 해야 하며, 이 과정 자체를 효율적으로 관리하는 것이 큰 과제입니다.
3. 모델의 동적인 특성: 소프트웨어 코드는 배포 후에도 동일하게 작동하는 경향이 있지만, ML 모델은 배포 후에도 데이터 분포 변화(데이터 드리프트) 등으로 성능이 저하될 수 있습니다. 따라서 지속적인 모니터링, 재훈련, 재배포가 필수적이며, 이는 MLOps라는 새로운 영역을 탄생시켰습니다.
4. 다양한 직군의 협업: ML 프로젝트는 데이터 과학자, ML 엔지니어, 소프트웨어 엔지니어, 도메인 전문가 등 다양한 배경을 가진 사람들이 긴밀하게 협력해야 합니다. 각자의 언어와 관점이 다르기 때문에 효과적인 커뮤니케이션과 협업 구조를 만드는 것이 매우 중요합니다.

현업에는 다양한 팀이 존재하는데 머신러닝 팀의 경우 기존 소프트웨어 개발 팀에 비해 방대하고 복잡도가 높으며 커뮤니케이션이 더욱 다양하게 필요함을 느꼈다. 그런 관점에서 볼때 이 책에서 말하는 내용은 상당히 효율적이고 좋은 팀으로의 방향을 제시해주고 있다.

책을 볼때 목차를 엄청 살핀다. 목차가 결국 말하고자 하는 바를 확실하게 이야기해주기 때문이다. 이 책에서는 제품과 전달, 엔지니어링, 팀이라는 큰 파트 3가지를 기준으로 이야기를 풀어 나간다. 현업에서 마주하는 중요한 허들을 나열해주고 있었다.

잘 되는 팀은 "효율성이 높아야 한다."  자동화는 필수!

신속, 정확, 그리고 자동화가 가능해야 효율성이 높아진다. 기존 레거시 프로그램 코드들을 보면 각 코드의 결합도가 높아서 나눠서 개발할 수 없고 테스트 또한 분리해서 할 수 없기 때문에 자동화가 불가능하다. 그런 코드들을 모듈단위로 분리하고 각 모듈간 입력과 출력을 확인하고 작은 단위로 테스트하고 통합해서 flow별 테스트를 자동으로 진행할 수 없다면 효율성은 석기시대 수준일수밖에 없다. 이런 점에서 이 책은 다양한 효율적인 방법을 이야기해주고 있다.

그리고 머신러닝 프로젝트를 성공적으로 수행하기 위한 범위가 개념을 확실하게 이야기해주고 있다. 제품부터 데이터 등 여러 분야의 협력이 필요하다는 말은 결국 상호작용해야할 대상이 포괄적이기 때문에 그것들을 모두 고려한 구성이 되어야한다는 말과 동일하다.

책에서 말하는 린 원칙은 가치 식별, 가치 흐름 매핑, 흐름 생성, 당기기 시스템 확립, 지속적인 개선을 이야기한다. 

“낭비를 제거하고 효율성을 극대화하여 지속적인 가치를 창출” - 린 원칙 요약

글을 읽으면서 전체적으로 정리하면 아래와 같다.

1. 낭비 제거 (Eliminate Waste): ML 프로젝트에서 불필요한 작업, 과도한 문서화, 불필요한 기능 개발, 대기 시간, 결함(버그) 등 가치를 더하지 않는 모든 요소를 식별하고 제거한다. 예를 들어, 수동으로 반복되는 작업을 자동화하거나, 불필요한 모델 재훈련을 줄이는 것이 해당된다.
2. 학습 증대 (Amplify Learning): 끊임없이 실험하고, 그 결과로부터 배우며, 지식을 공유하여 팀 전체의 학습 곡선을 높인다.. ML은 본질적으로 실험을 통해 발전하므로, 빠르고 효과적인 학습 루프를 구축하는 것이 중요하다.
3. 가능한 한 늦게 결정하기 (Decide as Late as Possible): 모든 정보를 알 때까지 중요한 결정을 미룬다. ML 개발은 불확실성이 크므로, 초기에 너무 많은 것을 확정하기보다 데이터를 기반으로 유연하게 방향을 조정할 수 있도록 선택의 폭을 넓게 가져가는 것을 의미한다.
4. 가능한 한 빠르게 전달하기 (Deliver as Fast as Possible): 고객에게 가치를 제공하는 기능을 최대한 빠르고 자주 배포한다. 이는 빠른 피드백을 얻고, 시장의 요구에 민첩하게 대응하며, 위험을 조기에 발견하고 최소화하는 데 필수적이다.
5. 팀에 권한 부여 (Empower the Team): 개발팀원들이 스스로 문제를 해결하고 의사결정을 내릴 수 있도록 신뢰하고 권한을 위임한다. 이는 팀의 주인의식과 생산성을 높여 창의적이고 효과적인 문제 해결을 가능하게 도와준다.
6. 품질 내재화 (Build Integrity In): 처음부터 품질을 염두에 두고 개발하여 결함을 예방한다. ML에서는 데이터 품질, 모델 검증, 지속적인 테스트 및 모니터링을 통해 높은 수준의 서비스 신뢰성을 확보하는 것을 의미한다.
7. 전체 시스템 보기 (See the Whole): 개별 구성 요소나 팀의 부분적인 최적화가 아닌, 전체 ML 시스템과 조직의 큰 그림을 이해하고 최적화한다. 데이터 파이프라인부터 모델 배포, 운영, 팀 협업까지 모든 단계를 유기적으로 연결하여 바라보는 시각이 중요하다.

린 원칙과 CD4ML, 의존성, 자동 테스트, 모델 테스트, 팀 관리에 이르기까지 다양한 파트에서의 노하우를 이 책은 말해주고 있다. 

• CD4ML: ML 시스템의 개발, 배포, 운영 전 과정을 데이터, 코드, 모델까지 아울러 자동화하여 지속적으로 가치를 전달하는 것 (Continuous Delivery for Machine Learning)

이 책에서는 ML 프로젝트 실패의 근본 원인을 파악하고 해결책을 제시하는 동시에, 팀과 조직 문화의 중요성을 결코 간과하지 않는다.

기술적 난관뿐 아니라 팀원 간의 효과적인 커뮤니케이션, 심리적 안정성 확보, 그리고 실패를 통해 학습하는 문화의 필요성을 역설하며, 이는 지속 가능한 팀 성장을 위한 필수 요소임을 강조하고 있다.

기술 리더로서 팀을 이끄는 과정에서 마주하는 인적, 조직적 과제들에 대한 깊이 있는 이해와 해법을 얻을 수 있다.

"잘되는 머신러닝 팀엔 이유가 있다"는 머신러닝 개발자뿐만 아니라, ML 프로젝트를 기획하고 이끄는 기술 리더, 그리고 효율적인 개발 문화를 고민하는 모든 IT 관리자에게 추천할 만한 가치가 있는 책이다.

기술의 복잡성 속에서도 사람과 시스템의 본질적인 조화를 통해 어떻게 지속 가능한 성공을 이룰 수 있는지, 그 깊이 있는 통찰과 실용적인 지혜를 함께 얻을 수 있을 것이다.



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

잘되는 머신러닝 팀엔 이유가 있다

한빛미디어에서 번역서로 발간된 "잘되는 머신러닝 팀엔 이유가 있다"는 관점이 아주 재밌습니다. 이 책은 소프트웨어 엔지니어를 위한 입문 내용과 ML 엔지니어로 커리어를 시작하는 사람들을 위한 내용이 섞여있다고 볼 수 있습니다. 시중에는 소프트웨어 엔지니어링으로 입문하는 사람들을 위한 책이 워낙 많고, ML 엔지니어를 위한 책은 중급 이상이거나 이미 소프트웨어 엔지니어링 기법을 알고 있다는 전제로 쓰인 책이 많았습니다. 즉, 이 책은 ML 엔지니어로 커리어를 시작하려는 사람들에게 최고의 책이 될 겁니다.

제품 개발은 쉽지 않습니다. 사실 대부분의 제품 개발은 실패하며 가장 흔한 원인은 잘못된 제품을 만드는 것입니다.

책은 의존성 도구가 필요한 이유를 설명하면서 자연스럽게 도커를 소개합니다. 형상관리와 더불어 CI/CD로 자연스럽게 넘어가고 테스트 방법론까지 언급을 하는데요, 책의 중반까지는 ML만 한정해서 다루지만 요즘 핫한 LLM을 위해 지면을 할애하기도 합습니다. LLM을 다루는 데 있어서 테스트를 어떤 식으로 해서 품질을 유지해야 하는지 궁금하시다면 이 책이 도움이 될 겁니다. 

그리고 나아가 코드 품질을 유지하기 위해 유지보수와 리팩터링, 기술부채에 대한 이야기로 어떤 식으로 제품 코드를 만들고 다듬어야 하는지 상세하기 기술합니다. 책에는 리팩터링의 대부 마틴 파울러의 말이 인용되기도 합니다.

리팩터링 없이는 소프트웨어의 내부 설계, 즉 아키텍처가 쇠퇴하는 경향이 있습니다. 사람들이 아키텍처를 완전히 이해하지 못한 채 단기 목표를 위해 코드를 변경함에 따라, 코드는 그 구조를 잃어갑니다.··• 코드의 구조 손실은 누적 효과를 가집니다. 코드에서 설계를 파악하기 어려울수록 구조를 보존하기 어렵고, 따라서 더욱 빠르게 쇠퇴합니다. 주기적인 리팩터링은 코드를 건강한 상태로 유지하는 데 도움이 됩니다.

위에 내용이 공감이 된다면 이 책에서 다루는 "CHAPTER 08 리팩터링과 기술 부채 관리"가 아주 재밌게 읽힐 겁니다. 리팩터링의 정의는 사람마다 다를 수 있지만 저는 마틴 파울러가 이야기하는 방식에 공감합니다. 

리팩터링의 핵심은 기존 동작을 유지하면서 작은 단계별로 개선하는 것입니다. 이러한 작은 개선들을 차근차근 연결하여 결과적으로 큰 변화를 이끌어내는 것이죠. 각각의 리팩터링 작업은 그 자체로 아주 작은 수정이거나 작은 수정들의 조합입니다. 그렇기 때문에 제가 리팩터링을 할 때는 코드가 제대로 작동하지 않는 상태로 오래 있지 않으며, 작업을 완료하지 않았더라도 언제든 중단할 수 있습니다. […] 만약 누군가 리팩터링 중에 코드가 며칠 동안이나 작동하지 않았다고 한다면, 그건 진정한 의미의 리팩터링이 아니었다고 봐도 무방합니다.

이것은 마치 클라우드네이티브 환경으로 마이그레이션 하면서 빅뱅 방식으로 옮기는 전략보다 점진적인 이전(Lift and Shift)을 채택하는 것과 같거든요. 아무튼, 책은 파트 3까지 있는데, 파트 3에 가면 드디어 팀에 대한 이야기가 나옵니다. 사실 파트 2까지는 ML 엔지니어로 커리어를 시작하는 사람이라면 무조건 도움이 될 내용들로 가득하고, 파트 3은 조직의 문화와 구성, 리더십에 대해 다뤄집니다. 파트 2까지 재밌게 보셨다면 파트 3도 재밌을 겁니다. 기술적인 내용이 없어서 파트 3은 좀 더 쉽게 읽힙니다. 

만약 신입으로 ML 엔지니어 커리어를 준비하고 계시거나 ML 엔지니어로 일을 시작했지만 조직의 규모가 작아서 문화를 한 단계 발전 시키고 싶다면 이 책을 일독하시길 바랍니다. 분명 도움이 되실 겁니다. :) 

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

'이 책에 대하여'에서 언급한 대로, 이 책은 생산성(가능한 한 많은 기능, 스토리, 코드를 배포하는 방법)에 관한 것이 아니며, 효율성(가능한 한 빠른 속도로 기능, 스토리, 코드를 배포하는 방법)에 관한 것도 아닙니다. 오히려 이 책은 효과성에 관한 것입니다. 즉, 올바른 제품을 신속하고 신뢰성 있게 그리고 책임감 있게 만드는 방법에 관한 것입니다. 이 책은 균형을 찾고 효과적인 방식으로 움직이는 방법에 관한 것입니다.

한국어로 번역된 책의 이름이 “잘되는 머신러닝 팀엔 이유가 있다”이지만 원서의 “Effective Machine Learning Teams”가 좀 더 적절하다는 인상을 받았습니다.

왜냐하면, 규모 있는 ML팀을 이끄는 리더보다 소수로 운영되는 회사에서 번아웃이 온 실무진에게 한국어 제목이 눈에 너무 들어오지 않을까.. 란 생각을 해보았거든요. ㅎ;

기술의 부채가 쌓이는 게 눈에 보이지만 당장 처리할 일에 어쩔 수 없이 리팩토링하기 어려운 모델을 남발하면서 

이 길을 계속 가는 게 맞나.. 라는 고민을 하는 사람에게 당장의 해결책을 주는 책은 아닙니다. 

하지만, 내가 시간을 들이고 좀 더 고생해서 나아질 수 있는 방법이 있다면 이런 것들을 찾아보고 먼저 해보라는 조언을 해주는 책이라고 할 수 있습니다. 

위와 같은 고민을 하고 있는 분들이라면 chapter01~09에서 자신의 상황과 시간이 허락하는 범위에서 읽고 해보시는 것을 추천합니다.

의존성, 종속성, 그리고 테스트는 처음 시작이 어려울 수 있지만 flow가 갖춰진다면 왜 이런 기본적인 게 중요한가를 알 수 있을 것입니다.

이 외의 조직을 이끌고 조직 문화에 대해 고민인 리더 분이라면 part03의 해당하는 팀 부분을 중점적으로 보시면 좋을 것 같습니다. 여러가지 관점과 이론/프레임워크를 제시하고 있어서 예상보다 더 유익했습니다.

개인적으로 인상 깊었던 점은 린의 원칙(lean principles)을 토대로 ML 팀에 적용할 원칙을 제안했다는 점.

챕터 마지막마다 “결론”으로 내용을 마무리함으로써 이해를 돕고 있다는 점입니다.

이 책을 읽으면서 현실과 동떨어진 모델링에 대해 다시 한번 점검하는 기회가 되었습니다. 

그리고 혼자만의 힘/소수가 해결할 수 있는 게 아니라 조직적으로 다같이 해야 한다는 점도요. 

한편으로는, 우리 회사만, 대한민국만 그런 게 아니라 해외도 이런 고민을 똑같이 하긴 하는구나.. 삽질은 다 똑같구나 란 쓸데 없는 위로도 조금 받았습니다.