[JAVA SCRIPT] typeof null이 왜 "object"로 나오나요? 30년 된 설계 오류의 비밀

typeof null

 

자바스크립트(JavaScript)를 공부하다 보면 누구나 한 번쯤 당혹스러운 순간을 마주합니다. 분명히 비어 있는 값을 의미하는 null을 typeof 연산자로 검사했는데, 결과가 "object"라고 나오기 때문입니다. 객체가 아닌데 객체라고 주장하는 이 현상은 단순한 실수가 아니라, 자바스크립트의 탄생 비화와 깊은 연관이 있습니다. 오늘은 이 '역사적 유산'이 왜 발생했는지, 그리고 현대 개발 환경에서는 이를 어떻게 다뤄야 하는지 심층 분석해 보겠습니다.

1. 1995년, 10일의 기적이 남긴 흔적

자바스크립트의 창시자 브렌던 아이크(Brendan Eich)는 단 10일 만에 이 언어의 초안을 설계했습니다. 급박한 일정 속에서 데이터 타입을 메모리에 저장하는 방식이 결정되었는데, 이것이 30년이 지난 지금까지 우리를 괴롭히는 '버그'의 시초가 되었습니다.

메모리 태그(Type Tag)의 원리

당시 자바스크립트 엔진은 변수의 값을 저장할 때, 하위 비트 중 일부를 데이터 타입을 나타내는 '태그'로 사용했습니다. 초기 구현에서는 다음과 같은 규칙을 가졌습니다.

데이터 타입	메모리 타입 태그 (하위 비트)	설명
Object	000	데이터가 객체임을 나타냄
Int	1	31비트 부호 있는 정수
Double	010	부동 소수점 숫자
String	100	문자열 데이터
Boolean	110	논리값

문제는 null 값이었습니다. 당시 자바스크립트에서 null은 Null Pointer(0x00)로 표현되었습니다. 즉, 모든 비트가 0이었던 것이죠. 하위 비트 3개를 추출하여 타입을 판별하는 typeof 연산자의 입장에서 null의 하위 3비트(000)는 객체(Object)의 태그와 일치했습니다. 이것이 바로 typeof null === "object"가 된 결정적인 이유입니다.

---

2. 왜 지금까지 수정되지 않았을까?

자바스크립트 표준화 기구인 ECMA에서는 이 오류를 수정하려는 시도를 여러 번 했습니다. 실제로 typeof null === "null"로 변경하자는 제안이 있었으나 거절되었습니다. 그 이유는 '하위 호환성(Backward Compatibility)' 때문입니다.

이미 전 세계의 수많은 웹사이트가 if (typeof v === "object" && v !== null)과 같은 코드를 사용하여 null을 걸러내고 있습니다. 만약 이 동작을 수정한다면 기존의 수조 개의 웹 페이지가 순식간에 작동을 멈추거나 예상치 못한 오류를 뿜어낼 위험이 컸기 때문입니다.

---

3. 실무 대응 전략: 올바른 null 체크 방법

전문적인 개발자라면 typeof의 한계를 인지하고, 상황에 맞는 정확한 검증 방식을 사용해야 합니다.

비교 분석표: 객체와 Null 구분하기

검사 방법	결과 (null일 때)	신뢰도	추천 용도
typeof value === "object"	true (오류)	낮음	사용 비권장
value === null	true	매우 높음	단순 null 확인
Object.prototype.toString.call(value)	"[object Null]"	최상	정밀한 타입 판별

---

4. Sample Example: 견고한 타입 검사 함수

다음은 실무에서 활용할 수 있는, null의 함정을 피하는 유틸리티 함수 예시입니다.

/**
 * 값이 실제 객체(null 제외)인지 확인하는 함수
 */
function isRealObject(val) {
    // typeof val이 "object"이면서 동시에 null이 아니어야 함
    return val !== null && typeof val === "object";
}

/**
 * 완벽한 타입 이름을 반환하는 함수
 */
function getExactType(val) {
    return Object.prototype.toString.call(val).slice(8, -1).toLowerCase();
}

console.log(isRealObject({}));   // true
console.log(isRealObject(null)); // false

console.log(getExactType(null));      // "null"
console.log(getExactType([]));        // "array"
console.log(getExactType(new Date())); // "date"

---

5. 결론: 버그조차 언어의 일부가 될 때

typeof null이 "object"인 것은 명백한 설계 오류입니다. 하지만 이를 통해 우리는 기술의 발전 과정에서 '호환성'이 얼마나 중요한 가치를 지니는지 배울 수 있습니다. 자바스크립트는 완벽해서 살아남은 것이 아니라, 변화에 유연하게 대처하고 과거를 포용하며 성장했기에 오늘날 가장 영향력 있는 언어가 되었습니다. 이러한 디테일을 이해하는 것이 바로 시니어 개발자로 가는 첫걸음입니다.

참고 문헌 및 출처

1. Dr. Axel Rauschmayer, "The history of “typeof null”", 2-ality (2013).
2. MDN Web Docs, "typeof operator - null", Mozilla Foundation.
3. Brendan Eich's personal blog and interviews on JS history.
4. ECMA-262 Specification, "The typeof Operator".