TL;DR
튀는 결과를 봤다고 원본 기록부터 삭제하지 않습니다. 단위·시각·기기·상태를 확인하고 제외 판단은 원본과 분리해 남깁니다. 원인을 확인하지 못하면 이상 의심 상태로 보존하고 확정된 고장으로 부르지 않는 편이 좋습니다.
이상값은 원인 이름이 아니다
디에이텍 AF-40BT는 공식 자료에서 테스트 이력 저장을 안내합니다. 제조사 기술 문의에서는 결과 하나만 보내는 것보다 앞뒤 이력과 설정을 함께 보내는 편이 원인 범위를 좁히는 데 도움이 됩니다. 눈에 띄게 다른 숫자는 추가 확인의 시작점일 뿐 센서 결함이라는 결론이 아닙니다. 특히 다른 단위나 다른 사용자 기록이 섞인 상황은 장치 성능 문제와 별도로 살펴야 합니다. 실제 경험으로 확인한 것처럼 특정 원인을 꾸며 쓰지 않습니다.
삭제 전에 대조할 기록
| 점검 축 | 확인 필드 예시 | 다른 결과와 대조할 점 |
|---|---|---|
| Device identity | device_serial_number, product_model, firmware_revision | 같은 장비·버전인가 |
| Measurement identity | source_test_number, source_event_identifier, original_result_text | 중복 또는 잘못 붙은 행인가 |
| Unit configuration | measurement_unit_original, active_unit_setting, configuration_revision | 숫자 크기만 다른 단위는 아닌가 |
| Timing context | device_measured_at, server_received_at, device_clock_note | 시계나 정렬 문제인가 |
| Validity context | sample_status, analysis_status, warning_status_original | 실패를 수치로 읽었는가 |
| Review decision | review_status, exclusion_reason, reviewer_reference | 제외 근거를 남겼는가 |
| Follow-up evidence | related_event_references, support_request_reference, resolution_note | 추가 확인 자료로 연결되는가 |
품질 검토와 통계 제외를 분리한다
수치가 낯설다는 이유만으로 통계에서 빼면 보기 좋은 결과만 남길 위험이 있습니다. 제외가 필요한 경우 사전에 정한 기준에 맞는지 확인하고, 원본을 유지한 채 분석용 뷰에서만 제외하는 방식을 제안합니다. 사유가 단위 미확인이라면 단위 확인 대기라고 쓰고 장치 고장이라고 바꾸지 않습니다. 지원 담당자가 검토한 뒤에도 원인이 확정되지 않았다면 미해결 항목을 그대로 남깁니다. 여러 기록에서 같은 패턴이 나타나는지 보는 일과 사용자의 측정값으로 안전을 판단하는 일도 혼동하지 않아야 합니다.
정상 범위처럼 보이는 값도 단위나 사람 연결이 잘못되면 문제가 될 수 있습니다. 눈에 띄는 수치만 찾는 검토와 별도로 연결 및 형식 점검을 유지하면 조용한 오류도 확인할 수 있습니다.
마무리
이상값 처리는 지우는 일이 아니라 맥락을 회복하는 일입니다. 원본·주변 이력·제외 사유를 함께 보존하면 나중에 원인이 밝혀져도 같은 기록을 다시 검토할 수 있습니다.
