측정 결과가 0인 경우와 결과를 받지 못한 경우는 다른 상태다. 대시보드에서 둘 다 0으로 표시하면 합계뿐 아니라 평균, 위험 판단, 다음 행동까지 달라진다. 숫자 칸을 채우는 규칙보다 먼저 값이 존재하는 조건과 아직 모르는 범위를 정해야 한다.
이 글의 대상은 주기적으로 들어오는 운영 데이터를 보여주는 화면이다. 재고·생산·매출처럼 의미가 다른 지표에 하나의 결측 처리 규칙을 일괄 적용하지 않는다. 아래 수치는 설명을 위해 만든 가상 데이터이며 실제 설비나 고객 성과가 아니다.
한 상태 배지에 세 가지 사실을 섞지 않는다
먼저 업무에서 일어난 사건, 그것을 관측한 기록, 기록이 화면까지 전달된 상황을 나눈다. 생산량 0개라는 유효한 관측은 있을 수 있다. 그러나 그 값만으로 설비 고장이나 작업자 부재를 확정할 수는 없다. 반대로 기록이 도착하지 않았다고 해서 생산이 멈췄다고 말할 수도 없다.
| 질문 | 예시 | 화면이 말할 수 있는 범위 |
|---|---|---|
| 업무에서는 무엇이 일어났나 | 생산·대기·정지 | 검증된 업무 사건이 있을 때만 표시 |
| 무엇을 관측했나 | 구간 생산량 0개 | 해당 구간의 유효한 관측값 |
| 기록은 언제 도착했나 | 2분 늦게 수신 | 데이터 전달 지연; 원인은 별도 확인 |
시간도 하나로 합치지 않는다. 원천의 사건 발생 시각과 수집 시스템의 관측 시각을 따로 저장해야 늦게 도착한 과거 데이터가 최신 상태처럼 보이는 일을 막을 수 있다. OpenTelemetry의 로그 모델도 사건 발생 시각과 수집 시스템의 관측 시각을 별도 필드로 정의한다. 이는 시간 구분을 참고할 근거이며, 아래 화면 설계는 이 글의 제안이다.
가상 예시: 다섯 구간 중 세 구간만 확인됐다
1분 구간 생산량을 받는다고 가정하자. 표의 시각은 각 구간의 종료 시각이고, 단위는 개다. 09:05:30에 종료 시각 09:00부터 09:04까지를 선택해 조회한다. 이 선택 범위의 수집 대상은 5개 구간이다. 이 예시에서는 종료 후 60초를 넘겨도 도착하지 않으면 수집 지연으로 표시한다. 60초는 설명용 기준이며 실제 서비스의 허용 지연으로 추천하는 값이 아니다.
| 구간 종료 | 받은 생산량 | 09:05:30의 표시 |
|---|---|---|
| 09:00 | 12 | 확인됨 |
| 09:01 | 0 | 확인됨 |
| 09:02 | 없음 | 수집 지연 |
| 09:03 | 18 | 확인됨 |
| 09:04 | 없음 | 수집 지연 |
현재 확인된 합계는 12 + 0 + 18 = 30개다. 유효한 관측 구간만 대상으로 계산한 평균은 30 ÷ 3 = 10개/구간이다. 확인한 구간은 3 ÷ 5 = 60%다. 화면에는 “확인된 생산량 30개 · 5구간 중 3구간 확인”처럼 집계 범위를 함께 적는다.
빈칸을 0으로 바꾸면 평균은 30 ÷ 5 = 6개가 된다. 여기에는 모르는 두 구간을 생산량 0개로 간주했다는 가정이 숨어 있다. 또 실제 0을 평균에서 빼면 30 ÷ 2 = 15개가 된다. 두 결과 모두 위에서 정의한 “유효 관측 구간의 평균”과 다르다. 그렇다고 10개가 전체 다섯 구간의 실제 평균인 것도 아니다. 전체 평균은 아직 확정할 수 없다.
지연 데이터가 도착하면 값과 근거를 함께 바꾼다
09:06에 09:04 구간의 6개가 늦게 도착했다고 하자. 같은 다섯 구간을 다시 조회하면 확인된 합계는 36개, 유효 관측 평균은 36 ÷ 4 = 9개, 구간 확인율은 80%가 된다. 09:02 구간은 여전히 모른다. 최신 조회 구간을 슬쩍 옮겨 비교하지 말고 동일한 기간을 고정한 상태에서 이전 결과와 대조해야 한다.
표시 문구는 “36개 · 5구간 중 4구간 확인 · 09:06 갱신”으로 바꿀 수 있다. 과거 보고서를 다시 계산했다면 수정 이력에도 반영한다. 같은 기록이 재전송될 수 있는 시스템은 사건 또는 구간 식별자로 중복을 확인해야 한다. 수신 횟수가 두 번이라는 이유로 생산량까지 두 번 더하지 않는다.
한 설비의 기록이 도착하는 순서로 화면을 검토한다
기존 다섯 구간을 가상 설비 A의 기록으로 놓고 수신 시각만 보탠 정적 도해다. 날짜는 모두 같은 날, 시간대는 한국 표준시다. 원천 시각은 1분 구간의 종료 시각, 수신 시각은 집계 시스템에 도착한 시각으로 구분한다. 조회 대상은 처음부터 끝까지 종료 시각 09:00~09:04의 다섯 구간이다.
| 확인하는 시점 | 도착 기록과 화면 문구 |
|---|---|
| 09:00:10 · 정상 수신 | 원천 09:00 → 수신 09:00:10 12개 · 09:00 종료분 확인 |
| 09:01:10 · 실제 0 | 원천 09:01 → 수신 09:01:10 0개 · 09:01 종료분 확인 |
| 09:03:10 · 일부 공백 | 원천 09:03 → 수신 09:03:10 18개 · 09:03 종료분 확인 09:02 종료분은 아직 미수신 |
| 09:05:30 · 지연 상태 | 09:02·09:04 종료분 미수신 확인된 합계 30개 · 3/5구간 확인 전체 평균 미확정 |
| 09:06:00 · 과거분 추가 | 원천 09:04 → 수신 09:06:00 6개 추가 → 합계 36개 · 4/5구간 확인 09:02 종료분은 여전히 미수신 |
09:06 화면의 표시 예시
확인된 생산량 36개
5구간 중 4구간 확인 · 미확인 09:02 종료분
유효 관측 평균 9개/구간 · 전체 5구간 평균 미확정
마지막 수신 09:06:00 · 받은 기록은 09:04 종료분
09:05:30에 마지막 확인 값 18개를 남길 수는 있다. 다만 “현재 생산량 18개”가 아니라 “09:03 종료분 18개 · 이후 미확인”이어야 한다. 09:06의 6개 역시 09:04까지의 과거 관측이다. 수신 시각이 새롭다는 이유로 현재 생산이 회복됐다고 표시하지 않는다.
이 배치에서는 합계 다음에 확인 범위를 두고, 마지막 수신 시각은 보조 정보로 낮췄다. 큰 숫자와 초록색 “연결 정상”만 남기는 대안은 연결 여부를 생산 상태로 오인하게 할 수 있다. 수신이 재개돼도 09:02 공백이 남으면 “일부 지연 해소”까지만 말할 수 있다.
실제 제품 검수에서는 같은 09:04 기록을 다시 보내도 합계가 36개로 유지되는지, 조회 범위를 바꾸지 않았는지, 0개가 분모에 포함되는지를 확인한다. 이 글에서 검산한 것은 위 가상 데이터의 산술이며 재전송 방지 기능이나 실시간 갱신 동작을 실행한 것은 아니다.
화면에서 자주 발생하는 오류와 수정법
| 잘못된 표시 | 수정할 표시 또는 동작 |
|---|---|
| 값이 없으면 모두 0 | 값은 —, 옆에 수집 지연 또는 미수집 사유 표시 |
| 데이터가 끊겼으니 설비 정지 | 설비 상태 미확인; 마지막 확인 시각 제공 |
| 전송이 회복됐으니 정상 생산 | 연결 회복과 업무 상태를 따로 확인 |
| 빈 구간을 선으로 자연스럽게 연결 | 관측 공백을 드러내고 보간 여부 명시 |
| 오류가 나면 합계를 0으로 표시 | 계산 실패를 표시하고 마지막 유효 값의 시점 구분 |
관측값 0은 차트의 0 위치에 표시한다. 결측은 공백이나 별도 표식으로 표시하되 단위와 기간을 유지한다. 과거 값을 계속 보여주는 방식이 필요하다면 “현재 값” 대신 “마지막 확인 값”이라고 적고 시각을 붙인다. 데이터가 사라졌다는 이유로 빨강을 사용하면 실제 업무 위험과 수집 문제의 경계가 흐려질 수 있으므로 상태 명칭부터 분리한다.
결측 처리에는 예외와 책임 범위가 있다
관측이 없는 이유가 계획된 비가동 시간이라면 애초 수집 대상 구간에서 제외해야 할 수도 있다. 이때 확인율의 분모는 화면에 보이는 구간 수가 아니라 정의된 수집 대상 구간 수다. 업무 정의 없이 분모만 줄여 확인율을 높여서는 안 된다. 추정값을 쓰는 경우에는 원본과 추정값, 추정 방법과 적용 기간을 구별해 남긴다.
또한 유효 관측만 평균 내면 결측이 특정 상황에 몰릴 때 결과가 치우칠 수 있다. 문제가 생길 때만 수집이 실패하는 데이터라면 관측 평균이 운영 전체를 대표하지 않는다. 이 글의 계산은 결측을 복원하는 통계 기법이나 설비 정지 원인 분석을 대신하지 않는다.
배포 전 5가지 체크리스트
- 값 0, 값 없음, 아직 도착할 시간 전, 지연, 계산 실패를 구분하는가?
- 합계와 평균 옆에서 기간·단위·유효 관측 수·대상 수를 확인할 수 있는가?
- 원천 시각과 수신 시각을 분리하고 지연 기준을 문서에 적었는가?
- 늦은 도착과 중복 전송을 넣어 같은 기간의 집계 결과를 재확인했는가?
- 수집 문제를 업무 정지나 고장으로 단정하는 문구가 없는가?
지금 화면에서 빈칸 하나를 골라 보자. 그것이 실제 0인지, 미수집인지, 아직 집계 전인지 설명할 수 없다면 색상이나 차트보다 데이터 상태 정의부터 수정할 차례다.
함께 읽기: 비교 기간: 달력 마감과 데이터 마감을 나누는 법 · 색상 설계: 업무 상태와 주의 표시를 나누는 법