Business Understanding — 문제 정의와 ROI 계산

CRISP-DM Phase 1: 비즈니스 문제를 데이터 마이닝 태스크로 변환하는 원칙

데이터를 만지기 전에 반드시 먼저 해야 하는 일이 있다. 비즈니스 문제를 정의하고, 그것이 어떤 데이터 마이닝 태스크로 변환되는지 판단하며, ROI를 추정하는 것이다. CRISP-DM의 첫 번째 단계인 Business Understanding을 체계적으로 다룬다.

Data Science
저자

Kwangmin Kim

공개

2026년 03월 28일

1 개요

데이터 과학 프로젝트에서 가장 흔한 실패 원인은 모델이나 알고리즘의 문제가 아니다. 프로젝트를 시작하기도 전에 이미 잘못된 문제를 풀기로 결정한 경우가 많다.

고객 이탈을 줄이고 싶다는 비즈니스 목표가 있다면, 이것이 곧바로 “이탈 예측 분류 모델을 만들어라”는 데이터 과학 과제가 되는가? 반드시 그렇지는 않다. 이탈 고객을 예측하더라도 그들에게 어떤 행동을 취할지 정의하지 않으면 모델은 쓸모없다. 예측의 정확도를 높이는 것이 목표인지, 개입 비용 대비 기대 수익을 최대화하는 것이 목표인지에 따라 문제 공식화 자체가 달라진다.

이 포스트는 CRISP-DM의 첫 번째 단계인 Business Understanding — 비즈니스 문제를 정의하고, 그것을 데이터 마이닝 태스크로 변환하며, ROI를 추정하는 과정을 다룬다.


2 CRISP-DM과 Business Understanding의 위치

CRISP-DM(Cross Industry Standard Process for Data Mining)은 데이터 마이닝 프로세스의 표준 절차를 6단계로 정의한다 (Provost & Fawcett, 2013, Ch.2):

단계 이름 핵심 질문
1 Business Understanding 무엇을 풀어야 하는가?
2 Data Understanding 어떤 데이터가 있으며 어떤 한계가 있는가?
3 Data Preparation 분석 가능한 형태로 어떻게 변환할 것인가?
4 Modeling 어떤 알고리즘·모델을 적용할 것인가?
5 Evaluation 결과가 비즈니스 목표를 충족하는가?
6 Deployment 실제 환경에서 어떻게 사용할 것인가?

CRISP-DM의 핵심 특성은 반복적(iterative) 구조다. 단계가 순서대로 진행되지 않는다. Evaluation에서 문제 정의가 잘못됐다는 것을 발견하면 Business Understanding으로 돌아간다. Deployment 이후에도 새로운 인사이트를 바탕으로 다시 첫 단계로 돌아오는 것이 일반적이다.

핵심 원칙: 데이터 마이닝은 소프트웨어 엔지니어링이 아니다

CRISP-DM이 소프트웨어 개발 주기처럼 보인다는 이유로 동일하게 관리하는 것은 실수다. 데이터 마이닝은 본질적으로 탐색적 연구에 가깝다. 결과의 불확실성이 높고, 한 단계의 발견이 전체 문제 정의를 바꿀 수 있다. 고정된 마일스톤으로 관리하면 중간에 발견된 중요한 인사이트를 무시하게 된다 (Provost & Fawcett, 2013, Ch.2).


3 문제 정의: 비즈니스 문제 → 데이터 마이닝 태스크 변환

Business Understanding 단계의 가장 중요한 활동은 비즈니스 문제를 하나 이상의 데이터 마이닝 태스크로 변환하는 것이다. Provost & Fawcett (2013, Ch.2)는 데이터 마이닝 태스크를 9가지 유형으로 분류한다.

3.1 데이터 마이닝 태스크 9가지

1. 분류 (Classification)

이산적(discrete) 클래스 집합 중 한 클래스를 예측한다.

  • 예: “이 고객은 서비스 해지를 할 것인가?” (Yes / No)
  • 예: “이 이메일은 스팸인가?” (Spam / Ham)
  • 분류 모델은 새 개체가 주어졌을 때 클래스를 결정하는 규칙이나 함수를 출력한다
  • 관련 과제: 클래스 확률 추정(class probability estimation) — 클래스 자체가 아니라 각 클래스에 속할 확률을 추정하는 것 (예: 해지 확률 0.73)

