자바스크립트 기초 쌓기 시리즈 - 1: 실행 컨텍스트 및 호이스팅에 대해서

 

자바스크립트(JavaScript)는 오늘날 웹 생태계를 움직이는 거대한 심장이자, 명실상부한 글로벌 표준 언어입니다. 화면의 작은 버튼 하나를 움직이는 것부터 수백만 명의 트래픽을 감당하는 서버(Node.js) 구축, 더 나아가 모바일 앱과 데스크톱 애플리케이션 개발에 이르기까지 그 영향력은 경계가 없을 정도로 중요한 언어일 것입니다. 상황이 이렇다 보니, 프론트엔드와 백엔드를 막론하고 웹 개발자를 목표로 하는 전공자와 비전공자 학생들은 물론, 이제 막 현업에 뛰어든 신입 개발자, 그리고 연차가 점점 쌓여 가는 주니어 · 미들급 개발자들까지 모두가 자바스크립트를 붙잡고 치열하게 씨름하고 있습니다. 

하지만 아이러니하게도 자바스크립트는 '가장 배우기 쉬우면서도, 가장 마스터하기 어려운 언어'로 꼽힙니다. HTML, CSS와 결합하여 몇 줄의 코드만으로도 눈에 보이는 결과물을 만들어낼 수 있어 진입 장벽은 낮지만, 언어의 내부 깊숙한 곳으로 들어갈수록 예상치 못한 기이한 동작들과 마주하기 때문입니다. 독특한 프로토타입 기반의 상속, 실행 컨텍스트의 메커니즘, 메모리를 쥐고 흔드는 클로저, 그리고 이벤트 루프와 비동기 처리까지, 자바스크립트는 알면 알수록 미궁에 빠지기 쉬운 독특한 설계 철학을 가지고 있습니다.

많은 학생들이나 신입 개발자들이 범하는 가장 큰 실수는 프레임워크나 라이브러리(React, Vue, Next.js 등)의 화려한 기술을 빠르게 익히는 데만 급급해 정작 그 기반이 되는 '바닐라 자바스크립트(Vanilla JS)'의 기초 체력을 소홀히 한다는 점입니다. 당장 눈앞의 기능을 구현하는 데는 문제가 없을지 모릅니다. 그러나 코드의 규모가 커지고, 복잡한 성능 최적화가 필요하며, 원인을 알 수 없는 버그가 발생했을 때 기초가 부실한 개발자는 무너질 수밖에 없습니다. "에러는 안 나는데 왜 화면이 안 움직이지?", "왜 이 변수 값이 갑자기 변했지?"라는 질문에 답을 내리지 못하고 Stack Overflow나 AI가 제공하는 코드를 복사 · 붙여 넣기만 하는 악순환에 빠지게 됩니다.

이러한 현상은 현업에서 3~5년 동안 치열하게 서비스를 만들어온 경력직 개발자들에게도 찾아올 수 있습니다. 이른바 '주니어 레벨의 정체기'입니다. 라이브러리를 다루는 숙련도는 높아졌지만, 면접이나 기술 면접에서 언어 본연의 동작 원리를 묻는 질문(예: 실행 컨텍스트와 호이스팅의 관계를 설명해 주세요.)을 받으면 말문이 막히곤 합니다. 이 정체기를 뚫고 시니어 개발자로 도약하기 위해 필요한 유일한 열쇠 역시, 결국은 자바스크립트의 '기본기'를 다시 정교하게 다듬는 일입니다. 

본 연재 시리즈는 바로 이러한 고민을 안고 있는 모든 이들을 위해 준비했습니다. 이제 막 첫 걸음을 떼는 학생들에게는 단단한 이정표가 되고, 현업에서 고군분투하는 개발자들에게는 자신의 지식을 재정비하고 한 단계 도약할 수 있는 디딤돌이 되고자 합니다. 

 

 

 

 

 

실행 컨텍스트(Execution Context)와 변수의 생명주기(Hoisting/TDZ)

---

우리가 여러 IDE에 작성한 자바스크립트 코드는 브라우저나 Node.js 환경에서 어떻게 인식되고 실행될까요? 단순히 코드가 위에서 아래로 왼쪽에서 오른쪽으로 한 줄씩 읽힌다고 생각했다면, 자바스크립트의 수많은 '기이한 현상(선언 전에 변수를 호출하는 호이스팅)'을 절대 이해할 수 없습니다.

 

 

