🧠 01. 실행 컨텍스트 & 스코프 — JS 엔진은 코드를 어떻게 읽는가?

🎯 이 섹션을 읽고 나면:

• JS 엔진이 코드를 실행하기 전에 무엇을 먼저 하는지 설명할 수 있다.
• 호이스팅(Hoisting)이 왜 일어나는지, var가 왜 레거시 냄새가 나는지 이해한다.
• 스코프 체인(Scope Chain)이 변수 탐색을 어떻게 하는지 머릿속에 그릴 수 있다.

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 1. 왜 알아야 하는가?
• 🏗️ 2. 실행 컨텍스트란?
  • 전역 실행 컨텍스트 (GEC)
  • 함수 실행 컨텍스트 (FEC)
  • 콜 스택 (Call Stack)
• 🔍 3. 호이스팅 — 선언이 위로 끌려올라간다?
  • var 의 호이스팅 폭탄
  • 함수 선언식 vs 함수 표현식 차이
• 🗂️ 4. 스코프 & 스코프 체인
  • 렉시컬 스코프 (Lexical Scope)
  • var / let / const 스코프 비교
  • TDZ — Temporal Dead Zone
• 📝 5. 실무 패턴 정리
• 📝 마무리 퀴즈
• 🐣 영철이의 퇴근 일기
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 20분(전체) / 핵심 파트만: 12분

🗺️ 이 문서의 흐름
[JS 엔진의 2단계 실행] → [실행 컨텍스트 생성] → [호이스팅 이해] → [스코프 체인 탐색]

🎯 이 문서를 다 읽으면 할 수 있는 것

• "왜 var를 쓰지 말라는 거야?"에 기술적 근거로 답할 수 있다.
• ReferenceError: Cannot access before initialization 에러의 원인을 즉시 진단한다.
• 변수가 어떤 스코프에서 탐색되는지 콜 스택을 그리며 추적할 수 있다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

🐣 영철: "영호 님, 오늘 진짜 황당한 일이 있었어요. 제가 var로 반복문 변수 선언해서 비동기 콜백에서 쓰는 코드를 짰는데... 루프가 끝난 뒤에 콜백이 실행되니까 변수가 전부 마지막 값으로 굳어있는 거예요! 어떻게 모든 i가 다 5야? 분명 0, 1, 2, 3, 4가 찍혀야 하는데... 멘탈이 흔들렸습니다."

🦁 영호: "그거, 실행 컨텍스트를 모르면 평생 당하는 함정이야. var는 함수 스코프 라서 루프의 {} 블록을 무시하고, 그 위 함수(또는 전역)에 딱 하나만 선언되거든. 콜백이 실행될 때 모든 클로저가 같은 i를 참조하니까 당연히 마지막 값이 나오지. let을 쓰면 블록마다 새로운 바인딩이 생겨서 해결돼. 이게 바로 오늘 배울 실행 컨텍스트와 스코프 이야기야."

🤔 1. 왜 알아야 하는가?

영철이가 만든 게시판 댓글 로딩 코드를 보자.

// 🐣 영철의 코드 — 댓글 5개를 비동기로 각각 로드하려 했음
for (var i = 0; i < 5; i++) {
  setTimeout(function () {
    console.log("댓글 " + i + "번 로드 완료"); // 실제 출력: 전부 "댓글 5번 로드 완료"
  }, 1000);
}

영철이는 0, 1, 2, 3, 4를 기대했지만 실제로는 5, 5, 5, 5, 5가 출력됐다.

이 버그의 원인은 단 하나: var는 블록 스코프가 없다. 루프가 돌아도 i는 전역(또는 함수) 컨텍스트에 하나만 존재하고, setTimeout 콜백이 실행될 때는 이미 루프가 끝나 i === 5 상태다.

실행 컨텍스트와 스코프를 이해하면 이런 보이지 않는 함정 을 설계 단계에서 차단할 수 있다.

🏗️ 2. 실행 컨텍스트란?

JS 엔진이 코드를 실행할 때 만드는 환경 정보 묶음 이다. "이 코드가 어떤 변수에 접근할 수 있는가?", "this는 무엇을 가리키는가?"를 담고 있다.

실행 컨텍스트는 두 단계 로 생성된다:

핵심 멘탈 모델: JS 엔진은 코드를 두 번 훑는다. 첫 번째 훑을 때 변수/함수를 미리 등록해두고, 두 번째 훑을 때 실제로 실행한다.

전역 실행 컨텍스트 (GEC)

코드가 실행되기 전, JS 엔진이 가장 먼저 구축하는 기초 토대입니다. 이 단계에서 var로 선언된 변수나 함수 선언문들이 메모리에 등록됩니다.

