콘텐츠로 이동

주요 용어

이 페이지는 용어를 외우기 위한 목록이 아닙니다. 본문을 읽다가 비슷한 단어가 섞이거나, 보고서에 어떤 표현을 써야 할지 헷갈릴 때 돌아와 확인하는 기준표입니다.

이 과정에서는 같은 숫자라도 데이터 품질, 모델 품질, 운영 품질에서 의미가 달라질 수 있습니다. 예를 들어 high_risk 비율이 증가했다는 사실만으로는 모델 결함, 입력 분포 변화, threshold 변경, API 검증 실패 중 무엇이 원인인지 알 수 없습니다. 그래서 용어집도 단어 뜻만 적지 않고, “QA가 무엇을 확인해야 하는가”를 함께 적습니다.

과정과 판단 흐름 용어

과정 전체는 하나의 운영 사건을 여러 장에서 다른 증거로 다시 확인하는 구조입니다. 용어를 읽을 때도 “이 단어가 어느 장의 판단 범위에서 쓰이는가”를 같이 봐야 합니다.

용어 의미 QA 관점
AI QA AI가 포함된 서비스의 데이터, 모델 출력, 서빙, 운영 신호를 함께 확인하는 품질 활동 기능 테스트 통과만으로 품질 결론을 내리지 않음
공통 운영 시나리오 과정 전체에서 반복해서 사용하는 모델 배포 확인 상황 같은 후보 모델 배포 상황을 장별 확인 결과로 좁혀 가는 기준
관측값 로그, 메트릭, 리포트에서 실제로 확인한 값 결론이 아니라 원인 후보를 세우는 출발점
원인 후보 아직 확정되지 않았지만 확인해야 하는 가능 원인 데이터, 모델, 설정, 운영 환경으로 분리
근거 판단을 뒷받침하는 실행 결과, 로그, metric, report 보고서에 파일 경로와 값으로 남김
판단 범위 특정 장이나 산출물이 말할 수 있는 결론의 한계 test metric으로 운영 current 원인을 단정하지 않음
owner 후속 확인이나 조치를 맡는 팀 또는 역할 Data Engineering, ML Engineering, Platform/MLOps 등
audit reference 나중에 판단을 재검토할 때 볼 수 있는 증거 위치 request_id, report 경로, dashboard panel
QA sign-off 품질 확인 결과를 근거와 조건으로 승인하는 행위 체크리스트 완료가 아니라 근거 기반 판단
재평가 조건 보류나 조건부 승인 뒤 다시 확인해야 하는 기준 새 data batch, 수정된 client payload, 재실행 metric
Core 반드시 설명해야 하는 핵심 개념 실습 없이도 판단 기준을 이해해야 함
Lab 수강생이 직접 따라 하는 실습 실행 결과를 보고서 근거로 사용
Demo 준비된 실행 경로와 산출물을 확인하는 과정 직접 구현보다 판단 포인트 확인
Mention 시간이 부족하면 언급만 하고 넘어가는 주제 깊은 구현이나 운영 심화는 제외

데이터와 라벨 용어

데이터 용어는 1장과 2장에서 가장 많이 등장하지만, 4장과 5장의 운영 판단에서도 계속 사용됩니다. 특히 baseline, current, label, feature는 보고서에서 의미를 좁혀 써야 합니다.

