JavaScript 엔진이란 무엇입니까?

파일에 일련의 문자를 쓰고, 브라우저에서 해당 파일을 열고, 그것이 실제로 나타나는 것을 지켜본다는 점에서 웹용 코드를 작성하는 것은 때때로 약간 마법처럼 느껴집니다. 하지만 마법 뒤에 숨겨진 기술을 이해하면 프로그래머로서 기술을 더 잘 연마하는 데 도움이 될 수 있습니다.

이 기사에서는 브라우저를 구동하는 JavaScript 엔진의 복잡성을 파악하여 JavaScript 기반 웹 또는 모바일 스택의 뒤에서 무슨 일이 일어나고 있는지 알아볼 것입니다. JavaScript 엔진의 기능, 다양한 플랫폼에서 서로 다른 엔진을 사용하는 이유, 수년에 걸쳐 어떻게 발전해왔는지, 개발자로서 우리가 관심을 기울여야 하는 이유를 자세히 살펴보겠습니다.

먼저, 약간의 용어

'자바스크립트 엔진'은 흔히 가상머신의 일종으로 불립니다. '가상 머신'은 특정 컴퓨터 시스템의 소프트웨어 기반 에뮬레이션을 의미합니다. 가상 머신에는 다양한 유형이 있으며 실제 물리적 머신을 얼마나 정확하게 에뮬레이션하거나 대체할 수 있는지에 따라 분류됩니다.

예를 들어 '시스템 가상 머신'은 운영 체제가 실행될 수 있는 플랫폼의 완전한 에뮬레이션을 제공합니다. Mac 사용자는 Mac에서 Windows를 실행할 수 있는 시스템 가상 머신인 Parallels에 익숙할 것입니다.

반면 '프로세스 가상 머신'은 완전한 기능을 갖추지 못했으며 하나의 프로그램이나 프로세스를 실행할 수 있습니다. Wine은 Linux 시스템에서 Windows 애플리케이션을 실행할 수 있게 해주는 프로세스 가상 머신이지만 Linux 상자에서 전체 Windows OS를 제공하지는 않습니다.

자바스크립트 엔진은 자바스크립트 코드를 해석하고 실행하도록 특별히 설계된 일종의 프로세스 가상 머신입니다.

참고: 웹페이지를 레이아웃하여 브라우저를 구동하는 엔진과 코드를 해석하고 실행하는 하위 수준 JavaScript 엔진을 구별하는 것이 중요합니다. 브라우저 작동 방식에 대한 좋은 설명은 이 문서에서 찾을 수 있습니다.

그렇다면 JavaScript 엔진이란 정확히 무엇이며 어떤 역할을 합니까?
JavaScript 엔진의 기본 작업은 개발자가 작성한 JavaScript 코드를 브라우저에서 해석하거나 애플리케이션에 내장할 수 있는 빠르고 최적화된 코드로 변환하는 것입니다. 실제로 JavaScriptCore는 스스로를 "최적화 가상 머신"이라고 부릅니다.

보다 정확하게는 각 JavaScript 엔진은 JavaScript가 방언인 ECMAScript 버전을 구현합니다. ECMAScript가 발전함에 따라 JavaScript 엔진도 발전하고 있습니다. 다양한 엔진이 있는 이유는 각 엔진이 서로 다른 웹 브라우저, 헤드리스 브라우저 또는 Node.js와 같은 런타임에서 작동하도록 설계되었기 때문입니다.

아마도 웹 브라우저에 익숙할 것입니다. 그런데 헤드리스 브라우저가 무엇인가요? 그래픽 사용자 인터페이스가 없는 웹 브라우저입니다. 웹 제품에 대해 자동화된 테스트를 실행하는 데 유용합니다. Chrome 버전 59 및 Firefox 버전 56부터 일반 브라우저를 이러한 방식으로, 특히 테스트용으로 사용할 수 있습니다. 그리고 Node.js는 여기에 적합합니까? Node.js는 서버 측에서 JavaScript를 사용할 수 있게 해주는 비동기식 이벤트 중심 프레임워크입니다. JavaScript 기반 도구이므로 JavaScript 엔진으로 구동됩니다.

위의 가상 머신 정의에 따르면 JavaScript 엔진의 유일한 목적은 JavaScript 코드를 읽고 컴파일하는 것이기 때문에 JavaScript 엔진을 프로세스 가상 머신이라고 부르는 것이 합리적입니다. 그렇다고 해서 단순한 엔진이라는 뜻은 아닙니다. 예를 들어 JavaScriptCore에는 JavaScript 코드를 분석, 해석, 최적화 및 가비지 수집하는 6개의 '빌딩 블록'이 있습니다.

