암묵적 타입 변환은 왜 일어날까?

연산자 사용 시 JavaScript 엔진이 자동으로 수행하는 암묵적 타입 강제 변환의 규칙과 원리를 이해하고, 예상치 못한 동작을 예방합니다

JavaScript에는 개발자가 명시적으로 변환 코드를 작성하지 않아도 엔진이 스스로 값의 타입을 바꾸는 암묵적 타입 변환(Implicit Type Coercion) 메커니즘이 내장되어 있습니다. 이 변환은 연산자를 사용하거나 조건식을 평가할 때 조용히 발생하기 때문에, 개발자가 의도하지 않은 결과로 이어지는 경우가 매우 많습니다. 암묵적 타입 변환의 규칙을 이해하지 못하면, 디버깅하기 어려운 버그가 코드 곳곳에 숨어들게 됩니다. 반대로 이 메커니즘을 정확히 파악하고 있다면, 복잡한 코드에서 예상치 못한 동작을 빠르게 짚어내고 더 안전하고 명확한 코드를 작성할 수 있습니다.

🔍 핵심 문제점

동일해 보이는 연산이 피연산자의 타입에 따라 전혀 다른 결과를 만들어 낸다
비교 연산자(==)와 덧셈 연산자(+)는 특히 암묵적 변환이 빈번하게 일어나 혼란의 주된 원인이 된다
조건식에서 숫자, 문자열, 객체, null, undefined 등 다양한 값이 true 또는 false로 변환되는 규칙이 직관에 어긋날 수 있다
타입 변환이 연쇄적으로 일어나는 복잡한 표현식에서는 최종 타입을 예측하기 더욱 어렵다
런타임에서만 드러나는 특성 때문에 정적 분석만으로는 문제를 미리 발견하기가 쉽지 않다

💡 실무에서의 영향

프론트엔드 개발 현장에서 암묵적 타입 변환은 생각보다 훨씬 자주 마주치는 문제입니다. 사용자 입력 값은 기본적으로 문자열로 넘어오기 때문에, 이를 숫자와 비교하거나 더하는 연산을 작성할 때 의도치 않은 변환이 발생하여 계산 결과가 틀리거나 조건 분기가 잘못 흐르는 상황이 쉽게 생깁니다. API 응답 데이터를 가공할 때도 값의 타입이 예상과 다를 경우 암묵적 변환이 조용히 끼어들어 화면에 엉뚱한 값이 렌더링될 수 있습니다. 또한 조건문의 truthy/falsy 평가를 잘못 이해하면, 빈 배열이나 빈 객체를 false로 취급하려다 반대 결과를 얻는 고전적인 실수로 이어집니다. 결국 암묵적 타입 변환의 동작 원리를 명확히 아는 것은, 버그 발생 가능성을 줄이고 코드 리뷰 시 잠재적 문제를 빠르게 식별하는 핵심 역량이 됩니다. 이 주제를 깊이 이해하면 TypeScript 도입 이유와 엄격한 동등 연산자(===) 사용 관례가 왜 생겨났는지도 자연스럽게 납득하게 됩니다.

핵심 개념

암묵적 타입 변환 메커니즘

입문

JavaScript는 연산을 할 때 값의 종류가 맞지 않으면 엔진이 몰래 바꿔주는 자동 번역 기능을 갖고 있어요. 이 자동 번역이 왜 생기는지, 어떻게 동작하는지 알아볼게요!

🤖 JavaScript 엔진은 어떤 역할을 하나요? JavaScript 엔진은 여러분이 쓴 코드를 컴퓨터가 이해할 수 있도록 실행해주는 통역사예요. 그런데 이 통역사는 연산이 잘 안 맞는 상황을 만나면, 에러를 내기 전에 스스로 ‘이렇게 하면 되겠지!’ 하고 값의 타입을 바꿔버려요. 개발자 입장에서는 이 과정이 눈에 보이지 않기 때문에 깜짝 놀라는 결과가 나오곤 해요.

