따라가요 DDARUNG FLOW

지금 보이는 재고가 도착할 때도 남아 있을까?

대여 시점의 재고 정보만으로는 이동 후 도착할 시점의 대여 가능 여부를 알기 어렵습니다. 사용자가 필요한 수량과 도착 예상 시간을 기준으로 후보 대여소를 비교하도록 돕는 것이 프로젝트의 문제였습니다.

5주 동안 5명이 만든 팀 프로젝트입니다. 서비스는 예측 결과를 예약 보장으로 표현하지 않고 현재 재고·거리·이동시간과 함께 보여줍니다.

도착 시간과 필요한 자전거 수로 대여 가능성을 비교

모델 개발과 평가는 Data/ML 담당 팀원이 수행했습니다. 저는 모델 자체를 개발한 것으로 주장하지 않으며, 수집·품질, 전달과 릴리스 검증에 참여했습니다.

프로젝트 전체 분석 근거: 기준 README · 공개 Notion

수집 결과와 다음 단계에서 쓸 수 있는 데이터를 구분

따릉이·날씨 API와 Airflow 실행 흐름을 연결하고 Raw → Quality → Curated 단계로 분리했습니다. 원본은 보존하고 품질 기준을 통과한 데이터만 후속 단계로 넘기도록 구성했습니다.

• 정상 재고 0대는 유효한 관측으로 보존하고 누락·음수·파싱 오류는 구분
• 재실행 때 중복이 생기지 않도록 처리하고 timeout·실패 경계 확인
• OCI Object Storage에 manifest·lineage·checksum을 대조하고 행 보존 및 immutable upload 확인
• 원격 객체는 169개 HEAD metadata와 본문 표본 2개를 read-back 검증

프로젝트 전체의 과거 재고 6,152,132행 검사와 월별 최저 대여소 ID 결합률 99.6427%는 팀 검증치입니다. 개인 성과나 현재 운영 지표가 아닙니다.

조장 · 데이터 파이프라인 · 통합 · DevOps

팀원 역할: 황준형 Data/ML, 선경원 Backend/API/DB, 유제훈 Frontend/Admin 시각화, 김로운 Consumer/Admin UI입니다. 모델 개발과 팀원 Backend·Frontend 구현을 제 성과에 합산하지 않습니다.

개발 근거와 운영 범위를 분리

• Airflow DAG 통합 테스트 32개와 DAG 등록 검사를 확인했습니다. 해당 시점 pipeline 전체 검사 중 기존 근거 검사 1건은 실패로 남아 별도로 기록했습니다.
• 수집 DAG는 schedule=None인 로컬 수동 실행 단계입니다. 24시간 자동 운영이 아닙니다.
• Curated 66,467,477행·135 partitions는 팀 전체 검증치입니다. 원격 객체 169개는 메타데이터를 모두 다시 읽었고, 본문은 표본 2개만 확인했습니다.
• 배포 검증 환경은 OCI Staging입니다. 실제 운영(production) 규모의 무중단 운영을 뜻하지 않습니다.
• 예측은 예약·실제 대여 보장이 아니며 반납 예측·자전거 전용 routing·실과금 완료 기능이 아닙니다.

모델과 각 팀원 기여의 경계를 보존합니다. 근거 기준 commit · 공개 Notion