ML을 사용하지 말아야 할 때 (When NOT to Use ML)

핵심 요약: 규칙으로 해결 가능하면 ML이 필요 없다. 복잡함의 비용(개발, 유지보수, 모니터링)을 항상 고려하라. “가장 좋은 ML 모델은 필요 없는 ML 모델이다.”

개요

ML은 강력하지만 만능은 아니다. 많은 경우, 규칙 기반 시스템, 통계적 방법, 또는 단순한 휴리스틱이 ML보다 효과적이고 비용 효율적이다. ML의 도입은 개발, 유지보수, 데이터 수집, 모니터링 등의 비용을 수반하므로, 이 비용이 성능 개선의 가치를 초과하지 않는지 반드시 평가해야 한다.

비유: “모든 문제에 망치를 쓰지 마라 - 나사에는 드라이버가 필요하다.” ML은 강력한 도구이지만, 모든 문제에 적합한 도구는 아니다. 규칙 기반 시스템, 통계적 방법, 단순 휴리스틱이라는 “드라이버”가 더 적합한 문제에 ML이라는 “망치”를 휘두르면, 비용만 늘고 결과는 더 나빠질 수 있다.

탄생 배경

“ML을 사용하지 말아야 할 때”라는 주제가 진지하게 논의되기 시작한 것은, 역설적으로 ML 만능주의(ML Solutionism)가 최고조에 달한 시기 이후였다.

ML 만능주의의 시대 (2015~2019):

딥러닝의 성공 사례가 언론에 대대적으로 보도되면서, “AI/ML로 해결할 수 없는 문제는 없다”는 분위기가 형성되었다. 스타트업들은 사업 계획서에 “AI 기반”이라는 문구를 넣으면 투자 유치가 쉬워졌고, 기업들은 경쟁사가 ML을 도입한다는 이유만으로 ML 프로젝트를 시작했다.
Gartner Hype Cycle에서 AI/ML은 “부풀려진 기대의 정점(Peak of Inflated Expectations)“에 위치했고, 실패 사례가 축적되기 시작했다.

반성과 전환 (2019~현재):

Google의 엔지니어 Martin Zinkevich가 발표한 “Rules of Machine Learning: Best Practices for ML Engineering”은 “Rule #1: ML 없이 시작하라”로 시작하며, ML 도입 전 규칙 기반 시스템으로 충분한지 먼저 확인할 것을 강조했다.
여러 기업에서 ML 프로젝트의 실패 사례가 공유되면서, “ML이 아닌 해결책(Non-ML Solution)” 문화가 성장했다. “가장 좋은 ML 모델은 필요 없는 ML 모델이다”라는 격언이 실무자들 사이에서 자리 잡았다.
Airbnb, Netflix 등은 ML 도입 의사결정 프레임워크를 공개하며, ROI 분석과 규칙 기반 대안 평가를 ML 프로젝트의 필수 사전 단계로 정착시켰다.

핵심 개념

1. 규칙 기반 대안이 충분한 경우

상황	예시	이유
비즈니스 규칙이 명확	”금액 > 100만 원이면 승인 불가”	규칙이 간단하고 변하지 않음
규칙 10개 이내	단순한 의사결정 트리	복잡도가 낮음
설명 가능성 필수	법적 규제가 있는 결정	ML의 블랙박스 특성이 문제
결정적 출력 필요	같은 입력에 항상 같은 출력	ML의 확률적 특성이 부적합

규칙 기반의 장점: 투명성, 디버깅 용이, 배포 간단, 유지보수 쉬움, 데이터 불필요

2. 데이터가 부족한 경우

데이터 크기	추천 접근
수십 건	규칙 기반, 전문가 시스템
수백 건	간단한 통계 모델, 소수의 규칙
수천 건	간단한 ML (로지스틱 회귀, 트리)
수만 건+	ML이 효과적

라벨링 비용이 매우 높은 경우:

의료 영상 라벨링 (전문의 필요)
법률 문서 분류 (변호사 필요)
Few-shot/Zero-shot 학습 고려

경험적 최소 데이터 규모 추정:

$n \geq 10 \cdot \frac{d}{\epsilon^2}$

여기서 $n$ 은 최소 샘플 수, $d$ 는 특성(feature) 수, $\epsilon$ 은 허용 오차이다. 이른바 “10배 규칙”에 따르면, 특성 수의 최소 10~20배 이상의 샘플이 확보되어야 ML 모델이 안정적으로 학습할 수 있다.

3. 기타 ML이 부적합한 경우

상황	설명
데이터 품질이 매우 낮음	”Garbage In, Garbage Out” — ML이 노이즈를 학습
인과관계 추론이 필요	ML은 상관관계를 학습, 인과관계가 아님
비용 대비 효과 불명확	개발/유지 비용 > 성능 개선 가치
윤리적/법적 제약	특정 정보(인종, 성별)를 사용할 수 없는 경우
해결책이 이미 있음	기존 시스템이 충분히 잘 작동
문제가 정의되지 않음	”뭔가 개선하고 싶다”는 ML 문제가 아님

상세 내용

ML 도입 의사결정 플로우차트

ML 도입 의사결정 플로우차트 다이어그램

ROI (투자 수익률) 분석

ML 도입의 비용:

데이터 수집 및 라벨링
모델 개발 (엔지니어/연구자 인건비)
인프라 (GPU, 서버, 스토리지)
모니터링 및 유지보수
재학습 파이프라인

ML 도입의 가치:

성능/정확도 개선의 비즈니스 가치
자동화에 의한 인건비 절감
사용자 경험 개선
경쟁 우위

ML 도입의 ROI는 다음과 같이 정량화할 수 있다:

$\text{ROI}_{\text{ML}} = \frac{\text{Value}_{\text{ML}} - \text{Value}_{\text{baseline}} - \text{Cost}_{\text{ML}}}{\text{Cost}_{\text{ML}}}$

여기서 $\text{Value}_{\text{ML}}$ 은 ML 도입 후 기대 가치, $\text{Value}_{\text{baseline}}$ 은 기존 방법의 가치, $\text{Cost}_{\text{ML}}$ 은 ML 도입 총비용이다. ML 도입이 정당화되려면 $\text{ROI}_{\text{ML}} > 0$ 이어야 한다.

규칙 기반 대비 한계 이득(marginal gain)은 다음과 같다:

$\Delta V = V_{\text{ML}} - V_{\text{rule-based}}$

$\Delta V$ 가 ML 도입 비용을 초과하는지가 핵심 판단 기준이다.

핵심 질문: “이 문제에 ML을 적용했을 때의 한계 이득(marginal gain)이 규칙 기반 대비 충분히 큰가?”

ML을 도입하기 전에 시도할 것들

도메인 전문가의 규칙: 전문가 인터뷰로 핵심 규칙을 추출
간단한 통계: 기술 통계, 상관관계, 빈도 분석
SQL 쿼리 기반 분석: 집계, 필터, 임계값
A/B Testing: ML 없이도 간단한 변경의 효과 측정
기존 도구 활용: 이미 검증된 비ML 솔루션

언제 사용하는가

이 장의 내용은 ML 도입 여부를 판단해야 하는 모든 상황에 적용된다.

의사결정 이론에서 완전 정보의 기대 가치(EVPI)를 활용하면 ML 도입 여부를 정량적으로 판단할 수 있다:

$\text{EVPI} = \mathbb{E}[\text{Value with perfect info}] - \mathbb{E}[\text{Value with current info}]$

EVPI는 예측을 완벽하게 개선했을 때 얻을 수 있는 최대 추가 가치이다. $\text{EVPI} < \text{Cost}_{\text{ML}}$ 이면, 아무리 완벽한 ML 모델을 만들어도 비용을 정당화할 수 없으므로 ML 도입의 근거가 없다.