용어 의미 실습 또는 보고서 예시
원본 데이터(raw data) 외부에서 받은 최초 데이터 Kaggle Human Vital Sign Dataset
교육용 표준 데이터 과정에서 쓰기 위해 컬럼, label, split을 정리한 데이터 data/vital_signs_standardized.csv
데이터 계보(data lineage) 데이터와 산출물이 어떤 입력에서 만들어졌는지 나타내는 관계 configs/lineage/course_data_lineage.yaml
lineage manifest 데이터 계보를 파일로 관리하는 manifest 어떤 report가 어떤 데이터에서 생성됐는지 확인
특성(feature) 모델 입력으로 사용하는 값 heart_rate, oxygen_saturation
파생 특성(derived feature) 원본 컬럼을 계산해 만든 모델 입력 전처리나 feature engineering 결과
라벨(label) 모델 평가에서 정답으로 보는 값 high_risk, low_risk
라벨 표준화 원본 label 값을 평가에 쓰는 class 값으로 정리하는 작업 High Risk를 high_risk로 통일
클래스(class) label이나 prediction이 가질 수 있는 범주 high_risk, low_risk
관심 클래스(Positive class) 모델이 찾으려는 주요 class high_risk
비교 클래스(Negative class) 관심 class가 아닌 비교 기준 class low_risk
관심 클래스 표본 수(Positive support) 평가 데이터 안의 관심 class sample 수 high_risk sample 수
sample 데이터 한 행 또는 요청 한 건 평가 sample, 운영 요청 sample
결측값(missing value) 필요한 값이 비어 있는 상태 산소포화도 값 누락
이상치(outlier) 일반 범위에서 크게 벗어난 값 0~100 범위를 벗어난 산소포화도
범위 검증(range check) 값이 허용 범위 안에 있는지 확인하는 규칙 oxygen_saturation 0~100
데이터 타입(data type) 컬럼 값의 자료형 숫자형, 문자열형
스키마(schema) 데이터나 API 입력이 가져야 할 필드와 타입 구조 필수 컬럼, JSON request 구조
데이터 계약(data contract) producer와 consumer가 합의한 데이터 구조와 의미 API 입력 필드와 허용 범위
클래스 불균형(class imbalance) class별 sample 수가 크게 다른 상태 low_risk가 대부분인 평가 데이터
입력 출처(source) 데이터가 들어온 시스템이나 경로 partner-feed-v2, upstream feed

기준선과 데이터 분할 용어

기준선은 하나의 단어처럼 보이지만 장마다 층위가 다릅니다. 용어를 정확히 나누지 않으면 “기준 데이터가 정상이다”라는 문장을 운영 입력까지 정상이라는 뜻으로 잘못 읽을 수 있습니다.

용어 의미 쓰는 위치
기준선(baseline) 현재 상태와 비교하기 위한 기준 장별로 의미가 다름
현재 상태(current) 지금 확인 중인 운영 입력이나 운영 관측값 4장, 5장
evaluation_baseline_data 1장에서 모델 평가를 시작해도 되는지 보는 기준 데이터 데이터 품질 확인
model_valid_baseline 2장에서 설정 후보와 threshold 후보를 비교하는 validation 기준 모델 평가
model_test_baseline 선택된 모델과 threshold를 마지막으로 확인하는 test 기준 최종 모델 평가
operational_baseline 현재 운영 입력 sample과 비교할 평소 운영 분포 4장, 5장
deployment_holdout_baseline 최종 배포/보류 재평가에 쓰는 holdout 기준 배포 판단
train 모델을 학습하는 데이터 분할 2장 모델 학습
valid_baseline 설정 후보를 고르는 validation 데이터 threshold와 FP/FN 비교
test 선택된 모델과 threshold를 마지막으로 평가하는 데이터 최종 metric 확인
operational_holdout 모델 개발에서 제외하고 운영 입력과 로그를 만드는 데이터 3장부터 5장
valid_degraded validation 기준에서 품질 저하 조건을 재현한 데이터 데이터 조건 변화 영향 비교
current batch 현재 조사 중인 운영 요청 묶음 operational_current_events.jsonl

데이터 검증과 산출물 용어

데이터 검증 도구는 도구 자체보다 어떤 규칙이 실패했고 그 실패가 모델 평가나 운영 판단에 어떤 영향을 주는지가 중요합니다. 이 과정에서는 Great Expectations와 Pandas를 품질 근거를 만드는 도구로 다룹니다.

