월간 품질표에서 빈칸을 0으로 채웠더니 로트당 평균 불량 수가 3.0이 나왔어요. 빈칸을 제외하면 3.75예요. 추가 점검 기준을 3.5로 정했다면 같은 자료에서 점검 여부가 바뀌는 셈이에요. 어느 계산이 맞는지 결정하려면 먼저 빈칸이 불량이 없다는 뜻인지, 아직 확인하지 못했다는 뜻인지 나눠야 해요.
첨부 링크는 이 글의 예제 ZIP으로 연결돼요. 압축을 푼 뒤 링크에 표시된 파일을 열면 입력·코드·완성 자료를 함께 사용할 수 있어요.
이번에는 검사 대상 10개 로트를 맡은 담당자의 상황을 가정해요. 목표는 ‘전체 10개 로트의 평균 불량 수가 3.5 이하인지’ 판단하는 분석 메모를 만드는 거예요. 각 로트에는 제품이 20개씩 있고, 불량 제품 수는 0~20개예요. 자료와 점검 기준은 모두 설명용 합성 값이며 실제 사업장의 허용 기준이 아니에요.
먼저 숫자 열 옆에 값의 상태를 붙여요
입력 CSV (ZIP: input.csv)에는 다음 값과 확인 상태가 들어 있어요. 엑셀에서 빈칸과 문자열 오류를 모두 0으로 바꾸기 전에 이 상태 열을 만들어 두세요.
| 로트 | 기록된 불량 수 | 의미 |
|---|---|---|
| L01 | 0 | 실제 검사했고 불량 없음 |
| L02~L05 | 2, 1, 3, 2 | 검사 완료 |
| L06 | 18 | 재확인된 실제 값 |
| L07 | 0 | 실제 검사했고 불량 없음 |
| L08 | 4 | 검사 완료 |
| L09 | 빈칸 | 검사 미실시 |
| L10 | ERR | 입력 오류, 원래 값 미확인 |
실측 0 두 건은 평균에 포함해요. L09는 측정하지 않았고 L10은 값을 잃었으므로 둘 다 현재 숫자를 알 수 없어요. L06의 18은 다른 값보다 크지만, 예제의 확인 기록상 오류가 아니에요. ‘극단값’이라는 이유만으로 18을 지우면 질문이 달라져요.
원본은 보존하고 분석용 열을 따로 만드는 편이 재검토하기 쉬워요. 원자료와 처리 단계를 남기라는 원칙은 Good enough practices in scientific computing의 데이터 관리 권고와도 연결돼요. 여기서는 그 원칙을 defects, status, reason 세 열로 구체화했어요.
계산법보다 먼저 계산 대상이 달라져요
확인된 여덟 값은 0+2+1+3+2+18+0+4=30이에요. 아래 세 가지 처리를 같은 자료에 적용해 봤어요.
| 처리안 | 합계 | 분모 | 평균 | 이 값이 뜻하는 것 |
|---|---|---|---|---|
| 미확인 두 값을 0으로 대입 | 30 | 10 | 3.0 | 미확인도 불량 없음이라고 가정한 전체 평균 |
| 실측 여덟 값만 사용 | 30 | 8 | 3.75 | 관측된 로트의 평균 |
| 실측 18을 5로 줄여 계산 | 17 | 8 | 2.125 | 값을 절단한 관측 평균 |
첫 번째 방법은 계산 오류는 없지만 미확인 두 건에 새로운 값을 가정해요. 세 번째는 실제 확인한 불량 13개를 계산에서 없애요. 따라서 이 예제에서는 둘 다 최종 보고값으로 채택하지 않아요. 두 번째를 **‘검사 완료 8개 로트의 평균 3.75, 대상 10개 중 미확인 2개’**라는 설명과 함께 제시해요.
이 선택도 전체 10개가 3.5를 넘었다는 확정 판정은 아니에요. 미검사 로트의 품질이 다를 수 있기 때문이에요. 제외 평균이 전체 평균을 공정하게 대표하려면 결측이 생긴 과정에 대한 추가 정보가 필요해요. 검사 시간이 오래 걸리는 로트부터 누락됐다면, 편한 로트만 남았을 가능성도 확인해야 해요. 이 예제는 그런 결측 구조를 추정하지 않아요.
여덟 값의 중앙값은 2예요. 평균 3.75와 함께 보면 18의 영향이 크다는 설명에는 도움이 돼요. 하지만 중앙값은 ‘대표적인 로트의 가운데 값’이라는 다른 질문에 답하므로 평균 점검 기준 3.5와 바로 비교하지 않아요. 실제 18을 숨기지 않고 특이 로트를 따로 조사하는 편이 목적에 맞아요.
모르는 두 값이 결론을 얼마나 바꿀 수 있을까요
이 사례에서는 로트당 제품 수가 20개라는 상한을 알아요. 미확인 두 값의 합계를 u라고 두면 전체 평균은 (30+u)/10이에요. 두 로트 모두 불량이 없을 때 3.0, 모두 20개 불량일 때 7.0이에요. 이 3.0~7.0은 가정한 최솟값·최댓값으로 계산한 범위예요. 발생 확률이나 95% 신뢰구간이 아니에요.
추가 점검 기준 3.5를 넘는 조건도 구할 수 있어요. (30+u)/10 > 3.5를 풀면 u>5예요. 불량 수가 정수이므로 두 로트의 합계가 6개 이상이면 전체 평균이 기준을 넘어요. 합계가 5개면 정확히 3.5예요. 이렇게 쓰면 막연한 ‘결측 때문에 불확실함’을 어떤 값을 확인하면 결정을 내릴 수 있는지로 바꿀 수 있어요.
지금 보낼 분석 메모는 다음처럼 완성할 수 있어요.
대상 10개 로트 중 8개를 확인했고 불량 합계는 30개, 관측 평균은 3.75개예요. 2개 로트의 값이 미확인이라 전체 평균 기준 3.5 초과 여부는 아직 확정하지 않아요. 미확인 두 로트에서 합계 6개 이상이 확인되면 기준을 넘어요. L09는 검사를 수행하고 L10은 원기록을 복구한 뒤 전체 평균을 다시 계산해요. L06의 18은 재확인한 실측값으로 유지해요.
결측 처리나 정의 변경처럼 비교에 영향을 주는 내용을 수치 가까이에 설명하라는 취지는 영국 Government Analysis Function의 품질·불확실성 안내에서도 확인할 수 있어요. 위 메모의 특정 기준과 계산값은 공식 권고가 아니라 이번 예제에서 정한 것이에요.
내 자료에 적용할 때 바꿀 부분
검증 코드 (ZIP: verify.py)는 Python 3.12.3 표준 라이브러리로 실행했어요. python3 assets/verify.py를 실행하면 비교 CSV (ZIP: comparison.csv)와 결과 JSON (ZIP: results.json)을 다시 만들어요. 합계 30, 실측 8건, 평균 3.75, 중앙값 2가 일치하는지 먼저 확인해요. 자기 자료로 바꿀 때는 valid의 의미, 전체 대상 수, 가능한 값의 범위와 고정 검증값을 함께 수정해야 해요.
로트 크기가 다르면 불량 개수 평균과 전체 제품 불량률이 다른 지표가 돼요. 그때는 제품 수 열을 추가하고 질문에 맞는 분모부터 정해요. 상한을 모르는 시간·매출 같은 값에는 여기의 0~20 경계를 그대로 적용할 수 없어요. 처리 방법을 여러 개 비교해 결과가 비슷하더라도 누락 원인까지 해결된 것은 아니에요.
설정에 따른 결과 변화 자체를 기록하고 싶다면 조건을 바꾼 분석 비교로 이어가세요. 2026년 10월 13일 Codex가 합성 예제와 계산을 작성·검증했으며, 실제 자료의 결측 원인이나 조직의 점검 기준은 별도로 확인해야 해요.
예제 파일을 한 번에 받아 다시 확인해요
이 글의 입력·코드·완성 자료 ZIP을 새 폴더에 풀면 R08/README.txt, replay.py, assets 폴더가 함께 생겨요. 개별 코드 파일만 저장하면 보조 모듈이나 입력이 빠질 수 있으므로 처음에는 이 묶음을 사용하세요. R08 폴더에서 다음 명령을 실행하면 본문에 사용한 검사를 순서대로 수행해요.
python3 replay.py
확인할 결과는 0대체3.0·관측값3.75·절단2.125예요. 명령이 성공해도 이 값과 본문의 적용 범위를 함께 대조하세요. 실행 안내 (ZIP: README.txt)에 필요한 파일과 개별 명령을 적었어요. 실행 코드는 verify.py (ZIP: verify.py)에서 직접 볼 수 있어요. Python3.12의 표준 라이브러리를 사용하며, 명령이 실패하면 ZIP의 폴더 구조와 오류에 나온 파일부터 확인해요. 실제 앱 실행에 필요한 프로그램은 원래 설명을 따르세요.
설명 삽화 2장은 GPT로 생성한 개념 설명이에요. 실제 예제의 작업 화면과 실행 결과는 기존 그림·첨부 자료에서 따로 확인할 수 있어요.