머신러닝 실전 워크플로 (1) - 문제 정의: 비즈니스 문제를 ML 문제로

머신러닝 실전 워크플로 시리즈의 1편입니다. 0편의 소개에 이어, 프로젝트의 출발점인 문제 정의부터 시작합니다.

모델보다 먼저 정해야 하는 것

프로젝트가 실패하는 자리는 대개 모델링이 아닙니다. 애초에 잘못 정의된 문제를 붙들고 몇 주를 쓴 뒤에야 그 사실을 알게 됩니다. 지표가 비즈니스와 어긋나 있거나, 예측을 해도 아무 결정으로 이어지지 않거나, 필요한 레이블이 데이터에 없는 경우입니다. 이 단계가 푸는 문제는 하나입니다. 무엇을, 왜 예측하는지 확정하는 것입니다.

문제 정의는 다음 다섯 가지 질문으로 정리됩니다. 이 질문들에 답하지 못하면 코드를 짜지 않는 편이 낫습니다.

• 이건 정말 ML로 풀 문제인가
• 무엇을 예측하고(타깃), 그 예측으로 어떤 결정을 내리는가(action)
• 성공을 무엇으로 측정하는가(오프라인 지표와 비즈니스 지표)
• 무엇을 이기면 성공인가(베이스라인)
• 그 예측에 필요한 데이터와 레이블이 실제로 있는가

이건 정말 ML로 풀 문제인가

ML은 규칙을 명시하기 어려운 문제에 씁니다. 입력과 출력의 관계가 복잡하고 예외가 많아서 사람이 조건문으로 다 적을 수 없을 때, 데이터에서 그 관계를 배우게 하는 것이 ML입니다. 반대로 관계가 단순하고 명확하면 ML은 과한 도구입니다.

신용카드 한도 초과 여부는 잔액과 한도를 비교하면 끝입니다. 여기에 분류 모델을 붙이는 것은 불필요한 복잡성만 늘립니다. 규칙 몇 줄로 되는 일을 모델로 감싸면, 학습 데이터, 재현 환경, 서빙, 모니터링까지 이 시리즈의 나머지 부담을 전부 떠안게 됩니다. 얻는 것은 없이 유지비만 커집니다.

판단 기준은 세 가지입니다. 규칙으로 정확히 기술되지 않을 만큼 패턴이 복잡한가, 그 패턴을 담은 데이터가 충분히 있는가, 완벽하지 않은 예측이라도 가치가 있는가. 세 가지가 모두 참일 때 ML이 제값을 합니다. 셋 중 하나라도 아니면 규칙 기반이나 통계 요약으로 먼저 시도하는 편이 빠르고 안전합니다.

ML을 먼저 정하고 문제를 끼워 맞추면 안 된다. “ML로 뭔가 해보자”가 아니라 “이 결정을 더 잘 내리고 싶은데, 그 앞에 예측이 필요한가”의 순서로 접근한다. 예측이 필요 없으면 모델도 필요 없다.

타깃과 결정을 연결한다

예측 자체는 목적이 아닙니다. 예측은 더 나은 결정을 내리기 위한 재료입니다. 그래서 문제 정의의 핵심은 타깃(무엇을 예측하는가)과 action(그 예측으로 무엇을 하는가)을 한 문장으로 잇는 것입니다. 이 연결이 끊기면, 아무리 정확한 모델도 쓸 데가 없습니다.

타깃을 정할 때는 예측 시점을 함께 못 박아야 합니다. “이탈할 고객”이라는 타깃은 모호합니다. “다음 30일 안에 이탈할 고객”으로 시점을 붙이면, 그 예측으로 이번 주에 리텐션 쿠폰을 보낼 대상을 고른다는 action이 따라옵니다. 예측 대상과 예측 시점, 이어지는 결정이 하나로 묶여야 타깃이 확정됩니다.

action이 정해지면 문제 유형도 자연히 따라옵니다. 대상을 고르거나 자르는 결정이면 분류, 양이나 수요를 채워 넣는 결정이면 회귀가 됩니다. 유형을 먼저 고르고 문제를 맞추는 게 아니라, 내릴 결정에서 유형이 도출되는 순서입니다. 분류와 회귀의 갈림과 각각의 평가 방식은 기초 시리즈의 분류 지표와 회귀 지표에서 다뤘습니다.