2. 회귀 (Regression)

연속적(continuous) 수치값을 예측한다.

  • 예: “이 고객은 한 달에 데이터를 얼마나 사용할 것인가?”
  • 예: “내일 주식 가격은 얼마인가?”
  • 분류가 “그럴 것인가(whether)”를 예측한다면, 회귀는 “얼마나(how much)”를 예측한다

3. 유사도 매칭 (Similarity Matching)

데이터로 묘사된 개체들 간의 유사도를 기반으로 비슷한 개체를 찾는다.

  • 예: “우리의 최우수 기업 고객과 유사한 잠재 고객은 누구인가?” (IBM 사례)
  • 예: 상품 추천 — “이 사람과 유사한 취향을 가진 사람들은 무엇을 구매했는가?”
  • 유사도 개념은 클러스터링, 분류, 회귀의 기반이 된다

4. 클러스터링 (Clustering)

특정 목적 없이 개체들을 유사도에 따라 자연스러운 그룹으로 묶는다.

  • 예: “우리 고객은 자연스럽게 어떤 세그먼트로 나뉘는가?”
  • 목적 변수(target)가 지정되지 않는다는 점에서 비지도학습(unsupervised)
  • 발견된 클러스터는 이후 비즈니스 의사결정(어떤 상품을 개발할 것인가)의 입력이 된다

5. 공출현 그룹화 (Co-occurrence Grouping)

거래(transaction)를 기반으로 함께 등장하는 개체 간의 연관을 찾는다.

  • 예: “어떤 상품들이 함께 구매되는가?” (장바구니 분석)
  • 예: 슈퍼마켓 데이터에서 “간 고기와 핫소스가 기대치보다 훨씬 자주 함께 구매된다”는 패턴 발견
  • 결과에는 공출현 빈도와 놀라움(surprisingness) 통계가 포함된다

6. 프로파일링 (Profiling)

개체, 그룹, 모집단의 전형적인 행동을 특성화한다.

  • 예: “이 고객 세그먼트의 전형적인 휴대폰 사용 패턴은 무엇인가?”
  • 이상 탐지(anomaly detection)에 활용: 정상 행동 프로파일을 벗어나는 경우를 탐지 (신용카드 사기 감지)

7. 링크 예측 (Link Prediction)

데이터 개체 간의 연결을 예측한다.

  • 예: “당신과 Karen은 공통 친구가 10명이다. 친구 추천” (SNS)
  • 예: 영화 추천에서 고객-영화 그래프에 존재하지 않지만 강한 연결이 예상되는 링크를 추정

8. 데이터 축소 (Data Reduction)

대규모 데이터셋을 중요한 정보를 유지하면서 더 작고 다루기 쉬운 형태로 변환한다.

  • 예: 소비자의 방대한 영화 시청 데이터에서 잠재적 장르 선호도를 추출
  • 정보 손실과 통찰 향상 간의 트레이드오프가 핵심이다

9. 인과 모델링 (Causal Modeling)

어떤 사건·행동이 실제로 다른 것에 영향을 미치는지 이해하려 한다.

  • 예: “광고를 본 소비자가 더 많이 구매했다. 광고가 원인인가, 아니면 구매할 사람에게 광고가 도달했을 뿐인가?”
  • A/B 테스트(무작위 대조 실험) 또는 관측 데이터로부터의 인과 추론 방법을 사용한다
  • 모든 인과 결론에는 반드시 가정(assumption)이 수반된다. 어떤 가정을 했는지 항상 명시해야 한다

4 지도학습 vs 비지도학습 판단

비즈니스 문제를 태스크로 변환할 때 가장 먼저 결정해야 할 것은 지도(supervised) 방식을 사용할 것인가, 비지도(unsupervised) 방식을 사용할 것인가다.

