자바스크립트 기초 쌓기 시리즈 - 2: 렉시컬 스코프와 스코프 체인

 

기초 시리즈 첫 번째에서 '실행 컨텍스트'의 기본 개념과, 변수들이 생성되고 쓰이는 '생명주기'를 확인해 보았습니다. 코드가 실행되기 전에 이미 엔진이 메모리 공간을 확보하고 준비를 마친다는 사실은, 그동안 자바스크립트를 단순히 '위에서 아래로 한 줄씩 읽는' 형태로만 알고 있던 많은 이들에게 새로운 사실과도 같은 개념이었을 겁니다. 

그렇게 첫번째 시리즈를 공부하면 한 가지 본질적인 의문이 꼬리를 뭅니다. 엔진이 실행 컨텍스트라는 독립된 공간을 만들고 변수들을 관리하는 건 알겠는데, 만약 함수 안에 또 다른 함수가 겹겹이 중첩되어 있다면 엔진은 어떤 규칙으로 변수를 찾아 나설까요? 현재 컨텍스트(변수가 저장된 공간)에 내가 찾는 변수가 없다면 엔진은 그대로 작동을 멈추고 에러를 뿜어낼지 아니면 현재 컨텍스트에서 다른 컨텍스트 또는 상위 컨텍스트로 찾기 시작할까요?

자바스크립트를 다루다보면 "분명히 해당 변수를 선언한 기억이 없는데 어디선가 값을 기가 막히게 물어와 출력을 해주는 기현상", "당연히 접근할 수 있을 줄 알았던 변수인데 ReferenceError를 뿜어내며 프로그램이 멈춰버리는 현상" 등을 한 번쯤 겪었을 겁니다. 웹 개발자를 준비하는 학생들부터 주니어 개발자들까지, 수많은 버그와 기술 면접의 늪에서 가장 많이 좌절하는 지점이 바로 이 '변수 참조의 규칙'입니다.

여기서의 연결고리가 바로 '렉시컬 스코프(Lexical Scope)'와 '스코프 체인(Scope Chain)'입니다.

이번 장에서는 자바스크립트라는 언어가 변수의 활동 영역(Scope)을 결정하는 독특하고 고집스러운 설계 철학을 알아보고, 엔진 내부의 매모리 내역인 '외부 렉시컬 환경 참조(Outer Lexical Environment Reference)'가 어떻게 이 방식과 저 방식을 쇠사슬처럼 엮어내는지 그리고 런타임 이면의 실체를 조금 자세하게 들여다보려 합니다. 단순히 변수를 '위로 찾아 올라간다.'는 모호한 개념이 아니라, 자바스크립트 엔진의 시선으로 스코프를 바로 볼 수 있는 경험을 위해서 말이죠.

 

 

 

 

 

스코프(Scope)의 직관적 개념

 

 

러시아의 전통 인형인 '마트료시카'입니다. 큰 인형을 열면 그 안에 조금 더 작은 인형이 있고 또 열면 더 작은 인형이 줄줄이 나오는 구조입니다. 자바스크립트의 스코프(Scope)가 이 마트료시카 인형과 같은 구조입니다. 가장 바깥에 있는 거대한 인형이 '전역 스코프(Global Scope)'이고 그 인형을 열고 들어가면 나타나는 작은 인형들이 각각의 '함수 스코프(Function Scope)' 혹은 '블록 스코프(Block Scope)'가 됩니다. 여기서 안쪽에 있는 작은 인형은 바깥쪽에 있는 큰 인형의 공간을 훤히 들여다 볼 수 있지만, 바깥쪽의 큰 인형은 안쪽 인형 내부에 무엇이 들어있는지 절대 들여다볼 수 없습니다. 해당 규칙이 자바스크립트를 지배하는 변수 접근의 대원칙입니다.

 

 

 

 

 

렉시컬 스코프(Lexical Scope)

 

렉시컬(Lexical)이란 단어는 '어휘적'이라는 뜻을 가지는데 즉, "소스 코드가 작성된 문맥과 구조"를 의미합니다. 쉽게 말해서 렉시컬 스코프는 "함수가 어디서 호출 되었는가가 아니라, 소스 코드 상 어디서 선언되었는지에 따라 상위 스코프가 결정되는 규칙"을 뜻합니다. 이것은 자바스크립트 엔진의 구동 메커니즘인 '평가 단계'와 직결되어 있습니다. 엔진은 런타임에 코드를 한 줄씩 실행하기에 앞서, 소스 코드를 쭉 훑으며 파싱(Parsing)하는 단계를 거칩니다. 이때 함수 선언문이 배치된 물리적인 괄호 '{}' 구조를 보고 "이 함수의 상위 영역은 여기구나"라고 스코프 관계를 확정 지어 메모리에 기록합니다. 호출 타이밍 언제든, 동적으로 변하지 않는 정적(Static)인 규칙입니다.

 

소스 확인

const userName = "global hongkd";

// printName 함수는 전역에서 선언됨
function printName(){
    console.log(userName);
}

function outerFunction(){
    const userName = "local hongkildong";
    printName();    // 여기서 printName 함수를 호출함
}

outerFunction();	// userName의 값은?

 

많은 사람들이 outerFunction() 내부에서 printName()이 호출되는 것을 보고, printName 내부의 userName 지역 변수인 "local hongkildong"을 가져올 것이라 생각합니다. 호출된 위치의 주변 환경을 본 셈이죠. 하지만, 자바스크립트는 렉시컬 스코프를 따릅니다.

 

결과

1. printName() 함수가 선언된 물리적 위치는 바깥쪽 전역(Global)입니다.

2. printName() 함수의 상위 영역은 코드가 평가되는 시점에 이미 전역 스코프로 설정됩니다.

3. outerFunction() 안에서 호출되어도, printName() 함수는 자기가 선언된 영역인 전역 스코프의 변수 userName만을 바라봅니다.

4. 결론적으로 화면에는 "global hongkd"이 출력됩니다.

 

 

 

 

 

메모리 단의 연결고리인 스코프 체인(Scope Chain)

 

함수가 실행될 때 상위 스코프를 찾아 올라가는 이 유기적인 지도를 '스코프 체인'이라고 합니다. 자바스크립트 표준 명세(ECMAScript Specification)를 기반으로, 실행 컨텍스트의 메모리 단에서 어떻게 Linked List처럼 엮이는지 알아봅시다.

 

LexicalEnvironment & Outer Reference

 

실행 컨텍스트는 코드가 실행되기 위한 공간이라고 했습니다. 해당 공간에는 메모리를 관리하는 두 개의 핵심 내역이 들어있습니다.

 

1. EnvironmentRecord(환경 레코드) : 현재 공간에 선언된 변수와 함수 이름이 적힌 내역

2. Outer Lexical Environment Reference(외부 렉시컬 환경 참조) : 자신을 감싸고 있는 '상위 공간'의 주소록

 

코드가 실행되다가 현재 공간의 환경 레코드에 없는 변수를 만나면, 자바스크립트 엔진은 당황하지 않고 외부 렉시컬 환경 참조가 가리키는 상위 공간의 메모리 주소로 이동합니다. 그렇다면 환경 레코드에서도 변수를 찾지 못하면 어떻게 될까? 해당 공간의 Outer 참조를 타고 더 위에 있는 상위 공간으로 이동합니다.

이 형태가 쇠사슬처럼 연결되어 있다고 해서 스코프 체인이라고 하며, 이 체인의 종착지인 전역 렉시컬 환경(Global Lexical Environment)의 Outer 참조는 null을 가리키며, 여기까지 와서도 변수를 찾지 못하면 비로소 ReferenceError가 발생합니다.

 

소스 확인

const money = 1000;     // 전역 변수

// (1) 전역 컨텍스트 생성: Global LexicalEnvironment가 메모리에 확보(Outer: null)

function bank(){
    const money = 50000;    // bank 지역 변수

    // (2) bank 함수 선언: 평가 단계에서 bank의 상위 스코프는 '전역'으로 설정

    function withdraw(){
        console.log("실행 point(withdraw) : ", money);
    }
    return withdraw;
}

const myWithdraw = bank();      // bank가 실행되고 withdraw 함수를 리턴
myWithdraw();                   // bank 함수가 끝난 뒤, 전역에서 withdraw를 독립적으로 실행

 

결과

1. 소스가 읽히면서 전역 실행 컨텍스트가 생성되고, 해당 컨텍스트의 내부 환경 레코드에 'money = 1000'과 bank라는 함수 이름이 들어갑니다. 전역은 최상위 공간이므로 더 이상 위로 갈 곳이 없어 '외부 렉시컬 환경 참조'는 null로 묶입니다. 

2. bank() 함수가 호출됩니다. Stack으로 보면 전역 컨텍스트(money, bank()) 위에 bank 함수가 쌓이는 구조입니다. bank 컨텍스트의 내부 환경 레코드에는 'money = 50000'과 withdraw 함수 이름이 들어갑니다. 이때, bank 함수는 소스 코드 상 전역으로 설정된 함수입니다. 그래서 bank 컨텍스트에 있는 외부 렉시컬 환경 참조는 전역 컨텍스트를 향해 묶입니다.

 

[전역 렉시컬 환경] (메모리 주소: 0x1111)
 - 환경 레코드 : money = 1000, bank (함수 객체)
 - 외부 참조(Outer) : null    << (전역 위에는 아무것도 없기 때문에 null)

　▲
　│  (연결)

[bank 렉시컬 환경] (메모리 주소: 0x2222)
 - 환경 레코드 : money = 50000, withdraw (함수 객체)
 - 외부 참조(Outer) : 0x1111 (전역 주소)    << (null이 아니라 전역 방을 가리킴)

 

3. bank() 함수 내부에서 withdraw() 함수가 선언됩니다. withdraw 함수는 bank 함수 내부(지역)에서 선언되었고 이 물리적인 위치 때문에, withdraw 함수는 생성되자마자 상위 컨텍스트는 bank가 됩니다. 즉 외부 렉시컬 환경 참조는 bank 컨텍스트에 묶입니다.

4. bank() 함수가 종료됩니다. 그렇기 때문에 Stack에서는 bank() 함수가 사라집니다. 그렇지만 bank 함수가 리턴한 withdraw 함수는 myWithdraw라는 이름의 전역 컨텍스트에 남습니다. 그리고 myWithdraw는 외부 렉시컬 환경 참조인 bank 컨텍스트의 연결고리는 존재합니다.

5. myWithdraw() 함수가 호출됩니다. 전역 컨텍스트에 내부 환경 레코드에 들어있는 myWithdraw() 함수에 의해 withdraw 함수가 실행됩니다. withdraw에서 출력하고자 하는 money를 출력하려고 봤더니 내부 환경 레코드에 money라는 변수가 존재하지 않습니다. 그래서 외부 렉시컬 환경 참조에 의해 bank 함수는 이미 실행 종료되어 사라졌지만 메모리에 저장되어 있는 bank 함수 내의 money 변수를 찾아 출력합니다. (해당 현상이 향후 배우게 될 클로저의 핵심 내용이 됩니다.)

 

[전역 렉시컬 환경] (메모리 주소: 0x1111)
 - 환경 레코드 : money = 1000, bank (함수 객체)
 - 외부 참조(Outer) : null    << (전역 위에는 아무것도 없기 때문에 null)

　▲
　│  (연결)

[bank 렉시컬 환경] (메모리 주소: 0x2222)
 - 환경 레코드 : money = 50000, withdraw (함수 객체)
 - 외부 참조(Outer) : 0x1111 (전역 주소)    << (null이 아니라 전역 방을 가리킴)

　▲
　│  (연결)

[withdraw 렉시컬 환경] (메모리 주소: 0x3333)
 - 환경 레코드 : 비어있음
 - 외부 참조 (Outer) : 0x2222 (bank 주소)    << (bank에서 선언되었기 때문에)

 

 

 

 

 

현업에서는 왜 전역 변수를 권장하지 않을까?

 

실무에서는 시니어들이 주니어들이 작성한 코드를 리뷰할 때 가장 많이 하는 지적 중 하나가 '전역 변수 최소화' 일 겁니다. 단순히 지저분하기 때문에 가 아니라, 전역 변수 남발이 만드는 많은 이슈들 때문일 것입니다.

 

1. 스코프 체인 종착지 검색으로 인한 성능 저하
   - 엔진이 변수를 찾을 때 현재 지역 스코프부터 체인을 타고 맨 위까지 이동합니다. 전역 변수를 빈번하게 호출하면 매번 스코프 체인의 최상단까지 메모리를 거슬러 올라가야 하므로, 체인이 깊을수록 아주 미세하지만 불필요한 탐색 비용이 발생합니다.
2. 네임스페이스 오염
   - 대규모 협업 프로젝트에서는 수십 명의 개발자가 만든 수백 개의 모듈이 합쳐집니다. 전역 변수를 쓰면 내가 만든 변수를 다른 팀원이 다른 파일에서 덮어쓰거나 충돌이 나면서 예측 불가능한 런타임 버그를 만들어냅니다.
3. 가비지 컬렉션(GC) 대상 제외로 인한 메모리 누수
   - 함수 스코프 내부의 변수들은 함수 실행이 끝나 컨텍스트가 소멸하면 메모리 청소부인 가비지 컬렉터가 수거해 갑니다. 하지만 전역 변수는 애플리케이션이 완전히 종료될 때(웹 페이지를 닫을 때)까지 메모리 공간을 계속 차지하고 영원히 살아남습니다. 전역 변수가 많아질수록 브라우저가 무거워지고 성능이 저하되는 주원인이 됩니다.