가격표에서 숫자가 같으면 같은 비용이라고 읽기 쉽다. 실제 기술 데이터 도구의 단위 검산 코드를 읽으며 숫자보다 먼저 분모를 확인해야 한다는 판단을 새 합성 예제로 풀었다. 현재 제품과 제공자의 가격을 소개하는 글은 아니다.
분모가 바뀌면 비교 대상도 바뀐다
천 토큰당 값과 백만 토큰당 값은 같은 숫자여도 같은 단가가 아니다. 기존 작업에는 단위를 확인해 비교 기준으로 맞추는 검산이 있다. 나는 가격 순위와 보기 좋은 표보다 어떤 값을 어떤 분모로 읽었는지가 먼저 드러나야 한다고 보았다. 하나의 통화 표시만으로 단가의 의미가 모두 정해지지 않는다.
새 모듈은 per_1k와 per_1m만 받고 기준을 백만 단위로 맞춘다. 천 단위 값은 1000배한다. 다른 단위는 가까워 보이는 것으로 추정하지 않는다. 이것은 실제 제공자의 청구 규칙을 모두 모델링한 계산기가 아니라 단위가 명시된 작은 값의 비교 계약이다.
소수 문자열을 정확하게 읽었다
입력은 자리 수를 제한한 부호 없는 소수 문자열이다. Decimal로 계산해 이진 부동소수점의 표시 차이를 비교 판단에 끌어들이지 않는다. 숫자형과 참·거짓, 지수 표기와 NaN은 거절한다. 허용 형식을 좁히면 어떤 표현을 읽었는지 다시 확인하기 쉽다.
정확한 소수 계산이 원본 가격을 검증해 주지는 않는다. 잘못 옮긴 값도 형식은 정상일 수 있다. 나는 계산 표현의 정확성과 자료 사실의 확인을 별도로 설명했다. 실제 자료를 연결할 때는 원문 단위와 날짜, 조건이 필드에 맞게 옮겨졌는지 확인하는 절차가 필요하다.
단위만 다른 같은 값의 반례
합성 0.002 per_1k는 2 per_1m과 같다. 정규화 함수는 문자열로 2.000을 반환할 수 있지만 근거 비교는 Decimal 값으로 하므로 2와 일치한다. 문자열이 다르다는 이유로 서로 다른 가격이라고 표시하지 않았다. 단위 변환과 출력 형식의 책임을 나눈 것이다.
반대로 같은 2라도 두 단위가 다르면 백만 기준의 값은 다르다. 두 반례를 비교하면 값과 단위를 함께 읽어야 하는 이유를 확인할 수 있다. 예제에는 실제 회사 이름과 현재 가격을 쓰지 않았고 시장 비용을 추정하는 도구로 안내하지 않는다.
단위가 불분명하면 비교를 멈춘다
tokens처럼 분모가 빠진 표기는 거절한다. 편리하게 기본 단위를 정해 계산을 계속하면 실제 원문의 누락이 결과에서 사라질 수 있다. 사용자가 검토해야 할 불확실성을 0과 기본값으로 바꾸지 않는 방향이다. 상위 화면은 이 오류를 검토 필요로 보여 줄 수 있다.
현재 함수는 원문 문장을 자동 파싱하지 않는다. 사람이 준비한 value와 unit의 의미를 비교한다. 원문에서 어떤 숫자를 골랐는지, 캐시와 배치 같은 조건이 적용되는지는 별도 자료 검토다. 작은 단위 변환이 전체 청구 금액의 적합성을 보장한다고 말하지 않았다.
가격 외의 변경도 남겨 둔다
같은 값이 다른 단위로 다시 표현되면 가격 변경은 아니지만 표현 변경은 있다. 새 diff는 representation_fields를 따로 남긴다. 확인일과 근거 참조는 metadata_fields다. 비교 기준으로 맞춘 뒤에도 원래 값의 변화 흔적을 잃지 않는 구성이 필요했다.
이것은 원래 비교 코드가 일부 메타데이터를 무시하던 점에서 발전시킨 새 계약이다. 원본 도구를 수정하거나 실제 가격 피드를 호출한 것은 아니다. 작업 기록에서 찾은 질문을 공개 코드로 재현한 것이며 고객 프로젝트의 운영 상태를 바꿨다고 보고하지 않는다.
표를 믿기 전에 비교 기준을 읽는다
필드 근거 패키지의 12개 테스트에는 단위 변환과 모호한 단위, 값 표현과 메타데이터 변경, 중복 스냅샷 거절이 포함된다. ZIP을 새로 푼 환경에서도 통과했다. 실행 선택기는 실제 저장한 고정 결과이며 외부 가격을 최신으로 갱신하지 않는다.
다른 비교표에서도 단위는 열 제목에만 적고 데이터에서는 생략하기 쉽다. 나는 값과 단위를 함께 보관하고 변환 근거를 설명하는 방법을 공유하고 싶었다. 새로운 사업에 연결한다면 통화와 세금, 적용 조건을 같은 원칙으로 따로 모델링해야 한다. 지금 없는 조건을 표의 완성도만으로 채우지 않는다.