데이터 포트폴리오 프로젝트 5가지 — 취업으로 이어지는 실전 프로젝트 가이드

핵심 메시지

• 타이타닉·아이리스 같은 흔한 예제는 지원자를 서로 똑같아 보이게 만들어 포트폴리오에서 변별력을 주지 못한다.
• 가치 있는 프로젝트는 실제 비즈니스 의사결정, 지저분한 실데이터, 베이스라인과 제대로 된 평가, 배포, 결과·한계에 대한 설명이라는 다섯 단계를 갖춰야 한다.
• 이탈 위험 예측, 이상거래 탐지, 자전거 수요 예측, 패션 추천, 민원 분류·검색 등 다섯 가지 프로젝트는 모두 공개 데이터셋으로 처음부터 끝까지(end-to-end) 만들 수 있다.
• 예측 자체가 목적이 아니라 그 예측이 어떤 행동으로 이어지는지가 프로젝트의 핵심이다.
• 핵심은 하나라도 처음부터 끝까지 완성해 배포하고, 결과와 한계를 명확히 설명해 포트폴리오로 보여주는 것이다.

쉽게 이해하기

많은 지원자가 캐글의 타이타닉 생존 예측이나 아이리스 분류 같은 똑같은 예제를 반복한다. 그 결과 포트폴리오가 서로 복사한 것처럼 비슷해져 변별력이 사라진다. 발표자는 이런 흔한 예제 대신 실제 채용으로 이어질 수 있는, 눈에 띄는 데이터 프로젝트 다섯 가지를 난이도와 적합한 직무까지 함께 소개한다.

좋은 프로젝트가 되려면 다섯 단계를 통과해야 한다고 정리한다. 첫째, 무엇을 해결하려는지 실제 비즈니스 의사결정이 있어야 한다. 둘째, 결측값·불일치·까다로운 조인이 섞인 지저분한 실데이터로 작업해야 한다. 셋째, 단순한 모델을 베이스라인으로 두고 필요할 때만 복잡도를 올리며 결과를 평가해야 한다. 넷째, API·앱·예약 파이프라인으로 배포해 다른 사람이 쓸 수 있게 만들어야 한다. 다섯째, 결과와 한계를 분명히 설명해야 한다. 튜토리얼은 어려운 부분을 잘라내지만 실제 프로젝트는 스스로 판단을 내려야 한다.

첫 번째는 고객 행동을 이해하는 '이탈 위험 예측'이다. UCI의 Online Retail 데이터셋(약 100만 건, 계정 없이 무료 다운로드)에는 취소된 인보이스, 누락된 고객 ID, 비정상적인 수량이 들어 있어 비활성 기간과 위험 라벨을 스스로 정의해야 한다. RFM·행동 기반 피처를 직접 만들고, SHAP 같은 방법으로 고객별 위험을 설명하고, 점수화 앱과 재점수 스케줄까지 배포하는 흐름으로 이어진다.

두 번째 '이상거래 탐지'는 매 거래가 압박 속의 의사결정이 되는 프로젝트다. IEEE-CIS Fraud Detection(캐글 계정 필요, 학습용 약 60만 건, 400개 이상 피처, 사기 비율 약 3.5%)은 심한 클래스 불균형을 다뤄야 한다. 사기 확률에 따라 통과·검토·차단의 임계값을 직접 정의하고(예: 0.4 미만 통과, 0.4~0.7 검토, 0.7 초과 차단), 정상 고객을 막거나 사기를 놓치는 실제 비용을 고려한다. 시간 기준 분할, 단순 베이스라인에서 그래디언트 부스팅으로의 단계적 확장, 정밀도·재현율 등 지표 선택과 확률 보정이 핵심이다.

세 번째 '자전거 수요 예측'은 Citibike 이용 데이터와 Open-Meteo 날씨 데이터를 결합한다. 도시 전체 평균이 아니라 정거장별로 수요를 예측하고, 자전거나 거치대가 바닥날 위험이 있는 정거장을 표시해 재배치 결정으로 연결한다. 예보 자체가 아니라 재배치 행동이 진짜 목표다. 네 번째 '패션 추천'은 H&M 데이터셋(3천만 건 이상, 고객 100만 명 이상)으로 인기도 베이스라인 → 협업 필터링 → 개인화 랭킹을 쌓고, 무작위가 아닌 시간 기반 검증과 MAP@12·recall@K·NDCG 같은 지표를 쓴다. 다섯 번째 '민원 분류·검색'은 미국 CFPB 소비자 민원 데이터(무료 실시간 API, 자유 서술 텍스트)로 NLP와 검색·RAG를 활용해 제품·이슈·긴급도·담당 팀을 분류하고 유사 사례를 찾아준다.

주요 인사이트

• 포트폴리오의 변별력은 데이터셋의 참신함보다 '실제 의사결정과 연결되는가'에서 나온다. 예측 결과가 어떤 행동(이탈 방어, 거래 차단, 자전거 재배치, 민원 라우팅)으로 이어지는지를 설계에 담아야 한다.
• 지저분한 실데이터를 직접 정제하고 서로 다른 출처를 조인하는 과정 자체가 실무 역량의 증거다. 깔끔하게 정리된 단일 데이터셋만 쓰면 현실을 반영하지 못한다.
• 곧바로 최신 모델로 뛰어들지 말고 단순한 베이스라인에서 출발해 약점을 파악한 뒤 필요할 때만 복잡도를 올리는 접근이 권장된다.
• 노트북 안에만 있는 결과물은 데모일 뿐이며, API·앱·예약 파이프라인으로 배포해 남이 쓸 수 있게 만들어야 확장성과 변별력이 생긴다.
• 결과뿐 아니라 한계와 책임 있는 사용에 대한 설명을 문서에 남기는 것이 튜토리얼과 실전 프로젝트를 가르는 지점이다.

자주 묻는 질문

관련 AI 소식