🪄 자동 번역은 언제 일어나나요? 예를 들어 숫자와 문자를 더하려고 하면, 엔진은 “문자열 연결을 원하는 거겠지!”라고 판단하고 숫자를 문자로 바꿔버려요. 또 조건문(if)에 숫자를 넣으면 엔진은 “0은 거짓, 나머지 숫자는 참이겠지!”라고 바꿔서 처리해요. 이런 변환이 모두 개발자가 코드를 따로 작성하지 않아도 자동으로 일어난답니다.

🎭 왜 이게 문제가 되나요? 마치 외국어 통역사가 내 말을 임의로 바꿔서 전달하는 것과 같아요. 내가 원하는 말이 아닌 다른 말로 전달되면 오해가 생기죠. JavaScript도 마찬가지로, 엔진이 바꿔놓은 결과가 개발자의 의도와 다를 때 버그가 생겨요. 규칙을 알면 통역사가 어떻게 바꿀지 예측할 수 있어서, 이런 오해를 미리 막을 수 있어요.

💡 명시적 변환 vs 암묵적 변환의 차이는요? 명시적 변환은 개발자가 직접 “이 값을 숫자로 바꿔줘!”라고 직접 명령하는 거예요. 반면 암묵적 변환은 엔진이 알아서 바꾸는 거라서, 개발자가 바꿨다는 사실 자체를 모를 수 있어요. 친구에게 부탁해서 마트에 보내는 것(명시적)과, 친구가 알아서 장을 봐 오는 것(암묵적)의 차이와 비슷해요.

중급

암묵적 타입 변환(Implicit Type Coercion)은 JavaScript 엔진이 연산자나 표현식의 피연산자 타입이 기대하는 타입과 다를 때, 개발자의 개입 없이 자동으로 타입을 변환하는 동작입니다.

발동 조건 엔진은 다음 상황에서 암묵적 변환을 수행합니다.

이항 연산자(+, -, *, /, == 등)의 피연산자 타입 불일치
조건식(if, while, 삼항 연산자)에 boolean 이외의 값이 사용될 때
템플릿 리터럴이나 문자열 연결 표현식에 비문자열이 섞일 때

명시적 vs 암묵적 변환 비교 명시적 변환은 Number(), String(), Boolean() 등의 내장 함수를 사용하여 개발자가 의도를 명확히 드러냅니다. 암묵적 변환은 엔진이 내부적으로 동일한 변환 알고리즘을 수행하지만, 코드에 흔적이 없어 가독성과 예측 가능성이 낮아집니다.

// 명시적 변환 - 의도가 명확함
let explicit = Number("42"); // 42

// 암묵적 변환 - 엔진이 자동 수행
let implicit = "42" - 0;    // 42 (문자열 → 숫자 자동 변환)
let implicit2 = +"42";      // 42 (단항 + 연산자로 유발)

// 결과는 같지만 의도는 다름
console.log(typeof explicit);  // "number"
console.log(typeof implicit);  // "number"

Abstract Operations - 변환의 공통 알고리즘 ECMAScript는 암묵적 변환의 내부 로직을 추상 연산(Abstract Operation)으로 정의합니다. ToNumber, ToString, ToBoolean 등이 이에 해당하며, 연산자들은 이 추상 연산을 호출하는 방식으로 동작합니다.

심화

암묵적 타입 변환은 ECMAScript 명세에서 추상 연산(Abstract Operation)과 타입 변환 알고리즘으로 정밀하게 정의되어 있으며, 각 연산자의 평가 알고리즘이 이를 호출하는 구조로 설계되어 있습니다.

ECMAScript 명세의 추상 연산 체계 ECMAScript 2024 Section 7 (Abstract Operations)은 타입 변환의 핵심 추상 연산을 정의합니다. ToNumber(argument), ToString(argument), ToBoolean(argument), ToPrimitive(input [, preferredType]) 등이 여기에 속합니다. 각 이항 연산자의 런타임 시맨틱(Runtime Semantics)은 이 추상 연산을 직접 호출하도록 명세화되어 있어, 암묵적 변환의 결과는 명세에 의해 결정론적(deterministic)으로 보장됩니다.

