JavaScript가 동적 타입 언어인 의미는?

정적 타입 언어와 동적 타입 언어의 차이를 이해하고, 타입 결정 시점이 런타임인 JavaScript의 동작 방식을 학습합니다

입문 15분 동적 타입 정적 타입 타입 결정 런타임

JavaScript는 변수에 타입을 미리 선언하지 않아도 되는 동적 타입 언어입니다. 변수에 담기는 값의 종류는 코드가 실행되는 시점, 즉 런타임에 결정되며 언제든지 다른 타입의 값으로 바뀔 수 있습니다. 이 특성은 JavaScript를 배우기 시작할 때 매우 편리하게 느껴지지만, 동시에 예상하지 못한 버그의 원인이 되기도 합니다. 동적 타입 언어의 작동 원리를 제대로 이해하면 이러한 함정을 피하고 더 안정적인 코드를 작성할 수 있습니다.

핵심 특징

  • 🔄 타입이 런타임에 결정된다: 변수를 선언할 때 타입을 명시하지 않으며, 실제 값이 할당되는 순간 타입이 정해집니다.
  • 타입은 언제든지 변경 가능하다: 같은 변수에 숫자를 넣었다가 문자열로 바꾸는 것이 문법적으로 허용됩니다.
  • 컴파일 단계에서 타입 오류를 잡을 수 없다: 정적 타입 언어와 달리 타입 불일치 오류는 코드가 실행되어야 드러납니다.
  • 암묵적 타입 변환이 자주 발생한다: 연산자나 함수가 기대하는 타입과 실제 값의 타입이 다를 때, JavaScript 엔진이 자동으로 타입을 변환하려 시도합니다.
  • ⚠️ 타입 관련 버그는 디버깅이 어렵다: 타입 오류가 실행 중에만 나타나고 겉으로 드러나지 않을 수 있어, 원인을 추적하는 데 시간이 걸립니다.

실무에서의 영향

실무 JavaScript 코드에서는 함수에 전달되는 인자의 타입이 예상과 다른 경우가 빈번하게 발생합니다. 예를 들어 API 응답으로 받은 숫자 데이터가 실제로는 문자열로 넘어오는 상황, 또는 사용자 입력값이 항상 예상한 형태가 아닌 상황을 자주 마주치게 됩니다. 동적 타입 언어의 특성을 이해하지 못하면 이런 상황에서 원인을 특정하기 어렵고 디버깅에 불필요한 시간을 낭비하게 됩니다. 반대로 타입 결정 방식을 명확히 알고 있으면, 방어적인 코드를 작성하거나 TypeScript 같은 정적 타입 도구를 도입하는 판단 기준도 세울 수 있습니다. 결국 동적 타입 언어로서의 JavaScript 작동 원리는 타입 관련 기능 전반(타입 강제 변환, 비교 연산자, 타입 체크)의 토대가 되므로, 이 개념을 확실히 잡는 것이 JavaScript 숙련도를 높이는 첫걸음입니다.

핵심 개념

정적 타입 vs 동적 타입

입문

프로그래밍 언어마다 변수의 종류(타입)를 정하는 방식이 달라요. 어떤 언어는 미리 정해두고, 어떤 언어는 나중에 정해요. JavaScript는 ‘나중에 정하는’ 쪽이에요!

📦 타입이 뭔가요? 타입은 변수에 들어갈 수 있는 값의 ‘종류’예요. 숫자인지, 글자인지, 참/거짓인지를 나타내요. 마치 학교 사물함에 “이 칸에는 체육복만”, “저 칸에는 교과서만” 이렇게 용도를 정해두는 것과 비슷해요.

🔒 정적 타입 언어는 어떻게 작동하나요? Java나 C++ 같은 정적 타입 언어는 변수를 만들 때 “이 변수는 앞으로 숫자만 담을 거야!”라고 미리 선언해야 해요. 한 번 정하면 바꿀 수 없어서, 마치 ‘숫자 전용 사물함’처럼 숫자 이외의 것을 넣으려 하면 바로 오류가 나요.