용어 의미 QA 관점
Pandas 표 형태 데이터를 읽고 검사하는 Python 라이브러리 결측, 타입, 분포 확인
DataFrame Pandas에서 표 데이터를 다루는 기본 구조 컬럼과 행 기준 품질 확인
Notebook 셀 단위로 실행하고 결과를 확인하는 실습 문서 실행 과정과 출력 확인
CLI script 터미널에서 실행하는 Python 스크립트 같은 산출물을 반복 생성
Great Expectations 데이터 규칙을 정의하고 검증 결과를 만드는 도구 규칙 실패와 severity 해석
expectation Great Expectations에서 하나의 데이터 검증 규칙 null 금지, 범위 제한, 값 집합 제한
validation result expectation 실행 결과 어떤 규칙이 통과/실패했는지 확인
Data Docs Great Expectations 검증 결과를 HTML로 보여주는 문서 실패 규칙을 사람이 읽기 쉽게 확인
품질 리포트 데이터 품질 확인 결과를 요약한 근거 산출물 모델 평가 진행 가능 여부 판단
JSON 구조화 데이터를 저장하거나 주고받는 형식 API request, 평가 결과
JSONL 한 줄에 JSON 하나씩 저장하는 로그/이벤트 형식 운영 예측 event log
YAML 설정값이나 manifest를 사람이 읽기 쉽게 적는 형식 검증 규칙, lineage manifest
Markdown 보고서 Markdown으로 작성한 분석 또는 QA 판단 문서 수강생 최종 산출물
config 실행 조건을 담은 설정 파일 feature 목록, threshold, Grafana endpoint
severity 검증 실패나 품질 이슈의 심각도 release 판단 우선순위

모델 출력과 평가 지표 용어

모델 품질 용어는 score, threshold, prediction, label, metric의 순서를 지켜 읽어야 합니다. 이 순서가 섞이면 threshold 문제를 모델 문제로 오해하거나, prediction 변화만 보고 label 성능 변화를 단정할 수 있습니다.

용어 의미 QA 관점
점수(score) 관심 class일 가능성을 나타내는 모델 출력 risk_score = 0.72
임계값(threshold) score를 최종 class로 바꾸는 기준 score >= 0.50이면 high_risk
예측(prediction) threshold 적용 후의 최종 class high_risk 예측
metric prediction과 label을 비교해 계산한 품질 수치 Accuracy, Precision, Recall
Accuracy 전체 sample 중 맞게 예측한 비율 class imbalance가 있으면 단독 판단 금지
Precision 관심 class로 예측한 것 중 실제 관심 class 비율 알림이 얼마나 정확한지 확인
Recall 실제 관심 class 중 모델이 찾아낸 비율 놓친 관심 class가 얼마나 적은지 확인
F1-Score Precision과 Recall의 조화 평균 두 지표 균형 참고
Confusion Matrix TP, TN, FP, FN을 함께 보여주는 표 오류 방향 분리
TP 관심 class를 관심 class로 맞게 예측 탐지 성공
TN 비교 class를 비교 class로 맞게 예측 비탐지 성공
FP 비교 class를 관심 class로 잘못 예측 과도한 탐지
FN 관심 class를 비교 class로 잘못 예측 놓친 탐지
AUROC 여러 threshold에서 전반적 구분력을 보는 지표 해석 중심으로만 사용
PR-AUC Precision-Recall 곡선 아래 면적 class imbalance 상황에서 참고
Calibration score가 실제 확률처럼 해석 가능한지 보는 관점 Mention 깊이로만 다룸
threshold analysis threshold를 바꿨을 때 FP/FN과 Precision/Recall이 어떻게 변하는지 보는 분석 승인 기준 선택 근거

모델 버전과 실험 기록 용어

모델 품질 판단은 숫자만으로 끝나지 않습니다. 어떤 데이터, 어떤 모델, 어떤 threshold, 어떤 metric을 기록했는지 남아야 같은 판단을 다시 확인할 수 있습니다.

용어 의미 QA 관점
모델 산출물(model artifact) 학습 후 서빙에 사용하는 모델 파일과 관련 설정 재현과 배포 추적
model_version 응답이나 로그에 남기는 모델 버전 승인된 모델이 배포됐는지 확인
실험 기록(experiment record) 데이터셋, 모델, threshold, metric을 함께 기록한 자료 MLflow 또는 JSON artifact
MLflow 실험 조건과 metric을 기록하고 비교하는 도구 도구 운영보다 비교 근거가 핵심
run 한 번의 학습 또는 평가 실행 기록 같은 조건을 재현하는 단위
artifact 실행 결과로 남는 파일 model_test_eval.json, drift_report.md
재현 가능성(reproducibility) 같은 입력과 설정으로 같은 결과를 다시 만들 수 있는 성질 평가와 배포 승인 추적성
품질 회귀(regression) 변경 뒤 이전보다 품질 기준이 나빠진 상태 데이터셋, label, 모델 버전, threshold 변경 영향 확인

서빙과 API 용어

서빙 용어는 모델 파일을 API로 제공하는 구조를 이해하기 위한 단어입니다. QA는 API가 200 응답을 반환하는지뿐 아니라, 어떤 모델 버전과 threshold가 쓰였고 입력 feature가 학습 때와 일치하는지 확인해야 합니다.

용어 의미 QA 관점
서빙(serving) 학습된 모델을 API나 서비스 형태로 제공하는 실행 구조 모델이 실제 요청에 응답하는 구간
추론(inference) 입력 feature로 score와 prediction을 생성하는 실행 응답 필드와 latency 확인
API 클라이언트가 모델 서비스에 요청을 보내는 인터페이스 요청/응답 계약 확인
endpoint API가 요청을 받는 경로 /predict
client API를 호출하는 쪽 운영 앱, partner feed
server API 요청을 처리하는 쪽 API wrapper 또는 model server
request API에 들어오는 입력 JSON payload
response API가 반환하는 결과 score, threshold, prediction
payload request나 event에 담긴 실제 데이터 본문 JSON 요청 body
HTTP status code API 처리 결과를 나타내는 상태 코드 200, 400, 500
오류 응답(error response) API가 실패 이유를 구조화해 반환한 응답 입력 오류와 서버 오류 분리
FastAPI Python 기반 API framework custom predictor나 local smoke wrapper 구현 때만 확인
OpenAPI API schema와 endpoint를 문서화하는 표준 형식 입력/응답 구조 확인
모델 로더(model loader) 모델 artifact를 읽어 서빙 앱에 올리는 코드 의도한 모델 파일 사용 여부
특성 정렬(feature alignment) 학습 때 feature 순서와 서빙 입력 feature 순서를 맞추는 일 학습-서빙 입력 불일치 방지
학습-서빙 입력/기준 불일치 학습 때 처리한 입력이나 threshold 기준과 서빙 때 처리한 조건이 달라지는 문제 schema, 전처리, threshold 일치 확인
환경 변수(environment variable) 실행 환경에서 주입하는 설정값 MODEL_VERSION, Grafana endpoint

컨테이너와 배포 용어

컨테이너와 Kubernetes는 이 과정에서 운영 심화 주제가 아니라 동일 실행 환경과 배포 흐름을 확인하기 위한 배경 지식입니다. QA는 image 내부 구현보다 모델 파일, 환경 변수, API 응답, 로그가 일관되는지 확인합니다.