특히 다음 질문에 “아니오”가 나오면 ML을 재고해야 한다:

문제를 명확한 입력-출력 관계로 정의할 수 있는가?
충분한 양과 질의 데이터가 있는가?
ML이 기존 방법보다 의미 있는 개선을 가져올 것으로 기대되는가?
유지보수 비용을 감당할 수 있는가?

실전 사례

300만 달러 ML 사기탐지 vs 규칙 기반 시스템

한 중견 금융 회사에서 사기 탐지(Fraud Detection) 시스템을 도입하면서 겪은 비교 사례이다.

ML 기반 접근 (프로젝트 A):

항목	내용
개발 기간	18개월
총 비용	$3M (인건비$ 2M + 인프라 $700K + 데이터 라벨링$ 300K)
팀 규모	데이터 과학자 4명 + ML 엔지니어 2명 + 데이터 엔지니어 2명
최종 성능	정확도(Accuracy) 89%, 정밀도(Precision) 72%, 재현율(Recall) 68%
배포까지 지연	개발 완료 후 프로덕션 배포까지 추가 3개월
유지보수	월 $50K (모니터링, 재학습, 인프라)

규칙 기반 접근 (프로젝트 B):

항목	내용
개발 기간	2개월
총 비용	$150K (도메인 전문가 컨설팅$ 50K + 개발 $100K)
팀 규모	소프트웨어 엔지니어 2명 + 사기 조사 전문가 1명
최종 성능	정확도 95%, 정밀도 91%, 재현율 88%
배포까지 지연	즉시 배포 가능
유지보수	월 $5K (규칙 업데이트)

왜 규칙 기반이 더 좋았는가:

해당 금융 회사의 사기 패턴은 10가지 이내의 명확한 규칙으로 설명 가능했다 (예: “해외 거래 + 새벽 시간 + 고액” 등)
사기 조사 전문가가 20년간 축적한 도메인 지식이 데이터에 담기지 않은 패턴까지 포착
규칙 기반 시스템은 설명 가능성이 완벽해, 규제 기관 감사에 즉시 대응 가능
ML 모델의 89% 정확도는 False Positive가 너무 많아 조사팀의 업무 부하가 오히려 증가

교훈: ML은 도구이지 목적이 아니다. 이 회사는 결국 프로젝트 A를 폐기하고 프로젝트 B를 채택했으며, 절약된 예산으로 사기 조사팀을 확충했다. $3M의 ML 투자보다$ 150K의 규칙 기반 시스템이 모든 면에서 우월한 결과를 보여준 사례이다.

흔한 오해와 함정

“모든 문제에 AI를 적용해야 한다”: ML은 도구이지 목적이 아니다. 문제에 맞는 가장 간단한 해결책을 먼저 시도하라.
“ML이 규칙 기반보다 항상 우월하다”: 규칙이 명확하고 안정적인 문제에서는 규칙 기반이 더 신뢰할 수 있고, 유지보수가 쉽다.
“데이터가 적어도 딥러닝이면 된다”: 데이터가 부족하면 아무리 강력한 모델도 일반화할 수 없다. 전이 학습이나 few-shot learning을 고려하되, 근본적 한계를 인식하라.
유지보수 비용 과소평가: 모델은 배포 후에도 데이터 drift 모니터링, 재학습, 인프라 관리가 필요하다. 이 지속적 비용이 초기 개발 비용보다 클 수 있다.
“인과관계를 ML로 파악할 수 있다”: ML은 상관관계를 학습한다. 인과관계 분석에는 A/B Testing, 인과 추론(causal inference) 기법이 필요하다.

다른 주제와의 연결

ML 파이프라인 설계: Baseline 설정의 중요성
윤리적 AI: ML 도입의 윤리적 고려
흔한 실수: 잘못된 ML 적용
ML 시스템 설계 패턴: 시스템 복잡도 관리
Few-Shot/Zero-Shot: 데이터 부족 시 대안