성공 지표: 오프라인 지표와 비즈니스 지표

성공을 무엇으로 재는지 정하지 않으면, 모델이 좋아졌는지 나빠졌는지도 말할 수 없습니다. 지표는 두 층으로 나뉩니다. 이 둘을 구분하고, 동시에 서로 연결하는 것이 이 절의 요점입니다.

오프라인 지표는 모델을 데이터로 평가하는 숫자입니다. 회귀면 MAE나 RMSE, 분류면 정밀도, 재현율, AUC 같은 것입니다. 학습 중에 바로 계산되고 모델을 고르는 기준이 됩니다. 비즈니스 지표(KPI)는 그 예측이 실제로 만든 성과입니다. 대기 시간, 전환율, 매출, 이탈률 같은, 조직이 원래 신경 쓰던 숫자입니다.

문제는 오프라인 지표가 좋아졌다고 비즈니스 지표가 반드시 따라오지는 않는다는 점입니다. RMSE를 0.1 낮췄는데 매출은 그대로일 수 있습니다. 그래서 문제 정의 단계에서 둘을 잇는 가설을 세워야 합니다. “예측 오차가 줄면 어떤 결정이 나아지고, 그 결정이 어떤 KPI를 움직이는가”를 한 줄로 적을 수 있어야 합니다. 이 연결이 명확할수록, 나중에 오프라인 지표 하나를 대표로 골라 최적화하는 근거가 생깁니다.

예를 들어 수요 예측이라면 이렇게 잇습니다. 시간당 수요 예측의 MAE가 줄면(오프라인), 공급을 수요에 맞게 미리 배치해(결정), 손님을 놓치는 비율이 줄어든다(KPI). 이 문장이 서면 대표 오프라인 지표는 MAE로 정해집니다.

베이스라인을 먼저 정한다

모델 점수 하나만으로는 그 모델이 좋은지 알 수 없습니다. RMSE 8이라는 숫자는 그 자체로 의미가 없습니다. 비교 대상이 있어야 의미가 생깁니다. 그 비교 대상이 베이스라인입니다. 베이스라인은 모델 없이, 혹은 가장 단순한 규칙으로 얻는 성능입니다. 개선은 오직 이 기준 대비로만 말할 수 있습니다.

베이스라인은 문제 유형에 맞춰 단순하게 잡습니다. 회귀면 과거 평균이나 직전 값, 분류면 다수 클래스로 전부 찍기, 시계열이면 지난 주기의 같은 시점 값(계절 나이브)이 흔한 출발점입니다. 중요한 건 정교함이 아니라, 모델이 정말 이걸 넘는지 확인할 기준선을 먼저 손에 쥐는 것입니다.

계절성이 있는 수요 예측이라면 “지난주 같은 요일, 같은 시간대 값을 그대로 예측”이 강력한 베이스라인입니다. 코드는 한 줄입니다.

import pandas as pd

# y: 시각을 인덱스로 하는 시간당 승차 건수 시계열
y = rides["count"]

# 베이스라인: 168시간(7일) 전 값을 그대로 예측하는 계절 나이브
baseline_pred = y.shift(24 * 7)

mae = (y - baseline_pred).abs().mean()   # 모델이 넘어야 할 기준선. 이 숫자보다 못하면 모델은 무의미
print(f"baseline MAE = {mae:.2f}")

이 MAE보다 나은 모델만 가치가 있습니다. 복잡한 모델이 계절 나이브를 못 넘는 경우는 실제로 흔합니다. 베이스라인을 건너뛰면 그 사실을 영영 모른 채, 넘지도 못한 기준선 위에서 하이퍼파라미터만 튜닝하게 됩니다. 베이스라인과 누수 없는 평가를 함께 세우는 방법은 뒤의 7편에서 이어갑니다.

데이터와 레이블이 실제로 있는가

마지막 질문이 가장 자주 무시되고, 가장 뼈아프게 돌아옵니다. 타깃을 정하고 지표를 세워도, 그 타깃의 정답(레이블)이 데이터에 없으면 지도학습은 시작조차 못 합니다. 문제 정의 단계에서 데이터 존재 여부를 확인하지 않으면, 파이프라인을 다 짜고 학습 직전에 레이블이 없다는 걸 발견하게 됩니다.

