4장 운영 품질과 관측 신호¶
이 장의 실무 질문은 기존 운영 모델의 high_risk 예측 비율이 달라졌을 때 입력 분포 변화와 모델 성능 변화를 어떻게 분리할 것인가입니다. QA 담당자는 릴리스 회의에서 숫자를 크게 읽는 데서 멈추지 않고, 어떤 자료에서 무엇을 확인했는지와 아직 모르는 것을 함께 설명해야 합니다.
이 장에서는 입력과 출력의 분포, 서비스 상태, 구조화 로그, 요청 처리 경로를 서로 다른 관측 단위로 읽습니다. 지표(metric)는 일정 범위의 추세를 찾고, 로그(log)는 한 요청의 사건을 확인하며, 추적 기록(trace)은 그 요청이 지나간 단계별 시간을 좁히는 데 사용합니다.
첫째 날에 본 100건 비교와 이 장에서 사용하는 준비된 60+60+3 자료는 서로 다른 표본과 시간 범위를 가집니다. 따라서 한 자료의 수치를 다른 자료의 전후 값처럼 이어 붙이지 않으며, 각 자료가 허용하는 주장만 보고서에 남깁니다.
| 이번 장에서 고정할 항목 | 학습자가 남길 결과 |
|---|---|
| 받은 업무 | high_risk 예측 비율 변화가 입력, 서비스, 실행 환경 중 어떤 질문을 열어 두는지 기록합니다. |
| 비교 범위 | 환경, 모델 정보, 절대 UTC 범위, 요청 묶음과 자료의 출처를 함께 적습니다. |
| 판단 산출물 | 관측한 신호, 강화·약화된 원인 후보, 아직 모르는 사실, 다음 확인 질문을 한 행으로 정리합니다. |
| 보고서 활용 | 모델 성능 저하를 확정하지 않고 운영 확인 범위와 추가 자료 요청을 문장으로 씁니다. |
이 표의 목적은 관측 자료를 많이 모으는 것이 아니라 같은 조건에서 다시 확인할 수 있는 판단 근거를 만드는 데 있습니다. 실행이 필요한 확인은 운영 모니터링 실습에서, 신호별 세부 계약은 지표, 로그, 추적 기록을 연결하는 방법과 대시보드 자료를 해석하는 방법에서 이어집니다.
이 장은 2일차 오후 GitOps 확인 뒤에 이어지는 운영 조사 구간입니다. 여기서는 원인을 확정하지 않고 수집 범위와 신호의 역할을 고정하며, 뒤 단계에서 같은 범위를 유지한 채 세부 원인을 좁힐 수 있도록 기록합니다. 실시간 자료를 확인하지 못하면 준비된 자료의 출처 범위를 그대로 사용하고 대상 환경의 관측 결과로 확대하지 않습니다.
099. 입력 분포 변화와 모델 성능 변화¶
입력·예측 분포 변화와 정답 기준 모델 성능 변화는 서로 다른 주장입니다. 같은 모델이더라도 들어온 값의 구성, 점수(score)의 위치, 임계값(threshold) 뒤의 예측 구성이 달라지면 high_risk 비율이 달라질 수 있습니다.
이번 비교의 기준은 같은 모델과 같은 100건입니다. 기준 조건에서는 high_risk가 3건, 즉 3%였고 점수 P95는 0.3859였습니다. 입력 분포가 달라진 조건에서는 high_risk가 6건, 즉 6%였고 점수 P95는 0.5133이었습니다. 이 100건에는 실제 결과를 나타내는 정답(label)이 없으므로 관측할 수 있는 것은 입력·점수·예측 분포의 변화입니다.
관측값이 허용하는 주장과 허용하지 않는 주장을 나누면 다음과 같습니다. 정밀도(precision), 재현율(recall), 미탐 건수는 예측과 정답을 함께 비교해야 하므로 이 운영 표본에서 새로 계산하지 않습니다.
| 관측값 | 이 자료에서 말할 수 있는 것 | 이 자료만으로 말할 수 없는 것 |
|---|---|---|
high_risk 3건 → 6건 |
최종 예측 구성과 비율이 달라졌습니다. | 실제 high_risk를 더 잘 찾거나 더 많이 놓쳤다는 성능 변화입니다. |
| 점수 P95 0.3859 → 0.5133 | 점수 분포의 상위 경계가 높아졌습니다. | 모델 결함 또는 재현율·정밀도 저하의 원인이 확정되었습니다. |
| 정답 열 없음 | 정답 없는 운영 자료라는 범위를 확인합니다. | 정답을 임의로 채워 모델 품질 지표를 계산할 수 있습니다. |
표에서 확인한 변화는 입력 구성이나 임계값, 실행 조건을 더 살펴보게 하는 조사 신호입니다. 고위험 예측 비율이 두 배가 되었다는 사실을 성능이 두 배 나빠졌다는 문장으로 바꾸지 않는 것이 QA의 첫 번째 경계입니다.
보고서에는 “같은 모델과 같은 100건에서 high_risk 비율이 3%에서 6%로, 점수 P95가 0.3859에서 0.5133으로 변했지만 정답이 없어 모델 성능 변화는 확정하지 않았다”라고 남길 수 있습니다. 다음 확인에서는 비교 환경과 시간 범위를 고정하고 이 분포 변화가 서비스 상태나 입력 상태와 함께 나타났는지 확인합니다.
100. 운영 지표의 세 범주¶
운영 지표는 질문에 따라 서비스 상태, 입력·예측 분포, 시스템 자원으로 나누어 읽어야 합니다. 세 범주는 서로 관련될 수 있지만 하나의 숫자가 다른 범주의 원인을 대신 증명하지는 않습니다.
서비스 상태 지표는 요청이 얼마나 빠르고 안정적으로 처리되었는지 보여 줍니다. 입력·예측 지표는 요청 값과 모델 출력 구성이 어떻게 달라졌는지 보여 주며, 시스템 자원 지표는 CPU와 메모리처럼 실행 환경의 여유를 보여 줍니다. 95백분위수(P95)는 관측값의 95%가 그 값 이하가 되는 경계이므로 시간뿐 아니라 점수나 누락 특성 수에도 사용할 수 있습니다.
준비된 비교 자료에서 서비스 상태에는 시나리오별 응답 시간 P95 55ms, 640ms, 30ms와 상태 코드 200, 200, 422가 보입니다. 입력·예측 분포에는 점수 P95 0.40, 0.56, 값 없음과 빠진 특성 수 P95 0.5, 2.0, 1.0이 보입니다. CPU와 메모리 같은 시스템 자원 값은 이 자료에 없으므로 별도 수집 대상으로 남깁니다.
| 지표 범주 | 예시 값 또는 지표 | 답하는 질문 | 이 자료에서의 한계 |
|---|---|---|---|
| 서비스 상태 | 지연 시간, 요청량, 5xx 오류율, 상태 코드별 요청 수 | 요청 처리가 느려졌거나 실패했습니까? | 어느 코드나 구성 요소가 원인인지는 추가 자료가 필요합니다. |
| 입력·예측 분포 | 점수 P95, high_risk 비율, 빠진 특성 수 P95 |
들어온 입력과 모델 출력 구성이 달라졌습니까? | 정답 없는 자료에서는 정밀도·재현율을 계산하지 못합니다. |
| 시스템 자원 | CPU, 메모리, 컨테이너 재시작, 자원 제한 | 실행 환경에 여유가 있었습니까? | 준비된 비교 자료에 값이 없으면 자원 문제를 추정하지 않습니다. |
표의 세 줄은 같은 현상을 세 번 설명하는 목록이 아니라 서로 다른 질문의 측정 창입니다. 지연이 높다는 사실은 서비스 상태의 이상 신호이고, 데이터 변화나 자원 부족을 바로 확정하는 문장이 아닙니다.
따라서 보고서에는 “서비스 지표에서는 지연 변화를 확인했으나 입력 분포와 자원 지표가 같은 범위에서 확인되었는지는 별도 검토가 필요하다”처럼 범위를 나누어 씁니다. 특히 자원 자료가 없는 상태에서는 CPU 부족을 원인 후보로만 남기고, 실제 자원 측정 없이는 결론으로 올리지 않습니다.
101. 응답 시간과 오류율 지표 읽기¶
응답 시간과 오류율은 값만 읽지 말고 시간축, 단위, 표본 수, 상태 코드의 의미를 함께 확인해야 합니다. 이 자료의 시간 범위는 준비된 15분 구간인 06:00–06:15 UTC이며, 실시간 전체 서비스의 평균이나 장애 상태를 나타내는 화면이 아닙니다.
같은 구간에서 기준 입력 60건은 모두 HTTP 200이고 지연 시간 P95가 55.0ms입니다. 입력 변화 60건도 모두 HTTP 200이지만 지연 시간 P95가 640.0ms입니다. 잘못된 입력 3건은 HTTP 422이고 지연 시간 P95가 30.0ms입니다. 이 세 수치는 같은 단위로 보되, 서로 다른 시나리오의 요청 묶음이라는 전제를 유지합니다.
시나리오별 서비스를 비교하려면 표본 수와 상태 코드를 먼저 고정해야 합니다. 아래 표는 각 묶음의 지연 P95와 응답 상태를 함께 기록하며, Error rate는 이 장에서 5xx 서비스 오류율을 가리키고 422 입력 검증 실패를 그 값에 섞지 않습니다.
| 요청 묶음 | 표본 수 | 상태 코드 | 지연 시간 P95 | QA가 우선 읽을 내용 |
|---|---|---|---|---|
| 기준 입력 | 60 | 200 × 60 | 55.0ms | 비교의 출발점인 정상 응답 범위입니다. |
| 입력 변화 | 60 | 200 × 60 | 640.0ms | 같은 준비 자료 안에서 느린 요청 꼬리가 커졌습니다. |
| 잘못된 입력 | 3 | 422 × 3 | 30.0ms | 입력 검증 경로이며 5xx 서비스 오류가 아닙니다. |
표에서 640.0ms는 입력 변화 묶음의 P95 지연이 기준 입력보다 높다는 뜻입니다. 이 숫자 하나를 전체 서비스 평균 지연이나 5xx 장애로 확대하지 않으며, 30.0ms의 422 응답을 “오류가 없었다”로 읽지도 않습니다.
보고서에는 “06:00–06:15 UTC 준비 자료에서 입력 변화 60건의 지연 P95는 640.0ms로 기준 입력 60건의 55.0ms보다 높았고, 잘못된 입력 3건은 422로 분리되었다”라고 적을 수 있습니다. 다음 확인에서 필요한 것은 이 차이가 어느 요청 경로와 입력 상태에서 나타났는지이지, 준비 자료를 실시간 장애로 이름 붙이는 일이 아닙니다.
102. 한 요청을 설명하는 구조화 로그¶
구조화 로그는 한 요청에서 무엇이 언제 일어났는지를 필드별로 남기는 기록입니다. 지표가 전체 묶음의 비율과 분포를 보여 준다면 로그는 선택한 사건의 상태, 모델 정보, 결과와 오류 분류를 다시 찾게 합니다.
준비된 로그 한 행에는 시간, 환경, 시나리오, run_id, request_id, trace_id, HTTP 상태, 처리 시간, 모델 정보와 prediction이 함께 들어갑니다. 예를 들어 환경은 “준비된 오프라인 자료”, 시나리오는 current-shift, 상태는 200, 처리 시간은 920.0ms, 예측은 high_risk처럼 기록할 수 있습니다. 실제 식별값은 자료에서 확인한 값을 사용하고, 문서 예시는 <run_id>와 <request_id> 같은 자리표시자로 둡니다.
필드의 역할을 나누면 로그를 읽을 때 무엇을 확인했고 무엇을 보지 못했는지 분명해집니다.
| 필드 묶음 | 예시 필드 | 확인할 질문 |
|---|---|---|
| 사건과 범위 | timestamp, environment, scenario, run_id |
어느 자료와 어느 실행 묶음의 기록입니까? |
| 연결값 | request_id, trace_id |
같은 요청의 다른 기록을 다시 찾을 수 있습니까? |
| 결과와 상태 | status_code, prediction, score, threshold |
요청이 어떤 상태로 끝났고 어떤 출력이 나왔습니까? |
| 처리와 오류 | duration_ms, error_code, 제한된 validation_category |
얼마나 걸렸으며 공개 가능한 오류 분류가 있습니까? |
표의 필드는 민감한 원문 입력을 그대로 남기지 않고도 요청의 처리 상태를 설명하기 위한 최소 단서입니다. 한 행의 high_risk나 920.0ms는 그 요청의 사실일 뿐 전체 모델이나 서비스의 결론이 아니며, request_id는 인증 정보가 아니라 기록을 연결하는 값입니다.
보고서에는 “current-shift의 한 요청에서 상태 200, 처리 시간 920.0ms, high_risk 예측과 연결용 식별값을 확인했으나, 이 한 건만으로 전체 지연 원인은 확정하지 않았다”라고 남길 수 있습니다. 이 기록은 전체 지표에서 좁힌 사건의 범위를 보존하며, 이후 처리 경로를 확인할 때 같은 연결값을 사용하게 합니다.
103. 처리 시간을 보여 주는 요청 경로¶
추적 기록은 한 요청의 총 처리 시간을 부모·자식 구간(span)으로 나누어 지연 위치를 좁힙니다. 어느 단계에 시간이 많이 걸렸는지 확인할 수 있지만, 가장 긴 구간의 이름만으로 결함 원인을 확정할 수는 없습니다.
준비된 처리 경로 예시는 같은 <trace_id> 아래 traffic.generate 924ms, risk-api.predict 922ms, POST /v1/predict 920ms, risk.predict 861ms가 중첩되는 형태입니다. 안쪽 구간의 시간은 바깥 구간에 포함될 수 있으므로 네 값을 단순히 더해 총시간을 계산하지 않습니다.
각 span의 위치를 나누어야 지연 후보와 아직 모르는 원인을 분리할 수 있습니다. 아래 표는 부모·자식 관계에 있는 구간의 예시 시간과 해석 범위를 정리합니다.
| 처리 구간 | 예시 시간 | 확인할 수 있는 것 | 아직 모르는 것 |
|---|---|---|---|
traffic.generate |
924ms | 요청 생성부터 전체 관측 흐름까지의 범위 | 생성기 밖의 대기나 다른 요청의 상태 |
risk-api.predict |
922ms | API가 요청을 처리한 부모 구간 | API 내부에서 어느 작업이 원인인지 |
POST /v1/predict |
920ms | 예측 엔드포인트에 걸린 처리 시간 | 네트워크 대기와 애플리케이션 처리의 분리 |
risk.predict |
861ms | 위험도 계산 구간의 지연 후보 | 계산 자체, 전처리, 의존 서비스 중 단일 원인 |
표에서 861ms라는 가장 긴 내부 구간을 찾았다는 것은 조사 범위를 좁혔다는 뜻입니다. 모든 요청이 같은 경로를 지났다고 가정하지 않으며, 결측 처리 비용, 모델 계산, 네트워크 대기처럼 경쟁하는 설명을 추가 측정 없이 하나로 고정하지 않습니다.
보고서에는 “대표 처리 경로에서 risk.predict 861ms 구간이 지연 후보로 보였으나, 이 trace만으로 모델 계산을 유일한 원인으로 확정하지 않았다”라고 씁니다. 이 문장은 지표와 로그에서 찾은 한 요청의 범위를 처리 단계로 구체화하면서도 원인 확정과 조사 위치를 구분합니다.
104. 지표, 로그, 요청 경로의 연결값¶
지표, 로그, 추적 기록은 서로 다른 관측 단위에 답하므로 공통 범위와 연결값이 맞을 때만 같은 사건으로 이어야 합니다. 지표에서 이상 구간을 찾고, 실행 묶음과 요청 연결값으로 사건을 좁힌 뒤, 추적 기록에서 단계별 시간을 확인하는 순서가 기본 흐름입니다.
run_id는 한 번의 요청 묶음이나 시나리오 실행을 가리키고, request_id는 그 묶음 안의 한 요청을 가리킵니다. trace_id는 같은 요청이 지나간 처리 경로를, span_id는 그 경로의 한 구간을 가리킵니다. 요청마다 달라지는 식별값을 집계 지표의 레이블에 넣으면 시계열이 요청 수만큼 갈라지므로 지표에는 안정적인 범주만 남깁니다.
세 신호를 잇는 값과 역할은 다음과 같습니다.
| 관측 자료 | 범위를 맞추는 조건 | 연결에 쓰는 값 | 답하는 질문 |
|---|---|---|---|
| 지표 | 환경, 모델, 절대 UTC 범위, 시나리오 | 안정적인 profile·version·scenario·상태 범주 |
언제 어떤 범위의 변화가 보였습니까? |
| 구조화 로그 | 같은 실행 묶음과 요청 범위 | run_id, request_id |
그 범위의 한 요청은 어떤 상태였습니까? |
| 추적 기록 | 같은 요청과 처리 시각 | request_id, trace_id, span_id |
그 요청은 어느 단계에서 얼마나 걸렸습니까? |
표의 연결은 조사 범위를 단계적으로 좁히는 장치이지 원인을 자동으로 정하는 규칙이 아닙니다. 이름이 같은 모델이나 요청이라도 환경, 절대 UTC 범위, 실행 묶음이 다르면 서로 다른 자료로 남겨야 하며, 요청 연결값은 지표 레이블에 넣지 않습니다.
보고서에는 “동일한 환경·모델·UTC 범위에서 집계 지표의 이상 구간을 실행 묶음과 요청 연결값으로 좁혀 로그와 처리 경로를 연결했지만, 연결 자체는 원인 확정이 아니라 추가 확인 범위의 근거”라고 기록할 수 있습니다. 이 문장으로 전체 추세와 한 요청의 사건, 단계별 지연을 서로 대신 쓰는 오류를 줄입니다.
105. 로그와 지표를 모으는 도구의 역할¶
수집 도구는 애플리케이션이 만든 신호를 받아 알맞은 저장소로 전달하는 역할을 합니다. 수집기와 저장소의 이름을 안다는 사실은 대상 환경에서 신호가 실제로 도착했다는 증명이 아니며, 역할 구조와 관측 사실을 분리해야 합니다.
Risk API와 트래픽 생성기는 구조화 로그, /metrics 지표, 처리 경로 기록을 내보낼 수 있습니다. 수집기인 Alloy는 이 신호를 받아 로그 저장소인 Loki, Prometheus 호환 지표 저장소, Tempo 추적 기록 저장소로 전달하고, Grafana는 여러 저장소를 조회하는 화면을 제공합니다.
신호가 이동하는 경로와 각 도구의 책임을 표로 정리하면 다음과 같습니다.
| 단계 | 역할 | QA가 확인할 질문 |
|---|---|---|
| 애플리케이션 | 로그·지표·추적 기록을 생성합니다. | 필요한 필드와 안정적인 지표 범주가 만들어집니까? |
| Alloy | 신호를 수집하고 목적지로 전달합니다. | 선언한 입력과 출력 경로가 연결되어 있습니까? |
| Loki | 구조화 로그를 보관하고 조회합니다. | 요청 단위 사건을 다시 찾을 수 있습니까? |
| Prometheus 호환 저장소 | 시간에 따른 지표를 집계하고 보관합니다. | 같은 조건의 추세를 비교할 수 있습니까? |
| Tempo | 요청의 span과 부모·자식 경로를 보관합니다. | 지연 구간을 처리 흐름으로 좁힐 수 있습니까? |
| Grafana | 여러 신호를 같은 시간축에서 조회합니다. | 조사할 시간대와 다음 자료를 찾을 수 있습니까? |
표는 “수집기 하나와 세 저장소”라는 역할 관계를 보여 줄 뿐, 현재 대상 환경의 도착 상태를 보장하지 않습니다. 실제 자료를 보지 못한 경우에는 준비된 자료를 확인한 범위와 실시간 확인이 남은 범위를 나누어 적고, 접속 정보를 추정해 빈칸을 채우지 않습니다.
보고서에는 “애플리케이션에서 생성된 신호가 수집 경로와 저장소별 역할로 나뉘어 있음을 확인했으며, 실제 대상 환경의 도착 여부는 별도 확인 범위로 남겼다”라고 쓸 수 있습니다. 도구 이름은 다음 확인 위치를 알려 주지만, 어떤 원인이 맞는지 대신 판단하지 않습니다.
106. 운영 변화를 찾는 Grafana 대시보드¶
Grafana 대시보드는 여러 신호를 같은 시간축에 놓아 조사를 시작할 위치를 찾는 화면입니다. 대시보드의 한 spike나 설명용 표는 원인 판정문이 아니며, 특히 준비된 자료를 재구성한 예시는 실제 운영 화면과 구분해야 합니다.
준비된 06:00–06:15 UTC 구간에서는 입력 분포 변화가 나타난 06:08에 응답 시간이 960ms로 높아지고, 같은 시각의 high_risk 예측 비율도 함께 표시됩니다. 이 값은 “06:08을 먼저 조사한다”는 선택을 가능하게 하지만, 그 시각에 실제 장애가 발생했거나 전체 기간이 같은 상태였다는 사실까지 말해 주지는 않습니다.
패널에서 읽을 값과 그 한계를 나누면 다음과 같습니다.
| 패널 | 관측할 값 | 조사에 쓰는 방식 | 확정할 수 없는 것 |
|---|---|---|---|
| 응답 시간 | 시간축별 지연 또는 P95 | 급증한 시간대를 표시합니다. | 급증의 단일 원인입니다. |
| 오류율·상태 코드 | 5xx와 422의 분포 | 서비스 오류와 입력 검증 경로를 분리합니다. | 422가 곧 서버 장애라는 해석입니다. |
| 점수·예측 분포 | 점수 P95와 high_risk 비율 |
입력 변화와 출력 구성의 동행 여부를 봅니다. | 정답 기반 성능 저하입니다. |
| 누락 특성 | 빠진 특성 수 P95 | 입력 상태 후보를 확인합니다. | 원본 생성 단계의 원인입니다. |
표에서 06:08은 로그나 추적 기록으로 내려갈 조사 위치를 정하는 기준점입니다. 대시보드에 보이는 동행은 상관관계의 단서이므로, 그 화면만으로 모델 결함, 서버 장애, 전체 운영 상태를 확정하지 않습니다.
보고서에는 “준비된 06:00–06:15 UTC 대시보드 자료에서 06:08의 960ms 급증과 high_risk 비율 변화를 함께 확인해 해당 시각을 조사 시작점으로 정했으며, 대시보드만으로 원인은 확정하지 않았다”라고 남길 수 있습니다. 이렇게 쓰면 Grafana를 원인 확정 도구가 아니라 조사 위치 선택 도구로 정확히 설명할 수 있습니다.
107. 운영 자료의 비교 조건¶
운영 자료를 비교하기 전에는 환경, 모델 식별 정보, 절대 UTC 범위, 요청 묶음이라는 네 조건을 고정해야 합니다. 이 조건이 같아야 관측값의 차이를 같은 사건 안의 차이로 해석할 수 있으며, 하나라도 다르면 비교를 보류하거나 별도 자료로 분리합니다.
모델 식별 정보에는 최소한 profile, version, threshold가 포함됩니다. 예를 들어 준비된 자료에서 profile=baseline, threshold=0.5를 확인했다면 그 값과 절대 UTC 범위, 요청 묶음의 표본 수를 함께 기록합니다. 모델 이름만 같은지 보는 것은 충분하지 않으며, 임계값이 바뀌어도 예측 비율은 달라질 수 있습니다.
비교 전에 고정할 조건과 불일치 시의 해석은 다음과 같습니다.
| 고정 조건 | 기록 예시 | 빠졌을 때의 위험 |
|---|---|---|
| 환경 | 준비된 자료, 로컬, 또는 직접 확인한 대상 범위 | 서로 다른 실행 환경의 신호를 한 사건으로 묶습니다. |
| 모델 식별 | profile, version, threshold=0.5 |
모델·임계값 변화와 입력 변화를 구분하지 못합니다. |
| 절대 UTC 범위 | 2026-07-15 06:00–06:15 UTC |
상대 시간창이 움직여 전후 비교가 흔들립니다. |
| 요청 묶음 | 기준 60건 + 입력 변화 60건 + 잘못된 입력 3건 | 표본과 시나리오가 다른 값을 직접 비교합니다. |
표의 네 조건은 분석 범위를 잠그는 경계입니다. 같은 모델 이름이나 비슷한 그래프만으로 환경·시간·표본이 다른 자료를 합치지 않으며, 조건을 확인하지 못한 칸은 완료처럼 채우지 않고 미확인으로 남깁니다.
보고서에는 “환경, 모델의 profile·version·threshold, 절대 UTC 범위와 요청 묶음을 고정한 뒤에만 두 신호를 비교했으며, 조건이 다른 자료의 증감은 계산하지 않았다”라고 적을 수 있습니다. 이 문장은 이후에 새 값이 들어와도 무엇을 같은 사건으로 다시 열 수 있는지 알려 줍니다.
108. 서로 다른 두 운영 자료 묶음¶
첫째 날의 100건 비교와 준비된 60+60+3 자료는 표본, 시간, 출처와 학습 목적이 다르므로 서로 다른 자료 묶음으로 다뤄야 합니다. 두 자료를 한 연속 운영 추세로 이어 붙이면 관측 신호와 실습 절차의 경계가 사라집니다.
첫째 날 자료는 100건의 정답 없는 운영 표본에서 같은 모델의 high_risk가 3건에서 6건으로, 점수 P95가 0.3859에서 0.5133으로 변한 비교입니다. 이 자료의 시간 범위는 2026-07-01 09:00–09:10 KST입니다. 준비된 자료는 별도의 15분 연습 범위인 2026-07-15 06:00–06:15 UTC에서 기준 입력 60건, 입력 변화 60건, 잘못된 입력 3건을 비교하며 실제 대상 환경 수집 결과를 뜻하지 않습니다.
두 자료를 별도 묶음으로 유지하려면 표본, 시간, 출처와 가능한 주장을 나란히 기록해야 합니다. 아래 표는 두 자료를 직접 연결하지 않고 각각의 범위에서 읽는 기준을 정리합니다.
| 구분 | 첫째 날 100건 | 준비된 60+60+3 자료 |
|---|---|---|
| 시간 범위 | 2026-07-01 09:00–09:10 KST |
2026-07-15 06:00–06:15 UTC |
| 표본 구성 | 같은 모델의 100건 비교 | 기준 입력 60건, 입력 변화 60건, 잘못된 입력 3건 |
| 핵심 관측 | high_risk 3건 → 6건, 점수 P95 0.3859 → 0.5133 |
시나리오별 상태 코드, 지연·점수·누락 특성 분포 |
| 정답과 출처 | 정답 없음, 운영 관찰 범위 | 정답 없음, 관측 연결 절차를 위한 준비 자료 |
| 가능한 주장 | 입력·예측 분포가 달라졌습니다. | 고정된 15분 범위 안에서 시나리오 차이를 비교합니다. |
표에서 두 자료의 숫자를 직접 빼거나 나누어 시간에 따른 증가율로 계산하지 않습니다. 첫째 날의 3%와 6%는 준비된 자료의 시나리오별 비율을 설명하는 기준값이 아니며, 준비된 자료도 실제 대상 환경의 연속 측정으로 바꾸어 쓸 수 없습니다.
보고서에는 “첫째 날 100건은 정답 없는 운영 관찰의 초기 신호로, 준비된 60+60+3 자료는 별도 15분 범위에서 관측 연결 절차를 확인하는 자료로 분리했다”라고 남길 수 있습니다. 다음 단계에서는 준비된 묶음 안의 절대 UTC 범위와 비교 조건을 유지한 채 관측을 더 구체화하며, 두 자료를 하나의 성능 추세로 결론내리지 않습니다.