그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록JavaScript
JavaScript

JavaScript에서 0.1 + 0.2 === 0.3이 false인 이유는 무엇인가요?

실무4/5
설계4/5
인간4/5
기초4/5

면접관의 질문 의도

결과를 외웠는지가 아니라, 이진 부동소수점의 한계를 알고 도메인에 맞는 대응을 골라 쓸 수 있는지 가르려는 질문이다.

큐레이션 답변

학습 자료

JavaScript의 number는 IEEE 754 배정밀도 부동소수점 한 형식뿐인데, 0.1·0.2 같은 십진 분수는 이진수로 정확히 떨어지지 않아 가까운 값으로 근사된다. 그 근사값끼리 더하면 0.30000000000000004 같은 값이 나와 === 0.3 비교가 실패한다. 대응은 도메인 정확도에 따라 갈린다. 금액처럼 정확해야 하면 센트·원 단위 정수로 스케일링하거나 decimal 라이브러리·BigInt를 쓰고, 그래픽·물리처럼 작은 오차가 허용되면 Math.abs(a - b) < Number.EPSILON 같은 허용 오차 비교로 푼다.

좋은 답변 구조

  1. 010.1 + 0.2가 0.3과 같지 않다는 사실을 먼저 단정한다
  2. 02이진 부동소수점의 표현 한계와 IEEE 754를 원인으로 짚는다
  3. 03근사값이 실제 메모리에 어떻게 들어가는지 한 줄로 설명한다
  4. 04정수 스케일링·decimal·허용 오차 비교 같은 대응을 도메인 기준으로 정리한다

자주 실수하는 포인트

toFixed로 만든 문자열을 다시 number로 변환해 같은 오차에 다시 노출된다
Number.EPSILON 하나로 모든 정확도 요구를 해결할 수 있다고 본다
결제·세금 계산을 별 고민 없이 number 그대로 더해 누적 오차를 키운다

실무 맥락

  • 결제 금액·할인·세금처럼 합계가 누적되는 정산 코드
  • 차트·통계·실시간 지표에서 작은 오차가 시각적으로 드러나는 화면
  • 테스트에서 실수 비교 결과가 환경에 따라 달라지는 플레이크 상황

본인 경험에 녹이는 힌트

금액 계산을 number에서 정수·decimal로 옮겨 정산 오차를 줄여 본 경험이 있다면 도메인별 대응 사례로 연결할 수 있다

공통 실수 비교 헬퍼를 만들어 본 적이 있다면 허용 오차 기준 선택 관점으로 엮을 수 있다

오차 허용 범위를 PM·QA와 합의해 본 경험이 있다면 정확도 요구를 코드로 옮기는 과정으로 말할 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1정수 스케일링 방식의 장단점은 무엇인가요
Q2BigInt는 이 문제를 언제 해결하고 언제 못하나요
Q3decimal 라이브러리를 도입할 기준은 무엇인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문