어떻게 작동하나요?

엔진에 따라 다릅니다. WebKit의 JavaScriptCore와 Google의 V8 엔진이라는 두 가지 중요한 엔진을 고려해 보겠습니다. 이 두 엔진은 처리 코드를 다르게 처리합니다.

JavaScriptCore는 스크립트를 해석하고 최적화하기 위해 일련의 단계를 수행합니다.

어휘 분석을 수행하여 소스를 일련의 토큰 또는 식별된 의미가 있는 문자열로 분류합니다.

그런 다음 구문 분석기에 의해 토큰이 분석되어 구문 트리에 구축됩니다.

4개의 JIT(적시) 프로세스가 시작되어 파서에서 생성된 바이트코드를 분석 및 실행합니다.

간단히 말하면 이 JavaScript 엔진은 소스 코드를 문자열로 나누고(즉, 렉싱) 해당 문자열을 컴파일러가 이해할 수 있는 바이트코드로 변환한 다음 실행합니다.

C로 작성된 Google의 V8 엔진은 JavaScript 소스 코드를 컴파일 및 실행하고, 메모리 할당을 처리하고, 남은 항목을 가비지 수집합니다. 그 디자인은 소스 코드를 기계어 코드로 직접 컴파일하는 컴파일러 파이프라인으로 구성됩니다.

• 바이트코드를 생성하는 인터프리터 Ignition

• 바이트코드를 기계어 코드로 컴파일하는 최적화 컴파일러인 TurboFan

• TurboFan을 보완하는 컴파일러 SparkPlug

역사에 관심이 있다면 이 새로운 파이프라인은 이전에 V8에서 사용했던 이전 Full-codegen 및 Crankshaft 이중 컴파일러 디자인을 대체했습니다.

컴파일 프로세스를 통해 기계어 코드가 생성되면 엔진은 ECMA 표준에 지정된 모든 데이터 유형, 연산자, 개체 및 함수를 브라우저 또는 Node.js와 같이 이를 사용해야 하는 모든 런타임에 노출합니다. Deno 또는 Electron(Visual Studio Code에서 사용됨).

약간의 우회: 런타임

JavaScript 엔진이 백그라운드에서 조용히 실행되어 코드를 구문 분석하고 컴파일러가 읽고 컴파일할 수 있도록 읽을 수 있는 문자열로 분할하는 경우 런타임이 더 많은 관심을 끄는 경향이 있습니다. 왜 그럴까요?

잘 알려진 런타임은 JavaScript 엔진 위에서 작동하여 성능을 확장합니다. 가장 잘 알려진 것은 Node이지만 Deno와 Bun은 이 분야에 새로 온 사람들입니다. Node와 Deno는 V8을 내장하고 Bun은 JavaScriptCore를 내장합니다.

Bun은 JavaScriptCore가 V8보다 빠르며 초당 69,845개의 http 요청을 처리하고 Node의 경우 16,288개, Deno의 경우 12,926개를 처리하기 때문에 Node 또는 Deno보다 빠르게 실행된다고 주장합니다.

Bun의 문서에 명시된 바와 같이 이러한 런타임의 목표는 "전 세계 대부분의 JavaScript를 브라우저 외부에서 실행하여 미래 인프라의 성능과 복잡성을 향상시키고 더 좋고 간단한 도구를 통해 개발자 생산성을 높이는 것"입니다. 실제로 이러한 런타임은 JavaScript 엔진의 성능을 활용하여 JavaScript가 브라우저 외부에서 실행되도록 합니다.

NativeScript는 JavaScript를 사용하여 구축된 크로스 플랫폼 네이티브 모바일 애플리케이션 개발을 위해 특별히 구축된 런타임의 좋은 예입니다.

또한 이러한 런타임은 JavaScript의 단일 스레드 아키텍처에서 나타나는 고유한 문제 중 일부를 해결하기 위해 구축되었습니다. 예를 들어 노드는 비동기식, 스레드 없는 루틴 실행을 우선시합니다. 이러한 모든 런타임은 React 개발자들이 선호하는 fetch, websocket, 심지어 JSX와 같이 널리 사랑받는 API에 대한 기본 지원을 포함하여 엄선된 개발자 환경을 제공합니다. 이것이 개발자의 관심을 끄는 경향이 있는 이유일 수 있습니다.

