🍰ML 팀 규모에 따른 개발 환경 구성 하기
#인기 블로그 포스팅 정리
팀 규모와 업무 방향성
ML 프로젝트를 수행할 때 적절한 팀 구조가 필요합니다
프로젝트 초기에는 개인이 단독으로 수행할 수 있지만, 전문화된 팀과 수백 명의 사람들이 필요할 수 있습니다
모델 파이프라인 개발 단계마다 다른 문제가 발생하므로, 적절한 팀 구조를 만드는 것이 필요합니다
리더 (엔지니어링 매니저, 테크 리드, 제품 매니저 등)는 적절한 팀 구조를 고민하고, 경험을 바탕으로 교훈을 얻어야 합니다
MVP 단계 모델 만들기
일부 관리자들은 "머신 러닝"이 흥미로우며 조사가 필요하다고 결정합니다 😂
ML 프로젝트를 시작하기 위해 시간과 인력을 투자합니다
목표는 MVP를 구축하고 실행시킨 후 이 도메인에 더 많은 자원을 투자할지 여부를 평가하는 것입니다
프로젝트 초기에는 한 두 명의 사람이 모든 것을 실행하도록 지정되며, 몇 일에서 몇 주의 시간이 주어집니다
일부 사람들은 박사 학위나 산업 경력 몇 년의 경험을 갖춘 노령화된 ML 엔지니어이지만, 대부분은 석사 프로그램 졸업생이거나 일반적인 소프트웨어 엔지니어이며, ML에 대한 아마추어 수준의 지식을 갖고 있습니다
간단한 모델을 먼저 만들기
이 단계에서 일부 엔지니어들은 자신만의 모델을 처음부터 만들고자 할 수 있지만, 이것은 권장되지 않습니다
가능한 한 간단한 것을 시도하고 결과를 확인한 후 조정하는 것이 좋습니다
이미 구축된 것을 활용하는 것이 거의 항상 더 나은 방법입니다
기본 디버깅 검사를 수행하고 데이터, 레이블 및 모델 추론을 시각화하는 것이 도움이 됩니다
모델 손실을 시각화하고 정확성 메트릭을 검사하는 것도 유용합니다
파이프라인을 만들기
MVP가 어느정도 가능성을 보여주게 되면 ML 프로젝트에 더 많은 자원을 투자하여 제품으로 출시하기로 결정됩니다. 이제는 빠진 인프라를 구축하고, 시스템과 통합하며, 제품 및 비즈니스에 구체적인 영향을 보여주는 것이 중요할 것 입니다. 이를 위해서는 많은 작업들이 필요할 것 입니다.
1. 레이블링 도구 (Labeling tools)
데이터 레이블링을 위한 도구로, 시각화, 레이블링, QA 등을 위해 데이터를 운영 팀에 배치할 수 있습니다.
2. 데이터셋 관리 시스템 (Dataset management systems)
데이터 및 레이블 저장, 시각화, 버전 관리 등을 위한 시스템입니다.
3. 데이터 파이프라인 (Data pipelines)
대용량 데이터셋에서 데이터 전처리, 피처 추출 등을 수행하기 위한 파이프라인 입니다.
4. 훈련 인프라 (Training infrastructure)
대용량 데이터셋에서 빠르게 모델을 훈련시키기 위한 인프라 입니다.
5. 테스트 및 검증 인프라 (Testing and validation infrastructure)
모델 성능 측정을 위한 테스트 및 검증 인프라 입니다.
6. 배포 최적화 (Deployment optimization)
테스트, 운영 환경에서 빠르게 모델 추론을 실행하기 위해 최적화된 시스템입니다.
7. 모니터링 (Monitoring)
모델이 학습, 테스트, 운영 환경에서 올바르게 작동하는지 확인하기 위한 모니터링입니다.
이 단계에서 인원은 여전히 Amazon의 "투 피자 규칙"을 충족시키기에 충분히 작습니다. 일반적으로 전체 팀은 한 명의 매니저/리드에 의해 비교적 쉽게 관리될 수 있습니다. 그러나 여전히 올바른 팀 구성을 위한 몇 가지 모범 사례가 있습니다.
팀 규모를 더 확장하기
인력 부족 문제
해야할 일이 현재 인원으로 감당하기 힘든 수준까지 오면 팀 내 인원이 충원되어야 합니다.
엔지니어링 대역폭의 제약
파이프라인 구축에서 가장 제한적인 자원은 늘 엔지니어링 대역폭입니다. 이 때, 비기술 직군의 팀원을 추가하는 것은 더 나은 모델을 더 빠르게 출시하는 데 많은 가치를 추가할 수 있습니다.
비기술 직군의 가치 추가
추가적인 일반 엔지니어들이 파이프라인의 다른 부분을 병렬로 구축합니다. 이 팀 규모에서는 엔지니어들이 스택의 다른 부분에 노출되어 있으며, 배포 환경에서 버그를 수정하거나 모델을 조정하는 등 팀의 요구에 따라 다른 일을 합니다.
레이블링 작업의 복잡성 증가할 경우
레이블링이 필요한 도메인에서는 ML 엔지니어가 레이블러를 감독하고 데이터셋을 구축해야 합니다. 그러나 레이블링 작업의 크기와 복잡성이 커지면 이것은 곧 비기술 직원에게 할당될 수 있는 전문 업무가 됩니다. ML 운영 매니저는 ML 데이터셋을 관리하고 개선하기 위한 일상적인 업무를 담당합니다. 그들의 일부는 레이블러 품질을 위한 QA 프로세스 구축, 레이블 훈련을 위한 엣지 케이스 문서화, 레이블링 계약업체/제공업체 관리 등입니다. 이렇게 하면 ML 엔지니어가 ML 파이프라인의 다른 부분을 구축하는 데 집중할 수 있습니다.
모델 출시 후의 역할
모델이 프로덕션 환경에 배포되면, ML 팀은 어떤 문제를 해결해야 하는지 파악하고 이해관계자들과 소통해야 합니다. ML 제품 관리자는 팀이 항상 올바른 문제를 해결하도록 보장하는 데 많은 가치를 제공합니다. 그들은 모델의 실패 사례를 분석하고 고객의 피드백을 수집하며, 비즈니스에 영향을 미칠 다음 가장 좋은 일을 우선순위에 따라 결정합니다.
제품 관리자의 의사소통 역할
ML 제품을 위한 작업들은 꽤 혼란스러울 수 있기에, 제품 관리자는 다른 이해관계자들과 의사 소통하는 데 중요한 역할을 수행해야 합니다. 제품 관리자는 판매, 마케팅, 고객 성공 팀과 함께 일하며, 왜 모델이 그렇게 행동하는지, ML 팀이 모델 혹은 서비스를 개선시키기 위해 노력하고 있는 것이 무엇인지 설명하고, 다른 팀에서 요구하는 것을 엔지니어링 작업 항목으로 전환하는 일을 해야합니다.
새로운 모델 배포 자동화 프로세스의 중요성
모델 부패(Model rot)
ML 팀은 보통 "우선 잘 작동하는 것을 만들고, 더 큰 문제를 해결하자"라는 마인드셋에 빠지는 경향이 있습니다. 이는 팀이 모델을 훈련시키고 배포한 다음 그것을 방치하는 것을 의미합니다. 6개월 후, 모델을 재훈련해야 할 상황이 발생하면, 팀은 훈련 파이프라인 코드가 망가졌다는 것을 발견하고, 다시 살려내기 위해 추가적인 엔지니어링 노력이 필요합니다. 이를 "모델 부패"라고 합니다.
재배포 프로세스
이상적으로 ML 팀은 개선된 모델을 매주 (또는 정말 뛰어난 경우 매일) 재배포할 수 있습니다! 이러한 주기를 달성하는 "적절한" 방법은 모델이 새로운 데이터로 지속적으로 재학습하고 인간 개입없이 재배포될 수 있도록 훈련 프로세스를 최대한 자동화하는 것입니다. 그러나 이를 설정하는 데는 종종 많은 엔지니어링 시간이 필요합니다.
ML 제품 담당자와 재학습 프로세스
이러한 경우 ML 제품 및 운영 관리자를 최대한 활용하는 것이 매우 유용합니다. ML 제품 및 운영 관리자를 활용하여 데이터셋을 지속적으로 개선하고, ML 엔지니어는 매주 새로운 데이터로 기존 모델 코드를 재학습하여 새로운 모델을 생성할 수 있습니다. 이 과정은 쉽고 자동화되어야 하며, 이를 통해 새로운 모델을 매주 배포함으로써 이전 모델보다 더 나은 성능을 제공할 수 있습니다.
좋은 ML 도구를 많이 사용하기
엔지니어들은 언제나 "스스로" 자체적인 도구/인프라를 구축하여 문제를 해결할 수 있지만, 이는 썩 좋은 방법은 아닙니다. 이는 많은 엔지니어링 시간이 소비되며, 최종 제품에는 많은 버그와 문제가 있을 가능성이 높습니다. 더 중요한 것은 이렇게 만들어 진 것이 사용하기 어렵다는 것입니다. 이는 도구 개발자 외 ML 제품 및 운영 관리자가 그 도구를 사용하는 것을 어렵게 만듭니다.
그래서 직접 만들기 보다는 훌륭한 오픈 소스 또는 유료 도구를 활용하려고 노력해야 합니다. 과거에는 ML 스택을 구축할 때 딥러닝은 아직 상대적으로 새로운 기술이었기 때문에 대부분의 도구를 직접 만들어야 했습니다. 하지만 요즘에는 유료 및 오픈 소스 도구들이 매우 풍부하게 제공되고 있어, ML 프로젝트를 더욱 빠르고 쉽게 시작할 수 있습니다. 또한 머신러닝을 위한 종합 플랫폼은 많이 있지만, 이런 플랫폼들은 대체로 활용성 측면에서 평범한 경우가 많습니다. 따라서 우리는 하나의 전문적인 부분에서 집중하고 있는 도구들, 이들을 통합하는 것이 더 나은 ML 도구 활용 방법으로 생각합니다.
추천 포스팅 (더 큰 규모의 ML 팀)
핵심 참고자료
Last updated