ToPrimitive와 힌트 시스템 객체를 원시값으로 변환할 때 호출되는 ToPrimitive(input, preferredType)는 힌트(hint)로 "number", "string", "default" 중 하나를 받습니다. 힌트에 따라 @@toPrimitive 심볼 메서드를 먼저 탐색하고, 없으면 valueOf() → toString() 순서(숫자 힌트) 또는 toString() → valueOf() 순서(문자열 힌트)로 폴백(fallback)합니다. + 연산자는 "default" 힌트를 전달하며, 대부분의 내장 객체는 "default"를 "number"와 동일하게 처리합니다.

V8 엔진의 최적화 경로 V8의 TurboFan 컴파일러는 타입 피드백(type feedback)을 통해 암묵적 변환이 일어나는 코드의 최적화 경로를 결정합니다. 피연산자의 타입이 항상 동일하면 Monomorphic(단형성) 최적화가 적용되어 IC(Inline Cache)가 빠른 경로를 사용합니다. 그러나 암묵적 변환으로 인해 타입이 혼재하면 Megamorphic(다형성) 상태로 전환되어 최적화가 해제(deoptimization)될 수 있으며, 이는 성능에 직접적인 영향을 줍니다.

+ 연산자와 문자열 변환

입문

더하기 기호(+)는 수학에서 숫자를 더할 때 쓰지만, JavaScript에서는 문자를 붙이는 용도로도 쓰여요. 그래서 숫자와 문자를 +로 연결하면 생각지도 못한 결과가 나올 수 있어요!

➕ + 는 두 가지 얼굴을 가져요 더하기(+)는 JavaScript에서 두 가지 역할을 해요. 숫자끼리 더하는 ‘덧셈’과, 문자를 이어 붙이는 ‘연결’ 역할이에요. 마치 가위가 종이도 자르고 실도 자르는 것처럼, + 기호 하나가 두 가지 일을 해요.

🔢 숫자 + 문자를 하면 어떻게 되나요? 예를 들어 5 + "3"을 하면 어떻게 될까요? 수학에서는 8이 나와야 할 것 같지만, JavaScript는 “5라는 숫자를 문자 ‘5’로 바꾸고, 그다음 문자 ‘3’을 붙여서 ‘53’을 만들어요.” 이게 바로 암묵적 타입 변환이에요! 엔진이 숫자를 문자로 몰래 바꿔버린 거예요.

🧲 왜 숫자가 문자 쪽으로 바뀌나요? JavaScript 엔진에게는 규칙이 있어요. + 연산에서 한쪽이라도 문자열이면, 다른 쪽도 문자열로 바꿔서 연결해버려요. 마치 파티에서 한 명만 정장을 입어도 다른 사람도 정장으로 갈아입어야 하는 규칙 같아요. 문자열이 더 강한 쪽이에요!

🚨 실수가 생기는 상황은 언제인가요? 웹페이지에서 사용자가 숫자를 입력하면, 그 값은 항상 ‘문자열’로 들어와요. 그래서 “사용자가 입력한 숫자 + 10”을 하면 더하기가 아니라 문자 붙이기가 돼버려요. 예를 들어 사용자가 ‘5’를 입력했는데 5 + 10 = 15가 아니라, ‘5’ + 10 = ‘510’이 되는 거예요!

💡 어떻게 예방할 수 있나요? 입력받은 값을 숫자로 쓰고 싶다면 먼저 숫자로 바꿔주는 과정이 필요해요. 요리할 때 재료를 손질하는 것처럼, 값을 사용하기 전에 타입을 먼저 정리해두면 이런 실수를 막을 수 있어요.

중급

+ 연산자는 JavaScript에서 유일하게 덧셈과 문자열 연결(concatenation)을 모두 수행하는 이중 역할 연산자입니다. 피연산자 중 하나라도 문자열이면 나머지 피연산자도 ToString 추상 연산으로 변환된 후 연결이 수행됩니다.

문자열 우선 규칙

피연산자 중 하나가 string이면 → 나머지를 ToString()으로 변환 후 연결
피연산자 중 하나가 object이면 → ToPrimitive(hint: "default") 먼저 적용
둘 다 number, boolean, null, undefined이면 → ToNumber()로 변환 후 덧셈

