프로젝트 범위 설정: 문제와 성공 기준 정의
코드를 작성하기 전에 예측 대상, 성공 지표, 데이터 원천, 배포 제약 조건을 명시한 한 페이지 분량의 프로젝트 헌장을 작성합니다.
프로젝트 범위 설정: 문제와 성공 기준 정의은(는) CoddyKit의 무료 Machine Learning Academy 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Machine Learning Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Machine Learning Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.
Why Scoping Is the Most Important Step
The single most common reason ML projects fail is not a poorly chosen algorithm — it is a poorly defined problem. Project scoping translates a vague business need ('we want to use AI') into a precise, measurable specification that guides every subsequent technical decision. A well-scoped project defines the prediction target, success criteria, data requirements, and deployment constraints before writing a single line of modelling code.
Choosing the Right ML Formulation
The first scoping decision is the ML task type. Ask: is the output a number (regression), a category (classification), a ranking (learning to rank), a cluster (unsupervised), or a sequence (NLP/time-series)? Each leads to different algorithms, data requirements, and metrics. For example, 'predict customer churn' is a binary classification problem, not a regression problem, even though the business ultimately cares about revenue.
# Scoping checklist — ML task type
questions = [
'What is the exact output the model should produce?',
'Is the output a number (regression) or a category (classification)?',
'Do we need probabilities, or just labels?',
'Is there a natural ordering in the labels (ordinal vs nominal)?',
'Is this supervised (labelled data exists) or unsupervised?',
'Is time ordering important (time-series)?'
]
for q in questions:
print('•', q)Defining the Prediction Target
The prediction target (label or dependent variable) must be defined unambiguously. 'Will this customer churn?' is ambiguous: within what time window? Using what definition of churn (cancellation, inactivity, refund)? A precise target definition might be: 'will the customer not make any purchase in the 90 days following their last purchase?' Each word matters because it determines which rows in the database become training examples.
# Example: formalising target definition in code
import pandas as pd
def label_churn(df, observation_date, prediction_window_days=90):
'''
Label a customer as churned (1) if they made no purchase
in the prediction_window_days after observation_date.
'''
cutoff = pd.Timestamp(observation_date)
window_end = cutoff + pd.Timedelta(days=prediction_window_days)
churned = (
df.groupby('customer_id')['purchase_date']
.apply(lambda dates: not any((dates > cutoff) & (dates <= window_end)))
.reset_index(name='churned')
)
return churnedIdentifying Data Sources and Feasibility
After defining the target, audit available data. Ask: does labelled historical data exist? How far back does it go — is that enough training examples? Are the features available at prediction time (not only after the event)? A feature that is only recorded after the outcome (e.g., 'complaint submitted') is a data leakage risk. Map each candidate feature to its source, collection frequency, and availability latency before committing to it.
# Data audit template
data_sources = [
{'feature': 'days_since_last_purchase', 'source': 'orders DB', 'latency_hours': 1, 'leakage_risk': False},
{'feature': 'total_spend_90d', 'source': 'orders DB', 'latency_hours': 1, 'leakage_risk': False},
{'feature': 'support_tickets_opened', 'source': 'CRM', 'latency_hours': 24, 'leakage_risk': False},
{'feature': 'refund_requested', 'source': 'finance DB', 'latency_hours': 1, 'leakage_risk': True}
]
import pandas as pd
audit = pd.DataFrame(data_sources)
print(audit)
print('\nFeatures with leakage risk:')
print(audit[audit['leakage_risk'] == True]['feature'].tolist())Setting Quantitative Success Criteria
Vague success criteria ('the model should be accurate') make projects impossible to evaluate. Success criteria must be specific, measurable, achievable, relevant, and time-bound (SMART). Define a primary metric (e.g., recall ≥ 0.80 for fraud detection), a secondary metric (precision ≥ 0.70), and a business metric (reduce churn losses by 15% within 6 months). These determine when to launch and when to retrain.
# Formalised success criteria
success_criteria = {
'primary_metric': {
'name': 'recall (churn class)',
'threshold': 0.80,
'rationale': 'Missing a churner costs more than a false alert'
},
'secondary_metric': {
'name': 'precision (churn class)',
'threshold': 0.60,
'rationale': 'Intervention budget: can only contact 40% of flagged customers'
},
'business_metric': {
'name': 'retained revenue lift',
'threshold': '+15% over no-model baseline',
'measurement': 'A/B test over 90 days post-launch'
}
}
for metric, spec in success_criteria.items():
print(f'{metric}: {spec}')Baseline Performance: The Floor to Beat
Before building any model, define a baseline — the simplest reasonable solution against which all models will be compared. For classification, the baseline is typically a DummyClassifier predicting the majority class or random predictions weighted by class frequency. For regression it is predicting the mean. Any model that cannot outperform this baseline offers zero business value and should not be deployed.
from sklearn.dummy import DummyClassifier
from sklearn.metrics import classification_report
import numpy as np
# Simulate imbalanced dataset (10% churn rate)
np.random.seed(42)
y = np.random.choice([0, 1], size=1000, p=[0.9, 0.1])
# Majority-class baseline
dummy = DummyClassifier(strategy='most_frequent')
dummy.fit(np.zeros((1000, 1)), y) # features irrelevant for dummy
y_dummy = dummy.predict(np.zeros((1000, 1)))
print(classification_report(y, y_dummy, target_names=['retained', 'churned']))Deployment Constraints: Latency and Throughput
A model that is 95% accurate but takes 10 seconds per prediction is useless in a real-time recommendation system. Deployment constraints must be captured during scoping: latency (max time per prediction), throughput (predictions per second), memory footprint (mobile vs cloud), and update frequency (retraining every day vs every month). These constraints often rule out entire families of algorithms before any code is written.
# Deployment constraint spec
deployment = {
'serving_mode': 'batch (nightly scoring of all active customers)',
'max_latency_ms': None, # batch: no real-time constraint
'throughput_rps': None,
'memory_budget_mb': 512, # must run on a single EC2 t3.medium
'retraining_frequency': 'weekly',
'max_model_size_mb': 100,
'explainability_required': True,
'regulatory_audit_trail': True
}
for k, v in deployment.items():
print(f'{k}: {v}')Ethical and Legal Review Upfront
Before committing to a project, assess ethical and legal risks. Ask: does the model affect individuals' access to services, employment, or credit? Are protected attributes (race, gender, age) either directly present or recoverable from proxies? Are there GDPR, CCPA, or sector-specific regulations (HIPAA for healthcare, FCRA for credit) that apply? Identifying these issues at scoping time costs minutes; discovering them post-deployment can cost millions and destroy user trust.
# Ethics and legal checklist
ethics_checklist = [
('High-stakes decisions on individuals?', True, 'churn model triggers retention offers, low risk'),
('Protected attributes in data?', True, 'age and region present — must audit for proxy bias'),
('GDPR data minimisation required?', True, 'only collect features needed for prediction'),
('Right to explanation required?', True, 'EU AI Act high-risk? Check with legal team'),
('Regulatory filing required?', False, 'B2C retention model, not financial services')
]
for question, answer, note in ethics_checklist:
print(f'[{"YES" if answer else "NO"}] {question} -> {note}')The One-Page Project Charter
All scoping decisions should be captured in a concise project charter — a single-page document that stakeholders, engineers, and data scientists can all read and agree on before work begins. The charter specifies: problem statement, ML task type, prediction target definition, data sources, success metrics, baseline, deployment constraints, and ethical considerations. It becomes the ground truth for scope creep discussions throughout the project.
charter_template = '''
PROJECT CHARTER
===============
Problem: Identify customers at risk of churning before they cancel.
ML Task: Binary classification (churned=1, retained=0)
Target: No purchase in 90 days after monthly observation date
Data Sources: orders DB, CRM (support tickets), product analytics
Primary Metric: Recall >= 0.80 on held-out test set
Secondary Metric: Precision >= 0.60
Baseline: DummyClassifier majority-class (recall = 0, precision = NaN)
Deployment: Batch scoring, weekly retraining, 100 MB model limit
Ethical Flags: Audit for age/region proxy bias; GDPR minimisation
Timeline: MVP in 6 weeks; A/B test for 90 days; review in month 5
'''
print(charter_template)Iterating on the Scope
Scoping is not a one-time activity. After initial data exploration (EDA) you may discover the label is impossible to compute historically, the class imbalance is worse than expected, or the most informative feature has too high a latency for real-time serving. Plan for at least one scope revision after EDA and one after a baseline model run. Version the project charter with dates to track how the problem definition evolved.
# Charter revision log (tracked in version control)
revision_log = [
{'version': 'v1.0', 'date': '2026-06-01',
'change': 'Initial scope: 30-day churn window'},
{'version': 'v1.1', 'date': '2026-06-05',
'change': 'EDA: 30-day window has only 4% churn rate (too imbalanced); widened to 90 days'},
{'version': 'v1.2', 'date': '2026-06-10',
'change': 'Baseline run: dummy recall=0, real-time serving infeasible (10s latency); switched to batch'}
]
for rev in revision_log:
print(f"{rev['version']} ({rev['date']}): {rev['change']}")From Charter to Actionable Plan
A completed charter drives a concrete work plan. Break the project into phases: Phase 1 — EDA and data quality audit; Phase 2 — feature engineering and baseline; Phase 3 — model selection and tuning; Phase 4 — evaluation and fairness audit; Phase 5 — deployment, monitoring, and A/B test. Assign owners and deadlines to each phase. This structure is the same whether your timeline is two weeks or six months.
project_phases = [
('Phase 1', 'EDA + data quality audit', '2026-06-01', '2026-06-07'),
('Phase 2', 'Feature engineering + baseline model', '2026-06-08', '2026-06-14'),
('Phase 3', 'Model selection + hyperparameter tuning', '2026-06-15', '2026-06-21'),
('Phase 4', 'Evaluation, fairness audit, model card', '2026-06-22', '2026-06-25'),
('Phase 5', 'Deploy + A/B test + monitoring setup', '2026-06-26', '2026-07-31')
]
print(f'{'Phase':8} | {'Deliverable':42} | Start | End')
print('-' * 80)
for phase, desc, start, end in project_phases:
print(f'{phase:8} | {desc:42} | {start} | {end}')Quick Check
Test your understanding of Machine Learning with Python concepts from this lesson.
Lesson Recap
In this lesson you learned: project scoping translates business needs into precise ML specifications before any code is written, success criteria must be quantitative and tied to both model metrics and business outcomes, and deployment constraints, ethical risks, and data feasibility must be assessed upfront to prevent expensive pivots later. Next up we dive into data wrangling and exploratory data analysis to understand the raw dataset and uncover quality issues.
AI 튜터와 함께 Python을(를) 배우세요 — 무료
브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.
- 코스
- 30
- 레슨
- 120
자주 묻는 질문
“프로젝트 범위 설정: 문제와 성공 기준 정의” 강의는 무료인가요?
네 — “프로젝트 범위 설정: 문제와 성공 기준 정의” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Machine Learning Academy 강의 전체를 잠금 해제할 수 있습니다. Machine Learning Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
“프로젝트 범위 설정: 문제와 성공 기준 정의”에서 뭘 배우나요?
코드를 작성하기 전에 예측 대상, 성공 지표, 데이터 원천, 배포 제약 조건을 명시한 한 페이지 분량의 프로젝트 헌장을 작성합니다. 브라우저에서 직접 실행하는 실습 코드로 Machine Learning Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Machine Learning Academy을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Machine Learning Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.
“프로젝트 범위 설정: 문제와 성공 기준 정의” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Machine Learning Academy 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Machine Learning Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- 프로젝트 범위 설정: 문제와 성공 기준 정의
- 데이터 정제와 탐색적 데이터 분석
- 모델 선택 토너먼트: 다섯 가지 알고리즘 비교
- 최종 모델 패키징, 문서화 및 발표