용어 의미 QA 관점
컨테이너(container) 애플리케이션과 실행 환경을 함께 격리해 실행하는 단위 같은 환경 재현
이미지(image) 컨테이너를 만들기 위한 실행 템플릿 어떤 코드와 모델이 들어갔는지 확인
Dockerfile 이미지를 만드는 절차를 적은 파일 모델 파일 복사, 실행 명령 확인
Docker Compose 여러 컨테이너를 함께 실행하는 설정 Alloy와 서빙 앱 실행
Kubernetes 여러 Linux node 위의 container workload를 API object로 선언하고 원하는 상태로 맞추는 cluster control plane spec, status, event, readiness를 분리해 확인
etcd Kubernetes cluster object 상태를 저장하는 key-value store live state를 주장할 때 cluster 상태 저장 계층이 있음을 이해
Pod Kubernetes에서 컨테이너를 담는 최소 실행 단위 모델 서버가 어디서 실행되는지 이해
scheduler Pod를 실행할 node를 선택하는 control plane 구성요소 Pending 원인이 배치 조건인지 확인
controller 원하는 상태와 실제 상태의 차이를 줄이는 control loop replica, condition, reconcile 실패 원인 확인
Deployment Pod 복제와 배포 상태를 관리하는 Kubernetes 리소스 배포 흐름 확인
manifest Kubernetes 리소스나 설정을 선언한 파일 제공된 설정 구조 확인
rollout 새 버전을 운영에 반영하는 배포 과정 배포 전후 품질 비교

로그, 메트릭, 트레이싱 용어

운영 환경에서는 label을 즉시 알 수 없는 경우가 많습니다. 그래서 로그, 메트릭, 트레이싱을 함께 보며 “무슨 요청에서 어떤 변화가 발생했는가”를 추적합니다.

용어 의미 확인 목적
로그(log) 개별 사건이나 요청의 상세 기록 특정 요청의 입력, 응답, 실패 사유 확인
구조화 로그(structured log) JSON처럼 field를 가진 로그 request_id, score, prediction 조회
메트릭(metric) 시간 흐름에 따라 집계해 보는 수치 오류율, 지연 시간, 분포 변화 확인
트레이싱(tracing) 요청이 여러 처리 단계를 지나간 경로를 추적하는 방식 어느 단계에서 지연이나 실패가 생겼는지 확인
trace 요청 하나의 전체 처리 흐름 대표 요청 분석
span trace 안의 개별 처리 단계 input-validator, model-runtime
request_id 요청 하나를 추적하기 위한 ID 로그와 응답 연결
trace_id trace를 식별하는 ID Loki 로그와 Tempo trace 연결
latency 요청에 대한 응답 지연 시간 운영 성능 저하 확인
error rate 요청 중 오류가 발생한 비율 API 기능 또는 운영 장애 확인
validation failure 입력 schema나 데이터 규칙 실패 입력 품질 또는 API 계약 문제 확인
score distribution 운영 요청에서 score가 분포하는 모습 모델 출력 변화 확인
prediction distribution 운영 요청에서 prediction이 분포하는 모습 특정 class 급증 확인

Grafana Cloud 데모 용어

Grafana Cloud 데모는 도구 사용법을 외우는 시간이 아니라, Logs, Metrics, Traces가 각각 어떤 증거를 제공하는지 확인하는 과정입니다. 수강생은 tool 이름보다 어떤 질문에 답하는 자료인지 먼저 봅니다.

