JavaScript에서 두 값이 “같은지” 비교하는 방법은 하나가 아닙니다. == 연산자(추상적 동등)와 === 연산자(엄격한 동등)는 겉보기에 비슷해 보이지만, 내부적으로 전혀 다른 알고리즘으로 동작합니다. ==는 비교 전에 피연산자의 타입을 자동으로 변환하는 반면, ===는 타입과 값을 모두 그대로 비교합니다. 이 차이를 제대로 이해하지 못하면 버그의 원인을 찾는 데 수십 분에서 수 시간을 낭비할 수 있으며, 오랜 경험을 가진 개발자도 간혹 이 연산자들 앞에서 예상치 못한 결과를 마주칩니다.
🔍 핵심 문제점
==비교 시 JavaScript가 자동으로 타입을 변환하기 때문에, 서로 다른 타입의 값이 “같다”고 판정되는 상황이 발생합니다- 어떤 타입이 어떤 타입으로 변환되는지 규칙이 직관적이지 않아, 결과를 예측하기 어렵습니다
null과undefined처럼 특수한 값들은==로 비교할 때 독특한 예외 규칙을 따릅니다===를 무조건 사용하는 것이 항상 옳은 것은 아니며,==가 유용한 특수한 상황도 존재합니다- 두 연산자의 동작 차이를 모르면 조건문이나 데이터 검증 로직에서 조용한 오류(silent bug)가 발생할 수 있습니다
왜 중요한가?
실무에서 ==와 ===의 혼용은 예측 불가능한 버그의 주요 원인 중 하나입니다. 서버에서 받아온 데이터가 문자열 타입인지 숫자 타입인지 명확하지 않을 때, 잘못된 연산자 선택 하나로 인해 결제 금액 비교나 사용자 권한 검사 같은 중요한 로직이 오동작할 수 있습니다. 또한 코드 리뷰 과정에서 동료 개발자에게 “왜 여기서 ==를 썼나요?”라는 질문을 받을 때 명확히 설명하지 못한다면, 코드의 신뢰성에 의문이 생깁니다. 두 연산자 뒤에 숨은 알고리즘과 설계 철학을 이해하면, 상황에 맞는 연산자를 의도적으로 선택할 수 있고, 코드에서 타입 관련 버그가 발생했을 때 신속하게 원인을 파악할 수 있습니다. 나아가 ESLint 같은 정적 분석 도구가 왜 특정 비교 방식에 경고를 내리는지도 근본적으로 이해할 수 있게 됩니다.
핵심 개념
엄격한 동등 연산자 (===)
입문
===는 두 값이 “완전히 똑같은지” 확인하는 가장 정직한 비교 방법이에요. 값의 종류(타입)와 내용이 모두 일치해야만 같다고 판정해요.
🔍 같은 번호라도 쪽지와 구슬은 달라요
여기 숫자 5가 적힌 쪽지 한 장과 진짜 구슬 5개가 있어요. 둘 다 “5”와 관련 있지만, 쪽지와 구슬은 종류 자체가 달라요. ===는 이처럼 값의 내용만 보는 게 아니라 “종류”까지 함께 확인해요. 쪽지(문자열 “5”)와 구슬(숫자 5)은 ===로 비교하면 다르다고 판정해요.
📋 같은 내용의 시험지라도 복사본은 달라요
친구와 내가 똑같은 답을 쓴 시험지가 있어도, 물리적으로 다른 종이예요. 객체나 배열도 마찬가지로, 내용이 같아 보여도 다른 곳에 저장된 것이라면 ===는 “다르다”고 판정해요. 오직 같은 물건을 가리키는 경우에만 같다고 해요.
✅ 언제 같다고 판정하나요?
===가 “같다”고 판정하려면 두 가지 조건이 모두 맞아야 해요. 첫째, 두 값의 종류(문자열인지, 숫자인지, 참/거짓인지)가 같아야 해요. 둘째, 값의 내용도 정확히 같아야 해요. 하나라도 다르면 바로 “다르다”고 결론 내려요.
🎯 왜 ===가 더 안전한가요?
===는 예상치 못한 변환 없이 있는 그대로 비교하기 때문에, 결과를 예측하기 쉬워요. 마치 수학 시험에서 “정확히 똑같은 답”만 맞다고 인정하는 것처럼, 애매함이 없어서 코드 실수를 줄일 수 있어요.
중급
=== 연산자는 **엄격한 동등 비교(Strict Equality Comparison)**를 수행합니다. 피연산자의 타입 변환 없이 타입과 값을 동시에 비교하며, 두 가지 중 하나라도 다르면 즉시 false를 반환합니다.
비교 순서
- 두 피연산자의 타입(type)이 다르면 →
false - 타입이 같으면 값(value)을 비교
- 단,
NaN === NaN은false(유일한 예외) +0 === -0은true
// 타입이 다르면 false
console.log(1 === "1"); // false (number vs string)
console.log(true === 1); // false (boolean vs number)
console.log(null === undefined); // false (다른 타입)
// 타입과 값이 모두 같아야 true
console.log(1 === 1); // true
console.log("hello" === "hello"); // true
console.log(true === true); // true// 객체는 참조(reference)를 비교
const a = { x: 1 };
const b = { x: 1 };
const c = a;
console.log(a === b); // false (내용이 같아도 다른 객체)
console.log(a === c); // true (같은 객체를 참조)
// NaN 예외
console.log(NaN === NaN); // false (자기 자신과도 다름)
console.log(Number.isNaN(NaN)); // true (올바른 NaN 검사 방법)심화
===는 ECMAScript 명세의 The Abstract Equality Comparison Algorithm과 구분되는 The Strict Equality Comparison Algorithm (Section 7.2.16)을 구현합니다. 타입 강제 변환(Type Coercion)이 전혀 없으며 순수하게 값 동일성(Value Identity)을 비교합니다.
ECMAScript 명세 Section 7.2.16 - Strict Equality Comparison
명세는 x === y를 다음과 같은 정형적 알고리즘으로 정의합니다:
Type(x) !== Type(y)→false반환Type(x) == Number또는BigInt인 경우 →Number::equal(x, y)또는BigInt::equal(x, y)호출SameValueNonNumeric(x, y)호출
특히 Number::equal은 IEEE 754-2019의 compareQuietEqual 연산을 따르므로, NaN에 대해 항상 false를 반환하고 +0과 -0은 동일하게 처리합니다. 이는 Object.is() (SameValue 알고리즘, Section 7.2.15)와의 핵심 차이점으로, Object.is(NaN, NaN)은 true, Object.is(+0, -0)은 false를 반환합니다.
V8 엔진 구현 - Turbofan과 Hidden Class 최적화
V8은 === 비교를 Turbofan JIT 컴파일러 수준에서 최적화합니다. 동일한 Hidden Class를 가진 객체들의 참조 비교는 포인터 동등성 검사(Pointer Equality Check)로 단순화되어 O(1) 연산이 됩니다. 반면 원시값(Primitive)의 경우 타입 태그(Type Tag) 비교 후 값 비교를 수행하는 2단계 검사가 이루어지며, Inline Cache(IC) 메커니즘이 반복 비교를 가속합니다. 현대 엔진에서 ===의 성능은 ==와 거의 동일하며, 타입 강제 변환이 없어 오히려 예측 가능한 최적화 경로를 제공합니다.
추상적 동등 연산자 (==)와 타입 강제 변환 규칙
입문
==는 두 값을 비교할 때 “최대한 비슷하게 맞춰서” 비교하는 연산자예요. 종류(타입)가 다르면 JavaScript가 자동으로 한쪽을 변환해서 비교해요.
🤝 번역가처럼 맞춰서 비교해요
한국어로 쓰인 편지와 영어로 쓰인 편지가 있다고 해봐요. 내용이 같은지 확인하려면 먼저 같은 언어로 번역해야 하죠. ==도 마찬가지로, 타입이 다른 두 값을 비교하기 전에 JavaScript가 하나를 다른 타입으로 자동 번역(변환)해서 비교해요.
🔢 숫자로 통일해서 비교할 때가 많아요
==의 가장 흔한 변환 규칙은 “숫자로 바꾸기”예요. 예를 들어 숫자 1과 문자열 “1”을 ==로 비교하면, JavaScript가 문자열 “1”을 숫자 1로 바꾼 다음 비교해요. 그래서 결과가 “같다”가 돼요. 하지만 이런 자동 변환이 항상 예상대로 되는 건 아니에요.
😵 예상과 다른 결과가 나올 수 있어요
"" == 0은 왜 같을까요? 빈 문자열을 숫자로 바꾸면 0이 되기 때문이에요. false == 0은요? 거짓(false)을 숫자로 바꾸면 0이 되기 때문에 같아요. 이처럼 자동 변환 규칙을 모르면 결과를 예측하기 어려워요.
🧩 변환 규칙이 복잡해요
다양한 타입 조합마다 어떤 타입으로 변환할지 규칙이 다르게 적용돼요. 불리언(true/false)은 먼저 숫자로 바뀌고, 문자열과 숫자가 만나면 문자열이 숫자로 바뀌어요. 규칙을 외우기보다 ===를 쓰는 게 훨씬 편리해요.
중급
== 연산자는 **추상적 동등 비교(Abstract Equality Comparison)**를 수행합니다. 타입이 다른 경우 정해진 우선순위 규칙에 따라 타입을 강제 변환(Type Coercion)한 후 비교합니다.
주요 타입 강제 변환 규칙 (우선순위 순)
null == undefined→true(유일하게 정의된 특별 규칙)null또는undefined와 다른 타입 비교 →falseboolean이 포함되면 →boolean을Number로 변환 후 재비교string과number비교 →string을Number로 변환 후 비교object와 원시값 비교 →object.valueOf()또는object.toString()호출
// boolean → number 변환
console.log(true == 1); // true (true → 1)
console.log(false == 0); // true (false → 0)
console.log(true == 2); // false (true → 1, 1 !== 2)
// string → number 변환
console.log("1" == 1); // true ("1" → 1)
console.log("" == 0); // true ("" → 0)
console.log("2" == 2); // true
// null/undefined 특별 규칙
console.log(null == undefined); // true (특별 규칙)
console.log(null == 0); // false (null은 오직 undefined와만 ==)
console.log(null == false); // false// 객체는 valueOf/toString으로 원시값 변환
console.log([] == 0); // true ([] → "" → 0)
console.log([] == false); // true ([] → "" → 0, false → 0)
console.log([1] == 1); // true ([1] → "1" → 1)
console.log({} == "[object Object]"); // true ({} → "[object Object]")심화
==는 ECMAScript 명세 Section 7.2.15 - Abstract Equality Comparison이 정의하는 다단계 알고리즘으로 구현됩니다. 이 알고리즘은 ToPrimitive, ToNumber, ToString 추상 연산(Abstract Operations)의 조합으로 타입 강제 변환을 수행합니다.
ECMAScript Section 7.2.15 알고리즘 분석
x == y의 완전한 알고리즘 (요약):
Type(x) === Type(y)→ Strict Equality로 위임null == undefined→true(또는 반대)null/undefined와 다른 타입 →falseType(x) == Number && Type(y) == String→x == ToNumber(y)재귀 호출Type(x) == String && Type(y) == Number→ToNumber(x) == y재귀 호출Type(x) == Boolean→ToNumber(x) == y재귀 호출 (boolean 우선 변환)Type(y) == Object && Type(x)가 String/Number/Symbol →x == ToPrimitive(y)
ToPrimitive와 Symbol.toPrimitive 커스터마이징
ToPrimitive 추상 연산(Section 7.1.1)은 힌트(hint: “default”, “number”, “string”)에 따라 객체를 원시값으로 변환합니다. Symbol.toPrimitive가 정의된 경우 이를 우선 호출하고, 없으면 valueOf() → toString() 순서로 폴백합니다. 이 메커니즘을 통해 커스텀 객체의 == 동작을 재정의할 수 있습니다.
const custom = {
[Symbol.toPrimitive](hint) {
if (hint === 'number') return 42;
return 'custom';
}
};
console.log(custom == 42); // true (number 힌트)
console.log(custom == 'custom'); // true (default 힌트)설계 철학: Brendan Eich의 의도와 한계
==의 타입 강제 변환은 1995년 자바스크립트 초기 설계에서 “비전문가 친화적 언어”를 목표로 도입되었습니다. 타입을 명시하지 않아도 “의미 있는” 비교가 되도록 의도했으나, 결과적으로 null == undefined처럼 의도적 예외와 [] == ![]처럼 비직관적 결과가 공존하는 복잡한 명세가 되었습니다. ESLint의 eqeqeq 규칙이 == 사용을 경고하는 근거가 이 복잡성에 있으며, 현대 코드베이스에서 null == undefined 관용구를 제외한 == 사용은 기피됩니다.
null과 undefined의 특별한 동등 규칙
입문
null과 undefined는 JavaScript에서 “아무것도 없다”는 의미를 가진 두 가지 특별한 값이에요. 이 두 값은 ==로 비교할 때 아주 독특한 규칙을 따라요.
📭 빈 우편함 vs 우편함 자체가 없음
undefined는 우편함이 있는데 아무 편지도 없는 상태예요. null은 아예 우편함이 없다고 신고한 상태예요. 서로 표현하는 방식은 다르지만, 결국 둘 다 “편지가 없음”이라는 점에서 ==는 이 둘을 같다고 판정해요.
🤝 딱 둘만의 특별한 사이
null == undefined는 true예요. 그런데 null == 0은 false이고, null == false도 false예요. null과 undefined는 오직 서로에게만 관대해요. 다른 어떤 값과 ==로 비교해도 항상 false가 돼요.
🔒 언제 활용할 수 있나요?
값이 null이거나 undefined인지 한 번에 확인할 때 == null 패턴을 쓸 수 있어요. if (value == null)이라고 쓰면 value가 null인 경우와 undefined인 경우를 동시에 잡을 수 있어요. 이건 ==를 의도적으로 사용하는 몇 안 되는 상황 중 하나예요.
⚠️ ===로 비교하면 어떻게 되나요?
null === undefined는 false예요. ===는 타입까지 비교하는데, null의 타입은 null이고 undefined의 타입은 undefined라서 서로 달라요. 둘을 구분해야 한다면 ===를 쓰고, 둘 다 없는 값으로 처리하고 싶다면 == null을 써요.
중급
null과 undefined는 == 비교에서 ECMAScript 명세가 명시적으로 정의한 특별 규칙을 적용받습니다. 이 규칙에 의해 null == undefined는 true이며, 두 값 모두 다른 어떤 값과 ==로 비교해도 false를 반환합니다.
이 특성을 이용한 value == null 관용구(idiom)는 값이 “없음” 상태인지 확인하는 가장 간결한 방법이며, 일부 스타일 가이드에서 == 사용을 허용하는 유일한 예외입니다.
// 특별 규칙: null == undefined
console.log(null == undefined); // true
console.log(null === undefined); // false (타입이 다름)
// null은 오직 undefined와만 ==
console.log(null == 0); // false
console.log(null == ""); // false
console.log(null == false); // false
console.log(null == NaN); // false
// 실용적인 == null 패턴
function processValue(value) {
if (value == null) {
// value가 null이거나 undefined인 경우를 한번에 처리
return "값이 없습니다";
}
return value;
}
console.log(processValue(null)); // "값이 없습니다"
console.log(processValue(undefined)); // "값이 없습니다"
console.log(processValue(0)); // 0 (falsy지만 null/undefined 아님)
console.log(processValue("")); // "" (falsy지만 null/undefined 아님)// null과 undefined를 구분해야 하는 경우
function apiResponse(data) {
if (data === null) {
console.log("서버가 명시적으로 null 반환"); // 의도된 빈 값
} else if (data === undefined) {
console.log("데이터 없음 (키 자체가 없음)"); // 미정의 상태
} else {
console.log("데이터:", data);
}
}심화
null == undefined 관계는 ECMAScript Section 7.2.15 알고리즘에서 Steps 2-3로 명시적으로 하드코딩되어 있습니다. 이는 타입 강제 변환 체인의 결과가 아니라 명세 수준의 예외 처리입니다.
명세 레벨 특례와 설계 배경
명세 알고리즘에서 x == y를 평가할 때:
x가null이고y가undefined→true반환 (Step 2)x가undefined이고y가null→true반환 (Step 3)x또는y가null/undefined이고 상대방이 다른 타입 →false반환 (Step 4)
이 설계는 typeof null === "object"라는 초기 버그와 맞물려, null을 “의도적 부재”로, undefined를 “비의도적 부재”로 구분하면서도 의미론적으로 “없음”이라는 공통 개념으로 묶기 위한 실용적 타협입니다.
TypeScript와 정적 분석 관점
TypeScript의 strict 모드와 strictNullChecks 옵션은 null과 undefined를 구분된 타입으로 취급합니다. value == null 패턴은 TypeScript 타입 가드(Type Guard)로 인식되어 해당 블록 밖에서 value의 타입에서 null | undefined를 자동으로 제거합니다. 이는 value === null || value === undefined 조건의 의미론적 동치이며, TypeScript 컴파일러가 두 표현을 동일하게 타입 좁히기(Type Narrowing)에 활용합니다. ESLint eqeqeq 규칙도 "smart" 또는 "allow-null" 옵션으로 이 관용구를 예외로 허용합니다.
실무 사용 가이드라인과 선택 기준
입문
==와 === 중 어떤 걸 써야 할지 헷갈린다면, 간단한 규칙 하나만 기억해요. 거의 모든 경우에 ===를 쓰고, == null 한 가지 경우에만 ==를 허용해요.
🎯 기본 원칙: ===를 써요
평소에는 ===를 사용하는 게 가장 안전해요. 타입 변환 없이 있는 그대로 비교하므로, 예상치 못한 결과가 나올 확률이 거의 없어요. 마치 정확한 저울로 무게를 재는 것처럼, 정확하게 비교해줘요.
✅ 예외: value == null은 괜찮아요
null인지 undefined인지 둘 다 한 번에 확인하고 싶을 때는 == null을 쓰는 게 허용돼요. if (value == null)은 “값이 아예 없는 상태”인지 확인하는 깔끔한 방법이에요. 이건 의도적으로 ==를 사용하는 경우예요.
🚫 절대 피해야 할 것들
==를 쓰면 결과를 예측하기 어려운 비교들이 있어요. 예를 들어 [] == false나 "" == 0 같은 비교는 이유를 알아야 결과를 예측할 수 있어요. 모르는 상태에서 쓰면 버그를 만들어요. 이런 비교가 필요한 상황이라면 먼저 명시적으로 타입을 변환한 다음 ===로 비교하는 게 좋아요.
🔧 팀에서 어떻게 정하나요?
대부분의 팀에서는 ESLint 규칙으로 === 사용을 강제해요. 이 규칙을 켜두면 ==를 썼을 때 경고가 뜨기 때문에, 팀 전체에서 일관된 비교 방식을 유지할 수 있어요.
중급
실무에서 ==와 === 선택 기준은 명확합니다. 기본값은 ===, 예외는 == null 패턴 하나입니다.
=== 사용 규칙 (대부분의 경우)
- 타입이 확실한 값들 간의 비교
- API 응답 데이터와 상수 비교
- 조건문, 스위치문에서의 비교
- 배열이나 객체의 동일성 확인
== null 예외 사용 (유일한 허용 패턴)
- 값이
null또는undefined중 하나인지 확인할 때 - 선택적 파라미터(optional parameter) 처리 시
// 나쁜 예 - == 남용
function bad(input) {
if (input == 1) { ... } // 문자열 "1"도 통과됨
if (input == true) { ... } // 예상치 못한 변환
if (input == "") { ... } // 0과 false도 통과
}
// 좋은 예 - === 사용 + 명시적 변환
function good(input) {
if (Number(input) === 1) { ... } // 명시적으로 숫자 변환 후 비교
if (input === true) { ... } // 정확히 true인 경우만
if (input === "") { ... } // 정확히 빈 문자열인 경우만
// 유일한 == 허용 패턴
if (input == null) { // null이거나 undefined인 경우
return defaultValue;
}
}// .eslintrc.js
module.exports = {
rules: {
// "always"는 항상 ===, null 비교 시 == 예외 허용은 "smart" 사용
"eqeqeq": ["error", "always", { "null": "ignore" }]
}
};
// 위 설정으로 아래 코드는 에러, 아래는 허용
if (value == 1) { } // ESLint Error
if (value == null) { } // OK (null 예외 허용)
if (value === 1) { } // OK심화
==와 ===의 선택은 단순한 코딩 스타일 문제가 아니라 **타입 안전성(Type Safety)과 의도 명시성(Intent Clarity)**의 설계 결정입니다. 현대 JavaScript 생태계에서의 컨센서스와 그 근거를 분석합니다.
정적 분석 도구의 진화와 eqeqeq 규칙
ESLint의 eqeqeq 규칙은 Douglas Crockford의 “JavaScript: The Good Parts” (2008)의 === 권고를 코드베이스에 강제하기 위해 설계되었습니다. 규칙 옵션의 진화:
"always": 예외 없이===강제"smart":null비교,typeof비교, 리터럴 비교에서==허용"allow-null":null비교에서만==허용
Google Style Guide, Airbnb Style Guide, TypeScript 공식 가이드라인 모두 eqeqeq: "error" 또는 이에 준하는 규칙을 채택합니다.
TypeScript에서의 완전한 해결
TypeScript strict 모드에서는 ==의 타입 강제 변환이 일부 컴파일 타임에 감지됩니다. string == number 비교는 TypeScript 4.x+에서 타입 오류로 검출되어, 런타임 버그를 컴파일 단계에서 사전 차단합니다. 이는 ===를 강제하는 것과 유사한 효과를 달성하며, TypeScript 도입 시 == 관련 버그 클래스가 사실상 소멸합니다.
== null 관용구의 유일한 정당성
value == null이 value === null || value === undefined보다 선호되는 이유는 단순 코드 길이가 아닙니다. 의미론적으로 “값이 존재하지 않는 상태”라는 단일 개념을 표현하며, TypeScript의 타입 가드로도 인식됩니다. 단, Optional Chaining(?.)과 Nullish Coalescing(??) 연산자(ECMAScript 2020)가 도입된 이후 null/undefined 처리 패턴이 다양해졌으며, value == null은 여전히 간결하고 명확한 선택지로 유지됩니다.