// 문자열이 있으면 연결(concatenation)
console.log(1 + "2");      // "12"  (1 → "1", 연결)
console.log("1" + 2);      // "12"  (2 → "2", 연결)
console.log(true + "1");   // "true1"

// 둘 다 숫자/불리언/null이면 덧셈
console.log(1 + 2);        // 3
console.log(true + 1);     // 2     (true → 1)
console.log(null + 1);     // 1     (null → 0)

// 객체는 ToPrimitive 먼저
console.log([] + []);      // ""    ([] → "")
console.log([] + {});      // "[object Object]"
console.log({} + []);      // "[object Object]"

연산 순서가 결과를 바꾸는 경우 + 연산자는 왼쪽에서 오른쪽으로(left-to-right) 결합하기 때문에, 표현식 내 피연산자의 배치 순서가 최종 타입에 영향을 줍니다.

console.log(1 + 2 + "3"); // "33" (1+2=3, 3+"3"="33")
console.log("1" + 2 + 3); // "123" ("1"+2="12", "12"+3="123")

심화

+ 연산자의 암묵적 변환은 ECMAScript 명세 13.15.3절 ApplyStringOrNumericBinaryOperator 추상 연산에 의해 결정됩니다. 이 과정에서 ToPrimitive의 힌트 시스템과 ToString / ToNumber 추상 연산이 정교하게 연계됩니다.

ApplyStringOrNumericBinaryOperator 알고리즘 분석 + 연산자의 런타임 시맨틱은 다음 순서로 동작합니다.

ToPrimitive(lval, hint: "default") 및 ToPrimitive(rval, hint: "default") 호출
lprim 또는 rprim 중 하나가 String 타입이면 → ToString(lprim) + ToString(rprim) (문자열 연결)
그렇지 않으면 → ToNumber(lprim) + ToNumber(rprim) (수치 덧셈)

Symbol.toPrimitive와 힌트 오버라이딩 객체에 [Symbol.toPrimitive] 메서드를 정의하면 + 연산자가 전달하는 "default" 힌트를 가로채어 변환 동작을 완전히 제어할 수 있습니다. 내장 Date 객체는 "default" 힌트를 "string"으로 처리하도록 [Symbol.toPrimitive]를 구현하여, date + 1이 수치 덧셈이 아닌 문자열 연결로 동작하게 합니다. 이는 명세상 의도된 설계로, 날짜 객체의 직관적인 문자열 표현을 우선시한 결정입니다.

V8의 StringAdd 최적화와 ConsString V8 엔진은 문자열 연결 성능 최적화를 위해 ConsString(Concatenated String) 내부 표현을 사용합니다. 작은 문자열을 반복적으로 +로 연결할 때 즉시 새로운 연속 메모리를 할당하지 않고 트리 구조의 ConsString을 생성합니다. 이는 불필요한 메모리 복사를 지연시켜 중간 연결 성능을 향상시키지만, 최종 문자열에 접근할 때 트리를 평탄화(flattening)하는 비용이 발생합니다. 대량의 문자열 연결에는 배열과 Array.prototype.join()을 사용하는 것이 ConsString 트리의 깊이를 방지하여 메모리 효율을 높입니다.

비교 연산자와 숫자 변환

입문

두 값이 같은지 비교할 때 ==를 쓰면 JavaScript는 타입이 달라도 몰래 맞춰서 비교해요. 이 과정에서 예상치 못한 결과가 자주 생겨요. 어떤 규칙으로 바꾸는지 알아볼게요!

⚖️ == 와 === 는 어떻게 다른가요? ==는 ‘느슨한 비교’라고 해요. 값이 같아 보이면 타입이 달라도 같다고 해줘요. 마치 100원짜리 동전과 100원 지폐가 있다면, ‘금액’만 보고 같다고 판단하는 것과 같아요. 반면 ===는 ‘엄격한 비교’로, 타입까지 완전히 같아야 같다고 해요.