전역 실행 컨텍스트 (GEC)
├── VariableEnvironment (var 선언들)
│   ├── userName: undefined  ← 호이스팅됨
│   └── getUserCount: function  ← 함수 선언식은 완전히 올라옴
├── LexicalEnvironment (let/const 선언들)
│   └── POST_LIMIT: <uninitialized>  ← TDZ 상태
└── ThisBinding: window (브라우저) / global (Node.js)

함수 실행 컨텍스트 (FEC)

함수가 호출될 때마다, 그 함수만을 위한 전용 공간이 새로 생깁니다. 영철이가 새로운 유저 프로필 로드 함수를 만들었을 때의 컨텍스트 내부를 들여다보겠습니다.

function loadUserProfile(userId) {
  const user = findUser(userId); // 이 함수가 호출되면 새 컨텍스트 생성
  return user;
}
 
// loadUserProfile(42) 호출 시:
// 함수 실행 컨텍스트 (FEC)
// ├── Arguments: { userId: 42 }
// ├── LexicalEnvironment: { user: <uninitialized> }
// └── OuterEnvironment: → 전역 실행 컨텍스트 (스코프 체인)

콜 스택 (Call Stack)

생성된 실행 컨텍스트들은 차곡차곡 쌓이게 됩니다. 영수네 커뮤니티에서 게시글 상세 조회를 누르는 순간, 브라우저 내부에서 어떤 일이 일어나는지 시각화해 보겠습니다.

// 영수네 커뮤니티 — 게시글 상세 조회 흐름
 
function getComments(postId) {
  return fetchFromDB(postId);  // fetchFromDB 호출
}
 
function renderPost(postId) {
  const comments = getComments(postId);  // getComments 호출
  return { comments };
}
 
renderPost(101);
 
// 콜 스택 시각화:
// ┌─────────────────────┐
// │  fetchFromDB (FEC)  │  ← 현재 실행 중 (top)
// ├─────────────────────┤
// │  getComments (FEC)  │
// ├─────────────────────┤
// │   renderPost (FEC)  │
// ├─────────────────────┤
// │  전역 컨텍스트 (GEC) │  ← 항상 bottom
// └─────────────────────┘
//
// fetchFromDB 완료 → pop
// getComments 완료 → pop
// renderPost 완료 → pop
// 전역만 남음

🔍 3. 호이스팅 — 선언이 위로 끌려올라간다?

호이스팅은 "코드가 물리적으로 위로 이동" 하는 게 아니다. 실행 컨텍스트의 생성 단계 에서 변수와 함수가 미리 메모리에 등록되는 것이다.

var 의 호이스팅 폭탄

var 는 선언되기 전부터 마치 이미 존재하는 것처럼 행동합니다. 에러를 내뱉는 대신 undefined를 반환하며 조용히 버그를 숨기곤 하는데, 영호 리드 님은 이를 "언제 터질지 모르는 시한폭탄 같은 코드"라고 부릅니다.

// ❌ 순진한 코드 (Naive Approach) — 영철이의 초기 코드
console.log(userName); // undefined (에러가 아님! 이게 더 무서움)
var userName = "영철";
console.log(userName); // "영철"
 
// 🦁 JS 엔진이 실제로 처리하는 방식 (생성 단계에서 이미 등록됨):
// var userName = undefined;  ← 생성 단계에서 undefined로 초기화
// console.log(userName);     // undefined
// userName = "영철";          ← 실행 단계에서 값 할당
// console.log(userName);     // "영철"

왜 이게 문제인가? undefined가 조용히 반환되기 때문에, 어딘가에서 데이터가 꼬여도 원인을 찾기가 매우 힘들어집니다. 특히 반복문 안에서 비동기 코드를 섞어 쓸 때 그 위험성이 두드러집니다.

// ❌ var의 함수 스코프 함정 — 루프 버그
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100); // 3, 3, 3
}
 
// ✅ let으로 교체 — 블록 스코프
for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100); // 0, 1, 2
}
// let은 블록({})`마다 새로운 바인딩을 생성한다.
// 각 이터레이션마다 독립적인 i가 존재함.

함수 선언식 vs 함수 표현식 차이

함수를 정의하는 방식에 따라 엔진의 대우가 달라집니다. 어떤 녀석은 파일 최상단에서 불러도 씩씩하게 답하지만, 어떤 녀석은 "아직 준비가 안 됐다"며 에러를 내기도 합니다.

// ✅ 함수 선언식 — 완전히 호이스팅됨 (정의까지 올라옴)
sayHello(); // "안녕하세요!" — 선언 전에 호출해도 정상 작동
 
function sayHello() {
  console.log("안녕하세요!");
}
 
// ❌ 함수 표현식 — 변수만 호이스팅됨 (undefined 상태)
sayBye(); // TypeError: sayBye is not a function
 
var sayBye = function () {
  console.log("안녕히 가세요!");
};
 