기준 지도학습 비지도학습
목적 변수(target) 있음 — 예측할 특정 변수가 지정됨 없음 — 데이터 내 자연적 구조 발견
레이블(label) 역사적 데이터에 결과값이 존재해야 함 불필요
예시 태스크 분류, 회귀, 인과 모델링 클러스터링, 공출현, 프로파일링
결과의 목적성 높음 (특정 목적을 위한 예측) 낮음 (구조 발견, 이후 해석 필요)

지도 방식의 조건: 지도학습을 사용하려면 두 가지가 충족되어야 한다. (1) 예측하고 싶은 목적 변수가 명확히 정의되어야 한다. (2) 그 변수의 값이 역사적 데이터에 존재해야 한다.

레이블 획득이 핵심 데이터 투자 결정이 된다. 신용카드 사기는 고객과 사기범이 별개 인물이므로 레이블이 명확하다. 메디케어 사기는 의료 제공자 자신이 부당 청구를 하므로 신뢰할 수 있는 레이블이 없다. 겉으로 동일해 보이는 “사기 탐지” 문제가 전혀 다른 접근법을 요구하는 이유다.


5 Use Scenario 설계

Business Understanding에서 단순히 “무엇을 예측할 것인가”만 결정하는 것으로 충분하지 않다. 모델 결과가 실제로 어떻게 사용될 것인가까지 설계해야 한다. Provost & Fawcett (2013, Ch.2)는 이를 “use scenario를 신중하게 설계하라”고 강조한다.

MegaTelCo의 이탈 예측 사례로 생각해보자.

잘못된 문제 공식화: “이탈할 고객을 예측하라” - 예측 정확도(accuracy)를 최대화하는 모델을 만든다 - 모델이 이탈할 것으로 예측한 고객에게 일률적으로 특별 혜택을 제공한다 - 문제: 이미 이탈할 의향이 없는 고객에게도 불필요한 비용을 지출한다. 이탈 확률이 낮지만 고객 가치가 매우 높은 경우와 이탈 확률은 높지만 가치가 낮은 경우를 동일하게 취급한다.

올바른 문제 공식화: “한정된 인센티브 예산을 사용하여 예상 이탈 감소 효과를 최대화하라” - 예측해야 하는 것은 단순히 “이탈 여부”가 아니라 “인센티브를 받았을 때 이탈을 중단할 확률” 이다 - 고객 가치(Customer Lifetime Value), 인센티브 비용, 개입 효과를 모두 포함하는 기대값(Expected Value) 프레임워크로 문제를 재공식화한다

기대값 프레임워크 (Expected Value Framework)

비즈니스 문제를 기대값으로 공식화하면 데이터 마이닝 태스크로의 분해가 체계적으로 이루어진다.

\[ \text{기대 이익}(x) = P(\text{이탈 방지} \mid \text{개입}, x) \times V(x) - C(\text{개입}) \]

여기서 \(x\) 는 고객, \(P(\cdot)\) 는 개입 시 이탈 방지 확률, \(V(x)\) 는 고객 생애 가치, \(C\) 는 인센티브 비용이다. 이 공식화는 세 가지 하위 데이터 마이닝 태스크를 드러낸다: - \(P(\text{이탈 방지} \mid \text{개입}, x)\) 추정 → 분류/회귀 - \(V(x)\) 추정 → 회귀 - 개입 효과의 인과 추정 → 인과 모델링 (A/B 테스트)


6 ROI 추정: 데이터 과학 프로젝트 제안 평가

Business Understanding 단계에서 프로젝트 시작 전에 ROI를 추정해야 한다. 근거 없이 시작하면 6개월 뒤에 “이 모델이 실제로 비즈니스에 가치를 주는가”라는 질문에 답할 수 없게 된다.

6.1 데이터 기반 의사결정(DDD)의 가치

데이터 기반 의사결정(Data-Driven Decision-Making, DDD)의 효과는 실증 연구로 뒷받침된다. MIT와 Wharton School의 Brynjolfsson et al. (2011)은 기업의 DDD 수준을 측정하여 다음을 발견했다:

  • DDD 수준 1 표준편차 향상 → 생산성 4-6% 증가
  • 자산 수익률(ROA), 자기자본 수익률(ROE), 자산 활용률, 시장 가치와 모두 양의 상관관계
  • 이 관계는 인과적(causal)으로 보인다 (Provost & Fawcett, 2013, Ch.1)

