이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
실무형 Data Science 포트폴리오는 Notebook에서 모델을 학습하는 데 머물지 않고 비즈니스 문제 정의부터 SQL 추출, Python 정제, EDA, Feature Engineering, 모델 평가, API와 Dashboard 배포, 최종 추천까지 하나의 흐름으로 이어져야 합니다. DoorDash 배달 시간 예측 사례에서는 197,283건의 정제 데이터에서 XGBoost가 테스트 RMSE 875초를 기록했고, 5개 폴드 교차 검증 평균은 883초(±11초)로 나타났습니다. 학습 Pipeline을 joblib으로 저장한 뒤 FastAPI의 /predict 엔드포인트와 Streamlit Dashboard로 연결하면 예측 결과를 실제 사용 가능한 형태로 바꿀 수 있습니다. 마지막에는 높은 busy_dashers_ratio에 대응한 피크 시간대 인력 조정처럼 모델 결과를 사업 의사결정으로 연결해야 하며, 이 전체 생명주기가 여러 개의 미완성 Notebook과 구별되는 포트폴리오의 핵심입니다.
섹션별 상세
채용으로 이어지는 Data Science 포트폴리오는 Notebook에서 모델을 학습하는 데 그치지 않고 비즈니스 문제에서 실행 가능한 추천까지 연결합니다. 이 글은 DoorDash 배달 시간 예측 프로젝트를 하나의 사례로 삼아 문제 정의, SQL 데이터 추출, Python 정제, 탐색, Feature Engineering, 모델링, 평가, API 배포, Dashboard 구축의 아홉 단계를 이어갑니다. 원시 데이터부터 배포된 애플리케이션까지의 흐름을 갖추면 이력서나 단일 Notebook만으로 드러내기 어려운 실무 범위를 포트폴리오에서 확인할 수 있습니다.
비즈니스 문제는 알고리즘 이름이 아니라 실제 운영 결과를 기준으로 정의해야 합니다. DoorDash 사례에서는 주문이 주어졌을 때 배달에 걸리는 시간을 예측하는 질문을 먼저 세우고, 이를 운영 효율성이라는 사업 목표와 연결합니다. 같은 프로젝트라도 XGBoost Regression Demo처럼 모델 중심으로 제목을 붙이는 방식보다 Delivery Time Prediction처럼 결과 중심으로 구성하면 데이터 과학 작업이 해결하려는 의사결정이 분명해집니다.
실무형 데이터셋은 CSV를 조용히 불러오는 대신 데이터베이스에서 분석용 테이블을 만드는 과정을 재현해야 합니다. 예시 SQL은 market_id, created_at, actual_delivery_time, 매장·주문·배달원 관련 열을 선택하고, actual_delivery_time이 비어 있지 않으며 주문 시각보다 늦은 행만 WHERE 조건으로 남깁니다. 실제 환경에서는 주문, 배달원, 매장 테이블의 JOIN과 GROUP BY까지 포함해 불량 행을 제거하고 Python으로 넘길 분석 준비 테이블을 구성한다는 점이 포트폴리오의 실무성을 높입니다.
근거
- DoorDash 프로젝트는 주문 생성 시각과 실제 배달 시각의 차이로 배달 시간을 계산한다. — Python 정제 단계의 delivery_duration_seconds 계산 코드와 출력 표
Python 정제 단계에서는 시각 열을 datetime으로 바꾸고 실제 배달 시각에서 주문 생성 시각을 빼 delivery_duration_seconds라는 타깃을 계산합니다. 이후 배달 시간이 60초에서 3시간 사이인 행만 남기고 결측 타깃을 제거해 비현실적 관측값의 영향을 줄입니다. 정제된 데이터의 상당 부분을 차지하는 반복 작업을 생략하지 않는 태도가 데이터셋을 모델 입력으로 바꾸는 기본 역량을 드러내며, 규모가 커 메모리가 부족할 때는 Polars를 대안으로 사용할 수 있습니다.
근거
- 정제된 데이터에는 197,283건의 기록이 있고 평균 배달 시간은 47.5분, 중앙값은 44.3분이다. — EDA 단계의 delivery_minutes.describe() 출력
EDA는 정제된 데이터에서 예측 대상의 분포와 업무상 변동 요인을 찾는 단계입니다. 이 사례에서는 197,283건의 배달 기록에서 평균 배달 시간이 47.5분, 중앙값이 44.3분, 표준편차가 18.0분이며, 시장별 중앙값은 43.3분에서 46.9분 사이로 나타납니다. 시간대, 시장, 배달원 업무량별 차이를 히스토그램·박스플롯·산점도로 확인하면 이후 Feature Engineering과 모델 해석에 필요한 패턴을 찾을 수 있습니다.
근거
- 11개 원시 열이 범주형 인코딩 이후 22개 모델 준비 특성으로 변환된다. — Feature Engineering 단계의 preprocess.fit_transform(...).shape 출력 (175596, 22)
Feature Engineering은 원시 열을 도메인 지식이 반영된 예측 변수로 바꾸는 과정입니다. 글은 total_busy_dashers를 total_onshift_dashers로 나눈 busy_dashers_ratio와 운전 시간 및 주문 배치 시간을 합친 estimated_non_prep_duration을 만들고, 0으로 나누어 생긴 무한값을 결측으로 치환합니다. market_id와 order_protocol은 OneHotEncoder로 변환하고 수치형 변수는 StandardScaler로 표준화해 11개 원시 열을 22개 모델 입력 특성으로 확장한 뒤 Pipeline에서 동일한 전처리를 반복합니다.
근거
- 테스트 분할에서 XGBoost의 RMSE는 875초로 기준선 1074초와 Ridge 927초보다 낮다. — 모델 구축 단계의 모델별 RMSE 출력 표
모델링은 평균 배달 시간을 내놓는 DummyRegressor를 기준선으로 삼은 뒤 Ridge와 XGBoost를 순차적으로 비교하는 구조입니다. 20% 테스트 분할에서 기준선의 RMSE는 1074초, Ridge는 927초, XGBoost는 875초로 나타나 표 형식의 업무 데이터에서 트리 기반 모델을 선택할 근거가 생깁니다. 기준선보다 나아지지 않는 모델을 초기에 식별하면 복잡한 알고리즘을 무작정 채택하는 대신 입력 변수와 학습 과정을 점검할 수 있습니다.
근거
- 5개 폴드 교차 검증에서 XGBoost의 평균 RMSE는 883초이고 표준편차는 11초다. — 평가 단계의 Fold RMSEs와 CV RMSE 출력
단일 테스트 점수만으로 모델을 평가하지 않고 교차 검증과 기준선 비교를 함께 사용해야 합니다. XGBoost Pipeline을 5개 폴드로 평가한 결과 폴드별 RMSE는 900, 886, 867, 878, 882초였고 평균은 883초, 표준편차는 11초였습니다. 테스트 세트에 맞춰 반복적으로 튜닝하면 낙관적으로 왜곡된 점수가 나오므로 테스트 세트를 최종 검증용으로 보존하고, 분류 문제라면 accuracy와 함께 precision, recall, F1을 기록해야 합니다.
근거
- FastAPI의 /predict 엔드포인트는 주문 입력을 받아 predicted_delivery_seconds JSON을 반환한다. — 모델 배포 단계의 api.py 코드와 POST 응답 예시
배포 단계에서는 학습한 Pipeline을 joblib 파일로 저장하고 FastAPI 서비스가 이를 불러와 /predict 엔드포인트에서 주문 정보를 받도록 구성합니다. Pydantic의 Order 모델은 busy_dashers_ratio, estimated_non_prep_duration, 상품 수, 가격, 시장, 주문 프로토콜 같은 입력 형식을 검증하고, 모델 예측값은 predicted_delivery_seconds라는 JSON 응답으로 반환합니다. Docker 컨테이너로 패키징해 공개 Cloud 환경에 배포하면 사용자가 주문 데이터를 보내 실제 배달 시간 예측을 호출할 수 있습니다.
Dashboard는 API를 직접 호출하지 않는 평가자도 모델을 사용하고 결과를 해석하도록 만드는 마지막 접점입니다. Streamlit 화면에서 배달원 과부하 비율, 조리 외 소요 시간, 상품 수, 금액, 시장과 주문 프로토콜을 입력받고 Predict 버튼을 누르면 예측 시간을 분 단위 지표로 표시합니다. 높은 busy_dashers_ratio가 긴 배달 시간을 이끄는 요인이라면 피크 부하에 맞춘 인력 조정으로 연결하는 것처럼, 포트폴리오는 예측값보다 의사결정 가능한 추천으로 끝나야 합니다.
용어 해설
- Feature Engineering
- — 원시 데이터의 열을 모델이 학습하기 좋은 입력 변수로 바꾸는 과정입니다. 이 글에서는 배달원 과부하 비율과 조리 외 소요 시간을 계산하고, 범주형 변수를 OneHotEncoder로 변환해 예측력을 높이는 방식으로 활용합니다.
- 교차 검증(Cross-Validation)
- — 데이터를 여러 부분으로 나누어 학습과 평가를 반복하면서 모델 성능을 확인하는 방법입니다. 단일 train-test 분할에 우연히 의존하지 않고, 다섯 개 폴드의 RMSE를 비교해 예측 오차의 안정성을 판단하는 데 쓰입니다.
- 데이터 누수(Data Leakage)
- — 모델이 실제 예측 시점에는 알 수 없는 정보를 학습 과정에서 미리 사용하는 문제입니다. 글에서는 전처리와 모델을 하나의 scikit-learn Pipeline으로 묶어 학습 데이터와 새 입력에 같은 변환을 적용함으로써 누수 위험을 줄입니다.
- RMSE
- — 회귀 모델의 예측값과 실제값 사이 오차를 제곱한 뒤 평균내고 제곱근을 취한 지표입니다. 배달 시간 예측에서는 초 단위 오차를 측정하며, 값이 낮을수록 평균적인 큰 오차가 작다는 의미를 가집니다.
- API
- — 외부 프로그램이 모델의 예측 기능을 요청할 수 있도록 정해진 입력과 출력 형식을 제공하는 인터페이스입니다. FastAPI 서비스는 주문 정보를 POST 요청으로 받아 모델에 전달하고, 예측된 배달 시간을 JSON으로 반환합니다.
기술
- SQL
- Python
- pandas
- Polars
- Matplotlib
- Seaborn
- NumPy
- scikit-learn
- OneHotEncoder
- StandardScaler
- Pipeline
- XGBoost
- joblib
- FastAPI
- Pydantic
- Docker
- Streamlit
활용 사례
- 배달 시간 예측
- 배달원 인력 배치 조정
- 주문 운영 효율성 분석
- 예측 모델 API 서비스
- 모델 결과 Dashboard
언급된 리소스
DemoStrataScratch
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 12.수집 2026. 08. 12.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