// ❌ const/let + 화살표 함수 — TDZ로 인해 ReferenceError
greet(); // ReferenceError: Cannot access 'greet' before initialization
 
const greet = () => {
  console.log("반갑습니다!");
};

🦁 영호의 조언: "함수 선언식의 호이스팅 덕분에 파일 아래쪽에 헬퍼 함수를 모아두는 스타일이 가능하긴 해. 하지만 팀 프로젝트에서는 선언 순서가 의도를 전달 하므로, 일관성을 위해 함수 표현식(const fn = () => {})을 선호하는 팀도 많아."

🗂️ 4. 스코프 & 스코프 체인

스코프 (Scope) 는 변수가 유효한 영역이다. JS는 렉시컬 스코프 를 사용한다.

렉시컬 스코프 (Lexical Scope)

함수가 어디서 호출됐는지는 중요하지 않습니다. 오직 어디서 태어났는가 가 변수의 운명을 결정합니다. 영수네 커뮤니티의 권한 체크 로직을 통해 이 관계를 확인해 보겠습니다.

// 영수네 커뮤니티 — 권한 체크 로직
 
const APP_NAME = "영수네 커뮤니티"; // 전역 스코프
 
function checkAuth() {
  const role = "admin"; // checkAuth 스코프
 
  function showWelcome() {
    // role을 선언한 적 없지만, 선언된 위치(상위 스코프)에서 찾아옴
    console.log(`${APP_NAME}에 오신 ${role} 님 환영합니다!`);
    // → "영수네 커뮤니티에 오신 admin 님 환영합니다!"
  }
 
  showWelcome();
}
 
checkAuth();
 
// 스코프 체인 탐색 순서:
// showWelcome → checkAuth → 전역
// role: showWelcome에 없음 → checkAuth에서 발견 ✅
// APP_NAME: showWelcome에 없음 → checkAuth에 없음 → 전역에서 발견 ✅

var / let / const 스코프 비교

// ❌ var — 블록을 무시하는 위험한 행동
function processPost() {
  if (true) {
    var tempData = "임시 데이터"; // if 블록 밖에서도 접근 가능!
  }
  console.log(tempData); // "임시 데이터" — 의도치 않은 접근
}
 
// ✅ let/const — 블록 경계를 지킨다
function processPost() {
  if (true) {
    const tempData = "임시 데이터"; // if 블록 내부에서만 유효
  }
  console.log(tempData); // ReferenceError: tempData is not defined ← 명확한 에러!
}

TDZ — Temporal Dead Zone

let과 const도 사실 호이스팅은 되지만, 안전을 위해 "선언문이 실행되기 전까지는 만지지 마시오" 라는 일시적 사각지대를 만듭니다.

// TDZ 시각화
{
  // ← 여기서부터 TDZ 시작 (postTitle은 메모리에 등록됐지만 초기화 안 됨)
  console.log(postTitle); // ❌ ReferenceError: Cannot access 'postTitle' before initialization
 
  const postTitle = "클로저 완전정복"; // ← 여기서 TDZ 종료, 초기화
 
  console.log(postTitle); // ✅ "클로저 완전정복"
}
 
// 왜 TDZ가 좋은가?
// var: 선언 전 접근 → undefined (조용한 버그)
// let/const: 선언 전 접근 → ReferenceError (즉시 발견되는 명확한 에러) ✅

📝 5. 실무 패턴 정리

지금까지 배운 개념들을 실무 코드에 어떻게 녹여내야 할까요? 영호 리드 님이 팀원들에게 공유한 "절대 무너지지 않는 변수 선언 전략"을 소개합니다.

// ✅ 실무에서 권장하는 변수 선언 전략
 
// 1. 기본은 const — 대부분의 변수는 재할당 불필요
const API_BASE_URL = "https://api.youngsu.com";
const currentUser = { id: 42, name: "영철" };
 
// 2. 재할당이 필요한 경우만 let
let retryCount = 0;
while (retryCount < 3) {
  // ...
  retryCount++;
}
 
// 3. var는 절대 사용 금지
// var isLoading = true; ← 이 코드가 PR에 올라오면 영호 리드가 reject
 
// 4. 함수는 const + 화살표 함수로 일관성 유지
const fetchPost = async (postId) => {
  const response = await fetch(`${API_BASE_URL}/posts/${postId}`);
  return response.json();
};
 
// 5. for...of 루프에서도 const 사용 가능 (매 이터레이션마다 새 바인딩)
const posts = [{ id: 1 }, { id: 2 }, { id: 3 }];
for (const post of posts) {
  console.log(post.id); // 1, 2, 3
}

📝 마무리 퀴즈

Q1. 아래 코드의 출력 결과를 예측하고, 그 이유를 설명하라.

