본문 바로가기
Development

[21.01.06] YDKJSY - Around the Global Scope

by igy95 2024. 1. 7.

Why Global Scope?

여러 개의 JS 파일들을 하나의 실행 컨텍스트 안에서 협력하게 하는 방법은 크게 세 가지가 있다.

  • ES 모듈을 사용할 때, 각각의 모듈은 접근이 필요한 모듈이 필요할 때 import 를 할 수 있다. 그래서 서로 다른 파일들은 이 방법을 통해 따로 공유하는 외부 스코프 없이도 JS 환경 안에서 협력이 가능하다.

  • 빌드하는 과정에서 번들러를 사용하면, 모든 파일들은 JS 엔진이나 브라우저로 전송되기 전에 하나의 파일로 병합된다.

  • 번들 유무나 파일들이 개별적으로 브라우저에 연결되는 것과 상관없이, 이러한 파일들을 둘러싼 특정 스코프(e.g. Wrapper function, UMD) 가 존재하지 않는다면 전역 스코프 가 파일들을 서로 협력하게 할 유일한 방법이다.

전역 범위에서 존재하는 변수는 버그 발생을 초래할 수 있기 때문에 무분별한 선언은 경계해야 하지만, 그럼에도 불구하고 하위 스코프들을 서로 연결시켜줄 수 있는 매개체임은 부정할 수 없다.

Where Exactly is this Global Scope?

대부분 한 파일의 가장 바깥 스코프를 전역 범위로 생각하기 쉽지만, 전역 범위는 JS 환경에 따라 천차만별이라고 한다.

Browser - Window

어떠한 파일의 가장 바깥 영역에서 변수나 함수를 선언하게 되면, 선언된 것들은 웹 안에서 global object 인 window의 프로퍼티로도 선언 된다. 하지만 이 영역에서 변수를 선언할 때 var가 아닌 let, const로 선언하게 되면 shadowing이 일어나게 되는데, 해당 키워드로 선언된 변수의 값이 window.properties 의 참조를 막게 된다. 이러한 혼동을 막기 위해서는 전역의 변수는 var로 선언하는 것이 좋다.

Developer Tools Console/REPL

개발자 도구는 JS 환경을 완벽히 지원하도록 설계된 것은 아니다. 어떠한 방면에서는 JS에서 적용할 수 있는 특정 오류 조건들이 개발자 도구에서는 표시되지 않을 수 있다. 이 관점에서 차이점을 몇 개 짚어보자면,

  • 전역 범위
  • 호이스팅
  • 최상단 스코프에서 let, const 선언

console, REPL 을 사용하다보면, 최상단 스코프에 입력된 선언문들이 자칫 실제 전역 범위에서 동작한다고 생각할 수 있지만 그것은 정확한 사실이 아니다. 그러한 툴들은 단지 개발자의 편리함을 우선시 하기에 전역 범위의 처리를 모방한 것일 뿐, 동일하지는 않다.

여기서 중요한 점은 개발자 도구는 다양한 개발자 활동에 편리하고 유용하도록 최적화되었지만, 실제 JS 프로그램 컨텍스트의 동작을 결정하거나 검증하기에는 적합한 환경이 아니라는 점이다.

ES Modules (ESM)

하나의 모듈 파일 안에서 선언된 변수와 함수들은 최상단에 위치하고 있다고 해도 전역 변수라고 할 수 없다. 모듈은 각 파일 안에서 자신만의 스코프를 가지기 때문이다.