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

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

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

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

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

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

ex. AMD64, AARCH64, ARM64, ... 

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

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

- 의존성 고정

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

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

- 패키징 및 배포의 유용성

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

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

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

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

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

각 Task 를 정의하게 되고, 

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

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

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

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

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

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

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

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

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

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

- ...

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

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

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

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

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

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

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

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

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

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

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

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

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