머신러닝 모델이 실무에서 실패하는 이유 — 프로젝트 범위 설정과 모델 드리프트 대응 전략

핵심 메시지

• 예측 성능이 높은 모델이라도 이해관계자의 실제 필요와 어긋나면 실서비스에 오르지 못한다.
• 성공 기준은 반드시 수치로 정의해야 한다. 정량화하지 못하면 모델 유지 비용을 정당화할 수 없다.
• 제약과 위험을 먼저 따져야 한다. 잘못된 예측이 누구에게 어떤 피해를 주는지에 따라 배포 여부 자체가 달라진다.
• 복잡한 모델이 단순한 모델보다 2% 나은 정도라면, 반나절이면 배포되는 단순한 모델이 사업적으로 더 낫다.
• 모델은 한 시점의 세상을 학습한 결과물이라 반드시 낡는다. 모니터링과 갱신 전략 없이 '한 번 올려두고 잊는' 방식은 성립하지 않는다.

쉽게 이해하기

한 개발자 콘퍼런스 강연에서 9년 경력의 머신러닝 엔지니어가 자신의 실패담으로 발표를 시작한다. 발표자는 소셜미디어 데이터를 분석해 핵심 고객층이 무엇을 이야기하는지 요약해 주는 토픽 모델을 만들었고, 업계 표준 지표로는 성능이 좋았다. 그러나 그 코드는 실험 환경 밖으로 나가지 못했고, 발표자는 이를 '모델 연옥'이라고 부른다.

실패의 원인은 두 가지였다. 하나는 정작 그 모델을 쓸 팀과 한 번도 이야기하지 않았다는 것이다. 그 팀에는 더 시급한 기술적 과제가 있었고, 이 프로젝트를 확장할 시간과 예산을 쓸 이유가 없었다. 다른 하나는 데이터 비용이었다. 작업 한 달 전쯤 해당 소셜미디어 플랫폼이 API 데이터 과금 정책을 바꾸면서, 사소했던 비용이 다음 분기 예산의 큰 항목으로 바뀌어 있었다.

발표자는 이를 일반화해 좋은 모델이 실패하는 두 가지 큰 패턴을 제시한다. 첫째는 업무 범위가 제대로 정의되지 않은 경우, 둘째는 시간이 흐르며 세상이 바뀌는 경우다. 그래서 강연의 전반부는 프로젝트 범위 설정 절차에, 후반부는 배포 이후의 모니터링과 드리프트 대응에 할애된다.

범위 설정은 네 단계로 제시된다. 이해관계자와 최종 사용자를 식별하고 풀어야 할 문제와 성공 기준을 정의하는 단계, 예산·연산·일정 같은 제약과 잘못된 예측의 위험을 파악하는 단계, 이미 시도된 해법을 조사하고 최소 기능 제품을 정하는 단계, 마지막으로 유지보수와 모니터링을 계획하는 단계다. 발표자는 각 단계마다 '이것이 사업 목표에 기여하는가'라는 질문으로 되돌아오라고 권한다.

후반부는 모델이 낡는 방식을 유형별로 나눈다. 입력과 예측 대상 사이의 관계가 바뀌는 개념 드리프트, 입력 분포 자체가 달라지는 데이터 드리프트, 예측 대상의 분포가 변하는 라벨 드리프트, 그리고 팬데믹처럼 세상이 급격히 달라지는 경우다. 대응책으로는 피처 재설계, 재학습, 알고리즘 교체, 그리고 마지막으로 모델을 은퇴시키는 선택지가 제시된다.

주요 인사이트

• '좋아 보이는 최신 기술을 써 보고 싶다'는 동기로 시작한 프로젝트는 매일 조금씩 실제 필요에서 멀어진다. 발표자는 자신이 그랬다고 인정하며, 매 단계마다 사업 가치로 되돌아오는 습관을 대안으로 제시한다.
• 비기술 이해관계자는 스스로 필요하다고 생각하는 것과 실제로 필요한 것이 다른 경우가 많다. 무엇이 궁금한지, 시간을 많이 잡아먹는 수작업이 무엇인지 묻는 질문이 더 나은 출발점이 된다.
• '분위기로 평가하기'는 위험하다. 긍정적인 반응 몇 건을 보고 잘 되고 있다고 판단하면, 모델의 기여를 수치로 말할 수 없고 유지 비용도 정당화할 수 없다.
• 조용히 실패하는 파이프라인이 가장 위험하다. 발표자는 테이블 갱신이 오류 없이 그냥 넘어가 2주 뒤 이해관계자의 제보로 알게 된 경험을 공유한다. 실패 지점을 미리 파악하고 알림을 붙여야 한다.
• 예측 자체가 세상에 개입하기 때문에 모델이 변하기도 한다. 구매 가능성이 높은 고객에게 추가 알림을 보내는 순간 고객 행동이 달라지고, 그 결과 모델의 성능 해석도 흔들린다.

자주 묻는 질문

관련 AI 소식