실험과 버전 연결

이 문서에서 공식 평가 결과는 모델과 임계값을 정한 뒤 최종 평가 데이터로 한 번 계산해 canonical-benchmark.json에 남긴 모델 승인 기록입니다. 정밀도, 재현율, 미탐, 재현율 하한의 뜻이 낯선 독자는 분류 지표와 곡선을 먼저 확인합니다.

공식 평가 결과를 확인한 뒤 모델이나 임계값을 다시 조정하면 승인 판단의 근거가 무너집니다. 공식 평가 자료는 결과를 개선하는 재료가 아니라, 최종 판단이 어떤 정책과 어떤 고정 모델 패키지(model package)에 연결되어 있는지 확인하는 근거입니다. 특성, threshold, 배포 정책은 바꾸지 않습니다. 여기서 고정 모델 패키지는 승인 시점에 고정한 모델과 메타데이터를 함께 식별하는 배포 단위를 뜻합니다.

수치만으로는 모델 승인 판단을 충분히 설명할 수 없습니다. 정책과 고정 모델 패키지까지 연결해야 승인 결과가 나온 조건을 다른 사람이 다시 확인할 수 있습니다. 수치를 다시 계산하지 말고 같은 판단을 뒷받침하는 정책과 산출물을 추적합니다.

고정된 평가 자료를 읽는 법

• 결과를 개선하려고 임계값·특성·정책을 다시 조정하지 않습니다.
• 보호 기준 표에서는 모든 필수 기준의 통과 여부를 확인합니다.
• 선언 파일과 MLflow 이력은 결과를 새로 만드는 자료가 아니라, 공식 판단의 생성 이력을 대조하는 자료입니다.

코드, 데이터, 실험과 파일을 연결하는 원리

같은 학습 코드를 실행해도 데이터와 설정이 다르면 다른 모델 파일이 나올 수 있습니다. 기능 시험의 소스 버전만 기록하던 방식에 학습 데이터와 전처리, 모델 설정, 실행 기록과 파일 내용을 추가해야 합니다. 성능 표만 복사하면 그 숫자를 만든 모델이 무엇인지 나중에 다시 확인하기 어렵습니다.

기록 도구는 서로 다른 대상을 식별합니다. Git commit은 추적하는 소스와 설정의 상태를 찾는 출발점이고, DVC와 데이터 지문은 입력 파일과 처리 단계의 버전을 확인합니다. MLflow run은 한 번 실행에 기록한 설정, 지표와 산출물을 묶습니다. SHA-256은 비교 대상 파일의 내용에서 계산한 값이므로 같은 파일명으로 덮어쓴 산출물을 구분할 때 사용합니다. MLflow Tracking 공식 문서의 실험 기록 개념을 이 과정에서는 다음 연결에 적용합니다.

기록	이 과정에서 읽을 위치	연결할 질문
코드와 설정	model-bootstrap.json의 provenance	어떤 소스 시점과 설정에서 시작했는가
데이터 내용	split-revision-v2.json의 역할과 SHA-256	같은 revision의 같은 자료를 사용했는가
개발 실행	model-bootstrap.json의 프로필별 mlflow_run_id	train과 valid로 만든 지표와 파일의 짝이 맞는가
승인 실행	release-manifest.json의 final_mlflow_run_id	고정된 최종 평가의 승인 근거는 어느 실행인가
파일 내용	approved_model의 모델, 메타데이터, 입력 계약 SHA-256	어떤 실제 파일 묶음이 승인됐는가

후보 B는 승인 결과에서 개발 기록으로 거꾸로 추적합니다. release-manifest.json의 approved_profile과 canonical_evidence로 승인 대상과 결과를 확인하고, approved_model.model_mlflow_run_id를 model-bootstrap.json의 후보 B와 대조합니다. model_sha256, metadata_sha256, feature_contract_sha256도 해당 파일끼리 연결합니다. 화면의 짧은 지문은 설명용 앞부분이며 실제 대조에는 전체 값을 사용합니다.

이력 연결과 완전한 재학습 재현은 구분해야 합니다. 제공된 model-bootstrap.json에는 git_worktree_dirty="true"가 남아 있고, release-manifest.json에는 frozen_dvc_lock_snapshot_available=false가 기록되어 있습니다. 기록된 승인 모델 파일과 근거의 대응은 추적할 수 있지만, commit 하나와 지문만으로 당시 모든 소스 변경과 데이터를 복원했다고 말할 수는 없습니다. 완전한 재현에는 누락된 변경분, 원래 잠금 정보와 실행 의존성까지 필요합니다.