4-6%가 작아 보일 수 있지만, 대기업에서 이 수치는 수십억 원의 추가 가치를 의미한다.

6.2 프로젝트 타당성 평가 기준

데이터 과학 프로젝트를 시작하기 전에 4가지 축으로 타당성을 평가한다 (Provost & Fawcett, 2013, Ch.13):

평가 축 핵심 질문 좋은 신호
비즈니스 가치 이 문제를 풀면 얼마나 가치가 있는가? 현재 의사결정의 비용·오류가 크다
기술적 타당성 데이터 마이닝으로 이 문제를 풀 수 있는가? 유사 문제의 선례가 있다
데이터 가용성 필요한 데이터가 존재하고 획득 가능한가? 역사 데이터에 목적 변수가 있다
ROI 추정 투자 대비 수익이 합리적인가? 작은 개선도 큰 규모로 반복되면 가치가 크다

6.3 ROI 추정 방법

정확한 ROI를 미리 계산하기 어렵지만, 다음 방식으로 합리적 추정을 할 수 있다.

Step 1: 현재 상태(baseline) 측정

현재 얼마나 비효율적인 의사결정이 이루어지고 있는가?

  • 예: 무작위 발송 프로모션에서 응답률이 1%라면, 나머지 99%에 지출된 비용은 낭비다
  • 기준값 없이는 개선 효과를 측정할 수 없다

Step 2: 모델의 예상 성능 추정

  • 유사 문제의 선행 연구나 파일럿 결과를 참조한다
  • 보수적으로 추정한다. 과대 추정은 프로젝트 실패의 주요 원인이다

Step 3: 개선으로 인한 기대 가치 계산

\[ \text{기대 가치} = \underbrace{(\text{현재 비용} - \text{개선 후 비용})}_{\text{비용 절감}} + \underbrace{(\text{개선 후 수익} - \text{현재 수익})}_{\text{수익 증가}} \]

이 수식이 말하는 것은 간단하다. 데이터 과학 프로젝트의 순이익은 비용 절감과 수익 증가의 합이며, 이 합이 개발·운영 비용보다 클 때만 투자가 정당화된다.

Step 4: 개발 및 운영 비용과 비교

  • 데이터 수집·정제 비용
  • 모델 개발 인건비
  • 인프라·배포 비용
  • 유지 보수·재학습 비용 (종종 간과됨)
ROI 추정의 흔한 실수
  1. 비용 과소 계산: 데이터 준비와 지속적 유지관리 비용을 무시한다
  2. 베이스라인 무시: 현재 “아무것도 안 하는” 수준의 성능을 기준으로 삼지 않는다
  3. 모델 성능 과대 추정: 논문의 SOTA 성능을 실제 비즈니스 환경에서 그대로 기대한다
  4. 배포 후 비용 무시: “모델을 만들면 끝”이라고 생각하지만, 실제로는 배포·모니터링·재학습이 더 큰 비용이다

7 ML 적용 판단 기준

모든 비즈니스 문제가 머신러닝으로 풀어야 하는 것은 아니다. ML을 적용하기에 적합한 조건이 있다. Huyen (2022, Ch.1)은 6가지 조건을 제시한다:

조건 설명
학습 가능성 과거 데이터에서 패턴을 학습할 수 있어야 한다
복잡한 패턴 단순 규칙으로 해결하기 어려운 복잡한 패턴이 있어야 한다
패턴의 존재 데이터에 실제로 패턴이 있어야 한다 (랜덤하지 않아야 한다)
기존 데이터 충분한 역사 데이터가 존재하거나 수집 가능해야 한다
예측 문제로 프레이밍 가능 입력 → 출력 매핑 구조로 문제를 정의할 수 있어야 한다
미래 데이터의 유사성 배포 환경의 데이터가 학습 데이터와 유사한 분포를 가져야 한다