🔓 동적 타입 언어는 어떻게 다른가요? JavaScript는 변수를 만들 때 타입을 정하지 않아요. “이 변수는 일단 뭐든 담을 수 있는 만능 상자야!”처럼 시작하고, 실제로 값을 넣는 순간에 타입이 결정돼요. 숫자를 넣으면 숫자 타입, 글자를 넣으면 문자열 타입이 되는 거예요.

💡 어느 방식이 더 좋은가요? 둘 다 장단점이 있어요. 정적 타입은 실수를 미리 잡아줘서 큰 프로그램에 유리하고, 동적 타입은 빠르게 코드를 작성할 수 있어서 유연해요. JavaScript를 처음 배울 때 쉽게 느껴지는 이유 중 하나가 바로 타입을 신경 쓰지 않아도 되는 동적 타입 방식 때문이에요!

중급

정적 타입 언어(statically typed language)는 변수 선언 시점에 타입을 명시하며, 컴파일 단계(compile-time)에서 타입 검사를 수행합니다. 동적 타입 언어(dynamically typed language)는 변수에 타입 정보를 부여하지 않으며, 값(value)이 타입을 가지고 변수는 단순히 값을 참조하는 역할만 합니다.

JavaScript에서 변수는 타입이 없고 값에 타입이 있습니다. let x = 42에서 42라는 숫자 값이 Number 타입을 가지며, x는 그 값을 가리키는 이름일 뿐입니다.

// Java (정적 타입) - 아래는 참고용 의사 코드
// int x = 42;      // 숫자만 담을 수 있는 변수 선언
// x = "hello";     // 컴파일 오류! 타입 불일치

// JavaScript (동적 타입)
let x = 42;         // x는 현재 Number 타입 값을 참조
x = "hello";        // 합법적: 이제 String 타입 값을 참조
x = true;           // 합법적: 이제 Boolean 타입 값을 참조

console.log(typeof x); // "boolean"

타입 검사 시점의 차이 정적 타입 언어는 코드를 실행하기 전 컴파일 단계에서 타입 오류를 검출합니다. 동적 타입 언어인 JavaScript는 타입 오류가 런타임(runtime)에서만 드러납니다. 이 차이는 대규모 프로젝트에서 TypeScript 도입을 고려하게 되는 핵심 이유입니다.

심화

정적 타입 언어와 동적 타입 언어의 근본적인 차이는 타입 정보가 변수(variable)에 귀속되는지 아니면 값(value)에 귀속되는지에 있습니다. ECMAScript 명세는 이 구분을 명시적으로 설계에 반영하고 있습니다.

ECMAScript 명세의 타입 모델 ECMAScript 2023 명세 Section 6 (ECMAScript Data Types and Values)에 따르면, JavaScript는 언어 타입(Language Types) 8가지(Undefined, Null, Boolean, String, Symbol, BigInt, Number, Object)를 정의하며 이 타입들은 모두 값(value)에 속성으로 부여됩니다. 변수 자체는 Environment Record의 바인딩(Binding)으로 표현되며, 바인딩에는 타입 정보가 포함되지 않습니다.

즉, let x = 42는 x라는 식별자(Identifier)를 현재 Lexical Environment의 바인딩에 등록하고, Number 타입인 42라는 원시 값(primitive value)을 해당 바인딩에 할당합니다. 이후 x = "hello"는 동일한 바인딩이 String 타입의 다른 값을 참조하도록 갱신합니다.

컴파일 타임 vs 런타임 타입 검사의 이론적 배경 타입 이론(Type Theory) 관점에서 정적 타입 시스템은 Hindley-Milner 타입 추론이나 명시적 타입 어노테이션을 기반으로 컴파일 타임에 타입 건전성(type soundness)을 보장합니다. 반면 동적 타입 시스템은 duck typing 원칙을 따르며, 런타임에 값의 실제 구조를 검사해 연산 가능 여부를 결정합니다.