용어 의미 이 과정에서 보는 것
Grafana 로그, metric, trace를 dashboard로 묶어 보는 도구 Overview와 Details dashboard
Grafana Cloud Grafana, Loki, Prometheus, Tempo를 managed service로 제공하는 환경 수업 demo의 실제 연결 대상
Cloud Portal Grafana Cloud stack과 datasource 정보를 확인하는 웹 화면 URL, User, token 생성 위치 확인
stack Grafana Cloud에서 하나의 Grafana instance와 관련 datasource 묶음 GRAFANA_CLOUD_URL 확인
dashboard 여러 panel을 한 화면에 배치한 관측 화면 이상 후보를 찾는 출발점
panel dashboard 안의 개별 시각화 단위 Request Count, Service Topology Map
datasource Grafana panel이 질의하는 데이터 원천 Prometheus, Loki, Tempo
Loki 로그 저장과 조회를 담당하는 Grafana 생태계 도구 validation failure 로그 조회
LogQL Loki 로그를 조회하는 query 언어 {service="ai-quality-serving"} | json
Prometheus metric 수집과 조회를 담당하는 도구 ai_quality_high_risk_rate 조회
PromQL Prometheus metric을 조회하는 query 언어 sum(...) by (...)
scrape Prometheus 방식으로 /metrics endpoint를 주기적으로 읽는 동작 Alloy가 serve_metrics.py를 읽음
remote_write 수집한 metric을 원격 Prometheus 저장소로 보내는 방식 Grafana Cloud Metrics 전송
Tempo trace 저장과 조회를 담당하는 Grafana 생태계 도구 대표 요청 trace 확인
TraceQL Tempo trace를 조회하는 query 언어 { .course_trace_id = "..." }
Alloy 로그, metric, trace를 수집해 Grafana Cloud로 보내는 collector course demo의 기본 전송 경로
OTLP OpenTelemetry 데이터를 보내는 프로토콜 trace를 Alloy receiver로 전송
service graph trace에서 client/server 호출 관계를 metric으로 만든 그래프 데이터 topology map의 입력
topology map 서비스 간 호출 관계를 node와 edge로 보여주는 화면 qa-client -> ai-quality-serving
node graph Grafana에서 node와 edge 관계를 시각화하는 panel type Service Topology Map
Access Policy token Logs, Metrics, Traces write scope로 생성하는 telemetry 전송 token GRAFANA_TELEMETRY_TOKEN
Service Account token Grafana HTTP API로 dashboard를 만들거나 수정할 때 쓰는 token GRAFANA_DASHBOARD_TOKEN
Basic Auth username과 password/token으로 인증하는 방식 Grafana Cloud datasource 전송 인증
instance id Grafana Cloud datasource가 Basic Auth username으로 요구하는 숫자 Logs/Metrics/Tempo마다 다를 수 있음
region Grafana Cloud endpoint에 포함된 배포 지역 정보 endpoint URL에서 확인

Drift와 운영 이상 용어

Drift는 원인 확정 문장이 아니라 조사 신호입니다. 입력 분포가 달라졌다는 사실과 모델이 잘못됐다는 결론은 다르므로, score, prediction, validation failure, latency를 함께 봐야 합니다.

용어 의미 QA 관점
드리프트(drift) 기준선과 현재 분포나 값이 달라진 상태 원인 후보이지 최종 원인 아님
데이터 드리프트(data drift) 모델 입력 feature 분포가 달라진 상태 입력 출처, 수집 기간, 전처리 확인
예측 드리프트(prediction drift) prediction 분포가 달라진 상태 threshold와 score 분포를 함께 확인
모델 드리프트(model drift) 모델 성능 자체가 시간이 지나며 나빠지는 현상 label 지연 환경에서는 단정 주의
입력 분포(input distribution) 운영 요청 feature 값들이 퍼져 있는 모습 baseline/current 비교
히스토그램(histogram) 값을 bucket으로 나눠 count를 보는 분포 표현 어떤 구간이 늘었는지 확인
bucket histogram에서 값을 묶는 구간 0.2-0.4, 83.40~91.20
delta 기준선과 현재 값의 차이 high_risk_rate_delta
current sample 현재 조사 중인 운영 sample 120건 incident sample 또는 streaming sample
streaming 실행 중 data를 계속 추가로 보내는 방식 dashboard 값이 계속 갱신됨
KDE 또는 density plot raw data로 부드러운 분포 곡선을 계산해 보여주는 방식 Grafana metric dashboard에서는 기본 범위 밖

릴리스 판단과 체크리스트 용어

