대부분의 개발자는 결국 이 코드 라인을 마주하게 됩니다:
typeof null // "object"
그리고 반응은 보통 즉각적입니다:
“기다려… 뭐지?”
왜냐하면 null는 객체가 아닙니다.
그것은 값의 의도적인 부재를 나타냅니다.
그래서 왜 JavaScript는 그것을 객체로 식별하는 걸까요?
조사가 시작됩니다
1990년대에, 자바스크립트 엔진은 속도와 메모리 효율성을 위해 설계되었습니다.
값은 아주 작은 32비트 메모리 컨테이너 내에 저장되었습니다.
저장되는 값의 종류를 빠르게 식별하기 위해 엔진은 숨겨진 이진 마커인 type tags를 사용했습니다.
이를 내부 증거 라벨처럼 생각해보세요.
비슷한 것과:
| 타입 | 개념 태그 |
|---|---|
| 객체 | 000 |
| 정수 | 001 |
| 문자열 | 010 |
| 불리언 | 011 |
(단순화된 개념적 표현)
중요한 실수
객체는 내부적으로 0 기반 타입 패턴과 연관되었습니다.
하지만null은 문제가 있었습니다.
그 내부 표현은本质上 모두 영어였습니다.
00000000000000000000000000000000
그래서 JavaScript가 값의 타입을 확인할 때…
우연히 객체 태그와 일치했습니다.
엔진은 효과적으로 해석했습니다.
“모두 영어”
를:
“객체”
그리고 그렇게…
null가 잘못 식별되었습니다.
왜 버그가 수정되지 않았을까요?
사고가 전 세계로 퍼졌기 때문입니다.
개발자들이 문제를 인지했을 때에는 이미 인터넷 전체의 웹사이트와 애플리케이션이 이 행동에 의존하고 있었습니다.
변경하면 기존의 대량의 코드가 손상될 것입니다.
그래서 버그가 영구적이게 되었습니다.
개발자의 대안 방법
작성 대신에
typeof value === "object"
개발자들은 안전하게 확인하는 방법을 배웠습니다.
value !== null && typeof value === "object"
그 추가 조건은 null가 유출되는 것을 방지합니다.
사건을 닫다
이 버그가 흥미로운 것은 잘못된 출력뿐만 아니라.
자바스크립트의 초기 단계에서의 작은 구현 세부 사항이...
여전히 수십 년 후에 현대 애플리케이션에서 생존하고 있다는 사실이.
하나의 작은 실수.
하나의 거대한 유산.
매우 이상한 사건 현장.
📹 감시 영상
전체 조사는 TikTok에서 제공됩니다:
증거를 보세요
네가 마주친 가장 이상한 JavaScript 동작은 무엇인가요?