TypeScript는 JavaScript 위에 정적 타입 레이어를 추가하되, 컴파일 결과물(트랜스파일된 JavaScript)에는 타입 정보가 제거됩니다. 이는 TypeScript의 타입 시스템이 구조적 서브타이핑(structural subtyping)을 채택해 명목적 타이핑(nominal typing)보다 유연한 타입 호환성을 제공하면서도 완전한 런타임 타입 안전성을 보장하지는 않는 이유입니다.

런타임 타입 결정

입문

JavaScript에서 변수의 타입은 코드가 실행되는 바로 그 순간에 정해져요. 마치 빈 그릇에 무엇을 담느냐에 따라 그릇의 용도가 달라지는 것처럼요!

🎯 런타임이 뭔가요? 런타임은 “코드가 실제로 실행되는 시간”이에요. 코드를 작성하는 시간과는 달라요. 마치 요리 레시피를 쓰는 시간(코드 작성)과 실제로 요리하는 시간(런타임)이 다른 것처럼요. JavaScript는 요리를 시작해야 비로소 재료의 양을 결정해요!

🎁 값이 할당될 때 타입이 정해져요 let greeting = "안녕하세요"라고 쓰면, 코드가 실행되는 순간 JavaScript가 “아, 이건 글자(문자열)구나!”라고 판단해요. 이 판단은 코드를 쓰는 시점이 아니라 컴퓨터가 이 줄을 처리하는 순간에 일어나요.

🔍 typeof로 타입을 확인할 수 있어요 typeof 명령어를 사용하면 지금 이 변수에 어떤 종류의 값이 들어있는지 물어볼 수 있어요. 마치 그릇을 열어보고 “안에 뭐가 들었지?” 확인하는 것과 같아요. 하지만 이 확인은 코드가 실행될 때만 가능해요.

🚨 이게 왜 중요한가요? 타입이 런타임에 결정된다는 건, 우리가 예상치 못한 타입의 값을 받을 수도 있다는 뜻이에요. 예를 들어 사용자가 나이를 입력했을 때 우리는 숫자를 기대하지만, 실제로는 글자 “25”가 들어올 수도 있어요. 이 차이를 모르면 나중에 계산이 이상하게 될 수 있어요!

중급

JavaScript 엔진은 표현식(expression)을 평가하는 시점에 해당 값의 타입을 결정합니다. 변수 선언 자체는 타입 정보를 포함하지 않으며, 변수에 값이 바인딩되는 순간 그 값이 가지는 타입이 활성화됩니다.

typeof 연산자는 런타임에 값의 타입을 문자열로 반환하는 단항 연산자입니다. 이는 정적 타입 언어의 컴파일 타임 타입 검사와 달리, 실행 중에만 타입 정보를 얻을 수 있다는 JavaScript의 특성을 잘 보여줍니다.

let value;
console.log(typeof value); // "undefined" - 아직 값 없음

value = 42;
console.log(typeof value); // "number" - Number 타입

value = "JavaScript";
console.log(typeof value); // "string" - String 타입

value = { name: "JS" };
console.log(typeof value); // "object" - Object 타입
function processInput(input) {
  // 인자 타입은 호출 시점에서 결정됨
  console.log(typeof input);

  if (typeof input === "string") {
    return input.toUpperCase();
  } else if (typeof input === "number") {
    return input * 2;
  }
  return input;
}

processInput("hello");  // "string" → "HELLO"
processInput(21);       // "number" → 42
processInput(true);     // "boolean" → true (변환 없이 반환)

심화

JavaScript 엔진의 타입 결정은 ECMAScript 명세의 값 평가(Value Evaluation) 메커니즘과 직결됩니다. 런타임 타입 결정은 엔진 내부에서 정교한 최적화 과정을 거칩니다.

ECMAScript 명세의 값 평가 메커니즘 ECMAScript 2023 Section 13 (ECMAScript Language: Expressions)에 따르면, 각 표현식은 평가(evaluation) 시 완료 레코드(Completion Record)를 반환하며 실제 값은 Reference Record 또는 원시 값으로 전달됩니다. 변수 참조 시 GetValue 추상 연산이 호출되어 Environment Record에서 현재 바인딩된 값을 가져오고, 이 값이 가진 내부 슬롯(internal slot) [[Type]]이 런타임 타입을 결정합니다.

typeof 연산자는 Section 13.5.3 (The typeof Operator)에 정의되며, 피연산자를 평가할 때 Reference Record를 완전히 역참조하지 않아 선언되지 않은 변수에도 오류 없이 “undefined”를 반환하는 특수한 동작을 합니다.

V8 엔진의 Hidden Class와 런타임 타입 최적화 V8 엔진은 JavaScript의 동적 타입 특성에도 불구하고 높은 성능을 달성하기 위해 Hidden Class(내부적으로 Map이라 칭함)라는 최적화 구조를 사용합니다. 객체의 속성 구조가 변경될 때마다 새로운 Hidden Class 전환(transition)이 발생하며, 이 전환 트리(transition tree)를 통해 동적 디스패치(dynamic dispatch) 비용을 줄입니다.

원시 타입(primitive types)에 대해서는 Smi(Small Integer, 31비트 정수), HeapNumber(부동소수점), String 등으로 내부 표현을 세분화해 메모리 효율과 연산 속도를 최적화합니다. TurboFan JIT 컴파일러는 Inline Cache(인라인 캐시)를 통해 동일 코드 경로에서 반복적으로 관찰된 타입 정보를 기반으로 특화된 기계어 코드를 생성하는 Speculative Optimization(추측적 최적화)을 수행합니다. 타입이 변경되면 Deoptimization(역최적화)이 발생해 인터프리터 모드로 복귀합니다.

타입 변경 가능성과 암묵적 타입 변환

입문

JavaScript에서는 변수의 타입이 언제든 바뀔 수 있고, 심지어 JavaScript 스스로 타입을 몰래 바꾸기도 해요. 이 특성을 모르면 이상한 결과를 보게 될 수 있어요!

🔄 타입이 바뀐다고요? 맞아요! let x = 10이라고 해서 x가 영원히 숫자인 건 아니에요. 나중에 x = "열"이라고 쓰면 x는 이제 문자열이 돼요. 마치 빈 파일을 처음엔 그림 파일로 쓰다가 나중에 음악 파일로 바꾸는 것처럼요.

🤫 JavaScript가 몰래 타입을 바꿔요! "5" + 3을 계산하면 뭐가 나올까요? 53이 나와요! JavaScript가 숫자 3을 문자열 “3”으로 몰래 바꿔서 글자를 이어붙이기 때문이에요. 이걸 ‘암묵적 타입 변환’이라고 해요. 개발자가 직접 바꾸지 않았는데 JavaScript가 스스로 결정한 거예요!

🎲 예상치 못한 결과가 나올 수 있어요 "5" - 3은 뭘까요? 이번엔 2가 나와요! 더하기(+)에서는 문자열 합치기를 했는데, 빼기(-)에서는 숫자 계산을 해요. JavaScript가 상황에 따라 다르게 판단하기 때문이에요. 규칙을 모르면 헷갈릴 수 있어요.

💡 어떻게 대비해야 하나요? 이런 특성 때문에 숫자를 다룰 때는 정말 숫자인지 확인하는 습관이 중요해요. 사용자 입력이나 인터넷에서 받은 데이터는 항상 예상과 다를 수 있거든요. 나중에 배울 typeof, parseInt, Number() 같은 도구들이 이때 큰 도움이 돼요!

중급

JavaScript는 두 가지 방식으로 타입을 변환합니다. 개발자가 명시적으로 변환하는 명시적 타입 변환(explicit type conversion/type casting)과, JavaScript 엔진이 연산 수행 시 자동으로 변환하는 암묵적 타입 변환(implicit type conversion/type coercion)입니다.

암묵적 타입 변환은 연산자(operator)가 기대하는 피연산자 타입과 실제 타입이 다를 때 발생합니다. + 연산자는 피연산자 중 하나가 문자열이면 문자열 연결(concatenation)을 수행하고, 산술 연산자(-, *, /)는 피연산자를 항상 숫자로 변환을 시도합니다.

// + 연산자: 문자열이 있으면 문자열 연결
console.log("5" + 3);    // "53" (숫자 3이 "3"으로 변환)
console.log(5 + "3");    // "53"

// -, *, / 연산자: 숫자 변환 시도
console.log("5" - 3);    // 2 ("5"가 5로 변환)
console.log("5" * "2");  // 10 (둘 다 숫자로 변환)
console.log("abc" - 1);  // NaN (변환 실패)
let data = 42;
console.log(typeof data); // "number"

data = "forty-two";        // 타입 변경 허용
console.log(typeof data); // "string"

// 명시적 타입 변환 (안전한 방법)
const num = Number("42"); // 42
const str = String(42);   // "42"
const bool = Boolean(0);  // false

타입 변경 가능성의 실무적 함의 API 응답이나 사용자 입력을 처리할 때 타입이 예상과 다를 수 있습니다. 방어적 코드 작성을 위해 입력값의 타입을 명시적으로 변환하거나 typeof로 검증하는 패턴이 권장됩니다.

심화

암묵적 타입 변환(type coercion)은 ECMAScript 명세에서 추상 연산(abstract operations)을 통해 엄밀하게 정의되어 있으며, 각 연산자는 내부적으로 특정 추상 연산을 호출해 피연산자 타입을 강제 변환합니다.

ECMAScript 추상 연산과 타입 변환 알고리즘 ECMAScript 2023 Section 7 (Abstract Operations)은 타입 변환의 핵심 추상 연산을 정의합니다. ToPrimitive(입력값, 힌트) 추상 연산은 객체를 원시 값으로 변환할 때 호출되며, 힌트(hint)가 “number”면 valueOf()를 먼저 시도하고 “string”이면 toString()을 먼저 시도합니다. 힌트 없이 호출될 경우 기본 힌트(default hint)가 적용됩니다.

+ 연산자(Section 13.15.3, ApplyStringOrNumericBinaryOperator)의 평가 순서는 다음과 같습니다.

  1. ToPrimitive(lval) 호출
  2. ToPrimitive(rval) 호출
  3. 두 결과 중 하나라도 String이면 ToString을 각각 호출하고 문자열 연결 수행
  4. 그렇지 않으면 ToNumeric을 호출하고 숫자 덧셈 수행

반면 산술 연산자 -, *, /(Section 13.15.4)는 ToPrimitive 힌트를 “number”로 고정해 항상 숫자 변환을 시도합니다.

타입 변경 가능성과 엔진 최적화의 상충 V8 엔진의 TurboFan은 Speculative Optimization(추측적 최적화)을 통해 특정 변수가 항상 Number 타입이라고 가정하고 최적화된 기계어를 생성합니다. 그러나 런타임에 타입이 변경되면 Deoptimization 체크포인트(deopt checkpoint)가 발동되어 해당 코드 경로를 인터프리터 바이트코드로 재실행합니다. 이 Deoptimization은 성능 저하의 주요 원인이 될 수 있어, 성능 임계 코드(hot path)에서는 변수 타입을 일관되게 유지하는 것이 최적화 관점에서 권장됩니다.

또한 암묵적 타입 변환은 Inline Cache(IC)의 오염(polymorphic/megamorphic IC)을 유발할 수 있습니다. 단일형 IC(monomorphic IC)는 항상 동일 타입이 들어올 때 최고 성능을 내지만, 여러 타입이 동일 코드 경로에 들어오면 IC가 다형성(polymorphic) 상태로 전환되어 캐시 효율이 저하됩니다.