🔄 == 비교에서 타입을 어떻게 맞추나요? ==로 비교할 때 타입이 다르면 엔진은 정해진 규칙에 따라 한쪽을 바꿔요. 대부분의 경우 문자열이나 불리언을 숫자로 바꿔서 비교해요. 예를 들어 "5" == 5를 비교할 때는 문자 "5"를 숫자 5로 바꾼 뒤 비교해서 같다고 답해요.

🧮 뺄셈, 곱셈, 나눗셈은 어떻게 작동하나요? +와 달리 -, *, / 연산자는 항상 숫자 계산을 원해요. 그래서 문자열이 있어도 무조건 숫자로 바꾸려고 해요. "10" - "4"를 하면 문자 "10"과 "4"가 모두 숫자 10과 4로 바뀌어서 결과가 6이 나와요. 정말 신기하죠!

😲 가장 헷갈리는 경우는 어떤 건가요? null == 0은 왜 false일까요? 수학적으로는 null을 0으로 볼 수도 있을 것 같은데 말이에요. JavaScript에서 null은 오직 undefined와만 ==으로 같아요. 다른 값과는 모두 다르다고 해요. 이런 특별한 규칙들이 있어서 꼭 외워둬야 해요.

🎯 언제 == 를 써도 되고, 언제 === 를 써야 하나요? 대부분의 개발자들은 항상 ===를 쓰라고 조언해요. ===를 쓰면 암묵적 변환이 일어나지 않아서, 내가 예상한 대로만 비교가 돼요. ==는 규칙을 정확히 알고 있을 때만, 아주 특별한 경우에만 쓰는 게 좋아요.

중급

-, *, / 등 산술 연산자는 항상 숫자 컨텍스트(numeric context)에서 동작하므로, 피연산자를 ToNumber() 추상 연산으로 강제 변환합니다. == 연산자(추상 동등 비교, Abstract Equality Comparison)는 피연산자 타입이 다를 때 정해진 변환 우선순위에 따라 암묵적 변환을 수행합니다.

ToNumber 변환 규칙 요약

원래 값	변환 결과
`"123"`	`123`
`""`	`0`
`"abc"`	`NaN`
`true`	`1`
`false`	`0`
`null`	`0`
`undefined`	`NaN`
`[]`	`0`
`[1]`	`1`
`[1,2]`	`NaN`

// 뺄셈, 곱셈, 나눗셈 - 항상 ToNumber 적용
console.log("10" - 4);    // 6   ("10" → 10)
console.log("6" * "2");   // 12  (둘 다 ToNumber)
console.log(true - false); // 1  (1 - 0)
console.log(null + 1);    // 1   (null → 0)
console.log(undefined - 1); // NaN (undefined → NaN)

// number vs string: 문자열을 ToNumber로 변환
console.log(5 == "5");    // true  ("5" → 5)
console.log(0 == "");     // true  ("" → 0)

// boolean 비교: boolean을 ToNumber로 변환
console.log(true == 1);   // true  (true → 1)
console.log(false == 0);  // true  (false → 0)
console.log(false == ""); // true  (false→0, ""→0)

// null / undefined: 서로만 같음
console.log(null == undefined); // true  (특별 규칙)
console.log(null == 0);         // false (null 특별 처리)
console.log(null == false);     // false

=== 연산자(엄격 동등 비교, Strict Equality Comparison)는 타입 변환 없이 타입과 값을 모두 비교합니다. 실무에서는 예기치 않은 암묵적 변환을 방지하기 위해 ===를 기본으로 사용하는 것이 권장됩니다.

심화

== 연산자는 ECMAScript 명세 7.2.14절 IsLooselyEqual 추상 연산으로 정의되며, 피연산자 타입의 조합에 따라 정밀한 분기 알고리즘을 따릅니다. -, *, / 연산자는 7.1.4절 ToNumber 추상 연산을 직접 호출합니다.

IsLooselyEqual 알고리즘의 분기 구조 명세의 IsLooselyEqual(x, y) 알고리즘은 다음 우선순위로 동작합니다.

Type(x) === Type(y) → IsStrictlyEqual(x, y) 호출 (추가 변환 없음)
null과 undefined 조합 → true 반환 (특별 규칙, 어떤 변환도 없음)
null 또는 undefined가 다른 타입과 비교 → false 반환
number와 string 조합 → string을 ToNumber()로 변환 후 재귀 호출
boolean이 피연산자 → ToNumber(boolean) 후 재귀 호출
object가 string, number, symbol, bigint와 비교 → ToPrimitive(object) 후 재귀 호출

ToNumber의 내부 동작과 엣지 케이스 ToNumber(argument) (명세 7.1.4절)는 인수 타입별로 다음 경로를 따릅니다. 문자열의 경우 StringToNumber 추상 연산이 호출되며, 선행/후행 공백을 제거한 후 숫자 리터럴 파싱을 시도합니다. 빈 문자열은 명세상 +0으로 정의되며, 파싱 실패 시 NaN을 반환합니다. 객체의 경우 ToPrimitive(hint: "number")를 먼저 호출하여 원시값을 얻은 뒤 해당 원시값에 대해 ToNumber를 재귀적으로 적용합니다.

null의 특수 처리와 설계 의도 null == 0이 false인 이유는 IsLooselyEqual 알고리즘에서 null과 undefined에 대한 특별 규칙이 ToNumber 변환 규칙보다 먼저 평가되기 때문입니다. null의 ToNumber 결과는 0이지만, 알고리즘 분기 2와 3에서 null은 undefined와만 같고 다른 모든 값과는 다르다고 선언합니다. 이는 Brendan Eich가 null을 “의도적 부재”(intentional absence), undefined를 “미초기화”(uninitialized)로 의미적으로 구분하면서도 두 값을 느슨하게 같다고 처리하기 위해 설계한 결과입니다.

Truthy와 Falsy

입문

JavaScript에서 if 같은 조건문을 쓸 때, 엔진은 어떤 값이든 ‘참(true)’ 또는 ‘거짓(false)‘으로 판단해요. 이 판단 기준을 ‘truthy’와 ‘falsy’라고 불러요!

🚦 조건문에서 무슨 일이 일어나나요? 신호등이 초록불이면 ‘가도 된다(참)’, 빨간불이면 ‘멈춰라(거짓)‘를 뜻하잖아요. JavaScript의 if도 비슷해요. 조건 자리에 어떤 값이 오든, 엔진이 그 값을 초록불(truthy)인지 빨간불(falsy)인지 판단해서 코드를 실행할지 말지 결정해요.

🕳️ falsy 값은 어떤 것들이 있나요? JavaScript에서 ‘거짓’으로 판단되는 값은 딱 여섯 가지예요. 숫자 0, 빈 문자열 "", null, undefined, NaN, 그리고 false 자체예요. 이 여섯 가지 외에 나머지 모든 값은 ‘참’으로 판단돼요. 이 여섯 가지만 외워두면 나머지는 전부 참이에요!

🎁 빈 배열과 빈 객체는 참일까요, 거짓일까요? 많은 초보자들이 헷갈리는 부분이에요. 빈 배열 []과 빈 객체 {}는 비어 있어도 ‘참(truthy)‘이에요! 물건이 없는 빈 상자도 상자 자체는 ‘있는’ 것이잖아요. JavaScript도 마찬가지로, 값이 없는 배열이나 객체도 ‘존재하는’ 것이기 때문에 참으로 판단해요.

😮 0은 왜 거짓인가요? 수학에서 0은 ‘아무것도 없음’을 뜻하죠. JavaScript도 그 개념을 그대로 가져왔어요. 0은 ‘아무 의미 없는 숫자’로 봐서 거짓으로 처리해요. 그래서 if (0) 안의 코드는 절대 실행되지 않아요. 비슷하게, 빈 문자열 ""도 ‘아무 글자도 없는 텍스트’라서 거짓이에요.

💡 실수를 어떻게 줄일 수 있나요? 배열이 비어 있는지 확인하고 싶을 때 if (arr)를 쓰면 항상 참이 나와요. 그래서 if (arr.length > 0) 또는 if (arr.length)처럼 직접 길이를 확인해야 해요. 이렇게 의도를 명확하게 표현하면 암묵적 변환 때문에 생기는 실수를 줄일 수 있어요.