실행 컨텍스트(Execution Context)란 무엇인가?

📄 실행 컨텍스트란?

우리가 맛있는 음식을 만들기 위해서 요리한다고 가정해 봅니다. 요리를 하려면 레시피(코드)만 있어서는 요리를 할 수 없습니다. 요리를 위한 도구와 음식 재료들이 준비되어야 하고, 요리를 할 수 있는 공간이 필요합니다. 여기서 공간을 자바스크립트에서는 실행 컨텍스트라고 합니다. 자바스크립트 코드가 실행되기 위해 필요한 사방의 모든 정보(변수, 함수 선언, 스코프, this 등)를 담고 있는 환경이자 객체.

 

 

실행 컨텍스트의 3가지 종류

자바스크립트 엔진은 코드를 한 줄 한줄 읽어 내려가면서 실행 컨텍스트를 영역별로 생성합니다. 해당 영역은 '전역 컨텍스트(Global Execution Context)', '함수 컨텍스트(Function Execution Context)', 'Eval 함수 컨텍스트(보안 및 성능 문제로 거의 사용 안 함)' 3가지 종류로 구성되어 있습니다.

 

백문이 불여일견이죠. 우리가 작성하는 코드에서 각각의 컨텍스트가 어떻게 생성되고 구획되는지 확인해 봅시다.

 

소스 확인

// ===================================================
// 1. 전역 실행 컨텍스트 (Global Execution Context)
// 함수 바깥에 있는 해당 공간 자체가 '전역 컨텍스트' 영역입니다.
// 프로그램이 시작되자마자 단 하나만 생성되며, window(브라우저) 또는 global(Node.js) 객체를 만든다.
// ===================================================
const globalSubject = "자바스크립트 실행 컨텍스트";

console.log("전역 컨텍스트 실행 중 :", globalSubject);

// ===================================================
// 2. 함수 실행 컨텍스트 (Function Execution Context)
// 함수가 '선언' 될 때가 아니라, 실제 '호출(Execution)'될 때마다 각각의 
// 독립적인 함수 컨텍스트가 새롭게 생성된다.
// ===================================================
function printSubject(subject){
    // printSubject 함수 컨텍스트 영역 시작으로 전역 변수와 격리된 지역 매개변수(subject)와 
    // 지역 변수(status)를 가진다.
    const status = "진행!";
    console.log(`${subject} 현재 ${status}`);
}
// 해당 함수를 호출할 때마다 콜 스택에 새로운 방이 만들어진다.
printSubject("실행 컨텍스트 공부"); // printSubject 함수 컨텍스트 생성

// ===================================================
// 3. Eval 함수 실행 컨텍스트 (Eval Execution Context)
// 문자로 된 자바스크립트 코드를 동적으로 실행할 때 생성되는 독특한 컨텍스트입니다.
// 변수 스코프를 런타임에 오염시키고 성능을 떨어뜨려 사용하지 않습니다.
// ===================================================
const code = "var dynamic = '보안 위험!'; console.log(dynamic)";
// eval() 함수가 실행되는 순간, 일반 함수와는 다른 별도의 Eval 컨텍스트가 만들어진다.
eval(code);

 

위 소스를 통해서 우리가 짚고 넘어가야 할 핵심 내용이 3가지 존재합니다. 확인해 보죠.

 

1. 선언과 실행의 타이밍 분리

 

위 소스에서 function printSubject()를 작성한 순간에는 함수 컨텍스트가 만들어지지 않습니다. 엔진은 그저 전역 컨텍스트 내역에 "printSubject 라는 함수가 존재한다." 라고 이름만 적어둔 셈이죠. 실제 함수 컨텍스트가 생성되는 시점은 맨 아래에서 printSubject("실행 컨텍스트 공부")라고 괄호를 붙여 호출하는 순간입니다.

 

2. 독립된 메모리 공간 (함수 컨텍스트의 특징)

 

printSubject 내부의 status 변수는 함수 컨텍스트가 켜질 때 태어났다가, 함수가 종료되면(컨텍스트가 콜 스택에서 사라지면) 함께 메모리에서 완전히 소멸합니다. 전역 컨텍스트에 있는 globalSubject 변수는 프로그램이 꺼질 때까지 계속 메모리에 남아있습니다. 이것이 전역 변수를 남발하면 안 되는 이유입니다.

 

3. 왜 Eval 컨텍스트는 쓰면 안 될까?

 