추가적으로, ML이 특히 효과적인 상황은: - 반복적 태스크: 하루에 수백만 번 동일한 유형의 의사결정이 일어난다 - 잘못된 예측 비용이 낮음: 오예측이 치명적이지 않은 경우 (상품 추천이 정확하지 않은 것과 의료 진단이 틀린 것은 다르다) - 대규모 처리 필요: 사람이 하나씩 처리할 수 없는 양의 케이스가 존재한다

조건 적용 예시: 신용카드 부정 거래 탐지

이 6가지 조건을 실제 문제에 대입해보자.

  1. 학습 가능성 — 과거 부정 거래 패턴은 학습 가능하다 (정상 vs 부정 레이블 존재)
  2. 복잡한 패턴 — “금액 > 500만원이면 사기”처럼 단순 규칙으로는 정교한 사기꾼을 잡을 수 없다
  3. 패턴의 존재 — 부정 거래에는 실제 패턴이 있다 (시간대, 지역, 거래 빈도 등)
  4. 기존 데이터 — 수년간의 거래 이력이 쌓여 있다
  5. 예측 문제로 프레이밍 가능 — 입력: 거래 특징 → 출력: 부정 여부 확률
  6. 미래 데이터 유사성 — 주의 필요. 사기 수법이 변하면 분포가 달라진다 → 정기 재학습 필수

6가지 조건을 모두 충족하므로 ML 적용이 적합하다. 반면 “회사 내 직원 수가 50명 미만이면 중소기업으로 분류” 같은 문제는 조건 2(복잡한 패턴 없음)를 충족하지 못해 ML이 과잉이다.

언제 ML을 쓰지 말아야 하는가
  • 간단한 규칙(rule)으로 충분히 해결되는 경우 (예: 나이 >= 18이면 성인)
  • 데이터가 거의 없는 경우
  • 결과 해석과 감사(audit)가 법적으로 필요한 경우 (복잡한 모델은 설명이 어렵다)
  • 문제 자체가 아직 명확히 정의되지 않은 경우 — 이 때는 Business Understanding으로 돌아가야 한다

8 자주 발생하는 실수

8.1 실수 1: 비즈니스 문제와 데이터 마이닝 태스크를 혼동

“고객 세분화를 해달라”는 요청을 받으면 바로 클러스터링 알고리즘을 돌리는 경우가 많다. 그러나 목적이 “이탈 가능성이 높은 고객 그룹 식별”이라면 이것은 지도 분류 문제다. 클러스터링은 목적이 지정되지 않은 탐색적 분석에 적합하고, 지도학습은 특정 목적의 예측에 적합하다.

올바른 순서: 비즈니스 목적 명확화 → 지도/비지도 판단 → 구체적 태스크 유형 결정 → 알고리즘 선택

8.2 실수 2: 타겟 변수를 잘못 정의

예측하고 싶은 것은 “6개월 후에도 고객으로 남아 있는지 여부”인데, 데이터에 “계약 해지 날짜”만 있어서 이를 기준으로 레이블을 만들 수 있다고 생각하는 경우. 그런데 계약 해지 데이터가 2개월까지만 보존되어 있다면 타겟 변수를 만들 수가 없다. 타겟 변수가 실제로 데이터에 존재하는지 확인하는 것이 Business Understanding에서 해결해야 할 핵심 질문이다.

8.3 실수 3: Leakage를 Data Preparation 단계까지 발견하지 못함

Business Understanding 단계에서 use scenario를 설계할 때, 의사결정 시점에 어떤 데이터가 실제로 사용 가능한지를 명확히 해야 한다. 역사 데이터에는 의사결정 이후에 생성된 정보가 포함되어 있을 수 있다. 이를 미리 파악하지 않으면 Data Preparation 또는 심지어 Deployment 단계에서야 모델이 현실에서 작동하지 않는다는 것을 발견하게 된다.


9 Target Variable의 정밀 정의

지도학습에서 Business Understanding 단계의 가장 결정적인 작업은 타겟 변수를 정밀하게 정의하는 것이다. 대부분의 실패는 여기서 시작된다.

9.1 좋은 타겟 변수의 조건

조건 1: 의사결정 시점에 예측 가능해야 한다

