렉시컬 스코프 v 렉시컬 환경

렉시컬 스코프라는 용어를 처음 접했을 때, 나는 이것을 별다른 의심 없이 ‘렉시컬 환경에 따른 스코프 체인’ 정도로 이해했다. 두 개념이 밀접하게 연결되어 있다는 인상 때문이었을 것이다. 그 결과, 모 회사의 면접에서 렉시컬 스코프를 설명해 보라는 질문을 받았을 때 스코프 체인에 대한 설명만을 늘어놓고 말았다.

면접이 끝난 뒤, 렉시컬 스코프와 스코프 체인은 다른 개념이라는 피드백을 들었다. 하지만 왜 다른지, 무엇이 다른지, 어떤 관점에서 구분해야 하는지는 명확히 설명할 수 없었다. 이후 _코어 자바스크립트_와 _YDKJSY_를 차례로 읽으며, 이 두 개념이 비슷해 보일 뿐 실제로는 서로 다른 층위의 개념이라는 사실을 비로소 이해하게 되었다.

렉시컬 스코프는 변수와 함수의 유효 범위가 소스 코드의 어느 위치에 선언되었는지에 따라 결정된다는 원칙을 의미한다. 코드가 작성된 위치에 따라 스코프의 관계가 정해지는 것이다. 다시 말해 함수가 어느 코드 블록 안에서 선언되었는지가 그 함수가 접근할 수 있는 식별자의 범위를 결정하며, 이 관계는 함수를 어디에서 호출했는지에 따라 바뀌지 않는다.

이러한 이유로 렉시컬 스코프는 흔히 컴파일 타임에 결정된다고 설명된다. 다만 자바스크립트의 실행 과정을 컴파일 타임과 런타임으로 딱 잘라 구분하기보다, 호출 당시의 실행 흐름이 아니라 소스 코드의 렉시컬 중첩 구조가 식별자를 탐색할 방향을 정한다고 이해하는 편이 정확하다.

반면 렉시컬 환경은 그 규칙에 따라 식별자를 실제 바인딩과 연결하고, 실행 중인 바인딩의 상태를 관리하는 명세상의 메커니즘이다. 현재 ECMAScript 명세에서 실행 컨텍스트의 LexicalEnvironment는 Environment Record를 가리킨다. Environment Record는 변수와 함수 선언, 매개변수 등의 바인딩을 관리한다. 함수 실행에 대응하는 Function Environment Record는 필요한 경우 this를 처리할 상태도 가지지만, 모든 Environment Record가 this 바인딩을 가지는 것은 아니다.

즉, 렉시컬 스코프가 “어디까지 접근할 수 있는가”를 정하는 규칙이라면, 렉시컬 환경은 “그 규칙에 따라 식별자를 어느 바인딩에서 찾고, 그 바인딩이 현재 어떤 상태인가”를 다루는 실행 시점의 구조다. 이 관점에서 렉시컬 환경은 렉시컬 스코프의 관계를 런타임에 구현하는 명세상의 장치라고 볼 수 있다.

함수가 호출되면 새로운 실행 컨텍스트가 활성화되고, 식별자를 찾는 데 사용할 환경이 연결된다. 다만 실행 컨텍스트와 Environment Record가 언제나 하나씩 짝을 이루는 것은 아니다. let과 const가 있는 블록이나 catch 절을 평가할 때도 새로운 Environment Record가 만들어질 수 있다. 각 Environment Record는 [[OuterEnv]]를 통해 바깥 Environment Record를 참조하며, 현재 환경에서 식별자를 찾지 못하면 이 참조를 따라 탐색한다. 이 식별자 탐색 경로를 흔히 스코프 체인이라고 부른다.

이러한 맥락에서 클로저도 함께 이해할 수 있다. 함수 객체가 만들어질 때 그 함수의 [[Environment]]에는 당시의 Environment Record가 기록된다. 바깥 함수의 실행 컨텍스트가 스택에서 제거된 뒤에도 반환된 함수에 계속 도달할 수 있다면, 그 함수는 자신이 만들어진 환경과의 연결을 통해 바깥 바인딩에 접근할 수 있다. 이는 “종료된 실행 컨텍스트가 그대로 살아남는 현상”이라기보다, 함수가 생성 당시의 환경과 연결되어 있는 구조에 가깝다.

정리하면 렉시컬 스코프는 소스 코드의 중첩 구조에 따라 정해지는 식별자 접근 규칙이고, 렉시컬 환경은 그 규칙에 따라 실행 중 바인딩을 만들고 탐색하기 위한 명세상의 메커니즘이다. 스코프 체인은 Environment Record의 외부 참조를 따라가는 탐색 경로이며, 클로저는 함수가 자신이 만들어진 환경과의 연결을 유지하기 때문에 성립한다.

비슷하게 들리는 말이지만 같은 층위의 개념은 아니다.