5-8. 최종 배포 판단 기록 완성하기¶
최종 산출물은 승인 또는 보류 한 단어가 아니라, 다른 담당자가 같은 근거를 다시 찾아 판단 범위와 한계를 검토할 수 있는 기록입니다. 이 페이지에서는 앞 단계에서 확인한 데이터, 모델 평가, 실행 환경, 운영 신호를 한 문서에 연결하되 서로 다른 결론을 섞지 않습니다.
최종 기록은 배포 회의 전에 작성해 다음 담당자에게 넘길 수 있어야 합니다. 확인하지 못한 값은 추정으로 채우지 않고 미확인과 필요한 자료, 담당자, 재평가 조건을 남기는 것이 정확한 결과입니다. 실제 작업본 생성과 제출 점검은 배포 판단 기록 실습에서 이어집니다.
다른 서비스에도 재사용할 확인 순서¶
AI 서비스의 도구와 입력이 달라도 판단의 순서는 재사용할 수 있습니다. 먼저 데이터 범위를 고정하고, 그 범위에서 계산 가능한 지표를 확인한 뒤, 실제 실행 모델, 배포 상태, 운영 신호를 차례로 대조합니다.
각 단계는 앞 단계의 답을 넓히지 않는 역할을 합니다. 아래 표의 질문에 한 줄씩 답하면 마지막 화면 하나나 단일 지표가 전체 품질을 대신하는 일을 막을 수 있습니다.
| 확인 순서 | 먼저 답할 질문 | 기록에 남길 결론 | 다음 단계가 필요한 이유 |
|---|---|---|---|
| 데이터 범위 | 어떤 표본, 환경, 시각을 보았는가 | 자료가 지지하는 범위와 미확인 범위 | 다른 자료의 값을 섞지 않음 |
| 지표 계산 | 정답이 있어 계산 가능한 지표는 무엇인가 | 계산한 값과 계산 불가 항목 | 분포 관찰을 성능으로 과장하지 않음 |
| 실행 모델 | 실제로 어떤 모델과 임계값이 실행됐는가 | 모델 식별 정보의 일치 또는 불일치 | 평가 결과가 다른 모델에 붙지 않음 |
| 배포 상태 | 대상 환경에서 준비와 요청 처리가 확인됐는가 | 직접 확인한 운영 환경 상태 | 선언 파일을 실행 성공으로 바꾸지 않음 |
| 운영 신호 | 같은 범위의 오류와 지연 신호가 있는가 | 운영 영향 또는 관측 공백 | 모델 문제와 관측 문제를 구분함 |
이 순서는 암기용 절차가 아니라 결론의 범위를 지키는 검사 순서입니다. 예를 들어 정답 없는 운영 표본에서는 분포 변화까지만 기록하고, 대상 환경 자료가 없으면 모델 승인을 유지하되 운영 상태는 target_pending으로 남깁니다.
대상이 달라도 지키는 최종 기록 원칙¶
최종 기록은 이번 생체신호 기반 위험 알림 시스템의 수치와 도구를 복사하는 문서가 아니라, 질문과 근거와 실행 상태를 분리하는 산출물입니다. 작업본은 tta-aiqa 루트의 labs/record.md 양식에서 만들어 artifacts/reports/release-decision-record.md에 저장하며, 직접 확인한 범위에 맞춰 채웁니다.
제출 전에는 아래 다섯 영역이 모두 있는지 확인합니다. 표의 항목은 한 줄 결론을 더 길게 쓰기 위한 목록이 아니라, 회의에서 근거를 다시 열고 다음 행동을 정할 수 있게 만드는 최소 구성입니다.
| 최종 기록 영역 | 반드시 남길 내용 | 이번 사례에서의 작성 방향 |
|---|---|---|
| 사건 질문과 판단 변화 | 처음 관측, 새 근거, 바뀐 판단, 남은 질문 | 같은 100건에서 3→6, score P95 0.3859→0.5133을 분포 변화로 기록 |
| 근거 목록 | 직접 확인한 사실, 자료 경로와 시각, 미확인 | 정적 자료인지 실제 대상 자료인지 구분 |
| 최종 판단 | 모델 승인, 운영 환경 확인 상태, 현재 권고, 양쪽 위험 | Candidate A=HOLD, Candidate B=APPROVE, 운영 상태=target_pending, 대상 자료 수집 뒤 재검토 |
| 다음 행동 | 담당 팀, 필요한 자료, 기한, 재평가 또는 복구 검토 조건 | 서빙·플랫폼·데이터 담당의 자료와 판단 재개 조건 |
| 검토 메타데이터 | 판단한 절대 시각, 검토자와 검토 결과, 핵심 근거의 버전 또는 해시 | 나중에 같은 자료와 판단을 다시 찾을 수 있는 값 |
이번 사례의 최종 문장은 “Candidate B는 고정 평가에서 승인되었으나 대상 환경의 실행 자료가 없어 운영 상태는 target_pending이며, 정답 없는 100건 비교의 원인은 미확정이므로 대상 자료를 수집한 뒤 운영 결정을 다시 연다”처럼 쓸 수 있습니다. 이 문장은 모델 승인, 운영 상태, 원인 해석을 분리하고, 잘못 승인할 위험과 지나치게 보류할 위험을 다음 회의에서 함께 검토할 수 있게 합니다.
대상이 다른 AI 서비스로 바뀌면 수치, 데이터 규약, 담당 팀, 허용 기준은 새로 정해야 합니다. 그러나 어떤 자료가 질문을 지지하는지, 어떤 계산이 가능한지, 실제 실행 상태를 확인했는지, 미확인을 어떻게 인계하는지를 분리하는 원칙은 그대로 유지합니다.
새 운영 사실로 판단 갱신하기
6교시 요청 조사와 7교시 운영 판단을 마친 뒤 다음 사실만 사용합니다. 새 조회를 실행하거나 숨은 정답을 가정하지 않습니다.
- 후보별 공식 모델 승인은 그대로 유지합니다.
- 대상
/v1/model은 기록된 시각에 Candidate B의 프로필, 버전, 임계값을 반환했고, 별도 배포 선언은 Candidate B의 전체 SHA-256을 가리킵니다. - 같은 URL의 규약에 맞는 요청 한 건은 HTTP 200과 요청 식별값을 반환했습니다.
- 같은 UTC 범위의 대시보드에는 기존 운영 모델 버전이 표시되지만, 그 요청의 로그에는 Candidate B 버전이 기록되어 있습니다.
- 같은 요청의 처리 경로는 찾지 못했고 운영 요청의 정답도 없습니다.
이 카드는 모델 승인을 다시 계산하는 문제가 아니라, 서로 충돌하는 운영 자료가 들어왔을 때 바뀌는 판단만 가르는 회고 과제입니다. 200 한 건으로 대상 배포 완료를 선언하거나, 대시보드의 모델 버전만 보고 즉시 복구를 지시하지 않습니다. 현재 근거는 운영 환경 확인 상태와 다음 조사 범위를 다시 열게 하지만, 정답 기반 성능이나 단일 원인을 확정하지 않습니다.
작업본에는 다음 여섯 줄만 추가합니다. 요청 식별값이나 환경 식별자를 공개 답안에 복사하지 않고, 확인한 자료의 위치와 범위로 바꿔 적습니다.
- 직접 확인한 사실:
- 아직 모르는 사실:
- 바뀌는 판단 항목:
- 양쪽 위험의 변화:
- 현재 권고:
- 담당자·필요 자료·재평가 조건:
동료 검토에서는 모델 승인이 새 공식 평가 없이 바뀌지 않았는지, 운영 상태가 확인 범위를 넘지 않았는지, 플랫폼과 서빙 담당자가 같은 모델 정보와 새 시간대에서 요청·지표·로그·처리 경로를 다시 연결할 조건이 있는지 확인합니다. 이 여섯 줄이 질문, 근거, 실행 상태와 양쪽 위험을 분리하면 대상이 다른 서비스여도 같은 회고 원칙을 재사용할 수 있습니다.