TL;DR
원본은 장치가 제공한 형태로 남기고 반올림은 표시 단계에서 수행하는 편이 좋습니다. 장치 자체의 표시 규칙과 서버가 추가하는 규칙을 구분해야 합니다. 경계값 비교와 내보내기는 같은 규칙을 참조하는지 확인합니다.
원본과 화면 숫자의 책임을 나눈다
디에이텍 AF-40BT 공식 정보는 날짜·시간·결과값 저장 기능을 안내합니다. 이 저장값을 서버로 옮긴다면 제조사 측 기록과 서비스의 화면 표현을 구분하는 것이 중요합니다. 이미 반올림된 장치값에서 사라진 자릿수를 다시 만들어 낼 수는 없습니다. 따라서 장치가 실제 제공한 문자열을 보존하고 서버의 파싱·표시 규칙은 별도 문서로 두는 방식을 제안합니다. 아래 필드는 제품 공식 프로토콜이 아니라 연동 설계 예시입니다.
각 단계에서 남길 자료
| 단계 | 필드 예시 | 검토할 행동 |
|---|---|---|
| Reception | source_numeric_text, source_unit_text, received_payload_reference | 수신 원문을 변형 없이 보존 |
| Parsing | parsed_decimal_value, parser_version, parse_error_reason | 부동소수점 처리 영향을 확인 |
| Evaluation | evaluation_input_value, comparison_rule_version, evaluation_unit | 표시값으로 판정했는지 구별 |
| Rendering | displayed_value_text, decimal_place_setting, rounding_method | 반올림 규칙을 명시 |
| Export | exported_value_text, export_format_revision, original_value_included | 화면 복사인지 원본 내보내기인지 표시 |
| Regression | input_fixture_reference, expected_display_text, expected_export_text | 같은 예제로 변경 전후 확인 |
| Change review | affected_report_list, implementation_release_reference, approved_by | 과거 보고서 영향도 검토 |
끝자리 처리도 시험 예제가 필요하다
테스트에는 끝자리 영이 있는 값, 지정 자리수의 중간에 걸리는 값, 빈칸, 숫자가 아닌 상태를 넣습니다. 실제 농도나 사람의 결과 대신 형식 검증용 가상값을 사용하면 됩니다. 입력을 여러 번 반올림한 후 다시 반올림하면 처음부터 한 번만 처리했을 때와 달라질 수 있으므로 가공 단계를 줄이는 편이 좋습니다. 보고서와 앱이 다르게 보일 경우 장치 오차라고 부르기 전에 각 단계의 표시 규칙을 비교합니다. 정상 범위의 숫자만 시험하면 실패나 범위 초과가 잘못 변환되는 문제를 놓칠 수 있습니다.
개발 검토에서는 화면, 파일, API를 같은 입력 예제로 확인하는 작은 대조표를 남기는 방식을 제안합니다. 화면에서만 끝자리 영이 사라진 것과 실제 저장값이 바뀐 것을 구별하면 수정할 위치를 좁힐 수 있습니다.
마무리
반올림의 위치를 한 군데로 정하되 장치 내부에서 이미 이루어진 처리는 별도로 기록합니다. 원본과 표시본을 구분하면 디자인 변경 뒤에도 같은 측정 기록을 다시 설명할 수 있습니다.
