자바스크립트 호이스팅, 왜 가능할까: 생성 단계와 TDZ까지 한 번에 이해하기
빠른 답
- 호이스팅은 코드가 이동하는 현상이 아니라 실행 전에 식별자 바인딩이 준비되는 동작입니다.
- var는 선언 시 undefined로 초기화되지만 let과 const는 초기화 전 구간인 TDZ에 들어갑니다.
- 함수 선언문은 호출 가능한 상태로 먼저 준비되지만 함수 표현식은 변수 규칙을 따릅니다.
- 실무에서는 호이스팅에 기대기보다 선언을 먼저 쓰고 const와 블록 스코프를 기본으로 두는 편이 안전합니다.
원문 초안을 현재 기준의 자바스크립트 의미론에 맞게 다듬고 있습니다. 우선 스펙과 런타임 문서를 기준으로 오래된 설명과 현재 설명의 차이를 확인한 뒤, 그 흐름에 맞춰 발행형 Markdown으로 재구성하겠습니다.# 자바스크립트 호이스팅, 왜 가능할까: 실행 컨텍스트 생성과 TDZ로 이해하기
목차
시간 흐름으로 이해하기
흐름으로 보기
이 순서를 먼저 잡아두면, 왜 어떤 줄은 undefined를 내보내고 어떤 줄은 ReferenceError를 던지는지 같은 문맥에서 읽을 수 있습니다. 호이스팅은 “선언이 위로 끌어올려진다”는 비유로 시작해도 되지만, 실제로는 “실행 전에 무엇이 어떤 상태로 준비되는가”를 설명하는 말에 더 가깝습니다.
호이스팅은 코드가 위로 이동하는 현상일까
호이스팅을 처음 접할 때는 “선언문이 코드 위로 올라간다”는 식으로 배우는 경우가 많습니다. 관찰 결과만 놓고 보면 꽤 자연스러운 설명입니다. 다만 실제 소스 코드가 재배치되는 것은 아닙니다. 엔진은 스코프에 진입하기 전에 선언들을 훑고, 각 이름에 대한 바인딩을 먼저 준비합니다. 그래서 선언보다 앞에서 접근해도 특정한 결과가 보이는 것입니다.
이때 중요한 점은 “먼저 준비된다”의 의미가 선언 종류마다 다르다는 사실입니다. var는 읽을 수 있는 값인 undefined까지 들어온 상태이고, let과 const는 이름은 존재하지만 아직 초기화되지 않았습니다. 함수 선언문은 함수 객체까지 연결되지만, 함수 표현식은 그 함수를 담는 변수의 규칙을 따릅니다.
그래서 호이스팅을 단순히 “위로 올라간다”로만 기억하면 let, const, TDZ, 함수 표현식에서 바로 설명이 끊깁니다. 자바스크립트에서 더 안정적으로 맞아떨어지는 설명은 “실행 전에 바인딩이 준비되지만, 읽을 수 있는 시점은 선언 종류마다 다르다”입니다.
현재 기준으로 다시 보는 호이스팅 설명
2026년 4월 기준의 ECMAScript 명세는 이 동작을 막연한 “컴파일 단계”라는 말 하나로 설명하지 않습니다. 대신 Execution Contexts, GlobalDeclarationInstantiation, BlockDeclarationInstantiation처럼 실행 컨텍스트와 선언 인스턴스화 규칙으로 더 구체적으로 다룹니다. 초기화되지 않은 바인딩을 읽을 때 ReferenceError가 난다는 점도 환경 레코드의 GetBindingValue 규칙에서 확인할 수 있습니다.
오래된 글에서 자주 보이는 “컴파일 단계에서 메모리에 올려 둔다”는 설명이 완전히 틀렸다고 보기는 어렵지만, 현재 기준으로는 너무 뭉뚱그려져 있습니다. ES5 시절에는 var와 함수 선언문 중심으로도 대체로 설명이 통했지만, ES2015 이후 let, const, class, 블록 스코프, 모듈이 들어오면서 “왜 어떤 이름은 읽히고 어떤 이름은 TDZ에 걸리는가”를 분리해서 봐야 했기 때문입니다.
여기서 흔한 오해도 하나 정리할 수 있습니다. let과 const는 “호이스팅되지 않는다”기보다, 실행 전에 바인딩은 만들어지지만 초기화 전까지 읽을 수 없다고 보는 편이 더 정확합니다. 이름이 아예 없는 상태와, 이름은 있지만 미초기화 상태는 다른 규칙으로 동작합니다.
실행 환경에서 먼저 확인하기
호이스팅의 기본 규칙은 브라우저와 Node에서 공통으로 이해할 수 있지만, 전역 처리 방식은 실행 환경에 따라 다르게 보일 수 있습니다. 특히 오래된 브라우저 script 전역 예제는 var가 전역 객체와 연결되는 모습을 보여주곤 했지만, 요즘 자주 보는 ESM과 Node 모듈 문맥에서는 그대로 일반화하기 어렵습니다. Node에서는 공식 문서의 Packages와 ES Modules 페이지가 package.json의 "type": "module"과 ESM/CommonJS 차이를 분리해 설명합니다.
아래처럼 최소 설정을 두고 예제를 실행하면, TDZ와 함수 선언문·함수 표현식의 차이를 비교적 깔끔하게 확인할 수 있습니다.
{
"type": "module"
}
var, let, const, 함수 선언문은 어떻게 준비될까
같은 “먼저 준비된다”라는 말 안에서도 준비 상태는 꽤 다릅니다.
var: 스코프 진입 시 바인딩이 만들어지고 바로undefined로 초기화됩니다. 선언 전 접근이 가능해 보이는 이유가 여기 있습니다.let: 바인딩은 먼저 만들어지지만 초기화 전까지 읽을 수 없습니다. 선언문이 실행되기 전 구간이 TDZ입니다.const:let과 마찬가지로 TDZ를 거치며, 초기화 이후에는 재할당이 허용되지 않습니다. 선언 시 초기값이 필요하다는 점도 함께 기억할 만합니다.- 함수 선언문: 스코프 진입 시 함수 객체까지 연결되므로 선언보다 앞에서 호출해도 동작합니다.
- 함수 표현식: 함수가 담기는 변수의 규칙을 따릅니다.
var f = function () {}는var처럼,let f = function () {}는let처럼 읽어야 합니다.
이 차이는 “값”, “상태”, “오류”를 따로 보지 않으면 쉽게 섞입니다. undefined는 값이고, TDZ는 값이 아니라 미초기화 상태이며, TypeError는 이미 존재하는 값에 대해 잘못된 연산을 했을 때 나타나는 오류입니다.
실행 결과로 보는 값, 상태, 오류의 차이
아래 예제는 호이스팅 이야기를 할 때 가장 자주 섞이는 네 가지를 한 번에 보여줍니다. var, let, 함수 선언문, 함수 표현식이 각각 어떤 상태로 준비되는지 실제 출력으로 확인할 수 있습니다.
console.log('var-before =', value);
var value = 10;
console.log('var-after =', value);
try {
console.log('let-before =', count);
} catch (error) {
console.log('let-before error =', error.name + ': ' + error.message);
}
let count = 3;
console.log('let-after =', count);
hoisted();
function hoisted() {
console.log('function declaration = ok');
}
try {
notHoisted();
} catch (error) {
console.log('function expression error =', error.name + ': ' + error.message);
}
var notHoisted = function () {
console.log('function expression = ok');
};
console.log('function expression typeof after init =', typeof notHoisted);
$ node hoisting-demo.js
var-before = undefined
var-after = 10
let-before error = ReferenceError: Cannot access 'count' before initialization
let-after = 3
function declaration = ok
function expression error = TypeError: notHoisted is not a function
function expression typeof after init = function
이 출력은 세 층위로 나눠 읽으면 덜 헷갈립니다.
var-before = undefined는 바인딩이 이미 존재하고 값도 들어 있다는 뜻입니다. 다만 그 값이 아직 개발자가 대입한 10이 아니라 초기값 undefined일 뿐입니다.
let-before에서 난 ReferenceError는 값을 읽지 못한 것이 아니라, 바인딩이 미초기화 상태였다는 뜻입니다. TDZ는 “없는 이름”이 아니라 “있지만 아직 읽을 수 없는 이름”에 가깝습니다.
notHoisted()에서 난 TypeError는 또 다른 상황입니다. 이 경우 notHoisted라는 이름은 존재합니다. 하지만 그 시점의 값이 함수가 아니라 undefined이기 때문에, undefined()를 호출하려다 실패한 것입니다. 즉 ReferenceError와 TypeError는 실패 지점이 다릅니다. 하나는 바인딩 읽기에서, 다른 하나는 읽어 온 값에 대한 연산에서 발생합니다.
TDZ에서 자주 헷갈리는 typeof
디버깅할 때 자주 섞이는 지점이 typeof입니다. 선언되지 않은 이름에 대해서는 typeof가 비교적 안전해 보이지만, TDZ에 있는 이름에는 그렇지 않습니다. 이 차이는 “없는 이름”과 “미초기화된 이름”이 다르다는 사실을 다시 보여줍니다.
try {
console.log('typeof undeclared =', typeof undeclaredVar);
} catch (error) {
console.log('typeof undeclared error =', error.name + ': ' + error.message);
}
try {
console.log('typeof tdz =', typeof tdzVar);
} catch (error) {
console.log('typeof tdz error =', error.name + ': ' + error.message);
}
let tdzVar = 1;
console.log('after init =', tdzVar);
$ node typeof-demo.js
typeof undeclared = undefined
typeof tdz error = ReferenceError: Cannot access 'tdzVar' before initialization
after init = 1
첫 줄의 undeclaredVar는 애초에 선언되지 않았기 때문에 typeof가 undefined를 돌려줍니다. 반면 tdzVar는 이미 현재 스코프의 바인딩으로 잡혀 있으므로, 엔진은 이 이름을 “없는 이름”으로 취급하지 않습니다. 다만 아직 초기화 전이므로 읽는 순간 ReferenceError가 납니다.
이 차이는 const를 읽을 때도 그대로 이어집니다. 초기화 전에 접근하면 ReferenceError이고, 초기화 뒤에 다시 할당하려고 하면 TypeError입니다. 둘 다 const 주변에서 나오는 오류지만 의미는 전혀 다릅니다.
오래된 설명과 현재 설명이 엇갈리는 지점
호이스팅 관련 글을 읽을 때 특히 조심할 만한 부분은 몇 가지가 있습니다.
- “호이스팅은 선언문이 위로 이동하는 것”이라는 표현은 입문 비유로는 쓸 수 있지만, TDZ와 함수 표현식 차이까지 설명하기에는 부족합니다.
- “
let과const는 호이스팅되지 않는다”는 설명은 현재 기준으로는 부정확합니다. 바인딩은 먼저 만들어지며, 초기화 전 접근만 막혀 있습니다. - “전역의
var는 항상 전역 객체 프로퍼티가 된다”는 설명은 고전 브라우저script문맥에 가까운 말입니다. ESM과 Node 모듈에서는 전역 처리 방식이 다르게 보일 수 있습니다. - 블록 안 함수 선언문은 오래된 비엄격 모드
script환경에서 웹 호환성 규칙이 섞여 더 복잡하게 동작할 수 있습니다. 최근 코드에서는 모듈이나 strict mode를 기준으로 읽는 편이 혼동을 줄여 줍니다.
그래서 최근 자바스크립트에서는 “엔진이 내부적으로 컴파일한다”는 큰 말보다, “스코프 진입 시 어떤 바인딩이 생성되고, 언제 초기화되며, 그 전후에 읽으면 어떤 값이나 오류가 관찰되는가”라는 흐름이 더 설명력이 높습니다. 호이스팅은 결국 코드 이동이 아니라, 실행 이전 준비 단계와 실행 시점의 차이를 관찰한 결과라고 볼 수 있습니다.
원문 참고
https://www.maeil-mail.kr/question/45
댓글
댓글 쓰기