콘텐츠로 이동

강의 순서

이 과정은 하루 7교시, 총 14교시입니다. 수업 중에는 아래 현재 교시의 링크만 따라갑니다. 문서는 더 작은 단위로 나뉘어 있으므로, 필요한 절만 읽고 실행합니다.

모든 교시는 같은 사건을 이어갑니다. 운영 중인 기존 모델의 high_risk 예측 비율이 늘어난 상태를 확인하는 일입니다. 매 교시가 끝나면 확인한 사실과 아직 모르는 것을 구분해서 적습니다. 칸을 나누는 방법은 5-8 최종 기록에서 확인합니다.

마지막 교시에는 모델 평가에서 승인할 수 있는 범위와, 실제 서비스에서 확인한 범위를 따로 결론냅니다.

회귀 검사, 시험 데이터, 운영 사례는 7교시 판단을 마친 뒤에 읽습니다.

이 페이지를 읽는 방법

수업 중에는 현재 교시의 링크만 따라갑니다. 개념이나 실습이 막힐 때에만 상세 페이지를 엽니다. 교시가 끝나면 확인한 사실과 아직 모르는 것을 적고, 같은 내용을 장마다 다시 쓰지 않습니다.

교시가 끝날 때

확인한 사실 한 가지와 그 근거, 아직 모르는 것 한 가지, 다음 교시에 볼 자료 한 가지를 적습니다. 실행이 막혔다면 막힌 이유와 필요한 환경을 남깁니다.

1일차 오전: AI 품질과 데이터 품질

첫째 날 오전에는 운영 신호만 보고 모델을 바꾸지 않기 위해, 비교에 쓸 데이터부터 확인합니다. 원본, 가공 데이터, 분할의 역할을 구분하고, 실제 구조와 품질 문제를 관찰합니다.

3교시는 결측을 없애거나 이상치 후보를 자동 삭제하는 활동이 아닙니다. 모델 평가 전에 무엇을 사실로 남기고 무엇을 더 볼지 정리합니다.

오전 세 교시에서 확인하는 질문은 다음과 같습니다.

  1. 지금 사건에서 어떤 품질 신호가 달라졌는가
  2. 비교에 쓰는 데이터가 어떤 범위와 한계를 가지는가
  3. 관측한 데이터 문제를 어떻게 남길 것인가

1교시 · AI 품질과 이상 신호

  • 질문: high_risk 예측 비율이 늘었다는 신호만으로 모델을 바꿔도 될까요?
  • 이 교시에서: 실습 환경 준비에서 만든 내 공개 Risk API로 /docs를 열고 /health/ready와 /v1/model을 GET합니다. 예측 요청은 측정한 특성만 넣어 볼 수 있지만, 그 점수만으로 원인을 단정하지 않습니다. AI 품질과 이상 신호에서 기능 정상과 예측 품질을 구분한 뒤 문제의 시작의 비교 표에서 변화 전후 값과 아직 모르는 원인을 확인합니다.
  • 확인할 것: 공개 HTTPS가 기준 모델로 응답하는 사실과, 준비된 비교 표의 예측 비율 변화를 다른 질문으로 둡니다. 공개 베이스와 로컬 실행 주소를 구분하고, 입력, 요청, 실행 환경, 모델은 아직 열린 원인 후보로 둡니다.
  • 적을 것: 내 공개 베이스 URL, /v1/model의 profile과 version, 비교 표에서 확인한 값과 숫자의 출처 경로를 적습니다.
  • 막히면: 공개 API가 없으면 target_pending과 막힌 이유를 남기고, 비교 표의 값은 파일에서 옮깁니다. 출처 경로를 확인하지 못했으면 그 사실을 남깁니다.

2교시 · 데이터의 네 가지 역할

  • 질문: 후보 모델을 비교하기 전에 어떤 데이터 조건이 같아야 할까요?
  • 이 교시에서: 데이터의 네 가지 역할과 데이터 역할과 분할에서 학습, 검증, 최종 평가, 운영 자료의 역할을 구분합니다.
  • 확인할 것: 같은 행 수라도 역할과 정답 유무가 다르면 근거를 합칠 수 없습니다.
  • 적을 것: 평가 전에 고정할 데이터 역할과 아직 모르는 영향을 적습니다.
  • 막히면: 분할을 다시 만들지 않고, 현재 분할의 역할별 건수와 정답 유무까지 확인합니다.

