자주자주 공지를 확인하세요!

SpiderMonkey: 두 판 사이의 차이

최근 수정 시각: 2026년 10월 16일 (금) 21:22
주시 편집 토론 문서 역사
시각위키텍스트
Gaon12 (토론 / 기여)
4,665 편집
SpiderMonkey 문서 신규 작성: 역사(넷스케이프~2026 asm.js 종료), JIT 계층 구조, GC, 사용처, 비교
 
Gaon12 (토론 / 기여)
4,665 편집
문서 보강: asm.js·Wasm 역사, Irregexp, Speedometer 3 최적화, 인라인 캐시, Wasm 기능표, 최신 JS 기능표, 보안 사례, 비교 확대
 
9번째 줄: 9번째 줄:
|상태 = 개발 중
|상태 = 개발 중
|프로그래밍 언어 = [[C++]], [[Rust]], [[JavaScript|자바스크립트]]
|프로그래밍 언어 = [[C++]], [[Rust]], [[JavaScript|자바스크립트]]
|운영체제 = [[Microsoft Windows|Windows]], [[macOS]], [[리눅스]], [[안드로이드]] 등
|운영체제 = [[Microsoft Windows|Windows]], [[macOS]], [[리눅스]], [[안드로이드]], BSD 계열 등
|플랫폼 = x86, x86-64, ARM, ARM64, MIPS64, LoongArch64, RISC-V 64 등
|종류 = [[자바스크립트 엔진]], [[WebAssembly]] 엔진
|종류 = [[자바스크립트 엔진]], [[WebAssembly]] 엔진
|라이선스 = [[모질라 공개 라이선스]] 2.0
|라이선스 = [[모질라 공개 라이선스]] 2.0
17번째 줄: 18번째 줄:


== 개요 ==
== 개요 ==
'''SpiderMonkey'''(스파이더몽키)는 [[모질라 재단|모질라]]가 개발하는 오픈 소스 [[자바스크립트 엔진]]이자 [[WebAssembly]] 엔진이다. [[Firefox|파이어폭스]]를 비롯한 [[Gecko]] 기반 브라우저에서 웹 페이지의 [[JavaScript|자바스크립트]]와 WebAssembly 코드를 실행하는 역할을 맡고 있다.
'''SpiderMonkey'''(스파이더몽키)는 [[모질라 재단|모질라]]가 개발하는 오픈 소스 [[자바스크립트 엔진]]이자 [[WebAssembly]] 엔진이다. [[Firefox|파이어폭스]]를 비롯한 [[Gecko]] 기반 브라우저에서 웹 페이지의 [[JavaScript|자바스크립트]]와 WebAssembly 코드를 해석하고 실행하는 역할을 맡는다.


1995년 [[넷스케이프]]의 [[브렌던 아이크]]가 자바스크립트라는 언어를 만들면서 함께 만든 '''세계 최초의 자바스크립트 엔진'''이 그 시초다. 즉 자바스크립트와 나이가 같은, 현역 엔진 중 가장 오래된 엔진이다. [[구글]]의 [[V8]], [[애플]]의 JavaScriptCore와 함께 현재 남아 있는 '''3대 브라우저 자바스크립트 엔진'''으로 꼽힌다.
1995년 [[넷스케이프]]의 [[브렌던 아이크]]가 자바스크립트라는 언어를 만들면서 함께 만든 '''세계 최초의 자바스크립트 엔진'''이 그 시초다. 즉 자바스크립트와 나이가 같고, 지금도 쓰이는 엔진 중 가장 오래되었다. [[구글]]의 [[V8]], [[애플]]의 JavaScriptCore와 함께 현재 남아 있는 '''3대 브라우저 자바스크립트 엔진'''으로 꼽히며, 이 셋이 사실상 전 세계 웹의 자바스크립트 실행을 나눠 맡고 있다.


[[C++]]를 중심으로 작성되었고, 일부 구성 요소는 [[Rust]]로 작성되어 있다. 라이선스는 [[모질라 공개 라이선스]](MPL) 2.0이며, 브라우저 밖에서도 쓸 수 있도록 '''임베딩 API'''(JSAPI)와 독립 실행용 셸(<code>js</code>)을 제공한다.
[[C++]]를 중심으로 작성되었고 일부 구성 요소는 [[Rust]]로 작성되어 있다. 라이선스는 [[모질라 공개 라이선스]](MPL) 2.0이다. 브라우저 밖에서도 쓸 수 있도록 C++ 임베딩 API(JSAPI)와 독립 실행용 셸(<code>js</code>)을 제공하며, [[GNOME]], [[MongoDB]] 등 다양한 프로그램에 내장되어 쓰인다.
 
엔진 성능 경쟁에서는 2008년 이후 줄곧 V8에 끌려가는 처지였지만, 표준 기능을 일찍 구현하는 편이며 '''[[asm.js]]를 통해 [[WebAssembly]]의 탄생을 이끌어 낸 엔진'''이라는 점에서 웹 역사에 남긴 족적이 크다.


=== 명칭 ===
=== 명칭 ===
이름의 유래에 대해 공식적으로 자세히 밝혀진 바는 없지만, 이후 모질라는 새로운 JIT 컴파일러를 만들 때마다 TraceMonkey, JägerMonkey, IonMonkey, OdinMonkey, WarpMonkey처럼 '''○○Monkey'''라는 이름을 붙이는 전통을 이어 왔다. WebAssembly 관련 컴파일러에는 북유럽 신화의 신 이름을 딴 BaldrMonkey, RabaldrMonkey 같은 이름도 쓰였다. 한국어로는 '스파이더몽키'라고 읽는다.
이름의 정확한 유래는 공식적으로 자세히 남아 있지 않다. 다만 이후 모질라는 새로운 JIT 컴파일러를 만들 때마다 TraceMonkey, JägerMonkey, IonMonkey, OdinMonkey, WarpMonkey처럼 '''○○Monkey'''라는 이름을 붙이는 전통을 이어 왔다. WebAssembly 컴파일러에는 북유럽 신화에서 따온 BaldrMonkey(발드르), RabaldrMonkey 같은 이름도 쓰였다. 한국어로는 '스파이더몽키'라고 읽는다.


== 역사 ==
== 역사 ==
=== 탄생 (1995~1998) ===
=== 탄생 (1995~1998) ===
1995년 넷스케이프에 입사한 브렌던 아이크는 웹 페이지에 넣을 간단한 스크립트 언어를 단 '''10일''' 만에 설계해 구현했다. 이 언어는 Mocha → LiveScript를 거쳐 '''JavaScript'''라는 이름으로 넷스케이프 내비게이터 2.0에 탑재되었는데, 이때 언어를 실행하던 [[인터프리터]]가 SpiderMonkey의 원형이다.
1995년 넷스케이프에 입사한 브렌던 아이크는 웹 페이지에 넣을 간단한 스크립트 언어를 단 '''10일''' 만에 설계해 구현했다. 이 언어는 Mocha → LiveScript를 거쳐 '''JavaScript'''라는 이름으로 넷스케이프 내비게이터 2.0에 탑재되었다. 이때 언어를 실행하던 인터프리터가 SpiderMonkey의 원형이다. 당시에는 성능보다 '일단 돌아가는 것'이 목표였기 때문에, 코드를 트리 형태로 해석해 실행하는 매우 단순한 인터프리터였다.
 
이후 자바스크립트가 [[ECMA 인터내셔널]]에서 '''[[ECMAScript]]'''라는 이름으로 표준화되었고(1997년), SpiderMonkey는 이 표준을 따라 발전했다.
 
=== 오픈 소스화 (1998~2007) ===
1998년 넷스케이프가 브라우저 소스 코드를 공개하면서 '''모질라 프로젝트'''가 출범했고, 자바스크립트 엔진도 C로 재작성되어 '''SpiderMonkey'''라는 이름으로 오픈 소스가 되었다. 이후 [[모질라 스위트]], [[Firefox|파이어폭스]](2004), [[모질라 썬더버드|썬더버드]] 등 모질라의 모든 제품에 들어갔다.


1998년 넷스케이프가 브라우저 소스 코드를 공개하면서 모질라 프로젝트가 출범했고, 자바스크립트 엔진도 C로 재작성되어 '''SpiderMonkey'''라는 이름으로 오픈 소스가 되었다. 이후 [[모질라 스위트]], [[Firefox|파이어폭스]](2004), [[모질라 썬더버드|썬더버드]] 등 모질라의 모든 제품에 들어갔다.
이 시기 모질라는 자바(Java)로 작성된 또 하나의 자바스크립트 엔진 '''Rhino'''도 함께 관리했는데, Rhino는 이후 자바 생태계의 스크립트 엔진으로 독자적인 길을 걸었다. 또 [[어도비]]가 플래시의 [[액션스크립트]] 3 가상 머신(Tamarin)을 모질라에 기증해 SpiderMonkey와 통합하려는 계획(ActionMonkey)이 있었으나, ECMAScript 4 표준이 무산되면서 흐지부지되었다.