eval() 은 문자열을 코드로 바꿉니다. 자바스크립트 엔진은 코드를 실행하기 전에 미리 컴파일을 해두는데, eval을 쓰면 중간에 어떤 코드가 튀어나올지 알 수 없어 엔진의 최적화 작업을 전부 망가뜨릴 수 있습니다. 더불어 악성 스크립트가 주입될 수 있는 치명적인 보안 구멍이 될 수 있습니다.

 

 

콜 스택(Call Stack)과 컨텍스트의 순환

자바스크립트는 '싱글 스레드' 언어입니다. 한 번에 하나의 일만 처리할 수 있습니다. 그래서 여러 컨텍스트가 생성될 때, 이를 관리하기 위해 콜 스택(Call Stack)이라는 구조를 사용합니다. (Stack은 밑이 막힌 항아리라고 생각하고 먼저 들어간 게 나중에 나오는 구조라고 생각하면 됩니다.)

 

간단한 소스를 보면서 콜 스택 순서에 대해서 확인해 봅시다.

 

소스 확인

// (1) 전역 코드 시작
let topGlobal = "Top Global";

function myMethod(){
    // (3) myMethod 함수 실행

    function myInnerMethod(){
        // (5) myInnerMethod() 실행
    }
    myInnerMethod();    // (4) myInnerMethod() 호출
}
myMethod(); // (2) myMethod 호출

 

위 소스를 통해 엔진의 내부 움직임을 살펴보겠습니다.

 

코드가 실행되자마자 항아리 맨 밑바닥에 전역 컨텍스트인 topGlobal이 깔립니다. myMethod() 호출문을 만나면, 엔진은 하던 일을 멈추고 myMethod 함수 컨텍스트를 생성해 전역 컨텍스트 위에 얹습니다. myMethod 안에서 myInnerMethod() 호출문을 만나면 또 그위에 myInnerMethod 함수 컨텍스트를 얹습니다 (현재 실행 중인 컨텍스트는 항아리 입장에서 보면은 항상 맨 위에 올려져 있는 것이죠). myInnerMethod 함수가 끝나면 스택에서 myInnerMethod가 팝(Pop)되어 사라집니다. 이어서 myMethod 함수가 끝나면 myMethod가 사라지고, 마지막으로 전역 코드까지 끝나면 콜 스택은 완전히 비워지게 됩니다.

 

myInnerMethod() myMethod() topGlobal

myMethod() topGlobal

topGlobal

 

 

 

 

변수의 생명주기(Variable Lifecycle)란 무엇인가?

실행 컨텍스트가 '공간'이라면, 그 안을 채우는 변수들은 저마다 태어나고, 쓰이고, 사라지는 생명주기(Lifecycle)를 가집니다. 많은 개발자가 변수를 그저 'let a = 1;'처럼 한 줄로 인식하지만, 자바스크립트 엔진 내부에서는 변수가 생성될 때 명확히 3가지 단계를 거칩니다. 

 

🏃‍♂️ 변수 생성의 3단계 프로세스

1. 선언 단계 (Declaration Phase)
변수의 이름을 실행 컨텍스트의 메모리 관리 대장(환경 레코드)에 등록하는 단계입니다. "앞으로 이런 이름의 변수를 쓸 거야!"라고 엔진에게 알리는 단계입니다.

2. 초기화 단계 (Initialization Phase)
등록된 변수를 위해 메모리 공간을 확보하고, 기본값인 'undefined'를 채워 넣는 단계입니다. 해당 단계가 지나야 비로소 변수를 호출했을 때 에러가 나지 않습니다.

3. 할당 단계 (Assignment Phase)
'undefined'로 채워져 있던 메모리 공간에 개발자가 의도한 실제 값(예: a = 1;)을 덮어씌우는 단계입니다.

 

 

var, let, const

특성	var	let	const
스코프(Scope)	함수 레벨 스코프(Function)	블록 레벨 스코프(Block)	블록 레벨 스코프(Block)
값 재할당	가능	가능	불가능 (상수)
변수 재선언	가능	불가능	불가능
호이스팅 동작	선언 + 초기화(undefined)	선언만 됨(TDZ 발생)	선언만 됨(TDZ 발생)

 

스코프는 변수가 태어나서 접근할 수 있는 활동 영역입니다. 

 

① var : 함수 레벨 스코프 (Function-level Scope)

var는 함수 레벨 스코프로 전역으로 설정할 수 있습니다. 지역으로도 설정할 수 있는데, 오직 함수의 블록('{}')만을 지역 스코프로 인정합니다. 즉, 함수 내부가 아니라면 if문, for문, while문 등 어떤 블록 안에서 선언하더라도 모두 전역 변수가 되어 버립니다.

 

소스 확인

// 전역 변수 선언
var globalVariable = "global";

if(true){
    // 블록 안에서 선언했지만, 전역 변수가 된다.
    var totalAmount = 5000;
}

console.log(globalVariable);
console.log(totalAmount);

// 반복문에서 선언한 i도 전역 변수가 된다.
for(var i = 0; i < 22; i++){
    console.log("반복 roop : ", i);
}

console.log("반복문에서 반복한 i : ", i);

function method(){
    // 함수 블록({})에서 선언한 변수는 지역변수가 된다.
    var a = 1;
}

console.log(a);     // Uncaught ReferenceError: a is not defined 발생

 

globalVariable 변수는 블록 밖에 선언되어 있기 때문에 전역 변수로 설정됩니다. 조건문 안에서 작성된 totalAmount도 var로 선언되었기 때문에 전역 변수가 됩니다. 반복문도 마찬가지로 var로 선언된 카운터 변수 i가 루프가 끝난 후에도 전역으로 살아남아 있습니다. 그렇기 때문에 다른 로직의 변수를 오염시키는 치명적인 버그를 유발할 수 있습니다.

유일하게 함수 method에서 선언한 'var a = 1;'은 지역변수로 설정되어 아래 a를 출력 시, ReferencesError( Uncaught ReferencesError: a is not defined)가 발생합니다. 

 

 

② let, const : 블록 레벨 스코프 (Block-level Scope)

let, const는 블록 레벨 스코프로 지역으로 설정할 수 있습니다. 함수는 물론, 모든 코드 블록({})을 지역 스코프로 인정합니다. 블록 내부에서 선언된 변수는 오직 그 블록 내부에서만 라이프 사이크를 가집니다. 블록을 벗어나는 순간 메모리에서 소멸합니다. 

 

소스 확인

if(true){
    let internalValue = "def";
    const internalNumber = 100;
    console.log(internalValue);
}
// 블록 외부에서는 내부 변수에 절대 접근 불가능 (캡슐화 및 보호)
console.log(internalNumber);    // ReferencesError: internalNumber is not defined

 

internalValue와 internalNumber는 블록 내에 선언되어, 해당 블록 내에서만 사용할 수 있는 지역 변수로 설정됩니다. 블록 밖에서 블록 내에 선언된 두 변수 중, internalNumber를 출력하면 ReferencesError가 발생합니다.

 

 

변수 재선언과 재할당

코드가 대규모화될수록 변수의 값이 중간에 의도치 않게 바뀌거나, 이미 존재하난 변수 이름을 실수로 다시 선언하는 일이 없어야 합니다.

 

소스 확인

// ① var : 재선언 가능, 재할당 가능 (무법지대)
var productId = "A-20260518001";
var productId = "B-20260519003";	// 경고 없이 재선언 가능(기존 값 덮어씀)
productId = "A-20260514012";		// 재할당 가능

‼️ 수만 줄의 협업 코드에서 누군가 내가 만든 변수명을 모르고 var로 또 선언했다면, 
기존 데이터가 유실되는 문제가 발생됩니다.

// ② let : 재선언 불가능, 재할당 가능 (유연한 변수)
let age = 20;
// let age = 24;	// SyntaxError: Identified 'age' has already been declared
age = 30;			// 값의 변경(재할당)은 가능

// ③ const : 재선언 불가능, 재할당 불가능 (안전한 상수)
const url = "https://example.com";
url = "https://junesker.tistory.com";	// TypeError: Assignment to constant variable

‼️ const는 'Constant(상수)'의 약자로, 한 번 선언하면 절대 변하지 않는 값을 담을 때 사용합니다.
따라서 선언과 동시에 값을 무조건 할당(초기화)해야 합니다.

 

const와 참조 타입(Object, Array)

"const는 값을 재할당 할 수 없다."는 말에는 객체로 보면 함정이 있습니다. 원시 값(숫자, 문자열 등)은 바꿀 수 없지만, 객체(Object)나 배열(Array)이 할당된 경우 내부의 프로퍼티나 요소는 수정할 수 있습니다. 

 

소스 확인

const student = {
	name : "kildong",
    age : 20
}

