수량과 단가를 입력하면 공급가액과 합계가 바로 나와야 한다. 이 프로젝트에서도 가장 자연스럽고 구체적인 요구였다. 그런데 화면에 즉시 나오는 숫자와 저장된 전표의 숫자가 다르면 그 편리함은 신뢰를 잃는다. 나는 보관된 계산 코드와 점검 기록에서 작은 차이를 발견한 과정을 읽으며, 숫자를 다루는 화면은 예쁜 표시보다 먼저 같은 계산 계약을 가져야 한다는 기준을 다시 확인했다.
숫자를 읽는 순간부터 다른 값이 될 수 있다
문제는 반올림 함수 하나에만 있지 않았다. 당시 점검 기록에는 긴 소수 단가를 서버의 기본 정밀도로 계산하다가 중간 값이 먼저 바뀐 사례가 남아 있다. 원 단위로 반올림하기 전에 값이 절반 경계를 넘어 버리면 화면과 다른 결과가 저장된다. 마지막에 같은 반올림 규칙을 호출하더라도 그 함수에 들어가는 값이 이미 다르면 결과는 같아지지 않는다.
보관된 화면 코드는 소수 입력을 정수와 분모의 관계로 읽어 계산한다. 나는 여기서 특정 언어가 더 정확하다는 결론보다, 입력 문자열을 언제 숫자로 바꾸고 어떤 범위를 허용하는지가 중요하다고 본다. 계산 중간의 근사값을 다시 확정값으로 사용하지 않고, 합의한 경계에서만 반올림해야 한다. 화면의 보기 좋은 쉼표와 저장할 숫자의 표현도 따로 다루는 편이 명확하다.
행별 계산과 문서 합계를 같은 계약으로
여러 행의 금액을 각각 반올림한 뒤 더하는 것과 곱한 값을 전부 더한 뒤 한 번 반올림하는 것은 다를 수 있다. 세액 포함과 별도도 중간 순서가 달라진다. 이 구현에서는 행별 계산 결과를 문서 합계로 모으는 구조와 화면·서버의 비교 검사가 남아 있다. 독자가 참고할 것은 특정 숫자만이 아니라 어떤 단위에서 어떤 순서로 계산했는지다.
반품처럼 음수가 들어오는 경우도 양수 시험만으로 설명할 수 없다. 절반 바로 아래, 정확히 절반, 절반 바로 위의 양수와 음수를 한 쌍으로 준비하면 부호에 따라 달라지는 문제를 찾기 쉽다. 영처럼 보이는 음수 표기, 소수 수량의 합계, 포함·별도 전환도 함께 본다. 이것은 당시 프로그램의 계산 규칙에 대한 설명이며 모든 업무와 신고에 같은 계산법을 강제하는 안내는 아니다.
계산 실패를 영으로 감추지 않는다
입력 자릿수나 곱셈 결과가 처리 범위를 벗어날 수도 있다. 이때 무한대나 내부 오류를 합계 칸에 그대로 내보내거나 영으로 바꿔 저장하면 잘못된 전표가 만들어진다. 당시 보고서에는 큰 입력에서 내부 숫자 오류가 나던 경로를 범위 초과 안내와 저장 거부로 바꾼 기록이 있다. 실패를 설명하고 현재 입력을 유지하는 것도 계산 기능의 일부다.
화면에서 일부 행을 계산하지 못했는데 나머지만 더한 숫자를 최종 합계처럼 보여 주는지도 살펴야 한다. 서버 검증이 최종 저장을 막더라도 사용자는 화면의 숫자를 이미 다른 사람에게 전달할 수 있다. 내가 새 화면을 검토한다면 계산 불가 행과 임시 소계를 명확히 표시하고, 완전한 합계로 사용할 수 있는 상태를 따로 정한다. 오류 메시지는 어느 입력을 고쳐야 하는지도 알려 줘야 한다.
두 구현을 같은 예제로 대조하는 방법
검사는 수량과 단가, 세액 처리, 예상 결과를 가진 같은 사례 묶음을 화면 계산과 서버 계산에 넣는 방식으로 설계할 수 있다. 단순한 정수뿐 아니라 긴 소수, 반품, 허용 경계, 잘못된 문자열을 포함한다. 각 구현이 자기 내부 계산을 반복해 맞다고 주장하는 대신 실제 저장 응답의 행 금액과 문서 합계까지 대조해야 한다. 저장 실패 때 전표가 생기지 않는지도 별도로 확인한다.
이번 글에서는 보관된 코드와 당시 수정·검사 보고서를 확인했다. 회사의 기존 전표를 다시 계산하거나 현재 운영 서버에서 숫자를 시험하지 않았다. 과거 원본 금액을 보존하는 이관과 새 입력을 계산하는 기능도 다른 작업이다. 계산 오류를 고쳤다는 이유로 오래된 장부 전체를 새 공식으로 덮어쓰면 안 된다. 숫자의 정확함은 계산식과 함께 어느 기록에 그 식을 적용했는지까지 설명할 때 비로소 검토할 수 있다.