console.log(a);
console.log(b);
var a = 1;
let b = 2;

✅ 정답: undefined 출력 후, ReferenceError: Cannot access 'b' before initialization

💡 상세 해설:

• var a의 호이스팅: 생성 단계에서 a는 undefined로 초기화되어 메모리에 등록된다. 따라서 선언 전 접근해도 undefined를 반환한다.
• let b의 TDZ: b도 메모리에 등록되지만 초기화되지 않은 상태(uninitialized) 로 TDZ 구간에 있다. 선언문 실행 전에 접근하면 ReferenceError가 발생한다.
• 📌 핵심 기억법: var는 "조용한 undefined", let/const는 "시끄러운 에러". 시끄러운 에러가 더 좋다. 버그를 즉시 발견할 수 있으니까.

Q2. 렉시컬 스코프와 동적 스코프의 차이는? JavaScript는 어느 쪽인가?

✅ 정답: JavaScript는 렉시컬 스코프 (정적 스코프)

💡 상세 해설:

• 렉시컬 스코프: 함수가 선언된 위치 를 기준으로 상위 스코프를 결정한다. 코드를 작성할 때(정적으로) 스코프가 확정된다.
• 동적 스코프: 함수가 호출된 위치 를 기준으로 스코프를 결정한다. (JavaScript는 이 방식 사용 안 함)
• JS는 렉시컬 스코프이므로, 함수를 어디에서 호출하든 선언된 위치의 상위 스코프 를 참조한다. 이것이 클로저의 근간이다.
• 📌 핵심 기억법: "함수가 태어난 곳을 기억한다." — 클로저 챕터에서 이 개념이 폭발적으로 확장된다.

Q3. 영철이의 테스트 타임 — 긴급 디버깅

영수 PM이 호통을 친다: "영철 님, 관리자 페이지에서 isAdmin 체크가 완전히 뚫렸어요! 루프 안에서 권한 체크하는 코드를 보내줘요!"

// 🐣 영철이 보낸 코드
var isAdmin = false;
 
for (var i = 0; i < adminList.length; i++) {
  if (adminList[i].id === currentUser.id) {
    var isAdmin = true; // 재선언해도 에러 없음!
  }
}
 
setTimeout(() => {
  if (isAdmin) {
    showAdminPanel(); // 의도는 맞지만 구조 자체가 위험
  }
}, 0);

어떤 문제가 있는가? 어떻게 리팩토링해야 하는가?

✅ 정답: var 재선언 허용 + 함수 스코프로 인한 구조적 취약점. const와 Array.some()으로 교체.

💡 상세 해설:

• var isAdmin 재선언: var는 같은 스코프 내에서 중복 선언이 허용된다. 대규모 코드베이스에서 다른 개발자가 실수로 같은 이름의 var를 선언하면 조용히 덮어쓴다. 보안 버그의 씨앗 이다.
• 더 나은 패턴 (Pro Approach):

  // ✅ 리팩토링된 코드
  const isAdmin = adminList.some((admin) => admin.id === currentUser.id);
  // - const: 재할당/재선언 불가 → 의도치 않은 변경 방지
  // - some(): 조건 충족 즉시 순회 중단 (성능 ✅)
  // - 함수형: 순수 표현식으로 가독성 극대화

• 📌 핵심 기억법: "인증이나 보안에 관련된 변수는 반드시 const로 관리해야 합니다." var는 나도 모르는 사이에 다른 코드에 의해 값이 덮어써질 위험이 있기 때문입니다.

🐣 영철이의 퇴근 일기

퇴근길 버스에 앉았다. 오늘 영호 님이 "실행 컨텍스트" 설명해주는 거 듣고, 솔직히 처음에는 '이게 뭔 철학 수업이야...' 싶었는데. 지금 돌아보니까 내가 그동안 얼마나 아무것도 모르고 코드를 짰는지가 느껴져서 좀 민망하다. var로 루프 돌리고 비동기 쓴 코드가... 팀 프로젝트 레포에 아직 살아있을 텐데. 내일 출근하자마자 조용히 PR 올려야겠다.

💡 오늘의 교훈: "JS 엔진은 코드를 두 번 읽는다. 첫 번째는 변수를 등록하고, 두 번째는 실행한다. var는 첫 번째 때 undefined로 조용히 들어오고, let/const는 TDZ로 시끄럽게 자기 존재를 알린다. 시끄러운 쪽이 오히려 착한 거다."

영호 님 덕분에 살았다. 오늘 한 건 배웠으니까, 집 가서 맥주 한 캔 따고 다음 챕터 한 번만 더 훑어봐야지. 클로저가 기다리고 있다고.

🔗 더 알아보기

• MDN — Closures
• MDN — Grammar and types (var/let/const)
• You Don't Know JS — Scope & Closures (Kyle Simpson)