역사 데이터에 타겟 정보가 있더라도, 그 값이 의사결정 후에야 알 수 있는 경우 예측이 불가능하다.

  • 잘못된 예: 웹사이트 방문자의 “세션 내 총 방문 페이지 수”로 조기 이탈 예측
    • 세션이 끝나야 총 방문 페이지 수를 알 수 있으므로, 세션 중간에 이 변수를 사용할 수 없다
  • 올바른 예: “첫 2페이지 방문 후 이탈 여부”를 2페이지 방문 직후에 예측하는 문제로 재정의

조건 2: 비즈니스 의사결정과 직결되어야 한다

예측한 결과로 무엇을 할 것인지와 연결되어야 한다.

  • “이탈할 것인가?”보다 “이탈 방지 인센티브를 줄 때 잔류할 것인가?”가 더 직접적인 타겟이다
  • 두 번째 타겟은 인과 추론 문제를 포함하므로 A/B 테스트 데이터가 필요하다

조건 3: 획득 비용이 정당화되어야 한다

레이블을 획득하는 데 드는 비용이 모델의 기대 가치보다 크면 안 된다.

  • 의료 이미지 레이블링: 전문의 1인당 1시간 = 수백만 원
  • 이 비용을 정당화할 만큼 모델의 기대 가치가 있는가를 Business Understanding 단계에서 판단해야 한다

9.2 타겟 변수 정의가 바뀌면 모든 것이 바뀐다

동일한 비즈니스 목표(“이탈을 줄여라”)도 타겟 변수를 어떻게 정의하는가에 따라 완전히 다른 데이터 마이닝 프로젝트가 된다:

타겟 정의 필요 데이터 방법론
계약 만료 후 해지 여부 (Yes/No) 계약 만료 이력 이진 분류
해지까지 남은 기간 계약 기간 전체 이력 생존 분석
인센티브 개입 시 잔류 확률 A/B 테스트 데이터 인과 추론 + 분류
해지까지 남은 기간 (생존 분석) 계약 기간 전체 이력 생존 분석(survival analysis, 시간에 따른 사건 발생 확률 모델링)
고객 생애 가치 변화 결제 이력 전체 회귀

10 데이터 가용성 평가

Business Understanding과 Data Understanding은 순환적으로 진행된다. 이상적인 타겟 변수를 정의했더라도, 그에 해당하는 데이터가 없으면 문제 정의를 수정해야 한다.

10.1 데이터 비용-편익 분석

각 데이터 소스는 비용과 편익을 함께 평가한다 (Provost & Fawcett, 2013, Ch.2):

데이터 유형 비용 편익 결정
이미 보유한 내부 DB 매우 낮음 보통 우선 활용
추가 수집이 필요한 내부 데이터 중간 높을 경우 가치 추정 후 결정
외부 데이터 구매 높음 불확실 파일럿 테스트 후 결정
레이블 직접 획득 (전문가 어노테이션) 매우 높음 높음 ROI 계산 필수
새로운 데이터 수집 인프라 구축 극히 높음 장기적으로 높음 별도 프로젝트로 분리

10.2 데이터 부재 시 대안

필요한 데이터가 없을 때 Business Understanding 단계에서 취할 수 있는 대안:

  1. 문제 재정의: 보유한 데이터로 해결 가능한 더 좁은 문제로 축소
  2. 파일럿 우선: 소규모 데이터 수집 실험 후 본 프로젝트 결정
  3. 비지도 접근: 레이블 없이 클러스터링으로 탐색적 분석 후 레이블 필요성 재평가
  4. 프록시 변수 사용: 이상적인 타겟의 대리 변수(proxy)를 사용하되 한계를 명시

11 Business Understanding 체크리스트

앞의 모든 내용을 바탕으로, 실제 프로젝트에서 Business Understanding 단계를 완료했다고 판단하는 기준은 다음 질문들에 답할 수 있을 때다:


12 관련 주제

선행 개념

후속 단계

  • Data Understanding — EDA와 데이터 품질 진단 (예정)
  • Data Preparation — 피처 엔지니어링과 leakage 방지 (예정)

연관 카테고리

Subscribe

Enjoy this blog? Get notified of new posts by email: