자바스크립트 호이스팅, undefined와 ReferenceError는 왜 다를까

빠른 답

호이스팅은 코드 이동이 아니라 실행 전 선언이 먼저 등록되는 과정으로 이해하는 편이 정확하다.
var는 선언 시 undefined로 초기화되므로 값 할당 전 접근하면 undefined가 나온다.
let과 const는 TDZ 구간이 있어 선언문 이전 접근 시 ReferenceError가 발생한다.
함수 선언문은 먼저 준비되지만 함수 표현식은 변수 규칙을 따라 다른 오류를 만들 수 있다.

호이스팅은 코드가 올라가는 현상이 아니라 선언이 먼저 준비되는 과정이다
흐름으로 보기
실행 전에 일어나는 일: 생성 단계와 실행 단계
실험 환경 준비
한 파일로 비교하는 var, let, const, 함수 선언문, 함수 표현식
콘솔 출력으로 읽는 undefined, ReferenceError, TypeError의 차이
블록 스코프와 TDZ에서 자주 생기는 실수
실무에서 기억할 판단 기준

호이스팅은 코드가 올라가는 현상이 아니라 선언이 먼저 준비되는 과정이다

호이스팅을 "변수와 함수가 위로 끌어올려진다"라고만 외우면 실제 실행 결과를 설명하기 어려워집니다. 자바스크립트 엔진은 코드를 물리적으로 위로 옮기지 않습니다. 대신 현재 스코프에서 어떤 이름이 선언됐는지 먼저 파악하고, 그 이름들을 사용할 준비를 해 둡니다. 그래서 핵심은 "코드가 어디 있나"보다 "이 시점에 그 이름이 어떤 상태인가"입니다.

용어도 하나 바로잡아 두면 좋습니다. function hello() {}를 흔히 함수 선언식이라고 부르지만, 함수 표현식과 구분하려면 함수 선언문이라고 부르는 편이 더 정확합니다. 이 글에서는 함수 선언문과 함수 표현식을 분리해서 설명합니다.

흐름으로 보기

자바스크립트 호이스팅, undefined와 ReferenceError는 왜 다를까 흐름 다이어그램

자바스크립트 엔진은 먼저 소스 코드를 읽고 선언을 수집합니다. 그다음 var, let, const, 함수 선언문을 서로 다른 규칙으로 준비한 뒤, 실제 실행 단계에서 대입과 호출을 처리합니다. 우리가 콘솔에서 보는 undefined, ReferenceError, TypeError는 모두 이 준비 상태와 실행 시점이 만나는 지점에서 결정됩니다.

실행 전에 일어나는 일: 생성 단계와 실행 단계

학습용으로는 스코프 진입 시점을 생성 단계와 실행 단계로 나눠 보면 이해가 쉽습니다. 생성 단계에서는 식별자가 등록되고, 실행 단계에서는 코드가 위에서 아래로 수행됩니다. 정확한 내부 알고리즘은 더 잘게 나뉘지만, 호이스팅을 이해하는 데는 이 구분만으로 충분합니다.

var는 생성 단계에서 곧바로 undefined로 초기화됩니다. 그래서 선언문보다 먼저 읽어도 값은 꺼낼 수 있지만, 아직 대입이 끝나지 않았으므로 undefined가 보입니다. 반대로 let과 const는 이름만 등록되고 초기화는 선언문이 실행될 때 일어납니다. 이 초기화 전 구간이 TDZ(Temporal Dead Zone)입니다.

함수 선언문은 생성 단계에서 함수 본문까지 사용할 수 있는 상태로 준비됩니다. 그래서 선언 이전 호출이 가능합니다. 하지만 함수 표현식은 변수에 함수를 나중에 대입하는 방식이므로, 결국 그 변수를 var, let, const 중 무엇으로 선언했는지가 동작을 결정합니다. 화살표 함수도 변수에 담기는 함수 표현식이므로 같은 규칙을 따릅니다.

실험 환경 준비

브라우저 개발자 도구 콘솔에서도 확인할 수 있지만, 한 번에 여러 케이스를 비교하려면 작은 Node.js 실험 파일이 가장 편합니다. 스크립트와 실행 명령을 미리 잡아 두면 오류가 발생해도 try/catch로 흐름을 끊지 않고 전체 결과를 한 화면에서 볼 수 있습니다.

{
  "name": "hoisting-lab",
  "private": true,
  "scripts": {
    "hoisting": "node hoisting-demo.js",
    "tdz": "node tdz-block.js"
  }
}

위처럼 package.json만 준비해 두고 npm run hoisting 또는 npm run tdz를 실행하면 됩니다. 개념 글이라도 실행 환경을 붙여 두면 "왜 그런가"에서 멈추지 않고 "실제로 무엇이 나오나"까지 확인할 수 있습니다.

한 파일로 비교하는 var, let, const, 함수 선언문, 함수 표현식

아래 예제는 호이스팅을 이해할 때 가장 자주 섞이는 다섯 가지를 한 파일에 모아 놓은 것입니다. 의도적으로 선언 이전 접근을 만들고 try/catch로 결과를 모두 출력하게 했습니다.

console.log("1.var before assignment =", valueVar);
var valueVar = 1;

try {
  console.log("2.let before declaration =", valueLet);
} catch (error) {
  console.log("2.let before declaration =", error.name + ": " + error.message);
}
let valueLet = 2;

console.log("3.function declaration =", add(1, 2));
function add(a, b) {
  return a + b;
}

try {
  console.log("4.var function expression =", multiply(2, 3));
} catch (error) {
  console.log("4.var function expression =", error.name + ": " + error.message);
}
var multiply = function (a, b) {
  return a * b;
};

try {
  console.log("5.const function expression =", divide(6, 2));
} catch (error) {
  console.log("5.const function expression =", error.name + ": " + error.message);
}
const divide = function (a, b) {
  return a / b;
};

이 예제를 한 번에 보면 선언 방식이 달라질 때 무엇이 먼저 준비되는지가 그대로 드러납니다. add는 함수 선언문이므로 바로 호출되고, multiply는 이름은 있지만 아직 함수가 아니라서 호출에 실패하며, divide는 아예 읽을 수 없는 상태라 더 이른 단계에서 막힙니다.

콘솔 출력으로 읽는 undefined, ReferenceError, TypeError의 차이

런타임마다 오류 문구는 조금 달라질 수 있지만, 아래와 같은 흐름이 나오면 정상입니다. 중요한 것은 메시지의 세부 문장보다 오류 종류와 그 시점입니다.

1.var before assignment = undefined
2.let before declaration = ReferenceError: Cannot access 'valueLet' before initialization
3.function declaration = 3
4.var function expression = TypeError: multiply is not a function
5.const function expression = ReferenceError: Cannot access 'divide' before initialization

여기서 undefined는 "이름은 있고 읽을 수도 있지만, 아직 원하는 값이 없다"는 신호입니다. ReferenceError는 "현재 시점에는 이 식별자를 읽을 수 없다"는 뜻이며, TDZ나 스코프 문제를 먼저 의심해야 합니다. TypeError는 읽기 자체는 성공했지만 그 값이 기대한 형태가 아닐 때 나옵니다. multiply 예제에서는 값이 undefined인데 이를 함수처럼 호출했기 때문에 TypeError가 발생합니다.

실무 디버깅에서도 이 구분은 그대로 도움이 됩니다. ReferenceError를 보고 함수 여부를 먼저 의심하면 순서가 틀리고, TypeError: x is not a function을 보고 선언 누락부터 찾기 시작해도 시간이 낭비됩니다. 먼저 "이름이 있나", 다음으로 "읽을 수 있나", 마지막으로 "읽은 값이 지금 기대한 타입인가" 순서로 보면 훨씬 빠르게 원인을 좁힐 수 있습니다.

블록 스코프와 TDZ에서 자주 생기는 실수

TDZ는 선언문 이전에만 생기는 문제가 아닙니다. 블록 스코프 안에서 같은 이름을 다시 선언하면, 바깥 변수를 읽을 것처럼 보여도 실제로는 안쪽 변수의 TDZ에 먼저 걸릴 수 있습니다. 이 부분에서 많은 코드가 예상과 다르게 동작합니다.

const user = "outer";

{
  try {
    console.log(user);
  } catch (error) {
    console.log(error.name + ": " + error.message);
  }

  const user = "inner";
  console.log(user);
}

위 코드는 바깥에 user가 이미 있는데도 첫 번째 console.log(user)에서 오류가 납니다. 이유는 안쪽 블록에 const user가 선언될 예정이기 때문입니다. 엔진은 블록에 진입할 때 안쪽 user를 먼저 등록하고, 선언문이 실행되기 전까지는 TDZ로 묶어 둡니다. 그래서 바깥 user를 읽는 것이 아니라, 아직 초기화되지 않은 안쪽 user를 읽으려다 ReferenceError가 납니다.

같은 맥락으로 "let과 const는 호이스팅되지 않는다"라는 설명도 정확하지 않습니다. 둘 다 호이스팅됩니다. 다만 var처럼 즉시 undefined로 초기화되지 않을 뿐입니다. 참고로 const는 선언과 동시에 초기화해야 하므로 const answer; 같은 코드는 TDZ 이전에 문법 단계에서 SyntaxError가 납니다. 호이스팅 여부보다 초기화 시점과 접근 가능 시점을 구분해서 기억하는 편이 훨씬 덜 헷갈립니다.

실무에서 기억할 판단 기준

호이스팅은 시험용 암기 포인트보다 디버깅 규칙으로 기억하는 편이 오래 남습니다. 아래 기준만 잡고 가도 대부분의 실수를 빠르게 줄일 수 있습니다.

선언 이전 접근 문제가 보이면 코드 순서보다 현재 바인딩 상태를 먼저 봅니다.
undefined는 "없다"가 아니라 "아직 값이 대입되지 않았다"는 경우가 많습니다.
함수 표현식을 선언 전에 호출할 때는 함수 자체보다 그 변수를 var, let, const 중 무엇으로 선언했는지부터 확인합니다.
블록 안에서 같은 이름을 다시 선언했다면 바깥 변수를 읽을 것이라고 가정하지 않습니다. 섀도잉과 TDZ를 함께 봐야 합니다.
새 코드에서는 const를 기본값으로, 재할당이 필요할 때만 let을 쓰고, 선언 이전 사용에 기대는 패턴은 피하는 편이 안전합니다.

브라우저 환경까지 넓혀 보면 추가로 기억할 점이 하나 더 있습니다. 전통적인 script 환경의 최상위 var는 전역 객체와 연결될 수 있지만, let과 const는 그렇지 않습니다. 다만 요즘은 모듈 환경이 많기 때문에 이 차이에 기대기보다는, 선언을 먼저 쓰고 이후에 사용하는 형태로 코드를 정리하는 편이 더 읽기 쉽고 안전합니다.

원문 참고

https://www.maeil-mail.kr/question/31

코드 땜장이

이 블로그 검색