"XGBoost 데모"가 아닌 "비즈니스 문제 해결"로 시작하는 포트폴리오 전략

프로젝트 제목을 'XGBoost Regression Demo'라고 적는 것과 'Delivery Time Prediction'이라고 적는 것은 채용 담당자가 파악하는 지원자의 역량 범위를 바꾼다. 전자는 기술 튜토리얼을 따라 했다는 신호로 읽히지만, 후자는 기업이 직면한 문제를 해결하기 위해 무엇을 수행했는지를 보여주는 결과 중심의 기록이다. 채용 담당자는 특정 알고리즘의 사용 능력을 넘어 비즈니스 문제를 정의하고 해결하는 전체 라이프사이클을 스스로 수행할 수 있는지를 평가한다.

DoorDash 배달 시간 예측 프로젝트는 '주문 발생 후 배달 완료까지 시간이 얼마나 소요될 것인가'라는 명확한 비즈니스 질문에서 출발한다. 이러한 프레이밍은 알고리즘의 성능보다 비즈니스가 실제로 중요하게 생각하는 지점에 집중하는 방식이다. 실무자는 제공된 `historical_data.csv` 파일을 활용해 실제 배달 완료 시간에서 주문 생성 시간을 뺀 값을 타겟 변수로 설정하며 분석을 시작한다. 채용 담당자는 이 변수 설정 논리를 통해 지원자가 도구를 단순히 사용하는지, 아니면 원리를 이해하고 적용하는지 판단한다.

포트폴리오 주제는 이탈(Churn), 수요 예측(Forecasting), 사기 탐지(Fraud), 운영 효율성 개선처럼 기업의 이해관계가 깊은 문제를 선택해야 한다. 결과 중심으로 문제를 정의한 프로젝트는 비즈니스 가치를 창출하는 능력을 증명한다. 특히 DoorDash 사례와 같은 운영 효율성 문제는 예측 결과가 실제 인력 배치나 고객 경험 개선으로 이어질 수 있어 설득력이 높다. 결과 중심의 프레이밍은 기술적 구현 단계의 근거가 된다.

데이터 사이언스 포트폴리오는 문제 정의에서 시작해 비즈니스 추천으로 끝나는 흐름을 증명해야 한다. 대부분의 지원자는 모델링이나 데이터 정제 중 한 영역만 보여주지만, 두 영역을 연결하는 역량은 드물다. 배달 시간 예측이라는 비즈니스 질문을 세우고 이를 해결하기 위한 전 과정을 구축하는 것은 이 간극을 메우는 작업이다. 첫 단계의 비즈니스 프레이밍은 이후의 데이터 정제, 모델링, API 배포, 대시보드 구축의 모든 단계가 하나의 목적지를 향하게 만드는 기준점이 된다.

SQL 쿼리부터 pandas 전처리까지, 데이터 파이프라인의 실무적 구현

분석용 테이블을 만들 때 모든 데이터를 가져오는 raw dump 방식 대신 SQL의 JOIN과 WHERE 필터를 사용해 필요한 행만 추출한다. 실제 기업 환경의 데이터는 데이터베이스에 분산 저장되어 있으므로 이를 통합하는 SQL 작성 능력이 필수적이다. 주문(order) 테이블을 중심으로 배달원(dasher)와 상점(store) 테이블을 JOIN으로 연결해 뷰를 만들고, WHERE 절로 데이터 오류 행을 제거한다. 특히 GROUP BY 절을 활용해 무거운 필터링과 집계 작업을 데이터베이스 서버 단에서 처리한 뒤 분석 준비가 된 테이블만 파이썬으로 가져오면 로컬 메모리 부하를 줄이고 추출 속도를 높일 수 있다.

추출한 데이터는 pandas를 이용해 모델 학습이 가능한 형태로 정제한다. 배달 완료 시간에서 주문 생성 시간을 빼서 타겟 변수인 실제 배달 소요 시간을 계산하고, 데이터 타입 불일치 오류를 수정하며, 배달 시간이 음수로 나오는 물리적 불가능 값을 제거하거나 보정한다. 처리 데이터셋이 수백만 건 이상으로 커져 pandas의 메모리 점유율이 높아지면 Polars를 대안으로 선택해 처리 효율을 높인다. 데이터 정제 단계의 예외 케이스 처리 수준이 최종 모델의 예측 정확도를 결정한다.