3교시 · 원시 측정값과 데이터 오류

  • 질문: 실제 평가 자료에는 어떤 결측, 값의 범위, 라벨 구성이 있나요?
  • 이 교시에서: 결측값, 이상치, 라벨과 클래스 구성을 읽은 뒤 원시 측정값과 데이터 오류를 위에서 아래로 실행합니다.
  • 확인할 것: 결측, 이상치 후보, 라벨, 클래스 구성의 관측값을 확인합니다.
  • 적을 것: 실행한 범위, 관측값, 모델 평가 전에 남은 질문을 적습니다.
  • 막히면: 노트북 실행 오류와 마지막 성공 위치까지 적고, 문서의 기준값은 준비된 근거로만 읽습니다.

오전이 끝나면 데이터 검증 결과가 Candidate A나 B의 승인을 뜻하지 않는다는 점을 설명할 수 있어야 합니다. 오후에는 같은 데이터 범위를 유지한 채 자동 검증과 모델 평가로 넘어갑니다.

1일차 오후: 자동 검증과 모델 품질

첫째 날 오후에는 사람이 본 데이터 조건을 반복 가능한 검사로 바꾸고, 같은 평가 조건에서 후보 모델을 비교합니다. 지표는 숫자를 많이 아는 도구가 아니라, 관심 클래스의 놓침과 잘못된 경보를 어떤 위험으로 볼지 설명하는 근거입니다.

개발용 실습은 지표가 만들어지는 과정을 보는 활동입니다. 두 후보의 승인 여부는 미리 확정한 평가 자료로 확인하며, 두 숫자를 섞지 않습니다.

오후 네 교시에서는 다음 구분을 유지합니다.

  • 자동 검증은 데이터 규약이 맞는지 확인합니다.
  • 개발용 실습은 지표가 어떻게 계산되는지 익힙니다.
  • 공식 평가 기록은 후보 승인 결론을 확인합니다.

4교시 · 데이터 검증 자동화

  • 질문: 사람이 확인한 데이터 조건을 반복 가능한 검사로 만들 수 있을까요?
  • 이 교시에서: 데이터 검증 자동화를 실행하고 Great Expectations 결과를 읽습니다.
  • 확인할 것: 구조 검증의 통과 또는 실패와 모델 승인 여부는 서로 다른 판단입니다.
  • 적을 것: 검사 결과, 검사한 범위, 모델 평가 전에 남은 조건을 적습니다.
  • 막히면: 실행 오류와 규칙 파일까지만 확인하고, 실행하지 않은 검사를 통과로 적지 않습니다. 실행이 막히면 준비된 검증 요약의 경로를 출처로 남깁니다.

5교시 · 분류 지표와 곡선

  • 질문: 정확도가 높아도 놓친 high_risk 사례가 많을 수 있을까요?
  • 이 교시에서: 분류 지표와 곡선에서 정밀도, 재현율, 잘못된 경보, 놓침을 서비스 위험과 연결하고, 점수 곡선은 해석 범위까지 읽습니다. 어떤 결과에서 후보 판단을 바꿀지 먼저 적습니다.
  • 확인할 것: 관심 클래스의 놓침과 잘못된 경보를 구분합니다. 지표 하나로 후보를 고르지 않습니다.
  • 적을 것: 이번 서비스에서 우선 통제할 오류와 그 이유를 적습니다.
  • 막히면: 용어 정의보다 혼동행렬의 네 칸을 먼저 채우고 지표 계산으로 돌아옵니다.

6교시 · 승인 조건과 후보 비교

  • 질문: 같은 평가 조건에서 A와 B 중 누가 미리 정한 기준을 만족할까요?
  • 이 교시에서: 1차 판단과 바꿀 조건을 적은 뒤 후보 비교와 실험 이력에서 두 후보를 대조합니다. 지표가 만들어지는 과정이 필요하면 개발용 학습과 평가 흐름을 따로 실행합니다.
  • 확인할 것: 두 후보의 보류 또는 승인을 수치와 평가 범위로 설명합니다. 처음 판단이 유지되거나 바뀐 이유를 남깁니다.
  • 적을 것: 후보별 기준 충족 여부와 공식 평가 자료의 경로를 적습니다.
  • 막히면: 개발용 실행 결과와 공식 평가 자료를 분리하고, 공식 자료의 기준만 읽습니다.

7교시 · 실험과 버전 연결

  • 질문: 공식 평가 숫자가 어느 데이터, 실행, 모델 파일에서 만들어졌는지 다시 찾을 수 있나요?
  • 이 교시에서: 실험과 버전 연결과 후보 비교와 실험 이력에서 데이터 이력, 실행 기록, 모델 파일이 같은 평가를 가리키는지 대조합니다.
  • 확인할 것: 데이터, 실행 기록, 모델 파일, 공식 판단의 연결을 설명합니다.
  • 적을 것: 실행 기록 또는 준비된 근거 경로와 확인 범위를 적습니다.
  • 막히면: 화면이 없으면 고정된 평가 자료를 읽고, 화면을 확인하지 못한 사실을 남깁니다.

첫째 날이 끝나면 Candidate B가 모델 평가에서 승인된 이유를 설명할 수 있습니다. 대상 API가 그 후보를 실행한다는 근거는 아직 없으므로, 운영 환경은 미확인으로 둡니다.

2일차 오전: 컨테이너와 예측 API, 실행 모델, Kubernetes

둘째 날 오전에는 1일차에서 승인한 후보가 실제 실행 경로에서도 같은 모델을 가리키는지 확인합니다. 슬라이드 본편 066부터 090까지는 컨테이너와 예측 API, 실행 모델 확인, Kubernetes 배포 구조를 이 순서로 설명합니다. FastAPI 서비스를 처음부터 만들지 않고, 제공된 코드와 로컬 Compose에서 입력 검사와 응답 형식을 확인합니다.

공동 Kubernetes 환경을 직접 바꾸는 작업은 필수 실습이 아닙니다. 로컬 Compose와 배포 설정 검사는 이 과정에서 실행하고, 대상 환경의 배포 상태와 모델 정보는 직접 본 경우에만 확인한 사실로 적습니다. GitOps 동기화와 배포 완료 확인은 오후 4교시입니다.

오전 실습에서는 결과 범위를 다음처럼 나눕니다.

  • 로컬 Compose의 200, 422, 요청 ID: 로컬 API 규약을 확인한 근거
  • API 응답과 모델 파일, 배포 설정의 대조: 로컬에서 어떤 모델을 실행했는지 확인한 근거
  • 배포 설정 검사: 선언한 모델 연결을 확인한 근거
  • 대상 환경의 주소와 운영 자료: 직접 본 경우에만 대상 환경 확인 근거

1교시 · 컨테이너와 예측 API

  • 질문: 이미지, 컨테이너, 모델 파일은 각각 무엇을 고정하고, HTTP 200과 422는 무엇을 증명할까요?
  • 이 교시에서: 실행 환경과 운영 기록, 컨테이너와 예측 API, Docker Compose API 확인을 따라 로컬 기준 모델을 시작합니다. 요청 처리와 모델 계산이 나뉜 구조, 정상 200, 입력 오류 422, 본문 크기 413, 서버 오류 5xx, 요청 ID를 구분합니다.
  • 확인할 것: 이미지는 실행 환경, 컨테이너는 실행 중인 인스턴스, 모델 파일은 예측 규칙입니다. 200은 이 요청이 규약을 통과했다는 뜻이고, 422는 모델 품질 오류가 아닙니다.
  • 적을 것: 로컬에서 확인한 기준 모델 정보, 200과 422, 응답의 요청 ID를 적습니다. Candidate B가 대상 환경에서 실행 중인지는 아직 모릅니다.
  • 막히면: Docker를 사용할 수 없으면 이미지 설정과 모델 패키지 연결만 확인하고, 시작하지 못한 이유를 남깁니다.

2교시 · 실행 모델 확인

  • 질문: API가 평가에서 승인한 모델을 실제로 실행하고 있습니까?
  • 이 교시에서: 실행 모델 확인과 로컬 모델 패키지 준비 상태 확인에서 /v1/model, 모델 묶음 정보, 배포 설정을 같은 식별값으로 대조합니다. 로컬 확인과 대상 환경 확인을 나란히 두고, 프로필, 버전, 임계값, 해시가 다를 때 어디를 더 볼지 적습니다.
  • 확인할 것: 한 자료의 이름만으로 실행 모델을 확정할 수 없습니다. 로컬 성공은 대상 배포 성공을 대신하지 않습니다.
  • 적을 것: 확인한 주소, 시간, 프로필, 버전, 특성 수, 해시 대조 결과, 불일치가 있으면 다음에 볼 자료를 적습니다.
  • 막히면: API가 꺼져 있으면 마지막 성공 단계까지 적습니다. 설정 파일만 읽은 결과를 로컬 실행 확인이나 Candidate B 확인으로 올리지 않습니다.

3교시 · Kubernetes 배포 구조

  • 질문: 배포 파일은 컨테이너와 모델을 Kubernetes에 어떻게 배치합니까?
  • 이 교시에서: Kubernetes 배포 구조와 배포 설정 점검에서 Pod, Deployment, Service, 공통 설정과 overlay, 모델 저장소 경로, 이미지 digest와 모델 SHA-256을 읽습니다. 수강생은 클러스터에 적용하지 않습니다.
  • 확인할 것: 설정 파일은 목표 상태이고 실제 실행 상태가 아닙니다. 이미지 지문과 모델 지문은 서로 대신할 수 없습니다.
  • 적을 것: 확인한 프로필과 해시값, overlay가 선택한 경로, 대상 환경을 보지 못한 범위를 적습니다.
  • 막히면: kubectl이 없으면 배포 선언 검사로 전환하고, 대상 환경은 미확인과 담당자의 다음 조치로 남깁니다.

오전이 끝나면 로컬에서 확인한 기준 모델과, 아직 보지 못한 Candidate B 대상 환경을 구분할 수 있어야 합니다. 로컬 기준 모델의 HTTP 200이나 배포 설정 검사를 Candidate B 또는 대상 Kubernetes 환경의 성공으로 바꾸어 쓰지 않습니다.

2일차 오후: GitOps, 관측 신호, 운영 판단

둘째 날 오후는 슬라이드 본편 091부터 126까지입니다. 4교시에는 Git 목표 상태와 클러스터 현재 상태를 구분해 배포 완료를 주장할 수 있는 증거 사슬을 확인합니다. 5교시에는 어떤 신호를 어떤 범위에서 모을지 정하고, 실시간으로 모으지 못하면 준비된 결과를 사용합니다. 6교시에는 그 범위에서 대표 요청을 고르고 로그와 처리 경로로 연결합니다. 7교시에는 모델 승인과 운영 상태를 나눠 현재 권고를 적습니다.

5-1 입력 분포와 5-2 점수와 예측 분포는 별도 강의가 아닙니다. 6교시에서 입력과 출력을 연결해 읽을 때 사용합니다.

오후에는 다음 순서로 좁혀 갑니다.

  1. 목표 상태 반영, 준비 상태, 실제 요청 성공을 배포 완료의 다른 단계로 구분하는가
  2. 어떤 운영 신호가 어떤 질문에 답하는지, 비교 조건을 팀이 다시 열 수 있게 남기는가
  3. 같은 범위에서 한 요청을 지표, 로그, 처리 경로의 같은 사건으로 연결하는가
  4. 모델 승인과 운영 확인을 나눠 현재 권고와 다시 판단할 조건을 적는가

4교시 · GitOps와 배포 상태

  • 질문: 배포 완료를 어떤 순서의 증거로 확인합니까?
  • 이 교시에서: GitOps와 배포 상태와 서빙 실습의 확인 기록에서 Git 목표 상태, 동기화, 준비 상태, 실제 요청을 나눕니다. 수강생은 Application 생성이나 sync를 하지 않습니다. 강사가 보여 준 화면이 있으면 모델 이름과 시각만 기록합니다.
  • 확인할 것: Synced는 목표 상태 반영, Healthy는 실행 준비입니다. 둘 다 있어도 요청 성공과 운영 신호는 별도 확인입니다. overlay 파일은 복구 의도를 선언할 뿐 복구 완료가 아닙니다.
  • 적을 것: 본 화면의 범위와 시각, 네 단계 가운데 확인한 단계와 확인하지 못한 단계를 적습니다.
  • 막히면: 강사 화면이 없으면 대상 운영 범위를 미확인으로 두고 정적 overlay만 읽습니다. kubectl로 대신하지 않습니다.

5교시 · 운영 품질과 관측 신호

  • 질문: 운영 중 어떤 신호를 어떤 범위에서 모아야 합니까?
  • 이 교시에서: 운영 품질과 관측 신호, 운영 중 품질을 흔드는 요인, 운영 모니터링 실습에서 입력 변화와 성능 변화, 서비스 지표, 구조화 로그, 처리 경로를 구분합니다. 비교할 환경, 모델, 시간 범위를 먼저 고정한 뒤 baseline, current-shift, invalid를 보내거나 준비된 결과를 지정합니다. 이 교시에는 원인을 확정하거나 대표 요청을 고르지 않습니다.
  • 확인할 것: 입력 변화는 성능 저하의 가능 원인이지 증명이 아닙니다. 첫째 날의 100건 비교와 둘째 날의 15분 세 시나리오는 표본과 시간이 달라 직접 증감으로 연결하지 않습니다.
  • 적을 것: 팀이 공유한 자료의 경로, 확인한 수집 범위, 아직 해석하지 않은 이유를 적습니다.
  • 막히면: 실시간 수집이 빠졌으면 재시작을 반복하지 않습니다. 준비된 결과의 시간 범위로 조사 범위를 정하고, 확인하지 못한 실시간 수집과 담당자를 적습니다. 다음 교시까지 Compose와 Alloy를 내리지 않습니다.

6교시 · 요청 단위 원인 조사

  • 질문: 평균값 변화에서 원인 후보를 어떻게 좁힙니까?
  • 이 교시에서: 5교시에 남긴 시간 범위를 복원한 뒤 요청 단위 원인 조사 실습에서 세 시나리오의 추세를 보고 대표 요청을 고릅니다. 5-1 입력 분포와 5-2 점수와 예측 분포를 보조 자료로 연결하고, 요청 단위 원인 조사 본문에 따라 같은 요청 ID로 로그와 처리 경로를 확인합니다.
  • 확인할 것: 한 요청은 전체 현상의 증명이 아니라 조사 시작점입니다. 함께 움직인 신호는 단서이고, 원인 확정에는 추가 검증이 필요합니다. invalid의 422는 입력 검증 결과이며 모델 성능 계산에서 제외합니다.
  • 적을 것: 사용한 조사 범위, 관측값, 대표 요청을 고른 이유, 아직 모르는 것을 적습니다.
  • 막히면: 5교시에 정한 경로를 유지하고 수집 환경을 다시 만들지 않습니다. 준비된 결과를 쓰는 경우에는 그 범위의 값과 대표 요청만 분석합니다. 실시간 수집 성공이나 대상 운영 상태로 확대하지 않습니다.

7교시 · 운영 판단과 회고

  • 질문: 어떤 결론을 승인하고 무엇을 더 확인해야 합니까?
  • 이 교시에서: 6교시에서 완료한 요청 조사 결과를 이어받아 5-6 판단 기준을 적용하고 5-8 최종 기록을 완성합니다. 모델 승인과 운영 상태, 오류 유형별 대응, 잘못 승인과 과도한 보류의 비용을 나눕니다.
  • 확인할 것: 후보 B의 모델 평가는 승인 가능하고, 대상 환경은 추가 확인이 필요할 수 있으며, 초기 변화의 원인은 미확정일 수 있습니다. 확인한 것만 결론으로 기록합니다.
  • 적을 것: 최종 판단을 완성하고, 새 사실이 바꾸는 항목만 답합니다. 담당자, 필요 자료, 다시 판단할 조건을 남깁니다.
  • 막히면: 새 검사를 추가하지 말고 아직 모르는 것과 담당자를 남깁니다. 최종 판단에 필요한 근거가 빠졌다면 그 범위를 미확인으로 두고 담당자의 다음 확인 조건을 적습니다.

7교시가 끝날 때

기술 지연이나 접근 제한이 생겨도 새 조회를 멈춘 뒤 다음을 적습니다.

  1. 실제로 확인한 범위와 다시 찾을 수 있는 근거. 실행하지 못한 항목은 막힌 이유와 필요한 환경
  2. 모델 평가 결과와 운영에서 확인한 범위의 구분
  3. 잘못 승인할 위험과 지나치게 보류할 위험
  4. 담당자, 필요 자료, 다시 판단할 조건

이 네 가지를 마치지 못했다면 새 대시보드 조회나 나중에 읽는 자료를 시작하지 않습니다.

7교시에서 읽는 본편은 5-6과 5-8입니다. 5-3의 요청 조사는 6교시에서 끝냅니다.

각 교시의 기록은 다음 판단의 입력입니다. 원인 후보가 강해졌는지, 약해졌는지, 그대로인지도 함께 적습니다.