=== JIT 경쟁 시대 (2008~2013) ===
=== JIT 경쟁 시대 (2008~2013) ===
2008년 [[구글 크롬]]이 빠른 자바스크립트 엔진 [[V8]]을 들고 나오면서 '''브라우저 자바스크립트 속도 경쟁'''이 시작되었다. SpiderMonkey도 이에 맞서 [[JIT 컴파일러|JIT 컴파일러]]를 차례로 도입했다.
2008년 [[구글 크롬]]이 빠른 자바스크립트 엔진 [[V8]]을 들고 나오면서 '''브라우저 자바스크립트 속도 경쟁'''이 본격화되었다. 사파리의 SquirrelFish Extreme, 오페라의 Carakan, 인터넷 익스플로러 9의 Chakra까지 가세한 이 경쟁에서 SpiderMonkey도 [[JIT 컴파일러]]를 차례로 도입했다.
{| class="wikitable"
{| class="wikitable"
! 이름 !! 도입 !! 설명
! 이름 !! 도입 !! 설명
|-
|-
| '''TraceMonkey''' || 2009년, 파이어폭스 3.5 || 자주 실행되는 반복문의 실행 경로를 '추적'(tracing)해 기계어로 컴파일하는 '''트레이싱 JIT'''. 특정 벤치마크에서는 매우 빨랐지만, 코드 흐름이 복잡하면 효과가 떨어졌다.
| '''TraceMonkey''' || 2009년, 파이어폭스 3.5 || 자주 실행되는 반복문의 실행 경로를 '추적'(tracing)해 기계어로 컴파일하는 '''트레이싱 JIT'''. 단순한 반복문에서는 매우 빨랐지만, 코드 흐름이 복잡해지면 추적이 자주 깨져 효과가 떨어졌다.
|-
|-
| '''JägerMonkey''' || 2011년, 파이어폭스 4 || 함수 단위로 컴파일하는 '''메서드 JIT'''. TraceMonkey의 약점을 보완했다.
| '''JägerMonkey''' || 2011년, 파이어폭스 4 || 함수 단위로 컴파일하는 '''메서드 JIT'''. TraceMonkey가 약한 코드를 보완했다. 두 JIT이 함께 동작했다.
|-
|-
| '''IonMonkey''' || 2013년, 파이어폭스 18 || 중간 표현(IR)을 이용해 본격적인 최적화를 수행하는 '''최적화 컴파일러'''. 이후 약 8년간 최상위 계층으로 쓰였다.
| '''IonMonkey''' || 2013년, 파이어폭스 18 || 중간 표현(IR, MIR/LIR)을 이용해 전역 최적화를 수행하는 본격적인 '''최적화 컴파일러'''. 타입 추론(Type Inference) 시스템과 함께 동작했다.
|-
|-
| '''Baseline Compiler''' || 2013년, 파이어폭스 23 || 빠르게 컴파일하면서 타입 정보를 수집하는 중간 계층. TraceMonkey와 JägerMonkey를 대체했다.
| '''OdinMonkey''' || 2013년, 파이어폭스 22 || [[asm.js]] 전용 사전(AOT) 컴파일러.
|-
|-
| '''OdinMonkey''' || 2013년, 파이어폭스 22 || [[asm.js]] 전용 사전(AOT) 컴파일러. 후술.
| '''Baseline Compiler''' || 2013년, 파이어폭스 23 || 빠르게 컴파일하면서 인라인 캐시로 타입 정보를 수집하는 중간 계층. 이후 TraceMonkey와 JägerMonkey가 제거되었다.
|}
|}


=== asm.js와 WebAssembly ===
=== asm.js와 WebAssembly ===
2013년 모질라는 C/C++ 프로그램을 웹에서 거의 네이티브 속도로 돌리기 위해, 엔진이 쉽게 최적화할 수 있는 자바스크립트의 엄격한 부분집합 '''[[asm.js]]'''를 제안했다. SpiderMonkey는 <code>"use asm"</code> 지시문을 감지하면 이를 일반 JIT 대신 OdinMonkey로 바로 기계어로 컴파일했다. 이를 통해 [[유니티 (게임 엔진)|유니티]], [[언리얼 엔진]] 같은 게임 엔진이 처음으로 플러그인 없이 웹에서 돌아갈 수 있었고, 에픽 게임즈의 'Epic Citadel' 데모는 단 4일 만에 웹으로 포팅되었다.
2013년 모질라는 C/C++ 프로그램을 웹에서 거의 네이티브 속도로 돌리기 위해, 엔진이 쉽게 최적화할 수 있도록 엄격하게 제한한 자바스크립트의 부분집합 '''[[asm.js]]'''를 제안했다. 예를 들어 <code>x | 0</code>은 "x는 32비트 정수", <code>+x</code>는 "x는 실수"라는 뜻이 되어, 엔진은 이를 사실상 타입이 정해진 바이트코드처럼 다룰 수 있다. SpiderMonkey는 <code>"use asm"</code> 지시문을 감지하면 일반 JIT을 거치지 않고 OdinMonkey로 바로 기계어로 컴파일했다.


asm.js의 성공은 구글, 애플, 마이크로소프트를 설득해 정식 바이너리 형식인 '''[[WebAssembly]]'''를 공동 개발하는 계기가 되었다. WebAssembly는 2017년 파이어폭스 52에 탑재되었고, 같은 해 4대 브라우저에서 모두 지원되었다. 그리고 '''2026년''', 파이어폭스 148부터 SpiderMonkey의 asm.js 전용 최적화가 기본적으로 꺼졌으며, 관련 코드도 향후 완전히 삭제될 예정이다. asm.js 코드는 일반 자바스크립트로 계속 실행되므로 사이트가 깨지지는 않지만, 모질라는 WebAssembly로 다시 컴파일할 것을 권고했다.<ref name="asmjs">[https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-asmjs.html Saying goodbye to asm.js] - SpiderMonkey 블로그, 2026년 5월 20일.</ref> "asm.js가 없었다면 WebAssembly도 없었을 것"이라는 말처럼, 자기 손으로 낳은 기술을 자기 손으로 정리한 셈이다.
C/C++ 코드를 asm.js로 변환하는 컴파일러 '''[[엠스크립튼]]'''(Emscripten)과 결합해, [[유니티 (게임 엔진)|유니티]]와 [[언리얼 엔진]] 같은 게임 엔진이 처음으로 플러그인 없이 웹 표준 기술만으로 브라우저에서 돌아갈 수 있게 되었다. 에픽 게임즈의 'Epic Citadel' 데모는 단 4일 만에 웹으로 포팅되어 큰 화제가 되었다. 구글이 별도로 추진하던 '''네이티브 클라이언트'''(NaCl/PNaCl)와 경쟁 구도였는데, asm.js는 별도 샌드박스나 API 없이 기존 웹 기술 그대로 동작한다는 점이 강점이었다.


=== 퀀텀과 WarpMonkey (2017~2020) ===
asm.js의 성공은 구글, 애플, 마이크로소프트를 설득해 정식 바이너리 형식인 '''[[WebAssembly]]'''를 공동 개발하는 계기가 되었다. WebAssembly는 2017년 파이어폭스 52에 탑재되었고, 같은 해 4대 브라우저에서 모두 지원되었다. 구글도 2018년 PNaCl을 정리했다.
2017년 파이어폭스 57의 '''퀀텀'''(Quantum) 프로젝트 이후 모질라는 엔진 전반을 대대적으로 손봤다. SpiderMonkey 쪽에서는 다음과 같은 변화가 있었다.
* '''Baseline Interpreter'''(2019) - 바이트코드 인터프리터와 Baseline JIT 사이에 들어가는 새로운 계층으로, JIT 컴파일 전에도 빠르게 실행되도록 했다.
* '''CacheIR''' - 객체의 속성 접근, 함수 호출 등에서 관찰한 정보를 공통 중간 표현으로 기록하는 '''인라인 캐시''' 시스템. 모든 계층이 이 정보를 공유한다.
* '''WarpMonkey'''(2020, 파이어폭스 83) - 기존 IonMonkey의 타입 추론(Type Inference) 시스템을 걷어내고, CacheIR 정보를 바탕으로 최적화하는 새 최상위 계층. 코드가 단순해지고 메모리 사용량과 실제 웹 페이지 성능이 개선되었다.
* '''Stencil'''(2021) - 파서가 만든 결과물을 스레드 간에 안전하게 공유·캐시할 수 있는 형태로 바꿔, 페이지 로딩 시 파싱 비용을 줄였다.


