| V8 | |
|---|---|
|
| |
| 개발자 | 구글, Chromium 프로젝트 기여자 |
| 발표일 | 2008년 9월 2일 |
| 프로그래밍 언어 | C++ |
| 운영 체제 | Windows, macOS, Linux, Android, ChromeOS 등 |
| 플랫폼 | x64, IA-32, ARM, ARM64 등 |
| 종류 | 자바스크립트 엔진, WebAssembly 엔진 |
| 라이선스 | BSD 계열 라이선스 |
| 웹 사이트 | https://v8.dev/ |
V8은 구글이 개발하고 Chromium 프로젝트와 함께 유지보수하는 오픈 소스 자바스크립트 엔진이자 WebAssembly 엔진이다.[1] V8은 ECMAScript 표준에 정의된 JavaScript를 실행하고, WebAssembly 모듈을 컴파일 및 실행하며, Google Chrome, Chromium, Node.js, Deno, Electron, Google Apps Script 등 여러 실행 환경에서 사용된다.[2][3]
V8의 가장 중요한 특징은 JavaScript 코드를 단순히 해석하는 데 그치지 않고, 실행 중 수집한 정보를 바탕으로 기계어 코드를 생성하고 최적화한다는 점이다. 현대의 V8은 인터프리터인 Ignition, 빠른 비최적화 컴파일러인 Sparkplug, 중간 단계 최적화 JIT 컴파일러인 Maglev, 고성능 최종 단계 최적화 컴파일러인 TurboFan 및 그 내부 구조 변화인 Turboshaft를 중심으로 발전해 왔다.[4][5][6][7]
개요[편집 / 원본 편집]
V8은 웹 브라우저 안에서 JavaScript를 실행하기 위해 만들어졌지만, 현재는 브라우저 밖의 서버, 데스크톱 애플리케이션, 개발 도구, 스크립트 자동화 환경에서도 널리 사용된다. Node.js는 서버 측 JavaScript 실행을 위해 V8을 채택했고, Electron은 Chromium과 Node.js를 결합하여 데스크톱 애플리케이션을 만들 수 있게 하며, Deno는 V8, Rust, Tokio를 기반으로 JavaScript, TypeScript, WebAssembly 런타임을 제공한다.[8][9]
V8은 C++로 작성되어 있으며, 독립 실행형으로 사용할 수도 있고 C++ 애플리케이션에 내장할 수도 있다.[10] 이 때문에 V8은 단순한 브라우저 구성요소가 아니라, JavaScript를 애플리케이션 내부 스크립트 언어로 제공하려는 프로그램에서도 사용할 수 있는 범용 실행 엔진에 가깝다.
다만 V8 자체는 DOM, HTML, CSS, 네트워크 API, 파일 시스템 API 같은 실행 환경 기능을 제공하지 않는다. 예를 들어 웹 브라우저에서는 DOM과 Web API를 브라우저가 제공하고, Node.js에서는 파일 시스템, 네트워크, 프로세스 제어 API를 Node.js 런타임이 제공한다. V8의 역할은 ECMAScript 코드와 WebAssembly 코드를 파싱, 컴파일, 실행하고 메모리를 관리하는 것이다.[3]
명칭[편집 / 원본 편집]
V8이라는 이름은 자동차의 V8 엔진에서 따온 것으로 알려져 있다. Chrome이 빠른 웹 애플리케이션 실행을 목표로 개발되던 시기에, JavaScript 실행 성능을 강조하기 위해 고성능 엔진을 연상시키는 이름이 붙었다. 이 이름은 Chrome의 브랜드 이미지와도 연결되며, 초기 Chrome 발표 자료에서도 V8은 브라우저의 속도와 복잡한 웹 애플리케이션 실행 능력을 상징하는 핵심 기술로 소개되었다.[11]
역사[편집 / 원본 편집]
개발 배경[편집 / 원본 편집]
2000년대 중반까지 JavaScript는 주로 웹 페이지의 보조적인 동작을 구현하는 언어로 여겨졌다. 그러나 Gmail, Google Maps와 같은 복잡한 웹 애플리케이션이 등장하면서 브라우저 안에서 대규모 JavaScript 코드를 빠르게 실행하는 능력이 중요해졌다. Google은 Chrome을 개발하면서 웹 애플리케이션이 기존 데스크톱 애플리케이션에 가까운 반응성과 복잡성을 가질 수 있어야 한다고 보았고, 이를 위해 새로운 JavaScript 엔진인 V8을 만들었다.[11]
V8 프로젝트는 가상 머신과 동적 언어 구현 경험이 많은 Lars Bak이 주도하였다. 2008년 9월 2일 Google Chrome이 처음 공개되었을 때 V8도 함께 공개되었고, 같은 날 오픈 소스 프로젝트가 되었다.[12][13]
2008년: Chrome과 함께 공개[편집 / 원본 편집]
2008년 9월 2일 Google은 Chrome 베타를 공개하면서 Chromium과 V8도 함께 공개하였다.[13] 초기 V8은 JavaScript를 중간 바이트코드로 오래 머무르게 하지 않고 가능한 한 빠르게 기계어로 컴파일하는 접근을 취했다. 당시 이 방식은 복잡한 웹 애플리케이션을 더 빠르게 실행하기 위한 핵심 전략으로 소개되었다.[14]
초기 V8의 설계에는 빠른 속성 접근, 숨겨진 클래스, 인라인 캐시, 효율적인 가비지 컬렉션 같은 기술이 포함되었다. 이러한 기술들은 동적 타입 언어인 JavaScript에서 객체 구조가 실행 중 바뀔 수 있다는 문제를 다루면서도 가능한 한 정적 언어에 가까운 최적화 기회를 얻기 위한 것이었다.
Crankshaft 시대[편집 / 원본 편집]
2010년대 초반 V8은 Crankshaft라는 최적화 컴파일러를 도입하였다. Crankshaft는 자주 실행되는 코드를 찾아 더 빠른 기계어로 다시 컴파일하는 역할을 했다. 그러나 JavaScript 언어가 빠르게 발전하고, 예외 처리, 모듈, 클래스, 다양한 ES2015 이후 문법이 보편화되면서 Crankshaft의 구조적 한계가 점점 커졌다. V8 팀은 Crankshaft가 새로운 언어 기능과 다양한 아키텍처를 장기적으로 지원하기에 복잡도가 높고 유지보수가 어렵다고 보았다.[4]
Ignition과 TurboFan으로의 전환[편집 / 원본 편집]
2017년 V8 v5.9부터 V8은 JavaScript 실행 파이프라인을 Ignition과 TurboFan 중심으로 재구성하였다.[4] Ignition은 JavaScript를 바이트코드로 변환하고 이를 실행하는 인터프리터이며, TurboFan은 실행 중 수집된 타입 피드백과 프로파일 정보를 바탕으로 최적화된 기계어를 생성하는 컴파일러이다.
이 전환의 중요한 목적은 다음과 같다.
- 메모리 사용량 감소
- 모바일 환경에서의 시작 성능 개선
- 새 ECMAScript 기능을 더 쉽게 지원
- 아키텍처별 코드 중복 감소
- 최적화 컴파일러의 유지보수성 향상
- Crankshaft와 Full-codegen 제거
Ignition과 TurboFan의 도입은 V8 역사에서 매우 큰 구조 변화였다. V8 팀은 이를 통해 JavaScript 언어 전체를 더 일관되게 최적화할 수 있는 기반을 마련했다고 설명하였다.[4]
WebAssembly 지원[편집 / 원본 편집]
V8은 JavaScript뿐 아니라 WebAssembly 실행 엔진이기도 하다. WebAssembly는 C, C++, Rust 같은 언어로 작성된 프로그램을 웹과 기타 실행 환경에서 효율적이고 안전하게 실행하기 위한 이진 명령어 형식이다. V8은 WebAssembly 모듈을 빠르게 시작하기 위해 Liftoff라는 baseline compiler를 도입하였고, 더 높은 성능이 필요한 코드에는 TurboFan 계열의 최적화 컴파일러를 사용한다.[15][16]
2020년대에는 WebAssembly SIMD, WebAssembly BigInt 통합, WebAssembly tail calls, WasmGC, WebAssembly 동적 티어링, WebAssembly 최적화와 deoptimization 지원 등도 발전하였다.[17][18]
Sparkplug 도입[편집 / 원본 편집]
2021년 V8은 Sparkplug라는 빠른 비최적화 JavaScript 컴파일러를 도입하였다.[5] Sparkplug는 Ignition 바이트코드를 기반으로 빠르게 기계어 코드를 생성한다. Sparkplug의 목표는 TurboFan처럼 무거운 최적화를 수행하지 않으면서도 인터프리터 실행보다 빠른 코드를 제공하는 것이다.
Sparkplug는 V8의 티어드 컴파일 구조에서 Ignition과 TurboFan 사이의 간격을 줄였다. JavaScript 코드는 처음에는 Ignition으로 빠르게 시작하고, 이후 Sparkplug로 더 빠르게 실행되며, 충분히 자주 실행되고 최적화 가치가 있는 코드는 Maglev나 TurboFan으로 넘어갈 수 있다.
Maglev 도입[편집 / 원본 편집]
2023년 Chrome M117에서 V8은 Maglev라는 새로운 중간 단계 최적화 JIT 컴파일러를 도입하였다.[6] Maglev는 Sparkplug보다 훨씬 빠른 코드를 만들면서도 TurboFan보다 훨씬 빠르게 컴파일되는 것을 목표로 한다. V8 팀은 Maglev가 웹 성능 벤치마크와 에너지 사용량 측면에서 이점을 제공한다고 설명하였다.[19]
Maglev는 특히 짧은 시간 안에 최적화 이익을 얻어야 하는 실제 웹 페이지와 웹 애플리케이션에서 중요하다. TurboFan은 매우 고성능의 코드를 만들 수 있지만 컴파일 비용이 높기 때문에 모든 코드에 적용하기 어렵다. Maglev는 이러한 비용과 성능 사이의 균형을 맞추기 위해 도입되었다.
Turboshaft와 Sea of Nodes 탈피[편집 / 원본 편집]
2025년 V8 팀은 TurboFan 내부의 일부 구조를 기존의 Sea of Nodes 표현에서 더 전통적인 제어 흐름 그래프 기반 중간 표현인 Turboshaft로 옮기는 작업을 설명하였다.[7] Sea of Nodes는 이론적으로 강력한 최적화 표현이지만, JavaScript와 WebAssembly처럼 복잡한 제어 흐름, 부작용, 타입 체크, 메모리 접근이 많은 언어에서는 분석과 유지보수가 어렵다는 문제가 있었다.
Turboshaft는 컴파일러 내부 구조를 더 명확하게 만들고, 버그 조사와 최적화 구현을 쉽게 하며, 컴파일 시간을 줄이기 위한 방향으로 도입되었다. V8 팀은 2025년 기준으로 JavaScript 백엔드 전체와 WebAssembly 파이프라인 전체에서 Turboshaft가 사용되고 있다고 설명하였다.[7]
구조와 동작 원리[편집 / 원본 편집]
파싱과 추상 구문 트리[편집 / 원본 편집]
V8은 JavaScript 소스 코드를 먼저 파싱하여 내부 표현으로 변환한다. 이 단계에서는 문법 오류를 검사하고, 스크립트 또는 모듈의 구조를 분석하며, 함수, 변수, 클래스, 블록, 표현식 등의 관계를 파악한다. 일반적으로 JavaScript 엔진은 소스 코드를 토큰화하고, 파서가 이를 구문 트리 형태로 구성한 뒤, 실행에 적합한 내부 형식으로 변환한다.
V8은 전체 코드를 처음부터 모두 무겁게 컴파일하지 않는다. 실제 웹 페이지와 서버 프로그램에서는 많은 함수가 전혀 호출되지 않거나 드물게 호출된다. 따라서 V8은 필요한 부분을 늦게 파싱하거나 컴파일하는 방식으로 시작 시간을 줄이고 메모리 사용량을 낮춘다.
Ignition 인터프리터[편집 / 원본 편집]
Ignition은 V8의 JavaScript 인터프리터이다. Ignition은 JavaScript를 V8 내부 바이트코드로 변환하고, 이 바이트코드를 실행한다.[4] 바이트코드는 원본 JavaScript보다 실행 엔진이 다루기 쉽고, 이후 Sparkplug, Maglev, TurboFan 같은 컴파일러가 참고할 수 있는 기반이 된다.
Ignition의 중요한 역할은 단순 실행뿐 아니라 피드백 수집이다. V8은 함수 호출, 객체 속성 접근, 산술 연산, 배열 접근, 함수 인자 타입 등에 대한 정보를 실행 중에 수집한다. 이 정보는 나중에 코드를 최적화할 때 사용된다.
인라인 캐시와 타입 피드백[편집 / 원본 편집]
JavaScript는 동적 타입 언어이므로 같은 코드가 서로 다른 타입의 값을 처리할 수 있다. 예를 들어 `obj.name`이라는 속성 접근은 어떤 순간에는 일반 객체의 문자열 속성을 읽을 수도 있고, 다른 순간에는 전혀 다른 구조의 객체를 읽을 수도 있다.
V8은 이러한 동적 특성을 다루기 위해 인라인 캐시와 타입 피드백을 사용한다. 특정 코드 위치에서 반복적으로 같은 형태의 객체가 등장하면 V8은 그 패턴을 기록하고, 다음 실행 때 더 빠른 경로를 사용할 수 있다. 예를 들어 어떤 객체가 같은 hidden class 또는 map 구조를 가진다면, V8은 속성 이름을 매번 일반적인 해시 검색으로 찾지 않고 정해진 오프셋에서 빠르게 읽을 수 있다.
Hidden class와 Map[편집 / 원본 편집]
V8은 JavaScript 객체의 구조를 내부적으로 Map 또는 hidden class에 가까운 개념으로 표현한다. JavaScript 객체는 실행 중 속성이 추가되거나 삭제될 수 있지만, 실제 프로그램에서는 같은 생성자나 같은 객체 리터럴에서 만들어진 객체들이 비슷한 구조를 갖는 경우가 많다. V8은 이 구조적 공통성을 이용해 속성 접근을 최적화한다.
예를 들어 다음과 같은 객체들이 반복적으로 만들어진다고 가정할 수 있다.
function User(name, age) {
this.name = name;
this.age = age;
}
const a = new User("Kim", 20);
const b = new User("Lee", 25);`a`와 `b`는 같은 순서로 `name`, `age` 속성이 추가되므로 내부적으로 비슷한 구조를 공유할 수 있다. V8은 이 점을 활용하여 `user.name` 같은 접근을 빠르게 만든다.
Sparkplug 컴파일러[편집 / 원본 편집]
Sparkplug는 Ignition이 만든 바이트코드를 바탕으로 빠르게 기계어를 생성하는 비최적화 컴파일러이다.[5] Sparkplug는 복잡한 최적화 분석을 수행하지 않으므로 컴파일 비용이 낮다. 대신 인터프리터보다 빠른 실행 속도를 제공한다.
Sparkplug의 핵심 가치는 시작 직후의 성능 개선이다. 웹 페이지는 사용자가 기다리지 않도록 빠르게 반응해야 하고, 서버 애플리케이션도 요청을 지연 없이 처리해야 한다. Sparkplug는 최적화 컴파일러가 충분한 정보를 모으기 전까지의 중간 성능을 높이는 역할을 한다.
Maglev 컴파일러[편집 / 원본 편집]
Maglev는 Sparkplug와 TurboFan 사이에 위치한 중간 단계 최적화 컴파일러이다.[6] Maglev는 정적 단일 할당 형태와 제어 흐름 그래프 기반 구조를 사용하여 비교적 빠르게 최적화 코드를 생성한다. TurboFan만큼 깊은 최적화를 수행하지는 않지만, Sparkplug보다 훨씬 나은 실행 성능을 목표로 한다.
Maglev의 도입은 V8의 실행 파이프라인을 더 세밀하게 만들었다. 단순히 인터프리터와 최종 최적화 컴파일러 사이에서 오가는 것이 아니라, 코드의 실행 빈도와 안정성에 따라 적절한 단계의 컴파일러를 선택할 수 있게 된 것이다.
TurboFan 컴파일러[편집 / 원본 편집]
TurboFan은 V8의 고성능 최적화 컴파일러이다. 자주 실행되고 타입 정보가 안정적인 코드는 TurboFan에 의해 더 깊게 최적화될 수 있다.[4] TurboFan은 인라인 확장, 불필요한 검사 제거, 상수 접기, dead code elimination, bounds check 최적화, escape analysis 등 다양한 컴파일러 최적화 기법을 적용할 수 있다.
TurboFan은 JavaScript의 동적 특성 때문에 추측적 최적화를 많이 사용한다. 예를 들어 어떤 함수가 계속 숫자만 처리한다면, V8은 그 함수가 앞으로도 숫자를 처리할 것이라고 가정하고 숫자 연산에 특화된 빠른 코드를 만들 수 있다. 그러나 나중에 문자열이나 객체가 들어오면 그 가정은 깨질 수 있다. 이때 V8은 최적화된 코드를 버리고 안전한 코드 경로로 되돌아간다.
Deoptimization[편집 / 원본 편집]
Deoptimization은 V8 같은 JIT 엔진에서 매우 중요한 개념이다. 최적화 컴파일러는 실행 중 수집한 정보를 바탕으로 “이 코드는 앞으로도 이런 타입을 받을 가능성이 높다”는 가정을 세우고 빠른 코드를 만든다. 그러나 JavaScript는 동적 언어이므로 그 가정이 언제든 깨질 수 있다.
가정이 깨지면 V8은 최적화된 코드를 계속 실행하지 않고, 더 일반적인 코드 상태로 되돌아간다. 이 과정을 deoptimization이라고 한다. Deoptimization은 JavaScript의 유연성을 유지하면서도 일반적인 경우에는 빠르게 실행하기 위한 핵심 장치이다.
가비지 컬렉션[편집 / 원본 편집]
V8은 자동 메모리 관리를 위해 가비지 컬렉션을 수행한다. JavaScript 개발자는 일반적으로 객체를 명시적으로 해제하지 않고, 더 이상 도달할 수 없는 객체는 엔진이 회수한다. V8의 가비지 컬렉터는 세대별 수집, 증분 처리, 병렬 처리, 동시 처리 등을 활용하여 중단 시간을 줄이고 처리량을 높이는 방향으로 발전하였다.
V8의 Orinoco 프로젝트는 가비지 컬렉션 작업을 병렬화하고 동시화하여 웹 페이지와 애플리케이션의 끊김을 줄이는 데 초점을 맞추었다.[12] 특히 브라우저 환경에서는 가비지 컬렉션으로 인해 사용자 인터페이스가 멈추는 현상이 체감 성능에 큰 영향을 주기 때문에, GC의 지연 시간을 줄이는 것이 중요하다.
메모리 최적화[편집 / 원본 편집]
V8은 성능뿐 아니라 메모리 사용량도 중요하게 다룬다. 모바일 기기, 저사양 장치, 서버의 고밀도 워크로드에서는 메모리 사용량이 곧 비용과 사용자 경험으로 이어진다.
대표적인 메모리 최적화로는 다음이 있다.
- Pointer compression: 64비트 환경에서 포인터를 압축하여 힙 메모리 사용량을 줄이는 기술이다.[20]
- Embedded builtins: 여러 isolate가 공통 내장 코드를 공유하여 메모리 중복을 줄이는 방향의 최적화이다.
- Startup snapshot: 초기 실행에 필요한 객체와 내장 함수 상태를 스냅샷으로 저장하여 시작 속도를 높인다.
- Code caching: 이미 컴파일된 코드나 파싱 결과를 재사용하여 반복 실행 비용을 줄인다.
WebAssembly 실행[편집 / 원본 편집]
V8은 JavaScript 엔진이면서 동시에 WebAssembly 엔진이다. WebAssembly 코드는 브라우저나 런타임에서 안전하게 실행될 수 있도록 설계된 저수준 이진 형식이다. V8은 WebAssembly 모듈을 로드하고 검증한 뒤, 실행 가능한 기계어 코드로 컴파일한다.[16]
Liftoff[편집 / 원본 편집]
Liftoff는 V8의 WebAssembly baseline compiler이다.[15] Liftoff의 목표는 WebAssembly 코드를 매우 빠르게 컴파일하여 시작 시간을 줄이는 것이다. 고성능 코드를 만드는 것보다 빠른 시작이 우선인 단계에서 사용된다.
TurboFan과 Turboshaft[편집 / 원본 편집]
더 자주 실행되거나 성능이 중요한 WebAssembly 코드는 TurboFan 계열 컴파일러를 통해 최적화될 수 있다. 2025년 기준으로 V8은 WebAssembly 파이프라인에서도 Turboshaft를 사용한다고 설명하였다.[7]
동적 티어링[편집 / 원본 편집]
WebAssembly에서도 JavaScript와 비슷하게 티어드 컴파일 전략이 사용된다. 먼저 Liftoff가 빠르게 코드를 생성하고, 이후 성능이 중요한 부분은 더 무거운 최적화 컴파일러가 다시 컴파일할 수 있다. 이를 통해 빠른 시작과 높은 장기 실행 성능 사이의 균형을 맞춘다.[16]
WasmGC와 최신 WebAssembly 기능[편집 / 원본 편집]
WasmGC는 Java, Kotlin, Dart, C# 같은 가비지 컬렉션 기반 언어를 WebAssembly로 더 효율적으로 옮기기 위한 기능이다. V8은 WebAssembly 기능 설명과 블로그를 통해 WasmGC, tail calls, SIMD, BigInt 통합 등 여러 WebAssembly 관련 기능을 다루고 있다.[17]
보안[편집 / 원본 편집]
V8은 공격자가 제공한 웹 페이지의 JavaScript와 WebAssembly를 실행해야 하므로 보안상 매우 민감한 구성요소이다. 브라우저 공격에서 JavaScript 엔진 취약점은 원격 코드 실행, 샌드박스 내부 코드 실행, 메모리 손상 공격의 출발점이 될 수 있다.
V8 Sandbox[편집 / 원본 편집]
2024년 V8 팀은 V8 Sandbox를 설명하였다.[21] V8 Sandbox는 V8 내부의 메모리 손상 취약점이 프로세스의 다른 메모리 영역으로 확산되는 것을 막기 위한 소프트웨어 기반 격리 구조이다. 이 구조는 공격자가 V8 샌드박스 내부에서 읽기와 쓰기 능력을 얻었다고 가정하더라도, 그 영향이 샌드박스 바깥으로 쉽게 나가지 못하게 만드는 것을 목표로 한다.
V8 Sandbox는 특히 최적화 JavaScript 엔진에 일반적인 메모리 안전 기법을 그대로 적용하기 어렵다는 현실에서 출발한다. JIT 컴파일러와 고성능 런타임은 성능과 유연성 때문에 복잡한 내부 구조를 가질 수밖에 없으므로, 취약점 발생 가능성을 줄이는 것과 함께 취약점의 영향을 제한하는 방어 계층이 필요하다.
취약점과 업데이트[편집 / 원본 편집]
Chrome과 Chromium 기반 브라우저는 V8 취약점을 포함한 보안 문제를 정기적으로 수정한다. Chrome의 릴리스 주기는 V8의 릴리스와 밀접하게 연결되어 있으며, V8 문서도 Chrome 릴리스 채널을 통해 새 버전이 사용자에게 전달된다고 설명한다.[22]
2026년 6월 기준 Chrome Stable 채널은 149 계열 업데이트를 배포하고 있으며, Chrome Release Blog는 안정화 채널 업데이트와 보안 수정 사항을 공지하고 있다.[23] V8처럼 많은 소프트웨어에 내장되는 엔진은 브라우저뿐 아니라 Electron 기반 애플리케이션, 런타임, 자동화 도구의 보안에도 영향을 준다.
릴리스와 버전 관리[편집 / 원본 편집]
V8의 릴리스 과정은 Chrome의 릴리스 과정과 매우 밀접하게 연결되어 있다.[22] V8 팀은 Chrome의 여러 릴리스 채널을 통해 새 기능과 수정 사항을 사용자에게 전달한다. Chrome은 안정 채널, 베타 채널, 개발자 채널, 카나리아 채널을 통해 단계적으로 새 버전을 배포하며, V8도 이 흐름에 맞추어 안정화된다.
Chrome의 주요 버전은 일정한 주기로 배포되며, 보안 수정이나 안정성 개선은 중간 업데이트로 제공될 수 있다. 특정 Chrome 버전에 어떤 V8 버전이 포함되어 있는지는 Chromium Dash 같은 도구를 통해 확인할 수 있다.[24]
Node.js와 같은 런타임은 Chrome과 별도의 릴리스 정책을 가지므로, 같은 시점의 Node.js가 반드시 최신 Chrome과 동일한 V8 버전을 포함하는 것은 아니다. Node.js는 안정성, 장기 지원, API 호환성, 생태계 영향 등을 고려하여 V8 버전을 선택하고 업데이트한다.
ECMAScript와 최신 JavaScript 기능[편집 / 원본 편집]
V8은 ECMA-262에 정의된 ECMAScript를 구현한다.[2] 최신 JavaScript 기능은 TC39 제안 절차를 거쳐 표준화되며, V8은 기능의 성숙도와 Chrome 릴리스 일정에 따라 이를 구현한다.
V8 공식 기능 문서는 ECMAScript와 WebAssembly의 최신 기능을 설명한다.[25] 최근 기능의 예로는 다음과 같은 것들이 있다.
- Explicit Resource Management
- Iterator helpers
- Import attributes
- RegExp v 플래그와 집합 표기법
- Array 및 TypedArray 요소 검색 기능
- `Array.prototype.at`
- Error cause
- `Object.hasOwn`
- class static initialization blocks
- Top-level await
- Optional chaining
- Nullish coalescing
- `globalThis`
2025년 V8은 Explicit Resource Management 기능을 설명하였다. 이 기능은 `using`, `await using`, `Symbol.dispose`, `Symbol.asyncDispose`, `DisposableStack`, `AsyncDisposableStack` 등을 통해 리소스 수명 주기를 명시적으로 관리할 수 있게 한다.[26]
V8과 런타임의 차이[편집 / 원본 편집]
V8은 JavaScript 코드를 실행하는 엔진이지만, 그 자체만으로 Node.js나 브라우저와 같은 완전한 실행 환경은 아니다. 이 차이는 매우 중요하다.
브라우저에서 다음과 같은 기능은 V8이 아니라 브라우저가 제공한다.
- DOM 조작
- `window`
- `document`
- `fetch`
- `setTimeout`
- 이벤트 루프의 브라우저 통합
- 렌더링 엔진과 레이아웃
- 네트워크 스택
- 보안 정책과 권한 모델
Node.js에서 다음과 같은 기능은 V8이 아니라 Node.js 런타임이 제공한다.
- 파일 시스템 API
- TCP, HTTP, TLS 네트워크 API
- `process`
- `Buffer`
- CommonJS 모듈 시스템
- npm 패키지 생태계 통합
- libuv 기반 이벤트 루프
따라서 “V8이 Node.js이다” 또는 “V8이 Chrome이다”라고 말하는 것은 정확하지 않다. V8은 Chrome과 Node.js 내부에서 JavaScript와 WebAssembly 실행을 담당하는 핵심 엔진이다.
임베딩[편집 / 원본 편집]
V8은 C++ 애플리케이션에 내장할 수 있다.[10] 임베더는 V8 API를 사용하여 JavaScript 실행 컨텍스트를 만들고, C++ 객체와 함수를 JavaScript에서 사용할 수 있도록 노출하며, JavaScript 함수와 객체를 C++ 코드에서 호출할 수 있다.
V8 임베딩에서 중요한 개념은 다음과 같다.
Isolate[편집 / 원본 편집]
Isolate는 독립적인 V8 실행 인스턴스이다. 각 isolate는 자체 힙을 가지며, 일반적으로 다른 isolate와 JavaScript 객체를 직접 공유하지 않는다. 이 구조는 서로 다른 실행 환경을 분리하고, 병렬 실행이나 샌드박싱을 구성하는 데 중요하다.
Context[편집 / 원본 편집]
Context는 JavaScript 코드가 실행되는 전역 객체와 내장 객체의 집합이다. 하나의 isolate 안에 여러 context를 만들 수 있다. 브라우저에서는 서로 다른 프레임이나 격리된 스크립트 환경을 context로 표현할 수 있다.
Handle[편집 / 원본 편집]
V8의 C++ API에서는 JavaScript 객체를 직접 포인터처럼 다루지 않고 handle을 사용한다. 이는 가비지 컬렉션이 객체를 이동하거나 회수할 수 있기 때문이다. handle은 C++ 코드가 V8 객체를 안전하게 참조할 수 있게 해 준다.
Snapshot[편집 / 원본 편집]
V8은 시작 성능을 높이기 위해 초기 힙 상태를 스냅샷으로 저장할 수 있다. 임베더는 자주 사용하는 라이브러리나 초기 객체를 스냅샷에 포함시켜 시작 시간을 줄일 수 있다.
사용 사례[편집 / 원본 편집]
Google Chrome과 Chromium[편집 / 원본 편집]
V8은 Google Chrome과 Chromium의 JavaScript 및 WebAssembly 실행 엔진이다.[1] Chrome에서 웹 페이지의 JavaScript가 실행될 때 V8이 코드를 파싱하고 실행한다. Chrome의 렌더링 엔진인 Blink, 네트워크 스택, 보안 샌드박스, DevTools 등은 V8과 함께 작동하지만 각각 별도의 역할을 가진다.
Node.js[편집 / 원본 편집]
Node.js는 V8을 기반으로 서버 측 JavaScript 실행 환경을 제공한다.[3] V8이 JavaScript 실행을 담당하고, Node.js는 파일 시스템, 네트워크, 프로세스, 패키지 생태계, 이벤트 루프 등을 제공한다. Node.js가 V8을 채택하면서 JavaScript는 브라우저 밖에서도 대규모 서버 애플리케이션 개발에 사용되기 시작했다.
Deno[편집 / 원본 편집]
Deno는 JavaScript, TypeScript, WebAssembly를 실행하는 런타임으로, V8, Rust, Tokio를 기반으로 한다.[9] Deno는 보안 기본값, TypeScript 지원, 웹 표준 API 지향, 단일 실행 파일 배포 등을 강조한다.
Electron[편집 / 원본 편집]
Electron은 Chromium과 Node.js를 결합하여 JavaScript, HTML, CSS로 데스크톱 애플리케이션을 만들 수 있게 하는 프레임워크이다.[8] Electron 애플리케이션은 Chromium의 웹 플랫폼 기능과 Node.js의 시스템 API를 함께 사용할 수 있으며, 그 내부의 JavaScript 실행에는 V8이 관여한다.
Google Apps Script[편집 / 원본 편집]
Google Apps Script는 과거 Rhino JavaScript 인터프리터를 사용했으나, 현대 JavaScript 문법과 기능을 지원하기 위해 V8 런타임을 제공한다.[27] 이를 통해 Apps Script 개발자는 더 최신의 JavaScript 문법을 사용할 수 있다.
다른 JavaScript 엔진과의 비교[편집 / 원본 편집]
V8은 여러 JavaScript 엔진 중 하나이다. 대표적인 JavaScript 엔진에는 다음이 있다.
- SpiderMonkey: Mozilla Firefox의 JavaScript 엔진
- JavaScriptCore: Safari와 WebKit의 JavaScript 엔진
- Chakra: 과거 Microsoft Edge 및 Internet Explorer 계열에서 사용된 JavaScript 엔진
- Hermes: React Native 환경을 위해 개발된 JavaScript 엔진
- QuickJS: 작고 내장하기 쉬운 JavaScript 엔진
V8의 강점은 Chrome, Node.js, Chromium 기반 생태계와의 깊은 통합, 높은 실행 성능, 활발한 최적화 연구, WebAssembly 지원, 광범위한 실제 사용 사례이다. 반면 V8은 매우 큰 코드베이스이며, 임베딩과 빌드가 간단한 편은 아니다. 작은 프로그램에 JavaScript 실행 기능을 넣는 목적이라면 QuickJS 같은 경량 엔진이 더 적합할 수 있다.
성능 특성[편집 / 원본 편집]
V8의 성능은 단순히 “JavaScript를 기계어로 컴파일한다”는 한 문장으로 설명하기 어렵다. 현대 V8은 다음과 같은 전략을 함께 사용한다.
- 빠른 시작을 위한 지연 파싱과 인터프리터 실행
- 반복 실행되는 코드에 대한 피드백 수집
- Sparkplug를 통한 빠른 baseline 기계어 생성
- Maglev를 통한 빠른 중간 단계 최적화
- TurboFan을 통한 고성능 최종 단계 최적화
- 잘못된 가정이 발견될 때 deoptimization 수행
- 객체 구조와 배열 요소 종류에 따른 특화 최적화
- 가비지 컬렉션 중단 시간 감소
- WebAssembly 전용 컴파일 파이프라인
V8에서 성능이 좋은 JavaScript 코드는 일반적으로 객체 구조가 안정적이고, 함수가 일관된 타입의 값을 다루며, 불필요한 동적 속성 변경을 피하고, 과도한 deoptimization을 유발하지 않는 코드이다. 그러나 V8은 시간이 지남에 따라 다양한 JavaScript 패턴을 더 잘 최적화하도록 발전해 왔기 때문에, 과거의 미세 최적화 조언이 현재 버전에서는 더 이상 맞지 않을 수 있다.
개발과 빌드[편집 / 원본 편집]
V8의 공식 저장소는 Chromium의 Git 인프라에 있으며, GitHub에도 공식 미러가 존재한다.[2] V8을 직접 빌드하려면 Chromium 개발 도구와 빌드 시스템을 사용해야 한다. 일반적인 애플리케이션 개발자가 V8을 직접 빌드하는 경우는 많지 않지만, 런타임 개발자, 브라우저 개발자, 보안 연구자, 컴파일러 연구자, 임베더는 V8 소스 코드를 직접 다룰 수 있다.
V8 개발에는 다음과 같은 영역이 포함된다.
- JavaScript 파서
- Ignition 바이트코드 인터프리터
- Sparkplug, Maglev, TurboFan, Turboshaft 컴파일러
- WebAssembly 컴파일러
- 가비지 컬렉터
- 힙과 객체 모델
- 국제화 및 ECMAScript 내장 객체
- 테스트 인프라
- fuzzing과 보안 도구
- 플랫폼별 코드 생성기
한계와 비판[편집 / 원본 편집]
V8은 매우 강력한 엔진이지만 몇 가지 한계도 있다.
첫째, V8은 복잡하다. JIT 컴파일, 가비지 컬렉션, 동적 타입 최적화, WebAssembly, 샌드박스, 다양한 CPU 아키텍처 지원을 모두 포함하기 때문에 코드베이스와 빌드 과정이 방대하다.
둘째, JIT 엔진은 보안상 공격 표면이 크다. V8은 V8 Sandbox, fuzzing, CFI, 메모리 안전성 강화 등 여러 방어 기법을 도입하고 있지만, JavaScript 엔진은 여전히 브라우저 보안에서 중요한 공격 대상이다.[21]
셋째, V8의 성능은 코드 패턴과 실행 환경에 따라 달라진다. 특정 벤치마크에서 빠르다고 해서 모든 실제 애플리케이션에서 항상 빠른 것은 아니다. V8 팀도 실제 웹 성능과 다양한 워크로드를 중요하게 보며, 하나의 벤치마크만으로 엔진의 전체 성능을 판단하기 어렵다고 설명해 왔다.
넷째, V8은 런타임이 아니라 엔진이다. 파일 시스템, 네트워크, DOM, GUI 등은 V8 자체가 제공하지 않는다. 이러한 기능은 Chrome, Node.js, Deno, Electron 같은 임베더 또는 런타임이 제공해야 한다.
관련 기술[편집 / 원본 편집]
Blink[편집 / 원본 편집]
Blink는 Chromium 계열 브라우저의 렌더링 엔진이다. V8이 JavaScript와 WebAssembly 실행을 담당한다면, Blink는 HTML, CSS, 레이아웃, 렌더링, DOM 구현 등 웹 페이지 표시와 관련된 기능을 담당한다. 두 구성요소는 브라우저 안에서 밀접하게 협력하지만 서로 다른 역할을 가진다.
WebAssembly[편집 / 원본 편집]
WebAssembly는 웹과 여러 실행 환경에서 사용할 수 있는 저수준 이진 명령어 형식이다. V8은 WebAssembly의 주요 구현체 중 하나이며, Liftoff와 TurboFan/Turboshaft 기반 파이프라인을 통해 빠른 시작과 높은 실행 성능을 모두 추구한다.
ECMAScript[편집 / 원본 편집]
ECMAScript는 JavaScript 언어의 표준 사양이다. V8은 ECMA-262에 정의된 ECMAScript를 구현하며, ECMA-402 국제화 API와 관련된 기능도 지원한다.[25]
Test262[편집 / 원본 편집]
Test262는 ECMAScript 구현체의 표준 준수 여부를 검증하기 위한 공식 테스트 스위트이다. V8을 포함한 여러 JavaScript 엔진은 ECMAScript 호환성을 확인하기 위해 Test262를 활용한다.[28]
같이 보기[편집 / 원본 편집]
참고 문헌[편집 / 원본 편집]
- ↑ 1.0 1.1 V8 JavaScript engine. Google, V8.dev,. 2026년 6월 16일에 확인.
- ↑ 2.0 2.1 2.2 V8 JavaScript Engine. V8 project authors, GitHub,. 2026년 6월 16일에 확인.
- ↑ 3.0 3.1 3.2 The V8 JavaScript Engine. OpenJS Foundation, Node.js Learn,. 2026년 6월 16일에 확인.
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 Launching Ignition and TurboFan. Google, V8.dev, (2017년 5월 15일). 2026년 6월 16일에 확인.
- ↑ 5.0 5.1 5.2 Sparkplug — a non-optimizing JavaScript compiler. Google, V8.dev, (2021년 5월 27일). 2026년 6월 16일에 확인.
- ↑ 6.0 6.1 6.2 Maglev - V8’s Fastest Optimizing JIT. Google, V8.dev, (2023년 12월 5일). 2026년 6월 16일에 확인.
- ↑ 7.0 7.1 7.2 7.3 Land ahoy: leaving the Sea of Nodes. Google, V8.dev, (2025년 3월 25일). 2026년 6월 16일에 확인.
- ↑ 8.0 8.1 Electron. OpenJS Foundation, Electron,. 2026년 6월 16일에 확인.
- ↑ 9.0 9.1 denoland/deno. Deno Land Inc., GitHub,. 2026년 6월 16일에 확인.
- ↑ 10.0 10.1 Getting started with embedding V8. Google, V8.dev,. 2026년 6월 16일에 확인.
- ↑ 11.0 11.1 A fresh take on the browser. Google, Official Google Blog, (2008년 9월 1일). 2026년 6월 16일에 확인.
- ↑ 12.0 12.1 Celebrating 10 years of V8. Google, V8.dev, (2018년 9월 11일). 2026년 6월 16일에 확인.
- ↑ 13.0 13.1 Google Chrome, Chromium, and V8 launch today. Google, Google Developers Blog, (2008년 9월 2일). 2026년 6월 16일에 확인.
- ↑ Google Chrome's Need for Speed. Google, Chromium Blog, (2008년 9월 2일). 2026년 6월 16일에 확인.
- ↑ 15.0 15.1 Liftoff: a new baseline compiler for WebAssembly in V8. Google, V8.dev, (2018년 8월 20일). 2026년 6월 16일에 확인.
- ↑ 16.0 16.1 16.2 WebAssembly compilation pipeline. Google, V8.dev,. 2026년 6월 16일에 확인.
- ↑ 17.0 17.1 JavaScript and WebAssembly features. Google, V8.dev,. 2026년 6월 16일에 확인.
- ↑ Speculative Optimizations for WebAssembly using Deopts and Data Structures. Google, V8.dev, (2025년 6월 24일). 2026년 6월 16일에 확인.
- ↑ V8 is Faster and Safer than Ever!. Google, V8.dev, (2023년 12월 14일). 2026년 6월 16일에 확인.
- ↑ Pointer Compression in V8. Google, V8.dev, (2020년 3월 30일). 2026년 6월 16일에 확인.
- ↑ 21.0 21.1 The V8 Sandbox. Google, V8.dev, (2024년 4월 4일). 2026년 6월 16일에 확인.
- ↑ 22.0 22.1 Release process. Google, V8.dev,. 2026년 6월 16일에 확인.
- ↑ Chrome Releases: 2026. Google, Chrome Releases Blog,. 2026년 6월 16일에 확인.
- ↑ Chromium Dash Schedule. Chromium project, Chromium Dash,. 2026년 6월 16일에 확인.
- ↑ 25.0 25.1 JavaScript and WebAssembly features. Google, V8.dev,. 2026년 6월 16일에 확인.
- ↑ JavaScript's New Superpower: Explicit Resource Management. Google, V8.dev, (2025년 5월 9일). 2026년 6월 16일에 확인.
- ↑ V8 runtime overview. Google, Google for Developers, (2026년 4월 20일). 2026년 6월 16일에 확인.
- ↑ tc39/test262: Official ECMAScript Conformance Test Suite. TC39, GitHub,. 2026년 6월 16일에 확인.