중급

조건식(conditional expression)은 Boolean() 내장 함수와 동일한 ToBoolean 추상 연산으로 피연산자를 변환합니다. ECMAScript는 특정 값들을 falsy로 명시하며, 나머지 모든 값은 truthy입니다.

Falsy 값 목록 (6개, 완전한 목록)

값	타입
`false`	boolean
`0`, `-0`, `0n`	number / bigint
`""`, `''`, ``	string (빈 문자열)
`null`	null
`undefined`	undefined
`NaN`	number

이 외의 모든 값은 truthy입니다. 빈 배열 [], 빈 객체 {}, 문자열 "0", 문자열 "false" 모두 truthy입니다.

// falsy 값들
if (!false)     console.log("false는 falsy");
if (!0)         console.log("0은 falsy");
if (!"")        console.log("빈 문자열은 falsy");
if (!null)      console.log("null은 falsy");
if (!undefined) console.log("undefined는 falsy");
if (!NaN)       console.log("NaN은 falsy");

// 주의: 빈 배열/객체는 truthy
if ([])   console.log("빈 배열은 truthy!");  // 출력됨
if ({})   console.log("빈 객체는 truthy!");  // 출력됨
if ("0")  console.log('"0"은 truthy!');      // 출력됨

const arr = [];

// 잘못된 패턴 - 빈 배열도 truthy라 항상 실행됨
if (arr) {
  console.log("배열 있음"); // 항상 출력! (의도와 다를 수 있음)
}

// 올바른 패턴 - 배열의 길이로 명시적 확인
if (arr.length > 0) {
  console.log("배열에 요소가 있음");
}

// 논리 연산자에서도 동일 규칙 적용
const value = null;
const result = value || "기본값"; // "기본값" (null은 falsy)

심화

ToBoolean 추상 연산(ECMAScript 명세 7.1.2절)은 타입 변환 추상 연산 중 가장 단순한 형태로, 입력 타입별 falsy 여부를 명세 테이블로 정의합니다. 이 연산은 if, while, for, 삼항 연산자, 논리 연산자(&&, ||, !) 등의 런타임 시맨틱에서 직접 호출됩니다.

ToBoolean 명세의 결정론적 정의 ECMAScript 7.1.2절 ToBoolean은 인수의 타입에 따라 다음과 같이 정의됩니다. Undefined → false, Null → false, Boolean → 인수 자체, Number → +0, -0, NaN이면 false, 그 외 true, String → 빈 문자열이면 false, 그 외 true, Symbol → true, BigInt → 0n이면 false, 그 외 true, Object → 항상 true. 특히 Object 타입은 예외 없이 항상 true를 반환하도록 명세에 명시되어 있으며, 이는 new Boolean(false)조차 truthy인 이유입니다.

논리 연산자의 Short-Circuit과 ToBoolean &&와 || 연산자는 실제로 불리언을 반환하지 않습니다. ECMAScript 13.13절에 따르면, x && y는 ToBoolean(x)가 false이면 x를 반환하고, true이면 y를 반환합니다. x || y는 반대입니다. 이 설계는 논리 연산자를 조건부 할당(Optional Chaining 이전 패턴인 a = a || default)과 가드 패턴(obj && obj.prop)에 활용할 수 있게 하지만, 동시에 반환값의 타입이 불리언이 아닐 수 있다는 점에서 암묵적 변환과 유사한 혼란을 야기합니다.

document.all과 Exotic Falsy Object 역사적으로 흥미로운 사례로, document.all은 ToBoolean이 false를 반환하는 유일한 객체입니다. 이는 명세의 일반 Object 규칙(항상 true)에 대한 유일한 예외로, 레거시 IE 코드 호환성(if (document.all))을 위해 HTML Living Standard와 ECMAScript 명세가 협력하여 [[IsHTMLDDA]] 내부 슬롯을 통해 예외를 정의한 결과입니다. 이 케이스는 표준화 과정에서 하위 호환성(backward compatibility)이 명세 일관성보다 우선될 수 있음을 보여주는 사례입니다.