=== 2020년대 ===
그리고 '''2026년''', 파이어폭스 148부터 SpiderMonkey의 asm.js 전용 최적화가 기본적으로 꺼졌으며 관련 코드도 향후 완전히 삭제될 예정이다. asm.js 코드는 평범한 자바스크립트로서 계속 실행되므로 사이트가 깨지지는 않지만, 연산이 많은 코드는 눈에 띄게 느려질 수 있어 모질라는 WebAssembly로 다시 컴파일할 것을 권고했다. 모질라는 별도의 asm.js 컴파일 경로가 유지보수 부담이자 가상 머신의 공격 표면이 된다는 점을 이유로 들었다.<ref name="asmjs">[https://spidermonkey.dev/blog/2026/05/20/saying-goodbye-to-asmjs.html Saying goodbye to asm.js] - SpiderMonkey 블로그, 2026년 5월 20일.</ref> "asm.js가 없었다면 WebAssembly도 없었을 것"이라는 말처럼, 자기 손으로 낳은 기술을 자기 손으로 정리한 셈이다.
* '''사이트 격리'''(Fission) 도입에 맞춰 메모리 사용량과 시작 속도를 최적화했다.
 
* 브라우저 벤치마크 [[Speedometer]] 3(2024년, 애플·구글·마이크로소프트·모질라 공동 개발)에서 V8과의 격차를 크게 좁혔다.
=== 퀀텀과 WarpMonkey (2017~2021) ===
* '''2025년 5월''', 파이어폭스 139에서 날짜·시간 처리의 고질적인 문제를 해결하는 새 표준 API '''[[Temporal (자바스크립트)|Temporal]]'''을 '''주요 브라우저 중 가장 먼저''' 기본 탑재했다.
2017년 파이어폭스 57의 '''퀀텀'''(Quantum) 프로젝트 이후 모질라는 Gecko 전반을 대대적으로 현대화했고, SpiderMonkey도 내부 구조를 크게 손봤다.
* '''2026년''', 앞서 말한 asm.js 최적화가 비활성화되었다.<ref name="asmjs" />
* '''Irregexp 도입'''(2020, 파이어폭스 78) - 정규 표현식 엔진을 V8의 '''Irregexp'''로 교체했다. 이를 위해 V8 코드를 그대로 가져와 쓸 수 있도록 얇은 호환 계층을 만들었다. 덕분에 lookbehind(후방 탐색), 명명된 캡처 그룹, 유니코드 속성 이스케이프 같은 최신 정규식 기능을 한꺼번에 지원하게 되었다. 경쟁 엔진의 코드를 공유해 쓰는 오픈 소스 협력의 대표 사례다.
* '''2026년''', 모질라는 [[앤트로픽]]과 협력해 AI 모델 Claude로 파이어폭스 코드를 2주간 분석해 22건의 취약점(그중 14건이 높은 등급)을 찾아 수정했다고 밝혔다. 이는 2025년 한 해 동안 수정된 높은 등급 취약점의 약 5분의 1에 해당하는 규모였다.<ref>[https://en.wikipedia.org/wiki/Firefox Firefox] - 영어 위키백과. 2026년 10월 기준.</ref>
* '''Baseline Interpreter'''(2019) - 바이트코드 인터프리터와 Baseline JIT 사이에 들어가는 새 계층. JIT 컴파일 전에도 인라인 캐시를 활용해 빠르게 실행된다.
* 파이어폭스 릴리스 주기가 2026년 하반기 '''4주에서 2주'''로 짧아지면서, SpiderMonkey도 같은 주기로 릴리스되고 있다. 2026년 10월 13일 파이어폭스 158이 출시되었다.
* '''CacheIR''' - 객체의 속성 접근, 함수 호출 등에서 관찰한 정보를 공통 중간 표현으로 기록하는 '''인라인 캐시''' 시스템. 모든 실행 계층이 이 정보를 공유한다.
* '''WarpMonkey'''(2020, 파이어폭스 83) - 기존 IonMonkey의 무거운 타입 추론 시스템을 걷어내고, CacheIR 정보를 바탕으로 최적화하는 새 최상위 계층. 코드가 단순해지고 메모리 사용량이 줄었으며, 실제 웹 페이지 성능이 개선되었다.
* '''Stencil'''(2021) - 파서 결과물을 스레드 간에 안전하게 공유하고 캐시할 수 있는 형태로 바꿔, 페이지 로딩 시 파싱 비용을 줄였다.
* '''사이트 격리'''(Fission, 2021) - 사이트마다 프로세스를 나누면서 프로세스 수가 크게 늘어나자, 엔진의 프로세스당 메모리 사용량과 시작 시간을 줄이는 최적화가 집중적으로 이루어졌다.
 
=== Speedometer 3 시대 (2022~2025) ===
2024년 애플·구글·마이크로소프트·모질라가 공동 개발한 브라우저 벤치마크 '''[[Speedometer]] 3'''가 공개되면서, 실제 웹 앱(리액트, 차트, 텍스트 편집기 등)에 가까운 작업을 기준으로 엔진을 최적화하는 흐름이 강해졌다. SpiderMonkey 팀은 이 시기 다음과 같은 개선을 이어 갔다.
* 객체를 처음부터 최종 크기로 할당하도록 힌트를 주는 최적화, 너서리(젊은 세대) 할당 확대, 메모리 할당기 경합 감소.
* 프로토타입 체인 탐색을 건너뛰는 '''Shape Teleportation''' 최적화의 성능 절벽(performance cliff) 완화.
* Ion 컴파일러 백엔드의 레지스터 할당 최적화. 특정 대형 WebAssembly 모듈에서 컴파일 시간을 수십 배 단축했다는 사례가 블로그로 소개되기도 했다.
* WebAssembly '''추측 인라이닝'''(speculative inlining), '''지연 계층화'''(lazy tiering) 등 고급 최적화 도입.
 
=== 2025~2026년 ===
* '''2025년 5월''' - 파이어폭스 139에서 날짜·시간 처리의 고질적인 문제(<code>Date</code> 객체의 각종 함정)를 해결하는 새 표준 API '''[[Temporal (자바스크립트)|Temporal]]'''을 '''주요 브라우저 중 가장 먼저''' 기본 탑재했다.
* '''2025년''' - 웹 호환성 개선 프로젝트 '''Interop 2025'''에서 파이어폭스는 연초 46점에서 연말 99점으로 점수를 끌어올렸다(실험판 기준). 이 가운데 상당수가 자바스크립트·DOM API 관련 항목이었다.<ref>[https://hacks.mozilla.org/2026/02/launching-interop-2026/ Launching Interop 2026] - Mozilla Hacks, 2026년 2월.</ref>
* '''2026년 2월''' - 파이어폭스 148에서 asm.js 최적화를 기본 비활성화했다.<ref name="asmjs" />
* '''2026년''' - 모질라는 [[앤트로픽]]과 협력해 AI 모델 Claude로 파이어폭스 코드를 2주간 분석해 22건의 보안 취약점(그중 14건이 높은 등급)과 90여 건의 일반 버그를 찾아 수정했다고 밝혔다. 이는 2025년 한 해 동안 수정된 높은 등급 취약점의 약 5분의 1에 해당하는 규모였다.<ref name="enwiki-ff">[https://en.wikipedia.org/wiki/Firefox Firefox] - 영어 위키백과. 2026년 10월 기준.</ref>
* '''2026년 하반기''' - 파이어폭스 릴리스 주기가 '''4주에서 2주'''로 짧아지면서 SpiderMonkey도 같은 주기로 릴리스되고 있다. 2026년 10월 13일 파이어폭스 158이 출시되었다.


== 구조 ==
== 구조 ==
=== 실행 계층 ===
=== 실행 과정 ===
현대 SpiderMonkey는 코드가 얼마나 자주 실행되는지에 따라 점점 더 강력한 계층으로 '''승급'''(tier-up)시키는 다단계 구조를 가진다.
현대 SpiderMonkey는 코드가 얼마나 자주 실행되는지에 따라 점점 더 강력한 계층으로 '''승급'''(tier-up)시키는 다단계 구조를 가진다. 처음부터 모든 코드를 최고 수준으로 최적화하면 컴파일 시간이 너무 오래 걸리고, 반대로 인터프리터로만 실행하면 느리기 때문에 '''자주 쓰는 코드에만 비싼 최적화를 투자'''하는 전략이다.
{| class="wikitable"
{| class="wikitable"
! 계층 !! 역할
! 단계 !! 역할 !! 특징
|-
|-
| '''파서 / Stencil''' || 소스 코드를 바이트코드로 변환한다. 당장 실행하지 않는 함수는 대충 훑기만 하는 '''지연 파싱'''(lazy parsing)으로 시간을 아낀다.
| '''파서 / Stencil''' || 소스 코드를 바이트코드로 변환 || 당장 실행하지 않는 함수는 문법 검사만 하고 넘어가는 '''지연 파싱'''(lazy parsing)으로 시간을 아낀다.
|-
|-
| '''바이트코드 인터프리터''' || 처음 실행되는 코드를 실행한다.
| '''바이트코드 인터프리터''' || 처음 실행되는 코드를 실행 || 가장 느리지만 준비 시간이 0이다.
|-
|-
| '''Baseline Interpreter''' || 인라인 캐시를 활용하는 빠른 인터프리터.
| '''Baseline Interpreter''' || 인라인 캐시를 활용한 빠른 인터프리터 || 컴파일 없이도 관찰한 타입 정보를 활용한다.
|-
|-
| '''Baseline Compiler''' || 바이트코드를 빠르게 기계어로 옮기는 단순 JIT.
| '''Baseline Compiler''' || 바이트코드를 단순하게 기계어로 번역 || 컴파일이 매우 빠르며, 계속 타입 정보를 수집한다.
|-
|-
| '''WarpMonkey'''(Ion) || 아주 자주 실행되는 '''핫 코드'''를 인라이닝, 타입 특화 등 고급 최적화로 컴파일한다.
| '''WarpMonkey'''(Ion 백엔드) || 아주 자주 실행되는 '''핫 코드'''를 고급 최적화 || 함수 인라이닝, 타입 특화, 불필요한 검사 제거, 레지스터 할당 등. 백그라운드 스레드에서 컴파일한다.
|}
|}
최적화 과정에서 가정이 깨지면(예: 지금까지 숫자만 들어오던 변수에 문자열이 들어오면) 최적화된 코드를 버리고 하위 계층으로 되돌아가는 '''역최적화'''(deoptimization, bailout)를 수행한다.
최적화 과정에서 세운 가정이 깨지면(예: 지금까지 숫자만 들어오던 변수에 갑자기 문자열이 들어오면) 최적화된 코드를 버리고 하위 계층으로 되돌아가는 '''역최적화'''(deoptimization, bailout)를 수행한다. 이 때문에 자바스크립트 성능 최적화의 기본 요령으로 "변수와 객체의 타입·모양을 일관되게 유지하라"는 조언이 나온다.


WebAssembly는 별도의 파이프라인을 쓴다. 빠르게 컴파일하는 '''베이스라인 컴파일러'''(RabaldrMonkey)로 먼저 실행한 뒤, 백그라운드에서 '''최적화 컴파일러'''(BaldrMonkey, Ion 기반)로 다시 컴파일해 교체한다. WebAssembly [[가비지 컬렉션]](WasmGC), 예외 처리, SIMD, 꼬리 호출 등 최신 기능도 지원한다.
=== 인라인 캐시와 CacheIR ===
자바스크립트에서 <code>obj.x</code>처럼 속성에 접근하는 코드는, 매번 객체를 뒤져 'x'가 어디 있는지 찾으면 매우 느리다. SpiderMonkey는 이 지점에서 한 번 찾은 결과를 '''인라인 캐시'''(IC)로 기억해 두고, 다음번에 같은 모양의 객체가 오면 바로 결과를 꺼낸다. 이때 "어떤 조건을 검사하고 어떤 동작을 했는지"를 '''CacheIR'''이라는 공통 중간 언어로 기록하는데, 인터프리터·Baseline·Warp 모든 계층이 이 기록을 재활용한다. 특히 WarpMonkey는 CacheIR 기록을 그대로 최적화 컴파일의 재료로 쓰기 때문에, 여러 계층이 따로 타입 정보를 관리하던 과거보다 구조가 훨씬 단순해졌다.


=== 객체와 Shape ===
=== 객체와 Shape ===
자바스크립트 객체는 마음대로 속성을 추가·삭제할 수 있어 그대로 두면 매우 느리다. SpiderMonkey는 같은 속성 구성을 가진 객체들이 같은 '''Shape'''(V8의 Hidden Class와 비슷한 개념)를 공유하도록 하여, JIT 코드가 "이 Shape이면 속성은 몇 번째 칸에 있다"는 식으로 빠르게 접근할 수 있게 한다.
자바스크립트 객체는 실행 중에 속성을 마음대로 추가·삭제할 수 있어 그대로 두면 매우 느리다. SpiderMonkey는 같은 속성 구성(키와 순서)을 가진 객체들이 같은 '''Shape'''을 공유하도록 한다(V8의 Hidden Class와 비슷한 개념). JIT 코드는 "이 Shape이면 x 속성은 몇 번째 칸에 있다"는 식으로 빠르게 접근할 수 있다. 배열은 별도의 '''요소'''(elements) 저장소에 연속으로 저장해 C 배열에 가까운 속도를 낸다.


=== 가비지 컬렉터 ===
=== 가비지 컬렉터 ===
SpiderMonkey의 [[가비지 컬렉션|가비지 컬렉터]]는 다음과 같은 특징을 가진다.
SpiderMonkey의 [[가비지 컬렉션|가비지 컬렉터]]는 다음과 같은 특징을 가진다.
* '''세대별'''(generational) - 대부분의 객체는 금방 죽는다는 점을 이용해, 새로 만든 객체를 '너서리'(nursery)에 두고 자주 빠르게 정리한다.
* '''세대별'''(generational) - 대부분의 객체는 금방 버려진다는 점을 이용해, 새 객체를 '''너서리'''(nursery)라는 작은 영역에 두고 자주 빠르게 정리한다. 살아남은 객체만 오래 사는 영역(tenured heap)으로 옮긴다.
* '''점진적'''(incremental) - 수집 작업을 잘게 쪼개 실행해 화면 멈춤을 줄인다.
* '''점진적'''(incremental) - 수집 작업을 잘게 쪼개 브라우저가 쉬는 틈에 실행해, 화면이 멈추는 시간을 줄인다.
* '''압축'''(compacting) - 살아남은 객체를 모아 메모리 단편화를 줄인다.
* '''압축'''(compacting) - 살아남은 객체를 한데 모아 메모리 단편화를 줄인다.
* '''병렬·동시 처리''' - 일부 작업을 여러 스레드에서 처리한다.
* '''병렬·동시 처리''' - 마킹, 정리(sweeping) 등 일부 작업을 여러 스레드에서 처리한다.
* '''사전 승격'''(pretenuring) - 오래 살아남을 것으로 예상되는 할당 지점의 객체는 처음부터 오래 사는 영역에 할당한다.
 
=== WebAssembly 파이프라인 ===
WebAssembly는 자바스크립트와 별개의 파이프라인을 쓴다. 웹 페이지가 무거운 WebAssembly 모듈을 불러오면, 먼저 빠르게 컴파일하는 '''베이스라인 컴파일러'''(RabaldrMonkey)로 즉시 실행을 시작하고, 백그라운드에서 '''최적화 컴파일러'''(BaldrMonkey, Ion 백엔드 공유)로 다시 컴파일해 완성되는 대로 교체한다. 한동안 ARM64에서는 Rust로 작성된 코드 생성기 '''[[Cranelift]]'''를 최적화 계층으로 실험적으로 쓰기도 했지만, 이후 Ion 기반으로 일원화되었다.
 
주요 WebAssembly 기능의 파이어폭스 탑재 시기는 다음과 같다.
{| class="wikitable"
! 기능 !! 파이어폭스 버전 !! 설명
|-
| WebAssembly MVP || 52 (2017년) || 최초 지원
|-
| 128비트 SIMD || 89 (2021년) || 벡터 연산으로 이미지·영상·AI 연산 가속
|-
| 예외 처리 || 100 (2022년) || C++ 예외 등을 WebAssembly에서 직접 처리
|-
| '''WasmGC''' || 120 (2023년) || 브라우저의 가비지 컬렉터를 WebAssembly에서 사용. [[코틀린]], [[다트 (프로그래밍 언어)|다트]](플러터), 자바 등 GC 언어를 효율적으로 컴파일할 수 있게 되었다.
|-
| 꼬리 호출 || 121 (2023년) || OCaml, Scheme 등 함수형 언어의 꼬리 재귀 최적화
|-
| exnref || 131 (2024년) || 개선된 예외 처리 방식
|}
이 밖에 64비트 메모리(Memory64), 다중 메모리, 자바스크립트 Promise 통합(JSPI) 등 최신 제안도 순차적으로 구현되고 있다.
 
=== 최근 탑재된 자바스크립트 기능 ===
{| class="wikitable"
! 기능 !! 파이어폭스 버전 !! 설명
|-
| Set 메서드 || 127 (2024년) || <code>union</code>, <code>intersection</code> 등 집합 연산
|-
| <code>Float16Array</code> || 129 (2024년) || 16비트 부동소수점 배열. 머신러닝·그래픽 데이터 처리용
|-
| Iterator Helpers || 131 (2024년) || 이터레이터에 <code>map</code>, <code>filter</code>, <code>take</code> 등 사용
|-
| <code>Uint8Array</code> Base64 || 133 (2024년) || 바이너리와 Base64·16진수 문자열 간 변환
|-
| <code>RegExp.escape</code> || 134 (2025년) || 문자열을 정규식에 안전하게 넣기 위한 이스케이프
|-
| '''Temporal''' || 139 (2025년) || 새 날짜·시간 API. 주요 브라우저 최초
|}


=== 임베딩 ===
=== 임베딩 ===
SpiderMonkey는 '''JSAPI'''라는 C++ 임베딩 API를 제공해 다른 프로그램에 자바스크립트 실행 기능을 넣을 수 있다. 다만 V8과 마찬가지로 API가 버전마다 자주 바뀌어, 외부 프로젝트는 보통 파이어폭스 ESR 버전에 맞춰 업데이트한다.
SpiderMonkey는 '''JSAPI'''라는 C++ 임베딩 API를 제공해, 다른 프로그램에 자바스크립트 실행 기능을 넣을 수 있다. 임베딩하는 쪽은 '''전역 객체'''와 '''컴파트먼트'''(compartment, 보안 경계 단위)를 만들고, 그 안에서 스크립트를 실행하며 C++ 함수를 자바스크립트에 노출할 수 있다. 다만 V8과 마찬가지로 API가 버전마다 자주 바뀌기 때문에, 외부 프로젝트는 보통 파이어폭스 ESR(장기 지원판) 버전을 기준으로 따라간다. Rust에서는 '''mozjs''' 크레이트를 통해 쓸 수 있다.


== 사용처 ==
== 사용처 ==
* '''[[Firefox|파이어폭스]]''' 및 [[Gecko]] 기반 브라우저 - [[토르 브라우저|Tor Browser]], [[LibreWolf]], [[Waterfox]], [[Floorp]], [[Zen Browser]], Mullvad Browser 등.
=== 브라우저와 모질라 제품 ===
* '''[[Firefox|파이어폭스]]''' - 데스크톱과 안드로이드. iOS판은 애플 정책상 WebKit의 JavaScriptCore를 쓴다.
* '''[[모질라 썬더버드|썬더버드]]''' - 모질라의 이메일 클라이언트.
* '''[[모질라 썬더버드|썬더버드]]''' - 모질라의 이메일 클라이언트.
* '''[[GNOME]]''' - 리눅스 데스크톱 환경 그놈의 자바스크립트 바인딩 '''GJS'''가 SpiderMonkey를 사용한다. 그놈 셸의 상당 부분과 여러 기본 앱이 자바스크립트로 작성되어 있다.
* '''[[Gecko]] 기반 파생 브라우저''' - [[토르 브라우저|Tor Browser]], Mullvad Browser, [[LibreWolf]], [[Waterfox]], [[Floorp]], [[Zen Browser]] 등.
* '''[[MongoDB]]''' - 서버 측 자바스크립트 실행(일부 기능)과 과거의 <code>mongo</code> 셸에서 SpiderMonkey를 사용했다. 원래 V8을 쓰다가 3.2 버전부터 SpiderMonkey로 바꾸었다.
 
* '''[[Servo]]''' - 모질라에서 시작해 현재 [[리눅스 재단]] 산하에서 개발되는 Rust 기반 브라우저 엔진. Rust 바인딩(mozjs)을 통해 SpiderMonkey를 쓴다.
=== 브라우저 밖 ===
* '''[[어도비 애크로뱃]]''' - PDF 문서 안의 자바스크립트 실행에 SpiderMonkey 기반 엔진을 사용하는 것으로 알려져 있다.
* '''[[GNOME]]''' - 리눅스 데스크톱 환경 그놈의 자바스크립트 바인딩 '''GJS'''가 SpiderMonkey를 사용한다. [[그놈 셸]]의 상당 부분과 여러 기본 앱이 자바스크립트로 작성되어 있어, 리눅스 데스크톱 사용자는 브라우저를 켜지 않아도 SpiderMonkey를 쓰고 있는 셈이다.
* '''엣지 컴퓨팅''' - [[패스틀리]](Fastly) 등은 SpiderMonkey 자체를 WebAssembly로 컴파일해 서버리스 환경에서 자바스크립트를 실행하는 방식(StarlingMonkey 등)을 사용한다. 이를 위해 JIT 없이도 빠르게 동작하는 '''Portable Baseline Interpreter'''가 개발되었다.
* '''[[MongoDB]]''' - 서버 측 자바스크립트 실행 기능(<code>$where</code>, mapReduce 등)과 과거의 <code>mongo</code> 셸에서 SpiderMonkey를 사용했다. 원래 V8을 쓰다가 3.2 버전부터 SpiderMonkey로 바꾸었다.
* '''[[Servo]]''' - 모질라에서 시작해 현재 [[리눅스 재단]] 산하에서 개발되는 Rust 기반 브라우저 엔진. mozjs를 통해 SpiderMonkey를 쓴다.
* '''[[어도비 애크로뱃]]''' - PDF 문서 안의 자바스크립트(양식 계산 등) 실행에 SpiderMonkey 기반 엔진을 사용하는 것으로 알려져 있다.
* '''[[아파치 CouchDB]]''' - 맵리듀스 뷰를 자바스크립트로 정의할 때 오랫동안 SpiderMonkey를 사용했다.
* '''엣지 컴퓨팅''' - [[패스틀리]](Fastly) 등은 SpiderMonkey 자체를 WebAssembly로 컴파일해 서버리스 환경에서 자바스크립트를 실행하는 방식(StarlingMonkey 등)을 쓴다. 이를 위해 JIT 없이도 빠르게 동작하는 '''Portable Baseline Interpreter'''(PBL)가 개발되었다. "자바스크립트 엔진을 WebAssembly로 돌리고, 그 안에서 자바스크립트를 실행한다"는 다소 기묘한 구조지만, 보안 격리와 빠른 시작 시간 덕분에 실용적으로 쓰이고 있다.
 
== 보안 ==
자바스크립트 엔진은 웹 페이지가 마음대로 보낸 코드를 실행하고, 특히 JIT 컴파일러는 '''실행 중에 기계어를 만들어 내기''' 때문에 브라우저에서 가장 공격받기 쉬운 부분 중 하나다. JIT의 최적화 가정을 속여 타입 혼동(type confusion)을 일으키면, 메모리를 마음대로 읽고 쓰는 공격으로 이어질 수 있다.
* '''2019년''' - 암호화폐 거래소 [[코인베이스]] 직원들을 노린 표적 공격에서, SpiderMonkey의 배열 처리 관련 타입 혼동 취약점(CVE-2019-11707)이 샌드박스 탈출 취약점과 연계되어 실제로 악용되었다. 모질라는 긴급 업데이트로 대응했다.
* '''2024년''' - 해킹 대회 [[Pwn2Own]] 밴쿠버에서 보안 연구자 만프레드 폴(Manfred Paul)이 SpiderMonkey 취약점을 이용해 파이어폭스 공략에 성공했고, 모질라는 약 하루 만에 수정판을 배포했다.
 
이에 대응해 SpiderMonkey는 JIT 코드 영역에 쓰기와 실행을 동시에 허용하지 않는 '''W^X''' 정책, 대규모 [[퍼징]], 사이트 격리(Fission)와 프로세스 샌드박스 등의 다중 방어를 적용하고 있다. 앞서 말한 asm.js 코드 제거도 '공격 표면 축소'라는 같은 맥락이며, 2026년에는 AI 모델을 활용한 코드 감사까지 도입되었다.<ref name="enwiki-ff" />


== 다른 엔진과의 비교 ==
== 다른 엔진과의 비교 ==
{| class="wikitable"
{| class="wikitable"
! 엔진 !! 개발 !! 주요 사용처 !! 특징
! 엔진 !! 개발 !! 주요 사용처 !! 최상위 최적화 계층 !! 특징
|-
|-
| '''SpiderMonkey''' || 모질라 || 파이어폭스 || 최초의 자바스크립트 엔진. 새 표준 기능을 일찍 탑재하는 편
| '''SpiderMonkey''' || 모질라 || 파이어폭스, 그놈 || WarpMonkey || 최초의 자바스크립트 엔진. 새 표준 기능을 일찍 탑재하는 편
|-
|-
| [[V8]] || 구글 || 크롬, 엣지, [[Node.js]], [[Deno]] || 점유율 압도적 1위. 서버 측 생태계까지 장악
| [[V8]] || 구글 || 크롬·엣지 등 크로미움 계열, [[Node.js]], [[Deno]] || TurboFan (+Maglev) || 점유율 압도적 1위. 서버 측 생태계까지 장악
|-
|-
| JavaScriptCore || 애플 || [[사파리 (웹 브라우저)|사파리]], [[Bun]] || 4단계 JIT(LLInt, Baseline, DFG, FTL). iOS의 모든 브라우저가 사용
| JavaScriptCore || 애플 || [[사파리 (웹 브라우저)|사파리]], iOS의 모든 브라우저, [[Bun]] || FTL || 4단계 구조(LLInt, Baseline, DFG, FTL)
|-
|-
| Chakra || 마이크로소프트 || 구 [[마이크로소프트 엣지|엣지]](EdgeHTML) || 엣지의 크로미움 전환 후 사실상 개발 종료
| Chakra || 마이크로소프트 || 구 [[마이크로소프트 엣지|엣지]](EdgeHTML) || - || 엣지의 크로미움 전환 후 사실상 개발 종료
|}
|}
일반적인 벤치마크에서는 V8과 JavaScriptCore가 앞서는 경우가 많지만, 실제 웹 사용 체감에서는 세 엔진 모두 차이가 크지 않은 수준까지 수렴했다. 엔진의 승부처는 단순 연산 속도보다 페이지 시작 시간, 메모리 사용량, 큰 웹 앱의 반응성 쪽으로 옮겨 가는 추세다.


== 여담 ==
== 여담 ==
* 모질라의 엔진 이름 짓기 전통 덕분에 버그질라와 개발 문서에는 온갖 '○○Monkey'가 등장한다.
* 모질라의 엔진 이름 짓기 전통 덕분에 버그질라와 개발 문서에는 온갖 '○○Monkey'가 등장한다. 엔진 내부 문서에서는 SpiderMonkey를 줄여 '''SM'''이라고 부르기도 한다.
* '''[[브렌던 아이크]]'''는 자바스크립트와 SpiderMonkey를 만든 뒤 모질라 재단 설립에 참여하고 모질라 CTO와 CEO를 지냈으나, 2014년 CEO 취임 직후 과거의 정치 기부 논란으로 열흘 만에 사임했다. 이후 [[브레이브 (웹 브라우저)|브레이브]]를 창업했는데, 브레이브는 크로미움 기반이라 자신이 만든 엔진이 아닌 V8을 쓰고 있다.
* '''[[브렌던 아이크]]'''는 자바스크립트와 SpiderMonkey를 만든 뒤 모질라 재단 설립에 참여하고 모질라 CTO와 CEO를 지냈으나, 2014년 CEO 취임 직후 과거의 정치 기부 논란으로 열흘 남짓 만에 사임했다. 이후 [[브레이브 (웹 브라우저)|브레이브]]를 창업했는데, 브레이브는 크로미움 기반이라 자신이 만든 엔진이 아닌 V8을 쓰고 있다.
* 파이어폭스에서 <code>about:support</code>를 열면 JIT 관련 설정 상태를 확인할 수 있고, 개발자는 <code>about:config</code>에서 <code>javascript.options.</code>로 시작하는 항목으로 개별 JIT 계층을 켜고 끌 수 있다.
* 정규식 엔진은 V8에서, 일부 기능 구현은 다른 엔진과 공유하는 등 경쟁 엔진끼리 코드를 주고받는 일이 드물지 않다. 반대로 V8 역시 SpiderMonkey 팀이 만든 테스트와 제안의 덕을 보고 있으며, 표준 위원회 [[TC39]]에서는 세 엔진 개발자들이 함께 언어의 미래를 논의한다.
* 파이어폭스에서 <code>about:config</code>를 열고 <code>javascript.options.</code>로 시작하는 항목을 보면 개별 JIT 계층(Baseline, Ion/Warp 등)을 켜고 끌 수 있다. 보안을 극도로 중시하는 일부 사용자는 JIT을 꺼서 공격 표면을 줄이기도 한다(대신 느려진다).
* 엔진 소스 코드 곳곳에는 <code>[SMDOC]</code>이라는 표식이 붙은 상세한 설계 설명 주석이 있어, 엔진 내부를 공부하려는 사람들에게 좋은 교재가 된다.


== 관련 문서 ==
== 관련 문서 ==
135번째 줄: 210번째 줄:
* [[Firefox|파이어폭스]]
* [[Firefox|파이어폭스]]
* [[WebAssembly]]
* [[WebAssembly]]
* [[asm.js]]
* [[JIT 컴파일러]]
* [[JIT 컴파일러]]


2026년 10월 16일 (금) 21:22 기준 최신판

자바스크립트 엔진
브라우저 내장 V8 V8 (크롬·크로미움) · SpiderMonkey SpiderMonkey (파이어폭스) · JavaScriptCore JavaScriptCore (사파리) · LibJS (래디버드)
경량·임베디드 QuickJS · Hermes (리액트 네이티브) · Duktape · JerryScript · Boa · Espruino
런타임 Node.js Node.js · Deno Deno · Bun
개발 종료 Chakra Chakra · JScript (인터넷 익스플로러) · Carakan (오페라) · Rhino · Nashorn (자바)
관련 기술 자바스크립트 · ECMAScript · WebAssembly · JIT 컴파일러 · 가비지 컬렉션 · 브라우저 엔진
SpiderMonkey
SpiderMonkey의 로고
원작자 브렌던 아이크(Brendan Eich) / 넷스케이프
개발자 모질라 재단 / 모질라 코퍼레이션
발표일 1995년 (넷스케이프 내비게이터 2.0)
버전 정보 파이어폭스와 같은 번호로 릴리스 (2026년 10월 현재 158)
개발 상태 개발 중
프로그래밍 언어 C++, Rust, 자바스크립트
운영 체제 Windows, macOS, 리눅스, 안드로이드, BSD 계열 등
플랫폼 x86, x86-64, ARM, ARM64, MIPS64, LoongArch64, RISC-V 64 등
종류 자바스크립트 엔진, WebAssembly 엔진
라이선스 모질라 공개 라이선스 2.0
웹 사이트 spidermonkey.dev

개요[편집 / 원본 편집]

SpiderMonkey(스파이더몽키)는 모질라가 개발하는 오픈 소스 자바스크립트 엔진이자 WebAssembly 엔진이다. 파이어폭스를 비롯한 Gecko 기반 브라우저에서 웹 페이지의 자바스크립트와 WebAssembly 코드를 해석하고 실행하는 역할을 맡는다.

1995년 넷스케이프의 브렌던 아이크가 자바스크립트라는 언어를 만들면서 함께 만든 세계 최초의 자바스크립트 엔진이 그 시초다. 즉 자바스크립트와 나이가 같고, 지금도 쓰이는 엔진 중 가장 오래되었다. 구글의 V8, 애플의 JavaScriptCore와 함께 현재 남아 있는 3대 브라우저 자바스크립트 엔진으로 꼽히며, 이 셋이 사실상 전 세계 웹의 자바스크립트 실행을 나눠 맡고 있다.

C++를 중심으로 작성되었고 일부 구성 요소는 Rust로 작성되어 있다. 라이선스는 모질라 공개 라이선스(MPL) 2.0이다. 브라우저 밖에서도 쓸 수 있도록 C++ 임베딩 API(JSAPI)와 독립 실행용 셸(js)을 제공하며, GNOME, MongoDB 등 다양한 프로그램에 내장되어 쓰인다.

엔진 성능 경쟁에서는 2008년 이후 줄곧 V8에 끌려가는 처지였지만, 표준 기능을 일찍 구현하는 편이며 asm.js를 통해 WebAssembly의 탄생을 이끌어 낸 엔진이라는 점에서 웹 역사에 남긴 족적이 크다.

명칭[편집 / 원본 편집]

이름의 정확한 유래는 공식적으로 자세히 남아 있지 않다. 다만 이후 모질라는 새로운 JIT 컴파일러를 만들 때마다 TraceMonkey, JägerMonkey, IonMonkey, OdinMonkey, WarpMonkey처럼 ○○Monkey라는 이름을 붙이는 전통을 이어 왔다. WebAssembly 컴파일러에는 북유럽 신화에서 따온 BaldrMonkey(발드르), RabaldrMonkey 같은 이름도 쓰였다. 한국어로는 '스파이더몽키'라고 읽는다.

역사[편집 / 원본 편집]

탄생 (1995~1998)[편집 / 원본 편집]

1995년 넷스케이프에 입사한 브렌던 아이크는 웹 페이지에 넣을 간단한 스크립트 언어를 단 10일 만에 설계해 구현했다. 이 언어는 Mocha → LiveScript를 거쳐 JavaScript라는 이름으로 넷스케이프 내비게이터 2.0에 탑재되었다. 이때 언어를 실행하던 인터프리터가 SpiderMonkey의 원형이다. 당시에는 성능보다 '일단 돌아가는 것'이 목표였기 때문에, 코드를 트리 형태로 해석해 실행하는 매우 단순한 인터프리터였다.

이후 자바스크립트가 ECMA 인터내셔널에서 ECMAScript라는 이름으로 표준화되었고(1997년), SpiderMonkey는 이 표준을 따라 발전했다.

오픈 소스화 (1998~2007)[편집 / 원본 편집]

1998년 넷스케이프가 브라우저 소스 코드를 공개하면서 모질라 프로젝트가 출범했고, 자바스크립트 엔진도 C로 재작성되어 SpiderMonkey라는 이름으로 오픈 소스가 되었다. 이후 모질라 스위트, 파이어폭스(2004), 썬더버드 등 모질라의 모든 제품에 들어갔다.

이 시기 모질라는 자바(Java)로 작성된 또 하나의 자바스크립트 엔진 Rhino도 함께 관리했는데, Rhino는 이후 자바 생태계의 스크립트 엔진으로 독자적인 길을 걸었다. 또 어도비가 플래시의 액션스크립트 3 가상 머신(Tamarin)을 모질라에 기증해 SpiderMonkey와 통합하려는 계획(ActionMonkey)이 있었으나, ECMAScript 4 표준이 무산되면서 흐지부지되었다.

JIT 경쟁 시대 (2008~2013)[편집 / 원본 편집]

2008년 구글 크롬이 빠른 자바스크립트 엔진 V8을 들고 나오면서 브라우저 자바스크립트 속도 경쟁이 본격화되었다. 사파리의 SquirrelFish Extreme, 오페라의 Carakan, 인터넷 익스플로러 9의 Chakra까지 가세한 이 경쟁에서 SpiderMonkey도 JIT 컴파일러를 차례로 도입했다.

이름 도입 설명
TraceMonkey 2009년, 파이어폭스 3.5 자주 실행되는 반복문의 실행 경로를 '추적'(tracing)해 기계어로 컴파일하는 트레이싱 JIT. 단순한 반복문에서는 매우 빨랐지만, 코드 흐름이 복잡해지면 추적이 자주 깨져 효과가 떨어졌다.
JägerMonkey 2011년, 파이어폭스 4 함수 단위로 컴파일하는 메서드 JIT. TraceMonkey가 약한 코드를 보완했다. 두 JIT이 함께 동작했다.
IonMonkey 2013년, 파이어폭스 18 중간 표현(IR, MIR/LIR)을 이용해 전역 최적화를 수행하는 본격적인 최적화 컴파일러. 타입 추론(Type Inference) 시스템과 함께 동작했다.
OdinMonkey 2013년, 파이어폭스 22 asm.js 전용 사전(AOT) 컴파일러.
Baseline Compiler 2013년, 파이어폭스 23 빠르게 컴파일하면서 인라인 캐시로 타입 정보를 수집하는 중간 계층. 이후 TraceMonkey와 JägerMonkey가 제거되었다.

asm.js와 WebAssembly[편집 / 원본 편집]

2013년 모질라는 C/C++ 프로그램을 웹에서 거의 네이티브 속도로 돌리기 위해, 엔진이 쉽게 최적화할 수 있도록 엄격하게 제한한 자바스크립트의 부분집합 asm.js를 제안했다. 예를 들어 x | 0은 "x는 32비트 정수", +x는 "x는 실수"라는 뜻이 되어, 엔진은 이를 사실상 타입이 정해진 바이트코드처럼 다룰 수 있다. SpiderMonkey는 "use asm" 지시문을 감지하면 일반 JIT을 거치지 않고 OdinMonkey로 바로 기계어로 컴파일했다.

C/C++ 코드를 asm.js로 변환하는 컴파일러 엠스크립튼(Emscripten)과 결합해, 유니티와 언리얼 엔진 같은 게임 엔진이 처음으로 플러그인 없이 웹 표준 기술만으로 브라우저에서 돌아갈 수 있게 되었다. 에픽 게임즈의 'Epic Citadel' 데모는 단 4일 만에 웹으로 포팅되어 큰 화제가 되었다. 구글이 별도로 추진하던 네이티브 클라이언트(NaCl/PNaCl)와 경쟁 구도였는데, asm.js는 별도 샌드박스나 API 없이 기존 웹 기술 그대로 동작한다는 점이 강점이었다.

asm.js의 성공은 구글, 애플, 마이크로소프트를 설득해 정식 바이너리 형식인 WebAssembly를 공동 개발하는 계기가 되었다. WebAssembly는 2017년 파이어폭스 52에 탑재되었고, 같은 해 4대 브라우저에서 모두 지원되었다. 구글도 2018년 PNaCl을 정리했다.

그리고 2026년, 파이어폭스 148부터 SpiderMonkey의 asm.js 전용 최적화가 기본적으로 꺼졌으며 관련 코드도 향후 완전히 삭제될 예정이다. asm.js 코드는 평범한 자바스크립트로서 계속 실행되므로 사이트가 깨지지는 않지만, 연산이 많은 코드는 눈에 띄게 느려질 수 있어 모질라는 WebAssembly로 다시 컴파일할 것을 권고했다. 모질라는 별도의 asm.js 컴파일 경로가 유지보수 부담이자 가상 머신의 공격 표면이 된다는 점을 이유로 들었다.[1] "asm.js가 없었다면 WebAssembly도 없었을 것"이라는 말처럼, 자기 손으로 낳은 기술을 자기 손으로 정리한 셈이다.

퀀텀과 WarpMonkey (2017~2021)[편집 / 원본 편집]

2017년 파이어폭스 57의 퀀텀(Quantum) 프로젝트 이후 모질라는 Gecko 전반을 대대적으로 현대화했고, SpiderMonkey도 내부 구조를 크게 손봤다.

  • Irregexp 도입(2020, 파이어폭스 78) - 정규 표현식 엔진을 V8의 Irregexp로 교체했다. 이를 위해 V8 코드를 그대로 가져와 쓸 수 있도록 얇은 호환 계층을 만들었다. 덕분에 lookbehind(후방 탐색), 명명된 캡처 그룹, 유니코드 속성 이스케이프 같은 최신 정규식 기능을 한꺼번에 지원하게 되었다. 경쟁 엔진의 코드를 공유해 쓰는 오픈 소스 협력의 대표 사례다.
  • Baseline Interpreter(2019) - 바이트코드 인터프리터와 Baseline JIT 사이에 들어가는 새 계층. JIT 컴파일 전에도 인라인 캐시를 활용해 빠르게 실행된다.
  • CacheIR - 객체의 속성 접근, 함수 호출 등에서 관찰한 정보를 공통 중간 표현으로 기록하는 인라인 캐시 시스템. 모든 실행 계층이 이 정보를 공유한다.
  • WarpMonkey(2020, 파이어폭스 83) - 기존 IonMonkey의 무거운 타입 추론 시스템을 걷어내고, CacheIR 정보를 바탕으로 최적화하는 새 최상위 계층. 코드가 단순해지고 메모리 사용량이 줄었으며, 실제 웹 페이지 성능이 개선되었다.
  • Stencil(2021) - 파서 결과물을 스레드 간에 안전하게 공유하고 캐시할 수 있는 형태로 바꿔, 페이지 로딩 시 파싱 비용을 줄였다.
  • 사이트 격리(Fission, 2021) - 사이트마다 프로세스를 나누면서 프로세스 수가 크게 늘어나자, 엔진의 프로세스당 메모리 사용량과 시작 시간을 줄이는 최적화가 집중적으로 이루어졌다.

Speedometer 3 시대 (2022~2025)[편집 / 원본 편집]

2024년 애플·구글·마이크로소프트·모질라가 공동 개발한 브라우저 벤치마크 Speedometer 3가 공개되면서, 실제 웹 앱(리액트, 차트, 텍스트 편집기 등)에 가까운 작업을 기준으로 엔진을 최적화하는 흐름이 강해졌다. SpiderMonkey 팀은 이 시기 다음과 같은 개선을 이어 갔다.

  • 객체를 처음부터 최종 크기로 할당하도록 힌트를 주는 최적화, 너서리(젊은 세대) 할당 확대, 메모리 할당기 경합 감소.
  • 프로토타입 체인 탐색을 건너뛰는 Shape Teleportation 최적화의 성능 절벽(performance cliff) 완화.
  • Ion 컴파일러 백엔드의 레지스터 할당 최적화. 특정 대형 WebAssembly 모듈에서 컴파일 시간을 수십 배 단축했다는 사례가 블로그로 소개되기도 했다.
  • WebAssembly 추측 인라이닝(speculative inlining), 지연 계층화(lazy tiering) 등 고급 최적화 도입.

2025~2026년[편집 / 원본 편집]

  • 2025년 5월 - 파이어폭스 139에서 날짜·시간 처리의 고질적인 문제(Date 객체의 각종 함정)를 해결하는 새 표준 API Temporal을 주요 브라우저 중 가장 먼저 기본 탑재했다.
  • 2025년 - 웹 호환성 개선 프로젝트 Interop 2025에서 파이어폭스는 연초 46점에서 연말 99점으로 점수를 끌어올렸다(실험판 기준). 이 가운데 상당수가 자바스크립트·DOM API 관련 항목이었다.[2]
  • 2026년 2월 - 파이어폭스 148에서 asm.js 최적화를 기본 비활성화했다.[1]
  • 2026년 - 모질라는 앤트로픽과 협력해 AI 모델 Claude로 파이어폭스 코드를 2주간 분석해 22건의 보안 취약점(그중 14건이 높은 등급)과 90여 건의 일반 버그를 찾아 수정했다고 밝혔다. 이는 2025년 한 해 동안 수정된 높은 등급 취약점의 약 5분의 1에 해당하는 규모였다.[3]
  • 2026년 하반기 - 파이어폭스 릴리스 주기가 4주에서 2주로 짧아지면서 SpiderMonkey도 같은 주기로 릴리스되고 있다. 2026년 10월 13일 파이어폭스 158이 출시되었다.

구조[편집 / 원본 편집]

실행 과정[편집 / 원본 편집]

현대 SpiderMonkey는 코드가 얼마나 자주 실행되는지에 따라 점점 더 강력한 계층으로 승급(tier-up)시키는 다단계 구조를 가진다. 처음부터 모든 코드를 최고 수준으로 최적화하면 컴파일 시간이 너무 오래 걸리고, 반대로 인터프리터로만 실행하면 느리기 때문에 자주 쓰는 코드에만 비싼 최적화를 투자하는 전략이다.

단계 역할 특징
파서 / Stencil 소스 코드를 바이트코드로 변환 당장 실행하지 않는 함수는 문법 검사만 하고 넘어가는 지연 파싱(lazy parsing)으로 시간을 아낀다.
바이트코드 인터프리터 처음 실행되는 코드를 실행 가장 느리지만 준비 시간이 0이다.
Baseline Interpreter 인라인 캐시를 활용한 빠른 인터프리터 컴파일 없이도 관찰한 타입 정보를 활용한다.
Baseline Compiler 바이트코드를 단순하게 기계어로 번역 컴파일이 매우 빠르며, 계속 타입 정보를 수집한다.
WarpMonkey(Ion 백엔드) 아주 자주 실행되는 핫 코드를 고급 최적화 함수 인라이닝, 타입 특화, 불필요한 검사 제거, 레지스터 할당 등. 백그라운드 스레드에서 컴파일한다.

최적화 과정에서 세운 가정이 깨지면(예: 지금까지 숫자만 들어오던 변수에 갑자기 문자열이 들어오면) 최적화된 코드를 버리고 하위 계층으로 되돌아가는 역최적화(deoptimization, bailout)를 수행한다. 이 때문에 자바스크립트 성능 최적화의 기본 요령으로 "변수와 객체의 타입·모양을 일관되게 유지하라"는 조언이 나온다.

인라인 캐시와 CacheIR[편집 / 원본 편집]

자바스크립트에서 obj.x처럼 속성에 접근하는 코드는, 매번 객체를 뒤져 'x'가 어디 있는지 찾으면 매우 느리다. SpiderMonkey는 이 지점에서 한 번 찾은 결과를 인라인 캐시(IC)로 기억해 두고, 다음번에 같은 모양의 객체가 오면 바로 결과를 꺼낸다. 이때 "어떤 조건을 검사하고 어떤 동작을 했는지"를 CacheIR이라는 공통 중간 언어로 기록하는데, 인터프리터·Baseline·Warp 모든 계층이 이 기록을 재활용한다. 특히 WarpMonkey는 CacheIR 기록을 그대로 최적화 컴파일의 재료로 쓰기 때문에, 여러 계층이 따로 타입 정보를 관리하던 과거보다 구조가 훨씬 단순해졌다.

객체와 Shape[편집 / 원본 편집]

자바스크립트 객체는 실행 중에 속성을 마음대로 추가·삭제할 수 있어 그대로 두면 매우 느리다. SpiderMonkey는 같은 속성 구성(키와 순서)을 가진 객체들이 같은 Shape을 공유하도록 한다(V8의 Hidden Class와 비슷한 개념). JIT 코드는 "이 Shape이면 x 속성은 몇 번째 칸에 있다"는 식으로 빠르게 접근할 수 있다. 배열은 별도의 요소(elements) 저장소에 연속으로 저장해 C 배열에 가까운 속도를 낸다.

가비지 컬렉터[편집 / 원본 편집]

SpiderMonkey의 가비지 컬렉터는 다음과 같은 특징을 가진다.

  • 세대별(generational) - 대부분의 객체는 금방 버려진다는 점을 이용해, 새 객체를 너서리(nursery)라는 작은 영역에 두고 자주 빠르게 정리한다. 살아남은 객체만 오래 사는 영역(tenured heap)으로 옮긴다.
  • 점진적(incremental) - 수집 작업을 잘게 쪼개 브라우저가 쉬는 틈에 실행해, 화면이 멈추는 시간을 줄인다.
  • 압축(compacting) - 살아남은 객체를 한데 모아 메모리 단편화를 줄인다.
  • 병렬·동시 처리 - 마킹, 정리(sweeping) 등 일부 작업을 여러 스레드에서 처리한다.
  • 사전 승격(pretenuring) - 오래 살아남을 것으로 예상되는 할당 지점의 객체는 처음부터 오래 사는 영역에 할당한다.

WebAssembly 파이프라인[편집 / 원본 편집]

WebAssembly는 자바스크립트와 별개의 파이프라인을 쓴다. 웹 페이지가 무거운 WebAssembly 모듈을 불러오면, 먼저 빠르게 컴파일하는 베이스라인 컴파일러(RabaldrMonkey)로 즉시 실행을 시작하고, 백그라운드에서 최적화 컴파일러(BaldrMonkey, Ion 백엔드 공유)로 다시 컴파일해 완성되는 대로 교체한다. 한동안 ARM64에서는 Rust로 작성된 코드 생성기 Cranelift를 최적화 계층으로 실험적으로 쓰기도 했지만, 이후 Ion 기반으로 일원화되었다.

주요 WebAssembly 기능의 파이어폭스 탑재 시기는 다음과 같다.

기능 파이어폭스 버전 설명
WebAssembly MVP 52 (2017년) 최초 지원
128비트 SIMD 89 (2021년) 벡터 연산으로 이미지·영상·AI 연산 가속
예외 처리 100 (2022년) C++ 예외 등을 WebAssembly에서 직접 처리
WasmGC 120 (2023년) 브라우저의 가비지 컬렉터를 WebAssembly에서 사용. 코틀린, 다트(플러터), 자바 등 GC 언어를 효율적으로 컴파일할 수 있게 되었다.
꼬리 호출 121 (2023년) OCaml, Scheme 등 함수형 언어의 꼬리 재귀 최적화
exnref 131 (2024년) 개선된 예외 처리 방식

이 밖에 64비트 메모리(Memory64), 다중 메모리, 자바스크립트 Promise 통합(JSPI) 등 최신 제안도 순차적으로 구현되고 있다.

최근 탑재된 자바스크립트 기능[편집 / 원본 편집]

기능 파이어폭스 버전 설명
Set 메서드 127 (2024년) union, intersection 등 집합 연산
Float16Array 129 (2024년) 16비트 부동소수점 배열. 머신러닝·그래픽 데이터 처리용
Iterator Helpers 131 (2024년) 이터레이터에 map, filter, take 등 사용
Uint8Array Base64 133 (2024년) 바이너리와 Base64·16진수 문자열 간 변환
RegExp.escape 134 (2025년) 문자열을 정규식에 안전하게 넣기 위한 이스케이프
Temporal 139 (2025년) 새 날짜·시간 API. 주요 브라우저 최초

임베딩[편집 / 원본 편집]

SpiderMonkey는 JSAPI라는 C++ 임베딩 API를 제공해, 다른 프로그램에 자바스크립트 실행 기능을 넣을 수 있다. 임베딩하는 쪽은 전역 객체와 컴파트먼트(compartment, 보안 경계 단위)를 만들고, 그 안에서 스크립트를 실행하며 C++ 함수를 자바스크립트에 노출할 수 있다. 다만 V8과 마찬가지로 API가 버전마다 자주 바뀌기 때문에, 외부 프로젝트는 보통 파이어폭스 ESR(장기 지원판) 버전을 기준으로 따라간다. Rust에서는 mozjs 크레이트를 통해 쓸 수 있다.

사용처[편집 / 원본 편집]

브라우저와 모질라 제품[편집 / 원본 편집]

브라우저 밖[편집 / 원본 편집]

  • GNOME - 리눅스 데스크톱 환경 그놈의 자바스크립트 바인딩 GJS가 SpiderMonkey를 사용한다. 그놈 셸의 상당 부분과 여러 기본 앱이 자바스크립트로 작성되어 있어, 리눅스 데스크톱 사용자는 브라우저를 켜지 않아도 SpiderMonkey를 쓰고 있는 셈이다.
  • MongoDB - 서버 측 자바스크립트 실행 기능($where, mapReduce 등)과 과거의 mongo 셸에서 SpiderMonkey를 사용했다. 원래 V8을 쓰다가 3.2 버전부터 SpiderMonkey로 바꾸었다.
  • Servo - 모질라에서 시작해 현재 리눅스 재단 산하에서 개발되는 Rust 기반 브라우저 엔진. mozjs를 통해 SpiderMonkey를 쓴다.
  • 어도비 애크로뱃 - PDF 문서 안의 자바스크립트(양식 계산 등) 실행에 SpiderMonkey 기반 엔진을 사용하는 것으로 알려져 있다.
  • 아파치 CouchDB - 맵리듀스 뷰를 자바스크립트로 정의할 때 오랫동안 SpiderMonkey를 사용했다.
  • 엣지 컴퓨팅 - 패스틀리(Fastly) 등은 SpiderMonkey 자체를 WebAssembly로 컴파일해 서버리스 환경에서 자바스크립트를 실행하는 방식(StarlingMonkey 등)을 쓴다. 이를 위해 JIT 없이도 빠르게 동작하는 Portable Baseline Interpreter(PBL)가 개발되었다. "자바스크립트 엔진을 WebAssembly로 돌리고, 그 안에서 자바스크립트를 실행한다"는 다소 기묘한 구조지만, 보안 격리와 빠른 시작 시간 덕분에 실용적으로 쓰이고 있다.

보안[편집 / 원본 편집]

자바스크립트 엔진은 웹 페이지가 마음대로 보낸 코드를 실행하고, 특히 JIT 컴파일러는 실행 중에 기계어를 만들어 내기 때문에 브라우저에서 가장 공격받기 쉬운 부분 중 하나다. JIT의 최적화 가정을 속여 타입 혼동(type confusion)을 일으키면, 메모리를 마음대로 읽고 쓰는 공격으로 이어질 수 있다.

  • 2019년 - 암호화폐 거래소 코인베이스 직원들을 노린 표적 공격에서, SpiderMonkey의 배열 처리 관련 타입 혼동 취약점(CVE-2019-11707)이 샌드박스 탈출 취약점과 연계되어 실제로 악용되었다. 모질라는 긴급 업데이트로 대응했다.
  • 2024년 - 해킹 대회 Pwn2Own 밴쿠버에서 보안 연구자 만프레드 폴(Manfred Paul)이 SpiderMonkey 취약점을 이용해 파이어폭스 공략에 성공했고, 모질라는 약 하루 만에 수정판을 배포했다.

이에 대응해 SpiderMonkey는 JIT 코드 영역에 쓰기와 실행을 동시에 허용하지 않는 W^X 정책, 대규모 퍼징, 사이트 격리(Fission)와 프로세스 샌드박스 등의 다중 방어를 적용하고 있다. 앞서 말한 asm.js 코드 제거도 '공격 표면 축소'라는 같은 맥락이며, 2026년에는 AI 모델을 활용한 코드 감사까지 도입되었다.[3]

다른 엔진과의 비교[편집 / 원본 편집]

엔진 개발 주요 사용처 최상위 최적화 계층 특징
SpiderMonkey 모질라 파이어폭스, 그놈 WarpMonkey 최초의 자바스크립트 엔진. 새 표준 기능을 일찍 탑재하는 편
V8 구글 크롬·엣지 등 크로미움 계열, Node.js, Deno TurboFan (+Maglev) 점유율 압도적 1위. 서버 측 생태계까지 장악
JavaScriptCore 애플 사파리, iOS의 모든 브라우저, Bun FTL 4단계 구조(LLInt, Baseline, DFG, FTL)
Chakra 마이크로소프트 구 엣지(EdgeHTML) - 엣지의 크로미움 전환 후 사실상 개발 종료

일반적인 벤치마크에서는 V8과 JavaScriptCore가 앞서는 경우가 많지만, 실제 웹 사용 체감에서는 세 엔진 모두 차이가 크지 않은 수준까지 수렴했다. 엔진의 승부처는 단순 연산 속도보다 페이지 시작 시간, 메모리 사용량, 큰 웹 앱의 반응성 쪽으로 옮겨 가는 추세다.

여담[편집 / 원본 편집]

  • 모질라의 엔진 이름 짓기 전통 덕분에 버그질라와 개발 문서에는 온갖 '○○Monkey'가 등장한다. 엔진 내부 문서에서는 SpiderMonkey를 줄여 SM이라고 부르기도 한다.
  • 브렌던 아이크는 자바스크립트와 SpiderMonkey를 만든 뒤 모질라 재단 설립에 참여하고 모질라 CTO와 CEO를 지냈으나, 2014년 CEO 취임 직후 과거의 정치 기부 논란으로 열흘 남짓 만에 사임했다. 이후 브레이브를 창업했는데, 브레이브는 크로미움 기반이라 자신이 만든 엔진이 아닌 V8을 쓰고 있다.
  • 정규식 엔진은 V8에서, 일부 기능 구현은 다른 엔진과 공유하는 등 경쟁 엔진끼리 코드를 주고받는 일이 드물지 않다. 반대로 V8 역시 SpiderMonkey 팀이 만든 테스트와 제안의 덕을 보고 있으며, 표준 위원회 TC39에서는 세 엔진 개발자들이 함께 언어의 미래를 논의한다.
  • 파이어폭스에서 about:config를 열고 javascript.options.로 시작하는 항목을 보면 개별 JIT 계층(Baseline, Ion/Warp 등)을 켜고 끌 수 있다. 보안을 극도로 중시하는 일부 사용자는 JIT을 꺼서 공격 표면을 줄이기도 한다(대신 느려진다).
  • 엔진 소스 코드 곳곳에는 [SMDOC]이라는 표식이 붙은 상세한 설계 설명 주석이 있어, 엔진 내부를 공부하려는 사람들에게 좋은 교재가 된다.

관련 문서[편집 / 원본 편집]

외부 링크[편집 / 원본 편집]

각주[편집 / 원본 편집]

  1. ↑ 1.0 1.1 Saying goodbye to asm.js - SpiderMonkey 블로그, 2026년 5월 20일.
  2. ↑ Launching Interop 2026 - Mozilla Hacks, 2026년 2월.
  3. ↑ 3.0 3.1 Firefox - 영어 위키백과. 2026년 10월 기준.
원본 주소 "https://www.gaonwiki.com/w/index.php?title=SpiderMonkey&oldid=108900"

최근 바뀜

더 보기