도구와 확인 결과 지도

이 과정에서 도구는 품질 판단을 대신하지 않습니다. 각 도구는 원래 맡는 책임이 있고, 그 책임을 수행하는 과정에서 관측값과 산출물을 남깁니다. 수강생은 먼저 도구가 무엇을 해결하는지 이해하고, 그다음 그 결과를 보고서에 쓸 수 있는 확인 결과로 바꾸어야 합니다.

도구를 이렇게 보는 이유는 실제 AI 서비스 품질 문제가 한 화면에서 끝나지 않기 때문입니다. 기준 데이터는 CSV와 Pandas 결과에 있고, 검증 실패는 Great Expectations 리포트에 있으며, 모델 지표는 평가 산출물(artifact)이나 MLflow 기록에 남습니다. 배포 의도는 Argo CD Application과 KServe InferenceService에 남고, endpoint 응답과 운영 변화는 로그, Prometheus, Loki, Grafana 산출물로 확인합니다. 마지막 판단은 입력 구성 변화 리포트, 배포 기준, 확인 결과로 정리됩니다.

이 문서에서는 리포트와 보고서를 구분합니다. 리포트는 데이터 검증, 입력 구성 변화, 모델 비교처럼 도구나 분석 코드가 만든 근거 산출물입니다. 보고서는 사람이 그 근거를 해석해 승인, 조건부 보류, 추가 확인 판단과 owner, next action을 정리한 문서입니다. 따라서 보고서에는 리포트 값을 그대로 복사하지 않고, 그 값이 어떤 판단을 허용하고 어떤 결론은 아직 금지하는지 함께 적어야 합니다.

1. 장별 도구와 확인 결과

장별 도구 지도는 실행 목록이 아니라 책임과 확인 결과를 구분하기 위한 기준입니다. 각 장에서 도구를 볼 때는 “무엇을 실행하는가”만 보지 않고 “이 도구가 원래 맡는 책임은 무엇이고, 그중 어떤 출력이 판단 근거가 되는가”를 함께 확인합니다. 로컬 실행 경로는 별도 표기가 없으면 tta-aiqa 루트 기준입니다.

장	도구와 실행 경로	도구가 만드는 확인 결과	QA 질문
1장 데이터 품질	Pandas, CSV, Jupyter Notebook, JupyterLite, uv/Python script	컬럼 구조, 결측치, 범위 오류, 라벨 분포, 데이터 품질 리포트	평가 가능한 데이터인가
2장 모델 품질	Great Expectations, scikit-learn 평가 코드, MLflow, Jupyter Notebook, JupyterLite	검증 실패, 혼동 행렬, Precision/Recall, FP/FN, PR-AUC, threshold, 평가 기록	지표를 신뢰할 조건인가
3장 모델 서빙	Docker, MLflow, Argo CD, KServe, GitOps manifest, /health, /predict	model URI, registry alias, Argo CD Application, KServe InferenceService, response contract	후보 모델을 GitOps로 배포할 경로가 있는가
4장 운영 관측	Structured Log, Prometheus metric, Loki, Grafana, trace, dashboard JSON	오류율, 지연 시간, 요청 수, 검증 실패, score 분포, prediction 분포, 요청 상세	후보 모델 endpoint가 배포 판단에 필요한 운영 값을 남기는가
5장 배포 판단	입력 구성 변화 리포트(drift_report.md), 배포 기준, Argo CD/KServe 확인 결과, quality issue trace, checklist	metric 기준, GitOps sync, KServe readiness, 되돌림 trigger, owner, 재평가 조건	배포, 보류, 되돌림 중 무엇인가

이 표의 핵심은 도구가 많다는 사실이 아닙니다. 모델 배포 확인 상황을 장마다 다른 확인 결과로 좁혀 간다는 점입니다. 1장은 데이터 조건, 2장은 모델 지표와 MLflow 기록, 3장은 GitOps 배포 경로, 4장은 운영 관측 신호, 5장은 배포/보류/되돌림 판단으로 이어집니다.

2. 도구별 기본 원리와 주요 책임

도구를 처음 볼 때는 이름보다 확인 범위를 먼저 잡는 것이 좋습니다. Docker는 실행 묶음, MLflow는 모델 lineage, Argo CD는 GitOps sync, KServe는 serving runtime, Grafana는 운영 현황판처럼 일단 쉬운 역할로 이해해도 충분합니다. 그다음 이 과정에서는 각 도구가 남기는 출력 중 배포 판단에 필요한 부분만 골라 사용합니다.