운영 배포는 이 연결의 다음 확인 대상입니다. 기록 안의 지문이 맞는다는 사실은 대상 서버에서 실제 파일을 읽어 확인한 결과가 아닙니다. 1일차에는 모델 승인과 생성 이력의 확인 범위를 남기고, 2일차에는 실행 중인 모델 정보를 대조합니다.

모델 승인 기준

이 평가 기준은 Candidate B가 비교 기준 모델보다 모든 품질 지표에서 더 높아야 한다고 요구하지 않습니다. high_risk 알림에서 놓침을 줄이기 위해 재현율과 미탐 기준을 두고, 불필요한 알림 부담을 무시하지 않도록 정밀도 최소 기준과 정밀도-재현율 곡선 아래 면적(Precision-Recall Area Under the Curve, PR-AUC)의 변화도 함께 확인합니다.

보호 기준은 필요한 값과 후보별 결과, 업무상 이유를 함께 봐야 합니다. 정밀도 하나가 높다는 이유로 후보를 자동 승인하지 않습니다.

보호 기준	필요한 값	Candidate A	Candidate B	이 기준이 뜻하는 것
재현율	0.60 이상 (0.55 + 0.05)	0.3091 ✗(미통과)	0.8000 ✓(통과)	high_risk 사례를 놓치지 않기 위한 최소 수준
재현율 부트스트랩 하한	0.45 이상	0.1864 ✗(미통과)	0.6956 ✓(통과)	불확실성을 고려한 보수적인 하한
정밀도	0.20 이상	0.7727 ✓(통과)	0.3793 ✓(통과)	알림 부담을 전혀 무시하지 않기 위한 최소 수준
비교 기준 모델 대비 PR-AUC 변화	0.00 이상	+0.0698 ✓(통과)	+0.0499 ✓(통과)	비교 기준 모델보다 순위 품질이 나빠지지 않았는지
미탐(FN) 감소	15 이상	4 ✗(미통과)	31 ✓(통과)	비교 기준 모델보다 놓침을 충분히 줄였는지

Candidate A를 HOLD하는 이유는 정밀도가 낮아서가 아니라 필수 보호 기준을 모두 통과하지 못했기 때문입니다. Candidate B는 A보다 정밀도가 낮다는 사실을 숨기지 않습니다. 다만 정책이 정한 최소 정밀도를 넘기면서 재현율과 미탐 목표를 만족했으므로, 이 평가 범위에서만 APPROVE로 기록합니다.

모델 승인과 실행 환경 확인

모델 승인과 대상 환경 배포 상태를 섞으면 잘못된 승인과 불필요한 보류가 모두 생길 수 있습니다.

• Candidate A를 정밀도 하나만 보고 승인하면 낮은 재현율과 부족한 미탐 감소를 놓칩니다.
• Candidate B를 실행 환경 자료 부재만으로 모델 HOLD로 쓰면, 고정된 모델 평가와 운영 확인을 한 판단으로 섞습니다.
• Candidate B의 모델 승인을 대상 환경 성공으로 확대하면, 다른 모델 패키지나 운영 요청 조건을 놓칩니다.

각 잘못된 판단은 생길 수 있는 문제, 현재 근거, 담당자의 다음 조치와 함께 기록합니다.

잘못된 판단	생길 수 있는 문제	지금 확인한 근거	담당자와 다음 할 일
Candidate A를 모델 APPROVE로 기록	정책 위반, 미탐 목표를 못 채운 배포 기록, 이후 감사와 품질 판단의 신뢰도 저하	A의 재현율 0.3091, 하한 0.1864, 미탐 감소 4는 기준에 못 미칩니다.	검토 담당자와 모델 담당자: A를 HOLD로 유지하고 새 개정본이 필요한 조건을 기록합니다.
Candidate B를 모델 HOLD로 기록	배포 검토 지연, 중복 모델 작업, 품질 판단의 신뢰도 저하	B는 다섯 보호 기준을 모두 통과했습니다.	검토 담당자: B의 APPROVE를 유지하고 서빙과 플랫폼 담당자에게 실행 환경 자료를 요청합니다.
B의 모델 승인을 대상 환경 성공으로 확대	다른 모델 패키지가 연결됐거나 운영 요청 조건이 다른 문제를 놓침	현재 자료는 비교 기준 모델과 두 후보의 평가 결과뿐입니다.	서빙과 플랫폼 담당자: 3장의 해시값과 API가 사용 중인 모델 정보, 4장의 운영 관측 범위를 확인합니다.