런타임은 전반적으로 표준 브라우저 아키텍처와 이를 구동하는 엔진의 성능에서 인식된 격차를 해결합니다. 엔진이 발전함에 따라 이러한 런타임도 반드시 발전할 것입니다.

어떤 JavaScript 엔진이 있습니까?

클라이언트 측 코드를 분석, 구문 분석 및 실행하는 데 사용할 수 있는 다양한 JavaScript 엔진이 있습니다. 브라우저 버전이 출시될 때마다 JavaScript 엔진은 JavaScript 코드 실행의 최신 기술을 따라잡기 위해 변경되거나 최적화될 수 있습니다.

이러한 엔진에 부여된 이름 때문에 완전히 혼란스러워지기 전에 많은 마케팅 활동이 이러한 엔진과 그 기반이 되는 브라우저에 적용된다는 점을 기억해 두는 것이 좋습니다. JavaScript 컴파일에 대한 이 유용한 분석에서 저자는 다음과 같이 냉정하게 언급합니다. "모르는 경우 컴파일러는 약 37%가 마케팅으로 구성되어 있으며 브랜드 변경은 마케팅 측면에서 컴파일러에 수행할 수 있는 몇 안 되는 작업 중 하나입니다. 따라서 기차라는 이름은 다음과 같습니다: SquirrelFish, Nitro, SFX..."

이러한 엔진의 이름 지정 및 이름 변경과 관련된 썰물과 흐름을 염두에 두면서 JavaScript 엔진 역사에서 몇 가지 주요 사건을 언급하는 것이 유용합니다. 여러분을 위해 편리한 차트를 준비했습니다:

Browser, Headless Browser, or Runtime	JavaScript Engine
Mozilla	Spidermonkey
Chrome	V8
IE	Chakra
Safari	JavaScriptCore*
Node.js	V8
Deno	V8
Bun	JavaScriptCore
Edge**	Blink and V8

*JavaScriptCore는 SquirrelFish로 재작성되었으며 Nitro라고도 불리는 SquirrelFish Extreme으로 브랜드가 변경되었습니다. 그러나 JavaScriptCore를 WebKit 구현(예: Safari)의 기반이 되는 JavaScript 엔진이라고 부르는 것은 여전히 ​​사실입니다.

**Edge는 원래 Chakra 엔진을 사용했으며 그 중 일부는 Microsoft가 오픈 소스로 제공했습니다. 그런 다음 Edge는 내부에 Blink 및 V8 JavaScript 엔진을 포함하여 Chromium 브라우저로 재구축되었습니다.

우리는 왜 관심을 가져야 합니까?

자바스크립트 엔진의 코드 분석 및 실행 프로세스의 목표는 가능한 한 짧은 시간 내에 가장 최적화된 코드를 생성하는 것입니다.
결론적으로, 이러한 엔진의 발전은 웹 및 모바일 환경을 최대한 성능을 높이기 위해 발전시키려는 우리의 노력과 유사합니다. 이러한 발전을 추적하기 위해 arewefastyet.com에서 생성된 것과 같은 벤치마킹 그래프에서 다양한 엔진의 성능을 확인할 수 있습니다.

모든 웹 개발자는 우리가 열심히 생산, 디버그, 유지 관리하는 코드를 표시하는 브라우저에 내재된 차이점을 인식해야 합니다. 특정 스크립트가 한 브라우저에서는 느리게 작동하지만 다른 브라우저에서는 더 빠르게 작동하는 이유는 무엇입니까?

마찬가지로 모바일 개발자, 특히 웹뷰를 사용하여 콘텐츠를 표시하는 하이브리드 모바일 앱을 작성하는 개발자는 어떤 엔진이 JavaScript 코드를 해석하는지 알고 싶어할 것입니다. 사용자 경험에 관심이 있는 모든 웹 개발자는 소형 장치의 다양한 브라우저에 내재된 한계와 가능성을 이해해야 합니다.
의 변화를 따라가세요 JavaScript 엔진은 웹, 모바일 또는 앱 개발자로 발전하는 데 많은 시간을 할애하게 될 것입니다.

이 기사는 원래 Telerik 개발자 네트워크에 2015년에 게재되었으며 이후 2022년 이후에 수정 및 업데이트되었습니다. 원본 기사는 Wikipedia의 JavaScript 엔진 항목에 인용되어 있습니다.
 

위 내용은 JavaScript 엔진이란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!