5장은 “좋다/나쁘다”를 말하는 장이 아니라, 승인할 수 있는 조건과 보류해야 하는 조건을 근거로 나누는 장입니다. 용어를 읽을 때는 approval risk와 hold risk를 함께 봐야 합니다.

용어 의미 보고서에서의 사용
배포 판단 배포 승인 전 품질 기준을 확인하는 관문 통과, 조건부 보류, 보류 판단
승인(approval) 정해진 기준을 충족해 배포 진행을 허용하는 판단 근거와 모니터링 조건이 필요
보류(hold) 근거 부족이나 리스크 때문에 배포를 멈추는 판단 owner와 재평가 조건이 필요
조건부 보류 문제 후보를 확인할 때까지 제한적으로 보류하는 판단 추가 확인 후 재평가
approval rule 승인/보류를 판단하는 규칙 metric 기준, validation failure 기준
acceptance criteria 통과해야 하는 품질 기준 오류율, latency, FP/FN 기준
approval risk 잘못 승인했을 때 생기는 위험 품질 저하 노출, 고객 신뢰 저하
hold risk 잘못 보류했을 때 생기는 위험 출시 지연, false alarm, 비용 증가
회귀 테스트(regression test) 변경 뒤 기존 품질 기준이 유지되는지 확인하는 테스트 데이터셋, label, 모델 버전, threshold 변경 영향
QA 체크리스트 최종 판단 전에 확인할 항목 묶음 근거를 대체하지 않고 누락 방지에 사용
보고서 문장 관측값, 후보, 판단, 후속 조치를 연결한 문장 “현재는 입력 구성 변화 후보가 남아 있어 조건부 보류합니다”

헷갈리기 쉬운 용어 구분

아래 표는 본문에서 가장 자주 섞이는 용어를 정리한 것입니다. 보고서에 쓸 때는 왼쪽과 오른쪽을 서로 대체하지 않습니다.

구분 서로 다른 점 잘못 쓰면 생기는 문제
score와 prediction score는 모델 출력 점수이고, prediction은 threshold 적용 후 class입니다 prediction 변화만 보고 score 변화라고 오해
prediction과 label prediction은 모델의 판단이고, label은 평가 정답입니다 운영 prediction 분포를 성능 지표로 오해
threshold와 model_version threshold는 class 변환 기준이고, model_version은 사용한 모델 식별자입니다 설정 변경과 모델 변경을 섞음
metric과 log metric은 집계 수치이고, log는 개별 요청 기록입니다 집계 이상을 개별 원인으로 단정
request_id와 trace_id request_id는 요청 식별, trace_id는 처리 흐름 식별입니다 로그와 trace 연결 실패
baseline과 current baseline은 비교 기준, current는 현재 조사 대상입니다 기준 데이터 정상 결론을 운영 정상으로 과장
validation failure와 model error validation failure는 입력 계약 실패이고, model error는 모델 처리 실패입니다 클라이언트 입력 문제를 모델 문제로 오해
data drift와 prediction drift data drift는 입력 변화, prediction drift는 출력 class 분포 변화입니다 입력 원인과 출력 결과를 뒤섞음
리포트와 보고서 리포트는 도구나 분석 코드가 만든 근거 산출물이고, 보고서는 사람이 근거를 해석한 판단 문서입니다 리포트 값을 복사하고 판단, 리스크, 다음 조치를 빠뜨림
dashboard와 보고서 dashboard는 관측 화면이고, 보고서는 판단 근거 문서입니다 화면 값을 결론으로 바로 복사
approval과 hold approval은 진행 허용, hold는 보류 판단입니다 리스크와 재평가 조건 누락

용어를 정확히 쓰는 목적은 표현을 멋지게 만드는 것이 아니라, 판단 범위를 지키는 것입니다. 수강생은 용어를 외우기보다 “이 단어가 어떤 증거와 어떤 결론까지 허용하는가”를 기준으로 읽으면 됩니다.