Paper: Software Engineering for Machine Learning: A Case Study
MS가 자사 제품에 머신러닝을 결합하면서 겪었던 과정들을 정리한 케이스 스터디에 대해 간단하게 리뷰합니다. 이 글에서는 주요 내용들 위주로 정리했습니다. 전체 내용은 논문을 참고해주세요.
Introduction
MS는 Bing Search, Cortana, Microsoft Translator 등과 같은 제품에서 머신러닝을 사용하고 있습니다. 이 과정에서 MS는 자사의 AI 역량을 활용해 회사 전체에 걸쳐 새로운 전문 지식을 쌓았습니다.
이 논문에서는 MS의 소프트웨어 팀이 어떻게 AI feature를 결합해 소프트웨어를 개발했는지에 대해 서술합니다. 이를 위해 직원들에게 AI를 결합한 소프트웨어 개발 과정에서 어떻게 일했는지에 대해 물었습니다.
이 과정을 통해 MS는 머신러닝 모델을 훈련하고 제품으로 적용하는 과정과 기존 어플리케이션 개발 과정과의 세 가지 주요 차이점을 발견했습니다. 먼저, 머신러닝은 모두 데이터에 관한 문제입니다. 데이터를 발굴하고, 관리하고 버저닝하는 데 드는 노력이 기존 소프트웨어 코드에 같은 과정을 적용하는 것보다 훨씬 복잡합니다. 두 번째로 커스터마이징이 쉽고 확장성 있는 모델을 개발하는 데에는 소프트웨어 엔지니어링 능력 뿐만 아니라 모델을 밑바닥부터 개발, 평가, 튜닝하는 데 필요한 깊은 지식이 항상 필요하다는 점입니다. 마지막으로 머신러닝 모델은 소프트웨어 팀이 다른 것들과 독립적으로 모델을 설계한다 하더라도 복잡하게 다른 것들에 영향을 끼칠 수 있다는 점입니다.
논문에서 스터디를 통해 말하고자 하는 점은 다음과 같습니다.
- MS 소프트웨어 팀이 머신러닝을 제품과 통합하기 위해 거치는 9가지 단계
- 머신러닝을 이용하는 어플리케이션과 플랫폼을 만드는 best practice
- 머신러닝 프로세스 성숙도를 평가하는 모델
- 머신러닝 중심 소프트웨어 개발과 기존 소프트웨어 개발간의 세 가지 주요 차이점
Study
연구는 인터뷰와 대규모 설문으로 진행되었습니다. 인터뷰 대상자는 ML에 익숙한 팀 리더, UX로서 AI가 주요 관점인 팀의 리더 (Cortana), 전사적인 AI/ML 교육에 관여하는 직원들입니다. 자세한 대상자는 아래와 같습니다.
설문은 인터뷰 결과를 바탕으로 설계되었습니다. 별표는 주관식 문항입니다.
Best Practices With Machine Learning In Software Engineering
아래 내용들은 인터뷰와 설문 결과 각 팀에서 어떻게 대규모 ML 어플리케이션과 플랫폼 적용에 도전하고 있는지 그 내용을 정리한 것입니다.
End-to-end pieline support
ML workflow (데이터 파이프라인, 하이퍼파라미터 튜닝 등)를 자동화하하는 것이 엔지니어의 업무상 오버헤드를 줄여줍니다. 논문에서 소개한 예는 내부 인프라 AEther를 활용하거나 MS의 고객이 머신러닝 모델을 만들고 배포할 수 있도록 Azure ML for VS Code나 Azure ML Studio를 개발한 경우입니다.
Data availability, collection, cleaning, and management
머신러닝 프로젝트는 대규모 데이터, 그 데이터의 품질과 관리에 달려 있습니다. 데이터 관리의 핵심은 (버전 관리 등과 같은) 데이터 소스 관리라고 할 수 있습니다.
또한 데이터는 계속해서 변경되기 때문에 그 과정을 잘 추적하는 것이 중요합니다. 데이터는 1) 엔지니어에 의해 변경되거나 2) 새로운 데이터가 추가되며 변경됩니다. 두 경우 모두 데이터 버저닝과 변경점 공유가 필요합니다.
MS에서는 데이터의 원천과 데이터를 추출하기 위해 사용된 코드 버전 등을 모두 명시함으로써 데이터 공유와 재사용성을 위해 데이터를 배포된 모델에 매핑했다고 합니다. (구체적인 방법은 나오지 않았습니다.)
Education and Training
머신러닝과 소프트웨어의 통합은 소비자가 사용하는 최접점 (이메일, 워드 프로세스)과 임베디드 기기에서 점점 광범위하게 일어나고 있습니다. 따라서 전통적인 소프트웨어 엔지니어는 ML 전문가와 함께 일하는 방법을 익혀야 합니다. MS에서는 다양한 방법으로 엔지니어를 교육했습니다.
먼저 연 2회 머신러닝/데이터 사이언스 사내 컨퍼런스를 열고 최소 하루는 기술의 기본, 알고리즘, 모범 사례를 소개하는 데 많은 노력을 쏟았씁니다. 추가로 직원이 엔지니어에게 프로젝트의 세부 사항과 제품 특징, 내부 툴을 소개하는 시간을 가지고 리서처는 학술 컨퍼런스에서 어떤 최신 연구들을 하는지 발표했습니다. 두번째로 MS의 여러 팀이 주마다 머신러닝/딥러닝 오픈 포럼을 열고 AI를 실습하고 배웁니다. 마지막으로 메일링과 수천명이 참여하는 온라인 포럼을 통해 누구나 AI/머신 러닝에 관한 질문과 답을 자유롭게 하고 최신 학술 컨퍼런스의 결과를 공유하는 공간을 마련했습니다.
Model Debugging and Interpretability
디버깅은 프로그램 자체의 디버깅 뿐만 아니라 모델의 오류와 불확실성에도 초점을 맞춥니다. 더 정확한 예측을 위해, 언제 어떻게 모델이 잘못 예측하는지 이해하는 것은 활발한 연구분야입니다. 또한 몇 가지 연구는 더 해석가능한 모델 사용을 위해 시각화 기술과 블랙박스를 해석하는 기술에 집중하고 있습니다.
Model Evolution, Evalutation, and Deployment
ML 중심 소프트웨어는 모델 수정, 파라미터 튜닝, 데이터 갱신, 시스템에 미치는 주요한 성능 상 영향 등을 이유로 빈번하게 바뀝니다. MS의 여러 팀은 모델 실험에 엄격하고 빠른 평가 기술이 중요하다고 밝혔습니다. 이를 위해 combo-flighting (복수의 평가 메트릭, 민감한 카테고리에는 사람이 평가 등) 기술을 적용한 체계적인 프로세스를 개발했습니다. 자동 테스트 또한 도입했습니다.
빠른 모델 개발 주기를 위해서는 배포도 자주 이뤄저야 합니다. 원활한 모델 배포를 위해 엔지니어들은 학습/배포 파이프라인 자동화, ML/비 ML 코드베이스를 함께 관리할 것을 추천했습니다.
Compliance
MS는 AI 사용에 대한 원칙들을 발표했습니다. 이 원칙들은 공정함, 책임, 투명함, 윤리에 대한 내용을 담고 있습니다. MS 내 모든 팀은 엔지니어링 과정이 이 원칙들을 따라야 합니다.
Varied Perceptions
MS의 팀은 각기 다른 ML 경험을 갖고 있습니다. 어떤 팀은 수십년간 데이터 사이언티스트와 리서처가 속해 ML 경험을 쌓아온 반면 어떤 팀은 빠르게 성장하고 있습니다. 이에 따라 각 팀이 M을 이용하는 데 맞닥뜨리고 있는 사항 또한 매우 다를 거라 판단했습니다.
눈몬 연구자들은 응답자들을 AI 경험연수 따라 낮음, 중간, 높음의 세 단계로 나눴습니다. 이에 따라 각 그룹별 가장 도전적인 분야가 무엇인지 순위를 매겼습니다.
두 가지를 주목할 수 있는데요. 먼저, ML 경험에 관계 없이 Data Availability, Collection, Cleaning, and Management 부분이 가장 도전적인 부분으로 꼽힌 것입니다. 이 외 각 그룹이 모두 비슷한 순위로 꼽은 분야에는 end-to-end pipeline support와 collaboration and working culture가 있습니다. 둘째, 응답자의 AI 경험도에 따라 순위가 오르내리는 분야가 있습니다. education and training은 경험이 낮은 그룹에서 더 중요하게 손꼽힙니다. 추가적으로 경험이 낮은 그룹에서 AI를 대규모 시스템에 통합하는 것을 높은 순위로 뽑았습니다. 반면 tooling, scale, and model evolution, evaluation, and deployment는 경험이 많은 그룹에게 더 도전적인 분야로 뽑히고 있습니다. 연구자들은 이러한 현상은 경험이 많은 그룹은 더 어려운 문제를 풀고 있기 때문일 가능성이 높을 것이라고 생각하고 있습니다.
각 분야별 빈도 빈도를 보면 Data Availability, Collection, Cleaning, and Management 은 낮음/중간 그룹에서 비슷한 반면 높음 그룹에서 더 빈번합니다. 반면 Education and Training, Integrating AI into larger systems, Education: Guidance and Mentoring에서는 중간/높음 그룹에서의 빈도가 급격히 떨어지는 모습을 보입니다. 이는 이들 그룹에서 위의 분야들이 낮음 그룹에 비해 덜 중요하다고 해석할 수 있습니다.
마지막으로 연구자들은 로지스틱 회귀 분석을 통해 개인/팀의 AI 경험, 업무 경험, AI 프로젝트 수, 머신러닝/데이터 사이언스 정규 교육 이수 등을 변수로 놓고 위의 빈도 차이를 설명할 수 있는지 확인했습니다. 아래의 5가지는 중요한 상관계수를 보인 것들입니다.
- Education and Training: 개인 AI 경험과의 상관계수가 -0.18 (p < 0.02) 입니다. 이는 AI 경험이 적은 사람이 이를 더 중요하게 느낀다는 의미입니다.
- Education: Guidance and Mentoring: AI 경험과의 상관계수가 0.26입니다 (p < 0.01). AI 경험이 많을수록 이를 더 중요하게 느낍니다.
- AI Tools: 이 항목은 팀 AI 경험과의 상관계수가 양수 (0.13, p < 0.001) 입니다. 이는 팀의 AI 경험이 쌓일 수록 그들이 사용하는 도구도 성장하고 따라서 그 도구들의 영향력 등을 더 고려하게 된다고 받아들일 수 있습니다.
- End-to-end pipeline support: 정규 교육과 양의 상관관계를 보입니다 (p < 0.01). 이는 정규 교육을 받은 사람들이 해당 분야에서 업무하고 있다는 것을 시사합니다.
- Specification: 이 항목 또한 정규 교육 이수 여부와 양의 상관관계를 보입니다 (p < 0.03). 이 또한 정규 교육을 이수한 사람들이 모델과 엔지니어링 시스템을 명세한다고 볼 수 있습니다.
Towards a model of ml process maturity
Varied Perceptions 섹션에서 보았듯이, AI 경험에 따라 중요하게 생각하는 분야도 다르고 업무에서 집중하는 분야도 다릅니다. 소프트웨어 팀이 더 성숙해질수록 ML 제품과 플랫폼을 더 효과적, 효율적으로 서비스할 수 있습니다.
연구자들은 이를 위해 단순 AI 경험도 대신 6가지 단계로 ML 성숙도를 측정하는 모델을 만들었습니다. 각 단계는 다음과 같습니다. 1) 명확한 목표 설정 2) 지속적 실행 3) 문서화 4) 자동화 5) 측정 및 추적 6) 끊임없는 개선. 각 단계는 소프트웨어 프로젝트의 성숙도를 평가하고 개선하기 위해 소프트웨어 개발에서 널리 쓰이는 CMM (Capability Maturity Model)과 6 sigma 를 기반으로 만들어졌습니다.
연구자들은 연구 참여자들에게 가장 신경쓰고 있는 두 단계 (소요 시간)에 대해 응답할 것을 요청했습니다. 구체적으로는 각 단계에 대해 그렇다고 생각하는 정도를 평가할 것을 요청했습니다. (1: 매우 그렇지 않음, 5: 매우 그러함) 아래는 구체적인 문항입니다.
- S1: My team has goals defined for what to accomplish with this activity.
- S2: My team does this activity in a consistent manner.
- S3: My team has largely documented the practices related to this activity.
- S4: My team does this activity mostly in an automated way.
- S5: My team measures and tracks how effective we are at completing this activity.
- S6: My team continuously improves our practices related to this activity.
결과 분석을 위해 연구자들은 참여자들에게 “How effective do you think your team’s practices around this activity are on a scale from 1 (poor) to 5 (excellent)?” 라는 질문으로 Activity Effectiveness (AE) 를 측정했습니다. AE와 성숙도 척도의 Spearman 상관계수는 0.4982 ~ 0.7627 (p < 0.001) 을 보입니다. 이는 성숙도 척도가 AI 업무의 성숙도와 효과를 측정하는 데 유효하다고 할 수 있습니다.
Discussion
연구자들은 기존 소프트웨어 엔지니어링과 ML 엔지니어링이 근본적으로 다른 부분을 세 가지로 요약합니다.
Data discovery and management
소프트웨어 엔지니어링에서 코드가 중요하다면 ML에서는 데이터가 전부입니다.
엔지니어들은 모델을 학습하고 튜닝하는 데 필요한 데이터를 탐색, 수집, 선별, 정제해야 합니다. 모든 데이터는 저장, 추적, 버전 관리가 되어야 합니다. 소프트웨어 API와 달리 데이터는 데이터를 특정하는 명시적인 스키마를 가진 경우가 드뭅니다. 하지만 ML의 빠른 주기 때문에 데이터 스키마는 빈번하게 바뀝니다.
코드는 버전 관리를 위한 잘 설계된 기술들이 있지만 데이터는 그렇지 않습니다. 프로젝트 사이즈가 커질수록 데이터를 잘 관리하는 것은 더욱 어려운 문제입니다. 이를 위한 기술들로 논문에서는 Gebru 의 연구와 Datadiff 기술을 추천합니다.
Customization and Reuse
ML 모델은 커스터마이징과 재사용에 코드보다 더 많은 노력을 들여야 합니다. 소프트웨어에서는 재사용 단위는 주로 함수, 알고리즘, 라이브러리, 모듈이며 이러한 것들은 GitHub 등에서 쉽게 검색하고 재사용할 수 있습니다.
ML 모델 또한 하나의 함수로 볼 수 있지만 실은 훨씬 복잡합니다. 모델의 한쪽 면은 학습 알고리즘이고 다른 한쪽은 그 함수를 통제하는 파라미터 집합입니다. 그러나 모델을 다른 도메인에 적용하거나 다른 입력에 사용하려면 많은 부분들이 바뀌어야 합니다. 파라미터는 에디터로 쉽게 바뀌는 것도 아닙니다. 모델은 재학습이 필요하거나 아예 다른 모델을 사용해야 할 수도 있습니다.
ML Modularity
대규모 소프트웨어 시스템의 또 다른 주요 특성은 모듈성입니다. 모듈은 분리되고 독립되어 개발 중 다른 컴포넌트의 행동에 간섭하지 않습니다. 모듈 별로 다른 각기 다른 팀이 개발하기도 합니다. 모듈 간 상호작용은 API를 통하며 API는 모듈 간 분리를 유지하고 각 팀이 함께 일할 수 있게 해줍니다.
ML 모델에서 엄격한 모듈을 유지하는 것은 두 가지 이유로 어렵습니다. 먼저 모델은 쉽게 확장되지 않습니다. 예를 들어 (아직은) 영어 NLP 모델에 피자 주문을 위한 NLP 모델을 붙여 제대로 동작하게 할 수 없습니다. 이 모델들은 함께 개발되어야 합니다.
둘째, 모델은 서로 간섭할 수 있습니다. 코드가 완벽히 분리되어 있더라도 한 모델의 결과는 다른 모델의 결과에 영향을 미칠 수 있습니다. 각 팀이 다른 모델을 개발하더라도 전체 시스템의 학습과 유지를 위해서는 매우 긴밀하게 소통해야 합니다. 이러한 현상은 대규모 시스템에서 한 모델의 변경이 전체 시스템의 성능을 떨어떠리는 결과를 불러올 수 있습니다.
마치며
이 논문은 ML을 기존 개발 프로세스에 통합하는 것이 결코 쉽지 않으며, 또한 ML 개발 프로세스는 기존 소프트웨어 엔지니어링과 매우 다르다는 것을 보여줍니다. 특히 데이터 관리의 어려움은 MS와 같은 큰 기업에서도 매우 중요하게 느끼고 있음을 확인할 수 있습니다. 대규모 시스템에서 대규모 데이터를 이용하며, 사용자와 수많은 상호작용이 일어나는 과정에서 전사적으로 ML을 통합하는 것이 얼마나 중요하고 또 어려운지를 알 수 있는 연구입니다.