ML 프로젝트를 계획하는 것은 일반적인 소프트웨어 엔지니어링 프로젝트를 계획하는 것과 다릅니다. ML 프로젝트는 비선형적이며 불확실성의 정도가 다양합니다. 반복적인 접근 방식과 실험적인 사고방식이 필요합니다.
프로젝트 불확실성
프로젝트를 시작할 때는 일반적으로 최선의 접근 방식이 명확하지 않으므로 초기 계획 단계가 어려울 수 있습니다. 이러한 내재된 불확실성으로 인해 타임라인을 추정하기 어렵습니다.
최근 Kaggle 대회에서는 ML 프로젝트의 불확실성을 보여주었습니다. 대회 첫 몇 주 동안 350개 팀이 참여했습니다. 상위 팀은 벤치마크 예측 품질을 35% 에서 65%로 높일 수 있었습니다. 그 후 2주 동안 이 문제를 해결하는 팀의 수가 350개에서 1, 400개로 늘어났습니다. 그러나 최적의 모델은 예측 품질이 68%에 불과했습니다.
그림 3은 노력은 크게 증가했지만 모델 품질은 최소한만 향상됨을 보여주는 ML 개발의 불확실성을 보여줍니다.
그림 3. 2주 동안 이 문제를 해결하는 팀의 수가 4배로 늘어났지만 모델의 품질은 거의 동일하게 유지되어 ML 솔루션의 노력을 추정하는 것이 얼마나 어려운지 보여줍니다.
즉, 각각 다양한 데이터 변환, 아키텍처, 초매개변수를 실험하는 1,000개가 넘는 팀이 68% 의 예측 품질을 갖는 모델을 만드는 데만 성공했습니다.
업계의 한 예는 출력이 입력에 비례하지 않는 ML 프로젝트의 비선형성을 보여줍니다. 두 팀은 모델을 90% 의 예측 품질로 학습하는 데 몇 개월이 걸렸습니다. 하지만 99.9% 의 예측 품질로 프로덕션에 사용할 준비가 되기까지 여러 팀이 5년 넘게 걸렸습니다.
이러한 예는 프로덕션에서 바로 사용 가능한 ML이 탐색적 프로세스이며 과학적 사고와 엔지니어링 사고가 모두 필요하다는 점을 보여줍니다.
실험적 접근 방식
대부분의 경우 ML 개발은 기존 소프트웨어 엔지니어링을 실행하는 것보다 실험을 실행하는 것과 더 유사합니다. ML을 사용하려면 다양한 기능을 테스트하고, 여러 아키텍처를 시도하고, 초매개변수를 적절하게 조정해야 합니다. 정의에 따라 실험이 성공적으로 진행된다고 보장할 수는 없습니다. 따라서 실험 프레임워크를 사용하여 계획하는 것이 가장 좋습니다.
일반적인 소프트웨어 엔지니어링 계획을 살펴보고 ML 프로젝트 계획과 어떻게 다른지 알아보겠습니다.
소프트웨어 엔지니어링 프로젝트 계획
일반적인 소프트웨어 엔지니어링 계획에서는 요구사항을 정의하고, 구성요소의 개요를 작성하고, 노력을 추정하고, 작업을 예약합니다. 해결 방법으로 명확하게 정의된 경로가 있습니다. 예를 들어 엔지니어는 설계 사양을 충족하는 애플리케이션을 빌드하기 위해 완료해야 하는 작업을 상당히 확실하게 알고 있습니다.
작업을 완료하는 데 걸리는 시간을 예측할 때 유사한 프로젝트를 기반으로 작업을 추정할 수 있습니다. 알 수 없는 종속 항목이나 변경되는 요구사항과 같이 예측하기 어려운 문제가 항상 발생하지만 일반적으로 솔루션으로 가는 명확한 경로가 있습니다.
반면 ML 프로젝트에는 일반적으로 하나의 명확한 성공 경로가 없습니다.
ML 프로젝트 계획
대부분의 ML 프로젝트에서는 시행착오를 거치는 과정에서 여러 접근 방식을 실험하여 최적의 솔루션을 찾습니다. 일반적으로 문제를 해결하기 전에 문제에 대한 최적의 해결책을 알 수 없습니다. 예를 들어 최적 솔루션의 아키텍처는 단순한 선형 모델, 신경망 또는 결정 트리일 수 있습니다. 각 접근 방식을 시도해 봐야만 최선의 해결책을 찾을 수 있습니다.
이러한 모호성으로 인해 계획하기가 어렵습니다. 앞서 설명한 것처럼 ML 프로젝트에 필요한 노력을 예측하기는 어렵습니다. 문제를 해결하려고 시도해 봐야만 해결에 필요한 시간과 리소스를 더 잘 파악할 수 있습니다.
다음은 ML 작업을 계획할 때 권장되는 전략입니다.
작업에 시간 제한을 적용합니다. 작업을 완료하거나 특정 해결 방법을 시도할 수 있는 명확한 기간을 설정합니다. 예를 들어 적절한 종류의 데이터에 액세스할 수 있는지 확인하는 데 2주를 할당할 수 있습니다. 데이터를 가져올 수 있다면 간단한 모델이 ML 솔루션이 실행 가능함을 나타내는지 확인하는 데 2주를 더 지정할 수 있습니다. 간단한 모델이 실패하면 2주를 더 지정하여 신경망을 시도해 볼 수 있습니다. 각 기간이 끝나면 문제에 리소스를 계속 적용하는 것이 가치가 있는지 판단할 수 있는 더 많은 정보가 확보됩니다.
프로젝트 요구사항 범위 축소 ML 솔루션이 유망해 보이지만 제품 또는 서비스에 중요한 기능이 아닌 경우 요구사항의 범위를 축소하세요. 예를 들어 다음 분기의 작업을 계획할 때 매우 간단한 솔루션을 시도해 볼 수 있습니다. 그런 다음 후속 분기에는 솔루션을 반복적으로 개선할 계획을 세울 수 있습니다. 장기간에 걸쳐 점진적으로 개선하여 ML 솔루션을 구현하는 것이 많은 팀이 효과적인 ML 솔루션을 도출하는 방법이었습니다.
인턴 또는 신입사원 프로젝트 인턴이나 신입사원을 지시하고 안내하여 ML 솔루션을 시도하도록 하는 것은 결과를 알 수 없는 새로운 영역을 탐색하는 좋은 방법일 수 있습니다. 프로젝트가 끝나면 ML 솔루션에 필요한 노력과 추구할 가능성이 있는 접근 방식 또는 리소스를 다른 곳에 배치해야 하는지 여부를 더 잘 파악할 수 있습니다.
어떤 전략이든 실패를 빠르게 경험하는 것이 좋습니다. 비용이 가장 적지만 잠재적으로 가장 높은 수익을 올릴 수 있는 접근 방식을 먼저 시도합니다. 이 접근 방식이 효과가 있으면 좋은 해결 방법을 찾은 것입니다. 그렇지 않다면 많은 시간과 리소스를 낭비하지 않은 것입니다.
팀이 실험 실행에 대한 경험과 노출을 얻으면 실험에 필요한 노력을 더 정확하게 추정하여 계획을 더 예측 가능하게 만들 수 있습니다. 그러나 실험 결과는 거의 항상 알 수 없으므로 최적의 솔루션을 찾는 데 필요한 실험 횟수를 미리 추정할 수 없습니다.
실험적인 사고방식으로 접근 방식을 계획하면 팀이 성공을 거둘 수 있습니다. 접근 방식이 막다른 길로 이어지더라도 팀원들은 실망하지 않고 ML 솔루션을 찾는 과정의 일부라고 이해합니다. 더 중요한 점은 ML 개발에 내재된 불확실성을 이해관계자와 논의하여 더 현실적인 기대치를 설정할 수 있다는 것입니다.
이해도 확인
주의사항
확률적으로 여러 ML 접근 방식을 계획하는 방법을 배우려면 시간과 경험이 필요합니다. 프로젝트 계획을 자주 업데이트해야 할 수 있습니다. 팀에서 여러 접근 방식을 실험하면서 지속적으로 발전하는 동적 문서로 생각하면 됩니다. 다음 핵심 사항에 집중하면 성공 확률을 높일 수 있습니다.
- 각 접근 방식의 비용과 성공 가능성을 추정합니다.
- 다양한 접근 방식을 시도해 보세요.
- 교훈을 파악하고 한 번에 하나씩 시스템을 개선해 보세요.
- 장애에 대비한 계획
초기 접근 방식이 획기적인 결과를 가져오는 경우도 있습니다. 누군가 데이터 생성 파이프라인 또는 학습-검증 분할에서 버그를 발견할 수 있습니다. 효과적인 계획과 철저한 문서화로 비즈니스 문제를 예상보다 빨리 해결하는 모델을 찾을 가능성이 높아집니다.