// ⭕ 객체 내부의 프로퍼티를 바꾸는 것은 가능
student.name = "Kilsoon";
student.hobby = "sports";

console.log(student.name);
console.log(student.hobby);

// ❌ student라는 변수 자체에 새로운 객체를 재할당 하는 것은 불가능
// student = {name : "yeong-he"};

 

const가 보장하는 것은 변수에 담긴 '메모리 주소값(참조값)'이 변하지 않는다는 것입니다. 주소지가 가리키는 실제 힙(Heap) 메모리 내부의 메모리 공간까지 잠그는 것은 아니기 때문입니다. 

 

⚠️ var vs let / const 생명주기의 결정적 차이

변수 생성의 3단계(선언 > 초기화 > 할당)가 어떻게 결합하느냐에 따라 자바스크립트의 호이스팅과 TDZ(Temporal Dead Zone) 현상이 발생합니다. 

 

 

 

 

 

호이스팅(Hoisting)과 TDZ(Temporal Dead Zone)

---

 

 

호이스팅(Hoisting)이란 무엇인가?

많은 책이나 강의에서 호이스팅에 대해서 설명하는 걸 보면 "변수와 함수 선언문이 코드의 최상단으로 끌어올려지는 현상"이라고 설명합니다. 하지만, 실제로 코드가 물리적으로 위로 이동하는 것은 아닙니다. 

실제는 자바스크립트 엔진은 코드를 실행하기 전 '컴파일 단계'를 거칩니다. 해당 단계에서 엔진은 코드를 쭉 훑으며 var, let, const, function과 같은 선언문들을 찾아내 실행 컨텍스트의 환경 레코드(Environment Record)라는 메모리 내역에 먼저 등록합니다. 

선언문들이 메모리에 이미 등록되어 있다 보니, 실제 코드가 실행될 때 선언문보다 위에서 변수나 함수를 호출해도 에러 없이 접근이 가능해지는 것입니다. 해당 현상을 마치 위로 끌어올려진 것 같다고 하여 '호이스팅'이라고 부릅니다.

 

 

변수 호이스팅: var / let, const

변수가 호이스팅 될 때, 어떤 키워드로 선언했느냐에 따라 엔진 내부에서 완전히 다르게 동작합니다. 여기서 함께 기억하고 봐야 할 개념은 변수의 생명주기 3단계(선언, 초기화, 할당)입니다. 

 

① var 변수의 호이스팅: 선언과 초기화가 동시에

 

소스확인

console.log(str);		// 에러가 나지 않고 undefined가 출력됩니다.

var str = "junesker";	// 실제 값이 할당되는 선언문

console.log(str);		// 할당이 완료되었으므로 "junesker" 출력

 

var 키워드로 변수를 선언하면, 자바스크립트 엔진은 컴파일 단계에서 '선언'과 '초기화'를 동시에 진행합니다. 즉, 내역에 이름을 적자마자 메모리 공간을 확보하고 기본값인 undefined를 채워 넣습니다.

 

② let, const 변수의 호이스팅: 선언만 먼저, 초기화는 보류

 

소스 확인

console.log(data);		// ❌ ReferencesError 발생
let data = "value";

 

많은 개발자가 let과 const는 호이스팅이 일어나지 않는다고 오해합니다. 하지만 let과 const 역시 분명히 호이스팅은 가능합니다. 차이점은 컴파일 단계에서 '선언'만 이루어지고, undefined를 채워 넣는 '초기화'는 절대 미리 하지 않는다는 점입니다. 초기화 단계는 코드가 실행되다가 실제 let이나 const 변수가 적힌 코드 줄에 도달했을 때야 비로소 수행합니다. 

 

위 소스를 보면, let과 const로 선언된 변수도 호이스팅 자체는 일어납니다. 자바스크립트 엔진이 해당 변수의 존재는 알고 있습니다. 하지만 초기화 단계가 실제 코드 줄에 도달하기 전까지 보류되므로, 그 사이의 사각지대인 TDZ(Temporal Dead Zone) 영역에서 변수를 호출하면 "초기화 전에 접근할 수 없다"는 명확한 레퍼런스 에러를 던져 개발자의 실수를 원천 차단할 수 있습니다. 

 

 

TDZ(Temporal Dead Zone, 일시적 사각지대)란 무엇인가?

