[Fix] 프로덕션 stacking 아티팩트가 8/11 버전에서 한 번도 승격 안 됨

[kite-pp]

🏷️ 이슈 유형

• feat : 새로운 기능 추가
• fix : 버그 수정
• refactor : 동작 변경 없는 구조 개선
• docs : README 등 문서 추가/수정
• chore : 설정, 빌드, 의존성 패키지 변경
• 기타 : 설명 추가 작성

💡 문제

프로덕션 코드(app/analysis/text/stacking_analyzer.py)의 DEFAULT_STACKING_MODEL_PATH가 실제 서비스 추론에 쓰는 유일한 경로인 최상위 data_science/SMSModel/artifacts/stacking/model.joblib을 가리킵니다. 이 파일이 8/11에 학습된 이후 한 번도 갱신되지 않았습니다.

created_at: 2026-08-11T00:13:11
dataset_path: Data/SMSData/phishing_total_dataset_2705.csv   (가장 오래된 원본)
base_models: [naive_bayes, logistic_regression, linear_svm]  (인코더 없음)

그 이후 #65(정상 포인트소멸 오탐 수정), #83(정상 데이터 taxonomy 개편), #96~#104(실데이터 판정셋, 인코더 추가, 데이터 보강), #106/#107(임계값 정책 픽스, 정상 데이터 보강)이 전부 artifacts/stacking/v2/ ~ v9/ 버전 디렉터리에만 쌓였고 이 최상위 경로로는 반영되지 않았습니다.

⚠️ 스코프 수정 (최초 등록 내용 정정)

최초 등록 시 "테스트하려면 승격이 필요하다"는 뉘앙스로 적었는데 틀렸습니다. run_error_analysis.py/run_adoption_gate.py는 --model-path로 아무 버전 디렉터리나 직접 가리켜 평가할 수 있고, 이번 세션에서도 실제로 승격 없이 v8-experiment/v9-experiment를 테스트했습니다. 즉:

• 버전 디렉터리(v2~v9)는 테스트 가능한 실제 후보 아티팩트다. "기록용"이 아니고, 테스트에 승격이 필요하지도 않다.
• 승격이 필요한 순간은 딱 하나: 그 버전을 실사용자에게 실제로 서빙하기 시작할 때(=최상위 model.joblib 갱신) 뿐이다.

그래서 이 이슈는 "v9를 테스트하기 위한 선행 작업"이 아니라, **"평가를 마친 어떤 버전을, 언제, 어떤 기준으로 실제 서비스에 반영할지에 대한 절차/결정이 없다"**는 별개의, 우선순위 낮은 문제로 스코프를 좁힙니다.

🔍 확인이 필요한 부분

docs/STANDALONE_ADOPTION_CRITERIA.md(#85)의 채택 게이트는 "LLM 없이 stacking 단독 운영"을 판정하는 기준이라 지금 FAIL인 게 맞습니다. 하지만 이건 다른 질문입니다 — 하이브리드 파이프라인(stacking + LLM 이중검증) 안에서 쓰이는 stacking 결과 자체를 최신 버전으로 갱신할지는 별개 판단입니다. LLM이 최종 안전망 역할을 하므로, 단독 운영 기준을 완전히 통과하지 못해도 8/11 버전보다 최신 버전이 낫다면 반영할 가치가 있을 수 있습니다.

• 최상위 model.joblib을 갱신하는 절차가 원래 없었던 건지, 있었는데 누락된 건지 확인 필요
• "승격" 기준을 무엇으로 할지 결정 필요 (단독 운영 게이트 통과 필수 vs 하이브리드 내 상대적 개선이면 충분)

🛠️ 할 일 목록

• 최상위 artifacts/stacking/model.joblib 갱신 절차 유무 확인 (문서/코드 전체 검색)
• 승격 기준 결정 (문서화) — 급하지 않음, 팀 논의 필요
• 기준이 정해지면 승격 스크립트/플래그 추가

📌 참고

• v9 아티팩트 생성·테스트는 이 이슈와 무관하게 바로 진행 가능 (--model-path로 직접 평가) — Feat(#102): 카드결제·포인트소멸·택배 정상 데이터 135건 보강 (2차) #107 참고
• 이 이슈는 "언젠가 실제 반영하기로 결정했을 때 절차가 없다"를 남겨두는 용도. 급한 선행 작업 아님