도구 출력은 결론이 아니라 확인한 흔적입니다. 실행 준비가 됐다는 흔적, 평가 숫자를 남겼다는 흔적, 운영 숫자가 바뀌었다는 흔적, 응답이 성공했다는 흔적은 서로 다른 의미를 가집니다. QA 보고서에서는 “어떤 도구를 봤는가”보다 “그 도구로 무엇을 확인했고, 아직 무엇은 말하면 안 되는가”를 더 중요하게 남겨야 합니다.

도구	기본 원리	주요 책임	이 과정에서 쓰는 범위	오해 방지
CSV / Parquet	데이터를 행과 열 또는 열 기반 형식(columnar format)으로 저장	분석과 학습에 사용할 데이터를 교환 가능한 파일로 보존	기준 데이터와 평가 데이터의 구조 확인	파일이 존재한다고 데이터가 평가 가능한 것은 아님
Pandas	표 형태 데이터를 메모리에서 읽고 집계, 필터링, 변환	데이터 구조 탐색과 간단한 품질 조건 확인	컬럼, 결측치, 범위, 라벨 분포 확인	Pandas 검사는 데이터 계약이나 운영 검증 체계를 대체하지 않음
Jupyter Notebook / JupyterLite	코드, 출력, 설명을 하나의 실행 문서로 묶음	분석 재현, 실습 흐름, 준비된 확인 결과 검토	브라우저에서 수치와 산출물 확인	JupyterLite 확인은 준비된 산출물 검토이며 전체 파이프라인 재생성과 다름
Great Expectations	데이터 조건을 expectation으로 선언하고 검증 결과를 리포트로 남김	데이터 규칙 검증과 실패 항목 기록	입력 데이터 조건 실패와 해석 제한 확인	검증 통과가 모델 품질 통과를 의미하지 않음
scikit-learn 평가 코드	prediction과 label을 비교해 metric 계산	모델 평가 지표와 혼동 행렬 계산	Precision, Recall, FP/FN, threshold 영향 확인	지표 계산 도구이지 운영 원인 분석 도구는 아님
MLflow	평가 실행을 기록장처럼 저장	모델 평가 이력과 버전 비교	데이터셋, 모델 버전, 판단 기준, 지표 기록 대조	기록이 있다고 운영 실행과 자동으로 일치하지 않음
Argo CD	Git에 선언된 Kubernetes 배포 파일를 cluster 상태와 동기화	GitOps 배포 관리	Application source/path, diff, sync, health 확인	sync 성공은 모델 품질 승인과 다름
KServe	Kubernetes 위에서 모델 serving resource를 관리	ML Serving endpoint 선언	InferenceService, ServingRuntime, predictor, storageUri 확인	추상화가 custom response contract를 자동 보장하지 않음
FastAPI / custom predictor	Python 기능을 웹 요청으로 호출할 수 있게 연결	요청 확인, 응답 형식, API 주소 제공	/health, /predict, 오류 응답, 추적 필드 확인	응답 성공은 기능 정상 신호이지 배포 승인 결론이 아님
Docker	프로그램, 라이브러리, 모델 파일, 설정을 하나의 실행 묶음으로 준비	동일 실행 환경과 배포 산출물 재현	포함된 파일, 실행 설정, API 응답 확인	실행 묶음 생성 성공과 실행 중 설정 확인은 다름
Kubernetes	여러 Linux node 위의 container workload를 API object로 선언하고 control plane으로 상태를 맞춤	원하는 실행 상태 유지, 설정 주입, 접근 경로 제공	manifest, spec, status, event, readiness, Service port 확인	manifest 검토는 live cluster 검증과 다름
JSONL / Structured Log	요청 단위 이벤트를 구조화된 레코드로 저장	request_id 기준 추적과 사후 분석	응답값, score, threshold, validation failure 재확인	로그가 남아도 필요한 필드가 없으면 원인 추적이 어려움
Prometheus	숫자 지표를 time series로 수집하고 query함	지연 시간, 오류율, 요청 수 같은 집계 추세 관측	운영 metric 변화 확인	집계 지표만으로 개별 요청 원인을 확정할 수 없음
Loki	구조화 로그를 검색하고 시간 범위로 조회	요청 상세와 오류 로그 검색	request_id와 validation failure 확인	로그 검색은 metric 추세의 원인 후보를 좁히는 단계임
Grafana	지표와 로그를 화면에서 함께 볼 수 있게 구성	여러 관측값을 한 화면에서 비교	준비된 화면 구성과 그래프 확인	화면이 있다는 사실이 운영 품질 관리를 보장하지 않음
입력 구성 변화/승인 산출물	기준 분포와 현재 분포, 승인 기준을 비교	원인 후보 정리와 배포 판단 기록	조건부 보류, owner, 재평가 조건 작성	입력 변화 신호만으로 원인을 단정하거나 배포를 거절하지 않음