let과 const가 가진 독특한 생명주기 때문에 TDZ라는 개념이 탄생합니다. 스코프의 시작 지점(코드의 최상단)부터 변수의 실제 선언문이 있는 위치까지는 변수가 내역에 이름만 있을 뿐, 메모리 방(초기화)이 없는 상태입니다. 이 사각지대 구간에서 변수에 접근하려고 하면 자바스크립트 엔진은 참조 에러(ReferencesError)를 발생시켜 접근을 원천 차단합니다. 우리는 이 구간을 TDZ라고 부릅니다.

 

소스 확인

// -- TDZ 구간 시작
// 엔진 내부 내역에는 'student'라는 이름이 등록은 되어 있음 (호이스팅 O)
// 하지만 메모리 공간(초기화)이 아직 없음
console.log(student);	// ❌ ReferencesError: Cannot access student' before initialization
// 초기화하기 전에는 변수에 접근할 수 없다는 에러를 던집니다.

// -- TDZ 구간 끝

// 해당 줄에 도달해서야 비로소 메모리 공간 확보(초기화 + 할당)
let student = "홍길동";
console.log(student);	// "홍길동"이 출력됩니다.

 

 

 

 

 

실무에서 지켜야 할 변수 선언 가이드라인

---

바닐라 자바스크립트 개발에서 var의 채용률은 0%에 수렴해야 합니다. 실무 및 대규모 아키텍처 설계 시 권장되는 규칙은 다음과 같습니다. 

 

1. 기본 설정은 항상 const로 시작

대부분의 변수는 한 번 선언된 후 재할당될 일이 생각보다 많지 않습니다. 코드를 읽는 다른 개발자에게 "이 값은 안전한 상수입니다."라는 신뢰를 주기 위해 const를 디폴트로 사용합니다.

 

2. 재할당이 명확히 필요한 순간에만 제한적으로 let을 사용

3. var는 완전히 레거시 코드를 분석할 때만 이해하고, 새로 작성하는 코드에는 절대 금지

 

 

실무에서 이 규칙을 '강제'로 지키게 만드는 도구들

개발자들이 "지키면 좋고 안 지키면 말고" 식으로 타협하지 못하도록, 실무에서는 자동 코드 검사 도구(

Linter)를 통해 이 가이드라인을 강제합니다.

 

① ESLint의 'no-var' 규칙

기업용 프로젝트를 세팅할 때 필수적으로 사용하는 ESLint에는 'no-var' 라는 기본 규칙이 있습니다. 코드에 var 라는 글자가 하나라도 들어가면 소스 코드가 저장되거나 Git에 업로드(Commit)되는 것 자체가 차단됩니다.

 

② ESLint의 'prefer-const' 규칙

이 규칙은 "재할당되지 않는 변수는 무조건 const로 선언하라"고 강제하는 규칙입니다. 개발자가 처음에는 값이 변할 줄 알고 let a = 10; 이라고 적었으나, 밑에는 a를 재할당하는 코드가 없다면 에러(또는 경고)를 띄우며 const로 바꾸라고 강요합니다. 

 

 

실무 개발자들이 const를 디폴트로 쓰는 진짜 이유

단순히 "에러를 안내려고" 쓰는게 아닙니다. 대규모 협업과 유지보수 관점에서 이득이 있기 때문입니다.

 

① 읽기 좋은 코드 (가독성과 심리적 안정감)

수천 줄의 코드를 읽어 내려갈 때, 어떤 변수가 const로 선언되어 있다면 개발자는 "아? 이 변수에 담긴 값이나 객체의 주소는 이 파일 끝날 때까지 절대 변하지 않는구나?"라는 확신을 하고 코드를 읽을 수 있습니다. 반면 let을 보면 "어딘가에서 이 값이 바뀌겠구나?"하고 스크롤을 내려 그 변수가 재할당되는 지점을 찾아야 합니다. 즉, const는 동료 개발자의 생각의 비용을 획기적으로 줄일 수 있습니다.

 

② 부수 효과(Side Effect) 의 원천 차단

함수형 프로그래밍 패러다임이 주류가 된 현 개발에서는 '불변성(Immutability)'을 유지하는 것이 버그를 줄이는 최고의 방법입니다. 예측하지 못한 순간에 변수 값이 휙휙 바뀌면 디버깅이 불가능에 가까워집니다. const는 개발자의 실수로 인한 재할당을 문법 레벨에서 막아주기 때문에 프로그램의 안정성을 완벽하게 보장할 수 있습니다.

 

 

 

 

 

@Junesker

---