김선호
PM / Integration / DevOps계약·통합·릴리스와 실행 근거
Project 01 · TEAM PROJECT · DATA PRODUCT
따라가요
도착할 때, 따릉이가 있을까?
5주 · 5인 팀 프로젝트
PM / Integration / DevOps
도착 시점의 대여 가능성을 예측하고, 현재 재고·거리·이동시간과 함께 후보 대여소를 비교하도록 돕는 데이터 기반 의사결정 지원 서비스.
Product Demo
Interactive Portfolio Demo
Consumer Core → AI Planner → Admin Operations
고정 sample data로 핵심 클릭 흐름을 재현한 backend-free 보존판입니다. 실제 현재 재고나 운영 서비스를 표시하지 않습니다.
Portfolio Demo · Sample Data · Backend Offline. 실제 운영 당시 화면은 별도 녹화 영상에서 확인할 수 있습니다.
Project Architecture
팀 전체가 만든 시스템입니다. 데이터·모델 결과가 API를 거쳐 사용자의 선택과 운영 판단으로 이어집니다.
One team, five responsibilities
역할은 위계가 아니라 책임의 경계입니다. 각 영역은 계약·리뷰·통합을 통해 하나의 서비스가 되었습니다.
황준형
Data / ML데이터 수집·품질·모델 평가
선경원
Backend / API / DB인증·예측 조회·API와 저장
유제훈
Frontend / 관리자 시각화로그인 UX·Data/Export·ModelOps
김로운
Frontend / Consumer / Admin UI검색·결과·상세와 관리자 UI
My Technical Contribution
From Data Collection to Release Evidence
팀 전체 구현을 개인 성과로 합산하지 않고, 제가 직접 구현·구성·검증한 연결 영역을 정리했습니다.
Data Engineering
실시간 API 데이터를 Airflow 기반으로 수집하고 Raw → Quality → Curated 흐름으로 저장·검증했습니다.
실패·지연·재실행이 잘못된 정상 데이터로 이어지지 않도록 품질 차단과 중복 방지 경계를 두었습니다.
Case Study 근거 보기Cloud Data / Storage
OCI Object Storage를 데이터와 artifact 전달 경계로 사용하고 manifest·lineage·checksum을 검증했습니다.
서버 로컬 경로에 의존하지 않고 원본과 산출물의 연결, 행 보존과 무결성을 확인하기 위해서입니다.
Case Study 근거 보기Cloud / Infrastructure
Docker·OCIR·OCI staging 연결과 환경 분리, preflight·smoke·rollback 근거를 구성하고 확인했습니다.
서버 로컬의 비추적 환경값과 Secrets를 구분하고, SSH·loopback·제한된 접근 경계를 유지하기 위해서입니다.
Case Study 근거 보기Integration / Release Engineering
5인 팀의 작업을 계약·PR·CI와 exact SHA 기준의 OCI staging으로 연결했습니다.
개별 구현이 서로 다른 계약이나 배포 후보로 엇갈리지 않도록 변경 범위와 품질 게이트를 추적했습니다.
Case Study 근거 보기Runtime Verification
배포 commit 일치, backend·inference·postgres 실행 상태와 restart count, 오류 marker를 확인했습니다.
배포 성공과 실제 실행 상태는 다릅니다. Runtime Evidence는 브라우저 수용성이나 프론트엔드 runtime health 검증을 대신하지 않습니다.
Case Study 근거 보기Project Stack / My Hands-on Stack
Project Stack
React · Spring Boot · PostgreSQL · Python · Airflow · OCI · Docker · GitHub Actions
팀 전체 시스템에 사용한 기술입니다.
My Hands-on Stack
Python · Airflow · OCI Object Storage · OCI Compute · Docker · GitHub Actions · CI/CD · Linux / SSH
아래 구현·구성·검증 근거가 있는 범위입니다. 팀원의 전체 Data/ML·Backend·Frontend 구현을 포함하지 않습니다.
Case Study 01
신뢰 가능한 실시간 API 데이터 흐름 만들기
- Problem
- 실시간 API에는 실패·지연·재실행이 발생합니다. 잘못된 데이터를 정상처럼 넘기거나 중복 적재하면 후속 데이터와 서비스의 신뢰성이 무너집니다.
- Decision
- Raw → Quality → Curated의 책임을 분리했습니다. 원본은 보존하고, 품질을 통과한 데이터만 다음 단계로 넘깁니다.
- Implementation
- 따릉이·날씨 API 수집과 Airflow 실행 흐름을 연결했습니다. 정상 관측인 0대는 유지하고 누락·음수·파싱 실패는 구분했습니다. 재실행 중복 방지와 timeout·실패 경계도 확인했습니다.
- Validation
- AIRFLOW-2.1 개발용 DAG 통합의 대상 테스트 32개와 DAG 등록·import 검사 근거를 확인했습니다. 당시 전체 pipeline은 47 PASS / 1 FAIL로, 기존 DATA-2.0 evidence SHA 검사 실패 1건을 분리해 기록했습니다. 후속 AIRFLOW-OPS-3.1은 schedule=None의 로컬 수동 stage-1 실행입니다. 자동 상시 운영이나 전체 파이프라인의 모든 검증 성공으로 확대하지 않습니다.
- What I Learned
- 수집 주기와 모델의 prediction horizon은 별개의 설계 문제입니다. 수집 성공보다 어떤 상태의 데이터를 다음 단계로 전달하는지가 중요했습니다.
Case Study 02
데이터와 artifact를 서버 로컬 밖으로 분리하기
- Problem
- Raw·Curated·artifact가 Compute 로컬 디스크에만 있으면 원본과 산출물의 연결, 무결성 확인과 원격 재현이 어려워집니다.
- Decision
- OCI Object Storage를 전달 경계로 사용했습니다. 파일이 존재한다는 사실과 승인된 데이터라는 사실을 구분했습니다.
- Implementation
- approved manifest, lineage, row preservation, checksum을 대조했습니다. immutable upload와 remote read-back으로 같은 입력의 재실행 및 원격 객체 검증을 분리했습니다.
- Validation
- DATA-OPS-OCI-01에서 Curated 66,467,477행·135 partitions를 검증했습니다. 원격 객체 169개의 HEAD metadata와 본문 표본 2개를 확인한 범위이며, 169개 전체 본문 read-back을 주장하지 않습니다. MODEL-OPS-OCI-02는 pointer-only INACTIVE artifact 전달 검증으로 모델 학습·활성화와 별개입니다.
- What I Learned
- 스토리지 분리는 저장 위치 변경만이 아닙니다. 어떤 입력에서 어떤 산출물이 나왔는지 설명할 수 있어야 전달 경계가 검증 가능해집니다.
Case Study 03
5명의 코드를 릴리스 근거로 연결하기
- Problem
- 개별 코드가 정상이더라도 통합·배포 이후 정상이라는 보장은 없습니다. 테스트한 코드와 배포한 코드가 다르면 근거도 이어지지 않습니다.
- Decision
- Merge를 완료 조건으로 보지 않고 계약부터 실행 상태까지 evidence chain을 구성했습니다.
- Notion Contract
- Branch / PR
- Changed Path
- CI Quality Gates
- main / Exact SHA
- Stale Candidate Guard
- Changed Images
- Docker / OCIR
- OCI Staging
- Smoke / Rollback
- Runtime Evidence · 별도 수동 검증
- Implementation
- Frontend·Backend·Pipeline·Inference·Workflow Validation 게이트를 변경 경로에 맞춰 연결했습니다. exact SHA와 stale candidate guard, 변경 이미지 판정으로 배포 후보를 추적했습니다. 변경 없는 이미지는 재사용하며, Runtime Evidence는 별도 수동 workflow_dispatch로 실행합니다.
- Validation
- 기능 동결 SHA 12ee414의 CI #937·Staging CD #369·Runtime Evidence #43 성공은 해당 기준의 기록입니다. 이후 문서 PR #432의 main 9310d65는 CI #947·CD #373 SUCCESS이고 Runtime Evidence는 NOT_RUN입니다. backend·inference·postgres, restart count, HTTP 5xx·DB/inference 오류 및 unsafe/raw AI marker 검사는 browser acceptance와 구분합니다.
- What I Learned
- 배포 성공과 실제 실행 상태 검증을 서로 다른 완료 조건으로 관리했습니다. 같은 SHA를 따라가야 각 검증이 하나의 릴리스 근거가 됩니다.
Limitations & Evidence
- 대여 가능성은 예약이나 실제 대여 보장이 아닙니다.
- 예측 범위는 H1–H4와 필요 수량 1–5대입니다. TOO_SOON·MISSING·UNAVAILABLE을 임의 확률이나 정상 값으로 바꾸지 않습니다.
- 반납 예측·자전거 전용 routing·실과금은 현재 완료 기능이 아닙니다.
- 운영 근거는 OCI staging 범위입니다. production-scale 무중단 운영으로 표현하지 않습니다.
- 모델 개발과 팀원의 Backend·Frontend ownership은 각 담당자에게 있습니다.