이 표는 도구를 “품질 판단 도구”로 축소하지 않기 위한 안전장치입니다. 예를 들어 Kubernetes는 QA 전용 도구가 아니라 컨테이너 실행 상태와 접근 경로를 관리하는 운영 플랫폼입니다. 이 과정에서는 그중 image tag, ConfigMap, readiness, Service port가 품질 판단에 필요한 실행 증거로 이어지는 부분만 다룹니다.

3. 도구를 보고서 근거로 바꾸는 기준

도구 출력은 그대로 보고서가 되지 않습니다. 출력값을 보고서 근거로 쓰려면 어느 경로에서 확인했는지, 직접 실행했는지 준비된 산출물(artifact)을 읽었는지, 어떤 판단까지 말할 수 있는지를 함께 남겨야 합니다.

구분	보고서에 남길 것	쓰면 안 되는 표현
직접 실행	실행한 명령, 생성된 파일, 확인한 값	준비된 산출물만 읽고 직접 생성했다고 쓰기
JupyterLite 확인	브라우저에서 확인한 notebook, 준비된 증거 범위	전체 데이터와 전체 산출물을 재생성했다고 쓰기
Demo 검토	Dockerfile, manifest, dashboard JSON처럼 읽은 파일과 값	live 실행이나 live 배포를 검증했다고 쓰기
운영 관측 산출물	로그, 메트릭, dashboard 패널, trace preview의 값	대시보드가 있으므로 원인이 확정됐다고 쓰기
승인 판단	실패 기준, 미검증 항목, owner, 재평가 조건	단일 지표만 보고 승인 또는 거절 단정

보고서 표현은 확인 범위를 넘지 않아야 합니다. Dockerfile을 읽어 MODEL_THRESHOLD=0.5를 확인했다면 “의도된 기본 설정은 확인했다”고 쓸 수 있습니다. 하지만 실행 중 /predict 응답을 호출하지 않았다면 “운영 API의 threshold가 확인되었다”고 쓰면 안 됩니다. 같은 방식으로 Grafana dashboard JSON을 확인했다면 운영 관측 구조를 확인한 것이고, 실제 Cloud에 전송된 실시간 telemetry를 확인한 것과는 구분해야 합니다.

4. 장별로 남길 한 줄 판단

각 장의 도구 확인은 마지막에 짧은 판단 문장으로 바뀌어야 합니다. 이 문장은 다음 장에서 이어질 질문을 만듭니다.

장	한 줄 판단 예시
1장	기준 데이터는 필수 컬럼과 라벨 분포가 확인되어 모델 평가를 시작할 수 있습니다.
2장	같은 모델과 threshold에서 입력 품질 저하가 Precision, PR-AUC, FP 변화와 연결되므로 입력 품질 저하를 주요 후보로 남깁니다.
3장	MLflow candidate, Argo CD 배포 파일, KServe serving resource, endpoint response contract가 같은 후보 모델을 가리킵니다.
4장	로그와 메트릭에서 설정값 변경 후보는 약해졌고, 입력 구성 변화와 검증 실패, 지연 증가 후보가 남았습니다.
5장	현재 증거에서는 Recall과 error rate 기준 실패, 실제 확인 결과 미검증 때문에 조건부 보류 후 재평가가 필요합니다.

도구 확인이 이 문장으로 이어지지 않으면 실행은 했지만 판단 근거가 부족한 상태입니다. 강의 중에는 각 Lab과 Demo가 끝날 때 “이 도구 출력으로 어떤 문장을 쓸 수 있는가”를 계속 확인합니다.