정제가 완료된 데이터는 탐색적 데이터 분석(EDA)을 통해 패턴을 찾아낸다. 먼저 `df.info()`와 `df.describe()` 메서드를 사용해 전체적인 데이터 구조와 기초 통계량을 요약한다.

python

데이터 구조 및 기초 통계량 요약

print(df.info())

print(df.describe())

이후 Matplotlib과 Seaborn 라이브러리를 활용해 변수들의 분포와 상호 관계를 시각화한다. 특정 시간대에 배달 시간이 급증하는 분포를 확인하거나 변수 간의 강한 상관관계를 파악하는 과정은 모델에 투입할 핵심 변수를 선정하고 가설을 검증하는 분석의 근거가 된다.

원시 데이터를 분석 가능한 형태로 가공하는 이 파이프라인 구축 과정은 실무 데이터 분석 워크플로의 60~80%를 차지한다. SQL 쿼리 작성부터 pandas 정제, EDA 시각화까지 이어지는 단계는 모호한 비즈니스 질문을 모델이 학습할 수 있는 수치적 형태로 번역하는 작업이다. 데이터 누수를 방지하고 깨끗한 상태를 만드는 정교한 전처리 능력은 실무자의 숙련도를 증명하며, 이는 이후 단계의 정직한 모델 평가와 서비스 배포로 연결된다.

피처 엔지니어링과 모델 검증: 단순 정확도를 넘어선 성능 증명

정제된 데이터를 바탕으로 도메인 지식을 활용해 모델이 학습하기 좋은 형태로 변수를 가공하는 피처 엔지니어링을 수행한다. 배달원 가동률을 나타내는 `busy_dashers_ratio`나 주행 시간과 주문 처리 시간의 합계를 계산한 `estimated_non_prep_duration` 같은 변수가 대표적이다. 배달원 가동률은 지역 혼잡도를 수치화한 것이며, 비조리 시간 합계는 음식 준비 시간을 제외한 실제 이동 시간을 분리해낸 값이다. 이는 비즈니스 현장의 논리를 수치로 변환해 모델의 입력값으로 제공하는 과정이다.

전처리 과정에서 학습 데이터의 정보가 검증 데이터로 흘러 들어가는 데이터 누수 현상이 발생하면 모델 성능이 과대평가된다. 특히 평균값이나 표준편차를 이용한 스케일링을 전체 데이터에 먼저 적용한 뒤 데이터를 나누면 검증 데이터의 정보가 학습 과정에 포함된다. 이를 방지하기 위해 scikit-learn 파이프라인을 구축해 전처리 단계와 모델 학습 과정을 하나의 객체로 묶어 관리한다. 이렇게 하면 학습 데이터에 적용한 기준이 새로운 데이터에도 동일하게 적용되어 데이터 누수를 차단하며, 이러한 검증 과정의 엄격함이 모델의 신뢰성을 결정한다.

모델링 단계에서는 모든 배달 시간을 단순 평균값으로 예측하는 나이브 베이스라인(Naive Baseline)부터 구축해 성능의 최저 기준선을 설정한다. 이후 선형 모델인 Ridge를 거쳐 트리 기반 모델인 XGBoost 순으로 모델을 고도화하며 성능 향상 폭을 측정한다. Ridge 모델은 변수 간의 선형 관계를 파악하는 기준이 되며, XGBoost는 복잡한 비선형 상호작용을 학습한다. 만약 고도화된 모델이 단순 평균값 예측보다 낮은 성능을 보인다면 데이터 수집 단계나 피처 생성 로직의 결함으로 판단한다.

배달 소요 시간 예측과 같은 회귀 문제에서는 예측값과 실제값의 차이를 제곱하여 평균 낸 뒤 루트를 씌운 RMSE(Root Mean Squared Error)를 핵심 지표로 사용한다. 이는 오차가 클수록 패널티를 크게 부여하므로 실무적으로 위험한 예측을 걸러내는 데 유리하다. 또한 교차 검증(Cross-validation)을 수행해 특정 데이터 뭉치에만 최적화되는 과적합 문제를 해결하고, 모든 모델의 결과를 베이스라인 및 상호 간의 수치와 대조하여 성능 향상의 근거를 기록한다.

노트북을 벗어난 API 배포와 Streamlit 대시보드 시각화

