배포 단위는 모델 파일 하나가 아니야
추정기 가중치만 저장해 두고 서비스가 결측 대치와 인코딩을 다시 구현하면 학습과 제공의 의미가 갈라져. 배포 가능한 결과물은 원시 행 검증, 전처리, 모델, 필요하면 확률 보정까지 묶은 전체 파이프라인과 그 계약이야. 새 환경에서 결과물을 불러 추가 접착 코드 없이 predict를 호출할 수 있어야 해.
파이프라인과 입력 스키마를 함께 묶어
맞춰진 Pipeline뿐 아니라 필요한 열 이름, 자료형, 단위, 허용 범주, 결측 규칙을 저장해. 열 순서가 바뀌거나 새로운 열이 추가되는 것은 안전할 수 있지만 필수 열이 없거나 단위가 달라지면 분명한 오류를 내야 해. 입력 스키마 버전과 예시 행을 결과물 시험에 포함하면 조용한 잘못된 예측을 막을 수 있어.
결과를 재현할 계보가 필요해
모델 버전, 학습 시각, 코드 커밋, 자료 해시, 설정, 라이브러리 버전, 교차검증과 시험 지표를 메타데이터에 남겨. 분류라면 확률 보정 방식, 선택한 문턱, 비용표와 정책 버전도 필요해. 누가 어떤 검증을 통과시켜 승격했는지까지 있어야 장애 때 비교와 복구가 가능해.
joblib은 편하지만 환경에 묶여
scikit-learn 파이프라인은 joblib로 저장하기 쉽지만 Python 객체 직렬화는 라이브러리 버전과 코드 위치에 민감해. 신뢰하지 못하는 pickle이나 joblib 파일은 임의 코드를 실행할 수 있으므로 열지 마. 학습과 제공 환경의 정확한 버전을 고정하고 새 버전 업그레이드는 결과물 재검증으로 다뤄.
ONNX는 다른 실행 환경을 연결해
Python이 아닌 서비스나 더 가벼운 런타임에서 제공하려면 ONNX를 검토할 수 있어. 모든 사용자 정의 변환과 모델이 변환되는 것은 아니고 수치 정밀도 차이도 생길 수 있어. 대표 행과 경계 사례에서 원본 파이프라인과 ONNX 출력의 허용 오차를 비교해야 해.
부스팅은 기본 형식도 함께 보존해
XGBoost와 LightGBM 같은 라이브러리는 JSON이나 자체 안정 형식으로 부스터를 저장할 수 있어. 나중에 분할과 특성 이름을 검사하고 Python pickle 의존성을 줄이는 데 도움이 돼. 그래도 부스터 앞의 전처리와 입력 계약이 사라지면 전체 제공 결과물은 아니므로 파이프라인 메타데이터와 연결해.
저장 뒤 새 프로세스에서 왕복 시험해
메모리에 남은 학습 객체를 쓰지 말고 디스크 결과물을 새 프로세스에서 불러 실제 형태의 원시 행을 예측해. 저장 전후 확률과 범주가 같고, 열 순서 변경과 결측·미지 범주가 계약대로 동작하는지 확인해. 결과물 자체와 메타데이터의 해시를 기록하면 전송 중 손상과 잘못된 파일 선택도 잡을 수 있어.
승격과 복구는 불변 결과물로 해
같은 파일을 덮어쓰지 말고 버전별 결과물을 불변으로 보존해. 현재 운영 버전을 가리키는 포인터만 승인 절차로 바꾸면 이전 버전으로 빠르게 돌아갈 수 있어. 결과물 저장소의 보존 기간, 접근 권한, 폐기 규칙도 운영 계약의 일부야.