Red Cross Works — 헌혈 데이터·운영 도구 5종
경기혈액원 복무 중 만든 웹 앱 모음. 데이터 수집·예측(how-many-blood, red-toolkit), 현장 운영(rc-kiosk), 공공 검색(blood-donation-criteria), 경로 최적화(optimal-route-planner)가 하나의 맥락으로 이어진다 — "현장의 문제를 데이터와 알고리즘으로 푼 사례 집합". 전부 실제 소스 코드를 직접 읽어 분석했다.
프로젝트별 핵심 — 코드 기반
how-many-blood
데이터 수집 · 예측혈액정보공개 API를 매시간 스크래핑해 자체 시계열을 만들고, 날씨 피처별 선형회귀 + 요일 가중치 가산 모델로 일별 헌혈량을 예측.
- Firebase Cloud Functions 5종 스케줄러: 매시간 수집(10-20시) / Open-Meteo 예보 6시간마다 / ASOS 관측 백필 / 일요일 모델 학습(개인·단체 분리) / 예측 생성
- 학습=기상청 ASOS 관측, 추론=Open-Meteo 예보 — 관측/예보 도메인 갭을 아는 것이 면접 포인트
- 평가는 in-sample R²/MAE/RMSE — 홀드아웃 부재를 스스로 짚기
red-toolkit
단체 섭외 분석 · 문서 자동화곱셈 팩터 휴리스틱(계절/요일/주기/추세) + 300건 이상 시 Ridge 회귀(closed-form, 순수 JS) 하이브리드로 단체별 헌혈 인원을 예측하고, HWPX/XLSX 문서를 자동 생성·발송.
- 예상 인원 = Base × Seasonal × DayOfWeek × CycleFactor × GlobalTrend × LocalTrend — 각 팩터에 클리핑/시그모이드
- Ridge: ln(ŷ) 로그선형, w=(XᵀX+αI)⁻¹Xᵀy (α=0.1), Gauss-Jordan 역행렬 직접 구현, data leakage 방지(해당 기록 이전 데이터만)
- 로드맵: Phase 2 Ridge(완료) → Phase 3 GBT(계획) — LightGBM 서버리스 또는 ONNX→onnxruntime-web 옵션 문서화
- Functions 15개 엔드포인트: HWPX/XLSX placeholder 치환, 템플릿 CRUD, comcigan 학교 시간표, nodemailer 발송
rc-kiosk-app / rc-kiosk-admin-app
현장 키오스크 + 관리 콘솔Supabase anon key 직접 쿼리로 현장 기념품 선택 키오스크 + Realtime 기록 모니터링 관리자 콘솔.
- 선택 규칙 검증: 'A 1개 + B 1개' 또는 'B 2개', allow_multiple 허용 — 클라이언트 상태 검증 (ProductSelector.tsx:95-135)
- 관리자: Supabase Realtime postgres_changes(INSERT) 구독 + 3초 강조, 장소별 기념품 일괄 동기화(delete→insert), QR 발급
- 정직한 한계: 인증이 user_auth 평문 비교 + localStorage 플래그 — '운영용 내부 도구' 스코프로 설명
blood-donation-criteria
헌혈 조건 검색헌혈 규정 6개 카테고리를 JSON으로 구조화해 Web Worker에서 병합·정규화하고, 제한기간을 일수로 통일해 '헌혈 가능일'을 즉시 계산.
- 데이터: 대한적십자사 공개 자료 → 질병/약물/백신/시술/지역/기타 6종 JSON
- Web Worker가 메인 스레드 밖에서 파싱 — 지역 exclusion/inclusion 펼침, day/week/month/year/permanent → restrictionPeriodDays 통일
- 가능일 = 기준날짜 + 제한일수 (ResultItem.jsx getStatusInfo)
optimal-route-planner
경로 최적화카카오 모빌리티의 방향성 거리(A→B≠B→A)를 반영한 비대칭 TSP를 Branch and Bound로 정확 최적화.
- 비대칭 거리 행렬 n(n-1)회 — 10개씩 배치 호출 + 실패 시 개별 폴백 (routeOptimizer.js)
- Branch and Bound: 각 unvisited 노드의 leaving 최소 비용 합 lower bound로 가지치기, 가까운 노드 우선 정렬로 좋은 해 조기 발견
- MAX_LOCATIONS=12, 완전탐색 대비 호출 절감 + 정확도 100%. LRU 캐시(5분 TTL)로 재최적화 시 API 호출 0회
- 카카오 장소검색이 좌표 반환 → 지오코딩 겸용 + 검색 의도 분석(역/학교↔카페/음식점)
배경지식 — 이 묶음을 관통하는 개념
- 휴리스틱 × 학습 하이브리드
- red-toolkit의 예측은 300건 미만(데이터 부족)일 땐 도메인 지식으로 짠 곱셈 팩터 공식, 이상일 땐 Ridge 회귀가 가중치를 자동 학습한다. 데이터 많다고 무조건 ML이 아니라, 데이터 양에 따라 모델 복잡도를 맞추는 것이 실무 정석 — 면접에서 "언제 학습이 이기는가"를 설명할 수 있는 근거.
- Ridge 회귀와 closed-form 해
- 선형회귀 최소제곱해는 (XᵀX)⁻¹Xᵀy. 피처 간 상관이 높으면 XᵀX가 특이행렬에 가까워져 불안정해지는데, αI를 더해(Ridge/릿지) 조건수를 낮춘다. 이 프로젝트는 역행렵을 순수 JS Gauss-Jordan으로 직접 구현 — 라이브러리 없이 수학을 코드로 옮긴 사례.
- 비대칭 TSP와 Branch and Bound
- 외판원 문제(TSP)는 NP-hard. 실제 도로에서는 일방통행 때문에 A→B와 B→A 비용이 다른 비대칭 행렬이 된다(대칭이면 2-opt 등 근사가 쉽지만 비대칭은 까다롭다). Branch and Bound는 하한(lower bound)으로 명백히 나쁜 분기를 가지치기해 최적해를 보장한 채 탐색을 줄인다. n=12에서 완전탐색 대비 호출 수가 수십 배 절감.
- 관측 소스 분리 (train/serve skew)
- how-many-blood는 학습을 실측(ASOS), 추론을 예보(Open-Meteo)로 한다. "미래 날씨"는 관측될 수 없어 불가피한 선택이지만, 예보 오차가 예측 오차로 직결된다. 프로덕션 ML의 전형적 skew 사례로 설명하면 깊이 있는 답이 된다.
- 서버리스 배치 vs 온라인 추론
- 두 예측 시스템 모두 요청 시점 계산이 아니라 주기적 batch scoring(예측 문서 미리 굽기) — 프런트는 읽기만 하고 비용·지연이 낮다.
- 공공 데이터 스크래핑의 실무
- 공개 API가 없거나 불친절한 공공 시스템(bissp.bloodinfo.net 모바일 엔드포인트, comcigan 학교 시간표)을 Referer 헤더 맞추기 등으로 수집 — 법적·기술적 경계를 알고 있는 것이 전제다.
면접 한 줄 답변
- "복무 중 뭘 했나요?" — 혈액원의 데이터 공백(시간별 데이터 없음)을 매시간 스크래핑으로 채우고, 그 위에 날씨 기반 예측과 단체별 인원 예측을 올렸으며, 현장 키오스크·기준 검색·경로 최적화로 실무 운영 도구까지 만들었습니다. 5개 프로젝트가 '헌혈 수급'이라는 하나의 문제로 연결됩니다.
- "예측 정확도는?" — how-many-blood는 in-sample R² 기반이라 일반화 성능 입증이 한계, red-toolkit은 data leakage 방지(과거 데이터만으로 피처 계산)와 신뢰도 가중치를 설계에 넣었습니다. 둘 다 '작은 데이터에서 해석 가능한 모델'을 선택한 이유를 먼저 설명합니다.
- "가장 알고리즘다운 것은?" — optimal-route-planner의 비대칭 TSP + Branch and Bound. 실도로의 방향성을 그대로 반영한 거리 행렬 위에서 최적해를 보장하면서 API 호출을 배치+캐시로 최소화했습니다.
- "왜 Firebase/Supabase 혼용?" — 예측·수집 파이프라인은 스케줄링과 Firestore 문서 모델에 맞는 Firebase, 키오스크는 Realtime 구독과 anon key 쓰기가 필요한 Supabase. 요구사항별 관리형 백엔드 선택 사례로 설명합니다.