학습이 끝난 모델은 joblib를 통해 직렬화하여 파일로 저장한다. 이후 FastAPI를 사용해 `POST /predict` 엔드포인트를 구현하면 외부에서 주문 데이터를 보냈을 때 모델이 예측값을 반환하는 구조가 완성된다. 실제 API 응답 값은 `{"predicted_delivery_seconds": 2472}`와 같은 JSON 형태로 출력되며, FastAPI의 자동 문서화 기능을 통해 API 규격을 즉시 확인하고 테스트할 수 있다.

로컬 환경의 코드를 외부에서 접속 가능하게 만들려면 Docker 패키징이 필요하다. 모델 파일, API 코드, 의존성 라이브러리를 하나의 이미지로 묶어 퍼블릭 클라우드 서버에 배포한다. 이 과정을 거치면 사용자는 파이썬 환경 구축 없이 표준 HTTP 요청만으로 배달 예상 시간을 받아볼 수 있다. 서버 설정과 환경 변수 관리를 컨테이너 단위로 처리하면 배포 환경이 바뀌어도 동일한 동작을 보장한다. 실제 작동하는 URL을 제공하는 것은 텍스트로 정확도를 제시하는 것보다 실무 적용 능력을 더 확실히 증명하는 방법이다.

API 호출의 진입장벽을 낮추기 위해 Streamlit을 이용해 인터랙티브 대시보드를 구축한다. 사용자가 웹 화면의 입력창에 주문 조건이나 배달원 상태를 입력하면, 백엔드 API와 통신하여 실시간 예측 시간이 계산되어 표시된다. 특정 변수를 슬라이더나 드롭다운으로 조정했을 때 예측 시간이 어떻게 변하는지 탐색하게 함으로써 모델의 영향 요인을 직관적으로 보여준다. 이는 모델이 실제 비즈니스 환경에서 어떻게 작동할지 시뮬레이션하는 도구가 되며, 기술적 성취를 비즈니스 가치로 치환해 프로젝트의 문제 정의로 다시 돌아가 루프를 닫는 역할을 한다.

예측 모델을 '비즈니스 추천'으로 닫는 최종 산출물의 가치

단순히 모델의 예측 오차를 줄이는 작업에서 멈추지 않고, `busy_dashers_ratio` 변수를 통해 피크 시간대 인력 조정이라는 구체적인 액션을 제안하는 단계로 산출물을 확장한다. 배달원 가동률이 예측 결과에 결정적인 영향을 준다는 사실을 발견했다면, 이를 운영 효율화를 위한 구체적인 인력 배치 전략으로 연결해야 한다. 데이터 사이언스의 최종 목적지는 예측값이 아니라 그 수치를 바탕으로 비즈니스 의사결정을 바꾸는 추천안을 제시하는 것이다. 이러한 흐름은 초기 문제 정의와 최종 비즈니스 추천을 하나로 이어 분석 목적을 달성한다.

채용 담당자가 포트폴리오에서 확인하는 핵심은 전체 라이프사이클의 완결성이다. SQL 쿼리로 데이터를 추출하는 것부터 시작해 배포된 애플리케이션과 명확한 추천안까지 도출하는 엔드투엔드 스토리는 이력서의 텍스트만으로는 증명할 수 없는 실무 역량을 보여준다. 문제 정의, SQL 추출, 데이터 정제, 탐색적 데이터 분석, 피처 엔지니어링, 모델링, 검증, API 구축, 대시보드 추천으로 이어지는 9단계 구성은 실무 워크플로를 이해하고 있음을 보여준다. 각 단계가 하나의 이야기처럼 연결될 때 실무자가 신뢰할 수 있는 포트폴리오가 완성된다.

데이터 사이언티스트의 역량은 정밀한 데이터 정제 능력과 모델 서비스화 및 의사결정 지원 능력이 결합될 때 완성된다. 정제된 데이터가 모델을 거쳐 API 형태로 제공되고, 최종적으로 경영진이 판단할 수 있는 구체적인 추천안으로 변환되는 전체 흐름을 구축하는 능력이 필요하다. 모델의 정확도라는 기술적 지표를 비즈니스 가치라는 언어로 번역하는 과정이 프로젝트의 실질적인 마무리가 된다.

포트폴리오의 최종 가치는 단순한 노트북 파일의 나열이 아니라, 초기 문제 정의 단계에서 제기한 비즈니스 질문에 대해 최종 추천안으로 답을 내놓는 완결된 루프를 증명하는 데 있다.