확인할 것은 두 가지입니다. 첫째, 타깃 레이블이 있는가. “다음 30일 내 이탈”을 예측하려면 과거 고객들이 실제로 이탈했는지가 기록돼 있어야 합니다. 둘째, 예측 시점에 쓸 수 있는 입력만으로 그 레이블을 맞힐 수 있는가. 예측하는 순간에는 존재하지 않는 값을 특성으로 넣으면 학습 점수만 좋고 배포하면 무너집니다. 이 함정이 데이터 누수이고, 기초 시리즈의 누수와 파이프라인 편에서 자세히 다뤘습니다.

레이블을 얻는 비용도 이때 따져야 합니다. 레이블이 자동으로 쌓이는 문제(과거 수요는 시간이 지나면 그냥 집계됨)와 사람이 일일이 달아야 하는 문제(악성 리뷰 여부)는 프로젝트 난이도가 다릅니다. 레이블이 없거나 비싸면, 문제를 레이블이 있는 형태로 다시 정의하거나 규칙 기반으로 후퇴하는 것이 정직한 선택입니다.

NYC 택시로 보는 문제 정의

이 다섯 질문을 실제 데이터 하나에 적용한 것이 NYC 택시 파이프라인의 설계 편입니다. 거기서는 문제를 “각 존에서 다음 1시간 승차 건수를 예측”으로 정의합니다. 위의 질문에 그대로 대입해 보면 정의가 왜 그렇게 잡혔는지 보입니다.

• ML 문제인가: 시간, 요일, 날씨, 지역이 얽힌 수요 패턴은 규칙으로 적기 어렵고, 완벽하지 않은 예측도 배차에 도움이 됩니다. ML이 제값을 하는 조건입니다.
• 타깃과 결정: 타깃은 존별 다음 1시간 승차 건수, action은 그 수요가 높을 곳으로 차량을 미리 배치하는 것입니다. 양을 채우는 결정이므로 회귀 문제가 됩니다.
• 지표 연결: 예측 MAE가 줄면 배차가 수요에 맞고, 그 결과 손님 대기 시간과 놓친 호출이 줄어듭니다. 대표 오프라인 지표는 MAE로 정해집니다.
• 베이스라인: 위 코드의 계절 나이브가 첫 기준선입니다. 모델 비교 편에서 이 기준선 위에 LightGBM과 신경망을 올려 개선폭을 잽니다.
• 데이터와 레이블: 과거 승차 기록은 공개 데이터로 존재하고, 시간이 지나면 실제 건수가 그대로 레이블이 됩니다. 레이블 비용이 낮은, 시작하기 좋은 문제입니다.

문제 정의가 이렇게 서면, 다음 단계인 프로젝트 구조와 데이터 준비가 무엇을 향해 가는지 분명해집니다.

정리

질문	한 줄 요약
ML로 풀 문제인가	규칙으로 적기 어렵고, 데이터가 있고, 불완전한 예측도 가치 있을 때만 ML을 쓴다
타깃과 결정	타깃은 예측 시점까지 못 박고, 그 예측으로 내릴 결정(action)과 한 문장으로 잇는다
문제 유형	유형을 먼저 고르지 않는다. 내릴 결정에서 분류인지 회귀인지가 도출된다
오프라인 지표	모델을 데이터로 재는 숫자(MAE, AUC 등). 대표 하나를 골라 최적화한다
비즈니스 지표	예측이 만든 실제 성과(대기 시간, 전환율). 오프라인 지표와 잇는 가설을 세운다
베이스라인	단순 규칙이나 과거 평균으로 먼저 기준선을 잡는다. 개선은 이 대비로만 의미 있다
데이터와 레이블	타깃 레이블이 있고, 예측 시점 입력만으로 맞힐 수 있는지 먼저 확인한다

문제가 정의되면 이제 코드를 담을 그릇이 필요합니다. 다음 편은 재현 가능한 프로젝트 구조와 환경을 세웁니다.

다음 글: 머신러닝 실전 워크플로 (2) - 프로젝트 구조와 재현성