NASA의 1억 2500만 달러짜리 단위 오류: API에 명시적인 명명이 필요한 이유

1999년 화성 기후 궤도선 파괴는 미터법과 야드파운드법 간의 단위 불일치로 인해 발생했습니다. 추력기 소프트웨어는 뉴턴 단위를 사용했지만, 입력 데이터는 파운드-힘 단위를 사용하여 치명적인 실패를 초래했습니다. 단위가 없는 원시 숫자는 본질적으로 위험하며 소프트웨어에서 조용한 오류를 유발할 수 있습니다. 컴퓨터는 맥락을 고려하지 않고 숫자를 처리하므로 단위 오류를 간과하기 쉽습니다. 이러한 오류를 방지하려면 필드 이름에 단위를 포함시켜 코드가 자체적으로 문서화되도록 하십시오. 모호한 이름 대신 `size_bytes` 또는 `price_cents_usd`와 같은 명시적인 필드 이름을 사용하십시오. Typescript와 같은 언어의 브랜드 타입은 컴파일 시간에 단위 안전성을 보장하여 호환되지 않는 단위 연산을 방지합니다. 단위 정보를 문서에만 의존하는 것은 쉽게 놓칠 수 있으므로 충분하지 않습니다. 내부적으로 SI 단위를 표준화하는 것이 가장 좋은 방법이지만, 일관성을 유지하는 것이 중요합니다. 레거시 시스템의 경우, 새롭고 명시적인 필드를 도입하고 기존 필드를 점진적으로 폐기하십시오. 부동 소수점 정밀도 문제를 피하기 위해 통화 및 시간과 같은 단위에는 정수를 사용하는 것이 좋습니다.