2. 비동기 큐로 분리

무거운 수집·계산은 큐로 넘겨 요청 응답을 막지 않습니다.

문제

수집과 피처 계산이 무거워 요청 응답을 막을 수 있고, 큐 재배달이 일어나면 같은 작업이 다시 실행될 수 있음

판단

동기 처리는 응답 지연 때문에 탈락 → Celery 비동기 큐로 분리. 재배달로 중복 실행이 생긴다는 점은 코드로 원인을 확인하고 이력에서 구분

결과

운영 배포. 남은 미연결 이력의 원인이 재배달임을 코드와 데이터로 확정

3. 최신 데이터 수집

외부 플랫폼에서 최신 데이터를 가져옵니다. 데이터가 부족하면 검증 안 된 점수를 내지 않고 그 평가는 스킵합니다.

문제

수집 기간 막바지에만 거래가 몰린 드문 경우, 일부 피처(금액 계산에 필요한 확정 데이터)를 만들 수 없음

판단

해당 피처만 비워 점수를 내는 방식은 탈락(학습 때 거의 없던 결측 상태라 검증 안 된 점수가 됨) → 하드 실패로 스킵. 스킵 비용과 잘못된 점수의 위험을 숫자로 비교해 결정

결과

스킵되는 건 극소수이고 이후 재평가가 가능. 원인을 추적해 수정을 보류하고 현행 유지로 결론

4. 정제 · 피처 계산

정제 후 주간·월간 집계로 피처를 계산합니다. 학습 때와 같은 기준일·집계 단위인지가 핵심 검증 포인트입니다.

문제

서빙 피처가 학습 때와 같은 기준으로 계산되는지 알 수 없고, 통계 요약만으로는 이상 피처를 놓침

판단

통계 요약 점검만으로 끝내는 방식은 탈락(과거 버그가 표본 재계산에서 발견됨) → 표본을 원본에서 다시 계산해 대조, 이상해 보이는 수치는 기대값 계산으로 판별

결과

기준일 차이로 최근 주 피처가 비는 구간 등 학습-서빙 불일치를 찾아 별도 안건으로 분리

5. 모델 추론

학습된 모델에 피처를 넣어 점수를 계산합니다.

문제

피처 이상이 실제 점수에 얼마나 영향을 주는지는 아직 재지 못함

판단

트리 기반이라 영향이 작을 것이라는 추정을 사실처럼 쓰지 않고, 확인된 것 / 추정 / 미확인으로 나눠 기록

결과

모델링팀에 전달할 질문 목록과 한계를 함께 정리

6. 저장 · 출처 추적

점수를 저장하고, 수집 실행마다 원본 ID를 기록해 결과를 끝까지 역추적할 수 있습니다.

문제

실행 기록이 실제로 어느 원본 파일을 만들었는지 알 방법이 없었음

판단

날짜와 실행 ID를 함께 저장하려던 안은 탈락(수집이 자정을 걸치면 테이블별 날짜가 달라져 한 칸에 못 담음) → 실행 ID만 저장

결과

실제 수집으로 성공·실패 케이스를 검증. 과거 데이터 소급 연결 중 오매칭을 표본 대조로 찾아 매칭 기준을 교체