데이비드 탄, 에이다 양, 데이비드
2일 전
814
잘되는 머신러닝 팀의 비밀 3부작
1부. “왜 많은 머신러닝 프로젝트는 실패하는가?” — 제품화 실패의 진짜 이유
가장 위험한 종류의 낭비는 우리가 인식하지 못하는 낭비입니다.
시게오 신고 Shigeo Shingo, 도요타 생산 시스템에 대한 선도적 전문가
많은 개인과 조직이 머신러닝(ML) 여정을 시작할 때 큰 기대를 품습니다. 하지만 많은 ML 실무자들의 경험은, 그 여정이 함정과 우회로, 때로는 넘기 어려운 장애물로 가득하다는 현실을 보여주죠. 화려한 데이터 과학의 겉모습을 걷어내고 보면, 실제로는 수많은 수작업, 운영 중 발생하는 복잡한 문제 해결, 고립된 팀 간 협업, 다루기 까다롭고 불안정한 시스템과 마주하는 경우가 많습니다.
이러한 문제는 고객에게 가치를 전달하는 데 직접적인 방해가 되며, 결국 조직의 AI 투자와 기대를 좌절로 이끌기도 합니다. ML 기술에 대한 과도한 기대가 만들어낸 하이프 사이클 hype cycle 을 따라가다 보면, 어느 순간 '부풀려진 기대의 정점'을 지나 '실망의 골짜기'로 추락하게 되는 경험을 하게 됩니다. 일부 ML 팀만이 지속적인 성과를 내며 ‘생산성의 고원’에 도달합니다. 우리는 종종 이런 팀을 보며, 과연 우리도 그곳에 이를 수 있을지 고민하게 됩니다.
ML이 포함된 제품이나 시스템을 만들고 있다면, 곧 마주치게 될 공통적인 도전 과제들이 있습니다. 이 글은 다양한 팀과 우리의 실제 경험을 바탕으로, 그 도전들을 극복하기 위한 원칙과 실천 방법을 정리한 것으로, 불필요한 함정을 피하고 신뢰할 수 있는 ML 여정을 설계하는 데 도움이 되길 바랍니다.
과대광고와 하이프 사이클에서 한발 물러나 보면, 머신러닝(ML)은 여전히 빠르게 진화 중인 분야이며, 실제 문제 해결을 위한 강력한 기술들을 제공합니다. 스탠퍼드의 <AI 인덱스 보고서>에 따르면, 2021년 전 세계 민간 AI 투자액은 약 940억 달러(약 134조 원)에 달했습니다. 이는 팬데믹 이전인 2019년 대비 두 배 이상 증가한 수치입니다.
맥킨지의 <2021년 AI 현황>도 이를 뒷받침합니다. AI를 도입한 기업의 비율은 2020년 50%에서 2021년에는 56%로 상승하며, 도입 추세가 지속되고 있음을 보여줍니다.
스탠퍼드 보고서에 따르면, 기업들은 자연어 이해(NLU), 컴퓨터 비전, 강화학습 같은 다양한 ML 기술을 실제 산업에 적용하기 위해 계속해서 투자하고 있습니다. 또한 2010년 이후 수백만 건의 구인 공고를 분석한 결과, ML 역량에 대한 수요는 매년 꾸준히 증가하고 있으며, 이는 코로나19 팬데믹 기간과 그 이후에도 마찬가지였습니다.
이러한 흐름은 기회 측면에서는 고무적이지만, 동시에 경고이기도 합니다. 과거에 많은 ML 시스템이 마주한 공통적인 실패 요인들을 제대로 이해하고 극복하지 못한다면, 이 성장세는 오히려 새로운 낭비와 좌절을 반복하게 만들 수 있습니다.
지금부터 그 함정들을 하나씩 살펴보겠습니다.
캐글(Kaggle)에는 뛰어난 노트북이 넘쳐나지만, 현실 세계의 ML 프로젝트는 실패하는 경우가 훨씬 더 흔합니다. 실패는 다양한 형태로 나타납니다.
✔️ ML 기능이 포함된 제품을 운영 환경에 배포하지 못함
✔️ 고객이 실제로는 거의 사용하지 않는 제품을 배포함
✔️ 신뢰할 수 없는 결함 있는 제품을 내놓음
✔️ 운영 중인 모델을 개선하지 못함
우리는 실패 자체를 피하려는 것이 아닙니다. 실패는 피할 수 없고, 때로는 유익하기도 합니다. 하지만 그 실패의 비용이 너무 클 때 문제가 됩니다. 예를 들어, 마감일을 놓치거나 비즈니스 목표를 달성하지 못하는 정도를 넘어, 사람들에게 피해를 주거나, 프로젝트 외부의 팀원들까지 영향을 받아 일자리를 잃는 상황까지 벌어지기도 합니다.
따라서 목표는 저비용, 저위험의 환경에서 자주 실험하고 실패하면서도, 그 경험에서 교훈을 얻어 문서화하고 공유해 같은 실패를 반복하지 않는 것입니다.
먼저 ML 프로젝트의 성공 가능성을 낮추는 일반적인 도전 과제들을 살펴보고, 이어지는 이야기에서는 어떻게 하면 실패의 비용과 가능성을 낮추며, 더 안정적으로 가치를 전달할 수 있을지 이야기합니다.
ML 프로젝트가 원하는 성과를 달성하지 못하는 이유를 높은 수준에서 살펴보면 다음과 같은 도전들 때문입니다.
이 경우에는 엔지니어링 사례가 충분히 갖추어져 있고 ‘제대로 된 제품을 만들었다’고 할지라도, ‘올바른 제품을 만들지 않았다’는 이유로 비즈니스 목표에 도달하지 못합니다. 엔지니어링적으로 완성도가 높은 제품이라도, ‘올바른 제품을 만들지 않았다’면 성공할 수 없습니다. 이는 보통 제품 관리 역량 부족이나, 제품이 비즈니스 목표와 일치하지 않았을 때 나타납니다. 사용자 중심 설계 없이 ML 팀이 독단적으로 방향을 정하면, 고객에게 실제 가치를 주지 못하게 됩니다.
모델이 잘 훈련되었어도 운영 환경에는 배포되지 못하는 경우가 많습니다. 단순히 컴퓨팅 문제에 국한되지 않고, 운영 환경에서 사용할 수 있는 데이터 품질, 지연 시간, 입력 분포 등이 개발 환경과 다른 점도 포함됩니다.
모델이 운영 환경에 도입된 후에도 문제는 발생할 수 있습니다. 반복적인 실험과 모델 개선을 방해하는 지루한 작업에 ML 종사자들이 매몰되는 것이 일반적입니다. 2021년 알고리드미아 보고서에 따르면, 기업의 64%는 새 모델을 배포하는 데 한 달 이상이 걸리며, 데이터 과학자의 절반 이상이 그 시간을 ‘배포 준비’에 쓰고 있습니다. 이는 프로젝트 규모가 커질수록 악화됩니다.
모델을 개선하려면 빠른 피드백이 필요하지만, 수동으로 노트북을 실행하고 로그를 검토하는 긴 피드백 루프는 비효율적이며, 개발 중이나 운영 중에 예상치 못한 오류와 품질 저하 문제를 발생시키기도 합니다. 운영 환경에 데이터 수집 및 라벨링 메커니즘이 없으면, 모델 개선 기회를 놓치게 됩니다.
ML 코드 베이스는 종종 이해하기 어려운 코드로 가득 차 있습니다. 예를 들어, 잘못된 변수 이름, 길고 복잡한 함수, 구조가 명확하지 않은 코드 (또는 스파게티 코드) 등이 있습니다. 이런 요소들은 코드를 이해하고 수정하기 어렵게 만들고, 기능 추가 시 오류와 버그의 위험을 증가시킵니다. 또한 자동화된 테스트 없이 운영되는 ML 시스템은 리팩터링도 어렵고, 결과적으로 개발 주기를 느리게 만듭니다.
<영국 의학 저널>의 연구에 따르면, 병원이 코로나19를 감지하기 위해 개발한 수백 개의 예측 도구 중 어느 것도 실제로 작동하지 않았습니다. 이 모델들이 실패한 이유 중 하나는 데이터 품질 문제였습니다. 데이터 누출, 잘못된 레이블 데이터, 훈련 데이터와 실제 데이터 간의 차이 등이 주요 원인이었습니다.
문제를 더 복잡하게 만드는 것은 모델을 자동으로 재훈련, 재평가, 재테스트 및 재배포 하는 과정에서의 어려움입니다. 이는 시간이 지남에 따라 변화하는 데이터에 대응하는 우리의 능력을 저해합니다.
데이터 보안과 프라이버시는 팀의 구성원 모두가 함께 책임져야 합니다. 악의적이거나 편향된 데이터를 훈련셋에 주입하여 모델을 손상시키는 데이터 포이즈닝data poisoning, 프롬프트 주입 공격, 사용자 데이터 유출 가능성 등은 점점 현실적인 위협이 되고 있습니다.
또한, 아마존의 채용 필터처럼 무의식적 편향이 내재된 ML 제품은 심각한 윤리 문제로 이어질 수 있습니다. 이런 문제는 모델 자체보다, 훈련 데이터와 설계 과정의 투명성 부족에서 비롯됩니다.
많은 팀이 ML 전달의 효율성을 높이기 위해 MLOps나 ML 플랫폼에 기대를 겁니다. 하지만 이들만으로는 충분하지 않습니다. DevOps가 소프트웨어 개발에서 인프라나 배포를 돕지만, 설계·사용자 경험·전달 방식까지 해결해주지는 않는 것과 마찬가지입니다.
ML에서도 마찬가지입니다. 자동화된 파이프라인과 플랫폼은 중요하지만, 그것만으로는 좋은 제품을 만들 수 없습니다.자동 테스트, 잘 구성된 설계처럼 소프트웨어 엔지니어링 실천 방법과 고객 여정 매핑, 명확한 사용자 스토리 등의 제품 전달 실천 방법이 없다면, 아무리 훌륭한 MLOps 체계라도 반복적 낭비와 재작업을 막을 수 없습니다.
실제로 Booking.com의 연구에 따르면, 성공적인 ML 응용 프로그램은 대부분 가설 기반의 반복 실험을 중심으로 제품 설계, 사용자 경험, 컴퓨터 과학, 소프트웨어 엔지니어링, 인과 추론 등 다양한 분야가 통합되어 있었습니다.
우리 역시 ML 프로젝트의 성공에는 제품, 소프트웨어 엔지니어링, 데이터, ML, 그리고 전달이라는 다섯 가지 핵심 분야의 통합이 필요하다는 사실을 여러 번 확인해 왔습니다.
이 다섯 요소가 균형 있게 통합되지 않으면, 성과는 구조적으로 반복되기 어렵습니다.
시스템 사고는 시스템의 개별 부분보다, 모든 요소 간의 관계와 상호작용에 초점을 맞추도록 도와줍니다. 시스템 사고는 우리가 잘못된 구조를 이해하고 개선할 수 있도록 정신 모델과 도구를 제공합니다. 여기에는 우리의 사고 방식과 인식도 포함됩니다.
왜 ML 제품 전달을 시스템으로 봐야 할까요? 그리고 시스템이란 무엇일까요? 시스템 사고의 선구자인 도넬라 메도우스 Donella H. Meadows 는 시스템을 ‘서로 연결된 요소들이 일관되게 조직 되어 어떤 목적을 달성하는 집합’으로 정의합니다. 시스템은 요소, 상호 연결, 기능 또는 목적 이라는 세 가지 요소로 구성되어야 합니다.
이제 ML 제품 전달의 맥락에서 다시 읽어 보겠습니다. 시스템은 방금 말한 것처럼 세 가지 요소로 구성됩니다.
데이터, ML 실험, 소프트웨어 엔지니어링, 인프라 및 배포, 사용자 및 고객, 제품 설계및 사용자 경험 등
크로스 기능 협업 및 이후 레이블링과 재훈련을 위한 데이터를 생성하는 운영 ML 시스 템 등
사용자가 가장 적합한 제품을 찾도록 돕는 것 등
이러한 상호 연결에서 정보 흐름을 보고 최적화하는 능력은 ML 제품을 효과적으로 전달하는데 도움이 됩니다. 반면, ML 제품 전달을 단순히 데이터와 ML 문제로만 보는 팀은 실패할 가능성이 더 큽니다. 시스템의 전체적인 본질이 결국 드러날 것이기 때문입니다.
시스템 사고는 모든 요소가 상호 연결된 전체로서의 시스템을 인식합니다. 이 관점에서는 시스템 내 어느 한 부분의 변화가 전체에 영향을 미칠 수 있다는 것을 이해해야 합니다. 따라서 시스템을 깊이 이해하고 효과적으로 개선하려면 개별 요소뿐만 아니라 시스템 전체의 작동 방식을 종합적으로 고려해야 합니다.
다행히도, ML 전달 시스템 요소 사이의 상호 연결에서 정보 흐름을 개선하는 데 도움이 되는 철학이 있습니다. 그것이 바로 린입니다.
우리는 다양한 ML 프로젝트에서 반복적으로 낭비가 발생하는 장면을 목격합니다. 예를 들어, 고객에게 가치를 주지 못하는 기능을 완성하느라 시간을 소모하거나, 팀 간 협업 병목으로 며칠을 허비하거나, 예상치 못한 버그로 작업 흐름이 중단되기도 합니다. 이러한 낭비는 곧 출시 지연, 목표 미달성, 팀 피로와 사기 저하로 이어집니다.
이런 문제는 ML 팀이라면 누구나 경험하게 되는 현실입니다. 그러나 해결의 실마리는 있습니다. 린은 조직이 고객 중심의 가치를 식별하고, 그 가치를 효율적으로 전달하도록 돕는 원칙과 도구를 제공합니다. 고객의 목소리를 개발 과정에 반영함으로써, 팀은 더 적절한 제품을 만들고 불필요한 작업을 줄일 수 있습니다.
린 실천 방법은 1950년대 도요타 생산 시스템(TPS)에서 출발했으며, 이후 제임스 워맥과 다니엘 존스가『The Machine That Changed the World』에서 정리한 린 원칙으로 널리 알려졌습니다. 이 원칙들은 자동차 산업을 넘어 IT, 소프트웨어, 데이터 분야까지 널리 확산되었습니다.
린의 핵심은 단순히 기능을 ‘많이’ 만드는 것이 아니라, 고객에게 의미 있는 가치를 ‘먼저’ 전달하는 데 집중하는 것입니다. 우리는 기술이 멋지다는 이유만으로 기능을 추가하기보다는, 고객 가치를 기준으로 우선순위를 정하고, 그 수요가 명확해졌을 때만 이를 개발 흐름에 ‘끌어오는’ 방식을 택합니다. 반대로 이 원칙이 무시되면, 코드 베이스에 복잡성은 늘어나고 가치 없는 결과물이 쌓이게 됩니다.
이어 린 원칙 중 하나인 가치 흐름 매핑(Value Stream Mapping)은 고객에게 가치를 전달하는 데 필요한 모든 단계와 자원을 시각화하는 도구입니다. 이를 통해 팀은 낭비를 식별하고 제거하며, 더 효율적인 흐름을 설계할 수 있습니다.
위 콘텐츠는『잘되는 머신러닝 팀엔 이유가 있다』내용을 재구성하여 작성하였습니다. 우리는 이를 통해 ML 프로젝트 실패의 주요 원인과, 시스템 사고를 통한 전체 구조의 이해, 그리고 린 사고를 통해 낭비를 줄이고 가치를 극대화하는 방법을 살펴봤습니다. 또한 효과적인 ML 전달을 위해 필요한 다섯 가지 핵심 영역을 조망했습니다.
우리는 다양한 산업의 ML 및 데이터 과학 팀과 협업하며, 여전히 많은 팀이 ‘ML과 린 소프트웨어 전달’ 사이에 커다란 간극을 겪고 있다는 사실을 확인했습니다. 일부 팀은 이 간극을 넘어 성공적으로 제품을 출시했지만, 많은 팀은 여전히 제품 설계, 전달 구조, 엔지니어링 실천에 있어서 기초가 부족한 상태입니다.
이 간극을 해소하기 위해서는 ML 커뮤니티가 기술 중심의 접근을 넘어, 제품 중심의 관점과 다학제적 협업 기반으로 사고 전환을 해야 합니다. ML 제품은 단순히 데이터와 모델의 문제가 아니라, 본질적으로 제품, 엔지니어링, 전달의 문제이기 때문입니다.
희망적인 점은, 이미 검증된 원칙과 실천 방법들이 있다는 것입니다. 바다를 끓일 필요도, 새로운 바퀴를 발명할 필요도 없습니다. 책 『잘되는 머신러닝 팀엔 이유가 있다』에서는 각 분야별로 구체적인 실천 전략과 사례를 소개합니다. 제품과 전달에서 출발해, 실용적인 원칙과 코드 예제, 프레임워크까지 함께 다루며, 여러분이 ML 프로젝트에 직접 적용할 수 있도록 돕겠습니다. 이 여정에 함께하길 기대합니다.
0
2 
댓글