Candidate B의 모델 APPROVE는 지금 대상 환경에 적용하라는 지시가 아니라, 공식 평가 범위에서 보호 기준을 통과했다는 기록입니다. 모델 승인 판단과 운영 배포 판단을 분리하고, 운영 배포 항목에는 실제로 확인한 범위와 담당자의 다음 조치를 기록해야 합니다.

공식 평가 자료의 확인 범위

공식 평가 결과가 만들어진 과정은 화면에 보이는 실행 하나가 아니라 정책과 결과 파일까지 연결해 확인해야 합니다. MLflow는 모델 학습과 평가에 사용한 설정, 지표, 실행 ID를 기록하는 도구이며, 파일에 남은 MLflow 실행 ID를 평가 자료와 대조하는 데 사용합니다.

사전에 정한 데이터 분할·정책·모델 패키지는 생성 이력을 확인하는 대상이지, 결과를 본 뒤 바꾸거나 운영 요청으로 대체할 대상이 아닙니다.

사전에 정한 대상	실습에서 확인할 내용	피해야 할 해석 또는 조작
데이터 분할과 테스트 역할	분할 이력과 최종 평가 데이터의 사용 상태를 확인합니다.	운영 요청 데이터를 정답이 있는 테스트처럼 사용합니다.
프로필, 임계값, 정책	설정 해시값, threshold, 보호 기준을 비교합니다.	결과를 본 뒤 임계값이나 정책을 바꿉니다.
최종 평가 자료와 고정 모델 패키지	배포 선언 파일의 해시값과 MLflow 생성 이력을 대조합니다.	과거 공식 평가 결과를 새 실행 결과로 바꿉니다.

평가 당시의 데이터와 처리 단계 버전이 바뀌지 않았는지 확인해야 고정한 수치와 모델 패키지를 같은 근거로 연결할 수 있습니다. DVC(Data Version Control) 잠금 파일은 데이터와 처리 단계의 버전을 고정해 둔 기록입니다. 과거 평가 자료에는 직렬화한 모델 파일과 메타데이터의 무결성을 추가로 확인한 이력이 남아 있습니다. 이 검사는 고정한 평가 수치가 기존 모델 패키지에서 재현되는지를 확인한 것이며, 특성, 임계값, 정책, 평가 수치를 바꾸지 않았습니다. 보고서에는 품질 지표와 고정 모델 패키지의 해시값, 확인 범위만 기록합니다. 원래 DVC 잠금 파일 전체가 현재 저장소에서 복원됐다고 단정하지 않습니다.

MLflow를 이용한 생성 이력 확인

MLflow 화면에서는 프로필 설정값, 검증 품질 지표, 데이터셋 이력, 실행 ID를 찾아 모델이 만들어진 과정을 확인합니다. 화면에 보이는 실행 하나가 곧 공식 승인은 아닙니다. 최종 승인은 canonical-benchmark.json과 release-manifest.json이 정책, 공식 평가 자료, 승인된 모델 패키지, 실행 ID를 함께 연결할 때만 기록합니다.

질문마다 MLflow와 파일에서 확인할 경로를 대조한 뒤, 확인 범위에 맞는 문장으로 기록합니다. 대상 실행 환경은 별도 근거로 확인해야 합니다.

확인할 질문	확인 경로	보고서 문장 예시
어떤 프로필과 임계값을 비교했는가	profiles.yaml, 노트북, MLflow 프로필 실행	비교 기준 모델과 A/B에 고정된 설정을 사용했습니다.
왜 B가 승인됐는가	canonical-benchmark.json, 보호 기준 표	모든 필수 보호 기준을 통과했습니다.
어떤 모델 패키지가 승인됐는가	release-manifest.json	Candidate B 모델과 메타데이터의 SHA-256이 연결되어 있습니다.
대상 실행 환경도 B인가	3장의 API, 선언 파일, 해시값 자료	이 장의 자료만으로는 답할 수 없습니다.

보고서에 기록할 내용

보고서의 E-03 근거 행은 공식 평가에서 승인한 범위와 실행 환경에서 아직 확인하지 못한 범위를 함께 남겨야 합니다.

• 확인한 사실: Candidate A=HOLD, Candidate B=APPROVE, threshold, 보호 기준, 고정된 선언 파일
• 확인한 범위: 공식 평가에서의 모델 승인
• 아직 모르는 것: 실행 중인 모델 패키지 식별정보와 대상 환경의 운영 관측
• 다음 확인: 3장에서 API 모델 정보를, 4장에서 운영 지표를 같은 범위로 기록합니다.

이 기록만으로 Candidate B가 모든 실행 환경에서 안전하다고 선언할 수는 없습니다.